Szoftver minőség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM6-PSP.pdf · – Egyéni tervezés – Egyéni minőség – Kalibrálás 6 + 1 fázis •1. planning •2. designing

Szoftver minőség és menedzsment -6. Egyéb érettségi modellek

2003 / 2004 1

Szoftver minőség és menedzsment

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

PSP, TSP, egyéb megközelítések. Integrált modellek.

Dr. Balla Katalin

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

2

TartalomEgyéb folyamatjavítási modellek– a PSP– a TSP

A TQM filozófia– Az EFQM modell

Kombinált érettségi modellek– A CMMI – EFQM / SPICE

A folyamatjavítási modellek összehasonlítása


3

Egyéb folyamatjavítási modellekPersonal Software Process (PSP)– Watts Huphrey, 1995– A CMM elvein alapul– A szoftverfejlesztőket egyénként segíti

teljesítményük javításában, a fegyelmezett munkavégzés bevezetésében

• A szoftverfejlesztés költségének 70%-át a személyi költségek teszik ki, tehát az egyének képessége, tapasztalata, munkamódszere lényegesen befolyásolja a fejlesztési folyamat minőségét

(Forrás:Watts Humphrey: 1. A Discipline for software engineering. Addison-Wesley, 19952. Using a Defined and Measured Personal Software Process. In: IEEE Software, May 1996, pp. 77-873. What is your life depended on software? EuroSPI 2000, Copenhaga, 7. November 2000.)

http://www.sei.cmu.edu/tsp/psp.html)


2003 / 2004 2


4

A PSPAz egyéni fejlesztési folyamat

– Egyéni mérés– Egyéni tervezés– Egyéni minőség– Kalibrálás

6 + 1 fázis• 1. planning• 2. designing• 3. coding• 4. compiling• 5. testing• 6. post morten

+1. A programozó munkájának értékelése - számos formtámogatásával Oktatás


5

A PSPEgyénre szabott tudományág, magasabb szintű szoftverfejlesztéshezA szoftverfejlesztési folyamat bármely szakaszában alkalmazhatóA módszer biztosítja:– a szoftverfejlesztőknek szükséges elveket és módszereket, amelyekkel

egyéni teljesítményüket javíthatják– az elvek módszerek alkalmazásához szükséges tudást

A módszer leírja: • az egyéni folyamat definiálását• a fejlesztő saját munkájának becslését, tervezését, követését• hibamentes termékek fejlesztését


6

A PSPMegtanítja a szoftverfejlesztőket

– idő és hiba - feljegyzésre

– szoftvertermék méretének mérésére

– szoftvertermék méretének becslésére

– statisztikai alapú becslések végzésére

– időbecslésre és projekt ütemezésre

– folyamatmenedzsmentre

– tervezési- és kódszemlézésre

– minőségbiztosításra, a hibák számának csökkentésével

– tervezési jelölésekre, technikákra, ellenőrzésre

– a PSP átszabására, nagyobb projektek esetében

– a PSP továbbfejlesztésére


2003 / 2004 3


7

A PSP lépéseiHumphrey, Watts.S.: Using a Defined and Measured Personal Software Process. In: IEEE Software, May 1996, pp. 77-87

PSO0: Personal MeasurementEngineers learn how to apply the PSP forms and scripts to their personal work; they do this by measuring / recording development time and defects– planning– development– post mortem

PSP01: coding standards, size measurement, process improvement proposal (PIP) --> they record their proposals here


8

A PSP lépései

PSP1 : Personal planningIntroduces the PROBE method: is used to estimate the sizes and development times for new programs based on their personal data (PROBE --> linear regression to calculate estimating parameters, and it generates prediction intervals to indicate size and estimate quality.)


9

A PSP lépései

PSP2 : Personal QualityIntroduces defect management; with defect data engineers construct and use checklist for design and code reviewsFrom their own data they see how checklist can help them.By measuring the time tasks take and the nr. of defects they inject and remove in each process phase, engineers learn to evaluate and improve their personal performance


2003 / 2004 4


10

A PSP lépései

PSP3: Scaling up (cyclic development)At this level engineers also explore design-verification methods as well as process-definition principles and methods


11

A PSPKimutatható javulást eredményez a szoftverfejlesztési munkában– 10-nél több gyakorlat, amelyekben a

szoftverfejlesztők megtanulják a módszereket alkalmazni

– megtanulják saját munkájukat tervezni és követni– Több időt fordítanak tervezésre– A fordítási és tesztelési hibák száma tipikusan 5-

10-szer lesz kevesebb– Nő a termelékenység


12

A CMM és a PSPA CMM – a szervezetre vonatkozik– keret, amelyben jó minőségű

szoftverfejlesztés végezhető– keret a folyamatok javítására– feltételezi, hogy a fejlesztők

hatékony módszereket ismernek és alkalmaznak, részt vesznek a folyamatok javításában

A PSP– az egyénre vonatkozik– feltételezi, hogy van egy rendezett

és vezetett keret, amelyben dolgozni kell

– megvan az infrastruktúra a megfelelő szoftverfejlesztési folyamatok támogatására


2003 / 2004 5


13

Egyéb folyamatjavítási modellek

Team Software Process1998 után, Watts Humphrey, SEICsapatok munkájára vonatkozikKapcsolódik a CMM-hez és PSP-hez

(http://www.sei.cmu.edu/tsp/tsp.html)


14

A TSPAhhoz, hogy a fejlesztők hatékonyan alkalmazzák a PSP-t, szükséges – saját munkamódszerük és a csapat munkamódszerének

összekapcsolása– irányítást és támogatást kapniuk a fegyelmezett

munkavégzésben

Szükség van „magas szintű” csapatokra, amelyek– folyamatosan jó minőségű szoftvert gyártanak– betartják a határidőket– nem lépik túl a költségkeretet– munkájukat folyamatosan javítják


15

A TSP céljai

Önálló, sajátmagukat vezető csapatokat kialakítani, amelyek tervezik és követik saját munkájukat. Megmutatni a vezetőknek, hogyan kell csapataikat irányítani és motiválni, munkájukat segíteniGyorsítani a szoftverfejlesztési folyamat javulását, a CMM 5 szintre jellemző magatartást természetessé téveMagas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításbanTámogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását.


2003 / 2004 6


16

A TSP céljai

– Míg a CMM és a PSP a képességeket és a szervezet érettségét fejleszti,

a TSP termékeket állít elő.A TSP csapatok

• sajátmagukat vezérlik• tervezik saját munkájukat• teljesítményüket követik és jelentik• jól meghatározott céljaik vannak• saját folyamataik gazdái• részt vesznek a tervezésben és döntéshozásban


17

A TSP fázisai

KövetelményekTervezésImplementálásTesztelés– Minden fázis indítással vagy

újraindítással kezdődik.


18

A TSP jellemzőiA TSP projektek bármely fázisban elkezdődhetnek vagy befejeződhetnek.A TSP fázisai egymásra tevődhetnek.A TSP bármilyen folyamatstruktúra használatát lehetővé tesziA TSP a csapatmunkát tanítja meg. 4 napos indulási fázis van, amelyben meg kell érteni a feladatot, ki kell tűzni a célokat, meg kell határozni a csapatban a szerepeket, kockázatkezelést kell végezni, csapat-tervet kell készíteni. Indulás után a TSP pontos mechanizmust nyújt a csapat tevékenységének követésére, vezérlésére


2003 / 2004 7


19

A TSP

TSP képzés előtt a fejlesztőknek PSP képzésen kell részt venniük.A TSP-t alkalmazó csapatok: – 3-20 fősek– kizárólag szoftverfejlesztéssel foglalkozó

csapatok– vegyes csapatok


20

Folyamatjavítási modellek

Szervezeti szinten: CMMFejlesztők szintjén: PSPCsapatok szintjén: TSP


21


A SEI egyéb érettségi modelleket is fejlesztett: szoftverre, rendszerfejlesztésre, termékfejlesztésre

• SW-CMM Capability Maturity Model for Software

• SE-CMM Systems Engineering Capability Maturity Model

• IPD-CMM Integrated Product Development Capability Maturity Model

További modellek, amelyeknek fejlesztésében, kiterjesztésében, vagy karbantartásában részt vesz a SEI:• SA-CMM Software Acquisition Capability Maturity Model

• P-CMM People Capability Maturity Model


2003 / 2004 8


22

A TQM filozófiaW. Edwards Deming, 1950-es évek– Japán kérése: segítség a háború által tönkretett

gazdaság helyreállításában– sikerült!

1980-as évek: az USA is felfedezte– Joseph Juran, Philip Crosby munkássága

Jelenleg: a TQM -et alkalmazzák – üzleti életben, kormányzatban, hadászatban,

oktatásban, non-profit szervezetekben….


23

A TQM filozófia„…folytonos javítást/javulást támogató rendszer, amely a vezetőség bevonásán és a felhasználók igényein alapszik” (Jurow & Barnard, 1993)A minőséget „be kell építeni” a folyamatbaSzemléletmódAlapvető összetevők:– 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


24

A TQM filozófia

A szoftverfejlesztésben is alkalmazhatóA klasszikus szoftverminőségi modellek

nem TQM-szemléletűek– különválasztják a szoftverfolyamatokat az „egyéb”

folyamatoktól – megtörténhet, hogy a szoftverfolyamat javítása nem

kapcsolódik a cég üzleti céljaihoz

Kis cégeknek gondjuk lehet a TQM elvek értelmezésével, alkalmazásával


2003 / 2004 9


25


EFQM által javasolt kiválósági modellAz ESI által kidolgozott EFQM / SPICE

integrált modell...


26

EFQMÜzleti kiválósági modell („business

excellence”)Minőség : specifikációnak / modellnek való megfelelős + vevők elégedettségének eléréseTQM filozófián alapulA kiválóság legfőbb összetevői: – eredmény-orientáltság, vevőközpontúság, vezetés és célok állandósága,

folyamatokon és tényeken alapuló vezetés, emberek fejlődés és bevonása, folyamatos tanulás, újítás és javítás, kölcsönösen előnyös partnerkapcsolatok, társadalmi felelősségtudat. (http://www.efqm.org/imodel/model.htm)


27

EFQMA minőségügyi rendszer és az üzleti

irányítási rendszer összekapcsolódikA modell fontosnak tekinti az üzleti folyamatok résztvevőit:

• vevők (belső, külső, jelenlegi, potenciális)• alkalmazottak• részvényesek• társadalom• alvállalkozók

„Win-win” típusú kapcsolat az összes partnerrel


2003 / 2004 10


28

EFQMKeret („non prescriptive framework”)9 elven alapul– ezek közül: 5: Lehetőséget teremtő („enabler”)– 4: „eredmény”


29

Az EFQM modell


30

EFQM

A modell középpontjában a RADAR elnevezést viselő logika áll– Result (eredmény)– Approach (megközelítés)– Deployment (fejlődés, felfejlődés)– Assessment and Review (értékelés, szemlézés)

A modell alkalmazását segítő eszközök léteznek (pl. kérdőívek)


2003 / 2004 11


31

EFQM / SPICE

Integrált modellAz ESI dolgozta ki

Ötvözi a SPICE szemléletét a TQM filozófiávalTanúsítható

(http://www.esi.es/Consultancy/diagnosis5.html)


32

É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 (continuos 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


33

A CMMI

Capability Maturity Model Integration

Jelenleg is futó projekt(http://www.sei.cmu.edu/cmmi/)

Forrás: CMMI - Overview- Turtorial. 2001. By Carnegyi Mellon UniversityCapability Maturity Model Integration, Version 1.1.Continuous representation. Stagedrepresentation. December 2001. Internet: http://www.sei.cmu.edu/cmmi/products/ippd/model-components-word.html


2003 / 2004 12


34

A CMMI célja

A többféle érettségi modell alkalmazásból adódó nehézségek kiküszöböléseA meglévő érettségi modellek integrálása, a

következetlenségek megszüntetése, a duplikálás csökkentéseA modell-alapú folyamatjavítási tevékenységek költségének csökkentéseAz átláthatóság, érthetőség javítása

– közös terminológia– konzisztens stílus– egységes felépítés– közös elemek


35

A CMMI céljaA szoftverfejlesztésben, rendszerfejlesztésben és termékfejlesztésben leggyakrabban alkalmazott modellek nevezetesen:

1. Capability Maturity Model for Software (SW-CMM) v2.0 draft C2. Electronic Industries Alliance Interim Standard (EIA/IS) 731, Systems Engineering Capability Model (SECM) 3. Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98

összevonása egyetlen modellé /szabvánnyá, amelyet minden szervezet használhat a folyamatjavításban.

– A modell az ISO/IEC) 15504 Technical Report for Software Process

Assessment-ben leírt modellen is kompatibilis


36

A CMMI projektSzponzora az amerikai Védelmi Minisztérium (DoD) és a National Defense IndustrialAssociation (NDIA).Résztevők (100-nál több személy):– Ipar– kormányzat– SEI


2003 / 2004 13


37

A CMMI projekt fázisaiFejlesztés

• A CMMI termékek kifejlesztése• A CMMI termékek ellenőrzése - jelenleg a CMMI V 1.1. került kiadásra 2001

január 11.-én: CMMI-SE/SW, V1.1 és CMMI-SE/SW/IPPD, V1.1

Átmenet• A kezdeti modellek jóváhagyása hivatalos kiadásra• Bizonyíték, hogy a modelleket elegendő mértékben használták• Az átállás megtervezése, a cégek támogatása az új CMMI termékek

bevezetésére

Támogatás• A modell folytonos javítása• Az alkalmazások figyelése


38

A CMMI modell elemeiMindkét megjelenítésben: – Folyamatok / folyamatcsoportok (Process area)– Sajátos célok (Specific goals)– Sajátos gyakorlat (Specific practices)– Általános célok (Generic goals)– Általános gyakorlat (Generic practices)

Lépcsős megjelenítésben:– Általános jellemvonások (common features)

• a végrehajtáshoz szükséges elkötelezettség, képesség, a bevezetés irányítása, a bevezetés ellenőrzése (commitment to perform, ability toperform, directing implementation, verifying implementattion)

– Érettségi szintek (Matturity levels)Folytonos megjelenítésben– Képességi szintek (Capability levels)


39

A CMMI elemeiLépcsős megjelenítés esetében:

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

AbilityImplementation

Verifyingto Perform

Commitment DirectingImplementation

Specific Goals

ImplementationSpecific Practices

to Perform

Maturity Levels

Generic Practices

Generic Goals

Process Area 2

Common Features

Process Area 1 Process Area n

AbilityImplementation

Verifyingto Perform

Commitment DirectingImplementation

Specific Goals

ImplementationSpecific Practices


2003 / 2004 14


40

A CMMI elemei

Folytonos megjelenítésben

Generic Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability LevelsGeneric Practices

Generic Goals

Process Area 2Process Area 1 Process Area n

Specific Goals

Specific Practices Capability Levels


41

A CMMI elemeiA lépcsős megközelítés a folyamatokat 5 szervezeti érettségi szinthez (maturity levels) társítja, ezzel támogatva és vezérelve a folyamatjavítást.

1. Kezdeti (Initial)

2. Menedzselt (Managed)3. Meghatározott (Defined)4. Minőségileg menedzselt (Quantitatively Managed)5. Optimalizáló (Optimizing)

Egy adott érettségi szinten bizonyos folyamatoknak jelen kell lenniük.

A modell minden folyamat esetében megadja a sajátos célokat, az általános célokat, a célok megvalósítását szolgáló gyakorlatot a 2 és 3 szinteken.

A lépcsős megközelítés 4 általános jellemzőt használ a gyakorlatleírásához.


42

A CMMI elemeiA folytonos megközelítés 6 képességi szintet határoz meg, bármely folyamatra

0. Hiányos (Incomplete)

1. Végrehajtott (Performed)2. Menedzselt (Managed)3. Meghatározott (Defined)4. Minőségileg menedzselt (Quantitatively Managed)5. Optimalizáló (Optimizing)

A folyamatok között rokonsági fokozatokat határoz meg.

A fejlesztés itt az egyes folyamatokra vonatkozik.

Folyamatjavítási utak, lehetséges folyamatprofilok vannak.

A folyamatoknak általános és sajátos céljai vannak, s a célok megvalósításához szükséges gyakorlat, minden szinten.


2003 / 2004 15


43

A lépcsős megközelítés folyamatai2. Szint (projekt központú):

– Requirement management, Project Planning and Control, Supplier Agreement Management, Measurement and Analysis, Product and Process Quality Assurance, Configuration Management

3. Szint (szervezet központú):– Requirement Definition, Technical Solution, Product Integration, Product

verification, Product Validation, Organisational Process Focus, Org Proc Definition, Org Training, Integrated pr man, Risk management, Decision Analysis and Resolution

4. Szint (mennyiségi kontroll):– Org. process performance, Quantitative Project Management

5. Szint (folytonos javítás):– Org Innovation and Deployment, Casual Analysis and Resolution


44

A lépcsős megközelítés folyamatai2. Szint (projekt központú):

– Követelménykezelés, projekt tervezés és vezérlés, beszállítók kezelése, mérés és elemzés, termék és folyamat minőségbiztosítás, konfigurációkezelés

3. Szint (szervezet központú):– Követelmények meghatározása, műszaki megoldások, termék integráció,

termék ellenőrzés, termék igazoló ellenőrzése, szervezeti szintű folyamatok léte, szerv szintű folyamatok meghatározása, szerv szintű képzés, intergálttermék menedzsment, kockázatkezelés, döntéselemzés és támogatás

4. Szint (mennyiségi kontroll):– Szervezeti szintű folyamatok teljesítménye, mennyiségi projekt

menedzsment

5. Szint (folytonos javítás):– Szervezeti szintű innováció és bevezetés, eseti elemzés és döntéskezelés


45

A folyamatcsoportok a folytonos megközelítésben

• Folyamat menedzsment (ProcessManagement )

• Projekt menedzsment (Project Management

• Engineering )• Support

• Vannak alapfolyamatok (basic) és magas szintű (advanced) folyamatok


2003 / 2004 16


46


• Folyamat menedzsment• Szervezeti szintű folyamatok léte • Szervezeti szintű folyamatok meghatározása • Szervezeti szintű képzés

Szervezeti szintű folyamatok hatékonysága• Szervezeti szintű innováció és bevezetés


47


OPF OPDResources and

coordination

OT

Standard processand other

assets

Training for projects andsupport groups instandard process andassets

Organization’sprocess needsand objectives

Standard processand other

assets

Seniormanagement

Organization’sbusiness

objectives

Project Management,Support, and Engineering

process areas

Training needs

Improvement information(e.g., lessons learned, data, artifacts)

Process improvementproposals; participation indefining, assessing, anddeploying processes

Pl: Folyamatmenedzsment. Alapfolyamatok.


48


Senior management

OPPProgress toward

achieving businessobjectives

OID

Quality and process performance objectives,

measures, baselines, models

Cost and benefitdata from pilotedimprovements

Quality and processperformance objectives,

measures, baselines, models

Process performanceand capability data

Basic set of Process Managementprocess areas

Project Management,Support, and Engineering

process areas

Ability to developand deploy processand supporting assets

Organization Improvements

Common measures

Pl: Folyamatmenedzsment. Magas szintű folyamatok.


2003 / 2004 17


49


• Projekt menedzsment • Projekt tervezés• Projekt követés és vezérlés • Beszállítók kezelése

• Integrált projekt menedzsment • Kockázatkezelés• Intergált csapat-épjtés• Mennyiségi projekt menedzsment


50


• Engineering (fejlesztés)• Követelmények meghatározása • Követelménymenedzsment• Műszaki megoldások• Termék integráció• Ellenőrzés• Validálás

Systems engineering: teljes rendszerek fejlesztése, amelyek tartalmazhatnak szoftvert isSoftware engineering: szoftver fejlesztés


51


RD PI

VAL

CustomerTS

VER

REQM Requirements

Customer needs

Product and product component requirements

Product components, work products, verification and validation reports

Productcomponents

Alternativesolutions

Require-ments

Product

Fejlesztés.


2003 / 2004 18


52

A folyamatcsoportok a folytonos megközelítésbenSupport• Konfigurációkezelés• Folyamat és termék minőségbiztosítás• Mérés és elemzés

• Integrációra alkalmas szervezeti környezet • Döntés elemzés és támogatás • Eseti elemzés és döntés


53

A két reprezentáció folyamatai egymásnak megfeleltethetők

Folytonos Lépcsős:– Folyamat menedzsment

– Szerv szintű folyamatok definiálása 3– Szerv szintű képzés 3– Szerv szintű foly-k teljesítménye 4– Szerv szintű innováció , bevezetés 5

Projekt menedzsment– Beszállítók kezelése 2– Projekt tervezés 2– Projekt követés és vezérlés 2– Integrált projekt menedzsment 3– Kockázatkezelés 3– Integrált csapat építés 3– Mennyiségi projekt menedzsment 4


54

A két reprezentáció folyamatai egymásnak megfeleltethetők

– Folytonos Lépcsős:– Engineering (fejlesztés)

– Követelmények meghatározása 3– Követelménymenedzsment 2– Műszaki megoldások 3– Termék integráció 3– Ellenőrzés 3– Validálás 3

– Support– Konfigurációmenedzsment 2– Folyamat és termék minőségbiztosítás 2– Mérés és elemzés 2– Integrációra alkalmas szervezeti környezet 3– Döntéselemzés és -támogatás 3– Eseti elemzés és döntés 5


2003 / 2004 19


55

Auditálás a CMMI modell alapjánSCAMPI audit módszertan (Standard CMMI Assessment Method for Process Improvement)2002.április és 2003. Június között a SEI-nekjelentett SCAMPI felmérések:– 100 felmérés– 93 szervezet– 52 cég– 6 újrafelmért cég– 357 projekt– 54% USA-n kívüli


56

SCAMPI auditok tapasztalatai


57



2003 / 2004 20


58



59



60



2003 / 2004 21


61



62

Választás modellek között

ISO 9001:2000 – szükségszerűség (+ szakirányú szabvány, pl. orvosi, autóipari...)CMM – 2005 decemberig auditálják, auditorokat már nem képeznekCMMI – folyamatosan auditálják


63

Választás a CMMI elemei között

Függ – a vállalat céljaitól– korábbi tapasztalatátólEsettanulmányok segíthetnekIsmerni kell a modell elemeit!

Lépcsős vagy folytonos?(Forrás: J. Hamilton: Staged and Continuous SPI Model Architectures - which is best? EuroSPI 2000,

Copenhaga, 7. Nov. 2000)


2003 / 2004 22


64

Lépcsős vagy folytonos modell?

Folytonos modellek előnyei– Választási lehetőség

• nincs egyetlen, meghatározott javítási irány

– Kiterjeszthető• könnyű újabb folyamatot bevenni a rendszerbe

– A felmérés eredménye bőséges• megmutatja az erősségeket és gyengeségeket

– Elvi megalapozottságú• elméleti modellen alapul


65


Folytonos modellek hátrányai– Kevés tapasztalat, támogatás– Nehéz a megfelelő folyamatokat kiválasztani

• az üzleti célok pontos ismerete szükséges

– Nem támogatja eléggé a folyamatjavítás bevezetését

– Általában nem működik magas érettségi szinteken ( 4 és 5)

• ilyen szinten nem segíti eléggé a szoftverfejlesztési folyamat javítását


66

Lépcsős vagy folytonos modell?Lépcsős modellek előnyei:– Kezdetben nagyon pontosan fókuszál

• pl. 2-es szinten mindössze 6-7, pontosan meghatározott kulcstevékenység van

– Hangsúlyozza a támogatott javítás fontosságát• „intézményesítés”

– Megkönnyíti különböző szervezetek összehasonlítását• ez jó, ha pl. beszállítót választunk / választanak

– Pragmatikus és támogatott• Van kialakult „köre”, konferenciák, esettanulmányok stb.• fokozatos és elérhető


2003 / 2004 23


67


Lépcsős modellek hátrányai:– Nehéz 3-as szint fölé emelkedni– Túl késő a méréseket 4-es szinten kezdeni– (Idegen nyelven van leírva)– Elsősorban nagy cégek igényeit elégíti ki– Ismerni kell, hogy testre szabva lehessen

alkalmazni


68


Folytonos modell– könnyen tanítható, nehezebben használható

Lépcsős modell– nehezen tanítható, könnyebben használható

Mindenképpen a nekünk megfelelőt kell választani!


69

Mit válasszunk?


2003 / 2004 24


70

Mit válasszunk?

Ha a cég csak most kezdi a folyamatjavítást:– tanulmányozzunk egy lépcsős modellt, kiemelten

figyelve a 2-es szint elemeire– vonjuk a futó projekteket ellenőrzés alá– alakítsuk ki a megfelelő vállalati kultúrát

(politika, képzés, mérés…)– határozzuk meg a fejlődési mechanizmust

(tervezés, a fejlődés követése, mérése…)


71

Mit válasszunk?

Ha a cég magasabb érettségi szinten áll– tanulmányozzuk a folytonos modell által kínált

lehetőséget az egyes folyamatok javítására vonatkozóan

– ott mérjünk, ahol a legtöbbet profitálhatunk a mérésekből


72

Miről volt szó?

Termék

Folyamat

Erőforrás

Definíció

Minőségiattribútum

Mérőszám

Documents

Szoftver minőség és menedzsmentkondor/rszf/SWMM/ELOADASOK/SzMM6-PSP.pdf · – Egyéni tervezés – Egyéni minőség – Kalibrálás 6 + 1 fázis •1. planning •2. designing