SLUTTRAPPORT FOR
INF3120-PROSJEKT: G15

Versjon: 1.0

21.november 2003

Gruppe 15:
MORTEN M. WANG HANSEN
ESPEN URNE
PER THOMAS KRAABØL
CHRISTER MICHAELSEN

INNHOLD

1Innledning   3
 
2Vurdering av ressursestimering   4
2.1Estimert vs faktisk ressursforbruk   4
2.2Forklaring til resultatet   4
 
3Erfaringer fra prosjektgjennomføring   6
 
4Evaluering av leveransene   9
4.1Analysefasen   9
4.2Designfasen   9
4.3Implementeringsfasen   9
4.4Konklusjon   10
 
5Evaluering av kurset   11
5.1Pensumlitteratur   11
5.2Forelesninger   11
5.3Obligatoriske oppgaver   11
 

1. INNLEDNING

Vi skal i denne sluttrapporten evaluere prosjektet, både når det gjelder gjennomføring og kvaliteten på resultatet.

Rapporten vil først sammenlikne forholdet mellom estimert og faktisk tidsforbruk og begrunne resultatet. Videre vil vi beskrive erfaringer vi gjort oss i forbindelse med prosjektarbeidet. Kapittel 4 beskriver hva vi mener om kvaliteten på vår gruppes leveranser sammenliknet med leveransene til prosjektgruppe 11. Til slutt vil vi gi ris og ros til opplegget rundt de obligatoriske oppgavene.

2. VURDERING AV RESSURSESTIMERING

Dette kapitlet beskriver estimert og faktisk tidsforbruk, sammenlikning av disse og en forklaring til resultatene (avviket/likheten). Vi beskriver først utgangspunktet, og hva som lå til grunn for vår estimering. Deretter litt om hvordan vi estimerte tidsforbruket, og til slutt kommenteres forskjellen på virkelig og estimert tidsforbruk.

2.1 Estimert vs faktisk ressursforbruk

Når vi i begynnelsen av semesteret skulle estimere tid var det flere ting som bidro til usikkerhet. Noen elementer var vi klar over, andre har vi erfart gjennom prosjektet. Den mest åpenbare usikkerheten var knyttet til vårt erfaringsgrunnlag. Ingen av prosjektdeltakerene hadde relevant erfaring å bygge på fra denne type prosjekter. Vi hadde erfaring fra deler av oppgavene, men i andre sammenhenger. For estimeringen var det nødvendig å få en oversikt over aktivitetene som skulle gjennomføres.

På dette grunnlaget valgte vi 'reverse estimering'. Vi fordelte tilgjengelig tid etter beste skjønn på de forskjellige aktivitetene, mye i tråd med eksemplet fra feriebudsjettering i forelesningen. Da vi hadde lite informasjon om prosjektaktivitetene var dette den eneste mulige tilnærmingen. For at denne estimeringen av tid skal kunne brukes må det være en viss fleksibilitet i oppgaven som skal utføres slik at arbeidsmengden kan tilpasses noe. Slik fleksibilitet var det i prosjektet, og vi hadde også anledning til å bruke noe mer tid om det ble nødvendig.

Utsnitt av aktivitetsplanen

Aktivitet Estimert vs. Brukt tid
EstimertBruktAvvik
Prosjektplan30:0030:000%
Use Cases20:0022:0010%
Domenemodell08:0015:0091%
Reverse engineering10:0026:00160%
Klassediagram12:0078:00541%
Sekvensdiagram30:00150:00400%
Koding30:0034:0013%
Implementering30:0010:00-67%
Validering&verifisering20:0004:00-80%
Leveranse10:0007:00-30%
Evaluering25:0036:0044%
Totalt avvik +83%

2.2 Forklaring til resultatet

Når vi i ettertid sammenligner virkelig og estimert tid kan vi konstatere en overskridelse på hele 83%.

Det reelle avviket er egentlig enda større, da vi leverte en enklere løsning enn forespeilet. Dette gjorde at vi kunne ta inn igjen en del av forsinkelsene ved at koding ble gjort på kortere tid. Vi bommet kraftig når vi estimerte tid for aktivitetene knyttet til bruk av TAU-pakken. Jevnt over har vi tatt i for lite. Mot slutten av prosjektet har vi hentet mye av dette inn igjen ved å redusere omfanget av arbeidet knyttet til koding, testing, validering og verifisering.

De store avvikene skyldes for lite informasjon som grunnlag for estimatene , som beskrevet ovenfor. I tillegg oppsto enkelte problemer som har gitt oss mye ekstra arbeide underveis. Spesielt har det slått kraftig ut at det var nødvendig for oss å gjøre mye av arbeidet to og to. Vi var svært usikre på hvordan vi skulle gjennomføre mye av arbeidet og det viste seg nødvendig, eller svært nyttig, å være to som sammen diskuterte oppgaven mens vi arbeidet. Dette resulterte i høyere tidsforbruk enn vi antok i utgangspunktet.

3. ERFARINGER FRA PROSJEKTGJENNOMFØRING

Dette kapittelet beskriver de erfaringer vi har hatt i forbindelse med gjennomføring av prosjektet.

For å kartlegge positive og negative erfaringer fra gjennomføringa av dette prosjektet har vi foretatt en Post-Mortem Analyse (PMA), ved først å sette opp en mengde innspill til hva som var viktig for prosjektet, både positive og negative. Vi brukte en såkalt KJ-metode (oppkalt etter Jiro Kawakita) for å komme fram til disse. Den består i å skrive ned på gule lapper, og så gruppere disse for oversikt. Deretter satte vi opp et såkalt Ishikawa-diagram, eller fiskebeinsdiagram om du vil, en gruppering av årsaker til problemer eller suksesser.

Ved KJ-metoden kom vi fram til følgende grupperinger (med negativ/positiv indikasjon foran):

Gruppedynamikk:

Ressurser:

Prosjektstyring:

Kompetanse:

Rammebetingelser:

Fiskebeinsdiagram: Fiskebeindiagram

Merknader: Tidsbruk står oppført på begge fordi siden kompetansen på ulike områder er ulik, vil det bety enten økt eller redusert tidsbruk alt ettersom. (Det samme vil også gjelde de andre punktene med +/-)

For mye lunsj betyr ikke at vi har spist for mye, men at det noen ganger kan bli litt mye utenomsnakk og dårlig fokus, så vi bruker lenger tid på en sak enn vi optimalt hadde fått til.

Vi mener vi har hatt et trivelig arbeidsmiljø i gruppa, der alle fritt har kunnet komme med sine meninger og vurderinger. Tilgjengelige ressurser har vært litt varierende. Som oftest har det vært ledige maskiner til oss, men ofte har vi måtte gått fra IfI til PO eller holdt oss der. Der har det til gjengjeld ofte vært gruppetime, slik at vi ikke fritt har kunnet diskutere. Det må allikevel nevnes at dette ikke har vært noe stort problem for oss. TAU_UML har ikke alltid virket når vi skulle bruke det (kan skyldes vår inkompetanse med verktøyet). Dette har heller ikke vært et kjempestort problem for oss, men det har hatt stor betydning når det ikke har virket. Da har vi ikke fått gjort det vi hadde tenkt til. Uklarhet i hva de forskjellige innleveringene skulle bestå av, har også gjort at vi har brukt litt lenger tid enn vi kunne. Vi har ikke alltid umiddelbart sett helt klart hva som skulle gjøres. Vi har også brukt litt tid på å tilegne oss kunnskaper om TAU_UML da de eneste kunnskapene vi hadde om dette på forhånd var som et reint grafisk designprogram (hvordan tegne diagrammer, ikke kobling mot klasser og lignende). Uklar kravspesifikasjon har også voldt oss litt problemer og tatt litt tid fra oss.

4. EVALUERING AV LEVERANSENE

I dette kapittelet evaluerer vi kvaliteten på våre leveranser. For å få et forhold til nivå på kvaliteten, skal vi sammenlikne våre leveranser med en annen prosjektgruppes leveranser. Vi har blitt tildelt gruppe INF3120-11 sitt prosjekt som sammenlikningsgrunnlag.

Vi har valgt å dele opp evalueringen i forhold til fasene i prosjektet.

4.1 Analysefasen

Leveranse I tok for seg fasen Analyse i prosjektet. Denne leveransen inneholder prosjektplan, Use Case-diagram og domenemodell.

Etter gjennomlesning av Gruppe 11 sin prosjektplan, ser vi at vår er noe mangelfull. Vi mener at innholdet av prosjektplanen vår er av relativt god kvalitet, men at sammenhengen ikke er god nok. Vi mangler nok en helhet i dokumentet som holder en rød tråd og gir følelse av kontroll i prosjektet. Kapitlene er litt selvstendige og mangler sammenheng. Gruppe 11 har gjennomgående språk i hele dokumentet og passende brødtekst som knytter kapitlene sammen. Det kan virke som om gr. 11 har benyttet kun en deltager til å skrive all brødteksten i dokumentet, noe som gjør det mer lettlest og sammenhengde fordi språkbruken er lik gjennom hele dokumentet.

Ved å sammenlikne prosjektplanene, kan man tydlig se at gr.11 har lagt ned mye mer arbeid i oppdeling i delaktiviteter, estimering og beskrivelse av dette. Vi synes de har lagt vel mye vekt på dette, så en mellomting hadde nok vært det beste.

Totalt sett innser vi at gr.11 sin prosjektplan er bedre enn vår.

4.2 Designfasen

Innenfor fasebetegnelsen Design leverte vi klassediagram og sekvensdiagram. I Leveranse II lagde vi forslag til klassediagram som skulle beskrive datalaget i henhold til kravspesifikasjonen. I Leveranse IV lagde vi sekvensdiagram for den funksjonaliteten som ikke ble dekket av pre-implementert system samt nytt klassediagram.

Vi la mye arbeid i sekvensdiagrammene og mener at disse ble gode. Vi var litt usikre på notasjonen, men logikken kommer tydlig fram og hjalp oss i forbindelse med kodingen. Det detaljerte nivået gjorde også at vi innad i gruppa fikk en omforent forståelse av funksjonaliteten.

Klassediagrammet fra LevII var nok noe mangelfullt, både på innhold og ikke minst beskrivelse. Diagrammet fra LevIV mener vi er dekkende i forhold til kravspesifikasjon, selv om den avviker en god del fra modellen generert fra utdelt kode.

4.3 Implementeringsfasen

I Leveranse IV skulle vi implementere ny funksjonalitet. Vi vurderte eksisterende kode som tung å sette seg inn i og enkelte steder direkte dårlig. Blandt annet var klare GUI-elementer lagt i kontroll-laget.

Vi valgte derfor å begynne helt fra scratch og gikk over til en ren 2-lags-arkitektur. Vi valgte en GUI-løsning med arkfaner istedet for popup-bokser. Vi synes denne løsningen var både penere og langt mer praktisk. Rammeverket vi lagde for videre implementering var vi også meget godt fornøyd med.

Vi må likevel innrømme at omfanget av arbeidet med å begynne med blanke ark, var langt større enn forventet. Derfor ble vi heller ikke ferdig med den funksjonaliteten som vi hadde planlagt å få med. Hadde vi hatt mer tid, tror vi at dette kunne bli en meget god løsning.

4.4 Konklusjon

I obligteksten står det at vi skal vurdere "mulighetene til å implementere et godt system basert på det som er gjort så langt i utviklingen av systemet". Generelt mener vi at mye ligger til rette for videre implementasjon. Modell-laget ligger klart i klassemodellen og dekker funksjonaliteten i forhold kravspesifikasjonen. Det nye GUI-laget er bedre enn tidligere og vi har laget et "rammeverk" som standardiserer og forenkler videre implementasjon av funksjonalitet.

Det vi ikke er helt fornøyd med er prosjektplanen. Denne er kanskje noe tynn og mangler en helhet som viser at vi har kontroll på prosjektet.

5. EVALUERING AV KURSET

I dette kapittelet vil vi gi ris og ros til opplegget rundt den obligatoriske prosjektoppgaven

5.1 Pensumlitteratur

Vi er av den mening at pensum i kurset, særlig boka Software Engineering av Ian Sommerville (6th edition, Addison-Wesley 2000) er for lite rettet mot norske forhold og utviklingsprosjekter i norske bedrifter. Vår oppfatning er at en del av stoffet er ment for en annen målgruppe, det er amerikansk i formen og til tider vanskelig å se relevansen og knytte dette opp mot vårt prosjekt.

5.2 Forelesninger

Vi synes også det kan virke som om forelesningene i liten grad har vært vesentlige for prosjektet, og oppfatter det som om kurset har 2 helt adskilte røde tråder:

Pensum og forelesninger rettet seg i hovedsak mot deler av gjennomføringen / tekniske sider ved gjennomføringen av et prosjekt, som programmeringsteknikker, verktøy, kvalitetssikring og testing osv. Dette er relevant for utførelse av begrensede deler av den obligatoriske oppgaven, som i tillegg hadde mye fokus på den administrative delen.
Det er derfor litt vagt for oss hvilket utbytte vi forventes å ha fått av kurset.

Sammensetningen av forelesningene virker litt tilfeldig. Eksempelvis var forelesningen om XP-programmering interessant, men ved at denne formen for programmering får en hel forelesning settes samtidig andre aktuelle teknikker / tilnærmingsmåter i skyggen. Det hadde vært nyttig med forelesninger også om disse for å skape balanse og perspektiv.
Forelesningen om hva som kommer i UML v.2.0 er i og for seg spennende, men treffer ikke kursdeltagerne som målgruppe, hvor mange knapt vet hvordan de skal bruke eksisterende versjon av UML og tilkyttede verktøy.
Vi hadde ønsket mer gruppeundervisning i modellering med UML, og ville satt pris på mer undervisning i bruk av TAU-UML slik at vi hadde kunnet nyttiggjøre oss dette verktøyet maksimalt.

5.3 Obligatoriske oppgaver

De obligatoriske oppgavene kunne vært utformet annerledes. Vi opplevde at det tok mye tid å forstå hva oppgavene gikk ut på. Dette skyldtes ofte at vi lurte på om vi hadde forstått oppgavene riktig, da vi syntes vi hadde for lite informasjon til å kunne besvare dem.

Som eksempel kan nevnes estimering av tidsbruk i oppgave 1. Vi hadde ingen informasjon om arbeidsmengde i oppgave 4, da vi ikke visste hvor store deler av systemet som skulle implementeres. Vi foretok derfor en "reverse estimering" ved å ta utgangspunkt i hvor mange timer i uken det burde forventes at vi arbeidet med prosjektet, ut i fra antall vekttall i kurset. Vi fordelte deretter disse timene på de forskjellige aktivitetene i prosjektet. Dette er ingen ideell tilnærming. Følgelig har vi unøyaktige estimater.

Vi ville foretrukket en tilnærming basert på mer tilgjengelig informasjon, eksempelvis modeller av eksisterende system, informasjon om hvilken funksjonalitet som var implementert og hvilken som manglet, tilgang til eksisterende kjørbart system eller lignende. Dette ville gitt oss et bedre grunnlag for våre estimater.

Vi mener det ville vært en fordel å ha en mer fullstendig og korrekt kravspesifikasjon. Dette ville motivert mer mot å og modellere et best mulig system, og økt vår forståelse av prosjektets seriøsitet. Det vil ikke være vanskelig å heve kvaliteten på kravspesifikasjon og system, enten ved å ha høyere kvalitet på eksisterende kode og mer implementert funksjonalitet fra før, eller ved å ha et mindre prosjekt som utvikles fra bunnen av.

Dette ville gitt et prosjekt hvor det var lettere å få oversikt over arbeidsoppgaver og estimere basert på aktuell informasjon. Slik ville avvikene vært tydeligere, lettere å forstå og årsakene lettere å identifisere. Nå er det vanskelig å lære av forskjellene mellom estimert og reell tidsforbruk, da estimatene ikke var basert på saklig informasjon.