50 - Moderní modely životního cyklu vývoje software Flashcards

1
Q

Základní pojmy

A

• 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ı́
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Fáze životního cyklu vývoje SW

A

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Modely životního cyklu SW - vodopád se zpětnou vazbou (označovaný také jako klasický)

A
  • 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))

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Modely životního cyklu SW - Iterativní inkrementální modely - obecně

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Modely životního cyklu SW - Iterativní inkrementální modely - Spirálový model

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Modely životního cyklu SW - Iterativní inkrementální modely - Modelem řízené architektury - Model-driven architecture (MDA)

A
  • 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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Modely životního cyklu SW - Iterativní inkrementální modely - agilní vývoj a agilní modelování

A
  • ž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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

UP (unified process)

A

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.

  1. 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
  2. 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)
  3. Konstrukce (Construction) – doladěnı́ požadavků, implementace
    - Počáteční provozní způsobilost (Usable solution available)
  4. 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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

RUP (Rational Unified Process)

A
  • 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.
    • UP - otevřený, obecný případ vs. RUP - konkrétní komerční podtřídu, která UP v řadě rysů rozšiřuje a modifikuje.
    ○ 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í
How well did you know this?
1
Not at all
2
3
4
5
Perfectly