Metody modelování požadavků na IS Vývoj informačních systémů

Základní pojmy Projekt je časově ohraničené úsilí vynaložené s cílem vytvořit jedinečný výsledek (produkt). Proces je ucelený sled činností, který má na výstupu měřitelný výsledný produkt. Produkt může být hmotný (výrobek) nebo nehmotný (informace) nebo to může být služba. Pozn.: tedy třeba architektura IT

Zralost organizace Organizace, které realizují softwarové projekty, jsou na tuto činnost různě připraveny a vybaveny. Návrh IT architektury je založen na předchozích zkušenostech a informacích. Čím více jich organizace má, tím lépe je na realizaci projektu připravena. Z pohledu připravenosti organizace rozeznáváme několik úrovní a mluvíme v této souvislosti o úrovni zralosti organizace.

Základní úrovně zralosti organizace Počáteční - SW proces je prováděn ad hoc, příležitostně až chaoticky. Několik procesuje definováno, případné úspěchy závisí na osobním úsilí. Opakovatelná - Jsou zavedeny základní procesy řízení projektu. Je snaha opakovat procesy úspěšných projektů podobných aplikací. Definovaná - SW proces jak z hlediska řízení tak i z hlediska SI je dokumentován, standardizován a integrován do ostatních procesů organizace. Řízená - Jsou prováděna podrobná měření kvality SW procesu a produktu Optimalizovaná - Soustavné zdokonalování procesů využívá kvantitativní zpětnou vazbu z procesů a testů nových myšlenek a technologií.

Základní oblasti Při realizaci projektu je nutné sledovat tři základní oblasti: Lidé - práce s lidmi. Problém - pochopení řešeného problému. Špatným pochopením problému může vzniknout sice elegantní řešení, ale pro jiný problém Problém - pochopení řešeného problému. Špatným pochopením problému může vzniknout sice elegantní řešení, ale pro jiný problém Proces - sledování procesu. Proces je nutné připravit, naplánovat, kontrolovat a řídit.

Lidé Nejdůležitějším předpokladem pro úspěšný softwarový projekt je výběr vysoce kvalifikovaných odborníků.

Role lidí, kteří ovlivňují softwarový proces vrcholový management manažer projektu pracovnícizákazníci koncoví uživatelé

Úloha manažera projektu komunikace se zákazníkem plánování projektu řízení rozpočtu výběr řešitelů kontrola stavu projektu prezentace výsledků

Typy organizace týmu Problémy se řeší na vrcholové úrovni, vnitřní koordinaci řídí vedoucí týmu. Komunikace mezi vedoucím a týmem je vertikální. CC - řízené centralizovaná Je určen vedoucí týmu (případně vedoucí podskupin), který koordinuje úkoly. Řešení problému se provádí ve skupině. Komunikace mezi podskupinami a individui je horizontální. Vedle toho existuje ještě vertikální komunikace. CD - řízené decentralizovaná Rozhodnutí se provádí na základě skupinového konsensu. Komunikace uvnitř týmu je horizontální. DD - decentralizované demokratická

Jiné paradigma záleží na přirozeném dělení problému a organizuje členy týmu, aby pracovali na částech bez potřeby velké komunikace mezi sebou. Synchronní paradigma pokus strukturovat tým s určitým řízením jako v uzavřeném paradigmatu, ale s ponecháním volnosti v tvorbě jako v náhodném paradigmatu Otevřené paradigma uvolněná struktura, závislá na individualitách Náhodné paradigma struktura s tradiční hierarchií autorit (podobné CC) Uzavřené paradigma

Problém U řešeného projektu je nejdůležitější pochopit: –cíle projektu –rozsah projektu –alternativy řešení –technická omezení

Modely softwarového procesu lineární sekvenční model model prototypování RAD model přírůstkový model spirálový model model skládání komponent model souběžného vývoje formální metody techniky čtvrté generace

Lineární sekvenční model (model vodopád) Je to klasický životní cyklus. V 80. letech byl podroben kritice, která dospěla k formulování základních nedostatků, kterými jsou: reálné projekty zřídka kdy sledují jednotlivé kroky v předepsaném pořadí pro zákazníka je obtížné vyjádřit předem všechny požadavky provozuschopná verze bude k disposici až po delší době (může být už zastaralá) často dochází k prodlevám

Prototypování Slouží k pochopení požadavků na systémy, které nejdou dobře specifikovat předem. Prototypy, na kterých mají být modelovány nějaké vlastnosti systému, mohou být dělány s vědomím, že budou zahozeny. Tento model lze použít pro menší systémy

RAD = Rapid Application Development Je to lineární sekvenční model spočívající v extrémně krátkém vývojovém cyklu - do 3 měsíců. Model je určen pro dobře srozumitelné a dobře vymezené problémy, s malými riziky. Problém je rozdělen na samostatné moduly, které se rozdělí týmům. Při vývoji jsou využívány hotové softwarové komponenty.

Přírůstkový evoluční model Kombinuje lineární model s iterativní filosofií. Produkt se vytváří po částech (přírůstcích), které jsou funkční (na rozdíl od prototypu). První přírůstek je označován jako jádro. Model je vhodný pro malý tým a velký úkol, který se dá zvládnout v předem po částech, v domluvených termínech.

Spirálový evoluční model Model kombinuje prototypování se systematickým sekvenčním přístupem a opakováním na výším stupni zvládnutí problematiky. Je založen na prioritě tvorby verze s vyšší rizikovostí. Části s větší mírou rizika jsou realizovány drive. Nevýhodu modelu je, že nelze stanovit přesné termíny (při práci na zakázku), závisí na správnosti rizikové analýzy, náročné na zkušenost pracovníků (je nutné více kontrolních bodů, po každé analýze rizik). Je vhodný pro velké systémy.

Model skládání komponent (evoluční) Spirálový model, ale pro objektové technologie, který využívá skládání hotových komponent z knihovna tříd objektů.

Model souběžného vývoje (evoluční) Jednotlivé komponenty jsou vyvíjeny paralelně (vývoj je modelován jako paralelní procesy). Je vhodný např. pro klient/server aplikace.

Formální metody Spočívají na formálních specifikacích, podporují formální verifikaci programů. Nevýhody, které zatím brání praktickému nasazení je, že je drahý a časově náročný, je náročný na kvalifikaci vývojářů, je v něm obtížná komunikace s běžným uživatelem.

Techniky čtvrté generace Jsou založeny na programování na vysoké úrovni abstrakce. Výhodou je rychlý vývoj a zvýšení produktivity. Nevýhodou je, že některé prostředky jsou stejně složité jako klasické programovací jazyky, výsledný kód nemusí být dostatečně efektivní a údržba velkého systému může být problematická.

Dojem Neexistuje „nejlepší“ model popisu ani řešení problému Za perspektivní metodu vývoje softwaru považuji spojení CASE nástroje s modelem skládání komponent

Proces V procesu realizace softwaru jsou nejdůležitější následující faktory: výběr modelu propojení problému a procesu dekomposice (zjemnění) procesu

Závěry Podstatný vliv na management softwarových projektů mají 3P: Pracovníci musí být organizování do efektivních týmů, motivováni k vysoce kvalitní práci, koordinováni tak, aby dosáhli efektivní komunikace. Problém musí být definován v komunikaci zákazníka s realizátorem, rozdělen (dekomponován) na části a přidělen softwarovým týmům. Proces musí být přizpůsoben lidem a problému, vybrán vhodný model

Děkuji za pozornost.