Bedre programvareprosess gir bedre programvarekvalitet

                    Kronikk

Kansellerte, forsinkete, feilbefengte eller stivbente dataprogrammer er ikke uvanlige. Ja, få programvareprosjekter utføres i henhold til avtalt prosjektplan, og mange datasystemer fungerer ikke skikkelig etter leveranse.

Vi kan nevne Rikstrygdeverkets påtenkte TRESS-system eller manntallssystemet ved Stortingsvalget i Oslo i 1993.

Det er derfor av nasjonal viktighet at norsk programvarebransje har tilstrekkelig kompetanse for å levere feilfri og nyttig programvare til rett tid og pris. Én prosent prosessforbedring betyr 150 millioner kroner spart for utviklerne, og kanskje enda mer for brukerne av tjenestene.

Forbedring av programvareprosessen (the "software process") er derfor et aktuelt tema. Prosessen dekker både utvikling og vedlikehold av programvare, til sammen kalt programvare-produksjonsprosess. Prosessen kan være oppdelt etter vannfallsmodellen og/eller følge mer detaljerte metoder (Cleanroom, objektorientert systemutvikling), og er ofte organisert som et PROSJEKT. Prosessen bør beskrives i en formell prosessmodell etter en standard mal, ofte som en finkornet prosjektplan i form av aktivitetsnettverk.

Det fins flere kommersielle prosesstøtte- og arbeidsflyt-verktøy (Process Weaver, Process Engineer, Action Workflow System) som tolker slike prosessmodeller og bistår aktørene med delvis automatisk gjennomføring av den beskrevne prosessen. Et aktuelt forskningsfelt er hvor stor del av prosessen som lar seg formelt beskrive, og hvordan avvik og endringer underveis skal håndteres.

Standarder for prosess og kvalitet

Tilhørende kvalitetsstandarder baserer seg ofte på sjekklister. Vi kan nevne sertifisering etter ISO 9000-3 og TickIT-utvidelsen av denne. Videre fins prosessevaluering (process assessment) i henhold til Capability Maturity Model (CMM) fra SEI i Pittsburgh eller den europeisk-utviklede BOOTSTRAP-modellen, begge med fem modenhetsnivåer.

Det pågående arbeidet i ISOs nye SPICE-standard (Software Process Improvement and Capability Etermination) vil inkorporere aspekter av de to sistnevnte. Over 30 norske programvare- og IT-bedrifter er ISO-sertifiserte, mens ingen har hittil vært formelt evaluert etter CMM. Den virkelige utfordringen er ikke å passere en formell sertifisering eller evaluering, men å få til en gradvis, vedvarende og målbar prosessforbedring i egen organisasjon. Her må man ta utgangspunkt i organisasjonens konkrete profil og behov, og planlegge forbedringstiltakene for programprosessen deretter. Dvs. vi må rette tiltakene mot der "skoen trykker mest" - er det for eksempel tid, ressurser eller feilrate som er mest kritisk?

Uansett bør vi utvise nøkternhet: Å bli ti ganger bedre på fem år er utopisk; det fins ingen vidundermedisin ("silver bullet").

Forbedringstiltakene kan være bedre oppfølging av vanlige prosjekt/kvalitetsmål (forbrukt tid, antall feil, o.l) eller introduksjon av mer spesiell teknologi (eksempelvis tekniske gjennomganger eller objektorientering). Underveis måler vi hvordan prosessen generelt forløper og spesielt hvordan de nye tiltakene virker, og justerer prosessen i henhold til oppsatte mål, og drar lærdom for framtidige prosjekter.

Prosessforbedring i NASA

NASA-SEL har loggført nesten 150 programvareprosjekter siden starten, og har observert effekten av alternative forbedringsteknologier, så som Ada, objektorientering, Cleanroom, osv. Siden 1976 har feilraten gått ned med over 80 prosent, og produktiviteten har økt med med over 50 prosent. De to mest suksessfulle forbedringsteknologiene har vært gjenbruk av funksjonsmoduler og tekniske gjennomganger.

Prosjektene kjøres etter en relativt stabil mal for å være sammenliknbare, og resultatene lagres i en felles ERFARINGSDATABASE som muliggjør både kortsiktig prosjektoppfølging og langsiktig læring. De reviderte prosjektmalene lagres som interne standarder i den samme erfaringsdatabasen, sammen med metrikk-definisjoner, sjekklister, gjenbrukbare produktbeskrivelser o.l. NASA-SEL har etablert prosesstøtte-grupper med prosessingeniører ("process engineers"), som assisterer prosjektledere og utviklere. Slike grupper er kun "the helpers, not the doers". Kostnaden ved slik prosessforbedring er anslått til 11 prosent av totalen, men da er eksisterende prosjekt/kvalitetsoppfølging medregnet. Men det lønner seg klart, hvis vi avregner investering mot gevinst. For alt dette har Victor Basili formulert et "Quality Improvement Paradigm, QIP", med følgende forbedringsprosess eller "meta-prosess": 1) etabler et referansepunkt eller "baseline" for typiske prosjekter - deres profil, størrelse, feilrate, produktivitet, teknologier osv., 2) forstå og vurder dette referansepunktet, 3) formuler kvantiserbare forbedringsmål, 4) velg relevante metrikker, 5) utfør prosessen med foreskrevne målinger og justering underveis, 6) vurder sluttresultat, og 7) pakk inn erfaringene for framtidig bruk.

For å få reproduserbare og sammenliknbare "eksperimentelle" resultater, stiller QIP sterke metodiske krav til statistisk analyse og til bruk av få uavhengige variable (dvs. forbedringstiltak). QIP likner på Shewhart/Demings Plan-Do-Check-Act prosess for industriell kvalitetskontroll, men er utvidet for organisasjonsmessig læring etter ISO-9000 oppskrift.

Konkrete erfaringer utenom NASA

Hva med Norge? Kan suksessen overføres til en vanlig norsk programvarebedrift? Eller er det bare store organisasjoner som NASA og ATT som kan påta seg ambisiøse forbedringsinitiativ? Ytre konkurranse diktererer at vi må få demonstrerbar effekt innen rammen av ett prosjekt, og hvertfall innen to år, eller helst i går! Erfaring viser at slik gevinst er fullt mulig, gitt skikkelig referansepunkt-analyse, og senere planlegging og oppfølging av forbedringstiltak. Problemet er at det sjelden fins et representativt referansepunkt å måle en prosessforbedring mot, siden datainnsamlingen har vært og fortsatt er mangelfull.

Et norsk eksempel: Tandberg Data Storage har redusert feilraten vesentlig (50 ganger?) på sine tape-streamere, bl.a. ved bruk av tekniske gjennomganger av programvare. Sammen med andre kvalitetsforbedrende tiltak medførte dette at Tandberg Data Storage ble tildelt IBMs "Custom Storage Solutions Quality Award" for 1992.

Hvordan komme i gang lokalt?

Tidlig og vedvarende støtte fra toppledelsen er derfor et absolutt krav. Denne støtten kan være vanskelig å oppnå, siden all endring er forbundet med kostnader og risiki, men fins det egentlig noe alternativ? På grasrotnivå kan det være nyttig å la noen lokale ildsjeler utprøve mulige forbedringer i egne prosjekter, og senere satse på smitteeffekt i resten av organisasjonen.

Men framfor alt: vi må kontinuerlig måle på prosess og produkt, lagre måledata i en erfaringsdatabase, og la alt dette drive prosessen. En slik erfaringsdatabase er også nyttig for generell synliggjøring av virksomhet og for strategisk planlegging. Mesteparten av forbedringstiltakene kan, som nevnt, ses på som en oppfølging av ISO-9000. Det viktigste er å endre firmakulturen, slik at uselvisk og MÅLINGSBASERT PROSESSFORBEDRING blir "our way of doing the business".

Bygg kontaktnettverk rundt et metodesenter!

Disse fagmiljøene planlegger et felles metodesenter, med "ringer i vannet" av organisasjoner på forskjellig modenhets- og ambisjonsnivå, og med felles nyhetsbrev, seminarer, erfaringsfora osv. For eksempel er det nylig gjennomført en spørreundersøkelse blant medlemmene i Den Norske Dataforening om prosessforståelse og -status.

Men det viktigste er å komme i gang med konkrete forbedringstiltak i den enkelte utviklingsorganisasjon. Disse tiltakene kan inngå som en del av nasjonale og internasjonale FoU-prosjekter. Fagmiljøene ovenfor deltar allerede i slike prosjekter, og driver teknologispredning ut fra disse.

Kanskje kan vi foreslå en mal for erfaringsdatabaser for prosessforbedring, som del av en nasjonal metodebok? Så hva venter vi på?

REIDAR CONRADI

NTH, TRONDHEIM

TOR STåLHANE

DELAB, TRONDHEIM

KARLHEINZ KAUTZ

NR, OSLO