I det här avsnittet kommer jag att ta upp olika utvecklingsprocesser. Det kan vara värt att påminna sig om att de olika processerna finns där för att hjälpa oss att utveckla program: värdet av en process ligger i den nytta vi har av den.
Är inte det självklart? Kanske, men de metoder man använder i utveckling får ofta ett eget liv och blir lite av självändamål. Det är ofta en bra idé att reflektera över om metoderna verkligen ger oss en bra utdelning av det arbete vi lägger ner för att genomföra dem.
De önskemål man kan lägga på en utvecklingsprocess är i allmänhet ganska enkla och grundläggande. Några exempel:
(Om du har erfarenhet av lite större projekt vet du säkert att de här kraven inte alltid är så lätta att uppfylla.)
Man kan tänka sig andra önskemål, men det gör inte så stor skillnad för vår diskussion. Det intressanta är:
I hur hög grad hjälper utvecklingsmodellen oss att uppfylla de önskemål vi har på utvecklingsprocessen?
När vi diskuterar värdet av olika utvecklingsmodeller är det förstås här vi måste börja.
Utvecklingen av ett större system kan delas upp i arbetsmoment, till exempel:
Notera att de olika stegen ej nödvändigtvis behöver göras i sekvens.
Numera verkar vattenfallsmodellen inte längre vara aktuell. När jag sökte på nätet kunde jag inte hitta någon som försvarade modellen. Men i beskrivningar av hur man genomför ett projekt ser man ofta liknande idér. Vattenfallsmodellen förutsätter att man kan göra en perfekt analys av problemställningen och från analysen ta fram en (lika) perfekt design. Om du försöker genomföra ditt projekt med dessa antaganden är det vattenfallsmodellen du följer, även om du använder andra ord för att beskriva din utvecklingsmodell.
Vattenfallsmodellen förutsätter att analys, design och implementation utförs (i stort) i sekvens.
De flesta som får lära sig om vattenfallsmodellen upplever att den känns intuitiv och naturlig. Mycket enkelt kan den beskrivas så här:
Först tar man reda på vad som ska göras, sen planerar man sin lösning, sen implementerar man den.
I senare avsnitt kommer jag att diskutera olika problem med vattenfallsmodellen och ta upp Extreme Programming (XP) och Iterative Design (ID) som alternativ.
Utgångspunkten för analysfasen är den information man kan få fram om det önskade systemet, till exempel
I tekniska sammanhang är det ofta ganska uppenbart hur en bra lösning ska se ut. Men i många situationer ligger svårigheten i att förstå vad som ska implementeras. Vad vill kunden egentligen ha? Hur ska systemet fungera ihop med andra system? Hur ska systemet utformas för att vara användarvänligt?
Hur hanterar vi informationen från analysfasen? En lösning kan vara att helt enkelt sammanfatta den i en rapport. Man kan också tänka sig att beskriva önskemålen på ett mera formellt sätt. Ett tredje alternativ är att skapa en modell av det önskade systemet. Det finns invändningar mot det tredje alternativet, det är till exempel lätt hänt att bekrivningen av hur det önskade systemet ska fungera istället blir en beskrivning av hur man tänker sig att systemet ska implementeras.
Nackdelen med att göra implementationsval i ett tidigt skede är att man då låser sig för olika lösningar trots att man inte har hunnit sätta sig in i projektets tekniska aspekter.
Om man väljer att ta fram en modell kan den uttryckas i UML med till exempel användningsfall, klassdiagram och interaktionsdiagram.
En enkel metodik (som kan vara lämplig för mindre projekt) är
Objekt kan vara substantiv i kravspecen. Man kan också titta på fysiska ting, roller hos olika aktörer (student, lärare, kund, kassörska), platser eller händelser.
För varje klass måste vi
När vi har klasserna är nästa steg att undersöka hur de relateras via arv, relationer eller på annat sätt.
En varning: Om man följer ovanstående strategi händer det lätt att det kommer in klasser i kravspecen som inte behövs i den färdiga lösningen.
Om systemet är lite större vill man antagligen bryta ner det i delsystem, men även när man delar upp ett system i delsystem är det en risk att designbeslut smyger sig in i specifikationen.
Den här fasen handlar till stor del om aspekter av systemdesign som inte är så intressant för den här kursen, till exempel val av hårdvara, anpassning till befintliga system, databaser och nätverk. Här tittar man även på utformning av användargränssnitt.
Klassdiagrammen från analysfasen utvecklas vidare för att fungera i det programspråk som valts för implementationen. Här måste man ta hänsyn till begränsningar i språket och tillgång till standardbibliotek etc.
När designen utförts återstår det i bästa fall bara att koda systemet.
Vattenfallsmodellen kan kännas intuitiv och naturlig. Men det är lätt att se att många av de problem som kan uppstå i ett projekt inte hanteras så väl i vattenfallsmodellen. Till exempel:
Hur fångar man upp problem som dessa under projektets gång? I praktiken händer det alldeles för ofta att problem upptäcks för sent. Ibland kan det till och med vara svårt att i efterhand avgöra var problemet uppstod: var analysen felaktig eller ofullständig, gjordes misstag i designen eller låg bristerna i implementationsarbetet?
Jag kommer att fortsätta diskussionen om vattenfallsmetoden i avsnittet "Kritik av vattenfallsmodellen".
Vattenfallsmetoden kan sammanfattas mycket enkelt:
Först tar man reda på vad som ska göras, sen planerar man sin lösning, sen implementerar man den.
Problemet är att vattenfallsmodellen inte hjälper oss att undvika de risker som alltid följer med stora projekt.
Idag talar man inte så mycket om vattenfallsmodellen, men idéerna lever kvar under andra namn.