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í
Historie
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:
splnění požadavků
cena
čas
typy softwarového produktu:
generický software
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)
firma si objedná sw
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
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)
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ší
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.
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.
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í
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
získat, analyzovat a definovat požadavky
transformovat neformální požadavky uživatele do strukturovaného popisu požadavků
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í
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ů:
funkcionální požadavky - co má projekt dělat
požadavky na provoz systému - podmínky za jakých bude systém pracovat
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
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
požadavky na rozhraní - komunikace se systémem
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
Modely
funkční modelování
datové modelování
datový slovník
modelování dynamického chování
2. Architektonický návrh
slouží k ujasnění koncepce systému a k jeho dekompozici
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
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
testování
odhalování chyb během vývoje
důležité volit dobré vstupy
testovací kritérium:
spolehlivé - nezáleží, jakou množinu vstupů vezmeme, vždy dostaneme stejný výsledek
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:
náhodné - generátor pseudonáhodných čísel
funkcionální - vychází pouze ze specifikace a neuvažuje se vnitřní struktura programu - metoda černé skříňky
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
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
-
průběžnou kontrolu kvality produktu
řízení změn
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 | |
Diskuze