Modele de procesare a ciclului de viață al sistemului: Vee

Figura 1. Partea stângă a modelului Vee secvențial (Forsberg, Mooz și Cotterman 2005). Retipărită cu permisiunea John Wiley & Sons Inc. Toate celelalte drepturi sunt rezervate de către proprietarul drepturilor de autor.

Modelul Vee aprobă definiția din Manualul INCOSE de inginerie a sistemelor (INCOSE 2012) a etapelor ciclului de viață și scopurile sau activitățile acestora, așa cum se arată în Figura 2 de mai jos.

Figura 2. Un exemplu de etape, scopurile lor și porțile majore de decizie. (SEBoK Original)

Manualul INCOSE Systems Engineering Handbook 3.2.2 conține o versiune mai detaliată a diagramei Vee (2012, figurile 3-4, p. 27) care încorporează activitățile ciclului de viață în modelul Vee mai generic. O diagramă similară, elaborată la Defense Acquisition University (DAU) din SUA, poate fi văzută în figura 3 de mai jos.

Figura 3. Diagrama de activitate Vee (Prosnik 2010). Publicată de Universitatea de Achiziții pentru Apărare (DAU)/Departamentul de Apărare al SUA (DoD).

Aplicarea modelului Vee

Lawson (Lawson 2010) detaliază activitățile din fiecare etapă a ciclului de viață și notează că este util să se ia în considerare structura unui model generic al etapelor ciclului de viață pentru orice tip de sistem de interes (SoI), așa cum este prezentat în Figura 4. Acest model (T) indică faptul că una sau mai multe etape de definire precedă una sau mai multe etape de producție în care a fost realizată implementarea (achiziția, furnizarea sau dezvoltarea) a două sau mai multe elemente ale sistemului

Figura 4. Structura generică (T) a etapelor modelelor ciclului de viață al sistemului (Lawson 2010). Retipărită cu permisiunea lui Harold Lawson. Toate celelalte drepturi sunt rezervate de către proprietarul drepturilor de autor.

Figura 5 prezintă etapele generice ale ciclului de viață pentru o varietate de părți interesate, de la o organizație de standardizare (ISO/CEI) la organizații comerciale și guvernamentale. Deși aceste etape diferă în detaliu, toate au un format secvențial similar care pune accentul pe activitățile de bază, așa cum se observă în figura 2 (definire, producție și utilizare/retragere).

Figura 5. Comparații ale modelelor de ciclu de viață (Forsberg, Mooz și Cotterman 2005). Retipărit cu permisiunea John Wiley & Sons. Toate celelalte drepturi sunt rezervate de către proprietarul drepturilor de autor.

Este important de remarcat faptul că multe dintre activitățile din cadrul ciclului de viață sunt iterative. Acesta este un exemplu de recursivitate (glosar)recursivitate (glosar), așa cum s-a discutat în partea 3 Introducere.

Fundamentele etapelor ciclului de viață și faza de management al programului

Pentru această discuție, este important să rețineți că:

• Termenul etapă se referă la diferitele stări ale unui sistem în timpul ciclului său de viață; unele etape se pot suprapune în timp, cum ar fi etapa de utilizare și etapa de suport. Termenul „etapă” este utilizat în ISO/IEC/IEEE 15288.

• Termenul fază se referă la diferitele etape ale programului care sprijină și gestionează durata de viață a sistemului; de obicei, fazele nu se suprapun. Termenul „fază” este utilizat în multe modele bine stabilite ca un echivalent al termenului „etapă.”

Managementul programuluiManagementul programului utilizează faze, etape de referințăetape de referință și porți de decizieporți de decizie care sunt utilizate pentru a evalua evoluția unui sistem prin diferitele sale etape. Etapele conțin activitățile desfășurate pentru atingerea obiectivelor și servesc la controlul și gestionarea succesiunii etapelor și a tranzițiilor între fiecare etapă. Pentru fiecare proiect, este esențial să se definească și să se publice termenii și definițiile aferente utilizate pe proiectele respective pentru a minimiza confuzia.

Un program tipicprogramul este compus din următoarele faze:

• Faza de pre-studiu, care identifică potențialele oportunități de a răspunde nevoilor utilizatorilor cu noi soluții care au sens din punct de vedere comercial.
• Faza de fezabilitate constă în studierea fezabilității conceptelor alternative pentru a ajunge la o a doua poartă de decizie înainte de inițierea etapei de execuție. În timpul fazei de fezabilitate, se identifică cerințele părților interesate și cerințele sistemului, se identifică și se studiază soluțiile viabile și pot fi implementate prototipuri virtuale (glosar)prototipuri (glosar). În timpul acestei faze, decizia de a merge mai departe se bazează pe:
  • dacă un concept este fezabil și este considerat capabil să contracareze o amenințare identificată sau să exploateze o oportunitate;
  • dacă un concept este suficient de matur pentru a justifica dezvoltarea în continuare a unui nou produs sau a unei linii de produse; și
  • dacă se aprobă o propunere generată ca răspuns la o cerere de ofertă.
• Faza de execuție include activități legate de patru etape ale ciclului de viață al sistemului: dezvoltare, producție, utilizare și suport. În mod obișnuit, există două porți de decizie și două repere asociate cu activitățile de execuție. Prima etapă de referință oferă conducerii posibilitatea de a revizui planurile de execuție înainte de a da undă verde. A doua etapă de referință oferă posibilitatea de a revizui progresul înainte de a se lua decizia de a iniția producția. Porțile de decizie din timpul execuției pot fi utilizate pentru a determina dacă se va produce SoI dezvoltat și dacă se va îmbunătăți sau se va retrage.

Aceste viziuni de gestionare a programului se aplică nu numai la SoI, ci și la elementele și structura sa.

Etapele ciclului de viață

Variațiile modelului Vee se ocupă de aceleași etape generale ale unui ciclu de viață:

• Proiectele noi încep, de obicei, cu o fază de cercetare exploratorie care include, în general, activitățile de definire a conceptului, în special subiectele de analiză a afacerii sau a misiunii și de înțelegere a nevoilor și cerințelor părților interesate. Acestea se maturizează pe măsură ce proiectul trece de la faza exploratorie la faza de concept și la faza de dezvoltare.
• Faza de producție include activitățile de definire a sistemului și de realizare a sistemului, precum și dezvoltarea cerințelor (glosar)cerințelor (glosar) și a arhitecturii (glosar)arhitecturii (glosar) sistemului prin verificare și validare.
• Faza de utilizare include activitățile de implementare a sistemului și de operare a sistemului.
• Faza de sprijin include activitățile de întreținere a sistemului, de logistică și de gestionare a duratei de viață a produsului și a serviciului, care pot include activități cum ar fi prelungirea duratei de viață sau actualizări ale capacităților, modernizări și modernizări.
• Faza de retragere include activitățile de eliminare și retragere, deși în unele modele, activități precum prelungirea duratei de viață utilă sau actualizări ale capacităților, actualizări și modernizări sunt grupate în faza de „retragere”.

Informații suplimentare despre fiecare dintre aceste etape pot fi găsite în secțiunile de mai jos (pentru mai multe detalii, a se vedea linkurile către articolele suplimentare din partea 3 de mai sus). Este important de reținut că aceste etape ale ciclului de viață și activitățile din fiecare etapă sunt susținute de un set de procese de management al ingineriei sistemelor.

Etapa de cercetare exploratorie

Analiza și acordul privind cerințele utilizatorului fac parte din etapa de cercetare exploratorie și sunt esențiale pentru dezvoltarea unor sisteme de succes. Fără o înțelegere adecvată a nevoilor utilizatorilor, orice sistem riscă să fie construit pentru a rezolva probleme greșite. Primul pas în etapa de cercetare exploratorie este definirea cerințelor și constrângerilor utilizatorului (și ale părților interesate). O parte esențială a acestui proces este stabilirea fezabilității îndeplinirii cerințelor utilizatorului, inclusiv evaluarea pregătirii tehnologice. La fel ca în cazul multor activități de SE, acest lucru se face adesea în mod iterativ, iar nevoile și cerințele părților interesate sunt revizuite pe măsură ce noi informații devin disponibile.

Un studiu recent al Consiliului Național de Cercetare (National Research Council 2008) s-a axat pe reducerea timpului de dezvoltare pentru proiectele US Air Force. Raportul notează că, „simplu spus, ingineria sistemelor este transpunerea nevoilor unui utilizator într-o definiție a unui sistem și a arhitecturii acestuia printr-un proces iterativ care are ca rezultat o proiectare eficientă a sistemului”. Implicarea iterativă cu părțile interesate este esențială pentru succesul proiectului.

Cu excepția primei și ultimei porți de decizie a unui proiect, porțile sunt efectuate simultan. A se vedea Figura 6 de mai jos.

Figura 6. Programarea fazelor de dezvoltare. (SEBoK Original)

Etapa de concept

În timpul etapei de concept, se creează concepte alternative pentru a determina cea mai bună abordare pentru a satisface nevoile părților interesate. Prin conceperea de alternative și crearea de modele, inclusiv prototipuri adecvate, se vor clarifica nevoile părților interesate și se vor evidenția problemele determinante. Acest lucru poate conduce la o abordare incrementală sau evolutivă a dezvoltării sistemului. Mai multe concepte diferite pot fi explorate în paralel.

Etapa de dezvoltare

Conceptul (conceptele) selectat(e), identificat(e) în etapa de concept, este (sunt) elaborat(e) în detaliu până la nivelul cel mai de jos pentru a produce soluția care satisface cerințele părților interesateexigențele părților interesate. De-a lungul acestei etape, este esențial să se continue cu implicarea utilizatorilor prin validarea în cadrul procesului (săgeata ascendentă de pe modelele Vee). În cazul hardware-ului, acest lucru se realizează prin revizuiri frecvente ale programului și prin intermediul unui (unor) reprezentant(i) rezident(i) al(e) clientului (dacă este cazul). În dezvoltarea agilă, practica este ca reprezentantul clientului să fie integrat în echipa de dezvoltare.

Etapa de producție

Etapa de producție este cea în care este construit sau fabricat SoI. Pot fi necesare modificări ale produsului pentru a rezolva probleme de producție, pentru a reduce costurile de producție sau pentru a îmbunătăți capacitățile produsului sau ale SoI. Oricare dintre aceste modificări poate influența cerințele sistemului și poate necesita recalificarea sistemului, recalificarea, recalificareaverificareaverificarea sau recalificareavalidarea sistemului. Toate aceste modificări necesită evaluarea SE înainte ca modificările să fie aprobate.

Etapa de utilizare

Un aspect semnificativ al gestionării ciclului de viață al produsului este furnizarea de sisteme de sprijin care sunt vitale pentru susținerea funcționării produsului. În timp ce produsul sau serviciul furnizat poate fi considerat ca fiind sistemul de interes restrâns (NSOI) pentru un achizitor, achizitorul trebuie, de asemenea, să încorporeze sistemele de sprijin într-un sistem de interes mai larg (WSOI). Aceste sisteme de sprijin ar trebui să fie văzute ca active de sistem care, atunci când este necesar, sunt activate ca răspuns la o situație apărută în ceea ce privește funcționarea NSOI. Denumirea colectivă pentru setul de sisteme de sprijin este sistemul de sprijin logistic integrat (ILS).

Este vital să se aibă o viziune holistică atunci când se definesc, se produc și se exploatează produse și servicii de sistem. În figura 7, este descrisă relația dintre proiectarea și dezvoltarea sistemului și cerințele ILS.

Figura 7. Relaționarea ILS cu ciclul de viață al sistemului (Eichmueller și Foreman 2009). Retipărită cu permisiunea Comitetului director ASD/AIA S3000L. Toate celelalte drepturi sunt rezervate de către proprietarul drepturilor de autor.

Exigențele de fiabilitate, care au ca rezultat nevoia de mentenabilitate și testabilitate, sunt factori determinanți.

Etapa de susținere

În etapa de susținere, SoI primește servicii care permit continuarea funcționării. Pot fi propuse modificări pentru a rezolva problemele de suportabilitate, pentru a reduce costurile operaționale sau pentru a prelungi durata de viață a unui sistem. Aceste modificări necesită evaluarea SE pentru a evita pierderea capacităților sistemului în timpul funcționării. Procesul tehnic corespunzător este procesul de mentenanță.

Etapa de retragere

În etapa de retragere, SoI și serviciile aferente acestuia sunt scoase din funcțiune. Activitățile SE din această etapă se concentrează în principal pe asigurarea satisfacerii cerințelor de eliminare. De fapt, planificarea eliminării face parte din definirea sistemului în timpul etapei de concept. Experiențele din secolul XX au demonstrat în mod repetat consecințele atunci când retragerea și eliminarea sistemului nu au fost luate în considerare încă de la început. La începutul secolului XXI, multe țări și-au modificat legile pentru a trage la răspundere creatorul unui SoI pentru eliminarea corespunzătoare a sistemului la sfârșitul ciclului de viață.

Revizuiri ale ciclului de viață

Pentru a controla progresul unui proiect, sunt planificate diferite tipuri de revizuiri. Cele mai frecvent utilizate sunt enumerate în cele ce urmează, deși denumirile nu sunt universale:

• Revizuirea cerințelor sistemului (SRR) este planificată pentru a verifica și valida setul de cerințe ale sistemului înainte de începerea activităților de proiectare detaliată.
• Revizuirea preliminară a proiectuluirevizuirea preliminară a proiectului (PDR) este planificată pentru a verifica și valida setul de cerințe de sistem, artefactele de proiectare și elementele de justificare la sfârșitul primei bucle de inginerie (cunoscută și sub numele de poarta „design-to”).
• Revizuirea critică a proiectăriiRevizuirea critică a proiectării (CDR) este planificată pentru a verifica și valida setul de cerințe ale sistemului, artefactele de proiectare și elementele de justificare la sfârșitul ultimei bucle de inginerie (proiectele „build-to” și „code-to” sunt lansate după această revizuire).
• Revizuirile de integrareintegrare, verificareverificare și validarevalidarerevizuirile de validare sunt planificate pe măsură ce componentele sunt asamblate în subsisteme și elemente de nivel superior. Se organizează o secvență de revizuiri pentru a se asigura că totul se integrează corect și că există dovezi obiective că toate cerințele au fost îndeplinite. Ar trebui să existe, de asemenea, o validare în timpul procesului care să arate că sistemul, pe măsură ce evoluează, va îndeplini cerințele părților interesate (a se vedea figura 7).
• Revizuirea finală de validare se efectuează la sfârșitul fazei de integrare.
• Pot fi planificate și efectuate și alte revizuiri legate de management pentru a controla progresul corect al lucrărilor, pe baza tipului de sistem și a riscurilor asociate.

Figura 8. Partea dreaptă a modelului Vee (Forsberg, Mooz și Cotterman 2005). Retipărită cu permisiunea John Wiley & Sons Inc. Toate celelalte drepturi sunt rezervate de proprietarul drepturilor de autor.

Lucrări citate

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

Faisandier, A. 2012. Arhitectura și proiectarea sistemelor. Belberaud, Franța: Sinergy’Com.

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

INCOSE. 2012. Manualul de inginerie a sistemelor: A Guide for System Life Cycle Processes and Activities, versiunea 3.2.2. San Diego, CA, SUA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape (O călătorie prin peisajul sistemelor). London, UK: College Publications, Kings College, UK.

Referințe principale

Beedle, M., et al. 2009. „The Agile Manifesto: Principles behind the Agile Manifesto”. în The Agile Manifesto . Accesat la 04 decembrie 2014 la www.agilemanifesto.org/principles.html

Boehm, B. și R. Turner. 2004. Balancing Agility and Discipline (Echilibrarea agilității și a disciplinei). New York, NY, SUA: Addison-Wesley.

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

Forsberg, K., H. Mooz, și H. Cotterman. 2005. Vizualizarea managementului de proiect. 3rd ed. New York, NY, SUA: J. Wiley & Sons.

INCOSE. 2012. Manualul de inginerie a sistemelor: A Guide for System Life Cycle Processes and Activities, versiunea 3.2.2. San Diego, CA, SUA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape (O călătorie prin peisajul sistemelor). Kings College, Marea Britanie: College Publications.

Pew, R., și A. Mavor (eds.) 2007. Integrarea om-sistem în procesul de dezvoltare a sistemelor: A New Look. Washington, DC, SUA: The National Academies Press.

Royce, W.E. 1998. Managementul proiectelor de software: A Unified Framework. New York, NY, SUA: Addison Wesley.

Referințe suplimentare

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

Baldwin, C. și K. Clark. 2000. Reguli de proiectare: The Power of Modularity (Puterea modularității). Cambridge, MA, SUA: MIT Press.

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

Beedle, M., et al. 2009. „The Agile Manifesto: Principles behind the Agile Manifesto”. în The Agile Manifesto . Accesat în 2010. Disponibil la: www.agilemanifesto.org/principles.html

Biffl, S., A. Aurum, B. Boehm, H. Erdogmus, și P. Gruenbacher (eds.). 2005. Value-Based Software Engineering. New York, NY, SUA: 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 și 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 (în presă). Îmbrățișarea modelului spiralat: Creating Successful Systems with the Incremental Commitment Spiral Model: Creating Successful Systems with the Incremental Commitment Spiral Model. Boston, MA, SUA: Addison Wesley.

Castellano, D.R. 2004. „Top cinci proiecte software de calitate”. CrossTalk. 17(7) (iulie 2004): 4-19. Disponibilă la adresa:: http://www.crosstalkonline.org/storage/issue-archives/2004/200407/200407-0-Issue.pdf

Checkland, P. 1981. Gândire sistemică, practică sistemică. New York, NY, SUA: Wiley.

Crosson, S. și B. Boehm. 2009. „Ajustarea punctelor de ancorare a ciclului de viață al software-ului: Lessons Learned in a System of Systems Context”. Proceedings of the Systems and Software Technology Conference, 20-23 aprilie 2009, Salt Lake City, UT, SUA.

Dingsoyr, T., T. Dyba. și N. Moe (eds.). 2010. „Agile Software Development: Current Research and Future Directions”. Capitol în B. Boehm, J. Lane, S. Koolmanjwong și R. Turner, Architected Agile Solutions for Software-Reliant Systems. New York, NY, SUA: Springer.

Dorner, D. 1996. The Logic of Failure (Logica eșecului). New York, NY, SUA: 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 iulie 1995. St. Louis, MO, SUA.

Forsberg, K. 2010. „Projects Don’t Begin With Requirements” („Proiectele nu încep cu cerințele”). Proceedings of the IEEE Systems Conference, 5-8 aprilie 2010, San Diego, CA, SUA.

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

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

Hitchins, D. 2007. Ingineria sistemelor: A 21st Century Systems Methodology. New York, NY, SUA: Wiley.

Holland, J. 1998. Emergența. New York, NY, SUA: Perseus Books.

ISO/IEC. 2010. Ingineria sistemelor și a software-ului, Partea 1: Ghid pentru managementul ciclului de viață. Geneva, Elveția: Organizația Internațională pentru Standardizare (ISO)/Comisia Electrotehnică Internațională (IEC), ISO/IEC 24748-1:2010.

ISO/IEC/IEEE. 2015. Ingineria sistemelor și a software-ului — System Life Cycle Processes. Geneva, Elveția: Organizația Internațională pentru Standardizare / Comisiile Electrotehnice Internaționale / Institutul Inginerilor Electrici și Electronici. ISO/IEC/IEEE 15288:2015.

ISO/IEC. 2003. Ingineria sistemelor – Ghid pentru aplicarea proceselor din ciclul de viață al sistemului ISO/IEC 15288. Geneva, Elveția: Organizația Internațională pentru Standardizare (ISO)/Comisia Electrotehnică Internațională (IEC), ISO/IEC 19760:2003 (E).

Jarzombek, J. 2003. „Top cinci proiecte software de calitate”. CrossTalk. 16(7) (iulie 2003): 4-19. Disponibil la: http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-0-Issue.pdf.

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

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

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

Maranzano, J.F., S.A. Rozsypal, G.H. Zimmerman, G.W. Warnken, P.E. Wirth, D.W. Weiss. 2005. „Architecture Reviews: Practică și experiență”. IEEE Software. 22(2): 34-43.

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

Osterweil, L. 1987. „Software Processes are Software Too” (Procesele software sunt și ele software). Proceedings of the SEFM 2011: A 9-a Conferință internațională privind ingineria software. Monterey, CA, SUA.

Poppendeick, M. și T. Poppendeick. 2003. Lean Software Development: an Agile Toolkit. New York, NY, SUA: Addison Wesley.

Rechtin, E. 1991. Arhitectura de sistem: Creating and Building Complex Systems. Upper Saddle River, NY, SUA: Prentice-Hall.

Rechtin, E., și M. Maier. 1997. The Art of System Architecting. Boca Raton, FL, SUA: CRC Press.

Schwaber, K. și M. Beedle. 2002. Agile Software Development with Scrum. Upper Saddle River, NY, SUA: Prentice Hall.

Spruill, N. 2002. „Top cinci proiecte software de calitate”. CrossTalk. 15(1) (ianuarie 2002): 4-19. Disponibilă la adresa:: 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) (septembrie 2005): 4-13. Disponibil la: http://www.crosstalkonline.org/storage/issue-archives/2005/200509/200509-0-Issue.pdf.

Warfield, J. 1976. Sisteme societale: Planning, Policy, and Complexity (Planificare, politică și complexitate). New York, NY, SUA: Wiley.

Womack, J. și D. Jones. 1996. Gândirea Lean. New York, NY, SUA: Simon and Schuster.

Videoclipuri relevante=

• Introducere de bază în ingineria sistemelor (metoda V)
• Introducere de bază în ingineria sistemelor (metoda V) Partea a 2-a din 2