Software for Mobile Encryption

Transkript

1 Software for Mobile Encryption Kundestyrt Prosjekt Høsten 2003 Oppdragsgiver: Deriga AS Gruppe 20: Michael Sars Norum Jon Bendik Helland Åsmund Nordstoga Erik Østby Erlend Mongstad Tobias Melcher Torje Lundereng

2 Forord Denne prosjektrapporten inneholder dokumentasjon av arbeidet utført av gruppe 20 i faget TDT4290 Kundestyrt Prosjekt høsten Prosjektgruppen består av syv studenter i fjerde klasse, linjen for datateknikk ved Norges teknisk-naturvitenskapelige universitet. Prosjektet har vært utført på oppdrag fra Deriga AS. Prosjektets overordnede mål var å utvikle en plattform for sikker kommunikasjon fra en mobiltelefon til en tjenestetilbyder. Gruppen gjennomførte et forstudie hvor ulike teknologier og standarder for sikkerhet ble kartlagt samt at det ble tatt en beslutning om hvordan systemet skulle utvikles i grove trekk. Etter forstudiet ble kravene til systemet fastsatt i en kravspesifikasjon. Alle kravene i denne spesifikasjonen ble ikke oppfylt av ulike årsaker. Håpet er at kravene skal legge retningslinjer for videre utvikling av det leverte systemet. Etter at kravene var fastsatt, fulgte konstruksjonen og etterhvert også implementasjonen av selve systemet. Begge disse fasene er dokumentert i egne fasedokumenter. Prosjektets resultat ble et bibliotek for mobiltelefoner som tilbyr sikker kommunikasjon med en server samt et lignende bibliotek for eventuelle tjenestetilbydere. Både kunden og prosjektgruppen er fornøyd med det leverte resultatet. Ellers kan det nevnes at prosjektet har tilført gruppens medlemmer mye både i form av kunnskaper og ikke minst erfaring med gruppearbeid. Gruppen vil takke Nils Vold, vår kundekontakt, for god oppfølging gjennom prosjektet. En takk går også til Svein Knappskog ved ITEM, NTNU, for verdifulle innspill. Til sist ønsker vi å takke gruppens hovedveiledere Reidar Conradi og Thomas Østerlie samt hjelpeveileder Mona Sivertsen for god veiledning og verdifull oppfølging. Deler av denne prosjektrapporten er erklært konfidensiell av Deriga. Derfor vil utgaven som offentliggjøres på nettet bare inneholde 3 av de opprinnelige dokumentene; prosjektdirektivet, forstudiet og kravspesifikasjonen. Trondheim, tirsdag 11. november Michael Sars Norum Erlend Mongstad Jon Bendik Helland Tobias Melcher Åsmund Nordstoga Erik Østby Torje Lundereng i

3 Om leveransen I tillegg til selve prosjektrapporten leveres en cd som innholder pdf-filer av de ulike fasedokumentene samt koden som er nødvendig for å sette opp det utviklede systemet. Deler av prosjektrapporten offentliggjøres på IDI s hjemmesider som en pdf-fil. Konstruksjonsdokumentet og implementasjonsdokumentet er konfidensielle og dermed utelatt i denne offentlige rapporten etter ønske fra kunden. ii

4 Innhold Prosjektrapporten inneholder følgende dokumenter: Prosjektdirektiv Forstudie Kravspesifikasjon Konstruksjon, blir ikke offentliggjort på nett. Implementasjon, blir ikke offentliggjort på nett. Installasjonsveiledning, blir ikke offentliggjort på nett. Brukerveiledning, blir ikke offentliggjort på nett. Testdokumentasjon og resultater, blir ikke offentliggjort på nett. Prosjektevaluering, blir ikke offentliggjort på nett. iii

5 Prosjektdirektiv Gruppe november 2003

6 Innhold 1 Innledning Formål Oversikt Prosjektmandat Prosjektnavn Oppdragsgiver Interessenter Bakgrunn Effektmål Resultatmål Omfang Rammebetingelser Tilgjengelighet av ressurser Krav fra kunde Økonomi Tid Prosjektplan Faser Forelesninger og egenlæring Prosjektledelse Planlegging Forstudium Testing Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Konstruksjon Programmering og dokumentasjon Prosjektvurdering i

7 INNHOLD Presentasjon Fremdriftsplan Organisering Ansvarsfordeling Prosjektleder Kundekontakt Drifter Testansvarlig Dokumentansvarlig BSCW-ansvarlig Maler og standarder Møteinnkallelser Møtereferater Statusrapporter Statusrapporter Fasedokumenter Versjonskontroll Basic Support for Cooperative Work (BSCW) Concurrent Versions System (CVS) Prosjektoppfølging Prosjektmøter Internrapportering Statusrapporter Risikohåndtering Kvalitetssikring Responstider Kvalitet ved første forsøk Godkjenning av fasedokumenter Overordnet testplan Testfaser Modultesting Systemtesting Akseptanstesting Tidsplan ii

8 INNHOLD A Interessenter 32 A.0.1 Gruppens medlemmer A.0.2 Kunde A.0.3 Veiledere B Katalogstruktur og navngiving av filer 34 B.1 Katalogstruktur B.2 Navngiving på filer iii

9 Figurer 3.1 Ganttdiagram Mal for møteinnkallelse Mal for møtereferat Mal for statusrapport Mal for timeoppfølgingsskjema V-modellen for testing iv

10 Tabeller 3.2 Planlagt tidsforbruk Organisering Møtetider Risikotabell Risikotabell v

11 Kapittel 1 Innledning Dette dokumentet er det innledende dokumentet for gruppe 20 i Kundestyrt Prosjekt høsten Dette dokumentet er ment å være et dynamisk dokument som kan endres på gjennom hele prosjektet. Det regulerer den administrative delen av prosjektet og legger føringer for prosjektgjennomføringen. Dokumentet er skrevet på bakgrunn av det eksempelet som er gitt i infoheftet tilhørende faget Kundestyrt Prosjekt høsten 2003 [3]. 1.1 Formål Prosjektdirektivet er ment som et oppslagsverk som kan brukes av gruppemedlemmene under prosjektperioden. Det skal ikke være et uforanderlig, statisk dokument. Meningen er at det skal endres og oppdateres fortløpende under prosjektperioden. Dermed beholder det sin verdi helt frem til prosjektslutt. Dokumentet beskriver prosjektets rammevilkår og målsetning. Alle de rutiner man er enige om i gruppa beskrives. 1.2 Oversikt I kapittel 2 presenteres prosjektmandatet. Her vil vi ta med en del overordnet informasjon om prosjektet. Blant annet er effekt- og resultatmålene med her. I kapittel 3 beskrives de ulike fasene vi har satt opp i prosjektet. Spesielt kan en merke seg her at vi har som mål å utføre konstruksjon og implementasjon i to inkrementer. Fremdriftsplan og Ganttdiagram tas også med her. I kapittel 4 utdypes ansvarsfordelingen innad i prosjektet. De neste to kapitlene, 5 og 6, beskrives de malene og standardene som benyttes i prosjektet. I tillegg kommenterer vi hvordan vi skal holde orden på alt det vi produserer av kode og dokumenter. I kapittel 7 blir all rapportering forklart. Det gjelder 1

12 Kapittel 1. Innledning både internt i gruppen og til veilederne. Risikotabellen tas i slutten av dette kapitlet. I kapittel 8 presenterer vi de virkemidlene vi trenger for å sikre en tilfredstillende gjennomføring av prosjektet. Til slutt, i kapittel 9 har vi laget en overordnet beskrivelse av testplanen vi har planlagt å utføre. 2

13 Kapittel 2 Prosjektmandat Prosjektmandatet inneholder informasjon om prosjektets navn, rammebetingelser, mål og krav. 2.1 Prosjektnavn Oppgavens tittel er System for sikker kommunikasjon mellom mobiltelefon og server. Prosjektets navn er Software for Mobile Encryption, forkortet til SME. 2.2 Oppdragsgiver Gruppen har kontakt med Deriga AS gjennom daglig leder Nils Vold. Kontaktinformasjon kan finnes i vedlegg A. Deriga AS arbeider med utvikling av et rammeverk for sikker kommunikasjon og sikker utveksling av informasjon. Bedriften ble etablert i mai 2001 og har i dag 8 ansatte. Bedriftens hovedvekt av kunder er i helsesektoren. 2.3 Interessenter Liste over interessenter er gitt i vedlegg A. 2.4 Bakgrunn Deriga AS har utviklet et rammeverk, Secure Information Interchange (SII), som skal underbygge sikker informasjonsutveksling fra for eksempel personlige datamaskiner i forbindelse med timebestilling hos lege og lignende. For 3

14 Kapittel 2. Prosjektmandat å kunne øke tilgjengeligheten av sine tjenester ønsker Deriga AS å utvikle en løsning der også mobile enheter kan kommunisere med SII på en tilfredsstillende måte. Denne kommunikasjonen skal være sikker Deriga ønsker seg en løsning der Java benyttes for å sikre den informasjonen som sendes. En Java-løsning vil være plattform uavhengig. 2.5 Effektmål Følgende effektmål kan settes opp: EFF1 Tilgjengeligheten av Deriga AS sine systemer skal økes. EFF2 Tilliten til mobile tjenester skal styrkes fra starten av. EFF3 Deriga AS skal kunne tilby nye tjenester. 2.6 Resultatmål De resultatmålene som er gitt for dette prosjektet er: RES1 Prosjektet skal levere et rammeverk for sikker kommunikasjon mellom mobiltelefoner og servere. RES2 Prosjektet skal levere en applikasjon for å demonstrere funksjonaliteten bygget inn i rammeverket vi bygger. RES3 Prosjektet skal undersøke og finne de alternative løsningene som finnes. 2.7 Omfang Prosjektet avgrenses av følgende aspekter: Krypteringsrammeverket skal kjøres på mobiltelefoner og må derfor nytte den mest brukte versjonen av Sun s Java 2 Micro Edition (J2ME) som finnes på dagens telefoner. På grunn av mobiltelefoners begrensede lagringskapasitet skal krypteringsrammeverket ikke være større en 30kB. Dette vil begrense hvilke løsninger som er tilfredsstillende. 4

15 Kapittel 2. Prosjektmandat 2.8 Rammebetingelser Prosjektet er basert på de rammebetingelser som er beskrevet i underkapitlene og 2.8.2: Tilgjengelighet av ressurser Alle IDIs ressurser stilles til gruppens rådighet, inkludert: En PC, som gruppen selv kan administrere. Et møterom (ITV142) gruppen disponerer hver mandag fra 9.15 til I tillegg kan alle IDIs datasaler og møterom nyttes ved behov dersom de er ledige Krav fra kunde Kunden stiller følgende krav til løsningen: Løsningen skal ikke være større en 30kB i størrelse. Løsningen skal kjøre på J2ME versjon 1.04.X. Løsningen skal inneholde en testapplikasjon. Systemet skal leveres elektronisk og kunne kjøres på en håndholdt enhet. Kode og kommentarer skal være på engelsk. 2.9 Økonomi Eneste økonomiske målebegreper gruppen opererer med er timeantall. Gruppen består av syv personer som hver skal jobbe 24 timer i uken. Dette gir et totalt timeantall på 2184 timer. Kunden stiller 5000 NOK til gruppens rådighet for innkjøp av mobiltelefon og abonnement for testing av sluttproduktet. Deriga AS vil stå for selve innkjøpet etter at gruppen har meldt inn sine behov. 5

16 Kapittel 2. Prosjektmandat 2.10 Tid Prosjektet er begrenset i tid. Prosjektets levetid er fra til

17 Kapittel 3 Prosjektplan I dette kapitlet beskriver vi en plan for hvordan prosjektet skal gjennomføres. Det vil si hvilke faser som skal gjennomføres og hvilke milepæler vi har satt oss. 3.1 Faser Vi velger å bruke en inkrementell modell for prosjektarbeidet fordi vi mener det passer best til prosjektets natur. Prosjektet er komplisert og har et strengt krav til størrelse. Derfor blir det naturlig å prøve seg fram i inkrementer på veien mot et ferdig produkt. Inkrement 1 Testapplikasjonen ferdigstilles. Støtte for kryptering av meldinger. Serverapplikasjonen bygges opp med nødvendig funksjonalitet for å sende og motta krypterte meldinger fra en håndholdt enhet. Dette inkrementet skal gi oss en pekepinn på hvordan vi ligger ann plassmessig, slik at vi dermed unngår å bruke for mye plass til applikasjonen på mobilen. Inkrement 2 Krypteringen utvides. Her ønsker vi å få utvidet sikkerhetsaspektet i applikasjonen på mobilen til å nærme seg en PKI-struktur. Vi vil nok legge mest vekt på planlegging og forstudium i begynnelsen av prosjektperioden. Prosjektledelse, forelesninger og egenlæring vil vi bruke tid på gjennom hele prosjektperioden. 7

18 Kapittel 3. Prosjektplan Forelesninger og egenlæring Denne oppgaven strekker seg over hele prosjektperioden med størst vekt på forelesninger i første halvdel av perioden Prosjektledelse Denne oppgaven strekker seg også over hele prosjektperioden. Koordinering av gruppen og møtevirksomheten er hovedoppgavene her Planlegging I denne fasen vil vi planlegge det videre prosjektarbeidet. Vi lager et prosjektdirektiv som danner grunnlaget for gjennomføringen av resten av prosjektet og for samarbeidet med kunden. Vi antar at planleggingen vil bli mer detaljert underveis i prosjektet og for de forskjellige fasene. Oppgaver Disse oppgavene må utføres i planleggingsfasen: Utforme maler og standarder for prosjektet. Utforme prosjektdirektiv. Etablere rutiner for møtevirksomhet, timeregistrering og fordeling av roller i gruppen Forstudium I dette prosjektet beregner vi litt mer tid på forstudium enn det som er normalt fordi det er av en relativt høy kompleksitet. I forstudiet skal vi sette oss inn i alt faglig stoff som er relevant for oppgaven. Det gjelder for eksempel J2ME og krypteringsalgoritmer som RSA og 3DES. Vi fordeler stoffet og skriver sammendrag av det. Disse sammendragene havner i sluttrapporten. Oppgaver Disse oppgavene må utføres i forstudiet: Beskrive hva som finnes av relevant teknologi i dag (AS IS). Beskrive oppgaven vi skal utføre. 8

19 Kapittel 3. Prosjektplan Utrede alternative løsninger(to BE). Studere faglig relevante emner og skrive sammendrag av disse Testing Denne fasen er spesiell, da den går parallelt med kravspesifikasjon og konstruksjon, og vil også i stor grad være en integrert del av implementeringen. Vi har derfor valgt å ikke skille testing ut som en egen fase i tidsplanen. Tid brukt på testing vil føres som en del av tiden brukt på fasene som er nevnt ovenfor. Oppgaver Disse oppgavene må utføres i løpet av testingen: Lage alle relevante testspesifikasjoner. Utføre testene når de relevante moduler er ferdig programmerte. Plassere resultatet av testene i et eget testdokument Kravspesifikasjon Her må vi spesifisere alle krav som systemet skal oppfylle. Inkludert i kravspesifikasjonen er kravene til første og andre inkrement i prosjektet. Oppgaver Disse oppgavene må utføres i kravspesifikasjonen: Kartlegge de funksjonelle kravene. Kartlegge de ikke-funksjonelle kravene Konstruksjon1 Under konstruksjonen skal vi velge en konkret programvarearkitektur. Vi må derfor vurdere ulike alternativer opp mot hverandre. Disse alternativene vil komme frem på bakgrunn av arbeidet i forstudiet. 9

20 Kapittel 3. Prosjektplan Oppgaver Disse oppgavene må utføres i konstruksjon 1: Velge en konkret arkitektur for systemet. Det vil si å velge hvilke moduler og klasser systemet skal bestå av. Avklare hvilket grensesnitt (interface) de ulike modulene skal ha. Lage diagrammer som UML og lignende til den valgte arkitekturen Programmering og dokumentasjon 1 I denne delen skal systemet programmeres i henhold til konstruksjonsplanen utviklet i fasen konstruksjon 1. Oppgaver Disse oppgavene må utføres: Programmere de moduler som ble valgt i konstruksjon 1. Dokumentere all kode Konstruksjon2 Under konstrukskjon 2 skal vi utvide systemet fra det som ble konstruert i forrige konstruksjonsfase. Håpet er å få et sikrere system enn i det første inkrementet. Oppgaver Disse oppgavene må utføres i konstruksjon 2: Utvide arkitekturen fra inkrement 1. Lage diagrammer som UML og lignende til den valgte arkitekturen Programmering og dokumentasjon 2 Her programmerer vi de utvidelsene og endringen som er beskrevet i konstruksjon 2. Vi bygger videre på koden fra det første inkrementet. 10

21 Kapittel 3. Prosjektplan Oppgaver Disse oppgavene må utføres: Programmere de moduler som ble valgt i konstruksjon 2. Få det til å fungere i tillegg til funksjonene fra det første inkrementet. Dokumentere all kode Prosjektvurdering Prosjektet evalueres av gruppemedlemmene i fellesskap. Alle erfaringer skal frem, både positive og negative. Følgende momenter skal evalueres: Gruppeprosessen: hvordan har samarbeidet fungert innad i gruppa? Resultatet: har vi nådd de mål vi hadde for prosjektet? Hvordan har samarbeidet med kunden fungert? Hvordan har vi likt faget, og hvordan har samarbeidet med veileder vært? Presentasjon Systemet skal presenteres for representanter fra fakultetet og Deriga. Oppgaver Disse oppgavene må utføres i presentasjonen: Prøve ut presentasjonen på forhånd, ikke bruke for mye grafikk. Gjennomføre presentasjonen. 3.2 Fremdriftsplan Her er et foreløpig forslag til milepæler gruppen har satt seg: Ferdig prosjektdirektiv 3/9 Ferdig forstudium 29/9 Ferdig kravspesifikasjon 10/10 Ferdig inkrement 1 22/10 11

22 Kapittel 3. Prosjektplan Ferdig inkrement 2 4/11 Ferdig prosjektvurdering 6/11 Presentasjon og demo 13/11 Tabell 3.2 viser et foreløpig anslag over tidsforbruk i prosjektet. Det er en viss usikkerhet når det gjelder antall timer som er beregnet. Faser Tidsforbruk Sluttdato % av arbeid (timer) Prosjektledelse Forelesninger og egenlæring Planlegging Forstudium Kravspesifikasjon Konstruksjon inkrement Programmering, dokumentasjon og testing inkrement 1 Konstruksjon inkrement Programmering, dokumentasjon og testing inkrement 2 Prosjektvurdering Presentasjon og demo Totalt Tabell 3.2: Planlagt tidsforbruk Ganttdiagrammet i figur 3.1 på side 13 beskriver fremdriften i prosjektet grafisk. Den viser hvilket tidsrom de ulike fasene strekker seg over. 12

23 Kapittel 3. Prosjektplan Figur 3.1: Ganttdiagram 13

24 Kapittel 4 Organisering Gruppen har valgt å organisere seg som beskrevet i tabell 4.1. Ansvarsområdene for hver rolle er beskrevet i underkapitlene 4.1 til Rolle Prosjektleder Kundekontakt/Drifter Drifter Testansvarlig Dokumentansvarlig BSCW-ansvarlig Navn Michael Torje Tobias Åsmund Jon Bendik Erlend Tabell 4.1: Organisering 4.1 Ansvarsfordeling De forskjellige rollene er tildelt forskjellig ansvar. Riktignok er det overordnede ansvaret for sluttproduktet og fasedokumentene gruppens ansvar i fellesskap, men for å få kabalen til å gå opp er det noen som får hovedansvaret for enkelte aktiviter Prosjektleder Prosjektleder har ansvaret for å sende ut møteinnkallelser. Fremdriften i prosjektet følges opp med timerapportering og skriving av statusrapporter. 14

25 Kapittel 4. Organisering Kundekontakt Kundekontakten har som ansvar å være gruppens bindeledd til vår kontakt hos kunden. Dette for at det skal bli enklere for kunden å forholde seg til informasjon fra oss, samt enklere for oss å få tak i kunden Drifter Driftsjobben går ut på å sørge for at den maskinen gruppen får stilt til rådighet fra instituttet for datateknikk og informasjonsvitenskap (IDI) er operativ og har de rette programmene installert. I tillegg må drifteren ta backup av kildekode og dokumenter som ligger på serveren og sørge for at de rette personene har tilstrekkelige rettigheter på maskinen Testansvarlig Testansvarlig har ansvaret for at testplanen blir skrevet og at testene blir gjennomført og oppsummert i henhold til testplanen og gruppens bestemmelser Dokumentansvarlig Dokumentansvarlig skal sørge for at nødvendig kvalitetssikring av dokumentene blir gjennomført BSCW-ansvarlig BSCW-ansvarlig har ansvaret for at nødvendig orden opprettholdes på gruppens BSCW-område samt at alle gruppens medlemmer har tilgang på området. 15

26 Kapittel 5 Maler og standarder Gruppen har utarbeidet egne maler for følgende dokumenter: Møteinnkallelser Møtereferat Statusrapporter Timeoppfølgingsskjema Fasedokumenter 5.1 Møteinnkallelser Møteinnkallelser skrives i Word og distribueres i pdf-format. Dette for å unngå kompatibilitetsproblemer siden medlemmene på gruppen benytter seg av ulike plattformer. Malen for møteinnkallelser er gjengitt i figur 5.1. Enkelte saker går igjen på hvert møte. Disse sakene er tatt med i malen. Dette gjelder Godkjenning av innkalling og referat, Valg av referent, Eventuelt og Kritikk av møtet. 5.2 Møtereferater Møtereferater skrives i Word og distribueres i rtf-format. Malen for møtereferater er gjengitt i figur

27 Kapittel 5. Maler og standarder 5.3 Statusrapporter Figur 5.1: Mal for møteinnkallelse. Statusrapporter skrives i Word. Malen for statusrapporter er gjengitt i figur Statusrapporter Timeoppfølgingsskjema skrives i Excel og distribueres i pdf-format. Malen for timeoppfølgingsskjema er gjengitt i figur Fasedokumenter For fasedokumentene benyttes L A TEX sin innebygde report-mal. De ulike fasedokumentene er ganske forskjellige i innhold, men i strukturen er det en del likheter. Hvis det faller naturlig, legges det inn et sammendrag i starten av et fasedokument. Sammendraget inneholder den viktigste informasjonen fra fasedokumentet, og gjør leseren i stand til å vurdere om dokumentet er verdt å lese eller ikke. Sammendraget etterfølges av en innledning. Innledningen forklarer hensikten med dokumentet. Til slutt i et fasedokument kommer gjerne diverse tillegg. Tilleggene er typisk informasjon som noen lesere er interessert i, men som ikke er helt nødvendig å lese. 17

28 Kapittel 5. Maler og standarder Figur 5.2: Mal for møtereferat. I små dokumenter er strukturen forenklet i forhold til det som står beskrevet her. 18

29 Kapittel 5. Maler og standarder Figur 5.3: Mal for statusrapport. 19

30 Kapittel 5. Maler og standarder Figur 5.4: Mal for timeoppfølgingsskjema. 20

31 Kapittel 6 Versjonskontroll 6.1 Basic Support for Cooperative Work (BSCW) BSCW er et system som muliggjør samarbeid over internett. Det er et delt arbeidsområde som støtter deling av dokumenter, gruppeplanlegging, varsling av hendelser med mer [1]. Gruppen benytter IDI sin BSCW-server som finnes på idi.ntnu.no. Denne benyttes for deling av møteinnkallelser, møtereferater og statusrapporter. Alle dokumenter skal legges på fellesområdet hver gang det er gjort endringer på dem for at gruppens resterende medlemmer skal ha tilgang på nyeste versjon til enhver tid. Før man laster opp et dokument på BSCW må man kontrollere at man ikke overskriver noen andres endringer. Dokumentene vil aldri låses, men dersom to personer jobber på den samme filen må dette koordineres mellom de som deltar i arbeidet. I tillegg benyttes BSCW sin versjonskontroll for å synligjøre at det har blitt gjort endringer. Dokumentene i BSCW låses ikke fordi det vil kunne hindre gruppemedlemmer i å gjøre arbeidet sitt ved at de ikke får tilgang på låste dokumenter de trenger. BSCW er ikke noe effektivt verktøy når det jobbes på mange dokumenter. Derfor vil det settes opp en CVS-server som tar seg av versjonskontrollen for de ulike fasedokumentene. Se tillegg B for en oversikt over hvordan filene lagres i BSCW og hvilke filnavn som skal brukes. 21

32 Kapittel 6. Versjonskontroll 6.2 Concurrent Versions System (CVS) CVS er et klient/tjener-system med god versjonskontroll, som blant annet gjør det enkelt å gå tilbake til en tidligere versjon. Det har også endringskontroll som muliggjør at to personer kan skrive på den samme filen til samme tid, og likevel unngå at de overskriver hverandres endringer [2]. CVS benyttes for kode og fasedokumenter. Det skal derfor etterhvert settes opp en CVS-server der alle på gruppen vil få tilgang. Inntil videre vil BSCW benyttes også for deling av fasedokumenter. 22

33 Kapittel 7 Prosjektoppfølging For å passe på at prosjektet blir gjennomført på best mulig måte har vi satt opp en del faste møtetider og prosedyrer. 7.1 Prosjektmøter Gruppen har satt opp faste møtetider som spesifisert i tabell 7.1. Utover dette har gruppen ofte et koordineringsmøte på torsdager før veiledermøtet. Dag Tid Sted Type Mandag ITV-142 Internmøte Torsdag ITV-242 Veiledermøte Tabell 7.1: Møtetider 7.2 Internrapportering Gruppens medlemmer rapporterer timer gjennom et webgrensesnitt. Rapporteringssystemet finnes ved å logge seg på adressen: cjb.net/login.php. Det som registreres er timer jobbet for hver kategori for hver dato. Dette gjør det enkelt å rapportere timene til prosjektleder. Det blir også lett for prosjektleder å regne ut faktisk timeforbruk i forhold til det som er budsjettert. 23

34 Kapittel 7. Prosjektoppfølging 7.3 Statusrapporter Hver uke skriver prosjektleder en statusrapport til hovedveileder. Denne blir gjort tilgjengelig for alle gruppens medlemmer på BSCW. Statusrapporten oppsummerer uken som har gått ved å omtale oppnådde og ikke oppnådde milepæler og delmål. Den omtaler også status på de forskjellige fasedokumentene samt timeregnskap for gruppen som helhet. 7.4 Risikohåndtering I forbindelse med prosjektet er mulige risikoer, deres sannsynlighet, konsekvens og mottiltak kartlagt. Resultatet finnes i tabell

35 Kapittel 7. Prosjektoppfølging Nr Aktivitet Risiko S Konsekvens S Tiltak Tidsfrist Ansvarlig Kont. MSN 1 Alle Sykdom M Mer belastning for resten av gruppen 2 Alle Interne stridigheter 3 Alle Tekniske problemer 4 Alle, men først og fremst forstudium og kravspec Kundeproblemer 5 Alle Fritidsaktiviteter 6 Alle Manglende ferdigheter H Stridigheter kan forringe enkeltpersoners innsats og gruppens motivasjon H Tap av dokumenter, kildekode eller annet M Gruppen og kunde kommer ikke til enighet om beslutninger M Oppgaver blir ikke ferdigstilt til avtalt tid M Gruppen får ikke til oppgavene sine H Kommunikasjon, overføring av arbeidsoppgaver M Spilleregler, høflighet, aksept og respekt Kont. Alle M Backup-rutiner Kont. TM, TL M Sørge for åpen og god dialog med kunde H Kommunikasjon Tidlig, Kont Kont. TL. MSN Alle L Egenlæring Kont. Alle Tabell 7.2: Risikotabell. Forklaring: L=Liten, M=Middels, H=Høy, S=Sannsynlighet. 25

36 Kapittel 7. Prosjektoppfølging Nr Aktivitet Risiko S Konsekvens S Tiltak Tidsfrist Ansvarlig Kont. Alle 7 Alle Manglende konsistens mellom resultater 8 Møter Manglende møteinnkallinger eller bakgrunnsdokumenter 9 Programmering Plattform programvare fungerer ikke som den skal M Dokumenter gir ufullstendig eller uriktig informasjon. Ingen har full oversikt M Møtene blir ustrukturerte og ineffektive H Prosjektets fremdrift stagnerer inntil problemet er utbedret M Kvalitetssikring, korrekturlesing, kommunikasjon M Presise avtaler, kommunikasjon M Teste ut programvare underveis og sjekke at ting fungerer som det skal i god tid før det tas i bruk Kont. MSN/ Alle Slutten på kravspec TM, TL Tabell 7.3: Risikotabell. Forklaring: L=Liten, M=Middels, H=Høy, S=Sannsynlighet. 26

37 Kapittel 8 Kvalitetssikring For å sikre kvaliteten på arbeidet og resultatet er det foreslått en del punkter. 8.1 Responstider Det er satt en rekke frister i forbindelse med prosjektarbeidet: Møtereferater skal være ute senest klokken dagen etter møtet. Sakspapirer og innkalling til veildedermøtet skal være levert inn til veiledere senest klokken dagen før møtet. Møteinnkallinger til interne møter skal være ute senest klokken dagen før møtet. Det er også satt opp en del krav til kunden: Tilbakemelding på fasedokumenter skal gis senest etter 48 timer dersom dette er påkrevd. Spørsmål skal besvares innen 24 timer. Avtalte dokumenter skal skaffes til veie innen 24 timer. 8.2 Kvalitet ved første forsøk For å kvalitetssikre arbeidet underveis er det viktig at flere på gruppa leser gjennom dokumentene underveis for å sikre kvaliteten på det som skrives. Dette gjelder både rettskriving, språklig oppbygging og layout. 27

38 Kapittel 8. Kvalitetssikring 8.3 Godkjenning av fasedokumenter Alle fasedokumenter skal godkjennes på gruppens ukentlige møter. Før godkjenning skal alle på gruppen ha lest og være inneforstått med det gjeldende dokumentets innhold. Ingen fasedokumenter godkjennes før veilederne er fornøyde. Dokumenter renleses av dokumentansvarlig på oppfordring fra forfatteren av dokumentet. Alle dokumenter skal renleses så snart de er ferdig skrevet. Dokumenter kan også sendes til hjelpeveileder Mona for faglige tips. 28

39 Kapittel 9 Overordnet testplan I dette delkapitlet følger en overordnet beskrivelse av testplanen for prosjektet. Testplanen består av framgangsmåte for testingen, samt en teststrategi. I de forskjellige fasene i prosjektet vil det være behov for varierende metoder for verifisering og validering. Disse vil bli nevnt i et eget testdokument. Vi vil her kun nevne forskjellige testbehov i henholdsvis kravspesifikasjons-, konstruksjons- og implementeringsfasene, samt en overordnet tidsplan for testingen. Vi deler testingen inn i 3 hovedfaser, modultest, systemtest og akseptansetest, inspirert av v-modellen for testing hvor testingen foregår parallelt med utviklings-fasene 9.1. For mer informasjon om testingen og de forskjellige testfasene henviser vi til testdokumentet. Figur 9.1: V-modellen for testing 29