Úvod do softwarového inženýrství IUS 2010/2011 p.1/43

Transkript

1 Úvod do softwarového inženýrství IUS 2010/ přednáška Ing. Radek Kočí, Ph.D. Ing. Bohuslav Křena, Ph.D. Úvod do softwarového inženýrství IUS 2010/2011 p.1/43

2 Organizace předmětu Přednášky D105 + D0207 D105 + D0207 1BIA + 2BIA + 2BIB 1BIB + 2BIA + 2BIB úterý 16:00 17:50 pátek 10:00 11:50 Ing. Bohuslav Křena, Ph.D. Ing. Radek Kočí, Ph.D. V úterý 28. září 2010 přednáška není (státní svátek). V rámci přednášek je vyhrazeno 10 minut pro studijní koutek. Konzultace: fóra v IS FIT, , osobně Děkujeme prof. M. Bielikové za poskytnutí původních přednášek. Úvod do softwarového inženýrství IUS 2010/2011 p.2/43

3 Organizace předmětu Projekty Projekty (35 bodů): 1. absolvování e-learningového kurzu (5 bodů) 2. dokumentace k projektu z IZP (10 bodů) registrace v IS FIT 3. model informačního systému (20 bodů) registrace v IS FIT Konzultace a hodnocení: 1. projekt: tým doktorandů pod vedením Bc. Petry Nastulczykové 2. projekt: tým doktorandů pod vedením doc. RNDr. Jitky Kreslíkové, CSc. a Ing. Aleše Smrčky 3. projekt: Ing. Jan Fiedor, Ing. Vendula Hrubá, Ing. Ondřej Lengál a Ing. Petr Müller Úvod do softwarového inženýrství IUS 2010/2011 p.3/43

4 Organizace předmětu Projekty Podmínky zápočtu (nutné splnit všechny): minimálně 1 bod z 1. projektu (absolvování e-learningového kurzu), minimálně 8 bodů ze 3. projektu, minimálně 17 bodů ze všech projektů. Další poznámky: Pro uznání loňských bodů z projektů se do přihlaste v IS FIT. Vzorové řešení 3. projektu bude prezentováno na přednáškách. Za odevzdání 3. projektu týden před termínem 2 prémiové body. Pozdní odevzdání 3. projektu není tolerováno. Projekty se vypracovávají samostatně! Cvičení ani laboratoře v IUS nejsou. Úvod do softwarového inženýrství IUS 2010/2011 p.4/43

5 Organizace předmětu Hodnocení Projekty: 35 bodů Zkouška: 65 bodů Celkem: 100 bodů Pro přistoupení ke zkoušce je nutný zápočet. Zkouška má 3 termíny (pouze při 4F lze jít k dalšímu). Stupnice ECTS (European Credit Transfer System): Bodů Klasifikace Číselně Slovně A 1 výborně B 1,5 velmi dobře C 2 dobře D 2,5 uspokojivě E 3 dostatečně 0-49 F 4 nevyhovující Úvod do softwarového inženýrství IUS 2010/2011 p.5/43

6 Organizace předmětu Zkouška Studium je investice do vzdělání, která má vysokou návratnost. lepší pozice s vyšším platem Především na Vás je, jak bude investice 3-5 let života úspěšná. FIT nabízí v praxi vysoce ceněné vzdělání, ale nemůže ho studentům vnutit proti jejich vůli. Snaží se ale chránit své dobré jméno a atraktivitu svých absolventů na trhu práce. Zkouškou se zjišt uje komplexní zvládnutí látky vymezené v dokumentaci předmětu prezentované ve výuce na úrovni odpovídající absolvované části studia a schopnosti získané poznatky samostatně a tvůrčím způsobem aplikovat. (SZŘ VUT, Čl. 12, Odst. 3) Pro získání bodů ze zkoušky je nutné zkoušku vypracovat tak, aby byla hodnocena nejméně 30 body. V opačném případě bude zkouška hodnocena 0 body. Nezkoumejte, jak projít studiem s co nejmenším úsilím, ale sami se snažte naučit co nejvíc. Ovlivní to celou Vaši profesní kariéru! Úvod do softwarového inženýrství IUS 2010/2011 p.6/43

7 Histogram hodnocení 2009 Úvod do softwarového inženýrství IUS 2010/2011 p.7/43

8 Organizace předmětu Komunikace Informační systém fakulty (IS FIT) termíny a jejich hodnocení diskuzní fóra slidy k přednáškám Webová stránka předmětu plán přednášek zadání 3. projektu odkazy na literaturu a další studijní materiály Úvod do softwarového inženýrství IUS 2010/2011 p.8/43

9 Cíle předmětu získat základní přehled v oblasti tvorby rozsáhlých softwarových systémů, seznámit se s procesem tvorby softwaru a s etapami jeho životního cyklu, naučit se používat základní modely UML. Úvod do softwarového inženýrství IUS 2010/2011 p.9/43

10 Co je to softwarové inženýrství?? Úvod do softwarového inženýrství IUS 2010/2011 p.10/43

11 Co je to softwarové inženýrství? systematický přístup k vývoji, nasazení a údržbě softwaru The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software. (IEEE Standard Computer Dictionary, 1990) inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých softwarových systémů (Vondrák, 2002) Úvod do softwarového inženýrství IUS 2010/2011 p.10/43

12 Co je to softwarové inženýrství? systematický přístup k vývoji, nasazení a údržbě softwaru The application of a systematic, disciplined, quantifiable approach to development, operation, and maintenance of software; that is, the application of engineering to software. (IEEE Standard Computer Dictionary, 1990) inženýrská disciplína zabývající se praktickými problémy vývoje rozsáhlých softwarových systémů (Vondrák, 2002)! softwarové inženýrství programování Úvod do softwarového inženýrství IUS 2010/2011 p.10/43

13 Proč softwarové inženýrství? Software je všude okolo nás. Je nutné zlepšovat vlastnosti SW, hlavně jeho spolehlivost, bezpečnost a použitelnost. Je potřeba zvyšovat produktivitu vývoje SW. Úvod do softwarového inženýrství IUS 2010/2011 p.11/43

14 Historie SW inženýrství 60. léta problémy při vývoji větších programů zavedení pojmů softwarové inženýrství a softwarová krize na konferencích v letech SW krize se projevovala (a stále projevuje) neúnosným prodlužováním a prodražováním projektů nízkou kvalitou výsledných produktů problematickou údržbou a inovacemi špatnou produktivitou práce programátorů řada projektů končila neúspěchem Hledání jednoduchého a účinného řešení na existující problémy vedlo ke strukturovanému programování, jehož začátek je spojován s článkem pana Dijkstry o používání příkazu GOTO. Úvod do softwarového inženýrství IUS 2010/2011 p.12/43

15 Kvalita Kvalita je souhrn vlastností a charakteristik výrobku, procesu nebo služby, které ukazují jeho schopnost splnit určené nebo odvozené potřeby. (ISO 8402) Kvalita není definovaná jako absolutní míra, ale jako stupeň splnění požadavku či potřeb. Kvalita je míra stupně dokonalosti (Oxfordský slovník) splnění požadavků (Crosby) vhodnost k danému účelu (ISO 9001) schopnost produktu nebo služby plnit dané potřeby (BS 4778) Pokud bude cílem vyvinout nespolehlivý software, pak čím méně bude tento software spolehlivý, tím bude kvalitnější. Úvod do softwarového inženýrství IUS 2010/2011 p.13/43

16 Kvalita výrobku čas cena splnění požadavků Úvod do softwarového inženýrství IUS 2010/2011 p.14/43

17 (Ne)úspěšnost SW projektů (Standish Group Report, USA, 1995) Překročení nákadů o Projektů méně než 20 % 15,5 % % 31,5 % % 29,6 % % 10,2 % % 8,8 % více než 400 % 4,4 % Překročení času o Projektů méně než 20 % 13,9 % % 18,3 % % 20,0 % % 35,5 % % 11,2 % více než 400 % 1,1 % Úvod do softwarového inženýrství IUS 2010/2011 p.15/43

18 (Ne)úspěšnost SW projektů (Standish Group Report, USA, 1995) Výsledná funkčnost Projektů méně než 25 % 4,6 % % 27,2 % % 21,8 % % 39,1 % 100 % 7,3 % Průměrný SW projekt tedy v porovnání s původním plánem: stál o 89 % více, trval 2,22 krát déle a poskytuje pouze 61 % funkčnosti. Průměrný projekt byl tedy téměř 7 krát horší, než se původně plánovalo! Úvod do softwarového inženýrství IUS 2010/2011 p.16/43

19 Historie SW inženýrství 70. léta výzkum dobrých programovacích praktik zdůraznění lidského faktoru při programování návrh shora-dolů (postupné zjemňování a modulární programování) podpora řízení tvorby softwaru technika programování v týmech (pravidlo vedoucího programátora) zavedení pojmu abstraktní datový typ metodologie strukturovaná analýza a návrh datově a procesně orientované metody vnímání životního cyklu tvorby softwaru nárůst významu a důležitosti etap specifikace a návrhu snahy o zabezpečení kvality vývoj procedur zaměřených na systematické testování zavedení pojmu formální správnost programu využití formálních transformací specifikace do programu Úvod do softwarového inženýrství IUS 2010/2011 p.17/43

20 Historie SW inženýrství 80. léta využívání vývojových (programovacích) prostředí snaha o počítačovou podporu jednotlivých metod vývoj CASE prostředků pokračující vývoj funkcionálního, logického i imperativního programování rozvoj dalších programových paradigmat např. objektově-orientované programování vývoj formálních metod specifikace a návrhu větších programů pokroky v oblasti paralelního programování zvýšení významu etapy nasazení a údržby softwaru vývoj systémů na podporu údržby verzí softwarových objektů a řízení konfigurací SW systémů Úvod do softwarového inženýrství IUS 2010/2011 p.18/43

21 Historie SW inženýrství 90. léta rozšíření prototypování vývoj softwaru založený na znovupoužitelnosti (angl. reusability) a komponentách rozvoj objektově-orientovaného programování, rozšíření jazyka Java pozornost se věnuje OO specifikacím a návrhu schémata a vzory (např. návrhové vzory) aplikace technik znalostních systémů a umělé inteligence do softwarového inženýrství sledování kvality softwarového procesu a softwaru použitím metrik vývoj open source software snahy o efektivní využití Internetu; nové metody, techniky a prostředky spolupráce; pozornost se věnuje tvorbě distribuovaného SW a metodám a technikám distribuové tvorby SW Úvod do softwarového inženýrství IUS 2010/2011 p.19/43

22 Historie SW inženýrství Vývoj jazyků 1954 Fortran 1958 Algol Lisp 1967 Simula Smalltalk 1970 Pascal C Prolog 1980 Smalltalk Object Pascal C++ Self Common Lisp 1989 CLOS 1995 Java 2000 C# Úvod do softwarového inženýrství IUS 2010/2011 p.20/43

23 Současnost SW inženýrství zavedení UML (Unified Modelling Language) do praxe rozvoj formálních technik pro analýzu a verifikaci systémů důraz je kladen na podporu zákazníků, servis, údržbu softwaru,... outsourcing rozvoj agilních metodologií extrémní programování (extreme programming) SCRUM... rozvoj metod návrhu založených na modelech Model Based Design (Development) Model Driven Architecture MDA... Úvod do softwarového inženýrství IUS 2010/2011 p.21/43

24 Hlavní cíle SW inženýrství Management projektu řízení životního cyklu projektu dosažení požadovaného výsledku v požadovaném čase efektivní práce s časem a tedy i s náklady Techniky analýzy návrhu programování testování... Vlastnosti SW inženýra základní báze znalostí schopnost aplikovat znalosti schopnost vyhledávat nové informace a osvojit si nové znalosti... Úvod do softwarového inženýrství IUS 2010/2011 p.22/43

25 Softwarový produkt Členové jedné komunity vytvářejí výrobky (software) pro členy jiné komunity (uživatelé). Softwarový produkt je sbírka počítačových programů, procedur, pravidel a s nimi spojená dokumentace. Software zahrnuje např.: požadavky, specifikace, popisy návrhu, zdrojové texty, testovací data, příručky,... Proč vlastně vytváříme software? Řešení problému není možné bez použití počítačů. předpověd počasí, bankomaty prostředek pro používání nových technologií psaní na počítači, návrh součástek zlepšení služeb zákazníkům (informační systém knihovny) snížení nákladů (řízení skladu) Úvod do softwarového inženýrství IUS 2010/2011 p.23/43

26 Vztah mezi programem a softwarem Program používá autor, v podmínkách, pro které ho vyvinul. 3x Program systém sbírka spolupracujících programů; dohodnutá rozhraní; dohodnuté prostředky 3x 3x Program výrobek může používat, opravovat a rozšiřovat kdokoliv; otestovaný a s dokumentací 3x Softwarový systém Úvod do softwarového inženýrství IUS 2010/2011 p.24/43

27 Typy softwarových výrobků Generické Software se prodává libovolnému zájemci (krabicový software). Musí být velice důkladně otestován, protože opravy chyb jsou vzhledem k velkému rozšíření drahé. Zákaznické (na objednávku) Software se vytváří na základě požadavků pro konkrétního zákazníka. Většinou pro specializované aplikace, pro které vhodný generický software neexistuje. Cena zákaznického softwaru je výrazně vyšší. Dvě možnosti jeho tvorby: zadáním zakázky SW firmě v rámci vlastní firmy Úvod do softwarového inženýrství IUS 2010/2011 p.25/43

28 Vlastnosti softwarového produktu použití (Nejedná se o funkcionalitu, ale o ty vlastnosti softwaru, které jsou potřeba až tehdy, kdy se software začne používat.) Správnost míra, do jaké software vyhovuje specifikaci. Spolehlivost pravděpodobnost, že software bude v daném čase vykonávat zamýšlenou funkci. Efektivnost splnění kritérií na využití zdrojů počítačového systému, na čas potřebný na realizaci a dalších kritérií spojených se samotným vývojem (např. náklady). Použitelnost úsilí, které je nutné vynaložit na to, aby se dal software používat. Bezpečnost míra odolnosti vůči neoprávněným zásahům do systému. Úvod do softwarového inženýrství IUS 2010/2011 p.26/43

29 Vlastnosti softwarového produktu přenos Přenositelnost úsilí, které je nutné pro přenos softwaru z jedné platformy na jinou. Znovupoužitelnost míra, do jaké je možné jednotlivé části softwaru znovu použít v dalších aplikacích. Interoperabilita úsilí, které je potřebné k zajištění spolupráce systému s jinými systémy. Úvod do softwarového inženýrství IUS 2010/2011 p.27/43

30 Vlastnosti softwarového produktu změny Udržovatelnost úsilí, které je potřeba vynaložit na další vývoj a údržbu softwaru podle měnících se potřeb zákazníka a také v důsledku měnícího se okolí (např. změna legislativy). Testovatelnost úsilí nutné pro testování vlastností softwaru, např. zda se chová správně. Dokumentovanost míra, do které jsou všechna rozhodnutí při vývoji zdokumentována a kontinuita dokumentace v průběhu všech etap vývoje. Úvod do softwarového inženýrství IUS 2010/2011 p.28/43

31 Problémy při vývoji softwaru Podstatné, vnitřní, nevyhnutelné problémy: Složitost žádné dvě části nejsou stejné; složitost je zdrojem dalších problémů jako např. komunikace v týmech; je náročné pochopit všechny možné stavy systému; problémy s úpravami a rozšířeními,... Přizpůsobivost když se něco změní, měl by se přizpůsobit software a ne naopak. Nestálost mění se okolí a mění se i software (nejde o nahrazení novým); přibývají požadavky na úspěšně používaný software; software přežívá hardwarové prostředky. Neviditelnost neexistuje přijatelný způsob reprezentace softwarového výrobku, který by pokryl všechny aspekty; dokonce ani nejsme schopni určit, co v dané reprezentaci chybí. Syndrom 90% hotovo: Při posuzování hotové části se nevychází z hotového, ale z odpracovaného (např. podle plánu). Úvod do softwarového inženýrství IUS 2010/2011 p.29/43

32 Problémy při vývoji softwaru Problémy, které se nemusí projevit vždy: specifikace požadavků problematická komunikace s uživatelem nejasná a neúplná formulace požadavků spojená s neucelenou představou uživatele o výsledném softwarovém systému nejednoznačnost spojená s častou specifikací požadavků v přirozeném jazyce nestálost, rozporuplnost požadavků přirozená neúplnost a nepřesnost při specifikaci velkých softwarových systémů nedostatek znalostí z analyzované oblasti a z toho vyplývající problémy s plánováním projektu problémy s testováním a validací požadavků náchylnost softwaru k chybám Hodně chyb se projeví až při provozu (a ne při vývoji). Odstraňování chyb vede k návratu v etapách vývoje softwaru. Úvod do softwarového inženýrství IUS 2010/2011 p.30/43

33 Problémy při vývoji softwaru Další problémy, které se nemusí projevit vždy: práce v týmu problémy s organizací práce na velkých softwarových projektech problémy s plánováním procesu tvorby softwaru Komunikační problémy jsou jedním z hlavních zdrojů chyb v programech. extrémní odchylky v produktivitě mezi jednotlivými programátory, až 1:20 nízká znovupoužitelnost při tvorbě softwaru V procesu tvorby softwaru je málo standardů a většinou se software tvoří od začátku. S každým programem se vymýšlí už vymyšlené. Málo produktů se sestavuje z už existujících součástí. problém míry Metody použitelné na řešení malých problémů se nedají přizpůsobit na řešení velkých (složitých) problémů. software nelze vyrábět Úvod do softwarového inženýrství IUS 2010/2011 p.31/43

34 Problémy při vývoji softwaru A ještě další problémy, které se nemusí projevit vždy: tvorba dokumentace Tvorba dokumentace je podobná tvorbě vlastního programu. enormní rozsah dokumentace co do kvantity i rozmanitosti Např. ve velkých vojenských softwarových projektech připadalo 400 anglických slov na každý příkaz v programovacím jazyce Ada. problémy s udržováním aktuálnosti dokumentace vzhledem ke změnám softwaru problémy s konzistencí a úplností dokumentace způsob stárnutí softwaru Přidávání nových funkcí ve spojení s častými opravami chyb vede k postupné degradaci struktury a k snižování spolehlivosti softwarových systémů. Software se fyzicky neopotřebuje. Úvod do softwarového inženýrství IUS 2010/2011 p.32/43

35 Typická chybová křivka hardwaru Úvod do softwarového inženýrství IUS 2010/2011 p.33/43

36 Typická chybová křivka softwaru Úvod do softwarového inženýrství IUS 2010/2011 p.34/43

39 Příčiny zastavení softwarových projektů... podle analýzy víc jak 350 firem a 8000 aplikací: neúplnost nebo nejasnost požadavků (13,1 %) nedostatek zájmu a podpory ze strany uživatele (12,4 %) nedostatek zdrojů, tj. podhodnocený rozpočet a krátké termíny (10,6 %) nerealistické očekávání (9,9 %) malá podpora od vedení dodavatele nebo odběratele (9,3 %) změna požadavků a specifikace (8,7 %) nedostatečné plánování (8,1 %) vyvíjený systém už není potřeba (7,5 %)... Úvod do softwarového inženýrství IUS 2010/2011 p.35/43

40 Katastrofy způsobené chybou SW 1996: Přetečení při konverzi 64 b. čísla v plovoucí řádové čárce na 16 b. celé číslo se znaménkem reprezentující vertikální rychlost vedlo 40 s po startu k autodestrukci rakety Ariane : V důsledku odstranění hardwarové zábrany proti nadměrnému ozáření při vývoji lékařského přístroje Therac-25 a SW chyb bylo nadměrně ozářeno 6 pacientů (3 na následky zemřeli). Varující je zejména přístup výrobce, který při prvních případech nadměrného ozáření místo nápravy tvrdil, že k němu nemůže dojít. Další informace jsou např. na URL: huckle/bugse.html Úvod do softwarového inženýrství IUS 2010/2011 p.36/43

41 Důležité faktory pro úspěch SW projektů zájem, zapojení uživatelů podpora vedení zákazníka jasně definované požadavky dobré plánování realistické očekávání správná dekompozice úlohy kompetentnost zúčastněných... Úvod do softwarového inženýrství IUS 2010/2011 p.37/43

42 Pár postřehů Freda Brookse Přidáním dalších pracovníků do zpožděného projektu se tento projekt ještě více zpozdí. Napsání překladače Algolu zabere 6 měsíců nezávisle na tom, kolik ho vytváří programátorů. Efekt (syndrom) druhého sytému při návrhu druhé verze systému hrozí rizika: příliš složitý a neefektivní systém Systém není dokonalý, když k němu nelze nic přidat, ale tehdy, když z něho nelze nic odstranit. nepoužití nových technologií Úvod do softwarového inženýrství IUS 2010/2011 p.38/43

43 Studijní koutek Měl by vám pomoci s orientací při studiu. Je pro něj vyhrazeno posledních 10 minut přednášky. Zde uvedené informace se nezkoušejí. Můžete posílat náměty na to, co vás zajímá. Úvod do softwarového inženýrství IUS 2010/2011 p.39/43

44 Vysoké učení technické v Brně Historie 1849 německo-české technické učiliště 1899 Česká vysoká škola technická v Brně 1956 Vysoké učení technické v Brně Vedení Nejvyšším představitelem vysoké školy je rektor. 51. rektorem VUT v Brně je prof. Ing. Karel Rais, CSc., MBA Fakulty Fakulta stavební - FAST Fakulta strojního inženýrství - FSI Fakulta elektrotechniky a komunikačních technologií - FEKT Fakulta informačních technologií - FIT Fakulta architektury - FA Fakulta výtvarných umění - FAVU Fakulta podnikatelská - FP Fakulta chemická - FCH Úvod do softwarového inženýrství IUS 2010/2011 p.40/43

45 Fakulta informačních technologií Historie 1964 Ústav informatiky a výpočetní techniky na FE (později FEI) 2002 Fakulta informačních technologií (FIT) Vedení Nejvyšším představitelem fakulty je děkan. 1. děkanem FIT byl ( ) prof. Ing. Tomáš Hruška, CSc. 2. děkanem FIT je doc. Ing. Jaroslav Zendulka, CSc. Studijním poradcem je Ing. Miloš Eysselt, CSc. Proděkanem pro vzdělávací činnost v bakalářském studiu je Ing. Bohuslav Křena, Ph.D. v magisterském studiu je Ing. Richard Růžička, Ph.D. Ústavy Ústav inteligentních systémů Ústav informačních systémů Ústav počítačových systémů Ústav počítačové grafiky a multimédií Úvod do softwarového inženýrství IUS 2010/2011 p.41/43

46 Akademický senát FIT Akademický senát FIT VUT v Brně schvaluje předpisy FIT, které doplňují vnitřní předpisy VUT v Brně, volí děkana a schvaluje rozpočet FIT, je volen akademickou obcí FIT (a tedy i studenty), je složen ze dvou komor: komora akademických pracovníků (8 členů) studentská komora (4 + 1 člen) Vnitřní předpisy FIT, které se nejvíce dotýkají studentů: Směrnice děkana doplňující studijní a zkušební řád VUT v Brně, Směrnice děkana doplňující stipendijní řád VUT v Brně, Disciplinární řád pro studenty FIT. Úvod do softwarového inženýrství IUS 2010/2011 p.42/43

47 Akademický senát VUT v Brně schvaluje předpisy platné pro celou školu, volí rektora a schvaluje rozpočet VUT v Brně, je volen akademickou obcí celé školy, je složen ze dvou komor: komora akademických pracovníků studentská komora FIT zastupují 2 zaměstnanci a 1 student. Vnitřní předpisy, které se nejvíce dotýkají studentů: Studijní a zkušební řád VUT v Brně, Stipendijní řád VUT v Brně, Úvod do softwarového inženýrství IUS 2010/2011 p.43/43