PROSJEKTPLAN FOR
INF3120-PROSJEKT: G15
Versjon: Første utkast
1.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 | 01.10.2003 |
| Revidert utkast | Andre utkast endret iflg. kommentarer, distrubuert for gjennomgang før ferdigstillelse | ||
| Ferdigstilt utkast | Ferdigstilt utkast, underlagt revisjonskontroll | ||
| 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 | |
| 2 | Prosjektorganisering | 6 | |
| 2.1 | Prosessmodell | 6 | |
| 2.2 | Ansvarsfordeling i prosjektet | 7 | |
| 3 | Styringsprosess | 8 | |
| 3.1 | Risikohåndtering | 8 | |
| 3.2 | Monitorerings- og kontrollmekanismer | 9 | |
| 4 | Teknisk prosess | 10 | |
| 4.1 | Metoder, verktøy og teknikker | 10 | |
| 4.2 | Støttefunksjoner | 10 | |
| 5 | Arbeidspakker, tidsplan og budsjett | 11 | |
| 5.1 | Tekstlig beskrivelse av aktiviteter | 11 | |
| 5.2 | Arbeidsfordeling | 12 | |
| 5.3 | Aktivitetsplan | 12 | |
| 6 | Bidrag til arbeidsdokumenter | 13 | |
| 6 | Prosjektplan | 13 | |
| 6 | Use Case-dokumentet | 13 |
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, distrubuert 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 |
2. PROSJEKTORGANISERING
2.1 Prosessmodell
Slik prosjektet er satt opp med fastsatt innhold i delleveransene, er det mulig å velge Fossefallmetoden som prosessmodell. 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
Lev V - Evaluering:
Dette kan tilsvare Testfasene i Fossefallmetoden, selv om det her er mest snakk om evaluering av prosjektet, ikke systemet.
Tillegg som fraviker klassisk Fossefallmetode:
Leveranse III vil være oppdatering av prosjektplanen. Slik vi forstår det, vil det være endringer i interne problemstillinger i prosjektet, slik som risiko, aktivitetsplan og lignende. Designet, slik det er godkjent av kunden, vil ikke endres.
Leveranse IV vil også inneholde tilleggsfunksjonalitet. Dette håndteres som egne enheter og syes sammen med helheten. Dette kan også skje, selv om man følger Fossefallmetoden.
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 |
|---|---|---|
| Fratredelser | Liten | Kritisk |
| Sykdom | Middels | Kritisk |
| Endret ledelse | Middels | Lav |
| Mangel på maskinvare | Liten | Kritisk |
| Mangel på eksterne ressurser | Liten | Kritisk |
| Endrede behov | Liten | Liten |
| Forsinkede spesifikasjoner | Liten | Kritisk |
| Undervurdering av størrelse | Stor | 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 vurderes for tiden å være midt i diagrammet vårt. 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.
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å.
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
Nå 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. Vi har likevel noen spesialfelter som de enkelte har hovedansvar for:
- Per Thomas: risiko
- Espen: prosessmodell
- Christer: web-ansvarlig
5.3 Aktivitetsplan
Aktivitetsplanen finnes som eksternt dokument:
http://inf3120g15.chrismic.com/oblig1/prosjektplan/aktivitetsplan.pdf
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 | - | - | - |