Procesní standardy Radek Mařík CA CZ, s.r.o. May 21, 2010 Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 1 / 39
Obsah 1 Koncept 2 Hodnocení softwarového procesu SEI a SPR hodnocení Malcolm Baldrige hodnocení ISO 9000, IEEE/ANSI 3 Specifikace dokumentů Plány Procedury, scripty, záznamy Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 2 / 39
Koncept, Standardy kvality [?] který proces je použit, stupeň, jak se používá, se liší: od organizace k organizaci, od projektu k projektu, implementační procedury, metody a nástroje, které se používají, metriky a měření, co je dobrý stav vs. jak se do stavu dostat. Metodologie používané k hodnocení vyspělosti procesu organizace nebo projektu: The SEI Capability Maturity Model Integrated (CMMI), The Software Productivity Research (SPR) process maturity assessment methods, The Malcom Baldrige discipline and assessment processes, ISO 9000 registrační proces. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 4 / 39
Koncept Nezralé vs. Vyspělé softwarové organizace [?] Bez porozumění rozdílu mezi vyspělou a nezralou softwarovou organizací nelze vybrat přiměřené cíle k zlepšení softwarového procesu. Základním problémem je neschopnost řídit softwarový proces. V nedisciplinovaných organizacích zavisí úspěch na heroických výkonech týmu. Zopakování výsledků závisí cele na přítomnosti těch samých individuálů na následujícím projektům. Nezralé organizace jsou reakční a manažéři se soustředí na řešení okamžitých krizí (hašení požáru). Kvality produktu je obtízně předpovídat. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 5 / 39
Základní koncepty [?] Koncept Proces (IEEE-STD-610) je sekvence kroků vykonaných za daným účelem. Softwarový proces může být definován jako množina aktivit, metod, praktik a transformací, které lidé používají k vývoji a údržbě softwaru a asociovaných produktů (např. plánů projektů, návrhových dokumentů, kódu, testovacích případů a uživatelských manuálů). Schopnost softwarového procesu popisuje rozsah očekávaných výsledků, které mohou být dosaženy, pokud se dodržuje daný softwarový proces. Výkonnost softwarového procesu prezentuje dosažené aktuální výsledky, pokud se dodržuje daný softwarový proces. Vyspělost softwarového procesu je míra, se kterou je daný proces explicitně definován, organizován, měřen, řízen a jak je efektivní. Vyspělost znamená potenciál růstu schopnosti a indikuje jak bohatost softwarového procesu ogranizace tak konzistenci, se kterou je proces aplikován v projektech organizace. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 6 / 39
CMMI [?] CMMI: organizační strategie zlepšení, jak navrhnout vývojovou cestu, průvodce k výběru strategie zlepšení procesu, poskytuje rámec organizace vývojových kroků do 5 úrovní výspělosti. Úroveň vyspělosti: je jasně definovaný stupeň dosažený vyspělosti, každá úroveň vyspělosti poskytuje vývojovou základnu pro kontinuální zlepšování procesu. každá úrověn je definována množinou cílů, které při splnění stabilizují jistou důležitou komponentu procesu. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 8 / 39
5 úrovní vyspělosti softwarového procesu [?] Continuously improving process Optimizing (5) Predictable process Managed (4) Standard, consistent process Defined (3) Disciplined process Repeatable (2) Initial (1) Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 9 / 39
Charakteristiky 5 úrovní vyspělosti [?] 1 Počáteční: ad hoc, někdy až chaotický softwarý proces, některé procesy mohou být definovány, úspěch závisí na úsiĺı jednotlivců. 2 Opakovatelný: organizační procesy sledování nákladů, časového rozvrhu a funkčnosti, procesní discipĺına k zopakování úspěchu na podobných aplikacích. 3 Definovaný: organizační a inženýrské aktivity dokumentovány, standardizovány a integrovány jako standard organizace, odsouhlasenou přizpůsobenou verzi standardu na všech projektech. 4 Řízený: sběr podrobných měrových ukazatelů kvality procesu i produktu, kvantitativní porozumění procesu a produktu. 5 Optimalizující: neustálé zlepšování procesu, kvantitativní zpětná vazba z procesu, zavádění inovačních myšlenek a technologíı. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 10 / 39
Charakterizace chování na úrovni vyspělosti 1 [?] Není vytvořeno stabilní prostředí pro vývoj a údržbu softwaru. Během krizí projekty typicky opouští plány a vrhají se na pouhé kódování a testování. Úspěch závisí cele na vyjímečném manažérovi a sehraném efektivním softwarovém týmu. Nelze se spoléhat na odhady časových rozvrhů, nákladů, funkčnosti a kvality produktu. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 11 / 39
Charakterizace chování na úrovni vyspělosti 2 [?] Efektivní proces dovoluje zopakovat úspěšné praktiky minulých projektů. Jsou instalovány základní nástroje řízení softwaru. Požadavky na software a pracovní produkty jsou evidovány a je kontrolována jejich integrita. Jsou definovány standardy softwarového projektu. Plánování a trasování projektu je stabilní. Vytvářejí se reálné plány založené na zkušenostech z minulých projektů. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 12 / 39
Charakterizace chování na úrovni vyspělosti 3 [?] Standardní proces vývoje a údržby softwaru je dokumentován, zahrnuje jak manažérské tak i inženýrské procesy, které spolu jsou koheretní. Standardní proces je základním procesem organizace. Existuje skupina odpovědná za softwarový proces. Projekty se odvíjejí od standardu s příhlédnutím na jejich unikátní charakteristiky. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 13 / 39
Porozumění úrovním vyspělosti [?] Základní atributy - dostatečná úroveň abstrakce Interpretace praktik by měla být rozumná. CMMI nepředpisuje. CMMI nepředepisuje organizaci, jak se zlepšit. 1-2: několik let, ostatní pak dva roky. Úspěch na úrovni 1 závisí cele na heroických výkonech lidí. Úrovně Opakující a Definovaný posunují pozornost na organizační a manažérská témata. Úroveň 2: disciplinovaný softwarový proces, management se orientuje, dokumentované procedury. Úroveň 3: integrace na úrovni organizace. Úroveň 4 a 5: relativně neznámá teritoria, založeno na konceptech statistického řízení procesu. Úroveň 4: řízení procesu, obecně stabilní prostředí. Úroveň 5: neustálé zlepšování procesu. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 14 / 39
Viditelnost do softwarového procesu [?] 5 In 0000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 1111111111111111 1111111111111111 1111111111111111 1111111111111111 1111111111111 01 000000000000 111111111111 00 11 Out 4 In Out 3 In Out 2 In Out 1 In Out Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 15 / 39
Schopnost procesu [?] Čím je vyspělost vyšší, tím se zmenšuje rozdíl mezi cílenými a aktuálními výsledky. Variability aktuálních výsledků se zmenšuje okolo cílů. Probability Probability Probability Probability Probability Time/$/... Time/$/... Time/$/... Time/$/... Time/$/... continuous improvement quantitative understanding of process well defined process realistic plans overruns Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 16 / 39
Přeskakování úrovní [?] Organize může s výhodou použít procesy vyšších úrovní. Tyto procesy se nemohou plně rozvinout, pokud nemají řádný základ. Přeskočení úrovně často nepřinese hledané výhody, neboť každá úroveň tvoří základy pro následující úroveň. Organizace na úrovni 1 nemají úspěch se zavedením definovaného procesu, neboť manažéři jsou přetíženi rozvrhováním a tlaky cen. Toto je základní důvod, proč je nutné nejprve řešit manažérské problémy před technickými. Technici se často domnívají, že jsou schopni implementovat inženýrské procesy bez ohledu na manažérské procesy, ale končí pod tlakem plánování a nákladů. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 17 / 39
Operační definice CMMI [?] Použití CMMI: Hodnotící týmy - identifikace silných a slabých stránek organizace. Výběrové týmy - identifikace risků při výběru z řady kontraktorů. Manažéři a technici - porozumění aktivitám, které potřebují k plánování a implementaci procesu a programu jeho vylepšení. Procesní skupina - průvodce, který pomáhá definovat a zlepšit proces. Dokompozice úrovní vyspělosti: abstraktní přehledy, Kĺıčové procesní oblasti - organizovány do 5 sekcí zvané obecné vlastnosti. Obecné vlastnosti - specifikují kĺıčové praktiky, které jako celek splňují cíle dané kĺıčové procesní oblasti. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 18 / 39
Struktura CMMI [?] Maturity Levels Process Capability Goals contain indicate Key Process Areas organized by achieve Common Features Implementation or Institutionalization address contain Key Practices Infrastructure or Activities describe Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 19 / 39
Kĺıčové procesní oblasti [?] Optimizing (5) Process change management Technology change management Defect prevention Managed (4) Software quality management Quantitative process management Defined (3) Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus Repeatable(2) Software configuration management Software quality assurance Software subcontract management Software project tracking and oversight Software project planning Requirements management Initial (1) Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 20 / 39
Kĺıčové procesní oblasti, obecné vlastnosti, kĺıčové praktiky [?] Každá kĺıčová procesní oblast - identifikuje sadu aktivit, které,pokud jsou všechny prováděny, splňují množinu cílů důležitých k dosažení procesní schnopnosti. Všechny cíle kĺıčové procesní oblastí musí být dosaženy k tomu, aby daná oblast byla splněna. Kĺıčová znamená, že existují oblasti, které nejsou kĺıčové k dosažení úrovně vyspělosti. Obecné vlastnosti - atributy, které indikují, zda implementace a ustanovení kličové oblasti je efektivní, opakovatelné a trvající. Kĺıčové praktiky - předepisují infrastrukturu a aktivity, které nejvíce přispívají k efektivní implementaci kĺıčové oblasti (co, ne jak). Každá kĺıčová praktika je jednoduchá věta, která je často doplněna podrobným popisem s příklady. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 21 / 39
Příklad kĺıčové praktiky [?] Maturity Level: Level 2, Repeatable Process Capability: disciplined process indicates contains Key Process Area: Software Project Planning Goal 1: Software estimates are documented for use in planning and tracking the software project. achieves organized by Implementation or Institutionalization: Implementation address Common Feature: Activities Performed contains Infrastructure or Activities: Activity describes Key Practices: Activity 9. Estimates for the size of the software work products (or changes to the size of software work products) are derived according to documented procedure. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 22 / 39
Kĺıčové procesní oblasti úrovně 2: Opakovatelné [?] Řízení požadavků 1 Systémové požadavky na systém jsou řízeny tak, že vytvářejí evidovanou základnu určenou pro softwarové inženýrství a potřeby manažérů. 2 Plány na vývoj softwaru, produkty a aktivity jsou udržovány konsistentní ss systémovými požadavky na software. Plánování softwarového projektu 1 Softwarové odhady jsou dokumentovány za účelem použití při plánování a traosvání softwaru. 2 Softwarové projektové aktivity a povinnosti jsou plánovány a dokumentovány. 3 Skupiny a jednotliví lidé souhlasí s tím, co mají udělat v rámci daného projektu. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 23 / 39
Hodnocení softwarového procesu Hodnocení SPR a SEI [?] SEI a SPR hodnocení vyvinuto Jonesem v Software Productivity Research, Inc. (SPR), publikováno v 1986, velký stupeň podobnosti, ale i podstatné odlišnosti mezi metodami SEI a SPR, process ohodnocení SEI: zaměřeno na strukturu softwarové organizace a softwarové procesy, 85 otázek, binární škála (ano/ne), SPR: pokrývá jak strategické problémy korporace, tak i projektovou taktiku, okolo 400 otázek, pětibodová stupnice dle Likerta: 1 výborný, 2 dobrý, 3 průměrný, 4 dostatečný, 5 nedostatecný Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 25 / 39
Hodnocení softwarového procesu Okruhy SPR otázek [?] SEI a SPR hodnocení měření kvality a produktivity, zkušenosti programátorů s odstraňováním defektů před testováním, zkušenosti programátorů s odstraňováním defektů při testování, cíle kvality a spolehlivosti na projektech, odstraňování defektů před testováním na projektové úrovni, odstraňování defektů při testování na projektové úrovni, odstraňování defektů po uvedení na trh. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 26 / 39
Hodnocení softwarového procesu Malcolm Baldrige hodnocení [?] Malcolm Baldrige hodnocení The Malcolm Baldrige National Quality Award (MBNQA), jedna z nejprestižnějších ocenění kvality ve Spojených státech, 1988, the U.S. Department of Commerce, udělováno ročně americkým společnostem, které vynikají v řízení kvality a stupni jejího dosažení, mnohem širší rozsah než SEI a SPR hodnocení (výroba, servis, drobné podnikání) přezkušovacího kritéria - sedm kategoríı obsahující 28 položek: schopnosti vedení, informace a analýza, strategické plánovaní kvality, používání lidských zdrojů, zabezpečení kvality produktů a servisu výsledky kvality, spokojenost zákazníků. 1992, The European Quality Award Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 28 / 39
ISO 9000 [?] Hodnocení softwarového procesu ISO 9000, IEEE/ANSI sada standardů a průvodců k řízení zajištění kvality, system International Organization for Standardization řada firem neprojde auditem napoprvé, od 60% do 70%. velmi silné požadavky na správu dokumentů, musí být adekvátní účelu, identifikace vlastníka, řádně schválen před zvěřejněním, řízená distribuce, identifikace verze, očíslované stránky, indikace celkového počtu stran, zastaralé dokumenty jsou ihned likvidovány, ISO 9000 audit se zaměřuje na systém řízení kvality a řízení procesu. Řekni, co děláš, dělej, co říkáš, a dokaž to. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 30 / 39
Hodnocení softwarového procesu ISO 9000, IEEE/ANSI IEEE/ANSI Standardy softwarového procesu [?] IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 IEEE Standard Dictionary of Measures to Produce Reliable Software, IEEE Std 982.1-1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software, IEEE Std 982.2-1988 IEEE Standard for Developing Software Life Cycle Processes, IEEE Std 1074-1991 IEEE Standard for Software Test Documentation, (Reaff.1991), IEEE Std 829-1983 IEEE Standard for Software Verification and Validation Plans, (Reaff. 1992, IEEE Std 1012-1986 IEEE Standard for Software Review and Audits, IEEE Std 1028-1988 IEEE Standard for Software Quality Assurance Plans, IEEE Std 730-1989 IEEE Standard for Software Unit Testing, IEEE Std 1008-1987 Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 31 / 39
Specifikace dokumentů Plány Plánování testování, ISO 9000 [?] Plány by měly adresovat: plány pro softwarové jednotky, integraci, systémové testy, akceptační testy. testovací případy, testovací data, očekávané výsledky, typy testů, např. funkční testy, testy hranic, testy výkonnosti, test použitelnosti, testovací prostředí, testovací nástroje a testovací software, kritéria, podle kterých lze ukončit testování, vstupní a výstupní podmínky každé fáze testování, uživatelskou dokumentaci, požadavky na pracovní síly a jejich zacvičení, zdroje a rozvrh návrhu testů, zdroje a rozvrh provedení testů, závislosti na externích podmínkách, technické, rozpočtové a rozvrhové risky. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 33 / 39
Specifikace dokumentů Plány IEEE hlavní validační testovací plán [?] Účel: stanovuje rámec, přístup, zdroje a rozvrh testovacích aktivit. Obsah: identifikátor testovacího plánu, úvod, struktura testů, vlastnosti testované a netestované, přístup, kritéria selhání a akceptování, kritéria přerušení a požadavky na obnovení, dodávané testovací položky, úlohy testování, požadavky na prostředí, lidské zdroje a jejich zaučení, rozvrh, risk a nepředvídané události, schvalování. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 34 / 39
Specifikace dokumentů Specifikace testovací procedury [?] Procedury, scripty, záznamy popisuje kroky provedení sady testovacích případů a analýzy jejich výsledků: identifikátor specifikace testovací procedury, účel a křížové reference všech testovacích případů používající tuto testovací proceduru, speciální požadavky, kroky procedury: záznam: všechny speciální metody a formáty, nastavení: příprava provedení procedury, zahájení: jak začít běh procedury, pokračování: jaké akce jsou potřeba během provádění procedury, měření: jak dělají testovací měření, ukončení: jak přerušit testování, opětné zahájení: kde je možné po přerušení opětně zahájit testy, zastavení: jak je možné ukončit běh testů, opakovatelnost: jak nastavit prostředí zpět do jeho výchozího stavu, nepředvídatelnost: co dělat, když to nejede podle očekávání. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 36 / 39
Testovací skript [?] Specifikace dokumentů Procedury, scripty, záznamy je návod provedení testu krok po kroku: obecné pokyny: jak číst a používat skript, jak začít: informace o nastavení, procedurální popis testu krok po kroku, kontrolní body pro každý krok testu a očekáváné výsledky, důraz na popis podivného chování či možného chybného porozumění. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 37 / 39
Záznam testu [?] Specifikace dokumentů Procedury, scripty, záznamy je chronologický zápis provedení testu a událostí, které nastaly během testování: identifikátor záznam testu, popis: informace o konfiguraci, activity a události: co se stalo, popis provedení, výsledky procedury, informace o prostředí, popis anomálíı, identifikátory zpráv o problémových událostech. Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 38 / 39
Literatura I Specifikace dokumentů Procedury, scripty, záznamy Radek Mařík (radek.marik@ca.com) Procesní standardy May 21, 2010 39 / 39