Life Cycle Models

Lead Authors: Kevin Forsberg, Rick Adcock, Közreműködő szerzők: Kevin Forsberg, Rick Adcock: Alan Faisandier

Az életciklus-modell a rendszertervezés (SE) egyik kulcsfogalma. Egy rendszerrendszer életciklusaéletciklusa általában szakaszok sorozatából állolyan szakaszok, amelyeket olyan vezetői döntések szabályoznak, amelyek megerősítik, hogy a rendszer elég érett ahhoz, hogy elhagyja az egyik szakaszt és belépjen egy másikba.

Témák

A SEBoK minden része tudásterületekre (KA-kra) van osztva, amelyek a kapcsolódó témájú információk csoportosításai. A KA-k viszont témákra oszlanak. Ez a KA a következő témaköröket tartalmazza:

• Rendszeréletciklus-folyamatok mozgatórugói és választások
• Rendszeréletciklus-folyamatmodellek: Vee
• System Life Cycle Process Models:
• Folyamat- és termékmodellek integrációja
• Lean Engineering

A 7. részben szereplő esettanulmányok és vignetták a 3. részben tárgyalt témákhoz való hozzárendelését lásd a Megvalósítási példák mátrixa című cikkben.

A hozzáadott értékű termékek/szolgáltatások típusa

A Generikus életciklusmodell csak az egylépéses megközelítést mutatja be a rendszer életciklusának szakaszain való végighaladáshoz. Az értékteremtés (termékként, szolgáltatásként vagy mindkettő) közös célja minden vállalkozásnak, legyen az állami vagy magán, profitorientált vagy nonprofit. Az érték előállítása a rendszer elemeinek a rendszerleírásnak megfelelő termékké vagy szolgáltatássá történő előállításával és integrálásával, valamint a rendszer produktív használatba vételével történik. Ezek az értékkel kapcsolatos megfontolások az 1. ábrán látható általános életciklus-menedzsment megközelítés különböző formáihoz vezetnek. Néhány példa a következő (Lawson 2010):

• Egy termelő vállalkozás anyákat, csavarokat és alátéteket gyárt, majd a termékeit értékteremtő elemként értékesíti, hogy más vállalkozások felhasználhassák; ezek a vállalkozások viszont integrálják ezeket a termékeket a nagyobb értékteremtő rendszerükbe, például egy repülőgépbe vagy egy autóba. Követelményeiket általában a vevő vagy az iparági szabványok határozzák meg előre.

• A nagy- vagy kiskereskedelmi vállalkozás termékeket kínál vevőinek. Ügyfelei (magánszemélyek vagy vállalkozások) beszerzik a termékeket, és rendszereik elemeiként használják azokat. A vállalati támogató rendszer valószínűleg opportunista módon fejlődik, ahogy új infrastrukturális képességek vagy keresleti minták jelennek meg.

• Egy kereskedelmi szolgáltató vállalkozás, mint például egy bank, különféle termékeket értékesít szolgáltatásként ügyfeleinek. Ide tartoznak a folyószámlák, a megtakarítási számlák, a hitelek és a befektetések kezelése. Ezek a szolgáltatások értéket teremtenek, és beépülnek az egyének vagy vállalkozások ügyfélrendszereibe. A szolgáltató vállalkozás támogató rendszere valószínűleg opportunista módon is fejlődik, ahogy új infrastrukturális képességek vagy keresleti minták jelennek meg.

• A kormányzati szolgáltató vállalkozás olyan szolgáltatásokat nyújt a polgároknak, amelyek széles skálán mozognak, de olyan szolgáltatásokat foglalhatnak magukban, mint az egészségügyi ellátás, az autópályák és utak, a nyugdíjak, a bűnüldözés vagy a védelem. Adott esetben ezek a szolgáltatások olyan infrastrukturális elemekké válnak, amelyeket az egyének és/vagy vállalkozások érdekeit szolgáló nagyobb, átfogó rendszerekben használnak. A nagyobb kezdeményezések, mint például egy új generációs légiforgalmi irányító rendszer vagy egy nagyvárosi területre vonatkozó válságkezelő rendszer (hurrikán, tájfun, földrengés, szökőár, árvíz, tűzvész), eléggé összetettek ahhoz, hogy evolúciós fejlesztési és üzembe helyezési megközelítést kövessenek. Elemi szinten valószínűleg előre meghatározott egymenetes életciklusok lesznek.

• A repülőgép- és gépjárműrendszerek esetében valószínűleg előre meghatározott többmenetes életciklusok lesznek, hogy a korai képességeket az első menetben kihasználják, de úgy tervezik, hogy a későbbi menetekben további értéknövelő képességeket adjanak hozzá.

• A diverzifikált szoftverfejlesztő vállalkozás az érdekelt felek követelményeinek (igényeinek) megfelelő szoftvertermékeket nyújt, és így szolgáltatásokat nyújt a termék felhasználói számára. Olyan képességekkel kell fejleszteni, amelyek testre szabhatók, hogy a különböző ügyfelek életciklus-megközelítésében hasznosíthatók legyenek, valamint olyan termékvonalbeli képességekkel, amelyek gyorsan és könnyen alkalmazhatók a hasonló ügyfélrendszer-fejlesztésekhez. Az üzleti modellje magában foglalhatja azt is, hogy az ügyfél számára rendszer-életciklus-támogatást és evolúciós képességeket biztosít.

Ezekben a példákban vannak olyan rendszerek, amelyek ésszerűen hosszú ideig stabilak maradnak, és vannak olyanok, amelyek gyorsan változnak. Az e példák és folyamataik által képviselt sokféleség jól szemlélteti, hogy miért nem létezik olyan egységes folyamat, amely egy adott rendszer életciklusának meghatározására használható. Az irányítási és vezetői megközelítéseknek figyelembe kell venniük az érintett rendszerek típusát, azok hosszú élettartamát, valamint az előre nem látható változásokhoz való gyors alkalmazkodás szükségességét, legyen szó akár a versenyben, a technológiában, a vezetésben vagy a küldetés prioritásaiban bekövetkező változásokról. Az irányítási és vezetési megközelítések viszont hatással vannak az alkalmazott életciklus-modellek típusára és számára, valamint az adott életcikluson belül alkalmazott folyamatokra.

A fenti kérdések némelyikének kezelésére számos inkrementális és evolúciós megközelítés létezik az életciklus szakaszainak sorrendiségére. Az életciklus-modellek tudásterület számos inkrementális-krementális és evolúciósevolúciós életciklus-modellt foglal össze, beleértve azok főbb erősségeit és gyengeségeit, valamint tárgyalja a legmegfelelőbb megközelítés kiválasztásának kritériumait.

Az életciklus-modell kategóriái

Az 1. ábrán látható általános rendszeréletciklus-modell nem kifejezetten alkalmas minden helyzetre. Egy egyszerű, precedensértékű, követő rendszer csak egy fázist igényelhet a definíciós szakaszban, míg egy összetett rendszernek kettőnél több fázisra lehet szüksége. A felépülő rendszerek (vs. eldobható) prototípusokprototípusok esetében a fejlesztés jó része a definíciós szakaszban történhet. Rendszerintegrációintegráció, verifikációverifikáció és validációérvényesítésérvényesítés követheti a rendszerelemek megvalósítását vagy beszerzését. A szoftverek esetében, különösen a tesztelésre épülő és a napi építésű szoftverek esetében az integráció, az ellenőrzés és az érvényesítés összefonódik az elemek megvalósításával. Emellett a közelgő harmadik ipari forradalom, a háromdimenziós nyomtatás és a digitális gyártás (Whadcock 2012) miatt nemcsak a kezdeti fejlesztés, hanem a kezdeti gyártás is megvalósulhat a koncepció fázisában.

A szoftver rugalmas és alakítható közeg, amely nagyobb mértékben megkönnyíti az iteratív elemzést, tervezést, konstrukciót, verifikációt és validálást, mint az általában a rendszer tisztán fizikai elemei esetében lehetséges. Az iteratív fejlesztési modell minden egyes ismétlése anyagot (kódot) ad a növekvő szoftverbázishoz, amelyben a kibővített kódbázist tesztelik, szükség szerint átdolgozzák, és bizonyítják, hogy megfelel az alapvonal követelményeinek.

A szoftver elektronikusan megvásárolható, eladható, szállítható és fejleszthető a világ bármely pontján a digitális kommunikáció hatósugarán belül, így logisztikája jelentősen eltér és költséghatékonyabb, mint a hardveré. Nem kopik el, és javításai megváltoztatják a tartalmát és a viselkedését, ami a regressziós tesztelést összetettebbé teszi, mint a hardveres javítások esetében. Diszkrét jellege miatt tesztelése nem számíthat az analitikai folyamatosságra, mint a hardver esetében. Egy 15 bites regiszterben a 32767-hez 1 hozzáadása nem 32768-at, hanem 0-t eredményez, amint azt súlyos helyzetekben, például a Patriot rakéta alkalmazásakor tapasztaltuk.

Nagyszámú lehetséges életciklusfolyamat-életciklusfolyamatmodell létezik. Ezek három fő kategóriába sorolhatók:

1. főleg előre meghatározott és szekvenciális folyamatok (pl. az egylépéses vízesésmodell)
2. főleg evolúciós és egyidejű folyamatok (pl. a lean fejlesztés, a racionális egységesített folyamat, valamint a vee- és spirálmodell különböző formái)
3. főleg interperszonális és emergens folyamatok (pl. agilis fejlesztés, scrum, extrém programozás (XP), a dinamikus rendszerfejlesztési módszer és az innováción alapuló folyamatok)

Az integrált, interaktív hardver-szoftver rendszerek megjelenésével az előre meghatározott folyamatok potenciálisan károsak lettek, mivel a leghatékonyabb ember-rendszer interfészek általában a használatával együtt alakultak ki, ami további folyamatváltozatokhoz vezetett, például a soft SE (Warfield 1976, Checkland 1981) és az ember-rendszer integrációs folyamatokhoz (Booher 2003, Pew és Mavor 2007). A közelmúltig a folyamatszabványok és az érettségi modellek minden eshetőséget megpróbáltak lefedni. Ezek kiterjedt folyamatokat tartalmaztak a beszerzésirányításra, a forráskiválasztásra, a felülvizsgálatokra és auditokra, a minőségbiztosításra, a konfigurációkezelésre és a dokumentumkezelésre vonatkozóan, ami sok esetben túlságosan bürokratikussá és hatástalanná vált volna. Ez vezetett a karcsúbb (Ohno 1988; Womack et al. 1990; Oppenheim 2011) és agilisabb (Beck 1999; Anderson 2010) megközelítések bevezetéséhez a párhuzamos hardver-szoftver-emberi tényezők megközelítéséhez, mint például a párhuzamos vee-modellek (Forsberg 1991; Forsberg 2005) és az inkrementális elkötelezettségi spirálmodell (Pew és Mavor 2007; Boehm és Lane 2007).

A rendszeréletciklus-folyamatok mozgatórugóiról és választási lehetőségeiről szóló következő cikkben az életciklus-modellek ezen variációit azonosítjuk és mutatjuk be.

Rendszermérnöki felelősség

Függetlenül az alkalmazott életciklus-modellektől, a rendszermérnök szerepe átfogja az adott rendszer teljes életciklusát. A rendszermérnökök irányítják a megoldás fejlesztését és evolúcióját a követelmények meghatározásától az üzemeltetésen át egészen a rendszer nyugdíjazásáig. Ők biztosítják, hogy a szakterület szakértői megfelelően bevonásra kerüljenek, minden előnyös lehetőséget kihasználjanak, és minden jelentős kockázatot azonosítsanak és lehetőség szerint mérsékeljenek. A rendszermérnök szorosan együttműködik a projektmenedzserrel az általános életciklusnak – beleértve a kulcsfontosságú döntési kapukat is – az adott projekt igényeihez való igazításában.

A rendszertervezési feladatok általában az életciklus kezdetére koncentrálódnak; azonban mind a kereskedelmi, mind a kormányzati szervezetek elismerik, hogy az SE-re a rendszer teljes életciklusa során szükség van. Gyakran ez a folyamatos erőfeszítés a rendszer, termék vagy szolgáltatás gyártásba kerülése vagy üzembe helyezése utáni módosítására vagy megváltoztatására irányul. Következésképpen az SE az életciklus valamennyi szakaszának fontos része. A gyártási, támogatási és használati (PSU) szakaszok során például az SE végzi a teljesítményelemzést, a kapcsolódási pontok felügyeletét, a hibaelemzést, a logisztikai elemzést, a nyomon követést és a javasolt változtatások elemzését. Mindezek a tevékenységek elengedhetetlenek a rendszer folyamatos támogatásához.

Minden projektvezetőnek biztosítania kell, hogy a projektciklus üzleti szempontja (költség, ütemezés és érték) és műszaki szempontja szinkronban maradjon. Gyakran a műszaki szempont irányítja a projektet. A rendszermérnökök felelőssége annak biztosítása, hogy a mérlegelt műszaki megoldások összhangban legyenek a költség- és ütemezési célokkal. Ez megkövetelheti a felhasználókkal és az ügyfelekkel való együttműködést a célok felülvizsgálata érdekében, hogy azok az üzleti korlátok közé illeszkedjenek. Ezek a kérdések azt is elősegítik, hogy a döntési kapuk megfelelő időközönként legyenek elhelyezve a projektciklus során. Bár e döntési kapuk jellege a fenti fő kategóriák szerint változik, mindegyik magában foglalja a fejlesztők és a végfelhasználók közötti folyamatközi érvényesítést. A folyamaton belüli validálás a következő kérdést teszi fel: “Az, amit tervezünk vagy létrehozunk, kielégíti-e az érdekelt felek igényeit?”. A folyamaton belüli validálás a projekt kezdetekor, a felhasználói igények feltárása során kezdődik, és a napi tevékenységeken, a hivatalos döntési kapu felülvizsgálatokon, a végső termék vagy megoldás átadásán, az üzemeltetésen és végül a rendszer lezárásán és megsemmisítésén keresztül folytatódik.

Works Cited

Anderson, D. 2010. Kanban. Sequim, WA: Blue Hole Press.

Beck, K. 1999. Extreme Programming Explained. Boston, MA: Addison Wesley.

Boehm, B. and J. Lane. 2007. “Az inkrementális kötelezettségvállalási modell használata a rendszerbeszerzés, a rendszertervezés és a szoftverfejlesztés integrálására”. CrossTalk. Október 2007: 4-9.

Booher, H. (szerk.) 2003. Handbook of Human Systems Integration (Az emberi rendszerek integrációjának kézikönyve). Hoboken, NJ, USA: Wiley.

Checkland, P. 1999. Systems Thinking, Systems Practice, 2nd ed. Hoboken, NJ, USA: Wiley.

Cusumano, M. és D. Yoffie. 1998. Competing on Internet Time, New York, NY, USA: The Free Press.

Forsberg, K. és H. Mooz. 1991. “The Relationship of System Engineering to the Project Cycle,” Proceedings of INCOSE, October 1991.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management, 3rd ed. Hoboken, NJ: J. Wiley & Sons.

ISO/IEC/IEEE. 2015. 2015.Systems and software engineering – system life cycle processes.Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC 15288:2015.

Lawson, H. 2010. Utazás a rendszerszemléleten keresztül. London, UK: College Publications.

Ohno, T. 1988. Toyota termelési rendszer. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean for Systems Engineering. Hoboken, NJ: Wiley.

Pew, R. és A. Mavor (szerk.). 2007. Ember-rendszer integráció a rendszerfejlesztési folyamatban: A New Look. Washington, DC, USA: The National Academies Press.

Warfield, J. 1976. Systems Engineering. Washington, DC, USA: US Department of Commerce (DoC).

Whadcock, I. 2012. “A harmadik ipari forradalom”. The Economist. 2012. április 21.

Womack, J.P., D.T. Jones, and D. Roos 1990. A gép, amely megváltoztatta a világot: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Primary References

Blanchard, B.S., and W.J. Fabrycky. 2011. Systems Engineering and Analysis, 5. kiadás. 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. kiadás. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Rendszermérnöki kézikönyv, 3.2.2. verzió. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Utazás a rendszerszintű tájakon. London, UK: College Publications.

Pew, R. és A. Mavor (szerk.). 2007. Ember-rendszer integráció a rendszerfejlesztési folyamatban: A New Look. Washington, DC, USA: The National Academies Press.

Kiegészítő hivatkozások

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Irányelvek a folyamatintegrációhoz és a termékfejlesztéshez. New York, NY, USA: Addison Wesley.

Larman, C. és B. Vodde. 2009. A lean és agilis fejlesztés skálázása. New York, NY, USA: Addison Wesley.

A következő három könyvre nem hivatkozik a SEBoK szövege, és nem is rendszertechnikai “szövegek”; azonban fontos rendszertechnikai tanulságokat tartalmaznak, és a jelen SEBOK olvasóinak ajánlott elolvasni őket.

Kinder, G. 1998. Aranyhajó a mélykék tengeren. New York, NY, USA: Grove Press.

Ez egy kiváló könyv, amely egy ötletet követ végig a kezdetektől a végül sikeres megvalósításig. Bár a rendszertechnika nem kerül tárgyalásra, világosan illusztrálja az egész folyamatot a korai projektmeghatározástól az alternatív koncepció kidolgozásán át a szakaszos feltárásokig és “gondolatkísérletekig”, valamint az útközben felmerülő kihívások kezeléséig. Bemutatja azt a problémát is, hogy a szokásos projekt- és mérnöki hatáskörön kívül eső kritikus problémákat nem látjuk előre. A 2500 méter mély óceánban elsüllyedt hajó 24 tonna aranyrúdjának és érméjének felkutatása és kiemelése körülbelül öt évbe telt, de tíz évbe telt, amíg megnyerték a jogi csatát a biztosítótársaságokat képviselő ügyvédekkel, akik az 1857-ben az arany tulajdonosainak kiállított 130 éves kötvények alapján követelték a tulajdonjogot.

McCullough, D. 1977. Az út a tengerek között: A Panama-csatorna létrehozása (1870-1914). New York, NY, USA: Simon & Schuster.

Bár a “rendszertechnika” nem szerepel, ez a könyv számos rendszertechnikai kérdésre rávilágít, és illusztrálja az SE mint tudományág szükségességét. A könyv azt is szemlélteti, hogy milyen veszélyt jelent egy korábban sikeres koncepció (az egy évtizeddel korábban Szuezben alkalmazott tengerszint feletti csatorna) alkalmazása egy hasonló, de más helyzetben. Ferdinand de Lesseps mind a szuezi, mind a panamai projektet vezette. Bemutatja a tényeken alapuló projektciklus és az értelmes döntési kapuk hiányának veszélyét a teljes projektciklus során. Rávilágít továbbá a projektstátusz láthatóság nélküli biztosításának veszélyére. A tízéves projekt öt év elteltével a befektetőknek azt mondták, hogy a projekt több mint 50 százalékban befejeződött, holott valójában csak a munkálatok 10 százaléka volt befejezve. A Stevens vezette második fejlesztési kör 1904-ben a csatorna ásása helyett a “föld mozgatására” összpontosított, amely rendszertechnikai koncepció kulcsfontosságú volt a csatorna befejezéséhez. A The Path Between the Seas elnyerte a National Book Award for History (1978), a Francis Parkman-díjat (1978), a Samuel Eliot Morison-díjat (1978) és a Cornelius Ryan-díjat (1977).

Shackleton, Sir E.H. 2008. (Eredetileg megjelent: William Heinemann, London, 1919). South: Shackleton és az Endurance utolsó antarktiszi expedíciója. Guilford, CT, USA: Lyons Press.

Ez Shackleton és az Endurance 1914 és 1917 közötti utolsó antarktiszi expedíciójának elképesztő története. A rendszertechnikai tanulság a kapitány, az expedíció vezetője és a legénység folyamatos, napi szintű kockázatértékelése, miközben 18 hónapig a sarkvidéki jégben rekedtek. A legénység mind a 28 tagja túlélte.

Releváns videók

• NASA’s Approach to Systems Engineering- Space Systems Engineering 101 w/ NASA