Modelli del ciclo di vita

Autori principali: Kevin Forsberg, Rick Adcock, Contributing Author: Alan Faisandier

Il modello del ciclo di vita è uno dei concetti chiave dell’ingegneria dei sistemi (SE). Il ciclo di vita di un sistema consiste generalmente in una serie di stadi regolati da una serie di decisioni di gestione che confermano che il sistema è abbastanza maturo per lasciare uno stadio ed entrare in un altro.

Temi

Ogni parte del SEBoK è divisa in aree di conoscenza (KA), che sono raggruppamenti di informazioni con un tema correlato. Le KA a loro volta sono divise in argomenti. Questa KA contiene i seguenti argomenti:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• Modelli di processo del ciclo di vita del sistema: Iterativo
• Integrazione dei modelli di processo e di prodotto
• Lean Engineering

Vedi l’articolo Matrice di esempi di implementazione per una mappatura dei casi di studio e delle vignette incluse nella Parte 7 agli argomenti trattati nella Parte 3.

Tipo di prodotti/servizi a valore aggiunto

Il modello generico del ciclo di vita mostra solo il singolo approccio per procedere attraverso le fasi del ciclo di vita di un sistema. Aggiungere valore (come un prodotto, un servizio, o entrambi), è uno scopo condiviso da tutte le imprese, sia pubbliche che private, a scopo di lucro o no. Il valore viene prodotto fornendo e integrando gli elementi di un sistema in un prodotto o servizio secondo la descrizione del sistema e trasformandolo in uso produttivo. Queste considerazioni sul valore porteranno a varie forme dell’approccio generico di gestione del ciclo di vita nella Figura 1. Alcuni esempi sono i seguenti (Lawson 2010):

• Un’impresa manifatturiera produce dadi, bulloni e rondelle di sicurezza e poi vende i suoi prodotti come elementi a valore aggiunto per essere usati da altre imprese; a loro volta, queste imprese integrano questi prodotti nel loro sistema a valore aggiunto più ampio, come un aereo o un’automobile. I loro requisiti saranno generalmente prestabiliti dal cliente o dagli standard industriali.

• Un’impresa di vendita all’ingrosso o al dettaglio offre prodotti ai propri clienti. I suoi clienti (individui o imprese) acquistano i prodotti e li usano come elementi nei loro sistemi. Il sistema di supporto dell’impresa probabilmente si evolverà opportunisticamente, quando emergeranno nuove capacità infrastrutturali o modelli di domanda.

• Un’impresa di servizi commerciali come una banca vende una varietà di prodotti come servizi ai propri clienti. Questo include conti correnti, conti di risparmio, prestiti e gestione degli investimenti. Questi servizi aggiungono valore e sono incorporati nei sistemi dei clienti degli individui o delle imprese. Il sistema di supporto dell’impresa di servizi probabilmente si evolverà anche in modo opportunistico, quando emergeranno nuove capacità infrastrutturali o modelli di domanda.

• Un’impresa di servizi governativa fornisce ai cittadini servizi che variano ampiamente, ma possono includere servizi come l’assistenza sanitaria, le strade e le autostrade, le pensioni, l’applicazione della legge o la difesa. Dove appropriato, questi servizi diventano elementi di infrastruttura utilizzati in sistemi più ampi che comprendono l’interesse degli individui e/o delle imprese. Le iniziative più importanti, come un sistema di controllo del traffico aereo di nuova generazione o un sistema di gestione delle crisi nell’area metropolitana (uragano, tifone, terremoto, tsunami, inondazione, incendio), saranno sufficientemente complesse da seguire un approccio evolutivo di sviluppo e messa in campo. A livello elementare, ci saranno probabilmente cicli di vita pre-specificati a passaggio singolo.

• Per i sistemi aerei e automobilistici, ci sarà probabilmente un ciclo di vita pre-specificato a passaggio multiplo per capitalizzare le prime capacità nel primo passaggio, ma architettato per aggiungere ulteriori capacità di valore aggiunto nei passaggi successivi.

• Un’impresa di sviluppo software diversificata fornisce prodotti software che soddisfano i requisiti degli stakeholder (bisogni), fornendo così servizi agli utenti del prodotto. Dovrà essere sviluppata per avere capacità che possono essere adattate per essere utilizzate nei diversi approcci del ciclo di vita dei clienti e anche con capacità della linea di prodotti che possono essere applicate rapidamente e facilmente agli sviluppi di sistemi simili dei clienti. Il suo modello di business può anche includere la fornitura al cliente di capacità di supporto ed evoluzione del ciclo di vita del sistema.

In questi esempi, ci sono sistemi che rimangono stabili per periodi di tempo ragionevolmente lunghi e quelli che cambiano rapidamente. La diversità rappresentata da questi esempi e dai loro processi illustra perché non esiste un processo unico che possa essere usato per definire uno specifico ciclo di vita dei sistemi. Gli approcci di gestione e di leadership devono considerare il tipo di sistemi coinvolti, la loro longevità e la necessità di un rapido adattamento a cambiamenti imprevisti, che si tratti di concorrenza, tecnologia, leadership o priorità della missione. A sua volta, gli approcci di gestione e di leadership hanno un impatto sul tipo e sul numero di modelli del ciclo di vita che vengono implementati, così come i processi che verranno utilizzati all’interno di ogni particolare ciclo di vita.

Ci sono diversi approcci incrementali ed evolutivi per sequenziare le fasi del ciclo di vita per affrontare alcune delle questioni sollevate sopra. L’area di conoscenza dei modelli del ciclo di vita riassume un certo numero di modelli incrementali ed evolutivi del ciclo di vita, inclusi i loro principali punti di forza e di debolezza e discute anche i criteri per scegliere l’approccio più adatto.

Categorie di modelli del ciclo di vita

Il modello generico del ciclo di vita del sistema nella figura 1 non si adatta esplicitamente a tutte le situazioni. Un sistema semplice, precedente, successivo può aver bisogno di una sola fase nella fase di definizione, mentre un sistema complesso può averne più di due. Con i sistemi build-upon (contro i prototipi usa e getta) i prototipi, una buona parte dello sviluppo può avvenire durante la fase di definizione. Integrazione del sistemaintegrazione, verificaverifica e convalidavalidazione possono seguire l’implementazione o l’acquisizione degli elementi del sistema. Con il software, in particolare il test-first e le build giornaliere, l’integrazione, la verifica e la convalida si intrecciano con l’implementazione degli elementi. Inoltre, con l’imminente terza rivoluzione industriale della stampa tridimensionale e della produzione digitale (Whadcock 2012), non solo lo sviluppo iniziale ma anche la produzione iniziale può essere fatta durante la fase di concetto.

Il software è un mezzo flessibile e malleabile che facilita l’analisi iterativa, la progettazione, la costruzione, la verifica e la convalida in misura maggiore di quanto sia solitamente possibile per i componenti puramente fisici di un sistema. Ogni ripetizione di un modello di sviluppo iterativo aggiunge materiale (codice) alla crescente base di software, in cui la base di codice espansa viene testata, rielaborata se necessario, e dimostrata per soddisfare i requisiti della linea di base.

Il software può essere elettronicamente acquistato, venduto, consegnato e aggiornato ovunque nel mondo entro la portata della comunicazione digitale, rendendo la sua logistica significativamente diversa e più conveniente dell’hardware. Non si consuma e le sue correzioni cambiano il suo contenuto e comportamento, rendendo i test di regressione più complessi rispetto alle correzioni dell’hardware. La sua natura discreta impone che i suoi test non possano contare sulla continuità analitica come per l’hardware. Aggiungere 1 a 32767 in un registro a 15 bit non produce 32768, ma 0, come sperimentato in situazioni gravi, come con l’uso del missile Patriot.

Ci sono un gran numero di potenziali modelli di processo del ciclo di vita. Essi rientrano in tre categorie principali:

1. principalmente processi prestabiliti e sequenziali (per esempio il modello a cascata a passo singolo)
2. principalmente processi evolutivi e concorrenti (per esempio lo sviluppo snello, il processo razionale unificato, e varie forme dei modelli a vena e a spirale)
3. principalmente processi interpersonali ed emergenti (per esempio sviluppo agile, scrum, programmazione estrema (XP), il metodo di sviluppo dinamico del sistema e i processi basati sull’innovazione)

L’emergere di sistemi integrati e interattivi hardware-software ha reso i processi prestabiliti potenzialmente dannosi, poiché le interfacce uomo-sistema più efficaci tendevano a emergere con il suo utilizzo, portando a ulteriori variazioni di processo, come il soft SE (Warfield 1976, Checkland 1981) e i processi di integrazione uomo-sistema (Booher 2003, Pew e Mavor 2007). Fino a poco tempo fa, gli standard di processo e i modelli di maturità hanno cercato di coprire ogni eventualità. Hanno incluso ampi processi per la gestione dell’acquisizione, la selezione delle fonti, le revisioni e gli audit, la garanzia della qualità, la gestione della configurazione e la gestione dei documenti, che in molti casi diventavano eccessivamente burocratici e inefficienti. Questo ha portato all’introduzione di approcci più snelli (Ohno 1988; Womack et al. 1990; Oppenheim 2011) e agili (Beck 1999; Anderson 2010) agli approcci concomitanti hardware-software-fattori umani come i modelli concomitanti vee (Forsberg 1991; Forsberg 2005) e il modello a spirale di impegno incrementale (Pew e Mavor 2007; Boehm e Lane 2007).

Nel prossimo articolo su System Life Cycle Process Drivers and Choices, queste variazioni sul tema dei modelli del ciclo di vita saranno identificate e presentate.

La responsabilità dell’ingegneria dei sistemi

A prescindere dai modelli del ciclo di vita impiegati, il ruolo dell’ingegnere dei sistemi comprende l’intero ciclo di vita del sistema di interesse. Gli ingegneri dei sistemi orchestrano lo sviluppo e l’evoluzione di una soluzione, dalla definizione dei requisiti al funzionamento e infine fino al ritiro del sistema. Essi assicurano che gli esperti del settore siano adeguatamente coinvolti, che tutte le opportunità vantaggiose siano perseguite, e che tutti i rischi significativi siano identificati e, quando possibile, mitigati. L’ingegnere dei sistemi lavora a stretto contatto con il project manager nell’adattare il ciclo di vita generico, compresi i cancelli decisionali chiave, per soddisfare le esigenze del loro progetto specifico.

I compiti di ingegneria dei sistemi sono solitamente concentrati all’inizio del ciclo di vita; tuttavia, sia le organizzazioni commerciali che quelle governative riconoscono la necessità di SE durante tutto il ciclo di vita del sistema. Spesso questo sforzo continuo è quello di modificare o cambiare un sistema, prodotto o servizio dopo che è entrato in produzione o è stato messo in funzione. Di conseguenza, la SE è una parte importante di tutte le fasi del ciclo di vita. Durante le fasi di produzione, supporto e utilizzo (PSU), per esempio, il SE esegue l’analisi delle prestazioni, il monitoraggio dell’interfaccia, l’analisi dei guasti, l’analisi logistica, il monitoraggio e l’analisi delle modifiche proposte. Tutte queste attività sono essenziali per il supporto continuo del sistema.

Tutti i project manager devono assicurare che l’aspetto commerciale (costi, scadenze e valore) e l’aspetto tecnico del ciclo del progetto rimangano sincronizzati. Spesso, l’aspetto tecnico guida il progetto. E’ responsabilità degli ingegneri di sistema assicurare che le soluzioni tecniche considerate siano coerenti con gli obiettivi di costo e di pianificazione. Questo può richiedere di lavorare con gli utenti e i clienti per rivedere gli obiettivi per adattarli ai limiti del business. Questi problemi guidano anche la necessità che i decision gates siano adeguatamente distanziati durante il ciclo del progetto. Anche se la natura di questi decision gates varierà in base alle categorie principali di cui sopra, ognuno coinvolgerà la convalida in-processo tra gli sviluppatori e gli utenti finali. La convalida in-processo pone la domanda: “Quello che stiamo progettando o creando soddisferà le esigenze delle parti interessate? La convalida in-processo inizia all’inizializzazione del progetto durante la scoperta delle necessità degli utenti e continua attraverso le attività quotidiane, le revisioni formali del gate decisionale, la consegna finale del prodotto o della soluzione, le operazioni e infine la chiusura del sistema e lo smaltimento.

Works Cited

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

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

Boehm, B. e J. Lane. 2007. “Usare il modello di impegno incrementale per integrare l’acquisizione del sistema, l’ingegneria dei sistemi e l’ingegneria del software”. CrossTalk. Ottobre 2007: 4-9.

Booher, H. (ed.) 2003. Manuale di integrazione dei sistemi umani. Hoboken, NJ, USA: Wiley.

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

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

Forsberg, K. e 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. Un viaggio attraverso il paesaggio dei sistemi. Londra, Regno Unito: College Publications.

Ohno, T. 1988. Sistema di produzione Toyota. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean per l’ingegneria dei sistemi. Hoboken, NJ: Wiley.

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

Warfield, J. 1976. Ingegneria dei sistemi. Washington, DC, USA: US Department of Commerce (DoC).

Whadcock, I. 2012. “Una terza rivoluzione industriale”. The Economist. April 21, 2012.

Womack, J.P., D.T. Jones, and D. Roos 1990. La macchina che ha cambiato il mondo: The Story of Lean Production. New York, NY, USA: Rawson Associates.

Riferimenti primari

Blanchard, B.S., e W.J. Fabrycky. 2011. Ingegneria e analisi dei sistemi, 5a ed. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Visualizzare la gestione dei progetti, 3a Ed. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Manuale di ingegneria dei sistemi, 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.

Pew, R. e A. Mavor (Eds.). 2007. Integrazione uomo-sistema nel processo di sviluppo del sistema: A New Look. Washington, DC, USA: The National Academies Press.

Riferimenti aggiuntivi

Chrissis, M., M. Konrad, and S. Shrum. 2003. CMMI: Linee guida per l’integrazione dei processi e il miglioramento dei prodotti. New York, NY, USA: Addison Wesley.

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

I seguenti tre libri non sono referenziati nel testo SEBoK, né sono “testi” di ingegneria dei sistemi; tuttavia, contengono importanti lezioni di ingegneria dei sistemi, e i lettori di questo SEBOK sono incoraggiati a leggerli.

Kinder, G. 1998. La nave d’oro nel profondo mare blu. New York, NY, USA: Grove Press.

Questo è un libro eccellente che segue un’idea dall’inizio alla sua implementazione di successo. Anche se l’ingegneria dei sistemi non è discussa, è chiaramente illustrata nell’intero processo, dalla definizione iniziale del progetto allo sviluppo del concetto alternativo, all’esplorazione per fasi e agli “esperimenti del pensiero” per affrontare le sfide lungo la strada. Mostra anche il problema di non anticipare i problemi critici al di fuori dell’ambito abituale del progetto e dell’ingegneria. Ci sono voluti circa cinque anni per localizzare e recuperare le 24 tonnellate di lingotti d’oro e monete dalla nave affondata nell’oceano profondo 2.500 metri, ma ci sono voluti dieci anni per vincere la battaglia legale con gli avvocati che rappresentavano le compagnie di assicurazione che rivendicavano la proprietà sulla base di polizze di 130 anni che avevano emesso per i proprietari dell’oro nel 1857.

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

Anche se l'”ingegneria dei sistemi” non è menzionata, questo libro evidenzia molti problemi di ingegneria dei sistemi e illustra la necessità della SE come disciplina. Il libro illustra anche il pericolo di applicare un concetto di successo precedente (il canale a livello del mare usato a Suez un decennio prima) in una situazione simile ma diversa. Ferdinand de Lesseps ha guidato entrambi i progetti di Suez e Panama. Illustra il pericolo della mancanza di un ciclo di progetto basato sui fatti e di cancelli decisionali significativi durante tutto il ciclo del progetto. Evidenzia anche il pericolo di fornire lo stato del progetto senza visibilità. Dopo cinque anni di progetto decennale, agli investitori è stato detto che il progetto era stato completato per più del 50%, quando in realtà solo il 10% del lavoro era stato completato. La seconda fase di sviluppo sotto Stevens nel 1904 si concentrò sullo “spostare la terra” piuttosto che scavare un canale, un concetto di ingegneria dei sistemi chiave per il completamento del canale. The Path Between the Seas ha vinto il National Book Award per la storia (1978), il Francis Parkman Prize (1978), il Samuel Eliot Morison Award (1978), e il Cornelius Ryan Award (1977).

Shackleton, Sir E.H. 2008. (Originariamente pubblicato in da William Heinemann, Londra, 1919). Sud: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, USA: Lyons Press.

Questa è l’incredibile storia dell’ultima spedizione antartica di Shackleton e l’Endurance nel 1914-1917. La lezione di ingegneria dei sistemi è la continua, quotidiana valutazione del rischio da parte del capitano, del capo spedizione e dell’equipaggio mentre giacevano intrappolati nel ghiaccio artico per 18 mesi. Tutti i 28 membri dell’equipaggio sopravvissero.

Video rilevanti

• L’approccio della NASA all’ingegneria dei sistemi – Space Systems Engineering 101 con la NASA