Od zadání k architektuře aplikace

Prezentace na téma: "Od zadání k architektuře aplikace"— Transkript prezentace:

1 Od zadání k architektuře aplikace
Požadavky na SW Od zadání k architektuře aplikace

2 Specifikace požadavků
Specifikace požadavků je 1. fáze návrhu IS (po podnikovém modelování) a je nástrojem poznání potřeb budoucího uživatele. Cílem je vymezit systém z hlediska požadavků na funkcionalitu, technologie, bezpečnost atd. Je to základ pro veškeré práce na projektu. Modelování podnikových procesů Specifikace požadavků zákazníka Analýza a návrh Implementace Poznání reality Nové potřeby Návrh řešení Realizace

3 Inženýrství požadavků
Před začátkem OOA (objektově orientovaná analýza) nebo OOD (objektově orientovaný návrh, design) je třeba vytvořit alespoň rámcový přehled o tom, co má systém dělat a jaký je smysl požadavků a jaká je jejich specifikace (vše v terminologii, které rozumí uživatel). Tzv. Inženýrství požadavků (Requirements Engineering) spočívá ve stanovení služeb, které by měl vyvíjený systém poskytovat, včetně různých omezení. Jediný způsob zachycení požadavku v OOA je případ užití, toto ale neplatí pro nefunkční požadavky. Základem jsou interview s pověřenými zástupci zadavatele, nebo studium podnikových norem zákazníka, BPM (Business Process Model), studium standardů problémové oblasti, ..

4 Specifikace požadavků
Při analýze požadavků je nutno uvažovat tyto faktory: Zaměření podnikových činností Okolí podniku Legislativa Strategické a podnikatelské plány Omezení zdrojů (personální a technické) Finanční omezení Termínová omezení Platí obecně, nejen u OOA (resp. OOD).

5 RUP (Rational Unified Process) a požadavky
V analýze a návrhu nás zajímají následující činnosti: Vyhledání aktorů a případů užití Detail případu užití (scénáře) Struktura modelu případu užití Pracovní postup v RUP je rozšířen o následující procesy Vyhledání funkčních požadavků Vyhledání nefunkčních požadavků Prioritizace jednotlivých požadavků Sledování požadavků k případům užití

6 Formát požadavků Požadavek lze definovat stručně jako „specifikaci toho, co by mělo být implementováno”. Funkční požadavky (functional req.) určují, jaké chování nebo jaké služby bude systém nabízet Nefunkční požadavky (non-functional req.) specifikují vlastnosti nebo omezující podmínky daného systému (kvalita, technologie, dokumentace, řízení projektu, ..) (Požadavek vyjadřuje CO? nikoliv JAK?) Formát pro vyjádření požadavků <id><systém>bude<funkce>, kde id jedinečný identifikátor název systému „bude” – klíčové slovo vykonávaná funkce

7 Klasifikace požadavků (taxonomie)
Nefunkční požadavky Výkon Kapacita Dostupnost Shoda se standardy Zabezpečení Dokumentace Organizace projektu Technologie Funkční požadavky Zákazníci Produkty Objednávky Prodejní kanály Platby Veškeré požadavky na funkce a služby od zadavatele

8 Modelování nefunkčních požadavků
Nefunkční požadavky je třeba zaznamenat a neustále je promítat do návrhu řešení. Použít katalogový záznam Identifikační číslo Datum poslední změny Kdo ho požaduje, kdo ho přijímá Priorita požadavků Stručný název požadavku Detailní popis požadavku Návaznost na další požadavky Komplexnost/složitost požadavku

9 Příklady nefunkčních požadavků
Realizace projektu v přírůstcích Pouze jedna zodpovědná osoba na straně dodavatele Realizace kontrolních dnů každý měsíc Podpora hotového produktu po dobu 7 let Provoz na platformách Linux/Unix Podpora uložení dat v DB ORACLE Odezva systému do 3 sekund při všech operacích …

10 Záznam požadavku Atributy požadavků (pro dodatečné informace) Status
Význam Riziko Stabilita resp. cílová verze Termín, datumSplatnosti Zdroj Priorita (Must have, Should have, Could have, Want to have) Odpovědná osoba (kdo požadavek požaduje a kdo ho přijímá) Dále datum vytvoření požadavku a datum poslední změny, detailní popis, návaznosti na jiné požadavky, komplexnost/složitost požadavku (pokud je možné toto určit).

11 Získání požadavku Získávání požadavků (mapa pracovního modelu pracovníků). Pro co nejpodrobnější zachycení požadavků a jejich nejhlubší analýzu se používá Vyřazení Deformace Zobecnění. Nejlepší způsob je konzultace a pohovor se zainteresovanými osobami, dotazník, spontánní diskuze. Správně formulované požadavky by měly být vyjádřeny strukturovaným jazykem, aby bylo možné využít nástroje pro podporu požadavků.

12 Modelování případů užití
Je jedna z forem inženýrství požadavků, skládá se z aktivit (viz. cvič.) Nalezení hranic systému (ohraničení zobrazené kolem případů užití, jež je vyznačením hranic modelovaného systému – v UML 2 subjekt Vyhledání aktorů Nalezení případu užití Tvorba slovníku pojmů (terminologie v dané oblasti, pozor na synonyma a homonyma) Tento use case model je hlavním zdrojem objektů a tříd a prvotním vstupem k modelování tříd. Zdroje pro model případu užití Podnikový model Model požadavků (seznam funkčních a nefunkčních požadavků) Seznam vlastností (v souladu s vizí podniku)

13 Specifikace případu užití
Specifikace případu užití (doporučeno používat jednotný a konzistentní standard v rámci celého projektu) Název + jedinečný identifikátor Stručný popis Aktoři (hlavní – spouští UC, vedlejší- jsou v interakci s UC po jeho spuštění) Vstupní (co musí být PRAVDA předtím, než se spustí UC) a výstupní podmínky (stav systému po skončení UC) Hlavní scénář Alternativní scénáře Vše ve srozumitelné strukturované češtině Ostatní viz. cvičení

14 Softwarový projekt Účastníci SW projektu
Zákazníci, uživatelé, analytici, vývojáři, testeři, dokumentátoři, vedoucí projektu, právníci, lidé z výroby, prodeje, marketingu, technické podpory Typy požadavků ještě jednou - vztahy mezi různými typy požadavků Viz Obr.

15 Vývoj a správa požadavků
Základní discipliny práce s požadavky viz Obr. Vývoj požadavků jako proces Doporučeno postupné upřesňování, iterativní postup, správnost svých analýz ověřovat s uživateli. Správa požadavků jako proces Definice požadavků, posouzení navrhovaných změn, zpracování změn, aktualizace plánů vývoje podle změn, vyjednávání, sledování požadavků od návrhu po implementaci a testování.

16 Hranice mezi vývojem a správou požadavků

17 Výhody kvalitního zpracování požadavků
Méně chyb v požadavcích Snížení objemu přidělávané práce Méně nepotřebných funkcí Nižší náklady na vylepšování Rychlejší vývoj Méně nedorozumění Menší pravděpodobnost tichého rozšiřování rozsahu , menší chaos v projektu Přesnější odhady Spokojenější zákazník i vývojář

18 Vlastnosti požadavků a celé specifikace
Vlastnosti dobře popsaných požadavků Úplnost Správnost Proveditelnost Nepostradatelnost Priorita Jednoznačnost Ověřitelnost Vlastnost celé specifikace Jednotnost Přizpůsobitelnost Dohledatelnost

19 Vztah mezi zákazníkem a vývojáři
Základní práva a povinnosti softwarového zákazníka viz tab 1 a tab.2 dále. Faktem je, že na začátku projektu všechny požadavky nemohou být známy a budou se v průběhu času měnit. Podepsaná směrná verze specifikace = závazná podoba požadavků v daném čase. Další úpravy se budou provádět kontrolovaným způsobem (analýza důsledků na termín, cenu a další faktory).

20

21 Aktivity vývoje požadavků
Etapy : Sbírání, analýza, specifikace, kontrola. Sbírání (popsat rozsah a jeho vizi, najít třídy uživatelů a klíčovou osobu pro každou třídu uživatelů, vybrat skupinu typických uživatelů, najít jejich UC, najít systémové události a odpovědi na ně, uspořádat workshop, sledovat uživatele při práci, hledat nápady na zlepšení…) Analýza (vytvořit kontextový diagram, vytvořit prototyp GUI, analyzovat proveditelnost požadavků, prioritizovat požadavky, modelovat požadavky (ERD, STD, DFD, diagram tříd, mapa dialogů, SD, rozhodovací tabulky, rozhodovací stromy,..), vytvořit DD, rozdělit požadavky do subsystémů,…) Specifikace (psát podle šablony, najít zdroje požadavků, ID, zapsat pravidlo, popsat kvalitativní parametry jako je výkon, efektivita, spolehlivost, použitelnost,…) Kontrola (provést revizi, testovat požadavky) Proces vývoje požadavků viz Obr.

22 Aktivity správy požadavků
Stanovit postup verzování změnového řízení včetně zřízení komise Pro každou změnu provést analýzu Verzovat i dokumentaci požadavků Vést historii změn (datum, změna, autor a důvod) Sledovat stav každého požadavku Používat nástroj pro správu požadavků Vytvořit spojovací matici (požadavek X odkaz na implementační kód, testy)

23 Analytik požadavků Úkoly (definovat uživatele, sbírat a analyzovat požadavek, psát specifikace, modelovat požadavek, kontrolovat, prioritizovat, spravovat požadavky) Analytické dovednosti (umění naslouchat, ptát se, vést hovor,moderovat diskuze, pozorovací schopnost, vyjadřovací schopnost, organizační schopnost, modelovací schopnost, sociální inteligence, nápaditost). Většina znalostí s získá zkušenostmi (soft kills znalosti se týkají spíše lidí než technologií). Viz Obr.

24 Dokumentace požadavků
Tři způsoby psaní požadavků Dobře strukturovaným dokumentem v přirozeném jazyce Grafickými modely Formální specifikace pomocí matematického a formálního jazyka Šablona pro specifikaci požadavků ze standardu IEEE 830 viz Obr. Dále Modelování požadavků „Jeden obrázek vydá za 1024 slov“ Zákazníkův hlas X modely Podstatné jméno X datastore, aktor, entity, atribut, třída Sloveso X proces, use case, vztah v ERD, přechod v STD, aktivita v AD

25 Šablona pro specifikaci požadavků ze standardu IEEE 830

26 Kvalitativní parametry SW systémů
Důležité pro uživatele Dostupnost (poměr plánované doby provozu systému a doby, kdy je systém skutečné k dispozici a plně funkční) Efektivita (jak systém nakládá s časem procesoru, místem na disku, pamětí a komunikačními prostředky) Flexibilita (jak snadno se do hotového systému přidávají nové funkce) Integrita (neautorizovaný přístup k systému, ztráta informací, ochrana před viry, …) Kompatibilita (jak snadno dokáže systém vyměňovat data nebo služby s jinými systémy) Spolehlivost (pravděpodobnost, se kterou bude systém pracovat bez chyby, např. průměrný čas mezi chybami) Odolnost (míra do jaké systém odolá chybám vstupu nebo nečekaným provozním podmínkám) Použitelnost (patří sem uživatelská přívětivost).

27 Kvalitativní parametry SW systémů
Důležité pro vývojáře Udržovatelnost (jak snadno se SW upravuje a jak rychle se v něm hledají a opravují chyby) Přenositelnost (úsilí, které je třeba k přenosu SW z jednoho provozního prostředí do druhého) Znovu použitelnost (recyklovatelnost, úsilí pro vytvoření komponenty pro použití v jiných aplikacích) Testovatelnost (úsilí, které je potřeba pro hledání chyb). Výkonnostní požadavky (jak dobře nebo rychle musí systém zvládat zadané funkce Rychlost a odezva, propustnost (počet transakcí za sekundu, kapacita (schopnost zvládat souběžnou zátěž), časování (schopnost vyřídit požadavky v daném čase). Různé části systému vyžadují různé kombinace kvalitativních parametrů, pro některé je kritická efektivita, pro jiné použitelnost,…

28 Rozdělení priorit požadavků
Důležité nejen pro určení pořadí implementace, ale pomáhá to také vyjasnit zákazníkova očekávání. Tradičně požadavky s vysokou (důležité a naléhavé kvůli smluvním nebo právním požadavkům nebo z podnikatelských důvodů), střední (důležité ale ne naléhavé, mohou počkat do další verze) a s nízkou prioritou (nespěchají).

29 Kontrola požadavků V - model SW vývoje naznačuje, že testování přijetí SW vychází z uživatelských požadavků, systémové testování z funkčních požadavků a integrační testování z architektury systému. viz Obr. dále Provádí se neformální (popis si přečte někdo jiný než autor) a formální recenze (probíhá podle jasně definovaného procesu se vstupy, recenzenty a výstupy, shrnutím všech chyb a problémů, které z nich plynou. Typem recenzního řízení je inspekce požadavkové dokumentace. Fáze inspekce viz Obr. dále

30