Lebenszyklusmodelle

Führende Autoren: Kevin Forsberg, Rick Adcock, Mitwirkende Autoren: Alan Faisandier

Das Lebenszyklusmodell ist eines der Schlüsselkonzepte des Systems Engineering (SE). Der Lebenszyklus eines Systems besteht im Allgemeinen aus einer Reihe von Phasen, die durch eine Reihe von Managemententscheidungen geregelt werden, die bestätigen, dass das System reif genug ist, um eine Phase zu verlassen und in eine andere einzutreten.

Themen

Jeder Teil des SEBoK ist in Wissensbereiche (KAs) unterteilt, die Gruppierungen von Informationen mit einem verwandten Thema sind. Die KAs sind ihrerseits in Themen unterteilt. Dieser KA enthält die folgenden Themen:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• Systemlebenszyklus-Prozessmodelle: Iterativ
• Integration von Prozess- und Produktmodellen
• Lean Engineering

Siehe den Artikel Matrix der Umsetzungsbeispiele für eine Zuordnung der in Teil 7 enthaltenen Fallstudien und Vignetten zu den in Teil 3 behandelten Themen.

Art der wertschöpfenden Produkte/Dienstleistungen

Das generische Lebenszyklusmodell zeigt nur den einstufigen Ansatz für das Durchlaufen der Phasen des Lebenszyklus eines Systems. Die Wertschöpfung (als Produkt, Dienstleistung oder beides) ist ein gemeinsames Ziel aller Unternehmen, ob öffentlich oder privat, gewinnorientiert oder gemeinnützig. Wert wird durch die Bereitstellung und Integration der Elemente eines Systems in ein Produkt oder eine Dienstleistung entsprechend der Systembeschreibung und deren Überführung in den produktiven Einsatz geschaffen. Diese Wertüberlegungen führen zu verschiedenen Formen des generischen Lebenszyklusmanagementansatzes in Abbildung 1. Einige Beispiele sind wie folgt (Lawson 2010):

• Ein Fertigungsunternehmen stellt Muttern, Schrauben und Sicherungsscheiben her und verkauft seine Produkte dann als Wertschöpfungselemente, die von anderen Unternehmen verwendet werden; diese Unternehmen wiederum integrieren diese Produkte in ihr umfassenderes Wertschöpfungssystem, wie z. B. ein Flugzeug oder ein Automobil. Ihre Anforderungen werden im Allgemeinen vom Kunden oder durch Industriestandards vorgegeben.

• Ein Groß- oder Einzelhandelsunternehmen bietet seinen Kunden Produkte an. Seine Kunden (Einzelpersonen oder Unternehmen) erwerben die Produkte und verwenden sie als Elemente in ihren Systemen. Das Unterstützungssystem des Unternehmens wird sich wahrscheinlich opportunistisch weiterentwickeln, wenn neue Infrastrukturkapazitäten oder Nachfragemuster auftauchen.

• Ein kommerzielles Dienstleistungsunternehmen wie eine Bank verkauft eine Vielzahl von Produkten als Dienstleistungen an seine Kunden. Dazu gehören Girokonten, Sparkonten, Kredite und Investitionsmanagement. Diese Dienstleistungen bieten einen Mehrwert und werden in die Kundensysteme von Einzelpersonen oder Unternehmen integriert. Das Unterstützungssystem des Dienstleistungsunternehmens wird sich wahrscheinlich auch opportunistisch weiterentwickeln, wenn neue Infrastrukturkapazitäten oder Nachfragemuster auftauchen.

• Ein staatliches Dienstleistungsunternehmen stellt den Bürgern Dienstleistungen zur Verfügung, die sehr unterschiedlich sind, aber Dienstleistungen wie Gesundheitsfürsorge, Autobahnen und Straßen, Renten, Strafverfolgung oder Verteidigung umfassen können. Gegebenenfalls werden diese Dienste zu Infrastrukturelementen, die in größeren, umfassenden Systemen von Interesse für Einzelpersonen und/oder Unternehmen genutzt werden. Größere Initiativen wie ein Luftverkehrskontrollsystem der nächsten Generation oder ein Krisenmanagementsystem für ein Großstadtgebiet (Hurrikan, Taifun, Erdbeben, Tsunami, Überschwemmung, Feuer) werden so komplex sein, dass sie einem evolutionären Entwicklungs- und Einführungskonzept folgen.

• Für Flugzeug- und Automobilsysteme wird es wahrscheinlich einen vordefinierten Lebenszyklus mit mehreren Durchläufen geben, um die frühen Fähigkeiten im ersten Durchlauf zu nutzen, der jedoch so gestaltet ist, dass in späteren Durchläufen weitere wertsteigernde Fähigkeiten hinzugefügt werden.

• Ein diversifiziertes Softwareentwicklungsunternehmen stellt Softwareprodukte bereit, die die Anforderungen (Bedürfnisse) der Beteiligten erfüllen und somit Dienstleistungen für die Produktnutzer bieten. Es muss so entwickelt werden, dass es über Fähigkeiten verfügt, die auf die verschiedenen Lebenszyklusansätze der Kunden zugeschnitten werden können, und auch über Produktlinienfähigkeiten, die schnell und einfach auf ähnliche Kundensystementwicklungen angewendet werden können. Das Geschäftsmodell kann auch die Bereitstellung von Systemlebenszyklus-Support und Evolutionsfähigkeiten für den Kunden beinhalten.

In diesen Beispielen gibt es Systeme, die über einen längeren Zeitraum stabil bleiben, und solche, die sich schnell verändern. Die Vielfalt dieser Beispiele und ihrer Prozesse verdeutlicht, warum es keinen einheitlichen Prozess gibt, der für die Definition eines bestimmten Systemlebenszyklus verwendet werden kann. Management- und Führungsansätze müssen die Art der betroffenen Systeme, ihre Langlebigkeit und die Notwendigkeit einer schnellen Anpassung an unvorhergesehene Veränderungen berücksichtigen, sei es in Bezug auf den Wettbewerb, die Technologie, die Führung oder die Auftragsprioritäten. Die Management- und Führungsansätze wirken sich wiederum auf die Art und Anzahl der Lebenszyklusmodelle aus, die eingesetzt werden, sowie auf die Prozesse, die innerhalb eines bestimmten Lebenszyklus verwendet werden.

Es gibt mehrere inkrementelle und evolutionäre Ansätze für die Abfolge der Lebenszyklusphasen, um einige der oben angesprochenen Probleme zu lösen. Der Wissensbereich Lebenszyklusmodelle fasst eine Reihe von inkrementell-inkrementellen und evolutionär-evolutionären Lebenszyklusmodellen zusammen, einschließlich ihrer Hauptstärken und -schwächen, und erörtert auch Kriterien für die Auswahl des am besten geeigneten Ansatzes.

Kategorien von Lebenszyklusmodellen

Das generische Systemlebenszyklusmodell in Abbildung 1 ist nicht explizit für alle Situationen geeignet. Ein einfaches, vorausgehendes Folgesystem braucht vielleicht nur eine Phase in der Definitionsphase, während ein komplexes System mehr als zwei benötigt. Bei Aufbausystemen (im Gegensatz zu Wegwerfprototypen) kann ein großer Teil der Entwicklung in der Definitionsphase stattfinden. SystemintegrationIntegration, VerifizierungVerifizierung und ValidierungValidierung können der Implementierung oder dem Erwerb der Systemelemente folgen. Bei Software, insbesondere bei Test-First und Daily Builds, sind Integration, Verifizierung und Validierung mit der Implementierung der Elemente verwoben. Darüber hinaus kann mit der bevorstehenden dritten industriellen Revolution des dreidimensionalen Drucks und der digitalen Fertigung (Whadcock 2012) nicht nur die anfängliche Entwicklung, sondern auch die anfängliche Produktion während der Konzeptphase erfolgen.

Software ist ein flexibles und formbares Medium, das die iterative Analyse, den Entwurf, die Konstruktion, die Verifizierung und die Validierung in einem größeren Maße erleichtert, als dies bei den rein physischen Komponenten eines Systems normalerweise möglich ist. Jede Wiederholung eines iterativen Entwicklungsmodells fügt der wachsenden Softwarebasis Material (Code) hinzu, wobei die erweiterte Codebasis getestet, bei Bedarf überarbeitet und nachgewiesen wird, dass sie die Anforderungen für die Baseline erfüllt.

Software kann überall auf der Welt innerhalb der Reichweite digitaler Kommunikation elektronisch gekauft, verkauft, geliefert und aufgerüstet werden, wodurch sich ihre Logistik erheblich von der von Hardware unterscheidet und kostengünstiger ist. Sie nutzt sich nicht ab, und ihre Korrekturen ändern ihren Inhalt und ihr Verhalten, was Regressionstests komplexer macht als bei Hardwarekorrekturen. Aufgrund ihrer diskreten Natur können sich ihre Tests nicht auf eine analytische Kontinuität wie bei Hardware verlassen. Die Addition von 1 zu 32767 in einem 15-Bit-Register ergibt nicht 32768, sondern 0, wie man in ernsten Situationen, z. B. beim Einsatz von Patriot-Raketen, erlebt.

Es gibt eine große Anzahl potenzieller Lebenszyklus-Prozessmodelle. Sie lassen sich in drei Hauptkategorien einteilen:

1. primär vorgegebene und sequentielle Prozesse (z.B. das einstufige Wasserfallmodell)
2. primär evolutionäre und gleichzeitige Prozesse (z.B. Lean Development, der rationale Einheitsprozess und verschiedene Formen des Vee- und Spiralmodells)
3. primär interpersonelle und emergente Prozesse (z.B. Agile Entwicklung, Scrum, Extreme Programming (XP), die dynamische Systementwicklungsmethode und innovationsbasierte Prozesse)

Das Aufkommen integrierter, interaktiver Hardware-Software-Systeme machte vordefinierte Prozesse potenziell schädlich, da die effektivsten Mensch-System-Schnittstellen tendenziell mit ihrem Einsatz entstanden, was zu weiteren Prozessvariationen wie Soft SE (Warfield 1976, Checkland 1981) und Mensch-System-Integrationsprozessen (Booher 2003, Pew und Mavor 2007) führte. Bis vor kurzem haben die Prozessstandards und Reifegradmodelle versucht, alle Eventualitäten abzudecken. Sie umfassten umfangreiche Prozesse für das Beschaffungsmanagement, die Auswahl von Bezugsquellen, Überprüfungen und Audits, die Qualitätssicherung, das Konfigurationsmanagement und das Dokumentenmanagement, die in vielen Fällen zu bürokratisch und ineffizient wurden. Dies führte zur Einführung von schlankeren (Ohno 1988; Womack et al. 1990; Oppenheim 2011) und agileren (Beck 1999; Anderson 2010) Ansätzen für gleichzeitige Hardware-Software-Human-Factors-Ansätze wie dem Concurrent-Vee-Modell (Forsberg 1991; Forsberg 2005) und dem Incremental Commitment Spiral Model (Pew und Mavor 2007; Boehm und Lane 2007).

Im nächsten Artikel über System Life Cycle Process Drivers and Choices werden diese Variationen des Themas Lebenszyklusmodelle identifiziert und vorgestellt.

Systems Engineering Responsibility

Ungeachtet der eingesetzten Lebenszyklusmodelle umfasst die Rolle des Systems Engineers den gesamten Lebenszyklus des Systems-of-Interest. Systemingenieure orchestrieren die Entwicklung und Evolution einer Lösung, von der Definition der Anforderungen über den Betrieb bis hin zur Ausmusterung des Systems. Sie stellen sicher, dass die Fachexperten angemessen einbezogen, alle vorteilhaften Möglichkeiten genutzt und alle bedeutenden Risiken identifiziert und, wenn möglich, gemildert werden. Der Systems Engineer arbeitet eng mit dem Projektmanager zusammen, um den allgemeinen Lebenszyklus, einschließlich der wichtigsten Entscheidungspunkte, auf die Bedürfnisse des jeweiligen Projekts abzustimmen.

Die Aufgaben des Systems Engineering konzentrieren sich in der Regel auf den Beginn des Lebenszyklus; sowohl kommerzielle als auch staatliche Organisationen erkennen jedoch die Notwendigkeit von SE während des gesamten Lebenszyklus des Systems an. Häufig handelt es sich bei diesen laufenden Bemühungen um Modifikationen oder Änderungen an einem System, Produkt oder einer Dienstleistung, nachdem es in Produktion gegangen oder in Betrieb genommen worden ist. Folglich ist SE ein wichtiger Bestandteil aller Lebenszyklusphasen. Während der Produktions-, Support- und Nutzungsphasen (PSU) führt SE beispielsweise Leistungsanalysen, Schnittstellenüberwachung, Fehleranalysen, logistische Analysen, Nachverfolgung und Analysen von Änderungsvorschlägen durch. All diese Aktivitäten sind für die laufende Unterstützung des Systems unerlässlich.

Alle Projektmanager müssen sicherstellen, dass der geschäftliche Aspekt (Kosten, Zeitplan und Wert) und der technische Aspekt des Projektzyklus synchronisiert bleiben. Oft ist der technische Aspekt der Motor des Projekts. Es liegt in der Verantwortung der Systemingenieure sicherzustellen, dass die in Betracht gezogenen technischen Lösungen mit den Kosten- und Terminzielen vereinbar sind. Dazu kann es erforderlich sein, mit den Benutzern und Kunden zusammenzuarbeiten, um die Ziele so zu ändern, dass sie in den Rahmen des Unternehmens passen. Aus diesen Aspekten ergibt sich auch die Notwendigkeit, die Entscheidungspunkte in angemessenen Abständen über den gesamten Projektzyklus zu verteilen. Obwohl die Art dieser Entscheidungspunkte je nach den oben genannten Hauptkategorien variiert, beinhaltet jeder von ihnen eine prozessinterne Validierungin-process validation zwischen den Entwicklern und den Endbenutzern. Bei der prozessbegleitenden Validierung wird die Frage gestellt: „Wird das, was wir planen oder erstellen, die Bedürfnisse der Beteiligten erfüllen?“ Die prozessbegleitende Validierung beginnt bei der Initialisierung des Projekts während der Ermittlung der Benutzerbedürfnisse und setzt sich über die täglichen Aktivitäten, die formale Überprüfung der Entscheidungspunkte, die Lieferung des Endprodukts oder der Lösung, den Betrieb und schließlich die Schließung und Entsorgung des Systems fort.

Works Cited

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

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

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

Booher, H. (ed.) 2003. Handbook of Human Systems Integration. Hoboken, NJ, USA: Wiley.

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

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

Forsberg, K. und 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.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. A Journey Through the Systems Landscape. London, UK: College Publications.

Ohno, T. 1988. Toyota Production System. New York, NY: Productivity Press.

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

Pew, R. and A. Mavor (eds.). 2007. Human-System Integration in The System Development Process: 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 third industrial revolution.“ The Economist. April 21, 2012.

Womack, J.P., D.T. Jones, and D. Roos 1990. The Machine That Changed the World: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Primärliteratur

Blanchard, B.S., und 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, Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications.

Pew, R. und A. Mavor (Eds.). 2007. Human-System Integration in The System Development Process: A New Look. Washington, DC, USA: The National Academies Press.

Additional References

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Leitlinien für Prozessintegration und Produktverbesserung. New York, NY, USA: Addison Wesley.

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

Die folgenden drei Bücher werden im SEBoK-Text nicht referenziert und sind auch keine Systems-Engineering-„Texte“; sie enthalten jedoch wichtige Systems-Engineering-Lektionen, und die Leser dieses SEBOK werden aufgefordert, sie zu lesen.

Kinder, G. 1998. Ship of Gold in the Deep Blue Sea. New York, NY, USA: Grove Press.

Dies ist ein ausgezeichnetes Buch, das eine Idee von ihrer Entstehung bis zu ihrer letztendlich erfolgreichen Umsetzung verfolgt. Obwohl die Systemtechnik nicht behandelt wird, wird sie im gesamten Prozess von der frühen Projektdefinition über die Entwicklung eines alternativen Konzepts, die stufenweise Erkundung und die „Gedankenexperimente“ bis hin zur Bewältigung der Herausforderungen auf dem Weg deutlich dargestellt. Es zeigt auch das Problem, dass kritische Probleme außerhalb des üblichen Projekt- und Technikbereichs nicht vorhergesehen werden. Es dauerte etwa fünf Jahre, um die 24 Tonnen Goldbarren und -münzen aus dem gesunkenen Schiff im 2.500 Meter tiefen Ozean zu lokalisieren und zu bergen, aber es dauerte zehn Jahre, um den Rechtsstreit mit den Anwälten zu gewinnen, die Versicherungsgesellschaften vertraten, die auf der Grundlage von 130 Jahre alten Policen, die sie 1857 an die Goldeigentümer ausgestellt hatten, Eigentum beanspruchten.

McCullough, D. 1977. Der Weg zwischen den Meeren: Die Entstehung des Panamakanals (1870 – 1914). New York, NY, USA: Simon & Schuster.

Obwohl „Systems Engineering“ nicht erwähnt wird, beleuchtet dieses Buch viele Probleme des Systems Engineering und veranschaulicht die Notwendigkeit von SE als Disziplin. Das Buch veranschaulicht auch die Gefahr, ein früher erfolgreiches Konzept (den ein Jahrzehnt zuvor in Suez eingesetzten Kanal auf Meereshöhe) auf eine ähnliche, aber andere Situation anzuwenden. Ferdinand de Lesseps leitete sowohl das Suez- als auch das Panama-Projekt. Dies verdeutlicht die Gefahr des Fehlens eines faktenbasierten Projektzyklus und sinnvoller Entscheidungshilfen während des gesamten Projektzyklus. Es zeigt auch die Gefahr auf, dass der Projektstatus nicht sichtbar ist. Nach fünf Jahren des zehnjährigen Projekts wurde den Investoren mitgeteilt, dass das Projekt zu mehr als 50 Prozent abgeschlossen sei, während in Wirklichkeit nur 10 Prozent der Arbeiten abgeschlossen waren. Die zweite Entwicklungsrunde unter Stevens im Jahr 1904 konzentrierte sich auf das „Bewegen von Erde“ statt auf das Graben eines Kanals, ein systemtechnisches Konzept, das für die Fertigstellung des Kanals entscheidend war. The Path Between the Seas wurde mit dem National Book Award für Geschichte (1978), dem Francis Parkman Prize (1978), dem Samuel Eliot Morison Award (1978) und dem Cornelius Ryan Award (1977) ausgezeichnet.

Shackleton, Sir E.H. 2008. (Ursprünglich veröffentlicht in von William Heinemann, London, 1919). South: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, USA: Lyons Press.

Dies ist die erstaunliche Geschichte der letzten Antarktis-Expedition von Shackleton und der Endurance in den Jahren 1914 bis 1917. Die Lektion in Systemtechnik ist die kontinuierliche, tägliche Risikobewertung durch den Kapitän, den Expeditionsleiter und die Besatzung, als sie 18 Monate lang im arktischen Eis gefangen waren. Alle 28 Besatzungsmitglieder überlebten.

Relevante Videos

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