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

Základní otázky Základní otázky, na které je třeba si odpovědět, než začneme tvořit architekturu informačního systému: –Koupit? –Přebudovat? –Znovu použít? –Navrhnout a realizovat? Ne vždy je potřeba navrhovat a realizovat nový systém. Stále častěji se setkáváme s řešeními, kdy výsledný produkt skládáme z již hotových nebo upravených modulů

Aktivity spojené s řešením Aktivity, spojené s řešením problému můžeme shrnout do kroků: –formulace problému –analýza problému –hledání řešení –volba vhodného řešení –vyřešení

Smůla V praxi se tak zpravidla nepostupuje. Důsledkem je, že: –průměrně 50% velkých projektů trvá déle než bylo odhadnuto –¾ velkých projektů mají provozní chyby –¼ velkých projektů je zrušena

V ČR na tom nejsme nejhůř Statistiky USA z počátku 80.let ukazují, že: –2% programů se používají tak, jak byly vytvořeny, –2-3% se používají po mírném dopracování, nepřekračujícím 10-15% zdroj. textů, –20% bylo nutno přepracovat zásadním způsobem,

…pokračování… –20% vráceno a přepracováno (vesměs na základě nových kontraktů), –50% zákazník program nikdy nepoužil, –5% program shledán nepoužitelným

…pokračování

Rozsah IS Rozsah IS je dán řešeným problémem, jmenovitě: –funkcí systému o chováním o rozhraním –omezujícími podmínkami o spolehlivostí Všechny uvedené atributy problému mají vliv na jeho rozsah. Rozsah problému se stanoví na základě interwiev se zákazníkem.

Schůzky se zákazníkem Schůzky se zákazníkem mají svá pravidla a obvykle začínají předběžnou řízenou schůzkou se zákazníkem Další setkání se zákazníkem jsou formálnější. Týkají se řešení problému, vyjednávání a specifikací zadání.

Předběžná řízená schůzka se zákazníkem Během této schůzky pokládáme zákazníkovy tři typy otázek: otázky bez vazby na řešený problém, otázky vedoucí k hlubšímu pochopení problému a otázky, které na první pohled s problémem nesouvisí, tzv. meta otázky.

Bezkontextové otázky Kdo tu práci požaduje? Kdo ji bude užívat? Jaký bude ekonomický užitek při úspěšném ukončení? Je ještě jiná možnost, jak to vyřešit?

Otázky vedoucí k hlubšímu pochopení názoru zákazníka Jak byste charakterizoval "dobrý" výstup? Na jaké problémy je toto řešení zaměřeno? Ukažte mi (popište) prostředí, kde to bude systém pracovat? Jsou nějaké speciální požadavky na chování systému a na jeho omezení?

"meta otázky" Jste ta správná osoba, která mi může na tyto otázky odpovědět? Jsou vaše odpovědi oficiální? Jsou mé otázky relevantní k danému problému? Nedávám vám moc otázek? Je tu ještě někdo další, kdo by mohl poskytnout doplňující informace? Je ještě něco, na co bych se měl zeptat?

Další schůzky Týkají se řešení problému, vyjednávání a specifikací zadání Často se zde využívá techniky označované jako FAST (Facilitated Application Specification Techniques).

Schůzka technikou FAST Je to schůzka realizátorů a zákazníků. Je řízena neutrální stranou (facilitátorem). Určují se pravidla pro přípravu a průběh realizace projektu. Je specifikována agenda, která bude vedena. Používá se tabule, flip chart apod. Cílem schůzky je identifikovat problém, navrhnout řešení, vyjednat odlišné přístupy a specifikovat předběžnou množinu požadavků

Plánování zdrojů Po stanovení rozsahu projektuje třeba naplánovat zdroje. Mezi zdroje řadíme: –lidské zdroje –využitelné SW komponenty –HW a SW nástroje Je nutné provést identifikaci každého zdroje, jeho popis, zjistit jeho dostupnost, čas, kdy bude požadován a na jak dlouho. V současné době mají stále vetší význam softwarové komponenty

SW komponenty hotové komponenty {off-the-shelf components) komponenty se zkušeností (full- experience components) komponenty s částečnou zkušeností (partial-experience components) nové komponenty

Zkušenosti Pokud nějaká hotová komponenta odpovídá projektovým specifikacím, získej ji. Cena za nákup a její integraci je skoro vždycky menší, než cena za vývoj. Také rizika jsou relativně malá. Pokud jsou dostupné komponenty se zkušeností, riziko spojené s jejich modifikací a integrací je obecně přijatelné. Pokud je třeba velkých modifikací, buď opatrný. Cena za modifikaci takových komponent může být větší než cena za vývoj nových.

Odhad ceny a pracnosti S plánováním projektu souvisí i odhad ceny a pracnosti projektu. Tento odhad je možné provést jako: Odhad se zpožděním. Počáteční odhad podle minulého podobného projektu, Odhad s použitím dekomposičních technik, Odhad s použitím empirických modelů.

Dekomposiční techniky Tyto techniky používají veličiny: –LOC = počet řádků kódu a –FP = funkční bod LOC a FP se používají: –jako proměnné pro odhad různých veličin v projektu –jako základní údaje o minulých projektech

Empirické odhady Pro odhad pracnosti existuje celá řada empirických modelů, ve kterých vystupují veličiny FP nebo LOC vycházející z řešeného projektu a empiricky odvozené konstanty z předchozích projektů A, B, C. Při jejich použití je vhodné provést porovnání odhadu podle několika modelů

Empirický model COCOMO Za nejpropracovanější a nejpoužívanější empirický model můžeme považovat model COCOMO

Děkuji za pozornost.