Riziky řízený vývoj software Jaroslav Procházka Katedra informatiky a počítačů, Přírodovědecká fakulta, Ostravská univerzita v Ostravě / Tieto Corp., 701 03 Ostrava Jaroslav.prochazka@osu.cz Abstrakt Neřešená rizika softwarových projektů jsou jednou ze základních příčin selhání projektů, ať už se jedná o překročený rozpočet, dobu trvání projektu či nekvalitní produkt. Risk management používaný v dnešních softwarových projektech je spíše evidencí faktů (důsledky neřešených rizik se k překvapení všech zúčastněných objevují stejně). Článek se zabývá riziky řízeným vývojem software a prakticky vysvětluje, jakým způsobem je možné snížit pravděpodobnost výskytu rizik na akceptovatelnou úroveň. Tento přístup pomáhá omezit ztráty a problémy generované neřešenými riziky na minimální úroveň. Klíčová slova: riziky řízený vývoj, správa a řízení rizik, OpenUP, RUP, CRT. Abstract One of the software development project s failures root causes are not identified and not solved risks. These failures are visible as project s over-time, over-budget and/or poor quality of the product. Today s risk management is rather fact evidence (and people are surprised when risks generate consequences with high impact). This article deals with risk driven software development and explains practical risk mitigation approach leading to acceptable risk level. Such an approach minimizes costs and losses generated by not identified and/or solved risks. Keywords: risk driven development, risk management, OpenUP, RUP, CRT. Rizika a reaktivní přístup Oblast vývoje software prodělala za několik posledních desítek let obrovský rozmach a posun od ad hoc vývoje k rigidním a agilním přístupům dneška. Jednou ze zásadních změn bylo zaměření se na rizika projektu a jejich eliminace či snížení na akceptovatelnou úroveň. Neřešená rizika softwarových projektů jsou jednou ze základních příčin selhání projektů, ať už se jedná o překročený rozpočet, dobu trvání projektu či nekvalitní produkt. Risk management je velmi používané slovo a seznam rizik existuje v každém projektu, většinou proto, že jej vyžadují firemní procesy nebo zákazník. Ve skutečnosti jsou tato rizika spíše fakta a akce na odstranění či snížení rizik jsou převážně monitorovací (pokud vůbec nějaké existují). Důsledky neřešených rizik se k překvapení všech zúčastněných objevují stejně, i když dělají risk management. Risk management tak, jak ho známe například z Rational Unified Process (dále již jen RUP) [1], [5] potažmo z OpenUP [6] zná a skutečně provádí málokdo. Podle Project Management Institute (PMI) je riziko definováno následovně [2]: Riziko je nejistá událost či podmínka, která pokud nastane, má negativní nebo pozitivní dopad na jeden nebo více cílů projektu. SYSTÉMOVÁ INTEGRACE 1/2009 7
Jaroslav Procházka Software Engineering Institute (SEI) zmiňuje v [3]: Při vývoji software je riziko něčím, co může snížit, kompromitovat úspěch projektu. Z uvedených definicí vyplývá, že rizika jsou události, které mohou nastat a nějakým způsobem ovlivnit úspěch či cíle našeho projektu (nízká kvalita produktu, nespokojenost zákazníků, překročený rozpočet či délka projektu). V projektech je běžné, že se o riziku dozvíme, až v momentě, kdy nastane a způsobí viditelné problémy. Říká vám něco z následujících sdělení? Po doručení aplikace se nejsme schopni napojit na externí systémy. Nová technologie způsobí nečekané komplikace, nutnost předělání části kódu. Nedostupná dokumentace externích systémů zpozdí vývoj. Reaktivní přístup k rizikům má několik důsledků: vývoj (či provoz a údržba) je dražší, jedná se o hašení požárů, neřešíme příčiny ale důsledky, pozdní odhalení problémů (až když nastanou), překročené limity (rozpočet, doba projektu, SLA 1 ), přetížení zaměstnanci. Riziky řízený vývoj software je proaktivní, snažíme se identifikovat rizika co nejdříve. Hlavní rozdíl však tkví v přístupu k identifikovaným rizikům. Cílem není pouhá identifikace události, která nás může ohrozit, ale navrhnout akce na její odstranění, na snížení dopadu na (peněžně, časově) akceptovatelnou úroveň, případně riziko přesunout na externí subjekt (subdodavatel, zákazník) nebo definovat náhradní řešení (tzv. contingency strategy), pokud se nic z předchozího nepodaří nebo prostě provést nelze. Tento proaktivní (riziky řízený) přístup má o mnoho větší dopad, než je na první pohled zřejmé. Obr. 1 popisuje situaci na projektech s nevhodným či chybějícím risk managementem. Použili jsme nástroj z teorie omezení zvaný Current Reality Tree (CRT), který zobrazuje týmem viditelné problémy a pomáhá identifikovat jejich (většinou netušené) příčiny a důsledky. Červeně zobrazené objekty jsou zmíněny zainteresovanými na projektu jako viditelný problém. Objekty z nich vycházející jsou důsledky. Takže například důsledkem neřešených příčin incidentů jsou znovu se opakující incidenty a chyby aplikace, což má za následek nespokojeného zákazníka a také dražší projekt. Další typický problém jsou přetížení zaměstnanci. Lidé pod tlakem či s nedostatečnými informacemi (např. neznalost softwarové architektury systému) přijímají špatná rozhodnutí, v tomto případě myšleno hlavně technického charakteru. Stejně tak můžeme jít opačně. Co je příčinou toho, že jsou zaměstnanci přetíženi? Proč neřešíme příčiny incidentů a jen hasíme požáry? Tím identifikujeme nejnižší, kořenovou příčinu na jejiž odstranění se pak zaměříme. 1 SLA (Service Level Agreement) popisuje dohodnuté IT služby poskytované zákazníkovi a jejich kvalitativní parametry (dostupnost, dobu podpory, maximální počty incidentů za čas apod.). 8 SYSTÉMOVÁ INTEGRACE 1/2009
Riziky řízený vývoj software Obr. 1: Current Reality Tree (CRT) projektu s neřešenými riziky Z CRT je tedy zřejmé, že příčina (reaktivní risk management) má (nebo může mít) za následek zpoždění projektů, překročení rozpočtu, přetížené zaměstnance a také nespokojeného zákazníka. Kdo z výkonných či projektových manažerů si je důsledků takovéhoto risk managementu vědom? Lidé jsou tímto těsným propojením většinou překvapeni. Tolik nám snad k motivaci stačí. Pojďme se tedy podívat, jak risk management dělat při vývoji software v praxi. Více o problematice risk managementu lze nalézt například v [7], [8], [9] či [5]. My se dále budeme zabývat problematikou rizik v kontextu iterativního a inkrementálního vývoje softwarových aplikací a jeho praktickou aplikací. Rizika a akce Pomocí CRT jsme tedy identifikovali příčiny problémů na projektech z pohledu identifikace, správy a řízení rizik. Z CRT a praxe můžeme shrnout nejčastější chyby riziky řízeného vývoje: fakta jsou uváděna jako rizika, nejsou navrženy akce na snížení dopadu/odstranění rizika (případně contingency plány), navržené akce jsou velmi vágní či neúčinné, rizika nejsou průběžně monitorována a vyhodnocována. SYSTÉMOVÁ INTEGRACE 1/2009 9
Pravděpodobnost Dopad Priorita Jaroslav Procházka Příklad typického rizika ukazuje následující tabulka: ID X Riziko Implementační tým nemá zkušenost s použitou technologií Pravděpodobnost Dopad Priorita Akce HI HI HI Tabulka 1: Příklad faktu místo rizika a nedostatečných akcí 1/ Pošleme členy týmu na školení 2/ Monitorujeme průběh implementace Co je špatného na takto definovaném riziku? Předně je zde nezkušenost týmu s technologií interpretována jako riziko, ve skutečnosti je to fakt, který již nastal a nemůžeme s ním nic dělat. Máme k dispozici tým vývojářů, kteří v dané technologii ještě nikdy nenavrhovali ani neprogramovali nebo ji znají pouze z prostředí univerzitních lavic. Rizikem je však něco jiného, událost, která může na základě tohoto faktu v budoucnu nastat a ohrozit úspěšné doručení projektu (chybovost produktu, těžce implementovatelné změny díky nevhodné architektuře, překročení termínu dodání). Druhým důležitým krokem je nejen riziko správně identifikovat a formulovat, ale hlavně navrhnout akce na snížení jeho dopadu či úplné odstranění (samozřejmě cenově ospravedlnitelné, což je také důležité). Akce uvedená v předchozí tabulce nám moc nepomůže. Pouhé školení neudělá z juniora zkušeného programátora a monitoring nám již pouze oznámí, že jsme ve skluzu či už nejsme dál schopni pokračovat. Abychom byli schopni riziko dopadu neznalosti technologie na úspěšné doručení snížit, musíme definovat konkrétní kroky, které nám řeknou: ano jsme schopni projekt dokončit, ne nejsme schopni projekt dokončit. Podívejme se na lepší příklad rizik a dohodnutých akcí z reálného riziky řízeného projektu: ID Fakt Riziko Akce na snížení dopadu / odstranění rizika 1 2 Implementační tým je nový v problémové doméně Tým nemá zkušenost s technologií (jbpm, jasper,...) Možné nepochopení byznys procesů a požadavků = dodán produkt neřešící potřebu zákazníka Dodán nekvalitní, hůře udržitelný produkt, resp. nemožnost naplnění kritických (prioritních) požadavků zákazníka HI HI HI MI HI HI 1/ Implementace těchto kritických use case. 2/ Analytici sedící v prostorách zákazníka. 3/ Zástupci zákazníka jako testeři. 4/ Vytvářet Business Process diagramy přímo v jbpm notaci místo stavových diagramů vytvářených nyní. 1/ Implementace kritických use case 2/ Vytvoření prototypu ověřující komunikaci a funkčnost WebSphere Portal a jbpm (aplikace správně reaguje na stavy a jejich změny přijaté z jbpm) 3/ Konzultace / najmutí programátora se zkušeností s danou technologií do role architekta 10 SYSTÉMOVÁ INTEGRACE 1/2009
Pravděpodobnost Dopad Priorita Riziky řízený vývoj software ID Fakt Riziko Akce na snížení dopadu / odstranění rizika 3 Neexistující testeři Nedefinován a neověřen testovací přístup/proces Nezkušenost s automatiza cí testování Netestované či slabě testované řešení => nesplnění kritických požadavků zákazníka (masivně testovaný produkt jako jeden z nefunkčních požadavků) + nízká kvalita produktu HI HI HI 1/ Definovat testovací postup (co, jak, kdy, kým). 2/ Ověřit testovací postup na prototypu. 3/ Zástupce/i zákazníka jako testeři funkčnosti. 4/ Analytici jako testeři funkčnosti. 5/ Inkrementální automatizace testů (hlavně nefunkčních) 6/ Mentoring v dané oblasti Tabulka 2: Příklad seznamu rizik a mitigačních akcí z reálného projektu Rizika (viz Tabulka 2) jsou spojena s atributy (mohou je negativně ovlivnit), které definujeme jako úspěšné doručení softwarového produktu: dodržen dohodnutý rozpočet, produkt doručen v dohodnutém čase, produkt je kvalitní = bez velkého množství chyb, jednoduše rozšiřitelný a udržitelný, produkt obsahuje zákazníkem očekávané chování, funkčnosti. Zvláštní sloupec fakta nám pomáhá identifikovat rizika a vyhnout se jejich záměně za rizika. Akce jsou již v tomto případě konkrétní kroky, které musíme co nejdříve provést, abychom se dozvěděli, zda jsme schopni úspěšně doručit s danou technologií, v dané kvalitě, za danou cenu a v daném čase. Pokud ne, máme možnost technologii či osazení týmu změnit, zmenšit rozsah projektu či provést jiné akce, jelikož jsme stále v úvodních iteracích projektu! Pokud navíc ani jedno z předchozího nelze, pak vyjde ukončení projektu nyní mnohem levněji. Toto je velkou výhodou riziky řízeného projektu. Pokud by riziko již skutečně nastalo v průběhu implementačních či integračních prací, nemůžeme dělat téměř nic, resp. jsou tyto akce velmi nákladné. Oblasti, ve kterých můžeme hledat rizika jsou následující: požadavky (měnící se, jejich nepochopení, naplnění, testování), návrh a použité technologie (vhodná architektura, rozhraní na externí systémy), proces vývoje a testování (způsob práce, testování), pracovní prostředí (distribuovaný vývoj, nástroje, automatizace), zdroje, kontrakty, závislosti a omezení projektu. Pro každé identifikované riziko musíme dopředu uvažovat jakou cenově efektivní strategii či akci zvolit, v úvahu přicházejí následující tři oblasti: předcházení (avoid) riziku reorganizace projektu tak, abychom riziku předešli (typicky změna členů týmu či technologie, nábor konzultanta na doménu apod.), SYSTÉMOVÁ INTEGRACE 1/2009 11
Jaroslav Procházka přesun (transfer) rizika reorganizace projektu tak, aby jiný subjekt přebral a nesl riziko (zákazník, subdodavatel, banka), snížení dopadu (mitigate) rizika rozhodnutí, že s tímto rizikem se dá pokračovat, pak: o přijmeme alespoň nějaké proaktivní kroky a monitorujeme zda se již neobjevily symptomy rizika (abychom byli připraveni použít contingency plán), o definujeme contingency plán (akce a náhradní řešení), který použijeme v případě že riziko nastane. Rámec pro řešení rizik fáze Elaboration Iterativní projekt se skládá z řetězce iterací, kdy výstup předchozí iterace je vstupem pro iteraci následující. Časově ohraničenými úseky (iteracemi), neustálou spoluprací týmů a omezeným obsahem implementace se snažíme eliminovat plýtvání, práci do šuplíku, paralýzu analýzou a další důsledky vodopádových přístupů. Projekt jako pouhý sled iterací a návrh pro pouze aktuálně známé požadavky by však byl krátkozraký a vyžadoval by zásadní refaktoring v každé další iteraci. V rámci vývoje software musíme dělat jistý konceptuální návrh architektury (tím myslíme i implementaci to je jediné ověření schůdnosti návrhu), která je nejvhodnější pro daný projekt. K dosažení výše zmíněných cílů nám slouží fáze, které seskupují iterace za různým účelem 2 : Inception zaměřena na nalezení shody na cílech projektu (vize), identifikace rizik, definice roadmap, vytvoření týmu. Elaboration zaměřena na snížení rizik a implementaci architektury včetně kritických scénářů aplikace. Construction zaměřena na inkrementální vývoj zbývajících scénářů aplikace na základě vytvořené architektury. Transition zaměřena na předání výsledku zákazníkovi, akceptační testy, školení, doladění dokumentace. V životním cyklu iterativního vývoje software je tedy pro řešení rizik určena tzv. Elaboration (Rozpracování) fází. Můžeme si všimnout, že RUP či OpenUP nejsou jen zřetězením iterací jako např. XP či Scrum. Seskupení iterací do fází má důležitý přínos v zaměření se na rizika a architekturu, nejedná se tedy o pozůstatek vodopádu, jak tyto fáze popisuje mnoho autorů. Obr. 2 ukazuje, jakým způsobem a kdy se zaměřujeme na rizika. Akce definované v seznamu rizik, a prioritní, na implementaci kritické scénáře jsou první, které musíme provést, abychom snížili úroveň rizik na akceptovatelnou úroveň (viz křivka). Akce ze seznamu rizik a implementace kritických scénářů se tedy stanou cíli jednotlivých iterací seskupených do Elaboration fáze. Cílem je vyzkoušet technologii, pokusit se implementovat složité algoritmy, vyzkoušet různé druhy architektury, abychom případně mohli zasáhnout a zvolit technologii, architekturu jinou, abychom věděli, zda jsme pochopili doménu, zda je tým schopný pracovat 2 Pojmy z Rational Unified Process (RUP), resp. OpenUP [1], [5], [6]. 12 SYSTÉMOVÁ INTEGRACE 1/2009
Riziky řízený vývoj software v těchto podmínkách 3. V případě, že neexistují varianty, nelze pokračovat dále a tudíž jsme nuceni projekt ukončit, toto díky riziky řízenému přístupu zjistíme velmi brzy a nestojí nás neúspěch projektu tolik. V úspěšném případě budeme mít na konci Elaboration fáze k dispozici implementovanou a otestovanou architekturu = část produktu (podle typu projektu od 20 do 60% celkového řešení). Díky tomuto postupu můžeme v Construction fázi použít více vývojářů a vyvíjet zbytek produktu relativně bez překvapení. Obr. 2: Hladina rizika u iterativních projektů a vodopádu a její mapování na životní cyklus projektu Risk management ale nekončí Elaboration fází. Na začátku každé iterace, v rámci tzv. iteračního plánování týmu (iteration planning) se vždy snažíme zjistit, jestli nevyvstalo riziko nové a nemůže nás opět nějakým způsobem ohrozit, stejně tak 3 Srovnejte s klasickým přístupem, kdy např. ve dvou třetinách projektu zjistíme, že naše téměř hotová aplikace jde jen velmi těžko integrovat se zákazníkovými systémy. SYSTÉMOVÁ INTEGRACE 1/2009 13
Jaroslav Procházka tento krok opakujeme na konci iterace v rámci iteračního hodnocení týmu (iteration assessment). Takže stejně jako celý iterativně inkrementální postup vývoje software, je i risk management iterativní, neustále se opakující sled aktivit. Příklad iteračního plánu, jedné z prvních iterací v Elaboration fázi, reflektující risk management. Můžeme si všimnout, že snížení rizika R1 a R2 je cílem iterace, stejně jako akce z risk listu (viz Tabulka 2) jsou zařazeny v úkolech a mají konkrétní řešitele (odlišeny barevně). Plán iterace E1 Začátek iterace (plánovací meeting dané iterace): 6. 4. 2009 Konec iterace (demo, assessment): 20. 4. 2009 Cíle iterace: Implementace prototypu UC1 [BF] ověření technologie Snížení rizika R1 Odstranění rizika R2 Evaluační kritéria: 60 % kódu pokryto unit testy 100 % unit testů prošlo 70 % implementovaných funkčních testů prošlo Odstraněno riziko R2 Bylo předvedeno demo zákazníkovi Zákazník demo akceptoval Úkoly iterace E1: Název / Popis Priorita Odhad (body, čas) Přiřazeno Instalace build mechanismu (Maven) 2 2h Karel (architekt) Instalace a nastavení jbpm prostředí 2 8h Ivan (programátor) Instalace a nastavení Web- Sphere Portal a propojení s Karel jbpm 2 24h Vytvoření prostředí pro analytiky v prostorách zákazníka (místnost, VPN, vstupní karty) 1 25h Popis hlavních byznys procesů v jbpm 1 8b Analýza scénáře UC1 (BF) 2 8h Návrh scénáře UC1 (BF) a implementace prototypu ověření technologie a schopností týmu 1 8b Testy prototypu UC1 (BF) 2 6b Sestavení dema pro hodnocení iterace (assessment) 3 5b IBM support Lucie (projektová manažerka) Josef (zástupce zákazníka) Petr (analytik) Julie (reprezentant uživatelů) Petr Julie Karel Petr Ivan (programátor) Petr Ivan Ivan Petr 14 SYSTÉMOVÁ INTEGRACE 1/2009
Riziky řízený vývoj software Závěrem Článek se zabývá riziky řízeným přístupem k vývoji software. Ukázali jsme, že jednou z příčin selhání softwarových projektů (překročený rozpočet/doba trvání projektu, nekvalitní produkt, neschopnost dodat produkt) jsou neřešená rizika či slabé, vágní akce na jejich snížení či odstranění. Dnešní risk management je spíše evidencí faktů s reaktivním přístupem. Představili jsme tedy proaktivní variantu k identifikaci a řízení rizik, která snižuje úroveň rizik na akceptovatelnou úroveň již v úvodních fázích projektu. Iterativní a inkrementální způsob vývoje software definuje tzv. Elaboration fázi, jejíž cílem je zaměření se na nejrizikovější oblasti a produktem této fáze je vhodná implementovaná a otestovaná architektura. Akce navržené na předcházení, snížení rizik se stávají reálnými úkoly jednotlivých členů týmu v brzkých fázích projektu. Výhodou proaktivního přístupu k rizikům je dřívější identifikace problémů, nižší náklady na jejich řešení, možnost změnit tým, technologii, rozsah projektu. Použité zdroje [1] Kroll, P. and Kruchten, P.: The Rational Unified Process Made Easy, 1st Edition Addison-Wesley, 2003. [2] PMI04: Project Management Institute, A Guide to the Project Management Body of Knowledge, Third Edition, 2004. [3] SEI: Software Risk Evaluation (SRE) Method Description, v2.0 SEI, 1999 http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr029- body.pdf#search=%22software%20risk%20evaluation%22 [4] Schwaber, K.: Agile Project Management with Scrum. 1st Ed. Microsoft Press. 192 p. 2004. ISBN 073561993X. [5] Kroll, P. and MacIsaac B.: Agility and Discipline Made Easy: Practices from OpenUP and RUP. 1st Edition Addison-Wesley. 448 p. 2006. ISBN 0321321308. [6] OpenUP. Dostupné na: [http://www.eclipse.org/epf/]. [7] Barry W. Boehm 1991. Software Risk Management: Principles and Practices, IEEE Software, Jan. 1991, IEEE, pp.32-41. [8] Marvin J. Carr, et al. 1993. Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, Pittsburgh, PA, SEI, June 1993. [9] Robert Charette 1989. Software Engineering Risk Analysis and Management. New York, NY: McGraw-Hill. [10] Poppendieck, M., Poppendieck, T.: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley 2006. 304 str. ISBN 0321437381. [11] Procházka, J.: Ročníkový projekt 1, 2. Elektronický učební text. PřF. Ostravská univerzita. Dostupné na: [http://albert.osu.cz/oukip/prochazka/xrop/index.html]. SYSTÉMOVÁ INTEGRACE 1/2009 15