Základní modely životního cyklu software, softwarový proces

Z Na státnice zvesela!

Obsah [skrýt] 1 Softwarový proces 1.1 Potup vývoje software 2 Vodopádový model 2.1 V-model 3 Průzkumný vývoj (exploratory development) 4 Prototyp (throw-away prototyping) 5 Spirála (Boehm, 1988)

[editovat] Softwarový proces

• systematická série akcí, jejímž výstupem je software
• typy:
  • řízené plánem (jistotou) = vodopád, V-model
  • řízené riziky = exploratory/prototype model
  • řízené změnou = iterativní, agilní

[Zdroj: ASWI přednášky, Brada]

[editovat] Potup vývoje software

• ad-hoc (nahodilé, bez využité konkrétní metodiky)
• sekvenční (všechny kroky vývoje jdou postupně po sobě, viz vodopád)
• cyklický (aktivity se opakují a produkt postupně roste, viz spirála)
• agilní (iterativní + navíc vítaná změna, spolupráce, důraz na funkční software)

[Zdroj: ASWI přednášky, Brada]

[editovat] Vodopádový model

• Jeden z nejstarších modelů (dokonce asi první)
• Hlavní myšlenky:
  • před návrhem řešení se musí kompletně rozumět zadání
  • výstup jedné aktivity je vstupem následující
• Základní aktivity jsou
  • Analýza a definice požadavků (Requirements definition)
    • Konzultací s uživateli systému se zjistí cíle, požadované služby a omezení kladená na systém
    • To se podrobně definuje v dokumentu, který slouží jako specifikace systému (Dokument Specifikace Požadavků)
  • Design systému a sw (System and software design)
    • Provede se návrh systému, rozdělí se celkové požadavky na požadavky na HW a požadavky na SW, určí se celková architektura systému
  • Implementace a testování modulů (Implementation and unit testing)
    • programování množiny modulů
    • Testování na úrovni modulů, ověření, že každý modul odpovídá specifikaci modulu
  • Integrace a testování systému (Integration and system testing)
    • Jednotlivé moduly jsou sestaveny do výsledného systému
    • Úplný systém je otestován na shodu se specifikací
    • Po otestování je systém předán zákazníkovi
  • Provoz a údržba (Maintenance)
    • Nejdelší fáze životního cyklu – systém se prakticky používá
    • Údržba = oprava chyb programu a designu, které nebyly odhaleny v předchozích fázích + rozšiřování systému podle nových požadavků + zlepšování implementace
• Výhody
  • snadné k pochopení
  • dobrá možnost řízení a sledování postupu řešení (milníky(milestones))
  • klade důraz na dokumentaci -- specifikace, design, analýza
• Nevýhody
  • vyžaduje mít na počátku přesně a úplně definované požadavky (uživatel často nedokáže stanovit předem)
  • provozuschopnost verze vidí zákazník až v závěrečných fázích řešení, případné závažné nedostatky jsou odhaleny velmi pozdě.
  • během vývoje se mohou měnit požadavky a výsledkem je, že dodaný produkt není to, co zákazník chtěl
  • během implementace se zjistí, že design není v pořádku a je třeba ho změnit
• vhodný pro projekty s předem známou problematikou a neměnnými požadavky

[editovat] V-model

• jedna z nejznámějších variant vodopádového modelu
• důraz na testování sw, každá aktivita musí být verifikována

[editovat] Průzkumný vývoj (exploratory development)

• vytvoří se počáteční implementace, ta se vystaví komentářům uživatele a postupně se vylepšuje přes meziverze, dokud se nedostaneme k adekvátnímu výsledku
• cílem je spolupracovat se zákazníkem na zjištění jeho požadavků, abychom mu nakonec dodali požadovaný systém
• vývoj obvykle začíná dobře srozumitelnými částmi systému
• systém se vyvíjí přidáváním nových vlastností navrhovaných zákazníkem
• VÝHODY
  • systém je velice dobře přizpůsobitelný i dodatečným požadavkům zákazníka.
• NEVÝHODY
  • manažersky velmi náročné – etapy lze stěží plánovat časově, finančně i personálně.
  • dokumentace – pokud nevzniká průběžně, je odrazem hotového díla.
  • není jasné, které požadavky byly stanoveny při zadání a které jsou nyní nové.

[editovat] Prototyp (throw-away prototyping)

• tvorba prototypu, který bude zahozen
• ověřuje funkcionalitu výsledného systému
• zaměřuje se na ty části požadavků zákazníka, kterým se moc nerozumí
• cílem je lepší pochopení zákazníkových požadavků a v důsledku vytvoření lepší definice požadavků na systém
• VÝHODY
  • budoucí uživatelé testují a ověřují prototyp a je upřesňována specifikace požadavků.
• NEVÝHODY
  • náročný na vedení v okamžiku, kdy existuje třeba i několik nezávislých vývojových skupin. Počet pracovníků a způsob vývoje se pak samozřejmě nepříznivě projeví i na nákladech projektu.

Smíšený přístup

• špatně srozumitelné části – throw-away prototyping -> zpřesnění DSP (dokument specifikace požadavků)
• dobře srozumitelné části – vodopádový model
• uživatelské rozhraní - exploratory development

Pozn. Oproti průzkumnému vývoji dochází po vytvoření "úplného" prototypu teprve k vytvoření specifikace a následně k výsledné implementaci. K implementaci mohou být využity znovupoužitelné části prototypu.

[editovat] Spirála (Boehm, 1988)

• iterativní přístup
• určen pro velké, složité a nákladné projekty
• základem celého modelu je neustálé opakování vývojových kroků tak, že v každém dalším kroku se na již ověřenou část systému přibalují části na vyšší úrovni.
• každá otočka spirály je rozdělena do 4 sektorů
  • specifikace cílů a určení plánu řešení
    • určíme alternativní možnosti realizace
    • identifikujeme omezení daných alternativ (cena, časový plán, přenositelnost)
  • vyhodnocení a snížení rizik
    • pro každé z identifikovaných rizik je provedena detailní analýza a kroky ke snížení rizika
  • vývoj a validace
  • plánování
    • naplánujeme další fázi projektu (organizace, požadavky na zdroje, rozdělení práce, časový plán, výstupy)
    • každá otočka je zakončena posouzením všech produktů vytvořených v předešlém cyklu

Náklady a čas nutný na realizaci jednotlivých částí projektu, či na řešení celého projektu jsou patrné z modelu, neboť úhlová dimenze udává časovou náročnost a radiální úroveň udává rostoucí náklady.

Výhody

• explicitně uvažuje rizika projektu
• umožňuje konzultovat požadavky zákazníků v jednotlivých krocích a modifikovat systém podle upřesněných požadavků
• první verze systému je možné sledovat a hodnotit při jejich postupném vzniku
• cenové a časové odhady se v průběhu projektu stávají realističtějšími, protože důležité vlastnosti systému jsou objeveny brzy
• vývojáři mohou začít pracovat velmi brzy

Nevýhody

• řešení systému pomocí tohoto modelu vyžaduje neustálou spolupráci zákazníků, proto není vhodný zejména pro systémy vyvíjené na zakázku bez účasti budoucích uživatelů.
• neumožňuje přesné naplánování termínů, cen a jednotlivých výstupů a tím i jejich plnění.
• je nutné provést bezchybnou analýzu rizik a vybrat aspekty u nichž budeme rizika prověřovat, neboť na této analýze jsou založeny další fáze projektu. Pozdní zjištění komponent s vysokou mírou rizika může mít zásadní vliv na celý projekt.

(zdroj: Kubovec - Okruhy otázek ke státní závěrečné zkoušce z předmětu - Návrh informačních systémů (NIS) 2005/2006)