Ojda, jeg glemte visst noe!

På to punkter innen systemutvikling bør vi bli langt bedre: Når vi spesifiserer bestillingen og når vi skal forsikre oss om at vi har fått det vi har bestilt. Det er komplette og testbare krav som driver programkvaliteten opp.
70% av alle feil i programmer sniker seg inn, ikke fordi utviklerne gjør en dårlig jobb, men på grunn av upresise eller manglende krav.

Omtrent 60% av dem blir ikke avslørt før godkjenningsprøven, anslår National Institute of Standards and Technology i USA. Da blir det dyrt! Det er nemlig slik at hvis en feil eller mangel blir oppdaget mens kravene blir spesifisert, koster det 150 dollar å rette den. Den samme feilen koster det dobbelte hvis den blir oppdaget og rettet mens konstruksjon pågår, og fem ganger så mye hvis prosjektet allerede er kommet i utviklingsfasen. Hvis feilen ikke blir rettet før godkjenningsprøve, blir kostnaden 7 000 dollar og hvis det skjer etter produksjonssetting, blir kostnaden doblet igjen, sier forskerne Boehm og Basili i en klassisk studie. (Tallene er ment for illustrasjon.)
Årsaken er åpenbar: Mye arbeid må gjøres om. Jo senere feilen eller mangelen blir oppdaget desto mer må gjøres om. Dessuten – hvis krav blir feilaktig stilt eller mangler, skaper dette endeløse diskusjoner mellom dem som har bestilt og dem som skal levere: Hvem er det som ikke har gjort jobben sin her?

Feilaktige krav kan grupperes i to – de som ikke er der eller ikke skulle vært der, og de som er feiltolket eller ikke er komplette. I fagspråket kalles den første ”error of omission”, det vil si at krav blir oversett, og den andre ”error of commission”, det vil si dårlig kommunikasjon om hva bestilleren egentlig ville ha.

Hva kan vi lære av dette, da dere? Vi vet at leveransen blir mye bedre hvis vi tidlig viser frem hva bestilleren skal få. Prototyping var populært for 10-15 år siden, nå er det gått litt i glemmeboken. En av årsakene er at prototypen ikke kan bygges videre til å bli sluttproduktet, det er bare en skisse underveis. Derfor kan den oppfattes som bortkastet arbeid – men det er feil. En prototyp er et framifrå kommunikasjonsmiddel, mye bedre enn Powerpoint. I dag finnes det verktøy som gjør det lett å lage prototyper. Det har også kommet hjelpemidler for å koble prototyper og tekster sammen, f.eks. RAVEN og iRise Studio.

Iterativ utvikling er en populær metode for å gjøre kravbildet mer komplett. Lage litt, vise det frem, høre hva bestilleren har å si før neste trinn. Alle prosjekter har mye å lære av hvordan smidige metoder som Scrum håndterer krav. Intens, daglig dialog mellom bestiller og leverandør er sunt. Smidig dreier seg om å levere sluttproduktet i deler, så hyppig som det er praktisk mulig. Hvis brukerne kan studere en del i praksis, kan de raskere komme på sporet av misforståelser. Det kan godt hende at brukerne endrer oppfatning 180 grader mens de studerer en delleveranse, men den sjansen må vi ta. Jo før, jo heller. Det hender dessuten ofte at krav som opprinnelig ble bedømt som må-ha, forsvinner ut av soga. Hyppige leveranser bøter ikke på alle svakheter i kravprosessen, men det er velegnet til å avsløre at krav mangler eller er unødvendige.

Men smidige metoder har også lært oss andre ting. Den ene er at mengden av krav både stiger og faller underveis. En annen erfaring er at den innledende brede planlegningsfasen har noe for seg. Det ligger en fare i å skrive programmer for tidlig. Det kan bety at fundamentet ikke er der. Det kan føre til fragmentering fordi flere team jobber parallelt, litt hist og litt pist. Sporbarheten av datagrunnlaget kan forsvinne. På en eller annen måte må prosjektet sørge for at helhetsblikket ikke dunster bort. Utvikling er viktig, javisst, men det etterfølgende vedlikehold og videreutvikling over ti eller tyve år, mens systemet er i bruk, er enda viktigere. Formalisert håndtering av krav i hele systemets livsløp bør understøttes med digitale verktøy, også når den smidige modellen er valgt. En komplett systemtest for å prøve helheten hører også med.

Beste praksis tilsier at bestilleren må forsikre seg om at hvert krav som er stilt, faktisk er oppfylt. Hvis bestilleren ikke kan fortelle hvordan det skal prøves om et krav er oppfylt, er det fare på ferde. Et annet poeng som jeg kommenterte i min siste spalte (”Tapt og funnet”, 3. april) er om det er ledelsens eller brukernes krav det er snakk om. Her kan det ligge interessekonflikter. Hvis ledelsens krav skal ligge til grunn, mens det er brukerne som forklarer dem i møter, kan leverandøren bli forvirret. Eller enda verre – levere et system som ingen vil ha.

Hvis bestilleren ikke kan fortelle hvordan det skal prøves om et krav er oppfylt, er det fare på ferde.