Modeluri ale ciclului de viață

Autori principali: Kevin Forsberg, Rick Adcock, Autor colaborator: Kevin Forsberg, Rick Adcock: Alan Faisandier

Modelul ciclului de viață este unul dintre conceptele cheie ale ingineriei sistemelor (SE). Un ciclu de viațăciclul de viață pentru un sistemde sistem constă, în general, dintr-o serie de etapeetape reglementate de un set de decizii de management care confirmă faptul că sistemul este suficient de matur pentru a părăsi o etapă și a intra în alta.

Teme

Care parte a SEBoK este împărțită în domenii de cunoaștere (KA), care sunt grupări de informații cu o temă conexă. La rândul lor, KA-urile sunt împărțite în subiecte. Acest KA conține următoarele subiecte:

• System Life Cycle Process Drivers and Choices
• System Life Cycle Process Models: Vee
• Modeluri de procese ale ciclului de viață al sistemului: Iterativ
• Integrarea modelelor de proces și de produs
• Lean Engineering

Vezi articolul Matricea exemplelor de implementare pentru o cartografiere a studiilor de caz și a vinietelor incluse în partea a 7-a cu subiectele abordate în partea a 3-a.

Tipul de produse/servicii cu valoare adăugată

Modelul generic al ciclului de viață prezintă doar abordarea într-o singură etapă pentru a trece prin etapele ciclului de viață al unui sistem. Adăugarea de valoare (ca produs, serviciu sau ambele), este un scop comun al tuturor întreprinderilor, fie ele publice sau private, cu sau fără scop lucrativ. Valoarea este produsă prin furnizarea și integrarea elementelor unui sistem într-un produs sau serviciu în conformitate cu descrierea sistemului și prin tranziția acestuia spre o utilizare productivă. Aceste considerații privind valoarea vor conduce la diferite forme ale abordării generice de gestionare a ciclului de viață din figura 1. Câteva exemple sunt următoarele (Lawson 2010):

• O întreprindere de producție produce piulițe, șuruburi și șaibe de blocare și apoi își vinde produsele ca elemente cu valoare adăugată pentru a fi utilizate de alte întreprinderi; la rândul lor, aceste întreprinderi integrează aceste produse în sistemul lor cu valoare adăugată mai cuprinzător, cum ar fi un avion sau un automobil. Cerințele lor vor fi, în general, pre-specificate de către client sau de standardele industriei.

• O întreprindere de comerț cu ridicata sau cu amănuntul oferă produse clienților săi. Clienții săi (persoane fizice sau întreprinderi) achiziționează produsele și le utilizează ca elemente în sistemele lor. Sistemul de suport al întreprinderii va evolua probabil în mod oportunist, pe măsură ce apar noi capacități de infrastructură sau modele de cerere.

• O întreprindere de servicii comerciale, cum ar fi o bancă, vinde clienților săi o varietate de produse ca servicii. Aceasta include conturi curente, conturi de economii, împrumuturi și gestionarea investițiilor. Aceste servicii adaugă valoare și sunt încorporate în sistemele de clientelă ale persoanelor fizice sau ale întreprinderilor. De asemenea, sistemul de sprijin al întreprinderii de servicii va evolua probabil în mod oportunist, pe măsură ce apar noi capacități de infrastructură sau noi modele de cerere.

• O întreprindere de servicii guvernamentale oferă cetățenilor servicii care variază foarte mult, dar pot include servicii precum asistența medicală, autostrăzi și drumuri, pensii, aplicarea legii sau apărare. Acolo unde este cazul, aceste servicii devin elemente de infrastructură utilizate în sisteme mai mari care cuprind sisteme de interes pentru persoane și/sau întreprinderi. Inițiativele majore, cum ar fi un sistem de control al traficului aerian de ultimă generație sau un sistem de gestionare a crizelor din zona metropolitană (uragan, taifun, cutremur, tsunami, inundații, incendii), vor fi suficient de complexe pentru a urma o abordare evolutivă de dezvoltare și punere în funcțiune. La nivel elementar, vor exista probabil cicluri de viață pre-specificate cu o singură trecere.

• Pentru sistemele pentru aeronave și automobile, va exista probabil un ciclu de viață pre-specificat cu treceri multiple pentru a capitaliza capacitățile timpurii în prima trecere, dar arhitecturat pentru a adăuga capacități suplimentare care să adauge valoare în trecerile ulterioare.

• O întreprindere diversificată de dezvoltare de software furnizează produse software care îndeplinesc cerințele (nevoile) părților interesate, oferind astfel servicii utilizatorilor de produse. Va trebui să fie dezvoltată pentru a avea capacități care pot fi adaptate pentru a fi utilizate în diferite abordări ale ciclului de viață al clienților și, de asemenea, cu capacități de linie de produse care pot fi aplicate rapid și ușor la dezvoltări de sisteme similare ale clienților. Modelul său de afaceri poate include, de asemenea, furnizarea către client a suportului pentru ciclul de viață al sistemului și a capacităților de evoluție.

În cadrul acestor exemple, există sisteme care rămân stabile pe perioade de timp rezonabil de lungi și altele care se schimbă rapid. Diversitatea reprezentată de aceste exemple și de procesele lor ilustrează de ce nu există un proces unic care să poată fi utilizat pentru a defini un ciclu de viață al sistemelor specifice. Abordările de management și de conducere trebuie să ia în considerare tipul de sisteme implicate, longevitatea acestora și nevoia de adaptare rapidă la schimbări neprevăzute, fie că este vorba de concurență, tehnologie, conducere sau priorități ale misiunii. La rândul lor, abordările de management și de conducere au un impact asupra tipului și numărului de modele de ciclu de viață care sunt implementate, precum și asupra proceselor care vor fi utilizate în cadrul unui anumit ciclu de viață.

Există mai multe abordări incrementale și evolutive pentru secvențierea etapelor ciclului de viață pentru a face față unora dintre problemele ridicate mai sus. Domeniul de cunoștințe privind modelele ciclului de viață rezumă o serie de modele de ciclu de viață incrementaleincrementale și evolutiveevolutive, inclusiv principalele lor puncte forte și puncte slabe și, de asemenea, discută criteriile pentru alegerea celei mai potrivite abordări.

Categorii de modele de ciclu de viață

Modelul generic al ciclului de viață al sistemului din figura 1 nu se potrivește în mod explicit tuturor situațiilor. Un sistem simplu, precedențial, de urmărire, poate avea nevoie doar de o singură fază în etapa de definire, în timp ce un sistem complex poate avea nevoie de mai mult de două. În cazul sistemelor build-upon (vs. prototipuri de aruncat) prototipuriprototipuri, o bună parte din dezvoltare poate avea loc în timpul etapei de definire. Integrarea sistemuluiintegrarea, verificareaverificarea, și validarea validarea sistemului pot urma implementării sau achiziționării elementelor sistemului. În cazul software-ului, în special în cazul testării mai întâi și al construcțiilor zilnice, integrarea, verificarea și validarea se împletesc cu implementarea elementelor. În plus, odată cu iminenta a treia revoluție industrială a imprimării tridimensionale și a producției digitale (Whadcock 2012), nu numai dezvoltarea inițială, ci și producția inițială pot fi realizate în timpul etapei de concept.

Software-ul este un mediu flexibil și maleabil care facilitează analiza iterativă, proiectarea, construcția, verificarea și validarea într-un grad mai mare decât este posibil, de obicei, pentru componentele pur fizice ale unui sistem. Fiecare repetare a unui model de dezvoltare iterativă adaugă material (cod) la baza software în creștere, în care baza de cod extinsă este testată, reelaborată dacă este necesar și se demonstrează că satisface cerințele pentru linia de bază.

Software-ul poate fi cumpărat, vândut, livrat și actualizat electronic oriunde în lume, la îndemâna comunicațiilor digitale, ceea ce face ca logistica sa să fie semnificativ diferită și mai rentabilă decât cea a hardware-ului. Nu se uzează, iar corecturile sale îi modifică conținutul și comportamentul, ceea ce face ca testarea de regresie să fie mai complexă decât în cazul corecturilor hardware. Natura sa discretă impune ca testarea sa să nu se poată baza pe continuitatea analitică, ca în cazul hardware-ului. Adăugarea lui 1 la 32767 într-un registru pe 15 biți nu produce 32768, ci 0, așa cum se întâmplă în situații grave, cum ar fi în cazul utilizării rachetelor Patriot.

Există un număr mare de modele potențiale de procese ale ciclului de viață. Acestea se împart în trei categorii majore:

1. procese pre-specificate și secvențiale în primul rând (de exemplu, modelul în cascadă cu o singură etapă)
2. procese evolutive și concurente în primul rând (de exemplu, dezvoltarea suplu, procesul rațional unificat și diverse forme ale modelelor în V și în spirală)
3. procese interpersonale și emergente în primul rând (de exemplu, modelul în V și în spirală)
4. procese interpersonale și emergente în primul rând (de exemplu, modelul în V și în spirală). dezvoltarea agilă, scrum, programarea extremă (XP), metoda de dezvoltare dinamică a sistemelor și procesele bazate pe inovare)

Emergența sistemelor hardware-software integrate și interactive a făcut ca procesele pre-specificate să fie potențial dăunătoare, deoarece cele mai eficiente interfețe om-sistem au avut tendința de a apărea odată cu utilizarea acestora, ceea ce a condus la alte variații ale proceselor, cum ar fi soft SE (Warfield 1976, Checkland 1981) și procesele de integrare om-sistem (Booher 2003, Pew și Mavor 2007). Până de curând, standardele de proces și modelele de maturitate au încercat să acopere orice eventualitate. Acestea au inclus procese extinse pentru gestionarea achizițiilor, selecția surselor, revizuiri și audituri, asigurarea calității, gestionarea configurației și gestionarea documentelor, care, în multe cazuri, ar deveni excesiv de birocratice și ineficiente. Acest lucru a dus la introducerea unor abordări mai suplu (Ohno 1988; Womack et al. 1990; Oppenheim 2011) și mai agile (Beck 1999; Anderson 2010) ale abordărilor concurente hardware-software-factori umani, cum ar fi modelele concurente în vee (Forsberg 1991; Forsberg 2005) și modelul spiralat al angajamentului incremental (Pew și Mavor 2007; Boehm și Lane 2007).

În următorul articol privind factorii determinanți și opțiunile procesului ciclului de viață al sistemului, vor fi identificate și prezentate aceste variații pe tema modelelor ciclului de viață.

Responsabilitatea inginerului de sistem

Indiferent de modelele ciclului de viață implementate, rolul inginerului de sistem cuprinde întregul ciclu de viață al sistemului de interes. Inginerii de sistem orchestrează dezvoltarea și evoluția unei soluții, de la definirea cerințelor până la operare și, în cele din urmă, până la retragerea sistemului. Aceștia se asigură că experții din domeniu sunt implicați în mod corespunzător, că toate oportunitățile avantajoase sunt urmărite și că toate riscurile semnificative sunt identificate și, atunci când este posibil, atenuate. Inginerul de sistem colaborează îndeaproape cu managerul de proiect pentru a adapta ciclul de viață generic, inclusiv porțile de decizie cheieporțile de decizie, pentru a răspunde nevoilor proiectului lor specific.

Timpurile ingineriei sistemelor sunt, de obicei, concentrate la începutul ciclului de viață; cu toate acestea, atât organizațiile comerciale, cât și cele guvernamentale recunosc necesitatea SE pe tot parcursul ciclului de viață al sistemului. Adesea, acest efort continuu constă în modificarea sau schimbarea unui sistem, produs sau serviciu după ce acesta intră în producție sau este pus în funcțiune. În consecință, SE este o parte importantă a tuturor etapelor ciclului de viață. În timpul etapelor de producție, suport și utilizare (PSU), de exemplu, SE execută analiza performanțelor, monitorizarea interfețelor, analiza defecțiunilor, analiza logistică, urmărirea și analiza modificărilor propuse. Toate aceste activități sunt esențiale pentru susținerea continuă a sistemului.

Toți managerii de proiect trebuie să se asigure că aspectul comercial (cost, calendar și valoare) și aspectul tehnic al ciclului de proiect rămân sincronizate. Adesea, aspectul tehnic conduce proiectul. Este responsabilitatea inginerilor de sistem să se asigure că soluțiile tehnice care sunt luate în considerare sunt în concordanță cu obiectivele de cost și de program. Acest lucru poate necesita colaborarea cu utilizatorii și clienții pentru a revizui obiectivele pentru a se încadra în limitele afacerii. Aceste aspecte determină, de asemenea, necesitatea ca porțile de decizie să fie spațiate în mod corespunzător pe parcursul ciclului de proiect. Deși natura acestor porți de decizie va varia în funcție de categoriile majore de mai sus, fiecare dintre ele va implica o validare în cadrul procesului validare în cadrul procesului între dezvoltatori și utilizatorii finali. Validarea în cadrul procesului pune întrebarea: „Ceea ce planificăm sau creăm va satisface nevoile părților interesate?”. Validarea în proces începe la inițializarea proiectului în timpul descoperirii nevoilor utilizatorilor și continuă prin activitățile zilnice, revizuirile formale ale porții de decizie, livrarea produsului final sau a soluției, operațiunile și, în cele din urmă, până la închiderea și eliminarea sistemului.

Lucrări citate

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

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

Boehm, B. și J. Lane. 2007. „Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering”. CrossTalk. Octombrie 2007: 4-9.

Booher, H. (ed.) 2003. Handbook of Human Systems Integration (Manual de integrare a sistemelor umane). Hoboken, NJ, SUA: Wiley.

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

Cusumano, M., și D. Yoffie. 1998. Competing on Internet Time, New York, NY, SUA: The Free Press.

Forsberg, K. și H. Mooz. 1991. „The Relationship of System Engineering to the Project Cycle”, Proceedings of INCOSE, octombrie 1991.

Forsberg, K., H. Mooz și 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, Elveția: Organizația Internațională de Standardizare (ISO)/Comisia Electrotehnică Internațională (IEC), Institutul Inginerilor Electrici și Electroniști.ISO/IEC 15288:2015.

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

Ohno, T. 1988. Sistemul de producție Toyota. New York, NY: Productivity Press.

Oppenheim, B. 2011. Lean pentru ingineria sistemelor. Hoboken, NJ: Wiley.

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.

Warfield, J. 1976. Ingineria sistemelor. Washington, DC, SUA: US Department of Commerce (DoC).

Whadcock, I. 2012. „A treia revoluție industrială”. The Economist. 21 aprilie 2012.

Womack, J.P., D.T. Jones, and D. Roos 1990. The Machine That Changed the World (Mașina care a schimbat lumea): The Story of Lean Production. New York, NY, SUA: Rawson Associates.

Referințe principale

Blanchard, B.S., și W.J. Fabrycky. 2011. Systems Engineering and Analysis, ed. a 5-a. Prentice-Hall International series in Industrial and Systems Engineering. Englewood Cliffs, NJ, SUA: Prentice-Hall.

Forsberg, K., H. Mooz, H. Cotterman. 2005. Vizualizarea managementului de proiect, Ed. a 3-a. Hoboken, NJ: J. Wiley & Sons.

INCOSE. 2012. Manualul de inginerie a sistemelor, versiunea 3.2.2. San Diego, CA, SUA: International Council on Systems Engineering (INCOSE). INCOSE-TP-2003-002-03.2.2.

Lawson, H. 2010. A Journey Through the Systems Landscape (O călătorie prin peisajul sistemelor). London, UK: 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.

Referințe suplimentare

Chrissis, M., M. Konrad, și S. Shrum. 2003. CMMI: Orientări pentru integrarea proceselor și îmbunătățirea produselor. New York, NY, SUA: Addison Wesley.

Larman, C. și B. Vodde. 2009. Scalarea dezvoltării Lean și Agile. New York, NY, SUA: Addison Wesley.

Cele trei cărți următoare nu sunt menționate în textul SEBoK și nici nu sunt „texte” de inginerie a sistemelor; cu toate acestea, ele conțin lecții importante de inginerie a sistemelor, iar cititorii acestui SEBOK sunt încurajați să le citească.

Kinder, G. 1998. Corabia de aur în Marea Albastră. New York, NY, SUA: Grove Press.

Este o carte excelentă care urmărește o idee de la început până la implementarea ei cu succes în cele din urmă. Deși nu se discută despre ingineria sistemelor, aceasta este ilustrată în mod clar în întregul proces, de la definirea inițială a proiectului, la dezvoltarea unui concept alternativ, la explorarea pe etape și „experimentele de gândire”, până la abordarea provocărilor pe parcurs. Se arată, de asemenea, problema neanticipării problemelor critice în afara proiectului obișnuit și a domeniului de aplicare al ingineriei. A fost nevoie de aproximativ cinci ani pentru a localiza și recupera cele 24 de tone de lingouri și monede de aur de pe nava scufundată în oceanul adânc de 2 500 de metri, dar a fost nevoie de zece ani pentru a câștiga bătălia juridică cu avocații care reprezentau companiile de asigurări care revendicau proprietatea pe baza unor polițe vechi de 130 de ani pe care le-au emis proprietarilor de aur în 1857.

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

Deși „ingineria sistemelor” nu este menționată, această carte evidențiază multe probleme de inginerie a sistemelor și ilustrează necesitatea SE ca disciplină. Cartea ilustrează, de asemenea, pericolul de a aplica un concept de succes anterior (canalul la nivelul mării folosit în Suez cu un deceniu mai devreme) într-o situație similară, dar diferită. Ferdinand de Lesseps a condus atât proiectul Suez, cât și proiectul Panama. Cartea ilustrează pericolul lipsei unui ciclu de proiect bazat pe fapte și a unor porți de decizie semnificative pe tot parcursul ciclului de proiect. De asemenea, evidențiază pericolul de a oferi statutul proiectului fără vizibilitate. După cinci ani de la începerea proiectului de zece ani, investitorilor li s-a spus că proiectul era finalizat în proporție de peste 50 %, când, de fapt, doar 10 % din lucrări erau finalizate. A doua rundă de dezvoltare sub conducerea lui Stevens, în 1904, s-a concentrat pe „mutarea pământului”, mai degrabă decât pe săparea unui canal, un concept de inginerie a sistemelor care a fost esențial pentru finalizarea canalului. The Path Between the Seas a fost distins cu National Book Award pentru istorie (1978), Francis Parkman Prize (1978), Samuel Eliot Morison Award (1978) și Cornelius Ryan Award (1977).

Shackleton, Sir E.H. 2008. (publicat inițial în de William Heinemann, Londra, 1919). Sud: The Last Antarctic Expedition of Shackleton and the Endurance. Guilford, CT, SUA: Lyons Press.

Aceasta este povestea uimitoare a ultimei expediții antarctice a lui Shackleton și a lui Endurance în Antarctica între 1914 și 1917. Lecția de inginerie a sistemelor este evaluarea continuă și zilnică a riscurilor de către căpitanul, conducătorul expediției și echipaj în timp ce aceștia au rămas blocați în gheața arctică timp de 18 luni. Toți cei 28 de membri ai echipajului au supraviețuit.

VIDEOURI RELEVANTE

• Abordarea NASA la ingineria sistemelor- Space Systems Engineering 101 w/ NASA