Prosjektrapport. Gruppe 18. Magnus Solberg Kristoffer Jacobsen Harald Ueland Lisa Wold Eriksen Frode Hjeltnes

Transkript

1 Prosjektrapport Gruppe 18 Magnus Solberg Kristoffer Jacobsen Harald Ueland Lisa Wold Eriksen Frode Hjeltnes TDT4290 Kundestyrt prosjekt 2003, Institutt for datateknikk og informasjonsvitenskap, Fakultet for informasjonsteknologi, matematikk og elektronikk

2

3 Forord Forord Denne prosjektrapporten er laget i forbindelse med faget TDT4290 Kundestyrt Prosjekt høsten Vårt prosjekt har vært å lage et statistisk system for behandling av data knyttet til avisproduksjon, for studentavisa Under Dusken. Vi vil spesielt takke våre veiledere for god veiledning. Hjelpeveileder Mona Sivertsen har vært til stor hjelp med sin nøye gjennomgang av de ulike dokumentene, mens hovedveileder Ola Stenseth har gitt gode og konstruktive tilbakemeldinger på arbeidet som helhet. Vi vil også takke kunderepresentant Eirik Bjørsnøs for et godt samarbeid. Han har vært til stor hjelp og har vært lett tilgjengelig gjennom hele prosjektperioden. Til slutt vil vi takke kjærester, familie og venner for stor tålmodighet i en stresset periode. Trondheim, 11. november Magnus Solberg Kristoffer Jacobsen Harald Ueland Lisa Wold Eriksen Frode Hjeltnes TDT4290 Kundestyrt prosjekt - Gruppe 18

4

5 Innhold Innhold :: Prosjektdirektiv :: Forstudie :: Kravspesifikasjon :: Konstruksjon :: Implementasjon :: Testdokument :: Documentation :: Evaluering :: Ordliste TDT4290 Kundestyrt prosjekt - Gruppe 18

6

7 :Prosjektdirektiv Gruppe 18 Magnus Solberg Kristoffer Jacobsen Harald Ueland Lisa Wold Eriksen Frode Hjeltnes TDT4290 Kundestyrt prosjekt 2003, Institutt for datateknikk og informasjonsvitenskap, Fakultet for informasjonsteknologi, matematikk og elektronikk

8

9 Prosjektdirektiv Sammendrag Prosjektdirektivet er første faseleveranse av faget TDT Kundestyrt Prosjekt ved 4. klasse Datateknikk ved NTNU. Dokumentet er laget for å koordinere prosjektforløpet for prosjektet StatSys når det gjelder oppgave-, tids- og organisasjonsmessige aspekter. Prosjektets kunde, Under Dusken, er en studentavis som er tilknyttet Studentersamfundet i Trondheim. Dette innebærer at alle avisens medarbeidere er ansatt på frivillig basis. Med utgangspunkt i en rapport fra faget Kundestyrt prosjekt i 1997, startet utviklingen av et redaksjonelt system til bruk internt i avisen. Produktet som idag går under navnet Redsys, er under kontinuerlig utvikling av avisens dataavdeling, og planlegges å distribueres som open source til neste år. I prosessen med å utvikle Redsys har det også dukket opp et ønske om å lage et statistisk system for å kunne få en oversikt over hvordan arbeidet i produksjonssyklusen forløper, og hvordan de ansatte bruker det redaksjonelle systemet. Gruppen er organisert i ulike roller: prosjektleder, test- og visesjef, koordinator, dokumentansvarlig og teknisk ansvarlig. Maler og standarder for møtereferat, interne og eksterne statusrapporter og øvrige fasedokumenter er utarbeidet, og hvert gruppemedlem er ansvarlig for å levere dokumenter i henhold til disse. Gruppeverktøyet BSCW brukes til dokumenthåndtering innad i prosjektgruppen, og en intern katalogstruktur er utarbeidet for organisering av gruppens dokumentleveranser. TDT4290 Kundestyrt prosjekt - Gruppe 18

10

11 Prosjektdirektiv Innholdsfortegnelse Innledning Prosjektmandat Prosjektnavn Prosjektsponsor Interessenter Bakgrunn for prosjektet Effektmål Resultatmål Prosjektets omfang Rammebetingelser Økonomi Tid Prosjektplan Vannfallsmodellen Faser og aktiviteter Planlegging Forstudie Kravspesifikasjon Kontruksjon Programmering og dokumentasjon Evaluering Presentasjon Hovedansvarlige Milepæler - leveranser Timer per aktivitet og fase + forelesninger + prosjektledelse Organisasjon Roller Rollenes oppgaver Prosjektleder Test- og visesjef Koordinator Dokumentansvarlig Teknisk ansvarlig Referent Maler og standarder Maler Dokumentorganisering Katalogstruktur Filstruktur Tekststandard Versjonskontroll BSCW CVS Prosjektoppfølging Møteplan Organisering Intern timerapportering Statusrapportering Risikohåndtering / TROKK TDT4290 Kundestyrt prosjekt - Gruppe 18

12 Prosjektdirektiv 6.6 Konflikthåndtering Kvalitetssikring Interne retningslinjer Retningslinjer ovenfor veileder Retningslinjer ovenfor kunden Testplan Innledning Tester som skal gjennomføres Tester for utviklerne Tester for brukerne Testing av krav Hvordan testene skal gjennomføres Sjekklister Testspesifikasjoner Black box og White box testing Nødvendig testdata Ansvarsfordeling for utvikling av tester Ansvarsfordeling for gjennomføring av tester Hvem gjennomfører testene Hvem godkjenner testene Evaluering av testene Klassifisering av feil Rutiner for håndtering av feil Rutiner for testrapportering Godkjenningskriterier Tidsplan for testing Vedlegg A: Interessenter A.1 Prosjektgruppa A.2 Kunderepresentanter A.3 Veiledere Vedlegg B: Detaljerte fasedokumenter B.1 Prosjektdirektiv B.2 Forstudie B.3 Kravspesifikasjon B.4 Konstruksjon B.5 Implementasjon B.6 Documentation B.7 Evaluering Vedlegg C: Gantt-diagram Vedlegg D: Maler D.1 Møtereferat D.2 Møteinnkalling D.3 Statusrapport internt D.4 Statusrapport eksternt D.5 Intern timerapportering Vedlegg E: Dataflytdiagram fasedokument TDT4290 Kundestyrt prosjekt - Gruppe 18

13 Prosjektdirektiv Tabeller 1. Hovedansvarlige Leveranser Timefordeling Rollefordeling Tekststandard for dokumentskriving Faste møter hver uke Veiledermøter Utdrag av risikotabell TDT4290 Kundestyrt prosjekt - Gruppe 18

14 Prosjektdirektiv Figurer 1. Vannfallsmodellen Aktiviteter Organisasjonskart Katalogstruktur BSCW Gantt-diagram Mal for intern timerapportering Utarbeidelse av fasedokument TDT4290 Kundestyrt prosjekt - Gruppe 18

15 Prosjektdirektiv Innledning Prosjektdirektivets formål er å danne en ramme rundt prosjektarbeidet som gruppa skal gjennomføre. Utover dette skal prosjektdirektivet fungere som et oppslagsverk for det videre prosjektarbeidet for gruppas medlemmer, kunde og veiledere gjennom at all relevant informasjon for prosjektet skal ligge samlet her. Vårt prosjekt er å lage et program for å generere artikkelstatistikk for studentavisa Under Dusken. Prosjektet skal avsluttes 13. november med en skriftlig innlevering og presentasjon av prosjektet. Prosjektdirektivet inneholder følgende kapitler: Prosjektmandat Dette er en beskrivelse av prosjektets konkrete data. Dette er bakgrunnen for prosjektet, prosjektets sponsor, målsettingen, rammebetingelsene, økonomien og tidsrammen prosjektet har å jobbe ut i fra. Prosjektplan Her angis i hovedsak den overordnede planen for prosjektet i form av milepæler, tidsforbruk, de ulike fasene og hvilke aktiviteter prosjektet innebærer. Maler og standarder Denne delen av prosjektdirektivet presenterer hvilke standarder gruppa har valgt å bruke for å skrive rapporten, hvordan filstrukturen er oppdelt på BSCW og hvilken standard som brukes for filnavngivning. Versjonskontroll Under versjonskontroll beskrives prosjektets måter å sikre versjonskontroll og en kort presentasjon av hvordan dette løses i valgte verktøy CVS og BSCW. Prosjektoppfølging Her beskrives hvordan prosjektet følges opp gjennom møtetider, status- og timerapportering og konflikt- og risikohåndtering. Kvalitetssikring Dette kapitlet tar for seg alle interne rutiner og retningslinjer. Her er det delt opp i retningslinjer internt, mot veiledere og overfor kunden. Testplan Testplan-kapitlet beskriver hvordan systemet i hovedsak skal testes. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 1 av 34

16 Prosjektdirektiv 1. Prosjektmandat Prosjektmandatet skal gi en kort og god oversikt over bakgrunnen for prosjektet, dets mål og hvilke rammebetingelser som ligger til grunn for prosjektet. 1.1 Prosjektnavn Prosjektet heter StatSys - Statistisk System. 1.2 Prosjektsponsor Under Dusken representert ved Eirik Bjørsnøs er oppdragsgiver for prosjektet. Han er med i dataavdelingen og har vært med på utviklingen av publiseringsverktøyet Redsys. Under Dusken er den eldste nålevende studentavisen i Norge. Den blir drevet av frivillige studenter og hører til under Studentersamfundet i Trondheim. Avisen har idag et opplag på eksemplarer som utgis annenhver tirsdag. Per idag er det 65 arbeidere i Under Dusken som er fordelt på ulike redaksjoner. 1.3 Interessenter Se VedleggA. 1.4 Bakgrunn for prosjektet Under Dusken ble startet opp i 1914 og er nordens eldste studentavis. Etter at bruken av data og internett tok av på slutten av 90-tallet ble det opprettet en egen dataavdeling som skulle ta seg av drift og utvikling av datasystemer for avisen, deriblant Redsys. Dette redaksjonelle systemet har vært under kontinuerlig utvikling siden 1999, men ble først satt i drift i Arbeidet med Redsys er basert på DAPSUD 1 -rapporten, et kundestyrt prosjekt fra Redsys består av en artikkeldatabase, artikkeleditor, kildedatabase og en fotodatabase (som foreløpig er under utvikling). Systemet gir bedre oversikt over artikler og status for produksjonen. Dessuten er den nye integrerte artikkeleditoren forenklet slik at journalistene kan fokusere på innhold og ikke trenger å kunne koder. Dette har ført til færre feil, større effektivitet og generelt bedre kvalitet. Artikler blir lagret i et egendefinert XML-format, men kan transformeres til Quark-, HTML-, PDFeller NITF-format. Dataene lagres i en MySQL-database og det er Java som brukes i implementasjonen. Den videre utvidelsen av systemet som kunden ser for seg er å ha muligheten for å hente ut måledata fra artikkeldatabasen og presentere disse på en fornuftig måte. Det vil blant annet være nyttig for redaktøren å kunne ha tilgang til statistikk over hvordan journalistene jobber og når tekst blir skrevet. Hvis redaktøren har bedre oversikt over hvor mye som er produsert til enhver tid vil det sjeldnere bli problemer med levering til layout innen tiden. Layout-gruppa er i stor grad avhengig av at teksten er ferdig før de kan påbegynne arbeidet og jo bedre tid de har på jobben jo bedre avis blir levert. Det vil også være nyttig med statistikk over når på døgnet og når i uka systemet brukes. Et annet aspekt ved systemet er bruken av kilder. Det vil være interessant for redaktøren og andre å se på hvilke kilder som brukes mest og om det er enkelte kilder som er overrepresentert. For eksempel vil det være nyttig å vite hvordan NTNU-kilder brukes i forhold til HIST-kilder. Dette er imidlertid ikke like aktuelt for oss å føre statistikk over, ettersom kilde-databasen ikke er i utstrakt bruk blant journalistene enda. Kunden har også antydet at språk 1. Distribuert AvisProduksjonsSystem for Under Dusken Side 2 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

17 Prosjektdirektiv kan være aktuelt å bygge inn, slik at man kan se hvordan språkbruken utvikler seg, og søke etter utvalgte ord i artiklene. 1.5 Effektmål Systemet vi lager vil lette oppgavene til redaktøren med tanke på oppfølging av journalistene og for å skaffe seg en oversikt over arbeidet som blir gjort i staben. Følgende effektmål er definert for prosjektet: Journalistene vil disponere tiden bedre i skriveprosessen. Kvaliteten heves for det ferdige produktet. Redaktøren får mindre arbeid med desking. De ansatte vil få bedre oversikt over produksjonssyklusen i avisen. 1.6 Resultatmål Resultatene vi ønsker å oppnå er et system som henter ut data fra databasen som brukes av Redsys og beregner ulik statistikk av denne informasjonen. De konkrete resultatmålene er: Systemet skal vise avisens og journalistenes produksjon av artikler. Systemet skal vise avisens og journalistenes bruk av tilleggsfunksjoner. Systemet skal vise hvordan artikler fordeler seg på forskjellige kategorier. Systemet skal vise statistikk over artiklenes status. Vi skal bygge et rammeverk som skal gjøre det enkelt å legge til nye målinger ved en senere anledning. 1.7 Prosjektets omfang Systemet skal gjøre statistiske beregninger på data fra publiseringssystemet Redsys, og skal være tilgjengelig for alle brukerne av systemet. Systemet skal fremvise følgende grafiske statistikk: Produksjonsmengde i antall tegn. Produksjonsmengden skal vises totalt for Under Dusken, fordelt på redaksjon og individuelt. Produksjon av tegn fordelt på tid, totalt for Under Dusken, fordelt på redaksjon og individuelt. Bruk av nye features som for eksempel notat-funksjonen fordelt på tid, totalt for Under Dusken, fordelt på redaksjon og individuelt. Hvor mange av artiklene som hører til under de forskjellige kategoriene. Oversikt over artiklenes statusskifter. Oversikt over hvor mange artikler som til enhver tid befinner seg i de forskjellige statusfasene. Oversikt over hvor mange artikler som overføres mellom forskjellige utgaver av avisen. Systemet skal også kunne generere rapporter med samtlig grafikk. Systemet skal generere statistikk på forespørsel fra brukeren og prosessere dette i sanntid. Hver bruker skal kunne se sin egen, redaksjonens og organisasjonens totale statistikk. 1.8 Rammebetingelser Vårt system skal integreres mot et allerede eksisterende publiseringssystem Redsys, og det ligger derfor en del rammebetingelser til grunn for prosjektet: Artiklene ligger lagret i XML-format og all informasjon ligger lagret i en MySQL-database. Systemet skal implementeres i Java. Koding og dokumentasjon skal gjøres på engelsk, fordi det er ønskelig å publisere systemet vårt som Open Source på internett sammen med den allerede eksisterende løsningen. Systemet som lages skal være et rammeverk som lett lar seg utvide med nye målinger. For å kunne gjøre statistiske beregninger på data fra Redsys må disse dataene foreligge i systemet, og dersom noe av dataene ikke finnes ved prosjektets start skal det bli lagt til etter TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 3 av 34

18 Prosjektdirektiv avtale med kunden. Under implementasjonen vil vi få tilgang til noen artikler etter avtale med journalistene om opphavsrett til skrevet materiale. 1.9 Økonomi Tidsrammen for prosjektet er bestemt i fagplanen for TDT4290 Kundestyrt Prosjekt og er i utgangspunktet satt til 310 timer per person. For en gruppe på 5 personer blir dette 1550 timer tilgjengelig som budsjettramme. Dette tilsvarer ca. 24 arbeidstimer per gruppemedlem i uken. Kostnadsoverskridelser kan godtas, men skal unngås så langt det er mulig Tid Prosjektet har en fast deadline. Dato for innlevering er satt til 13. november Side 4 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

19 Prosjektdirektiv 2. Prosjektplan Prosjektplanen inneholder informasjon om de ulike faser prosjektet skal gå gjennom, om aktiviteter, milepæler og fordeling av timer mellom fasene. Først ser vi kort på vannfallsmodellen som vi bruker som utgangspunkt i dette prosjektet. 2.1 Vannfallsmodellen Vannfallsmodellen er delt opp i følgende hoveddeler: Planlegging Forstudie Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Testing Vannfallsmodellens hovedprinsipp er at den i hovedsak følger en sekvensiell utvikling gjennom de nevnte hoveddelene og at det ikke er noen iterativ prosess der hver fase gjøres flere ganger. Figur1 illustrerer hvordan de ulike fasene i vannfallsmodellen henger sammen. Planlegging Forstudie Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Testing 2.2 Faser og aktiviteter Figur 1: Vannfallsmodellen Detaljerte faseplaner for en fase planlegges ved avslutningen av forrige fase. Disse blir tilføyd som vedlegg etter hvert som de produseres. Fasene består av ulike aktiviteter. For hver aktivitet kreves det nødvendig input fra en foregående aktivitet samt ressurser for å utføre aktiviteten. I tillegg har hver aktivitet ønsket output, som vist i Figur2. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 5 av 34

20 Prosjektdirektiv Et konkret eksempel på dette, kan være å skrive møtereferat - en relativt enkel aktivitet. Nødvendig input er en kladd til møtereferat fra selve møtet. Ressurser som kreves, er en datamaskin med teksteditor installert og tilkobling mot internett slik at møtereferatet kan deles med resten av gruppa. I tillegg er referenten selv, og de andre tilstedeværende på møtet en ressurs for denne aktiviteten. Ønsket output er et møtereferat. Nødvendig input Aktivitet Ønsket output Ressurser Vi deler prosjektet inn i følgende faser: Planlegging Forstudie Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Evaluering Presentasjon Disse fasene følger ikke helt den beskrevne vannfallsmodellen. Grunnen til dette er at vi her legger inn evaluering og presentasjon som egne faser, selv om de strengt tatt ikke er reelle faser i prosjektet. Testing er utelatt her, men vil inngå i de faser der det er naturlig. I delkapitlene som følger sier vi kort hva hver fase innebærer. Se VedleggB for nærmere beskrivelse av de ulike fasene vi har i dette prosjektet Planlegging Her lages prosjektdirektivet, som oppdateres etter hvert som prosjektet utvikler seg Forstudie I forstudiet skaffes informasjon og forståelse av problemet og utfordringene: Forståelse av problemstillingen (dagens system, potensielle løsninger, operasjonelle/ forretningsmessige krav). Bevissthet om allerede eksisterende mulige løsninger på markedet, evaluering av muligheter og valg av løsning. Kost/nytte-vurdering dersom det finnes aktuelle eksisterende systemer eller komponenter Kravspesifikasjon Under kravspesifikasjon lages en oversikt over krav til systemet og omgivelsene, basert på kravene som kom fram i forbindelse med forstudiet. Her skal man beskrive overordnet programvarearkitektur, funksjonelle krav og ikke-funksjonelle krav Kontruksjon Figur 2: Aktiviteter Side 6 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

21 Prosjektdirektiv Her skal man komme fra en overordnet systembeskrivelse til en realiserbar spesifikasjon. Teknologien som skal brukes, og hvordan den brukes, må beskrives. Det detaljerte designet beskrives/modelleres. I tillegg utarbeides testplan og detaljerte testspesifikasjoner Programmering og dokumentasjon I denne fasen foregår selve programmeringen og produksjon av programmeringsdokumentasjon. I tillegg lages bruker- og installasjonsveiledning Evaluering Dette innebærer en evaluering av prosjektet (prosess og resultat, kunde og oppgave, faget og videre arbeid). Vi har her valgt å sette opp evalueringen som et eget punkt, selv om det egentlig utføres under hele prosjektarbeidet og dermed ikke er en reell fase Presentasjon Under presentasjon planlegges og utføres presentasjon og demonstrasjon av prosjektet. Dette er heller ingen virkelig fase, men vi nevner det her som eget punkt fordi det utgjør en sentral del av dette prosjektet. 2.3 Hovedansvarlige Prosjektets ulike faser krever en ansvarlig. Dette har vi fordelt mellom gruppas medlemmer slik Tabell 1 viser. Tabell 1: Hovedansvarlige Fase Planlegging Forstudie Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Evaluering Presentasjon Hovedansvarlig Alle Kristoffer Frode Magnus Harald Frode Lisa 2.4 Milepæler - leveranser I slutten av fase vil fasedokumentene leveres inn til hovedveiledermøtene for gjennomgang og evt. godkjenning slik at vi kan legge enkelte fasedokumenter til sides som ferdige. Se VedleggE for et dataflytdiagram om hvordan våre rutiner er her. Preleveranse av forstudium og kravspesifikasjon er 23. oktober. Siste milepæl er presentasjon og demonstrasjon av produktet 13. november. Tidsfrister er vist i Tabell 2. Tabell 2: Leveranser Fase Planlegging Forstudie Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Evaluering Presentasjon Tidsfrist 2. september 25. september 6. oktober 22. oktober 5. november 10. november 13. november Gantt-diagram er laget for å få en oversikt over prosjektplanen. Se VedleggC der Ganttdiagrammet ligger i sin helhet. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 7 av 34

22 Prosjektdirektiv 2.5 Timer per aktivitet og fase + forelesninger + prosjektledelse Vi har valgt å gå ut fra den oppgitte normen fra tidligere år, med noen tilpasninger etter vårt antatte behov. Endringene innebærer mer tid til forstudiet og mindre tid til kravspesifikasjon, ettersom et godt forstudie kan gjøre produksjon av kravspesifikasjon enklere og raskere. Timefordelingen blir da som oppsatt i Tabell3. Tabell 3: Timefordeling Fase % Timer pr. person Timer totalt Prosjektledelse Forelesninger og egenlæring Planlegging 7 21,7 108,5 Forstudium 18 55,8 279 Kravspesifikasjon 17 52,7 263,5 Konstruksjon 15 46,5 232,5 Programmering og dokumentasjon 13 40,3 201,5 Prosjektvurdering 5 15,5 77,5 Presetasjon og dokumentasjon 5 15,5 77,5 Totalt Side 8 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

23 Prosjektdirektiv 3. Organisasjon Vi har definert relevante roller for alle gruppemedlemmene. Disse kan sees under kap kap. 3.2 viser hva de enkelte rollene innebærer av konkrete oppgaver og ansvar. 3.1 Roller Figur3 viser gruppas definerte roller oppsatt i et organisasjonskart. Prosjektleder Koordinator Dokumentansvarlig Teknisk ansvarlig Test- og visesjef Referent Figur 3: Organisasjonskart Rollene er besatt av gruppas medlemmer slik Tabell 4 viser. Tabell 4: Rollefordeling Rolle Prosjektleder Test- og visesjef Koordinator Dokumentansvarlig Teknisk ansvarlig Referent Besatt av Lisa Frode Kristoffer Magnus Harald Alle 3.2 Rollenes oppgaver Her beskrives alle roller og hva de innebærer av ansvar Prosjektleder Prosjektleders oppgaver er: Ordstyrer på møter Holde kontroll på alle deadlines og oppfølging av dem Samle inn og samordne statusoversikt hver uke Kontroll og oppfølging av progresjonen i arbeidet til gruppen som helhet Test- og visesjef Test- og visesjefs oppgaver er: Ansvarlig for oppsett av testplan og gjennomføring av testing Stedfortreder for prosjektleder Sosiale aktiviteter i gruppa Koordinator Koordinators oppgaver er: TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 9 av 34

24 Prosjektdirektiv Ansvarlig for møter Kundekontakt Ansvarlig for oppfølging mot veileder, spesielt at alle dokumenter sendes til riktig tid Dokumentansvarlig Dokumentansvarligs oppgaver er: Lage maler og oppsett for alle dokumenter (referat, møteinnkalling, møtereferat etc.) BSCW, spesielt orden og struktur med hensyn på filnavn og kataloger. Opplæring og nødvendig viderelæring i FrameMaker Samle inn og sette sammen dokumenter Teknisk ansvarlig Teknisk ansvarligs oppgaver er: Språk-kontroll (riktig kode og dokumentasjon etc.) Oversikt over tekniske løsninger CVS Referent Referentens oppgaver er å skrive referat og distribuere dette innen kl 12 neste dag til alle involverte på møtet. Unntaket er veiledermøtene der veilderne får referatet sammen med øvrige dokumenter kl. 12 dagen før møtet. Side 10 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

25 Prosjektdirektiv 4. Maler og standarder I dette kapitlet presenterer vi hvilke maler og standarder som gjelder for prosjektet. 4.1 Maler Vi har laget maler for møteinnkalling, møtereferat, statusrapport (både internt og mot veileder) og timerapportering. Disse kan sees i VedleggD med konkrete eksempler. En felles mal for oppsett av den endelige rapporten er laget i programmet FrameMaker. kap viser hvilken tekststandard dokumentene skal bygge på. 4.2 Dokumentorganisering Alle filer og kataloger som er i bruk har vi laget et felles område på BSCW 1 (Basic Support For Cooperative Work) for. Se kap for hvordan katalogstrukturen er oppbygd. På BSCW skal alt lastes opp med en gang et dokument er ferdig eller skal leses/jobbes videre med av andre på gruppa. Se kap. 5. for hvordan vi her skal sikre versjonskontroll Katalogstruktur Katalogene er organisert slik Figur4 viser på BSCW. Under hver fasedokument-katalog vil vi dele opp i delkapitler og fullstendige dokument, noe som ikke fremgår av figuren. Kundestyrt prosjekt, gruppe 18 Administrativt Diverse Fasedokumenter Diskusjon Møtereferat Maler Statusrapport Timerapport Veiledermøter Interne møter Kundemøter Forstudie Prosjektdirektiv Kravspesifikasjon Konstruksjon Programmering og dokumentasjon Evaluering Presentasjon Filstruktur Figur 4: Katalogstruktur BSCW Filene er navngitt så informative som mulig innen riktig katalog. F.eks vil et referat fra veiledermøte ha filnavnet ref-veil-2108.doc. Tilsvarende ref-intern-2108.doc for interne møter og refkunde-2108.doc for kundemøter. Alle delkapitler innen fasedokumentene navngis på formen kapittel X - navn, mens hovedfiler navngis med fase. For eksempel vil da dette kapitlet ha navnet kapittel 4 - Maler og Standarder. Tilsvarende vil det fullstendige dokumentet ha navnet Prosjektdirektiv. 1. Vi bruker NTNUs felles BSCW-løsning under TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 11 av 34

26 Prosjektdirektiv Tekststandard Tabell 5 viser vår standard for bruk av tekst i rapporten. Tabellen angir alle stiltyper som vi bruker i FrameMaker 1 med skrifttype, størrelse, avstand over og under teksten og evt. innrykk til teksten.. Tabell 5: Tekststandard for dokumentskriving Stiltype Brukesområde Spesifikasjon Heading1 Heading in Appendix Heading No Num Appendix2 Appendix3 Heading2 Heading3 Heading3NoNum Alle hovedoverskrifter i hver delbok, som kapitlene i prosjektdirektivet. Brukes 1. foran for å angi kapittel nummer 1. Overskrift som brukes for hvert vedlegg. Angis på formen vedlegg A. Brukes ved hovedoverskrifter som ikke skal nummeres. I hovedsak ved innledning og sammendrag for de ulike fasedokumentene. Underoverskrift som brukes for å angi delkapittel i et vedlegg. Nummeres på formen: A.1 for å angi delkapittel 1 i vedlegg A. Overskrift innen underkapitler i et vedlegg. Angis med nummer på formen: A.1.2 som angir underkapittel 2 til delkapittel 1 i vedlegg A. Underoverskrifter som angir delkapitler med nummering på formen: 1.2 for å angi underkapittel 2 av hovedkapittel 1. Overskrifter innen underkapitler med nummerering på formen: foran. Dette angir delkapittel 3 av underkapittel 3 til hovedkapittel 1. Overskrifter innen underkapitler som ikke skal bruke nummering av overskriften Skrift: Verdana, bold, 18pt. Avstand:18pt over, 6pt under Pagebreak før stilen. Skrift: Verdana, bold, 18 pt. Avstand:18pt over, 6pt under Pagebreak før stilen. Skrift: Verdana, bold, 18 pt. Avstand:18pt over, 6pt under Pagebreak før stilen. Skrift: Arial, bold, 11 pt. Avstand:14pt over, 6pt under Innrykk: 0 cm Skrift: Arial, bold, 10 pt. Avstand: 8 pt over, 4pt. under Innrykk: 0,7 cm Skrift: Arial, bold, 11 pt. Avstand:14pt over, 6pt under Innrykk: 0 cm Skrift: Arial, bold, 10 pt. Avstand: 8 pt over, 4pt. under Innrykk: 0,7 cm Skrift: Arial, bold, 10 pt. Avstand: 8 pt over, 4pt. under Innrykk: 0,7 cm Body All vanlig tekst i dokumentene Skrift: Arial, plain, 10 pt. Innrykk: 0,7 cm Footnote Kode Eksempel Tekst på fotnoter. Lages med nr. tekst, der nr. referer til angitt pkt i teksten. Brukes for å angi kodeeksempler i teksten Angir navn og nr. på kodeeksempel i teksten Skrift: Arial, italic, 9 pt. Innrykk: 0,6cm til nr og 1 cm til teksten. Skrift: Courier, plain, 10pt. Innrykk: 0,7 cm Skrift: Arial, bold, 10 pt. Innrykk: 0,7 cm Side 12 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

27 Prosjektdirektiv Bulleted Punktlister Skrift: Arial, plain, 10 pt. Innrykk: 0,7 cm til prikken og 1 cm til tekst Numbered1 Numbered Numbered1Table NumberedTable Brukes for å starte en ny nummertliste slik at telleren nullstilles og starter på 1. For nummererte lister f.o.m punkt 2 brukes numbered. Nret økes da automatisk. Brukes for å starte en ny nummertliste slik at telleren nullstilles og starter på 1. Brukes kun tabeller der det ikke skal være noe innrykk. For nummererte lister f.o.m punkt 2 brukes numbered. Nret økes da automatisk. Brukes kun til tabeller der det ikke skal være innrykk. Skrift: Arial, plain, 10 pt. Innrykk: 0,7 cm til nr. og 1 cm til tekst Skrift: Arial, plain, 10 pt. Innrykk: 0,7 cm til nr. og 1 cm til tekst Skrift: Arial, plain, 10 pt. Innrykk: 0 cm til nr. og 0,3 cm til tekst Skrift: Arial, plain, 10 pt. Innrykk: 0 cm til nr. og 0,3 cm til tekst Cellbody Tekst i en tabell Skrift: Arial, plain, 10 pt. Avstand: 0 pt CellHeading Overskrift i en tabell Skrift: Arial, bold, 10 pt. Avstand: 0 pt TableTitle FigureTitle Heading1 TOC Heading2 TOC Heading3 TOC Heading in Appendix TOC Appendix2 TOC Appendix3 TOC Tabell 5: Tekststandard for dokumentskriving Stiltype Brukesområde Spesifikasjon Angir tabellens navn og nr, plassert ovenfor selve tabellen Angir navn på figurer, med nr. og navn. Brukes som overskrift for hovedkapitlene i innholdsfortegnelsen Innslag til innholdsfortegnelsen for overskrift til delkapitler Innslag til innholdsfortegnelsen for overskrift til underkapitler Representerer overskriften til vedleggene i innholdsfortegnelsen Brukes for underoverskrifter til vedleggene fra vedleggene i innholdsfortegnelsen Innslag til innholdsfortegnelsen for overskrift til underkapitler i vedleggene Skrift: Arial, bold, 10 pt. Avstand: 0 pt Skrift: Arial, bold, 10 pt. Avstand: 0 pt Skrift: Arial, bold, 10 pt. Avstand:2pt. over, 3pt. under Skrift: Arial, plain, 10 pt. Avstand: 0 pt Innrykk: 3,1 cm Skrift: Arial, plain, 10 pt. Avstand: 0 pt Innrykk: 4,0 cm Skrift: Arial, bold, 10 pt. Avstand:2pt. over, 3pt. under Skrift: Arial, plain, 10 pt. Avstand: 0 pt Innrykk: 3,1 cm Skrift: Arial, plain, 10 pt. Avstand: 0 pt Innrykk: 4,0 cm 1. For beskrivelse av programmet, vises det til: TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 13 av 34

28 Prosjektdirektiv 5. Versjonskontroll Vi bruker to ulike verktøy for versjonskontroll: BSCW (Basic Support For Cooperative Work) og CVS (Concurrent Versions System). For dokumenter brukes BSCW, mens til versjonskontroll av kildekode benyttes CVS. 5.1 BSCW BSCW støtter to typer av versjonskontroll: Dokumenter kan låses, dvs. at aksjonene Replace, Delete og Edit ikke kan utføres. Det dukker da opp en hengelås ved dokumentet som viser at dette er låst og under oppdatering. Når oppdateringen er ferdig, må unlock gjøres. Versjonskontroll av dokumenter. Et versjonsnummer settes da inn etter dokumentnavnet. Eieren av dokumentet blir han eller hun som har etterspurt versjonskontrollen. I tillegg byttes Replace-aksjonen ut med en Revise-aksjon i Actions-menyen. Vi benytter oss av begge typer av versjonskontroll for våre dokumenter. Punkt 1 hindrer andre i å oppdatere/slette et dokument mens det er under oppdatering, mens punkt 2 gjør det mulig å holde oversikt over versjoner av dokumentet. Når et dokument skal revideres (Revise-aksjonen), låses dette først (ved Lock-aksjonen). Ved opplasting av det reviderte dokumentet, skrives det hvilke endringer som er gjort. Det er også mulig å få tak i en tidligere revisjon av et dokument. Oversikten over alle revisjoner gjøres ved å velge Branch fra Actions-menyen. 5.2 CVS All versjonskontroll av kildekode skjer via CVS. Gruppen har opprettet en felles CVS-katalog (cvs) hvor prosjektets kildekode og informasjon om filers versjoner og endringer gjort på disse ligger. Kunderepresentant Eirik Bjørsnøs har tilbydt oss et web-basert brukergrensesnitt mot CVS. Foreløpig vil vi benytte oss av en CVS-klient for Java som tilbyr et grafisk brukergrensesnitt. 1 Denne klienten jobber opp mot et repository som finnes sentralt på en IDI-server. 1. Informasjon om denne klienten kan finnes på og Side 14 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

29 Prosjektdirektiv 6. Prosjektoppfølging Denne delen tar for seg hvordan gruppen følger opp prosjektet underveis i form av møter, rapportering og håndtering av risiko og interne/eksterne konflikter. 6.1 Møteplan Gruppen holder faste internmøter 2 ganger i uken eksklusivt veiledermøtene. De ordinære møtene holdes mandager og torsdager (se Tabell6), mens veiledermøtene holdes onsdager til fastsatte tider. Hver mandag har gruppen fast kundemøte. Til alle ordinære møter har vi reserverte rom. Møter utenom disse koordineres av koordinator. Tabell 6 viser alle faste møter gruppa har hver uke med sted og tid. Tabell 6: Faste møter hver uke Dag Type Rom/sted Tid Mandag Kundemøte IT :15-12:00 Mandag Internt møte IT :15-15:00 Onsdag Hovedveiledermøte IT 142 Se Tabell 7 Torsdag Internt møte E :15-17:00 I Tabell7 vises møteplanen for hovedveiledermøtene etter oppsatt plan av vår hovedveileder. Tabell 7: Veiledermøter Dato Rom/sted Tid Onsdag 27. august IT :15-16:00 Onsdag 03. september IT :15-17:00 Onsdag 10. september IT :15-18:00 Onsdag 17. september IT :15-19:00 Onsdag 24. september IT :15-16:00 Onsdag 01. oktober IT :15-17:00 Onsdag 08. oktober IT :15-18:00 Onsdag 15. oktober IT :15-19:00 Onsdag 22. oktober IT :05-15:35 Onsdag 29. oktober IT :40-16:10 Onsdag 05. november IT :15-16: Organisering Alle medlemmer av gruppen møter til de fastsatte møtetidspunktene. De som eventuelt ikke kan møte gir beskjed til prosjektleder eller koordinator. Andre møter utenom dette varsles gruppemedlemmene senest 24 timer før møtet. På mandager deltar kunden på kundemøtet dersom han har anledning. Det kan også inntreffe at det ikke er behov for samtale og diskusjon med han. Kunden får tilsendt møteinnkallelse av koordinator senest 24 timer før møtet. Agenda settes opp av prosjektleder/koordinator. Møtet innledes med at prosjektleder gir en kort presentasjon av agendaen. På slutten av hvert møte kommer gruppemedlemmene med punkter til agendaen for neste møte. Referentrollen på møtene sirkuleres blant gruppemedlemmene. Han eller hun har ansvar for at møtereferatet ligger på BSCW innen neste dag. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 15 av 34

30 Prosjektdirektiv Når gruppa ikke er samlet kan MSN (Microsoft Messenger) og et eget diskusjonforum 1 brukes som kommunikasjonsmedium. Men her diskuteres ikke større og viktigere momenter ved prosjektet. 6.3 Intern timerapportering Hvert gruppemedlem rapporterer sine timer til prosjektleder innen søndag klokken Her rapporteres antall timer i henhold til aktivitetskategorier og fasebelastning. Se mal for individuell timerapportering i Vedlegg D. Prosjektleder fører så dette over i eget timerapporteringsskjema (se vedlegg B for mal). Den oppdaterte rapporten finnes på BSCW under Administrativt/Timerapport. 6.4 Statusrapportering Statusrapportering leveres skriftlig til prosjektleder innen klokken hver søndag. Punktene som inngår i denne rapporten er: Status ferdigstilt arbeid i perioden Status påbegynt arbeid Problemer Melding om fravær Eventuelt Se for øvrig mal for dette i VedleggD. Prosjektleder har så ansvar for å oppdatere gruppens statusrapport. Se VedleggD for hvordan malen ser ut. Rapporten sendes til veiledere sammen med øvrige dokumenter før veiledermøtene senest tirsdag før hvert møte. Den er for øvrig tilgjengelig på BSCW under Administrativt/ Statusrapport. 6.5 Risikohåndtering / TROKK TROKK står for Tid, Risiko, Omfang, Kostnad og Kvalitet og er et hjelpemiddel for å holde oversikt over viktige momenter ved prosjektarbeidet. Her legges det vekt på om prosjektet holder seg innenfor de tidsrammer som er fastsatt, risikomomenter identifiseres sammen med deres sannsynligheter, konsekvenser, tiltak og ansvar. Se Tabell8 for eksempel på vårt oppsett av risikotabell. Videre kartlegges omfanget av arbeidet med tanke på stabilitet og endringer, kostnader/timer estimeres og produktets kvalitet vurderes for å se om noe må reduseres. Tabell 8: Utdrag av risikotabell Nr Aktivitet Risikofaktor Konsekvens Sanns Strategi og tiltak Tidsfrist Ansvar 1 Alle BSCW går ned. Ikke tilgjengelig gruppeområd e. H Mister adgang til gruppas dokumenter. L Enhver laster opp de dokumentene de er ansvarlige for til IDIs BSCWserver (i stedet for bscw.ntnu.no) 48 timer Dokume ntansvarl ig 1. Diskusjonsforumet til gruppa finnes på Side 16 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

31 Prosjektdirektiv Nr Aktivitet Risikofaktor Konsekvens Sanns Strategi og tiltak Tidsfrist Ansvar 2 Alle Tap av dokument. 3 Alle Elise kan frafalle gruppa fordi hun skal være med på NTNUs Entreprenørs kole. H Kan føre til tap av mange timers arbeid, og frustrasjon i gruppa. L Ettersom vi har planlagt ut fra at vi er 5, kommer ikke dette til å bli noe stort problem, men vi kommer til å få gjort mindre enn vi ellers ville få gjort. M H Dokumentene må rekonstrueres dersom det ikke er mulig å få dem tilbake på andre måter (backup el. lign.). Fagledere informeres, slik at gruppa blir vurdert ut fra at vi kun er 5. En uke Dokume ntansvarl ig 8. sept. Koordina tor 6.6 Konflikthåndtering Det er viktig å ha klart for seg hvordan man skal håndtere konflikter, men det er bedre å unngå at konflikter oppstår i utgangspunktet. For eksempel kan det virke forebyggende å la alle på gruppa bli hørt, og ha rutiner for å sørge for at dette skjer (ta en runde hvor alle i gruppa sier spontant hva de føler ved felles avgjørelser, og ta opp mulige problemer med prosjektleder før det blir en konflikt). I tillegg er det viktig å ha klart på forhånd hvem som har myndighet til å avgjøre hvilke spørsmål, og når en sak bør avgjøres ved flertall. For å håndtere en eksisterende konflikt, har vi kommet fram til at følgende bør gjøres: Ta saken opp med prosjektleder. Samtaler ansikt til ansikt mellom partene, med hele eller deler av gruppa til stede. De som ikke har del i konflikten, kan fungere som meglere mellom partene i konflikten. Hver part får anledning til å forklare sine synspunkter, og hører på de(n) andre parten(e)s synspunkter. Deretter kan de som ikke har del i konflikten komme med sine synspunkter, og man stemmer over saken (eventuelt avgjøres saken av den som har myndighet til det). Prosjektleder har vetorett. Det som er vedtatt av gruppa som helhet er loven, og alle må holde seg til dette. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 17 av 34

32 Prosjektdirektiv 7. Kvalitetssikring Følgende retningslinjer skal med mindre annet er påpekt benyttes for å sikre kvaliteten på dokumentene som produseres. 7.1 Interne retningslinjer Følgende retningslinjer benyttes for responstider og godkjenningsrutiner innad i gruppa: BSCW benyttes som felles lagringsområde. Mail til kpro18@idi.ntnu.no sendes umiddelbart etter at noen har lagt ut et nytt eller oppdatert dokument på BSCW. Møtereferater skal være lagt ut på BSCW senest kl 1200 etterfølgende dag. Alle utlagte dokumenter skal være lest av samtlige gruppemedlemmer senest 24t etter at de har blitt lagt ut. Fast agenda på de interne gruppemøtene er godkjenning av ferdige dokumenter som er lagt ut på BSCW innen 24t før møtet. Et dataflytdiagram for våre rutiner knyttet til utarbeidelse av fasedokument kan sees i VedleggE. 7.2 Retningslinjer ovenfor veileder Følgende retningslinjer benyttes for responstider, godkjenningsrutiner og møtevirksomhet med veilederene. Møteinnkalling til veileder skal være sendt senest tirsdag kl Agenda for veiledermøte 1. Godkjenning av dagsorden 2. Godkjenning av referat fra forrige veiledermøte 3. Kommentar til møtereferat fra forrige veiledermøte 4. Godkjenning av statusrapport 5. Gjennomgang/godkjenning av vedlagte fasedokumenter 6. Andre saker listes fortløpende 7. Eventuelt Møtereferat fra veiledermøter legges ved neste møteinnkalling og er et fast punkt (pkt 2) på agendaen. 7.3 Retningslinjer ovenfor kunden Følgende retningslinjer benyttes for responstider, godkjenningsrutiner og møtevirksomhet med kunden. Det er fast kundemøte hver mandag kl på rom IT242. Agenda til kundemøte sendes senest fredag kl Det er avtalt følgende responstider med kunden: 1. Godkjenning av tilsendt referat fra kundemøte: 24 timer. 2. Svare på spørsmål: 24 timer. 3. Tilbakemelding på fasedokumenter kunden ønsker å få til gjennomsyn: 48 timer. 4. Godkjenning av fasedokumenter: 48 timer. 5. Skaffe til veie avtalte dokumenter: 24 timer. Møtereferat fra kundemøte sendes til kunden senest kl 1200 etterfølgende dag. Side 18 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

33 Prosjektdirektiv 8. Testplan Her følger en overordnet testplan for utviklingen av StatSys.Testplanen inneholder ikke de konkrete testene, men en oversikt over hvilke tester som skal gjennomføres, og hvordan de skal gjennomføres og evalueres. Et eget testdokument følger senere i rapporten. 8.1 Innledning Under utviklingen av et IT-system er en nødt til å gjennomføre kontinuerlige tester av det, slik at en eliminerer feil i koden, og slik at brukerne får en mulighet til å kommentere det som blir laget før det er ferdig. Å eliminere feil i koden kalles gjerne verifisering, og omtales som å forsikre seg om at en lager systemet riktig. Å la brukerne komme med tilbakemeldinger underveis kalles validering, og forklares som å lage riktig system. For at testingen skal være konsekvent og konsistent har vi laget en plan for denne på forhånd, slik at alle gruppas medlemmer jobber etter samme prinsipp. Nedenfor følger punktene i denne overordnede planen. 8.2 Tester som skal gjennomføres Testene deles inn i to hovedgrupper. Tester som gjennomføres av utviklerne, og tester som gjennomføres av systemets brukere Tester for utviklerne Dette er tester som er utviklet av og skal gjennomføres av systemets utviklere, altså gruppa. Målet med disse testene er å sørge for at programkoden ikke inneholder feil, og at samspillet mellom systemets moduler fungerer. Rekkefølgen i testene er bygd opp slik at når en tester på et nivå, skal en ikke heftes med feil fra forrige nivå. Testene deles inn i tre nivåer, enhetstester, modultester og system- og integrasjonstest, på følgende måte: Enhetstester er tester av de minste kodesegmentene som lages. Det være seg klasser, objekter, skjema, grafikk, osv. Modultestene tester at de forskjellige modulene som systemet er satt sammen av fungerer som enkeltmoduler, og at samspillet mellom modulene fungerer som det skal. Oppsett av slike moduler utvikles i designfasen av prosjektet. System- og integrasjonstesten er en komplett test av systemet som helhet. En tester her hvorvidt systemet tilfredstiller kravene i kravspesifikasjonen Tester for brukerne Dette er tester som systemets utviklere lager, men som gjennomføres av brukerne. Målet med disse testene er å undersøke hvorvidt systemet utfører ønskelig funksjonalitet, og hvorvidt grensesnittet mot brukerne er godt nok. Når en kommer til det stadiet at brukerne skal teste systemet, skal det være gjennomtestet nok fra utviklernes side, til at brukerne ikke plages med datatekniske feil. Testene deles inn i to nivå, brukbarhetstester og akseptansetest: Brukbarhetstestene gir brukerne en mulighet til å teste grensesnittet til systemet, underveis i utviklingen. En prøver med dette å forsikre seg at systemet virker intuitivt for de som skal benytte seg av det, og at det gjør det det skal. Akseptansetesten er brukernes siste test, som avgjør hvorvidt han ønsker å ta systemet i bruk eller ikke Testing av krav Testing av krav utføres som beskrevet i eget fasedokument for testing. 8.3 Hvordan testene skal gjennomføres Her følger en beskrivelse av hvordan de ovennevnte testene skal gjennomføres Sjekklister Sjekklister er enkle punklister for hvordan en test skal gjennomføres. Disse sjekklistene skal benyttes på enhets- og modultestene. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 19 av 34

34 Prosjektdirektiv Testspesifikasjoner En testspesifikasjon er en mer detaljert beskrivelse om hvordan en test skal gjennomføres. Den inneholder blant annet informasjon om: Hvilke data som skal inn i testen. Hvilke resultater en forventer å få ut av testen. Hvor lang tid den skal ta. Hvem som er ansvarlig for testen. Hvordan rapporteringen av problemene skal gjennomføres. En mer detaljert beskrivelse av testspesifikasjonene følger i fasedokument for testing Black box og White box testing Black box og White box testing er to vanlige metoder for testing, som vi velger og benytte. Mer om disse metodene følger i eget fasedokument for testing. 8.4 Nødvendig testdata Kunden har gitt oss tilgang til Redsys, og til database-skjemaet som benyttes, slik at vi selv kan opprette en database med nødvendig testdata. Vi ønsker imidlertid full tilgang til den eksisterende databasen, slik at testingen blir mest mulig realistisk. 8.5 Ansvarsfordeling for utvikling av tester Testsjef er ansvarlig for utvikling av tester. 8.6 Ansvarsfordeling for gjennomføring av tester I dette avsnittet følger en oversikt over hvem som skal gjennomføre de forskjellige testene, og hvem som skal godkjenne de Hvem gjennomfører testene Her følger en beskrivelse av hvem som skal utføre de forskjellige testene. Enhetstestene utføres av den/de som har laget den koden som testes. Ansvar for utføring av modultester fordeles etter at de forskjellige modulene er definert, og kan finnes i eget fasedokument for testing. Ansvar for utføring av system- og integrasjonstest finnes i eget fasedokument for testing. Brukbarhetstestene gjennomføres av representanter fra kunden. Akseptansetesten gjennomføres av ansvarlig kunderepresentant Hvem godkjenner testene Her følger en beskrivelse av hvem som godkjenner de forskjellige testene. Testsjef er Frode. Enhetstestene godkjennes av den/de som har utført testen. Modultestene godkjennes av den/de som har utført testen, samt testsjef. System- og integrasjonstesten godkjennes av de som har utført testen, samt testsjef og prosjektleder. Brukbarhetstestene godkjennes av den/de som har utført testen, samt testsjef. Akseptansetest godkjennes av kunden. 8.7 Evaluering av testene En beskrivelse av kriteriene for evaluering av en test følger i fasedokument for testing Klassifisering av feil Innenfor de forskjellige typene testing plasseres eventuelle feil i forhåndsdefinerte klasser, for å oppnå konsistens mellom de forskjellige testene, og for å kunne lage definerte rutiner for håndtering av feilene. Denne klassifiseringen finnes i testdokumentet. Side 20 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

35 Prosjektdirektiv Rutiner for håndtering av feil Alt ettersom hvilken feil som oppdages i en test håndteres denne utifra forhåndsdefinerte rutiner. Disse finnes i testdokumentet Rutiner for testrapportering For alle andre tester enn enhetstester lages egne rapport-skjema, hvor resultatene av testene skal føres. Disse finnes også i testdokumentet. 8.8 Godkjenningskriterier Kriterier for godkjenning av tester er også definert, slik at alle gruppas medlemmer legger seg på samme nivå. Se testdokument. 8.9 Tidsplan for testing Testingen vil foregå både i konstruksjons- og programmering og dokumentasjonsfasen av prosjektet. Det vil si fra fredag til torsdag En mer detaljert tidsplan for de enkelte testene følger i testdokumentet. TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 21 av 34

36 Prosjektdirektiv Vedlegg A: Interessenter A.1 Prosjektgruppa Lisa Wold Eriksen Kristoffer Jacobsen Voll Studentby, Hybel A16 Bergljotsgate 5 Vegamot 1, 7048 Trondheim 7030 Trondheim Tlf Tlf lisaer@stud.ntnu.no kristoja@stud.ntnu.no Magnus Solberg Harald Ueland Voll Studentby, Hybel M12 Singsakerbakken 2e-27 Vegamot 1, 7048 Trondheim 7030 Trondheim Tlf Tlf magnusol@stud.ntnu.no ueland@stud.ntnu.no Frode Hjeltnes Neufeldts gate Trondheim Tlf hjeltnes@stud.ntnu.no A.2 Kunderepresentanter Eirik Bjørsnøs - Kunderepresentant - Tlf bjorsnos@underdusken.no Karen Møllerop - Ansvarlig redaktør - Tlf mollerop@underdusken.no Gøril Forbord - Reportasjeredaktør - Tlf gorilf@underdusken.no A.3 Veiledere Ola Stenseth - Hovedveileder - Tlf ola.stenseth@stolav.no Mona Sivertsen - Hjelpeveileder - Tlf monasi@stud.ntnu.no Side 22 av 34 TDT4290 Kundestyrt prosjekt - Gruppe 18

37 Prosjektdirektiv Vedlegg B: Detaljerte fasedokumenter B.1 Prosjektdirektiv Prosjektdirektivet definerer og inneholder alle konkrete opplysninger rundt prosjektet. Dette dokumentet skal fungere som en oppslagsbok for prosjektet. Det skal gi alle involverte en enkel og god måte å finne søkt informasjon på, samtidig som relevante mål defineres og kan måles mot hva som oppnås siden. Vårt prosjektdirektiv er inndelt i følgende hoveddeler: Prosjektmandat Prosjektplan Organisering Maler og standarder Versjonskontroll Prosjektoppfølging Kvalitetssikring Testplan B.2 Forstudie Forstudie er kort sagt forarbeidet til prosjektet. Her jobber prosjektgruppa med forskning og undersøkelse av eksisterende løsninger, teknologier, ulike krav til systemet og lignende. Det er her viktig å få fram så mange muligheter, synspunkter og synsvinkler som mulig, slik at riktig beslutning med hensyn på valgt løsning blir riktig. Denne fasen inneholder også denne vurderingen av de ulike alternativene og en konklusjon på hvilken som velges. Forstudiet har vi delt inn i følgende hovedkapitler: Presentasjon av nåværende situasjon Mål og forutsetninger Alternative løsninger Vurdering av løsningsalternativer B.3 Kravspesifikasjon Kravspesifikasjonen inneholder alle kravene vi, i samarbeid med kunden, definerer for systemet. Dette dokumentet er essesielt for den påløpende konstruksjonsfasen da konstruksjonen baserer seg direkte på å innfri systemkravene. Kravspesifikasjonen har vi delt inn i følgende hovedkapitler: Overordnet systembeskrivelse Ikke-funksjonelle krav Funksjonelle krav Krav til brukergrensesnitt Krav til dokumentasjon Krav til opplæring i bruk av systemet Kravoppsummering Regler for akseptansetest Overordnet testplan B.4 Konstruksjon Konstruksjonsdokumentet inneholder selve designet av systemet. Vi beskriver først systemet på et overordnet nivå, og tar deretter for oss hver enkelt modul. Konstruksjonen har vi delt inn i følgende hovedkapitler: Overordnet systembeskrivelse Klientmodulen Servermodulen Statistikkmodulen TDT4290 Kundestyrt prosjekt - Gruppe 18 Side 23 av 34