Innholdsfortegnelse. Side 6 av 135

Transkript

1

2

3 Forord Denne delen av rapporten vil ta for seg de tekniske sidene av applikasjonene. Den er delt opp slik at hver applikasjon har sitt eget kapittel som tar for seg alt ved den applikasjonen. Kapittel 1 (innledningen) og 2 (det endelige produktet) er de samme som kapittel 1 og 2 i produktdokumentasjonen. Det er derfor ikke nødvendig å lese disse kapitlene dersom De har lest de tilsvarende i produktdokumentasjonen.

4

5 Innholdsfortegnelse 1 Innledning Om Noark Dagens situasjon Vårt prosjekt Gruppen Oppdragsgiver Det endelige produktet Facebookapplikasjon (FIR) Mobil- og skrivebordsapplikasjon Planlegging og forberedelser Gruppen blir til Valg av oppgave Analyse Kostnad Mål og rammebetingelser Oppstartsfasen Roller i gruppen Samarbeid og møter Styringsdokumenter Metodikk Rapid Application Development Teknologier Noark Valg av utviklingsverktøy Facebookapplikasjon Mobil -og skrivebordsapplikasjon Utviklingsteknologier NET Android Andre tekniske hjelpemidler Dropbox Google Docs Utviklingsprosessen FIR (Facebookapplikasjon) Kommunikasjon med Facebook Side 6 av 135

6 6.1.2 FIR Tidlig prototype Fra skrivebordsapp til webapp Utvikling i henhold til kravspesifikasjon Marc (Android applikasjon) Selvlæring i Android Fra daemon til full brukerinteraksjon Utvikling i henhold til kravspesifikasjon Utfordring med meldinger Eksportering til XML Marc (skrivebordsapplikasjon) Oppsett av Noark Testing Brukertesting FIR Marc Foredrag for målgruppen Kravspesifikasjonen og dens rolle Kravspesifikasjon Endringer etter oppdragsgivers ønsker Innfrielse av kravene Avslutningsfase Ferdigstilling av prosjektet Konklusjon Kilder Vedlegg Arbeidsplan Fremdriftsplan Risikoanalyse Side 7 av 135

7 Side 8 av 135

8 Side 9 av 135

9 Prosessdokumentasjon Kapittel 1: Innledning 1 Innledning Dette kapittelet er identisk med kapittel 1 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Denne delen består av prosessdokumentasjon. Først vil du få en innføring i prosjektet, gruppen og oppdragsgiver. 1.1 Om Noark Norsk arkivstandard (Noark) er en standard for elektroniske journalsystemer som stiller krav til arkivstruktur, metadata og funksjonalitet. Noark 5 skal kunne brukes for alle typer arkivdanning, uavhengig av teknologisk løsning og type organ. Alle former for aktiviteter som skaper dokumenter som det er viktig å sørge for at oppbevares og gjenfinnes i autentisk form, skal i prinsippet inngå i en løsning for arkivdanning. Dette er helt uavhengig av offentlig eller privat sektor, om dokumentene inngår i tradisjonell saksbehandling, hvor mange år de skal oppbevares eller om de skal avleveres til depotarkiv. Noark 5 er den siste utgaven av Noark-standarden, og ble publisert sommeren Fra og med mars 2011 er Noark 5 versjon 3.0 gjeldende versjon. Figur 1.1: Noark 5 kjernen Side 10 av 135

10 Kapittel 1: Innledning Noark 5 Dokumentfangst 1.2 Dagens situasjon Mye av informasjon som finnes på nettet i dag er ikke i et format som passer til å lagre i et dokument. Se f.eks. Facebook grupper(master i Hardanger), informasjonen som kommer ut herifra kunne vært fint å fått dokumentert, men er vanskelig pga. formatet det er i. Kommunikasjon per SMS mellom politikere og andre som jobber i offentlig virksomhet, blir i dag ikke arkivert eller gjort tilgjengelig for ande. Et problem som ble tydelig da Jens Stoltenberg sendte en SMS til DnB Nor-sjefen i 2008, hvor det ble kritisert om at en politiker hadde hatt uoffisiell kontakt om politiske beslutninger. Ved hjelp av Noark og nødvendig programvare på mobiltelefonen skal det være mulig å arkivere denne type kommunikasjon. 1.3 Vårt prosjekt I forbindelse med oppdragsgivers arbeid med Noark 5, og et ønske om dokumentfangst fra utradisjonelle kilder, har vi utviklet 3 applikasjoner. En mobilapplikasjon som gjør tekstmeldinger tilgjengelig for en skrivebordsapplikasjon. Denne skrivebordsapplikasjonen tar seg av journalføring og arkivering til Noark-arkivet. Det er også utviklet en facebookapplikasjon som i likhet med skrivebordsapplikasjonen tar seg av journalføringen og arkivering, men da med meldinger fra Facebook. 1.4 Gruppen Prosjektgruppen består av tre it-studenter ved Høgskolen i Oslo: Joakim Vorren 22år, Lars-Erik Arnesen 24år og Daniel Brunstad Diakoff 21år. Alle tre kjenner hverandre godt fra tidligere prosjekter i forbindelse med bachelorgraden i informasjonsteknologi. 1.5 Oppdragsgiver Høgskolen i Oslo (HiO) ble opprettet 1. august 1994 og er landets største høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og over 20 masterstudier. Forskning og utvikling (FOU) ved Avdeling for journalistikk, bibliotek- og informasjonsfag (JBI) består pr av 3 professorer, 18 f. amanuenser, 1 forsker, 6 lektorer, 20 høgskolelektorer, 1 høgskolelærer og 7 dr. gradsstipendiater. Blant fagpersonaler er det 15 med dr. grad. Vår kontaktperson, Thomas Sødring er førsteamanuensis ved JBI og har i lengre tid jobbet med utvikling av Noark 5. Side 11 av 135

11 Prosessdokumentasjon Kapittel 2: Det endelige produktet 2 Det endelige produktet Dette kapittelet er identisk med kapittel 2 i prosessdokumentasjonen, og det er derfor ikke nødvendig å lese det dersom du har lest den. Her følger en kort beskrivelse av produktet vi har laget. Mer informasjon om funksjonalitet og bruk vil komme i produktdokumentasjonen og brukerveiledningen. 2.1 Facebookapplikasjon (FIR) Facebookapplikasjonen, eller Facebook Information Retriever som vi har døpt den, har som funksjon å hente og lagre informasjon som brukeren definerer som journalføringspliktig. Figur 2.1: Facebookapplikasjon (FIR) Applikasjonen henter inn alle grupper, sider og arrangementer som brukeren administrerer. Brukeren kan så velge en gruppe, side eller arrangement han vil journalføre, velge hvilke meldinger han vil ha med, merke disse og få opp en forhåndsvisning. Er brukeren fornøyd, kan han/hun velge å sende inn og dokumentet vil bli gjort om til et format Noark kan håndtere, og lagres i arkivet. Side 12 av 135

12 Kapittel 2: Det endelige produktet Noark 5 Dokumentfangst Figur 2.2: Dataflyt til facebookapplikasjon (FIR) 2.2 Mobil- og skrivebordsapplikasjon Den andre løsningen består av to applikasjoner. Den ene er en mobilapplikasjon på Android som viser deg en liste over personer du har sendt meldinger med, enten med navn du har lagret i kontaktlisten din, eller med nummer om du ikke har de lagret. Du kan videre velge personer, og lagre meldinger fra disse på minnekortet til mobilen i en XML fil. Denne filen kan enkelt transporteres til PC og deretter videre inn til Noark. Figur 2.3: Dataflyt til Marc Når du nå kobler mobilen til PC-en skal vi ta i bruk den andre delen av løsningen. Dette er en skrivebordsapplikasjon som finner mobilen, og henter ut meldingene som vi nå har lagret på mobilens minnekort. Her kan du igjen velge personer, og hvilke meldinger fra valgt person du vil ha arkivert. Etter dette er det bare å velge send inn, og meldingene blir gjort om til et format Noark kan håndtere og arkiveres i arkivet. Figur 2.4: Marc (mobilapplikasjon) Side 13 av 135

13 Prosessdokumentasjon Kapittel 2: Det endelige produktet Figur 2.5: Marc (skrivebordsapplikasjon) Side 14 av 135

14 Kapittel 3: Planlegging og forberedelser Noark 5 Dokumentfangst 3 Planlegging og forberedelser Dette kapittelet tar for seg den tidlige begynnelsen av prosjektet. Handler om hvordan gruppen ble til, valg av oppgave, analyse av kostnader, mål og rammebetingelser vi satt oss og hvilke ressurser vi har hatt tilgang på under prosjektperioden. 3.1 Gruppen blir til En varm ettermiddag sensommeren 2010, tre studenter, Lars-Erik, Joakim, og Daniel setter seg ned på en pub på Aker Brygge for å diskutere hovedprosjekt. Alle er på sisteåret bachelor i Informasjonsteknologi og alle er klare for et nytt studieår. De diskuterer å ta med et fjerde medlem, men dessverre har han ikke nok studiepoeng til å melde seg opp til hovedprosjekt. Like greit, han droppet ut uken etterpå. Diskusjonen fortsetter, de bestemmer seg for kun å være 3 på gruppen. 3.2 Valg av oppgave Oppgaven valgte vi etter at vi hadde vært innom en del andre prosjektforslag først. Vi hadde først en mulig avtale med KS om de kunne stå for hovedprosjekt til oss. De hadde dessverre ingen mulige hovedprosjekt for oss, så vi begynte å se oss om etter andre mulige prosjekt. Vi fant et spennende et for Accenture, der vi sendte inn søknad. Vi holdt godt øye med prosjektsiden til hovedprosjektet denne tiden, for å se etter prosjekt. Fant et prosjekt der som gikk ut på å utvikle Noark standarden. Siden vi enda ikke hadde hørt fra Accenture tok vi kontakt med kontaktpersonen for Noark-prosjektet. Vi fikk kjapt tilbakemelding og hadde en introduksjon til prosjektet. Vi ringte Accenture og hørte, der vi fikk vite at de ikke hadde noe til oss. Da var egentlig valget enkelt, og vi gikk for prosjektet. 3.3 Analyse Her skrives det om analyser vi gjennomførte før vi startet med prosjektet Kostnad Som det kan leses ovenfor benyttet vi stort sett programmer som er kommersielle. Normalt vil man måtte betale Microsoft for å få løst ut lisensene. Det slapp vi siden Høgskolen i Oslo er medlem av et samarbeid, MSDN Academic Alliance, som ga oss mulighet til å bruke Microsoft-produktene i undervisningssammenheng. Android SDK og Eclipse er også gratis. Side 15 av 135

15 Prosessdokumentasjon Kapittel 3: Planlegging og forberedelser 3.4 Mål og rammebetingelser Målet med prosjektet er å påvise eller avkrefte om det er mulig å få informasjon fra nyere sosiale medier (Facebook, tekstmeldinger) i et Noark format. For å besvare denne teorien har vi utviklet tre applikasjoner. Facebook-applikasjon o Henter meldinger fra grupper, arrangementer og sider på Facebook. o Krever at brukeren er administrator eller eier av informasjonen som innhentes. o Bearbeider informasjonen før det arkiveres i Noark-arkivet. Mobilapplikasjon for lagring av tekstmeldinger o Lagrer tekstmeldinger på mobilen. Skrivebordsapplikasjon for arkivering av tekstmeldinger o Henter tekstmeldinger fra mobiltelefon. o Sender tekstmeldinger til arkiv. Side 16 av 135

16 Kapittel 4: Oppstartsfasen Noark 5 Dokumentfangst 4 Oppstartsfasen Oppstartsfasen omhandler rollefordeling innad i gruppen, møter og samarbeid, styringsdokumenter vi har opprettet og hvilken metodikk vi har brukt (RAD). 4.1 Roller i gruppen For samarbeidet i gruppen var det viktig å dele inn i roller, slik at alle fikk et ansvarsområde de kunne fokusere mere på. Selv om rollene ble bestemt på forhånd, har vi i stor grad arbeidet på tvers av disse, uten problem. Gruppeleder, kontaktperson og en sekretær ble valgt, men under hele prosjektet har vi hatt fokus på å ta avgjørelser i felleskap for å sikre kvaliteten i arbeidet vi gjorde. Navn Daniel Brunstad Diakoff Joakim Vorren Lars-Erik Arnesen Hovedrolle Gruppeleder Kontaktperson Sekretær Gruppeleder Som leder for gruppen har han det overværende ansvaret når det gjelder samarbeidet. Ansvarsområder innebærer reservasjon av grupperom, avtale møter, kontaktperson ved sykdom eller andre komplikasjoner. Kontaktperson Har ansvar for kontakten med oppdragsgiver. Det innebærer å avtale møter, svare på henvendelser fra oppdragsgiver. Sekretær Hovedansvaret ligger i å skrive møtereferat, ferdigstille dokumenter og delegere ansvar for dokumentskriving til de andre gruppemedlemmene. 4.2 Samarbeid og møter Fra Høgskolen i Oslo fikk vi Eva Hadler Vihovde som veileder for prosjektet. Vihovde har vært en viktig og god ressurs når det gjelder utforming og skriving av rapport, tilbakemeldinger underveis og til rådføring hvis det var noe gruppen lurte på. Gruppen har hatt fokus på å møtes så ofte som mulig under prosjektperioden. Vi hadde derfor faste dager i uken hvor vi jobbet sammen og diskuterte løsninger på problemer og hva som måtte gjøres framover. På grunn av dette nære samarbeidet hadde alle til enhver tid noe å gjøre, og når det dukket opp spørsmål om hvordan ting skulle løses, ble de ofte løst i plenum. Side 17 av 135

17 Prosessdokumentasjon Kapittel 4: Oppstartsfasen Vår oppdragsgiver Thomas Sødring var i likhet med Vihovde en viktig og god ressurs å ha for gruppen. Sødring veiledet og underviste gruppen om Noark 5 og dens oppbygning, noe som vi var svært avhengig av for å løse oppgaven. 4.3 Styringsdokumenter Kapittelet tar for seg styringsdokumenter og deres rolle i prosjektet Arbeids og fremdriftsplan Arbeidsplanen var et av de første dokumentene vi opprettet. Denne inneholder milepæler for når ting skal være ferdig. Gjennom hele prosjektet har vi prøvd å følge denne. Siden arbeidsplanen ble satt opp helt i starten av prosjektet, er det punkter vi har hatt med som har forsvunnet, rett og slett fordi vi ikke har sett noe behov for disse punktene i prosjektet. Andre punkter som vi gjerne skulle hatt mer tid til (testing) har måttet blitt nedprioritert for å få andre ting ferdig i tide. Arbeidsplanen er en del av vedlegget. Fremdriftsplanen er en grafisk versjon av arbeidsplanen. Her kan du se hvor mye tid vi har satt av til de forskjellige punktene, og hvilke punkter som kan jobbes parallelt med. Risikoanalyse Risikoanalysen er delt opp i 3 deler. En del som tar for seg mulige trusler, sannsynligheten for at de oppstår og konsekvensen av trusselen. En annen del tar for seg forhindrende arbeid, det vil si hva vi kan gjøre for å minimalisere sjansen for at en trussel vil oppstå. Vi har her navnet på trusselen og strategien for å minimalisere. Den siste delen er begrensende arbeid, det vil si når uhellet først er ute. Det er her delt opp i risikodel og strategi for å begrense uhellet. Prosjektdagbok Når gruppen kommer til sluttfasen av prosjektet er det ikke alltid like lett å huske alle valg og beslutninger man tok underveis. En prosjektdagbok ble opprettet i starten av prosjektet for å dokumentere hele prosessen. Det er et viktig dokument som gruppen har brukt under hele perioden for å skrive ned de problemene, valgene og spørsmålene som dukket opp. Etter hver arbeidsdag ble gruppen enig om hva som skulle være med fra den dagen og sekretæren skrev det ned. Under utviklingsfasen var dagboken veldig nyttig for å se hva de andre gruppemedlemmene hadde gjort. Vi kunne lettere hjelpe hverandre hvis vi støtet på problemer, og vi hadde allerede spørsmålene klare når vi skulle i møter med oppdragsgiver og veileder. Kravspesifikasjon Vi satte opp en kravspesifikasjon etter oppdragsgivers ønsker og de undersøkelsene vi hadde gjort. For å lage en kravspesifikasjon undersøkte vi blant annet Facebooks Side 18 av 135

18 Kapittel 4: Oppstartsfasen Noark 5 Dokumentfangst personvernpolicy, Noark sitt grensesnitt, samt utviklingsverktøy og rammeverk for Android for å nevne noen. Kravspesifikasjonen skulle hjelpe oss til å få en felles forståelse og enighet av produktet. Rammer og betingelser var også viktig i vår sammenheng, da vi har applikasjoner som må samhandle med hverandre. 4.4 Metodikk Som et FoU-prosjekt basert på en proof of concept løsning har vi i løpet av prosjektet vært opptatt av å produsere regelmessige utgaver av applikasjonene i kortere iterasjoner. Oppdragsgiver hadde ingen krav til utviklingsmetodikk, men ønsket å være en del av prosessen som en veileder når det kom til elektronisk journalføring og arkivering. Prototyping ble benyttet i starten for å redusere risker for misforståelser mellom oppdragsgiver og gruppen. Vi fikk også en bedre forståelse av produktet og de kravene vi måtte stille. Tilbakemeldingene vi fikk på prototypen ble brukt til videreutvikling av applikasjonene. Dette førte til at vi kom raskt i gang med utviklingen av det endelige produktet og at det resultatet av det også reflekter de ønskene oppdragsgiver hadde Rapid Application Development Rapid application development (RAD) er en utviklingsmetodikk som bruker minimalt med planlegging til fordel for prototyping. Utvikling av programmet er en del av planleggingen. Det medfører at programvaren blir raskere utviklet og det er lettere å forandre på kravene underveis. Det starter med at man i første fase analyserer og utformer data- og prosessmodeller. I neste fase blir kravspesifikasjonen verifisert ut i fra prototyping. Og til slutt forandrer man modellene. Disse fasene gjentas iterativt. Fordelene med RAD er at det fremmer samarbeid i gruppen og dynamisk samling av krav. Ulempene er at man er avhengig av en sammenhengende gruppe og individuelle engasjement i prosjektet. Beslutninger som blir tatt er avhengig av en kompetent gruppe hvor alle kan bidra og i mindre grad av en sentralisert prosjektledelse. Figur 4.1: RAD Side 19 av 135

19 Prosessdokumentasjon Kapittel 4: Oppstartsfasen I en tradisjonell metodikk er man mye mer fastbundet til en plan og følger de samme kravene under hele prosjektet. Feil og misforståelser blir ikke rettet opp i like fort og man ender opp med å bruke mye tid på slutten. Krav fra kunden kan ha blitt endret når man er ferdig, og man risikerer i verste fall å måtte starte helt på nytt. Figur 4.2: Tradisjonell metodikk Side 20 av 135

20 Kapittel 5: Teknologier Noark 5 Dokumentfangst 5 Teknologier Dette kapittelet handler om hvilke teknologier vi har brukt under prosjektet. Det tar for seg oppbyggingen av Noark, argumentasjoner for valg av utviklingsverktøy, hvilke utviklingsverktøy vi har brukt i de forskjellige applikasjonene og andre tekniske hjelpemidler som har blitt brukt til blant annet versjonskontrollering og fildeling. 5.1 Noark Noark 5 indre kjerne er utviklet som tjeneste orientert arkitektur (TOA) av masterstudenter ved Dublin City Univirsity. TOA tankegangen går ut på å utvikle komponenter som lett kan settes sammen og integreres. Med en TOA kjøres programmet i en klient/tjener modell. Selve programmet som i vårt tilfelle er Noark, kjører i en applikasjonsserver som f.eks. JBOSS. Klientprogrammet kompileres mot grensesnittet til programmet i applikasjonsserveren og vil da kunne kommunisere over et grensesnitt så lenge det ikke endres. Applikasjonene som vi har utviklet i forbindelse med dette prosjektet kan sees på som klient i denne modellen. Figur 5.1: Tjenesteorientert arkitektur Noark-kjernen er bygget opp av flere lag med tjenestelaget på toppen som et grensesnitt ut til andre applikasjoner. Tjenestelaget oppretter en kontrakt som klientene er nødt til å ta i bruk for å kommunisere med tjeneren. For å beskrive tjenesten brukes WSDL, en velkjent standard måte for å etablere dialog mellom klient og tjener. Virksomhetslogikklaget er laget under tjenestelaget og hvor logikken er delt inn i klassestrukturer. Under virksomhetslogikken finner vi det ORM-baserte lagringslaget. I motsetning til tradisjonell opprettelse av en database, hvor vi først designer databasestrukturen, for så å tilpasse virksomhetslogikken i forhold til det, vil man med ORM-løsningen bruke data fra virksomhetslogikken til å beskrive datastrukturene i databasen, og en logisk beskrivelse av sammenhengen mellom de ulike data i systemet. Modellen viser også hva som skjer når bestemte hendelser inntrer og hvordan objektene i databasen oppfører seg. En fordel med ORM er at man ikke trenger å administrere databasen ved endringer i Side 21 av 135

21 Prosessdokumentasjon Kapittel 5: Teknologier virksomhetslogikken. Ved en forandring av virksomhetslogikken vil databasen automatisk reflektere endringene som ble gjort. I det nederste laget finner vi en relasjonsdatabase der all informasjons som blir avlevert til Noark havner. Figur 5.2: Lagene i Noark-kjernen. 5.2 Valg av utviklingsverktøy Dette kapittelet tar for seg prosessen vi gjennomgikk for å velge utviklingsverktøy. Vi stod ganske fritt med tanke på å utvikle dette prosjektet. Oppdragsgiver hadde ikke satt noe begrensing på valg av programmeringsspråk, kun det at vi må kunne kommunisere med Noark tjeneren som kommuniserer gjennom SOAP. Vi kom tidlig fram til at vi skulle bruke.net(c#) i det integrerte utviklingsmiljøet Microsoft Visual Studio Til utviklingen av mobilapplikasjonen kom vi til slutt fram til at vi skulle bruke Android SDK & emulator sammen med Eclipse. Samarbeidet i gruppen foregikk ved hjelp av versjonskontrollsystemet Microsoft Team Foundation og Microsoft SQL Server 2008 som ble installert på en server som kjører Microsoft Windows Server 2008 med IIS (Internet Information Services). Dette muliggjorde at vi kunne dele kildekoden mellom oss og ha den samme versjonen på tvers av maskinene vi jobber på. Datamaskiner som ble brukt som server under prosjektarbeidet, ble satt opp av gruppen selv. Side 22 av 135

22 Kapittel 5: Teknologier Noark 5 Dokumentfangst Valg av mobilplattform Før vi kunne velge hvilken mobilplattform vi ville utvikle for måtte vi finne ut hvilken plattform som ga oss mulighet til å få tak i all informasjonen vi ønsket. Vi satte derfor i gang med å finne ut hvilke funksjoner som vi trodde vi ville trenge for å kunne utføre oppgaven på en tilfredsstillende måte. Valget stod mellom Android, Windows Phone 7 og ios. Android Android er åpen kildekode og er eid av Google Inc. Dette operativsystemet er basert på linux. Det er den største smarttelefonplattformen, med over applikasjoner tilgjengelig på Android Marked. Dette gjør det lettere å finne eksempler på kode som utfører noe lignende av funksjonene vi var ute etter. Android har også en veldig informativ hjemmeside for utviklere, hvor du finner all informasjon du skulle ønske. Applikasjoner på Android blir skrevet i Java. Windows Phone 7 Windows Phone 7 er eid av Microsoft og er etterfølger til Windows Mobile. Applikasjoner blir skrevet i C# som betyr at vi kan bruke Visual Studio til å programmere i. Negative ting ved dette operativsystemet er at det er såpass nytt at det funksjonsmessig ikke er på samme nivå som konkurrentene, det er ikke bakoverkompatibelt og veldig få applikasjoner er ute i forhold til Android og ios. ios ios, også kjent som iphone OS, er Apple sitt mobile operativsystem. Var opprinnelig kun for iphone, men er senere blitt utviklet til å fungere med ipod, ipad og Apple TV. ios er basert på Mac OS X, som er et Unix operativsystem. Apples App Store inneholder mer enn ios applikasjoner, mer enn Android har på sitt Android Marked. ios blir skrevet i Objective-C. Det positive med å utvikle for dette operativsystemet er at det finnes mye dokumentasjon på Internett. Det negative er at det kun er lagt til rette for å programmere på Mac med Xcode som utviklingsverktøy. Endelig valg Valget falt til slutt på Android. Vi fant ut at dette ville være den plattformen som ville gi oss nok fleksibilitet til å kunne løse oppgaven. Vi var aldri helt sikre i begynnelsen på hvordan vi skulle gå fram for å lage mobilapplikasjonen, så det at det ligger så mange eksempler på nettet programmert på Android gjorde det lettere for oss å komme fram til en løsning Facebookapplikasjon For å lage Facebookapplikasjonen har vi benyttet oss av ASP.NET med C# som programmeringsspråk. Det var i grunn ingen andre alternativer vi vurderte utenom C#, da vi allerede hadde funnet en utviklingspakke (SDK) for Facebook for dette språket. Side 23 av 135

23 Prosessdokumentasjon Kapittel 5: Teknologier Når det kommer til uthenting av informasjon fra Facebook, blir dette tilbudt gjennom Facebooks Graph API, hvor man mottar informasjonen i JSON format, som lett lar seg håndtere. Applikasjonen kjøres på en Microsoft Windows Server 2008 maskin som vi har satt opp hos en av gruppemedlemmene Mobil -og skrivebordsapplikasjon Mobilapplikasjonen benytter seg av Android SDK og med programmeringsspråket Java. Den er laget for Android 2.1 og programmert i Eclipse Helios. Skrivebordsapplikasjonen er utviklet i C#. Det var lite tvil om det fra begynnelsen av, siden språket ikke har noe å si da informasjonen blir sendt mellom mobilen og datamaskinen i XML format. 5.3 Utviklingsteknologier Dette kapittelet tar for seg teknologiene vi har brukt under utviklingen av applikasjonene NET.NET rammeverket er i dag en av de mest brukte utviklingsplattformene i verden. For å kunne programmere mot Facebook krevde det at vi brukte eksterne biblioteker som lett kunne integreres i rammeverket. Facebook C# SDK Facebook C# SDK hjelper.net utviklere å lage applikasjoner som kan integrere med Facebook. Før utviklingen av facebookapplikasjonen kunne begynne, var vi nødt til å finne en måte å hente ut informasjon fra Facebook på som tokk hensyn til brukerens sikkerhet og de personvernsinnstillingene de har satt for sin konto. En relativ ny API kalt Graph gjorde det mulig å hente det ut som JSON eller XML objekter. Det fantes ingen offisiell utviklingsplattform for C# fra Facebook, så vi brukte litt tid på å finne en alternativ løsning. På Codeplex, Microsoft sin egen møteplass for fri programvare, fant vi Facebook C# SDK, som inkluderer den samme funksjonaliteten som den offisielle utviklingsplattformen Android Android er et mobilt operativsystem opprinnelig utviklet av Android Inc, et firma som ble kjøpt av google i Android er basert på en modifisert versjon av Linuxkjernen. Google og andre medlemmer av Open Handset Alliance har samarbeidet om Androids Side 24 av 135

24 Kapittel 5: Teknologier Noark 5 Dokumentfangst utvikling og lansering. The Android Open Source Project (AOSP) har i oppgave å vedlikeholde og videreutvikle Android. Android er verdens mestselgende smarttelefonplattform. 5.4 Andre tekniske hjelpemidler Kapittelet omhandler teknologier brukt til versjonskontroll, fildeling og rapportskriving Dropbox Dropbox er en nettjeneste som synkroniserer filer man har liggende lokalt på sin datamaskin med en nettverksharddisk eller skyen som mange vil kalle det. Ved å installere denne tjenesten hos alle gruppemedlemmene, kunne vi dele dokumenter med hverandre og sikre at alle hadde siste versjon til enhver tid. I tillegg til å ta sikkerhetskopi av filene, knytter den også de opp mot versjonskontroll. Det hjelper oss å finne tilbake til en gitt versjon når vi måtte ønske Google Docs Google Docs eller Google Dokumenter som det kalles på norsk, er en gratis nettbasert kontorpakke utviklet av Google som inneholder programmer som tekstbehandling, regneark og presentasjon. Gruppen brukte Google Docs til å skrive dokumenter, møteplanlegging og dele ressurser vi fant på Internett. Fordelene med Google Docs er at redigering av et gitt dokument kan gjøres av flere personer samtidig, og endringer vil for de andre brukerne gjengis med det samme (i sanntid). Side 25 av 135

25 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen 6 Utviklingsprosessen Vi kom godt i gang med prosjektet før juleferien, og satte i gang med høy arbeidslyst på nyåret. På dette tidspunktet ønsket vi å programmere mobilapplikasjonen for Windows Phone 7, fordi da kunne vi programmert alle applikasjonene i.net rammeverket. I begynnelsen brukte vi god tid på teste ulike teknologier, og prøvde oss frem for å finne mulige løsninger på problemstillingen. Vi så på fordeler og ulemper ved de forskjellige mobilplattformene rett over jul for å finne ut om vi kunne holde oss til et programmeringsspråk. Se punkt 5.2 for begrunnelse for valget vi gjorde. Videre ble det gjort undersøkelser på hvilken måte som egnet seg best for å hente ut informasjon fra Facebook og hva som måtte gjøres for å få det i et format Noark kunne håndtere. Endringer i Facebook applikasjonen, hvorfor og mer om prosessen ved informasjonsuthenting kan leses i punkt 6.1. For å lære om utviklingsprosessen til mobil -og skrivebordsapplikasjonen, fra opplæring i Android, prosessen fra daemon til full brukerinteraksjon og løsning av problemer se punkt FIR (Facebookapplikasjon) Kapittelet tar for seg utviklingen av Facebookapplikasjonen. Hvordan applikasjonen kommuniserer med Facebook, tidlig prototype, utviklingen fra skrivebordsapplikasjon til webapplikasjon og utvikling i henhold til kravspesifikasjonen Kommunikasjon med Facebook Før utviklingen av FIR kunne begynne, var vi nødt til å undersøke hvordan vår applikasjon kunne kommunisere med Facebook. Facebook har i dag et mye brukt grensesnitt kalt Graph API, som lar utviklere hente informasjon fra Facebook til egne applikasjoner. Informasjonen i API-et blir presentert som JSON-objekter (f.eks. personer, bilder, arrangementer og sider) og koblingene mellom dem (f.eks. vennerelasjoner, delt innhold og bildetekster). Vi gjorde noen testforsøk mot Graph for å se hva slags informasjon vi fikk, hvordan formatet var, og hva som krevdes av rettigheter for å få tilgang til informasjonen. Resultatene av forsøkene, gjorde at vi ville fortsette med Graph. Det gjenstod bare å ta det i bruk i applikasjonen med en SDK. Som det kan leses i kapittel i avsnittet om Facebook C# SDK var det den beste SDK-en for vårt formål og utviklingsmiljø. Med dette implementert i applikasjonen kunne vi med metoder innebygget i SDK-en kommunisere med Facebook over Graph API. Noe av tiden gikk også til å lære seg SDKen og prøve nye versjoner etter hvert som vi utviklet FIR. Side 26 av 135

26 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst FIR Tidlig prototype Etter at undersøkelsene av Facebooks programmeringsgrensesnitt ble gjennomført satte vi i gang med å utvikle en prototype som skulle vise at det gikk an å hente meldinger fra en gruppe på Facebook. Det første som ble gjort da var å registrere en applikasjon på Facebook. Vi fikk da en applikasjons-id som kunne benyttes i programmet slik at vi kunne koble oss opp mot Facebook og få tilgang til informasjonen som lå der. Vi bygde opp applikasjonen i tre lag med et datatilgangslag, virksomhetslogikklag, og presentasjonslag. Lagdelingen ble gjort fordi vi ville sikre at koden var klar til gjenbruk ved en senere anledning og at det ville være mye lettere å flytte på koden når det lå i egne lag eller klassebibliotek enn om vi hadde det blandet sammen. Prototypen hadde et felt for ID til facebookgruppen og et felt for antall meldinger som skulle hentes. Meldingene som kom inn presenterte vi med en avhukingsboks for å illustrere at det gikk an å velge dem. Figur 6.1: Første prototype av FIR I løpet av noen få dager var prototypen klar og vi tokk den med til oppdragsgiver for å få tilbakemeldinger. Vi ble klar over at det var et sterkere ønske om en webapplikasjon fordi det ville være mere tilgjengelig for brukerne og i mindre grad plattformavhengig. Det var ikke mange funksjoner i denne utgaven, men den beviste likevel noe elementært. At det var mulig å hente informasjonen fra Facebook. Vi hadde oppnådd en milepæl og var sikre på at det ville være mulig å jobbe videre med dette. Side 27 av 135

27 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen Fra skrivebordsapp til webapp Fra den første prototypen brukte vi mye av koden i det som skulle bli den andre prototypen, en webapplikasjon. Applikasjonen kjørte fra en webserver til en av gruppemedlemmene og ble da implementert inn i Facebook i en så kalt iframe. Med en iframe-løsning kjører applikasjonen i et eget vindu integrert inne i Facebook. Denne prototypen ble også presentert under en forelesning til oppdragsgiver hvor to andre fra samme avdeling, journalistikk, bibliotekog informasjonsfag deltok. Tilbakemeldingene var positive og vi følte at dette var mer i trå med det oppdragsgiver hadde sett for seg. Det var lite funksjonalitet på dette tidspunktet grunnet mangel på en Noark kjerne vi kunne jobbe mot. Dessverre oppstod det en del komplikasjoner når vi skulle begynne å programmere funksjonaliteten i applikasjonen. Det oppstod problemer som det å bevare tilstanden til en avhukingsboks og flytte informasjon fra en side til en annen. iframe er nok mer egnet hvis man kun skal presentere én side, og ikke navigere mellom flere. Figur 6.2: Filtrering i FIR Vi var derfor nødt til å gå bort i fra den integrerte iframe-løsningen og bevege oss over på en dedikert applikasjon som lå utenfor, men som likevel kunne oppleves som en del av Facebook. Applikasjonen kunne fortsatt kjøre fra den samme webserveren og koden fra de tidligere prototypene ble overført. Etterhvert som vi utviklet nye prototyper og tiden gikk, gjorde Facebook endringer i programmeringsgrensesnittet og vi måtte oppdatere vår kunnskap fortløpende for å ta det i bruk. Applikasjonen har til dette tidspunktet ikke hatt mange funksjoner fordi vi ville være sikre på at vi hadde en god plattform å bygge på. Vi implementerte mulighet for å hente meldinger fra arrangementer og sider i tillegg til grupper som allerede var fra før. For å gi et bedre bilde av hva en slik applikasjon kan brukes til, ble det også utviklet en egen filtreringsfunksjon. Den fikk en søkefelt for å finne igjen innhold i meldinger, datosortering for å finne tilbake til meldinger fra en bestemt dato eller periode og sortering på type melding (status, bilde og kobling). Oppdragsgiver Sødring, hadde nå klargjort en versjon av Noark-kjernen som vi kunne ta i bruk og teste mot. En JBoss-server ble satt opp på en av gruppemedlemmenes bærbare datamaskin med Sødrings Noark 5 kjørende. Vi importerte kontrakten (WSDL) fra Noark inn i facebookapplikasjonen og kunne umiddelbart ved bruk av SOAP-meldinger kommunisere med Noark. Side 28 av 135

28 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst Figur 6.3: Endelig versjon av FIR Selv om versjonen av Noark vi fikk av Sødring var uferdig og manglet en del fra å være komplett, var det vi hadde oppnådd et bevis på at det var mulig å hente meldinger fra Facebook og arkivere det i et arkiv. Det er viktig å være klar over at arkivet ikke var tilpasset facebookmeldinger på noe som helst måte fordi Sødring hadde mer fokus på å få en fungerende versjon som vi kunne ta i bruk. Som en følge av at Noark-kjernen var så lite tilpasset, ble veldig lite metadata til meldingene tatt vare på. Selve innholdet i meldingen og hvem som hadde opprettet den ble lagt i arkivet Utvikling i henhold til kravspesifikasjon Med facebookapplikasjonen hadde vi som mål å hente meldinger fra Facebook og arkivere dem i et arkiv. Vi fant det nødvendig å få utarbeidet krav til funksjonaliteten rundt dette målet. Vi var også nødt til å ta hensyn til personvern og utforming av utseende til applikasjonen. Da vi utviklet de første prototypene av applikasjonen ble det også mer klart hvilke krav som var reelle og kunne bli gjennomført innen for tidsrammene vi hadde. 6.2 Marc (Android applikasjon) Utvikling i Android har vært en spennende og lærerik reise. Hadde absolutt ingen erfaring med å programmere mobilapplikasjoner før prosjektet. Det er vel kanskje litt Side 29 av 135

29 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen derfor at mobilapplikasjonen er den delen av produktet vårt som har gjennomgått de største endringene siden vi satte i gang dette prosjektet. Kravspesifikasjonen var ganske åpen på denne applikasjonen, og eneste kravet fra oppdragsgiver var at meldingene skulle kunne hentes ut av telefonen og håndteres av Noark Selvlæring i Android Som beskrevet tidligere er Android et javabasert mobiloperativsystem. Gikk derfor i gang med oppfriskning av våre javakunnskaper før vi satte i gang å lese oss opp på Android. Hjemmesiden til Android (developer.android.com) har gitt oss mye god informasjon, og er veldig fint bygget opp for folk som ønsker å lære å programmere i Android. Denne siden har blitt flittig brukt gjennom hele utviklingsprosessen. Alt fra oppsett av programmeringsverktøy til tutorials på forskjellige programmer, til informasjon om klassene og deres metoder finnes her Fra daemon til full brukerinteraksjon Oppdragsgiver var veldig åpen når det kom til mobilapplikasjonen. Vi hadde derfor noen brainstormingsøkter med både oppdragsgiver og alle gruppemedlemmene, der vi drøftet forskjellige løsninger. Det første vi kom fram til var en daemon. En deamon er en prosess som går i bakgrunnen på et operativsystem, uten noen form for brukerinteraksjon. Denne ville starte opp på telefonen ved oppstart, for så å ligge i bakgrunn og vente på at bruker sender eller mottar meldinger. Den ville så sende meldingen som er sendt eller mottatt til brukerens epostkonto, eller til en applikasjon vi lager selv. Vi var usikre på hvor mye tid vi ville legge i applikasjonen, og nedprioriterte den endel de første ukene. Etter noen uker, mer opplæring i Android, og enda et møte med veileder, tok vi igjen opp kravspesifikasjonen til mobilapplikasjonen. Vi lå såpass godt an med FIR at vi bestemte oss for å utvikle en skrivebordsapplikasjon sammen med mobilapplikasjonen. Gikk dermed bort fra ideen om å sende meldingene til mobileierens epostkonto. Mobilapplikasjonen skulle fortsatt være en daemon. Nå kom derimot utfordringene. Det er ikke mulig å lagre utgående meldinger i Android med en lytter. Se for problemene som oppstod med lagring og uthenting av meldinger. Igjen satt vi oss ned og leste gjennom nettsider og Android sin utviklerside. Løsningen vi fant var content providers. Vil du lese mer teknisk om dette må du se i produktdokumentasjonen. Kort fortalt så er en content provider en måte for Android å hente og lagre data på. Du har content provider for SMS, kontakter og epost. Nå hadde vi kommet til et punkt i programmeringen hvor vi måtte finne ut hva som ville være mest hensiktsmessig, fortsette med daemon eller gi brukeren mulighet til å interagere. Med content provider hadde vi nå tilgang direkte på innboksen, og kunne hente SMS som vi ville. Om vi nå skulle fortsatt med daemon ville en lokal versjon av innboksen oppdateres for hver melding du mottar. Vi så for oss at dette ville bli en svært tidkrevende prosess og kun ville irritere brukeren. Samtidig vil applikasjonen kun oppdatere meldingene når brukeren mottar meldinger, men ikke når de blir sendt. Side 30 av 135

30 Kapittel 6: Utviklingsprosessen Noark 5 Dokumentfangst Med brukerinteraksjon ville brukeren selv kunne velge hvilke kontakter han/hun vil lagre meldinger fra, og når de skal lagres. På denne måten vil vi unngå mye uønsket venting. Vi vil heller ikke trenge en lytter på mottatte SMS. Løsningen blir å gi brukeren mulighet til å interagere med programmet. Igjen setter vi oss ned og besøker utviklersiden til Android. Vi oppretter også noen klasser for å få mer struktur i programmet. Klassene som er opprettet og deres hensikt kan leses om i produktdokumentasjonen. Mobilapplikasjonen begynner å ta form; det dukker ikke opp noen store problemer ved utvikling av GUI. Etter tungvint eksportering av applikasjon til mobil, der blant annet et digitalt sertifikat må signeres har vi endelig noe som fungerer på telefonen. Programmet kjører utrolig tregt på telefonen, så vi optimaliserer koden og legger til en splash screen (velkomstskjerm) som brukeren kan se på mens programmet laster. Tegner et ikon til applikasjonen og sier oss klare til å begynne med testing. Hvordan testingen foregikk, kan du lese om i kapittel 7 avsnitt Utvikling i henhold til kravspesifikasjon Som nevnt over hadde vi ikke store kravspesifikasjonen til mobilapplikasjonen. Vi har endret både kravspesifikasjonen og programmet etterhvert som vi har fått bedre kunnskap om Android og mobilprogrammering generelt. Endringer som har blitt gjort i programmet har blitt gått over med oppdragsgiver, som har kommet med ønsker, som vi igjen har lagt til i kravspesifikasjonen og implementert i programmet Utfordring med meldinger Første problemene vi støtet på var at det ikke var noen lytter ved utgående SMS. Derfor ville daemonen vår ikke fungere optimalt, fordi den kun vil ha mulighet til å lagre innkommende meldinger. Siden vi ikke hadde mulighet til å lagre utgående meldinger, måtte vi se oss om etter andre løsningsalternativer. Løsningen var content providers som nevnes ovenfor. Her lagres meldingene ikke når de blir mottatt, men hentes ut fra mobilen sin innboks og lagres på minnekortet. Denne prosessen viste seg å være spesielt tungvint ved bruk av daemon så vi gikk over til å ha brukerinteraksjon. Andre problemer vi støtte på var blant annet det å kunne knytte melding til kontakt. Løste dette ved å hente content provideren til kontaktene og lage en kontaktliste. Knyttet så denne opp mot en liste av meldinger hentet ut av content provideren til innboks. Se produktdokumentasjonen for teknisk beskrivelse Eksportering til XML Ble tidlig klart at formatet vi skulle bruke på meldingene vi sendte ut skulle være i XML. XML står for Extensible Markup Language og brukes til å lagre og transportere data. Formatet på XML filen er samme som brukes på iphone, så i teorien skal Side 31 av 135

31 Prosessdokumentasjon Kapittel 6: Utviklingsprosessen skrivebordsapplikasjonen også kunne lese XML-filer som er hentet ut fra en iphone. Vi støtte også på noen småproblemer med XML-formateringen, fordi spesialtegn som < og > vil ødelegge for programmene. Løsningen ble da å endre disse tegnene der de forekommer i meldingene så koden ville kjøre normalt. 6.3 Marc (skrivebordsapplikasjon) Som nevnt i forrige delkapittel, bestemte vi oss for å utvikle en skrivebordsapplikasjon i tillegg til mobilapplikasjonen. Vi gjorde dette da det vil gi brukeren bedre kontroll over hva som skal arkiveres. Det ville i lengden vært et irritasjonsmoment for brukeren å kun bruke en mobilapplikasjon til formålet programmet er beregnet for. Skrivebordsapplikasjonen var tenkt å være et meget enkelt program som kun har som formål å gi brukeren en oversikt over meldinger, organisert etter kontakt, og gi ham/henne muligheten til å velge enkeltmeldinger for så å sende dette inn til Noark. Vi la også til et enkelt søkesystem, som kan benyttes for å søke etter avsender og innhold i meldinger. 6.4 Oppsett av Noark I begynnelsen av prosjektet hadde vi ingen Noark-kjerne til disposisjon fordi oppdragsgiver ikke hadde den klar. Vi fikk opplyst at det fantes en åpen utgave av Noark kalt Friark. Fra Friark sin nettside( kan vi lese: Friark utvikles av Machina AS og har som mål å bli en implementasjon av en Noark-5 indre kjerne. Løsningen er åpen kildekode, og tilgjengelig som fri og åpen programvare (GPL lisens). På det tidspunktet vi lastet ned kildekoden til Friark fantes det lite dokumentasjon om hvordan vi skulle ta det i bruk. En virtuell maskin (VM) med Ubuntu ble installert på en av gruppens datamaskiner, og etter utallige forsøk klarte vi til slutt å få det til å kjøre, men måtte legge det fra oss da vi oppdaget at vi ikke hadde en mulighet til å kommunisere med Friark fra applikasjonene våre. Vi bestemte oss for å ta kontakt med oppdragsgiver for å høre om det var mulig å ta i bruk Noark-kjernen hans. Det løste seg ved at vi fikk en gjennomgang av koden og de forskjellige lagene i Noark, hvor det endte med at en av datamaskinene til gruppen ble overrukket til oppdragsgiver slik at han kunne installere det for oss. I løpet av en ettermiddag hadde vi en fungerende Noark-kjerne kjørende og testing av applikasjonene mot kjernen ble en realitet. Side 32 av 135

32 Kapittel 7: Testing Noark 5 Dokumentfangst 7 Testing Dette kapittelet tar for seg testing, og gjør rede for hvorfor vi har prioritert andre ting foran testing. 7.1 Brukertesting FIR Testing av FIR har blitt nedprioritert. I fremdriftsplanen ble det ikke satt mye tid testing fordi vi valgte å fokusere på å få til et fungerende produkt, for så å gå over til å skrive dokumentasjon. Det ble gjort litt brukertesting av applikasjonen for Riksarkivet. Mer om brukertesting kan leses i avsnitt Brukertest Vi har hatt minimalt med bruktertesting pga. følgende faktorer: Testing ble nedprioritert i fremdriftsplanen Å få tak i testsubjekter har vist seg problematisk av følgende grunner: o Mangel på en Noark-kjerne som var tilgjengelig for flere datamaskiner enn bare maskinene vi utviklet på. o Programvaren har ikke blitt lagt ut på Facebook og gjort tilgjengelig for andre. Vanskelig å ta i bruk for testsubjekter. Likevel har vi fått til noen brukertester. Du kan lese om disse i produktdokumentasjonen Marc Testingen av mobilapplikasjonen er noe som har blitt nedprioritert. Vi satt ikke opp mye tid til testing i fremdriftsplanen, vi valgte heller å fokusere på å få til et fungerende produkt, for så å gå over til å skrive dokumentasjon. Vi har fått tatt litt brukertesting av applikasjonen som kan leses om i avsnitt Vi har hatt minimalt med bruktertesting pga. følgende faktorer: Testing ble nedprioritert i fremdriftsplanen Få tak i testsubjekter har vist seg problematisk av følgende grunner: o Brukeren må ha en Android telefon nyere en 2.1. Programvaren har ikke blitt lagt ut på Android Market, så vanskelig å laste ned i forhold til andre androidapplikasjoner. Noen brukertester har vi derimot fått til. Dette kan du lese om i produktdokumentasjonen. Side 33 av 135

33 Prosessdokumentasjon Kapittel 7: Testing 7.2 Foredrag for målgruppen Oppdragsgiver inviterte oss til en av hans forelesninger om Noark der han ønsket at vi skulle presentere vårt prosjekt og ha en demo av applikasjonene vi hadde utviklet. Publikum bestod av personer fra Riksarkivet som var til stede for å lære om Noark 5, så vi følte derfor at det ville være verdifullt for oss med denne presentasjonen siden de er i målgruppen. Etter en demo av både FIR og Marc hadde vi en spørsmålsrunde hvor både oppdragsgiver og de fra Riksarkivet kom med spørsmål. Og til slutt ble det litt tid til utprøving av applikasjonene. Det hele ble en lærerik presentasjon. Vi fikk spørsmål om ting vi ikke hadde tenkt på tidligere og så ting fra et annet ståsted. Side 34 av 135

34 Kapittel 8: Kravspesifikasjonen og dens rolle Noark 5 Dokumentfangst 8 Kravspesifikasjonen og dens rolle Hvordan kravspesifikasjonen har forandret seg gjennom prosjektet og hvordan endringer i kravspesifikasjonen har påvirket produktet er hva dette kapittelet handler om. 8.1 Kravspesifikasjon 1.0 I og med at prosjektet utspeilet seg som proof of concept og oppdragsgiver ikke hadde noen formening om hvordan det skulle løses teknologisk ble det vanskelig å lage en kravspesifikasjon fra starten av. Den første kravspesifikasjonen dekker de kravene vi mente var nødvendig for at applikasjonene skulle besvare spørsmålet om det var mulig å arkivere meldinger fra mobil og Facebook. 8.2 Endringer etter oppdragsgivers ønsker Etter utviklingen av første prototype til FIR fikk vi tilbakemelding fra oppdragsgiver om at det var et sterkere ønske om en webapplikasjon enn skrivebordsapplikasjon som det på tidspunktet var. Endringer i kravspesifikasjonen måtte gjøres siden skrivebordsapplikasjoner og webapplikasjoner har noen fundamentale forskjeller. Det var noen likheter ved applikasjonene, men nye krav måtte skrives som følge av de endringene og overgangen til en webapplikasjon. Grunnen til at oppdragsgiver ønsket en webapplikasjon var at applikasjonen skulle være en facebookapplikasjon som man kan legge til fra Facebooks applikasjonsbibliotek. Den nye webapplikasjonen ble derfor opprettet som en facebookapplikasjon med en applikasjons-id fra Facebook. Tilbakemeldinger fra oppdragsgiver har også påvirket Marc. I første utkast til kravspesifikasjonen skulle Marc kun være mobilapplikasjon med relativt lite funksjoner. Etter videre samtaler med oppdragsgiver endret vi Marc til også å inneholde en skrivebordsapplikasjon for håndtering av SMS. 8.3 Innfrielse av kravene Kravene i kravspesifikasjonen ble drøftet lenge i gruppen, vi ville være sikre på at de kravene vi satt utenfor oppdragsgivers ønsker skulle bli møtt. Det ene kravet fra arbeidsgiver i kravspesifikasjonen, innhenting og formatering av informasjon fra Facebook, ble møtt tidlig i utviklingen av applikasjonene. Vi gikk derfor tilbake til kravspesifikasjonen og la inn flere krav til utviklingen av FIR, muligheten til å lagre både vegger og sider, ikke bare grupper. Kravene til de andre applikasjonene ble senere møtt, men med tidsfristen vi hadde kunne vi ikke implementere andre ønskede funksjoner uten at implementeringen av disse funksjonene ville komme i veien for andre prioriteringer. Side 35 av 135

35 Prosessdokumentasjon Kapittel 9: Avslutningsfase 9 Avslutningsfase Dette kapittelet tar for seg avslutningsfasen av prosjektet, med rapportskriving og veiledningstimer. 9.1 Ferdigstilling av prosjektet Da det var 1 måned av prosjektet igjen før det hele skulle leveres ble det satt fokus på å skrive prosjektrapporten. Vi var rådet av veileder Vihovde til å sette av så mye tid fordi rapportskriving er en tidkrevende prosess. Vi var ferdig med utviklingen av applikasjonene i henhold til planen i slutten av april. Gruppen opprettet et dokument som bestemte strukturen i rapporten med inndeling av kapitler og avsnitt til delene i rapporten. Det ble lettere å forholde seg til hva som skulle skrives når alt var forhåndsbestemt. Dokumentet med strukturen ble lastet opp på Google Docs slik at alle kunne delta samtidig i skrivingen. Veiledningstimene ble holdt hyppigere i denne fasen enn tidligere og utkast av rapporten ble levert til veileder for vurdering. Vi satte stor pris på at en fagperson kunne gi sin tilbakemelding slik at vi kunne gjøre rapporten interessant og lærerik. Side 36 av 135

36 Kapittel 10: Konklusjon Noark 5 Dokumentfangst 10 Konklusjon Hvordan kan informasjon fra SMS og Facebook (sosiale medier) journalføres og arkiveres i et standardformat? Følgende problemstilling har vi utarbeidet, og jobbet med for å løse. Prosjektoppgaven har vist seg som en spennende og lærerik utfordring. Etter et halvt år med dette prosjektet, har vi gått fra en problemstilling til å kunne bevise at konseptet var mulig. Vi har utarbeidet en løsning bestående av applikasjoner som lar personer og bedrifter dokumentere sin egen og andres kommunikasjon i sosiale medier og SMS. Det bekrefter at det ikke handler om hvilket format innholdet er i. Så lenge innholdet er journalføringspliktig, er det kun en teknologisk utfordring. For oppdragsgiver dekker produktet alle kravene som ble satt i starten av prosjektet. Produktet har også en verdi for oppdragsgiver, i den form at produktet har vist at dokumentfangst av sosiale medier ikke er en teknisk umulighet, og har allerede rukket å påvirke debatten rundt journalføring av sosiale medier. Produktet dekker et voksende behov, siden sosiale medier blir oftere og oftere brukt til å formidle informasjon. Produktet har nærmest uendelige bruksmuligheter innenfor dokumentfangst. Vi kan se det for oss i bruk i mindre bedrifter som bruker Facebook eller SMS for å kommunisere i sin daglige virksomhet. Vi kan se det for oss i bruk av politikere og andre offentlige personer som på en enklere måte kan dokumentere sin egen og andres kommunikasjon i det offentlige rom. Ved videre utvikling av produktet kan også privatpersoner dokumentere all ønskelig kommunikasjon. Det gir de mulighet til å ha full oversikt over egne avtaler, samtaler o.l. Se for deg produktet bli utvidet til å gjelde Twitter, eller andre sosiale medier. Programmet kan hjelpe til å samle alt av informasjon du deler med verden på alle ønskelige måter, samler de i et format som er standardisert, og gir deg full oversikt over alle dine utsagn og samtaler. Vi har brukt mye tid på forskning, utvikling og å tilegne oss kunnskap om nye teknologier som TOA, Android, Noark og Facebook, noe vi pent har sett oss nødt til siden vi transporterer informasjon mellom mange forskjellige programmeringsspråk og plattformer. Underveis har vi møtt på mange utfordringer, både programmeringsmessig og teknisk. Under utviklingen av mobilapplikasjonen dukket det opp flere utfordringer, som skyldes at den gikk fra ingen brukerinteraksjon til full brukerinteraksjon. Av tekniske utfordringer har oppsett av en Noark-kjerne på egen hånd vært en utfordring, men som løste seg til slutt. Vi ønsker å takke veileder for å ha støttet oss med veiledningstimer og kommet med tilbakemeldinger. Vil også takke oppdragsgiver for informasjon om Noark og muligheten til å fremføre produktet foran Riksarkivet, som gjorde det mulig å få nyttige Side 37 av 135