Životní cyklus systému

1. Životní cyklus systému

2. Životní cyklus • zahrnuje fáze od počáteční představy o systému po použití či zrušení systému • je nástrojem pro řízení aktivit souvisejících se systémem (zdroje, lidé, čas apod.) • existuje řada přístupů • NASA program/project life cycle • „Vee“ graf • DoD life cycle • IEEE 1220 Life Cycle • Systems Engineering Process (Kossiakoff, Sweet) • a další

3. NASA Program/Project Life Cycle • slouží pro stanovení rámce pro řízení rozsáhlých projektů NASA • jednotlivé fáze obsahují velkou řadu kroků a definic • je těžké definovat hranice mezi jednotlivými fázemi, ktomu napomáhají tzv. kontrolní brány (control gates), které usnadňují rozhodnutí o posunu k další fázi • pokud se kontrolní branou nepodaří projít a je dostatek prostředků, je možné fázi (nebo její část) zopakovat; jinak se projekt ukončí nebo se pokračuje dále s tím, že je třeba některé nedostatky odstranit (je třeba stanovit do kdy) • fáze • pre-fáze A: Advanced Studies • fáze A: Preliminary Analysis • fáze B: Definition • fáze C: Design • fáze D: Development • fáze E: Operations

4. NASA Program/Project Life Cycle • Advanced Studies • vytvoření širokého spektra myšlenek, které by mohly být základem nových projektů (misí, programů) • mise musejí být kompatibilní s posláním organizace • součástí každé navrhované mise musí být nástin jejích cílů, možností jejich dosažení, odhady nákladů, přínosů a času • kontrolní brány: Mission Concept Review, neformální návrhy

5. NASA Program/Project Life Cycle • Premilinary Analysis • dále se zkoumá potřeba a schůdnost navržených misí, důraz je kladen na optimalitu spíše než na proveditelnost • definují se top-level požadavky, hranice projektu, hodnotící kritéria, alternativní návrhy, nástroje systémového inženýrství a modely, základní architektura systému • hlavní produkty: Mission Needs Statement, návrhy systému a jeho provozu • kontrolní brány: Mission Definition Review, Preliminary Non-Advocate Review (kompatibilita s misí organizace, jasnost cílů, realizovatelnost plánu, hodnocení rizika), Preliminary Program/Project Approval Review

6. NASA Program/Project Life Cycle • Definition • vytvoření dostatečně detailního návrhu projektu schopného dosažení mise • zaměřuje se na funkční, technické a organizační aspekty projektu – požadavky, návrhy, plány výroby a verifikace • kontrolní brány: Non-Advocate Review, Program/Project Approval Review, System Requirements Review(s), System Definition Review, System-level Preliminary Design Review, Lower-level Preliminary Design Reviews, Safety review(s)

7. NASA Program/Project Life Cycle • Design • vytvoření návrhu, který může být přímo realizován (vyroben, kódován) • provádí se návrh na potřebnou úroveň podrobnosti, zpřesňují se požadavky, verifikační plány apod., • kontrolní brány: Subsystem (and lower level) Critical Design Reviews, System-level Critical Design Review

8. NASA Program/Project Life Cycle • Development • vytvoření jednotlivých částí systému (výroba, kódování) a jejich integrace za současného ověřování směřování k cíli a přípravy na provoz systému • verifikace systému, prověření přijetí (acceptance test), příprava dokumentace (pro provoz, údržbu), školení • kontrolní brány: Test Readiness Reviews (pro všechny úrovně), System Acceptance Review, System functional and physical configuration audits, Flight Readiness Review (pro letecké systémy), Operational Readiness Review, Safety reviews

9. NASA Program/Project Life Cycle • Operations • uspokojení potřeby nebo využití příležitosti, která iniciovala projekt • provádějí se již malé úpravy systému, které nemění jeho podstatu, která by znamenala znovuspuštění celého projektu • kontrolní brány: Regular system operations readiness reviews, System upgrade reviews, Safety reviews, Decommissioning (odstavení z provozu) Review

10. „Vee“ graf • popisuje technický aspekt projektového cyklu • základní fáze • dekompozice a definice – podobné vodopádovému modelu • integrace a verifikace – integrační a kontrolní aktivity korespondují s aktivitami v pravé části grafu • model je třírozměrný, tzn. nejednou může probíhat práce na více variantách či subsystémech

11. porozumění potřebám, vytvoření konceptu demonstrace a validace systému vytvoření specifikace výkonu integrace systému, verifikace rozšíření specifikace výkonu pro subsystémy sestavení subsystémů, verifikace subsystémů dekompozice a definice integrace a verifikace vytvoření plánu vhodného k výrobě kontrola částí výroba, kódování „Vee“ graf Zdroj: Forsberg, K., Mooz, H. The Repationship of Systems Engineering to the Project Cycle. Center for Systems Management, 1995.

12. „Vee“ graf • na každé úrovni navíc probíhají neklíčové (off-core) aktivity – aktivity systémového inženýrství (SI je definováno jako aplikace metod analýzy, návrhu, integrace a verifikace na fáze projektu) • analýza a návrh – kroky jako u systémové analýzy a syntézy • verifikace a integrace – prověření vytvořených částí, v případě nedostatků jejich odstranění, případně opakovaný návrh a výroba, integrace a opětovná verifikace

13. Department of Defense SLC • DoD acquisition process je součástí amerických zákonů, DoD direktiv a řady regulačních opatření • dokumenty řady DoD 5000 byly revidovány v roce 2004 • zásady • flexibilita – postup doporučený DoD se upraví podle charakteru příslušného systému a aktuální situace • vnímavost – k technologiím a dostupným zdrojům • inovace – zahrnutí nových postupů redukujících čas, náklady a zlepšující týmovou práci • disciplína – projekty musejí být řízeny v souladu s regulacemi a nařízeními, s nejnižšími náklady, v souladu s plány • efektivní řízení – maximální decentralizace, poskytování dostatečných pravomocí • řízení v oblasti vojenských systémů zahrnuje tři základní aktivity • technické (technical) • obchodní (business) • smluvní (contract) • SI patří do skupiny technických aktivit

14. Fáze DoD SLC • fáze • vývoj konceptu a technologie • vývoj systému a předvedení • výroba a nasazení • provoz a údržba • podle charakteru systému je možné vstoupit do různé fáze (Milestone A, B, C) A B C vypracování konceptu vývoj technologie vývoj systému a předvedení výroba a nasazení provoz a údržba pre-systems acquisition systems acquisition sustainment and maintenance

15. Vypracování konceptu (Concept Refinement) • cílem je propracovat původní koncept vzniklý na základě analýzy existujících řešení jak uvnitř DoD, tak u spojenců • pozornost je věnována zhodnocení kritických technologií, inovaci a konkurenceschopnosti • výsledkem je Technology Development Strategy (předběžný plán vývoje, výzkumu, postupu demonstrací, plán testování, cíle, předběžné náklady a časový plán jednotlivých kroků) • schválení TDS je předmětem Milestone A

16. Vývoj technologie (Technology Development) • cílem je redukce technologických rizik a výběr vhodných technologií za současného zpřesňování požadavků • může zahrnovat i demonstrace technologií • výsledkem je Capability Development Document obsahující architekturu systému postavenou na technologiích s dostatečnou mírou zralosti a detailní parametry systému nezbytné pro jeho další vývoj

17. Vývoj systému a předvedení (System Development and Demonstration) • tato fáze začíná rozhodnutím zvaným Milestone B, které je založeno na zhodnocení technologií, uživatelských požadavků a financování • cílem je • vyvinout systém nebo zlepšit jeho schopnosti, • ujistit se, že integrovaný systém splňuje stanovené požadavky a funguje v provozním prostředí, • redukce rizika a nákladů • zakomponovat lidské zdroje • demonstrovat integraci, součinnost, bezpečnost a užitečnost • technologie, komponenty a subsystémy jsou integrovány na systémové úrovni, je provedena demonstrace a testování

18. Vývoj systému a předvedení (System Development and Demonstration) • fáze • integrace systému – integrace subsystémů, dokončení podrobného návrhu, snížení rizika na systémové úrovni • demonstrace – předvedení schopností systému v souladu se stanovenými klíčovými ukazateli výkonu v prostředí, kde systém bude používán • výsledkem je splnění Milestone C nebo ukončení projektu

19. Výroba a nasazení(Production and Deployment) • cílem je dosáhnout provozních schopností, které umožňují splnění stanoveného cíle • počátek fáze je podmíněn přijatelnými výsledky vývoje, testování a vyhodnocení, dostatečnou úrovní SW, malým rizikem při výrobě, dobrým řízením výroby, souladem se strategickým plánem DoD, důkazem toho, že je systém dostupný, financovatelný a dobře načasovaný • někdy je možné v této fázi zpočátku praktikovat pouze nízkoobjemovou produkci s pozdějším přechodem k plné produkci (po ověření)

20. Provoz a podpora(Operation and Support) • cílem je udržení systému ve stavu efektivního poměru nákladů a výkonu • fáze • údržba (sustainment) – zásobování, doprava, data management, konfigurace, lidské zdroje, školení, životní prostředí, bezpečnost, IT apod. • odstranění (disposal) – na konci užitečné existence systému v soulady s platnými předpisy

21. Evoluční vývoj (evolutionary development) • pro rychlé nasazení systému (existující technologie) • vyžaduje spolupráci mezi uživatelem, testerem a vývojářem • přístupy • spirálový vývoj • na začátku projektu nejsou známy přesné požadavky na cílový stav • požadavky se upřesňují díky demonstracím prototypů systému • inkrementální vývoj • je znám cílový stav • systém se vyvíjí po přírůstcích podle dostupné technologie

22. DoD Systems Engineering process • strukturovaný rekurzivní iterativní přístup k řešení problémů aplikovaný ve všech fázích vývoje systému • slouží k • transformaci potřeb a požadavků do popisu výsledných produktů či procesů (s další fází se vždy upřesňuje) • vytváření informací pro rozhodování • poskytnutí výstupu pro další fázi vývoje

24. DoD Systems Engineering process • vstupy – uživatelské potřeby, cíle, požadavky, omezení projektu, technologická báze apod. • výstupy – závisí na fázi, obsahuje databázi rozhodnutí, různé specifikace, systémové architektury • fáze • analýza požadavků • funkční analýza • syntéza • systémová analýza a řízení • souhrnný název pro techniky, které řídí celý proces SI • cílem je sledovat rozhodování, požadavky, prosazovat technické specifikace, spravovat rozhraní, rizika, sledovat náklady, časový plán, splňování požadavků a průběh celého procesu

25. Analýza požadavků • začíná analýzou vstupů • cílem je definice • požadavků na funkčnost a výkon (co a jak dobře musí systém umět) na základě uživatelských požadavků; definují kvantitu, kvalitu, pokrytí, čas a dostupnost • omezení pro návrh; zahrnují podmínky okolí, nutnost reagovat na hrozby z vnějšku i zevnitř, smlouvy, zákony apod. • musí se zajistit, aby požadavky byly srozumitelné, jednoznačné, kompletní a stručné • výstupy • provozní pohled – definuje, jak a za jakých podmínek bude systém pracovat • funkční pohled – co musí systém dělat (funkce, výkon) • fyzický pohled – říká, má být systém zkonstruován, definuje fyzickou podobu rozhraní mezi komponentami, systémem a uživatelem a požadavky na technologie

26. Typy požadavků podle DoD • uživatelské – definují očekávání ve formě cílů, okolí, omezení a měřítek efektivnosti a vhodnosti; důraz je kladen na vlastní používání systému • funkční – popisují, co za aktivity musí systém poskytovat • požadavky na výkon (performance) – určují, do jaké míry musí být naplněny cíle systému; mají charakter kvantitativní, kvalitativní, časový či rozsahu působení • návrhové – požadavky na realizaci • odvozené – vyplývají z jiných požadavků • přidělené (allocated) – jsou odvozeny z požadavků na vyšší úrovni (např. rozdělením na několik dílčích požadavků)

27. Funkční analýza • provádí se zde dekompozice funkcí identifikovaných v předchozí fázi a požadavky na výkon jsou přiřazovány těmto low-level funkcím • výsledkem je funkční architektura – popis logické funkcionality systému • díky lepšímu porozumění požadavkům může dojít k jejich zpětnému přehodnocení (Requirements Loop)

28. Syntéza • návrh systému pomocí fyzických a softwarových prvků • výsledkem je fyzická architektura • každá část musí sloužit alespoň jedné funkci, může sloužit více funkcím • konzultace s funkční architekturou pro zajištění požadované funkcionality (Design Loop) • výsledný návrh je kontrolován proti původním požadavkům (Verification); využívají se metody zkoušení, simulace, testování apod.

29. IEEE 1220 Life Cycle • Standard for Application and Management of the Systems Engineering Process • interdisciplinární standard sloužící k nalezení řešení od uživatelských požadavků, potřeb a omezení • použitelné pro nové produkty i pro inovaci produktů stávajících • důraz je kladen na aplikaci procesu systémového inženýrství ve všech fázích životního cyklu od úvodní studie (concept definition) po výrobu a provoz pro všechny úrovně pohledu na systém (od systému až po jednotlivé části)

30. Typický ŽC podle IEEE 1220-1994 • vývoj • definice systému – zaměření se na požadavky, architekturu (subsystémy, rozhraní), možná rizika, hrubý návrh systému • definice subsystémů • hrubý návrh (preliminary design) • detailní návrh – výstupy fáze jsou specifikace systému do nejnižší úrovně podrobnosti • výroba, integrace, testování – ověření, že produkt vyhovuje požadavkům • provoz • výroba produktů • uživatelská podpora, modifikace systému

31. SE Process podle IEEE P1220 • přidává další fáze

32. definice očekávání zákazníka definice omezení projetu/podniku definice externích omezení definice možností využití systému definice způsobů měření efektivnosti definice hranic systému definice rozhraní definice prostředí návrh životního cyklu definice funkčních požadavků definice požadavků na výkon definice režimů činnosti systému definice měření technické efektivnost definice fyzických vlastností definice lidských faktorů báze požadavků provozní pohled funkční pohled fyzický pohled validace požadavků Analýza požadavků

33. analýza požadavků porovnání s požadavky uživatelů porovnání s omezeními organizace či projektu porovnání s externími omezeními identifikace odchylek a konfliktů báze ověřených požadavků funkční analýza Validace požadavků

34. verifikace požadavků kontextová funkční analýza analýza chování funkcí definice rozhraní funkcí přiřazení požadavků k funkcím definice dílčích funkcí definice stavů dílčích funkcí dekompozice funkcí definice sekvencí dílčích funkcí definice toku dat mezi dílčími funkcemi definice chybových stavů funkcí identifikace nebezpečných funkcí funkční architektura Funkční analýza verifikace funkcí

35. funkční analýza definice postupu verifikace verifikace ověření úplnosti architektury ověření funkčnosti a výkonu kontrola vyhovění omezením báze požadavků funkční analýza identifikace odchylek a konfliktů analýza požadavků ověřená funkční architektura syntéza Verifikacefunkcí

36. funkční analýza Syntéza seskupení funkcí a přiřazení fyzickým prvkům alternativy fyzických řešení bezpečnostní a environm. rizika ohodnocení kvalitativních faktorů ohodnocení technologických požadavků ohodnocení fyz. a výkonnostních vlastností definice fyz. rozhraní analýza příležitostí vyplývajících ze standardizace analýza dostupnosti off-the-shelf zboží analýza, zda koupit nebo vyrobit modelování a prototypování analýza chybových stavů a jejich řešení zhodnocení potřeb testování analýza nutnosti změn v budoucnu dokončení návrhu fyzická architektura tvorba nákresů a schémat počátek možných změn fyzická verifikace

37. definice postupu verifikace • výběr vhodné metody (analýza, • demonstrace, simulace • volba postupu v rámci zvolených metod • definice prostředí pro verifikaci syntéza • vlastní verifikace • ověření kompletnosti architektury • ověření funkčních a výkonnostních • parametrů definovaných funkční arch. • ověření vyhovění omezením funkční arch. analýza požadavků a syntéza identifikace odchylek a konfliktů ověřená fyzická architektura systémová architektura fyzická verifikace

38. ostatní fáze identifikace konfliktů požadavků zhodnocení variant dekompozice funkcí zhodnocení přiřazení funkcí fyz. prvkům identifikace rizik definice rozsahu trade-off studie analýza volba metodologie a kritérií identifikace alternativ volba metrik a vah provedení trade-off studie analýza nákladů v souvislosti s ŽC analýza vztahu nákladů a efektivnosti analýza vlivu na okolí kvantifikace rizik zhodnocení efektivnosti řešení doporučení alternativy volba nakládání s rizikem ostatní fáze a řízení řízení výběr alternativy a dokumentace

39. ostatní fáze data management definice oblasti řízení management rozhraní řízení rizika měření postupu sběr dat z analýzy a testování sledování změn požadavků a návrhů sledování dat o plnění plánu projektu sledování dat o plnění technického plánu sledování dat metrik procesů změny specifikací změny požadavků a architektur změnu plánu projektu změny technických plánů integrovaná databáze řízení (control) ostatní fáze

40. Systems Engineering Life Cycle Model (Kossiakoff, Sweet, 2003) • model definuje tři hlaví fáze pokrývající různé fáze jiných modelů životního cyklu • vývoj konceptu • stanovení potřeb uživatelů • analýza (stanovení požadavků) • plánování • proveditelnost • vývoj (engineering development) • systém musí uspokojovat stanovené požadavky (systém se navrhne a ověří, případně se vytvoří prototyp) • sledují se ekonomické ukazatele výroby i provozu • post-vývojová fáze • dodatečné úpravy systému apod. po nasazení do výroby

41. Vývoj konceptu system operational requirements system performance requirements system functional specifications operational deficiencies need analysis concept exploration concept definition technological opportunities system studies candidate system concepts defined system concept

42. Vývoj system design specification test & evaluation plan production specifications system functional specifications advanced development engineering design integration & evaluation defined system concept validated development model engineered prototype production system

43. Post-vývojová fáze • výroba (production phase) • řešení problémů, které vznikají v průběhu procesu výroby • provoz a podpora • údržba systému • školení uživatelů • upgrade

44. Metoda (přístup, proces) systémového inženýrství (Kossiakoff, Sweet, 2003) • v jednotlivých fázích životního cyklu se uplatňují podobné postupy • tyto postupy se mohou lišit podle typu systému a fáze životního cyklu systémový model cíle požadavky funkce analýza požadavků funkční popis fyzický popis ověření návrhu předchozí fáze další fáze

45. Metoda (přístup, proces) systémového inženýrství • analýza požadavků (vymezení problému) • sběr a organizace vstupních podmínek, požadavků, modelů, plánů apod. z předchozí fáze • je nutné porozumět všem „proč“ • ujasňování, upravování, kvantifikace

46. Metoda (přístup, proces) systémového inženýrství • funkční definice (funkční analýza a alokace) • přiřazení požadavků funkcím, které musí systém poskytovat • rozvržení požadavků do funkčních bloků • definice vztahů mezi funkčními prvky

47. Metoda (přístup, proces) systémového inženýrství • fyzický popis (syntéza, fyzická analýza a alokace) • syntéza alternativních prvků systému • výběr preferovaného přístupu • vypracování návrhu v potřebné míře podrobnosti

48. Metoda (přístup, proces) systémového inženýrství • validace návrhu (verifikace, ověření) • vytvoření modelu okolí systému • simulace nebo testování systému vůči modelu okolí • revize systému a/nebo modelu okolí dokud je návrh a požadavky kompatibilní

49. Životní cyklus SW systémů • podobný životnímu cyklu systémů obecně • chybí fáze výroby SW částí • SW je často velmi komplexní a hraje důležitou roli, proto je velká pozornost věnována snížení rizika • hlavní kroky • analýza • návrh • implementace (kódování) • testování a integrace • existují různé přístupy lišící se terminologií a rozsahem jednotlivých fází, zvolení přístupu k životnímu cyklu a podoba jednotlivých fází závisí na typu systému

50. Tradiční model I potřeba systému plánování fáze produkt fáze předběžná studie analýza požadavky na systém návrh STOP systémová specifikace imple- mentace STOP fungující IS provoz a podpora STOP IS v provozu