Obsah

30 - Životní cyklus softwaru
Diskuze

30 - Životní cyklus softwaru

mechanismus uplatňovaný při návrhu softwaru
slouží při vývoji velkých a složitých projektů
spadá pod pojem softwarové inženýrství

Softwarové inženýrství

je systematický přístup k vývoji, nasazení a údržbě softwaru
není programování
dva protichůdné aspekty:
1. poslední dobou je od počítačů očekávána stále vyšší funkčnost ⇒ větší složitost
2. požadujeme větší bezpečnost, správnost a spolehlivost
- k dosažení obou aspektů nám slouží softwarové inženýrství

Historie

stále více peněz se vkládá do vývoje softwaru
1. dříve velmi drahé sálové počítače vs. jednoduché dávkové programy
2. dnes levné notebooky/PDA vs. drahý a složitý software

problémy s rozvojem programů vyústili k zavedení pojmu softwarová krize a jako odpověď softwarové inženýrství (konference 1968 a 1969)

Průměrný SW projekt v porovnání s původním plánem stál o 89% více, jeho vývoj trval 2,22 krát déle a výsledný produkt poskytuje pouze 61% funkčnosti. Průměrný softwarový projekt byl téměř 7 krát horší, než se původně plánovalo.

řešení:
- začly vznikat nové programovací jazyky, které uměli lépe dekomponovat daný problém ⇒ zavedl se pojem abstraktní datový typ
- začal se klást důraz na jednotlivé etapy vývoje
- programuje se software založený na znovupoužitelnosti
- nástup internetu přináší další rozměr do vývoje SW ⇒ vznikají open source programy
dnes:
- významnou hraje roli rozšíření jazyka UML (Unified Modelling Language) do praxe
- důraz na podporu zákazníků, servis a údržbu softwaru
- outsourcing - zajišťování některých neklíčových operací externími pracovníky

Softwarový produkt

software, který je vytvářen členovy jedné komunity (ve smyslu výrobku) pro členy jiné komunity (pro uživatele)
není pouze samotný program ⇒ zahrnuje i požadavky, specifikace, popisy návrhu, zdrojové texty programů, testovací data, příručky, manuály, …

problém nastává, kdy se jedná o soubor komunikujících programů, kde každý vytváří někdo jiný ⇒ třeba dohodnout rozhraní a průběžně vytvářet neformální dokumentaci
kvalita:
1. splnění požadavků
2. cena
3. čas
typy softwarového produktu:
1. generický software
  - software pro širokou veřejnost
  - tzv. krabicový software
  - musí být velice dobře otestován
2. zákaznický software
  - vyvíjen pro určitého zákazníka
  - většinou pro danou specializovanou oblast neexistuje generický sw
  - cena je mnohem vyšší ⇒ prodá se jednou (občas vícekrát)
  1. firma si objedná sw
  2. firma si najme lidi, kteří se o sw starají
vlastnosti softwaru
- použití - správnost, spolehlivost, efektivnost, použitelnost, bezpečnost
- přenos - přenositelnost, znovupoužitelnost, interoperabilita (zajištění, aby systém spolupracoval s jinými systémy)
- změny - udržovatelnost, pružnost (modifikovatelnost), testovatelnost, dokumentovanost
problémy při vývoji softwaru
1. nevyhnutelné - složitost, přizpůsobivost (když se něco změní, měl by se přizpůsobit sw), nestálost, neviditelnost (90% hotovo)
2. ostatní
  - specifikace požadavků - komunikace mezi uživatelem a vývojářem, nejasné formulace, jelikož používáme přirozený jazyk…
  - náchylnost k chybám - hodně chyb se projeví až v provozu
  - práce v týmu - Přidáním dalších pracovníků do zpožděného projektu se tento projekt ještě více zpozdí.
  - nízká znovupoužitelnost
  - dokumentování
  - stárnutí softwaru ⇒ opravováním chyb se do programu zanášejí další

příčiny zastavení softwarových projektů
- 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 %)

Proces vývoje softwaru

základní věcí je transformace požadavků uživatele na požadavky na software ⇒ na jejich základě je vytvořen návrh softwaru, podle něhož je systém implementován, otestován a předán uživateli
proces vývoje závisí na dobré dekompozici
- přináší lépe zvládnutelné podsystémy
- rozdělování problému na podproblémy
- je nutné věnovat pozornost integraci podsystémů

Softwarový proces definuje kdo, kdy a co má dělat, aby bylo dosaženo požadovaného cíle.

do vývoje vstupují tři strany:
1. zákazník - objednal si systém
2. dodavatel - vytváří systém
3. uživatel - bude systém používat, upřesňuje požadavky - nemusí mít vždy zájem spolupracovat

Etapy životního cyklu softwaru

Model životního cyklu softwaru definuje etapy vývoje softwaru a pro každou etapu dále definuje nutné činnosti a její vstupy a výstupy.

v následujících podkapitolách jsem rozebral jednotlivé etapy ⇒ uvádí se také jenom 5 etap, kde etapa 2 a 3 a etapa 5 a 6 jsou spojeny

1. Analýza a specifikace požadavků

zabýváme se požadavky zákazníka ⇒ prohlášení o cílech (co má systém umět, ne jak) ⇒ analyzujeme je ⇒ snažíme se co nejvíc pochopit zákazníka
pozornost bychom měli věnovat především požadavkům, nikoli realizaci
součástí je studie vhodnosti - říká nám, zda má smysl se do projektu pouštět
identifikujeme možná rizika a analyzujeme je
nezbytným výstupem etapy je plán akceptačního testování
- testy, na jejichž základě zákazník software převezme – akceptuje
- záruka při problémech při přebírání
výstupem tedy je prohlášení o cílech, studie vhodnosti a plán akceptačního testování

Analyza

velmi důležitá etapa ⇒ čas strávený v této etapě se pak odrazí v dalších etapách ⇒ odhalení chyb v pozdějších etapách stojí více času a peněz
důraz je kladen především na požadavky, nikoli na implementaci
smyslem této etapy je především
1. získat, analyzovat a definovat požadavky
2. transformovat neformální požadavky uživatele do strukturovaného popisu požadavků
3. provést studii vhodnosti, identifikovat a analyzovat rizik
musíme mít na zřeteli i způsob řešení ⇒ jeden projekt může mít více alternativ řešení
náš projekt bude používat více uživatelů, kde každý může mít jiný názor na uživatelské rozhraní
1. naplánovat akceptačního testování

strukturovaná analýza - chápe systém jako kolekci funkcí (procesů) operujících nad daty, tj. pracujeme (navrhujeme) strukturu dat a funkce pracující s těmito daty
objektová analýza - chápe systém jako kolekci vzájemně komunikujících objektů, tj. data a funkce pracující s těmito daty jsou spolu svázány

Typy požadavků

mohou být různorodé, nemusí vždy souviset pouze s tím, co je nutné naprogramovat
důležitá vlastnost požadavků je měřitelnost (pouze u měřitelných požadavků jsme schopni určit, zda je aplikace splňuje)
jednotlivé kategorie požadavků:
1. funkcionální požadavky - co má projekt dělat
2. požadavky na provoz systému - podmínky za jakých bude systém pracovat
3. požadavky na výsledný systém - podmínky pro vývoj a nasazení - počítačové vybavení, programové vybavení, spolehlivost, odolnost vůči chybám
4. požadavky na vývojový proces - požadavky zákazníka na dodržování norem během vývoje a předání systému
5. požadavky na rozhraní - komunikace se systémem
6. externí požadavky - požadavky vyplývající s charakteru aplikace (např. legislativní požadavky)

Specifikace

metody získávání požadavků
- interview
- dotazníky
- studium dokumentů
- pozorování prací u zákazníka
- přímá účast na pracích zákazníka
- analýza existujícího softwarového systému
problémy při získávání informací
- problémy plynoucí z použití přirozeného jazyka (vyřazení, deformace, zkreslení, zobecnění)
- zákazník nemá přesnou představu
- zákazník se neorientuje v problematice softwaru a vývojář se neorientuje v problematice zákazníka
- rozhodování, jaké požadavky už nezačleňovat do specifikace
kroky při specifikaci požadavků
- studie vhodnosti - prvotní odhad, zda jsme schopni zvládnout práci (čas, cena, rozsah)
- analýza požadavků - zkoumání požadavků zákazníka
- definování požadavků - transformace analyzovaných informací do textové podoby pro zákazníka a uživatele
- specifikace požadavků - transformace analyzovaných získaných informací do formální podoby pro vývojáře
- specifikace softwaru
prostředky pro specifikaci požadavků v RUP
- diagramy případů užití (Use cases)
  - součástí UML
  - definují se účastníci systému a jejich role
- detaily případů užití
  - podrobnější popis use case diagramů
  - znázorněno tabulkou
  - možnosti definování alternativních kroků (co se stane, když …)
- specifikace (strukturovaný text)
  - rozšíření use case diagramů o pokročilé techniky zlepšující přehlednost
  1. zobecnění účastníka - generalizace/specializace účastníků
  2. zobecnění případů užití - generalizace/specializace rolí (úkonů) účastníků
  3. relace «include» - nějaký úkon v sobě zahrnuje jiný (změna položky ⇒ «include» ⇒ vyhledání položky)
  4. relace «extend» - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy ⇒ «extend»)
- slovníky pojmů

prostředky pro analýzu v RUP:
1. analytické třídy - mapují pojmy problémové domény na abstraktní entity modelu – třídy
2. objektové diagramy - zachycují konkrétní instance tříd a jejich vazby v určitém čase či podmínce
3. analytické balíčky - seskupují sémanticky související elementy a definují hranice tohoto seskupení
4. diagramy interakce - reprezentují vztahy mezi objekty
5. sekvenční diagramy - reprezentují časově orientovanou posloupnost předávání zpráv mezi objekty
6. diagramy aktivit

Modely

funkční modelování
- ukazuje:
  - funkce systému
  - toky dat mezi systémem a okolím
  - toky dat mezi funkcemi systému
  - data ukládaná v systému
- základním modelem je DFD - Data Flow Diagram
datové modelování
- ukazuje entity aplikační domény zpracovávané systémem a statické vztahy mezi nimi (typicky perzistentní data ukládaná v databázi)
- typickým modelem je diagram vztahů a entit: ERD - Entity Relationship Diagram
datový slovník
- obsahuje specifikace prvků modelů, notace pro specifikaci informačního obsahu prvků DFD a ERD
modelování dynamického chování
- stavový diagram, který zachycuje stavy, ve kterých se systém (či jeho část) může nacházet

2. Architektonický návrh

slouží k ujasnění koncepce systému a k jeho dekompozici
- vymezení funkcionality jednotlivých podsystémů
- definování vztahů mezi podsystémy
naplánování postupu nasazení do provozu ⇒ je lepší to udělat již v této etapě, jelikož programátoři mají v hlavě informace nutné k jeho vytvoření z minulé etapy + je lepší, když už je dopředu daná určitá představa, která bude dále sloužit k odhalování problémů
zde je výstupem specifikační dokument a plán testování celého systému

dobrý návrh je podmínkou úspěšné tvorby softwaru a minimalizuje náklady spojené s implementací a posléze i údržbou softwarového produktu
výstupem etapy jsou většinou tyto diagramy:
1. doplněné (upřesněné) analytické diagramy - diagramy interakce
2. diagramy upřesňující vybrané analytické diagramy
  - návrhové třídy
    - vycházejí z analytických tříd
    - doplňují implementačně důležité vlastnosti (proměnné, metody)
    - lze je přímo implementovat
  - návrhové podsystémy
  - stavové diagramy
  - rozhraní
    - odděluje specifikaci funkčnosti od její implementace

3. Podrobný návrh

podrobná specifikace softwarových součástí
stanovení fyzické struktury dat a způsoby ošetřování neočekávaných a chybových stavů
návrh testů jednotlivých součástí včetně testovacích dat
zde je výstupem návrhový dokument

4. Implementace a testování součástí

implementace jednotlivých částí
vypracování dokumentace
testování jednotlivých částí
zde jsou výsledkem naimplementované jednotlivé části

implementace softwaru je transformace návrhu jednotlivých modulů a jejich vzájemných vazeb do programové realizace
úkony před implementací:
- výběr implementačního jazyka
- strategie implementace
  1. zdola-nahoru - od nejnižší úrovně po největší celky (moduly nižší úrovně lze dále použít ve vyšších úrovních x chyby v logice se projeví až při integrování modulů)
  2. shora-dolů - (systém lze brzy demonstrovat a nejzávažnější chyby jsou odhaleny včas x logika systému se ověřuje několikrát, pro testování jsou třeba speciální moduly, které simulují práci podsystému)
validace a verifikace programu:
- validace - ověření, že vyvíjený software splňuje potřeby uživatele
- verifikace - ověření, zda software vyhovuje specifikaci
- ověřujeme různé vlastnosti: správnost, spolehlivost, efektivnost či bezpečnost
- typy ověřování:
  1. statické: - nevyžaduje běh programu (libovolná etapa vývoje)
  2. dynamické = testování: - výsledky se odvozují na základě běhu programu (výstupů)

testování
- odhalování chyb během vývoje
- důležité volit dobré vstupy
- testovací kritérium:
  1. spolehlivé - nezáleží, jakou množinu vstupů vezmeme, vždy dostaneme stejný výsledek
  2. platné - když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje toto kritérium a která chybu odhalí
- typy:
  1. náhodné - generátor pseudonáhodných čísel
  2. funkcionální - vychází pouze ze specifikace a neuvažuje se vnitřní struktura programu - metoda černé skříňky
  3. strukturální - vychází z vnitřní struktury programu - metoda bíle skříňky
- test, co neodhalí chybu chování systému, je neúspěšný

5. Integrace a testování systému

spojení do jednoho celku
probíhá testování celku ⇒ odhalují se chyby spojené s integrací ⇒ případné opravování a návrat k předchozí části
zde je výsledkem celkový systém

6. Akceptační testování a instalace

otestování systému uživatelem
zákazník software převezme, případně je převzetí odloženo (po objevení závažných nedostatků) do doby napravení problémů
zde se ocení pečlivost 1. etapy
tato etapa záleží na typu softwaru (u generického zákazník může koupit software ještě před vyzkoušením, případně existují trial verze, atd…)
rozhoduje o úspěchu či neúspěchu

7. Provoz a údržba

vyžaduje průběžné řešení problémů a chyb, které se objevují až za běhu
tato etapa zabírá největší času a úsilí (ve skriptech uvedeno 67%) ⇒ peněz ⇒ je proto velmi důležité věnovat pozornost prvním etapám

Modely životního cyklu softwaru

u každého projektu se jednotlivé uspořádání etap může lišit ⇒ společné rysy je možné popsat modely životního cyklu softwaru
definují jednotlivé etapy, a jejich časovou následnost
nedefinují délku trvání etap ani jejich rozsah

Vodopádový model

jednotlivé etapy jsou řazeny za sebou
následující etapa začíná po ukončení předchozí (tak, jak jsou seřazeny v sekci o etapách)
pokud zákazník nestanoví všechny požadavky a zjistí se to až při posledních etapách, je třeba se vrátit prakticky na začátek a upravit návrh, jelikož se s tím v životním cyklu nepočítalo
neodpovídá vývoji reálných projektů, je ale lepší jak neřízený chaos

Iterativní model

snaží se odstranit hlavní problém vodopádového modelu ⇒ proces vývoje je rozdělen do iterací, kde každá iterace je instance vodopádového modelu
po každé iteraci je k dispozici spustitelná verze s neúplnou funkcionalitou ⇒ pomůže upřesnit požadavky na software
rozdělení do iterací vede k horšímu návrhu struktury systému

Inkrementální model

podobný iterativnímu modelu
projekt je odevzdáván uživateli po částech
pozdější upřesnění požadavků může mít negativní vliv jako u vodopádového modelu

Spirálový model

zavádí do vývoje prototypování a klade značný důraz na analýzu rizik
jednotlivé etapy vývoje se opakují vždy na vyšším stupni zvládnuté problematiky ⇒ podobné jako u iterativního s tím rozdílem, že výsledkem jedné iterace není software s omezenou funkcionalitou, ale prototyp ⇒ po použití se zahodí a začne se vytvářet nová verze
spustitelné verze existují od začátku, takže se lépe odhalují chyby spojené s provozem
je náročný na řízení

Vmodel

Rational Unified Process

na rozdíl od předchozích modelů není pouze konceptem, ale je použitelný na řízení reálných softwarových projektů
výsledkem výzkumu řady velkých firem koordinovaný firmou Rational
je založen na vývoji softwarového produktu iteračním způsobem (po každé iteraci je k dispozici spustitelný kód)
klade důraz na
1. vizualizaci softwarového systému (pomocí jazyka UML – Unified Modelling Language)
2. průběžnou kontrolu kvality produktu
3. řízení změn
4. využívání existujících komponent

Agilní metodologie

metodologie založené na klasických modelech životního cyklu softwaru se vyvíjely dlouhou dobu a postupem času zmohutněly ⇒ při tvorbě menších projektů spíše kvalitu výsledného produktu snížily ⇒ prodražování bez efektu ⇒ vývoj agilních metodologií
klade hlavní důraz na člověka jako určující faktor pro kvalitu výsledného produktu

Extrémní programování (XP)
propaguje časté dodávky software v krátkých vývojových cyklech
programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód
společné vlastnictví kódu a neustálý refaktoring
Vývojáři by měli počítat se změnami požadavků v průběhu času
Důležitá je častá komunikace se zákazníkem i mezi programátory.

Scrum
Klíčovou částí metodiky jsou každodenní krátká setkání týmu, nazývaná scrum
Každý člen zde referuje o své činnosti z minulého dne, o tom, co bude dělat dnes, a na jaké problémy narazil.
Metodika prosazuje iterativní vývoj. Období iterace se nazývá Sprint a trvá 2-4 týdny.
Výsledkem Sprintu je demo vzniklých úprav, které je předvedeno zákazníkovi
Ten poskytne zpětnou vazbu, což umožňuje rychle reagovat na změny v požadavcích
Product Owner má za úkol komunikovat se zákazníkem.
Správné fungování vývojového týmu zajišťuje Scrum Master
Člen vývojového týmu se nazývá Scrum Team Member

Vývoj řízený vlastnostmi (FDD – Feature Driven Development)
FDD začíná vytvořením doménového modelu popisujícího celý systém
Ten se převede do seznamu vlastností (elementární funkcionality, které přináší hodnotu uživateli)
Během každé iterace se implementují konkrétní užitné vlastnosti systému.
Zákazník průběžně dostává mezivýsledky a nové verze produktu.
Na rozdíl od XP nebo SCRUM je jednotlivým programátorům práce přidělena – nevybírají si ji sami.

Vývoj řízený testy (TDD – Test Driven Development)
TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód.
Implementuje se přesně takové množství kódu, jaké dokáže projít testem

Zdroj

Jedná se především o výtah ze skript. Občas jsem si pomohl googlem (přiložené odkazy na některé pojmy). Většinou se jedná o pojmy, které by měly být dále rozepsány v tématu UML.

Potvrzení

30
Celé jméno	OK	!!!
Jirka Hynek
vagy
Fituska User
	3

george, IUS