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? 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í. Něco
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 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í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 softwarové inž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 softwarové inž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 softwarové inž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í 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á 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 SWI přineslo? Ř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 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ř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) Počet hodin Operační systémy (18) povinné Výpočty orientované na síť (15) výuky – Programovací jazyky (21) celkem 280 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)
SWI041 - Úvod
Zdroj: CC2001
32
Z toho softwarové inž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čí 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ř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čí? 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 forgot, 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 Téma projektu
Výběr 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
Not OK SWI041 - Úvod
Výsledky testu
OK 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řednášek: 1.
2.
3.
Životní cyklus programového díla, softwarový projekt a jeho fáze, řízení projektů (ZDA a PROČ). Sběr a analýza požadavků, notace UML, konceptuální modelování, analýza (CO). 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. 2. 3.
SWI041 - Úvod
podmínky pro akceptační test, dokumentaci pro akceptační test, definici akcí pro akceptační test.
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
[ LOGOUT ]
entry: Zobrazení LOGIN přihlášení( jméno, heslo ) [ neregistrovaný uživatel ] / Chybná identifikace
Selekce role [ konec ]
[ registrovaný MANAŽER ] [ registrovaný OPERÁTOR ] Menu pro roli "MANAŽER" Menu pro roli "OPERÁTOR"
entry: nabídka služeb
entry: Nabídka služeb [ dodávka ] [ přejímka ] zpracování přejímky
SWI041 - Úvod
... podobně
zpracování dodávky
74
Scénáře pro ECO (viz model jednání)
Definice akceptačního testu pro ECO
Operátor
provádí přejímku Operátor vybavuje dodávku 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.)
Definice akcí akceptačního testu pro ECO
Akce
3: Dotaz na stav skladu
možné reakce: OK 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
Obsah
100%
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: Definice akceptačního testu pro ECO
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 4 barely typu B 2 barely typu C Postup vykládky: A, A, B, C, B, C, A, A, A, B, B
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í” 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:
SWI041 - Úvod
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
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 SWI041
SWI041 - Úvod
93
The End
