PROSJEKTPLAN FOR INF 3120-PROSJEKT: <PROJECT HOSPITAL 2005>

Transkript

1 PROSJEKTPLAN FOR INF 3120-PROSJEKT: <PROJECT HOSPITAL 2005> VERSJON: LEVERANSE 4.0 NB! Endringer i prosjektplanen for 3. leveranse sammenlignet med leveranse 1.1 er i blå skrift og med en strek i høyre marg. NB! Endringer for 4. leveranse er i grønn skrift og med en stiplet linje høyre marg Gruppe 46 - Team Innovation Prosjektplan Leveranse 4 1. versjon Gruppemedlemmer: Nam Duc Pham... namdp@ifi.uio.no Tofik Sahraoui... tofiksa@ifi.uio.no Cuong van Truong... cuongvt@ifi.uio.no Tor Øyvind Fluør... torof@ifi.uio.no Dagfinn Forsaa Andersen... dagfina@ifi.uio.no Dato for ferdigstillelse: 18/

2 REVISJONSOVERSIKT Versjon Ansvarlige Forklaring av versjon Dato Avsluttet 1. utkast Alle 1. utkast for gruppens inspeksjon utkast Tor Øyvind 2. utkast for gruppens inspeksjon Leveranse Alle Versjon godkjent til levering Revisjon 1 v1.1 Dagfinn - Oppdatert forsiden:inkludert brukernavn. - kap. 2.1: Lagt inn diagram og kommentert dette. - kap. 3.1: Risiko-oversikt oppdatert se tekst i kursiv, Satt inn midtrapport / risikodiagram - kap. 5: satt inn aktivitetsplan Leveranse III Versjon 3 til 3. leveranse 1.utkast Oppdatert prosjektplan (midtrapport) Dagfinn Kap. 1.1: Oppdatert i forhold til ny spesifikasjon. Kap. 2.1: Oppdatert prosessmodell og beskrivelse av denne. Kap : Risikoendringer midtrapport; revurdert risiko, samt oppdatert figur. Kap. 3.2: Post Mortem Analyse 2. utkast Dagfinn Kap 3.1: Risikoendringer er oppdatert igjen. Kap. 5: Revidert aktivitetsplanen og innført ny leveranseplan Appendiks I med klassediagram Leveranse VI Sluttrapport 1.utkast Kap. 2.1 Lagt til oppsummering av prosessen Kap. 3.1 Lagt til oppsummering av risikoene; hvordan det ble. Kap. 3.2 Post Mortem analyse oppdatert Kap. 5.1 Leveranseplan; oppdatert i forhold til hva vi leverte. 2. utkast Kap. 5 Aktivitetsplan med faktisk ressursbruk Team Innovation (11/18/05) Page 2

3 1. INNHOLD. 1. INNHOLD INTRODUKSJON PROSJEKT OVERBLIKK PLANLAGTE ENDRINGER AV PROSJEKTPLAN REFERANSEMATERIALE PROSJEKT ORGANISASJON PROSESSMODELL PROSJEKTSANSVAR PROSJEKTSHÅNDTERING PROSESS RISIKO-OVERSIKT RISIKOENDRINGER FOR MIDTRAPPORT OG LEVERANSE IV: POST MORTEM ANALYSE OVERVÅKING OG KONTROLL MEKANISMER TEKNISK PROSESS METODER, VERKTØY, OG TEKNIKKER PROSJEKT SUPPORT FUNKSJONER TIMEPLAN OG FRAMDRIFTSPLAN LEVERANSEPLAN...19 Team Innovation (11/18/05) Page 3

4 1. INTRODUKSJON. 1.1 Prosjekt Overblikk HealtCare er et privat sykehus som eies av en gruppe ledende leger som spesialiserer seg innen hofte operasjoner og ører-nese-hals operasjoner. HealthCare ønsker seg et nytt data system som skal brukes til å koordinere menneskelige resurser og som kan kontrollere pasient trafikken innenfor avdelinger. Systemet skal sikre presise seng reservasjoner og estimere ledige senger. I tillegg skal systemet hjelpe til med å håndtere forutsette og uforutsette operasjoner. Oppdatert kravspesifikasjon: HealthCare har endret kravene delvis som en følge av ny innsikt og delvis som en følge av problemer med den opprinnelig valgte leverandøren. De viktigste nye kravene er: Enkel turnusplanlegging: I første omgang er det administrasjonen, overlege (avdelingssjef) og oversykepleier som skal styre ressursplanleggingen. Man skal kunne sette opp overordnede planer for en måned frem i tid, mer detaljerte planer for den kommende uken og detaljplanlegging av morgendagen. Det skal også tas hensyn til arbeidstids- lover og regler Leger og sykepleiere skal ha tilgang til systemet slik at de kan få oversikt over sine egne vakter. Team Innovation har satt av 5 personer til å utforme Prosjekt Hospital De vil sørge for at systemet blir enkelt å forstå og lett å vedlikeholde. Med dette systemet vil legene i HealtCare få bedre tid til pasientene og hverdagen på sykehuset vil bli enklere og mer systematisert. 1.2 Planlagte endringer av Prosjektplan Versjon Deltakere Kort beskrivelse av versjonen Dato for innlevering 1. utkast Cuong, Dagfinn, Første utkast til inspeksjon Nam, Tofik, Tor Øyvind 2. utkast Tor Øyvind Andre utkast med forandringer lagt til Første innlevering Cuong, Dagfinn, Nam, Tofik, Tor Øyvind Første klare versjon til innlevering Revidert utgave Dagfinn En revidert utgave med de forandringene som har oppstått i prosjektprosessen Team Innovation (11/18/05) Page 4

5 1.3 Referansemateriale Sommerville: Software Engineering 7 Kursmateriale fra INF4120/3120 Craig Larman: Applying UML and Patterns Gerhard Skagestein: Systemutvikling fra kjernen og ut, fra skallet og inn. Team Innovation (11/18/05) Page 5

6 2. PROSJEKT ORGANISASJON 2.1 Prosessmodell Vannfallsmodellen er blitt valgt som arbeidsprosess. Denne modellen beskrives ved at prosjektet brytes ned i ulike faser som, informasjonsmessig, er avhengig av hverandre. Hver fase i prosjektets gang må være ferdig før neste fase kan begynnes på. Prosjektet er delt opp til 5 innleveringer med dato. Kravspesifikasjonen for prosjektet ser ut til å være veldig godt beskrevet og det er liten sannsynlighet for endringer fra kunden. Det er også slik at leveranse 3 til 5 ikke er avhengige av leveranse 1 og 2. Siden dette prosjektet er såpass veldefinert og statisk tror vi vannfallsmodellen vil fungere bra. Diagrammet til høyre viser de forskjellige stegene vi skal igjennom. Retningen på pilen indikerer tidsaksen. Input Kravspekk Kravspekk Delvis implementert system Leveranse I Prosjektplan Vurdering Analyse Reverse engeineering Evaluering Aktiviteter Planlegging Design Revisjon av plan Output Leveranse I Prosjektplan Leveranse II Analyse og Design (1) Leveranse III Klassediagram Prosjektplan I all hovedsak er en aktivitet ferdig før den neste påbegynnes. Men vi ser at vi regner med noen iterasjoner mellom: - anlyse og design - design og koding Leveranse III Klassediagram Arbeidstidslover og regler Analyse og Design Koding og test Leveranse IV Design (2) Kjørbart system I forhold til første plan trenger vi å gjøre en ny analyse i forbindelse med leveranse IV. I tillegg til ny kravspesifikasjon må vi også ta hensyn til lover og regler for arbeidstid og turnuser. Oppdatert kravspekk Erfaringer Leveranse I-IV Pensum Evaluere og oppsummere Forberde presentasjon Leveranse V Presentasjon Team Innovation (11/18/05) Page 6

7 Leveranse IV gikk ikke helt som forutsatt. Ny analyse og ny design brukte vi altfor lang tid på å få ferdig. Designet ble veldig ambisiøst se klassediagram2-design. Men omsider omsider fikk vi generert kode av dette. Det viste seg umulig å implementere med tiden som vi hadde til disposisjon. Det ble dermed gjort ei forenkling av klassediagrammet og vi lente oss i større grad på eksisterende kode og tildeles utkommentert kode slik at vi fikk noe som var kjørbart. Vi hadde ambisjoner om å ha en relativt grundig test og tilhørende bugfix, men på grunn av tidspresset ble det umulig å gjennomføre. Noen årsaker til at vi ikke ble helt ferdig: Vi fikk ikke etablert en god helhetsforstålese innad i gruppen for hvordan klassediagrammet burde se ut dermed ble det endel (interessante) diskusjoner og stadig nye versjoner. Den underliggende årsakene til dette er nok at vi ikke hadde noen i gruppen som hadde anvendt UML tidligere, vi manglet rett og slett god kompetanse på dette. Sykdom og fravær. Verktøyproblemer; I en kritisk periode hadde vi flere problemer med Tau UML og det gikk vel lang tid før problemene ble løst. Se forøvrig kapittel 3.1 risiko-oversikt. Hva kunne vi gjort anderledes? Vi burde nok tidlig gjort et par små og enkle justeringer på det genererte klassediagrammet og generert kode for dette v.h.a av TAU. Da ville vi fått bedre innsikt i sammenhengen mellom klassediagrammet og koden som ble generert. I tillegg ville vi vært bedre rustet til å takle tau-problemene vi fikk. Nå endte vi opp med en vannfallsmetode som gikk litt stokk over stein i siste del av prosjektet. Det ble rett og slett ikke mulig å få gjennomført noen fornuftige iterasjoner mellom design- og kode-fasene. Team Innovation (11/18/05) Page 7

8 2.2 Prosjektsansvar Ansvarsområder Prosjektleder Utviklingsleder Kvalitetsansvarlig Dokumentasjonsansvarlig Dokumenthåndteringsansvarlig PR ansvarlig Ansvarlige Tor Øyvind, Cuong, Dagfinn, Nam og Tofik Tofik Tor Øyvind Cuong Dagfinn Tofik Team Innovation (11/18/05) Page 8

9 3. PROSJEKTSHÅNDTERING PROSESS 3.1 Risiko-oversikt Risiko Alvorlighesynlighet Sann- Tiltak Nr Noen forlater gruppen Lav Middels Rullerende arbeidsoppgaver, ingen som sitter R1 Middels Lav på en kritiskposisjon. Korttids sykdom Lav Høy Trene regelmessig, drikke tran R2 Uenighet i gruppen Høy Lav Fest R3 Middels Middels Valg av feil verktøy Høy Lav Følge faglige retningslinjer og anbefalinger R4 Driftssvikt Høy Lav Personlige backup R5 Dobbelbooking av Middels Middels Faste møtetider R6 arbeid Forandring i Middels Lav Jevnlig kundekontakt R7 kravspekk. Utgår Utgår Under- og feilvurdering Høy Middels Legge inn interne deadlines i gruppen R8 av arbeid Middels Høy (buffer).omfordele og re-prioritere oppgaver etterhvert som vi får mer innsikt i deloppgavene som skal løses. Mangel av veiledning Høy Lav Møte opp til gruppetimer, søke informasjon R9 fra gruppelærer Middels Middels andre plasser Feiltolking av Høy Lav God kommunikasjon med oppdragsgiver R10 oppgaven Bruke mye tid på gammel kode av ukjent kvalitet Tau UML lisensproblemer Middels Middels Være pragmatisk, konsentrere oss om det vi må forholde oss til. Benytte tegnbasert grensesnitt (ikke sving) først. Høy Lav Være forberedt på at vi må endre på planene (begynne å kode fra scratch) Risikoendringer for midtrapport og leveranse IV: R1: Noen forlater gruppen Det vil være mer alvorlig fordi vi nå gjennomfører ei tettere ansvarsfordeling og på tross av at alle har en relativt god oversikt er det noen som besitter kompetanse som vi nødig vil miste. Risikoen for at noen forlater gruppen avtar desto lenger vi kommer ut i prosjektet. Dette fordi det nå allerede er investert mye tid og energi i prosjektet og eksamen nærmer seg. Gruppen er fremdeles inntakt. R3: Uenighet i gruppen Vi reduserer alvorlighet fra høy til middels fordi vi har fått en åpnere dialog i gruppen og vi kjenner hverandre bedre nå enn ved oppstarten av prosjektet. Post-mortem analysen var et godt bidrag til dette. Der tok vi spesielt opp problemer som den enkelte følte i forhold til prosjektet. Alt i alt tror vi nå at gruppen er bedre på å håndtere uenighet og problemer. Av tildels samme grunn øker vi sannsynligheten for at dette faktisk skal skje. Vi er blitt trygger på hverandre og dette gjør at det er enklere å ta opp problemer i stedet for å tie de i hjel. R11 R12 Team Innovation (11/18/05) Page 9

10 I siste fase av prosjektet var det spesielt diskusjoner om klassediagrammet disse var konstruktive og ble holdt i en god tone, men ikke alle var aktive og som nevnt i kapittel 2.1 ble det ikke etablert en god helhetsforståelse av klassediagrammet for gruppen totalt. R7 Forandring i kravspekk Vi anser ikke dette som en stor risiko, kun fire uker til levering og ingen annonserte endringer fra «Kunden» - ref. undervisningsplanen. R8: Under- og feilvurdering av arbeid Vi reduserer alvorlighet fra høy til middels fordi det har vist seg å være bra arbeidsmoral og engasjement i gruppen og selv om vi støter på uventede problemer så viser det seg at deltageren går på med krum hals for å få ryddet opp i problemene. Et eksempel på dette er ikke-godkjente innleveringer som det ikke var tatt høyde for i opprinnelig plan. Vi ser også at oppgaven er så krevende at vi pr. i dag tror det er ganske sannsynlig at vi vil oppleve dette igjen. Ref kapittel 2.1. Her støtte vi altså på problemer igjen. Design av klassediagram og kodegenerering av dette var mye mer omfattende enn vi la opp til. Og dermed måtte resten av prosessen lide for det. Det gikk lang tid før vi kunne starte kodingen, men de som skulle kode brukte ventetiden på å bli kjent med den utleverte koden og gjøre mindre endringer rett på originalkoden i stedet for å vente på den genererte koden fra klassediagrammet. Dette viste seg å bli nyttig mot slutten av prosjektet. R9: Mangel av veiledning fra gruppelærer Redusert alvorlighet på grunn av at vi nå har bedre oversikt over oppgaven enn ved første korsvei. Vi er ikke så avhengig av veiledning lenger og vi mener gruppen nå er bedre i stand til å løse oppgaven for egen maskin. Men vi øker sannsynligheten for dette fordi kommunikasjonen mellom gruppelærer/sensor ikke har vært god så langt i prosjektet. Dette tror vi til en viss grad skyldes at dette er to forskjellige personer. Det normale er jo at det er samme lærer. Det har vært eksempler på muntlige beskjeder som blir misforstått. Viktig info fra gruppelærerene bør sendes på e-post til hele gruppen (f.eks utdyping av oppgaveteksten). Det samme med tilbakemelding på innleveringene. Dette har bedret seg, mye fordi vi nå har vært representert på sensors gruppetimer. R11: Bruke mye tid på gammel kode av ukjent kvalitet Ny! Her har vi klart å begrense oss. Men vi burde kanskje i større grad utforsket sammenhengen mellom kode, klassediagram og kodegenerering. R12: Tau UML lisensproblemer Ny! Lisensproblemene ble løst ganske raskt, men vi fikk altså andre problemer med verktøyet som vi ikke hadde på risikolisten i det hele tatt og vi skjønner fremdeles ikke hva som var årsakene til problemen våre, men de ble da løst etterhvert... Team Innovation (11/18/05) Page 10

11 Alvorlighet høy R3 R12 R4 R10 R5 R9 R8 R11 middels R7 R1 R3 R6 R9 R8 lav lav middels høy R1 R2 Sannsynlighet Team Innovation (11/18/05) Page 11

12 3.2 Post mortem analyse Gruppen har gjennomført en post mortem analyse (PMA) som en oppstart på tredje leveranse. Analysen tok for seg hele prosjektet og ikke bare prosjektplanen. Her er et sammendrag av de viktigste oppdagelsene i denne analysen. Antall minus- og plusstegn indikerer hvor mange «stemmer» de enkelte punktene fikk: Dårlig møte-effektivitet, lange møter med mye utenomsnakk. Tiltak som ble foreslått: Sette slutt-tidspunkt for møtene Innføre agenda for møtene Innskjerpe faste møtetidspunkt Være bedre forberedt Jobbe i mindre grupper som forbereder forslag i forkant av møter Ha en møteleder (den som til enhver tid er prosjektleder) Nå mot slutten av prosjektet kan vi si at møte-effektiviteten har bedret seg. Det har også vist seg å være fornuftig å jobbe i mindre grupper med konkrete arbeidsoppgaver. Manglende kunnskap om UML; Dette gir usikkerhet i gruppa og det oppleves som krevende å benytte en metode vi ikke har noen særlige kunnskaper om. Tiltak som ble foreslått: Bedre forberedelser Bedre selvdisiplin i forhold til å lese pensum Forbedre lysarkene som blir utlevert. De er tildels ufullstendige og mangler gode eksempler. Vi må nok en gang innse at vi mangler kompetanse og erfaring i UML. Mangelfulle og sene interne leveringer Tiltak som ble foreslått: Øke «tidsbufferet» mellom interne og ekstern leveringer. Det er lov å stille krav internt og gi beskjed hvis ei del-levering ikke holder mål Ha større tålmodighet og forståelse for at noen i gruppa har problemer med skriftlige/tekstlige leveringer og støtte/hjelpe disse. Leveranse 3 gikk rimelig bra, men i skrivende stund ser det ut som at det blir temmelig hektisk før leveranse 4 er ferdigstilt Gruppa har stor ansvarsfølelse, er arbeidsvillig og engasjert God dialog/tone mellom medlemmene i gruppa Team Innovation (11/18/05) Page 12

13 3.3 Overvåking og kontroll mekanismer Websiden vil være en Wiki hvor alle medlemmene har tilgang til å forandre på innholdet. Timeregistrering vil legges inn som et eget dokument på prosjektwebsiden sammen med alle prosjektstyringsdokumentene. For å hindre tidsoverskridelser vil vi legge inn interne deadlines for når en levering skal være ferdig. Dette vil fungere som et buffer til den endelige innleveringsdatoen oppgitt fra oppdragsgiver. Alle prosjektstyringsdokumentene vil gjennomgå en kontroll og oppdateringsrutine fra gruppen før leveranse. Gjennom hele prosjektprosessen vil prosjektplanen gjennomgå endringer og vil bli klassifisert som midtveisplan og sluttplan i henhold til hvor langt prosjektet har kommet. Team Innovation (11/18/05) Page 13

14 4. TEKNISK PROSESS 4.1 Metoder, Verktøy, og Teknikker Programvare/verktøy vi vurderer CVS WIKI, Mantis, Eclipse, Javac, TAU Uml, Craig Larman: Applying UML and Patterns Vi har bestemt oss for å benytte CVS, Hver enkelt benytter det utviklingsmiljøet de kjenner best, det vil si Jbuilder, Emacs og Eclipse. Jobb metoder/standarder/språk: Javadoc Følge programmeringsstandard fra SUN Java UML OCL Utgår da det ikke er påkrevd i oppgaven Innad i gruppen har vi pekt ut personer som skal kvalitetssikre alle deler ved prosjektet. 4.2 Prosjekt Support Funksjoner For å sikre høyest mulig kvalitet på de delene hver person utvikler vil hver enkelt del bli kontrollert av minst et annet gruppemedlem. Ved større oppgaver, som f. eks. leveranse av en del innlevering, vil alle i gruppen kontrollere. Vi vil også etablere en filnavnsstandard på administrative dokumenter. Dette vil hjelpe oss i å skille de forskjellige versjonene fra hverandre. Team Innovation (11/18/05) Page 14

15 5. TIMEPLAN OG FRAMDRIFTSPLAN AKTIVITETSPLAN M1 M2 M3 M4 M5 MILEPÆLER Prosjektplan og webside 23. september Analyse og design (1) - 7. oktober Reverse engineering - 21 oktober Oppdatert prosjektplan (midtrapport) Design av ny funksjonalitet 18. november Koding av design Presentasjon 6. desember LEVERANSER HOVEDANSVARLIG QA Backup L1 Prosjektplan 23. september Tor Øyvind Dagfinn L2 Analyse og design (1) - 7. oktober Cuong Tor Øyvind L3 Reverse engineering - 21 oktober Dagfinn Cuong Oppdatert prosjektplan (midtrapport) L4 Design av ny funksjonalitet 18. nov. Nam Tofik Koding av design L5 Presentasjon nov. Tofik Nam Team Innovation (11/18/05) Page 15

16 GANTT-diagram (X angir hovedtidsrommet for aktiviteten, x angir "slakk") Estimat (timeverk) Totalestimat Snitt pr. pers M1 M2 M3 M4 M ,57 Sannsynlighet: Innenfor Min- Aktivitet Beskrivelse U36 U37 U38 U39 U40 U41 U42 U43 U44 U45 U46 U47 Lever. Avheng. Min MS Max Max Estimat Kommentarer T1 Prosjektplan og webside T1.1 SW dev. Plan m/gantdiag. X X x L % 60 T1.2 Etablering av webside wiki X X X L % 12 T2 Verktøy T2.1 Valg av verktøy cvs/jbuilder/eclipse/mantis/bugzilla X X X X X % 8 T2.2 Opplæring Tau UML X % 25 T3 Analyse og design (1) L2 T2.2 T3.1 Use case modell X X % 31 T3.2 Domenemodell X X % 9?? T3.3 Beskr. Av ikke funk.krav X % 4 T3.4 Andre kravspesifikasjoner X % 4 T3.5 UML Design klassediagram X X % 21 inkl OCL T4 Reverse engineering L3 T4.1 Generering av klassediagram X X T % 21 T5 Oppdatert prosjektplan (midtrapport) X X L3 T % 14 T6 Design av ny funksjonalitet L4 T6.1 Sekvensdiagram X % 16 T6.2 Klassediagram X X X % 20 T6.3 Koding av ny funksjonalitet X X x T % 70 T6.4 Test X X T % 40 T7 Presentasjon L5 T7.1 Forberede presentasjon X X % 12 T7.2 Holde presentasjon X % 1 Team Innovation (11/18/05) Page 16

17 RESSURSALLOKERING 1. versjon NAM TOF CUO TOR DAG Tot (SUM) 33,2 29,1 26,9 24,5 22,4 136,1 T1 Prosjektplan og webside T1.1 SW dev. Plan m/gantdiag T1.2 Etablering av webside wiki T2 Verktøy T2.1 Valg av verktøy cvs/jbuilder/eclipse/mantis/bugzilla T2.2 Opplæring Tau UML T3 Analyse og design (1) T3.1 Use case modell T3.2 Domenemodell T3.3 Beskr. Av ikke funk.krav T3.4 Andre kravspesifikasjoner 4 4 T3.5 UML Design klassediagram T4 Reverse engineering T4.1 Generering av klassediagram T5 Oppdatert prosjektplan (midtrapport) T6 Design av ny funksjonalitet T6.1 Sekvensdiagram T6.2 Klassediagram T6.3 Koding av ny funksjonalitet T6.4 Test T7 Presentasjon T7.1 Forberede presentasjon T7.2 Holde presentasjon 1 Sum timer: Team Innovation (11/18/05) Page 17

18 Status og plan 3, leveranse Status og plan 4. leveranse RESSURSALLOKERING Versjon 3 NAM TOF CUO TOR DAG Tot NAM TOF CUO TOR DAG Tot T5 Oppdatert prosjektplan (midtrapport) T5.1 evaluering av prosjektet T5.2 evaluering av prosjektplan T5.3 endring av prosjektplan T5.4 endring av aktivitetsplan T5.5 Endring av risikoplan T2 T2.3 Verktøy - konfigurasjonstyring: cvs T2.4 - tau umlkrav Analyse T5 - Leveranseplan T6 - Kodelesing T6 - Lover og regler som skal støttes T6 Design av ny funksjonalitet T6.1 - Sekvensdiagram T6.2 - Klassediagram T6.3 Koding av ny funksjonalitet T Kodegenerering Opprydding etter kodegenereringn T Java kodestandard - Implementere ny funksjonalitet feilretting T6.4 Test T autotester/enhetstester T brukertest T6.5 Dokumentasjon T hvis påkrevd (kjente svakheter og ev. feil) T javadok for egenimplementert kode T oppdatert klassediagram Overlevering leveranse T7 Presentasjon T7.1 - Forberede presentasjon T7.2 - Holde presentasjon Totalt Grå bakgrunnsfarge -> gjennomført til leveranse 3 Grønn bakgrunnsfarge -> gjennomført til leveranse 4 NB! Tallene på denne siden inkluderer IKKE leveranse 1 og 2. - se forrige side for disse. Timeregistreringen har ikke vært veldig nøyaktig. Men vi ser at vi brukte ca. tre ganger så mange timer på klassediagrammet i forhold til planen og dette gikk over en altfor lang periode. Dette har gått på bekostning av sekevensdiagrammene, testingen og dokumentasjon. Team Innovation (11/18/05) Page 18

19 5.1 LEVERANSEPLAN Her er en oversikt over hva som er planlagt levert til innlevering IV (v.1.0) og hva som ikke blir levert. Tegnbasert Grafisk Program- bruker- bruker- Modul versjon Design grensesnitt grensesnitt Kommentar Registrering Vers. 1 v staff og ward v.1.0 Integrering med eksisterende kode - turnusplanlegging 4 uker v.1.5 v ukeplan v.1.0 v detaljplan v.1.0 v.1.5 Endre/Slette Vers. 1 v staff og ward v.1.0 Integrering med eksisterende kode - turnusplanlegging 4 uker v.1.5 v ukeplan v.1.0 v detaljplan v.1.0 v.1.5 Visning og rapporter Vers. 1 v personlige vaktlister v månedlige rapporter v ukentlige rapporter v daglige rapporter v.1.0 Systemadministrasjon Vers. 1 v.1.0 v arbeidstidsregler - vedlikehold av lover og regler - ajourhold av turnustyper Brukerdokumentasjon Vers. 1.5 NB! Versjon 1.0 leveres Uke og detaljplanlegging er slått sammen Uke og detaljplanlegging er slått sammen I all hovedsak leverer vi det vi hadde planlagt. Noen av funksjonene er slått sammen slik at de finnes i et felles skjermbilde. Vi gikk ikke veien om å lage et tegnbasert grensesnitt først. Klassediagrammet drøyde for lenge slik at koding startet noe sent. I tillegg har vi ikke et fult gjennomtestet system og det finnes nok noen svakheter og feil. Team Innovation (11/18/05) Page 19