PROSJEKTGRUPPE 1 MGT SOFTWARE PROSJEKTPLAN LEVERANSE 1 (REVIDERT 1) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Store Prosjektledelse: Store Kvalitetssikring: Tommy Jansson Dato: 03. oktober 2005 Fil:.pdf
REVISJONS TABELL Denne tabellen viser hva som er blitt gjort i de forskjellige versjonene av prosjektplanen Versjon Ansvarlig Beskrivelse av versjon Dato ferdig Førsteutkast Andreutkast Endlig Revidert 1 Kladd hvor gruppemedlemmene har skrevet hver sin del Versjon som skal leses gjennom og godkjennes av alle på gruppa før levering 19.09.05 22.09.05 Ferdig versjon til oppdragsgiver. 23.09.05 Lagt til punkt 3.3 Kontrollmekanismer, utdypet punktet 2.1 Prosessmodell og endret noe av det visuelle. 29.09.05.rtf (10/04/05) Side 1
INNHOLD 1. INTRODUKSJON... 3 1.1 PROSJEKTET... 3 1.2 PROSJEKT LEVERANSER... 3 1.3 UTVIKLING AV PROSJEKTPLAN... 4 1.4 REFERANSER... 4 1.5 DEFINISJONER OG AKRONYMER... 4 2. PROSJEKTORGANISERING... 5 2.1 PROSESSMODELL... 5 2.2 ORGANISATORISK STRUKTUR... 6 2.3 PROSJEKTANSVARSOMRÅDER... 6 3. STYRINGSPROSESSER... 8 3.1 RISIKO PLANLEGGING... 8 3.2 RISIKOHÅNDTERING... 9 3.3 KONTROLLMEKANISMER... 9 4. TEKNISK PROSESS... 11 4.1 METODER, VERKTØY OG TEKNIKKER... 11 4.2 PROSJEKTHJELPEMIDLER... 11 5. AKTIVITETSPLAN OG RESSURSALLOKERING... 12.rtf (10/04/05) Side 2
1. INTRODUKSJON 1.1 Prosjektet Health Care er et privat sykehus eid av flere leger med spesialområde innen hofteoperasjoner og øre, nese, hals operasjoner. Sykehuset har i dag 49 fulltidsansatte og 2 avdelinger med 3 operasjonsrom i hver avdeling. Hospital Scheduling System, HSS, har to primære mål: Oversikt over tid/menneske ressurser Oversikt over tid/rom ressurser Tid/mennesker går på planlegging av de ansatte, mens tid/rom går på oversikt over pasienttrafikk og operasjoner. HSS skal gjøre at brukerne av systemet bruker mindre tid på papirarbeid, mer tid på pasientene, og har rask tilgang til status på leger, sykepleiere, operasjonsrom osv. 1.2 Prosjekt Leveranser Leveranse 1: 23.09.05 Leveranse 2: 07.10.05 Leveranse 3: 21.10.05 Leveranse 4: 18.11.05 Presentasjon av prosjektet: 21.11.05-25.11.05 Til Leveranse 1 skal det opprettes en hjemmeside for gruppa, http://folk.uio.no/tommyja/inf4120 Alle ferdig skrevet dokumentene legges på denne siden som pdf filer. Leveranse 1 og hjemmeside Leveranse 2 Use-Case modell og UML-design ved hjelp av klassediagram Leveranse 3 Reverse engineering og midtrapport Leveranse 4 Design av ny funksjonalitet, kodegenerering og implementasjon av ny design og oppdatert klassediagram.rtf (10/04/05) Side 3
1.3 Utvikling av Versjon Ansvarlig Versjonsbeskrivelse Dato ferdig Førsteutkast Andreutkast Endelig Tidlig kladd hvor hvert gruppemedlem har skrevet hver sin del. Denne versjonen skal diskuteres på gruppemøte for videre arbeid. Versjon som skal kvalitetssikres og godkjennes av alle på gruppa. 19.09.05 22.09.05 Første versjon til arbeidsgiver. 23.09.05 Midtrapport Gjermund Revidert versjon hvor kommentarer fra arbeidsgiver er tatt med i tillegg til oppdateringer fordi prosjektet har utviklet seg. 1.4 Referanser Software engineering 7 Summerville. Grunnleggende systemutvikling Gunnar Gurholt og Thor E. Hasle. Foiler fra forelesningene i INF4120. 1.5 Definisjoner og akronymer CVS Verktøy for kode og versjonshåntering. UML Unified Modeling Language. 21.10.05.rtf (10/04/05) Side 4
2. PROSJEKTORGANISERING 2.1 Prosessmodell Prosjektoppgaven legger ved første øyekast opp til en forholdsvis tradisjonell prosjektprosess. Måten de fem leveransene er lagt opp på, antyder at prosjektet vil utvikle seg i en serie steg. Det er også utleveret kravspeifikasjon, som i på en meget grundig og detaljert måte beskriver, spesielt de funksjonelle kravene, hva systemet skal bestå av. Leveransene legger også opp til en prosjektutvikling som på mange måter stiller krav til at et steg er fullført før man kan ta fatt på neste. Leversanse 1 vi bestå av en prosjekplan, hvor på leveranse 2 og 3 tar for seg system design. Først etter at disse er på plass kommer den reelle implementasjonen av systemet. På mange måte kan dette antyde en vannfallsmodell. Når dette er sagt, legges det samtidig opp til flere gjennomganger av planer og design fra tidligere steg. Og etterhvert som gruppen, og hvert enkelt gruppemedlem, får bedre kunnskap og innsikt i prosjektet, vil det være naturlig å gå tilbake og korrigere legger til innhold tidligere steg. Innenfor hvert enkelt steg vil det også være naturlig med en iterativ og evlusjonær fremgangsmåte. Hver enkelt leveranse vil deles opp i naturlige arbeidsoppgaver, som deretter fordeles til prosjektmedlemmene..rtf (10/04/05) Side 5
Samtidig vil det, grunnet en relativt beskjeden gruppe størrelse, være naturlig med et tett samarbeid. Dette både krever og medfører at vi vil ha et tett samarbeid på tvers av de indelte arbeidsoppgaver. På denne måter vil vi være i stand til å oppmuntre og korrigere hverandre. Testing vil foregå i parallell med de stegene hvor det vil være hensiktsmessig. Også før hver milepæl vil det være nødvendig med kvalitetssikring og en grundig gjennomgang får å sikre at alle krav er oppfylt. Til sist i prosjektforløpet vil det også være hensiktsmessig å foreta en gjennomgang av hva som har blitt gjort, hvordan det ble gjort og ikke minst hva vi har lært. 2.2 Organisatorisk Struktur Organisasjonsstrukturen i prosjektgruppa er relativt enkel. Dette er naturlig størrelsen på gruppen tatt i betraktning. Strore er prosjekt leder, med Gjermund Gartmann og Tommy Jansson på likt nivå under. Store Gjermund Gartman Tommy Jansson 2.3 Prosjektansvarsområder Ansvarsområde Prosjektleder Planlegging Analyse og design Ansvarlig person Store Gjermund Gartmann Tommy Jansson.rtf (10/04/05) Side 6
Implementasjon Dokumenter og websider Presentasjon Store Tommy Jansson Tommy Jansson.rtf (10/04/05) Side 7
3. STYRINGSPROSESSER 3.1 Risiko planlegging Har her listet opp de riskene som vi må være på vakt ovenfor. Risikoene er listet opp med en sannsynlighet målt i prosent, og hvor stor skade disse hver og en vil utgjør på prosjektet. Skalaen under kolonnen Skade er delt inn på følgende måte; Godtatt-Liten-Seriøs-Ekstrem. Sannsynligheten og skadestørrelsen er beregnet ut ifra magefølelse og tidligere erfaringer innad i gruppa. ID Risiko % Skade R01 Viktig personell blir syke på et kritisk tidspunkt. 30% Seriøs R02 Viktig personell slutter før prosjektslutt. 20% Seriøs R03 Personell skjuler status for å gi godt inntrykk til prosjektlederen og beholde sitt ry på arbeidsplassen. Som igjen fører til forskyvelser av prosesser og planer. 20% Seriøs R04 Umulig å få tak i personell med ønsket kompetanse. 30% Ekstrem R05 Umulig å få tak i den riktige opplæringen til personell. 50% Liten R06 En prosess, som en annen prosess-start er avhengig av, blir forsinket. 40% Seriøs R07 Prosjektets tidsperspektiv er underestimert. 70% Seriøs R08 Kravspesifikasjonen er blitt misforstått. 20% Seriøs R09 Uenigheter angående kravspesifikasjonen hos arbeidsgiver. 20% Ekstrem R10 Oppdragsgiveren foretar seg endringer på kravspesifikasjonen som utgjør store forandringer i programstrukturen. 30% Seriøs R11 Størrelsen på programmet er underestimert. 80% Godtatt R12 Programmets opprinnelige formål om enkelhet oppfylles ikke. 20% Seriøs R13 Hardware holder ikke mål. 35% Seriøs R14 En ny fordelaktig teknologi dukker opp på markedet 25% Liten R15 En teknologi oppfører seg ikke som forventet 40% Liten.rtf (10/04/05) Side 8
3.2 Risikohåndtering For å imøtekomme de mest skadelige risikoene er det viktig at prosjektledelsen holder seg konstant oppdatert om status i de forskjellige prosessene, slik at det kan vurderes kontinuerlig om sannsynligheten for skadelige risikoer økes eller minkes. I tillegg til dette ser vi et absolutt behov for en tiltaksplan for å kunne møte de risikoene som utgjør seriøs eller ekstrem fare for prosjektet. ID R01 R02 R02 R03 R04 R06 R07 R08 R09 Tiltak Overlapping av kvalifikasjoner, spesielt hos viktig personell, slik at om en faller fra kan en annen overta. Her kan også tiltak for R01 være et godt alternativ Bedre samhold blant personellet vil føre til lettere økt deling av kunnskap. Bidra til kollektiv moro for å forebygge dette. Gi oppdragsgiver beskjed om potensielle vanskeligheter og muligheter for at en forsinkelse vil dukke opp. Under slike kritiske faser er det viktig med kontinuerlig oppfølging av arbeidet, slik at det hele tida kan vurderes hvordan det ligger an. Er det kritisk med tid kan det vurderes å jobbe mer i en periode, eller få utsatt leveringene fra oppdragsgiver. Jobbe mer i perioder så vi blir ferdig med prosjektet til fastsatt dato. Det er også en mulighet å diskutere med arbeidsgiver om det er mulig å flytte leveranser så det blir bedre tid. Be flere av prosjektets nøkkelpersoner vurdere kravspesifikasjonen og komme med hver sin liste over frustrerende og unøyaktige punkter. Be til slutt oppdragsgiver om en bedre og mer detaljert beskrivelse av denne listen. R10 Jobbe godt med kravspesifikasjonen i tett samarbeid med oppdragsgiver. Implementere et design som i høy grad tillater endringer. R12 R13 I analysefasen må vi ha i bakhodet at det skal være et enkelt system og tilpasse designet der etter. Bruke andre teknologier eller programmer som støtter tilgjengelig hardware. 3.3 Kontrollmekanismer Under hvert gruppemøte vil alle bli kjent med situasjonen og fremgangen til prosjektet, og da spesielt lederen. For å opprettholde kontinuerlig fremgang og oversikt har vi fastsatt en tid hver uke som vi samles. Guppemøtene vil finne sted mandager kl. 12.00. Utover dette vil vi danne møter etter behov. Referatene fra møtene vil samles på gruppas hjemmeområde, som vi straks vil få tildelt. Timeregistreringsplanen vil nok også få sin naturlige plass på dette hjemmeområdet. Denne vil da følge samme struktur som aktivitetsplanleggeren, med registrering av timer per aktivitet..rtf (10/04/05) Side 9
Gruppens hjemmeside har Tommy Jansson tatt på seg hovedansvaret for, og sidene vil ligge på http://folk.uio.no/tommyja/inf4120. Vi har ikke helt blitt enige om hva den skal inneholde, bortsett fra at det skal være et samlingspunkt og informasjonsvindu for gruppa. Det vil blant annet komme en plan for timeregistrering, som vil følge samme struktur som planleggingen..rtf (10/04/05) Side 10
4. TEKNISK PROSESS 4.1 Metoder, verktøy og teknikker Programmer vi skal bruke: Eclipse Programmeringssuite. Tau UML UML modelleringsverktøy. Microsoft Word Dokumenter. Microsoft Excel GANTT diagram. Dreamweaver Websider. WinSCP3 Filhåndtering på webserver. UML vil bli brukt i analysefasen for å modellere. HSS skal programmeres i Java, og dokumentasjonen av koden skal gjøres ved hjelp av Javadoc. Til versjonshåndtering vil CVS bli brukt. All dokumentasjon skal skrives på norsk i Word med vanlig formattering. 4.2 Prosjekthjelpemidler Konfigurasjonsstyring skal gjøres ved hjelp av CVS. Når det har blitt gjort forandringer i koden skal forandringene commites med kommentar om hva som er endret. Vi har utnevnt en person som er hovedansvarlig for kvalitetssikring. Denne personen skal sjekke at alle SKAL krav er oppfylt og, alt som er blitt gjort er kommet med i leveransene..rtf (10/04/05) Side 11
5. AKTIVITETSPLAN OG RESSURSALLOKERING Fordi vi er en liten gruppe vil det bli naturlig med tettsamarbeid i de forskjellige arbeidsoppgavene. Vi har derfor ikke fordelt arbeidsoppgavene nærmere en hva som her er angitt...rtf (10/04/05) Side 12