PROSJEKTPLAN FOR
INF3120-PROSJEKT: G15
Versjon: Ferdigstilt utkast
9.oktober 2003
Gruppe 15:
MORTEN M. WANG HANSEN
ESPEN URNE
PER THOMAS KRAABØL
CHRISTER MICHAELSEN
Bidrag:
Se kap. 6
REVISJON
| Versjon | Primær(e) forfatter(e) | Versjonsbeskrivelse | Dato fullført |
|---|---|---|---|
| Første utkast | Christer Michaelsen Espen Urne Morten M. Wang Hansen Per Thomas Kraabøl |
Første utkast for distribusjon, gjennomsyn og kommentarer | 19.09.2003 |
| Revidert utkast | Christer Michaelsen Espen Urne Morten M. Wang Hansen Per Thomas Kraabøl |
Andre utkast endret iflg. kommentarer, distribuert for gjennomgang før ferdigstillelse | 01.10.2003 |
| Ferdigstilt utkast | Christer Michaelsen Espen Urne Morten M. Wang Hansen Per Thomas Kraabøl |
Ferdigstilt utkast, underlagt revisjonskontroll | 09.10.2003 |
| Revisjon 1 | Første revisjon, underlagt revisjonskontroll |
FORORD
INNHOLD
| 1 | Introduksjon | 5 | |
|---|---|---|---|
| 1.1 | Prosjektoversikt | 5 | |
| 1.2 | Prosjektleveranser | 5 | |
| 1.3 | Videre utvikling av prosjektplanen | 5 | |
| 1.4 | Endringer siden forrige versjon | 6 | |
| 2 | Prosjektorganisering | 7 | |
| 2.1 | Prosessmodell | 7 | |
| 2.2 | Ansvarsfordeling i prosjektet | 8 | |
| 3 | Styringsprosess | 9 | |
| 3.1 | Risikohåndtering | 9 | |
| 3.2 | Monitorerings- og kontrollmekanismer | 11 | |
| 4 | Teknisk prosess | 12 | |
| 4.1 | Metoder, verktøy og teknikker | 12 | |
| 4.2 | Støttefunksjoner | 12 | |
| 5 | Arbeidspakker, tidsplan og budsjett | 13 | |
| 5.1 | Tekstlig beskrivelse av aktiviteter | 13 | |
| 5.2 | Arbeidsfordeling | 14 | |
| 5.3 | Aktivitetsplan | 15 | |
| 5.4 | Ny kunnskap - endrede estimater | 16 | |
| 6 | Bidrag til arbeidsdokumenter | 17 | |
| 6.1 | Prosjektplan | 17 | |
| 6.2 | Use Case-dokumentet | 17 | |
| 6.3 | Ferdig prosjektplan | 17 | |
1. INTRODUKSJON
1.1 Prosjektoversikt
1.2 Prosjektleveranser
- Prosjektplan
- Use Case-modell
- Domene-modell
- Class-diagram
- Revidert prosjektplan
- Sekvensdiagram
- Nytt class-diagram
- Ny kode
- Implementering av nytt kjørbart system
- Evaluering
1.3 Videre utvikling av prosjektplanen
| Versjon | Primær(e) forfatter(e) | Versjonsbeskrivelse | Dato forventet |
|---|---|---|---|
| Første utkast | Christer Michaelsen Espen Urne Morten M. Wang Hansen Per Thomas Kraabøl |
Første utkast for distribusjon, gjennomsyn og kommentarer | 19.09.2003 |
| Revidert utkast | Christer Michaelsen Morten M. Wang Hansen Espen Urne Per Thomas Kraabøl |
Andre utkast endret iflg. kommentarer, distribuert for gjennomgang før ferdigstillelse | 03.10.2003 |
| Ferdigstilt utkast | Christer Michaelsen Morten M. Wang Hansen Espen Urne Per Thomas Kraabøl |
Ferdigstilt utkast, underlagt revisjonskontroll | 10.10.2003 |
| Revisjon 1 | Christer Michaelsen Morten M. Wang Hansen Espen Urne Per Thomas Kraabøl |
Første revisjon, underlagt revisjonskontroll | 14.11.2003 |
1.4 Endringer siden forrige versjon
Forrige versjon av dokumentet finnes på adressen:
http://inf3120g15.chrismic.com/oblig1/prosjektplan/index.htm
Pkt 2.1 Prosessmodell
- Lagt til nytt avsnitt 1
- Første setning avsnitt 2 (tidl. avsnitt 1) strøket
- Lagt til kommentar i parentes under "Lev IV - Implementasjon og integrasjon"
- Strøket avsnittet "Tillegg som fraviker klassisk Fossefallmetode"
Pkt. 3.1 Risikohåndtering
- Oppdatert tabell
- Lagt til nytt første påfølgende avsnitt
- Neste avsnitt noe forkortet
- Lagt til 5 avsnitt før illustrasjon av risiko
- Oppdatert illustrasjon
- Tillagt bisetning i siste avsnitt
Endringsbeskrivelse: Noe øket alvorlighet knyttet til risikiene. Hovedsakelig knyttet til knapp tid og at vi har brukt opp evt. slakk.
Pkt. 5.2 Arbeidsfordeling
- Tillegg i avsnitt 1
- Nytt avsnitt 2
- Resten strøket
Pkt. 5.3 Aktivitetsplan
Oppdatert i sin helhet
Nye punkter
- 5.4 Ny kunnskap - endrede estimater
- 7. Endringer siden forrige versjon
2. PROSJEKTORGANISERING
2.1 Prosessmodell
Etter å ha fått en bedre forståelse av hele prosjektet, ser vi at det vil det være naturlig å benytte en iterativ prosessmodell som spiralmodellen. Vi skal i Leveranse IV analysere og designe systemet på nytt og får mulighet til endre tidligere løsninger. Hver runde i spiralmodellen følger til en viss grad Fossefallmetoden.
Fossefallmetoden er en metode for å designe systemer som er bygd på veldefinerte faser i utviklingen.
Fasene kommer i rekkefølge (jfr. Sommerville):
- Kravanalyse
- Design
- Implementasjon
- Integrasjon
- Drift
Enkelt kan man si at hver fase må være ferdig og "godkjent" av oppdragsgiver, før man begynner på neste fase. Metoden forutsetter at oppdragsgiver er i stand til å stille de riktige og nødvendige krav fra prosjektets start og at alle behov til den fremtidige løsningen kan beskrives tilstrekkelig presist.
Leveranseplanen i prosjektet gjenspeiler i stor grad fasene:
Lev I - Analyse:
I dette prosjektet har kunden laget detaljerte krav på forhånd. Oppgaven vår blir da å beskrive vår forståelse av kravene og belyse uklarheter. Kunden "godkjenner" vår forståelse av kravene og våre forutsetninger.
Lev II - Design:
UML Design v.h.a. klassediagram
Lev IV - Implementasjon og integrasjon:
Generering av kode ut fra klassediagram. (Klassediagram endret etter ny forståelse).
Lev V - Evaluering:
Dette kan tilsvare Testfasene i Fossefallmetoden, selv om det her er mest snakk om evaluering av prosjektet, ikke systemet.
2.2 Ansvarsfordeling i prosjektet
| Ansvar | Ansvarlig person |
|---|---|
| Overall Project Manager | Christer Michaelsen |
| Engineering Manager | Espen Urne |
| Quality Assurance Manager | Morten M. Wang Hansen |
| End-User Documentation Manager | Per Thomas Kraabøl |
| Requirements Development | Christer Michaelsen |
| Software Architecture | Espen Urne |
| Technical Self-Reviews | Morten M. Wang Hansen |
| Andre mindre ansvarsområder som dukker opp underveis | Per Thomas Kraabøl |
3. STYRINGSPROSESS
3.1 Risikohåndtering
Risikoen i prosjektet er knyttet til teknologien, menneskene, organisatoriske forhold, verktøyene vi bruker, behovsspesifikasjonen, estimeringen og markedsforhold.
For oss er risikoen knyttet til teknologi meget lav. Det er et forholdsvis lite prosjekt, med få aktører og oversiktlig arkitektur.
Risikoen knyttet til menneskene vurderes til vesentlig. Prosjektet er bemannet med alle tilgjengelige ressurser som alle må ansees å ha lite erfaring med denne type prosjekter. Vi er kun 4 stykker, uten mulighet for å overlappe hverandre på kritisk kompetanse. Vi har ingen mulighet til å hente alternativ kompetanse om noen skulle bli syke eller av andre grunner velge å fratre. Tidsfristene synes forholdsvis knappe.
De organisatoriske forholdene er oversiktlige. Prosjektet strekker seg ikke over lang tid. Risikoene knyttet til organisatoriske forhold vurderes som lav.
Det er en betydelig risiko knyttet til bruk av verktøyene. Vi har liten erfaring både med verktøyene vi skal bruke og tilsvarende andre verktøy, slik at det er risiko knyttet til deltakerenes opplæringsbehov. Det er også slik at vi ikke selv har påvirkning på verktøyenes tilgjengelighet. For dette må vi forholde oss til eksterne aktører.
Risikoen knyttet til endrede behov synes liten. Det foreløpige arbeidet synes godt gjennomarbeidet og prosjektet er antatt gjennomført på kort tid slik at forutsetningene trolig ikke vil endre seg.
Det finnes en usikkerhet knyttet til estimatene i prosjektet. Denne er spesielt knyttet til prosjektorganisasjonens begrensede erfaring.
| Risiko | Sannsynlighet | Trussel |
|---|---|---|
| Tidkrevende / feil tolkning av oppgaven | Stor | Kritisk |
| Fratredelser | Liten | Kritisk |
| Sykdom | Middels | Kritisk |
| Endret ledelse | Middels | Lav |
| Mangel på maskinvare | Middels | Kritisk |
| Mangel på eksterne ressurser | Liten | Kritisk |
| Endrede behov | Liten | Liten |
| Forsinkede spesifikasjoner | Liten | Kritisk |
| Undervurdering av størrelse | Middels | Middels |
| Utilstrekkelig CASE-verktøy | Liten | Stor |
| Utilstrekkelig kompetanse på CASE-verktøy | Middels | Stor |
| Endret teknologi | Liten | Liten |
| Produktets konkurransesituasjon | Liten | Liten |
Risikobildet for vårt prosjekt har endret seg noe. Alvorligheten om noe skal skje er noe høyere nå enn tidligere. Vi er ikke i stand til å hente inn noe av forsinkelsene. Den slakken vi hadde finnes ikke lenger. Konsekvensene om vi møter på problemer er derfor høyere nå. Dette vil vi forsøke å rette ved en strammere styring av prosjektet.
Prosjektet er i mange henseender forholdsvis lite. Det er ingen stor organisasjon hvor systemet skal implementeres og prosjektet gjennomføres på kort tid. Dette gjør at prosjektet er oversiktlig og at risikoen med hensyn til konkurrerende teknologier og produkter blir liten. Forarbeidet som er gjort i prosjektet synes godt gjennomført og med god kvalitet.
Vi erfarer at gruppen har vanskeligheter med å tolke og forstå oppgaven. Dette resulterer i stort tidsforbruk før vi kommer i gang med å løse oppgavene. Når vi først kommer i gang med oppgaveløsningen er vi rimelig effektive. Dette har også resultert i at det har vært vanskelig å finne rett fordeling på oppgavene.
Trusselen er blitt noe høyere knyttet til endrede behov fordi tilgjengelig tid er blitt knappere og endringer vil true leveringstidspunket.
Vi opplever mangel på maskinvare. Tilgangen på maskiner, spesielt på termstuene, er tidvis meget vanskelig. Risikoen knyttet til mangel på maskinvare justeres derfor opp fra liten til middels. Trusselen knyttet til dette er fremdeles kritisk.
Risiko knyttet til undervurdering av størrelsen justerer vi noe ned. Vi har lagt ned betydelig arbeide i prosjektet til nå og vi har nå bedre oversikt over arbeidsmengdene fremover.
Oppsummert mener vi at risiko for prosjektet nå er omtrent like sannsynlig som tidligere i prosjektet. Alvorligheten knyttet til risikoene er blitt større. Først og fremst fordi tiden er en knapp ressurs for oss.
Risikoene i prosjektet synes å være størst med tanke på estimeringene og på personellsiden.
For estimeringene gjelder at de er gjort etter beste evne, men uten erfaring fra tilsvarende prosjekter. Dette representerer en risiko for at prosjektet helt eller delvis er feilestimert og gir skjev belastning på gruppen.
Prosjektorganisasjonen er lite fleksibel med tanke på sykdomsfrafall eller andre fratredelser. Medarbeiderne er uten relevant erfaring. Det finnes ingen overlapping av kritisk kompetanse, og det er korte tidsfrister.
Ved gjennomføringen synes det derfor riktig å monitorere fremdriften nøye. Organisasjonen vil i liten grad kunne hente ekstra ressurser for å arbeide inn eventuellt etterslep. Det er derfor meget viktig å avdekke problemer så tidlig som mulig.
For å begrense skadene knyttet til risikoen i prosjektet og risikoen selv, er det viktig å benytte den tiden vi har godt, og å ha størst mulig risikobuffer. Det betyr at vi må være ferdige i god tid med aktivitetene våre slik at vi kan samle ressursene der det eventuelt måtte oppstå problemer. Prosjektgruppen må ta et felles ansvar for alle aktivitetene, og være forberedt på å hjelpe til også utenfor avtalte arbeidsoppgaver.
Vi må også sørge for å holde tidsfristene slik at prosjektet ikke trekker ut i tid. Om prosjektet tar lenger tid enn antatt vil usikkerhetene knyttet til både organisatoriske forhold, og endrede behov bli mer sannsynlige. Også usikkerhet i forhold til teknologi og markedssituasjon blir mer markante om prosjektet tar lang tid å gjennomføre.
Risikoer knyttet til eksterne aktører vil prosjektgruppen ha liten påvirkning på, og denne risikoen må nå vektlegges mer.
3.2 Monitorerings- og kontrollmekanismer
Gruppen har som mål å skriftlig dokumentere hendelser fortløpende gjennom hele utviklingsprosessen. Informasjon utveksles internt i Word-dokumenter og ved bruk av e-post, møter dokumenteres i form av møtereferater. All dokumentasjon bevares gjennom prosessen, og viktige spørsmål, synspunkter osv. som måtte oppstå vil bringes videre og drøftes internt i gruppen samt med oppdragsgiver.
Timelister føres foreløpig manuelt av den enkelte person, men det er mulig at det lages et verktøy for dette som gjøres tilgjengelig gjennom prosjektets nettsted. Se mer under avsnitt 4.2 Støttefunksjoner.
4. TEKNISK PROSESS
4.1 Metoder, verktøy og teknikker
For å modellere systemet vil vi bruke verktøyet TAU_UML for å konstuere UML-modeller. Kodingen er tenkt gjennomført ved hjelp av JAVA.
Testing og kvalitetssikring utføres ved å lage testcaser der vi på forhånd vet resultatet, og sjekker det opp mot resultatet systemet gir oss. Det skal være forskjellige personer som skriver testcase og programkode for enhver del av systemet.
Det vil også gjennomføres en leveransetest - test som vi utfører før systemet overleveres kunden, der vi også tar en dokumentgjennomgang for å kontrollere at vi har fått med alt.
Til slutt gjennomføres akseptansetest i samarbeid med kunden.
4.2 Støttefunksjoner
Prosjektet har fått eget nettsted med funksjonalitet tilpasset prosjektet. Etter innlogging vil prosjektdeltagerne ha tilgang til alle dokumenter. Det finnes en enkel versjonshåndtering, basert på inn- og utsjekking av dokumenter, slik at kun en person av gangen kan arbeide med dokumentet.
Mht. kildekode og tilhørende dokumentasjon er det ikke tatt endelig stilling til om man skal ta i bruk CVS eller et lignende system. Det synes imidlertid tilfredsstillende å tilordne ansvaret for enkeltdeler (klasser) av systemet til enkeltpersoner, som sørger for feilretting og oppdatering av disse. Man vil på et prosjekt av denne størrelsesorden fint klare seg uten et mer avansert system.
5. ARBEIDSPAKKER, TIDSPLAN OG BUDSJETT
5.1 Tekstlig beskrivelse av aktiviteter
Prosjektplan
Dette dokumentet. En plan over prosjektet og dets gjennomføring.
Use case-modell
En modell der use casene blir framstilt.
Domenemodell
En modell som får fram forholdet mellom konsepter i applikasjonsdomenet, det vil si klasser med tilhørende attributter og entitetene mellom dem.
Reverse engineering
Når man endrer på design og spesifikasjon utifra kildekoden.
Klassediagram
Diagram som viser de forskjellige klassene, med metoder, attributter, entiteter og avhengigheter mellom dem.
Sekvensdiagram
Diagram som får fram hendelsesflyten i et use case, og viser hvordan objekter kommuniserer.
Koding
Koding av systemet som skal foregå i Java.
Implementering
Brukbart system slik det er tenkt å være for å gjøre det klart til testing.
Validering/verifisering
Sjekk av systemet, for å finne ut om alt er som det skal, og om det kan leveres kunden. Utførelse av forskjellige tester, både alene og i felleskap med kunden.
Leveranse
Levering av det ferdige produktet til kunden.
Evaluering
Evaluering av leveransen og arbeidet.
5.2 Arbeidsfordeling
I de innledende fasene har vi bestemt at alle er med på alle deler av prosjektet, slik at vi blir kjent med innholdet, arbeidsmetoder og hverandre. Dette er ikke den mest effektive måten å få fremdrift i prosjektet på, men i mangel av erfaring er det viktig og kunne dra nytte av hverandres kunnskaper.
Senere i prosjektet, når vi skal designe og generere ny funksjonalitet, er det naturlig å dele opp i konkrete oppgaver for den enkelte.
5.3 Aktivitetsplan
Overordnet aktivitetsplan viser hvilke aktiviteter som blir berørt i hvilke perioder:
Den detaljerte aktivitetsplanen finnes som eksternt dokument:
http://inf3120g15.chrismic.com/oblig3/prosjektplan/aktivitetsplan2.pdf
5.4 Ny kunnskap - endrede estimater
Vi har nå fått tilgang på eksisterende kildekode, og har gått igjennom denne. Vi har avdekket hvilken funksjonalitet som allerede er implementert, og hva som må implementeres. En nærmere beskrivelse finnes her:http://inf3120g15.chrismic.com/oblig3/kode-kommentarer.htm
Dette har gitt oss et vesentlig bedre grunnlag for å estimere tidsbruk på redesign, koding og testing. Vi føler at vi har fått mye bedre oversikt over prosjektet, hva som skal gjøres, og tidsbehovet.
6. BIDRAG TIL ARBEIDSDOKUMENTER
6.1 Prosjektplan
| Aktivitet | Tid brukt per person | |||
|---|---|---|---|---|
| Christer | Espen | Morten | Per Thomas | |
| Revisjon | 0:15 | 0:15 | 0:15 | 0:15 |
| Pkt. 1.2 | 1:00 | 1:00 | 1:00 | 1:00 |
| Pkt. 1.3 | 0:30 | 0:30 | 0:30 | 0:30 |
| Pkt. 2.1 | - | 3:00 | - | - |
| Pkt. 2.2 | 0:15 | 0:15 | 0:15 | 0:15 |
| Pkt. 3.1 | - | - | - | 5:00 |
| Pkt. 3.2 | 0:15 | - | - | - |
| Pkt. 4.1 | - | - | 2:00 | - |
| Pkt. 4.2 | 0:20 | - | - | - |
| Pkt. 5 | 4:00 | - | 4:00 | 4:00 |
| Innføring, legge ut på web 1. gang | 7:30 | - | - | - |
| Innføring, legge ut på web 2. gang | 3:00 | - | - | - |
6.2 Use Case
| Aktivitet | Tid brukt per person | |||
|---|---|---|---|---|
| Christer | Espen | Morten | Per Thomas | |
| Pkt. 1.1 | 0:20 | 0:20 | - | - |
| Use Case (møte / diskusjon) | 2:00 | 2:00 | 2:00 | 2:00 |
| Pkt. 1.2 | - | 4:00 | 2:00 | - |
| Pkt. 1.2.1 og 1.2.2 | - | 1:00 | - | - |
| Pkt. 1.3 | 4:00 | - | 4:00 | - |
| Pkt. 1.4 | 0:10 | 1:00 | - | 0:10 |
| Innføring, legge ut på web 1. gang | 3:30 | 2:00 | - | 2:00 |
| Innføring, legge ut på web 2. gang inkl. oppdatere UC-diagram og domenemodell | 3:00 | - | - | - |
6.3 Endring prosjektplan (midtrapport 09.10.2003)
| Aktivitet | Tid brukt per person | Sum | |||
|---|---|---|---|---|---|
| Christer | Espen | Morten | Per Thomas | ||
| Gjennomgang | 2:00 | 2:00 | 2:00 | 2:00 | 8:00 |
| Pkt. 2.1 | - | 1:30 | 0:30 | 0:30 | 2:30 |
| Pkt. 3.1 | - | 0:30 | 0:30 | 1:30 | 2:30 |
| Pkt. 5 | - | 3:00 | 1:00 | 2:00 | 6:00 |
| Pkt. 5.4 (m. tilh. ekst. dok.) | 2:10 | - | - | - | 2:10 |
| Innføring, legge ut på web | 3:10 | - | - | - | 3:10 |
| Revisjon | 0:15 | 0:15 | 0:15 | 0:15 | 1:00 |
| Innføring, legge ut på web 2.gang | 2:00 | - | - | - | 2:00 |
| Sum | 9:35 | 7:15 | 4:15 | 6:15 | 27:20 |