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:

poslední dobou je od počítačů očekávána stále vyšší funkčnost ⇒ větší složitost

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

dříve velmi drahé sálové počítače vs. jednoduché dávkové programy

dnes levné notebooky/PDA vs. drahý a složitý software

Poměr nákladů HW a SW v čase

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, …

Softwarový systém

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

software pro širokou veřejnost

tzv. krabicový software

musí být velice dobře otestován

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ší

Chybová křivka

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:

zákazník - objednal si systém

dodavatel - vytváří systém

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í

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

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

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

Vodopádový model životního cyklu softwaru

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

Iterativní model životního cyklu softwaru

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í

Spirálový model životního cyklu softwaru

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

vizualizaci softwarového systému (pomocí jazyka UML – Unified Modelling Language)

průběžnou kontrolu kvality produktu

řízení změn

využívání existujících komponent

Rational Unified Process

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

Analýza a specifikace požadavků

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í

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 požadavků

špatná specifikace požadavků = špatný výsledek práce

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

zobecnění účastníka - generalizace/specializace účastníků

zobecnění případů užití - generalizace/specializace rolí (úkonů) účastníků

relace «include» - nějaký úkon v sobě zahrnuje jiný (změna položky ⇒ «include» ⇒ vyhledání položky)

relace «extend» - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy ⇒ «extend»)

slovníky pojmů

Toto téma značně zasahuje do UML

prostředky pro analýzu v RUP:

analytické třídy - mapují pojmy problémové domény na abstraktní entity modelu – třídy

objektové diagramy - zachycují konkrétní instance tříd a jejich vazby v určitém čase či podmínce

analytické balíčky - seskupují sémanticky související elementy a definují hranice tohoto seskupení

diagramy interakce - reprezentují vztahy mezi objekty

sekvenční diagramy - reprezentují časově orientovanou posloupnost předávání zpráv mezi objekty

diagramy aktivit

Strukturovaná analýza

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

základní 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

Návrh

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:

doplněné (upřesněné) analytické diagramy - diagramy interakce

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

Implementace a testování

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

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ů)

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í:

statické: - nevyžaduje běh programu (libovolná etapa vývoje)

dynamické = testování: - výsledky se odvozují na základě běhu programu (výstupů)

Statické a dynamické ověřování

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ý

Proces testování

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í