Szoftver minőség és menedzsment - Szoftver minőség és menedzsment A szoftverminőség folyamat alapú megközelítése. PSP, TSP, egyéb megközelítések. Integrált modellek. Dr. Balla Katalin Tartalom Egyé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 2 Egyéb folyamatjavítási modellek Personal 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, 1995 2. Using a Defined and Measured Personal Software Process. In: IEEE Software, May 1996, pp. 77-87 3. What is your life depended on software? EuroSPI 2000, Copenhaga, 7. November 2000.) http://www.sei.cmu.edu/tsp/psp.html) 3 2003 / 2004 1
Szoftver minőség és menedzsment - A PSP Az 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 post morten +1. A programozó munkájának értékelése - számos form támogatásával Oktatás 4 A PSP Egyénre szabott tudományág, magasabb szintű szoftverfejlesztéshez A 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 5 A PSP Megtaní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 6 2003 / 2004 2
Szoftver minőség és menedzsment - A PSP lépései Humphrey, Watts.S.: Using a Defined and Measured Personal Software Process. In: IEEE Software, May 1996, pp. 77-87 PSO0: Personal Measurement Engineers 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 7 A PSP lépései PSP1 : Personal planning Introduces 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.) 8 A PSP lépései PSP2 : Personal Quality Introduces defect management; with defect data engineers construct and use checklist for design and code reviews From 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 9 2003 / 2004 3
Szoftver minőség és menedzsment - A PSP lépései PSP3: Scaling up (cyclic development) At this level engineers also explore designverification methods as well as process-definition principles and methods 10 A PSP Kimutatható 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 11 A CMM és a PSP A CMM A PSP a szervezetre vonatkozik az egyénre vonatkozik keret, amelyben jó minőségű feltételezi, hogy van egy rendezett szoftverfejlesztés végezhető és vezetett keret, amelyben keret a folyamatok javítására dolgozni kell feltételezi, hogy a fejlesztők megvan az infrastruktúra a hatékony módszereket megfelelő szoftverfejlesztési ismernek és alkalmaznak, részt folyamatok támogatására vesznek a folyamatok javításában 12 2003 / 2004 4
Szoftver minőség és menedzsment - Egyéb folyamatjavítási modellek Team Software Process 1998 után, Watts Humphrey, SEI Csapatok munkájára vonatkozik Kapcsolódik a CMM-hez és PSP-hez (http://www.sei.cmu.edu/tsp/tsp.html) 13 A TSP Ahhoz, 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 14 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íteni Gyorsítani a szoftverfejlesztési folyamat javulását, a CMM 5 szintre jellemző magatartást természetessé téve Magas érettségi szintű szervezetek számára támogatást nyújtani a folyamatjavításban Támogatni a szoftveriparban szükséges képességek egyetemi szintű oktatását. 15 2003 / 2004 5
Szoftver minőség és menedzsment - 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 16 A TSP fázisai Követelmények Tervezés Implementálás Tesztelés Minden fázis indítással vagy újraindítással kezdődik. 17 A TSP jellemzői A 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é teszi A 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 18 2003 / 2004 6
Szoftver minőség és menedzsment - 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 19 Folyamatjavítási modellek Szervezeti szinten: CMM Fejlesztők szintjén: PSP Csapatok szintjén: TSP 20 Egyéb folyamatjavítási modellek 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 21 2003 / 2004 7
Szoftver minőség és menedzsment - A TQM filozófia W. 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. 22 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 folyamatba Szemléletmód Alapvető ö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 23 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 24 2003 / 2004 8
Szoftver minőség és menedzsment - Egyéb folyamatjavítási modellek EFQM által javasolt kiválósági modell Az ESI által kidolgozott EFQM / SPICE integrált modell... 25 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ése TQM filozófián alapul A 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) 26 EFQM A minőségügyi rendszer és az üzleti irányítási rendszer összekapcsolódik A 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 27 2003 / 2004 9
Szoftver minőség és menedzsment - EFQM Keret ( non prescriptive framework ) 9 elven alapul ezek közül: 5: Lehetőséget teremtő ( enabler ) 4: eredmény 28 Az EFQM modell 29 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) 30 2003 / 2004 10
Szoftver minőség és menedzsment - EFQM / SPICE Integrált modell Az ESI dolgozta ki Ötvözi a SPICE szemléletét a TQM filozófiával Tanúsítható (http://www.esi.es/consultancy/diagnosis5.html) 31 Érettségi modellek Lé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 32 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 University Capability Maturity Model Integration, Version 1.1.Continuous representation. Staged representation. December 2001. Internet: http://www.sei.cmu.edu/cmmi/products/ippd/model-components-word.html 33 2003 / 2004 11
Szoftver minőség és menedzsment - A CMMI célja A többféle érettségi modell alkalmazásból adódó nehézségek kiküszöbölése A meglévő érettségi modellek integrálása, a következetlenségek megszüntetése, a duplikálás csökkentése A modell-alapú folyamatjavítási tevékenységek költségének csökkentése Az á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 34 A CMMI célja A szoftverfejlesztésben, rendszerfejlesztésben és termékfejlesztésben leggyakrabban alkalmazott modellek nevezetesen: 1. Capability Maturity Model for Software (SW-CMM) v2.0 draft C 2. 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 35 A CMMI projekt Szponzora az amerikai Védelmi Minisztérium (DoD) és a National Defense Industrial Association (NDIA). Résztevők (100-nál több személy): Ipar kormányzat SEI 36 2003 / 2004 12
Szoftver minőség és menedzsment - A CMMI projekt fázisai Fejleszté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 37 A CMMI modell elemei Mindké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 to perform, directing implementation, verifying implementattion) Érettségi szintek (Matturity levels) Folytonos megjelenítésben Képességi szintek (Capability levels) 38 A CMMI elemei Lépcsős megjelenítés esetében: Maturity Levels Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Common Features Commitment to Perform Ability to Perform Directing Verifying Implementation Implementation Specific Practices Generic Practices 39 2003 / 2004 13
Szoftver minőség és menedzsment - A CMMI elemei Folytonos megjelenítésben Process Area 1 Process Area 2 Process Area n Specific Goals Generic Goals Specific Practices Capability Levels Generic Practices 40 A CMMI elemei A 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 gyakorlat leírásához. 41 A CMMI elemei A 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. 42 2003 / 2004 14
Szoftver minőség és menedzsment - A lépcsős megközelítés folyamatai 2. 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 43 A lépcsős megközelítés folyamatai 2. 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ált termé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 44 A folyamatcsoportok a folytonos megközelítésben Folyamat menedzsment (Process Management ) Projekt menedzsment (Project Management Engineering ) Support Vannak alapfolyamatok (basic) és magas szintű (advanced) folyamatok 45 2003 / 2004 15
Szoftver minőség és menedzsment - A folyamatcsoportok a folytonos megközelítésben 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 46 A folyamatcsoportok a folytonos megközelítésben Pl: Folyamatmenedzsment. Alapfolyamatok. Senior management Organization s process needs and objectives Training for projects and support groups in standard process and assets Organization s business objectives OT Training needs OPF Resources and coordination Standard process and other assets Standard process and other assets OPD Project Management, Support, and Engineering process areas Process improvement proposals; participation in defining, assessing, and deploying processes Improvement information (e.g., lessons learned, data, artifacts) 47 A folyamatcsoportok a folytonos megközelítésben Pl: Folyamatmenedzsment. Magas szintű folyamatok. Organization Improvements Cost and benefit data from piloted improvements OID Quality and process performance objectives, measures, baselines, models Senior OPP management Progress toward achieving business objectives Quality and process performance objectives, Project Management, measures, baselines, models Support, and Engineering process areas Common measures Process performance and capability data Ability to develop and deploy process and supporting assets Basic set of Process Management process areas 48 2003 / 2004 16
Szoftver minőség és menedzsment - A folyamatcsoportok a folytonos megközelítésben 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 49 A folyamatcsoportok a folytonos megközelítésben 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 is Software engineering: szoftver fejlesztés 50 A folyamatcsoportok a folytonos megközelítésben Fejlesztés. REQM Requirements Product and product component requirements RD Alternative solutions Requirements TS Product components PI Product Customer Product components, work products, verification and validation reports VER VAL Customer needs 51 2003 / 2004 17
Szoftver minőség és menedzsment - A folyamatcsoportok a folytonos megközelítésben Support 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 52 A két reprezentáció folyamatai egymásnak megfeleltethetők Folytonos 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 Lépcsős: 53 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 54 2003 / 2004 18
Szoftver minőség és menedzsment - Auditálás a CMMI modell alapján SCAMPI audit módszertan (Standard CMMI Assessment Method for Process Improvement) 2002.április és 2003. Június között a SEI-nek jelentett 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 55 SCAMPI auditok tapasztalatai 56 SCAMPI auditok tapasztalatai 57 2003 / 2004 19
Szoftver minőség és menedzsment - SCAMPI auditok tapasztalatai 58 SCAMPI auditok tapasztalatai 59 SCAMPI auditok tapasztalatai 60 2003 / 2004 20
Szoftver minőség és menedzsment - SCAMPI auditok tapasztalatai 61 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épeznek CMMI folyamatosan auditálják 62 Választás a CMMI elemei között Függ a vállalat céljaitól korábbi tapasztalatától Esettanulmányok segíthetnek Ismerni 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) 63 2003 / 2004 21
Szoftver minőség és menedzsment - 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 64 Lépcsős vagy folytonos modell? 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 65 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ő 66 2003 / 2004 22
Szoftver minőség és menedzsment - Lépcsős vagy folytonos modell? 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 67 Lépcsős vagy folytonos modell? 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! 68 Mit válasszunk? 69 2003 / 2004 23
Szoftver minőség és menedzsment - 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 ) 70 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 71 Miről volt szó? Mérőszám Minőségi attribútum Definíció Erőforrás Folyamat Termék 72 2003 / 2004 24