Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Transkript

1 Innhold Innledning... 2 Faseplan... 2 Iterasjonsplanlegging... 3 Oppstartsfasen... 3 Artefaktene i oppstartsfasen... 4 Utdypingsfasen... 5 Konstruksjonsfasen... 5 Overføringsfasen... 6 Litteratur

2 Innledning I dette notatet summerer vi opp de sentrale tingene ved planlegging av UP-prosjekter og hva som gjøres i oppstartsfasen. Vi legger mest vekt på det som skjer i oppstartsfasen fordi det er det dere må ta tak i med tanke på første innlevering. I UP planlegges det på to nivåer ved at man lager en overordnet faseplan og detaljerte planer for hver iterasjon etter hvert. Temaet er behandlet kort i kapittel 40 i læreboken (Larman, 2005). I UP er det Use case som driver prosjektet. Det betyr at arbeidet i hovedsak organiseres rundt det å realiserer use case, de viktigste og mest kritiske for suksess først, deretter de mindre viktige og mindre kritiske. Men det betyr ikke at oppstartsfasen er en kravanalysefase i fossefallsforstand. Det er ikke gitt at en use case kan realiseres i en iterasjon. Noen use case kan være så store at de trenger flere iterasjoner og går over flere faser. Faseplan I UP er det fire faser. Faseplanleggingen er på overordnet nivå og består i å fastsette mål, milepæler og sluttdato for hver fase. I oppstartsfasen er estimatene for milepælene vage. Etter hvert som man arbeider seg gjennom bearbeidingsfasen, blir estimatene bedre og bedre. Et mål for bearbeidingsfasen er å ha fått frem nok realistisk informasjon til at man kan forplikte seg på milepæler og mål for slutten av konstruksjonsfasen og overføringsfasen. En grov faseplanen for et lite prosjekt, typisk 5000 linjer Javakode, kan se slik ut: Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1 1 (3) 1 (6) 3 (6) 1 (3) Tallene er kun ment som retningslinjer. I vårt prosjekt hvor vi også skal lære, kan det være nødvendig med flere, men kortere iterasjoner i alle faser slik som antydet i undervisningsplanen. For et større prosjekt med linjer Javakode er dette en typisk faseplan: Inception Elaboration Construction Transition Bemanning Varighet i uker Antall iterasjoner (lengde 1 (6) 2(8) 4(9) 1 (6) i uker i parentes) Tabell 2 2

3 Iterasjonsplanlegging Hovedideen med iterativ utvikling er at prosjektet stadig må tilpasses etter hvert som man får tilbakemeldinger fra interessepartene (brukere, oppdragsgiver, utviklerne). Man vil derfor bare planlegge i detalj neste iterasjon slik at man kan ta hensyn til den kunnskap man får gjennom tilbakemeldingene. Typiske trinn i iterasjonsplanleggingen er disse: 1. Bestem lengden på iterasjonen. To til seks uker er vanlig. Korte iterasjoner er å foretrekke, men de må ikke være så korte at man ikke får gjort noe fornuftig i iterasjonen. Når en sluttdato er bestemt skal den holdes (timeboxing). Hvis sluttdatoen ikke kan holdes med det opprinnelig planlagte arbeid, må omfanget reduseres. 2. Organiser og gjennomfør et planleggingsmøte. Dette gjøres mot slutten av en iterasjon unntatt for første iterasjon i oppstartsfasen (inception). På planleggingsmøtet deltar de fleste interesseparter: brukere, utviklere, markedsfolk, oppdragsgiver, prosjektleder. 3. Man setter opp en liste med mulige mål for iterasjonen. For eksempel hvilke use case som skal realiseres, feil som må rettes, tester som må kjøres, osv. Målene må rangeres etter viktighet. 4. Hvert medlem i utviklingsgruppen avklarer hvor mye ressurser de har til å jobbe på prosjektet den kommende tiden, for eksempel om de kan jobbe full tid, om de skal ha ferie osv. 5. Et mål blir detaljert og problemer avklart. Så må utviklerne gjennomføre idedugnader for å for å finne detaljerte oppgaver knyttet til målene med estimater for ressursbehovet. Estimatene for alle oppgaver summeres til en total. 6. Punkt 5 gjentas inntil man har fylt iterasjonen med oppgaver. Oppstartsfasen Se kapittel 4 i læreboken (Larman, 2005). Oppstartsfasen er en mulighetsfase. På engelsk feasibility phase. Her skal man avklare om prosjektet er gjennomførbart. Fasen er relativt kort, vanligvis bare en iterasjon. De sentrale oppgavene er å finne frem til 10% av use casene, avklare de kritiske ikkefunksjonelle kravene, få avklart lønnsomheten i prosjektet (engelsk business case) og legge til rette et utviklingsmiljø for den etterfølgende fase. Det man vil ha svar på er typiske spørsmål som: Hva er visjonen for og hva er lønnsomheten i prosjektet? Er det gjennomførbart? Skal man kjøpe eller utvikle? Hva er grovt størrelsesordenen for kostnadene? Dreier det seg om NOK eller er det snakk om flere millioner? Skal vi fortsette eller bare skrinlegge det hele? For å kunne utarbeide en visjon og svare på disse spørsmålene må man få avklart noen krav, men det er ikke meningen å finne alle krav. Alle estimater er også grove overslag. Det er først i utdypingsfasen at de fleste krav avklares. 3

4 Artefaktene i oppstartsfasen UP beskriver en rekke artefakter. Ikke alle er nødvendige i alle prosjekter. Det er også slik at artefakter kan påbegynnes i en fase og gis mer innhold i etterfølgende iterasjoner. Man lager ikke et artefakt hvis det ikke er et klart behov for det. Noen artefakter er midlertidige og laget for å avklare et aktuelt problem. Disse kastes når de ikke lenger tjener noen hensikt. Artefakter som kan være aktuelle å begynne med i oppstartsfasen er vist i Tabell 3 Den er hentet fra side 50 i læreboken (Larman, 2005). I første omgang må dere konsentrere dere om visjonsdokumentet og use casemodellen ettersom det er det dere skal levere først. Artefakt Visjon og lønnsomhet Use casemodell Tilleggsspesifikasjon Ordbok Risiko og plan for risikohåndtering Prototyper og bevis av mulighet Iterasjonsplan Faseplan og utviklingsplan Utviklingsopplegg Tabell 3 Beskriver overordnede mål, rammer, lønnsomhet og sammendrag for ledere. Beskriver de funksjonelle kravene. I oppstartsfasen vil navnene på de viktigste use case bli identifisert og rundt 10% av use casene vil bli detaljert. Andre krav, spesielt ikkefunksjonelle. Definisjon av sentrale ord og uttrykk. En beskrivelse av risikoer og ideer til hvordan de skal unngås eller håndteres. For å klargjøre visjonen og prøve ut tekniske ideer. Beskriver hva som skal gjøres i første iterasjon i utdypingsfasen. Unøyaktig gjetting av varigheten av og ressursbehov for utdypingsfasen samt behov for folk, verktøy, opplæring og andre ressurser. En beskrivelse av UP-trinn og artefakter for dette prosjektet. Et UP-prosjekt må alltid legges opp etter den aktuelle situasjonen. Hva skal man så lage først? Det er det ingen bestemte regler for. Men det kan være fruktbart å veksle mellom de forskjellige artefakter fordi de påvirker hverandre. På side 114 i læreboken (Larman, 2005) finner vi disse rådene knyttet til visjonsdokumentet og use case: 1. Lag et kort første utkast til visjonsdokumentet. 2. Finn frem til brukermålene og navnene til de tilhørende use casene. Dere har tidligere lært om use case. Les likevel kapittel 6 i læreboken. Der finner dere nok noe nytt. 3. Detaljer noen use case og start med de ikkefunksjonelle kravene. Det er det som i UP kalles Supplementary Specification. Se kapittel 7 i boken til Larman. 4. Utvid visjonsdokumentet ved å trekke ut viktig informasjon fra arbeidet med å identifisere use case. 4

5 Et eksempel på et utviklingsopplegg finner dere i Tabell 4 Krav Design Implement. Testdrevet utvikling Parprogrammering Stadig integrasjon Kodestandarder Smidig prosjektledelse Daglige stand up møter Prosjektledelse Tabell 4 arbeidsmøte Intensivt arbeidsmøte Smidig modellering Testdrevet utvikling Disiplin Praksis Artefakt Oppstart Utdyping Konstruk. Overfør. Forretningsmodellering Smidig modellering Intensivt Domenemodell start Use casemodell Visjon Supplerende krav Ordbok Designmodell Arkitekturdokument Datamodell Kildekode Løpende Løpende Løpende Løpende Utdypingsfasen Hovedmålet med denne fasen er å få på plass en kjernearkitektur og håndtering av de største risikoer gjennom en eller flere iterasjoner avhengig av prosjektets størrelse. Kjør flere (korte) iterasjoner. Planlegg neste iterasjon. Revider om nødvendig. Konstruksjonsfasen Her itererer man seg gjennom de gjenværende lettere og lavrisikotingene. Kjør korte iterasjoner. Planlegg neste iterasjon. Revider om nødvendig. 5

6 Overføringsfasen Systemet testes (betatester) og tas i bruk. Vanligvis en iterasjon. Erfaringsrapportering. 6

7 Litteratur Larman, Craig 2005, Applying UML and patterns. An introduction to object-oriented analysis and design and iterative development. Tredje utgave. Upper Saddle River: Prentice Hall. 7