Fra suksess til spott og spe

"Hva i h... kommer det av at denne lille endringen tar så lang tid og koster så mye penger?" pleier frustrerte bedriftsledere spørre sin it-avdeling eller it-leverandør.

"Dette kan ikke være sant."

Ja, hva kommer det av? Ingen stilte krav om at applikasjonene skal være lett å endre.

Kravspesifikasjonen inneholdt ikke noe håndgripelig om det.

Det prosjektgruppen fikk beskjed om var å levere et sett applikasjoner som skulle oppfylle flere hundre konkrete, funksjonelle krav innen gitte tidsrammer, kostnadsrammer og med en viss kvalitet.

Kvalitet betyr her at applikasjonen er fri for alvorlige feil og lar seg kjøre som forutsatt. Suksess for prosjektet betyr at disse tre krav er oppfylt.

Da kan korkene fly i været.

Men kan man forvente at ledere av forretningsvirksomheter skal spesifisere slike tekniske krav som vedlikeholdbarhet eller integrerbarhet? Er ikke det opp til utviklerne ("håndverkerne") å definere slike ikke-funksjonelle krav?

Gjøre lederne oppmerksom på at jo lengre de har tenkt at applikasjonene skal leve desto viktigere er det at de lett lar seg tilpasse endringer i omgivelsene? Tenker ledere i det hele tatt i disse baner, at en applikasjon kan leve i 10-20 år?

Hvor trøtt i trynet blir den da? En velstelt applikasjon er 10 prosent engangsinvestering og 90 prosent følgekostnader.

En av Gartners mest kjente analytikere, Andy Kyte, har formulert motsetningsforholdet omkring utilstrekkelig definisjon av krav på en treffende måte: "Alle våre utviklingsprosjekter er vellykkede, og alle våre applikasjoner er upopulære."

Svaret er at beslutningsgrunnlaget, the business case, skal inneholde mer enn funksjonelle krav, det vil si hva applikasjonene skal gjøre. At de ikke-funksjonelle krav (det vil si hvor godt de skal gjøre det) også blir konkretisert, og at det blir tydelig fortalt hvordan de skal designes og testes.

Det er opplagt at dette bør gjøres, men det er like opplagt at prosjektet da må få mer å rutte med. Og fordi leverandører ofte konkurrerer om prosjekter på pris, er det lett å hoppe bukk over langsiktige betraktninger. Levere det folk har bruk for, så billig og så raskt som mulig, det blir omkvedet. Vedlikehold er det noen andre som skal bekymre seg for. Imorra er en skjelm.

Gartner anbefaler å ta utgangspunkt i ISO-dokument 9126 som heter Software Engineering/Product Quality. Dokumentet definerer seks grupper av egenskaper for program-kvalitet: Funksjonalitet, pålitelighet, brukervennlighet, effektivitet, vedlikeholdbarhet og portabilitet. I flere omganger blir hver gruppe brutt ned i mindre elementer. Ikke alle prosjekter har bruk for alle seks, men det er greit å starte med helheten, det vil si avklare bevisst hvilke av dem som skal være i fokus. Av de seks er vedlikeholdbarhet den egenskapen som aller minst pleier å tas hensyn til.

Enda det er et velkjent faktum at livstidskostnadene som påløper etter at en applikasjon er satt i drift er flere ganger større enn det som medgår frem til den første igangsettingen. Versjon følger versjon. Dessuten er det slik at applikasjoner som er lett å holde oppdatert og tilpasset skiftende krav, vil vare lengre.

Utviklingsprosjekter kan altså feires som vellykkede i første omgang, for så å bli dømt nord og ned senere. Det er utmerket å levere på avtalt tid, kost og kvalitet, men det er ikke nok. Her er noen andre krav som skal oppfylles for langsiktig suksess:

• Tenk livstidskostnader når prosjekter skal vurderes.
• Plassér ansvar for hvem som skal definere ikke-funksjonelle krav.
• Allokér en del av prosjektbudsjettet til dem som skal definere ikke-funksjonelle krav.
• Presentér prosjektet slik at de ikke-funksjonelle krav får samme viktighet som de funksjonelle.
• Validér, før utviklingen starter, at det foreslåtte designet faktisk vil oppfylle de ikke-funksjonelle krav.
• Sørg for at prosjektets QA-plan vier nok oppmerksomhet til å verifisere de ikke-funksjonelle krav.
• Og sist, men ikke minst: Forlang at prosjektgruppen ikke fraskriver seg deler av ansvaret (for eksempel til arkitektene) men selv bærer flagget for alle krav.

Et sett av applikasjoner kan bare bli bedømt ut fra hvor godt de understøtter forretningsprosessene på lang sikt.

Ellers blir de en klamp om foten som brukerne prater stygt om og gjør alt for å bli kvitt.