Kvalita procesu vývoje (SW) Jaroslav Žáček

Transkript

1 Kvalita procesu vývoje (SW) Jaroslav Žáček

2 Vývoj software a jeho kvalita Samotný vývoj je rozsáhlá a složitá disciplína. Většina SW projektů (v průměru 60 %) je podhodnocena či zpožděna. Důvody: disciplína vývoje SW je relativně nová SW je v principu jiný produkt (oproti stavebnictví, automobilovému průmyslu) každý SW na zakázku je unikátní vzdáleně podobný výzkumné činnosti, vytváření duševního vlastnictví, ovšem je kladen velký důraz na kvalitu...

3 Jak je definována kvalita? Existuje spoustu definicí (odezva zákazníků, certifikace). Definice: Kvalita je stupeň spokojenosti zákazníka při kombinaci různých faktorů. Faktory (nejčastěji tvrdé metriky): počet chyb v produktu zpoždění zavádění změn délka záruky dostatečná podpora

4 Zajištění kvality QA (Quality assurance) - vytvoření a správa aktivit, které můžou pomoci dodržet požadovanou kvalitu Existuje univerzální návod? Možné způsoby: zaměření na procesy a jejich zlepšení metody pro minimalizaci chyb v kódu hlídání rizik projektu (risk list) správa požadavků a změn...

5 Tři hlavní pilíře kvality Měří, monitoruje a spravuje procesy CMMI Six Sigma Optimalizuje procesy Knowledge management Data přetváří ve znalosti

6 Zajištění kvality Existuje spoustu aktivit pro zajištění kvality. Existuje spoustu technologií pro řízení kvality. Zákazníci požadují implementaci technik od dodavatelů. ISO 9001:2000 QS 9000 PMBOK CMMI Prince 2

7 Co je CMMI CMMI - Capability Maturity Model (Integration) Je to model kvality určený pro vývojové týmy. Definuje oblasti pro zlepšení a cíle, kterých se má pro zlepšení dosáhnout. Samotný model je zdarma, certifikace už ne (cca 2000$/ den práce).

8 Proč CMMI (nebo jiný model kvality)? Zákazníci ho zpravidla vyžadují, bez certifikace nezískáte zakázku. Ostatní přínosy: Je to dobrá značka (viz. všichni chtějí ISO 9001). Minimalizuje chyby v procesu. Zlepšuje kvalitu doručeného produktu - zvyšuje přidanou hodnotu a šetří peníze. Zlepšuje projektové řízení.

9 Jak se vytváří standard Zeptejte se společností (SW) na jejich zkušenosti. Analyzujte současné i minulé projekty. Vytvořte sadu doporučení (best practices). Definujte standard... a vytvoříte CMM

10 CMM/CMMI Vytvořeno SEI na Carnegie Mellon University v roce 1991 (verze 1.0). Financováno grantem Ministerstva obrany (DoD) pro jejich projekty (vzpomeňte na vodopád). Je zaměřen na definici, standardizaci a neustálé vylepšování vývojového procesu.

11 Historie CMM v1.0 SW-CMM (software development) P-CMM (people management) SA-CMM (software acquisition) V roce 2000 integrovány ostatní modely (SPICE=ISO ) s SW a SE - v1.1 SW-CMM (software development) SE-CMM (system engineering)... V roce 2006 verze 1.2, reprezentace SW a SE jsou spojeny od jednoho pohledu. V roce 2012 verze 1.3, přidává agilní způsob vývoje.

12 Použití Jedná se převážně o americký standard 50% certifikací na CMMI pochází z USA Je vyžadován pro vládní zakázky Japonsko se také zaměřuje na kvalitu 30% certifikací na CMMI Certifikaci procesů vyžadují odběratelé Indie tzv. software factory 10% certifikací

13 Použití Evropa je v implementaci standardů kvality odlišná EU (vč. CZ) se zaměřuje převážně na ISO normy. Vývoj SW nemá dlouhou tradici v porovnání s USA. Důvod pro zavedení CMMI je převážně vstup na trh v USA, v regionu CE, EE navíc levní programátoři a kvalita je konkurenční výhodou.

14 Vyzrálost procesů

15 Vyzrálost procesů

16 Příklad - oblast bezpečnosti

17 Proces / procesní oblasti (PA) Fakticky v CMMI není žádný proces. Rozděleno do Procesních oblastí - ve verzi 1.3 je jich 22. PA jsou přítomny v každé úrovni modelu (levels). Level 2-7 oblastí Level 3-11 oblastí Level 4-2 oblasti Level 5-2 oblasti PA jsou sdruženy ve skupinách např. level 2 má 4 PA pro podporu procesů a 3 PA pro projektové řízení

18 Organizace CMMI Skládá se ze čtyřech základních skupin: 1.Project management 1.Jak naplánovat projekt 2.Jak sledovat projekt 3.Jak sledovat a řídit rizika 2.Process management 1.Definice procesů společnosti 2.Jak měřit proces 3.Engineering 1.Jak na analýzu 2.Jak na kódování 4.Support processes 1.Jak definovat etalon pro měření 2.Jak udělat vnitřní audit

19 Skupiny CMMI

20 Skupiny a procesní oblasti

21 Příklad PA a skupiny na úrovni 2 Requirements management Project planning Project tracking Executive area Projekt Configuration management Quality assurance Measurement and analysis Support area

22 PA na úrovni 2 Requirements management (REQM) získání požadavků monitorování změn v požadavcích identifikaci rozporů v požadavcích Project planing (PP) odhad pracnosti vytvoření projektového plánu hlídání závazků v PP(např. milníky) Project monitoring and control (PMC) sledování projektového plánu řešení nesrovnalostí

23 PA na úrovni 2 Product and process quality assurance (PPQA) ohodnocení procesů a produktů provedení interních auditů Measurement and analysis (MA) měření procesů komunikace výsledků Supplier arguments management (SAM) ohodnocení dodavatele definuj proces pro nákup produktu

24 Cíle a praktiky Každá PA má definovány cíle (goals). Každý cíl má své praktiky (practices). Abychom dosáhli vyšší úrovně, musíme splnit cíle -> cíle jsou povinné. Splnění praktik je pouze doporučeno -> zde je prostor pro vlastní iniciativu/nové řešení CMMI definuje pro každou praktiku také pod-praktiku (sub-practices), která dodává typický výstupní produkt.

25 Příklad CMMI pro Configuration Management říká: 1.Musíte mít definovánu základní úroveň. 2.Musíte mít definováno řízení změn. 3.Musíte zajistit integritu } Cíle Pro bod 3) pak definuje např. uchovávejte záznamy o CM provádějte audit } Praktiky

26 Příklad L2, PA Configuration Management nám říká: 3. Musíte zajistit integritu (a doporučuje) uchovávejte záznamy o CM provádějte audit (což znamená) 1.vytvoř základní podmínky pro audit 2.zkontroluj reálný a plánovaný stav 3.zkontroluj procedury a jejich popis } sub-praktiky 4.hlídej produkty CM typický produkt: zpráva auditora

27 Konkrétní cíle a praktiky Konkrétní praktika Konkrétní cíl

28 Obecné cíle Obecné cíle (generic goals) se v podstatě překrývají s úrovní modelu. Pokud tedy model dosahuje úrovně 2, splňuje GG2 - Proces funguje jako řízený proces. Všechny praktiky v příslušné PA musí splňovat tento obecný cíl.

29 Obecné cíle Obecné cíle PA

30 Six Sigma

31 Příklad výroba špendlíku Kdo: Univerzální pracovník Co: Výroba špendlíku

32 Příklad výroba špendlíku Pracovník 1 Pracovník 2 Pracovník 3 Pracovník 4 Pracovník 5 Pracovník 6 Pracovník 7

33 Co je Six Sigma Metodika (framework) pro neustále zlepšování procesu. Metodika (framework) pro vytvoření kvalitních procesů / produktů. Soubor statistických a kvalitativních nástrojů. Aplikace vědeckých metod do podnikových procesů

34 Co Six Sigma není Není to žádný standard. Není to certifikace. Není to jen další metrika. nic víc, než aplikovaná statistika

35 Historie Pojem vzešel od Billa Smithe (Motorola) Počátky již v roce řešení problémů pomocí statistiky 1987 Motorola spouští program Six Sigma 1996 se připojuje GE

36 Historie a kombinuje změnové řízení se statistickou analýzou: Define Measure Analyse Improve Control DMAIC

37 Firmy využívající Six Sigma General Electric Motorola Texas Instruments Honeywell NASA HP USAF

38 Tři metodiky Six Sigma BPMS - Business process Management Service DMAIC - Zlepšování procesu DMADOV - Tvorba nového procesu, který poběží podle Six Sigma

39 BPMS Hlavní cíle: Pochopení procesů Poznání zákazníka a jeho očekávání Identifikovat, monitorovat a zlepšovat procesy

40 Životní cyklus

41 DMAIC

42 Define Odstupující zákazník Výstup

43 Measure Odstupující zákazník Kolik? Jak dlouho? Jak předvídatelně? Výstup

44 Measure?

45 Measure IQ populace Hmotnost fazolí Doba čekání Doba obsluhy

46 Analyse Odstupující zákazník Kolik? Jak dlouho? Jak předvídatelně? Výstup Doba čekání Doba obsluhy

47 Analyse Sloupcový a čárový graf

48 Improve Hledání nového řešení (většinou analyticky) Pilotáž nového řešení Identifikace tolerance na důležitých uzlech

49 Improve Dělba práce Nástroje a techniky: Kanban špagetový diagram Brainstorming Pugh Matrix (criteria-based matrix) simulační software

50 Improve

51 Control Nové univerzální řešení má zpravidla vždy nějakou výjimku Ne všichni nové řešení pochopí a akceptují Ověření, že nové řešení splňuje očekávání (statistical process control, control plan)

52 Procesní mapy, lineární regrese, Six Sigma - tři dimenze rovnoměrné normální rozdělení, Paretův graf Metodika Define Measure Analyse Improve Control Nástroje Organizace Řízeno požadavky zákazníka Vedeno managementem Zaváděno QA týmem

53 QA tým Master black belt - expert na Six Sigma, mentoruje méně zkušené, vede celý proces Black belt - vede komplexní nebo vysoce rizikové projekty, na projektu zaměstnán na plný úvazek, tvoří jádro procesů dle Six Sigma, mentoruje méně zkušené Green belt - menší projekty ve specifických oblastech, může pracovat i na částečný úvazek

54 Body pro implementaci

55 Lean Software Development

56 Lean Development Toyota TPS Toyota production system Základní koncepty - JIT a automatizace. V devadesátých letech známý jako tzv. Lean (štíhlý) přístup k výrobě. Snaží se omezit plýtvání (waste / muda- 無駄 ). Typ I - pro zákazníka žádná přidaná hodnota, ale nezbytný pro proces. Typ II - žádná hodnota pro zákazníka - snažíme se identifikovat a odstranit

57 Druhy plýtvání Transport - není nutné vždy přesouvat jednotlivé produkty, abychom něco vyrobili Inventory - nářadí vyžaduje kapitál, který nepřináší přímý zisk Motion - zbytečné pohyby zaměstnanců Waiting - čekání na doručení vhodného nástroje Overproduction - produkce na sklad, nadbytečná výroba Over processing - součástka má až zbytečně velkou kvalitu Defects - oprava výrobku je nákladná...jak tohle souvisí s tvorbou software?

58 Kontext Dlouhodobé myšlení Leadership a koučing Respekt

59 Struktura

60 Principy Lean Odstranění plýtvání. Kvalita je součástí procesu/produktu. Vytváření znalostí. Odložení rozhodnutí. Brzké doručení. Optimalizace celku.

61 Nástroje - VSM

62 Podnikový proces

63

64

65

66 Proces po optimalizaci

67 NÁSTROJE LEAN

68 5 Proč

69 5 Proč

70 5 Proč Hřídel :-)

71 5 Proč

72 *návěstní tabule (signboard)

73 Vývoj Od 40 let používáno v Toyotě, vytvořil Taichi Ohno Objevil se po formalizaci technik ukládání zboží do regálů (znáte ze supermarketů) Systém řízení poptávky s možností změny, když to obchod požaduje. Použití vizualizace je pro systém klíčové

74 Kanban Systém plánování pro produkci Založený na JIT Skrz vizualizaci limituje rozdělanou práci (WiP) V jednodušší formě je to tabule s lístečky Tabule reprezentuje aktuální stav projektu (projektový plán?) Na rozdíl od jiných vizualizací nařizuje limit pro WiP Zlehčuje identifikaci úzkého hrdla v procesu Zaměřuje se na minimalizaci zbytečné práce (waste)

75 Vodopádový Kanban

76 Motivace použití Workflow je pro nás většinou skryté, proto pomáhá vizualizace Umožňuje lidem vidět aktuální stav rozdělané a dokončené práce Většinou se používají user stories (story cards) Proces vývoje je rozdělen do sloupců - motivace k paralelismu

77 Kolaborace Aplikace populárních modelů (Theory of Constraints) a postupů (Lean, Six Sigma) Použití modelů pro predikci (team velocity) Aktuální a očekávaný výsledek může být použit pro zlepšení procesu Zlepšení kvality zaměřením se na menší počet úkolů

78 Základní pojmy Lead time - čas potřebný pro dokončení vlastnosti (feature) Cycle time - čas potřebný pro dokončení úkolu (task) Throughput - produktivita, definována jako počet vlastností doručených za konkrétní časový úsek WiP Limit Value Stream - vztahuje se k procesu vývoje software Swarm(ing) - spolupráce nad řešením problému

79 Story Card Slouží ke sledování vlastností/úkolů Podobný způsob získávání požadavků jako v XP V praxi se většinou nahrazuje post-it lístečky Barvami se odlišují na opravy (bugs), vlastnosti (features), úkoly (tasks), zlepšení (improvements) Realizuje vizualizaci dle principů Token-Inscription- Placement (

80 Control chart Cílem je minimalizovat čas potřebný pro jeden úkol

81 Flow chart

82 Todo

83 Todo In Progress

84 Todo In Progress Done

85 Todo AnalYze Done

86 Todo AnalYze WoRK Done

87 Todo AnalYze WoRK VERIFY Done

88 Todo AnalYze WoRK VERIFY Doing Done

89 Todo AnalYze WoRK VERIFY Done Doing Done

90 Todo AnalYze WoRK VERIFY Done Doing Done Doing Done

91 Todo AnalYze WoRK VERIFY Done Doing Done Doing Done

92 Todo AnalYze WoRK VERIFY Done Doing Done Doing Done

93 Todo AnalYze WoRK VERIFY Done Doing Done Doing Done WIP LIMITS!

94 Todo AnalYze WoRK VERIFY Done Doing Done Doing Done FLOW!

95 KANBAN BOARD

96 KANBAN BOARD

97

98 Dual-Track Scrum Nespoléhá se pouze na roli PO, ale snaží se co nejdříve vytvořit prototyp a ověřit ho (ověřit věci v backlogu) Hodnota (Valuable) (PO, BA) Použitelnost (Usable) (UX, Design) Proveditelnost (Feasible) (Dev, QA) Dual Track Discovery Track: generuje ověřené položky do product backlogu Delivery Track: generuje rozumný software

99 Dual-Track Scrum

100 Dual-Track Scrum

101 Dual-Track Scrum Output Discovery Validated Learning populated as user stories in backlog Delivery Working software Primary Work Method Concepts and Experimentation Engineering Work Steps Discover-Design-Validate Build-Test-Release Validation & Verification Validation Verification Focus Building the Right Product Building the Product Right Measure of Success Outcomes Velocity Lean Approach Measure of Success Views unused Features as waste Valuable, Usable and Feasible software View unnecessary documentation as waste Working software

102 Scrumban Původně navržen jako proces pro přechod ze Scrumu na Kanban Metody: Bucket size planning - dlouhodobé plánování Lead and cycle time - měření času od přiřazení úkolu po jeho dokončení On demand planning - když úkoly v části To Do klesnou před předem dohodnuté číslo, vyvolává se nové plánování

103 Bucket size planning

104 Jak funguje release

105 Scrum vs. Scrumban