Szoftver minőség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM4-CMM.pdf · Szoftver minőség és menedzsment -4. Folyamatjavítás. Lécsős modellek. 2003 / 2004 1 Szoftver minőség

Szoftver minőség és menedzsment -4. Folyamatjavítás. Lécsős modellek.

2003 / 2004 1

Szoftver minőség és menedzsment

4. A szoftverminőség folyamat alapú megközelítése.

A CMM modell és a Bootstrap.

Dr. Balla Katalin

Dr. Balla Katalin Szoftver minőség és menedzsment -4.

2

Tartalom

Modellezés, folyamatjavításÉrettségi modellek– A lépcsős modellek– A CMM modell– CMM felmérés– A Bootstrap módszer


3

A valós élet modellezéseEmberekIrányítási folyamatokMűszaki folyamatokSzokások, konvenciók….

WBS

Általános projekt modellA projekt irányítási modellje

A projekt típus-modellje

A projektelőkészítése

A projektindítása

A projekt

végrehajtása

A projektzárása


2003 / 2004 2


4

Folyamatok

– Folyamat: amit az emberek csinálnak. Közben eljárásokat, módszereket, eszközöket használnak.

– Folyamat:• Bizonyos céllal elvégzett lépések / tevékenységek

sorozata. (IEEE-STD-610).

– Szoftverfolyamat:• Azoknak a tevékenységeknek, módszereknek,

eljárásoknak és transzformációknak az összessége, amelyeket az emberek szoftver fejlesztésének vagy karbantartásának céljából végeznek. [Paulk].


5

FolyamatjavításÖrökös gondok a folyamatokkal:– idő– költség– specifikáció– minőség…

Standish Group- CHAOS Study– Évi 250 milliárd USD-t költenek IT-re, átlagban 175000 projektet

indítanak


6

FolyamatjavításStandish Group- CHAOS Study– Évi 250 milliárd USD-t költenek IT-re, átlagban 175000 projektet

indítanakMéret Leállított pr. „gyanús” Sikeres Működőképesség

nagy 30% 62% 8% 42%közepes 37% 47% 16% 65%kicsi 22% 50% 28% 74%

nagy: > 500 mil. USDközepes 200mil- 500 mil USDkicsi < 200 mil USD

(forrás: ESI-SW-CMM, Training material, 2000)


2003 / 2004 3


7

FolyamatjavításAz átadott termékekben levő hibák 15%-a bent marad,

amikor a terméket a felhasználónak átadjákSok cég idejének és pénzének 30-44 %-át a már kész

szoftver újraírására használja

Folyamatjavításra szükség van!!!• Csökken az ügyfélnek átadott hibák száma (5% marad)• A projektek átfutási ideje 71%-kal csökkenhet• A termelékenység 222%-kal nőhet (naponta elkészült forrássorban v.

funkciópontban mérve)

!


8

Igen, javítsunk, fejlesszünk!De ki fejlesszen?

A jó folyamatok nem válnak automatikusan gyakorlattá. Ezért szükséges, hogy szoftverfolyamat fejlesztést egy szakértőkből álló csoport végezze (szoftverfolyamat-fejlesztési csoport, SEPG), ajánlott létszáma a szervezet létszámának 1.5-3 %-a + időszakosan résztvevő szakemberek– Az SEPG tevékenységének megoszlása ([P. Jalote]):

• 22%: folyamat irányítás (új folyamatok definiálása, működő folyamatok figyelése, mérése és fejlesztése...)

• 28%: folyamat bevezetés, működtetés• 12%: oktatás• 8%: auditok• 30%: különböző egyéb feladatok (dokumentáció karbantartása, képzésen

részvétel, új eszközök és módszerek megismerése, kipróbálása...)

A szoftverfolyamat-fejlesztés nem azonos a minőségbiztosítással!


9

Igen, fejlesszük! De mit és hogyan?

A szoftverfolyamatot, a termék minőségét...Összetevőit, jellemzőit megértve, definiálva...– A szoftvergyártással kapcsolatos modellek a szoftver

minősége körül „forognak”, amely sok mindentől függ, pl:

– A minőséget értékelő személyétől / nézőpontjától / értékrendjétől– A szoftvergyártás típusától– Az életciklustól– Rendszer típusától / szoftver alkalmazási területétől– Üzletpolitikától– …

– ...de mindig ugyanazon objektumok bevonásával!


2003 / 2004 4


10

Objektumok és folyamatfejlesztés

Folyamat

Termék

Erőforrás

Definíció

Minőségiattribútum

Mérőszám

Objektumok

Jellemzők

ISO 9001CMMSPICECMMI

ISO 15504TSP, PSP


11

Folyamatjavítás

Jól kell csinálni !Tudni kell csinálni !

Mások tapasztalatából kell tanulni!

Ismert, sokszor kipróbált modellek segíthetnek!


12

Modell alapú szoftverfolyamat fejlesztésA szoftvergyártás folyamatának bizonyos elemeire koncentrál, fejlődési irányt mutat, sok korábbi tapasztalatot használ fel...


2003 / 2004 5


13

Érettségi modellekElvek: Crosby 1979, Juran 1988, Deming 1986, Humphrey 1989Már az 1980-as években rájöttek, hogy vannak

„érettebb” és „kevésbé érett” folyamatok.Bizonyos kritériumok alapján vizsgálják a szervezetet és / vagy annak bizonyos vonatkozásaitA vizsgált területek jellemzői szerint a szervezetet / vizsgált folyamatot bizonyos érettségi szintre sorolják


14

ÉrettségA szoftver folyamat érettsége:

• Annak mértéke, hogy egy folyamat mennyire pontosan meghatározott, vezérelt, mért, ellenőrzött és hatékony. [Paulk].

A szoftverfolyamat érettsége megmutat(hat)ja, hogy a folyamat képes-e jó minőségű terméket előállítani, a költség- és időkeret betartásával. Az érett szoftver folyamat:

• Meghatározott (definiált), vezérelt, mért, ellenőrzött, hatékony és javulásra képes.


15

Érettségi modellek

Meghatározott struktúrájuk van, a szoftverfejlesztés bizonyos elemeire koncentrálnakBizonyos ellenőrzési modellek alakultak ki,

amelyek auditálhatóságot biztosítanak (pl. Bootstrap)


2003 / 2004 6


16

Érettségi modellekLépcsős modellek (staged models)– a teljes szervezetet vizsgálják– úgy tekintik, hogy egyetlen folyamat van a szervezetben, amelynek

bizonyos jellemzői vannak– foglalkoznak: vezetési és műszaki folyamatokkal, az alkalmazott

technológiával, magával a szervezettel…

Folytonos modellek (continuous models)– az egyes folyamatokra (és nem a teljes szervezetre) állapítanak meg

érettségi szinteket bizonyos jellemzők alapján– a modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét

szeretné vizsgálni

„Kombinált”, integrált modellek– ötvözik a kétféle modellt, a bizonyítottan hasznos elemeket kiválasztva


17

Lépcsős modellekA szervezet egészét vizsgálják

Úgy tekintik, hogy a szervezetben „egyetlen” folyamat van, a „szervezeti szintű folyamat”, ez maga a szoftverfejlesztési folyamat, amely magába foglalja: – a szoftverfejlesztésben részt vevő embereket– a szoftverfejlesztésben alkalmazott technológiát– a szoftverfejlesztésben alkalmazott módszereket– a szoftverfejlesztésben alkalmazott eszközöket– ...


18

Lépcsős modellek

A szervezeti szintű folyamatnak bizonyos jellemzői / összetevői vannakA jellemzők alapján dönthető el, hogy a

szervezet / a folyamat milyen érettségi szinten áll– A különböző érettségi szintekhez jól

meghatározott jellemzők tartoznak


2003 / 2004 7


19

– 1982-ben az U.S. Department of Defense (DoD) foglalkozni kezdett a szoftverproblémáival.

– Eredmény: létrejött a Software EngineeringInstitute (SEI) a Carnegie Mellon Egyetemen, 1984 decemberében.

– 1986-tól projekt indult szoftverfolyamat-javítás témában.

Lépcsős modellek: a CMM


20

Lépcsős modellek: a CMM

1989-1991- ben dolgozták kiWatts Humphrey vezetésével

http://www.sei.cmu.edu/about/about.html


21

A CMM modell

Első változata: – a Honvédelmi Minisztérium támogatására készült – kérdőív, 110 kérdéssel– lehetővé tette a szoftvercégek elhelyezését egy 5-

ös skálán


2003 / 2004 8


22

A CMM modell jelenlegi szerkezete

Maturity Levels

Key Practices

contain

contain

Key Process Areas

Implementation or Institutionalization

Goals

Process Capability

describe

achieve

indicate

organized by

Common Features

address

Infrastructure or Activities

Components Rated:

Key Process AreasGoals

Rating Basis:

Evidence of weaknessesEvidence of strengthsEvidence of alternative practicesEvidence of non-applicable practices


23

A CMM modell jelenlegi szerkezete

Érettségi szint

Kulcsfolyamattartalmazmeghatároz

Folyamat-képesség

Célok

elérÁltalános jellemvonások

tartalmaz

megcé loz

Bevezetés ésintézményesítés

Infrastruktúra vagytevékenységek

leír

Alapgyakorlatok

tartalmaz


24

A CMM modell

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


2003 / 2004 9


25A projektek tipikusan átlépik az idő- és költségkeretet1

A projekt tervezés és vezetés megfelelő

Szoftver konfigurációkezelésSzoftver minőségbiztosításSzoftver alvállalkozók kezeléseSzoftver projekt követés & felügyeletSzoftver projekt tervezésKövetelmények menedzsmentje

Hatékony módszerek léte2

A termékminőség lényeges javulása

Kölcsönös szemlékCsoportok közötti koordinációSzoftver termék fejlesztésIntegrált szoftver menedzsmentKépzési tervSzervezeti szintű folyamatok meghatározásaOdafigyelés a folyamatokra

A leghatékonyabb módszerek dokumentáltak és minden projektben használtak

3

A termelékenység és a ciklusidő javulása

Szoftver minőség menedzsment Mennyiségi folyamat menedzsment

A hatékonyság, hatásosság, termelékenység és minőség mennyiségi biztosítása

4

Termelékenység és ciklus időjavítása

Folyamat változás menedzsmentTechnológia változás menedzsmentHibamegelőzés

Javításra felhasznált mennyiségi visszacsatolás

5

kockázat

ellenőrzés


26

A CMM felmérésManaged (4)

Software quality managementQuantitative process management

Defined (3)Peer reviewsIntergroup coordinationSoftware product engineeringIntegrated software managementTraining programOrganisation process definitionOrganisation process focus

Initial (1)

Repeatable (2)Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking oversightSoftware project planningRequirements management

Optimising (5)Process change managementTechnology chng managementDefect prevention


27

A CMM kulcsfolyamatai

Menedzselt (4)Szoftverminőség-menedzsmentFolyamatmérés- és elemzés

Optimalizáló (5)Folyamatváltozás-menedzsmentTechnológiai változásmenedzsmentHibamegelőzés

Meghatározott (3)Egyenrangú szemlékCsoportok közötti koordinációSzoftvertermék-fejlesztésIntegrált szoftvermenedzsmentKépzési programSzervezeti szintű folyamatmeghatározásFolyamatközpontúság

Kezdeti (1)

Ismételhető (2)Szoftverkonfiguráció-menedzsmentSzoftverminőség-biztosításSzoftver alvállalkozók kezeléseSzoftverprojekt-követés és vezérlésSzoftverprojekt-tervezésKövetelmény-menedzsment


2003 / 2004 10


28

CMM felmérés

Munkamódszer– Kérdőívek– Megbeszélések– Jelentés– Regisztráció adatbázisbaFelmérés eredménye: egy egész szám az 1-5

skálán, indoklással. A szervezet egészére vonatkozó érettséget mutat.


29

A CMM érettségi szintek jellemzői

1. Kezdeti szint:– túlvállalás– a tervek és módszerek felrúgása– a termék esetleg működik, de a költség- és

időkeretet túllépik– a siker az egyes személyek hozzáértésétől és

„hősiességétől” függ– nem megismételhető


30

A CMM érettségi szintek jellemzői2. Ismételhető szint:– egyes projektek folyamatokat alkalmaznak– a folyamatok projektenként változhatnak– szervezeti szintű „politika”, projektvezetés– A projektben:

• reális vállalások• a projekt tervezik és követik (költség, idő és funkcionalitás

szempontjából)• vannak projektre vonatkozó szabványok, és követik őket• a termékeket (work products) ellenőrzik• a beszállítókkal jól működő kapcsolat van


2003 / 2004 11


31


3. Meghatározott szint:

A vállalat szabványos

szoftver folyamata

Szw projekt

A projektszabványos

szw folyamata


32


4. Menedzselt szint– Mennyiségi folyamat menedzsment– Szoftverminőség menedzsment

– Statisztikai módszerek alkalmazása a folyamatokban

– A folyamatváltozások vizsgálat, a sajátos okokra koncentrálva


33


5. Optimalizált szint:– hibamegelőzés– technológia változás - menedzsment– folyamat változás - menedzsment

– A gyenge teljesítmény valódi okainak meghatározása és megszüntetése

– A szoftverfolyamat folytonos javítása


2003 / 2004 12


34

A CMM modell

A világon 2150 szoftvercéget mértek fel 1997 és 2003 között, 11823 projektet, ebből :

2001-ben: 2002-ben: 2003:ban:1-es szinten: 27.1 % 19.3 % 13.3%2-es szinten: 39.1 % 43.2 % 43.5%3-as szinten: 23.4 % 23.4% 25.6%4-es szinten: 5.4 % 7.3% 8.5%5-ös szinten: 4.8 % 6.8% 9.2%

Forrás: http://www.sei.cmu.edu/sema/pdf/2003sepSwCMM.pdf


35

A CMM modell

A világon 1124 szoftvercéget mértek fel 1997 és 2002 között, (2001 aug.-2002-aug. 106 céget), ebből :

2001-ben 2002-ben:1-es szinten: 27.1 % 19.3 %2-es szinten: 39.1 % 43.2 %3-as szinten: 23.4 % 23.4%4-es szinten: 5.4 % 7.3%5-ös szinten: 4.8 % 6.8%

Forrás: http://www.sei.cmu.edu/sema/pdf/2002aug.pdf


36

A CMM modell alkalmazásának tapasztalatai


2003 / 2004 13


37



38



39



2003 / 2004 14


40



41



42



2003 / 2004 15


43



44



45



2003 / 2004 16


46



47



48

CMM vagy ISO 9001?

0 % 1 0 % 2 0 % 3 0 % 4 0 % 5 0 % 6 0 % 7 0 % 8 0 % 9 0 % 1 0 0 %

R e q u ir e m e n t s M a n a g e m e n t

S o f t w a r e P r o je c t P la n n in g

P r o je c t T r a c k in g & O v e r s ig h t

S o f t w a r e S u b c o n t r a c t M a n a g e m e n t

S o f t w a r e Q u a li t y A s s u r a n c e

S o f t w a r e C o n f ig u r a t io n M a n a g e m e n t

O r g a n is a t io n P r o c e s s F o c u s

O r g a n is a t io n P r o c e s s D e f in i t io n

T r a in in g P r o g r a m

In t e g r a t e d S o f t w a r e M a n a g e m e n t

S o f t w a r e P r o d u c t E n g in e e r in g

In t e r g r o u p C o o r d in a t io n

P e e r R e v ie w s

Q u a n t it a t iv e P r o c e s s M a n a g e m e n t

S o f t w a r e Q u a li t y M a n a g e m e n t

D e f e c t P r e v e n t io n

T e c h n o lo g y C h a n g e M a n a g e m e n t

P r o c e s s C h a n g e M a n a g e m e n t

Directly addressed by ISO 9001May be addressed by ISO 9001depending on interpretationNot addressed by ISO 9001

Source: CMU/SEI-94-TR-12“A Comparison of ISO 9001 and the Capability Maturity Model for Software”

Level 3

Level 2

Level 4

Level 5

KEY

PRO

CE

SS A

REA

S O

F TH

E C

MM

% of CMM Key Practices addressed by ISO 9001


2003 / 2004 17


49

Peer ReviewsIntergroup CoordinationSoftware Product EngineeringIntegrated Software ManagementTraining ProgramOrganisation Process DefinitionOrganisation Process Focus

Level 3 - Defined

Software configuration managementSoftware quality assuranceSoftware subcontract managementSoftware project tracking & oversightSoftware project planningRequirements management

Level 2 - Repeatable

Software Quality ManagementQuantitative Process Management

Level 4 - Managed

Process Change ManagementTechnology Change ManagementPeer Reviews

Level 5 - Optimising

Fully SatisfiedPartially SatisfiedNot SatisfiedNot ApplicableNot Rated

NAX

“ISO 9001 Best Case KPA Profile”(ESI)

CMM vagy ISO 9001?


50

CMM vagy ISO 9001?

Egy CMM-nek megfelelőrendszer alapja - általában -

egy ISO 9001-nek megfelelő rendszer !


51

Szoftverminőség-biztosítás a CMM 2-es szintenEgy jól meghatározott és következetesen végrehajtott ISO 9001:2000-nek megfelelő minőségirányítás

Projekt fázisokhoz igazodó SQA szervezet és auditok! – Projekt minőségügyi megbízottak / QA szerepkör: a projekttől

független– Minőségbiztosítási terv a projektben– Rendszeres SQA auditok a projektben (minden termék szemléje!)

A többi CMM 2-es kulcsfolyamat rendszeres SQA szemléje (PPL, PTO, RM, SCM, SSM)


2003 / 2004 18


52

A Bootstrap módszerA CMM kiterjesztése / változataAz EU ESPRIT projektje keretében dolgozták ki, 1991.

szept. és 1993 febr. között1993-tól az Európai Bootstrap Intézet forgalmazza

(http://www.bootstrap.org/)

Európai megközelítést ajánl a szoftverfejlesztési folyamat javításáraA CMM-en kívül az ISO 9001:1994 és ISO 9000-3 szabványokat is felhasználjaAz alkalmazott érettségi modell megegyezik a CMM érettségi modellel


53

A Bootstrap módszerFelépítése:– A szoftverfejlesztési egység (SPU) és a projektek

számára szükséges területeket, folyamatokat és tevékenységeket határoz meg

– Auditálja: az SPU-t és a projekteket, 3 vonatkozásban:

• szervezet• módszerek• technológia

A szoftver fejlesztési folyamat szervezettségét tekinti elsődlegesnek, de a módszertannal és a technológiával is foglalkozik.


54

A Bootstrap folyamat felépítéseBootstrap Process Architecture

Software Producing Unit Software Project

Organization Methodology Technology

•Quality System•Resource Management

•Technology Innovation•Techn. for Life Cycle Functions•Techn. for Life Cycle• Independent Functions•Tool Integration

Life Cycle IndependentFunctions

Life CycleFunctions

Process RelatedFunctions

•Configurat. & Change man.•Risk Management•Project Management•Quality Management•Subcontractor Management

•Development Model•Req., Analysis &Definition•Architecture Design•Detailed Design & Impl.•Testing•Operation&Maintenance

•Process Description•Process Measurement•Process Control


2003 / 2004 19


55

•Felkészít az ISO 9000 szerinti minősítésre•Olcsóbb az ISO 9000 felmérésnél•Útmutatást ad a magasabb szint elérésére•Nemcsak egész értékekben kifejezhető érettségi szinteket mutat (pl. lehet 2.75)•A különböző attribútumok érettségi szintjét külön is megmutatja

A Bootstrap alkalmazásának előnyei


56

Példa egy Bootstrap által adott profilra


57

Miről volt szó

Termék

Folyamat

Erőforrás

Definíció

Minőségiattribútum

Mérőszám


2003 / 2004 20


58

További felhasznált irodalom

Watts S. Humphrey:”Managing Technical People: Innovation Teamwork, and the Software Process”, Addison-Wesley-Longman”, 1997

M.C. Paulk, B. Curtis, M.B. Chrisis, “Capability Maturity Model for software, version 1.1”, Software Engineering Institute Technical Report, 1993

J. Paulson, “Introduction to Software Process Management:, University of Calgary Technical Report, 1998

Watts S. Humphrey:”Introduction to Software Process Improvement” June 1992

Watts S. Humphrey:”A Discipline for Software Engineering”, Addison-Wesley, 1995

Mohácsi János: Egyetemi jegyzetek (51CMM.PPT)

Documents

Szoftver minőség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM4-CMM.pdf · Szoftver minőség és menedzsment -4. Folyamatjavítás. Lécsős modellek. 2003 / 2004 1 Szoftver minőség