Vanlige misforståelser om IT: Husbyggingsanalogien

Skal du å lykkes med noe, så må du enten ha flaks, forstå hva du driver med (eller kunne delegere til noen som du kan stole på, og som forstår det). Siden det er vanskelig å påvirke flaks, så har jeg mest tro på å lære og å forstå det man gjør. Gitt alle de mislykkede prosjektene i IT-bransjen kan vi kanskje beskyldes for å ikke ha noen av delene? Det synes jeg vi bør gjøre noe med, og under vil jeg ta opp en misforståelse som jeg mistenker å ha i alle fall delvis skyld for mange katastrofeprosjekter.

Den gamle: Husbyggingsanalogien

Da jeg begynte å lære om IT ble systemutvikling sammenlignet med husbygging for å illustrere likhetene. Ved å sammenligne fasene i husbygging med fasene i utviklingsprosjekter kunne man raskt få en idé om hvordan prosjektene går. Sammenligningen var omtrent som vist i tabellen under:

Husbygging	Programvare/systemutvikling
Spesifikasjon	Spesifikasjon / kravspesifikasjon
Arkitektur	Arkitektur
Design	Design / detaljert design
Konstruksjon	Implementasjon/programmering
Godkjenning	Test/godkjenning

 

Flere av fasene i programvareutvikling synes å ha fått navnene sine fra nettopp denne sammenligningen. Denne modellen er lettforståelig og virker intuitivt riktig. Dessverre er den riv ruskende gal.

La oss se litt nærmere på hvorfor den er mer misvisende enn forklarende:

Programvareutvikling er nesten utelukkende spesifikasjonsarbeid

Spesifikasjon er arbeid som består i å beskrive hvordan noe skal gjøres/bygges/fungere el. Aktiviteten spesifikasjon/kravspesifikasjon består i å beskrive hvilke forventninger man har til systemet. Disse er ofte beskrevet som hva systemet skal gjøre (funksjonelle krav), og andre egenskaper til systemet, som feks ytelse (ikke-funksjonelle krav). Arkitektur-aktiviteten består i å beskrive «byggeklossene» i systemet og andre høynivå føringer for systemet. Design-aktiviteten består i å lage en mer detaljert teknisk beskrivelse av systemet. Programmerings-aktiviteten består i å lage en så detaljert beskrivelse av systemet at datamaskinen, evt. ved hjelp av annen programvare, kan utføre spesifikasjonen. Altså: Alle disse aktivitetene er spesifikasjon, på forskjellig detaljnivå.

Konstruksjon av programvare er automatisert

Når et hus er ferdig spesifisert/designet og klar til bygging, så brukes dette som utgangspunkt for håndverkerne på byggeplassen. Deres oppgave er å omgjøre planen og spesifikasjonen til en fungerende bygning. Hvis man i slutten av byggeprosessen finner ut at man for eksempel burde ha hatt en ekstra etasje, eller at huset burde vært snudd 90 grader, så er det for sent. Dette betyr at i byggeprosjekter, så er det essensielt at man har gjort en meget god planleggings-/spesifikasjonsjobb, for feil her blir ekstremt kostbart.

Når programvare er ferdig spesifisert på programkodenivå, så går som regel resten automatisk. Byggescript, kompilatorer og andre verktøy gjør automatisk om spesifikasjonen til et faktisk fungerende system. Dette er noe av det som er helt unikt med programvare. Hvis man finner ut at resultatet ikke ble helt slik man håper etter å ha bygd det, så kan man endre det. På engelsk heter det «software», som reflekterer nettopp denne spesielle egenskapen med programvare. Dette betyr også at det er mindre kritisk å ha laget en komplett og korrekt spesifikasjon før man bygger. Det er tilnærmet gratis å bygge programvaren, så derfor har man en gyllen mulighet til å bygge mange ganger, og å teste ut at antagelsene man gjør tidlig i prosessen faktisk stemmer.

Den nye: Husprosjekteringsanalogien

En bedre sammenligning av husbygging og programvareutvikling blir derfor:

Husbygging	Programvare/systemutvikling	Type arbeid
Prosjektering: – Spesifikasjon – Arkitektur – Design	Spesifikasjon / kravspesifikasjon Arkitektur Design / detaljert design Implementasjon/programmering	Kunnskapsarbeid. Man skaper noe som ikke tidligere har blitt laget. Fokus: Læring
Konstruksjon/bygging	Kompilering/bygging	Produksjonsarbeid. Man gjenskaper det som er spesifisert Fokus: Effektivitet og konformitet til spesifikasjon
Godkjenning	Test/godkjenning	Verifikasjonsarbeid.

 

En måte å tenke på dette på er at kunnskapsarbeidet er en kreativ fase der man på forskjellige nivåer stadig forbedrer det som blir skapt. Det betyr at arbeidet som foregår nødvendigvis blir en vekselvirkning mellom aktivitetene – derfor er de slått sammen til 1 rad i tabellen over. Eksempel: I et husbyggingsprosjekt har kanskje bestilleren av prosjektet noen innledende føringer og ønsker. Arkitekten forsøker å fange dette i sin arkitektur, og ingeniøren spesifiserer tekniske detaljer og sjekker at arkitekturen er fysisk gjennomførbar. Ofte vil man finne at for eksempel arkitektens forslag ikke kan gjennomføres uten visse endringer, som igjen kan ha betydning for bestillerens ønsker. Gjennom flere iterasjoner nærmer man seg stadig en bedre løsning.

Du kjenner sikkert til at det finnes «husmodeller» som man kan benytte hvis man skal bygge et nytt hus. Noen har da gjort (mesteparten av) prosjekteringsjobben for deg, og det gjenstår i hovedsak bare å bygge huset. Siden flere benytter seg av samme husmodellen, så vil man typisk ha ett prosjekt for å lage husmodellen, og ett prosjekt per bygging av et hus basert på modellen.

Enda en ny: Bilmodelldesignanalogien

Tilsvarende analogi kan vi gjøre med bilbransjen. Når feks Toyota skal lage en ny bilmodell, så har de et omfattende prosjekt for å utvikle bilmodellen. De spesifiserer ønsker om hva som skal være spesielt med modellen, feks lavere drivstoff-forbruk og et formspråk som appellerer til unge bilkjøpere. Videre forsøker ingeniører og designere å imøteomme ønskene gjennom å feks designe et nytt hybriddrivverk og å lage et moderne utseende som samtidig reduserer luftmotstanden. Stegene frem til nå tilsvarer aktivitetene til og med programmering i systemutvikling.

Når man i bilbransjen har kommet så langt at de finner ut at en modell skal settes i produksjon, designer de deretter produksjonsprosessen med tilhørende verktøy og produksjonslinjer, og setter i gang produksjonen. I systemutvikling tilsvarer dette aktiviteten med å sette opp byggescript/kompilering av systemet, og å bruke denne prosessen til gjentatt bygging av systemet.

Lær grunnleggende prinsipper for å gjennomføre bedre prosjekter

Mitt hovedpoeng i denne artikkelen er: Å lage programvare har mye tilfelles med å designe en ny husmodell, eller å designe en ny bilmodell. Hvis du prøver å lage programvare med metoder som er tilpasset husbygging, så har du høyst sannsynlig noen ubehagelige overraskelser som venter på deg.

Husk også at analogier har sine begrensninger. En analogi vil aldri ha overføringsverdi på alle punkter for det som sammenlignes (ellers ville det jo være det samme). En analogis hovedverdi er derfor at den på en intuitiv måte kan hjelpe deg å lære eller forklare hvordan visse ting om fungerer. Som vi har vært litt inne på tidligere har programvare noen unike egenskaper som analogiene ikke dekker, og som andre bransjer misunner oss hvis vi bruker dem riktig. Mer om dette i kommende artikler.