Elaboration

Ett väl utfört arbete under denna fas är ett stort steg på väg mot ett lyckat projekt. Slarvar vi här lever vi väldigt farligt i nästa fas.

Syfte

Syftet med elaboration är att göra en utförlig undersökning. Detta åstadkoms genom att implementera så mycket av produkten i färdig kod att:

• Arkitekturen är klar. För detta krävs att vi kodar något i alla "hörn" av produkten.
• Vi är övertygade om att alla kritiska use case fungerar. Med kritiska menas här både sådana som innehåller tekniska risker och  sådana som innehåller nödvändig funktionalitet.
• Det går att göra en bra uppskattning om hur mycket tid och resurser som krävs för resten av projektet.

Dessutom ska vi ha identifierat mer eller mindre alla krav på produkten, dvs alla dokument som påbörjades i inception ska vara så gott som färdiga.

Den kod som skrivs under elaboration ska inte kastas bort senare, den ska vara med ända till skarp drift.

Tidsåtgång

Elaboration är väsentligt mer tidskrävande än inception men kortare än construction. Elaboration består så gott som alltid av flera iterationer. Hur många iterationer och hur långa dessa ska vara finns det många teorier om och det beror dessutom på projektets karaktär. Min personliga åsikt (som är starkt påverkad både av XP och av egna bistra erfarenheter) är "desto kortare desto bättre". Med kortare iterationer får vi bättre koll på vad som faktiskt är klart och fungerar, vi kan lättare ändra i den befintliga koden och vi kommer snabbare att hitta fel (tiden för debuggning tenderar att växa närmast exponentiellt med tiden för att skriva ny kod).

Slutresultat

Alla artifakter som påbörjades under inception (use case model, supplementary specification (SS), glossary, risc list, vision, user interface prototype) uppdateras under elaboration så att när fasen är slut alla artifakter är i fas och speglar projektets aktuella status. Nya artifakter är främst kod och tester men även Software Architecture Document (SAD) som beskriver systemets arkitektur.

Ändringar

Ett viktigt syfte med vårt arbetssätt är att kunden ska kunna både ändra sig och komma på ny funktionalitet på ett sent stadium. Detta får dock inte ske okontrollerat, alla förändringar måste formaliseras (i samarbete med kunden), godkännas (av projektledaren) och placeras in i lämplig iteration (varvid någon annan funktionalitet kan behöva strykas pga tidsbrist).

Arbetet under en iteration

Under varje iteration implementeras hela eller delar av bestämda use case och ickefunktionella krav. Vilken funktionalitet som ska implementeras under en viss iteration anges i iterationsplanen (iteration plan). Iterationsplanen ska bara innehålla en detaljerad beskrivning av arbetet i aktuell iteration. Innehållet i kommande iterationer och slutdatum för dessa är gissningar, bättre ju närmre itertionen ligger.

Om allt arbete inom en iteration inte hinns med ändras iterationens innehåll, aldrig dess slutdatum.

Arbetet under en iteration består av dessa moment:

1. En kort genomgång av kravspecifikationen (use case model, SS, glossary, user interface prototype). Här har vi möjlighet att uppdatera den med de de föreslagna ändringarna, se avsnittet ändringar ovan. Dessa ändringar kan vara både nya förslag från kunden och förändringar vi kommit på själva under arbetet i föregående iteration. 
   
   I denna aktivitet skriver vi också allt fler use case i detalj. Framför allt måste de use case som ska implementeras i denna iteration vara beskrivna i detalj.
   
2. Analys. Syftet är att omvandla kravspecifikationerna för denna iterations funktionalitet till en mer mjukvarulik form (klasser, delsystem osv). Analysen fokuserar på de funktionella kraven, dvs på en ideal bild av systemet där den krassa verkligheten inte gör sig påmind. Detta innebär att indata till analysen främst är use case-modellen. Utdata är klasser, attribut osv men dessa är "logiska", dvs inte nödvändigtvis klasser och attribut i det program vi ska skriva.
3. Design. Denna aktivitet tar vid där analysen slutar. Syftet är att omvandla analysresultatet till en modell med konkreta klasser metoder osv i programmet som ska konstrueras. Under detta arbete tas även hänsyn till den dystra verkligheten i form av ickefunktionella krav.
4. Kodning och testning. Här implementeras designresultatet i konkret kod. Det är koden som ska vara informationsbärande (dvs förmedla det som vi kommit fram till i ovanstående punkter) och det är koden som avgör vad kunden till slut kommer att tycka om vårt arbete. Därför ligger tyngdpunkten av arbetet i en iteration här. Tätt sammanvävt med kodning är testning. Det finns många olika sorters test. Dels har vi tester av olika stora delar av systemet: enskilda metoder, klasser, paket, vissa use case, hela systemet och dels kan vi testa olika saker: funktionalitet, prestanda, vilken last systemet klarar osv. Observera att test inte är en aktivitet som utförs separat på slutet utan något som pågår hela tiden.
5. Integrering av den nya funktionaliteten med de delar av systemet som tagits fram i tidigare iterationer.

Ofta kommer det att hända att vi vid arbete på någon av punkterna hittar fel i resultatet från tidigare punkter. Det är helt OK och faktiskt själva anledningen till att arbeta iterativt. Kravspecifikationer, analys och design är viktiga men inte färdiga perfekta modeller av systemet. Se dem som "en stunds eftertanke för att komma mer rätt från början". Vi kommer också att hitta fel i koden från tidigare iterationer och även detta är helt OK.

Om en iteration tar en vecka kanske en erfaren programmerare skulle fördela tiden så här:  0,5 dagar kravhantering och analys, 0,5 dagar design, 3,5 dagar kodning (omväxlande nyutveckling, förbättring av befintlig kod och testning) samt 0,5 dagar integration (inte i en klump på slutet utan i små block i slutet av varje dag). För oss kommer förmodligen analys och design att ta mer tid, åtminstone i början.

Det finns två mycket felaktiga sätt att arbeta. Det ena är att inbilla sig att analys och design ska vara kompletta, perfekta modeller (vattenfallsprocess) vilket kanske resulterar i en dag kravhantering, en dag analys, två dagar design och sedan panik. Det andra felaktiga sättet är att inte se någon poäng med analys och design (vilt hackande). Resultatet av det kanske blir någon timmes kravhantering, analys, design följt av ett par dagars kodning (utan test) och sedan buggrättning utan framgång tills projektet blir nedlagt.

När en iteration är slut ska följande vara gjort:

1. All ny kod är helt integrerad med det sedan tidigare iterationer befintliga systemet. 
2. Hela systemet inklusive den nya koden har passerat alla nya och gamla tester.
3. Kunden har engagerats i en utvärdering av den nya versionen. 
4. En detaljerad plan för arbetet i nästa iteration är framtagen.