Life Cycle Models

Lead Authors: Kevin Forsberg, Rick Adcock, Bijdragende Auteur: Alan Faisandier

Het levenscyclusmodel is één van de sleutelconcepten van systems engineering (SE). Een levenscyclus voor een systeemsysteem bestaat in het algemeen uit een reeks stadia stadia die worden geregeld door een reeks managementbeslissingen die bevestigen dat het systeem rijp genoeg is om het ene stadium te verlaten en een ander in te gaan.

Topics

Elk deel van de SEBoK is onderverdeeld in kennisgebieden (KA’s), dat zijn groeperingen van informatie met een verwant thema. De KA’s zijn op hun beurt weer onderverdeeld in onderwerpen. Deze KA bevat de volgende onderwerpen:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• System Life Cycle Process Models: Iteratief
• Integratie van proces- en productmodellen
• Lean Engineering

Zie het artikel Matrix van implementatievoorbeelden voor een mapping van casestudies en vignetten uit deel 7 met onderwerpen uit deel 3.

Type producten/diensten met toegevoegde waarde

Het Generieke Levenscyclusmodel toont slechts de éénstapsbenadering voor het doorlopen van de fasen van de levenscyclus van een systeem. Het toevoegen van waarde (als een product, een dienst, of beide), is een gedeeld doel van alle ondernemingen, publiek of privé, met of zonder winstoogmerk. Waarde wordt geproduceerd door de elementen van een systeem te leveren en te integreren in een product of dienst volgens de systeembeschrijving en door het productief te gebruiken. Deze waardeoverwegingen zullen leiden tot verschillende vormen van de generieke levenscyclus-managementaanpak in figuur 1. Enkele voorbeelden (Lawson 2010):

• Een productiebedrijf produceert moeren, bouten en borgringen en verkoopt deze producten vervolgens als elementen met toegevoegde waarde die door andere bedrijven kunnen worden gebruikt; deze bedrijven integreren deze producten op hun beurt in een meer omvattend systeem met toegevoegde waarde, zoals een vliegtuig of een auto. Hun eisen worden over het algemeen vooraf gespecificeerd door de klant of door industrienormen.

• Een groot- of detailhandelsonderneming biedt producten aan haar klanten aan. De klanten (particulieren of ondernemingen) kopen de producten en gebruiken deze als elementen in hun systemen. Het ondersteunende systeem van de onderneming zal zich waarschijnlijk opportunistisch ontwikkelen, naarmate nieuwe infrastructuurmogelijkheden of vraagpatronen ontstaan.

• Een commerciële dienstverlenende onderneming, zoals een bank, verkoopt een verscheidenheid aan producten als diensten aan haar klanten. Hieronder vallen betaalrekeningen, spaarrekeningen, leningen en beleggingsbeheer. Deze diensten voegen waarde toe en worden opgenomen in klantensystemen van individuen of ondernemingen. Het ondersteunende systeem van de dienstverlenende onderneming zal waarschijnlijk ook opportunistisch evolueren, naarmate nieuwe infrastructuurmogelijkheden of vraagpatronen opduiken.

• Een dienstverlenende onderneming van de overheid levert diensten aan burgers die sterk uiteenlopen, maar diensten kunnen omvatten zoals gezondheidszorg, snelwegen en wegen, pensioenen, rechtshandhaving of defensie. Waar nodig worden deze diensten infrastructuurelementen die worden gebruikt in grotere, allesomvattende systemen die van belang zijn voor individuen en/of ondernemingen. Belangrijke initiatieven, zoals een luchtverkeersleidingssysteem van de volgende generatie of een crisisbeheersingssysteem voor een grootstedelijk gebied (orkaan, tyfoon, aardbeving, tsunami, overstroming, brand), zullen voldoende complex zijn om een evolutionaire ontwikkeling en veldbenadering te volgen.

• Voor vliegtuig- en automobielsystemen zal er waarschijnlijk sprake zijn van een vooraf gespecificeerde levenscyclus met meerdere fasen, zodat in de eerste fase kan worden geprofiteerd van de eerste capaciteiten, maar in latere fasen zal worden gewerkt met capaciteiten die waarde toevoegen.

• Een gediversifieerde softwareontwikkelingsonderneming levert softwareproducten die voldoen aan de eisen (behoeften) van de belanghebbenden, en levert op die manier diensten aan de gebruikers van het product. Zij zal moeten worden ontwikkeld om te beschikken over capaciteiten die op maat kunnen worden gemaakt om te worden gebruikt in de levenscyclusbenaderingen van verschillende klanten en ook met productlijncapaciteiten die snel en gemakkelijk kunnen worden toegepast op soortgelijke systeemontwikkelingen van klanten. Het bedrijfsmodel kan ook inhouden dat de klant wordt voorzien van mogelijkheden voor ondersteuning en evolutie gedurende de levenscyclus van het systeem.

In deze voorbeelden zijn er systemen die gedurende redelijk lange perioden stabiel blijven en systemen die snel veranderen. De diversiteit die deze voorbeelden en hun processen vertegenwoordigen, illustreren waarom er geen uniform proces bestaat dat kan worden gebruikt om een specifieke levenscyclus van een systeem te definiëren. Management- en leiderschapsbenaderingen moeten rekening houden met het soort systemen waar het om gaat, hun levensduur, en de noodzaak van snelle aanpassing aan onvoorziene veranderingen, of het nu gaat om concurrentie, technologie, leiderschap of missieprioriteiten. Op hun beurt hebben de management- en leiderschapsbenaderingen invloed op het soort en het aantal levenscyclusmodellen dat wordt ingezet, alsmede op de processen die binnen een bepaalde levenscyclus zullen worden gebruikt.

Er zijn verschillende incrementele en evolutionaire benaderingen voor de opeenvolging van de levenscyclusfasen om een aantal van de hierboven aan de orde gestelde kwesties aan te pakken. Het kennisgebied Levenscyclusmodellen geeft een overzicht van een aantal incrementeelincrementele en evolutionairevolutieve levenscyclusmodellen, inclusief hun belangrijkste sterke en zwakke punten en bespreekt ook criteria voor het kiezen van de best passende benadering.

Categorieën levenscyclusmodel

Het Generieke Systeem Levenscyclusmodel in figuur 1 past niet expliciet in alle situaties. Een eenvoudig, precedentgericht, opvolgend systeem heeft misschien maar één fase in de definitiefase nodig, terwijl een complex systeem er misschien meer dan twee nodig heeft. Bij opgebouwde systemen (vs. wegwerp-)prototypen kan een groot deel van de ontwikkeling tijdens de definitiefase plaatsvinden. Systeemintegratieintegratie, verificatieverificatie en validatie kunnen volgen op de implementatie of verwerving van de systeemelementen. Bij software, met name test-first en dagelijkse builds, zijn integratie, verificatie en validatie verweven met de implementatie van de elementen. Bovendien, met de komende Derde Industriële Revolutie van driedimensionaal printen en digitale productie (Whadcock 2012), kan niet alleen de initiële ontwikkeling maar ook de initiële productie al in de conceptfase plaatsvinden.

Software is een flexibel en kneedbaar medium dat iteratieve analyse, ontwerp, constructie, verificatie en validatie vergemakkelijkt in een grotere mate dan gewoonlijk mogelijk is voor de puur fysieke componenten van een systeem. Elke herhaling van een iteratief ontwikkelingsmodel voegt materiaal (code) toe aan de groeiende softwarebasis, waarbij de uitgebreide codebasis wordt getest, indien nodig herwerkt, en aangetoond dat deze voldoet aan de eisen voor de basislijn.

Software kan elektronisch worden gekocht, verkocht, geleverd, en overal ter wereld worden opgewaardeerd binnen het bereik van digitale communicatie, waardoor de logistiek ervan aanzienlijk anders en kosteneffectiever is dan die van hardware. Het verslijt niet en zijn herstellingen veranderen zijn inhoud en gedrag, waardoor regressietests complexer zijn dan bij hardwareherstellingen. Het discrete karakter ervan dicteert dat het testen niet kan rekenen op analytische continuïteit zoals bij hardware. Het toevoegen van 1 aan 32767 in een 15-bit register levert geen 32768 op, maar 0, zoals ervaren in ernstige situaties, zoals bij het gebruik van de Patriot-raket.

Er zijn een groot aantal potentiële levenscyclus-procesmodellen. Zij vallen in drie grote categorieën uiteen:

1. voornamelijk vooraf gespecificeerde en sequentiële processen (b.v. het watervalmodel in één stap)
2. voornamelijk evolutionaire en gelijktijdige processen (b.v. lean development, het rational unified process, en verschillende vormen van het vee- en spiraalmodel)
3. voornamelijk intermenselijke en opkomende processen (b.v. agile ontwikkeling, scrum, extreme programmering (XP), de dynamische systeemontwikkelingsmethode, en op innovatie gebaseerde processen)

De opkomst van geïntegreerde, interactieve hardware-softwaresystemen maakte vooraf gespecificeerde processen potentieel schadelijk, omdat de meest effectieve mens-systeeminterfaces de neiging hadden te ontstaan met het gebruik ervan, wat leidde tot verdere procesvariaties, zoals zachte SE (Warfield 1976, Checkland 1981) en mens-systeemintegratieprocessen (Booher 2003, Pew en Mavor 2007). Tot voor kort hebben processtandaarden en maturiteitsmodellen getracht alle eventualiteiten te bestrijken. Zij omvatten uitgebreide processen voor acquisitiebeheer, bronselectie, beoordelingen en audits, kwaliteitsborging, configuratiebeheer en documentbeheer, die in veel gevallen al te bureaucratisch en inefficiënt zouden worden. Dit leidde tot de introductie van meer lean (Ohno 1988; Womack et al. 1990; Oppenheim 2011) en agile (Beck 1999; Anderson 2010) benaderingen van gelijktijdige hardware-software-human factors benaderingen, zoals de concurrent vee modellen (Forsberg 1991; Forsberg 2005) en Incremental Commitment Spiral Model (Pew en Mavor 2007; Boehm en Lane 2007).

In het volgende artikel over System Life Cycle Process Drivers and Choices, zullen deze variaties op het thema van levenscyclusmodellen worden geïdentificeerd en gepresenteerd.

Systems Engineering Responsibility

Of de levenscyclusmodellen nu worden gebruikt, de rol van de systems engineer omvat de gehele levenscyclus van het systeem-van-belang. Systeemingenieurs orkestreren de ontwikkeling en de evolutie van een oplossing, van het bepalen van de vereisten tot de werking en uiteindelijk tot het buiten gebruik stellen van het systeem. Zij zorgen ervoor dat de domeinexperts op de juiste wijze worden betrokken, dat alle voordelige kansen worden benut en dat alle significante risico’s worden geïdentificeerd en, indien mogelijk, beperkt. De systeemingenieur werkt nauw samen met de projectmanager bij het afstemmen van de generieke levenscyclus, met inbegrip van de belangrijkste besluitvormingspoorten, om te voldoen aan de behoeften van hun specifieke project.

Systems engineering-taken zijn gewoonlijk geconcentreerd aan het begin van de levenscyclus; zowel commerciële als overheidsorganisaties erkennen echter de noodzaak van SE gedurende de gehele levenscyclus van het systeem. Vaak is deze voortdurende inspanning erop gericht een systeem, product of dienst te wijzigen of aan te passen nadat het in productie is genomen of in bedrijf is gesteld. SE is dan ook een belangrijk onderdeel van alle fasen van de levenscyclus. Tijdens de productie-, ondersteunings- en gebruiksfase (PSU) voert de SE bijvoorbeeld prestatieanalyses, interfacebewaking, storingsanalyse, logistieke analyse, tracering en analyse van voorgestelde wijzigingen uit. Al deze activiteiten zijn essentieel voor de voortdurende ondersteuning van het systeem.

Alle projectmanagers moeten ervoor zorgen dat het zakelijke aspect (kosten, planning en waarde) en het technische aspect van de projectcyclus gesynchroniseerd blijven. Vaak is het technische aspect de motor van het project. Het is de verantwoordelijkheid van de systeemingenieurs om ervoor te zorgen dat de technische oplossingen die worden overwogen in overeenstemming zijn met de kosten- en tijdsdoelstellingen. Dit kan inhouden dat met de gebruikers en klanten moet worden samengewerkt om de doelstellingen te herzien zodat zij binnen de bedrijfsgrenzen passen. Deze kwesties drijven ook de behoefte aan beslissingspoorten aan om op gepaste wijze door de projectcyclus te worden gespreid. Hoewel de aard van deze beslissingsmomenten varieert naar gelang de hoofdcategorieën hierboven, zal bij elk ervan sprake zijn van in-proces validatie tussen de ontwikkelaars en de eindgebruikers. In-proces validatie stelt de vraag: “Zal wat we plannen of creëren voldoen aan de behoeften van de belanghebbenden?” In-proces validatie begint bij de initialisatie van het project tijdens het ontdekken van de behoeften van de gebruiker en gaat verder via dagelijkse activiteiten, formele beslissingsgate reviews, eindproduct of oplossing levering, operaties, en uiteindelijk tot systeem closeout en verwijdering.

Works Cited

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

Beck, K. 1999. Extreem Programmeren Uitgelegd. Boston, MA: Addison Wesley.

Boehm, B. en J. Lane. 2007. “Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering.” CrossTalk. Oktober 2007: 4-9.

Booher, H. (ed.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, VS: 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. and H. Mooz. 1991. “The Relationship of System Engineering to the Project Cycle,” Proceedings of INCOSE, oktober 1991.

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

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

Lawson, H. 2010. Een reis door het systeemlandschap. Londen, UK: College Publications.

Ohno, T. 1988. Toyota Productie Systeem. New York, NY: Productivity Press.

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

Pew, R. en A. Mavor (eds.). 2007. Mens-Systeem Integratie in het Systeemontwikkelingsproces: Een nieuwe kijk. Washington, DC, USA: The National Academies Press.

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

Whadcock, I. 2012. “Een derde industriële revolutie.” The Economist. April 21, 2012.

Womack, J.P., D.T. Jones, and D. Roos 1990. De machine die de wereld veranderde: 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, 5th ed. 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, 3rd Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook, versie 3.2.2. San Diego, CA, VS: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Een reis door het systeemlandschap. Londen, UK: College Publications.

Pew, R. en A. Mavor (Eds.). 2007. Mens-Systeem Integratie in het Systeemontwikkelingsproces: Een nieuwe kijk. Washington, DC, USA: The National Academies Press.

Aanvullende Referenties

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Richtlijnen voor procesintegratie en productverbetering. New York, NY, USA: Addison Wesley.

Larman, C. en B. Vodde. 2009. Scaling Lean and Agile Development. New York, NY, USA: Addison Wesley.

De volgende drie boeken worden niet genoemd in de SEBoK-tekst en zijn ook geen “teksten” over systeemengineering; ze bevatten echter belangrijke lessen over systeemengineering en lezers van deze SEBOK worden aangemoedigd ze te lezen.

Kinder, G. 1998. Schip van goud in de diepe blauwe zee. New York, NY, USA: Grove Press.

Dit is een uitstekend boek dat een idee volgt vanaf het eerste idee tot de uiteindelijk succesvolle uitvoering ervan. Hoewel systeemengineering niet wordt besproken, wordt het duidelijk geïllustreerd in het hele proces van vroege projectdefinitie tot alternatieve conceptontwikkeling tot gefaseerde verkenning en “gedachte-experimenten” tot het aanpakken van uitdagingen onderweg. Het toont ook het probleem aan van het niet anticiperen op kritieke problemen buiten het gebruikelijke project- en engineeringbereik. Het duurde ongeveer vijf jaar om de 24 ton goudstaven en munten van het gezonken schip in de 2500 meter diepe oceaan te lokaliseren en te bergen, maar het kostte tien jaar om de juridische strijd te winnen met de advocaten die de verzekeringsmaatschappijen vertegenwoordigden die het eigendom opeisten op basis van 130 jaar oude polissen die zij in 1857 aan de goudeigenaren hadden afgegeven.

McCullough, D. 1977. The Path Between the Seas: The Creation of the Panama Canal (1870 – 1914). New York, NY, USA: Simon & Schuster.

Hoewel “systems engineering” niet wordt genoemd, belicht dit boek veel systems engineering-kwesties en illustreert het de behoefte aan SE als discipline. Het boek illustreert ook het gevaar van het toepassen van een eerder succesvol concept (het zeekanaal dat tien jaar eerder in Suez werd gebruikt) in een vergelijkbare maar andere situatie. Ferdinand de Lesseps leidde zowel het Suez- als het Panama-project. Het illustreert het gevaar van het ontbreken van een op feiten gebaseerde projectcyclus en zinvolle besluitvormingspoorten gedurende de gehele projectcyclus. Het toont ook het gevaar aan van het verstrekken van projectstatus zonder zichtbaarheid. Na vijf jaar van het tienjarige project werd investeerders verteld dat het project voor meer dan 50% was voltooid, terwijl in feite slechts 10% van het werk was voltooid. De tweede ontwikkelingsronde onder Stevens in 1904 richtte zich op het “verplaatsen van vuil” in plaats van het graven van een kanaal, een systeemtechnisch concept dat essentieel was voor de voltooiing van het kanaal. The Path Between the Seas won de National Book Award voor geschiedenis (1978), de Francis Parkman Prize (1978), de Samuel Eliot Morison Award (1978), en de Cornelius Ryan Award (1977).

Shackleton, Sir E.H. 2008. (Oorspronkelijk gepubliceerd in door William Heinemann, Londen, 1919). Het Zuiden: De laatste Antarctische expeditie van Shackleton en de Endurance. Guilford, CT, USA: Lyons Press.

Dit is het verbazingwekkende verhaal van de laatste Antarctische expeditie van Shackleton en de Endurance in 1914 tot 1917. De les van systeemengineering is de voortdurende, dagelijkse risicobeoordeling door de kapitein, de expeditieleider en de bemanning toen ze 18 maanden lang vastzaten in het arctische ijs. Alle 28 bemanningsleden overleefden het.

Relevante video’s

• NASA’s benadering van systeemengineering- Space Systems Engineering 101 w/ NASA