Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2

Transkript

1

2 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 2

3 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Backup for PDA/Smartphones DATO 25. mai 2007 ANTALL SIDER / BILAG 192 PROSJEKTDELTAKERE Mikael Cabot (s127844) Are Flyen (s129182) Bjørn Arne Hagen (s122417) Håvard Hebnes (s127620) INTERN VEILEDER Simen Hagen OPPDRAGSGIVER KONTAKTPERSON Touch Mobility AS ( Even Weberg SAMMENDRAG Oppgaven har gått ut på å lage en backupløsning rettet mot PDA/Smartphones som kjører på Windows Mobile plattformen fra Microsoft. Oppdragsgiver for oppgaven har vært Touch Mobility AS, et selskap som spesialiserer seg innen utvikling av løsninger for denne plattformen. Målet med løsningen var å kunne ta backup av såkalte PIM-data (kontakter, kalender, oppgaver og notater), meldinger og filer til en sentral lagring. Til dette er det utviklet en egen klient som kjører på PDA/Smartphone samt en serverdel. Serveren består av en del som tar i mot data fra klienten samt et webgrensesnitt som sluttbruker kan logge inn på for å se på status og sine data. Løsningen er utviklet på en ren Microsoft plattform ved hjelp av C#, C++ og ASP.NET. På klientsiden kjører løsningen på Microsoft Windows Mobile 5.0. Serversiden kjører på Windows Server 2003 med Internet Information Server applikasjontjener og MySQL relasjonsdatabase. Vi mener å ha klart å oppnå kravene til løsningen samt holdt oss innen for alle tidsfrister. 3 STIKKORD Backup PDA/Smartphones Microsoft Windows Mobile

4 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 4

5 Forord Dette dokumentet består av alle dokumentene knyttet til hovedprosjektet vi har hatt ved Høgskolen i Oslo, Avdeling for Ingeniørutdanning. Hoveddokumentet er bygd opp av samtlige dokumenter vi har jobbet på i prosjektet. Inndelingen av denne er som følger: Styringsdokumentasjon, Prosessrapport, Produktrapport, Testrapport og Brukerveiledning. Styringsdokumentasjonen består i tillegg av underdokumentene: Statusrapport, Prosjektskisse, Forprosjektrapport, Arbeidsplan, Fremdriftsplan og kravspesifikasjon. Dokumentene fungerer som selvstendige dokumenter, og kan leses uavhengige av hverandre. Dokumentene som inngår i hoveddokumentet er også tilgjengelige i PDF format på vedlagte CD og prosjektets webside ( sammen med dokumentasjon av kildekoden for programmet. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 5

6 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 6

7 Innholdsfortegnelse Styringsdokumenter... 9 Prosessrapport Produktdokumentasjon Testrapport Brukerveiledning Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 7

8 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 8

9

10 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 10

11 Forord Dette er en samling av alle styringsdokumentene som er lagd i forbindelse med planleggingen av hovedprosjektet. Disse er satt opp i en kronologisk rekkefølge fra det første dokumentet som er en statusrapport fra høsten 2006 til revidert kravspesifikasjon fra midten av februar Det er greit å merke seg at dokumentene ble produsert med tanke på at de skal kunne opptre selvstendig i enkeltleveranser og vil derfor inneholde litt overflødig informasjon i starten. Dokumentene er publisert på følgende tidspunkt: Dokumentnavn Publisert Statusrapport Prosjektskisse Forprosjektrapport Arbeidsplan Fremdriftsplan Kravspesifikasjon Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 11

12 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 12

13 Innholdsfortegnelse 1 Statusrapport Aktuelle firmaer Solve IT MediaLT AS, Oslo Statens Landbruksforvaltning Yara, Oslo Gruppens ønsker til prosjektet Prosjektskisse Om Touch Mobility AS Prosjektforslaget Forprosjektrapport Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger Analyse av løsninger Arbeidsplan Fremdriftsplan Kravspesifikasjon Presentasjon Innledning Innledning Om bedriften Bakgrunn for prosjektet Forord Systemkrav Overordnet usecase Funksjonelle krav Ikke funksjonelle krav Tekniske krav Krav til design Brukervennlighet Fleksibilitet Universell design Kode Krav til kode Dokumentasjon Krav til dokumentasjon Utvidelser Restore VNC Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 13

14 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 14

15 1 Statusrapport Innlevert fredag 27. oktober 2006 av Navn Klasse Studentnummer E-post Are Flyen 3AB Bjørn Arne Hagen 3AB Håvard Hebnes 3AB Mikael Cabot 3AB Vår gruppe består av Are Flyen, Håvard Hebnes, Bjørn Arne Hagen og Mikael Cabot. Vi har fått forslag til flere prosjektoppgaver, man har ikke foreløpig tatt noen avgjørelse på hvilke oppgave vi vil velge. 1.1 Aktuelle firmaer Solve IT Solve IT er en helhetlig leverandør av stabile og effektive IT løsninger og programmer til næringslivet. Firmaet ble startet i 2004, har nå 4 ansatte og utvikler primært i.net. All programvare som firmaet utvikler inkluderer bruk av håndholdte PCer MediaLT AS, Oslo Firmaet ble grunnlagt i 1999 og satser på opplæring, utvikling og tilrettelegging rettet mot personer med spesielle behov. Hovedvirksomheten er basert rundt forskning og utvikling og deltatt både i nasjonale og internasjonale forskningsprosjekter både med MediaLT som initiativtaker og som partner. Videre tilbyr de tjenester innen prosjektstyring, utviking av software og webapplikasjoner, tilpassning av eksisterende standardprogramvare, rådgivning med tanke på web og tilgjenglighet, leverandøruavhenig rådgivning for tilpassing av datautstyr og produksjon av elektroniske bøker og multimedia. Det er i dag 7 ansatte og firmaet holder til i nye lokaler på Furuset. Eget kontor for prosjektgruppen kan bli stilt til disposisjon med nødvendige fasiliteter. MediaLT har stilt 6 ulike prosjektforslag hovedsaklig rettet rundt utvikling mot web. Noen av disse vil inngå som deloppgaver i forskningsprosjekter som startes opp høsten 2006 / våren Statens Landbruksforvaltning Er en bedrift som jobber mot bøndene i landet, der bedriftens hovedoppgaver er å ta seg av utbetalinger til bøndene. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 15

16 1.1.4 Yara, Oslo Yara er et ledende selskap innenfor kjemisk industri som omdanner luftens energi og nitrogen til viktige produkter for landbruk og industri. Bedriften har 6800 medarbeidere over hele verden som med sin allsidighet og dyktighet hjelper selskapet med å forbli en ledende aktør innen sitt felt. 1.2 Gruppens ønsker til prosjektet Vi har drøftet litt hva som kan være interessant for oss å jobbe med. Flere på gruppen har tidligere jobbet mye med webutvikling og føler at det kanskje ikke er et hovedønske denne gangen. En kort grunn til det er at vi ønsker å benytte prosjektet til å fordype oss litt i ny teknologi. Noen områder som vi har lyst til å jobbe med er utvikling på Microsoft sin.net-plattform. Dette er siden skolen ikke tilbyr noe undervisning innenfor dette feltet mens bedriftsmarkedet i høyeste grad etterspør folk med denne kompetansen i dag. Dette området tror vi vil bare bli desto mer aktuelt med tiden. Selv om.net-plattformen byr på mye spennende innen web med ASP.NET så føler vi at det å utvikle enten en Windows-applikasjon, en service/server-tjeneste eller en Windows Mobile applikasjon ville vært noe nytt og spennende for oss! Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 16

17 2 Prosjektskisse Dato og sted: Oslo, 1. desember 2006 Foreløpig tittel: Backup for PDA/Smartphones Prosjektgruppe: Mikael Cabot, Are Flyen, Bjørn Arne Hagen og Håvard Hebnes Oppdragsgiver: Touch Mobility AS, Gjerdrums vei 12A, 0484 Oslo Kontaktperson: Supportansvarlig Even Weberg, tlf , e-post: 2.1 Om Touch Mobility AS Touch Mobility AS ble startet januar 2005 og eies av grunderne, Telenor og Telefast (importør av PDAer og Smartphones) Touch Mobility AS har pr. dags dato 10 ansatte fordelt på administrasjon, salg, utvikling og support. Firmaet utvikler programvare for PDAer og Smartphones basert på Microsoft Windows Mobile operativsystem. Kjerneproduktet er et såkalt Device Management System som benyttes for administrasjon av PDA/Smartphones over telefon nettet (Over The Air (OTA) teknologi). Med denne løsningen kan en IT Administrator i fra hvilken som helst datamaskin med internett-tilgang administrere alle slike enheter uansett hvor brukerne befinner seg eneste krav er at det er GPRS-dekning på PDA/Smartphone og firmaets InTouch-klient installert. Mer info finnes på firmaets hjemmesider: Prosjektforslaget Prosjektet skal gå ut på å utvikle en applikasjon som skal kjøre på PDA/Smartphones med Windows Mobile. Applikasjonen skal være et verktøy for brukeren og inneholde funksjoner for backup av SMS, MMS, e-post, kontakter, kaldender, bilder og dokumenter. Det skal legges opp til en fleksibel struktur som tillater at nye funksjoner kan legges til senere. Backup skal kunne tas enten mot fil lokalt eller mot sentral server med oversikt via et webgrensesnitt. Hvis tiden tillater det er det og ønskelig at det utredes hvordan VNC kan brukes på PDA/Smartphones for support av brukere via fjernstyring. Utover skolens krav til dokumentasjon så er følgende utviklingsfaser ønsket: funksjonelt design av løsning, visuelt design av løsning, implementasjon av løsning, testing av løsning og vurdering av løsning. Applikasjonen skal utvikles på Microsoft sin.net-plattform med Visual Studio 2005 og SDK for Windows Mobile 5. Løsningen bør også benytte Compact Framework 2.0. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 17

18 3 Forprosjektrapport 3.1 Presentasjon Tittel: Backup for PDA/Smartphones Oppgave: Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter Prosjektperiode: Gruppemedlemmer: Mikael Cabot, Are Flyen, Bjørn Arne Hagen, Håvard Hebnes Prosjektgruppe: Veileder: Simen Hagen Oppdragsgiver: Touch Mobility AS Kontaktperson: Even Weberg, tlf Sammendrag Prosjektet skal gjennomføres som hovedprosjekt ved Høgskolen i Oslo avd. for Ingeniørutdanning i samarbeid med Touch Mobility AS. Oppgaven går ut på å lage en løsning bestående av diverse verktøy for å ta backup av personlig informasjon som ligger lagret på en PDA/Smartphone basert på Windows Mobile Om bedriften Touch Mobility AS ble startet januar 2005 og eies av gründerne, Telenor og Telefast (importør av PDA'er og Smartphones) Touch Mobility AS har pr. dags dato 10 ansatte fordelt på administrasjon, salg, utvikling og support. Firmaet utvikler programvare for PDAer og Smartphones basert på Microsoft Windows Mobile operativsystem. Kjerneproduktet er et såkalt Device Management System som benyttes for administrasjon av PDA/Smartphones over telefon nettet (Over The Air (OTA) teknologi). Med denne løsningen kan en IT Administrator i fra hvilken som helst datamaskin med internett-tilgang administrere alle slike enheter uansett hvor brukerne befinner seg eneste krav er at det er GPRS-dekning på PDA/Smartphone og firmaets InTouch-klient installert. 3.4 Dagens situasjon Når en bruker av en PDA/Smartphone basert på Windows Mobile legger inn informasjon i telefonen, kan det være ønskelig å kunne ta backup av dette slik at innholdet er sikret hvis tap av data skulle skje. Typiske brukere av disse telefonene er bedrifter, og de har gjerne både sensitive og forretningskritiske data lagret på denne. Hvis brukeren skulle være uheldig å miste eller bli frastjålet telefonen, uheldig sletting, uopprettelig feil på telefonen, hardwarefeil, osv. vil dette kunne få store konsekvenser for både for den ansatte og for bedriften. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 18

19 Dette er en funksjon som per dags dato ikke eksisterer på disse telefonene uten bruk av 3.parts programvare. Touch Mobility ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder. 3.5 Mål og rammebetingelser Mål Målet med oppgaven er å utvikle en applikasjon for backup av informasjon som bruker har lagret på en PDA/Smartphone basert på Windows Mobile 5. Det vil bli lagt vekt på en fleksibel løsning som skal være så brukervennlig som mulig. Terskelen for å ta i bruk applikasjonen skal være så lav at selv ikke tekniske personer kan bruke den uten større opplæring. Videre skal den inneholde funksjonalitet for å tilfredsstille brukerens behov. Informasjon det kan være aktuelt å ta backup av: SMS MMS E-post Kontakter Kalender Bilder Dokumenter Filer av typen *.xyz Hovedfunksjonalitet som kan implementeres: Backup til minnekort/pc (med mulighet for kryptering/passord). Backup/synkronisering til Web-tjeneste ved bruk av SyncML. Implementasjon av VNC. Implementeringen av VNC er en oppgave som går litt utenom selve hovedoppgaven, og vil derfor ikke bli prioritet. Den vil kun bli tatt med som en bonus hvis det blir nok tid til dette på slutten av prosjektperioden Rammebetingelser Som hovedfunksjonalitet for applikasjonen er backup løsningen, i den sammenheng står vi ganske fritt til å velge funksjonalitetsmengden vi skal implementere. Det vil bli gjort en prioritering over hvilke av arbeidsoppgaver som er viktigst å få på plass, og de vil da bli utført først i prosjektet. Dette fordi det i en så tidlig fase kan være vanskelig å forutsi arbeidsmengden det vil medføre å implementere alle tenkelige deler. Vanskelighetsgraden av de ulike delene spiller også inn i denne avgjørelsen. Av utstyr er det stilt til rådighet en PDA til hvert av gruppemedlemmene. 3.6 Løsninger Alle PDA/Smartphones som skal kjøre denne applikasjonen benytter seg av operativsystemet Windows Mobile 5. Dette legger da klare føringer for at løsningen må benytte seg av Microsoft.NET Compact framework 2.0..NET eksisterer i Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 19

20 hovedgrad på Windowsplattformen, og valg av operativsystem vil derfor bli Windows XP. Windows Vista ble vurdert men blir ansett for å være litt for nytt til å benyttes i en utviklingsplattform. Koden kan lages uavhengig av verktøy, men det ligger klare fordeler ved å ta i bruk Visual Studio 2005 med de kravene som er stilt ovenfor. Når det gjelder selve backup løsningen så må en ta stilling til hvilken måte en ønsker å lagre data på. Dette kan skje enten ved lokal lagring til enheten (på minnekort) eller overføre backupen til en ekstern server ved hjelp av protokoller som SyncML. Lokal backup Ekstern backup Fordeler Alltid tilgjenglig Hastighet Tilgjenglig selv ved mistet enhet Større lagringskapasitet Andre kan ta ansvar for oppbevaring Ulemper Ved tap av enhet blir og backup borte Tar opp mye plass etter hvert Hastighet Krever tilgang til nettverk (GPRS/UTMS/WLAN) Sikkerhetsspørsmål Begge løsningene har såpass store fordeler at det vil være fornuftig å implementere de begge. Dette vil selvsagt medføre en større arbeidsmengde, men likevel så kan dette forsvares ved en betraktelig økning av både funksjonalitet og kvalitet på produktet. Brukeren av produktet vil være i situasjoner der både lokal og ekstern backup vil tale for og mot hverandre, og derfor vil en kombinasjon sikre at en alltid vil kunne få tatt ut en backup. 3.7 Analyse av løsninger Hovedargumentene ovenfor bedrifter er sikkerhets og kostnadsbesparelse. Ved å regelmessig kunne ta backup av data vil en sikre bedriften mot tap av sensitive og forretningskritiske data. Brukeren utfører selv backup, derfor vil IT-ansvarlig for bedriften i mindre grad involveres, noe som frigir ressurser. Produktet i seg selv kan være en avgjørende faktor for at en bedrift tar avgjørelsen for å innføre mobile terminaler. En bruker med ikke-teknisk bakgrunn vil føle større trygghet ved bruk av en slik enhet da brukerfeil vil ha mindre konsekvens og enkelt kunne rettes opp. Markedet for slike enheter er svært økende og behovet for en slik tjeneste vokser parallelt. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 20

21 4 Arbeidsplan Aktivitet Beskrivelse Ferdig Planlegging Statusrapport Prosjektskisse Prosjektside Forprosjektrapport Arbeidsplan Fremdriftsplan Kravspesifikasjon Datainnsamling Dataanalyse Kravspesifikasjon En oppsummering over hvilke gruppemedlemmer som skal delta, hvilke prosjekter vi kunne tenke oss å jobbe med samt hvilke firmaer vi har kontaktet om prosjektforslag. Informasjon om bedriften vi har valgt å jobbe videre med samt en presentasjon av deres prosjektforslag. Sette opp en egen webside for prosjektgruppa hvor alle dokumenter og informasjon publiseres. Mer utfyllende om prosjektet med mål, rammebetingelser og teknologier. En oversikt over alle fasene i prosjektet samt aktiviteter og dato for ferdigstillelse. Et Gantt-diagram over alle aktiviteter og milepæler i prosjektet. Samarbeid med oppdraggiver om å innhente informasjon om hva prosjektet skal inneholde samt nåværende situasjon og krav til løsning. Analyse av oppdragsgivers krav og ønsker for å komme frem til overkommelige krav og begrensinger til oppgaven. Utarbeide en detaljert kravspesifikasjon basert på de to overstående punktene. Godkjennes av oppdragsgiver før implementeringsfasen påbegynnes Implementering Design Utvikle et brukergrensesnitt for applikasjonen Lokal backup Utvikle løsning for backup til lokalt minnekort SyncML Utvikle en SyncML klient for WM Ekstern backup Utvikle løsning for backup til ekstern server ved hjelp av SyncML klient. Kodefrys All utvikling skal være ferdig og koden som er utviklet pr denne datoen skal være den endelige Testing og feilsøking Intern testing Ekstern testing Tester at systemet fungerer som det skal ut fra den funksjonaliteten som er utviklet. Oppdragsgiver og veileder tester på samme måte som oss og gir en siste tilbakemelding før Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 21

22 Feilretting eventuelle feil rettes. Rette feil om mangler som har kommet frem under overstående testperiode Dokumentasjon Brukermanual Utvikle en enkel brukermanual for oppdragsgiver og deres brukere. Prosjektrapport Skrive en prosess, produkt og testrapport Prosjektdagbok Gjennom hele prosjektperioden skal det føres en prosjektdagbok som logger alle aktiviteter som gruppen foretar seg i fellesskap. Dette skal være et underlag for sluttrapporten. Timelister Gjennom hele prosjektperioden skal det føres individuelle timelister for hvem som har utført hvilket arbeid Fullføring Forbrede presentasjon Lage et opplegg for presentasjonen, klargjøre Powerpoint-presentasjon og prøvekjøring av opplegget Presentasjon Presentasjon av prosjektet for sensor og veileder Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 22

23 5 Fremdriftsplan Denne fremdriftsplanen er delt opp over to sider i liggende format for å få best mulig presentasjon på papir. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 23

24 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 24

25 6 Kravspesifikasjon 6.1 Presentasjon Tittel: Backup for PDA/Smartphones Oppgave: Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter Prosjektperiode: Gruppemedlemmer: Mikael Cabot, Are Flyen, Bjørn Arne Hagen, Håvard Hebnes Prosjektgruppe: Veileder: Simen Hagen, HiO Oppdragsgiver: Touch Mobility AS Kontaktperson: Even Weberg, tlf Innledning Innledning Prosjektet skal gjennomføres som hovedprosjekt ved Høgskolen i Oslo avd. for Ingeniørutdanning i samarbeid med Touch Mobility AS. Oppgaven går ut på å lage en løsning bestående av diverse verktøy for å ta backup av personlig informasjon som ligger lagret på en PDA/Smartphone basert på Windows Mobile Om bedriften Touch Mobility AS ble startet januar 2005 og eies av gründerne, Telenor og Telefast (importør av PDA'er og Smartphones) Touch Mobility AS har pr. dags dato 10 ansatte fordelt på administrasjon, salg, utvikling og support. Firmaet utvikler programvare for PDAer og Smartphones basert på Microsoft Windows Mobile operativsystem. Kjerneproduktet er et såkalt Device Management System som benyttes for administrasjon av PDA/Smartphones over telefon nettet (Over The Air (OTA) teknologi). Med denne løsningen kan en IT Administrator i fra hvilken som helst datamaskin med internett-tilgang administrere alle slike enheter uansett hvor brukerne befinner seg eneste krav er at det er GPRS-dekning på PDA/Smartphone og firmaets InTouch-klient installert Bakgrunn for prosjektet Typiske brukere av PDA/Smartphones er bedrifter, og de har gjerne både sensitive og forretningskritiske data lagret på denne. Hvis brukeren skulle være uheldig å miste eller bli frastjålet telefonen, uheldig sletting, uopprettelig feil på telefonen, hardwarefeil, osv. vil dette kunne få store konsekvenser for både den ansatte og for bedriften. Derfor er det ønskelig med en funksjon for å kunne ta backup av informasjonen som er lagret på en slik telefon. Dette er en funksjon som per dags dato ikke eksisterer på disse telefonene uten bruk av 3.parts programvare. Touch Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 25

26 Mobility ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder. 6.3 Forord Formålet med denne kravspesifikasjonen er for det første å avgrense hovedoppgavens omfang mot vår oppdragsgiver Touch Mobility AS. Kravspesifikasjonen vil i så måte kunne endre seg underveis i løpet av prosjektperioden. Den vil videre være et hjelpemiddel for oss i det videre arbeidet med prosjektet, og sørge for at vi holder oss til kravene som er gitt. 6.4 Systemkrav Overordnet usecase Funksjonelle krav Bruker skal kunne velge hva man tar backup av Det er flere typer data det kan bli tatt backup av. Data som sms, mms, e-post, kontakter, kalender, bilder, dokumenter, filer, osv. Brukere kan velge hvilke data som skal sikkerhetskopieres. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 26

27 Velge hvor backup skal lagres Bruker kan velge hvor dataene det tas backup av skal lagres. Dette kan lagres enten lokalt på enhetens minnekort eller eksternt på en server. Overføre backup til en ekstern server Bruker skal kunne velge om han ønsker å overføre backup til en ekstern server. Under overføring av backup eksternt, vil SyncML bli benyttet. Applikasjonen må kjøres på WM 5 Det er et krav at applikasjonen skal kjøres på Windows Mobile 5, da applikasjonen skal utvikles for PDA/Smartphones med dette operativsystemet. Sikker overføring og lagring av data Når det skal tas backup av dataene, skal det være et krav at dataene er ivaretatt på best mulig måte under backup prosessen, slik at det ikke skal forekomme at data forsvinner. Brukervennlighet Det er et mål at systemet skal være brukervennlig. Vi vil så langt det lar seg gjøre sørge for et brukervennlig system. Admin system for oppretting av brukerrettigheter Det vil bli fremsatt et enkelt system for oppretting av brukerrettigheter for de forskjellige backup funksjonene i applikasjonen Ikke funksjonelle krav Oppetid Synkroniseringsserveren bør ha en oppetid på tilnærmet 100%. Ubegrenset antall brukere Det vil ikke være noen begrensninger i antall brukere som kan benytte seg av systemet Tekniske krav Utviklingsplattform Utviklingsverktøy: Microsoft Visual Studio 2005 Rammeverk: Microsoft.NET Compact framework 2.0 Operativsystem: Windows XP Driftsplattform Alle PDA/Smartphones med Windows Mobile 5.0 som operativsystem Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 27

28 6.5 Krav til design Brukervennlighet Ved utformingen av systemet vil det bli lagt stor vekt på brukervennlighet. Designet på systemet skal være av en slik karakter at det er lett å bruke de forskjellige funksjonene i applikasjonen, med logisk og naturlig plassering av slikt som knapper, menyvalg, funksjoner, innstillinger og lignende. Det tekniske ved systemet skal ikke synliggjøres for brukeren i noen form, men skjules over et enkelt og brukervennlig GUI. Dette skal ikke gå på bekostning av funksjonaliteten i systemet, men heller presenteres på en slik måte at bruker kan velge enkle snarveier for å utføre mer avanserte/kraftfulle funksjoner. Vi mener at dette er viktig da vi tenker oss at typiske brukere av systemet ikke bare er de med god teknisk forståelse, men også de som har liten teknisk innsikt. Dette vil gjøre det lettere for alle typer brukere å benytte seg av løsningen Fleksibilitet Løsningen som skal bygges opp, tar utgangspunkt i en fleksibel grunnstruktur. Der vi har tatt høyde for at videreutvikling av systemet skal være så smertefritt som mulig. Systemet blir derfor designet slik at det skal være lett å implementere ny funksjonalitet, enkelt å tilpasse og endre eksisterende elementer. Dette er viktig da nye krav til funksjonalitet kan gjøre seg gjeldende i fremtiden Universell design Vi skal bestrebe å utvikle systemet så universelt som mulig. Med dette menes utformingen av produktet, slik at det kan brukes av de aller fleste brukere, i så stor utstrekning som mulig, og uten behov for tilpasning til en bestemt brukergruppe. Totalt sett vil dette medføre at terskelen blir mindre for å ta i bruk funksjonene i applikasjonen. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 28

29 6.6 Kode Krav til kode Målet med å sette krav til koden som skrives i dette prosjektet er for at det både skal følge gitte standarder, samt at det skal være lett for hvem som helst å overta den på et senere tidspunkt. På samme måte vil det være enkelt for deltakerne i prosjektet å utveksle kode uten at det settes spor av hvem som har jobbet med den. Oppdragsgiver har ingen gitte krav til kodestandard men følger standarder ut fra Microsoft / Visual Studio. Microsoft har utviklet et grunnleggende dokument for design av klasser og datastrukturer [1]. Det gir en innsikt i hvordan en bør strukturere koden sin, men sier ikke detaljert om hvordan navngiving, tegnsetting, språk og dokumentasjon bør være. En av arkitektene bak.net rammeverket har utviklet mer detaljerte retningslinjer som beskriver dette [2]. De er mer lette å lese og oppsummerer de viktigste elementene som en bør følge under koding. Derfor bør de og ansees som en gjeldende retningslinje for utviklingen i dette prosjektet. En siste referanse er til en retningslinje fra Microsoft om hvordan skrive sikker kode [3]. De kan brukes for å se flere eksempler på syntaksbruk. Videre er de viktige for å få en grunnleggende innføring i hvordan en kan skrive sikrere kode nettopp for å bedre den generelle standarden på produktet. Oppsummert kan en si at det skal settes som mål å skrive både strukturert, enkel og sikker kode i dette prosjektet basert på de overstående anbefalingene. [1] [2] [2] Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 29

30 6.7 Dokumentasjon Krav til dokumentasjon Det blir i løpet av prosjektet ført prosjektdagbok, der denne kort beskriver hva som er blitt gjort. Vi har også utarbeidet en arbeidsplan og en fremdriftsplan, som hjelper oss å holde fokus på arbeidsoppgavene og holde oss til disse innen gitte frister. Vi har opprettet en egen dokumentmal som vi skal bruke for alle dokumenter vi skal lage. Dette vil medføre en lik og gjennomført stil for alle dokumenter vi lager. Og vil resultere i mindre jobb da vi slipper formateringsjobben i etterkant. Det er et krav at vi følger dokumentstandarden som er satt av skolen. Siden det er ganske store krav til dokumentasjonen og mengden av dokumenter som skal opprettes, skiller vi mellom styringsdokumentasjon og sluttdokumentasjon som hoveddeler. Der styringsdokumentene er dokumentene som lages under prosessen, og sluttdokumentasjonen er samlingen av dokumenter som skal leveres inn til slutt. På grunn av at kravspesifikasjonen vil kunne endres underveis vil denne være en del av både styringsdokumentasjonen og sluttdokumentasjonen. Dette for at veileder og sensor skal kunne se evt. endringer som er gjort i denne og for å kunne evaluere i hvilken grad denne er oppfylt. Styringsdokumenter: Prosjektskisse Prosjektdagbok Forprosjektrapport Arbeidsplan og fremdriftsplan Overordnet kravspesifikasjon Sluttdokumentasjon: Endelig kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerveiledning Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 30

31 6.8 Utvidelser Restore Av fremtidige utvidelser vil det være ønskelig å implementere en restore funksjon slik at brukeren kan legge inn en backup hvis det skulle bli behov for dette. Det bør kunne kjøres restore fra tidligere backup som er lagret som fil, og man bør også kunne kjøre restore fra backup som er lagret på ekstern server VNC En VNC-leser (Virtual Network Computing) er et program som f.eks. kjøres på en lokal maskin hvor man kopler seg opp til en ekstern PDA/Smartphone. Når man har koplet seg til PDA/Smartphonen kan man bruke den som om det var sin egen telefon. Dette vil være til stor hjelp for en som sitter på support og skal hjelpe en kunde som har problemer med sin egen PDA. Det er et ønske fra Touch Mobility at en slik leser utvikles hvis tiden tillater dette. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 31

32 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 32

33

34 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 34

35 Forord Denne rapporten beskriver gruppens arbeid gjennom hele prosjektperioden og hvordan prosessen har vært gjennomført. Rapporten er først og fremst beregnet på sensor, veileder og oppdragsgiver. Det kreves ingen nødvendig kompetanse for å sette seg inn i dette dokumentet. I rapporten blir det gjort rede for hvordan planleggingsprosessen er utført, om utviklingsprosessen og hvordan vi har løst arbeidet i alle dets faser. Rapporten beskriver videre om gjennomføringen av kravspesifikasjonen og reviderte utgaver av denne. Det blir også nevnt hvordan samsvaret mellom kravspesifikasjon og design til systemet og implementering har foregått. Vi fant tidlig ut av hva slags type oppgave vi kunne tenke oss som hovedprosjekt. Vi var i kontakt med flere bedrifter, men klarte ikke å finne en oppgave som passet oss. Da det omsider kom inn et prosjektforslag til skolen vi følte var riktig for oss, tok vi kontakt med bedriften. Etter et møte med dem ble det klart at dette var et prosjekt vi kunne tenke oss å jobbe med, og sa ja til å ta dette som hovedprosjekt. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 35

36 Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 36

37 Innholdsfortegnelse 1 Innledning Om bedriften Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Planlegging og metode Fordeling av oppgaver Innspill fra veileder Arbeidsplan og fremdriftsplan Utviklingsprosessen Innledende fase Forprosjekt fasen Dagbok Planleggingsfasen Forprosjektrapport Faste arbeidsdager Veileder Opprettelse av arbeidsplan og fremdriftsplan Forprosjektrapport og nettside Kontrakt inngåelse Programmering Planen for arbeidet En klientdel og en serverdel Samkjøring av klient og server Forskjellige løsninger og ny læring Samarbeidet i gruppen Revisjonsverktøy Testing Funksjonell testing Sluttesting Avslutningsfasen Dokumentering Kompetansetilegning Tilrettelegging fra oppdragsgiver Kontakt i forhold til veileder Kontakt i forhold til oppdragsgiver Arbeidsforhold i prosjekttiden Faglig utbytte Kvaliteten på prosjektet Brukervennlighet Tidsbruk Teknologi Sikkerhet Fleksibilitet Utforming av kode Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 37

38 3.15 Utfordringer under prosjektgjennomføringen Funksjonalitet for uthenting av sms Merking av filer for backup Sending av data til server Dynamic-link Libraries (.dll) Kravspesifikasjonen Generelt Endringer i kravspesifikasjonen SyncML Backup til Storage Card Kravspesifikasjonen i forhold til design og implementering Oppsummering og konklusjon Oppsummering Hva kunne vært gjort annerledes Produktets framtid Konklusjon Kildehenvisninger Vedlegg Dagbok Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 38

39 1 Innledning 1.1 Om bedriften Touch Mobility AS ble startet januar 2005 og eies av gründerne, Telenor og Telefast (importør av PDA'er og Smartphones) Touch Mobility AS har pr. dags dato 10 ansatte fordelt på administrasjon, salg, utvikling og support. Firmaet utvikler programvare for PDAer og Smartphones basert på Microsoft Windows Mobile operativsystem. Kjerneproduktet er et såkalt Device Management System som benyttes for administrasjon av PDA/Smartphones over telefon nettet (Over The Air (OTA) teknologi). Med denne løsningen kan en IT Administrator i fra hvilken som helst datamaskin med internett-tilgang administrere alle slike enheter uansett hvor brukerne befinner seg eneste krav er at det er GPRS-dekning på PDA/Smartphone og firmaets InTouch-klient installert. 1.2 Dagens situasjon Når en bruker av en PDA/Smartphone basert på Windows Mobile legger inn informasjon i telefonen, kan det være ønskelig å kunne ta backup av dette slik at innholdet er sikret hvis tap av data skulle skje. Typiske brukere av disse telefonene er bedrifter, og de har gjerne både sensitive og forretningskritiske data lagret på denne. Hvis brukeren skulle være uheldig å miste eller bli frastjålet telefonen, uheldig sletting, uopprettelig feil på telefonen, hardwarefeil, osv. vil dette kunne få store konsekvenser for både for den ansatte og for bedriften. Dette er en funksjon som per dags dato ikke eksisterer på disse telefonene uten bruk av 3.parts programvare. Touch Mobility ønsker derfor å inkludere en slik funksjon i den løsningen de tilbyr sine kunder. 1.3 Mål og rammebetingelser Mål Målet med oppgaven er å utvikle en applikasjon for backup av informasjon som bruker har lagret på en PDA/Smartphone basert på Windows Mobile 5. Det vil bli lagt vekt på en fleksibel løsning som skal være så brukervennlig som mulig. Terskelen for å ta i bruk applikasjonen skal være så lav at selv ikke tekniske personer kan bruke den uten større opplæring. Videre skal den inneholde funksjonalitet for å tilfredsstille brukerens behov. Informasjon det kan være aktuelt å ta backup av: SMS MMS E-post Kontakter Kalender Bilder Dokumenter Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 39

40 Filer av typen *.xyz Hovedfunksjonalitet som kan implementeres: Backup til minnekort/pc (med mulighet for kryptering/passord). Backup/synkronisering til Web-tjeneste ved bruk av SyncML. Implementasjon av VNC. Implementeringen av VNC er en oppgave som går litt utenom selve hovedoppgaven, og vil derfor ikke bli prioritet. Den vil kun bli tatt med som en bonus hvis det blir nok tid til dette på slutten av prosjektperioden Rammebetingelser Som hovedfunksjonalitet for applikasjonen er backup løsningen, i den sammenheng står vi ganske fritt til å velge funksjonalitetsmengden vi skal implementere. Det vil bli gjort en prioritering over hvilke av arbeidsoppgaver som er viktigst å få på plass, og de vil da bli utført først i prosjektet. Dette fordi det i en så tidlig fase kan være vanskelig å forutsi arbeidsmengden det vil medføre å implementere alle tenkelige deler. Vanskelighetsgraden av de ulike delene spiller også inn i denne avgjørelsen. Av utstyr er det stilt til rådighet en PDA til hvert av gruppemedlemmene. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 40

41 2 Planlegging og metode 2.1 Fordeling av oppgaver Når vårt prosjekt ble avklart, satte vi oss ned og begynte å planlegge hvordan vi ville strukturere prosjektet. Det ble på dette stadiet avklart hvem som skulle ha ansvaret for de ulike delene av prosjektet, og vi valgte å fordele oppgavene i fire hoveddeler, der hoveddelene bestod av ansvar for kontakt med skole/oppdragsgiver, ansvar for dokumentasjonen, ansvar for prosjektets webside og ansvar for utviklingsdelen. Ansvarsområdene bestod i å delegere ut arbeid til andre gruppemedlemmer, slik at alle fikk være med på samtlige deler av prosjektet. Dette har fungert bra og vi føler at dette har vært en riktig måte å strukturere hovedfasene i prosjektet på. Vi har ikke hatt noen gruppeleder for vårt prosjekt. Vi følte det ikke var behov for dette, da alle på gruppen har jobbet tett sammen gjennom hele prosjektet, og vi har jobbet sammen på mange av de tidligere prosjektene som er gjennomført på skolen. Alle har på denne måten bidratt og tatt ansvar for deler som det har vært behov for å gjennomføre under prosjektet. Vi føler at dette har fungert bra for oss. 2.2 Innspill fra veileder Vi har under prosjektets gang hatt god hjelp fra veileder som har hjulpet oss med å holde oss innenfor oppgavens rammer og hjulpet oss til å innse realistiske mål for hva vi faktisk kunne rekke å gjøre, samt gitt oss tips om hvordan vi skulle legge opp løpet underveis. Dette har vært nyttig siden vi i løpet av prosjektet har vurdert flere tillegg som vi kunne tenkt oss å ha med i oppgaven, men som det ikke egentlig var tid til å gjøre. Når første utkast av kravspesifikasjonen lå klar, ble denne vurdert av veileder og oppdragsgiver. Etter bra respons fra både veileder og oppdragsgiver følte vi at denne var god nok til at vi kunne ta fatt på det videre arbeidet. 2.3 Arbeidsplan og fremdriftsplan Det ble først opprettet en arbeidsplan der vi satte opp alle fasene i prosjektet med de forskjellige delene prosjektet inneholdt. Videre ble det lagd en fremdriftsplan med delmål for alle oppgaver som skulle gjøres. Disse dokumentene har vært nyttige å ha, og har gitt oss en god oversikt over de oppgavene som skulle gjøres. De har også gjort det lettere for oss å bli ferdige med hver del til gitte frister. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 41

42 3 Utviklingsprosessen 3.1 Innledende fase I startfasen av prosjektet ble vår gruppe dannet. Siden alle gruppemedlemmene har jobbet sammen ved mange prosjekter vi har hatt på skolen, hadde vi ingen startvansker innad i vår gruppe. Vi begynte på dette tidspunket å diskutere hva slags type oppgave vi kunne tenke oss i forbindelse med hovedprosjektet, og kom fram til at vi gjerne kunne tenke oss en oppgave som innbefattet programmering i.net og Windows Mobile. Vi var også i kontakt med flere bedrifter for en mulig prosjektoppgave. Vi fikk noen forslag til prosjektoppgaver fra noen av bedriftene, men følte at prosjektforslagene ikke var helt etter våre ønsker. Derfor så vi på dette som alternative løsninger i tilfelle vi ikke skulle finne en bedre egnet oppgave for oss. På dette stadiet påbegynte vi også planleggingen av en nettside for prosjektet, og hvordan utseende og funksjonalitet for denne skulle være. Statusrapporten var neste post, og vi jobbet for å få klargjort denne i tide til innlevering. 3.2 Forprosjekt fasen Før vi gikk løs på prosjektet hadde vi sett oss ut hvilken type oppgave vi kunne tenke oss å jobbe med. I denne perioden var gruppen i dialog med eksterne oppdragsgivere for mulig oppdrag. Da det omsider kom inn ett prosjektforslag til skolen som vi følte var aktuell for oss, tok vi kontakt med oppdragsgiveren, og avtalte et møte med dem. På dette møtet fikk vi en interessant presentasjon av firmaet og oppgaven. Vi syntes dette virket som en meget interessant oppgave. Etter å ha diskutert dette internt i gruppen ble det avklart at vi ville ha dette som hovedprosjekt. Når dette var avklart og prosjektet var vårt, begynte jobben videre med å få på plass prosjektskissen Dagbok Vi påbegynte også arbeidet med å få en dagbok opp å gå, for å få dokumentert hva som ble gjort under hele prosjektperioden. Dette følte vi var viktig å få på plass så tidlig som mulig, da vi var klar over faren med å kunne glemme ting som ble gjort underveis hvis dette ikke ble skrevet ned. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 42

43 3.3 Planleggingsfasen Når prosjektforslaget var klart, påbegynte planleggingen rundt oppgaven. Vi ble enige om å fordele arbeidsoppgavene slik at alle fikk et ansvarsområde å forholde seg til. Dette for at alle skulle få en rolle der man fulgte opp arbeidet på sitt ansvarsområde, dette var ikke det samme som at den personen skulle gjøre alt arbeidet innen sitt ansvarsområde, men heller følge opp og ta ansvar for det som skulle gjøres og delegere ut arbeid til andre gruppemedlemmer Forprosjektrapport Fremdrift videre i denne fasen var opprettelse av forprosjektrapporten, som hadde en fast innleveringsfrist. Før denne kunne bli opprettet måtte vi få konkretisert og definert oppgaven sammen med Touchmobility. Dette for å være på den sikre siden hva gjaldt oppdragsgivers ønsker og krav til oppgaven Faste arbeidsdager Det ble diskutert litt rundt hvor stort omfang vi ville gi oppgaven, og hva vi mente den burde inneholde rent gjennomføringsmessig samt strategisk. Vi bestemte oss også for hvilke dager som var aktuelle å jobbe med prosjektet. I denne forbindelse ble det bestemt å bruke onsdag, torsdag og fredag som felles faste arbeidsdager, i tillegg til individuelt arbeid for den enkelte gruppemedlem Veileder I denne fasen hadde vi også første møte med vår veileder. Her presenterte vi kort prosjektoppgaven vår. Vi fikk i forbindelse med dette, klare retningslinjer for hva som var viktig å vektlegge i forhold til prosjektet, og hvordan vi burde legge opp arbeidet og gjennomføringen av det. Dette har hjulpet oss til å holde fokus og å ta de riktige valg med hensyn til hva som burde gjøres til ulike tidspunkt. Det ble også avtalt med veileder å ha en møtefrekvens en gang i uken, for å avlegge status Opprettelse av arbeidsplan og fremdriftsplan Det ble på dette tidspunktet opprettet en arbeidsplan og fremdriftsplan, for å få en struktur og plan for de oppgaver som skulle utføres igjennom prosjektperioden Forprosjektrapport og nettside Forprosjektrapporten ble ferdigstilt, og vi fikk opp en nettside for prosjektet. Når dette var klart, var arbeidet med kravspesifikasjonen også godt i gang Kontrakt inngåelse Vi opprettet et kontraktsforslag og sendte dette til oppdragsgiver. Denne ble godtatt og kontraktsinngåelse ble deretter opprettet med Touchmobility. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 43

44 3.4 Programmering Utviklingsplattformen vi skulle bruke var ny for de fleste av oss, og i den forbindelse ble mye tid brukt til å sette seg inn i den valgte teknologien. Før vi kunne ta fatt på selve oppgaven, ble det derfor en del prøving for å se hvordan ting fungerte og oppførte seg Planen for arbeidet Det ble lagt mest vekt på funksjonalitet i starten av programmeringen. Vi følte det var viktig å få på plass grunnstrukturen før vi kunne gå videre med andre deler programmet skulle bestå av. Brukergrensesnitt og andre deler ble dermed satt til side. Etter hvert som vi fikk på plass det meste av funksjonaliteten, begynte vi arbeidet med brukergrensesnittet. Vi har i flere omganger omgjort og forbedret koden underveis i prosjektet, på grunn av dette har også kravspesifikasjonen blitt revidert En klientdel og en serverdel Vi delte opp programmeringen i to hoveddeler. En del for klientsiden og en del for serversiden. Der jobben på klientdelen bestod i å bygge opp denne med den funksjonaliteten som trengtes for å hente ut de aktuelle data. Jobben på serversiden, bestod i å bygge opp funksjonaliteten for denne, og å ta seg av alle data som ble mottatt og å behandle dette på en fornuftig og sikker måte. Det var naturlig å bygge opp programmeringen på denne måten da vi kunne skille dette som to hoveddeler Samkjøring av klient og server Det har vært viktig for oss å samkjøre funksjonaliteten på klientsiden og serversiden, slik at når en funksjonalitet var ferdigstilt på klientsiden, kunne arbeidet med oppbygging og mottak for data fra denne funksjonaliteten videreføres og sluttføres på serversiden. Dette har vært en nøysommelig prosess, og mye testing fram og tilbake var nødvendig i denne prosessen for å få dette til å fungere slik det skulle Forskjellige løsninger og ny læring I starten av prosjektet ble mye tid brukt til å se på forskjellige løsninger for vår oppgave, og dette ble videre utforsket etter hvert som prosjektet skred frem. Sammen med at vi har måttet lære mye nytt, har derfor programmeringen vært den delen vi har brukt desidert mest tid og resurser på under prosjektets gang Samarbeidet i gruppen Vi har i all hovedsak jobbet sammen, men har delt inn arbeidet mellom oss, der den enkelte har hatt sitt område å jobbe mot. Vi har utvekslet ideer og løsninger når noe har vært uklart. Å jobbe på denne måten har medført at alle gruppemedlemmene har fått en generell god oversikt over prosjektet, og vært nyttig når noen i gruppa har hatt et problem som andre i gruppa har kunnet svaret på Revisjonsverktøy Før vi påbegynte kodingen, diskuterte vi viktigheten av å få på plass et revisjonsverktøy. Og bestemte oss tidlig for å ta i bruk et slikt program, for å føre versjonskontroll over kode og for å holde en oversikt over hvem som jobbet på forskjellige deler av programmet. Det var også viktig for oss å vite at med et slikt Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 44

45 program ville sikkerheten være ivaretatt. Slik at tap av data ikke skulle kunne forekomme. 3.5 Testing Testingen av systemet deles inn i to deler. Den delen som omhandler testing underveis i prosessen i forbindelse med opprettelse av forskjellig funksjonalitet, og den delen som gjelder sluttesting der hele systemet blir grundig testet. Delene er beskrevet under Funksjonell testing Når nye programbiter ble opprettet, ble disse testet opp mot eksisterende kode, for å se at de fungerte sammen slik de skulle. Når implementering av disse funksjonene fungerte som de skulle, ble nye programbiter påbegynt. Fordelen med å teste systemets deler underveis, har gjort at vi har sluppet den store feilsøkingsjobben til slutt. Noe som kan være en stor og tidkrevende prosess, når programmet blir av en viss størrelse Sluttesting For å få luket ut så mange feil som mulig, var det viktig å ha en strukturert plan på hvordan sluttestingen skulle foregå. Det ble derfor opprettet et eget testdokument med beskrivelse av selve testingen som er gjort, der kriterier for hva som er testet og hvordan dette er utført med grundige forklaringer. 3.6 Avslutningsfasen Når testing av systemet var unnagjort, gjenstod det å lage en produktveiledning, klargjøring av øvrige dokumenter til endelig innlevering, samt alle de praktiske problemstillingene i forbindelse med sluttføring av hele oppgaven. De siste ukene av prosjektet har vært hektiske med å få avsluttet alle delene. Når det gjelder selve kildekoden, valgte vi å utelate den i selve papirutgaven av prosjektrapporten, dette fordi den ble svært omfattende og ville tatt opp alt for mange sider alene. Denne ble derfor kun tatt med på vedlagt cd. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 45

46 3.7 Dokumentering Vi bestemte oss tidlig for å starte arbeidet med dokumentering så tidlig som mulig, og ikke utsette dette til etter at produktet var ferdig. Det ble også påpekt av veileder som lurt å komme i gang med dokumentasjonen og å få på plass en grunnstruktur for alle dokumentene så tidlig som mulig. Vi var derfor relativt tidlig i gang med opprettelse av skjelett/rammeverk for diverse dokumenter, og begynte å skrive på disse etter hvert som vi kom på innhold vi ville ha med. Å gjennomføre dokumenteringen på denne måten, har medført at vi har hatt muligheten til å finpusse på teksten over tid, noe som igjen har ført til en bedre sluttdokumentasjon. Dokumentering av prosjektet har vært gjennomført igjennom hele prosjektperioden. Dokumentering av de ulike fasene i prosjektet har blitt utført gjennom dagbok. Å kunne gå tilbake og se hva som faktisk har blitt gjort til ulike tidspunkt har vært svært nyttig i forbindelse med opprettelse av blant annet dette dokumentet. Mange av dokumentene har blitt revidert flere ganger. Dette har det vært nødvendig å gjøre etter hvert som nye detaljer til oppgaven har kommet fram. Teksten har også blitt gjennomgått gang på gang, for å forsøke å få en bedre ordlyd av det vi ville uttrykke og for å få en bedre flyt og sammenheng. 3.8 Kompetansetilegning Siden mye av teknologien vi har brukt i prosjektet var ny for de fleste av oss i gruppa, var vi nødt til å bruke en del tid på å tilegne oss kunnskap om disse emnene før vi kunne ta fatt på selve oppgavene. Det ble satt av noen uker i starten av prosjektet til læring av teknologien og rammeverket vi skulle bruke. I desember var vi på et introduksjonskurs hos vår oppdragsgiver, der vi fikk en god innføring i den teknologien vi skulle bruke. Oppdragsgiver har også i løpet av prosjektperioden gitt oss diverse resurser og nødvendig materiale for å kunne sette oss inn i de respektive områdene vi skulle jobbe med. Parallelt med hovedprosjektet, hadde vi et kurs på høgskolen som gikk på C# og ASP.NET. Siden programmeringen i hovedprosjektet hovedsakelig er gjort i C#, har dette kurset kommet godt med under læring av denne teknologien. Høgskolen i Oslo Hovedprosjekt i data, 2007 Gruppe 2 Side 46