Introduktion till avsnittet om objektorienterad mjukvaruutveckling

Kommentarer om materialet

Föreläsningsanteckningarna i detta avsitt är en omarbetad version av en "manual" för ett projekt jag handleder, nämligen en av årets projektgrupper i årskurs tre. Det innebär att det arbete som beskrivs är alldeles för omfattande för den här kursen (programvaruprojektet). Likväl har jag använt dem i närapå ursprungligt skick därför att de utgör en bra introduktion till både en process för mjukvaruutveckling och till objektorienterad analys och design. I vad mån innehållet tillämpas i projektarbetet är helt upp till varje projektgrupp.

Trots att det inte ställs några krav på projektet vad gäller detta avsnitt råder jag er ändå att fundera kring det. Dels finns det förutsättning att projektresultatet blir bättre, dels är det mycket nyttig kunskap inför framtiden, tex inför projektet i årskurs tre. Speciellt viktigt tror jag det är att ta fram någon form av kravspec (det arbete som beskrivs främst under avsnittet inception) samt att fundera lite kring design, kodning och testning (och eventuellt analys) enligt avsnittet elaboration.

Hälften av tentan kommer att handla om detta avsnitt.

Den beskrivna processen

Alla aktuella processer för mjukvaruutveckling bygger på dystra erfarenheter av havererade projekt. Alla delar de följande drag:

Det är nödvändigt att iterera. I varje iteration utvecklas någon funktionalitet färdigt och resultat från tidigare iterationer kan vidareutvecklas eller förändras.
Tackla risker tidigt. Utveckla först kod som verkar svår.
Var beredd på förändringar under projektets gång. Det är ingen bra idé att tvinga kunden skriva på en kravspec, låsa in den i ett kassaskåp och i triumf hala fram den när vi anser att projektet är klart. Livet blir lättare och kunden mer nöjd om vi istället kan hantera förändrade krav. Samarbeta nära med kunden. Dema ofta. Fråga när något är oklart.
Testa ofta! Skriv ett gärna test för varje klass och ett för varje paket och kör dem varje gång du gör en förändring.
Se kravanalys och design som en stunds eftertanke för att komma mer rätt från början. Det är nödvändigt att göra dem men vi kommer att hitta fel i dem när vi börjar koda.
Om det blir svårt att hinna med är det funktionalitet som får stryka på foten, inte leveransdatum, kvalité eller utvecklarnas hälsa.

Den process som beskrivs här är huvudsakligen ett subset av RUP (Rational Unified Process) men har även lånat drag av XP (Extreme Programming). Detta torde vara de trendigaste processerna för närvarande.