DOZOR?!
A proč i software potřebuje stavební dozor? Třeba z důvodu, který popsal Melvin Conway již v roce 1967, tedy že organizace vytvářející software produkují architektury limitované svojí vlastní organizační strukturou. Takže například zadáte-li firmě sestávající ze tří týmů úkol vytvořit nový kompilátor, můžete si být jisti, že přijdou s unikátním třífázovým kompilátorem (tedy složitým a pomalým).
Ať již máte schopného architekta a chcete zjistit, zda jste na správné cestě, nebo tuto roli nikdo neplní a za dlouhodobá rozhodnutí nikdo neodpovídá? Nebo váš IT systém vyvíjí externí dodavatel a vám nezbývá než věřit jeho slibům? Anebo dokonce vidíte patologické projevy dysfunkčnosti projektového týmu, kde si každý stojí na své subjektivní pravdě a není kdo by spor rozhodl?
Neházejte ručník do ringu a přizvěte si „stavební dozor“. Naštěstí totiž existují metody, jak situaci objektivně analyzovat a sestavit seznam nápravných opatření, minimalizovat rizika a zaručit, že software bude podporovat firmu v jejím růstu, místo aby ji v rozvoji omezoval.
Jednou z takových metod je Architecture Trade-off Analysis Method (ATAM) vyvinutá na Carnegie Mellon univerzitě. Její podstata tkví v inventarizaci architektonických rozhodnutí (ať již byla učiněna vědomě nebo nevědomě/implicitně), validaci předpokladů, na jejichž základě byla rozhodnutí učiněná, a analýze kompromisů, ke kterým tato rozhodnutí vedla.
Analýzy se zúčastní část projektového týmu schopná vysvětlit funkce všech komponent, dále hodnotitelé z nezávislých týmů (typicky architekti z jiných částí firmy) a vlastník produktu (neboli „product owner“ ve SCRUM terminologii), nebo jiná osoba odpovědná za vizi.
ATAM analýza trvá podle velikosti hodnoceného řešení pět až deset dní, ale doporučuji ji rozdělit na dvě části. V první části je hodnotitelům představena byznys vize a je prezentována architektura (pokud její popis existuje). Ve druhé polovině, třeba o týden později, se uskuteční samotná analýza. Ta začne sestavením stromu architektonických atributů zkoumaného systému. Tyto atributy je třeba dokumentovat konkrétními scénáři používání a kvantifikovat očekávání jejich uživatelů.
Tak například software běžící v bankomatu musí mít následující atributy:
rychlost: systém reaguje na vložení karty výzvou ke vložení PIN do jedné vteřiny v 99 % případů, přesnost: systém vyplatí přesnou částku v 99,97 % případů, bezpečnost: systém neprozradí data o zákaznících a jejich transakcích, i když je ukraden hackery a podroben dešifrování po dobu jednoho CPU-měsíce.
Takto popsané kvalitativní atributy je vhodné přehledně sepsat do stromové struktury (utility tree), který má na levé straně jednotlivé business drivery a ty se větví a dělí do souvisejících kvalitativních atributů (např. rychlost, přesnost, bezpečnost, spolehlivost, opravitelnost…), a dále do kvantifikovaných scénářů, jež reflektují očekávání uživatelů systému.
Další uživatelské scénáře jsou pak identifikovány všemi účastníky. U zmíněného bankomatu půjde zejména o celý scénář od vložení karty až po odebrání hotovosti. Opět je třeba všechny kvantifikovatelné odezvy systému dokumentovat co nejkonkrétnějšími popisy a měřitelnými čísly. Některé scénáře by měly zachytit zamýšlený budoucí vývoj systému, jako například větší objemy dat, větší počet uživatelů nebo budoucí funkcionality systému. Další scénáře můžou být spekulativní. Například scénář, kdy se polovina serverů zhroutí, ale celková dostupnost systému tím není poznamenaná.
Před další částí je třeba scénáře seřadit podle důležitosti. Tento krok je zásadní pro objektivitu celé ATAM analýzy. Scénáře totiž neřadí ani architekt, ani majitel firmy, ale všichni zúčastnění. Mechanismus hlasování je také přesně daný. Každý dostane stejný počet bodů odvozený od celkového počtu scénářů, které podle vlastního uvážení mezi scénáře rozdělí.
PŘEDPLATNÉ
ČLÁNKY DO MAILU