Romicus - SPQR

Řím a informační technologie
Malá odlehčená úvaha nad nečekanými souvislostmi v tomto veskrze moderním oboru

Řím a informační technologie

Plzeň, 20.7.2011
Zdá se vám již sám název článku absurdní a je tedy i celý článek úplná blbost, neboť, jak zní parafráze klasického výroku: "I úplný blbec ví, že před dvěma tisíci lety přece žádné počítače neexistovaly!". Přesto jedna souvislost, která mě napadla při analýze jednoho modulu informačního systému, existuje.
 

"Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando".
Tak je citována u mnohých latinských autorů sekvence otázek, kterými se máme dobrat pravdy o zkoumané skutečnosti zejména v případě soudních jednání a jiných právních sporů. A přesně na tuto frázi jsem si vzpomněl při práci na analýze mého aktuálního projektu a vytváření modelu vyvíjeného systému (UML model realizovaný ve Sparx Enterprise architect). Je až s podivem, jak je postup při jeho sestavování podobný tomu, co používali římští právníci ve své advokátní praxi. Pro názornost si probereme jedno slovíčko za druhým a přiřadíme mu postup, při návrhu softwarového řešení. Pro dodržení obvyklého postupu práce pouze jednotlivá slůvka poněkud přeházíme.

Quis - Kdo.
Zde je to úplně jasné, "Kdo" je ten nešťastník, který se snaží absolutně nejasné a logických nonsensů plné zadání zákazníka převést do logické struktury exaktního a strukturovaného modelu.

Ubi - Kde.
V tomto případě musíme rozlišit dva různé významy tohoto slova v procesu analýzy IT systému.
První, místní význam, značí, že ač by analytik nejraději zpracovával zadané řešení v hospodě, musí z čistě formálních důvodů alespoň občas navštívit nevlídné kanceláře zadavatele, kde se za vynaložení značného úsilí snaží z více či méně kompetentních kolegů, vypáčit alespoň trochu relevantní informace.
Druhý význam se týká vlastního provozu příslušného systému, tzn. kde, na jaké hardwarové a softwarové platformě, finální verze systému poběží. V UML toto řeší deployment model.

Quid - Co.
Je dalším krokem analýzy, při kterém se výše uvedený nešťastník snaží zjistit, co že to ten zákazník vlastně požaduje. V UML návrhu se toto označuje jako functional and formal requirements a řeší se to v rámci use case modelu.

Quibus auxiliis - S čí pomocí.
Zde můžeme rozlišit opět dva různé sémantické výklady tohoto pojmu.
Prvním výkladem jsou fyzické osoby, které s námi budou na daném řešení participovat a jejichž přítomnost a mnohdy i nejapné připomínky musíme při vývoji přetrpět.
Druhým významem tohoto pojmu jsou osoby, které budou s daným systémem pracovat. Tyto osoby je třeba pak v návrhu rozlišit na fyzické (včetně těch naprosto blbých) a ostatní (roboti, matrix, A. Schwarzenegger, …).
V UML návrhu se toto označuje jako actors.

Cur - Proč.
Velice důležitá, ač často opomíjená otázka. Co je cílem celého snažení a co má přinést zadavateli výsledný efekt. Je až neuvěřitelné, jak často je tato elementární otázka opomenuta nebo zapomenuta v průběhu "boje". A tak zejména ve státní správě jsou často vynakládány ohromné prostředky na složitá a drahá řešení, která sice formálně fungují (někdy), ale přinášejí pramalý nebo vůbec žádný zisk. Maně mi napadá, že jedním z takovýchto projektů jsou i státní maturity, kde výsledkem neobyčejné byrokratické a technologické mašinérii je excelová tabulka na stole pana ministra. Jistě ve svém use case modelu zapomněli uvést element goal nebo target, jak se cíl v UML jazyku označuje.

Quomodo - Jak.
I když mnoho kolegů tímto bodem začíná, my jsme se svými slovíčky již skoro na konci seznamu. Ovšem teprve tehdy, když máme zodpovězeny všechny výše uvedené otázky, můžeme začít pracovat na definici procesů a vytváření vnitřní struktury vlastního systému. Tady teprve začíná kýžená fáze, kdy se vývojář uzavírá do svého dokonalého nitra a jak ze sopky z něj tryskají návrhy procesů, tříd a datových entit, což je celé završeno sprškou dialogů a uživatelských rozhraní. To první řeší behaviorální modely (process model, state model), to druhé pak strukturální diagramy jako např. class model, data model a to třetí pak návrháře uživatelského rozhraní. A pokud soptící informatik svou činností nezasypal sám sebe (opět řečeno spolu s Klasikem), může se dočkat zasloužené odměny.

Quando - Kdy.
Zde by spíše mělo být uvedeno do kdy. Údaj, který bývá velice často v rozporu s prvními body tohoto seznamu a často přivádí nebohého vývojáře k šílenství, neboť i v posledních chvílích, které zbývají do dokončení projektu, je nucen reagovat na různé "zlepšovací" návrhy a "drobné" změny v zadání, které vlivem naprostého nepochopení jeho díla staví celou jeho předchozí práci na hlavu.

Za kolik.
Tuto otázku klasičtí autoři neřeší a ani (jistě z důvodu vrozené skromnosti) neuvádějí. Je ale pravdou, že již císař Augustus se musel zabývat nemravnýmí odměnami právníků, které často dosahovaly nehorázné výše a byly v podstatě pouze chabě zastřenou formou korupce. Jím stanovená maximální odměna advokátům ve výši 10.000 sesterciů za jednotlivý případ, což byl cca desetinásobek ročního žoldu legionáře, je zcela jistě v poměrné shodě s tím, co jako odměnu dnes dostává každý průměrný vývojář.

Na závěr nezbývá než si postesknout, že kdyby se v Římě tak skvělé mozky, jakými byli M.Cicero, Q.Hortensius a jiní, místo plytkého žvanění zabývali systémovou analýzou a UML modelováním, mohli jsme být s cestou k technologicky dokonalé společnosti mnohem dále. Know how na to měli. Místo toho však musíme jejich pohrobky poslouchat v soudobých sněmovnách a parlamentech, zatímco technici se marně snaží jimi zaviněný skluz napravit.

Ach ouvej, tak jdu opět pokračovat v analýze ….
 

Website Name 2009 | Sponsored by Skluzavky