• Projevovala se (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 nízkou produktivitou práce programátorů.
• Hledání řešení problémů vedlo k zavedení strukturovaného programování

• Členové jedné komunity (programátoři) vytvářejí software (výrobek) pro jinou skupinu lidí (uživatelé).
• Softwarový produkt zahrnuje požadavky, specifikace, popisy návrhu, zdrojové texty programů, testovací data, příručky, manuály, ...

• Software šitý na míru určitého zákazníka.
• Jeho cena je vyšší, mohou je jej dovolit větší firmy.
• Typicky systémy pro řízení výroby, leteckého provozu, atd...

• Složitost - Není možné pochopit všechny stavy systému a důsledky jeho úprav. Problém komunikace v týmech.
• Syndrom 90% hotovo - Pri posuzování hotové části se vychází z odpracovaného (podle plánu), nikoliv ze skutečně hotového. 
• Specifikace požadavků
• Náchylnost softwaru k chybám - Hodně chyb se projeví až při provozu SW systému, ne při vývoji.
• Práce v týmu - komunikační problémy pri vývoji velkých projektů. 
• Tvorba dokumentace - Velké projekty vyžadují mnohem více dokumentace. Těžko se pak udržuje její aktuálnost. 
• Stárnutí softwaru - Postupné přidávání nových funkcí a časté opravy chyb vedou k degradaci struktury a ke snižování spolehlivosti SW. V případě, kdy už je situace neúnosná, je lepší vytvořit nový, lepší. Oprava starého systému by situaci jen zhoršila. 
• Syndrom druhého systému - Autor povzbuden úspěchem prvního systému chce udělat nový systém dokonalý, avšak nový systém je pak přiliš složitý, nepřehledný a neefektivní. (Systém není dokonalý, když k němu nelze nic přidat, ale tehdy, když z něho nelze nic odstranit.)

Postupné přidávání nových funkcí a časté opravy chyb vedou k degradaci struktury a ke snižování spolehlivosti SW. V případě, kdy už je situace neúnosná, je lepší vytvořit nový, lepší. Oprava starého systému by situaci jen zhoršila.

[image]

• Analýza a specifikace požadavků
• Přání zákazníka je potřeba analyzovat a zapsat je v strukturované podobě. Pozornost je věnována pouze požadavkům samotným, nikoliv jejich realizaci.
• Součástí této etapy by měla být studie proveditelnosti a analýza rizik.
• Architektonický návrh - slouží k ujasnění koncepce systému a jeho dekompozici. Plánuje se akceptační testování a zasazení do provozu (včetně zaškolování uživatelů).
• Podrobný návrh - soustřeďuje se na podrobnou specifikaci softwarových součástí, na výběr algorytmů, na stanovení struktury dat, ošetřování chyb. Specifikují se požadavky na lidské zdroje, odhaluje se doba trvání a náklady na projekt. Výsledek by měl být návrh testů součástí včetně testovacích dat.
• Implementace a testování součástí - Programová realizace softwarových součástí, vypracování dokumentace a otestování implementovaných součástí.
• Integrace a testování systému - Spojení součástí do jednoho celku, otestování celého systému, oprava chyb v součástech, které se projevily až při integraci.
• Akceptační testování a instalace - Otestování systému uživatelem/zákazníkem. Po akceptaci systému zákazníkem následuje instalace systému a školení uživatelů.
• Provoz a údržba - Průběžné řešení problémů souvisejících s používáním softwaru.

Základní model životního cyklu softwaru - jednotlivé etapy jsou řazeny za sebou. Problém tohoto modelu představuje uživatel, který není schopný na začátku přesně specifikovat požadavky. Tento model nedpovídá reálnému vývoji projektů.

• výhody:
• jednodužší na řízení
• při stálých požadavcích, nejvhodnější struktura výsledného produktu
• nevýhody:
• zákazník není schopen přesně předem stanovit své požadavky
• při změnách požadavků dlouhá realizace
• zákazník vidí spustitelnou verzi až v závěrečných fázích projektu --> odhalení nedostatku příliš pozdě

[image]

Je to varianta vodopádového modelu s větším důrazem na testování.

[image]

Aktivity spojené s ověřováním a testováním jsou na stejné úrovni jako návrhové aktivity --> druhé souběžné V

[image]

Proces vývoje sw je rozdělen do iterací. Jednotlivé iterace lze chápat jako instance vodopádového modelu. Po každé iteraci má uživatel k dispozici spustitelnou verzi SW s neúplnou funkcionalitou.

výhody:

• Zákazník má možnost validovat výsledek svými požadavky (každá iterace má reálný výsledek)

nevýhody:

• náročnější na řízení
• potencionálně horší výsledná struktura

[image]

Na základě specifikace jsou stanoveny ucelené části systému, které se uživateli odevzdávají postupně. Kombinace lineárního a iterativního typu.

výhody:

• zjednodušené zavedení během vývoje

nevýhody:

• vývoj po částech může vést ke ztrátě vnímání logiky a technických požadavků celého systému
• problematické je plánování termínů a cen
• vyžaduje stálou spolupráci se zákazníkem

Není to ucelený model, je součástí jiných systémů.

Prototyp - částečná implementace produktu, prezentuje vnější rozhraní systému --> validace, dále se nepoužívá.

[image]

• Kombinace prototypování a analýzy rizik.
• Jednotlivé etapy se neustále opakují, vždy na vyšším stupni zvládnutí problematiky

výhody:

• vhodný pro složité projekty
• nezávislý na metodologii
• chyby a nevyhovující postupy hned odhaleny

nevýhody:

• analýza rizik musí být na vysoké úrovni
• problematické plánování termínů a cen
• vyžaduje neustálou spolupráci se zákazníkem
• SW je k dispozici až po posledním cyklu

analýza rizik:

• cílem je odhalit možné ohrožení projektu (odchod lidí, snížení rozpočtu, selhání HW, nezájem o produkt) a připravit na ně reakce

[image]

výhody:

• rychlý iterativní vývoj protypů
• funkční prototypy jsou k dispozici dříve než u ostatních modelů
• schopnost rychlé změny návrhu podle požadavků
• úspora času, peněz a lidských prostředků

nevýhody:

• velká rychlost a nízké náklady mohou vést k nižší kvalitě
• projekt může skončit s více požadavky, než je nutné

S cílem zjednodušení komunikace mezi vývojáři byl v roce 1995 definován jazyk UML (Unified Modelling Language). Tento jazyk neposkytuje sám o sobě žádnou metodologii, nabízí pouze prostředky pro unifikovanou tvorbu modelů různých aspektů navrhovaného systému. UML je však součástí různých metodologií návrhu, např. RUP.

•  Pohled (view) Pohled je projekce systému na jeden z jeho aspektů, ostatní aspekty jsou pohledem ignorovány. Nad jedním systémem je vhodné vytvářet celou řadu pohledů:
• Strukturální pohled (structural view) popisuje vrstvu mezi objekty a třídami a jejich vztahy.
• Pohled chování (behavioral view) popisuje, jak objekty interagují a charakterizuje reakce na vnější podněty.
• Datový pohled (data view) popisuje stavy objektů a jejich vazby.
• Pohled rozhraní (interface view) popisuje zapouzdření komponent systému a jejich potenciální použití okolím systému.

Je narozdíl od předchozích modelů použitelný pro řízení reálných SW projektů.

RUP je výsledkem výzkumu řady velkých firem koordinovaných firmou Rational.

RUP klade důraz na vizualizace SW systému pomocí jazyka UML. Je to objektově orientovaná metodika, věnuje se všem etapám vývoje SW (kdo, co, kdy, jak...).

4 fáze, zahájení, projektování, realizace, předání

[image] 

• Smyslem Abstrakce je zjednodušit pohled na celý systém bez ztráty jeho významu. Každému objektu pak odpovídá určitá zodpovědnost za řešení identifikované části problému – objekt je abstrakcí části řešeného problému.
• Pomocí zapouzdření jsou skrývány implementační detaily objektu.
• Dědičnost umožňuje vytvářet nové objekty na základě již existujících objektů. Vyjadřuje hierarchický vztah mezi objekty.
• Polymorfismus Stejné zprávy mohou být zpracovány různým způsobem v závislosti na typu objektu. Rozlišujeme statický/dynamický polymorfismus a na základě toho říkáme že vzniká časná/pozdní vazba. Při časné vazbě je metoda vybrána v čase kompilace. Při pozdní vazbě je metoda vybrána za běhu programu.

• Třída je generická definice pro množinu objektů, které mají stejné chování a stejnou množinu atributů. Jde tedy o abstrakci nad objekty. Každý objekt je potom instancí své třídy.
• Dědičnost je relace uspořádání na množině tříd. Jednoduchá / vícenásobná dědičnost, víme... 
• Identita objektu Dva objekty téže třídy mohou být shodné, ne však identické. Nesouvisí s třídou. 

Realizace je vztah mezi třídou a rozhraním , který říká, že třída implementuje všechny operace z daného rozhraní.

• Rozhraní je speciální typ třídy, která specifikuje pouze množinu operací, ne však jejich implementaci. Na místě rozhraní lze pak použít kteroukoliv třídu, která rozhraní implementuje. Rozhraní se označují pomocí << interface >>. Pomocí rozhraní lze omezit počet vazeb mezi třídami. 

• Získání požadavků od uživatele - Zjistit, o jaký produkt má zákazník zájem, vymezit jeho funkcionalitu, ... Důraz je kladen na požadavky uživatele, nikoliv na způsob jejich realizace.
• Transformace požadavků uživatele do strukturované podoby - Požadavky od uživatele je potřeba převést do částečně formálního, strukturovaného popisu. Cílem je jednoznačné zadání odsouhlasené zákazníkem, které slouží jako výchozí bod. Změny požadavků se od této chvíle musí dokumentovat.
• Studie vhodnosti, analýza rizik - Na základě dostupných informací je třeba odhadnout, zda jsme schopni požadovaný produkt vytvořit za předpokládanou cenu v předpokládané době.
• Plánování akceptačního testování - Plán akceptačního testování by měl být součástí smlouvy se zákazníkem. Tento plán říká, jak se bude SW produkt testovat při přebírání zákazníkem, jaké výsledky testů budou považovaný za úspěšné, atd.

• Funkcionální požadavky - určují, co má systém dělat.
• Požadavky na provoz systému - definují podmínky, za jakých má SW pracovat.
• Požadavky na výsledný systém - počítačové vybavení, OS, programovací jazyk, spolehlivost, přenositelnost, bezpečnost, ... 
• Požadavky na vývojový proces - požadavky zákazníka na dodržování norem během vývoje a předávání systému 
• Požadavky na rozhraní systému se svým okolím (včetně GUI)
• Externí požadavky - etické požadavky, ochrana osobních údajů, ...

• Vyřadění - v době specifikace je nějaká entita implicitní, ale s odstupem času se může vytratit
• Deformace, zkreslení - získaná informace může zavazet
• Zobecnění - věta je příliš všeobecná, proto je nepravdivá.

• Klasifikované položky jsou propojeny statickými vztahy
• Kromě tříd obsahuje rozhraní, seskupení a vztahy
• Je často používaný na modelování a návrh systému

[image]

• Zobrazuje objekty jako instance tříd a jejich vztahy
• Jsou úzce spojeny s diagramy tříd
• Popisuje statickou strukturu systému ve specifickém čase
• Využívají se na testování přesnosti diagramu tříd
• IDK + jsou dynamické diagramy, které zachycují konkrétní instance tříd a jejich vazby v určitém čase. V objektovém diagramu nalézají využití stereotypy << instantiate >>.

[image]

• ukazuje seskupení příbuzných elementů systému a závislostí mezi nimi
• je užitečný na uspořádání rozsáhlých systémů

[image]

• vytváří se s pomocí uživatelů na zjistění funkčních požadavků na systém, hranice a rozsah systému
• představuje soubor případů užití, aktérů, vzájemných vztahů
• každý případ užití popisuje postupnost událostí

[image]

• Modelování dynamického chování a změn (stavy objektů, přechody mezi stavy, počáteční a koncový bod stavových změn)
• Zachycuje stav jednoho reaktivního objektu
• Využívá se k ujasnění životního cyklu objektů

[image]

• Diagram datových toků je technika využívaná při strukturované analýze a návrhu pro specifikaci chování systému
• DFD je hierarchický model, který oproti diagramu užití obsahuje i informace o datových skladech. Je tedy blíže k návrhu.

[image]

Slouží k modelování dat, která potřebujeme uchovat, a vztahů mezi nimi. Data jsou popisována na vyšší úrovni abstrakce.

• Entita - objekt reálného světa, který je nějak rozlišitelný od ostatních
• Entitní množina - je množina entit téhož typu, tyto entity lze charakterizovat podle stejných vlastností (např. klient)
• Vztah - vyjadřuje asociaci mezi entitamy (Jan Novák vlastní učet č.42)
• Vztahová množina - množina vztahů téhož typu (klient vlastní účet)

[image]

Slabá entitní množina je existenčně závislá na jiné (silné) entitní množině. Označuje se jako <<weak>>. Identifikátor slabé ent. množiny má následující složky:

• domimantní identifikátor silné ent. množiny
• diskriminátor slabé ent. množiny

Entitu modelujeme jako slabou, když tatko entita uplně zmizi po odstranění identifikující entity. Jsme-li na pochybách, volíme silnou entitní množinu.

• Zdola-nahoru - Nejdříve se implementují moduly nejnižší vrstvy aplikace. Odladěné moduly se pak dají přímo využívat při vytváření modulů vyšší úrovně. Nevýhoda spočívá v tom, že chyby v aplikační logice se projeví až při etapě integračního testování.
• Shora-dolů - Nejdříve se vytvoří moduly na nejvyšší úrovni a pak se postupně implementují moduly nižších vrstev aplikace. Systém lze dříve otestovat jako celek a nejzávaznější chyby jsou včas odstraněny. Nevýhoda spočívá v nutnosti simulovat podsystémy, které ještě nejsou implementované.

Validace je ověření, zda software vyhovuje specifikaci.

Verifikace je ověření, zda vyvíjený software splňuje potřeby uživatele.

------------------------------------------------------------

Statické ověřování - nevyžaduje běh programu, lze ho provádět v jakékoliv etapě vývoje SW.

Dynamické ověřování (testování) - odvozuje vlastnosti SW na základě výsledků běhu programu nebo prototypu s vybranými vstupy.

Cílem testování je odhalit chyby během vývoje softwaru. Test, který neodhalí správné chování systému, je neúspěšný.

1. Nejdříve jsou navrženy testovací vstupy. Testovací vstupy obsahují množinu 2. dvojic: vstupní data / očekávaná výstupní data.
2. Vstupní data jsou zadány na vstup programu a zaznamenány výsledky (výstupní data).
3. Výstupní data se porovnají s očekávanými výstupními daty.
4. Test, který neodchalí nesprávné chování systému, je neúspěšný.

Výběr testovacích vstupů - snažíme se vybrat takové vstupy, u kterých je velká pravděpodobnost, že způsobí chybu.

• Náhodné testování - testovací vstupy jsou vybírány náhodně, například pomocí generátoru náhodných čísel. Nevýhoda spočívá v nedostatečném testování okrajových hodnot. Proto se většinou doplňuje vhodným kritériem.
• Funkcionální testování (metoda černé skříňky) - testování vychází pouze ze specifikace a neuvažuje vnitřní strukturu programu. Množina vstupních hodnot je rozložena do tříd ekvivalence. Z každé třídy ekvivalence se vybere průměrná hodnota nebo medián, hranice třídy a několik náhodných hodnot.
• Strukturální testování (metoda bílé skříňky) - testování vychází z konkrétní interpretace.
• Mutační testování - slouží pro otestování množiny testovacích vstupů. Do programu se úmyslně zanese několik chyb a podle toho, kolik chyb je zachyceno se dá odhadnout, jak úspěšné bude testování.

Projekt je časově ohraničené úsilí, které se vyvíjí s cílem vytvořit jedinečný výsledek (např. výrobek nebo službu). Je časove ohraničený, má začátek a konec. Konec je dosažen jsou-li splněny stanovené cíle.

Parametry SW projektu:

• rozsah
• kvalita
• cena
• čas

• Beran příliš důrazně prosazuje variantu, kterou považuje za nejlepší. Problém nastává pokud se v týmu potkají 2 berani. Řešením situace je vymezení odpovědnosti každému z nich.
• Slabý článek je člen týmu, který je v porovnání s ostatními členy méně šikovný. Vhodným řešením je zařadit slabý článek na méně zodpovědnou pozici.
• Dělnická mentalita Lidé s dělnickou mentalitou mají dostatečné schopnosti, ale snaží se přežít pracovní dobu s vynaložením co nejmenší námahy. Vedoucí by měl takovým lidem přidělovat dobře měřitelnou práci. 
• Snaživec odvádí na své pozici dobrou práci, ale má zájem o prestižnější místo, na které nemusí mít předpoklady. Řešením je najít snaživci uspokojivou pozici, ale takovou, která neohrozí úspěšnost projektu.

• Naplánuj (vytvoření plánu)
• Udělej (provedení plánu)
• Zkontroluj (zhodnocení výsledků)
• Jednej (zlepšení procesu řízení na základě dosažených výsledků)

• Inicializace Během inicializace se získávají relevantní informace pro plánování projektu. Součástí této etapy je studie vhodnosti a analýza rizik.
• Plánování Cílem plánování je pochopení cílů projektu a vytvoření základny pro sledování a řízení práce. Plánování je třeba provádět v rozumné míře.
• Řízení Při řízení se sleduje aktuální stav projektu a porovnává se s plánem. Na základě toho se provádějí změny v plánu a odhaduje se další vývoj projektu.
• Provádění Provádění představuje samotnou realizaci plánu. Ze všech etap spotřebuje nejvíce času a peněz.
• Ukončení Ukončení představuje předání výrobků nebo služeb zákazníkovi. Zaznamenávají se nové poznatky z vývoje projektu. Vyčleňují se prostředky na údržbu softwaru.

Systém s řadou funkcí může mít nízkou kvalitu (např. hodně chyb) a naopak.

Software bez chyb =/= kvalitní software.

[image]

Měření v sw. inženýství umožňuje sw projekty řídit. Měření může však snižovat efektivitu práce na SW produktu. Měření může být přímé a nepřímé (odvozené z přímých měření). Pro úspěch projektu je důležitá dohona na kritériiích projektu a tato kritéria musí být měřitelná

Metriky pro software:

• LOC - Lines Of Code
• kLOC - kilo LOC
• Dostupnost - pravděpodobnost, že v daném čase program pracuje správně. Počítá se nepřímo jako MTTR/MTBF.
• Chybovost - průměrný součet chyb v jednom kLOC
• MTBF (Mean Time Between Failures) - střední doba mezi výpadky systému - používá se pro měření spolehlivosti. Je dána součtem MTTR a MTTF
• MTTR (Mean Time To Recovery)
• MTTF (Mean Time To Failure)

[image]

Předpoklady

• Lidé jsou zdroje, které jsou dostupné v několika rolích: analytik, programátor, tester manager...
• proces by měl fungovat za všech okolností

Důsledky

• není důležité jaké analytiky máme, ale kolik jich máme
• člově kje predikovatelná komponenta vývojového procesu

za standartní prostředek komunikace s považuje dokumentace

Předpoklady

• Lidé mají problém fungovat konzistentně v průběhu času.
• Pokud člověk dostane každý den dostane stejný úkol, vytvoří podobné výsledky ale nikdy ne stejné
• Schopnost pracovního nasazení/soustředení se mění ze dne na den, z místa na místo (někteří pracují lépe v noci)
• Lidé jsou komunikující bytosti
• fyzická blízkost - gestikulace, hlasový projev, intonace
• otázky a odpovědi v reálném čase
• Žádný proces nikdy nevytváří dovednosti (znalosti) vývojového týmu

Důsledky

• podstatná je individualita lidí
• hlavní komunikační prostředek je osobní komunikace
• dokumentace slouží především k dokumentačním účelům

Metodologie - Disciplinovaný proces nad vývojem softwaru, který ho činí predikovatelný a efektivnější.

Agilní metodologie - Kompromis mezi klasickými metodologiemi a chaotickým přístupek k vývoji. Všechny vývoje jsou součástí návrhu, klíčovou částí dokumentace je samotný zdrojový kód. Klasické metodologie neúnosně komplikují vývoj malých projektů. Agilní metodologie kladou hlavní důraz na člověka jako na určující faktor pro kvalitu výsledného produktu.

• AM jsou adaptibilní - reagují na změny, procesy se v čase vyvíjejí. Nevytváří se detailní plány pro delší časová období.
• AM jsou orientované na lidi - každý proces se přispůsobuje vývojovému týmu. Není definovaná pevná posloupnost kroků.
• AM lépe reagují na měnící se požadavky zákazníka, ale vyžadují jeho aktivní spolupráci.

Predikovatelnost požadavků - Existují projeky, o jejichž požadavcích máme na začátku jasnou představu. U některých se ale časem požadavky mění - zejména business projekty. Také existují projekty kde máme jen mlhavou představu. Některé procesně orientované modely s tím počítají - iterativní, inkrementační, spirálový. Důležitá je však délka jedné iterace.

Metody orientované na lidi - Lidé mají fungovat konzistentně v průběhu času. Jsou různí a proměnliví (v místě i čase). Lidé jsou komunikující bytosti...

CRC Cards (Class-Responsibilities-Collaborators) - Identifikace tříd, jejich zodpovědností a spolupracujících tříd.

Je to agilní metodologie vývoje SW, vytvořená skupinou lidí okolo Kenta Becka počátkem 90. let, která předepisuje určité činnosti všem účastníkům vývojového procesu.

Jedná se o tradiční činnosti, které jsou však dovedeny do extrému. Díky tomuto by mělo být XP schopné se lépe přizpůsobit měnícím se požadavků zákaníků a dodávat SW vyšší kvality.

• Zpětná vazba - Správnost je ověřována názáklade FEEDBACKu, navrhovaný systém je co nejrychleji vyvinut a na základě FB upravován.
• Jednoduchost - Úspora času, na jednoduchých částech pro věci opravdu složité.
• Komunikace - Testování, párové programování, odhady úkolů, ...
• Odvaha - nebát se provést zásadní změny, i za cenu dočasného snížení úspěšnosti testů
• Testování - ke každé fci napíšeme testy nejlépe ještě před její implementací.
• Párové programování
• Refaktorizace -při RF se stávající návrh zjednodušuje a zefektivňuje, nemění se však funkcionalita.
• Metriky - pokud přestane metrika splňovat svůj účel, je nahrazena jinou.
• Iterace - délka iterace je 1-4 týdny. Nezbytným výsledkem každé iterace je sada testů.

Crystal -  je také metoda orientovaná na lidi, na rozdíl od XP je však méně striktní. Obecně je však méně produktivní než XP. Na konci každé iterace jsou vloženy prostředky klasických metodologií.

Scrum - Iterace má délku 30 dní a nazývá se sprint. Každý den se konají 15 minutová setkání (scrum), kde se analyzuje, co se udělalo a co je potřeba ještě udělat. Scrum je možné kombinovat s XP.

Light RUP - používá měsíční iterace. První tři dny v každé iteraci se využívá UML pro vyjasnění návrhu.

Autorské právo - vzniká automaticky počínaje vytvořením díla. Podle Všeobecné úmluvy o autorském právu (uzavřené v Ženevě v roce 1952) jsou autorská práva chráněna ještě 70 let po smrti autora. Počítačové programy jsou autorským právem chráněny jako dílo literární.

Ochraná známka - je slovní, obrazové nebo prostorové označení výrobku nebo sluzby. Plní několik funkcí:

• Rozlišovací - odlišuje výrobce nebo poskytovatele služeb
• Ochranou - Zákazník ví, co dostane.
• Propagační - Vytváří poptávku po takto označením zboží.

Obchodní tajemství - Informace podniku, které nejsou v příslušných obchodních kruzích dostupné.

Licence - Slouží k udělení práv k použití intelektuálního vlastnictví.

• Public domain - veřejné dílo, použitelné bez omezení
• Open source - Volně dostupné zdrojové kódy
• Proprietární - Výrobce prodává spustitelnou aplikaci

Open source licence - pod touto licencí je šířen SW s volně dostupnými zdrojovými kódy. Nejedná se o SW zadarmo. Program je možné spouštět, studovat, upravovat, dále šířit a zveřejňovat svá vylepšení.

• General Public Licence (GPL) - Vyžaduje, aby SW zůstal pod GPL.
• Lesser GPL - Slabší GPL, používá se např. pro knihovny.
• Free Documentation Licence (GFDL) - Používá se pro dokumentaci.
• BSD Licence - Nevyžaduje, aby upravený program byl šířen pod BSD licencí.