Modely životního cyklu
On 13 listopadu, 2021 by adminVedoucí autoři: Přispívající autoři: Kevin Forsberg, Rick Adcock: Alan Faisandier
Model životního cyklu je jedním z klíčových konceptů systémového inženýrství (SE). Životní cyklusživotní cyklus pro systémový systém se obecně skládá z řady etapetapy regulované souborem manažerských rozhodnutí, která potvrzují, že systém je dostatečně zralý na to, aby opustil jednu etapu a vstoupil do další.
Témata
Každá část SEBoK je rozdělena do oblastí znalostí (KA), což jsou seskupení informací se souvisejícím tématem. KA se zase dělí na témata. Tato KA obsahuje následující témata:
- Hnací síly a volby procesů životního cyklu systému
- Modely procesů životního cyklu systému: Vee
- Modely procesů životního cyklu systému:
- Integrace procesních a produktových modelů
- Šetrné inženýrství
Mapování případových studií a vinět obsažených v části 7 na témata obsažená v části 3 naleznete v článku Matice příkladů implementace.
Typ produktů/služeb s přidanou hodnotou
Generický model životního cyklu ukazuje pouze jednokrokový přístup pro postup fázemi životního cyklu systému. Přidávání hodnoty (jako produktu, služby nebo obojího) je společným cílem všech podniků, ať už veřejných nebo soukromých, ziskových nebo neziskových. Hodnota vzniká poskytnutím a integrací prvků systému do produktu nebo služby podle popisu systému a jeho převedením do produktivního využití. Tyto úvahy o hodnotě povedou k různým formám obecného přístupu k řízení životního cyklu na obrázku 1. Některé příklady jsou následující (Lawson 2010):
- Výrobní podnik vyrábí matice, šrouby a podložky a pak prodává své výrobky jako prvky s přidanou hodnotou, které používají jiné podniky; tyto podniky zase integrují tyto výrobky do svého rozsáhlejšího systému s přidanou hodnotou, jako je letadlo nebo automobil. Jejich požadavky budou obvykle předem specifikovány zákazníkem nebo průmyslovými normami.
- Velkoobchodní nebo maloobchodní podnik nabízí výrobky svým zákazníkům. Jeho zákazníci (jednotlivci nebo podniky) získávají výrobky a používají je jako prvky svých systémů. Podnikový podpůrný systém se bude pravděpodobně oportunisticky vyvíjet podle toho, jak se objeví nové možnosti infrastruktury nebo vzorce poptávky.
- Podnik komerčních služeb, jako je banka, prodává svým zákazníkům různé produkty jako služby. Patří sem běžné účty, spořicí účty, úvěry a správa investic. Tyto služby přinášejí přidanou hodnotu a jsou začleněny do zákaznických systémů jednotlivců nebo podniků. Podpůrný systém podniku služeb se bude pravděpodobně také oportunisticky vyvíjet podle toho, jak se objeví nové možnosti infrastruktury nebo vzorce poptávky.
- Vládní podnik služeb poskytuje občanům služby, které se značně liší, ale mohou zahrnovat služby, jako je zdravotní péče, dálnice a silnice, důchody, prosazování práva nebo obrana. Tyto služby se případně stávají prvky infrastruktury využívanými ve větších všezahrnujících systémech, které jsou v zájmu jednotlivců a/nebo podniků. Významné iniciativy, jako je systém řízení letového provozu nové generace nebo systém krizového řízení v metropolitní oblasti (hurikán, tajfun, zemětřesení, tsunami, povodeň, požár), budou dostatečně složité na to, aby se řídily evolučním přístupem vývoje a zavádění do provozu. Na úrovni prvků budou pravděpodobně existovat předem specifikované jednoprůchodové životní cykly.
- U letadlových a automobilových systémů by pravděpodobně existoval předem specifikovaný víceprůchodový životní cyklus, který by využil počáteční schopnosti v prvním průchodu, ale byl by koncipován tak, aby v pozdějších průchodech přidával další schopnosti přidávající hodnotu.
- Diverzifikovaný podnik pro vývoj softwaru poskytuje softwarové produkty, které splňují požadavky (potřeby) zúčastněných stran, a poskytuje tak služby uživatelům produktů. Bude muset být vyvinut tak, aby disponoval schopnostmi, které lze přizpůsobit tak, aby byly využity v různých přístupech k životnímu cyklu zákazníků, a také schopnostmi produktové řady, které lze rychle a snadno aplikovat na podobný vývoj systému zákazníka. Jeho obchodní model může také zahrnovat poskytování podpory zákazníkovi v rámci životního cyklu systému a schopnosti vývoje.
V těchto příkladech jsou systémy, které zůstávají stabilní po přiměřeně dlouhou dobu, a systémy, které se rychle mění. Různorodost, kterou tyto příklady a jejich procesy představují, ilustruje, proč neexistuje žádný univerzální proces, který by bylo možné použít k definování konkrétního životního cyklu systémů. Přístupy managementu a vedení musí brát v úvahu typ příslušných systémů, jejich dlouhou životnost a potřebu rychlé adaptace na nepředvídané změny, ať už v oblasti konkurence, technologií, vedení nebo priorit mise. Přístupy k řízení a vedení zase ovlivňují typ a počet modelů životního cyklu, které budou nasazeny, a také procesy, které budou použity v rámci každého konkrétního životního cyklu.
Existuje několik postupných a evolučních přístupů k řazení fází životního cyklu, které řeší některé z výše uvedených problémů. Oblast znalostí Modely životního cyklu shrnuje řadu inkrementálních a evolučních modelů životního cyklu, včetně jejich hlavních silných a slabých stránek, a zabývá se také kritérii pro výběr nejvhodnějšího přístupu.
Kategorie modelu životního cyklu
Generický model životního cyklu systému na obrázku 1 jednoznačně nevyhovuje všem situacím. Jednoduchý, precedenční, navazující systém může potřebovat pouze jednu fázi ve fázi definice, zatímco složitý systém může potřebovat více než dvě. U build-upon systémů (vs. throwway) prototypůprototypů může dojít k velké části vývoje ve fázi definice. Integrace systémuintegrace, verifikaceverifikace a validacevalidace může následovat po implementaci nebo pořízení prvků systému. U softwaru, zejména u testovacích a denních sestav, se integrace, verifikace a validace prolínají s implementací prvků. Navíc s nadcházející třetí průmyslovou revolucí trojrozměrného tisku a digitální výroby (Whadcock 2012) může být ve fázi konceptu proveden nejen počáteční vývoj, ale i počáteční výroba.
Software je flexibilní a tvárné médium, které usnadňuje iterativní analýzu, návrh, konstrukci, ověřování a validaci ve větší míře, než je to obvykle možné u čistě fyzických prvků systému. Každé opakování iterativního modelu vývoje přidává materiál (kód) do rostoucí softwarové základny, v níž se rozšířená kódová základna testuje, podle potřeby přepracovává a prokazuje, že splňuje požadavky na výchozí stav.
Software lze elektronicky nakupovat, prodávat, dodávat a modernizovat kdekoli na světě v dosahu digitální komunikace, čímž se jeho logistika výrazně liší a je cenově výhodnější než u hardwaru. Neopotřebovává se a jeho opravy mění jeho obsah a chování, takže regresní testování je složitější než u oprav hardwaru. Jeho diskrétní povaha diktuje, že jeho testování nemůže počítat s analytickou kontinuitou jako u hardwaru. Přičtením 1 k 32767 v 15bitovém registru nevznikne 32768, ale místo toho 0, což se projevilo ve vážných situacích, například při použití střely Patriot.
Existuje velké množství potenciálních modelů životního cyklu procesu. Rozdělují se do tří hlavních kategorií:
- především předem specifikované a sekvenční procesy (např. jednostupňový model vodopádu)
- především evoluční a souběžné procesy (např. štíhlý vývoj, racionální jednotný proces a různé formy modelů vee a spirály)
- především interpersonální a emergentní procesy (např. agilní vývoj, scrum, extrémní programování (XP), metoda dynamického vývoje systémů a procesy založené na inovacích)
Vznik integrovaných, interaktivních hardwarově-softwarových systémů způsobil, že předem specifikované procesy se staly potenciálně škodlivými, protože s jejich používáním měla tendenci vznikat nejefektivnější rozhraní mezi člověkem a systémem, což vedlo k dalším variantám procesů, jako jsou měkké SE (Warfield 1976, Checkland 1981) a procesy integrace člověka a systému (Booher 2003, Pew a Mavor 2007). Donedávna se procesní standardy a modely vyspělosti snažily pokrýt všechny eventuality. Zahrnovaly rozsáhlé procesy pro řízení akvizice, výběr zdrojů, revize a audity, zajištění kvality, řízení konfigurace a správu dokumentů, které by se v mnoha případech staly příliš byrokratickými a neefektivními. To vedlo k zavedení štíhlejších (Ohno 1988; Womack et al. 1990; Oppenheim 2011) a agilnějších (Beck 1999; Anderson 2010) přístupů k souběžným přístupům k hardwaru, softwaru a lidským faktorům, jako jsou souběžné modely vee (Forsberg 1991; Forsberg 2005) a inkrementální spirálový model závazku (Pew a Mavor 2007; Boehm a Lane 2007).
V příštím článku o hnacích silách a volbách procesů životního cyklu systému budou tyto variace na téma modelů životního cyklu identifikovány a představeny.
Odpovědnost systémového inženýra
Bez ohledu na použité modely životního cyklu zahrnuje úloha systémového inženýra celý životní cyklus zájmového systému. Systémoví inženýři organizují vývoj a evoluci řešení od definování požadavků přes provoz až po vyřazení systému z provozu. Zajišťují, aby byli řádně zapojeni odborníci na danou oblast, aby byly využity všechny výhodné příležitosti a aby byla identifikována a pokud možno zmírněna všechna významná rizika. Systémový inženýr úzce spolupracuje s projektovým manažerem při přizpůsobování obecného životního cyklu, včetně klíčových rozhodovacích bran, potřebám svého konkrétního projektu.
Úkoly systémového inženýrství se obvykle soustřeďují na začátek životního cyklu; komerční i vládní organizace však uznávají potřebu SE v průběhu celého životního cyklu systému. Často se toto průběžné úsilí týká úprav nebo změn systému, výrobku nebo služby poté, co vstoupí do výroby nebo je uveden do provozu. Proto je SE důležitou součástí všech fází životního cyklu. Ve fázích výroby, podpory a používání (PSU) SE například provádí analýzu výkonnosti, monitorování rozhraní, analýzu poruch, logistickou analýzu, sledování a analýzu navrhovaných změn. Všechny tyto činnosti jsou nezbytné pro průběžnou podporu systému.
Všichni projektoví manažeři musí zajistit, aby obchodní aspekt (náklady, harmonogram a hodnota) a technický aspekt projektového cyklu zůstaly synchronizovány. Často je technický aspekt hnací silou projektu. Odpovědností systémových inženýrů je zajistit, aby zvažovaná technická řešení byla v souladu s cíli v oblasti nákladů a harmonogramu. To může vyžadovat spolupráci s uživateli a zákazníky na revizi cílů tak, aby se vešly do obchodních mezí. Z těchto otázek také vyplývá potřeba, aby rozhodovací brány byly v průběhu projektového cyklu vhodně rozmístěny. Ačkoli se povaha těchto rozhodovacích bran bude lišit podle výše uvedených hlavních kategorií, každá z nich bude zahrnovat validaci v průběhu procesu mezi vývojáři a koncovými uživateli. Validace v průběhu procesu si klade otázku: „Uspokojí to, co plánujeme nebo vytváříme, potřeby zúčastněných stran?“. In-procesní validace začíná při inicializaci projektu během zjišťování potřeb uživatelů a pokračuje přes každodenní činnosti, formální přezkoumání rozhodovací brány, dodání konečného produktu nebo řešení, provoz a nakonec až po uzavření a likvidaci systému.
Citované práce
Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.
Beck, K. 1999. Extrémní programování vysvětleno. Boston, MA: Addison Wesley.
Boehm, B. a J. Lane. 2007. „Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering“. CrossTalk. Říjen 2007: 4-9.
Booher, H. (ed.) 2003. Handbook of Human Systems Integration (Příručka integrace lidských systémů). Hoboken, NJ, USA: Wiley.
Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA: Wiley.
Cusumano, M., and D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA: The Free Press.
Forsberg, K. a H. Mooz. 1991. „The Relationship of System Engineering to the Project Cycle,“ Proceedings of INCOSE, October 1991.
Forsberg, K., H. Mooz a H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.
ISO/IEC/IEEE. 2015. systémové a softwarové inženýrství – procesy životního cyklu systému. ženeva, švýcarsko: Mezinárodní organizace pro normalizaci (ISO)/Mezinárodní elektrotechnická komise (IEC), Institut elektrotechnických a elektronických inženýrů.ISO/IEC 15288:2015.
Lawson, H. 2010. Cesta krajinou systémů. London, UK: College Publications.
Ohno, T. 1988. Výrobní systém Toyota. New York, NY: Productivity Press.
Oppenheim, B. 2011. Lean for Systems Engineering (Štíhlý systém pro systémové inženýrství). Hoboken, NJ: Wiley.
Pew, R. a A. Mavor (eds.). 2007. Human-System Integration in The System Development Process [Integrace člověka a systému v procesu vývoje systému]: A New Look. Washington, DC, USA: The National Academies Press.
Warfield, J. 1976. Systémové inženýrství. Washington, DC, USA: US Department of Commerce (DoC).
Whadcock, I. 2012. „Třetí průmyslová revoluce.“ The Economist. April 21, 2012.
Womack, J.P., D.T. Jones, and D. Roos 1990. The Machine That Changed the World [Stroj, který změnil svět]: The Story of Lean Production (Příběh štíhlé výroby). New York, NY, USA: Rawson Associates.
Primární literatura
Blanchard, B.S., and W.J. Fabrycky. 2011. Systémové inženýrství a analýza, 5. vyd. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.
Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizing Project Management, 3. vyd. Hoboken, NJ: J. Wiley & Sons.
INCOSE. 2012. Příručka systémového inženýrství, verze 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.
Lawson, H. 2010. Cesta krajinou systémů. London, UK: College Publications.
Pew, R. a A. Mavor (Eds.). 2007. Human-System Integration in The System Development Process [Integrace člověka a systému v procesu vývoje systému]: A New Look. Washington, DC, USA: The National Academies Press.
Další literatura
Chrissis, M., M. Konrad a S. Shrum. 2003. CMMI: Pokyny pro integraci procesů a zlepšování produktů. New York, NY, USA: Addison Wesley.
Larman, C. a B. Vodde. 2009. Škálování štíhlého a agilního vývoje. New York, NY, USA: Addison Wesley.
Následující tři knihy nejsou uvedeny v textu SEBoK, ani se nejedná o „texty“ systémového inženýrství; obsahují však důležité poznatky z oblasti systémového inženýrství a čtenářům tohoto SEBOKu doporučujeme jejich přečtení.
Kinder, G. 1998. Zlatá loď v hlubokém modrém moři. New York, NY, USA: Grove Press.
Jedná se o vynikající knihu, která sleduje nápad od jeho vzniku až po jeho nakonec úspěšnou realizaci. Přestože se zde nepojednává o systémovém inženýrství, je zde přehledně znázorněn celý proces od počátečního definování projektu přes vývoj alternativních koncepcí, postupný průzkum a „myšlenkové experimenty“ až po řešení problémů na této cestě. Ukazuje také problém nepředvídání kritických problémů mimo obvyklý rozsah projektu a inženýrství. Nalezení a vyzvednutí 24 tun zlatých prutů a mincí z potopené lodi v hloubce 2 500 metrů v oceánu trvalo asi pět let, ale vyhrát právní bitvu s právníky zastupujícími pojišťovny, které si nárokovaly vlastnictví na základě 130 let starých pojistek, jež vydaly majitelům zlata v roce 1857, trvalo deset let.
McCullough, D. 1977. Cesta mezi moři: vznik Panamského průplavu (1870-1914). New York, NY, USA: Simon & Schuster.
Ačkoli „systémové inženýrství“ není zmíněno, tato kniha poukazuje na mnoho problémů systémového inženýrství a ilustruje potřebu SE jako disciplíny. Kniha také ilustruje nebezpečí použití dříve úspěšného konceptu (mořský průplav použitý v Suezu o deset let dříve) v podobné, ale jiné situaci. Ferdinand de Lesseps vedl jak suezský, tak panamský projekt. Ilustruje nebezpečí absence projektového cyklu založeného na faktech a smysluplných rozhodovacích bran v průběhu celého projektového cyklu. Poukazuje také na nebezpečí poskytování stavu projektu bez viditelnosti. Po pěti letech desetiletého projektu bylo investorům sděleno, že projekt je dokončen z více než 50 %, zatímco ve skutečnosti bylo dokončeno pouze 10 % prací. Druhé kolo vývoje pod Stevensovým vedením v roce 1904 se zaměřilo spíše na „přemisťování hlíny“ než na kopání kanálu, což je koncepce systémového inženýrství klíčová pro dokončení kanálu. Cesta mezi moři získala Národní knižní cenu za historii (1978), Cenu Francise Parkmana (1978), Cenu Samuela Eliota Morisona (1978) a Cenu Cornelia Ryana (1977).
Shackleton, Sir E.H. 2008. (Původně vyšlo v nakladatelství William Heinemann, Londýn, 1919). Již: The Last Antarctic Expedition of Shackleton and the Endurance (Poslední antarktická výprava Shackletona a lodi Endurance). Guilford, CT, USA: Lyons Press.
Jedná se o úžasný příběh poslední antarktické výpravy Shackletona a lodi Endurance v letech 1914 až 1917. Lekcí systémového inženýrství je neustálé každodenní vyhodnocování rizik kapitánem, vedoucím expedice a posádkou, když leželi 18 měsíců uvězněni v arktickém ledu. Všech 28 členů posádky přežilo.
Relevantní videa
- Přístup NASA k systémovému inženýrství – Space Systems Engineering 101 w/ NASA
Napsat komentář