3. Prosessrapport. Forord

Transkript

1 3. Prosessrapport Forord Prosessrapporten er utarbeidet i forbindelse med hovedprosjekt våren 2015 ved Høgskolen i Oslo og Akershus. I denne rapporten vil vi beskrive prosessen bak utviklingen av publiserings- systemet (TEXTOP, Text Operator Panel) for Digitalarkivet. Denne rapporten er delt inn i følgende hoveddeler: Planleggingsfasen Arbeidsteknikker/ arbeidsforhold Verktøy Utviklingsprosess Kravspesifikasjonen og dens rolle Avsluttende del Vedlegg 1

2 Innhold Forord... 1 Innhold... 2 Planlegging... 4 Prosjektstart... 4 Prosjektstyringsdokumenter... 4 Milepælsplan... 4 Fremtidsplan og møtelogger... 5 Risikoplan... 5 Arbeidsteknikker... 7 Kommunikasjon med veileder og oppdragsgiver... 7 Smidig utvikling... 8 Arbeidsforhold... 9 Verktøy... 9 Versjonskontroll... 9 Utviklingsverktøy Fildeling Kommunikasjonsverktøy Utvikling og web Rammeverk Programmeringsspråk Server Dokumentasjon og backup Utviklingsprosessen Oppstartsfase Datainnsamling Målgruppe og behov Kravspesifikasjonen og dens rolle Hva ble gjort av endringer Oppfyllelse av krav Avsluttende del Samarbeid i gruppen Eget utbytte Utbytte/ fremtid av produkt Oppdragsgivers ord Referanser/ kilder Vedlegg

3 Vedlegg 1. Gantt- skjema - Fremtidsplan Vedlegg 2. Oppdragsgivers ord

4 Planlegging I dette kapitlet tar vi for oss planleggingen av prosjektet, tanker i prosjektstarten og ulike mål vi har hatt for prosjektperioden. Prosjektstart Gruppen ble startet på bakgrunn av tidligere god erfaring med sammensetningen og det ble raskt avklart at også dette prosjektet skulle gjennomføres av disse deltakerne/oss tre. Det første gruppemøtet ble avholdt allerede i oktober 2014 hvor det ble dannet en oversikt over tema for prosjektet samt diskutert oppdragsgiver. Ettersom ett av gruppemedlemmene hadde en bekjent hos IT avdelingen i Arkivverket var det naturlig å diskutere om dette kunne være aktuelt. Ettersom gruppemedlemmene var kjent med Riksarkivet og Digitalarkivet forelå det allerede en interesse for fagfeltet, og det var klart at akkurat dette fagfeltet var aktuelt. Gruppen melte tidlig sin interesse til vedkommende hos Digitalarkivet og tilbakemeldingen var utelukkende positiv. Et aktuelt oppdrag ble presentert per mail av oppdragsgiver og det ble gitt en innføring i funksjonalitet og brukergrensesnittet som systemet skulle ha. På det første møtet sammen ble det presentert en oversikt over database og mockups til systemet som skulle lages. Ettersom gruppen hadde klar interesse for temaene som var presentert ble et samarbeid innledet, og dermed ble Digtalarkivet vår oppdragsgiver. Prosjektstyringsdokumenter Milepælsplan Allerede under forprosjektrapporten ble det dannet en milepælsplan. Denne inkluderte de viktigste delmålene som var ansett for å kunne skape en god flyt gjennom prosjektet og som samtidig være motiverende gjennom prosessen. Milepælsplanen ble i stor grad fulgt og oppfylt. Herunder presentert: 08. februar 2015 ferdig testing av domenemodell 22. mars 2015 ferdig med å implementere logisk lag 30. mars 2015 ferdig med å implementere controllere 11. mai 2015 ferdig brukergrensesnitt 26. mai 2015 kl innlevering prosjektrapport juni 2015 presentasjon av prosjekt. 4

5 Fremtidsplan og møtelogger I tillegg til milepælsplanen, ble det også dannet en fremtidsplan i et gantt- skjema (se figur 3.1). Denne fremtidsplanen ble dannet ut ifra milepælene vi hadde satt oss, men ble på noen punkter endret underveis for å tilpasse den best nok, ettersom vi med tiden fikk mer innblikk i prosjektet. Denne gav oss en oversikt over hvor vi burde befinne oss på hvilket tidspunkt. Figur 3.1: Gantt- skjema For større bilde, se vedlegg 1 Dette ble ansett som et godt verktøy i både planlegging og videre utførelse av prosjektet. Gjennom hele prosjektperioden er det også ført møtelogger som dokumenterer alle møtene både internt i gruppen og også mellom gruppen og oppdragsgiver. Her er det notert om hva som har blitt utført og hva som eventuelt ble besluttet i korthet. Møteloggen er derfor ansett som en enkel måte for å se hva som er blitt uført til enhver tid og også eventuelle beslutninger som ble gjort dersom det skulle være aktuelt å gå tilbake for å se på utført arbeid. Møteloggene kan finnes på prosjektsiden vår i HTML- format under menyen Dagbok. Risikoplan En risiko plan ble opprettet og den inneholder hendelser og uforutsette ting som kan oppstå under prosjektperioden. Rangeringen er nummerert, og beskriver følgende: Beregning av sannsynligheten for en hendelse er rangert fra tallet 1 til 4 som utdypet under: 1: ikke sannsynlig 2: mindre sannsynlig 3: sannsynlig 4: svært sannsynlig 5

6 Beregning av konsekvensen av arbeidsprosessen dersom en hendelse oppstår er rangert tallet 1 til 4 som utdypet under: 1: ikke alvorlig 2: alvorlig 3: kritisk 4: svært kritisk Kolonnen for risikofaktoren viser om det er sannsynlig at hendelsen oppstår. Dette er summen av sannsynlighet og konsekvens, som danner grunnlaget for den helhetlige risikoen. 1-3: liten risiko (grønn) 4-5: middels risiko (gul) 6-8: stor risiko (rød) Hendelse Sannsynlighet Konsekvens Risiko Sykdom Manglende oppmøte Konflikt i gruppen Ikke holde avtaler Tap av data Tidsmangel Tekniske problemer Misforståelser med oppdragsgiver Sykdom Faren for sykdom der et gruppemedlem ikke kan bidra over en lengre periode er alltid til stede. Men om to gruppemedlemmer blir syke, vil dette få en middels risiko som kan svekke gruppen- over- en- periode. Tiltak: Kontakt via Skype, telefon og Facebook. Fordele oppgaver. Manglende oppmøte Manglende oppmøte svekker hele arbeidsprosessen under prosjektperioden, og kan føre til at arbeid blir lagt over på andre, uten at det var planlagt. Tiltak: Minkende tilstedeværelse, vil føre til utkastelse fra gruppen. Konflikt i gruppen Konflikter i gruppen kan oppstå dersom medlemmene har forskjellig oppfatning og meninger om oppgaven og arbeidsprosess. Tiltak: Komme til en enighet der alle parter føler seg rettferdig behandlet om en konflikt skulle oppstå. 6

7 Ikke holde avtaler Om avtaler ikke holdes, vil det få en konsekvens ovenfor hele gruppen, og konflikter kan oppstå. Tiltak: Ikke tillate at det blir et gjentakende problem, true med utkastelse. Tap av data Om tap av data oppstår, vil dette få store konsekvenser for gruppen. Dette vil svekke arbeidet, eller i verste fall starte prosjektet på nytt. Tiltak: Alltid lagre og ta backup flere steder. Bruke Github og Dropbox. Tidsmangel Prosjektet kan bli for omfattende ut i fra det vi har planlagt, og vi kan sitte igjen med mye arbeid mot slutten. Tiltak: Omfordele arbeidsoppgaver, omprioritere og deler av prosjektet kan tas helt ut, avsluttes helt, eller minkes. Tekniske problemer Rammeverk som blir brukt, kan hindre fremdrift i arbeidsprosessen, det samme kan samt dårlig maskinvare hos gruppemedlemmene. Tiltak: Bruke korrekt utstyr og programvare. Misforståelse med oppdragsgiver Ulik oppfatning av arbeidsmetode, forventning til arbeid kan være forskjellig. Tiltak: Holde tett dialog med oppdragsgiver, samt opptre profesjonelt. Arbeidsteknikker I dette kapitlet blir det utdypet hvilke arbeidsteknikker som er benyttet gjennom prosjekt- perioden. Herunder hva slags kommunikasjon vi har brukt, hvilke utviklingsteknikker og hva slags arbeidsforhold det har vært. Kommunikasjon med veileder og oppdragsgiver Kommunikasjon med veileder og oppdragsgiver ser vi på som svært god under prosjekt- perioden. Kommunikasjonen med oppdragsgiver har fungert på en profesjonell måte, enten i møte med oppdragsgiver eller spørsmål vedrørende applikasjon og utvikling. Oppdragsgiver har også fungert som en veileder for oss og for selve applikasjon. Kommunikasjonen med veileder fra HiOA, Michael Preminger, var mest utbredt i oppstart- og i avslutningsperioden. Denne veiledningen hadde fokus på selve prosjektet som en helhet, slik som prosjektstyring og rapporter, og ikke selve utviklingen. Kommunikasjonen med veileder er ansett som svært bra da veileder har holdt seg oppdatert gjennom arbeidsprosessen ved å følge med på 7

8 møtelogger og å ha tilgang til dokumenter. Han har også vært tilgjengelig for å besvare spørsmål og møtt opp på eventuelle ønskede møter fra gruppens side. Smidig utvikling Utviklingsteknikken vi har brukt, er smidig utvikling. Dette prosjektet er ansett som smidig utviklingsteknikk fordi vi står mer fritt i arbeidsformen. Og ettersom punktene i prosjektet mest sannsynlig ville endre seg underveis, var denne arbeidsformen rett for oss. Sammen med Scrum, Kanban og Fossefallsmetoden er denne utviklingsmetoden et av de mest kjente utviklingsteknikkene i systemutvikling. Det som gjenspeiler seg for oss som gruppe og den smidige utviklingen, er oppgaver som: (ref: blog.kjempekjekt) Kravanalyse og kundekontakt: Hele tiden jobbe med å forsøke å forstå behovet til kunden. I vår sammenheng er kunden ansett som oppdragsgiver. Prosjektplanlegging: Å hele tiden tenke smart i forhold til hva neste steg optimalt sett bør være. Altså sette opp en god fremtidsplan, samt ha milepæler. Design og arkitektur: Å hele tiden tenke på hvordan løsningen bør designes for å være mest mulig fleksibel. Altså tilfredsstille Digitalarkivets behov mest mulig. Prosjektstyring: Å hele tiden kommunisere med alle andre teammedlemmer om endringene som skjer. Altså ha god kommunikasjon innad i gruppen, med veileder og oppdragsgiver. Implementasjon: Å hele tiden tilføre verdi gjennom å kode løsningen med så høy kvalitet som mulig. Altså tilfredsstille Digitalarkivets behov mest mulig. Quality Assurance: Å hele tiden tenke kritisk og teste løsningen så effektivt som mulig. Samtidig kan vi si at vi har vært innom Scrum- teknikken innenfor den smidige utviklingen. Vi har gjennom prosjektperioden jobbet i forskjellige faser, eller i ulike sprintere, fra start til slutt: (ref: prosjektveiviseren) Konsept - idé, behov, mål. Her definerer vi funksjonelle krav sammen med oppdragsgiver. Planlegge - styringsunderlag. Her hadde vi fokus på å etablere styringsunderlaget for prosjektet. Hvem skulle være talsmann innad i gruppen? Hvordan skulle dette prosjektet danne gode verdier? Gjennomføre - gjennomføringsfaser. Fra startfasen av prosjektet opparbeidet vi flere styringsdokumenter (finnes på prosjektsiden). Dette hjalp oss på veien under prosjektperioden pga. strategier og prosjektets rolle var utarbeidet i allerede planleggingsfasen. Avslutte - overlevering, evaluering. Her ble klargjøring av prosjektet fullført. Var i stand til å avslutte prosjektet. 8

9 Realisere - gevinster. Prosjektet er formelt avsluttet. Overlevering av applikasjon og dokumentasjon til oppdragsgiver og veileder. Vi har hatt erfaring med Scrum fra tidligere prosjekter, og føler at smidig utvikling har fungert godt for oss som gruppe. Vi har lært mye, og skaffet oss erfaring med en metode som er svært effektiv blant annet i næringslivet. Noe vi ser på som svært positivt. For gruppens del, fungerte Daniel som Scrum Master. Men rollen har ikke i stor grad vært vektlagt ettersom vi er et mindre team på kun tre studenter. Vi har heller ikke hatt fokus på daily standups, siden vi hele tiden har vært oppdatert på hverandres oppgaver og arbeid. Arbeidsforhold Lokaliseringen vi har hatt som arbeidssted har variert under hele hele prosjektperioden. Vi har arbeidet på Høgskolen i Oslo og Akershus, Riksarkivet og hjemme hos de forskjellige gruppemedlemmene. Gruppen hadde aldri noen faste rutiner på hvor vi befant oss, men varierte mellom disse fasilitetene så langt det lot seg gjøre. HiOA Vi har hatt campus p35 på HiOA Pilestredet som vårt hovedsted. Her har vi benyttes oss av ulike grupperom og datalinjens lokaler. Riksarkivet Vi har benyttes oss av kontorfasiliteter i Riksarkivets lokaler på Sognsvann. Her har vi både holdt møter med oppdragsgiver og hatt muligheten for å sitte og jobbe. Figur 3.2: Riksarkivets lokaler, Sognsvann Verktøy I dette kapitlet tar vi for oss hva som ble benyttet av verktøyene og hjelpemidler under for å gjennomføre prosjektet. Her er også tiltak for hvordan dataene skal tas vare på. Versjonskontroll "En versjonskontroll er et system som holder styr på forandringer i en fil, eller et sett av filer, over tid, slik at man kan finne tilbake til spesifikke versjoner senere." (ref: git- scm) Det kan være programvare laget for å dele filer i prosjekter. Derfor er det et viktig ståsted å ha et fungerende system på det nevnte, slik at prosjektet kan gli på en rett linje. 9

10 Utviklingsverktøy Fildeling Dropbox er en skytjeneste som lar brukere lagre data med hverandre. Den gir muligheten til å dele filer og mapper ved å invitere brukere, samt holde styr over hvem som kan ha tilgang til dataene. Vi har brukt Dropbox til å dele dokumenter, bilder og prosjektside. Github er et versjonskontrollsystem ved et web- basert hosting system for Git- prosjekter. Sammen med oppdragsgiver har vi hatt samme tilgang. Github har egne kommandoer, pull og push, for synkronisering med andre repostorier. Dette gir muligheten for alle- til- alle synkronisering. Her har man hele tiden en oversikt over hvem som har tilgang til hvem som jobber med prosjektet og hvilke endringer de foretar seg. For å kunne se siste oppdaterte versjon, er det en commit av endringer som skriver en beskrivelse av endringene. Dette har medlemmene muligheten for å se, dermed er det enkelt å se siste oppdaterte versjon og de endringer som er blitt gjort. Kommunikasjonsverktøy Facebook er et sosialt nettverk som tilbyr en enkel, men en god chat- funksjon som lar parter sende meldinger med hverandre. Vi har brukt denne funksjonen flittig via kommunikasjon innad i gruppen. Vi har hatt muligheten for å avtale møter, samt stille raske spørsmål til hverandre. E- post er et verktøy som tilbyr elektronisk kommunikasjon med en og flere parter. E- post er blitt brukt flittig i sammenheng med kommunikasjon med veileder og oppdragsgiver. E- post er blitt brukt der større filer ble delt mellom gruppe og veileder. Utvikling og web Microsoft Office Word er et tekstbehandlingsprogram. Dette programmet har vi brukt til all dokumentasjon i prosjektet. Programmet gjør det enkelt å plassere tekst og bilder sammen. Sublime Text er et teksteditorprogram som vi har brukt i sammenhengen med utviklingen av kode. Sublime er tilgjengelig både for Mac OS X, Windows og Linux. Vi valgte dette teksteditorprogram fordi det er veldig oversiktlig og gir en fin struktur på koden. Sequel Pro er et database management for Mac OS X. Dette programmet ble brukt for å sjekke relasjoner mellom tabeller i databasene. Lage endringer og 10

11 nye tabeller. MySQL Workbench er et visuelt verktøy for databasearkitektur. Her har vi brukt datamodellering, SQL- utvikling og omfattende administrasjonsverktøy for selve databasen. MySQL Workbench er tilgjengelig både for Mac OS X, Windows og Linux. Mamp er en lokal server. Denne gav oss muligheten for at PHP- prosjektet enkelt kunne kjøres offline. Ble brukt for Mac OS X. Programmet ble brukt både for utviklingen av applikasjonen og prosjektsiden. Xampp er en lokal server. Denne ga oss muligheten for at PHP- prosjektet enkelt kunne kjøres offline. Ble brukt for Windows. Programmet ble brukt både for utviklingen av applikasjonen og prosjektsiden. Microsoft Paint er et program som blir brukt til bilderedigering/ tegning. Programmet har begrensede funksjoner, men er fortsatt til hjelp. Her har vi redigert enkle logoer og bilder som ikke krever mye fokus på detaljer. Adobe Photoshop er et bilde og redigeringsprogram fra Adobe. Programmet er stort, og tilbyr en rekke store funksjoner som ikke Paint leverer. Programmet er blitt brukt til større redigeringer av logoer og bilder, brukt i både applikasjon og i dokumentasjonen. Rammeverk Mako framework (ref: makoframework) er et open- source applikasjons- rammeverk skrevet i PHP. Rammeverket inneholder en rekke komponenter (restful routing, ORM, autentisering osv.) og har som mål å gjøre det raskt og enkelt å lage raske og sikre webapplikasjoner. I likhet med mange andre rammeverk er det inspirert av MVC- designmønsteret. Mako framework er et egenutviklet rammeverk utviklet av Frederic Østby hos Digitalarkivet. MVC (Ref: Tor Krattebøl) Model View Controller er et applikasjonspattern. Dette betyr at det er en standard applikasjonsarkitektur som er brukt av opp til flere leverandører av webapplikasjoner. Arkitekturen består av tre hoveddeler, en modell (Model), en kontroller(contol), og en presentasjonsdel (View). Enkelt kan vi si dette om hvert av delene: - Model: Lagrer og returnerer data fra databasen. - View: viser data. - Controller: flytter på data. 11

12 Programmeringsspråk PHP er (ref: itpro) et programmeringsspråk for utvikling av dynamiske nettsider. PHP er et server- side script. Det vil si at koden ligger på serveren og blir kjørt derfra. Når en bruker kommer og ser nettsiden, vil man ikke se kildekoden, men den HTML- teksten som PHP- koden genererer. HTML er et formateringsspråk for formatering av nettsider. Enkelt kan det forklares at HTML koder, er kodene som brukes for å skape nettiden slik man ser den på Internett. Bootstrap er (ref: dreis) et verktøy for utseende på nettstedet, altså et rammeverk med en enkel stilguide. Dette rammeverket bygger på HTML og CSS. Jquery er (ref: Wikipedia) et JavaScript- bibliotek utviklet for å forenkle klientskripting av HTML. Dette brukes for å kunne lettere navigere et dokument. Server NGINX - open- source HTTP- server. APACHE - open- source web- server. Dokumentasjon og backup Vi brukte Word til å produsere dokumentene våre. Vi delte inn dokumentene etter hvilke kategori de tilhørte og Dropbox ble brukt til å dele de ulike dokumentene. Ulempen ved bruk av Dropbox til dette arbeidet var at vi ikke kunne redigere dokumentene samtidig. Derfor var vi nødt til å redigere de lokalt, for og deretter legge de inn i Dropbox. Dette ble ikke ansett som et stort problem og la dermed ikke stor vekt på denne svakheten. Vi kunne brukt Google Docs ettersom alle i gruppen hadde en Google- konto, men følte at det ble mye dokumenter som ville ligge spredt overalt, og bestemte oss derfor tidlig å jobbe lokalt. Utviklingsprosessen Dette kapitlet beskriver prosessen med å utvikle applikasjonen i ulike faser. Her vil vi ta for oss utfordringer ved enkelte funksjonaliteter fra oppstart til produktutviklingen. Detaljer i arkitektur og oppbyggingen av det som befinner seg bak kulissene er beskrevet i kap. 4 produktrapport. 12

13 Oppstartsfase Siden oppstarten og det første møte med oppdragsgiver, snakket vi sammen om hva prosjektet gikk ut på, hva som var forventet og hvordan vi burde starte opp. Etter at forskjellige biter var satt på plass hos oppdragsgiver og hos oss, startet vi med forprosjektrapporten og satte oss inn i hva som skulle utarbeides. Vi fikk en gjennomgang hos oppdragsgiver i Mako framework sammen med Frederic Østby og databasen som tidligere var utarbeidet av Espen Tønnessen. Her fikk vi oppklaringer i ulike spørsmål vi stilte til både system og database. Datainnsamling Helt fra starten av fikk vi retningslinjer av oppdragsgiver for hvordan applikasjonens funksjonalitet skulle fungere, men dette var ingen absolutt fasit. Vi fikk forskjellige utkast på hvordan applikasjonen skulle se ut, og dannet brukergrensesnittet mest mulig ut ifra dette. Retningslinjene for funksjonalitet stod noe mindre fritt, ettersom database og bruksmønster allerede var opparbeidet på forhånd. Men eventuelle kutt, eller endringer var fult mulig. Målgruppe og behov Digitalarkivet er et stort nettsted for publikum. Historiske og nåværende hendelser og bøker kan finnes her. Hovedoppgaven til Digitalarkivet er å gjøre digitalt kildemateriale tilgjengelig ute på nett. Ettersom Digitalarkivet er i en prosess med å modifisere sine nettsider, behøver de et enklere system for brukerne slik at nettstedet blir i økt grad tilgjengelig for brukerne. Redaksjonen hos Riksarkivet som arbeider med nettsidene, har hovedkontor i Bergen hos Statsarkivet. Her har de rettledning for brukerne og holder kontakt med brukerne via telefon, e- post og i debatter. Redaksjonen har og ansvar for informasjonen på nettsidene, samt mottak og publisering av digitale kilder. Redaksjonen hos Riksarkivet som arbeider med nettsidene, har hovedkontor i Bergen hos Statsarkivet. Her har de rettledning for brukerne og holder kontakt med brukerne via telefon, e- post og gjennom debatter. Redaksjonen har også ansvar for informasjonen på nettsidene, samt mottak og publisering av digitale kilder. Men ettersom det nå er utviklet et publiseringssystem vil brukerne kunne ta store deler av arbeidet hos redaksjonen. Det gjør kommunikasjonen mellom redaksjonen og brukerne enklere, samt at publikum har muligheten til å gi mer kildemateriale til Digitalarkivet. Brukere skal selv kunne opprette artikler som legges ut på nettsiden. (ref: Arkivverket) 13

14 Kravspesifikasjonen og dens rolle Kravspesifikasjonen er bestemt av oppdragsgiver og deres brukere. Kravspesifikasjonen er med på å definere prosjektets rammer og applikasjonens funksjonalitet. Kravspesifikasjonen, som finnes i kapittel 2 i denne sluttdokumentasjonen har hatt en veiledende rolle under hele prosjektperioden. Den har bidratt til at vi kunne følge en rød tråd og dermed holde oss innenfor gitte rammer. Kravspesifikasjonen var til for å endres, slik at utviklingen av prosjektet ikke stoppet, eller belag seg på de forhåndssatte kravene, men gav oss muligheten for en dynamisk prosess der oppdragsgiver var sikret et best mulig resultat til slutt. Kravspesifikasjonen har hatt endringer underveis. Dette gjelder i hovedsak ulike funksjonaliteter som er tilknyttet databasen. Hva ble gjort av endringer I løpet av prosjektet har vi funnet noen svakheter i databasen. Det har vært begrensninger som gjør det umulig å oppfylle kravene som oppdragsgiver har gitt til oss. Vi har brukt biblioteker som gjør det mulig og enkelt formatere tekst som HTML markup, men det var ikke tatt høyde for å lagre ferdig kompilert HTML kode, slik at det ikke var nødvendig å kompilere det for hver nettside som ble lastet, vi la derfor til felter i databasen som kunne lagre ferdig cachet HTML markup. Det var heller ikke noen felter for å legge et hovedbilde til en artikkel, og vi måtte dermed legge til alle feltene i databasen og koden som trengs for å håndtere bildeopplastning. Oppfyllelse av krav Alle svakheter som vi oppdaget ble diskutert med oppdragsgiver, noen begrensninger måtte fjernes og felt måtte legges til i databasen, men alle svakheter ble håndtert og en løsning ble implementert for å tilfredsstille endringene som måtte gjøres. Avsluttende del I denne delen vil det vil bli gitt en beskrivelse av hvordan prosjektet har betjent oss og hvilke utbytter vi fikk gjennom prosjektperioden Samarbeid i gruppen Samarbeidet i gruppen har fungert på en vellykket måte. Dette var høyst nødvendig for å kunne levere løsningen av det omfanget vi valgte å sette oss inn i. Vi har jobbet som et team, både sammen med oppdragsgiver og internt i gruppen. Da dette samspillet fungerte, klarte vi å arbeide mot de milepælene som ble satt i startfasen av prosjektet. 14

15 Som gruppe og team er det ikke til å unngå at det oppstår uenigheter internt i gruppen. Derfor bestemte vi å akseptere konstruktive og faglig innhold ved enhver diskusjon. Dette så vi på som et viktig avgjørelse for å gjøre arbeidet best mulig hele tiden. Det var viktig at hver og en ble hørt, og at alle kunne ytre sin mening. Problemene ble løst på en profesjonell måte der problemene ble tatt på en profesjonell måte, og løst deretter. Eget utbytte Alle i gruppen har hatt erfaring med samme type arbeid fra tidligere prosjekter, men av betydelig mindre omfang. Under utviklingen av applikasjonen har vi møtt på kjente og ukjente problemer og satt oss inn i nye og kjente rammeverk. Gjennom prosjektet har vi blitt kjent med nye utviklingsverktøy og rammeverk, Mako. MVC- oppbyggingen var kjent fra tidligere emner på studiestedet, og ga oss derfor et bra utgangspunkt for å ta en utfordring ved å sette oss inn i nye rammeverk, derav Mako. Vi har ekspandert våre kunnskaper rundt utviklingen, og blitt kjent med hvordan moderne systemer blir bygget opp fra innsiden. I vårt tilfelle om hvordan valg av arkitektur, design og oppbyggingen av APIene er blitt utarbeidet. Det har vært verdifull læring å jobbe som konsulenter for et statlig selskap. Vi har fått mye erfaring med hvordan arbeidsrutinene i en IT- avdeling fungerer og kommunisert med ansatte under utviklingen av applikasjonen. Utbytte/ fremtid av produkt Systemet vil bli satt sammen som en pakke i Digitalarkivets nye systemer som er under utvikling pr. dags dato, og vi er som studentgruppe svært fornøyde med å kunne levere et fungerende produkt til oppdragsgiver. Gruppen ser det stort at Arkivverket faktisk velger å ta i bruk det noen studenter har laget under et studentprosjekt. Applikasjonen vil være en stor del av hverdagen til flere ansatte og brukere utenfor veggene i Arkivverkets lokaler. Alt i alt er vi svært fornøyde med læringsutbyttet under prosjektperioden, fra startfasen november 2014 til sluttfasen mai Vi har hatt muligheten til å delta i et aktivt arbeidsmiljø på Arkivverket, snakket med erfarende personer innen fagfeltet og fått et oversiktlig bilde om hva fremtiden kan bringe oss etter studenttiden. Oppdragsgivers ord Se vedlegg 2. 15

16 Referanser/ kilder Arkivverket. Om Digitalarkivet. Hentet fra Digitalarkivet/Organisasjon- og- tenester/organisasjon Blog.kjempekjekt. Om smidig utvikling. Hentet fra er- smidig- utvikling Dreis. Om bootstrap. Hentet fra kongen- av- github/ Git- scm. Om versjonskontroll. Hentet fra scm.com/book/no- nb/v1/komme- i- gang- Om- versjonskontroll Itpro. Om PHP. Hentet fra hva- er- php/ Mako framework. Om Mako framework. Hentet fra MVC. Om MVC. Hentet fra Tor Krattebøl, Webapplikajsoner, forelesning uke MVC Prosjektveiviseren. Om scrum. Hentet fra Wikipedia. Om JQuery. Hentet fra 16

17 Vedlegg Vedlegg 1. Gantt- skjema - Fremtidsplan 17

18 Vedlegg 2. Oppdragsgivers ord Riksarkivet er veldig takknemlige for å få anledning til å tilby en oppgave til studentene. I Riksarkivet, som i mange andre virksomheter, har vi ikke ressurser til å innfri alle behov. Studentenes arbeid gjør at vi står bedre rustet til å møte de forventningene som stilles til Seksjon for digital tilgjengeliggjøring, IT- avdelingens utviklere og Digitalarkivet. For mange brukere av Digitalarkivet er det en god del av kildematerialet og begrepene som kan være tungt å sette seg inn. I dag ligger informasjonen spredt rundt omkring, både på Arkivverkets nettsider og i menyene i Digitalarkivet. Studentenes arbeid har resultert i et administrasjonsverktøy som gjør det mulig for oss å berike kildematerialet i Digitalarkivet med forklarende tekster i den konteksten brukeren befinner seg i. Dette vil på sikt gi en langt bedre brukervennlighet og ikke minst en mer pedagogisk tjeneste. I tillegg kan verktøyet innlemmes i andre tjenester vi har på plakaten. Våre opprinnelige tanker har blitt utfordret på en konstruktiv måte av studentene. De har ikke nølt med å stille spørsmål og å kontrollere at de har forstått intensjonen med funksjonaliteten på rett måte, men samtidig har de jobbet svært selvstendig. Vi vil takke for et godt samarbeid og et vel utført arbeid. For Riksarkivet Espen Tønnessen Seniorrådgiver Seksjon for digital tilgjengeliggjøring 18