Referință: Sommerville, Software Engineering, 10 ed., Capitolul 2

Imaginea de ansamblu

Un proces software este un set structurat de activități necesare pentru a dezvolta un sistem software. Rețineți că vorbim despre un „proces software” — nu despre un „proces de dezvoltare software”.”

Există multe tipuri diferite de procese software, dar fiecare dintre ele implică aceste patru tipuri de activități fundamentale:

• Specificarea software – definirea a ceea ce ar trebui să facă sistemul;
• Proiectarea și implementarea software – definirea organizării sistemului și implementarea sistemului;
• Validarea software-ului – verificarea faptului că acesta face ceea ce dorește clientul;
• Evoluția software-ului – schimbarea sistemului ca răspuns la schimbarea nevoilor clientului.

Un model de proces software este o reprezentare abstractă a unui proces. El prezintă o descriere a unui proces dintr-o anumită perspectivă. Atunci când descriem și discutăm procesele software, vorbim de obicei despre activitățile din aceste procese, cum ar fi specificarea unui model de date, proiectarea unei interfețe utilizator etc. și ordonarea acestor activități.Descrierile proceselor pot include, de asemenea:

• Produse, care sunt rezultatele unei activități de proces;
• Roluri, care reflectă responsabilitățile persoanelor implicate în proces;
• Pre-condiții și post-condiții, care sunt afirmații care sunt adevărate înainte și după ce o activitate de proces a fost pusă în aplicare sau un produs a fost realizat.

Procesele bazate pe plan sunt procese în care toate activitățile procesului sunt planificate în avans, iar progresul este măsurat în raport cu acest plan. În procesele agile, planificarea este incrementală și este mai ușor să se modifice procesul pentru a reflecta cerințele în schimbare ale clienților. În practică, cele mai multe procese practice includ elemente atât ale abordărilor bazate pe planificare, cât și ale celor agile.

Modelul în cascadă Model bazat pe plan. Faze separate și distincte de specificare, proiectare software, implementare, testare și întreținere. Dezvoltare incrementală Specificația, dezvoltarea și validarea sunt intercalate. Sistemul este dezvoltat ca o serie de versiuni (incremente), fiecare versiune adăugând funcționalitate la versiunea anterioară. Poate fi bazată pe plan sau agilă. Integrare și configurare Bazată pe existența unui număr semnificativ de componente/sisteme reutilizabile. Procesul de dezvoltare a sistemului se concentrează pe integrarea acestor componente într-un sistem, mai degrabă decât pe dezvoltarea lor de la zero. Poate fi bazat pe planificare sau agil.

În practică, cele mai multe sisteme mari sunt dezvoltate folosind un proces care încorporează elemente din toate aceste modele.

În modelul în cascadă sunt identificate faze distincte:

Analiza și definirea cerințelor Serviciile, constrângerile și obiectivele sistemului sunt stabilite prin consultare cu utilizatorii sistemului. Ele sunt apoi definite în detaliu și servesc drept specificație a sistemului. Proiectarea sistemului și a software-ului Procesul de proiectare a sistemelor alocă cerințele fie la sisteme hardware, fie la sisteme software prin stabilirea unei arhitecturi generale a sistemului. Proiectarea software presupune identificarea și descrierea abstracțiunilor fundamentale ale sistemului software și a relațiilor dintre acestea. Implementarea și testarea unitară În această etapă, proiectarea software este realizată sub forma unui set de programe sau unități de program. Testarea unitară presupune verificarea faptului că fiecare unitate îndeplinește specificațiile sale. Integrarea și testarea sistemului Unitățile de program sau programele individuale sunt integrate și testate ca un sistem complet pentru a se asigura că cerințele software au fost îndeplinite. După testare, sistemul software este livrat clientului. Operare și întreținere În mod normal (deși nu neapărat), aceasta este cea mai lungă fază a ciclului de viață. Sistemul este instalat și pus în practică. Întreținerea implică corectarea erorilor care nu au fost descoperite în etapele anterioare ale ciclului de viață, îmbunătățirea implementării unităților sistemului și îmbunătățirea serviciilor sistemului pe măsură ce sunt descoperite noi cerințe.

Principalul dezavantaj al modelului în cascadă este dificultatea de a acomoda schimbările după ce procesul este în desfășurare. În principiu, o fază trebuie să fie finalizată înainte de a trece la faza următoare. Printre problemele modelului în cascadă se numără:

Dificultatea de a aborda schimbările Împărțirea inflexibilă a proiectului în etape distincte face dificilă reacția la cerințele în schimbare ale clienților. prin urmare, acest model este adecvat numai atunci când cerințele sunt bine înțelese și schimbările vor fi destul de limitate în timpul procesului de proiectare. Puține sisteme de afaceri au cerințe stabile. Foarte puține aplicații în lumea reală Modelul în cascadă este utilizat în principal pentru proiecte mari de inginerie a sistemelor, în care un sistem este dezvoltat în mai multe locații. în aceste circumstanțe, natura orientată spre plan a modelului în cascadă ajută la coordonarea activității.

Beneficii ale dezvoltării incrementale:

Cost mai mic al modificărilor Costul adaptării la cerințele în schimbare ale clienților este redus. Cantitatea de analiză și documentație care trebuie refăcută este mult mai mică decât cea necesară în cazul modelului waterfall. Feedback frecvent Este mai ușor de obținut feedback din partea clientului cu privire la activitatea de dezvoltare care a fost efectuată. Clienții pot comenta demonstrațiile de software și pot vedea cât de mult a fost implementat. Livrare mai rapidă Este posibilă livrarea și implementarea mai rapidă a unui software util pentru client. Clienții sunt capabili să utilizeze și să obțină valoare din software mai devreme decât este posibil cu un proces în cascadă.

Probleme cu dezvoltarea incrementală (din perspectiva managementului):

Procesul nu este vizibil Managerii au nevoie de livrabile regulate pentru a măsura progresul. Dacă sistemele sunt dezvoltate rapid, nu este rentabil să se producă documente care să reflecte fiecare versiune a sistemului. Structura sistemului tinde să se degradeze pe măsură ce se adaugă noi incrementări Dacă nu se cheltuiesc timp și bani pentru refactorizare în vederea îmbunătățirii software-ului, schimbările regulate tind să corupă structura acestuia. Încorporarea modificărilor ulterioare ale software-ului devine din ce în ce mai dificilă și mai costisitoare.

Această abordare se bazează pe reutilizarea sistematică în care sistemele sunt integrate din componente existente sau din sisteme COTS (Commercial-off-the-shelf). etapele procesului includ:

• Analiza componentelor;
• Modificarea cerințelor;
• Proiectarea sistemului cu reutilizare;
• Dezvoltarea și integrarea.

Reutilizarea este acum abordarea standard pentru construirea multor tipuri de sisteme de afaceri.

Tipuri de componente software:

• Servicii Web care sunt dezvoltate în conformitate cu standardele de servicii și care sunt disponibile pentru invocare de la distanță.
• Colecții de obiecte care sunt dezvoltate sub formă de pachet pentru a fi integrate cu un cadru de componente, cum ar fi .NET sau J2EE.
• Sisteme comerciale de sine stătătoare (COTS) care sunt configurate pentru a fi utilizate într-un anumit mediu.

Procesele software reale sunt secvențe intercalate de activități tehnice, de colaborare și manageriale cu scopul general de a specifica, proiecta, implementa și testa un sistem software.

Cele patru activități de bază ale procesului de specificație, dezvoltare, validare și evoluție sunt organizate diferit în diferite procese de dezvoltare. În modelul în cascadă, acestea sunt organizate în succesiune, în timp ce în dezvoltarea incrementală sunt intercalate.

Specificarea software-ului Procesul de stabilire a serviciilor necesare și a constrângerilor asupra funcționării și dezvoltării sistemului. Procesul de inginerie a cerințelor:

• Studiu de fezabilitate: este fezabil din punct de vedere tehnic și financiar să se construiască sistemul?
• Elicitarea și analiza cerințelor: ce cer sau ce așteaptă părțile interesate de sistem de la sistem?
• Specificarea cerințelor: definirea în detaliu a cerințelor
• Validarea cerințelor: verificarea validității cerințelor

Proiectarea și implementarea software-ului Procesul de convertire a specificației sistemului într-un sistem executabil.

• Proiectarea software: proiectarea unei structuri software care realizează specificația;
• Implementarea: transpunerea acestei structuri într-un program executabil;

Activitățile de proiectare și implementare sunt strâns legate și pot fi intercalate. Activitățile de proiectare includ:

• Proiectarea arhitecturală: identifică structura generală a sistemului, componentele principale (numite uneori subsisteme sau module), relațiile dintre ele și modul în care sunt distribuite.
• Proiectarea interfețelor: definește interfețele dintre componentele sistemului.
• Proiectarea componentelor: se ia fiecare componentă a sistemului și se proiectează modul în care aceasta va funcționa.
• Proiectarea bazei de date: se proiectează structurile de date ale sistemului și modul în care acestea vor fi reprezentate într-o bază de date.

Validarea software-ului Verificarea și validarea (V & V) are scopul de a demonstra că un sistem este conform cu specificațiile sale și îndeplinește cerințele clientului sistemului.

• Validare: construim produsul corect (ceea ce dorește clientul)?
• Verificare: construim produsul corect?

V & V implică procese de verificare și revizuire și testarea sistemului. Testarea sistemului implică executarea sistemului cu cazuri de testare care sunt derivate din specificația datelor reale care urmează să fie procesate de sistem. Testarea este cea mai frecvent utilizată activitate V & V și include următoarele etape:

• Testarea dezvoltării sau a componentelor: componentele individuale sunt testate independent; componentele pot fi funcții sau obiecte sau grupări coerente ale acestor entități.
• Testarea sistemului: testarea sistemului ca întreg, testarea proprietăților emergente este deosebit de importantă.
• Testarea de acceptare: testarea cu datele clientului pentru a verifica dacă sistemul satisface nevoile clientului.

Evoluția software-ului Software-ul este în mod inerent flexibil și se poate schimba. Pe măsură ce cerințele se modifică prin schimbarea circumstanțelor afacerii, software-ul care susține afacerea trebuie, de asemenea, să evolueze și să se schimbe. deși a existat o demarcație între dezvoltare și evoluție (întreținere), aceasta este din ce în ce mai irelevantă, deoarece tot mai puține sisteme sunt complet noi.

Schimbarea este inevitabilă în toate proiectele mari de software.schimbările de afaceri duc la cerințe de sistem noi și modificateTehnologiile noi deschid noi posibilități de îmbunătățire a implementărilor.schimbarea platformelor necesită modificări ale aplicațiilor.schimbarea duce la reluarea lucrărilor, astfel încât costurile schimbării includ atât reluarea lucrărilor (de ex.ex. reanalizarea cerințelor) cât și costurile de implementare a noilor funcționalități.

Două strategii de reducere a costurilor de reluare a lucrărilor:

Evitarea modificărilor Procesul software include activități care pot anticipa posibilele modificări înainte de a fi necesară o reluare semnificativă. De exemplu, se poate dezvolta un sistem prototip pentru a arăta clienților unele caracteristici cheie ale sistemului. Toleranța la schimbare Procesul este conceput astfel încât modificările să poată fi acomodate la un cost relativ scăzut. în mod normal, acest lucru implică o anumită formă de dezvoltare incrementală. Modificările propuse pot fi puse în aplicare în intervale care nu au fost încă dezvoltate. În cazul în care acest lucru este imposibil, atunci este posibil ca doar un singur increment (o mică parte a sistemului) să trebuiască să fie modificat pentru a încorpora schimbarea.

Un prototip este o versiune inițială a unui sistem utilizat pentru a demonstra concepte și a încerca opțiuni de proiectare. Un prototip poate fi utilizat în:

• Procesul de inginerie a cerințelor pentru a ajuta la elicitarea și validarea cerințelor;
• În procesele de proiectare pentru a explora opțiunile și a dezvolta un design al interfeței de utilizator;
• În procesul de testare pentru a rula teste back-to-back.

Beneficii ale prototipării:

• Ambunătățirea capacității de utilizare a sistemului.
• O potrivire mai strânsă cu nevoile reale ale utilizatorilor.
• Ambunătățirea calității proiectării.
• Ambunătățirea mentenabilității.
• Reducerea efortului de dezvoltare.

Prototipurile se pot baza pe limbaje sau instrumente de prototipare rapidă. Ele pot implica renunțarea la funcționalitate:

• Prototipul ar trebui să se concentreze pe zone ale produsului care nu sunt bine înțelese;
• Controlul și recuperarea erorilor pot să nu fie incluse în prototip;
• Concentrarea pe cerințele funcționale mai degrabă decât pe cele nefuncționale, cum ar fi fiabilitatea și securitatea.

Prototipurile ar trebui să fie aruncate după dezvoltare, deoarece nu reprezintă o bază bună pentru un sistem de producție:

• Poate fi imposibil de reglat sistemul pentru a îndeplini cerințele nefuncționale;
• Prototipurile sunt în mod normal nedocumentate;
• Structura prototipului este de obicei degradată prin schimbări rapide;
• Prototipul probabil nu va îndeplini standardele normale de calitate ale organizației.

În loc să livreze sistemul sub forma unei singure livrări, dezvoltarea și livrarea sunt împărțite în trepte, fiecare treaptă livrând o parte din funcționalitatea necesară.Cerințele utilizatorilor sunt prioritizate, iar cerințele cu cea mai mare prioritate sunt incluse în primele incrementări.Odată începută dezvoltarea unui increment, cerințele sunt înghețate, deși cerințele pentru incrementările ulterioare pot continua să evolueze.

Avantajele livrării incrementale:

• Valoarea clientului poate fi livrată cu fiecare increment, astfel încât funcționalitatea sistemului este disponibilă mai devreme.
• Cele mai timpurii incremente acționează ca un prototip pentru a ajuta la elucidarea cerințelor pentru incrementele ulterioare.
• Risc mai mic de eșec global al proiectului.
• Serviciile de sistem cu cea mai mare prioritate tind să primească cele mai multe teste.

Probleme ale livrării incrementale:

• Majoritatea sistemelor necesită un set de facilități de bază care sunt utilizate de diferite părți ale sistemului. Deoarece cerințele nu sunt definite în detaliu până când nu se implementează un increment, poate fi dificil să se identifice facilitățile comune care sunt necesare pentru toate incrementările.
• Esența proceselor iterative constă în faptul că specificația este dezvoltată împreună cu software-ul. Cu toate acestea, acest lucru intră în conflict cu modelul de achiziție al multor organizații, în care specificația completă a sistemului face parte din contractul de dezvoltare a sistemului.

Multe companii de software au apelat la îmbunătățirea proceselor software ca o modalitate de a spori calitatea software-ului lor, de a reduce costurile sau de a accelera procesele de dezvoltare. Îmbunătățirea proceselor înseamnă înțelegerea proceselor existente și modificarea acestor procese pentru a crește calitatea produsului și/sau a reduce costurile și timpul de dezvoltare.

Abordarea maturității proceselor Se concentrează pe îmbunătățirea managementului de proces și de proiect și pe introducerea de bune practici de inginerie software. Nivelul de maturitate a procesului reflectă măsura în care bunele practici tehnice și de management au fost adoptate în procesele organizaționale de dezvoltare software. Abordare agilă Se concentrează pe dezvoltarea iterativă și pe reducerea cheltuielilor generale în procesul software. Caracteristicile principale ale metodelor agile sunt livrarea rapidă a funcționalității și capacitatea de reacție la cerințele în schimbare ale clienților.

Activitățile de îmbunătățire a procesului formează un ciclu continuu cu o buclă de feedback:

• Măsurați unul sau mai multe atribute ale procesului sau produsului software. Aceste măsurători formează o bază de referință care ajută să se decidă dacă îmbunătățirile procesului au fost eficiente.
• Analizați procesul actual și identificați orice blocaje.
• Modificați procesul pentru a aborda unele dintre punctele slabe identificate ale procesului. Acestea sunt introduse și ciclul se reia pentru a colecta date despre eficacitatea schimbărilor.

Măsurarea procesului

• Dacă este posibil, ar trebui colectate date cantitative despre proces.
• Măsurătorile procesului ar trebui să fie folosite pentru a evalua îmbunătățirile procesului.
• Măsurătorile pot include:
  • Timpurile necesare pentru ca activitățile procesului să fie finalizate, de ex.de exemplu, timpul calendaristic sau efortul pentru a finaliza o activitate sau un proces.
  • Resursele necesare pentru procese sau activități, de exemplu, efortul total în zile-persoană.
  • Numărul de apariții ale unui anumit eveniment, de exemplu, numărul de defecte descoperite.

Modelul SEI de maturitate a capabilităților

• Inițial: În esență necontrolat

Repetabil: Proceduri de management al produsului definite și utilizate

• Definite: Proceduri și strategii de gestionare a proceselor definite și utilizate

Gestionate: Strategii de management al calității definite și utilizate

• Optimizare: Strategii de îmbunătățire a proceselor definite și utilizate