50 - Moderní modely životního cyklu vývoje software Flashcards
Základní pojmy
• SW se nevyrábí, ale implementuje
• Úrovně použití SW v organizacích k rozhodování
- operační (každodenní rozhodování)
- taktické (obvyklé rozhodování)
- strategické (dlouhodobé rozhodování)
životní cyklus SW = změny, kterými prochází v průběhu svého „života“ softwarový produkt.
Životní cyklus software je reprezentace softwarového procesu. Definuje:
• fáze
• kroky
• aktivity
• metody
• nástroje
• očekávané výstupy softwarového projektu.
Životnı́ cyklus vývoje software = model procesu tvorby SW systému
• phasing in - postupné zaváděnı́ produktu (do doby nasazenı́)
• phasing out - Postupného vyřazení produktu z provozu (od doby nasazenı́) - okamžikem plného nasazení do používání a zahájením údržby se informační systém dostává do období postupného vyřazování
* softwarové inženýrství je víc než programování, je to oblast počı́tačové vědy, která se zabývá vytvářenı́m softwarových systémů, které musejı́ tvořit týmy. Velmi se lišı́ od klasického inženýrstvı́ * softwarový proces je složitý a je součástí business procesu * Softwarový projekt je plánovaná činnost k dodánı́ SW produktu nebo služeb * Software je modelem reality, vývoj SW systémů je tedy hlavně modelovánı́
Fáze životního cyklu vývoje SW
1 - Analýza požadavků - získání požadavků na SW od zákazníka
2 - Návrh - na základě požadavků je proveden návrh SW
3 - Implementace
• implementace návrhu
• součástí je i testování a ladění
Testování = veškeré aktivity, jejichž cílem je odhalení chyb
Ladění = aktivity zaměřené na odstranění chyb
• posouzení (např. techniky procházení či inspekce) • spuštění proveditelného kódu • Testování: ○ testování ze specifikace - black-box - (funkční / test funkčnosti) - při návrhu testu vychází ze specifikace testovaného programu (co má umět) ○ testování z kódu - white-box - (implementace, test kódu) - vychází ze znalosti zdrojového kódu
4 - Integrace a nasazení = Integrace je spojení jednotlivých částí SW do jednoho celku
• Integrační testování
○ shora dolů - náhražky podprogramů - stubs
§ postupně přidáváme jednotlivé komponenty od kořene hierarchie. Vzniká ale problém, že testovaná část může používat komponenty, které v ní nejsou obsaženy. Použijí se náhražky podprogramů (stubs)
○ zdola nahoru - řídící prvky - drivers
§ postupuje naopak v hierarchii komponent od listů ke kořenům. I v tomto případě je třeba pro účely testování nahradit chybějící část, tentokrát komponenty, které testovanou část používají (řídí). Pro náhradu se v tomto případě používá označení driver. (práce navı́c, nadřazené prvky)
5 - Provoz a údržba Údržba kódu 1. Opravná – odstraněnı́ chyb 2. Adaptivnı́ – přizpůsobenı́ změnám prostředı́ 3. Vylepšovacı́ – rozvoj, nové funkce
X Ověřovánı́ správnosti a testovánı́ – je v každé části
Ověřenı́ správnosti software:
1. Validace – ověřenı́ splněnı́ funkčnı́ch požadavků
2. Verifikace – ověřenı́ dodržení specifikace
3. Testovaní – nalezení chyb
4. Ladění – odstranění chyb
Typy testovánı́:
1. Shora dolů – užitı́ stubs (náhražky podprogramů) 2. Zdola nahoru – užitı́ drivers (práce navı́c, nadřazené prvky) 1. Black box – ze specifikace, test funkčnosti 2. White box – z implementace, test kódu
Modely životního cyklu SW - vodopád se zpětnou vazbou (označovaný také jako klasický)
- Základní nejstarší model, dnes v praxi spíše nevhodný
- Je monolitický, tj. fázemi se prochází v zásadě jedenkrát, následují po sobě a jsou jednoznačně oddělené, a vše směřuje k jednomu datu nasazení celého systému.
- Každá fáze plně dokumentovaná
- Fáze může poskytnout zpětnou vazbu předchozí fázi (tj. návrat k předchozí fázi a její přepracování)
- Zpětnou vazbou lze promı́tnout změny zpět.
Nevýhody: (nelze paralelizovat, malá zpětná vazba, plánovánı́ prostředků je na počátku (nepřesné))
1. Kritéria pro ukončení fáze analýzy požadavků a systémového návrhu nejsou často definována. V takovém případě je obtížné poznat, kdy fázi ukončit, což může ohrozit termíny projektu. 2. Nedává možnost prostor pro vypořádání se se složitostí systému metodou „rozděl a panuj“. 3. Dokumentace, která zde hraje velice významnou roli, může dávat zkreslený dojem o postupu projektu. Navíc mohou být některé informace v ní obsažené chybně interpretovány a existuje riziko vysoké míry byrokracie. 4. Fakt, že výsledky jednotlivých fází jsou „zmrazeny“, jde proti skutečnosti, že se požadavky v procesu vyvíjejí. 5. Projekt se plánuje na začátku životního cyklu, kdy je k dispozici jen omezené množství informací. Hrozí tak nebezpečí chybného odhadu potřebných zdrojů.
Výhody:
1. Vyžaduje disciplinovaný přístup k vývoji, definuje jasné milníky vývoje a usnadňuje tak řízení projektu. 2. Produkuje úplnou dokumentaci systému. 3. Dokončení dokumentace příslušné fáze před postoupením do fáze následující ukazuje legální pozici vývojového týmu v procesu vývoje. 4. Vyžaduje pečlivé plánování projektu.
Variace:
• Fáze těsněji spojeny (překryty) – flexibilnějšı́ - Umožňuje překrytí jednotlivých fází životního cyklu. Tím lze dosáhnout vyšší flexibility, neboť potřeba změny v předchozí fázi se zjistí dříve a je možné ji realizovat již v rámci vytvářeného dokumentu předchozí fáze.
• Druhým rysem je využití prototypování. (ukázky (zahodit, nebo dál rozvı́jet))
Modely životního cyklu SW - Iterativní inkrementální modely - obecně
Rozkládá proces na iterace -> každá předkládá prototyp
- Iterace znamená opakovaný průchod fázemi životního cyklu s cílem obohatit vytvářený systém v každé iteraci o nějaké rozšíření či vylepšení, které budeme nazývat přírůstkem.
- Možná vás napadá, že i v případě životního cyklu vodopád vytvářely zpětné vazby iterace.
- Iterativní životní cyklus vytváří v každé iteraci novou verzi vytvářeného systému (build, konstrukce - proveditelný kód).
- V případě vodopádu je výsledkem fází vývoje jediná verze, která je verzí finální.
Iterace by měly být krátké - dny až týdny. Typicky iterace pevné nebo časově omezené délky, miniprojekt. Krátké iterace vedou k lepšı́ kontrole a plánovánı́.
Každá iterace iterativního životního cyklu je ve skutečnosti malým životním cyklem vodopád s tím, že uživatel je opakovaně zapojen do procesu vývoje při analýze požadavků v rámci následující iterace. Využívá již i zkušeností z práce s konstrukcí, která vznikla při předchozí iteraci.
Inkrementální/evoluční
• každé opakování přináší vylepšenou/rozšířenou verzi
• Sestavení (angl. build)
○ výsledek iterace: otestovaný, integrovaný, spustitelný kód.
Výhody • průběžné plánování • spolehlivější řízení projektu • odhady se postupně zpřesňují • požadavky se mohou mezi iteracemi zpřesňovat
VŠECHNY NÁSLEDUJÍCÍ MODELY JSOU TAKÉ ITERATIVNÍ…
Modely životního cyklu SW - Iterativní inkrementální modely - Spirálový model
PŘINÁŠÍ ANALÝZU RIZIK jako specifickou fázi A PROTOTYPOVÁNÍ
- Je ve skutečnosti rámcem nebo meta-modelem, který může obsahovat jiné modely životního cyklu. (Jde spíše o referenční model nebo způsob uvažování při vývoji software)
Model se prezentuje v podobě spirály, která prochází čtyřmi kvadranty:
1. Analýza rizik - pokračovat nebo ne? 2. Plánování 3. Zhodnocení zákazníka 4. Inženýrstvı́(analýza požadavků, návrh, implementace, integrace a nasazení) - V části inženýrstvı́ je vodopád, jinde je možnost zastavit práci, pokud je špatná/nevýhodná.
Důraz na opakované plánování projektu a vyhodnocování zákazníkem v každém cyklu dává modelu vysoce iterativní charakter.
Analýza rizik jako explicitní fáze je unikátní pro spirálový model, u jiných se v této podobě nevyskytuje.
Interpretace fáze inženýrství může být různá. Může to být například vývoj, jehož výsledkem je konstrukce (build).
Modely životního cyklu SW - Iterativní inkrementální modely - Modelem řízené architektury - Model-driven architecture (MDA)
- je rámec životního cyklu vytvořený skupinou Object Management Group (OMG), což je organizace, která si klade za cíl standardizaci v oblasti objektově orientovaného přístupu. Jí schválené standardy jsou akceptovány jako průmyslové standardy.
- Jedním z nich je i jazyk UML.
- MDA je snahou o použití jazyka UML jako spustitelné (executable) specifikace, tj. specifikace, ze které je možné vygenerovat softwarový systém, který model v UML reprezentuje.
- MDA předpokládá vývoj software jako posloupnost transformací z formální specifikace přes etapy návrhu až po proveditelný kód
- každá transformace by mela zajišťovat nebo umožnit verifikovat, že výstup odpovídá vstupu
- Takový přístup má naději na úspěch pouze tehdy, bude-li výrazně automatizován. K tomu je třeba, aby byly modely reprezentující vyvíjený systém vytvářeny využitím CASE nástrojů
- Computer-aided software engineering (CASE) = použití SW při vývoji SW (generování kódu, datové modelování, refaktorování, UML)
Proces: mostly text -> platform independent model -> platform specific models -> code
Modely životního cyklu SW - Iterativní inkrementální modely - agilní vývoj a agilní modelování
- životní cyklus navržený neziskovou organizací nadšenců Agile Alliance
- rychlá reakce na měnící se podmínky
- klade důraz na přizpůsobivost a spolupráci se zákazníkem po celou dobu vývoje
Hlavní zásady (definované v tzv. Agilním manifestu):
• Jednotlivci a interakce před procesy a nástroji
• Fungující software před úplnou dokumentací
• Spolupráce se zákazníkem před vyjednáváním smlouvy
• Reagování na změny před dodržováním plánu projektu
Některé postupy:
• Přijímací testy (acceptance test) - testy ověřující, že zákazník dostává to co chtěl
• Vývoj řízený testy (Test-driven development - TDD) - nejprve testy pak implementace
• Párové programování (kód vždy tvoří dva lidé)
• Kolektivní vlastnictví kódu (všichni jsou zodpovědní za celý kód)
• User stories - místo klasické analýzy požadavků uživatel vylíčí co by rád aby systém uměl (pár vět, běžný jazyk, nestrukturované)
• Refaktorizace (refactoring) - vylepšování kódu bez změny funkčnosti
* Klasická integrace a nasazení jsou u agilního vývoje nahrazeny spojitou integrací a krátkými iteracemi (2 týdny) * Každý pár programátorů může v libovolném okamžiku testovat a integrovat jejich kód. Současně ale může více dvojic pracovat se stejným kódem. => vyžaduje podporu správy verzí, která umožní případné konflikty detekovat. * Každá iterace dává určitý menší výsledek, který hodnotí zákazník * extrémní programování - programování v párech, kolektivní vlastnictví a refaktorizace jsou 3/12 principů
!!! Agilní modelování !!! • náčrtky na tabuli/papír, souběžné vytváření několika modelů (např. interakce a tříd) • modely se vytvářejí až když jsou potřeba, jen tak přesné, jak je pro daný účel potřeba • CRC - class responsibility cards - štítky - přiřazení zodpovědností třídám • Soubor „best-practices“ pro modelování a dokumentaci software. (z klasického RUP, agilního extrémního progr. i moderních metodik, jako je Scrum) • Definuje hodnoty, principy a praktiky pro modelování software. (5 hodnot, 11+2 principů a 13+5 praktik pro prosazování principů) • Popisuje jak jsou výše uvedené zapojeny do vývoje software. (Agile Model Driven Development, AMDD, přístup k vývoji software)
• Konkrétně definuje AM následující hodnoty ○ Komunikace (komunikace je důležitá a častá, uvnitř týmu i ven mezi týmem a zákazníkem) ○ Jednoduchost (tvorba jednoduchých modelů, spíš pro porozumění, než pro dokumentaci) ○ zpětná vazba (rychlá a častá zpětná vazba, reakce na předložené modely a interakce) ○ Odvaha (dělat rychlá rozhodnutí, zkoušet nové, zahazovat či měnit stávající) ○ pokora/respekt (naslouchat ostatním vývojářům i zákazníkům, přijímat jejich nápady)
UP (unified process)
Unified Process = generický proces vývoje SW, adaptuje se pro dané účely a organizaci (pro firemnı́ standardy, nástroje, šablony, databáze apod.)
Baseline = výsledek jedné iterace.
3 základní axiomy:
1. proces řízený požadavky a riziky (význam analýzy rizik) 2. staví na robustní architektuře systému (architecture centric) - používá pohled 4+1 z UML 3. iterativní a inkrementální - Každá iterace zahrnuje všechny fáze běžného vývoje (plánovánı́, analýza, konstrukce, integrace, testovánı́). * požadavky se považují za měnící se * celý projekt se dělí na několik fází zakončených milníky v rámci jednotlivých fází pak probíhají iterace (jedna nebo několik iterací na fázi dle potřeby)
Best practices v UP:
• Iterativní vývoj SW
• Správa požadavků
• Architektura založená na komponentách
• Vizuální modelování (UML)
• Ověřování kvality SW (funkcionalita, spolehlivost, výkonnost)
• Řízení změn SW
Činnosti v iteracích (v podstatě klasický vodopád) • Získávání požadavků (Requirements) • Analýza (Analysis) • Návrh (Design) • Implementace (Implementation) • Testování (Testing)
Disciplíny ve fázích UP (statický rozměr)
• Modelování organizace (Business modelling)
• Požadavky
• Analýza a návrh
• Implementace
• Testování
• Nasazení
• Podpůrné:
○ Správa konfigurace a změn
○ Vývojové prostředí (podpůrné nástroje)
○ Řízení projektu
Fáze vývoje obsahuje jednu nebo několik iteracı́ (a mezivýsledků – baseline). Má určeny cı́le a zaměřuje se nebo zdůrazňuje některé činnosti.
- Zahájenı́ (Inception) – stanovenı́ proveditelnosti, vytvořenı́ bussiness přı́padu, zachycenı́ požadavků, identifikace rizik
- Na konci fáze zahájení se rozhoduje o dalším pokračování projektu - Rozpracovánı́ (Elaboration) – spustitelná verze architektury, zpřesněnı́ rizik a požadavků, definice kvality, plán konstrukce a prostředků
- Spustitelná verze architektury (selected approach proven) - Konstrukce (Construction) – doladěnı́ požadavků, implementace
- Počáteční provozní způsobilost (Usable solution available) - Zavedenı́ (Transition) – opravy chyb, přı́prava pracoviště k nasazenı́, přizpůsobenı́ SW a pracoviště, manuály, konzultace
- Testování - beta-testování a přejímací testy na pracovišti uživatele
- Produkční verze (product complete)
RUP (Rational Unified Process)
- Více než model životního cyklu
- Rational Unified Process je komerčnı́ implementacı́ obecného Unified Process. Rational Software byl koupen IBM. Využı́vá CASE.
- Jde rovněž o prostředí (platforma RUP), které slouží vývojářům. To má podobu HTML a jiných dokumentů poskytujících online nápovědu, šablony dokumentace a průvodce.
- Podpůrné prostředí je součástí balíku CASE nástrojů dodávaných firmou IBM (dříve firmou Rational Corporation)
- Ale RUP lze použít jako model životního cyklu pro vývoj software obecně.
- Dá se říci, že v době jejich vzniku byl RUP přímou implementací UP. Od té doby ale RUP značně pokročil a obsahuje řadu rozšíření a změn oproti UP.
○ Hlavní rozdíly spočívají ve vyšší míře úplnosti a detailů, které poskytuje RUP.- Horizontální osa - dynamický aspekt životního cyklu, tj. jednotlivé fáze (modelování, požadavky, návrh, implementace,..)
- Vertikální směr naopak reprezentuje statický aspekt, kterým jsou disciplíny podílející se na životním cyklu (zahájení, rozpracování, konstrukce, přechod)
- v čase
- Odpovídá generickému modelu iterativního životního cyklu - vždy musí být nejdříve adaptován pro organizaci a každý projekt.
- Nejvýraznější odlišností je explicitní uvedení fáze testování
