SWI041: Modelování a realizace programových systémů. Rozsah: 2+1 Přednášející: Karel Richta Zakončení: z,zk.

Transkript

1 SWI041: Modelování a realizace programových systémů Rozsah: 2+1 Přednášející: Karel Richta Zakončení: z,zk.

2 Úvodem trochu historie Termín software zavedl v roce 1958 statistik John Tukey (také autor termínu bit ). Za okamžik zrození termínu softwarové inženýrství se obvykle považuje rok 1968, kdy NATO sponzoruje první konferenci s tímto názvem a na toto téma. V roce 1969 na ni navázala konference Techniky softwarového inženýrství. V roce 1972 vychází prvníčasopis Transactions on Software Engineering (IEEE Computer Society). V roce 1976 vytváří IEEE Computer Society první komisi, která by měla definovat obsah oboru softwarové inženýrství. SWI041 - Úvod 2

3 Proč to vůbec vzniklo? Něco bylo špatně Počítačů přibývalo, přibývalo i softwarových projektů, ale ubývalo úspěšně dokončených projektů. Někdy to došlo až na hranici únosnosti software byl, nebo mohl být, příčinou havárií. SWI041 - Úvod 3

4 Případ sondy Mariner I. (1962) Mariner I. byla sonda, která měla za cíl Venuši. Musela být zničena 293 sekund po startu. Příčinou byla hardwarová chyba v anténě, ta ale způsobila, že ovládání přešlo z počítače na zemi na lokální počítač rakety. A tam byla v softwaru chyba. Vznikla ručním přepisem vzorce, ve kterém programátor přehlédl aplikaci funkce (znázorněné nadepsanou čarou ), což způsobilo chybu ve výpočtu, která způsobila odklon rakety z požadované dráhy.

5 Případ Mercury (1962) Ve stejné době odhalili inženýři jinou chybu, která bývá s touto často zaměňována, ačkoliv nezpůsobila žádnou škodu. Záměna čárky za tečku ve FORTRANu: Místo "DO 17 I = 1,10", což je cykl, bylo "DO17I = 1.10", to je ale přiřazení do proměnné DO17I. Pozn.: Mezery nejsou ve FORTRANu důležité. Naštěstí se ale chyba odhalila dříve, než se mohla projevit. Iniciovala testování podle struktury programu, neboť výše uvedený cyklus nebyl v testování nikdy vyzkoušen.

6 Úplně se to vždy v nepovedlo (1996) Pád rakety Ariane 5: Neobsloužená výjimka při operaci v pohyblivé řádové čárce (konverzi). Ztráta 100 mil. $ (včetně družic Cluster, které nesla, 500 mil. $). Návrat programu Ariane o několik let zpět. Díky chybě dal řídicí počítač rakety příkaz k současnému vychýlení trysek urychlovacích bloků, tak i trysky motoru. Tím se kurs rakety prudce změnil a v důsledku aerodynamických sil se horníčást rakety odlomila. Byl aktivován vlastní autodestrukční systém rakety a raketa se změnila v oblak hořících úlomků 6

7 Případ Apollo 11 (1969) První přistání na Měsíci se v roce 1969 nezdařilo přesně podle představ. Přistávací modul Eagle se o 4 vteřiny odchýlil od plánované trajektorie. Mezi velké kameny poblíž kráteru dosednul pod manuálním řízením Neila Armstronga (míle daleko od zvoleného místa). Způsobil to zapnutý radar, který spotřeboval neplánovaný čas procesoru.

8 Výpadek elektřiny USA (2003) Způsobena neregistrovaným výpadkem automatizovaného hlásiče poruch v elektrárně u Niagary, který se kaskádně rozšířil sítí. Postihlo to až 50 mil. obyvatel, zemřeli 3 lidé, škoda 6 mld. $.

9 Přistávací modul na Marsu (1999) Celková ztráta Mars Climate Orbiter 125 mil. $ Problém komunikace mezi komponentami uživatel rozhranní očekával hodnotu v kilometrech, poskytovatel ji udával v mílích. Ve výšce 57 km se nepodařilo modul ukotvit na oběžné dráze (měl být ve výšce 145 km).

10 Zakládaj dající konference 1968 Organizátoři první konference Softwarové inženýrství v roce 1968 zvolili termín softwarové inženýrství úmyslně jako provokativní naznačující, že produkce software musí přejít na jiné postupy a být podložena teoretickými disciplinami, podobně, jako je tomu u inženýrského přístupu v jiných oborech. Konala se ve Spolkové republice Německo ve známém středisku Garmisch-Partenkirchen a řídil ji profesor Bauer z Mnichovské techniky. Účastnilo se jí asi 50 odborníků z různých oblastí, z praxe i ze škol. Její účastníci formulovali směry, kterými by se výzkum v oboru SI měl ubírat. SWI041 - Úvod 10

11 Termín n softwarové inženýrstv enýrství Softwarové inženýrství je disciplina, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. Konference Softwarové inženýrství 1968 SWI041 - Úvod 11

12 Termín n softwarové inženýrstv enýrství Softwarové inženýrství je disciplina, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. Konference Softwarové inženýrství 1968 SWI041 - Úvod 12

13 Termín n softwarové inženýrstv enýrství Softwarové inženýrství je disciplina, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. Konference Softwarové inženýrství 1968 SWI041 - Úvod 13

14 Další historie - standardizace V roce 1979 vytváří Fletcher Buckley standard IEEE 370 pro vytváření plánů zajišťujících kvalitu software. V roce 1986 vzniká standard IEEE 1002, který definuje taxonomii softwarově inženýrských standardů vznikají standardy pro proces životního cyklu software (Standard for Software Life Cycle Processes) - standard ISO/IEC12207, vychází z DoD Std 498. V roce 1993 vznikají komise IEEE a ACM, které ústí do společného úsilí definovat softwarové inženýrství jako disciplinu. SWI041 - Úvod 14

15 Další historie SWI jako profese V roce 1998 společná komise IEEE a ACM definuje profesi softwarového inženýra. Nakonec v roce 2004 vzniká společný návrh curricula pro výuku tohoto oboru, označovaného SE2004. Tím se završilo uznání softwarového inženýrství jako discipliny, podobně jako CS1991 završilo uznání informatiky. Softwarové inženýrství je definované jako standard IEEE SWI041 - Úvod 15

16 Příčina vzniku SWI? Obvykle se říká, že to způsobil jev nazývaný softwarová krize. Dokud výkon počítačů nepřesáhl určitý rozměr, bylo možno se spolehnout na programátorské hvězdy. Často se počítače se využívaly pro vědeckotechnické výpočty, kde záleželo spíše na preciznosti řešení, než na efektivitě tvorby programů. SWI041 - Úvod 16

17 Moorův zákon: Výkon hardwaru vzrůstá zhruba dvakrát za dva roky. Přestože sám autor prohlásil svou extrapolaci jako pěkně divokou, zákon zhruba platí dodnes. Firma Intel nedávno zveřejnila výsledky výzkumné zprávy uvádějící, že Moorův zákon pravděpodobně přestane platit až kolem roku 2021 (křemík se dostane na hranici svých možností). SWI041 - Úvod 17

18 Softwarová krize HW SW SWI041 - Úvod 18

19 Edsger W. Dijkstra: Hlavní příčinou softwarové krize byl nárůst výkonu hardware. Jinak řečeno, programování nemělo problémy, dokud neexistovaly počítače. Dokud jsme měli slabé počítače, mělo programování jen snesitelně těžké problémy. Nyní máme gigantické počítače a k nim gigantické problémy se softwarem. SWI041 - Úvod 19

20 Projevy softwarové krize Projekty překračují rozpočet. Projekty překračují čas. Software nemá dostatečnou kvalitu. Software neodpovídá požadavkům. Projekt není dobře řiditelný a software je obtížně udržovatelný. SWI041 - Úvod 20

21 Skončila softwarová krize? Při pohledu na předchozí body a současné projekty se zdá, že softwarová krize trvá stále. Svůj vliv zde mají též možnosti softwarových expertů, kteří jakkoli jsou geniální, mohou přímo mentálně obsáhnout jen určitý rozsah problémů. Řešení velkých projektů nelze proto nechat pouze na nich. Je nutno použít standardní techniku řešení obtížných problémů rozděl a panuj velký problém je třeba rozdrobit na problémy menší. SWI041 - Úvod 21

22 Zkušenost (Brooks): Přidání nových kapacit na zpožděný projekt prodlouží jeho řešení. SWI041 - Úvod 22

23 Tvorba software inženýrstv enýrství Všechny tyto problémy související se softwarovou krizí vedly tedy nakonec k pokusu udělat z vývoje produkovaného nadšenci inženýrskou disciplinu. V 70-tých letech dochází k formulaci základních principů tohoto oboru. Vzniká také první generace nástrojů pro podporu této discipliny, které jsou označovány jako CASE (Computer Aided Software Engineering). SWI041 - Úvod 23

24 Co dělád inženýr? Než něco vyrábí, tak si to nejdříve nakreslí, namodeluje. K tomu potřebuje zavedenou notaci a vědecky podložené metody a postupy. Snaží se používat vhodné technologie tak, aby se dílo vytvořilo spolehlivě, efektivně a aby vydrželo. Srovnáme-li softwarového inženýra s inženýrem stavebním, pak stavební inženýr realizuje stavbu podle modelu, programátor programuje podle modelu. Model stavebnímu inženýrovi navrhl architekt (územní rozhodnutí, stavební povolení, realizace stavby), programátorovi softwarový architekt (úvodní studie, návrh architektury), analytik (konceptuální model) a návrhář (logický model). SWI041 - Úvod 24

25 První studijní programy Prvý inženýrský program byl vypsán již v roce 1979 na universitě v Seattlu, kde v roce 1982 udělili prvý titul v tomto oboru. Prvý bakalářský program v oboru SWI vypsalo v roce 1996 vysoké učení technické v Rochesteru. Zpočátku byl odmítnut, ale později akreditaci získal v roce 2003 spolu s inženýrskou školou v Milwaukee. SWI041 - Úvod 25

26 Definice IEEE : Softwarové inženýrství je aplikace systematického, disciplinovaného, kvantifikovatelného přístupu k vývoji, provozu a údržbě softwaru, tj. aplikace inženýrství na software. Také je to studium přístupů dle výše uvedeného. SWI041 - Úvod 26

27 Co nám n m SWI přineslo? p Řadu novinek, namátkou některé: Softwarové profese a týmy. Modely životního cyklu. Oddělení správy dat od správy funkčnosti. Strukturované metody. Objektově-orientované metody. Komponentové metody. Nové programovací jazyky. Softwarové zápisy unifikovaná notace UML. Metodiky tvorby softwaru. Plánování, metriky, organizace. SWI041 - Úvod 27

28 Co nám n m SWI odneslo? Pocit opravdových programátorů: Software vytvářejí specializovaní odborníci, kteří jediní znají postupy, nástroje, metody a techniky. Plánování a podobné hlouposti sem nepatří. Dokumentaci ať si pořizují ti, kteří neumějí číst programy přímo. SWI041 - Úvod 28

29 Neznámý programátor: Softwarové inženýrství znamená zavedení discipliny do volné tvorby software. Žádný opravdový programátor ho proto nemůže mít příliš v lásce, neboť jej nutí vytvářet nesmyslnou dokumentaci a další podobné artefakty. SWI041 - Úvod 29

30 Smysl předmp edmětu SWI041 Seznámit se s metodami a nástroji používanými při modelování a realizaci programových systémů, protože to patří k běžnému vybavení absolventů universit v oboru softwarové inženýrství. Absolventi KSI MFF by neměli být pozadu a měli by se umět domluvit s absolventy jiných škol. SWI041 se zabývá zejména analýzou, návrhem a implementací programových systémů, neboť se zdá, že tyto profese budou ještě určitý čas žádané. SWI041 - Úvod 30

31 Sada znalostí softwarového inženýra SWEBOK (Software Engineering Body of Knowledge IEEE a ACM 2004) SEEK (Software Engineering Education Knowledge - SE2004) Pozn.: Na přípravě se podílejí známá jména jako Pressman, Sommerville, McConnell, na revizi ale také Jan Pavelka, Mária Bieliková, Pavol Návrat SWI041 - Úvod 31

32 Základníčlenění informatiky (CS) Diskrétní struktury (43) Základy programování (38) Algoritmy a složitost (31) Architektura a organizace (36) Operační systémy (18) Výpočty orientované na síť (15) Programovací jazyky (21) Styk člověka s počítačem (8) Grafika a vizualizace (3) Inteligentní systémy (10) Správa informací (10) Sociální a profesionální otázky (16) Softwarové inženýrství (31 11%) Počítačová věda a numerické metody (0) Počet hodin povinné výuky celkem 280 SWI041 - Úvod Zdroj: CC

33 Z toho softwarové inženýrstv enýrství Povinný základ: Návrh Programová rozhranní (API) Softwarové nástroje a prostředí Softwarové procesy Požadavky a specifikace Validace softwaru Vývoj softwaru Řízení softwarových projektů Volitelné doplňky: Komponentový vývoj Formální metody Spolehlivost softwaru Vývoj specializovaných systémů SWI041 - Úvod Zdroj: SE

34 Základní znalostní oblasti SWI Správa požadavků (Software requirements) Softwarový návrh (Software design) Tvorba softwaru (Software construction) Testování softwaru (Software testing) Údržba softwaru (Software maintenance) Správa konfigurací (Software configuration management) Řízení vývoje (Software engineering management) Softwarový proces (Software engineering process) Nástroje a metody softwarového inženýrství (Software engineering tools and methods) Kvalita softwaru (Software quality) SWI041 - Úvod Zdroj: SE

35 Kde se co učíu na KSI (jen SWI): SWI026: Softwarové inženýrství - přehledová přednáška o rozmanitých aspektech softwarového inženýrství. SWI041: Modelování a realizace softwarových produktů hlavní důraz je zde kladen na zpracování a analýzu požadavků, modelování, notaci UML, modelem řízený vývoj a využívání nástrojů typu CASE. SWI129: Softwarové inženýrství pro praxi hlavní důraz je zde kladen na projektovou stránku vývoje, zkušenosti z praxe, Q&A, konfiguračnířízení, vedení a organizaci projektů, modely životního cyklu, odhadování, plánování, proces vývoje projektu a organizace. SWI126: Nástroje pro vývoj a monitorování SW - správa verzí, sestavování, testování funkčnosti i výkonnosti, hledání chyb ve funkčnosti, zlepšování výkonnosti, udržování kvality software, komunikace mezi vývojáři, distribuce a instalace software, dokumentování a indexování kódu, integrovaná vývojová prostředí. SWI049: Informační systémy - Spolu s Informačními systémy II obsahují úplný komplet znalostí spojených s vývojem a používáním informačních systémů s důrazem na ta témata, která nejsou pokryta jinými přednáškami. SWI123: Vedení projektů v praxi hlavní důraz je zde kladen na praktické vyzkoušení nabytých znalostí, seznámit posluchače s praktickými aspekty vedení projektu a procvičit jeho řízení na konkrétním softwarovém příkladu. Softwarový projekt dvou-semestrový předmět, kde hlavní důraz je zde kladen na praktické zkušenosti z práce v týmu a nabytí komunikačních dovedností na konkrétním softwarovém projektu. SWI041 - Úvod 35

36 Osnova přednp ednášek Úvod do softwarového inženýrství, plánování projektů Modelování požadavků (CIM) Analýza (PIM) Architektura SW, MDA Návrh (PSM) Návrhové vzory Metodiky Testování Další novinky pro vývoj: WS, SOA, SWI041 - Úvod 36

37 Jak se SWI041 učí? u Projektová forma výuky. Projekty do výuky patří (kromě klasické výuky). Vyzkoušet si realizaci programového systému na příkladu projektu řešeného v týmu. SWI041 - Úvod 37

38 I see,, I forgotf rgot, I hear,, I recall, I do, I understand. Kong Fu Zi SWI041 - Úvod 38

39 Co je to projekt? Projekt je dobře definovaná posloupnost činností, která má určen začátek a konec, je zaměřena na dosažení nejistého cíle a je uskutečňována pomocí zdrojů lidí a prostředků. Projekt je specifická nerutinní akce, která proto vyžaduje plánování. Čím složitější je projekt, tím více vyžaduje plánování. SWI041 - Úvod 39

40 Co je to softwarový projekt? Softwarový projekt je projekt, jehož cílem je vytvoření nebo využití programového díla. Při uskutečňování SW projektů se uplatní SW inženýři, kteří nabyli znalostí v předmětech KSI (mimo jiné také v předmětu SWI041). SWI041 - Úvod 40

41 Jaké jsou softwarové projekty v předmětu SWI041? Větší projekt se za semestr nestihne (zkušenost). Projekt představuje hodně práce - je třeba řešit projekty v týmech (navíc se učíme týmovou práci a zodpovědnost). Projekt je třeba ukončit prezentací a obhajobou (prezentace práce představuje důležitou praktiku). Také metodika posouzení jiného projektu přináší nové poznatky. SWI041 - Úvod 41

42 Co z toho vyplývá? Studenti jsou rozděleni do týmů někteří studenti představují řešitele, jiní dělají manažery, testéry kvality a pod. Volbu organizace týmu a přidělení do rolí v týmech necháváme na řešitelích. Tým řeší projekt, který si zvolí a dohodne. Cvičení jsou projektová konají se tak, jak to odpovídá potřebě projektů! SWI041 - Úvod 42

43 SWI041 Jak získat známku Předmět SWI041 je zakončen zápočtem a zkouškou. Zápočet se uděluje na základě akceptovaného projektu. Známka je určena kvalitou projektu a znalostmi u zkoušky. SWI041 - Úvod 43

44 SWI041: Co je akceptovatelný projekt? Pro získání zápočtu z SWI041 je třeba: Realizovat projekt, který projde akceptačním testem. Provést akceptační test jiného projektu. SWI041 - Úvod 44

45 Aktivity SWI041 v UML Výběr projektu Téma projektu Analýza, příprava smlouvy o projektu Smlouva o projektu (definice akceptačního testu) Návrh a implementace Dokumentace projektu Akceptační test Výsledky testu Not OK OK SWI041 - Úvod 45

46 Co to znamená: Realizovat projekt znamená: sestavit dokumentaci (včetně plánu a definice akceptačního testu) vytvořit potřebné programy absolvovat akceptační test prezentovat projekt Posoudit cizí projekt znamená: prostudovat dokumentaci cizího projektu být přítomen při prezentaci cizího projektu participovat na akceptačním testu cizího projektu sepsat posudek SWI041 - Úvod 46

47 Přibližná osnova: Témata projektů, výběr projektu, rozdělení do týmů Zpracování analytické specifikace, plán projektu Definice akceptačního testu (smlouva o projektu) Návrh (dekompozice na komponenty) Implementace komponent Testování komponent Integrace komponent Akceptační test Prezentace Posouzení cizího projektu SWI041 - Úvod 47

48 Důležité termíny 1. a 2.týden volno, domluva témat a týmů 3.týden témata projektů (krátká prezentace), potvrzení projektů a týmů 4.týden smlouva o projektu (včetně definice akceptačního testu) 12.týden - odevzdání projektu (včetně dokumentace) Poslední 2 týdny - posouzení jiného projektu, prezentace, oponentura, zápočet SWI041 - Úvod 48

49 Obsah dokumentace projektu Projektová dokumentace Smlouva o projektu, definice akceptačního testu Řesitelský tým (funkce, zodpovědnosti) Harmonogram řešení Programová dokumentace Dokumentace návrhu řešení Zdrojové texty programů Makefile Instalační příručka Uživatelská příručka SWI041 - Úvod 49

50 Témata projektů Stránka předmětu SWI041 - Úvod 50

51 Co to znamená posoudit cizí projekt? Získávat zkušenosti pro práci na SW projektech lze nejen realizací softwarového projektu (vytvořením a prezentací vlastního projektu), ale i posuzováním cizích projektů (prostudováním dokumentace cizího projektu, přítomností při prezentaci cizího projektu, sepsáním posudku na cizí projekt). SWI041 - Úvod 51

52 Proto: Každý tým bude působit ve 2 rolích: v roli řešitele v roli posuzovatele. V roli řešitele tým projekt vytváří, v roli posuzovatele tým projekt posuzuje. SWI041 - Úvod 52

53 Osnova přednp ednášek: 1. Životní cyklus programového díla, softwarový projekt a jeho fáze, řízení projektů (ZDA a PROČ). 2. Sběr a analýza požadavků, notace UML, konceptuální modelování, analýza (CO). 3. Návrh a implementace SW, logické modely používané při návrhu, implementace SW, testování (JAK). SWI041 - Úvod 53

54 Literatura Tyto přednášky SWI041 - Úvod 54

55 Softwarové týmy a softwarové profese Jedním z projevů přechodu od ruční výroby k manufaktuře je definice softwarových profesí. Řešení velkých projektů vyžaduje spolupráci mnoha řešitelů a práci je nutno rozdělit. Dělba práce vyžaduje organizaci týmů řešících větší softwarové projekty. Týmy lze organizovat jako strukturované nebo nestrukturované. SWI041 - Úvod 55

56 Nestrukturované týmy Dělí práci podle objemu. Mohou být organizovány jako: Osamělí vlci Horda Demokratická skupina SWI041 - Úvod 56

57 Strukturované týmy Dělí práci podle profese. Mohou být organizovány jako: Chirurgický tým Tým hlavního programátora Agilní skupina Více-týmová organizace SWI041 - Úvod 57

58 Kterou organizaci zvolit? Volba organizace je dána rozsahem projektu. Na větší projekty je třeba více-týmová organizace. Pro větší projekty se samozřejmě hodí strukturované týmy. Máme-li dost prostředků, je nejvýkonnější chirurgický tým. Nemáme-li, nejefektivnější může být agilní skupina. SWI041 - Úvod 58

59 Akceptační test

60 Co to je akceptační test? Akceptační test představuje podklad pro ověření funkčnosti řešení. Definice akceptačního testu musí proto obsahovat následující náležitosti: 1. podmínky pro akceptační test, 2. dokumentaci pro akceptační test, 3. definici akcí pro akceptační test. SWI041 - Úvod 60

61 1. Podmínky pro akceptační test Popis prostředí, ve kterém bude akceptační test probíhat. Není-li v akceptačním testu prostředí explicitně stanoveno, musí být možno akceptační test vykonat v rámci standardního prostředí na katedře. Popis všech vstupních dat, která budou v akceptačním testu využívána. Patří sem popis všech databází, konfiguračních souborů a jiných testovacích dat, která budou v akceptačním testu využívána. SWI041 - Úvod 61

62 Příklad projektu ECO-sklad operátor SWI041 - Úvod 62

63 Podmínky pro akceptační test Podmínky akceptačního testu pro ECO - Produkt ECO bude realizován jako formulářová aplikace pro MS-Windows, pracující s daty uloženými v databázi Oracle. Produkt bude vytvořen pomocí nástrojů Designer/2000 a Developer/ Forms. Akceptační test produktu ECO může proto probíhat kdekoli, kde je přístup z MS-Windows k serveru Oracle. Pro provedení akceptačního testu je nutno mít právo přihlásit se jako uživatel do MS-Windows. Dále je nutné mít přístup k nějaké vhodné databázi Oracle jako uživatel, který může instalovat data produktu. SWI041 - Úvod 63

64 Podmínky pro akceptační test (pokr.) Podmínky akceptačního testu pro ECO - Před spuštěním produktu ECO je nutno vytvořit v databázi objekty aplikace a uložit do nich testovací data. Doporučený postup je vytvoření uživatele ECOuser, přidělit mu právo na vytváření objektů a pod tímto uživatelem spustit skript (creco.sql), který vytvoří potřebné objekty pro ECO a naplní je počátečními testovacími daty. Po absolvování akceptačního testu lze data z databáze odstranit zrušením uživatele ECOuser (s kaskádním odstraněním jeho objektů). SWI041 - Úvod 64

65 2. Dokumentace akceptačního testu Dokumentace potřebná pro vytvoření a instalaci produktu Uživatelská příručka Definice akceptačního testu Protokol o provedení akceptačního testu SWI041 - Úvod 65

66 Dokumentace akceptačního testu Dokumentace akceptačního testu pro ECO Návod pro instalaci aplikace ECO (zahrnuje popis instalace datové základny a formulářů aplikace) Uživatelská příručka produktu ECO Definice akceptačního testu ECO Protokol o provedení akceptačního testu SWI041 - Úvod 66

67 Dokumentace akceptačního testu (pokr.) Dokumentace akceptačního testu pro ECO - Instalace formulářů pro ECO (NT) - Instalační CD aplikace ECO obsahuje soubor setup.exe - Pomocí Start Nastavení Ovládací panely Přidat nebo ubrat programy nainstalujete formuláře aplikace ECO. V domovském adresáři aplikace se vytvoří i soubory potřebné pro instalaci datové základny, včetně testovacích dat a online uživatelské příručky. - Stejným postupem se formuláře aplikace ECO odinstalují. SWI041 - Úvod 67

68 Dokumentace akceptačního testu (pokr.) Dokumentace akceptačního testu pro ECO - Instalace testovacích dat pro ECO - Před spuštěním produktu ECO je nutno vytvořit v databázi objekty aplikace a uložit do nich testovací data. Doporučený postup je vytvoření uživatele ECOuser, přidělit mu právo na vytváření objektů a pod tímto uživatelem spustit skript (creco.sql), který vytvoří potřebné objekty pro ECO a naplní je počátečními testovacími daty. Po absolvování akceptačního testu lze data z databáze odstranit zrušením uživatele ECOuser (s kaskádním odstraněním jeho objektů). SWI041 - Úvod 68

69 3. Definice akceptačního testu Vychází se z definice aktérů - začíná se kontextem aplikace SWI041 - Úvod 69

70 Př.: ECO-sklad (model jednání) Definice akceptačního testu pro ECO SWI041 - Úvod 70

71 Pro akceptaci ECO je třeba stanovit: Definice akceptačního testu pro ECO Jak se vyzkouší zařazení do role OPERÁTOR a MANAŽER Jak se ověří, že každá role má k dispozici požadovanou sadu služeb SWI041 - Úvod 71

72 Akce akceptačního testu Popis všech scénářů, které budou tvořit akceptační test. Sada scénářů musí zaručit dostatečné ověření funkčnosti řešení. Pro testovací scénáře, pro které je možno stanovit požadovanou reakci systému, je součástí akceptačního testu i popis odpovídajících reakcí. Scénáře akceptačního testu musí zahrnovat i základní chybové situace a jejich řešení. Vychází se z životního cyklu systému. SWI041 - Úvod 72

73 Definice akcí pro akceptační test Definice akcí akceptačního testu pro ECO Akce 1: Instalace a spuštění aplikace ECO možné reakce: OK nepovedlo se Akce 2: Zařazení do rolí OPERÁTOR a MANAŽER možné reakce: OK nepovedlo se povedlo se, ale nejsou k dispozici služby SWI041 - Úvod 73

74 Životní cyklus ECO-skladu Definice akceptačního testu pro ECO Čeká na přihlášení uživatele entry: Zobrazení LOGIN [ LOGOUT ] [ konec ] přihlášení( jméno, heslo ) [ neregistrovaný uživatel ] / Chybná identifikace Selekce role [ registrovaný MANAŽER ] [ registrovaný OPERÁTOR ] Menu pro roli "OPERÁTOR" entry: Nabídka služeb Menu pro roli "MANAŽER" entry: nabídka služeb [ přejímka ] [ dodávka ]... podobně zpracování přejímky zpracování dodávky SWI041 - Úvod 74

75 Scénáře pro ECO (viz( model jednání) Operátor provádí přejímku Operátor vybavuje dodávku Definice akceptačního testu pro ECO Manažer se dotazuje na stav skladu Manažer zjišťuje, zda je sklad v bezpečném stavu SWI041 - Úvod 75

76 Pro akceptaci ECO je třeba stanovit: Jak se vyzkouší chování při akci dotaz na stav skladu Jak se vyzkouší chování při zjišťování, zda je sklad bezpečný Jak se vyzkouší chování při akci přejímka Jak se vyzkouší chování při akci dodávka Jak se ověří, že aplikace umí navázat akce SWI041 - Úvod 76

77 Definice akcí pro akceptační test (pokr.) Akce 3: Dotaz na stav skladu možné reakce: OK Definice akcí akceptačního testu pro ECO povedlo se - ale chybný výsledek nepovedlo se Akce 4: Dotaz na bezpečnost skladu Akce 5: Přejímka pro správnou dodávku Akce 6: Přejímka pro chybnou dodávku... SWI041 - Úvod 77

78 Popis akce Identifikace akce Popis: textový popis akce Co předpokládá Jaké reakce vyvolává (jaké zprávy posílá) Jaká data čte, mění nebo vytváří Co zajišťuje (zaručuje) SWI041 - Úvod 78

79 Popis pro Akci 3 Akce: 3 Popis: Dotaz na stav skladu Předpokládá: Postup: spuštění funkce dotaz na stav skladu musí vytvořit sestavu zobrazující aktuální stav skladu SWI041 - Úvod 79

80 Vstupní data pro akci 3: Definice akceptačního testu pro ECO ECO sklad musí být ve stavu S3 získaném importem souboru ECOS3.dmp příkazem imp file=ecos3.dmp SWI041 - Úvod 80

81 Výstupní reakce na akci 3: Definice akceptačního testu pro ECO Pokud je sklad ve stavu S3 měla by akce 3 vytvořit následující sestavu: Stav ECO skladu 100% Obsah 50% 0% S1 S2 O3 Kapacita A B C Budova SWI041 - Úvod 81

82 Scénář pro přejímku Definice akceptačního testu pro ECO SWI041 - Úvod 82

83 Životní cyklus přejímky Definice akceptačního testu pro ECO přejímka = prázdná plošina. dodací list. (barel k zařazení. #ID barelu)*. konec přejímky. [#rozdíly v přejímce]. #příkaz pro skladníka. [#nelze uložit] Musí se vyzkoušet: zda produkt nepovolí nesprávné pořadí akcí případ správné přejímky, SWI041 - Úvod 83

84 Popis pro Akci 5 Akce: 5 Popis: Přejímka pro správnou dodávku Předpokládá ECO-sklad v korektním stavu Postup: spuštění funkce přejímka - musí vyvolat formulář pro zadání informací z dodacího listu zadávají se údaje o barelech - generují se ID barelů (viz Vstupní data 5)... Po ukončení musí být ECO-sklad ve správném stavu (ověří se funkcí dotaz na stav ) a bezpečný (ověří se funkcí je bezpečný? ) SWI041 - Úvod 84

85 Vstupní data pro akci 5: ECO sklad musí být ve stavu S5 získaném importem souboru ECOS5.dmp příkazem imp file=ecos5.dmp Dodací list: 5 barelů typu A Postup vykládky: 4 barely typu B 2 barely typu C A, A, B, C, B, C, A, A, A, B, B Definice akceptačního testu pro ECO SWI041 - Úvod 85

86 Výstupní reakce na akci 5: Definice akceptačního testu pro ECO Pokud je sklad ve stavu S5 měla by akce 5 vyvolat následující: Nebyly detekovány žádné rozdíly mezi dodacím listem a skutečnou dodávkou Nebyly detekovány žádné barely, které nelze do skladu umístit Příkaz pro skladníka obsahuje všechny barely dodávky a nikdy neumisťuje barely typu B a C do stejné budovy, celkový počet barelů v budově nepřesáhne kapacitu budovy. SWI041 - Úvod 86

87 Scénář pro dodávku Definice akceptačního testu pro ECO SWI041 - Úvod 87

88 Životní cyklus dodávky Definice akceptačního testu pro ECO dodávka = prázdná plošina.požadovaná dodávka. #skutečná dodávka. #příkaz pro skladníka Musí se vyzkoušet: zda produkt nepovolí nesprávné pořadí akcí případ, kdy požadovanou dodávku lze splnit případ, kdy požadovanou dodávku nelze splnit zda jsou reakce systému správné SWI041 - Úvod 88

89 Popis pro barel k zařazen azení Operation: barel k zařazení Description: každý vyložený barel je jednoznačně identifikován Reads: supplied typ_chemikálie Changes: plošina, new b: Barel Sends: operátor:{id barelu} Assumes: Results: nakládací plošina obsahuje barel b operátor dostane identifikaci ID barelu atribut b.typ je nastaven na typ_chemikálie atribut b.id je nastaven na identifikaci ID barelu SWI041 - Úvod 89

90 Popis pro konec přejímky Operation: konec přejímky Description: informuje systém, že již byly vyloženy všechny barely Reads: plošina, zadaný_dodací_list Changes: budovy ve skladu Sends: operátor:{rozdíly v přejímce, nelze uložit}, skladník:{příkaz pro skladníka} Assumes: sklad je bezpečný SWI041 - Úvod 90

91 Popis pro konec přejímky (pokračování) Results: pro všechny barely, které lze do skladu umístit, přesune v modelu jejich umístění do vhodné budovy a vytvoří príkaz pro skladníka(kam: alokační seznam) pokud existují rozdíly mezi zadaným_dodacím_listem a skutečnou dodávkou, vytvoří se rozdíly v přejímce(navíc, chybí: seznam barelů) pro všechny barely, které nelze do skladu umístit vytvoří nelze uložit(co: seznam barelů) sklad je bezpečný SWI041 - Úvod 91

92 Obsah dokumentace SWI041 Programová dokumentace Projektová dokumentace SWI041 - Úvod 92

93 Dokumentace projektu SWI041S SWI041 - Úvod 93

94 The End