Jag kritiserade nyligen Ivar Jacobsson för att ha kokat en tunn soppa i sin krönika om misslyckade arkitekturer. Så lätt slapp jag förstås inte undan och har från flera håll avkrävts en mustigare brygd.
Så vad förklarar alla havererade projekt man ofta kan läsa om i CS? Det enkla svaret är att systemutveckling är svårt. Det längre svaret är att ett antal framgångsfaktorer måste finnas på plats, oavsett vilken metod man råkar ha valt. Saknas någon av dessa infinner sig olika problem som var för sig kan sänka projektet. Låt mig räkna upp några stycken.
Versionshantering av alla dokument - ordning och reda. Utan versionshantering har man ingen aning om vad som levererats och kan inte spåra samband mellan krav och systemets komponenter.
Kravhantering. Utan ordning på kraven kan man inte testa systemet eller validera att det tillgodoser faktiska behov i verksamheten. Med kravhantering avses också att man har en process att hantera kravändringar.
Iterationer. Med fungerande iterationer minskar man riskerna i projektet. Det ger korta mål som är hanterbara för alla projektmedlemmar och förändrade krav kan tas om hand. Utan fungerande iterationer levererar man vanligen fel system för sent, till för hög kostnad.
Kvalitetssäkring handlar om att testa kontinuerligt. Desto tidigare man identifierar brister desto mindre kostar det att åtgärda. Utan kvalitetssäkring levererar man slumpmässigt vad som helst till skitsura användare.
Komponentbaserad arkitektur är ett måste för att kunna hantera större system med samverkande delar. Då kan delarna utvecklas oberoende av varandra och testas separat. Saknas detta når systemet snart sin kritiska massa, dvs inget kan ändras utan att något annat spårar ur.
Visuell modellering av system är lika viktigt som att göra ritningar då man bygger hus. Om hus byggdes som vissa system skulle jag välja att tälta.
Kompetens. Har projektmedlemmarna fel kompetens spelar det ingen roll vilken metod man använder.
Enkelhet är kanske även det en självklarhet men det ligger ofta mer arbete bakom en enkel lösning än bakom en komplicerad. Det är lättare att följa och förstå en enkel lösning än en komplex. Det blir lättare att lära upp nya resurser etc.
Hårt arbete med fokus på produkten. Alla dokument och aktiviteter måste tillföra mer nytta för produkten än de kostar. Annars drunknar projektet i dokumentationsträsket.
Utan spaning ingen aning. Just det, man måste dessutom mäta framgångsfaktorerna. Hur det går till ryms förstås inte i denna krönika, men kan läsas här.
Läs krönikan hos Computer Sweden
Skriv ut