Bezpečný softvér agilným vývojom

Vývoj nového softvéru je náročná a komplexná záležitosť. Na zlepšenie predvídateľnosti a možnosti manažovať IT projekty sme ako komunita vymysleli a zaviedli množstvo štandardov a procesov. Stále však nemôžeme porovnávať túto oblasť s procesmi vo výrobe. Vo výrobe totiž po navrhnutí procesu výroby produktu prichádza fáza overovania a ladenia, a tak po niekoľkých iteráciach môžeme vidieť pomerne efektívny a stabilný proces, kde na konci linky vychádza produkt v pravidelných intervaloch s minimom odpadu a nedorobkov – či už je to mobilný telefón, alebo hoci aj automobil.

Na druhej strane pri vývoji softvéru môžeme každú jednu požiadavku považovať za nový výrobok, ktorý v konečnom dôsledku pri integrovaní do celku tvorí výsledný produkt. Každá požiadavka je jedinečná a ich variabilita je obrovská. Postup používaný pri ladení linky na výrobu fyzického produktu teda nebude fungovať. Existuje ale niekoľko prístupov, ako sa snažíme tento problém riešiť. Pokiaľ softvér nie je kritický, a teda nehrozí, že by jeho nedokonalosť ohrozila zdravie ľudí alebo spôsobila obrovskú finančnú ujmu, používame takzvané agilné procesy. Implementovaním týchto procesov dokážeme pomerne v krátkom čase vytvoriť stabilný softvér presne podľa požiadaviek v stanovenom čase a za odhadované náklady.

Vývoj kritického softvéru a agilný prístup

Čo ale v prípade, že sa jedná o kritický softvér, na ktorý sú kladené extrémne požiadavky z pohľadu spoľahlivosti (napríklad dostupnosť 99,95% počas životnosti produktu), bezpečnosti alebo výkonu? Niektoré oblasti si totiž nemôžu dovoliť chyby v softvére, pretože tieto môžu spôsobiť zranenie, smrť, alebo škody veľkého rozsahu. Takými sú napríklad automotive, medical, industry a iné.  

Štandardy kladené na vývoj softvéru pre tieto použitia vyžadujú komplexný prístup definovaný takzvaným V-modelom. Tento model požaduje najskôr definovanie systémových požiadaviek, systémovej architektúry, softvérových požiadaviek a návrhu. Až potom sa pristupuje k samotnej implementácii, ktorá je následne testovaná na rôznych úrovniach.

Intuitívny prístup nám káže v tomto prípade venovať najskôr čas na analýzu všetkých požiadaviek a na základe tejto analýzy navrhnúť systémové požiadavky. Tieto požiadavky následne preveriť a vyšperkovať v sérii reviews a potom sa venovať návrhu systémovej architektúry. Mnohí poznáte tento prístup pod názvom waterfall systém. Zo skúsenosti už vieme, že tento systém avšak neprináša potrebné výsledky.

Aké sú teda možnosti? Na našom projekte sme tento problém riešili prispôsobením (tailoring) agilného prístupu. Nejedná sa však o ScrumBut, kedy sa namiesto funkčného agilného systému implementujú mnohé kompromisy, ktoré v konečnom dôsledku zničia pôvodne dobre navrhnutú a zloženú sadu pravidiel. Pri prispôsobenom agilnom prístupe máme celý projektový tím rozdelený do takzvanej systémovej a softvérovej časti. 

Systémový tím pozostáva zo skupiny analytikov a product ownera, ktorý ich združuje a synchronizuje ich aktivity. Na druhej strane softvérový tím pozostáva z niekoľkých nezávislých,  tzv. cross-component, cross-functional feature tímov. Znamená to, že každý implementačný tím má zastúpené role potrebné na vytvorenie celej škály artefaktov požadovaných vývojovým štandardom. Patria sem requirement inžinier, softvérový architekt, developer, tester a v neposlednom rade scrum master, ktorý je zodpovedný za vývojový proces v tomto tíme.

Systémový tím potom pracuje v šesťtýždňových iteráciách, počas ktorých analytici analyzujú a vyjasňujú požiadavky. Následne prichádza softvérový tím, ktorý dané systémové požiadavky implementuje v troch dvojtýždňových iteráciách. Počas implementácie systémový tím pracuje na požiadavkách pre nasledujúce 3 dvojtýždňové iterácie. Takto fungujú oba tímy paralelne bez prestojov.

Ako uchopiť odovzdávanie know-how?

Vyzerá to jednoducho, ale pozornosti skúseného čitateľa určite neušla typicky problematická operácia odovzdávania know-how medzi týmito dvoma skupinami. Aby sme predišli klasickým neduhom pri odovzdávaní know-how, máme navrhnutú sadu opatrení, ktoré nám pomáhajú vykonať túto kľúčovú aktivitu s čo najmenšou stratou informácií a času:

• Séria workshopov od analytikov pre implementačné tímy. Tu každý analytik predstaví, aké zmeny sa plánujú v oblasti, ktorú má na starosti. Workshop je energeticky náročná a drahá aktivita, lebo sa na ňom zúčastňuje takmer celý tím, takže time management a poctivá príprava sú kľúčové faktory úspechu.
• Analýza systémových požiadaviek softvérovými architektmi, ktorí sú súčasťou implementačných tímov; toto je offline aktivita, kedy architekti prechádzajú na workshopoch systémové požiadavky, musia ich pochopiť a navrhnúť koncept riešenia. Tento koncept je zaznamenaný formou softvérových tiketov, zoradených podľa priority v produktovom backlogu.
• WHAT plánovanie, kde sa znova jednou, dvoma vetami predstaví funkcionalita. Tím má možnosť sa pýtať otázky a analytik so softvérovým architektom odpovedajú. Ako názov stretnutia napovedá, primárne zameranie je na otázku ČO, ale prípustné sú aj krátke úvahy v prípade otázok AKO.
• HOW plánovanie je už interná udalosť tímu. Cieľom je navrhnúť detailné riešenie a vytvoriť plán, kto sa bude venovať ktorej functionalite.

Skúsenosti z prebiehajúceho projektu ukazujú, že takáto synchronizácia, napriek istej časovej náročnosti, prináša svoje ovocie v podobe hladkého priebehu a dobrej predvídateľnosti, akým tempom sme ako tím schopní pracovať.