Modelli di processo del ciclo di vita del sistema: Vee

Autori principali: Dick Fairley, Kevin Forsberg, Contributing Author: Ray Madachy

C’è un gran numero di modelli di processo del ciclo di vita. Come discusso nell’articolo System Life Cycle Process Drivers and Choices, questi modelli rientrano in tre categorie principali: (1) principalmente processi prestabiliti e sequenziali; (2) principalmente processi evolutivi e concorrenti (per esempio, il processo razionale unificato e varie forme dei modelli Vee e a spirale); e (3) principalmente processi interpersonali e non vincolati (per esempio, sviluppo agile, Scrum, programmazione estrema (XP), il metodo di sviluppo dinamico del sistema e processi basati sull’innovazione).

Questo articolo si concentra specificamente sul modello Vee come esempio primario di processi prestabiliti e sequenziali. In questa discussione, è importante notare che il modello Vee, e le variazioni del modello Vee, affrontano tutti lo stesso set di base di attività di ingegneria dei sistemi (SE). La differenza chiave tra questi modelli è il modo in cui raggruppano e rappresentano le suddette attività SE.

Di seguito vengono discusse le implicazioni generali dell’uso del modello Vee per la progettazione e lo sviluppo dei sistemi; per una comprensione più specifica di come questo modello del ciclo di vita impatti le attività di ingegneria dei sistemi, si vedano le altre aree di conoscenza (KA) nella Parte 3.

Un modello di processo principalmente prestabilito e sequenziale: Il Modello Vee

La versione sequenziale del Modello Vee è mostrata nella Figura 1. Il suo nucleo comporta una progressione sequenziale di piani, specifiche e prodotti che sono basati e messi sotto gestione della configurazione. La freccia verticale a due punte permette ai progetti di eseguire analisi di opportunità e di rischio simultanee, così come una continua convalida in corso d’opera. Il modello Vee comprende le prime tre fasi del ciclo di vita elencate nella tabella “Generic Life Cycle Stages” dell’INCOSE Systems Engineering Handbook: ricerca esplorativa, concetto e sviluppo (INCOSE 2012).

Figura 1. Lato sinistro del modello Vee sequenziale (Forsberg, Mooz e Cotterman 2005). Ristampato con il permesso di John Wiley & Sons Inc. Tutti gli altri diritti sono riservati al proprietario del copyright.

Il modello Vee approva la definizione dell’INCOSE Systems Engineering Handbook (INCOSE 2012) delle fasi del ciclo di vita e dei loro scopi o attività, come mostrato nella seguente Figura 2.

Figura 2. Un esempio di fasi, i loro scopi e le principali porte di decisione. (SEBoK Original)

L’INCOSE Systems Engineering Handbook 3.2.2 contiene una versione più dettagliata del diagramma Vee (2012, Figure 3-4, p. 27) che incorpora le attività del ciclo di vita nel più generico modello Vee. Un diagramma simile, sviluppato alla Defense Acquisition University (DAU) degli Stati Uniti, può essere visto nella figura 3 qui sotto.

Figura 3. Il diagramma di attività Vee (Prosnik 2010). Rilasciato dalla Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).

Applicazione del modello Vee

Lawson (Lawson 2010) elabora le attività in ogni fase del ciclo di vita e nota che è utile considerare la struttura di un modello generico delle fasi del ciclo di vita per qualsiasi tipo di sistema di interesse (SoI) come rappresentato nella Figura 4. Questo modello (T) indica che una o più fasi di definizione precedono una o più fasi di produzione in cui l’implementazione (acquisizione, fornitura o sviluppo) di due o più elementi del sistema è stata realizzata.

Figura 4. Struttura generica (T) delle fasi dei modelli del ciclo di vita del sistema (Lawson 2010). Ristampato con il permesso di Harold Lawson. Tutti gli altri diritti sono riservati al proprietario del copyright.

La figura 5 mostra le fasi generiche del ciclo di vita per una varietà di attori, da un’organizzazione di standard (ISO/IEC) alle organizzazioni commerciali e governative. Anche se queste fasi differiscono in dettaglio, hanno tutte un formato sequenziale simile che enfatizza le attività principali come notato nella figura 2 (definizione, produzione e utilizzo/ritiro).

Figura 5. Comparazione dei modelli del ciclo di vita (Forsberg, Mooz e Cotterman 2005). Ristampato con il permesso di John Wiley & Sons. Tutti gli altri diritti sono riservati al proprietario del copyright.

È importante notare che molte delle attività del ciclo di vita sono iterate. Questo è un esempio di ricorsione (glossario)ricorsione (glossario) come discusso nella Parte 3 Introduzione.

Fondamenti delle fasi del ciclo di vita e della fase di gestione del programma

Per questa discussione, è importante notare che:

• Il termine stadio si riferisce ai diversi stati di un sistema durante il suo ciclo di vita; alcuni stadi possono sovrapporsi nel tempo, come lo stadio di utilizzo e lo stadio di supporto. Il termine “stadio” è usato nella ISO/IEC/IEEE 15288.

• Il termine fase si riferisce alle diverse fasi del programma che supportano e gestiscono la vita del sistema; le fasi di solito non si sovrappongono. Il termine “fase” è usato in molti modelli consolidati come equivalente al termine “stage”.

Gestione del programmaLa gestione del programma impiega fasi, milestonesmilestones, e decision gatesdecision gates che sono usati per valutare l’evoluzione di un sistema attraverso le sue varie fasi. Le fasi contengono le attività eseguite per raggiungere gli obiettivi e servono a controllare e gestire la sequenza delle fasi e le transizioni tra ogni fase. Per ogni progetto, è essenziale definire e pubblicare i termini e le relative definizioni usate nei rispettivi progetti per ridurre al minimo la confusione.

Un tipico programprogramma è composto dalle seguenti fasi:

• La fase di pre-studio, che identifica le potenziali opportunità di affrontare le esigenze degli utenti con nuove soluzioni che hanno senso per il business.
• La fase di fattibilità consiste nello studiare la fattibilità di concetti alternativi per raggiungere un secondo gate decisionale prima di iniziare la fase di esecuzione. Durante la fase di fattibilità, vengono identificati i requisiti delle parti interessate e i requisiti del sistema, vengono identificate e studiate le soluzioni fattibili e possono essere implementati prototipi virtuali (glossario). Durante questa fase, la decisione di andare avanti si basa su:
  • se un concetto è fattibile ed è considerato in grado di contrastare una minaccia identificata o sfruttare un’opportunità;
  • se un concetto è sufficientemente maturo da giustificare lo sviluppo continuo di un nuovo prodotto o linea di prodotti; e
  • se approvare una proposta generata in risposta a una richiesta di proposta.
• La fase di esecuzione include attività relative a quattro fasi del ciclo di vita del sistema: sviluppo, produzione, utilizzo e supporto. Tipicamente, ci sono due cancelli di decisione e due pietre miliari associate alle attività di esecuzione. La prima pietra miliare fornisce l’opportunità alla direzione di rivedere i piani di esecuzione prima di dare il via libera. La seconda pietra miliare fornisce l’opportunità di rivedere i progressi prima che venga presa la decisione di iniziare la produzione. Le porte di decisione durante l’esecuzione possono essere usate per determinare se produrre il SoI sviluppato e se migliorarlo o ritirarlo.

Queste viste di gestione del programma si applicano non solo al SoI, ma anche ai suoi elementi e alla sua struttura.

Fasi del ciclo di vita

Variazioni del modello Vee trattano le stesse fasi generali di un ciclo di vita:

• I nuovi progetti iniziano tipicamente con una fase di ricerca esplorativa che generalmente include le attività di definizione del concetto, in particolare i temi di analisi del business o della missione e la comprensione dei bisogni e delle esigenze degli stakeholder. Questi maturano man mano che il progetto passa dalla fase esplorativa a quella di concetto a quella di sviluppo.
• La fase di produzione include le attività di definizione del sistema e di realizzazione del sistema, così come lo sviluppo dei requisiti di sistema (glossario)requisiti (glossario) e dell’architettura (glossario)architettura (glossario) attraverso la verifica e la convalida.
• La fase di utilizzo include le attività di spiegamento e funzionamento del sistema.
• La fase di supporto include le attività di manutenzione del sistema, la logistica e la gestione della vita del prodotto e del servizio, che può includere attività come l’estensione della vita del servizio o gli aggiornamenti della capacità, gli aggiornamenti e la modernizzazione.
• La fase di pensionamento include le attività di smaltimento e pensionamento, anche se in alcuni modelli, attività come l’estensione della vita utile o gli aggiornamenti delle capacità, gli aggiornamenti e la modernizzazione sono raggruppati nella fase di “pensionamento”.

Informazioni aggiuntive su ciascuna di queste fasi possono essere trovate nelle sezioni seguenti (vedi i link agli articoli aggiuntivi della Parte 3 sopra per ulteriori dettagli). È importante notare che queste fasi del ciclo di vita, e le attività in ogni fase, sono supportate da una serie di processi di gestione dell’ingegneria dei sistemi.

Fase di ricerca esplorativa

L’analisi e l’accordo sui requisiti degli utenti fa parte della fase di ricerca esplorativa ed è fondamentale per lo sviluppo di sistemi di successo. Senza un’adeguata comprensione dei bisogni degli utenti, qualsiasi sistema corre il rischio di essere costruito per risolvere i problemi sbagliati. Il primo passo nella fase di ricerca esplorativa è definire i requisiti e i vincoli dell’utente (e degli stakeholder). Una parte fondamentale di questo processo è stabilire la fattibilità di soddisfare i requisiti dell’utente, inclusa la valutazione della prontezza tecnologica. Come per molte attività di SE, questo viene spesso fatto in modo iterativo, e le esigenze e i requisiti degli stakeholder vengono rivisitati quando si rendono disponibili nuove informazioni.

Un recente studio del National Research Council (National Research Council 2008) si è concentrato sulla riduzione del tempo di sviluppo per i progetti della US Air Force. Il rapporto nota che, “in parole povere, l’ingegneria dei sistemi è la traduzione dei bisogni di un utente in una definizione di un sistema e della sua architettura attraverso un processo iterativo che si traduce in un design di sistema efficace”. Il coinvolgimento iterativo con le parti interessate è fondamentale per il successo del progetto.

Ad eccezione del primo e dell’ultimo gate decisionale di un progetto, i gate vengono eseguiti simultaneamente. Vedi la figura 6 qui sotto.

Figura 6. Programmazione delle fasi di sviluppo. (SEBoK originale)

Fase di concetto

Durante la fase di concetto, vengono creati concetti alternativi per determinare il miglior approccio per soddisfare le esigenze degli stakeholder. Immaginando alternative e creando modelli, compresi prototipi appropriati, le esigenze degli stakeholder saranno chiarite e i problemi di guida evidenziati. Questo può portare a un approccio incrementale o evolutivo allo sviluppo del sistema. Diversi concetti diversi possono essere esplorati in parallelo.

Fase di sviluppo

I concetti selezionati identificati nella fase di concetto sono elaborati in dettaglio fino al livello più basso per produrre la soluzione che soddisfa i requisiti degli stakeholder. Durante questa fase, è vitale continuare con il coinvolgimento dell’utente attraverso la validazione in-process (la freccia verso l’alto sui modelli Vee). Sull’hardware, questo viene fatto con frequenti revisioni del programma e un rappresentante del cliente residente (se appropriato). Nello sviluppo agile, la pratica è di avere il rappresentante del cliente integrato nel team di sviluppo.

Fase di produzione

La fase di produzione è dove il SoI è costruito o fabbricato. Modifiche al prodotto possono essere richieste per risolvere problemi di produzione, per ridurre i costi di produzione, o per migliorare le capacità del prodotto o del SoI. Ognuna di queste modifiche può influenzare i requisiti di sistema e può richiedere una riqualificazione del sistema, una ri-verifica o una ri-convalida. Tutte queste modifiche richiedono una valutazione SE prima che le modifiche siano approvate.

Fase di utilizzo

Un aspetto significativo della gestione del ciclo di vita del prodotto è la fornitura di sistemi di supporto che sono vitali per sostenere il funzionamento del prodotto. Mentre il prodotto o il servizio fornito può essere visto come il sistema di interesse stretto (NSOI) per un acquirente, l’acquirente deve anche incorporare i sistemi di supporto in un sistema di interesse più ampio (WSOI). Questi sistemi di supporto dovrebbero essere visti come asset di sistema che, quando necessario, vengono attivati in risposta a una situazione emersa rispetto al funzionamento dell’NSOI. Il nome collettivo per l’insieme dei sistemi di supporto è il sistema di supporto logistico integrato (ILS).

È fondamentale avere una visione olistica quando si definiscono, si producono e si fanno funzionare prodotti e servizi di sistema. Nella Figura 7, viene rappresentata la relazione tra la progettazione e lo sviluppo del sistema e i requisiti ILS.

Figura 7. Relazione tra ILS e il ciclo di vita del sistema (Eichmueller e Foreman 2009). Ristampato con il permesso del comitato direttivo ASD/AIA S3000L. Tutti gli altri diritti sono riservati al proprietario del copyright.

I requisiti di affidabilità, con conseguente necessità di manutenibilità e testabilità, sono fattori trainanti.

Fase di supporto

Nella fase di supporto, al SoI vengono forniti servizi che permettono il funzionamento continuo. Le modifiche possono essere proposte per risolvere problemi di supportabilità, per ridurre i costi operativi o per estendere la vita di un sistema. Queste modifiche richiedono una valutazione SE per evitare la perdita di capacità del sistema durante il funzionamento. Il processo tecnico corrispondente è il processo di manutenzione.

Fase di ritiro

Nella fase di ritiro, il SoI e i suoi servizi correlati vengono rimossi dal funzionamento. Le attività di SE in questa fase sono principalmente focalizzate sull’assicurare che i requisiti di smaltimento siano soddisfatti. Infatti, la pianificazione dello smaltimento fa parte della definizione del sistema durante la fase di concetto. Le esperienze del 20° secolo hanno ripetutamente dimostrato le conseguenze quando il ritiro e lo smaltimento del sistema non sono stati considerati fin dall’inizio. All’inizio del 21° secolo, molti paesi hanno cambiato le loro leggi per ritenere il creatore di una SoI responsabile per il corretto smaltimento a fine vita del sistema.

Life Cycle Reviews

Per controllare il progresso di un progetto, sono previsti diversi tipi di revisione. Le più comunemente usate sono elencate come segue, sebbene i nomi non siano universali:

• La revisione dei requisiti di sistema (SRR) è pianificata per verificare e convalidare l’insieme dei requisiti di sistema prima di iniziare le attività di progettazione dettagliata.
• La revisione preliminare della progettazione (PDR) è prevista per verificare e convalidare l’insieme dei requisiti di sistema, gli artefatti di progettazione e gli elementi di giustificazione alla fine del primo ciclo di progettazione (noto anche come “design-to” gate).
• La critical design reviewcritical design review (CDR) è pianificata per verificare e convalidare l’insieme dei requisiti di sistema, gli artefatti di progettazione e gli elementi di giustificazione alla fine dell’ultimo ciclo di progettazione (i progetti “build-to” e “code-to” sono rilasciati dopo questa revisione).
• Le revisioni di integrazione, verifica e validazione sono pianificate man mano che i componenti sono assemblati in sottosistemi ed elementi di livello superiore. Si tiene una sequenza di revisioni per assicurare che tutto si integri correttamente e che ci siano prove oggettive che tutti i requisiti siano stati soddisfatti. Ci dovrebbe essere anche una validazione in-process che il sistema, così come si sta evolvendo, soddisfi i requisiti delle parti interessate (vedi Figura 7).
• La revisione di validazione finale viene effettuata alla fine della fase di integrazione.
• Altre revisioni relative alla gestione possono essere pianificate e condotte per controllare il corretto avanzamento del lavoro, in base al tipo di sistema e ai rischi associati.

Figura 8. Lato destro del modello Vee (Forsberg, Mooz e Cotterman 2005). Ristampato con il permesso di John Wiley & Sons Inc. Tutti gli altri diritti sono riservati al proprietario del copyright.

Works Cited

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

Faisandier, A. 2012. Architettura e progettazione di sistemi. Belberaud, Francia: Sinergy’Com.

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

INCOSE. 2012. Manuale di ingegneria dei sistemi: A Guide for System Life Cycle Processes and Activities, versione 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. Un viaggio attraverso il paesaggio dei sistemi. Londra, Regno Unito: College Publications, Kings College, Regno Unito.

Riferimenti primari

Beedle, M., et al. 2009. “Il Manifesto Agile: Principi dietro il Manifesto Agile”. in Il Manifesto Agile . Accessed December 04 2014 at www.agilemanifesto.org/principles.html

Boehm, B. and R. Turner. 2004. Bilanciare Agilità e Disciplina. New York, NY, USA: Addison-Wesley.

Fairley, R. 2009. Gestire e condurre progetti software. New York, NY, USA: J. Wiley & Sons.

Forsberg, K., H. Mooz, and H. Cotterman. 2005. Visualizzare la gestione del progetto. 3rd ed. New York, NY, USA: J. Wiley & Sons.

INCOSE. 2012. Manuale di ingegneria dei sistemi: 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. Un viaggio attraverso il paesaggio dei sistemi. Kings College, UK: College Publications.

Pew, R., and A. Mavor (eds.) 2007. Integrazione uomo-sistema nel processo di sviluppo del sistema: Un nuovo sguardo. Washington, DC, USA: The National Academies Press.

Royce, W.E. 1998. Gestione del progetto software: A Unified Framework. New York, NY, USA: Addison Wesley.

Riferimenti aggiuntivi

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

Baldwin, C. e K. Clark. 2000. Regole di progettazione: 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. “Il Manifesto Agile: Principi dietro il Manifesto Agile”. in Il Manifesto Agile . Accesso 2010. Disponibile su: 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. “Un modello a spirale dello sviluppo del software”. IEEE Computer 21(5): 61-72.

Boehm, B. 2006. “Alcune tendenze future e implicazioni per i sistemi e i processi di ingegneria del software”. Ingegneria dei Sistemi. 9(1): 1-19.

Boehm, B., A. Egyed, J. Kwan, D. Port, A. Shah, and R. Madachy. 1998. “Utilizzo del modello a spirale WinWin: Un caso di studio”. IEEE Computer. 31(7): 33-44.

Boehm, B., R. Turner, J. Lane, S. Koolmanojwong. 2014 (in stampa). Abbracciare il modello a spirale: Creazione di sistemi di successo con il modello a spirale di impegno incrementale. Boston, MA, USA: Addison Wesley.

Castellano, D.R. 2004. “I cinque migliori progetti software di qualità”. CrossTalk. 17(7) (luglio 2004): 4-19. Disponibile a: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Pensiero dei sistemi, pratica dei sistemi. New York, NY, USA: Wiley.

Crosson, S. e B. Boehm. 2009. “Regolazione dei punti di ancoraggio del ciclo di vita del software: Lessons Learned in a System of Systems Context.” Proceedings of the Systems and Software Technology Conference, 20-23 aprile 2009, Salt Lake City, UT, USA.

Dingsoyr, T., T. Dyba. e N. Moe (eds.). 2010. “Agile Software Development: Ricerca attuale e direzioni future”. Capitolo in B. Boehm, J. Lane, S. Koolmanjwong, e R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, USA: Springer.

Dorner, D. 1996. La logica del fallimento. 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”. Atti del quinto simposio internazionale annuale del Consiglio Internazionale di Ingegneria dei Sistemi (INCOSE). 22-26 luglio 1995. St. Louis, MO, USA.

Forsberg, K. 2010. “I progetti non iniziano con i requisiti”. Proceedings of the IEEE Systems Conference, 5-8 aprile 2010, San Diego, CA, USA.

Gilb, T. 2005. Ingegneria competitiva. Maryland Heights, MO, USA: Elsevier Butterworth Heinemann.

Goldratt, E. 1984. L’obiettivo. Great Barrington, MA, USA: North River Press.

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

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

ISO/IEC. 2010. Ingegneria dei sistemi e del software, Parte 1: Guida per la gestione del ciclo di vita. Ginevra, Svizzera: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Ingegneria dei sistemi e del software — Processi del ciclo di vita del sistema. Ginevra, Svizzera: Organizzazione internazionale per la standardizzazione / 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. Ginevra, Svizzera: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. “I cinque migliori progetti software di qualità”. CrossTalk. 16(7) (luglio 2003): 4-19. Disponibile a: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

Kruchten, P. 1999. Il Processo Unificato Razionale. New York, NY, USA: Addison Wesley.

Landis, T. R. 2010. Famiglia Lockheed Blackbird (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. “Recensioni di architettura: Pratica ed esperienza”. IEEE Software. 22(2): 34-43.

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

Osterweil, L. 1987. “Anche i processi software sono software”. Atti del SEFM 2011: 9th International Conference on Software Engineering. Monterey, CA, USA.

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

Rechtin, E. 1991. Architettura di sistema: Creare e costruire sistemi complessi. Upper Saddle River, NY, USA: Prentice-Hall.

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

Schwaber, K. e M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, USA: Prentice Hall.

Spruill, N. 2002. “I cinque migliori progetti software di qualità”. CrossTalk. 15(1) (Gennaio 2002): 4-19. Disponibile a: http://www.crosstalkonline.org/storage/issue-archives/2002/200201/200201-0-Issue.pdf.

Stauder, T. 2005. “I cinque migliori premi del programma del Dipartimento della Difesa”. CrossTalk. 18(9) (settembre 2005): 4-13. Disponibile a http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Sistemi sociali: Planning, Policy, and Complexity. New York, NY, USA: Wiley.

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

Video rilevanti=

• Introduzione di base all’ingegneria dei sistemi (metodo V)
• Introduzione di base all’ingegneria dei sistemi (metodo V) Parte 2 di 2