Procesele software

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Procesele software


Obiective

Modele pentru procesele software Trei modele generice de procese şi când pot fi

utilizate Schiţarea modelelor proceselor pentru ingineria

cerinţelor, dezvoltarea software-lui, testare şi evoluţie

Explicarea modelului RUP (Rational Unified Process)

Tehnologia CASE în sprijinirea activităţilor procesului software


Subiecte acoperite

Modele pentru procesul software Iterarea procesului Activităţile procesului RUP (Rational Unified Process) CASE (Computer-aided software engineering)


Procesul software

Def. Proces software = set structurat de activităţi necesare pentru dezvoltarea unui sistem software• specificare;

• proiectare;

• validare;

• evoluţie.

Def. Model pentru proces software = reprezentare abstractă a unui proces. Prezintă o descriere a unui proces dintr-o perspectivă particulară.


Modele generice pentru procesul software

Modelul cascadă (waterfall)• Etape separate şi disticte de specificare şi de dezvoltare.

Dezvoltare evolutivă• Specificarea, dezvoltarea şi validarea sunt intercalate.

CBSE (Component-based software engineering)• Sistemul este asamblat din componente existente.

Există variante multiple ale acestor modele. De exemplu, dezvoltarea formală unde se utilizează un proces de tip cascadă dar specificarea este o specificare formală care este rafinată de-a lungul mai multor stadii pentru a deveni un proiect implementabil.


Modelul cascadă

Requirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation and

maintenance


Etapele modelului cascadă

Analiza şi definirea cerinţelor Proiectarea sistemului şi a software-lui Implementarea şi testarea unităţilor Integrarea şi testarea sistemului Operarea şi întreţinereaPrincipalul dezavantaj al modelului cascadă constă în

dificultatea adaptării modificărilor după ce procesul demarat. Înainte de a se trece la o nouă etapă este necesară încheierea celei precedente.


Problematica modelului cascadă

Partiţionarea inflexibilă a proiectului în stadii distincte face dificil răspunsul la modificarea cerinţelor clientului.

Modelul este potrivit doar în cazurile în care cerinţele sunt bine înţelese şi modificările vor fi în limite acceptabile în timpul procesului de dezvoltare.

Puţine sisteme business au cerinţe stabile. Modelul cascadă este folosit în special pentru proiecte de

ingineria sistemelor mari, unde un sistem este dezvoltat pe mai multe sit-uri.


Dezvoltare evolutivă

Dezvoltare exploratorie• Obiectivul este acela de a lucra cu clienţii şi de a

dezvolta un sistem final dintr-o specificare schiţată iniţial. Trebuie să se înceapă cu cerinţe bine înţelese şi să se adauge caracteristici noi pe baza propunerilor clientului.

Prototipare (Throw-away prototyping)• Obiectivul este acela de a înţelege cerinţele

sistemului. Trebuie să se înceapă cu cerinţele puţin înţelese şi să se clarifice ceea ce este necesar cu adevărat.



Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription



Probleme• Lipsa vizibilităţii procesului;• Sistemele sunt deseori slab structurate;• Pot fi necesare calificări speciale (e.g. în limbaje pentru

prototipare rapidă). Aplicabilitate

• Pentru sisteme interactive de dimesiuni mici sau mijlocii;

• Pentru părţi din sisteme mari (e.g. interfaţa utilizator);• Pentru sisteme cu durate mici de viaţă.


CBSE (Component-based software engineering)

Bazată pe reutilizare sistematică, unde sistemele sunt integrate din componente existente sau sisteme COTS (Commercial-off-the-shelf).

Etapele procesului• Analiză componente;

• Modificare cerinţe;

• Proiectare sistem cu reutilizare;

• Deyvoltare şi integrare. Această abordare este din ce în ce mai mult utilizată

odată cu apariţia standardelor de componente.


Dezvoltare orientată pe reutilzare

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation


Iterare proces

Cerinţele sistemului se dezvoltă ÎNTOTDEAUNA în cursul unui proiect astfel încât reiterarea, în care primele etape sunt reluate, este întotdeauna parte a procesului pentru sisteme mari.

Iterarea se poate aplica oricărui model generic de proces software.

Două abordări (corelate)• Furnizare incrementală;

• Dezvoltare în spirală.


Furnizare incrementală

În loc de a livra sistemul deodată, dezvoltarea şi livrarea sunt divizate în incremente cu fiecare increment livrând o parte a funcţionalităţii cerute.

Cerinţele utilizatorului sunt prioritizate şi cerinţele cu cele mai mari priorităţi sunt incluse în primele incremente.

Odată ce a fost pornită dezvoltarea unui increment, cerinţele sunt îngheţate deşi cerinţele pentru următoarele incremente pot continua să evolueze.


Dezvoltare incrementală

Validateincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem


Avantajele dezvoltării incrementale

Se poate furniza valoare la client cu fiecare increment, astfel încât funcţionalitatea sistemului este disponibilă mai devreme.

Primele incremente acţionează ca un prototip care ajută la obţinerea cerinţelor pentru incrementele următoare.

Risc mai scăzut de eşuare a întregului proiect. Serviciile sistemului cu priorităţi mari tind să fie

testate mai mult.


Programare extremă

Abordare a dezvoltării bazată pe dezvoltarea şi furnizarea de incremente de funcţionalitate foarte mici.

Se bazează pe:

• îmbunătăţirea constantă a codului,• implicarea utilizatorului în echipa de

dezvoltare,• programare în mod pereche (pairwise).


Dezvoltare în spirală

Procesul este reprezentat sub formă de spirală (în loc de secvenţă de activităţi cu reluare).

Fiecare buclă din spirală reprezintă o etapă în proces.

Nu există faze fixe ca specificare sau proiectare – buclele din spirală sunt alese funcţie de ceea ce este necesar.

Risurile sunt evaluate explicit şi rezolvate de-a lungul procesului.


Modelul spirală al procesului software

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


Sectoarele modelului spirală

Stabilire obiective • Sunt identificate obiectivele specifice etapei.

Evaluare şi reducere risc• Riscurile sunt evaluate şi se realizează activităţi pentru

reducerea riscurilor cheie. Dezvoltare şi validare

• Se alege un model de dezvoltare pentru sistem, care poate fi oricare din modelele generice.

Planificare• Proiectul este revăzut şi se planifică următoarea etapă

a spiralei.


Activităţile procesului

Specificarea software-lui Proiectarea şi implementarea software-lui Validarea software-lui Evoluţia software-lui


Specificarea software-lui

Def. Procesul de stabilire a serviciilor cerute şi a constrângerilor asupra operării şi dezvoltării sistemului.

Procesul pentru ingineria cerinţelor• Studiu de fezabilitate;

• Obţinere şi analiză cerinţe;

• Specificare cerinţe;

• Validare cerinţe.


Procesul pentru ingineria cerinţelor

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument


Proiectarea şi implementarea software-lui

Def. Procesul de convertire a specificaţiilor sistemului într-un sistem executabil.

Proiectare software• Proiectarea unei structuri software care realizează

specificaţiile; Implementatare

• Translatarea acestei structuri într-un program executabil;

Activităţile de proiectare şi implementare sunt strâns corelate şi pot fi intercalate.


Activităţile procesului de proiectare a software-lui

Proiectare arhitecturală Specificare abstractă Proiectare interfaţă Proiectare componente Proiectare structură de date Proiectare algoritm


Procesul de proiectare a software-lui

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification


Design activities

Design products


Metode structurate

Def. Abordări sistematice ale proiectării software-lui.

Proiectul este documentat (în mod uzual) sub formă de set de modele grafice.

Modele posibile• Model obiecte;• Model secvenţe;• Model tranziţii de stare;• Model structural;• Model al fluxului de date.


Programare şi depanare

Def. Traducerea proiectului într-un program şi eliminarea erorilor din acel program.

Programarea este o activitate personală – nu există un proces generic pentru această activitate.

Programatorii realizează o testare iniţială a programului în cursul operaţiei de depanare (debugging) pentru a descoperi şi corecta erori ale programului.


Procesul de depanare

Locateerror

Designerror repair

Repairerror

Re-testprogram


Validarea software-lui

Verificarea şi validarea (V & V) are scopul de a arăta că sistemul se conformează specificaţiilor sale şi îndeplineşte cerinţele clientului sistemului.

Implică procese de verificare/control şi revizuire şi testarea sistemului.

Testarea sistemului implică executarea sistemului cu cazuri de testare care sunt derivate din specificarea de date reale ce trebuie procesate de sistem.


Procesul de testare

Componenttesting

Systemtesting

Acceptancetesting


Stadiile testării

Testare componente sau unităţi• Componentele individuale sunt testate independent; • Componentele pot fi funcţii sau obiecte sau grupuri

coerente de astfel de entităţi. Testare sistem

• Testarea sistemului în ansamblu. Testarea proprietăţilor emergente are o importanţă specială.

Teste de acceptare• Testare cu datele clientului pentru a verifica dacă

sistemul îndeplineşte cerinţele acestuia.


Etapele testării


Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand test

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test


Evoluţia software-lui

Software-ul este în mod inerent flexibil şi se poate modifica.

Pe măsură ce cerinţele se modifică odată cu modificarea circumstanţelor business, software-ul suport pentru business trebuie, de asemenea, să evolueze şi să se schimbe.

Deşi s-a făcut demarcarea între dezvoltare şi evoluţie (întreţinere), aceasta devine din ce în ce mai nerelevantă pe măsură ce din ce în ce mai puţine sisteme sunt complet noi.


Evoluţia sistemului

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems


RUP (Rational Unified Process)

Model modern pentru procesul software derivat din UML şi procesele asociate elaborării acestuia.

Descris din 3 perspective• Perspectivă dinamică – arată repartizarea

etapelor în timp;

• Perspectivă statică – arată activităţile procesului;

• Perspectivă practică - sugerează practici bune.


Modelul etapelor RUP

Phase iteration

Inception Elaboration Construction Transition


Etapele RUP

Concepţie• Stabilirea cazului business pentru sistem.

Elaborare• Dezvoltarea unei înţelegeri a domeniului

problemei şi a athitecturii sistemului. Construire

• Proiectarea sistemului, programarea şi testarea. Tranziţie

• Repartizarea (deploy) sistemului în contextul său de operare.


Practici bune RUP

Dezvoltare iterativă a software-lui Managementul cerinţelor Utilizare de arhitecturi bazate pe componente Modelare vizuală a software-lui Verificarea calităţii software-lui Controlul modificărilor în software


Fluxuri statice de activităţiFlux de activităţi (workflow) Descriere

Modelare business Procesele business sunt modelate utilizând cazuri de utilizare business.

Cerinţe Se identifică actorii care interacţionează cu sistemul şi sunt elaborate cazuri de utilizare pentru a modela cerinţele sistemului.

Analiză şi proiectare Se crează şi de documentează un model de proiectare utilizând modelel arhitecturale, modele de componente, modele de obiecte şi modele de secvenţe.

Implementare Componentele sistemului sunt implementate şi structurate în subsisteme de implementat. Generarea automată a codului din modelul de proiectare permite accelerarea acestui proces.

Testare Testarea este un proces iterativ desfăşurat în conjuncţie cu implementarea. Testarea sistemului are loc după finalizarea implementării.

Repartizarea (deployment) Se crează un release al produsului, se distribuie utilizatorilor şi este instalat în spaţiul lor de lucru.

Managementul configuraţiilor şi al modificărilor

Flux de activităţi suportativ care gestionează modificările la sistem.

Managementul proiectului Flux de activităţi suportativ care gestionează dezvoltarea sistemului.

Context Flux de activităţi care se ocupă cu punerea la dispoziţie de instrumente software pentru echipa de dezvoltare a software-lui.


CASE (Computer-aided software engineering)

CASE (Computer-aided software engineering) este software folosit ca suport pentru procesele de dezvoltare de software şi de evoluţie a software-lui.

Automatizare activităţi• Editoare grafice pentru dezvoltarea modelului sistemului;• Dicţionare de date pentru gestionarea entităţilor proiectării;• Constructor GUI pentru construirea interfeţei utilizator;• Debugger-e pentru a sprijini găsirea erorilor în program;• Traducătoare (translator) automate pentru generare de noi

versiuni de program.


Tehnologia CASE

Tehnologia CASE a condus la îmbunătăţiri semnificative ale procesului software. Totuşi nu

atât de mult cât s-a prezis. • Ingineria software cere gândire creativă – aceasta

nu este uşor de automatizat;

• Ingineria software este o activitate de echipă şi, pentru proiectele mari, se cheltuieşte mult timp cu interacţiunile în cadrul echipei. Tehnologia CASE nu oferă suport pentru acestea.


Clasificare pentru CASE

Clasificarea ajută la înţelegerea diferitelor tipuri de instrumente CASE şi suportul oferit de ele pentru activităţile procesului (care proces?).

Perspectiva funcţională• Instrumentele sunt clasificate conform funcţiei lor specifice.

Perspectiva proces• Instrumentele sunt clasificate conform activităţilor procesului

pentru care oferă suport. Perspectiva integrării

• Instrumentele sunt clasificate conform organizării lor în unităţi integrate.


Clasificarea funcţională a instrumentelor

Tip de instrument Exemple

Pentru planificare Instrumente PERT, instrumente pentru estimare, spreadsheets

Pentru editare Editoare text, editoare diagrame, procesoare text

Pentru managementul modificărilor

Instrumente pentru urmărirea cerinţelor, sisteme pentru controlul modificărilor

Pentru managementul configuraţiilor

Sisteme pentru management versiuni, instrumente pentru construire sistem

Pentru prototipare Limbaje de nivel f. înalt, generatoare de interfaţă utilizator

Suport al metodei Editoare pentru proiectare, dicţionare de date, generatoare de cod

Pentru procesare limbaj Compilatoare, interpretoare

Pentru analiză program Generatoare de referinţe încrucişate, analizoare statice, analizoare dinamic

Pentru testare Generatoare date de test, comparatoare fişiere

Pentru depanare Sisteme pentru depanare interactivă

Pentru elaborare documentaţie

Programe de aranjare în pagină, editoare de imagini

Pentru re-inginerie Sisteme pentru referinţe încrucişate, sisteme pentru restructurare programprogram re-structuring systems


Clasificare instrumente bazată pe activităţi

Specification Design Implementation Verificationand

Validation

Re-engineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools


Integrare CASE

Instrumente• Suport pentru activităţi individuale ale

procesului, cum ar fi verificarea consistenţei proiectării, editare text,

etc. Workbench-uri

• Suport pentru o etapă a procesului cum ar fi specificare sau proiectare; în mod normal includ mai multe instrumente integrate.

Medii• Suport pentru toate sau pentru o parte

substanţială a întregului proces software. În mod normal includ mai multe workbench-uri integrate.


Instrumente, workbench-uri, medii

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis and

design

Integratedenvironments

Process-centredenvironments

Filecomparators

CompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology


Puncte cheie

Procesele software sunt activităţile implicate în producerea şi evoluţia unui sistem software.

Modelele proceselor software sunt reprezentări abstracte ale acestor procese.

Activităţile generale sunt specificarea, proiectarea şi implementarea, validarea şi evoluţia.

Modelele generice ale proceselor descriu organizarea proceselor software. Exemplele includ modelul cascadă, modelul dezvoltării evolutive şi ingineria software bazată pe componente.

Modelele iterative ale procesului descriu procesul software process sub formă de ciclu de activităţi.


Puncte cheie

Ingineria cerinţelor este procesul de dezvoltare a specificaţiilor software-lui.

Procesele de proiectare şi implementare transformă specificaţiile în program executabil.

Validarea implică controlarea faptului că sistemele îşi îndeplinesc specificaţiile şi necesităţile utilizatorului.

Evoluţia se referă la modificarea sistemului după ce a fost dat în exploatare.

RUP (Rational Unified Process) este un model generic de proces care separă activităţile de etape.

Tehnologia CASE oferă suport pentru activităţile procesului software.

Documents

Procesele software