A szoftverfejlesztés és gyártás mutatószámai
Közzététel szerző: Fodor Tamás itt KPI · Csütörtök 17 Jún 2021
Tags: szoftver, fejlesztés, gyártás, mutatószám
Tags: szoftver, fejlesztés, gyártás, mutatószám
Szoftverfejlesztés, gyártás és szoftver termékek mutatószámai
Az Üzleti folyamatok fő mutatószámai c könyvem videós összefoglalóját posztoltam a LinkedIn közösségi oldalon. Az egyik kommentelő a következőket írta.
"Még nem lapoztam bele könyvbe "videó segítségével", de valósághű élmény volt, bár a LinkedIn appban nem volt könnyű. Köszönöm a lehetőséget, alapos gyűjteménye a KPI-knek, érthetően elmagyarázva, szemléletes példákkal. Ami a szoftver cégeknél segítene, ha szoftver fejlesztési illetve szoftver minőségi mutatókról is lenne szó. Szoftver minőség vonatkozásában az ISTQB oktatások kézikönyvei számítanak számomra referenciának, azt némi gyakorlati példákkal kiegészítve meg is lenne még egy fő fejezet, és még jó néhány olvasó."
Azt ígértem a kommentelőnek, hogy a következő kiadásban benne lesz.
Az ötlet azonban nem hagyott nyugodni, ezért összegyűjtöttem párat (egyenlőre példák nélkül), amelyeket szeretnék közre adni.
A szoftverfejlesztési mutatók két típusa
- <strong>Szoftvermutatók</strong> a szoftver minőségének mérésére (amely az időben is változhat).
- <strong>Projektmutatók</strong> a szoftverfejlesztési projekt előrehaladásának és az érintett teamek (fejlesztői csapat, UX tervezők, minőségbiztosítási csapatok, támogató csapat) termelékenységének értékelésére.
Szoftvermutatók
Kódminőség
A fő kódminőségi mérőszámok a következők:
Karbantarthatósági index
A fenntarthatósági index egy szoftveres mérőszám, amely azt méri, hogy a forráskód mennyire karbantartható (könnyen támogatható és módosítható). A karbantarthatósági indexet egy képlettel számítják ki, amely a Forráskód sorok száma, a Ciklomatikus komplexitás és a Halstead értékeit tartalmazza. Értéke 0-100 közé eshet. A 20 és100 közötti érték elfogadható, minél nagyobb, annál jobb.
Ciklomatikus komplexitás
Egy program vezérlésfolyam-gráfja éleinek és csúcsainak száma alapján számolják. Iránymutató a program fejlesztéséhez és teszteléséhez. A szoftver kockázati szintjének jellemzésére is használják. Az általános ajánlás szerint a 10-nél alacsonyabb mutatószám-értékre kell törekedni.
Az öröklési hierarchia mélysége
Objektumorientált programozásnál az osztály bonyolultságát mutatja: hány öröklődési szintnyi ,,távolságra" van a „gyökérosztálytól”. Célérték: 0.
Osztályok közötti csatlakozás
Osztály bonyolultsága: az adott osztályhoz kapcsolódó osztályok száma. Célérték: 0.
Kódsorok száma
Minél kevesebb, annál jobb.További mutaatókat ismerhet meg részletesen a következő dokumentumban: http://hadmernok.hu/2009_4_kun.pdf
A minőség tesztelése
Ezek a mutatószámok bizonyítják a szoftver tervek érettségét és érettségét a gyártásra. Mutatja, hogy a minőségbiztosítási csapat biztosította minimális a szoftverhibákat, és hozzájárul a kiváló minőségű szoftverkiadásokhoz.
Vizsgálati fedezettség
A tesztfedezettség a tesztesetekkel lefedett szoftverkövetelmények százalékos arányát mutatja. A tesztfedezet magas szintű fenntartása javítja a szoftvernek a követelményeknek való megfelelését. 80%-nál nagyobb legyen!
A felhasználói elfogadási tesztelés (UAT) során talált hibák
Az UAT (User Acceptance Testing) során talált hibák a gyártás előtti szoftverminőség szintjét tükrözik. Ha az UAT során felfedezett hibák száma megközelíti az előtte talált hibák számát, mind a tesztelési, mind a szoftvertervezési szakaszok javításra szorulhatnak. 30-nál kisebb a jó érték.
A gyártás során talált hibák
A gyártásba csúszott hibák bevételkiesést okozhatnak, mivel a felhasználók nem szeretik a hibás szoftverek Ahasználatát. Ezért gondoskodnia kell arról, hogy a hibák legalább 90% -a megszűnjön a szoftver kiadása előtt. Az összes „bug”-on kívül 10%-nál legyen kisebb.
A megoldás elérhetősége
A megoldás rendelkezésreállása fontos mutatószámcsoport, mivel a felhasználók elutasítják az olyan olyan alkalmazást, amely a hozzáférés és a használat során problémás. Mutatja a szoftverfejlesztő csapat hatékonyságát a hibaelhárítás és az alkalmazások teljesítményének javítása területén is.
A meghibásodások közötti középidő (MTBF)
Az MTBF használható szoftverhibák előrejelzésére és egy támogató csapat munkájának értékelésére. Az alacsony értékek itt a rendszer teljesítményének elégtelen nyomon követését vagy a múltban rosszul végrehajtott javítási munkát jelezhetik. (Könyvemben ezt a mutatót az Eszközmenedzsment indikátorai c. fejezeten belül mutattam be.)A helyreállítás/javítás átlagos ideje (MTTR)
Az MTTR megmutatja, hogy a csapat általában mennyi időt tölt szoftverproblémák megoldásával. A javítási idő a visszaállítási időszakra, a tesztelésre és a funkcionalitáshoz való visszatérésre terjed ki.Az MTTR legalacsonyabb szinten tartása kritikus fontosságú egy szoftverfejlesztési projektben, hogy elkerülje a hosszú állásidőket és az ebből eredő bevételkiesést. (Az MTTR szintén szerepel könyvem eszközmenedzsment fejezetében.)
Elérhetetlen esetek száma (rendelkezésreállás)
A mérőszám azt jelzi, hogy havonta hányszor nem sikerült egy alkalmazást elérni. Általában kisebb, mint 100%, mivel az alkalmazás ütemezett karbantartásához bizonyos állásidőre van szükség. (Az eszközmenedzsment és szolgáltatás fontos mutatója.)Oldal betöltési ideje (csak webalkalmazásokhoz)
Az oldal betöltési ideje azt mutatja, hogy a tartalom milyen gyorsan töltődik be egy weblapra. Ezt a mutatót folyamatosan javítani kell, mivel ez erősen befolyásolja az általános felhasználói élményt. A webalkalmazásnak az oldal betöltési idejének 2-3 másodpercen belül kell maradnia (az alacsonyabb még jobb). Ellenkező esetben a felhasználók elhagyhatják az oldalt. Ezen kívül a kereső motorok a lassúbb oldalakat hátrább sorolják keresési eredményeknél.Megoldás biztonsága
A biztonsági mutatókat a biztonsági réskezelés tervezésére használják. Itt az értékszámok nem annyira számítanak, mint egy általános tendencia, amelyet egy szoftverfejlesztési projekt során tárnak fel.
A rendszeres behatolásvizsgálattal talált sebezhetőségek száma
Ez a mérőszám a biztonsági kockázatoknak való megfelelés mértékét mutatja. Ideális esetben e mutatószám értékének csökkennie kell a projekt előrehaladásával, ami azt jelzi, hogy a megoldás a biztonság szempontjából egyre érettebb. A növekvő számok azt jelenthetik, hogy a szoftverfrissítések rohanásban kerülnek gyártásba. 5-nél kevesebb legyen.Megoldatlan ismert biztonsági rések száma
A javított biztonsági rések száma nem ad teljes képet a megoldás helyzetéről, ha nem hasonlítják össze a még nyitva hagyott biztonsági kiskapuk számával. Ennek a mutatószámnak a mérése segít ezeknek a kiskapuknak a szem előtt tartásában és azok bezárásának megtervezésében. Elfogadható, ha 3-nál kisebb.A biztonsági események száma és súlyossága
Ez a mérőszám a biztonsági megoldások általános tendenciáját állapítja meg, és segít rangsorolni az eseményeket, amelyekkel foglalkozni kell. A súlyossági rangsor mögötti kritérium azon alapul, hogy egy incidens milyen erősen befolyásolhatja a szoftver megbízhatóságát. Az incidensek komolyságától függöen 1-2 lehet.
Felhasználói elégedettség
A felhasználói elégedettség mérése felméréseken keresztül történik. A felhasználók számára a tapasztalatok értékelése segít megérteni, hogy mi a jó az alkalmazásban, és mi javítható a következő kiadásban. A felhasználói elégedettségi felmérésekhez a következő területeket is érintheti.
A funkcionalitással kapcsolatos felhasználói elvárásoknak való meg nem felelése.
Felhasználói felület kényelme
A szoftver teljesítményének stabilitása.
Projektmutatók
Költségek
Tényleges és tervezett költségek
A mérőszám segít szabályozni a kiadásokat, és jelzi, ha újratervezésre van szükség. A befejezéshez szükséges költségvetés
A projektmenedzser előrejelezheti ezt az értékeit minden egyes mérföldkő után, és korrekciót kérhet a projekt költségvetésének és időtartamának esetleges módosítására.
A fejlesztői team teljesítménymutatói
Ez a mutatószámcsoport meghatározza a szoftverfejlesztői csoport teljesítményének alapértékét, és segít egy biztonságos előrejelzést adni arról, hogy mennyi ideig tart a munka befejezése, például egy új funkció kifejlesztése. Átfutási idő és ciklusidő
Mind az átfutási idő, mind a ciklusidő azt méri, hogy egy adott típusú feladat milyen gyorsan fejeződik be, de a folyamat különböző részeit fedik le. A ciklusidő nyomon követi az adott feladaton végzett munka aktív folyamatát. Az átfutási idő pedig attól a pillanattól kezdődik, amikor a munkát kérik, és a ciklusidővel folytatódik, beleértve a feldolgozási időt és a várakozási időt. Például a feladat befejezése 2 órát vett igénybe (ciklusidő), de a folyamat egyéb feladatai miatt 4 napos átfutási ideje volt. (Könyvem Termékek és szolgáltatások fejlesztésének mutatószámai c. fejezetében az Agilis fejlesztés mutatószámaként írtam erről.) Sebesség
A csapat sebessége megmutatja az átlagos munkamennyiséget (sztoripontokban vagy órákban), amelyet egy csapat befejez az iteráció során. Segít megbecsülni, hogy a csapatnak hány iterációra van szüksége a feladatok befejezéséhez a lemaradásban. (Ezt a mutatót szintén tárgyaltam a könyvemben.) Üzembe helyezés gyakorisága
A telepítési gyakoriság azt jelzi, hogy milyen gyakran adnak új funkciókat a termékhez. Ennek a mérőszámnak állandónak kell maradnia, vagy idővel kissé növekednie kell. A gyors növekedés nem biztos, hogy jó jel, mivel az alkalmazás leállásainak és a gyártásban talált hibák számának növekedéséhez vezethet a sietős végrehajtás miatt, míg a hirtelen csökkenés a folyamat szűk keresztmetszetét jelzi. A tény/terv időráfordítás (iterációkhoz vagy bizonyos jellemzők végrehajtásához)
Ez a mutatószám ellenőrzi, hogy a szoftverfejlesztési folyamat követi-e a projekt ütemtervét. Ha az eltöltött idő eltér a tervezett időtől, előfordulhat, hogy a projektmenedzsernek át kell csoportosítania az erőforrásokat. Folyamatos projektek esetében ez a mérőszám a tervezett és a kidolgozott funkciókra változtatható. Fontos fejlesztési mutatószám, melyet a könyvemben is bemutatok. 80 % feletti érték elfogadható.
A biztonsági események száma és súlyossága
- Ez a mérőszám a biztonsági megoldások általános tendenciáját állapítja meg, és segít rangsorolni az eseményeket, amelyekkel foglalkozni kell. A súlyossági rangsor mögötti kritérium azon alapul, hogy egy incidens milyen erősen befolyásolhatja a szoftver megbízhatóságát. Az incidensek komolyságától függöen 1-2 lehet.
Felhasználói elégedettség
A felhasználói elégedettség mérése felméréseken keresztül történik. A felhasználók számára a tapasztalatok értékelése segít megérteni, hogy mi a jó az alkalmazásban, és mi javítható a következő kiadásban. A felhasználói elégedettségi felmérésekhez a következő területeket is érintheti.A funkcionalitással kapcsolatos felhasználói elvárásoknak való meg nem felelése.
Felhasználói felület kényelme
A szoftver teljesítményének stabilitása.
Projektmutatók
Költségek
Tényleges és tervezett költségek
A mérőszám segít szabályozni a kiadásokat, és jelzi, ha újratervezésre van szükség.
A befejezéshez szükséges költségvetés
A projektmenedzser előrejelezheti ezt az értékeit minden egyes mérföldkő után, és korrekciót kérhet a projekt költségvetésének és időtartamának esetleges módosítására.
A fejlesztői team teljesítménymutatói
Ez a mutatószámcsoport meghatározza a szoftverfejlesztői csoport teljesítményének alapértékét, és segít egy biztonságos előrejelzést adni arról, hogy mennyi ideig tart a munka befejezése, például egy új funkció kifejlesztése.
Átfutási idő és ciklusidő
Mind az átfutási idő, mind a ciklusidő azt méri, hogy egy adott típusú feladat milyen gyorsan fejeződik be, de a folyamat különböző részeit fedik le. A ciklusidő nyomon követi az adott feladaton végzett munka aktív folyamatát. Az átfutási idő pedig attól a pillanattól kezdődik, amikor a munkát kérik, és a ciklusidővel folytatódik, beleértve a feldolgozási időt és a várakozási időt. Például a feladat befejezése 2 órát vett igénybe (ciklusidő), de a folyamat egyéb feladatai miatt 4 napos átfutási ideje volt. (Könyvem Termékek és szolgáltatások fejlesztésének mutatószámai c. fejezetében az Agilis fejlesztés mutatószámaként írtam erről.)
Sebesség
A csapat sebessége megmutatja az átlagos munkamennyiséget (sztoripontokban vagy órákban), amelyet egy csapat befejez az iteráció során. Segít megbecsülni, hogy a csapatnak hány iterációra van szüksége a feladatok befejezéséhez a lemaradásban. (Ezt a mutatót szintén tárgyaltam a könyvemben.)
Üzembe helyezés gyakorisága
A telepítési gyakoriság azt jelzi, hogy milyen gyakran adnak új funkciókat a termékhez. Ennek a mérőszámnak állandónak kell maradnia, vagy idővel kissé növekednie kell. A gyors növekedés nem biztos, hogy jó jel, mivel az alkalmazás leállásainak és a gyártásban talált hibák számának növekedéséhez vezethet a sietős végrehajtás miatt, míg a hirtelen csökkenés a folyamat szűk keresztmetszetét jelzi.
A tény/terv időráfordítás (iterációkhoz vagy bizonyos jellemzők végrehajtásához)
Ez a mutatószám ellenőrzi, hogy a szoftverfejlesztési folyamat követi-e a projekt ütemtervét. Ha az eltöltött idő eltér a tervezett időtől, előfordulhat, hogy a projektmenedzsernek át kell csoportosítania az erőforrásokat. Folyamatos projektek esetében ez a mérőszám a tervezett és a kidolgozott funkciókra változtatható. Fontos fejlesztési mutatószám, melyet a könyvemben is bemutatok. 80 % feletti érték elfogadható.
Hír forrásai:
- Hadmérnök: http://hadmernok.hu/2009_4_kun.pdf
- ScienceSoft: https://www.scnsoft.com/blog/project-kpi
- Szechenyi Egyetem: http://www.sze.hu/~heckenas/okt/swmet.pdf