Takto jsou scénáře seřazeny od těch nejdůležitějších po ty marginální. Hlavní část analýzy potom prochází tyto scénáře v daném pořadí, přesně identifikuje zúčastněné softwarové komponenty a jejich odezvy a vzájemné interakce. Takováto detailní analýza vynáší na povrch rozhodnutí, která byla architektem nebo vývojáři učiněna. Každé rozhodnutí je přezkoumáno a jeho vlivy na systém jsou rozděleny do čtyř kategorií:
1. výhody, které rozhodnutí přináší,
2. rizika daného rozhodnutí,
3. kompromisy, ke kterým rozhodnutí vedlo (ke kompromisům dochází u takových rozhodnutí, jež přinášejí jak výhody, tak rizika),
4. citlivé body neboli předpoklady, za kterých je dané rozhodnutí, jež je kritické pro správnou funkci systému, odůvodněné.
Kompromisy typicky ovlivňují více než jeden atribut systému, a to tak, že jeden atribut zlepší a jiný zhorší. Například přepsání výpočetního kódu z CPU na GPU (grafickou kartu) vylepší rychlost systému, ale zhorší přenositelnost a nasaditelnost systému na různé typy hardwaru.
Citlivé body jsou zdokumentovány proto, aby budoucí vývojáři věděli, jaká rozhodnutí nemají měnit. Nebo naopak, pokud se změní nároky na systém a některé vlastnosti přestanou být kritickými, jaká rozhodnutí naopak musejí být znovu přezkoumána v tomto novém světle.
Z takto strukturovaně zapsaného inventáře pak vychází závěrečné hodnocení.
Jednoznačně dobrá rozhodnutí (s akceptovatelnou mírou rizika a vyváženými kompromisy) jsou shrnuta jako chvályhodná rozhodnutí. Rizika, která nejsou slučitelná s byznys plánem, jsou vypíchnutá jako nález. Rozhodnutí, jež jsou sice vyhodnocená jako dobrá v kontextu současných ambicí, ale dá se očekávat, že přestanou vyhovovat ve světle očekávaného budoucího vývoje, jsou označena jako znepokojující. Další důležité poznatky vynesené na světlo v průběhu analýzy jsou zmíněny pod nálepkou postřehy.
Celá analýza je zdokumentována psanou zprávou s předem danou ATAM osnovou, která ve svém executive summary shrnuje doporučení seřazená podle naléhavosti a závažnosti. Verbální prezentace výstupů na konci workshopu a tato psaná zpráva jsou dány k dispozici projektovému týmu a managementu, který rozhodne, jak zařadit doporučení mezi ostatní položky v backlogu.
V praxi se ukazuje, že čím větší jsou očekávání na softwarový produkt, službu nebo IT systém, tím více se vyplatí mít v týmu dobrého architekta. Funguje jako protiváha projektového manažera, čímž se dosáhne správného vyvážení krátkodobých a dlouhodobých cílů.
Architekt by měl být v týmu od počátku jeho sestavování, aby dokázal efektivně ovlivnit architektonická rozhodnutí a zaručil, že software bude odpovídat nárokům na něj kladeným v současné době a zároveň zachová možnost budoucího rozvoje. Metodologie ATAM dokáže architekturu systému zdokumentovat, objektivně posoudit a navrhnout nápravná opatření.
Pro efektivní průběh a konstruktivní výsledek ATAM analýzy se vyplatí přizvat odborníka s předchozími zkušenostmi z vedení a moderování ATAM workshopů.
Autor je softwarový architekt, manažer a vývojář. Příležitostně se věnuje konzultační činnosti pod hlavičkou Starforest.cz.
PŘEDPLATNÉ
ČLÁNKY DO MAILU