Könyvjelzők:

A szoftverminőség és a szoftverfolyamatok alapfogalmai

Kritikus sikertényezők, szoftverválság

A szoftverfolyamat mozgalma

Alapfogalmak az üzleti döntéshozatalban

A szoftvertermék minősége

A megbízható folyamatra alapozott üzleti döntések

Szoftverfolyamat modellek

Szoftverérettség modell

Érettségi szintek

Üzleti motivációk

A szoftverminőség és a szoftverfolyamatok alapfogalmai

A minőségirányítás és minőségbiztosítás alapfogalmait, mint ismert, az ISO 8402-es szabvány tartalmazza. Ennek magyar megfelelője 1996-ban jelent meg MSZ EN ISO 8402:1996 hivatkozási számon. Az ISO 8402 szerint:

      º  A „folyamat" olyan, egymással kölcsönös kapcsolatban lévő erőforrások és tevékenységek összessége, amely a bemeneteket (inputs) kimenetekké (out-puts) alakítja át.

      º  A "termék" tevékenységek vagy folyamatok eredménye. A termékeket négy általános kategóriába sorolják:

  -     hardver (például: alkatrészek, részegységek, szerelt termékek),

  -    szoftver (például: számítógépprogramok, eljárások, információk, adatok, feljegyzések),

  -    feldolgozott anyagok (például: alapanyagok, folyadékok, szilárd anyagok, gázok, lemezek, huzalok),

   -    szolgáltatások (például: biztosítás, bank, szállítás).

A termékek általában ezeknek az általános termékkategóriáknak a kombinációi.

Az alábbiakban a szabvány definícióinak további részletezése helyett elemez­zük az utóbbi évtizedekben kibontakozott szoftverválság okait, majd egy üzleti dön­téshozatali szempontú megközelítés segítségével világítjuk meg a szoftvertermék és folyamatminőséggel kapcsolatos fogalmak lényegét.”

Kritikus sikertényezők, szoftverválság

Hatalmas mértékben nő azon feladatok mennyisége, amelyeknek elvégzését szoftverekre bízzuk. Szoftverektől való függőségünk növekedési ütemének megtorpanása belátható időtávon nem várható.

A szoftver mind több és több termékbe épül bele a modern világ szolgáltatási infrastruktúrájának egyre nagyobb részében és egyre több üzleti folyamatban. Ezen felül gyorsan nő a fogyasztási cikként, önálló termékként forgalmazott szoft­verek piaca is. A szoftver így közvetlenül képviseli, közvetetten pedig alátámasztja egyre több szervezet tevékenységét, eredményét, forgalmát, profitját és valódi értékét.

Ha a termelő- és/vagy szolgáltatószervezetek (pl. vállalatok) sikereket akarnak elérni termékek piacra dobásakor, szerződések elnyerésekor, valamint belső műkö­désük megszervezésekor, és ha alkalmazkodóképesek akarnak lenni és fenn akar­nak maradni a gyorsan változó piacokon, akkor e szervezeteknek a megfelelő szoftverre van szükségük. Olyan szoftverre, amely a megfelelő feladatot látja el, a meg felelő áron, és a megfelelő időben áll rendelkezésre.

A megfelelő szoftver beszerzéséhez a vállalatnak széles körű tevékenységeke, belső és külső erőforrásokat kell mozgósítania. Ezek a tevékenységek és erőforrá­sok szoftverházaktól eltekintve idegenek a vállalat főprofiljától. Becslések szerint Európában a szoftverfejlesztések 70%-át olyan szervezetek végzik, amelyeknek az alaptevékenysége nem szoftverrel kapcsolatos.

Ebben rejlik a szoftverválság alapvető magyarázata. A szoftverválság közel há­rom évtizede vonja magára figyelmünket, megoldani azonban mindeddig nem tud­tuk. Első közelítésben ennek két fő oka az, hogy

-   egyrészt a szoftver olyan kritikus sikertényező, amelynek növekvő mértékű funkcionális teljesítőképességére a vállalatok egyre nagyobb igényt tartanak.

-   másrészt az ilyen igényeket kielégítő méretű és bonyolultságú szoftverek ki­fejlesztése olyan technikai és menedzselési képességeket követel, amelyek a legtöbb vállalat kulturális és erőforrás-lehetőségein kívül esnek.

Nagyszámú vállalat felső vezetői (akiknek képzése és tapasztalata nem az infor­mációtechnológia területéről származik) nem képesek sem megérteni a szoftver­probléma természetét és komolyságát, sem kiértékelni a javasolt megoldásokat. Így a feladat a professzionista szoftveresekre marad, akik a problémát elsősorban tech­nológiai szempontból látják, és úgy is próbálják megoldani. Mivel a szoftverfej­lesztési technológia általában a vállalati problémakör kisebb jelentőségű eleme, és mivel a rossz technológiai megoldások javítás helyett gyakran rontanak a helyze­ten, a fenti próbálkozások ritkán sikeresek.

A vállalati felső vezetés és a szoftverfejlesztők között kommunikációs szakadék tátong, amelyet már a szoftverválság előtt felismertek. A két csoportnak különböző a nyelve, a célja, a problémameglátási tere, az értékrendje. Kölcsönös meg nem értésük a legtöbb problémamegfogalmazási és megoldási kísérletet végzetesen eltorzítja.

Ma azonban már mindkét oldalról változás tapasztalható. A szoftverfejlesztők felismerték a minőségi szoftverkészítési folyamat, röviden: a szoftverfolyamat elő­térbe helyezésének fontosságát, a felső vezetés pedig felismerte, hogy a szoftver ténylegesen üzleti tevékenységük kritikus sikertényezője, valamint azt is, hogy a szoftverfolyamat javítása lehetővé teszi, hogy jobban kézben tartsák a szoftverfej­lesztők tevékenységét.

A szoftverfolyamat mozgalma

A szoftverfolyamat-mozgalom indulása az 1980-as évek közepére tehető. A 80-as évek végéig azonban csak speciális szakemberek érdeklődési körébe tartozott, a szoftverfejlesztőknek csak egy elenyésző kisebbsége foglalkozott vele.

Vizsgáljuk meg a szoftverfolyamat fogalom meghatározását és jelentőségét.

- A szoftverfolyamat azon technikai és menedzselési folyamatok összessége, amelyek a szoftverkövetelmények meghatározásához és ezen követelménye­ket kielégítő szoftvertermékek kidolgozásához és bevezetéséhez szüksége­sek.

A szoftverfolyamat jelentőségét az a felismerés indokolja, hogy „a termék minő­ségét nagymértékben meghatározza az előállítására szolgáló folyamat". A termé­kek tulajdonságainak ellenőrzése és javítása a folyamat ellenőrzésén és javításán keresztül valósítható meg.

A szoftverfolyamat-mozgalom a kezdetektől két ágon fejlődött:

-   A szoftverfolyamat technológiai ága a technikai tevékenységek mikroszintű modellezésével foglalkozott. Mind egyéni, mind csoportos folyamatok támo­gatásához nyújtott eszközöket. Épített a létező modellező nyelvekre és a szoft­verfejlesztő környezetek architektúrájára.

-   A szoftverfolyamat javítási ága a szoftverfolyamat struktúrájának és érettsé­gének makroszintű modellezésével foglalkozott, felmérési és javítási mód­szereket és eszközöket nyújtott. Forrásai a minőség- és a technológiafelmérés területéről származnak.

Mindezek, folyamatosan korszerűsödő tartalommal, ma is érvényesek.

A továbbiakban a javítási ággal foglalkozunk.

A felső vezetés (menedzsment) csak a 90-es évek eleje óta kezdi felismerni a tényt és annak következményeit, hogy a szoftver az üzlet kritikus sikertényezője bármilyen alaptevékenységen felül.

Új reményt ad számára, hogy a szoftverfelmérési és javítási módszertanok le­hetővé teszik a szoftverfejlesztők minőség, költség és idő vonatkozású teljesítésé­nek kézbentartását.

A további közeledés elengedhetetlen. A szoftver-előállítási folyamatnak haté­konynak és megbízhatónak kell lennie, hiszen a XXI. század információs társadal­mának hajtóereje a szoftver lesz, hasonlóan ahhoz, ahogy a XX. századé az elektro­mosság, a XIX. századé pedig a gőz volt.

Alapfogalmak az üzleti döntéshozatalban

Általában a minőség és azon belül a szoftverminőség megítélése sok szempontú döntéshozatali folyamat, ezért kiindulásképpen vizsgáljuk meg röviden ez utóbbi terület alapfogalmait.

A sok szempontú döntéshozatali folyamat megoldási változatok rangsorolását vagy kiválasztását végzi el egy jól meghatározott szempontrendszer alapján. A szem­pontok állhatnak tulajdonságokból, célirányokból és végcélokból. A tulajdonságok egyszerűen a valóság leírására szolgálnak. A célirányok tulajdonságokból képződ­nek az előnyös és előnytelen irányok meghatározásával. Ezeket már alapvetően befolyásolják a döntéshozók követelményei. A végcélok a tulajdonságok vagy cél­irányok elérendő szintjét jelentik. Ezeket teljes mértékben a döntéshozók követelményei határozzák meg. Végül a szempontrendszer egy egyén vagy csoport által egy adott döntési helyzetben lényegesnek ítélt tulajdonságok, célirányok és végcélok összességét jelenti. A kognitív pszichológiai korlátok legyőzésének érdekében a szempontrendszereket hierarchikusan strukturálják, hogy egy-egy szinten ne kell­jen 72 szempontnál többet áttekinteni.

Egy minőségi szabvány a szakértői csoport által konszenzus alapján lényegesnek ítélt szempontrendszer a minőség megítéléséhez. A minőségügy területén alapvető a  termék- és a folyamatminőség közötti különbség megértése. Most az alapvető különbségre világítunk rá a fenti sok szempontú döntéshozatali fogalmak felhasználásával

A szoftvertermék minősége

Egy szoftvertermék minőségének megítélése az információtechnológia egyik alap­kérdése. Számos könyv [Gilb, 1988], [Gillies, 1992], [Boehm, 1981] és cikk foglal­kozik ezzel a kérdéskörrel általában anélkül, hogy hivatkozna a sok szempontú döntéshozatal fogalmaira, azokat azonban mégis felhasználja. Az ISO/IEC 9126 szabvány meghatároz egy hierarchikus szempontrendszert, amelynek első szintje a következő elemeket tartalmazza:

-    funkcionalitás,

-    megbízhatóság,

-    használhatóság,

-    hatékonyság,

-    karbantarthatóság,

-    hordozhatóság.

Ez a szabvány is konszenzus alapján lényegesnek ítélt szempontrendszer a szoftverminőség megítéléséhez. Ilyen konszenzust azonban még nem sikerült kialakítani a szempontok további részletezésével kapcsolatban. Erre csak informális útmutatást ad a szabvány függeléke, addig a szintig azonban az sem jut el, ahol már a ténylegesen mérhető tulajdonságokat is meghatároznák. Így az ISO/IEC 9126 szabvány valójában nem teljesíti alapvető feladatát, hogy a szoftvertermék-minőséget egységesen kiértékelhessék. E szerep betöltésére alkalmas a SCOPE szoftvertermék-kiértékelési útmutató [Boegh, 1994], amelynek ISO szabvánnyá nyilvánítása folyamatban van

Az ISO/IEC 9126-os szabvány például a következő üzleti döntések támogatás­ra szolgál:

  -    A szoftver követelményspecifikációja megfelelően tükrözi-e felhasználói kö­vetelményeket?

  -    A kidolgozott szoftver kielégíti-e a felhasználói követelményeket?

A megbízható folyamatra alapozott üzleti döntések

Önmagában az a tény, hogy egy szervezet adott terméke kifogástalanul megfelel a követelményeknek, nyilvánvalóan nem jelenti azt, hogy ez az állítás a szervezet jövőbeli minden termékére érvényes lesz. Egy alapvető üzleti kérdés tehát a vevő döntési problémája:

-  Képes-e a szállítószervezet a termékét úgy előállítani, hogy az nagy megbíz­hatósággal megfeleljen a követelményeknek?

E kérdés megválaszolását támogatja az ISO 9000 szabványsorozat, amely a hangsúlyt a termék helyett a folyamatra helyezi. A szoftverfolyamatra általáno­san az ISO 9001 szabvány alkalmazható, amelyet kiegészít a konkrétan szoftver­fejlesztésre vonatkozó ISO 9000-3-as útmutató. Ez utóbbi az ISO 9001-ben kifej­lett 20 elemű szempontrendszer szoftvertechnológiai megközelítésű átstrukturá­lása. Ez a szempontrendszer azonban meglehetősen terjedelmes, elemeit nehéz egy időben megvalósítani. Ezenkívül egy ISO 9000 tanúsítványt nem elég elérni, annak érvényességét fenn is kell tartani, aminek legjobb módja a folyamatos minőségjavítás. Ehhez és általában minőségjavítási prioritások kijelöléséhez azonban nem nyújt segítséget az ISO 9000 tanúsítás. A szállító döntési problémája tehát:

   Hogyan javítsuk folyamatainkat úgy, hogy az általunk előállított termékek nagy megbízhatósággal megfeleljenek a követelményeknek?

Míg a vevő döntési problémája két alternatíva (igen vagy nem) közötti válasz­tásra vonatkozott, a szállító döntési problémája számos lehetséges előrelépési irány közötti válogatást tesz szükségessé. Ez utóbbit támogatják a szoftverfolyamat-felmérési módszertanok és az azok eredményeként előálló akciótervek.

Az ISO 9000 szabványt, valamint a szoftverfolyamat-felmérési módszertanok fejlődését alapvetően meghatározó Képesség-Érettség Modellt (Capability Matu-rity Model, CMM) a későbbiekben tárgyaljuk részletesen.

A programozásjavítás modellje

 A szoftverfejlesztés kezdeteikor használt modell két lépésből állt:

(1) Kódírás.

(2) Problémák kijavítása. Az e modell által felvetett nehézségek ma már jól ismertek:

-   Néhány javítás után a kód olyan rosszul strukturálttá válik, hogy a további javítások túl drágák lesznek.

-   Még a jól megtervezett szoftverek is olyan kevéssé felelnek meg a felhaszná­lói követelményeknek, hogy vagy eldobják, vagy drágán újrafejlesztik őket.

A vízesésmodell

Ma a legtöbb cég alkalmazza (lásd az alábbi ábrát). Ennek alapvető oka, hogy könnyű megérteni, és jól meghatározhatók az egyes szakaszokhoz tartozó dokumentációk.

A vízesésmodell konzisztens a felülről lefelé történő (top-down) kifejlesztést követő, strukturált programozási modellel, és lehetővé teszi az egyes szakaszok közötti visszacsatolást, valamint a prototípuskészítés beépítését a szoftver­életciklusba. E megközelítés következetes betartása azonban további problémákhoz vezet:

-   A prototípusépítés felesleges olyan projekteknél, ahol a tervezési kérdések egyébként világosak.

-   A tiszta felülről lefelé megközelítéshez előretekintő lépéseket kell beiktatni, hogy meghatározzák az alacsony szintű, de nagy kockázati tényezőt jelentő, esetleg sokszorosan felhasználható szoftvermodulokat.

A fenti problémák vezettek a spirálmodellhez.

Spirálmodell

A Boehm által 1988-ban javasolt ún. spirálmodell lényeges előrelépés a vízesésmodellhez képest.

E modell nagy figyelmet fordít a kockázatokra és a költségproblémákra, vala­mint előtérbe helyezi a prototípusépítést. A sugár irányú dimenzió a halmozott költségeket, míg a szögelfordulás az időbeli előrehaladást szemlélteti.

A spirálmodell egyik legfontosabb jellemzője, hogy minden ciklust érvényes­ségvizsgálati és ellenőrzési szemle követ. Ezáltal biztosítható minden érdekelt fél elkötelezettsége. Minden ciklusban készül egy (újabb) prototípus, amely lehetővé teszi a rendszer bemutatását és a hibák korai kiküszöbölését.

A spirálmodellt [Gilb, 1988] a következő módon kritizálja: „A spirálmodell semmi szükségeset nem ad a fejlesztési folyamathoz. Ez nem azt jelenti, hogy ne lenne hasznos egy olyan környezetben, ahol a vízesésmodellre hatalmas bürokrácia épül. Boehm feltehetően foltozgatni próbálja a létező kultúrát úgy, hogy diplomatikus maradjon."

Tom Gilb elégedetlen a spirálmodellel, és ezért kidolgozza az evolúciós modellt [Gilb, 1988].

Az evolúciós modell

Az evolúciós modell alapfogalmai a következők.

     -     Többcélú tervezés

A hagyományos szoftvertervezés a funkcionális követelményekre összpontosít, tehát arra, hogy mit csinál a szoftver és nem arra, hogy milyen jól, vagy milyen áron. Olyan jellemzőkre is megfelelő hangsúlyt kell helyezni, mint a használható­ság, vagy a karbantarthatóság.

     -     Korai és gyakori iteráció

A vízesésmodell és a spirálmodell alapkérdése, hogy mi a legtöbb, mi az a leg­nagyobb lépés, amit korlátaink között (költségvetés, határidő, tárolóhely) el tudunk érni. Az evolúciós modell ezzel szemben a végcélunk felé vezető, de legkevesebb erőforrást igénylő hasznos lépést keresi. Ezzel a megközelítéssel a távol-keleti filo­zófiák forrásaiból merít.

     -     Minden lépésben teljes elemzés, tervezés, építés és teszt

Tom Gilb véleménye szerint a szoftverfejlesztési folyamatban túl sok az ismeret­len, a dinamikus változás, túl komplexek az összefüggések. Ezért „a szoftverprojek­tekben a legnagyobb időpocsékolás a részletes követelményelemzés, amelyet részle­tes rendszerterv, majd kódolás és tesztelés követ". Ehelyett minden kis lépés után a kapott visszajelzésektől függően kell módosítani az azonnali tervet, az architekturális elképzeléseket, és szükség esetén mind a rövid, mind a hosszú távú célokat is.

     -     Felhasználóorientáltság

A szoftverprojektek gyakran eltávolodnak a tényleges piaci, felhasználói igé­nyektől, és a gép, az algoritmus, vagy a határidők kerülnek a középpontba. Az evo­lúciós modell ehelyett alapvető hangsúlyt helyez a visszacsatolásra, a felhasználói értékek változására, a fejlesztési költségek becslésére.

     -     Rendszermegközelítés (rendszerelmélet)

A programozás mellett figyelmet kell fordítani például a dokumentációra, a be­tanításra, a marketingre, a motivációra is.

     -     Nyíltvégű rendszerfelépítés

Folyamatosan elemezni kell azokat a lehetőségeket, amelyek minél adaptálhatóbb, változtatást tűrő (robusztus) rendszerhez vezetnek.

     -     Eredményorientáltság

A hagyományos vízesésmodellben a folyamat fontosabbnak tűnik, mint az ered­mény. A folyamat formális követelményeinek átgondolatlan követése oda vezethet, hogy projektek hatalmas erőfeszítéseket tesznek nem mérhető és nem is megfogal­mazott célok érdekében. Számos ismert, nagyszámítógépes szoftver példája igazol­ja, hogy ez a veszély mennyire gyakori és következményei milyen súlyosak.

Szoftverérettség-modell (CMM)

Az előző szoftverfolyamat-modell tényleges, fokozatosan érettebbé váló menedzse­léséhez ad segítséget [Humphrey, 89]. A Watts Humphrey által a Carnegie Mellon Egyetem Software Engineering Intézetében (SEI) kifejlesztett Képesség-Érettség Modell (Capability Maturity Model, CMM) mindmáig meghatározó szerepet játszik a szoftverfolyamat-felmérés és -fejlesztés területén.

Humphrey gondolatainak gyökerei a Teljes körű Minőségmenedzselés (Totál Quality Management, TQM) hagyományaiból erednek. A mozgalom első kiemel­kedő személyisége Shewhart volt, akinek a két világháború között jelent meg „Ipari termékek minőségének gazdasági ellenőrzése" (The Economic Control of Quality of Manufactured Products) című könyve. Követői a háború utáni ipari minőségi mozgalom tekintélyes vezéregyéniségei, Deming, Juran és Crosby. Humphrey mun­káját Crosby minőségmenedzselési érettségi táblázata ösztönözte.

Az eredmény többszöri átalakulás után a 18 kulcs-folyamatterületet (key process area) 5 érettségi szintre felosztó modell. A kulcs folyamatterületek csupán a szoftverfolyamat első felosztását jelentik. Minden kulcs-folyamatterület kulcs­tevékenységekből (key practices) áll. A kulcs-folyamatterületek az őket alkotó kulcs-tevékenységekkel jó megközelítést adnak a teljes szoftverfolyamat lefedéséhez. A megközelítés Crosby munkájával ellentétben nem a kulcs-folyamatterületek érettségét, hanem az egész szervezet szoftverkészítési érettségét méri. Ennek eredményeképpen választ lehet adni a szállító korábbiakban felvetett döntési problémájára, amely a folyamatjavítás lehetséges irányai közötti prioritásokra vonatkozott.

A képesség-érettség modell

Az egyszerűbb kifejezésmód érdekében a továbbiakban „kulcs-folyamatterület" helyett a kulcsterület szót használjuk.”

A következőkben a CMM összetevőit ismertetjük.

Érettségi szintek

Az érettségi szint az érett szoftverfolyamat irányába megtett lépések egy jól meghatározott szintje. A CMM legfelső szintű struktúráját az öt érettségi szint alkotja.

    -   A kezdeti szint

Egy kezdeti szintű szervezet nem biztosít stabil környezetet a szoftverfejlesztés és karbantartás számára. Kritikus helyzetekben a projektek nem követik a tervezett eljárásokat, rákényszerülnek a tűzoltásszerű kódolás-tesztelés stílusra. Az esetleges siker kizárólag egy kiváló képességű menedzseren és a lelkes programozócsapaton múlik. Ilyen környezetben általában nincs idő a folyamatok javításán gondolkodni.

     -   Az ismételhető szint

Egy ismételhető szintű cégnél vannak bevezetett irányelvek a szoftverprojektek menedzselésére, valamint eljárások ezen irányelvek betartására. Így lehetővé válik a korábbi projektekben kidolgozott sikeres megközelítések, tevékenységek megismétlése, akkor is, ha maguk a folyamatok eltérnek egymástól.

     -  A meghatározott szint

A meghatározott szinten a szoftverfejlesztés és karbantartás technológiai és menedzselési feladatainak végrehajtása dokumentált szabványos folyamatot követve megy végbe. Van egy olyan csoport, amelynek feladata a folyamatok követése és a szabványok szükség szerinti fejlesztése. Egy szervezeti képzési program biztosítja az alkalmazottak és a menedzserek tudásszintjének javítását.

     -  A menedzselt szint

A menedzselt szinten a szervezet mind a termékekre, mind a folyamatokra mér­hető minőségi célokat ír elő. A projektek úgy tartják kézben termékeiket és folyamataikat, hogy elfogadható mennyiségi korlátok közé szorítják azok szórását.

     -  Az optimalizáló szint

Az optimalizáló szintet az állandó folyamatfejlesztés jellemzi. A projektek elemzik a hibákat, meghatározzák azok okait, és javítják a folyamatot annak érdekében, hogy a hibák ne ismétlődjenek meg. A tapasztalatokat más projekteknek is átadják.

Képességek

A szoftverfolyamat képessége határozza meg, hogy a folyamatot követve milyen eredmény várható. A szervezet szoftverfolyamatának képessége arra is módot ad, hogy a szervezet által elvégzendő következő szoftverprojekt legvalószínűbb kimenetelét megjósoljuk.

Kulcsterületek

Mindegyik érettségi szint kulcsterületekből áll. Minden kulcsterület egymáshoz tartozó tevékenységek olyan csoportja, amelynek együttes megvalósítása az adott érettségi szinten a folyamat képességeinek biztosítása érdekében fontos céloknak felel meg. A kulcsterületek mindig egyetlen érettségi szinten helyezkednek el. Például a 2. szint egyik kulcsterülete a szoftverprojekt tervezése.

Célok

A célok a kulcsterületek kulcstevékenységeit foglalják össze, segítségükkel meghatározható, hogy a szervezet vagy projekt hatékonyan valósította-e meg a kulcsterületet. A célok megadják az egyes kulcsterületek alkalmazási korlátait és célkitűzését.

Például a szoftverprojekt tervezése kulcsterület egyik célja: A szoftverbecslések a szoftverprojekt-tervezés és -követés érdekében dokumentáltak.

Általános jellemzők

A kulcsterületek kulcstevékenységei az általános jellemzők szerint szerveződnek. Az általános jellemzők azt mutatják meg, hogy a kulcsterület megvalósítása és intézményesítése hatásos, megismételhető és tartós-e. Az általános jellemzők a kulcstevékenységet a felhasználást elősegítő csoportokba és sorrendbe rendezik. Az öt általános jellemző a következő:

Elvégzés iránti elkötelezettség

Az elvégzés iránti elkötelezettség azon tevékenységeket írja le, amelyeket a szervezet annak érdekében végez, hogy a folyamat létrejöjjön és tartós legyen. Az elvégzés iránti elkötelezettség általában a szervezeti irányelveket és a felső vezetés támogatását jelenti.

Elvégzés képessége

Az elvégzés képessége a szoftverfolyamat megfelelő megvalósításához szükséges projekt vagy szervezeti előfeltételeket írja le. Az elvégzés képességéhez tartoznak az erőforrások, szervezett struktúrák és a képzés.

Elvégzett tevékenységek

Az elvégzett tevékenységek a kulcsterület megvalósításához szükséges szerepköröket és eljárásokat írják le. Az elvégzett tevékenységek közé általában a tervek és eljárások elkészítése, a munka végrehajtása, követése és a szükséges helyesbítő tevékenységek elvégzése tartozik.

Mérés és vizsgálat

A mérés és vizsgálat a folyamat mérését és a mérések elemzését írja le. A mérés és vizsgálat általában olyan mérésekre tartalmaz mintát, amelyekkel meghatározható az elvégzett tevékenységek állapota és hatékonysága.

A megvalósítás ellenőrzése

A megvalósítás ellenőrzése azon lépéseket írja le, amelyek biztosítják, hogy a tevékenységek elvégzése a meghatározott folyamat szerint történjen. Az ellenőrzés általában a vezetői szemléket és auditokat, illetve a szoftverminőségbiztosítást jelenti.

A kulcstevékenységek

Minden kulcsterület kulcstevékenységek által meghatározott, amelyek elvégzése a kulcsterület céljainak elérését szolgálja. A kulcstevékenységek a kulcsterület hatékony megvalósításához és intézményesítéséhez szükséges legfontosabb infrastruktúrát és tevékenységeket írják le.

Minden kulcstevékenység egyetlen mondatból áll, amelyet gyakran egy részletesebb leírás követ, példákat és a kidolgozást is tartalmazva. Ezek a kulcstevékenységek, más néven a felső szintű kulcstevékenységek határozzák meg a kulcsterület alapvető irányelveit, eljárásait és tevékenységeit. A részletes leírás egyes elemeit gyakran résztevékenységeknek hívják. A kulcstevékenységek azt mondják meg, hogy mit kell elvégezni, de nem írják elő kötelezően, hogy ezeket a célokat hogyan kell elérni.

Üzleti motivációk

E szakasz célja kettős. Egyrészt a szoftverfejlesztők részére képet ad az üzleti menedzserek szoftverfolyamat-fejlesztéssel kapcsolatos motivációiról, másrészt az üzleti menedzserek részére bemutatja a szoftverfolyamat-fejlesztés előnyeit és hátrányait üzleti megközelítésből.

A szoftverérettségi modellek korai időszakában nehéz volt a szoftverfolyamat-javítás üzleti előnyeit leíró tapasztalatokat találni. Ennek oka világos. Egy alacsony érettségi szintű cégnek nyilvánvalóan nem érdeke, hogy ezt a tényt nyilvánosságra hozza. A helyzet azonnal megváltozik, ha az érettségi szint érzékelhetően javul. E tény publikálása önmagában jelentős marketingelőnyt eredményezhet a cég számára. Nem meglepő tehát, hogy mindmáig a főképpen az USA-ban publikált tapasztalatok pozitívak.

Egy üzletember legfontosabb problémája az, hogy milyen módon teheti sikeressé cégét az adott és változó versenykörnyezetben. Pénzügyi, működtetési, termelési, marketing- vagy emberi erőforrás orientáltságú menedzserek erre az alapproblémára különböző megoldásokat kínálnak. Az alábbiakban a megközelítéseket először itt közölt, eredeti integrált keretbe ágyazva mutatjuk be.

A keret alapfogalma az előny. Előnyt jelent minden olyan eszköz, amellyel egy cég növelni tudja erőforráselőállító képességét. A cég erőforrásait eszközeinek növelésére, valamint az alkalmazottak és a tulajdonosok díjazására használja.

Vizsgáljuk meg a nemzetközi tapasztalatok alapján, hogy a szoftverfolyamat-javítás milyen pénzügyi, működtetési, termelési, marketing- és emberi erőforrás előnyöket eredményezhet egy cég számára.

Pénzügyi előny

Egy cég akkor rendelkezik pénzügyi előnnyel, ha a saját pénzforrásain felül felhasználható hiteleket azok költségeinél magasabb hozammal tudja befektetni.

Vajon juthat-e egy cég pénzügyi előnyhöz szoftverfolyamat fejlesztése útján?

A válasz akkor igenlő, ha megvalósításához akár hitelt is érdemes felvenni, más szóval a befektetés megtérülése (ROI = return on investment) elég nagy.

A Carnegie Mellon Egyetem Szoftvertechnológiai Intézete (SEI, Software Engineering Institute) közölt egy fontos, olyan jelentést [Herbsleb et al, 1994], amely mennyiségi információkat szolgáltat a cégek számára. Tizenhárom olyan szervezet járult hozzá érzékeny és bizalmas adatainak közléséhez, amelynél CMM alapú szoft­verfolyamat-fejlesztés történt. Ezek a következők:

-   Bull HN,

-   GTE Government Systems,

-   Hewlett Packard,

-   Hughes Aircraft Co.,

-   Loral Federal Systems (korábban: IBM Federal Systems Company),

-   Lockheed Sanders,

-   Motorola,

-   Northrop,

-   Schlumberger,

-   Siemens Stromberg-Carlson,

-   Texas Instruments,

-   United States Air Force Oklahoma City Air Logistics Center,

-   United States Navy Fleet Combat Direction Systems Support Activity.

A jelentés hangsúlyozza, hogy a közölt eredmények nem feltétlenül tipikusak, csupán azt mutatják hogy kedvező környezetben milyen előnyökre lehet szert tenni.

A 3,5-től 6 évig terjedő szoftverfolyamat-fejlesztési időszakok alatt a mért haszon és a mért költségek aránya 4x és 8,8x között volt. A haszon tartalmazza a termelékenységjavulásból és a hibák csökkenéséből származó megtakarítást, nem tartalmazza azonban az elért piaci előny értékét, amelyről a későbbiekben lesz szó.

A költségek magukban foglalják a szoftverfolyamat-csoport, a felmérések és a képzés költségeit, nem tartalmazzák azonban az új eljárások bevezetésével esetlegesen eltöltött idő közvetlen költségét.

A számok biztatók, vannak azonban olyan tapasztalatok is, amelyek szerint el­lenkező eredmény is elérhető, ha nem figyelünk kellőképpen a befektetés azonnali kihasználására. Egy erre vonatkozó kivételes számot [Capers Jones, 1996] közöl: „Több cégnél és állami szervnél sikerült személyenként 10 000 USD-t meghaladó összeget elkölteni bármilyen érzékelhető haszon nélkül."

Működtetési előny

Egy cég nyereségességét nagymértékben befolyásolja a költségek struktúrája, az­az a fix és a változó költségek megoszlása. A működtetési előny egy relatív ter­melési mennyiségváltozás által eredményezett relatív nyereségváltozás. Ez nyil­ván annál nagyobb, minél alacsonyabbak a változó költségek. Alacsony változó költségeket azonban leginkább magas fix költségek, azaz tőkeigényes eljárás ese­tén lehet elérni.

Cég magas fix költségekkel (FK) és alacsony változó költségekkel (VK)
A teljes költség TK=FK+VK

A szoftverfolyamat-javítás a fix költségeket növeli, amelybe beleértendő a képzés, a tanácsadási díjak, a szoftverlicenszek és az irodai környezet javítása. A kérdés csupán az, hogy a cég mindezzel képes-e kellő változóköltség-csökkentést elérni.

A szoftverfejlesztés változó költségeinek mérése nem egyszerű feladat. Többek között erre szolgál a funkciópontszám (function point) fogalma.

A funkciópontszám a szoftvertermék néhány, felhasználói szempontból érdekes jellemzőjén alapuló számítás eredménye. Ilyen jellemzők: a bemenetek. Kimenetek, adatcsoportok, kérdések és interfészek. A szoftverfejlesztés változó költségeinek megfelelő mértéke az adott funkciópontszám megvalósításához szükséges emberhónapok költsége (emberhónap/funkciópontszám).

Cég alacsony fix költségekkel (FK) és magas változó költségekkel (VK)
A teljes költség TK=FK+VK

Ezzel szemben az irodalomban leginkább termelékenységjavulási adatokat kö­zölnek, amelyek a fenti számok reciprokai (funkciópontszám/emberhónap), tehát növekedésük a változó költségek csökkenését jelenti.

Ha a szoftverfolyamat-fejlesztés eredményeképpen egy cég ugyanannyi funk­ciópontszámot kevesebb emberhónap felhasználásával tud megvalósítani, akkor mű­ködési előnyre tehet szert. Mindezzel együtt valódi nyeresége csak akkor képződik, ha a ténylegesen teljesített funkciópontszámból származó bevétel meghaladja a szoftverfolyamat-fejlesztés fix költségének és a ráfordított emberhónap változó költségének összegét, ami a teljes költség. Ez azt jelenti, hogy nagyobb cégek nagyobb teljesített funkciópontszámmal, nagyobb eséllyel élvezhetik a működési előny eredményét.

A [Herbsleb et al., 1994] cikk adott idő alatt beprogramozott sorok számában mért termelékenységjavulásról számol be. Ez a vizsgált cégeknél 9% és 67% között volt. Egy másik közölt mérték a korán felismert hibák számának 6-25%-os növeke­dése. Ez jelentős megtakarítás, ha azt is hozzátesszük, hogy egy átadás előtt felfe­dezett hiba kijavítása ma átlagosan 50 USD/sor, míg az átadás után felfedezett hibáé 4000 USD/sor.

Termelési előny

A termelési előny azt a nyereségnövekedést jelenti, amely a termelés hosszú távú fenntartásából eredő költségcsökkenésből származik. Gyakorlati tény, hogy az egy­ségnyi termelési költség hatványfüggvény szerint csökken, ha a cég egyre több tapasztalatra tesz szert, és ezek újrafelhasználását megfelelően menedzseli. A következő ábrán látható tapasztalati görbe létezése a mennyiségi megtakarításoknak, a tanu­lásnak, a javulásoknak és az újrafelhasználásnak köszönhető.

Tapasztalati görbe a szokás szerint logaritmikus skálájú koordináta-rendszerben

A tapasztalatok összegyűjtése és újrafelhasználása a szoftverfolyamat-javítás el­sődleges célja. Ezt a kérdéskört azonban érdekes módon eddig nem vizsgálták. A [Herbsleb et al., 1994] cikk említi, hogy a költségváltozásokat követő technikák nem foglalkoznak a változások okaival. Az ok lehet a folyamatjavítás, de lehet a tapasztalatok gyűjtése, új módszerek vagy eszközök bevezetése is.

Marketingelőny

A marketingelőny a magasabban megállapítható árak és az újító szellemű terjesztés hatása a nyereségre.

A szoftverfolyamat fejlesztése, magasabb érettségi szint, ISO 9000 vagy TICKIT tanúsítás fokozza a cég érzékelt képességét és termékeinek érzékelt értékét. Ezáltal nő a megrendelők elégedettsége és magasabb árak elérésének lehetősége.

A minőség és folyamatjavítás szerves része annak a megkülönböztető stratégiá­nak, amellyel egy vállalkozás a versenytársainál magasabb színvonalú terméket vagy szolgáltatást kíván nyújtani, illetve megrendelőivel ezt kívánja érzékeltetni. Az Egyesült Államokban a 248 szolgáltató és high-tech cégre kiterjedő felmérés szerint [Aaker, 1995] „a leggyakrabban említett fenntartható piaci versenyelőnyt a minőség jó hírneve jelentette".

A fenti amerikai felmérés mellett európai cégek is a szoftverfolyamat-fejlesztés kulcsmotivációjának tartják a szoftverkompetencia külső láthatóságának javítását. Ilyen cégek például a Lloyds Bank Plc. [Lamer, 1996] és a Siemens [Völker, Gonauser, 1996].

Az SEI által közölt tanulmány [Peterson, 1996] kivételesen méréseket is közöl a szoftverfolyamat-javítás hatásáról a marketingelőnyre. A jelentés 560 SEI felmérésre alapul. A statisztika szerint a megrendelő megelégedettsége kiváló vagy jó volt kezdeti szintről történő szoftverfolyamat-javításakor az esetek 80%-ában, ismételhető szintről meglepően csak az esetek 70%-ában, meghatározott szintről azonban már az esetek 100%-ában.

Emberi előny

Az emberi előny az alkalmazottak motivációjának nyereségre gyakorolt hatását jelenti. Jól ismert tény, hogy az alkalmazottak motivációját nagymértékben befolyásolják olyan, nem anyagi tényezők, mint a vezetési stílus, vagy a szervezeti struktúra. Az emberi előny kihasználása különösen fontos szoftver folyamatok esetén, hiszen a szoftverfejlesztés alapvetően szellemi munka. A korábban már említett [Peterson, 1996] jelentés olyan statisztikákat is közöl, amelyek szerint az alkalmazottak hangulata kiváló vagy jó lett kezdeti szintről történő fejlődéskor az esetek 20%-ában, ismételhető szintről az esetek 50%-ában, meghatározott szintről az esetek 60%-ában.

   Egy, az IBM Európai Központja által kezdeményezett felmérés szerint [Goodhew, 1996] az alkalmazottak hangulata erős korrelációban van az átadási is minőségi telje­sítménnyel. Ez a statisztika 15 európai ország 360 szervezetének válaszaira épül.