SWI041: Modelování a realizace programových systémů Rozsah: 2+1 Přednášející: Karel Richta Zakončení: z,zk.
Ú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
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
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.
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.
Ú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
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.
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. $.
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).
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
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
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
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
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ů. 1990 1995 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
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 610.12. SWI041 - Úvod 15
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
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
Softwarová krize HW SW SWI041 - Úvod 18
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
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
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
Zkušenost (Brooks): Přidání nových kapacit na zpožděný projekt prodlouží jeho řešení. SWI041 - Úvod 22
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
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
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
Definice IEEE 610.12: 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
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
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
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
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
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
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: CC2001 32
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: SE2004 33
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: SE2004 34
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
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
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
I see,, I forgotf rgot, I hear,, I recall, I do, I understand. Kong Fu Zi SWI041 - Úvod 38
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
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
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
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
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
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
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
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
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
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) http://kocour.ms.mff.cuni.cz/~richta/swi041/swi041-2008 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
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
Témata projektů http://kocour.ms.mff.cuni.cz/~richta/swi041/ Stránka předmětu SWI041 - Úvod 50
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
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
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
Literatura Tyto přednášky http://kocour.ms.mff.cuni.cz/~richta/swi041/materialy.html SWI041 - Úvod 54
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
Nestrukturované týmy Dělí práci podle objemu. Mohou být organizovány jako: Osamělí vlci Horda Demokratická skupina SWI041 - Úvod 56
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
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
Akceptační test
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
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
Příklad projektu ECO-sklad operátor SWI041 - Úvod 62
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/2000 - 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
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
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
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
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
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
3. Definice akceptačního testu Vychází se z definice aktérů - začíná se kontextem aplikace SWI041 - Úvod 69
Př.: ECO-sklad (model jednání) Definice akceptačního testu pro ECO SWI041 - Úvod 70
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
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
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
Ž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
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
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
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
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
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
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 ECOuser/heslo@instance file=ecos3.dmp SWI041 - Úvod 80
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 80 50 0 A 40 0 0 B 15 30 0 C 0 44 0 Budova SWI041 - Úvod 81
Scénář pro přejímku Definice akceptačního testu pro ECO SWI041 - Úvod 82
Ž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
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
Vstupní data pro akci 5: ECO sklad musí být ve stavu S5 získaném importem souboru ECOS5.dmp příkazem imp ECOuser/heslo@instance 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
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
Scénář pro dodávku Definice akceptačního testu pro ECO SWI041 - Úvod 87
Ž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
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
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
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
Obsah dokumentace SWI041 Programová dokumentace Projektová dokumentace SWI041 - Úvod 92
Dokumentace projektu SWI041S SWI041 - Úvod 93
The End