System Life Cycle Process Models: Vee

Leitende Autoren: Dick Fairley, Kevin Forsberg, Mitwirkende Autoren: Ray Madachy

Es gibt eine große Anzahl von Lebenszyklusprozessmodellen. Wie im Artikel „System Life Cycle Process Drivers and Choices“ erörtert, lassen sich diese Modelle in drei Hauptkategorien einteilen: (1) primär vorspezifizierte und sequenzielle Prozesse; (2) primär evolutionäre und gleichzeitige Prozesse (z.B. der rationale Vereinheitlichungsprozess und verschiedene Formen des Vee- und Spiralmodells); und (3) primär interpersonelle und uneingeschränkte Prozesse (z.B. agile Entwicklung, Scrum, extreme Programmierung (XP), die dynamische Systementwicklungsmethode und innovationsbasierte Prozesse).

Dieser Artikel konzentriert sich speziell auf das Vee-Modell als primäres Beispiel für vorspezifizierte und sequenzielle Prozesse. In dieser Diskussion ist es wichtig festzustellen, dass das Vee-Modell und Variationen des Vee-Modells alle die gleichen grundlegenden Aktivitäten des Systems Engineering (SE) behandeln. Der Hauptunterschied zwischen diesen Modellen liegt in der Art und Weise, wie sie die oben genannten SE-Aktivitäten gruppieren und darstellen.

Allgemeine Implikationen der Verwendung des Vee-Modells für den Systementwurf und die Systementwicklung werden im Folgenden erörtert; für ein spezifischeres Verständnis der Auswirkungen dieses Lebenszyklusmodells auf Systems-Engineering-Aktivitäten siehe die anderen Wissensbereiche (KAs) in Teil 3.

Ein primär vorspezifiziertes und sequenzielles Prozessmodell: Das Vee-Modell

Die sequenzielle Version des Vee-Modells ist in Abbildung 1 dargestellt. Im Kern handelt es sich um eine sequentielle Abfolge von Plänen, Spezifikationen und Produkten, die als Grundlage dienen und dem Konfigurationsmanagement unterstellt werden. Der vertikale, zweispitzige Pfeil ermöglicht es den Projekten, gleichzeitig Chancen- und Risikoanalysen sowie eine kontinuierliche prozessbegleitende Validierung durchzuführen. Das Vee-Modell umfasst die ersten drei Lebenszyklusphasen, die in der Tabelle „Generic Life Cycle Stages“ des INCOSE Systems Engineering Handbook aufgeführt sind: explorative Forschung, Konzept und Entwicklung (INCOSE 2012).

Abbildung 1. Linke Seite des sequenziellen Vee-Modells (Forsberg, Mooz, und Cotterman 2005). Nachdruck mit Genehmigung von John Wiley & Sons Inc. Alle anderen Rechte sind dem Urheber vorbehalten.

Das Vee-Modell unterstützt die INCOSE Systems Engineering Handbook (INCOSE 2012) Definition der Lebenszyklusstadien und ihrer Zwecke oder Aktivitäten, wie in Abbildung 2 unten dargestellt.

Abbildung 2. Ein Beispiel für Phasen, ihre Zwecke und wichtige Entscheidungspunkte. (SEBoK Original)

Das INCOSE Systems Engineering Handbook 3.2.2 enthält eine detailliertere Version des Vee-Diagramms (2012, Abbildungen 3-4, S. 27), die Lebenszyklusaktivitäten in das allgemeinere Vee-Modell einbezieht. Ein ähnliches Diagramm, das an der U.S. Defense Acquisition University (DAU) entwickelt wurde, ist in Abbildung 3 unten zu sehen.

Abbildung 3. Das Vee-Aktivitätsdiagramm (Prosnik 2010). Herausgegeben von der Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Anwendung des Vee-Modells

Lawson (Lawson 2010) geht auf die Aktivitäten in den einzelnen Lebenszyklusstadien ein und stellt fest, dass es sinnvoll ist, die Struktur eines generischen Lebenszyklusstadienmodells für jede Art von System-of-Interest (SoI) zu betrachten, wie in Abbildung 4 dargestellt. Dieses (T)-Modell zeigt, dass eine oder mehrere Definitionsphasen einer oder mehreren Produktionsphasen vorausgehen, in denen die Implementierung (Beschaffung, Bereitstellung oder Entwicklung) von zwei oder mehreren Systemelementen abgeschlossen ist.

Abbildung 4. Generische (T) Stufenstruktur von Systemlebenszyklusmodellen (Lawson 2010). Nachdruck mit Genehmigung von Harold Lawson. Alle anderen Rechte sind dem Urheber vorbehalten.

Abbildung 5 zeigt die generischen Lebenszyklusphasen für eine Vielzahl von Interessengruppen, von einer Normungsorganisation (ISO/IEC) bis hin zu kommerziellen und staatlichen Organisationen. Obwohl sich diese Phasen im Detail unterscheiden, haben sie alle ein ähnliches sequenzielles Format, das die Kernaktivitäten wie in Abbildung 2 (Definition, Produktion und Nutzung/Abschaltung) betont.

Abbildung 5. Vergleiche von Lebenszyklusmodellen (Forsberg, Mooz und Cotterman 2005). Nachdruck mit Genehmigung von John Wiley & Sons. Alle anderen Rechte sind dem Urheber vorbehalten.

Es ist wichtig zu beachten, dass viele der Aktivitäten während des Lebenszyklus iteriert werden. Dies ist ein Beispiel für die Rekursion (Glossar)

Grundlagen der Lebenszyklusstadien und der Programm-Management-Phase

Für diese Diskussion ist es wichtig zu wissen, dass:

• Der Begriff „Stadium“ bezieht sich auf die verschiedenen Zustände eines Systems während seines Lebenszyklus; einige Stadien können sich zeitlich überschneiden, wie z.B. das Nutzungsstadium und das Support-Stadium. Der Begriff „stage“ wird in ISO/IEC/IEEE 15288 verwendet.

• Der Begriff „phase“ bezieht sich auf die verschiedenen Schritte des Programms, die das Leben des Systems unterstützen und verwalten; die Phasen überschneiden sich normalerweise nicht. Der Begriff „Phase“ wird in vielen etablierten Modellen als Äquivalent zum Begriff „Stadium“ verwendet.

ProgrammmanagementProgrammmanagement verwendet Phasen, Meilensteine und EntscheidungsgatterEntscheidungsgatter, die dazu dienen, die Entwicklung eines Systems durch seine verschiedenen Stadien zu bewerten. Die Phasen enthalten die Aktivitäten, die zur Erreichung der Ziele durchgeführt werden, und dienen der Steuerung und Verwaltung der Abfolge der Phasen und der Übergänge zwischen den einzelnen Phasen. Für jedes Projekt ist es wichtig, die Begriffe und die damit verbundenen Definitionen, die in den jeweiligen Projekten verwendet werden, zu definieren und zu veröffentlichen, um Verwirrung zu vermeiden.

Ein typisches Programm besteht aus den folgenden Phasen:

• Die Vorstudienphase, in der potenzielle Möglichkeiten identifiziert werden, um Benutzerbedürfnisse mit neuen Lösungen zu erfüllen, die geschäftlich sinnvoll sind.
• Die Durchführbarkeitsphase besteht aus der Untersuchung der Durchführbarkeit alternativer Konzepte, um ein zweites Entscheidungs-Gate zu erreichen, bevor die Ausführungsphase eingeleitet wird. In der Machbarkeitsphase werden die Anforderungen der Stakeholder und die Systemanforderungen ermittelt, praktikable Lösungen werden identifiziert und untersucht, und es können virtuelle Prototypen (Glossar)Prototypen (Glossar) implementiert werden. In dieser Phase hängt die Entscheidung über das weitere Vorgehen davon ab:
  • ob ein Konzept realisierbar ist und als geeignet erachtet wird, einer identifizierten Bedrohung entgegenzuwirken oder eine Chance zu nutzen;
  • ob ein Konzept ausreichend ausgereift ist, um die weitere Entwicklung eines neuen Produkts oder einer Produktlinie zu rechtfertigen; und
  • ob ein auf eine Ausschreibung hin erstellter Vorschlag genehmigt werden soll.
• Die Ausführungsphase umfasst Aktivitäten im Zusammenhang mit den vier Phasen des Systemlebenszyklus: Entwicklung, Produktion, Nutzung und Unterstützung. In der Regel gibt es zwei Entscheidungspunkte und zwei Meilensteine, die mit den Ausführungsaktivitäten verbunden sind. Der erste Meilenstein bietet dem Management die Möglichkeit, die Ausführungspläne zu überprüfen, bevor es grünes Licht gibt. Der zweite Meilenstein bietet die Möglichkeit, den Fortschritt zu überprüfen, bevor die Entscheidung getroffen wird, die Produktion zu starten. Die Entscheidungspunkte während der Ausführung können genutzt werden, um zu entscheiden, ob die entwickelte SoI produziert werden soll und ob sie verbessert oder ausgemustert werden soll.

Diese Ansichten des Programmmanagements gelten nicht nur für die SoI, sondern auch für ihre Elemente und Struktur.

Lebenszyklusphasen

Variationen des Vee-Modells befassen sich mit denselben allgemeinen Phasen eines Lebenszyklus:

• Neue Projekte beginnen in der Regel mit einer explorativen Forschungsphase, die im Allgemeinen die Aktivitäten der Konzeptdefinition umfasst, insbesondere die Themen Geschäfts- oder Aufgabenanalyse und das Verständnis der Bedürfnisse und Anforderungen der Beteiligten. Diese reifen, während das Projekt von der Sondierungsphase über die Konzeptphase zur Entwicklungsphase übergeht.
• Die Produktionsphase umfasst die Aktivitäten der Systemdefinition und der Systemrealisierung sowie die Entwicklung der Systemanforderungen (Glossar)Anforderungen (Glossar) und der Architektur (Glossar)Architektur (Glossar) bis hin zur Verifikation und Validierung.
• Die Nutzungsphase umfasst die Aktivitäten der Systembereitstellung und des Systembetriebs.
• Die Unterstützungsphase umfasst die Aktivitäten der Systemwartung, der Logistik und des Produkt- und Lebensdauermanagements, zu denen Aktivitäten wie die Verlängerung der Lebensdauer oder die Aktualisierung von Fähigkeiten, Upgrades und Modernisierungen gehören können.
• Die Ausmusterungsphase umfasst die Aktivitäten der Entsorgung und der Ausmusterung, obwohl in einigen Modellen Aktivitäten wie die Verlängerung der Nutzungsdauer oder die Aktualisierung, Aufrüstung und Modernisierung von Fähigkeiten in der Ausmusterungsphase zusammengefasst werden.

Weitere Informationen zu jeder dieser Phasen finden Sie in den folgenden Abschnitten (siehe Links zu zusätzlichen Artikeln in Teil 3 oben für weitere Einzelheiten). Es ist wichtig anzumerken, dass diese Lebenszyklusphasen und die Aktivitäten in jeder Phase durch eine Reihe von Systems-Engineering-Management-Prozessen unterstützt werden.

Erkundungsphase

Die Analyse und Vereinbarung von Benutzeranforderungen ist Teil der Erkundungsphase und ist für die Entwicklung erfolgreicher Systeme entscheidend. Ohne ein angemessenes Verständnis der Benutzerbedürfnisse läuft jedes System Gefahr, zur Lösung der falschen Probleme entwickelt zu werden. Der erste Schritt in der Sondierungsphase besteht darin, die Anforderungen und Einschränkungen der Benutzer (und der Interessenvertreter) zu definieren. Ein wichtiger Teil dieses Prozesses besteht darin, die Machbarkeit der Erfüllung der Benutzeranforderungen zu ermitteln, einschließlich der Bewertung der technologischen Bereitschaft. Wie bei vielen SE-Aktivitäten erfolgt dies oft iterativ, und die Bedürfnisse und Anforderungen der Interessengruppen werden erneut geprüft, wenn neue Informationen verfügbar werden.

Eine aktuelle Studie des National Research Council (National Research Council 2008) konzentrierte sich auf die Verkürzung der Entwicklungszeit für Projekte der US Air Force. In dem Bericht heißt es: „Vereinfacht ausgedrückt, ist Systems Engineering die Umsetzung der Bedürfnisse eines Benutzers in eine Definition eines Systems und seiner Architektur durch einen iterativen Prozess, der zu einem effektiven Systemdesign führt.“ Die iterative Einbindung der Stakeholder ist entscheidend für den Projekterfolg.

Abgesehen von den ersten und letzten Entscheidungsgates eines Projekts werden die Gates gleichzeitig durchgeführt. Siehe Abbildung 6 unten.

Abbildung 6. Zeitplanung der Entwicklungsphasen. (SEBoK Original)

Konzeptphase

In der Konzeptphase werden alternative Konzepte erstellt, um den besten Ansatz zur Erfüllung der Bedürfnisse der Beteiligten zu ermitteln. Durch die Vorstellung von Alternativen und die Erstellung von Modellen, einschließlich geeigneter Prototypen, werden die Bedürfnisse der Interessengruppen geklärt und die wichtigsten Probleme herausgestellt. Dies kann zu einem schrittweisen oder evolutionären Ansatz bei der Systementwicklung führen. Mehrere verschiedene Konzepte können parallel untersucht werden.

Entwicklungsphase

Die in der Konzeptphase ermittelten ausgewählten Konzepte werden bis auf die unterste Ebene detailliert ausgearbeitet, um eine Lösung zu schaffen, die den Anforderungen der Interessengruppen entspricht. In dieser Phase ist es von entscheidender Bedeutung, die Nutzer durch prozessbegleitende Validierung einzubeziehen (der Pfeil nach oben in den Vee-Modellen). Bei Hardware geschieht dies durch häufige Programmüberprüfungen und einen oder mehrere Vertreter des Kunden (falls erforderlich). In der agilen Entwicklung ist es üblich, den Kundenvertreter in das Entwicklungsteam zu integrieren.

Produktionsphase

In der Produktionsphase wird die SoI gebaut oder hergestellt. Produktmodifikationen können erforderlich sein, um Produktionsprobleme zu beheben, die Produktionskosten zu senken oder die Produkt- oder SoI-Fähigkeiten zu verbessern. Jede dieser Änderungen kann sich auf die Systemanforderungen auswirken und eine Requalifizierung, Reverifizierung, Revalidierung oder Validierung des Systems erfordern. Alle derartigen Änderungen erfordern eine SE-Bewertung, bevor die Änderungen genehmigt werden.

Nutzungsphase

Ein wichtiger Aspekt des Produktlebenszyklusmanagements ist die Bereitstellung von unterstützenden Systemen, die für die Aufrechterhaltung des Betriebs des Produkts unerlässlich sind. Während das gelieferte Produkt oder die Dienstleistung als das enge System von Interesse (NSOI) für einen Erwerber angesehen werden kann, muss der Erwerber auch die unterstützenden Systeme in ein breiteres System von Interesse (WSOI) einbeziehen. Diese unterstützenden Systeme sollten als System-Assets betrachtet werden, die bei Bedarf als Reaktion auf eine Situation aktiviert werden, die sich in Bezug auf den Betrieb des NSOI ergeben hat. Der Sammelbegriff für die Gesamtheit der unterstützenden Systeme ist das integrierte Logistikunterstützungssystem (ILS).

Bei der Definition, der Herstellung und dem Betrieb von Systemprodukten und -diensten ist eine ganzheitliche Sichtweise unerlässlich. In Abbildung 7 ist die Beziehung zwischen Systemdesign und -entwicklung und den ILS-Anforderungen dargestellt.

Abbildung 7. Beziehung zwischen ILS und dem Systemlebenszyklus (Eichmueller und Foreman 2009). Nachdruck mit Genehmigung des ASD/AIA S3000L Steering Committee. Alle weiteren Rechte sind dem Urheber vorbehalten.

Treibende Faktoren sind die Anforderungen an die Zuverlässigkeit, die sich aus der Notwendigkeit der Wartbarkeit und Testbarkeit ergeben.

Support Stage

In der Support Stage werden der SoI Dienste zur Verfügung gestellt, die den weiteren Betrieb ermöglichen. Es können Änderungen vorgeschlagen werden, um Probleme mit der Unterstützungsfähigkeit zu beheben, die Betriebskosten zu senken oder die Lebensdauer eines Systems zu verlängern. Diese Änderungen erfordern eine SE-Bewertung, um einen Verlust der Systemfähigkeiten während des Betriebs zu vermeiden. Der entsprechende technische Prozess ist der Wartungsprozess.

Auslaufphase

In der Auslaufphase werden die SoI und die zugehörigen Dienste aus dem Betrieb genommen. Die SE-Aktivitäten in dieser Phase konzentrieren sich in erster Linie darauf, sicherzustellen, dass die Entsorgungsanforderungen erfüllt werden. Tatsächlich ist die Planung der Entsorgung Teil der Systemdefinition in der Konzeptphase. Die Erfahrungen des 20. Jahrhunderts haben wiederholt gezeigt, welche Folgen es hat, wenn die Ausmusterung und Entsorgung von Systemen nicht von Anfang an berücksichtigt wird. Zu Beginn des 21. Jahrhunderts haben viele Länder ihre Gesetze dahingehend geändert, dass der Ersteller einer SoI für die ordnungsgemäße Entsorgung des Systems am Ende seiner Lebensdauer verantwortlich gemacht wird.

Life Cycle Reviews

Um den Fortschritt eines Projekts zu kontrollieren, sind verschiedene Arten von Reviews vorgesehen. Die am häufigsten verwendeten sind im Folgenden aufgeführt, obwohl die Namen nicht allgemeingültig sind:

• Die System Requirements Review (SRR) ist geplant, um die Systemanforderungen zu verifizieren und zu validieren, bevor mit dem detaillierten Design begonnen wird.
• Die vorläufige EntwurfsprüfungDie vorläufige Entwurfsprüfung (PDR) dient der Verifizierung und Validierung der Systemanforderungen, der Entwurfsartefakte und der Rechtfertigungselemente am Ende der ersten Entwicklungsschleife (auch als „Design-to“-Gate bezeichnet).
• Die kritische EntwurfsüberprüfungDie kritische Entwurfsüberprüfung (CDR) ist geplant, um die Systemanforderungen, die Entwurfsartefakte und die Begründungselemente am Ende der letzten Entwicklungsschleife zu verifizieren und zu validieren (die „Build-to“- und „Code-to“-Entwürfe werden nach dieser Überprüfung freigegeben).
• Die Integrationsintegrations-, Verifikations-, Verifizierungs- und ValidierungsüberprüfungenDie Validierungsüberprüfungen werden geplant, wenn die Komponenten zu Teilsystemen und Elementen auf höherer Ebene zusammengefügt werden. Es wird eine Abfolge von Überprüfungen durchgeführt, um sicherzustellen, dass alles ordnungsgemäß integriert ist und dass es einen objektiven Nachweis gibt, dass alle Anforderungen erfüllt wurden. Es sollte auch eine prozessbegleitende Validierung stattfinden, um sicherzustellen, dass das System in seiner Entwicklung die Anforderungen der Beteiligten erfüllt (siehe Abbildung 7).
• Die abschließende Validierungsprüfung wird am Ende der Integrationsphase durchgeführt.
• Auf der Grundlage der Art des Systems und der damit verbundenen Risiken können weitere managementbezogene Prüfungen geplant und durchgeführt werden, um den korrekten Arbeitsfortschritt zu kontrollieren.

Abbildung 8. Rechte Seite des Vee-Modells (Forsberg, Mooz, und Cotterman 2005). Nachdruck mit Genehmigung von John Wiley & Sons Inc. Alle anderen Rechte sind dem Urheber vorbehalten.

Zitierte Werke

Eichmueller, P. und B. Foreman. 2010. S3000LTM. Brussels, Belgium: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy’Com.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management, 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 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, Kings College, UK.

Primäre Referenzen

Beedle, M., et al. 2009. „The Agile Manifesto: Principles behind the Agile Manifesto“. in The Agile Manifesto . Accessed December 04 2014 at www.agilemanifesto.org/principles.html

Boehm, B. and R. Turner. 2004. Balancing Agility and Discipline. New York, NY, USA: Addison-Wesley.

Fairley, R. 2009. Managing and Leading Software Projects. New York, NY, USA: J. Wiley & Sons.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizing Project Management. 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 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. Kings College, UK: College Publications.

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.

Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, USA: Addison Wesley.

Weitere Literatur

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

Baldwin, C. und K. Clark. 2000. Design Rules: The Power of Modularity. Cambridge, MA, USA: MIT Press.

Beck, K. 1999. Extreme Programming Explained. New York, NY, USA: Addison Wesley.

Beedle, M., et al. 2009. „The Agile Manifesto: Principles behind the Agile Manifesto“. in The Agile Manifesto . Abgerufen 2010. Verfügbar unter: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, USA: Springer.

Boehm, B. 1988. „A Spiral Model of Software Development.“ IEEE Computer 21(5): 61-72.

Boehm, B. 2006. „Einige zukünftige Trends und Implikationen für System- und Software-Engineering-Prozesse.“ Systems Engineering. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. „Using the WinWin Spiral Model: A Case Study.“ IEEE Computer. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). Embracing the Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. „Top Five Quality Software Projects“. CrossTalk. 17(7) (Juli 2004): 4-19. Verfügbar unter: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Systems Thinking, Systems Practice. New York, NY, USA: Wiley.

Crosson, S. und B. Boehm. 2009. „Adjusting Software Life Cycle Anchorpoints: Lessons Learned in a System of Systems Context.“ Proceedings of the Systems and Software Technology Conference, 20-23 April 2009, Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. and N. Moe (eds.). 2010. „Agile Software Development: Current Research and Future Directions.“ Kapitel in B. Boehm, J. Lane, S. Koolmanjwong, and R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.

Dorner, D. 1996. The Logic of Failure. New York, NY, USA: Basic Books.

Forsberg, K. 1995. „‚If I Could Do That, Then I Could…‘ System Engineering in a Research and Development Environment.“ Proceedings of the Fifth Annual International Council on Systems Engineering (INCOSE) International Symposium. 22-26 July 1995. St. Louis, MO, USA.

Forsberg, K. 2010. „Projects Don’t Begin With Requirements.“ Proceedings of the IEEE Systems Conference, 5-8 April 2010, San Diego, CA, USA.

Gilb, T. 2005. Competitive Engineering. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.

Goldratt, E. 1984. The Goal. Great Barrington, MA, USA: North River Press.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. New York, NY, USA: Wiley.

Holland, J. 1998. Emergence. New York, NY, USA: Perseus Books.

ISO/IEC. 2010. Systems and Software Engineering, Part 1: Guide for Life Cycle Management. Genf, Schweiz: Internationale Organisation für Normung (ISO)/Internationale Elektrotechnische Kommission (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Systems and Software Engineering — System Life Cycle Processes. Genf, Schweiz: Internationale Organisation für Normung / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.

ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: Internationale Organisation für Normung (ISO)/Internationale Elektrotechnische Kommission (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. „Top Five Quality Software Projects.“ CrossTalk. 16(7) (Juli 2003): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. The Rational Unified Process. New York, NY, USA: Addison Wesley.

Landis, T. R. 2010. Lockheed Blackbird Family (A-12, YF-12, D-21/M-21 & SR-71). North Branch, MN, USA: Specialty Press.

Madachy, R. 2008. Software Process Dynamics. Hoboken, NJ, USA: Wiley.

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. „Architektur-Reviews: Praxis und Erfahrung.“ IEEE Software. 22(2): 34-43.

National Research Council of the National Academies (USA). 2008. Pre-Milestone A and Early-Phase Systems Engineering. Washington, DC, USA: The National Academies Press.

Osterweil, L. 1987. „Software Processes are Software Too.“ Proceedings of the SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

Poppendeick, M. und T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, USA: Addison Wesley.

Rechtin, E. 1991. System Architecting: Creating and Building Complex Systems. Upper Saddle River, NY, USA: Prentice-Hall.

Rechtin, E., und M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, USA: CRC Press.

Schwaber, K. und M. Beedle. 2002. Agile Softwareentwicklung mit Scrum. Upper Saddle River, NY, USA: Prentice Hall.

Spruill, N. 2002. „Top Five Quality Software Projects.“ CrossTalk. 15(1) (Januar 2002): 4-19. Available at: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

Stauder, T. 2005. „Top Five Department of Defense Program Awards.“ CrossTalk. 18(9) (September 2005): 4-13. Verfügbar unter http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Societal Systems: Planning, Policy, and Complexity. New York, NY, USA: Wiley.

Womack, J. und D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.

Relevante Videos=

• Grundlegende Einführung in Systems Engineering (V-Methode)
• Grundlegende Einführung in Systems Engineering (V-Methode) Teil 2 von 2