Lead Authors: Dick Fairley, Kevin Forsberg, bijdragende auteur: Ray Madachy
Er zijn een groot aantal life cycle procesmodellen. Zoals besproken in het artikel “System Life Cycle Process Drivers and Choices”, vallen deze modellen in drie hoofdcategorieën uiteen: (1) voornamelijk vooraf gespecificeerde en sequentiële processen; (2) voornamelijk evolutionaire en gelijktijdige processen (bijv. het rationele verenigde proces en verschillende vormen van het Vee- en spiraalmodel); en (3) voornamelijk interpersoonlijke en ongedwongen processen (bijv. agile ontwikkeling, Scrum, extreem programmeren (XP), de dynamische systeemontwikkelingsmethode, en op innovatie gebaseerde processen).
Dit artikel richt zich specifiek op het Vee-model als het primaire voorbeeld van vooraf gespecificeerde en sequentiële processen. Bij deze bespreking is het van belang op te merken dat het Vee-model, en variaties daarop, alle betrekking hebben op dezelfde basisset van systems engineering (SE) activiteiten. Het belangrijkste verschil tussen deze modellen is de manier waarop zij de voornoemde SE activiteiten groeperen en weergeven.
Algemene implicaties van het gebruik van het Vee-model voor systeemontwerp en -ontwikkeling worden hieronder besproken; voor een meer specifiek begrip van de wijze waarop dit levenscyclusmodel van invloed is op de activiteiten van systems engineering, zie de andere kennisgebieden (KA’s) in Deel 3.
- Een primair vooraf gespecificeerd en sequentieel procesmodel: Het Vee Model
- Toepassing van het Vee-model
- Fundamenten van levenscyclusfasen en programmabeheerfase
- Life Cycle Stages
- Exploratory Research Stage
- Conceptfase
- Ontwikkelingsfase
- Productiefase
- Gebruiksfase
- Ondersteuningsfase
- Terugtrekkingsfase
- Life Cycle Reviews
- Works Cited
- Primary References
- Aanvullende Referenties
- Relevante Video’s=
Een primair vooraf gespecificeerd en sequentieel procesmodel: Het Vee Model
De sequentiële versie van het Vee Model is weergegeven in Figuur 1. De kern bestaat uit een opeenvolging van plannen, specificaties, en producten die worden gebaseerd en onder configuratiebeheer worden geplaatst. De verticale, tweekoppige pijl stelt projecten in staat om gelijktijdig kansen- en risicoanalyses uit te voeren, alsmede continue in-proces validatie. Het Vee-model omvat de eerste drie fasen van de levenscyclus die zijn opgenomen in de tabel “Generic Life Cycle Stages” van het INCOSE Systems Engineering Handbook: verkennend onderzoek, concept en ontwikkeling (INCOSE 2012).
Het Vee Model onderschrijft de INCOSE Systems Engineering Handbook (INCOSE 2012) definitie van levenscyclusfasen en hun doelen of activiteiten, zoals weergegeven in figuur 2 hieronder.
Het INCOSE Systems Engineering Handbook 3.2.2 bevat een meer gedetailleerde versie van het Vee-diagram (2012, figuren 3-4, blz. 27), waarin levenscyclusactiviteiten zijn opgenomen in het meer generieke Vee-model. Een soortgelijk diagram, ontwikkeld aan de Amerikaanse Defense Acquisition University (DAU), is te zien in figuur 3 hieronder.
Toepassing van het Vee-model
Lawson (Lawson 2010) gaat dieper in op de activiteiten in elke levenscyclusfase en merkt op dat het nuttig is om de structuur van een generiek levenscyclusfasenmodel voor elk type systeem-van-belang (SoI) te overwegen, zoals afgebeeld in figuur 4. Dit (T)-model geeft aan dat een of meer definitiefasen voorafgaan aan een of meer productiefase(n) waarin de implementatie (verwerving, terbeschikkingstelling of ontwikkeling) van twee of meer systeemelementen is verwezenlijkt.
Figuur 5 toont de generieke levenscyclusfasen voor een verscheidenheid aan belanghebbenden, van een normalisatieorganisatie (ISO/IEC) tot commerciële en overheidsorganisaties. Hoewel deze stadia in detail verschillen, hebben ze allemaal een vergelijkbaar sequentieel formaat dat de nadruk legt op de kernactiviteiten zoals die in figuur 2 zijn aangegeven (definitie, productie en gebruik/terugtrekking).
Het is belangrijk op te merken dat veel van de activiteiten gedurende de levenscyclus iteratief zijn. Dit is een voorbeeld van recursie (verklarende woordenlijst)recursie (verklarende woordenlijst)zoals besproken in de Inleiding van Deel 3.
Fundamenten van levenscyclusfasen en programmabeheerfase
Voor deze discussie is het belangrijk op te merken dat:
- De term fase verwijst naar de verschillende toestanden van een systeem tijdens zijn levenscyclus; sommige fasen kunnen elkaar in de tijd overlappen, zoals het gebruiksstadium en het ondersteuningsstadium. De term “fase” wordt gebruikt in ISO/IEC/IEEE 15288.
- De term fase heeft betrekking op de verschillende stappen van het programma dat de levensduur van het systeem ondersteunt en beheert; de fasen overlappen elkaar gewoonlijk niet. De term “fase” wordt in veel gevestigde modellen gebruikt als equivalent van de term “fase.”
ProgrammabeheerProgrammabeheer maakt gebruik van fasen, mijlpalenmilestones en beslissingspoortenbeslissingspoorten die worden gebruikt om de evolutie van een systeem door de verschillende fasen te beoordelen. De fasen bevatten de activiteiten die worden uitgevoerd om de doelstellingen te bereiken en dienen om de opeenvolging van fasen en de overgangen tussen elke fase te controleren en te beheren. Voor elk project is het van essentieel belang om de termen en bijbehorende definities die in de respectieve projecten worden gebruikt, te definiëren en te publiceren om verwarring te minimaliseren.
Een typisch programma bestaat uit de volgende fasen:
- De voorstudiefase, waarin potentiële mogelijkheden worden geïdentificeerd om in de behoeften van gebruikers te voorzien met nieuwe oplossingen die zakelijk zinvol zijn.
- De haalbaarheidsfase bestaat uit het bestuderen van de haalbaarheid van alternatieve concepten om een tweede beslissingspoort te bereiken voordat de uitvoeringsfase wordt gestart. Tijdens de haalbaarheidsfase, worden de vereisten van belanghebbenden en systeemvereisten geïdentificeerd, levensvatbare oplossingen worden geïdentificeerd en bestudeerd, en virtuele prototypen (verklarende woordenlijst) prototypen (verklarende woordenlijst) kunnen worden uitgevoerd. Tijdens deze fase wordt het besluit om verder te gaan gebaseerd op:
- of een concept haalbaar is en in staat wordt geacht om een geïdentificeerde bedreiging tegen te gaan of een kans te benutten;
- of een concept voldoende is uitgerijpt om de verdere ontwikkeling van een nieuw product of een productlijn te rechtvaardigen; en
- of een voorstel moet worden goedgekeurd dat is gegenereerd in reactie op een verzoek om een voorstel.
- De uitvoeringsfase omvat activiteiten met betrekking tot vier fasen van de levenscyclus van het systeem: ontwikkeling, productie, gebruik, en ondersteuning. Typisch, zijn er twee besluit gates en twee mijlpalen verbonden aan uitvoeringsactiviteiten. De eerste mijlpaal biedt het management de gelegenheid om de plannen voor de uitvoering te beoordelen alvorens het groene licht te geven. De tweede mijlpaal biedt de mogelijkheid om de voortgang te beoordelen voordat de beslissing wordt genomen om de productie te starten. De beslissingspoorten tijdens de uitvoering kunnen worden gebruikt om te bepalen of de ontwikkelde SoI moet worden geproduceerd en of deze moet worden verbeterd of buiten gebruik moet worden gesteld.
Deze programmabeheerstandpunten zijn niet alleen van toepassing op de SoI, maar ook op de elementen en de structuur ervan.
Life Cycle Stages
Variaties van het Vee-model behandelen dezelfde algemene stadia van een levenscyclus:
- Nieuwe projecten beginnen gewoonlijk met een verkennende onderzoeksfase die over het algemeen de activiteiten van conceptdefinitie omvat, specifiek de onderwerpen van bedrijfs- of missie-analyse en het begrip van de behoeften en vereisten van de belanghebbenden. Deze rijpen naarmate het project van de verkennende fase naar de conceptfase naar de ontwikkelingsfase gaat.
- De productiefase omvat de activiteiten van systeemdefinitie en systeemrealisatie, evenals de ontwikkeling van de systeemvereisten (verklarende woordenlijst)vereisten (verklarende woordenlijst)en architectuur (verklarende woordenlijst)architectuur (verklarende woordenlijst) door verificatie en validatie.
- De gebruiksfase omvat de activiteiten van systeeminzet en systeemgebruik.
- De ondersteuningsfase omvat de activiteiten van systeemonderhoud, logistiek, en product- en levensduurbeheer, die activiteiten kunnen omvatten zoals levensduurverlenging of capaciteitsupdates, upgrades, en modernisering.
- De buitengebruikstellingsfase omvat de activiteiten van verwijdering en buitengebruikstelling, hoewel in sommige modellen activiteiten zoals levensduurverlenging of capaciteitsupdates, upgrades en modernisering worden gegroepeerd in de “buitengebruikstellingsfase”.
Aanvullende informatie over elk van deze fasen is te vinden in de onderstaande secties (zie de links naar aanvullende artikelen in deel 3 hierboven voor meer details). Het is belangrijk op te merken dat deze levenscyclusfasen, en de activiteiten in elke fase, worden ondersteund door een set van systems engineering management processen.
Exploratory Research Stage
User requirements analysis and agreement is onderdeel van de exploratory research stage en is van cruciaal belang voor de ontwikkeling van succesvolle systemen. Zonder een goed begrip van de gebruikersbehoeften loopt elk systeem het risico te worden gebouwd om de verkeerde problemen op te lossen. De eerste stap in de verkennende onderzoeksfase is het bepalen van de eisen en beperkingen van de gebruiker (en de belanghebbenden). Een belangrijk onderdeel van dit proces is het vaststellen van de haalbaarheid van het voldoen aan de gebruikerseisen, inclusief de beoordeling van de technologiegereedheid. Zoals bij veel SE activiteiten wordt dit vaak iteratief gedaan, en worden de behoeften en eisen van de stakeholders opnieuw bekeken als nieuwe informatie beschikbaar komt.
Een recente studie van de National Research Council (National Research Council 2008) richtte zich op het verkorten van de ontwikkelingstijd voor projecten van de Amerikaanse luchtmacht. Het rapport merkt op dat, “eenvoudig gezegd, systems engineering de vertaling is van de behoeften van een gebruiker in een definitie van een systeem en de architectuur ervan via een iteratief proces dat resulteert in een effectief systeemontwerp.” De iteratieve betrokkenheid van belanghebbenden is van cruciaal belang voor het projectsucces.
Met uitzondering van de eerste en laatste beslissingspoorten van een project, worden de poorten gelijktijdig uitgevoerd. Zie figuur 6 hieronder.
Conceptfase
Tijdens de conceptfase worden alternatieve concepten gecreëerd om te bepalen wat de beste aanpak is om aan de behoeften van de belanghebbenden te voldoen. Door alternatieven voor te stellen en modellen te creëren, met inbegrip van geschikte prototypen, worden de behoeften van de belanghebbenden verduidelijkt en de drijvende kwesties belicht. Dit kan leiden tot een incrementele of evolutionaire aanpak van de systeemontwikkeling. Verschillende concepten kunnen parallel worden onderzocht.
Ontwikkelingsfase
Het (de) in de conceptfase geselecteerde concept(en) wordt (worden) in detail uitgewerkt tot op het laagste niveau om de oplossing te produceren die voldoet aan de eisen van de stakeholders. Gedurende dit stadium is het van vitaal belang om de betrokkenheid van de gebruiker voort te zetten door middel van in-proces validatie (de opwaartse pijl op de Vee modellen). Op hardware, wordt dit gedaan met frequente programma-evaluaties en een vertegenwoordiger(s) van de klant ter plaatse (indien van toepassing). Bij agile ontwikkeling is het gebruikelijk dat de vertegenwoordiger van de klant in het ontwikkelingsteam wordt geïntegreerd.
Productiefase
De productiefase is de fase waarin de SoI wordt gebouwd of vervaardigd. Productwijzigingen kunnen nodig zijn om productieproblemen op te lossen, om de productiekosten te verlagen, of om de product- of SoI-mogelijkheden te verbeteren. Elk van deze wijzigingen kan van invloed zijn op de systeemvereisten en kan een herkwalificatie van het systeem, een herkwalificatieverificatie of een herkwalificatieverificatie vereisen. Al deze wijzigingen vereisen een SE-beoordeling voordat ze worden goedgekeurd.
Gebruiksfase
Een belangrijk aspect van productlevenscyclusbeheer is de levering van ondersteunende systemen die van vitaal belang zijn voor de instandhouding van de werking van het product. Terwijl het geleverde product of de dienst kan worden gezien als het smalle systeem van belang (NSOI) voor een verwerveracquirer, moet de verwerver ook de ondersteunende systemen in een breder systeem van belang (WSOI) opnemen. Deze ondersteunende systemen moeten worden gezien als systeemactiva die, wanneer nodig, worden geactiveerd in antwoord op een situatie die is ontstaan met betrekking tot de werking van de NSOI. De collectieve naam voor het geheel van ondersteunende systemen is het geïntegreerde logistieke ondersteuningssysteem (ILS).
Het is van vitaal belang een holistische visie te hebben bij het definiëren, produceren en exploiteren van systeemproducten en -diensten. In figuur 7 wordt de relatie tussen systeemontwerp en -ontwikkeling en de ILS-eisen weergegeven.
De eisen aan betrouwbaarheid, resulterend in de behoefte aan onderhoudbaarheid en testbaarheid, zijn drijvende factoren.
Ondersteuningsfase
In de ondersteuningsfase worden aan de SoI diensten verleend die voortzetting van de werking mogelijk maken. Wijzigingen kunnen worden voorgesteld om problemen met de ondersteunbaarheid op te lossen, om de operationele kosten te verlagen, of om de levensduur van een systeem te verlengen. Deze wijzigingen vereisen een SE-beoordeling om verlies van systeemcapaciteiten tijdens de exploitatie te voorkomen. Het overeenkomstige technische proces is het onderhoudsproces.
Terugtrekkingsfase
In de terugtrekkingsfase worden de SoI en de daarmee samenhangende diensten buiten gebruik gesteld. De SE-activiteiten in deze fase zijn er in de eerste plaats op gericht ervoor te zorgen dat aan de verwijderingseisen wordt voldaan. In feite maakt de planning van de verwijdering deel uit van de systeemdefinitie in de conceptfase. Ervaringen in de 20e eeuw hebben herhaaldelijk aangetoond wat de gevolgen zijn wanneer niet vanaf het begin rekening wordt gehouden met de buitenbedrijfstelling en verwijdering van systemen. In het begin van de 21e eeuw hebben veel landen hun wetgeving aangepast om de ontwerper van een SoI verantwoordelijk te stellen voor de juiste verwijdering van het systeem aan het einde van de levensduur.
Life Cycle Reviews
Om de voortgang van een project te controleren, worden verschillende soorten reviews gepland. De meest gebruikte zijn de volgende, hoewel de namen niet universeel zijn:
- De system requirements review (SRR) is gepland om de set van systeemeisen te verifiëren en te valideren voordat met de gedetailleerde ontwerpactiviteiten wordt begonnen.
- De voorlopige ontwerpevaluatie (preliminary design review, PDR) is gepland om de reeks systeemvereisten, de ontwerpartefacten en de motiveringselementen aan het einde van de eerste engineeringslus (ook bekend als de “design-to”-gate) te verifiëren en te valideren.
- The critical design reviewcritical design review (CDR) is planned to verify and validate the set of system requirements, the design artifacts, and justification elements at the end of the last engineering loop (the “build-to” and “code-to” designs are released after this review).
- The integrationintegration, verificationverification, and validation reviews are planned as the components are assembled into higher level subsystems and elements. Een opeenvolging van beoordelingen wordt gehouden om te verzekeren dat alles naar behoren integreert en dat er objectief bewijs is dat aan alle eisen is voldaan. Ook moet tijdens het proces worden gevalideerd dat het systeem, zoals het zich ontwikkelt, aan de eisen van de belanghebbenden zal voldoen (zie figuur 7).
- De laatste validatiebeoordeling wordt uitgevoerd aan het eind van de integratiefase.
- Overige managementgerelateerde beoordelingen kunnen worden gepland en uitgevoerd om de juiste voortgang van het werk te controleren, op basis van het type systeem en de bijbehorende risico’s.
Works Cited
Eichmueller, P. and B. Foreman. 2010. S3000LTM. Brussel, België: Aerospace and Defence Industries Association of Europe (ASD)/Aerospace Industries Association (AIA).
Faisandier, A. 2012. Systeemarchitectuur en -ontwerp. Belberaud, Frankrijk: 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, 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, Kings College, UK.
Primary References
Beedle, M., et al. 2009. “Het Agile Manifesto: Principes achter het Agile Manifesto”. in The Agile Manifesto . Accessed December 04 2014 at www.agilemanifesto.org/principles.html
Boehm, B. and R. Turner. 2004. Balanceren tussen Agility en 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, 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. Kings College, UK: College Publications.
Pew, R., and A. Mavor (eds.) 2007. Mens-Systeem Integratie in het Systeemontwikkelingsproces: Een nieuwe kijk. Washington, DC, USA: The National Academies Press.
Royce, W.E. 1998. Software Project Management: A Unified Framework. New York, NY, VS: Addison Wesley.
Aanvullende Referenties
Anderson, D. 2010. Kanban. Sequim, WA, USA: Blue Hole Press.
Baldwin, C. and K. Clark. 2000. Ontwerpregels: De kracht van modulariteit. Cambridge, MA, USA: MIT Press.
Beck, K. 1999. Extreem Programmeren Uitgelegd. New York, NY, USA: Addison Wesley.
Beedle, M., et al. 2009. “Het Agile Manifesto: Principes achter het Agile Manifesto”. in The Agile Manifesto . Accessed 2010. Beschikbaar op: 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. “Some Future Trends and Implications for Systems and Software Engineering Processes.” Systems Engineering. 9(1): 1-19.
Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “Het gebruik van het WinWin Spiraalmodel: A Case Study.” IEEE Computer. 31(7): 33-44.
Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in press). Het omarmen van het Spiraalmodel: Het creëren van succesvolle systemen met het Incremental Commitment Spiral Model. Boston, MA, USA: Addison Wesley.
Castellano, D.R. 2004. “Top Vijf Kwaliteit Software Projecten.” CrossTalk. 17(7) (juli 2004): 4-19. Beschikbaar op: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf
Checkland, P. 1981. Systeemdenken, systeempraktijk. New York, NY, VS: Wiley.
Crosson, S. en B. Boehm. 2009. “Aanpassing van de ankerpunten van de softwarelevenscyclus: 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 Ontwikkeling: Current Research and Future Directions.” Hoofdstuk 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. De logica van mislukking. 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 juli 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. Het Doel. 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, Deel 1: Gids voor Life Cycle Management. Genève, Zwitserland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.
ISO/IEC/IEEE. 2015. Systems and Software Engineering — System Life Cycle Processes. Genève, Zwitserland: Internationale Organisatie voor Standaardisatie / Internationale Elektrotechnische Commissies / 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. Genève, Zwitserland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).
Jarzombek, J. 2003. “Top Vijf Kwaliteit Software Projecten.” CrossTalk. 16(7) (juli 2003): 4-19. Beschikbaar op: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.
Kruchten, P. 1999. Het Rationele Uniforme Proces. 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. “Architectuurreviews: Practice and Experience.” 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 van de SEFM 2011: 9e Internationale Conferentie over Software Engineering. Monterey, CA, USA.
Poppendeick, M. and 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., and M. Maier. 1997. De kunst van systeemarchitectuur. Boca Raton, FL, USA: CRC Press.
Schwaber, K. en M. Beedle. 2002. Agile Software Ontwikkeling met Scrum. Upper Saddle River, NY, VS: Prentice Hall.
Spruill, N. 2002. “Top Vijf Kwaliteit Software Projecten.” CrossTalk. 15(1) (januari 2002): 4-19. Beschikbaar op: 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. Beschikbaar op http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.
Warfield, J. 1976. Maatschappelijke Systemen: Planning, Beleid, en Complexiteit. New York, NY, USA: Wiley.
Womack, J. and D. Jones. 1996. Lean Thinking. New York, NY, USA: Simon and Schuster.
Relevante Video’s=
- Basic Introduction of Systems Engineering (V-method)
- Basic Introduction to Systems Engineering (V-Method) Part 2 of 2