Szoftver min ség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM13-GQM.pdf · válaszolni kell ahhoz, hogy megértsük, a célt elértük-e – annak eldöntése, hogy mit kell mérni

Szoftver min ség és menedzsment -13. Mérési módszerek

2002 / 2003 1

Szoftver min ség ésmenedzsment

13. Mérési módszerek

Dr. Balla Katalin

Dr. Balla Katalin Szoftver min ség és menedzsment - 13. 2

Tartalom✔ Mérések egy szoftvercégnél

✔ Mérési módszerek, eszközök

✔ A QIP (GQM és EF)

✔ Példák lehetséges GQM-re

✔ Egyéb megközelítések

✔ Mérések a különböz modellekben• az ISO 9126-ban

• az ISO 9001:2000-ben

• a CMM-ben, SPICE-ban

• a PSP-ben és TSP-ben

• mérés és TQM filozófia

• mérés az EFQM-ben

• mérés a CMMI-ben

✔ A mérések költsége


Mérések egy szoftvercégnél✔ Stratégiai döntés

– mert költségvonzata (id, er forrás…) van

✔ Valamilyen céllal kell mérni

✔ A célok ismeretében kell a mérés tárgyát meghatározni

✔ A méréseket tervezni, követni, vezérelni kell

✔ Mérésekkel foglalkozó szervezet létrehozása szükséges

✔ A mérések elvégzése– elméleti tudás megszerzése

– tervezés

– végrehajtás

– eredmények feljegyzése, „csomagolása”, felhasználása

✔ Folyamatok javítása a mérések eredményei alapján


2002 / 2003 2


Mérési módszerek

✔Módszertanok, eljárások, esettanulmányok,„legjobb gyakorlat”…

✔Els sorban a mérések elvégzésére adnakúrmutatást, nem a konkrét mérszámokra

✔Szinte minden, a korábbi eladásokbanemlített megközelítés tartalmaz (többé-kevésbé részletes) mérési útmutatót, ajánlást


A QIP

✔ Min ségjavítási paradigma

✔ Basili, 1985(?)

✔ Software Engineering Laboryatory(SEL) - a NationalAeronautics and Space Administration/Goddard Space Flight Center(NASA/GSFC) által sponzorált szervezet

✔ Kísérleti laboratórium, a szoftverfejlesztési technológiákhatékonyságának vizsgálatára. 1976-ben alapították. Tagjai:NASA/GSFC, Software Engineering BranchUniversity of Maryland, Department of Computer ScienceComputer Sciences Corporation, Space and Earth Technology Systems

✔ http://sel.gsfc.nasa.gov/website/exp-factory/process-imp.htm


A QIP

✔ Folyamatos javításra koncentrál✔ Az egyes projektek tapasztalatát elemzi,

„csomagolja” további projektekben valófelhasználhatóság szempontjából

✔ Alapfázisai:– A szoftverfolyamat megértése– Az alkalmazott technológiák (munkamódszerek) hatékonyságának

figyelése, mérésekkel. Annak meghatározása, hogy melytechnológiák megfelelek az adott környezetben.

– A tapasztalatok „csomagolása”. Szabványok, képzés, fejldésistratégia kialakítása.


2002 / 2003 3


A QIP fázisai


A QIP lépései

1. A jelenlegi projekt és környezetének jellemzése a létez modellek ésmetrikák vonatkozásában

2. Mérhet célok meghatározása a sikeres projekt-teljesítményre és javításravonatkozóan

3. A projekt sajátosságainak megfelel mérési módszerek és eszközökkiválasztása

4. A folyamat végrehajtása, a termék elállítása, az elírt adatokösszegyjtése és validálása (hitelesítése), az adatok elemzése úgy, hogyvalós id ben javítási javaslatok is készüljenek

5. Az adatok elemzése a jelenlegi gyakorlat felmérése céljából, problémákazonosítása, leírása, javítási javaslatok

6. A tapasztalat „csomagolása”, közzététele, bevezetése más projektekben


A QIP alkalmazása

✔A QIP a SEL folyamatjavításitevékenységeinek alapja, központi elve

✔Széles körben alkalmazzák a világszoftvercégeiben


2002 / 2003 4


A QIP eszközei

✔Goal/ Question/ Metric paradigm (QIP)

✔Experience Factory Organization (EF)


A GQM✔ Eredetileg a NASA/GSFC környezetben

végrehajtott projektek hibáinak felmérésérefejlesztették (Basili), azután általánosították

✔ Gyakorlati módszer

✔ Lépései:– a projekt / szervezet céljainak megértése, számbavétele

– minden cél esetében azon kérdések meghatározása, amelyekreválaszolni kell ahhoz, hogy megértsük, a célt elértük-e

– annak eldöntése, hogy mit kell mérni ahhoz, hogy a kérdésekreválaszolni tudjunk


A GQM

✔3 lépcss mérési modellt határoz meg:• Fogalmi szint (conceptual)(cél): Egy célt egy objektumra

vonatkozóan, határozunk meg, különböz okok miatt, különbözmin ségi modelleket figyelembe véve, különböz néz pontokalapján, az objektum sajátos környezetét figyelembe véve

• Üzemeltetési szint (operational) (kérdés): Kérdéseket használunk atanulmányozott objektumra vonatkozó modellek meghatározására,majd az objektumra koncentrálunk, hogy jellemzi segítségével egybizonyos cél elérését vagy felmérését megvalósíthassuk

• Mennyiségi szint (quantitative) (metrika): Minden kérdéshez egy sormér számot rendelünk (a korábban meghatározott modellek alapján),abból a célból, hogy a kérdésre mérhet választ tudjunk adni


2002 / 2003 5


✔A modell hierarchikus struktúrája

A GQM


GQM: célok kiválasztása

Dimenziók:


GQM: példa

GOAL: Evaluate effectiveness of coding standard

QUESTIONS: Who is usingstandard?

What is coderproductivity?

What is codequality?

METRICS: Proportionof coders-using standard-using language

Experienceof coders-with standard-with language-with environ-mentetc...

CodeSize(lines ofcode, functionpoints, etc...)

Effort Errors...


2002 / 2003 6


GQM: példa


GQM: példa

(The Goal Question Metric Approach. V. Basili, G. Caldiera, D. Rombach. - ww2.umassd.edu/SWPI/ESEG/gqm.pdf )


GQM : példa

(The Goal Question Metric Approach. V. Basili, G. Caldiera, D. Rombach. - ww2.umassd.edu/SWPI/ESEG/gqm.pdf )


2002 / 2003 7


A GQM alkalmazása

✔A GQM változatos módokon használható, aszoftvergyártás minden elemére

✔ Alkalmazható a szoftverprojektre, a szoftvertel állító folyamatra és a termékre is, úgy, hogy

• A definiált metrikák a szervezethez és a szervezet céljaihozigazodnak

• A mért adatok konstruktívak, és a szervezet tanulhat azelemzésükbl.

• A metrikák és a metrikák értelmezése a különböz érdekelt felek/ csoportok nézpontját tükrözik (pl. fejlesztkét, felhasználókét,rendszergazdákét stb.)


A GQM alkalmazása. Példák.✔ 1. Cél: a fejlesztési folyamatok javítása

– Miért akar(hat)juk a fejlesztési folyamatokat javítani?• hogy (jobban) megfeleljünk a szabványkövetelményeknek (ezekben a

válaszokban nyilván az is benne van, hogy a kérdéses területen van javítanivaló)

• hogy magasabb érettségi szintet (CMM) érjünk el

• hogy a munkatársak hatékonyabban dolgozzanakMetrics needed and data to be collected:

0HWULFV�QHHGHG��3URFHVV�LPSURYHPHQWPHWULFV

'DWD�UHTXLUHG

Average elapsed time between defectidentification and correction

Average elapsed time between defectidentification and correction

Number of person hours (effort) tocomplete each activity

For each activity: actual number of personhours to complete

Elapsed time for each activity Project start dateFor each activity: Date activity started Date activity completed

Number of defects detected in each activity Number of defects detected in each activityNumber of deviations from the softwareprocess

Number of process exception reports

Nr. of requirements added or changedduring development

Nr. of requirements added or changedduring development

(http://www.spc.ca/downloads/)


A GQM alkalmazása. Példák.✔ 2. Cél: a

szoftvergyártássalkapcsolatos becslésekpontosabbá tétele

✔ Miért akar(hat)unk jobb becsléseket

végezni?– hogy ajánlataink pontosabban legyenek– hogy elkerüljük a költségek túllépését– hogy elkerüljük a határidk túllépését– hogy a profit biztos legyen– hogy a követelmények stabilak legyenek

(ne módosuljanak)– hogy a kockázatot csökkentsük

0HWULFV�QHHGHG��VRIWZDUH�HVWLPDWLRQPHWULFV

'DWD�UHTXLUHG

Initial estimate versus actual effort (personhours) for each activity

For each activity:- estimated nr of person hours to

complete- actual nr of person hours to

completeInitial estimate versus actual projectschedule for each activity

For each activity:- estimated start dateestimated completion date- date activity started- date activity completed

Initial estimate versus actual size of thesoftware (new and reused)

Estimated SLOC of new codeEstimated SLOC of reused codeTotal SLOC produced (new)Total SLOC produced (reused)

Initial estimate of staff required versusactual staff levels for each activity

For each activity:- estimated nr of staff required- nr of people on staff

Total overtime hours Total nr of overtime hours workedLabor rate (Person Hours / SLOC) for eachactivity

Total SLOC producedFor each activity:

- actual nr of person hours tocomplete

Requirements changed for each activity Initial nr of requirementsFor each activity:

- nr of requirements deleted- nr of requirements added- nr of requirements changed

Software product complexity Category of the sw product (according to apreviously made classification)



2002 / 2003 8


A GQM alkalmazása. Példák.

✔ 3. Cél: a projektkövetésjavítása

✔ Miért akar(hat)juk a projektekkövetését pontosabbá tenni?– hogy el re lássuk, ha közbe kell

avatkozni

– hogy a projektek lefutásamegfeleljen az elírásoknak

0HWULFV�QHHGHG��SURMHFW�WUDFNLQJ�PHWULFV 'DWD�UHTXLUHGEarned value of each activity Estimated SLOC required

Current SLOC completedFor each activity:Âestimated number of person hours tocompleteÂlabor rate in PH/SLOCÂnumber of units requiredÂnumber of units completed

SLOC completed Total SLOC completed to dateInitial estimate for SLOC Estimated SLOC requiredOverall percent of work complete Estimated SLOC required

Current SLOC completedFor each activity:Âestimated number of person hours tocompleteÂlabor rate in PH/SLOCÂnumber of units requiredÂnumber of units completed

Percent of work complete for each activity For each activity:Ânumber of units requiredÂnumber of units completed

Percent of budget spent to date Current total budgetTotal money spent to date

Percent of schedule elapsed Project start dateEstimated project completion dateCurrent date

Proportion of tests executed Total number of testsNumber of tests executed to date

Proportion of tests passed Total number of testsNumber of tests executed successfully to




✔ 4. Cél: a projektek átfutásiidejének minimalizálása

✔ Miért akar(hat)juk projektjeinkátfutási idejét minimalizálni?– hogy a projektek termékeit terv

szerinti határid vel adhassuk át

– hogy növeljük az új termékekvagy új program-elemekeredményességét

'HYHORSPHQW�6FKHGXOH0HWULFV

'DWD�5HTXLUHG

Elapsed time between project milestones oractivities

Project start dateFor each activity:Âestimated completion dateÂactual completion date

Initial estimate versus actual effort for eachactivity

For each activity:Âestimated number of person hours tocompleteÂactual number of person hours to complete

Initial project schedule versus actualschedule

For each activity:Âestimated start dateÂestimated completion dateÂdate activity startedÂdate activity completed

Initial estimate versus actual staffing levels For each activity:Âestimated number of staff requiredÂnumber of people on staff

Person hours spent on rework Total number of person hoursrequired to fix defects

Total overtime hours in each activity For each activity:Ânumber of overtime hours worked




✔ 5. Cél: a fejlesztésköltségeinek csökkentése– Miért akar(hat)juk fejlesztéseink

költségeit csökkenteni?• hogy a tervezett költséghatárt ne

lépjük túl

• hogy a profitot maximalizáljuk

'HYHORSPHQW�&RVW�0HWULFV 'DWD�5HTXLUHGActual cost for each activity For each activity:

•total cost in HUFAmount spent fixing defects in eachactivity

For each activity:•person hours spent fixing defects

Cost for each SLOC Total SLOC producedTotal HUF spent to date (andat end of the project)

Initial cost estimate for eachActivity

For each activity:•initial cost estimate in HUF

Budget for each activity For each activity:•funds allocated

Initial estimate versus actualeffort for each activity

For each activity:•estimated number of person hours tocomplete•actual number of person hours tocomplete

Labor rate (PH/SLOC) for each activity Total SLOC producedFor each activity:•actual number of personhours to complete

Percent of budget spent ondevelopment tasks

Current total budget in HUFTotal HUF spent ondevelopment tasks

Percent of budget spent onmanagement tasks

Current total budget in HUFTotal HUF spent onmanagement tasks

Percent of budget spent onsupport tasks

Current total budget in HUFTotal HUF spent on supportTasks



2002 / 2003 9


A GQM alkalmazása. Példák.✔ 6. Cél: a szoftver minségének javítása✔ Miért akar(hat)juk szoftverünk minségét javítani?

– hogy a termékeink megfeleljenek a követelményeknek

– hogy csökkentsük a (z átadott) hibák számát

– hogy csökkentsük az átdolgozásokra fordított idt

3URGXFW�4XDOLW\�0HWULFV'DWD�5HTXLUHG

Average person hours to fix a defect Average PH to fix a defectMean time between failures (if appropriate) Mean time between failuresNumber of defects detected of each type Number of defects of each type or priorityNumber of defects/SLOC Total number of defects detected

Total SLOC producedTotal lines of documentation Total LODPercent of code inspected Number of units coded (new)

Number of units inspected




✔ 7. Cél: a szoftver teljesítményének javítása– Miért akar(hat)juk a szoftver teljesítményét javítani?

• hogy a teljesítményre vonatkozó követelményeknek megfeleljünk

• hogy csökkentsük a hardverre vonatkozó teljesítmény-követelményeket

6RIWZDUH�3HUIRUPDQFH�0HWULFV 'DWD�5HTXLUHG

Average CPU utilization Average CPU utilizationAverage memory utilization Average memory utilizationMean time between failures (if appropriate) Mean time between failuresNumber of I/O transactions per unit of time(actual versus required)

Required I/O transactions rateMeasured I/O transactions rate

Number of lines of code (SLOC) Total SLOC producedSoftware product complexity Category of the software product



A GQM alkalmazása. Példák.✔ 8. Cél: a

termelékenységjavítása

✔ Miértakar(hat)jukjavítani atermelékenységet?– hogy a munkaer

számacsökkenjen vagystabil maradjon

3URGXFWLYLW\�0HWULFV 'DWD�5HTXLUHGAverage number of person hours spent onrework per development staff member

Total number of development staffTotal number of hours spent fixing defects

SLOC/person hours for each activity Total SLOC producedFor each activity:Âactual number of person hours to complete

Number of staff at each experience level Number of staff members at eachexperience level

Percent of budget available forsoftware development tools

Current total budget in HUFTotal HUF allocated to tools

Percent of budget available forsupport staff

Current total budget in HUFTotal HUF allocated to support staff

Proportion of person hours spent onmanagerial or support tasks for eachactivity

For each activity:Âactual number of person hours to completeÂnumber of person hours worked on supporttasksÂnumber of person hours worked onmanagement tasks

Ratio of development staff per Manager For each activity:Ânumber of managersÂnumber of development staff



2002 / 2003 10


A GQM alkalmazása. Példák.Tevékenység A tervezett és a

valós ráfordítás ,tevékenységenként

A tervezett és a valós ütemezés,tevékenységenként

A tervezett és a valós szoftverméret (újonnanfejleszetett és újrafelhasznált)

A tervezett és a valósemberi er IRUUiVszükséglet,tevékenységenként

Becsültemberórákszáma

Valósemberórákszáma

Terv.Kezdetdátuma

Trev.Befejezésdátuma

Valóskezdésdátuma

Valósbefejezésdátuma

Terv.újonnan írtSLOC

Terv.ÚjrafelhasználtSLOC

Valós újSLOc

Valósújrafelhsznált SLOC

Becsültemberier IRUUiV

száma

Valósemberier I�

száma



Terv.Kezdetdátuma






Valós újSLOc



száma

Valósemberier I�

száma



Terv.Kezdetdátuma






Valós újSLOc



száma

Valósemberier I�

száma


A GQM alkalmazása. Példák.Tevékenység Túlórák

számaTevékenységenként emberóra / forráskód-sorok száma

A megváltozott követelmények száma, tevékenységenként Az elkészítettszoftverkomplexitása (ateljes szoftverre)

ÖsszesSLOC

A megíráshozszükséges valósember órák száma

A kezdetikövetelményekszáma

Töröltkövetelményekszáma

Újonnan hozzáadottkövetelményekszáma

Megváltozottkövetelményekszáma

ÖsszesSLOC






ÖsszesSLOC






ÖsszesSLOC








tevékenység SLOC / emberóratevékenységenként

A vezetési ill. Technikai tevékenységek aránya A technikai erI��pV�YH]HW N�DUiQ\D

A support tev-kel töltött emberórák száma

A management tev-kel töltöttember órák száma

Vezet N�V]iPD Fejleszt Nszáma







A fejleszt N�V]iPD�A hibák javításával eltöltött órák száma:Az er IRUUiVRN�HORV]OiVD�V]DNWXGiV�pV�WDSDV]WDODW��V]HULQW�

A projekt tervezett költsége:A projekt tényleges költsége:Eszközök beszerzésére tervezett költség:Tényleges költség, eszközökre:A karbantartási munkák tényleges költsége:


2002 / 2003 11


Experience Factory Organization• A „kollektív tanulás”, „tudás-újrahasznosítás” szoftverfejleszt szervezete



EF3URMHFW�RUJDQL]DWLRQ ([SHULHQFH

IDFWRU\

&KDUDFWHUL]H

6HW�JRDOV

&KRRVH�SURFHVV

([HFXWH�SURFHVV

Project/environment characteristics

Tailorable goals, processes, tools,products, resource models, defectmodels...from similar projects

([HFXWLRQ�SODQV

Data, lessons learned...

Project analysis, processmodification...

3URMHFWRUJDQL]DWLRQ ([SHULHQFH�IDFWRU\

$QDO\]H�DQDO\VLV�

3URMHFWVXSSRUW

([SHULHQFHEDVH

3DFNDJH

*HQHUDOL]H

7DLORU

)RUPDOL]H

�6\QWKHVLV�

Products, data,lessons learned, models...

Direct projectfeedback

Products, leassons learned, models

Projectcharacteristics

Models, baselines,tools, consulting...

• Változó szerepek a szervezeten belül


Egyéb mérési módszerek

✔GQM: „top-down” megközelítés

✔MGQ: „bottom-up” megközelítés (Bache,1995)

✔„vegyes” megközelítés (N. Fuchs, 1995)– „fejl d ” megközelítés

• az elején: „bottom-up”

• „vegyes”

• „vegytiszta top-down”


2002 / 2003 12


Mérések a különbözszoftvermin ségi modellekben

✔ Mindenütt szerepel mérés, többé-kevésbékidolgozott módszertannal

• az ISO 9126-ban

• az ISO 9001:2000-ben

• a CMM-ben, SPICE-ban

• a PSP-ben és TSP-ben

• mérés és TQM filozófia

• mérés az EFQM-ben

• mérés a CMMI-ben


Mérés az ISO 9126-ban

✔A legjobban kidolgozott, termékre vonatkozómin ségi attribútum- és metrika-gyjtemény

✔(Boehm, McCall modellek)

✔Nem ad tanácsot arra nézve, hogy mikormilyen metrikákat válasszunk, hogyantörténjék az alkalmazandó metrikákkiválasztása

✔GQM-mel kombinálva jól használható


Mérés az ISO 9001:2000-ben✔ A szabvány 8. fejezete errl szól

✔ Alapelv a tényeken alapuló döntéshozatal,folyamatos javítás

✔ Túl általános mind a mérési módszertan, mind azalkalmazandó metrikák területén

0pUpV��HOHP]pV�pV�IHMOHV]WpV 8. Általános rész Figyelemmel kísérés és mérés A vev �PHJHOpJHGHWWVpJH

8.1.8.2.8.2.1.

Bels �DXGLW 8.2.2. A folyamatok figyelemmel kísérése és

mérése A termék figyelemmel kísérése és mérése

8.2.3.8.2.4.

A nem megfelel�WHUPpN�NH]HOpVH 8.3. Az adatok elemzése 8.4. Fejlesztés 8.5. Folyamatos fejlesztés 8.5.1. Helyesbít�WHYpNHQ\VpJ Megel ] �WHYpNHQ\VpJ

8.5.2.8.5.3.


2002 / 2003 13


Mérés a CMM-ben✔ Az érettségi szinteket

jellemz kulcsfolyamatokegyik közös jellemzjekéntjelenik meg

✔ Célja: olyan gyakorlat jelenléte,amely szükséges a folyamatállapotának megítéléséhez. Azehhez a tevékenységhez tartozómérései eredményeket folyamatosjavításra kell használni

0DWXULW\�/HYHOV

.H\�3UDFWLFHV

contain

contain

.H\�3URFHVV�$UHDV

,PSOHPHQWDWLRQ�RU�,QVWLWXWLRQDOL]DWLRQ

*RDOV

3URFHVV��&DSDELOLW\

describe

achieve

indicate

organized by

&RPPRQ�)HDWXUHV

address

,QIUDVWUXFWXUH�RU�$FWLYLWLHV


Mérés a CMM-ben

✔A 4. szinten a fjellemz az, hogy afolyamatokat mérik

✔Az 5. szinten a mérésekeredményétfolyamatosanvisszacsatolják,javításra használják

CMM érettségi szintek:1.: Kezdeti / kaotikus (initial)2.: Ismételhet (repetable)3.: Meghatározott (defined)4.: Menedzselt (managed)5.: Optimalizált (optimising)


Mérés a CMM-ben

✔Kétségtelenül jelen van, de a CMM nemmérési módszertan. Nem ad konkrét mérésieljárást, sem metrikákat.

✔Helytelen úgy értelmezni az elírásokat,hogy a méréseket csak a 4. szinten kellelkezdeni

✔Már legalacsonyabb szinten is kell mérni

✔A szervezet érettségének növekedésévelpontosabban meghatározhatók a mérés céljai


2002 / 2003 14


Mérés a SPICE-ban

✔ Az egyéni folyamatokhoz tartozó eljárásokat végrehajtják-e(legalább informálisan)?

✔ A folyamatot megfelelen tervezték-e?

✔ Követik-e a tervet?

✔ Ellen rzik-e a végrehajtást?

✔ Követik-e a végrehajtást és hoznak-e korrekciósintézkedéseket?

✔ Szabványosított-e a folyamat?

✔ Értik-e a folyamatot mennyiségileg is?

✔ Folyamatosan javítják-e a folyamatot?


Mérés a SPICE-ban

aremappedagainst

ORG

&DWHJRU\

3URFHVV

CUS ENG MANSUP

Life Cycle Processes

3URFHVV�'LPHQVLRQ &DSDELOLW\�'LPHQVLRQ

/HYHO��1DPH��$WWULEXWHV��2SWLPL]LQJ��SURFHVV

Process change attribute

��3UHGLFWDEOH��3URFHVVProcess measurement attribute

��(VWDEOLVKHG�3URFHVVProcess definition attribute

��0DQDJHG�3URFHVVPerformance management attribute

��3HUIRUPHG�3URFHVV

��,QFRPSOHWH�3URFHVVProcess perfomance attribute

Work Product management attribute

Process resource attribute

Process control attribute

Continuous improvement attribute

•4. szint folyamat attribútuma•Nem különálló tevékenység• Konkrét mérési módszertan ésmetrikák tekintetében túl általános

Folyamat érettségi szintek

0. Nem létez1. Végrehajtott

2. Menedzselt3. Meghatározott

4. Jósolható


Mérés a PSP-ben és TSP-ben✔ Alapfolyamat, amely segít a munkafolyamatokat

megérteni✔ Az egyéni fejlesztési folyamat (PSP)

– (J\pQL�PpUpV

– Egyéni tervezés

– Egyéni minség

– Kalibrálás

✔ PSO0: Egyéni mérés✔ A fejleszt k megtanulják a PSP szkripteket és formokat alkalmazni, a folyamat

id tartamának és a hibák számának mérésével / feljegyzésével . A fázisoktevékenységeit minden esetben tervezik, végrehajtják és elemzik.

✔ PSP01: kódolási szabványok, méret mérése, folyamat javítására vonatkozójavaslatok


2002 / 2003 15


Mérés a PSP-ben és TSP-ben

✔ A TSP fázisai:– Követelmények– Tervezés– Implementálás– Tesztelés

✔ Indulás után a TSP pontos mechanizmust nyújt a csapattevékenységének követésére, vezérlésére

✔ A PSP pontosabb, a TSP általánosabb mérési elveket kínál

✔ A PSP konkrét, mérend attribútumokat azonosít, de ezekköre igen szk


Mérés és TQM filozófia

✔ Szemléletmód✔ Alapvet összetevk:

– alkalmazottak bevonása és képzése– problémamegoldó csapatok– statisztikai módszerek– hosszú távú célok, „hosszú távú gondolkodás”– nem az emberek „hibásak”, hanem a rendszer rossz


Mérés az EFQM-ben

✔A modell középpontjában a RADAR elnevezéstvisel logika áll– Result (eredmény)

– Approach (megközelítés)

– Deployment (fejldés, felfejl dés)

– Assessment and Review (értékelés, szemlézés)

✔ A mérés / folyamatos javítás szükségessége része amodellnek, de a modell nem kínál konkrét mérésimódszertant, sem metrikákat


2002 / 2003 16


Mérés a CMMI-ben

✔ Nagyon hangsúlyosan jelenik meg, mind a lépcss,mind a folytonos megjelenítésben

✔ Mérés és elemzés: a 2. érettségi szinthez társítotttámogató folyamat– Folytonos megközelítésben: támogató folyamat, amely minden más

folyamatot segít megérteni és javítani. A mérési / javítási igényeketminden folyamatra meg kell határozni

– Lépcs s megközelítésben: már a szervezettség legalacsonyabb fokán

is jelen kell lennie . El bb a projektmenedzsment folyamatok közékell beilleszteni, mint a követés, vezérlés eszközét, azután szervezetiszint mérési programot kell létrehozni.


Mérés a CMMI-ben

✔Folytonos Lépcs s:

• Process Management (3)• Organizational Process Focus 3• Organizational Process Definition 3• Organizational Training 3

• Organizational Process Performance 4• Organizational Innovation and Deployment 5

• 3URMHFW�0DQDJHPHQW� ��• Project Planning 2• Project Monitoring and Control 2• Supplier Agreement Management 2

• Integrated Project Management 3• Risk Management 3• Integrated Teaming -• Quantitative Project Management 4


✔Folytonos Lépcs s:• (QJLQHHULQJ��IHMOHV]WpV� ��

• Requirements Development (3)• Requirements Management 2• Technical Solution 3• Product Integration 3• Verification 3• Validation 3

✔ Support• Configuration Management 2

• Process and Product Quality Assurance 2

• Measurement and Analysis (4-5)

• Organizational Environment for Integration -

• Decision Analysis and Resolution -

• Causal Analysis and Resolution 5

Mérés a CMMI-ben


2002 / 2003 17


Mérés a CMMI-ben

✔ Támogató tevékenységként (is) konzisztens a GQMelveivel. Minél magasabb az érettségi szint, annálpontosabban lehet a célt meghatározni, és annál jobbanm ködik a mérés- elemzés-javítás ciklus

✔ A mérési és elemzési tevékenységeket a projektekbenkezdjük el. Tevékenységek:– célok tervezése és becslése

– az aktuális állapot követése a tervhez és célhoz viszonyítva

– folyamatok hiányosságainak felderítése és javítása

– a mérések , javítások a folyamatok részévé válnak


Mérés a CMMI-ben

✔Minden folyamat esetében szükséges:– a mérési és elemzési tevékenységek beemelése a folyamatba

• mérés céljainak meghatározása, metrikák meghatározása, adatgyjtési és-tárolási eljárások meghatározása, elemzési eljárások meghatározása

– a mérési eredmények összegyjtése, elemzése, hiányosságokfelderítése, javítási javaslatok, folyamat javítása

• mérési adatok összegyjtése, elemzése, mérési adatok tárolása, méréseredményeinek kommunikálása

– a mért / menedzselt folyamat kiterjesztése, bevezetése• szervezeti politika, a mérési folyamat tervezése, szükséges erforrások

biztosítása a mérésekhez, felelsségek hozzárendelése, képzés,konfigurációk nyilvántartása, érdekelt felek felderítése, informálása, amérés folyamatának követése, vezérlése, a mérési folyamat értékelése afels vezetéssel


Adatgy jtési mechanizmusok

✔Formok

✔Számítógépes eszközök

✔Interjúk


2002 / 2003 18


Mérési módszerek, eszközök

✔B séges kínálat

✔Választani kell

✔ Saját konkrét mérési folyamatát mindencégnek ki kell dolgoznia!


A szoftvermérés költsége✔ Nem ingyen van, de a szervezethez lehet igazítani

✔ Vannak nyilvánvaló és rejtett elemek

✔ A mérési program beindítása drágább lehet a fenntartásánál

✔ „Kicsiben” kezdjük!

✔ A mérési költségek eredete– a szoftverprojektek adatszolgáltatásból származó többletköltségei

– a mérések elvégzéséhez nyújtott mszaki támogatás költsége

– a mért adatok elemzésének, „csomagolásának” költsége

✔ A mérési program költségei függnek:– a szervezet méretétl

– a mérési programba bevont projektek számától

– a mérési program kiterjedésétl (életciklus-elemek, metrikák száma stb.)


A szoftvermérés költsége✔NASA adatai a mérések költségeirl

– 17 év tapasztalatai

– 100-5000 fs szervezetek

– egyszerre aktív projektek száma, amelyek résztvettek a mérési tervben, szervezetenként: 5-6-tól,20-ig

– a mért projektek mérete: 5 KSLOC-tól több, mint1mil SLOC-ig

– egy projektben a mérésekbl adódótöbbletköltség max. 1-2 %


2002 / 2003 19


A szoftvermérés költsége

12345

10

15

20

A t

elje

s sz

erve

zeti

léts

zám

%-a

AdatforrásM szaki támogatás Adatelemzés, „csomagolás”Tervezési és karbant. projekt

Közepes szervezetek(kb. 100-500 ember)

nagy szervezetek(kb. 500-5000 ember)

•Formok kitöltése•Adatszolgáltatás

•Eredmények archiválása•adatbázis karbantartása•QA

•Mérési modellek / folyamatok fejlesztése•Eredmények elemzése•Képzés

•kísérletek elvégzése

<2 % <1 % 3-7 % 6-8 f<2 %

6-15 % 10-15 f<3 %

(Software Measurement Guidebook, NASA, Software Engineering Laboratories, NASA-GB-001-94)


A mérések költsége (példa)


Mir l volt szó?

PMfolyamat

Term

ék

Definíció

Min ségi attribútum

Mér szám

Mszaki

folyamat

Documents

Szoftver min ség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM13-GQM.pdf · válaszolni kell ahhoz, hogy megértsük, a célt elértük-e – annak eldöntése, hogy mit kell mérni