Brukergrensesnittmoduler for individuell plan

TDT4290 Kundestyrt prosjekt Gruppe 1 Brukergrensesnittmoduler for individuell plan Norges teknisk-naturvitenskapelige universitet (NTNU) Fakultet for informasjonsteknologi, matematikk og elektronikk (IME) Institutt for datateknikk og informasjonsvitenskap (IDI)

Norges teknisk-naturvitenskapelige universitet (NTNU) Fakultet for informasjonsteknologi, matematikk og elektronikk (IME) Institutt for datateknikk og informasjonsvitenskap (IDI) Gruppe 1 TDT4290 Kundestyrt prosjekt, høst 2003 3URVMHNWHWVWLWWHO %UXNHUJUHQVHVQLWWPRGXOHU IRULQGLYLGXHOOSODQ,QQOHYHUW 11. November 2003 7LOJMHQJHOLJKHW IDI, SINTEF, HEMIT 6WXGHQWHU Stud. techn. Even Aasland Stud. techn. Sigmund Augdal Stud. techn. Julie-Marie Foss Stud. techn. Kay Are Ulvestad Stud. techn. Gunnar René Øie Stud. techn. Knut Bjørnar Wålberg 2SSGUDJVJLYHU SINTEF Tele og data 6OXWWUDSSRUW *UXSSH 7UHVWLNNRUG Gruppedynamikk Individuell plan Brukergrensesnitt 9HLOHGHUH Margrethe Aune, hjelpeveileder Ola Stenseth, hovedveileder

Gruppe 1 )RURUG Denne oppgaven ble gitt av SINTEF (Stiftelse for Industriell og Teknisk Forskning) og ble gjennomført som en del av faget TDT4290 Kundestyrt prosjekt ved institutt for datateknikk og informasjonsvitenskap (IDI) ved Norges teknisk-naturvitenskapelige universitet NTNU. SINTEF samarbeider med Hiadata AS om å utvikle et elektronisk system for individuelle planer i helsevesenet. Vår oppgave besto i å utvikle en prototype på et grensesnitt for dette systemet. Prosjektet ble gjennomført høsten 2003. Det har vist seg å være et spennende og krevende prosjekt. Å få jobbe mot en reell arbeidgiver, med de utfordringene og det ansvaret medfører, har vært en stor motivasjon for gruppa. Omfanget og arbeidsmengden på prosjektet har vært stort, så samarbeid internt i gruppa har vært helt avgjørende for et godt resultat. Gruppa føler at de sitter igjen med større kunnskap i prosjektarbeid og samarbeid. Dessuten har vi økt vår kunnskap om en viktig del av helsevesenet som mest sannsynlig vil oppleve store endringer i den nærmeste årene. Håpet er at vi har klart å komme opp med noen gode ideer og konsepter som kan brukes videre. Gruppa vil takke representantene for kunden, Lillian Røstad og Nils Brede Moe. Som kunder har de vært flinke til å uttrykke sine ønsker og krav for prosjektet på en tydelig måte, samt gitt gode tilbakemeldinger på gruppas forslag til løsninger. En takk også til hovedveileder Ola Stenseth og hjelpeveileder Margrethe Louise Aune for konstuktive tilbakemeldinger på prosjektdokumenter og veiledning i prosjektorganisering. Even Aasland Sigmund Augdal Julie- Marie Foss Kay Are Ulvestad Gunnar René Øie Knut Bjørnar Wålberg iii

Gruppe 1 6DPPHQGUDJ På oppdrag fra SINTEF har gruppa utviklet en prototyp på brukergrensesnitt for individuell plan. Prosessen begynte med å utvikle god kunnskap om domenet, det vil si å få en god forståelse for bakgrunnen for, og det videre arbeidet med individuelle planer i helsevesenet. I følge "Forskrift om individuell plan etter helselovgivningen" har pasienter med behov for langvarige og koordinerte helsetjenester rett til å få utarbeidet en individuell plan. Dette ble lovbestemt i juli 2001. Målet for oppgaven har vært å samle inn krav, designe og implementere en prototyp som skal testes ut i helsenettet i forbindelse med SamPro. SamPro er et samarbeidsprosjekt mellom SINTEF og Hiadata AS som vil resultere i et web-basert system for individuell plan. Denne rapporten innholder en komplett dokumentasjon for prosjektet "Brukergrensesnittmoduler for individuell plan". Dette prosjektet har vært gitt i forbindelse med faget TDT4290 Kundestyrt prosjekt høsten 2003. I rapporten følger en dokumentasjon av hver av fasene prosjektet har vært gjennom. Disse fasene er planlegging, forstudie, kravspesifikasjon, konstruksjon, implementasjon, testing og evaluering. Gruppa har gjort et grundig forstudie for å velge det vi mener er det best egnede løsningsalternativet. Valget falt på å utvikle et nytt web-basert system. Vi har lagt opp til en arkitektur der databasen ligger i bunnen og vi har laget programlogikk og GUI oppå denne. Vi har benyttet Java Server Pages for å virkeliggjøre den ønskede arkitekturen. Brukergrensesnittet er utviklet med vekt på prosessorientering, det vil si at tilgjengelig funksjonalitet i systemet avhenger av hvilken fase brukeren befinner seg i i forhold til den individuelle planen. Systemet leveres som en prototyp som kan kjøres på en JSP-server. Vi håper at gruppens resultat vil oppfylle oppdragsgiverens forventninger til prosjektet. iv

Gruppe 1 )DVHGRNXPHQWHU 1 Prosjektdirektiv... PD 2 Forstudie...FS 3 Kravspesifikasjon...KS 4 Konstruksjon... KO 5 Implementasjon... IM 6 Testdokument...TE 7 Bruker- og installasjonsveiledning...bv 8 Evaluering...EV v

Norges teknisk-naturvitenskapelige universitet (NTNU) Fakultet for informasjonsteknologi, matematikk og elektronikk (IME) Institutt for datateknikk og informasjonsvitenskap (IDI) Gruppe 1 TDT4290 Kundestyrt prosjekt, høst 2003 3URVMHNWHWVWLWWHO %UXNHUJUHQVHVQLWWPRGXOHU IRULQGLYLGXHOOSODQ,QQOHYHUW 11. November 2003 7LOJMHQJHOLJKHW IDI, SINTEF, HEMIT, Hiadata 6WXGHQWHU Stud. techn. Even Aasland Stud. techn. Sigmund Augdal Stud. techn. Julie-Marie Foss Stud. techn. Kay Are Ulvestad Stud. techn. Gunnar René Øie Stud. techn. Knut Bjørnar Wålberg 2SSGUDJVJLYHU SINTEF Tele og data $QWDOOVLGHULKRYHGGRNXPHQW 33 3URVMHNWGLUHNWLY 7UHVWLNNRUG Mål Plan Oppfølging 9HLOHGHUH Margrethe Aune, hjelpeveileder Ola Stenseth, hovedveileder

Prosjektdirektiv Gruppe 1,QQKROGVIRUWHJQHOVH 1 Innledning... PD - 1 2 Prosjektmandat... PD - 2 3URVMHNWQDYQ 3' 3URVMHNWVSRQVRU 3',QWHUHVVHQWHU3' %DNJUXQQIRUSURVMHNWHW 3' (IIHNWPnO 3' 5HVXOWDWPnO 3' 3URVMHNWHWVRPIDQJ 3' 5DPPHEHWLQJHOVHU 3' NRQRPL 3' 7LG 3' 3 Prosjektplan... PD - 4 )DVHU3' )DVHUPHGWLOK UHQGHDNWLYLWHWHU 3' 3ODQOHJJLQJ 3' )RUVWXGLH3'.UDYVSHVLILNDVMRQ 3'.RQVWUXNVMRQ 3',PSOHPHQWHULQJ 3' 7HVWLQJ 3' (YDOXHULQJ 3' 3UHVHQWDVMRQRJGHPRQVWUDVMRQ3' 0LOHS OHU3' 7LPHU 3' 4 Organisering... PD - 11 5ROOHU 3' 5 Maler og standarder... PD - 12 'RNXPHQWPDOHU 3'.RGHVWDQGDUG3'.DWDORJVWUXNWXU 3' )LOQDYQ 3' 7HUPLQRORJL3' 6 Versjonskontroll... PD - 14 PD - ii

Prosjektdirektiv Gruppe 1 7 Prosjektoppfølging... PD - 15 3URVMHNWP WHU 3',QWHUQUDSRUWHULQJ 3' 6WDWXVUDSSRUWHULQJ 3' 5LVLNRKnQGWHULQJ 3'.RQIOLNWKnQGWHULQJ3' 8 Kvalitetssikring... PD - 17 5HVSRQVWLGHU3' )UDNXQGHWLOJUXSSH 3' )UDJUXSSHWLONXQGH 3' )UDYHLOHGHUWLOJUXSSH 3' )UDJUXSSHWLOYHLOHGHU 3',QQDGLJUXSSHQ 3' 0 WHLQQNDOOLQJWLONXQGHQ 3' 0 WHUHIHUDWIUDNXQGHP WH 3' 0 WHLQQNDOOLQJHUWLOYHLOHGHU 3' 0 WHUHIHUDWIUDYHLOHGHUP WHU3' 5XWLQHUIRUnSURGXVHUHNYDOLWHWI UVWHJDQJ 3' 5XWLQHUIRUJRGNMHQQLQJDYIDVHGRNXPHQWHU3' Vedlegg A:Interessenter... PD - 19 Vedlegg B:Maler... PD - 21 Vedlegg C:Katalogstruktur... PD - 31 Vedlegg D:Ordliste... PD - 33 PD - iii

Prosjektdirektiv Gruppe 1 /LVWHRYHUWDEHOOHU 7DEHOO7LPHIRUEUXN 3' 7DEHOO5ROOHIRUGHOLQJ 3' 7DEHOO2UGOLVWH3' PD - iv

Prosjektdirektiv Gruppe 1 /LVWHRYHUILJXUHU )LJXU9DQQIDOOVPRGHOOHQ 3' )LJXU2YHURUGQHWSURJUDPDUNLWHNWXU 3' )LJXU2YHURUGQHW*DQWWGLDJUDP 3' )LJXU2UJDQLVDVMRQVNDUW 3' )LJXU,OOXVWUDVMRQDYNDWDORJVWUXNWXU 3' PD - v

Innledning Prosjektdirektiv Gruppe 1,QQOHGQLQJ Dette dokumentet er prosjektdirektivet vi har utarbeidet for prosjektet. Det inneholder informasjon om hvordan vi vil gjennomføre prosjektet, og en del bestemmelser som vi akter å følge. Prosjektmandatet i Kapittel 2 inneholder bakgrunnskunnskap om oppgave og kunde, og hva som er prosjektets mål. Prosjektplanen følger i Kapittel 3 hvor man finner informasjon over hvilke faser prosjektet har, og hvor mange timer som er beregnet på hver fase. Det er også i gitt en oversikt over fasene sine start- og sluttdatoer i prosjektplanen. Etter prosjektplanen kommer kapitler om organisering, maler og standarder og versjonskontroll. Disse omhandler vår organisering av de ulike dokumentene vi produserer i prosjektet, og hvordan vi har fordelt roller innad i gruppa. Kapittel 7 og Kapittel 8 som omhandler henholdsvis prosjektoppfølging og kvalitetssikring er av spesiell interesse, siden vi her finner regler som gruppen følger fram mot et resultat. En god prosjektoppfølging er viktig for å sikre at man har kontrollen til enhver tid, mens kvalitetssikring fører til at resultatet blir best mulig. PD - 1

Prosjektmandat Prosjektdirektiv Gruppe 1 3URVMHNWPDQGDW I prosjektmandatet finner man generell informasjon om prosjektet, slik som navn på prosjektet, hvilke interessenter prosjektet har og målene som skal oppnåes. 3URVMHNWQDYQ Prosjektet vårt heter "Brukergrensesnittmoduler for individuell plan". 3URVMHNWVSRQVRU SINTEF Tele og Data (Nils Brede Moe). Prosjektsponsor jobber på oppdrag fra Hiadata AS. Prosjektet er en del av et større prosjekt, SamPro, som er det prosjektet SINTEF og Hiadata AS har gående.,qwhuhvvhqwhu For informasjon om interessentene, se Vedlegg A: Interessenter på side 19. %DNJUXQQIRUSURVMHNWHW I følge Forskrift om individuell plan etter helselovgivningen har pasienter med behov for langvarige og koordinerte helsetjenester rett til å få utarbeidet individuell plan. Det er i denne forbindelse et behov for å utvikle et system som muliggjør elektronisk samhandling rundt den individuelle planen. Se Veileder for individuell plan 2001. (IIHNWPnO Systemet skal bidra til at personer med individuell plan skal oppleve tjenesten forutsigbar og sammenhengende. Systemet skal også være et ledd i å lette arbeidet med individuelle planer. Dette er i sin tur med på å bidra til at tjenestene blir mer effektive og får økt kvalitet. 5HVXOWDWPnO Prosjektet vårt skal resultere i en prototyp for et brukergrensesnitt i forbindelse med arbeidet rundt en individuell plan. Vi skal utvikle noen brukergrensesnittkonsepter som letter utarbeiding og oppfølging av individuelle planer. Disse konseptene vil vi levere i form av prototypen på brukergrensesnittet. Denne protoypen er hovedleveransen i prosjektet. For at SINTEF skal kunne bruke vår prototyp i sitt videre arbeid, så følger det en brukerdokumentasjon til systemet. 3URVMHNWHWVRPIDQJ Prosjektet skal resultere i et web-basert brukergrensesnitt hvor konseptene skal videreutvikles og systemet som helhet skal implementert av SINTEF og Hiadata AS. Vedlagt prototypen skal det også følge en brukerdokumentasjon, som forklarer bruken av systemet, og kan være til hjelp hvis problemer eller uklarheter skulle oppstå. 5DPPHEHWLQJHOVHU Vi har ulike ressurser tilgjengelig i prosjektet. Det første angår tid, da prosjektets periode er satt til 13 uker. En nærmere beskrivelse kommer i punkt 2.9. Vi har vår egen datamaskin i P15- PD - 2

Prosjektmandat Prosjektdirektiv Gruppe 1 bygget, hvor vi har mulighet til å installere den programvaren vi måtte ønske. Denne maskinen skal ikke brukes av andre enn den gruppen den er reservert til. Gruppen har en plassbegrensning på 1GB på IDIs BSCW-server. Hver person i gruppa har en utskriftskvote på 500 sider. Det som skal leveres inn kan kopieres fritt på IDIs kopieringsmaskin på rom 122 i IT-bygget. Annen kopiering koster 50 øre pr. kopi. Kunden har lagt visse føringer i bruk av teknologi og modelleringsverktøy. Det er ønskelig at systemet utvikles med Java (JSP) eller.net. Som modelleringsspråk ønsker kunden at vi bruker UML. Kunden har også bestemt at tilgangen til systemet skal være nettbasert. I forbindelse med utviklingen av det grafiske brukergrensesnittet er det ønskelig at det benyttes en modellbasert utviklingsmetode. Kunden ønsker også at det benyttes kreative workshops i utviklingen av brukergrensesnittet. NRQRPL Prosjektet er beregnet til 310 arbeidstimer pr. person, som over 13 uker blir 24 timer pr. uke. Vår gruppe består av seks personer, og det medfører at totalt antall timer beløper seg til 1860. Det er her viktig å presisere at det er snakk om 60-minutters timer. En del av disse timene vil være bundet til obligatoriske seminarer i gruppedynamikk. 7LG Vi har i hovedsak tre tidsfrister å forholde oss til i forhold til. Den første datoen som er fastsatt er 23. oktober 2003. Dette er datoen for preleveranse av forstudium og kravspesifikasjon. Disse dokumentene leveres inn for å gi sensor en mulighet til å forberede seg til presentasjonen, og det vil ikke være de endelige versjonene av fasedokumentene som leveres. Den endelige versjonen av rapporten skal være klarstilt for kopiering senest 12. november 2003, da kopiering foregår i perioden 10. til 12. november. Datoen for presentasjon og endelig deadline for prosjektet er satt til 13. november 2003. PD - 3

Prosjektplan Prosjektdirektiv Gruppe 1 3URVMHNWSODQ Prosjektplanen sier noe om hvilke faser prosjektet inneholder, og i hvilket tidsrom disse fasene skal gjennomføres. Dokumentet inneholder også informasjon om hvilke hovedaktiviteter som skal finne sted innenfor de ulike fasene. )DVHU Figur 1: Vannfallsmodellen I dette prosjektet kommer vi til å benytte vannfallsmodellen i Figur 1: 'Vannfallsmodellen'. Figuren viser prosjektets framdrift mellom de ulike fasene, og den viser også tilbakekopling mellom kravspesifikasjon og forstudium. Vi ser det som mest sannsynlig å tilbake fra kravspesifikasjonen til forstudiet, hvis det er noe vi ikke har forstått rett eller fått oversikt over. Tilbakekoplingen mellom testing og implementasjon kan forklares ved at vi hele tiden vil teste nye kodebiter for å verifisere at de fungerer korrekt. Dermed vil en del av testfasen overlappe med implementasjonsfasen. Som regel er det enten tilbakekopling mellom hver av fasene i fossefallsmodellen, eller så er tilbakekoblingene utelatt. Vår figur er et avvik fra de originale fossefallsfigurene. Vi har endret figuren for at den skal kunne beskrive vår prosjektprosess i størst PD - 4

Prosjektplan Prosjektdirektiv Gruppe 1 mulig grad. Som figuren viser, har basert oss på å gjennomføre prosjektet etter fasene som er angitt under. Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementering Testing Evaluering Presentasjon og demonstrasjon )DVHUPHGWLOK UHQGHDNWLYLWHWHU Hver fase vil resultere i et tilhørende fasedokument med samme navn som fasen, med unntak av planleggingsfasen der fasedokumentet er prosjektdirektivet. De følgende punktene beskriver de ulike fasene i mer detalj. 3ODQOHJJLQJ I denne fasen skal det utarbeides et prosjektdirektiv. Prosjektdirektivet skal være et dynamiskdokument som beskriver forholdene i prosjektet. Dette skal være referanse for gruppen og kunden, og skal inneholde retningslinjene gruppen forholder seg til underveis. )RUVWXGLH Forstudiets hensikt er å skape en oversikt over problemstillingen og kunnskapsdomenet det befinner seg i. Det er her også viktig å gjøre seg kjent med hvilke utfordringer man står over for. Aktiviteter som inngår i denne fasen er beskrevet i de neste punktene. D/HVHIRUVNULIWHUEDNJUXQQVPDWHULDOH Vi har fått utdelt noen dokumenter som beskriver forskrifter og retningslinjer for problemdomenet. Disse er Veileder for individuell plan 2001, Kortutgave av veileder for individuell plan 2001 og Forskrift om individuelle planer etter helselovgivningen. Det er viktig å få inngående oversikt over disse. Annen nødvendig bakgrunnsinformasjon må også finnes. E/DJHHYDOXHULQJVNULWHULHU Her skal det utvikles retningslinjer som eksisterende systemer kan evalueres ut fra. Forskjellige kriterier vektes etter hvor relevante de er. Disse kriteriene legger grunnlaget når vi skal vurdere eksisterende systemer. F8WOHGHHNVLVWHUHQGHV\VWHPHU Her vil man undersøke markedet for eksisterende løsninger som kan brukes. Disse må beskrives og vurderes ut ifra evalueringskriteriene som er beskrevet. Hvis et tilfredsstillende system allerede eksisterer, så benyttes dette og prosjektet kan avsluttes. G,QWHUYMXHVOXWWEUXNHUH For å få en dypere forståelse av problemet som skal løses, må man snakke med de som i siste instans skal bruke systemet. Det som er viktig å finne er hvilke rutiner som allerede eksisterer, samt positive og negative sider ved disse. Siden det i liten grad finnes systemer for problemet i bruk vil vi i hovedsak bruke kunden (Sintef T&D) som intervjuobjekter. De skal ikke selv bruke systemet, men har allerede gjort grundige undersøkelser i feltet. I denne fasen vil det være rele- PD - 5

Prosjektplan Prosjektdirektiv Gruppe 1 vant å se på problemer med dagens situasjon, og finne ut hvordan sluttbrukerene ønsker at systemet skal fungere..udyvshvlilndvmrq Denne fasen vil til en viss grad overlappe forstudiet, siden de funksjonelle kravene er en detaljering av evalueringskriteriene fra forstudiet. D6SHVLILNDVMRQDYIXQNVMRQHOOHNUDY Her vil vi formalisere tidligere uttrykte krav. Kunden har allerede en delvis klar kravspesifikasjon, noe som vil medføre at vi kan fokusere mer på utviklingen av det grafiske grensesnittet og implementasjonen. Kunden ønsker også at vi skal fokusere på det grafiske designet, framfor at systemet skal ha full funksjonalitet. E6SHVLILNDVMRQDYLNNHIXQNVMRQHOOHNUDY Vi vil presisere hvilke ikke-funksjonelle krav som systemet skal støtte. Dette omhandler ting responstid og krav til programvare som sluttbrukeren trenger. F2YHURUGQHWSURJUDPDUNLWHNWXU Figur 2: Overordnet programarkitektur Vår applikasjon ligger mellom databasen og web-tjener programmet, slik Figur 2: 'Overordnet programarkitektur' illustrerer. På venstre side har applikasjonen kontakt med en database over individuelle planer og på høyre side vil applikasjonen ha kontakt med et web-tjenerprogram. Her får sluttbrukeren presentert data på det formatet som vår applikasjon tilbyr. G7HVWSODQ Testplanen skal gjøre det mulig å verifisere at kravene er tilfredsstilt etter implementeringen. Planen som utarbeides her er overordnet, og skal utarbeides før kravspesifikasjonsfasen avsluttes. Den vil komme i et eget testdokument, som senere også vil inneholde testrapporten. Testplanen skal gjøres mer detaljert ved oppstart av testfasen. Planen inneholder oversikt over hvilke tester som skal gjennomføres i prosjektet, hvilke tester det skal utarbeides sjekklister for, hvilke tester det skal utarbeides detaljerte testspesifikasjoner for..rqvwuxnvmrq I denne fasen vil vi ta steget fra den overordnede systembeskrivelsen og ned til en realiserbar spesifikasjon. Detaljnivået her skal være så detaljert at vi ser at det går an å lage systemet på denne måten, og slik at programmeringsfasen kan planlegges. PD - 6

Prosjektplan Prosjektdirektiv Gruppe 1 D7HNQRORJLEHVNULYHOVH Her skal man bestemme hvilken teknologi man vil benytte for å løse problemet. Man må beskrive valgene man gjør. Med tanke på valg av programmeringsspråk står valget mellom.net og Java, etter kunden sitt ønske. Vi vil også vurdere PHP som en mulig teknologi, siden vi har en del ferdigheter i forbindelse med denne teknologien. E'HWDOMHUWSURJUDPDUNLWHNWXU Det vil i denne aktiviteten utvikles klassediagrammer for systemet som helhet. Vi vil ha et klassediagram over ulike datatyper, som har sitt utgangspunkt i domenemodellen. I tillegg vil vi ha et klassediagram over hvordan systemets nettsider henger sammen, og hva slags type sider disse er. F'HVLJQDYEUXNHUJUHQVHVQLWW Denne aktiviteten går på design av brukergrensesnittet, og kunden legger meget stor vekt på denne aktiviteten. Aktiviteten vil foregå på den måten av vi utvikler papirskisser av brukergrensesnittet, og disse diskuteres med kunden i kreative workshops. Dette vil foregå i flere iterasjoner, til både kunden og vi er fornøyde med resultatet. Dette vil være en aktivitet som vil ta en del tid, men vi vurderer den til en av de viktigste aktivitetene i utviklingen av systemet. G.RQNUHWGHVLJQ Denne aktiviteten vil bestå av å realisere brukergrensesnittet designet i punkt 3.2.4.c. Det er viktig at designet av brukergrensesnittet er realiserbart i praksis, men at aktiviteten som skal utvikle det konkrete designet heller ikke legger for store føringer. Vi ser det som viktig å klare å balansere dette forholdet. H'HWDOMHUWWHVWSODQ Denne aktiviteten går på å utvide testplanen til å inneholde tester for implementasjonen. Det skal settes opp en plan for hver enkelt test som skal gjennomføres, og man skal utarbeide detaljerte testspesifikasjoner eller sjekklister for hver test. Vi vil presentere de testdata vi vil bruke under testingen. I,QIRUPDVMRQVRJGRPHQHPRGHOO Vi skal konstruere en informasjons- og domenemodell. Dette gjøres for at vi overfor kunden viser at vi har forstått domenet rett og at de data vi modellerer er relevante. I tillegg vil informasjonsmodellen ligge til grunn for hvordan databasen skal designes.,psohphqwhulqj Denne fasen går i korte trekk ut på å utvikle selve programkoden for systemet. D3URJUDPPHULQJ Denne aktiviteten vil bestå av å skrive koden for systemet. Vi vil også foreta enhets- og modultestene i denne aktiviteten. E'RNXPHQWHULQJ Aktiviteten går ut på å skrive brukerdokumentasjon og installasjonsveiledning. Disse dokumentene skal være til hjelp under bruk av systemet. PD - 7

Prosjektplan Prosjektdirektiv Gruppe 1 7HVWLQJ Etter at implementeringsfasen er ferdig, vil det oppstå et behov for å teste systemet man har laget. I testfasen vil vi gjennomføre ulike tester for å verifisere at systemet oppfyller kravene fra kravspesifikasjonen. D*MHQQRPI ULQJDYWHVWHU Testplanen som ble laget i kravspesifikasjonsfasen og konstruksjonsfasen skal gjennomføres. Her skal det også foregå retting av feil, gjen-testing og dokumentasjon av testresultatene. Testresultatene vil foreligge i en testrapport som vil finnes i testdokumentet. E$NVHSWDQVHWHVW Kunden vil oversendes en sjekkliste på krav som er realisert i systemet, og godkjenne disse. (YDOXHULQJ På slutten av prosjektet er det tid for evaluering av de ulike trinnene i prosessen, samarbeid med kunden og faget generelt. Vi vil også vurdere hvor mye arbeid som gjenstår før systemet kan sees på som ferdig. På grunn av at vi kan glemme de tidlige fasene mot slutten av prosjektet, vil vi ha en evaluering etter hver fase. Dette mener vi vil øke kvaliteten på evalueringen. D3URVHVVRJUHVXOWDW Gruppeprosessen skal vurderes. Vi vil se på hvor mange timer som ble brukt og hvor godt samarbeidet i gruppa fungerte. I all hovedsak skal vi vurdere om de oppsatte planer ble fulgt. E2SSJDYHQ Vi vil gi en evaluering av oppgaven, og hvordan vi oppfattet denne. Dette vil gå på hvor omfattende den er og hvordan den var formulert. F.XQGHQ Vi vil gjøre en vurdering av hvordan kunden har opptrådt, og hvordan kommunikasjonen med kunden har vært. G)DJHW Denne evalueringen går på ulike sider av faget som helhet. Dette innebærer en vurdering av veilederene vi har hatt. H9LGHUHDUEHLG Under dette punktet vil vi gi en vurdering av hvor mye arbeid som gjenstår før systemet er helt ferdig. 3UHVHQWDVMRQRJGHPRQVWUDVMRQ Den 13. november er det satt av tid til presentasjon og demonstrasjon av prosjektet og resultatene. Dette er en viktig del av prosjektet, og denne delen krever derfor litt forberedelse på ulike punkter. D/DJHSUHVHQWDVMRQVPDQXV Planlegging av framføring etter avslutning av evalueringsfasen. Det er avsatt 20 minutter til presentasjon, og deretter 20 minutter til en demonstrasjon av systemet. PD - 8

Prosjektplan Prosjektdirektiv Gruppe 1 E/DJHWUDQVSDUHQWHU Transparenter må lages for å støtte opp under presentasjonen av produktet. F/DJHGHWDOMHUWGHPRQVWUDVMRQVSODQ Det er satt av 20 minutter til demonstrasjon, og det må i forkant vurderes hva vi skal velge å vise fram av produketet og hvor det er nødvendig å forklare detaljer. G YLQJ Vi må øve på framføring av presentasjonen og demonstrasjonen. Vi må også være godt forberedt på 5 minutter med spørsmål fra sensor. H3UHVHQWDVMRQ Selve presentasjonen skal foregå den 13.november. 0LOHS OHU I forbindelse med milepælene vil vi cirka en uke i forkant oversende materialet slik det foreligger til kunden for en vurdering. Kunden har da mulighet til å komme med innspill før endelig ferdigstillelse av dokumentet. Vi har laget et overordnet Gantt-diagram som viser prosjektets ulike faser med start- og sluttdato. Diagrammet kan sees i Figur 3: 'Overordnet Gantt-diagram'. ID Fase-/Milepælnavn Start Slutt Aug 2003 Sep 2003 Oct 2003 Nov 2003 17.8 24.8 31.8 7.9 14.9 21.9 28.9 5.10 12.10 19.10 26.10 2.11 9.11 1 Planlegging 19.08.2003 13.11.2003 2 Forstudie 28.08.2003 16.09.2003 3 Evaluering 16.09.2003 16.09.2003 4 Kravspesifikasjon 09.09.2003 03.10.2003 5 Evaluering 03.10.2003 03.10.2003 6 Konstruksjon 26.09.2003 17.10.2003 7 Evaluering 17.10.2003 17.10.2003 Preleveranse, forstudie 8 23.10.2003 23.10.2003 og kravspesifikasjon 9 Implementering 10.10.2003 31.10.2003 10 Evaluering 31.10.2003 31.10.2003 11 Testing 31.10.2003 04.11.2003 12 Evaluering 04.11.2003 07.11.2003 13 Rapport klarstilt 10.11.2003 10.11.2003 Presentasjon og 14 31.10.2003 13.11.2003 demonstrasjon Figur 3: Overordnet Gantt-diagram 7LPHU Vi har satt opp antall timer vi vil bruke på de ulike fasene på bakgrunn av tidligere års erfaringer. Tallene vil bli justert etter evalueringer gjennom prosjektperioden. Fordelingen av timer kan PD - 9

Prosjektplan Prosjektdirektiv Gruppe 1 sees i Tabell 1:. Summen av alle fasene gir 1734 timer. Dette betyr at 126 av de 1860 timene vi hadde til rådighet i utgangspunktet går med til forelesninger, seminarer og prosjektledelse. Fase Timer Planlegging 126 Forstudie 372 Kravspesifikasjon 372 Konstruksjon 288 Implementasjon 288 Testing 90 Evaluering 54 Presentasjon 144 Totalt 1734 7DEHOO7LPHIRUEUXN PD - 10

Organisering Prosjektdirektiv Gruppe 1 2UJDQLVHULQJ Under organisering omtales gruppens struktur og fordeling av roller i nærmere detalj. 5ROOHU Even Aasland Prosjektleder 915 50 228 evenaa@stud.ntnu.no Gunnar René Øie Dokumentansvarlig 976 04 652 gunnarre@stud.ntnu.no Julie-Marie Foss Testansvarlig 986 36 889 juliemar@stud.ntnu.no Kay Are Ulvestad Integrasjonsansvarlig 411 06 009 kayare@stud.ntnu.no Knut Bjørnar Wålberg Kundekontakt 975 61 947 walberg@stud.ntnu.no Sigmund Augdal Presentasjonsansvarlig 918 09 129 sigmunau@stud.ntnu.no Figur 4: Organisasjonskart Figur 4: 'Organisasjonskart' Viser organisasjonskartet til prosjektgruppen. Strukturen er tilnærmet flat, med prosjektleder hevet litt over de andre. Vi har valgt å fordele rollene slik: 7DEHOO5ROOHIRUGHOLQJ Rolle Navn Beskrivelse Prosjektleder Even Aasland Prosjektleder er overordnet ansvarlig for prosjektet. Har ansvar for å holde oversikt over hvem som gjør hva, og at tidsfrister holdes. Prosjektlederen vil også være møteleder, og sende ut møteinnkallelser til veiledermøtene. Testsjef Julie-Marie Foss Testsjef er ansvarlig utarbeidelse og gjennomføring av testplan. Integrasjonsansvarlig Dokumentansvarlig Presentasjonsansvarlig Kundekontakt Sigmund Augdal Gunnar René Øie Kay Are Ulvestad Knut Bjørnar Wålberg Integrasjonsansvarlig er ansvarlig for å at modulene som utvikles fungerer sammen. Dokumentansvarlig har ansvaret for å utvikle maler for de dokumenter som skal produseres. I tillegg skal dokumentene ha en konsekvent layout. Presantattør er ansvarlig for presentasjonen, og dens forberedelser. Kundekontakten skal stå for all kontakt mellom gruppa og kunden. Denne har også ansvar for å sende ut møteinnkallelser til kundemøtene. PD - 11

Maler og standarder Prosjektdirektiv Gruppe 1 0DOHURJVWDQGDUGHU Dette kapitlet omtaler de maler og standarder som gruppen har vedtatt å benytte. Dette gjelder alt fra dokumenter, kataloger og filnavn til kodestandard for implementering. 'RNXPHQWPDOHU Dette prosjektdirektivet brukes som mal på fasedokument. Dokumentansvarlig vil tilpasse den endelige innleveringen. Andre maler ligger i Vedlegg B: Maler på side 21. Eksempel på forside finnes på side 22. Eksempel på innkalling til veiledermøte finnes på side 23. Eksempel på innkalling til kundemøte finnes på side 24. Eksempel på referat fra veiledermøte finnes på side 25. Eksempel på referat fra kundemøte finnes på side 26. Eksempel på statusrapport til veiledere finnes på side 27. Eksempel på statusrapport til kunde finnes på side 30..RGHVWDQGDUG Vi skal benytte Code Conventions for the JavaTM Programming Language (http://java.sun.com/docs/codeconv/html/codeconvtoc.doc.html) for all programkode vi skriver. Vi skal utvikle en standard for formatering av html-kode vi skriver..dwdorjvwuxnwxu Kpro_Gruppe1 Felles Intern * * * * * * Figur 5: Illustrasjon av katalogstruktur Dokumentansvarlig har laget en katalogstruktur på BSCW slik at gruppen har en intern katalog og en katalog hvor dokumenter beregnet på kunder og veiledere legges ut. En skisse over starten på katalogstrukturen kan sees i Figur 5: 'Illustrasjon av katalogstruktur'. Detaljert katalogstruktur kan sees i Vedlegg C: Katalogstruktur på side 31. PD - 12

Maler og standarder Prosjektdirektiv Gruppe 1 )LOQDYQ En felles standard for å navngi filer er viktig slik at alle på gruppa entydig vet hva filer inneholder ved å se navnet. Navn på filer og kataloger får ikke inneholde mellomrom. Mellomrommet kan fjærnes, eller erstattes med understrekning _ eller bindestrek -. Disse filnavnene kan avsluttes med vanlig filtype-postfiks, for eksempel ".txt", ".pdf", ".fm", ".book", eller ".html" (uten hermetegn eller komma). DDMMÅÅ er dato for møtet som dokumentet gjelder. DD er dag i måneden. MM er måned, og ÅÅ er to siste siffer i årstallet. Eksempel: Innkalling_veileder030903.pdf D)DVHGRNXPHQWHU Basisnavnet for filene vil være navnet på fasen, for eksempel "Prosjektdirektiv" eller "Kravspesifikasjon". Det dokumentet du leser nå vil ganske enkelt bli kalt "Prosjektdirektiv". Det vil altså bestå av filer som "Prosjektdirektiv.book", "ProsjektdirektivTOC.fm", "ProsjektdirektivLOT.fm" osv. Vedlegg, bilder og andre filer som settes inn i dokumentene kan navngis rimelig fritt, men de må avsluttes med filtype-postfiks. NB: Fasedokumenter trenger ikke ha med dato i filnavnet sitt. Det er lov å legge på datoen i utgaver som skal "publiseres" til kunden eller veiledere. E0 WHLQQNDOOLQJHU "Innkalling_kundeDMMÅÅ" "Innkalling_veilederDDMMÅÅ" F0 WHUHIHUDWHUHU "Referat_interntDDMMÅÅ" "Referat_kundeDMMÅÅ" "Referat_veilederDDMMÅÅ" G6WDWXVGRNXPHQWHUWLOYHLOHGHUP WHU "Status_veilederDDMMÅÅ" H6WDWXVGRNXPHQWHUWLONXQGHP WHU "Status_kundeDDMMÅÅ" 7HUPLQRORJL Terminologiene brukt innenfor helsevesen, andre offentlige etater, og informasjonsteknologi, kan "kollidere". Ord kan bety noe annet innenfor ulike områder. For å klargjøre betydningen av sentrale ord og uttrykk, vil vi inkludere ordlister i fasedokumenter der det regnes som nødvendig. Prosjektdirektivet vil inneholde en ordliste for hele rapporten, der sentrale ord i rapporten forklares. Ordlisten finnes i Vedlegg D: Ordliste på side 33. Hvis det er uenighet om hva ord og uttrykk skal bety, tas dette opp på et møte. PD - 13

Versjonskontroll Prosjektdirektiv Gruppe 1 9HUVMRQVNRQWUROO Vi har valgt å bruke BSCW som verktøy for deling av teksdokumenter. I tillegg har vi valgt å innføre visse regler i tilknytning til BSCW for å sikre at det alltid er gjeldende versjon som ligger ute. Dette gjøres ved at vi benytter BSCWs funksjon for versjonsnummer, i tillegg til at vi alle har ansvaret for å arbeide på den nyeste versjonen av en gitt fil. For å få til dette er vi avhengig av å ha en rutine på å gi klare beskjeder om hvilke arbeidsoppgaver vi jobber med, og hvilke dokumenter disse arbeidsoppgavene omfatter. Vi vil også benytte låsefunksjonen i BSCW, og denne låsen skal ikke overtas av annet gruppemedlem hvis dette ikke er avtalt eller absolutt nødvendig. Det er en fare for at BSCW-tjeneren kan slutte å virke. For å unngå at arbeid mistes, har vi iverksatt følgende tiltak: Det tas sikkerhetskopi av BSCW-tjeneren. Gunnar René Øie skal fortrinnsvis gjøre dette hver dag, unntatt helg og helligdager. Medlemmene i studentgruppen må ikke slette en fil som de har endret på fra sitt eget filsystem, før de har hentet ned en nyere versjon av filen fra BSCW-tjeneren. Ved bortfall av BSCW-tjeneren velges en koordinator som samler alle filer, helst med utgangspunkt i sikkerhetskopi. PD - 14

Prosjektoppfølging Prosjektdirektiv Gruppe 1 3URVMHNWRSSI OJLQJ For at vi lettere skal kunne ha oversikt over prosjektet, har vi satt opp visse punkter angående prosjektoppfølging. 3URVMHNWP WHU Vi har interne møter på gruppa hver mandag kl. 09.15. Det hadde vært ideelt med flere faste møte i uka, men det er vanskelig å få til å gå opp med timeplanen. De andre møtene vi har i uka avtales derfor ved behov, eller på det faste interne møtet. Det interne møtet på mandager går ut på å gjøre opp status. Faste punkter på agendaen er timerapportering og oppsummering av arbeid siste periode.,qwhuqudsruwhulqj Vi har en ukentlig timerapportering. Denne foregår gjerne på gruppemøtene på mandager. Vi har et regneark for timeregistrering, slik at vi kan holde styr på hvor mange timer som er brukt på hver fase. Vi ser også hvor mye tid som vi regner med å ha igjen for hver av fasene. Vi teller timer per uke med start på mandag, og periodeavslutning på søndag Vi har en rapportering innad i gruppa som går på hvilke oppgaver folk driver med til enhver tid. Dette gjøres fortløpende i prosjektperioden, ettersomman går over på en ny aktivitet eller det er andre endringer i arbeidet. Dette er som følger at pkt. 5 viktig med hensyn til versjonskontroll. For å analysere framdriften i prosjektet, ser vi på hvilke milepæler som er nådd/ikke nådd, eventuelt hvordan vi ligger an i rute til førstkommende milepæl. Tiltak iverksettes avhengig av hvordan vi ligger an. Dette kan for eksempek være å kutte ned omfanget til en oppgave, eller flytte tidsfristen. 6WDWXVUDSSRUWHULQJ I forbindelse med de ukentlige veiledermøtene vil vi levere en statusrapport for godkjenning. Denne inneholder informasjon om hvilket arbeid som er utført den siste uken, hvilke problemer vi har støtt på og hva vi har planlagt å gjøre den neste perioden. I tillegg inneholder statusrapporten et TROKK-dokument, som sier noe om tid, risiko, omfang, kostnad og kvalitet. Kunden har bedt om å få tilsendt en statusrapport for hver uke. Dette skal kort omfatte hva som er gjort og hva som gjenstår innenfor hver fase. Dette dokumentet har ikke fokus på organisering, og skiller seg derfor ut fra statusrapport til veileder. Rapporten merkes med rød, gul eller grønn farge. Grønn betyr at det ikke er noen problemer med aktiviteten, mens rød betyr at man ikke er i rute. Gul er en mellomting mellom de to foregående. 5LVLNRKnQGWHULQJ For risikohåndtering benytter vi et såkalt TROKK-dokument. Dette inneholder informasjon om hvordan vi ligger an i tid, hvilke risikomomenter vi må ta stilling til og hvilke tiltak vi eventuelt må iverksette, hvilket omfang prosjektet har og om omfanget er stabilt eller i endring, hvor mange timer vi har brukt og hvordan dette samsvarer med budsjettet og til sist inneholder dokumentet et punkt om kvalitet. Hvis det er noe som fører til at produktets kvalitet må reduseres, så er det beskrevet her. Kunden vil bli kontaktet dersom en kvalitetsreduksjon blir nødvendig. TRO- PD - 15

Prosjektoppfølging Prosjektdirektiv Gruppe 1 KK-dokumentet vil da oversendes kunden, og vi blir enige om hvor kvalitetsreduksjonen skal finne sted..rqiolnwknqgwhulqj De store konfliktene som oppstår vil bli tatt opp innad i gruppa. Ved uenigheter angående et valg, vil vi benytte avstemning. Hvis noen sitter med en oppfatning av at enkelte personer ikke arbeider nok med prosjektet, vil dette også i første omgang løses i gruppa. Vi forsøker så godt vi kan å oppdage konflikter på et tidlig stadium, slik at konfliktene ikke får lov å vokse seg store før de blir løst. Hvert enkelt gruppemedlem kan be om et konfliktløsende møte dersom dette skulle være nødvendig. PD - 16

Kvalitetssikring Prosjektdirektiv Gruppe 1.YDOLWHWVVLNULQJ For å sikre kvaliteten til prosjektet og resultatet, er vi bevisste på en del faktorer som kan være med å bidra til dette. 5HVSRQVWLGHU Under følger de responstider vi har avtalt med kunden og veileder. )UDNXQGHWLOJUXSSH Godkjenning av tilsendt møtereferat Referatet godkjennes før neste kundemøte. Hvis det er store uenigheter mellom partene, så diskuteres dette over e-post. Tilbakemelding og godkjenning av fasedokumenter til gjennomsyn Kunden skal gi tilbakemelding innen fire dager. Dokumentet må overleveres kunden senest én uke før endelig ferdigstillelse, slik at kundens kommentarer kan tas til følge. Svare på spørsmål Kunden skal innen 24 timer på hverdager bekrefte at spørsmålet fra gruppen er mottatt. Deretter avtales tid til svaret skal foreligge avhengig av spørsmålets omfang. Skaffe til veie avtalte dokumenter Avtales for hvert dokument. )UDJUXSSHWLONXQGH Utlevering av møtereferat for godkjenning Møtereferat legges ut på BSCW kl. 12.00 dagen etter møtet har funnet sted. )UDYHLOHGHUWLOJUXSSH Veileder skal innen 24 timer på hverdager bekrefte at spørsmålet fra gruppen er mottatt. Deretter avtales tid til svaret skal foreligge avhengig av spørsmålets omfang. )UDJUXSSHWLOYHLOHGHU Gruppen skal på lik linje med veileder bekrefte at spørsmålet er mottatt innen 24 timer på hverdager. Også denne veien avtales en tid for når svaret skal foreligge.,qqdgljuxsshq Timeraportering Gruppen rapporterer timebruk gjennom de ukentlige statusrapportene. 0 WHLQQNDOOLQJWLONXQGHQ Kunden skal motta en e-post senest klokken 12.00 en dag før møtet skal finne sted. Denne e- posten inneholder informasjon om at den formelle innkallingen samt nødvendige dokumenter for møtet ligger på BSCW. Dokumentene som legges ut skal datomerkes, slik at kunden ikke er i tvil om at det er de riktige dokumentene som er hentet ned. Møtetidspunktet skal være avtalt lenge før møteinnkallingen sendes. Normalt avtales dette på forrige kundemøte. PD - 17

Kvalitetssikring Prosjektdirektiv Gruppe 1 0 WHUHIHUDWIUDNXQGHP WH Gruppen legger ut møtereferat på BSCW for godkjenning senest klokken 12.00 dagen etter at møtet har funnet sted. Møtereferatene fra kundemøtene skal også inngå i agendaen på de ukentlige veiledermøtene. 0 WHLQQNDOOLQJHUWLOYHLOHGHU Møteinnkallinger til veiledermøte skal sendes senest kl. 12.00 dagen før møtet. Møtet bestemmes av møteplanen som gruppen har mottatt fra veileder. Innkallingen sendes til veileder per e- post, og dokumenter som skal gjennomgås på møtet skal være vedlegg til denne e-posten. Alle veiledermøter har denne fastsatte agendaen: 1. Godkjenning av dagsorden 2. Godkjenning av referat fra forrige veiledermøte 3. Kommentarer til møtereferat fra siste kundemøte 4. Godkjenning av statusrapport 5. Gjennomgang/godkjenning av vedlagte fasedokumenter 6. Andre saker 7. Eventuelt 0 WHUHIHUDWIUDYHLOHGHUP WHU Møtereferatet legges ved neste veiledermøte og er sak 2 på den faste agendaen for møtene. 5XWLQHUIRUnSURGXVHUHNYDOLWHWI UVWHJDQJ Vi kommer til å utarbeide en klar spesifikasjon av systemet før implementeringen starter. Dermed vil vi være bedre rustet for å utvikle rett produkt, enn om vi skulle gå rett i gang med selve kodingen. Når vi sitter med en kodebit som fungerer, vil denne bli kommentert slik at det er lett for andre å forstå denne koden. Vi vil følge Code Conventions for the JavaTM Programming Language, se pkt. 5.2, som vil standardisere koden. 5XWLQHUIRUJRGNMHQQLQJDYIDVHGRNXPHQWHU Gruppen kommer til å legge fasedokumenter fortløpende ut på BSCW ettersom revideringer finner sted. Når et dokument er klart til gjennomsyn av gruppa, vil dette bli opplyst og alle kommer med eventuelle kommentarer. De siste endringer gjøres før innlevering. PD - 18

Interessenter Prosjektdirektiv Gruppe 1 9HGOHJJ$,QWHUHVVHQWHU 6WXGHQWJUXSSHQ Even Aasland Brøsetvegen 153-28 7050 Trondheim mobil : 915 50 228 e-post: evenaa@stud.ntnu.no Julie-Marie Foss Klostergata 32A 7030 Trondheim mobil : 986 36 889 e-post: juliemar@stud.ntnu.no Kay Are Ulvestad Herman Krags veg 1-11 7050 Trondheim mobil : 411 06 009 e-post: kayare@stud.ntnu.no Knut Bjørnar Wålberg Nardoskrenten 1B 7032 Trondheim mobil : 975 61 947 e-post: walberg@stud.ntnu.no Sigmund Augdal Edgar B. Schieldrops veg 29-14 7033 Trondheim mobil : 918 09 129 e-post: sigmunau@stud.ntnu.no Gunnar René Øie Herman Krags veg 9-23 7050 Trondheim mobil : 976 04 652 fax : 978 49 589 e-post: gunnarre@stud.ntnu.no.xqgh Nild Brede Moe <nils.b.moe@sintef.no> SINTEF Tele og data Telefon: 73593000 PD - 19

Interessenter Prosjektdirektiv Gruppe 1 Fax: 73592977 Mobil: 93028687 Lillian Røstad <lillian.rostad@sintef.no> SINTEF Tele og data Telefon: 73593000 Fax: 73592977 Mobil: 99400628 9HLOHGHUH Margrethe Aune, hjelpeveileder, <margra@stud.ntnu.no> Ola Stenseth, hovedveileder, <Ola.Stenseth@stolav.no> PD - 20

Maler Prosjektdirektiv Gruppe 1 9HGOHJJ%0DOHU Dette vedlegget inneholder maler for dokumenter som skal brukes i prosjektet. PD - 21

Norges teknisk-naturvitenskapelige universitet (NTNU) Fakultet for informasjonsteknologi, matematikk og elektronikk (IME) Institutt for datateknikk og informasjonsvitenskap (IDI) Gruppe 1 TDT4290 Kundestyrt prosjekt, høst 2003 3URVMHNWHWVWLWWHO )RUVLGH,QQOHYHUW 7LOJMHQJHOLJKHW 6WXGHQWHU 2SSGUDJVJLYHU $QWDOOVLGHULKRYHGGRNXPHQW 7UHVWLNNRUG 9HLOHGHUH

NTNU Gruppe 1 Norges teknisk-naturvitenskapelige TDT4290 Kundestyrt prosjekt, høst 2003 universitet IDI, IME, NTNU 0 WHLQQNDOOLQJ Til: Siv.ing. Ola Stenseth, hovedveileder, <Ola.Stenseth@stolav.no> Stud. techn. Margrethe Aune, hjelpeveileder <margra@stud.ntnu.no> Stud. techn. Even Aasland, gruppemedlem <evenaa@stud.ntnu.no> Stud. techn. Sigmund Augdal, gruppemedlem <sigmunau@stud.ntnu.no> Stud. techn. Julie-Marie Foss, gruppemedlem <juliemar@stud.ntnu.no> Stud. techn. Knut Bjørnar Wålberg, gruppemedlem <walberg@stud.ntnu.no> Stud. techn. Kay Are Ulvestad, gruppemedlem <kayare@stud.ntnu.no> Stud. techn. Gunnar René Øie, gruppemedlem <gunnarre@stud.ntnu.no> Kopi til: *MHOGHU)RUVWXGLXPLNXQGHVW\UWSURVMHNW Møtetid: Onsdag 3. september 17.15-18.00 Møtested: IT-142. 6DNVOLVWH 6DN*RGNMHQQLQJDYGDJVRUGHQ 6DN*RGNMHQQLQJDYP WHUHIHUDWIUDIRUULJHYHLOHGHUP WH 6DN.RPPHQWDUHUWLOP WHUHIHUDWIUDVLVWHNXQGHP WH 6DN*RGNMHQQLQJDYVWDWXVUDSSRUW 6DN*MHQQRPJDQJJRGNMHQQLQJDYYHGODJWHIDVHGRNXPHQWHU 6DN(YHQWXHOW 9HGOHJJ Referat fra forrige veiledermøte. Referat fra evt. møter med kunden siden sist. Statusrapport til veileder Fasedokumenter: Side 23 av 30

NTNU Gruppe 1 Norges teknisk-naturvitenskapelige TDT4290 Kundestyrt prosjekt, høst 2003 universitet IDI, IME, NTNU 0 WHLQQNDOOLQJ Til: MSc Nils Brede Moe, SINTEF Tele og data (kunden) <nils.b.moe@sintef.no> MSc Lillian Røstad, SINTEF Tele og data (kunden) <Lillian.Rostad@sintef.no> Stud. techn. Even Aasland, gruppemedlem <evenaa@stud.ntnu.no> Stud. techn. Sigmund Augdal, gruppemedlem <sigmunau@stud.ntnu.no> Stud. techn. Julie-Marie Foss, gruppemedlem <juliemar@stud.ntnu.no> Stud. techn. Knut Bjørnar Wålberg, gruppemedlem <walberg@stud.ntnu.no> Stud. techn. Kay Are Ulvestad, gruppemedlem <kayare@stud.ntnu.no> Stud. techn. Gunnar René Øie, gruppemedlem <gunnarre@stud.ntnu.no> Kopi til: *MHOGHU)RUVWXGLXPLNXQGHVW\UWSURVMHNW Møtetid: Fredag 5. september 15.00-16.00 Møtested: SINTEF Tele og data. 6DNVOLVWH 6DN*RGNMHQQLQJDYP WHLQQNDOOLQJPHGVDNVOLVWH 6DN*RGNMHQQLQJDYUHIHUDWIUDIRUULJHNXQGHP WH 6DN7LOEDNHPHOGLQJSnSURVMHNWSODQ 6DN 6DN(YHQWXHOW 6DN.ULWLNNDYP WHW 9HGOHJJKHQWHVQHGIUD%6&: Referat fra forrige kundemøte. Statusrapport til kunde Fasedokumenter: Side 24 av 30

NTNU Gruppe 1 Norges teknisk-naturvitenskapelige TDT4290 Kundestyrt prosjekt, høst 2003 universitet IDI, IME, NTNU 5HIHUDW Til stede: Siv.ing. Ola Stenseth, hovedveileder, <Ola.Stenseth@stolav.no> Stud.techn. Margrethe Aune, hjelpeveileder <margra@stud.ntnu.no> Stud. techn. Even Aasland, gruppemedlem <evenaa@stud.ntnu.no> Stud. techn. Sigmund Augdal, gruppemedlem <sigmunau@stud.ntnu.no> Stud. techn. Julie-Marie Foss, gruppemedlem <juliemar@stud.ntnu.no> Stud. techn. Knut Bjørnar Wålberg, gruppemedlem <walberg@stud.ntnu.no> Stud. techn. Kay Are Ulvestad, gruppemedlem <kayare@stud.ntnu.no> Stud. techn. Gunnar René Øie, gruppemedlem <gunnarre@stud.ntnu.no> Forfall: Kopi til: *MHOGHU)RUVWXGLXPLNXQGHVW\UWSURVMHNW Møtetid: Tirsdag 27. august 16.15-17.00 Møtested: IT-142.. Referent:Gunnar René Øie 6DN*RGNMHQQLQJDYGDJVRUGHQ 6DN*RGNMHQQLQJDYP WHUHIHUDWIUDIRUULJHYHLOHGHUP WH 6DN.RPPHQWDUHUWLOP WHUHIHUDWIUDVLVWHNXQGHP WH 6DN*RGNMHQQLQJDYVWDWXVUDSSRUW 6DN*MHQQRPJDQJJRGNMHQQLQJDYYHGODJWHIDVHGRNXPHQWHU 6DN(YHQWXHOW Side 25 av 30

NTNU Gruppe 1 Norges teknisk-naturvitenskapelige TDT4290 Kundestyrt prosjekt, høst 2003 universitet IDI, IME, NTNU 5HIHUDW Til stede: MSc Nils Brede Moe, SINTEF Tele og data (kunden) <nils.b.moe@sintef.no> MSc Lillian Røstad, SINTEF Tele og data (kunden) <Lillian.Rostad@sintef.no> Stud. techn. Even Aasland, gruppemedlem <evenaa@stud.ntnu.no> Stud. techn. Sigmund Augdal, gruppemedlem <sigmunau@stud.ntnu.no> Stud. techn. Julie-Marie Foss, gruppemedlem <juliemar@stud.ntnu.no> Stud. techn. Knut Bjørnar Wålberg, gruppemedlem <walberg@stud.ntnu.no> Stud. techn. Kay Are Ulvestad, gruppemedlem <kayare@stud.ntnu.no> Stud. techn. Gunnar René Øie, gruppemedlem <gunnarre@stud.ntnu.no> Forfall: Kopi til: Siv.ing. Ola Stenseth, hovedveileder, <Ola.Stenseth@stolav.no> Stud. techn. Margrethe Aune, hjelpeveileder <margra@stud.ntnu.no> *MHOGHU)RUVWXGLXPLNXQGHVW\UWSURVMHNt Møtetid: Torsdag 28. august 9.15-10.00 Møtested: SINTEF Tele og data Referent:Gunnar René Øie. 6DN*RGNMHQQLQJDYP WHLQQNDOOLQJPHGVDNVOLVWH 6DN*RGNMHQQLQJDYUHIHUDWIUDIRUULJHNXQGHP WH 6DN7LOEDNHPHOGLQJSnSURVMHNWSODQ 6DN 6DN(YHQWXHOW 6DN.ULWLNNDYP WHW Side 26 av 30

Maler Prosjektdirektiv Gruppe 1 6WDWXVUDSSRUWWLOYHLOHGHUP WHVHSWHPEHU Rapporten gjelder for perioden fra 25. august til 31. august. 2SSVXPPHULQJ Gruppen regner prosjektdirektivet klart for å tas ibruk. Gruppen er igang med forstudiet. 8WI UWDUEHLGLSHULRGHQ 'RNXPHQWHU Utfylling av prosjektdirektiv. Grovplanlegging med kunden. Startet å utarbeide forstudiet. 0 WHU Kundemøte fredag 29. august. Internt møte 1. september. $NWLYLWHWHU Utarbeidelse av prosjektdirektiv med tilhørende planleggingsaktiviteter. Beskrivelse av dagens situasjon og utarbeidelse av vurderingskriterier. $QQHW Forelesninger. PD - 27

Maler Prosjektdirektiv Gruppe 1 752..PDYYLNRJWLOWDN 7LG Neste milepæl: Ferdig med forstudium: 16. september. Dette arbeidet er ikke skikkelig i gang ennå. KPro 2003 Gruppe 1 STATUSOVERSIKT Pros jekt : B rukergrens es nittmoduler for individuell plan Uke nr.: 37 2003 Ajour pr. 15.09 Prosjektnr. : Dato: 08.09-14.09 Akt Beskrivelse Opprinnelig plan Brukt Brukt hittil Estimat Estimat Tjente Produktivitet Planlagt Fremdrift Fremdrift nr. denne uke gjenst. totalt timer oppnådd avvik Forelesninger/S eminar 126 0 100,43 25,58 126 100,43 100 % 94,5 106 % 5,925 Planlegging 126 7 119,5 6,5 126 119,5 100 % 38,7 309 % 80,8 Forstudie 372 59 154 218 372 154 100 % 334,8 46 % -180,8 Kravspesifikasjon 372 38 38 334 372 38 100 % 89,3 43 % -51,3 Konstruksjon 288 13 13 275 288 13 100 % 0 13 Implementering 288 0 0 288 288 0 0 0 Testing 90 0 0 90 90 0 0 0 Evaluering 54 0 0 54 54 0 0 0 Presentasjon og demonstrasjon 144 0 0 144 144 0 0 0 TOTAL 1860 117 424,93 1435 1860 424,93 100 % 462,8 92 % -37,875 Opprinnelig plan: gis inn manuelt og er det første estimatet som lages. B rukt denne uken: kan legges inn manuelt eller dere kan utvide regnearket slik at alle registrere hvor mye de har jobbet og denne kolonnen summerer det. B rukt hittil : kan legges inn mauelt eller det kan lages automatikk ("Brukt denne uke" + "brukt hittil" fra forrige statusrapport E s timert gjenstående: legges inn manuelt og skal være et estimat av hvor mye dere rekner med gjenstår a denne aktiviteten. Dette estimatet skal være uavhengig av hva dere opprinnelig estimerte. Default i regnearket er Estimert gjenst. = Opprinnelig plan - brukt hittil E s timat totalt = Brukt hittil + Estimert gjenst. T jente timer = Opprinnelig plan - Estimert gjenst P roduktivitet = Tjente timer/brukt hittil P lanlagt oppnådd: Hvor mange timer dere skulle ha jobbet på denne aktiviteten til nå etter den opprinnelige planen. Kan legges inn manuelt eller dere kan utvide regnearket slik at planlagte tall for alle ukene legges inn. Framdrift = Tjente timer/planlagt oppnådd F remdrift avvik = Tjente timer - Planlagt oppnådd 5LVLNR Nr Aktivitet Risikofaktor Kons. Sanns. Prioritet Strategi og tiltak Tidsfrist Ansvar Underestimering Unngåelse: Legge inn marginer. 1Alle av tids bruk H H H Dempe: Legge inn mer arbeid. Kont. Even 2Alle Produktet blir ikke godt nok tilpasset sluttbrukerne M M M Unngåelse: Søke å få tidlig kontakt med sluttbrukere. 10. sept. Knut Bjørnar Unngåelse: Passe på at alle lagrer på BSCW. Dempe: Ta vekk krav. Endre 3Alle planer. Kont. Julie 4Alle Studenter går ut av prosjektet og arbeid mistes H L M Misforstått problemstilling H L M Unngåelse: Ta kontakt med kunden 10. sept. Kay 2PIDQJ Ingen endring av omfang, siden dette var den første skikkelige arbeidsperioden. PD - 28

Maler Prosjektdirektiv Gruppe 1.RVWQDGWLPHU Vi rapporterer timebruk hver uke. Et regneark for rapportering er under utarbeidelse, men foreløpig skjer dette manuelt..ydolwhw Har ikke ennå funnet noe som skulle redusere kvalitet. 3ODQODJWDUEHLGQHVWHSHULRGH 0 WHU Kundemøte fredag 5. september. Internt møte mandag 7. september. Flere interne møter. $NWLYLWHWHU Undersøkelse av eksisterende system. Kost/nytte- vurdering. Modellering av dagens system, og mulige fremtidige løsninger. Avklaring av grensesnitt mot mulig underliggende system. Oppfølging av tilbakemeldinger fra veiledning og kundemøte. $QQHW Lagbygging på luftkrigsskolen. Mulighet for en av studentene til å delta på HelsIT. PD - 29

Maler Prosjektdirektiv Gruppe 1 6WDWXVUDSSRUWNXQGH Periode: 3URVMHNWVWDWXV*U QQ*XO5 G )UHPGULIW $UEHLGXWI UWVLGHQIRUULJHVWDWXVUDSSRUWWLONXQGHQ $UEHLGVRPVNDOXWI UHVWLOQHVWHNXQGHP WH PD - 30

Katalogstruktur Prosjektdirektiv Gruppe 1 9HGOHJJ&.DWDORJVWUXNWXU Denne katalogstukturen er overordnet. Noen kataloger, for eksempel kataloger med implementering, må deles videre opp i underkataloger, for eksempel for kode og dokumentasjon. KPro_Gruppe1: Beskrivelse: Rot-katalog for gruppe 1. Underkataloger:KPro_Gruppe1_Felles KPro_Gruppe1_Intern KPro_Gruppe1/KPro_Gruppe1_Felles: Beskrivelse: Her, og i underkataloger, legges filer som kunden og veiledere har bruk for. Hovedveileder må imidlertid få tilsendt dokumenter som han trenger på e-post. Hvis kunden skulle ha hatt tilgang til KPro_Gruppe1/KPro_Gruppe1_Intern, hadde kundens representanter fått melding om alle endringer av dokumenter. Dokumenter og kode legges i KPro_Gruppe1/KPro_Gruppe1_Felle kun når kunde eller veileder skal se disse, og får melding om det via BSCW. Her legges også dokumenter som fra kunden, og dokumenter som oppdateres av kunden og studentgruppen i fellesskap. Underkataloger:Bakgrunnsinfo Faseresultater Kundemøter Veiledermøter KPro_Gruppe1/KPro_Gruppe1_Felles/Bakgrunnsinfo: Beskrivelse: Dokumenter om domenet, eksisterende systemer. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater: Beskrivelse: Delvis ferdige og ferdige fasedokumenter. Legges ut innen en viss tid før møter. Underkataloger:Evaluering Forstudie Implementering Konstruksjon Kravspesifikasjon Planlegging Presentasjon KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Planlegging: Beskrivelse: Inneholder dokumenter som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Forstudie: Beskrivelse: Inneholder dokumenter som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Kravspesifikasjon: Beskrivelse: Inneholder dokumenter som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Konstruksjon: Beskrivelse: Inneholder dokumenter som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Implementering: Beskrivelse: Inneholder dokumenter og kode som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Evaluering: Beskrivelse: Inneholder dokumenter som kom ut av fasen. KPro_Gruppe1/KPro_Gruppe1_Felles/Faseresultater/Presentasjon: Beskrivelse: Inneholder dokumenter som kom ut av fasen. PD - 31