Prosjektplan v1.3 (final)

Transkript

1 Prosjektplan v1.3 (final) gruppe 42: Nils-Kristian Liborg (kap.5), Bente Brevig (kap.5), Tom Olav Bruaas (kap: 3.4, 4.1), Eirik Lied (kap: 3.4, 4.1) Hege Lid Pedersen (dokumentasjon, kap: 1, 2, 3.3, 4.3) - alle (kvalitetssikring) 27. september

2 Innhold 1 Introduksjon Prosjektoverblikk Prosjektleveranser Utvikling av prosjektplanen Prosjektorganisering Prosessmodellen Ansvarsområder Management Risikovurderinger og håndteringer Overvåkning og kontrollmekanismer Den tekniske prosessen Metoder, verktøy og teknikker Prosjektsupportfunksjoner Konfigurasjonsstyring Kvalitetssikring Skeduleringer og estimeringer Delaktiviteter Gant-diagram og estimeringsplan Tidsforbruk

3 1 Introduksjon 1.1 Prosjektoverblikk Dette er dokumentasjonen av prosjektet Hospital 2002 for kurs in219 høsten Det skal utvikles et HSS - Hospital Scheduling System, hvor to hovedmål er satt i fokus: Allokering av tid/ansatt-resursser Allokering av tid/plass-resursser Det vil si; skeduleringer av ansatte, i hovedsak leger og sykepleiere, iforhold til arbeidstid og skeduleringer av sengeplasser, operasjonsrom etc. med hensyn på pasienters statuser og tiden som er til rådighet. Gjennom prosjektperioden skal det fremlegges fem leveranser. Hvor de fire siste bygger på hverandre. Etter siste leveranse skal det være utviklet nok slik at et system som oppfyller krevene skal kunne lages. 1.2 Prosjektleveranser Overordnet inneholder hver av leveransene: 1. [10.sep] - Hjemmeside for prosjektet 2. [27.sep] - UseCase-modell, Prosjektplan, TauUML tutorial, brukergrensesnitt 3. [11.okt] - UMLdesign A - prioriterte funksjoner, oppdateringer av leveranse 2 4. [29.okt] - UMLdesign B - detaljert design, innspeksjonsrapport og oppdateringer av design A, prosjektplan, UseCase-modell og brukergrensesnitt 5. [12.nov] - Kodegenerering med presentasjon av den og brukergrensesnitt, erfaringsrapport 1.3 Utvikling av prosjektplanen Vi regner med at dette dokumentet, prosjektplanen, vil forandre seg iløpet av leveransene. Da spesielt med tanke på kapitel 5 hvor skeduleringer og estimeringer blir satt opp. Gjennom prosjektet vil nye aktiviteter melde seg og dermed ha behov for tid og resursser. Gamle må oppdateres etter hensyn på nye og erfaringer som er opparbeidet seg. 3

4 Innad i gruppa kan også arbeidsfordelingene forandre seg og det må oppdateres. Prosjektplanen vil nok utvikle seg til å bli større og mer kompleks enn første eksemplar. Versjon Hovedforfatter Beskivelse Dato Draft Hege,Tom Olav Første kladdarbeid arbeidsfordeling 20.sep Preliminary Hege,Tom Olav, 2. kladd Nils-Kristian refordeling 23.sep Final Alle 1.levering 27.sep Revidert utgave 1 TBD - 11.okt Revidert utgave 2 TBD - 29.okt Revidert utgave 3 TBD - 12.nov Tabell 1: Prosjektplansutvikling 2 Prosjektorganisering 2.1 Prosessmodellen Med tanke på hvordan in219-prosjektets leveranser foreløper, er det naturlig å etterstrebe spiralmodellen når det gjelder valg av prosessmodell. Produktet er ikke lagt opp til som en sekvens av aktiviteter hvor en følger av en annen. Det er heller snakk om aktiviteter som utvikles gjennom flere leveranser. I alle leveransene skal vi oppdatere og videreutvikle det vi har gjort tidligere etter som vi får mer informasjon, både fra oppdragsgiver og fra egen læring og nye erfaringer. Samtidig med disse iterasjonene, er vi igjennom ulike faser i utviklingen av systemet. Dvs. analyse, design, implementasjon... For hver leveranse er det viktig å se på hvor stor risiko hver aktivitet har for å mislykkes. Det kan bestemme hvordan utviklingen av den aktiviteten skal foreløpe. Dette er i tråd med spiralmodellens intensjoner. Likevel er det naturlig la en evolusjonerende prosess være en del av prosessmodellen. Da med tanke på at vi får først en ufullstendig kravspesifikasjon, og senere, etter leveranse tre, får vi den fullstendige. Dette er det samme som at oppdragsgiveren kommer med nye ting til systemet, og av prosessmodeller er det evolusjonsmetoden som håndterer dette best. 4

5 2.2 Ansvarsområder Ansvarsområde Overordnet prosjektleder Dokumentasjon - Latex Hjemmesidene Tekniske hjelpemidler Kontakt med oppdragsgiver Kvalitetssikring Kravspesifikasjonsutviklingen Sekretær UML Hvem Nils-Kristian Hege Eirik Bente Nils-Kristian Eirik og Hege Tom Olav Bente Eirik og Tom Olav Tabell 2: Ansvarsområder 3 Management 3.1 Risikovurderinger og håndteringer Problemer av ulike slag vil kunne oppstå iløpet av gjennomføringen av et prosjekt. Vi har sett på hva som kan gå galt og vurdert sannsynligheten og effekten av de. Sannsynligheten vurderes ved: lav, moderat, høy og effekten vurderes: liten, moderat, stor. Det er også satt opp en liste over hva vi kan gjøre for å motarbeide disse. Risiko Sannsynlighet Effekt Gruppemedlemmer frafaller lav stor Teknologien svikter lav stor Estimering av tiden er undervurdert høy stor Dårlig arbeidsfordeling moderat moderat Dårlig kommunikasjon innad i gruppa moderat moderat Sykdom moderat stor Dårlig forståelse av verktøy moderat stor Feiltolkning av oppgaven lav moderat Kunnskapssvikt lav moderat Feilvurdering av arbeidsmengde moderat stor Tabell 3: Risikovurderinger 5

6 Risikohåndtering Frafall - Fokus på fellesskap, forståelse og gjennsidig respekt. Teknologisvikt - Krysse fingrene ofte, håpe på det beste. Tidsestimering - Sette av god tid til oppgavene, mer enn vi tror vi vil bruke. Arbeidsfordeling - Gi alle en stor oppgave, fordele de mindre etterhvert som man blir ferdig. Si ifra når en har for mye å gjøre iforhold til andre fag. Hjelpe hverandre underveis når problemer oppstår. Kommunikasjon - Gi alle de samme beskjedene. Opprette en beskjedside på hjemmesiden. Oppmuntre til å gi kommentarer på andres arbeid. Sykdom - Spise Vekk i morgen og drikke rød solhatt. Bruke lue, votter og skjerf. Verktøy - Lese tutorialen til tau uml. Sette av god tid til oppgaver som skal benytte fremmede verktøy. Gi andre tips om lure triks og hjelpemidler. Oppgaven - Lese oppgaveteksten godt. Lese den flere ganger gjennom hele prosjektet. Streke over viktige ting. Kunnskapssvikt - Lese først igjennom relevant pensum for oppgaven man begir seg utpå. Søke på nettet og titte på andre gruppers hjemmesider. Spørre gruppelærer og andre grupper enn sin egen. Arbeidmengde - Ikke ta på seg mer arbeid enn man vet man klarer. Si ifra i god tid når en er overarbeidet og har problemer med å bli ferdig innen tidsfristen. 3.2 Overvåkning og kontrollmekanismer Vi har registrert timer underveis etter hva vi har jobbet med. Mye går over i hverandre og er vanskelig å registrere. Hjemmesiden vil inneholde en del av tidsregistreringen slik at vi unngår lappesystem. Se kapittel 5.3 for oversikt. 4 Den tekniske prosessen 4.1 Metoder, verktøy og teknikker Software Tools: 6

7 Tau uml: Vi har brukt tau uml for uml modelleringen så langt. Latex: Verktøy for dokumentfremstilling (dokumentasjon). Source code control: På dette stadiet av prosjektet har det ikke vært nødvendig. Dette på grunn av at vi ikke har begynt noen implementasjon. Time accounting: Microsoft Excel: Vi har brukt dette regnearkprogrammet for å holde styr på beregnet tidsforbruk. Både for å beregne og for å føre den tiden vi har brukt. Compiler: Latex: Teksten skrives i emacs for så å kompileres til å bli et latex-dokument (.dvi) Debugging aids: Vi har ikke benyttet noen slike enda. Development methodologies: Requirements development practices: Viser til Professor Ray Wellands forelesning om Requirements Engineering. Design Methologies: Vi benytter oss av UML. Programming language: Systemet skal implementeres i Java Coding standards: Quality assurance practices: Vi har ikke vært i kontakt med noen slike metoder på dette stadiet av prosjektet. 7

8 4.2 Prosjektsupportfunksjoner Konfigurasjonsstyring Konfigurasjonsstyring er viktig. Også i små prosjekter som vårt. Bruk av CVS krever, av erfaring, mye tid, forståelse og krefter å sette opp. Siden vi er relativt få på gruppen har vi valgt å ha en som har ansvar for dokumentasjonen. Vedkommende mottar alt arbeid gjort av andre via mail eller papir, og legger det inn i dokumentene. På den måten vil det til enhver tid bare være en som arbeider på dokumentene, og versjonshåndteringen blir enkel. Gruppemedlemmene mottar jevnlig oppdaterte pdf-dokumenter til gjennomlesning og gir tilbakemelding ved hjelp av disse Kvalitetssikring Vår kvalitetssikring vil være at alle leser igjennom dokumentene jevnlig. Påpeker feil, mangler, bra og dårlig formuleringer. Bruker også sjekklister som er utarbeidet.tilsammen sikrer dette, forhåpentligvis, kvaliteten på arbeidet og produktet. 5 Skeduleringer og estimeringer 5.1 Delaktiviteter For hver aktivitet er det tilordnet anvarlige utifra hvor mye tid som er estimert. Se egent punkt. Prosjekthjemmeside (Eirik) Prosjektplan (Tom, Hege og Nils-Kristian) Use Case Modell (Eirik, Bente og Tom) 1. Vurdering av krav og tekniske konsekvenser (Eirik) 2. Use case diagram (Eirik og Bente) 3. Beskrivelse av hver aktør (Eirik, Bente og Tom) 4. Beskrivelse av hvert use case (Eirik, Bente og Tom) 5. Beskrivelse av ikke funksjonelle krav knyttet til use case eller systemet som helhet Skisse av brukergrensesnitt (Nils-Kristian) Tau UML tutorial (Eirik, Bente, Tom, Hege og Nils-Kristian) Domenemodell (Eirik og Bente) 8

9 Design UML modell (Eirik, Bente, Tom, Hege Nils-Kristian) Klassediagrammer (Hege og Nils-Kristian) Sekvensdiagrammer (Eirik, Bente og Tom) Inspeksjon av UML Design Modell (Hege og Nils-Kristian) Kodegenerering (Eirik) Sluttrapport (Eirik, Bente, Tom, Hege og Nils-Kristian) Sammenligning av virkelig og estimert ressursforbruk (Nils-Kristian) Erfaringer fra prosjektgjennomføring (Eirik, Bente, Tom, Hege og Nils-Kristian) Evalueringer av kvaliteten til leveransene (Eirik og Bente) Evaluering av muligheten til å implementere et godt system basert på produsert design, kodegenerering og brukergrensesnitt (Tom, Hege og Nils-Kristian) Ris og ros med forbedringsforslag til gjennomføringen av obligatorisk prosjekt (Eirik, Bente, Tom, Hege og Nils-Kristian) Presentasjon av kodegenerering og design (Eirik, Bente, Tom, Hege og Nils-Kristian) 9

10 5.2 Gant-diagram og estimeringsplan º9»¼¼½2º¼¾, ÀAÁ6»º6ÂÃÄ Å Å ÆÇ È ÉÊ Ë ÉÌÍ Î ÆÉÌ Ï Ç Ê Ç&ÌÐ ÑÒ&Å ÆÓ Ô&Ô Í Ç ÉÆÉÎ ÌÉÇ Õ¼6½9Ö,! " # $ Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ù Ú&ÛÒ&ÆÍ ÑÜ&ÆÉÎ Î Ç!Ï È Ò&ÆÛÒ&Æ ÛÒ&ÆÝÌÇ&Ë Ç!ÉÎ Î ÇÛÓ Ë Î Ç&ÆÞ,+ ß6à " # $ )) #+ #* /.,- ßæ áæò áæò ÍâÇ&ÎÑÏ "" ## $ $ Í Î ÑÐâÇ )) #,. #- ÌÔ&Ë ÝAÝ,Ç Í Éã Ç ç&ä!å ç&ä!å æ à ä ä!å,0 ßèìàjéÍ éí Ç!ê6Ô Í Ç*ë/Ò&ã Ç&ÌÌ çäaå æ ä!å ç&ä!å ßèìæ ïç " # $ ÇAê6Ô #&%'&( Í ) Ç!í6ÉÔ #0 Ê&ÆÔ&Ý î ä!å î ßèìèjð9Ó Í "& &123,456 ÆãÎÇ&ÆÉË ÆÉÈ Ç&ÌÍ ÊÔ ÇAÔ È/ÑÇ&Î ÈAéÍ Ë ÉÍ ÇAê6Ô&Í Î ÇAÎ ÆÔ Ç È è è!å è è!å " # $ ) #* 7891/:3,45163,9&; à èä èaå ßç ßèìç íò&ýç Ë Ç&Ý,Ò ã Ç&ÌÌ " + " # $ ) #+ î äaå =B î ä!å ßî ïæó Î Ç&ÆÊ&ÆÇ&Ë Í Ç Í Ë ÉÑÑÍ Î ÉÍ Í Ç " - " # $ ) #- C&%D à ä ä!å ßò ßÔ&ÓAé9ëAñ/ÑÓ ÑÒ&ÆÉÔ&Ì æ äaå æ&äaå æ ä!å æ ä!å æ ä!å ßòìà óìô "". 0 "" íç ## $ $ Í #&%'&( ÉÊ&ËAé9ëñ,ÝÒ )) #0 #,. ã Ç&ÌÌ æ ä!å æ æ äaå æ äaå æ äaå ßòìæ ôç&îè Í Í Ç ã ÉÔ Ê&ÆÔ&ÝÝÇ&Æ î ä!å î ä!å ßõ öë Í Ð Ç&Î Ç&ËÍâÒ&ËÔ Í ã&éô Ê&ÆÔ&ÝÝÇ È,ã Ç Í ÉÊ&Ë!é9ëñÝ,Ò Æ ã Ç&ÌÌ è è!å î ä!å î ä!å è è!å è èaå ß ôìó óò ãññæô&ð Ç Ê Ç ËÐ Ç&ÆÇ&ÆÉË Ò&ÆÑ Ê ;23,4EEFGHI JK æ ä!å I&LNMOPI&Q&JHKR&S&TUæ G&V HGWK SL*L!U VX SKI&Y æ ä!å V HTHVU VU&QZ æ ä!å à äæ ä!å ßøìæ«ùÆÛÔ&ÆÉË ßø&ìàšôÔ&ÝÝÇ&Ë ÌÉÊ&Ë ÉË ÊÔ ÈÆÇ Í Í Ó ÆÍ Å ÆÓ Î A\,] à ä ä!å,^ /_,` &W V HL!I VMV HL!U T&U&K Y Z ESVI&[U W] V` HL!I ] V ßøìè«ùÈ Ê Ç&Æ&ÛÆÔ!Ð ÆÒ&Í âç&î ÑÇ Ñ æ äaå æ äaå æ ä!å æ ä!å æ ä!å 3/Y ßøìç ùè ÊÔ ÈÌÇ È Ç&ÆÔ&Ë Í Ç ÚÎ È Ô&ÌÉÑÇ Ñ î ä!å î äaå V HTHV U VbaU WY K HT&U&[W&U c6^ dec6^ fec6^ gec6^ hec_ijc_\kc_&]ec_&^ec lc_&èc_&dl U T&U&K I&Q&W&Um39TR&U&Q&JHJRnoAHQp5qI r 5I&QQ&W QQ&UQ X sq[hjru SKHQFI V t ß9à äúáæçô&ìó Í Ç&Ë Ç&ÆÉË ÑÔ ÍâÒ&ËÔ ÊAÔ ÈÝÓ ÈÎÌÉÊ&Ï Ò ã ÇÇÊÑÇ&Ë&ì ÛÒ&ÆÉÝÐ Ò&ÊãÌìÇ Í ÉÊ&Ë æ äaå æ&äaå è èaå æè ä!å èaå æè ä!å è!å æ ä!å r W V HLAI VouSL*L!U&Q V I&K U&K v+ v6 w%c w%c x# >'&( {A{,# ) = # } }} } } } } } } } ""& + + -&.& -~0! - 0 ) #*/C #&>> } } } } } } } } " + - ˆ. 0 Š 0!.& v- e ) v- + Ž# #A 6' ) y %=$ #&>) ) #!Œ6=' #A' $A ) D&%'&{ #A 6'&) # } }} }} } } } } } "" & Š! + 0 v- -j 9 % #&%=( D' $/@#&y ( =) y #Ay %' $ } " + +~- 0 Š v-. ŒC&{,#&( # {C #&>> } } } } } } " ! - v. Ž% y #&%D%#&( ) # ) ( =@@) y =) ) # } } } } } } } " + 0 k 0 Š! 0 v0 v'& A } } } } " + 0 +& + 0 0! + v Œ# ) =D&(A 9",{C #&>> } } } } } +& + 0 +?>' ) ) # =' D&%'&{{#&% } } } } } k 0 v + #&y$ #&( ) &=' D&%'&{{# % } } } } } 0 +! v ( ) ƒ #&y )xc&(' $, # ) =D&(! 9"{,C #&>> } } } v 0 j 0 Š 0A 0 v?c # D # ( #&%#&%=( D } } v -~0j 0! ƒ C&%@ Figur 1: Gantdiagram } } med v estimering 0 +& + 0 Š! + vš š œ2œ9 ž Ÿ ž ž 2 2 } } 0!. vš +«ª% '&%=( vš -«ª$ '&> D #&% DA' %'Aƒ $># %C $ )x#&y@# #&%'&( ) #@ y$ }} }} ŠŠ!. vš&. ª$ '&> #&%=( D' ${A >=D&z C&%={ƒ > } } +. 0!. v9 w%# ) )xc&(' $y C # D #&(& C D #&) =D&( } } vš + - Š!. + A±²6³µÁ 6 ¹ ûaüý6þ ÿ ÿ 10

11 5.3 Tidsforbruk 1 4 > G? A G K G O?! 6 A 6? G G G G G Y!! "$#&%(')+*,.-/ : : ; ; <= 5@? 89:! 6??A 57A BCED&! < F = 57AH 6IBC< D&! J&!!; 57AH?ML9!NBC< D&! 57AH AQP$= R!S < 57AHTMJC; ; = 5@T L9 < 57G 57!EB&F Ü! 57O J& EB&F UE; = 57OH 6IV9!< =!!; ; 57OH?MW9 =!!; ;E 57X : E! S= EB&F U ;= 57K VZ= 57> W9! 57>H 6IW9!; ;ER!N 57>H?M[9\! ]\! : 57>H AI[Z! R!N!^+! Figur 2: Tidsforbruk 57>HTM[Z<! (! _; 576` 89!: E! N = H = < 11