Procesní standardy. September 14, CA CZ, s.r.o. Radek Mařík Procesní standardy September 14, / 32

Podobne dokumenty
Procesní standardy. May 21, CA CZ, s.r.o. Radek Mařík Procesní standardy May 21, / 39

Kristýna Kuncová. Matematika B2 18/19

Cechy charakterystyczne tworzenia oprogramowania w Inżynierii Biomedycznej. Wykładowca Dr inż. Zofia Kruczkiewicz

Kuchta Jarosław Jakość Oprogramowania. Modele dojrzałości procesu wytwarzania oprogramowania CMM/CMMI

dr inż. M. Żabińska, Katedra Informatyki AGH, D17/ 2.27 dr inż. M. Żabińska

Edita Pelantová, katedra matematiky / 16

Metodyki, standardy i certyfikaty a jakość wdraŝanych rozwiązań informatycznych

Úvodní informace. 18. února 2019

Klasická metodologie testování

Aproximace funkcí 1,00 0,841 1,10 0,864 1,20 0,885. Body proložíme lomenou čarou.

Metodologie testování

Internet a zdroje. (Zdroje na Internetu) Mgr. Petr Jakubec. Katedra fyzikální chemie Univerzita Palackého v Olomouci Tř. 17.

Metodyka dla projektu SYRIUSZ

Marek Krętowski Wydział Informatyki PB. Wersja 1.1 IO2 (wyk.

(1) Derivace. Kristýna Kuncová. Matematika B2 17/18. Kristýna Kuncová (1) Derivace 1 / 35

1 Soustava lineárních rovnic

Wykaz norm i innych dokumentów normalizacyjnych serii ISO i ich polskie odpowiedniki

Register and win!

PROGRAM STAŻU. Nazwa podmiotu oferującego staż IBM Global Services Delivery Centre Polska Sp. z o.o.

WYMAGANIA POMIAROWE W MODELACH OCENY PROCESU PROGRAMOWEGO

MATEMATIKA 3. Katedra matematiky a didaktiky matematiky Technická univerzita v Liberci

Co nám prozradí derivace? 21. listopadu 2018

Anna Kratochvílová Anna Kratochvílová (FJFI ČVUT) PDR ve zpracování obrazu / 17

CA CZ, s.r.o. May 21, Radek Mařík Testování řídicích struktur May 21, / 45

Tworzenie zintegrowanych strategii miejskich. Creation of integrated urban strategies? the example of the Krakow Functional Area

Obkládačky a dlaždičky Płytki ścienne i podłogowe: SIGHT šedá szary

Numerické metody minimalizace

Úvod do testování a verifikace

5. a 12. prosince 2018

CERTIFICATION CONTACT SECRETARY HOMEPAGE OFFER CERTIFICATION. The Building Research Institute as:

Inverzní Z-transformace

Powyższe reguły to tylko jedna z wersji gry. Istnieje wiele innych wariantów, można też ustalać własne zasady. Miłej zabawy!

Platforma pro analýzu, agregaci a vizualizaci otevřených dat souv

ČVUT FEL, K Radek Mařík Strukturované testování 20. října / 52

Źródła dumy zawodowej testera oprogramowania

Kristýna Kuncová. Matematika B2

CERTIFICATION CONTACT SECRETARY HOMEPAGE OFFER CERTIFICATION. The Building Research Institute as:

Metodyki projektowania i modelowania systemów Cyganek & Kasperek & Rajda 2013 Katedra Elektroniki AGH

PA152,Implementace databázových systémů 2 / 25

PLANY I PROGRAMY STUDIÓW

Projekt Kompetencyjny - założenia

ZÁVĚREČNÁ KONFERENCE Poslanecká sněmovna PČR Praha MEZINÁRODNÍ DOTAZNÍKOVÉ ŠETŘENÍ ANKIETY MIEDZYNARODOWE

Funkce zadané implicitně. 4. března 2019

INŻYNIERIA OPROGRAMOWANIA Jakość w projekcie informatycznym - normy

Vybrané kapitoly z matematiky

Dotyczy PN-EN ISO 14001:2005 Systemy zarządzania środowiskowego Wymagania i wytyczne stosowania

Komplexní analýza. Martin Bohata. Katedra matematiky FEL ČVUT v Praze Martin Bohata Komplexní analýza Mocninné řady 1 / 18

PLANY I PROGRAMY STUDIÓW

Health Resorts Pearls of Eastern Europe Innovative Cluster Health and Tourism

POPRAWKA do POLSKIEJ NORMY PN-EN ISO 9001:2009/AC. Dotyczy PN-EN ISO 9001:2009 Systemy zarządzania jakością Wymagania. listopad 2009 ICS

Usługowy model zarządzania w oparciu o ITIL v3. wprowadzenie do biblioteki ITIL na prostym przykładzie

Design of Experiment (DOE) Petr Misák. Brno 2016

Richard Moret, Bartosz Zawisza. 10 czerwca 2011

Linea rnı (ne)za vislost

Dwie oceny systemu bezpieczeństwa: ilościowa i jakościowa. Robert Kępczyński Senior Consultant

K SAMOSTATNÉ MODULOVÉ SCHODY MONTÁŽI. asta

Podejście zwinne do zarządzania projektami

wydany przez issued by POLSKIE CENTRUM AKREDYTACJI ul. Szczotkarska 42, Warszawa, Polska

Rovnice proudění Slapový model

Business Development Consulting

2. AQAP 2105 wydanie C, wersja 1 jest obowiązująca z chwilą ustanowienia.

Lecznictwo uzdrowiskowe na pograniczu czeskopolskim. jego wkład w rozwój regionalny. jeho přínos pro regionální rozvoj

Model CMMI, ISO, zapewnianie jakości oprogramowania

ZARZĄDZANIE PROJEKTAMI W PROJEKTACH TECHNICZNYCH I INFORMATYCZNYCH

SYNTHOS PS GPPS HIPS

Numerické metody 8. května FJFI ČVUT v Praze

No matter how much you have, it matters how much you need

Necht je funkce f spojitá v intervalu a, b a má derivaci v (a, b). Pak existuje bod ξ (a, b) tak, že f(b) f(a) b a. Geometricky

kontaktní modely (Winklerův, Pasternakův)

(2) Funkce. Kristýna Kuncová. Matematika B2. Kristýna Kuncová (2) Funkce 1 / 25

Wykaz norm i innych dokumentów normalizacyjnych serii ISO i ich polskie odpowiedniki

I. Praktyczne zwroty. Prezentacja danego działu obejmuje poczatkową treść każdego podrozdziału. abandon the procedure, to unieważnić procedurę

ZMIANY W NORMACH DOTYCZĄCYCH ZARZĄDZANIA ŚRODOWISKOWEGO

CMMI Doskonalenie Procesów w Organizacji XII

PROGRAM STAŻU Nazwa podmiotu oferującego staż IBM GSDC SP.Z.O.O

NÁVOD K POUŽITÍ KEZELÉSI KÉZIKÖNYV INSTRUKCJA OBSŁUGI NÁVOD NA POUŽÍVANIE. Česky. Magyar. Polski. Slovensky

Teorie plasticity. Varianty teorie plasticity. Pružnoplastická matice tuhosti materiálu

Zadání: Vypočítejte hlavní momenty setrvačnosti a vykreslete elipsu setrvačnosti na zadaných

Wydział Inżynierii Produkcji i Logistyki Faculty of Production Engineering and Logistics

Krytyczne czynniki sukcesu w zarządzaniu projektami

Automatové modely. Stefan Ratschan. Fakulta informačních technologíı. Evropský sociální fond Praha & EU: Investujeme do vaší budoucnosti

Rekrutacja List Motywacyjny

ČVUT FEL, K October 1, Radek Mařík Ověřování modelů II October 1, / 39

NORMY JAKOŚCIOWE ISO 9001, i W TRANSPORCIE KOLEJOWYM. mgr inż. Wojciech Rzepka

Martin Pergel. 26. února Martin Pergel

Komplexní analýza. Martin Bohata. Katedra matematiky FEL ČVUT v Praze Martin Bohata Komplexní analýza Úvod 1 / 32

KATALOG SZKOLEŃ. Kod szkolenia Nazwa szkolenia Czas trwania. QC370 ALM Quality Center Scripting 11.x 2

Wprowadzenie do przedmiotu 1

Masarykova univerzita Ekonomicko-správní fakulta

PROGRAM STAŻU. Nazwa podmiotu oferującego staż / Company name IBM Global Services Delivery Centre Sp z o.o.

Geometrická nelinearita: úvod

Normalizacja zarządzania środowiskowego Teraźniejszo. niejszość. Anna Gruszka

Oticon Polska Production (OPP)

Matematika 2, vzorová písemka 1

Kvalita z oceli Jakość ze stali

Wyzwania interoperacyjności

LEPSZE GROMADZENIE I WYKORZYSTANIE DANYCH BHP

Transkrypt:

Procesní standardy Radek Mařík CA CZ, s.r.o. September 14, 2007 Radek Mařík (Radek.Marik@ca.com) Procesní standardy September 14, 2007 1 / 32

Obsah 1 Koncept 2 Hodnocení softwarového procesu SEI a SPR hodnocení Malcolm Baldrige hodnocení ISO 9000, IEEE/ANSI Radek Mařík (Radek.Marik@ca.com) Procesní standardy September 14, 2007 2 / 32

Koncept, Standardy kvality [Kan95] 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 September 14, 2007 4 / 32

Koncept Nezralé vs. Vyspělé softwarové organizace [PCCW93] 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 September 14, 2007 5 / 32

Základní koncepty [PCCW93] 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 September 14, 2007 6 / 32

CMMI [PCCW93] 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 September 14, 2007 8 / 32

5 úrovní vyspělosti softwarového procesu [PCCW93] 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 September 14, 2007 9 / 32

Charakteristiky 5 úrovní vyspělosti [PCCW93] 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 September 14, 2007 10 / 32

Charakterizace chování na úrovni vyspělosti 1 [PCCW93] 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 September 14, 2007 11 / 32

Charakterizace chování na úrovni vyspělosti 2 [PCCW93] 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 September 14, 2007 12 / 32

Charakterizace chování na úrovni vyspělosti 3 [PCCW93] 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 September 14, 2007 13 / 32

Porozumění úrovním vyspělosti [PCCW93] 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 September 14, 2007 14 / 32

Viditelnost do softwarového procesu [PCCW93] 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 September 14, 2007 15 / 32

Schopnost procesu [PCCW93] Čí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 September 14, 2007 16 / 32

Přeskakování úrovní [PCCW93] 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 September 14, 2007 17 / 32

Operační definice CMMI [PCCW93] 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 September 14, 2007 18 / 32

Struktura CMMI [PCCW93] 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 September 14, 2007 19 / 32

Kĺıčové procesní oblasti [PCCW93] 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 September 14, 2007 20 / 32

Kĺıčové procesní oblasti, obecné vlastnosti, kĺıčové praktiky [PCCW93] 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 September 14, 2007 21 / 32

Příklad kĺıčové praktiky [PCCW93] 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 September 14, 2007 22 / 32

Kĺıčové procesní oblasti úrovně 2: Opakovatelné [PCCW93] Ří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 September 14, 2007 23 / 32

Hodnocení softwarového procesu Hodnocení SPR a SEI [Kan95] 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 September 14, 2007 25 / 32

Hodnocení softwarového procesu Okruhy SPR otázek [Kan95] 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 September 14, 2007 26 / 32

Hodnocení softwarového procesu Malcolm Baldrige hodnocení [Kan95] 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 September 14, 2007 28 / 32

ISO 9000 [Kan95] 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 September 14, 2007 30 / 32

Hodnocení softwarového procesu ISO 9000, IEEE/ANSI IEEE/ANSI Standardy softwarového procesu [Kit95] 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 September 14, 2007 31 / 32

Literatura I Hodnocení softwarového procesu ISO 9000, IEEE/ANSI Stephen H. Kan. Metrics and Models in Software Quality Engineering. Addison-Wesley, 1995. Edward Kit. Software Testing in the Real World. Addison-Wesley, 1995. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, and Charles V. Weber. Capability maturity model for software, version 1.1, cmu/sei-93-tr-024, esc-tr-93-117. Technical report, Software Engineering Institute, February 1993. Radek Mařík (Radek.Marik@ca.com) Procesní standardy September 14, 2007 32 / 32