Detta avsnitt beskriver en projektmodell som kan användas vid utveckling av programvara. De projekt som den är avsedd för är relativt små, till exempel 15-20 personer som arbetar mellan ett halvår eller ett år i projektet. Vore projekt större fordras mer omfattande rutiner.

Projektetmodellen omfattar endast utveckling av programvara. Andra delar av produktutveckling som till exempel hårdvara, marknadsanalys, etc. omfattas inte.

Modellen består av ett antal faser (se figur 5.1) och milstolpar och beskriver vilka leverabler som ska skapas och i vilken ordning det ska ske. För några av leverablerna finns mallar och exempel som stöd för arbetet.

Under projektet ska åtminstone följande leverabler skapas:

• Kravspecifikation
• Projektplan 
• Testplan med testspecifikation 
• Designdokument 
• Användarmanual för systemstart
• Källkod och exekverbart program

Projektet genomförs i följande faser:  

• Fas 1: Specifikation
• Fas 2: Design 
• Fas 3: Implementering och enhetstest 
• Fas 4: Systemtest 

Varje fas avslutas med en milstolpe. Avsikten med en milstolpe är att det tydligt ska framgå om den uppnåtts eller inte och på så vis synliggöra hur långt projektet kommit. Exakt vad som ingår i de olika milstolparna bör vara känt av samtliga deltagare i projektet och övriga andra intressenter, såsom kunder och linjechefer. 

Eftersom det finns fyra faser finns det även fyra milstolpar: 

• MS 1: Specifikation
• MS 2: Design 
• MS 3: Implementation och enhetstest 
• MS 4: Systemtest 

En milstolpe är uppnådd när samtliga leverabler för den fasen är godkända av alla berörda parter. Närmare detaljer om vem som ska godkänna vilka dokument och hur detta bör göras beskrivs i avsnitt 5.4.

Den grundläggande tanken med projektmodellen är att en fas inte påbörjas förrän föregående fas avslutas och dess milstolpe har uppnåtts. Men även om man inte startar en fas innan de tidigare faserna är slutförda är det naturligtvis tillåtet, och i många fall lämpligt att börja förbereda sig för framtida faser. Till exempel, om du vet att du kommer att implementera ett användargränssnitt i implementationsfasen men du vet inte hur man gör detta, då du kan börja förbereda implementationsfasen tidigt i projektet. Du kan börja studera användargränssnitt, fråga folk som vet mer om ämnet eller skapa en mindre prototyp för användargränssnitt bara för att lära sig hur man gör. Man kan naturligtvis, i mån av tid, även chansa och påbörja något som man räknar med eller hoppas kan bli användbart senare i projektet, men du bör då vara medveten om risken att kraven och design kan ändras tidigt i projektet och att det inte är säkert att programkoden du har skrivit verkligen blir användbar. 

5.2.1 Fas 1: Specifikation

Projektets första fas är specifikationsfasen. Arbetet i denna fas utgår från en idé om vad man ska genomföra samt från en rad förutsättningar vad gäller tidsplaner, tidsfrister och budget i förhållande till kostnaden. Den inledande projektidén är beskriven på en hög nivå som inte är tillräckligt tydlig för att i detalj definiera exakt vad som ska utvecklas. Arbetet i denna fas syftar till att precisera exakt vad som ska utvecklas under resten av projektet och skapa en plan för hur det ska gå till.

Konkreta resultat från fas 1 är:

• Projektplan 
• Kravspecifikation

I projektets designfas ligger fokus på att utveckla en högnivådesign för den utvecklade produkten. Utöver detta utvecklas testplan och de testfall som ska genomföras under systemtest

Konkreta resultat från fas 2 är:

• Designdokument
• Testplan 

I den tredje fasen av projektet ligger fokus på att utveckla det exekverbara programmet. Detta innebär att varje utvecklare utvecklar programkod som kompileras och enhetstestas. Enhetstest innebär att man testa delar av programmet isolerat från övriga delar av systemet

Konkreta resultat från fas 3 är:

• Körbar källkod

I den fjärde och sista fasen av projektet ligger fokus på att testa hela systemet. Det innebär att alla enheter av programvaran måste integreras till ett system som kan testas. Vid systemtest verifieras att systemet uppfyller alla krav i kravspecifikationen. Detta görs genom att man kör samtliga testfall i testplanen. Systemtesterna dokumenteras i ett testprotokoll som för varje testfall visar om det lyckas eller inte. Fasen kan inte avslutas förrän alla testfall genomförs utan misslyckanden. Detta innebär att om något test avslöjar fel får man gå tillbaka och ändra i dem utvecklade produkterna (krav, kod, etc) och upprepa samtliga testfall.

Konkreta resultat från fas 4 är:

• Dokumenterat bevis, t.ex. ett testprotokoll, som visar att systemtest för samtliga testfall genomförts utan fel.

En återkommande aktivitet för kvalitetssäkring av dokument och produkter i projektmodellen är dokumentgranskning (statisk test). Grundtanken är att projektmedlemmar eller andra experter individuellt och på ett systematiskt sätt letar problem och brister i dokument i syfte att höja kvaliteten. Dokumentgranskning kan göras för i stort sätt vilken typ av dokument som helst. Figur 5.3 ger en översiktlig bild av en möjlig granskningsprocess. I processmodellen kan man skilja mellan informell och formell granskning. Skillnaden ligger i att den formella granskningen är slutsteget att sätta ett dokument i baseline.

I följande stycke beskrivs processen steg för steg.

1. Planering
   Den som ansvarar för granskningsobjektet förbereder dokumentet och förmedlar det till de som ska granska det tillsammans med instruktioner för i vilken form granskarnas synpunkter ska dokumenteras. Om checklista ska användas bifogas en sådan och instruktion om hur den ska användas.  Förslagsvis dokumenterar man problem i den form man avser dokumentera granskningsprotokollet i steg 3. Det blir lättare att sammanställa då.
   
   Om man är många som granskar kan det vara lämpligt att dela upp arbetet i olika ansvarsområden eller perspektiv. T ex kan någon fokusera på att granskningsobjektet följer olika regler och mallar. Någon annan tittar på att dokumentet stämmer överens med relaterade dokument medan en tredje person fokuserar på språk, en fjärde på sakinnehållet o. s. v. 
   
   Den som ansvarar för granskningsobjektet och granskningen ser också till att granskarna har tillgång till övriga relevanta dokument. Ska man granska en projektplan behöver man ju ha tillgång till uppdragsbeskrivning och en eventuell kravspecifikation. Granskar man en testspecifikation är det viktigt att man har tillgång till rätt version av kravspecifikationen. Den individuella granskningen (steg 2) tar tid. Det är därför viktigt att man har en viss framförhållning vid planeringen.
   
   
2. Individuell granskning
   Granskarna granskar nu granskningsobjektet enligt de instruktioner man har fått och dokumenterar de problem och brister man hittar på överenskommet sätt. Ofta hittar man saker som man inte förstår eller är osäker på. Då kan det vara bra att fråga granskningsobjektets skapare hur han/hon tänkte. Eller också nöjer man sig med att notera tveksamheten för vidare diskussion under granskningsmötet (steg 3).
   
   
3. Granskningsmöte
   Med vid granskningsmötet är granskarna och någon som representerar den eller de som skapat granskningsobjektet, ibland kallad författare. Någon av dessa eller ytterligare en person ansvarar för att dokumentera resultatet av mötet i form av ett granskningsprotokoll. Vad mötet sedan gör är att gå igenom de problem, brister och andra synpunkter som granskarna hittat under den individuella granskningen (steg 2). För varje punkt resonerar man sig fram till om det är något man skall åtgärda eller ej. Om problemet ska åtgärdas noterar man det som ett problem i granskningsprotokollet, eventuellt tillsammans med information om vem som ska åtgärda det (steg 4) och till när. Man beslutar också om att problemen man funnit sammantaget är så omfattande att man behöver granska dokumentet en gång till innan man är nöjd. Därefter distribueras granskningsprotokollet till berörda parter.
4. Omarbete
   När granskningsprotokollet är distribuerat åtgärdar man problemen och rapporterar att så skett.
   
   
5. Uppföljning
   Den som ansvarar för hela granskningen verifierar att problemen åtgärdats och går vidare med dokumentet enligt planen. Till exempel kan ett granskningsprotokoll med tillagda kolumner för åtgärdat och datum vara en enkel men utmärkt beskrivning av skillnaden mellan två versioner av ett dokument (se avsnitt 5.7) 

För varje dokument bör det finnas en person som ansvarar för detta dokument. Detta innebär naturligtvis inte att den ansvariga personen ska göra allt arbete med dokumentet, endast att han eller hon är ansvarig för det dokumentet. Den dokumentansvariga personen samordnar arbetet med dokumentet och ansvarar för att rutinerna för ändringshantering följs. 

Det är viktigt att man arbetar på ett systematiskt och planerat sätt i projektet. Till exempel får man många gånger problem om två personer ändrar i samma dokument samtidigt. Den person som ansvarar för dokument ser till att förändringar i ett dokument inte blir motstridiga. 

Det blir också ett problem om någon ändrar i ett dokument utan att meddela andra personer i projektet. Till exempel, om en person förändrar kravspecifikationen utan att berätta för de personer som kommer att implementerar koden, kommer överensstämmelsen mellan kod och krav att försvinna.

Ett sätt att lösa denna typ av problem är att ha en formell ändringshantering i projektet. Denna projektmodell har förhållandevis enkla ändringsrutiner och de gäller först efter att dokumenten satts i baseline, d v s efter att dess milstolpe uppnåtts och de därmed har ett versionsnummer på version 1.0 eller högre. Efter det medför varje förändring av dokumentet att:

• den nya versionens versionsnummer ökas. 1.0 --> 1.1-->1.2 etc
• i, eller i anslutning till, den nya versionen finns en beskrivning av skillnaden mellan de båda versionerna
• den föregående versionen ändras inte fler gånger
 

Rutinerna för ändringshanteringen kan beskrivas enligt följande exempel:

1. Person A upptäcker ett problem i designdokumentet 
2. Person A lokaliserar felet i designdokumentet (som för närvarande är i version 1.0) 
3. Person A meddelar den person som ansvarar för utformning designdokumentet (person B) och ber om tillåtelse att ändra dokumentet
4. Person B ger person A tillåtelse att ändra utformningen av dokumentet
5. Person A uppdaterar designdokumentet, uppdaterar versionsnumret till 1.1 och förmedlar dokumentet och en beskrivning av vilka förändringar som skett till person B. 
6. Person B har nu ansvaret för att meddela alla personer som arbetar med designdokument eller beroende av det, att det finns en ny version som de ska använda i stället för den gamla versionen. 

När ett dokument ändras är det viktigt att tänka på att andra dokument som är beroende av dokumentet också kan behöva ändras. Om till exempel en kravspecifikation ändras sent i ett projekt kan det mycket väl vara nödvändigt att ändra i såväl testspecifikationer och designdokument som i programkod och manualer. 

Vill man ändra i kraven behöver man också i många fall ha en dialog med beställaren eftersom kraven ofta är en del av ett kontrakt. I kursen gäller att ändringar i kravspecifikationen efter att den satts i baseline måste godkännas av den tänkta kundens representant, d v s projekthandledaren. För det ändamålet ska en särskild blankett användas, se avsnitt 6.5. För övriga dokument i projektet måste man inte använda blanketten. Däremot är det viktigt att man dokumenterar skillnader mellan olika versioner och har en idé om varför man uppdaterar till en ny version.