Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

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

Podobné prezentace


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

1 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. 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. 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). 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. 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,.. 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: 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: 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 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”. 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ů Formát pro vyjádření požadavků – bude, kde –id jedinečný identifikátor –název systému –„bude” – klíčové slovo –vykonávaná funkce

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

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í. Nefunkční požadavky je třeba zaznamenat a neustále je promítat do návrhu řešení. Použít katalogový záznam 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 Realizace projektu v přírůstcích Pouze jedna zodpovědná osoba na straně dodavatele Pouze jedna zodpovědná osoba na straně dodavatele Realizace kontrolních dnů každý měsíc Realizace kontrolních dnů každý měsíc Podpora hotového produktu po dobu 7 let Podpora hotového produktu po dobu 7 let Provoz na platformách Linux/Unix Provoz na platformách Linux/Unix Podpora uložení dat v DB ORACLE Podpora uložení dat v DB ORACLE Odezva systému do 3 sekund při všech operacích Odezva systému do 3 sekund při všech operacích …

10 Záznam požadavku Atributy požadavků (pro dodatečné informace) 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á 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. 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ů. 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č.) 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. 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í 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) 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 Úč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ů Typy požadavků ještě jednou - vztahy mezi různými typy požadavků Viz Obr. Viz Obr.

15 Vývoj a správa požadavků Základní discipliny Základní discipliny práce s požadavky práce s požadavky viz Obr. viz Obr. Vývoj požadavků jako proces 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. 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 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í. 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 Méně chyb v požadavcích Snížení objemu přidělávané práce Snížení objemu přidělávané práce Méně nepotřebných funkcí Méně nepotřebných funkcí Nižší náklady na vylepšování Nižší náklady na vylepšování Rychlejší vývoj Rychlejší vývoj Méně nedorozumění Méně nedorozumění Menší pravděpodobnost tichého rozšiřování rozsahu, menší chaos v projektu Menší pravděpodobnost tichého rozšiřování rozsahu, menší chaos v projektu Přesnější odhady Přesnější odhady Spokojenější zákazník i vývojář Spokojenější zákazník i vývojář

18 Vlastnosti požadavků a celé specifikace Vlastnosti dobře popsaných požadavků Vlastnosti dobře popsaných požadavků –Úplnost –Správnost –Proveditelnost –Nepostradatelnost –Priorita –Jednoznačnost –Ověřitelnost Vlastnost celé specifikace Vlastnost celé specifikace –Úplnost –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. 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. 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). 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. 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í…) 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ů,…) 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,…) 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, Kontrola (provést revizi, testovat požadavky) testovat požadavky) Proces vývoje požadavků viz Obr. 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 Stanovit postup verzování změnového řízení včetně zřízení komise Pro každou změnu provést analýzu Pro každou změnu provést analýzu Verzovat i dokumentaci požadavků Verzovat i dokumentaci požadavků Vést historii změn (datum, změna, autor a důvod) Vést historii změn (datum, změna, autor a důvod) Sledovat stav každého požadavku Sledovat stav každého požadavku Používat nástroj pro správu požadavků Používat nástroj pro správu požadavků Vytvořit spojovací matici (požadavek X odkaz na implementační kód, testy) 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) Ú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í). 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. Viz Obr.

24 Dokumentace požadavků Tři způsoby psaní 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 Šablona pro specifikaci požadavků ze standardu IEEE 830 viz Obr. Dále Modelování požadavků 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 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 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). 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,… 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í. 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í). 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 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 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


Stáhnout ppt "Požadavky na SW Od zadání k architektuře aplikace."

Podobné prezentace


Reklamy Google