Trnitá cesta k dokonalým informačním systémům

Vývoj informačního systému je věc poměrně nesnadná, pročež začaly vznikat metodiky pro vývoj informačních systé...


Vývoj informačního systému je věc poměrně nesnadná, pročež začaly vznikat
metodiky pro vývoj informačních systémů, které poskytují návod, jak krok za
krokem při vývoji informačního systému postupovat. Jednou z takových metodik je
Rational Unified Process, kterou si nyní představíme.
Obtížnost vývoje softwaru lze dobře dokumentovat na výzkumu, který prováděla
skupina OMG. Podle tohoto výzkumu jsou bez dalších úprav použita 2 % vyvíjeného
softwaru, po úpravách další 3 % a po rozsáhlém přepracování 19 %. Celých 47 %
dodaného softwaru není vůbec použito a 29 % softwaru není ani nikdy dokončeno.
Metodika Rational Unified Process (RUP) byla konstruována tak, aby se vyrovnala
s těmi faktory, které nejčastěji způsobují neúspěch při vývoji softwaru mezi ně
například patří špatné pochopení potřeb zákazníků/uživatelů, neschopnost
vypořádání se se změnami v daném projektu, pozdní rozpoznání chyb v projektu,
špatný výkon aplikací či špatné řízení změn. Příčinami takových problémů mohou
být špatná správa požadavků, nevhodná architektura, rozpory mezi požadavky a
implementací, nekvalitní řízení projektu, nekontrolované provádění změn nebo
nepředcházení rizikům.
Metodika doporučuje používat tzv. "nejlepší praktiky" best practices (resp. je
na nich postavena), které mají zajistit, aby ke zmíněným problémům nedošlo.
Mezi tyto praktiky patří řízení změn, správa požadavků, komponentová
architektura, vizuální modelování, kontrola kvality a iterativní vývoj (viz
přehled).
Procesní pohled
Podívejme se nyní na metodiku RUP z pohledu procesu vývoje nějaké aplikace.
Metodika v každé fázi definuje, kdo dělá co, kdy a jak. RUP pracuje s rolemi
(funkcemi, které zastávají osoby), aktivitami, artefakty a pracovními postupy.
Zastavme se u pojmu artefakt. Z pohledu metodiky RUP je artefakt nějakou
informací, která je vytvářena, modifikována nebo využívána nějakým procesem
(artefaktem obvykle nejsou myšleny pouhé dokumenty). Příkladem takového
artefaktu může být plán testů, požadavek na změnu nebo seznam rizik. Procesy
při vývoji aplikace, které tato metodika definuje, jsou: obchodní modelování,
správa požadavků, analýza a návrh, implementace, testování a dodání všechny
vycházejí z uvedených 6 praktik. Jako podpůrné procesy pro vývoj jsou metodicky
pokryty konfigurační řízení a řízení projektu. Metodika věnuje zvláštní
pozornost řízení projektu, neboť je také častým zdrojem chyb, a navíc obsahuje
i definici metrik, kterými lze měřit průběh projektu a případně jeho úspěšnost.
Uvedené procesy jsou uskutečňovány v několika iteracích,
Metodika vývoje IS
do nichž je životní cyklus systému či aplikace rozdělen. Iterativní vývoj se
vymezuje oproti "vodopádovému vývoji", který předpokládá vývoj celé aplikace v
jedné iteraci a je založen na většinou mylném předpokladu, že požadavky se v
průběhu času nemění a že první navržené řešení bude zcela správné. Riziko, že
aplikace nebude bezchybně plnit svou funkci, pak přetrvává během celého
projektu a odbouráno může být teprve v jeho samém závěru. Naproti tomu
iterativní vývoj, díky průběžnému testování a ověřování, odstraňuje podobná
rizika již v raných fázích projektu. Kritériem výběru funkcionality pro
implementaci v každé fázi vývoje je podle metodiky RUP míra rizika, kterou daná
část funkcionality představuje (tj. nejrizikovější části se implementují
nejdříve).
Fáze a milníky
První fází projektu je "počátek" (inception), kdy by měla být definována
základní vize projektu a jeho rozsah. Na jejím konci by měla být uzavřena
dohoda se zadavatelem o rozsahu projektu, měly by být analyzovány
nejdůležitější případy užití (scénáře použití aplikace) a definice priorit a
rizik.
Následující fáze je označována jako "elaborace". Účelem této druhé fáze je
definovat architekturu systému, zjistit potřebné množství času, peněžních a
lidských zdrojů a odstranit rizika spojená s architekturou. Výsledkem této fáze
by měla být odzkoušená základní architektura, analyzováno cca 80 % případů
užití, revidovaný seznam rizik a priorit, návrh uživatelské dokumentace a plán
pro zbytek projektu.
V další fázi nazývané "konstrukce" je již kladen hlavní důraz na samotnou
implementaci. Během této fáze by mělo dojít k implementaci hlavních funkčních
bloků a na konci by měla být k dispozici "betaverze" pokrývající základní
požadavky zadavatele, uživatelská dokumentace, vyhodnocení testů a eliminována
(téměř všechna) rizika.
Předmětem poslední fáze, tzv. "zavádění", je již nasazení produktu do rutinního
provozu u zákazníka. Kromě vlastní instalace produktu probíhá v této fázi
rovněž školení a podpora uživatelů. Po jejím ukončení musí být produkt nasazen
v rutinním provozu, poskytovat požadovaný výkon a všichni uživatelé musejí být
vyškoleni.
Každá ze jmenovaných fází může podle potřeby procházet několika iteracemi
obvykle se celkový počet iterací všech fází dohromady pohybuje v rozmezí 3-9
(při 3 iteracích se vynechává počáteční fáze). Délka jedné iterace je přitom
přibližně 1-3 měsíce. Je také třeba zachovat zásadu nepřekrývání iterací, neboť
následující iterace musí vycházet z vyhodnocení iterace předchozí. Iteracemi
nelze nazývat vytváření jednotlivých "buildů" aplikace. Obecně se doporučuje,
aby délka celého projektu nepřekročila období jednoho roku, neboť delší
projekty jsou pro řešitele i zákazníka značně demotivující, nehledě na to, že v
tomto horizontu mohou probíhat velmi rozsáhlé změny prostředí, které mohou
vývoj aplikace zcela zmařit.
Architektura
Velká část metodiky RUP je zaměřena na tvorbu architektury aplikace nebo
informačního systému, neboť tato fáze s sebou většinou přináší největší rizika.
Architektura je metodikou vnímána jako "páteř", která musí být schopna unést
veškerou funkcionalitu a musí být zajímavá pro všechny účastnící se osoby.
RUP je zaměřen na architekturu výsledného řešení. Architektura je vnímána jako
"vnitřní struktura", která je považována za klíčovou podmínku kvality. Tudíž
architektura je rizikem projektu a riziko je nutné odstranit pokud možno co
nejdříve, tzn. již v elaborační fázi.
Rámcem pro tvorbu architektury je pro metodiku RUP model "případů užití", který
je také hojně používaným modelem u objektově orientovaných metodik. Tento model
je ústředním pohledem na architekturu zachycuje "scénáře" použití aplikace krok
za krokem tak, jak by měly probíhat (např. popis krok za krokem, jakým způsobem
bude probíhat vyplňování objednávky). Zahrnuty jsou zde nejen scénáře, kdy je
vše v pořádku, ale také veškeré scénáře, kdy dochází k nějakým chybám či
problémům.
Architektura je vnímána z 5 základních pohledů logický pohled (struktura
funkcionality do subsystémů), implemetační pohled (3vrstevná architektura,
komponenty), procesní pohled (zachycující dynamiku systému) a pohled nasazení
(fyzické rozložení komponent, ladění výkonu, instalace). Jako pátý pohled jsou
vnímány případy užití.
Softwarová architektura (tj. logický a implementační pohled) má obvykle
maticovou strukturu. Jednu osu matice tvoří vrstvy typicky 3vrstevného modelu
aplikací (uživatelské rozhraní, obchodní logika, přístup k datům) a druhou osu
tvoří kategorie komponent podle funkcionality. Zde se rozlišují věcné
komponenty (implementující specifické vlastnosti aplikace), systémové
komponenty (implementující obecné služby jako přihlašování uživatele,
potvrzování akcí) a univerzální komponenty (databázový server).
Dostupnost
Metodika Rational Unified Process je k dispozici ve formě sady HTML stránek,
které jsou bohatě formátovány a využívají množství odkazů. Součástí této
metodiky jsou ale také šablony pro různé typy dokumentů (vize, plán nasazování,
různé druhy reportů a podobně).
V případě metodiky ale nejde jen o "zakoupení krabice". Ať už bude metodika
používána pro interní vývojové oddělení nebo pro softwarehouse, vždy je
zapotřebí také nějaká konzultační činnost, která podpoří přechod firmy na
používání této metodiky.


Nejlepší praktiky v Rational Unified Process
l Iterativní vývoj je založen na rozdělení vývoje aplikace do několika částí
(iterací). Výsledkem každé iterace musí být spustitelný program, na kterém je
možné ověřit určité části funkčnosti. Každá iterace zahrnuje revizi požadavků
na vyvíjenou aplikaci, analýzu a návrh, implementaci, testování, vyhodnocení a
rozhodnutí o dalším postupu při vývoji. Význam jednotlivých součástí každé
takové iterace se přitom v průběhu vývoje mění postupem času klesá význam
analýzy a návrhu a roste význam implementace a testování.
l Další důležitou praktikou je správa požadavků. Ta zahrnuje zajištění
dokumentace o požadované funkčnosti a omezení systému, vyhodnocování dopadu
změn požadavků na systém a dokumentaci jednotlivých rozhodnutí o dalším vývoji
systému. Splnění požadavků je možné považovat za zástupný cíl, ke kterému by
měl vývoj aplikace směřovat. Problémem však je, že požadavky jsou "dynamické"
tedy podléhají častým změnám. Ačkoliv se to může zdát na první pohled podivné,
uživatelé své požadavky na systém poměrně často mění, a proto je třeba takové
změny účinně, jednotně a formalizovaně řídit.
l Komponentovou architekturu vyvíjeného softwaru nejspíše není třeba dlouze
představovat. Aplikace vyvíjené komponentově mají pružnější architekturu,
jejich části mohou být znovu použity při vývoji dalších aplikací. Komponentové
technologie také podporují lépe týmový vývoj a umožňují snazší aktualizaci
aplikací. Komponenta v pojetí RUP je však vnímána poněkud šířeji, než je běžně
vnímána např. z pohledu komponentových technologií.
l Vizuální modelování se už dnes také stává rychle standardem. Vizuální
modelování je přehlednější, a umožňuje tak snazší verifikaci modelů s
uživatelem (resp. zadavatelem), který obvykle není s vývojem aplikací do
hloubky obeznámen. Modelovací nástroje dále umožňují kontrolu konzistencí
jednotlivých modelů a případně konzistenci mezi návrhem a implementací. RUP
předpokládá použití nástrojů, které jsou založeny na UML (Unified Modeling
Language). Metodika pracuje například s diagramy tříd, objektů, komponent,
rozmístění, aktivit, spolupráce, případů užití a se stavovými a sekvenčními
diagramy.
l Kontrola kvality je založena na "objektivním hodnocení stavu", které je
prováděno pomocí testování. Kontrola by měla odhalit nesoulady mezi požadavky,
návrhem a implementací, přičemž základním mottem je: Čím dříve budou chyby
odhaleny, tím méně bude stát jejich odstranění soustavné testování během celého
vývoje umožní celkové náklady na odstraňování chyb snižovat. Tyto testy by dle
RUP měly být prováděny v závěru každé iterace. Testování zahrnuje plánování
testu, návrh testů, jejich implementaci, provádění a vyhodnocení a v každé
další iteraci se okruh prováděných testů rozšiřuje. Metodika RUP také počítá s
automatickým prováděním testů všude tam, kde je to možné. Metodika rozděluje
testy do 4 základních skupin testy funkcionality (implementace případů užití),
testy spolehlivosti (stabilita), testy výkonu aplikace a testy výkonu systému.
Některé typy testů lze automatizovat poměrně snadno (například výkonové testy)
a jejich snazší opakování může lépe zmapovat funkčnost aplikace. Pomocí
automatických nástrojů je možné rovněž testovat kvalitu programového kódu a
automaticky vyhledávat podezřelé programové konstrukce (například použití
neinicializovaných ukazatelů).
l Řízení změn má zajistit, aby požadavky na změny byly reflektovány ve vyvíjené
aplikaci. V prvé řadě jde o jejich dokumentaci a o vyhodnocování dopadu
požadavků na změny, přičemž těmito požadavky mohou být požadavky na nové rysy,
upřesnění funkcionality anebo požadavky na opravu chyby. Jednotlivé změny v
systému musejí být kontrolovány rovněž.

Jazyk UML
(Unified Modeling Language)
Metodika Rational Unified Process při vizuálním modelování předpokládá použití
nástrojů založených na jazyce UML. Jedná se o standard užívaný pro specifikaci,
vizualizaci, konstrukci a dokumentaci artefaktů softwarových systémů. Účelem je
zjednodušení obvykle velmi komplexního procesu designu softwarových aplikací.
UML je nástupcem jazyků pro objektové modelování, které byly používány u třech
svého času nejúspěšnějších objektově orientovaných metod Booch, OMT a OOSE.
Jeho využití zahrnuje následující oblasti:
modelování obchodních procesů
modelování tříd a objektů
modelování komponent
modelování distribuce a nasazení
Konstrukce modelů je nezbytná pro efektivní komunikaci mezi projektovými týmy i
pro zajištění kvalitní architektury systému. Nároky na modelovací techniky
pochopitelně stoupají s jeho rostoucí složitostí. Je jasné, že úspěch projektu
závisí i na mnoha jiných faktorech, ale přísný standard pro konstrukci modelů
tvoří důležitou součást či předpoklad pro jeho dosažení. Jazyk UML je pokusem
vnést do této oblasti všeobecně přijatelný standard využívající dobrých
vlastností svých předchůdců. Zatímco běžné softwarové produkty pro řízení
projektů umožňovaly koordinaci různých částí projektu pouze v jejich časové
souvislosti, diagramy založené na UML mohou sloužit k jejich zobrazení z
perspektivy architektury projektu. Na vývoji jazyka UML se podílely např.
společnosti Hewlett-Packard, IBM, Oracle, Microsoft, Rational Software, Unisys
a další. Podrobnější informace můžete nalézt například na stránce
www.rational.com/.

Klady a zápory metody RUP
Hlavním posláním popisované metodiky je, jak již bylo naznačeno, minimalizace
rizik selhání celého projektu. Toho je poměrně dobře dosaženo iterativním
vývojem. Jedná se také o objektově orientovanou, progresivní metodiku, která
staví na použití inteligentních nástrojů a moderních technologií. V rámci
objektivity je ovšem nezbytné shrnout i nevýhody a rizika samotné metodiky.
Iterativní vývoj je nepochybně obtížnější. Je náročnější na plánování, kontrolu
a účast zákazníka na vývoji. V krajním případě může tato metodika při nevhodném
užití zavést řešitele až do nikdy nekončícího cyklu nových požadavků a
opětovného přepracovávání. Problémy také může způsobit orientace ve velkém
množství překrývajících se iterací (kde potom iterace přestávají mít smysl).
0 3182 / wep









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.