Procese software

- introducere -
 Proces software

“Because software, like all capital, is embodied knowledge, and

because that knowledge is initially dispersed, tacit, latent, and
incomplete in large measure, software development is a social
learning process. The process is a dialogue in which the knowledge
that must become the software is brought together and embodied in
the software. The process provides interaction between users and
designers, between users and evolving tools, and between designers
and evolving tools [technology]. It is an iterative process in which the
evolving tool itself serves as the medium for communication, with each
new round of the dialogue eliciting more useful knowledge from the
people involved.”

Howard Baetjer, Jr.

Ce este procesul software?
O “hartă” a drumului ce trebuie urmat pentru construirea unui
produs sau sistem, de calitate crescută şi într-un timp dat.

Cine face procesul software?

Inginerii de sistem (software engineers) şi managerii lor; sunt
implicaţi şi cei cărora li se adresează.

De ce este important procesul software?

Deoarece dovedeşte stabilitate, control şi organizare.

Care sunt paşii?

Depind de software-ul pe care îl construim.

Care este produsul muncii?

În ochii inginerului de sistem produsul este format din programe,
documentaţie şi datele produse ca urmare a activităţii de inginerie
software definită de proces.
 Proces software – o tehnologie pe nivele

IEEE defineşte astfel Ingineria software:

(1) Aplicarea unei abordări sistematice, disciplinate, cuantificabile
asupra dezvoltării, punerii în funcţiune şi mentenanţei software-ului
(2) Studiul abordărilor de la (1).
Nivelul Proces: defineşte un cadru pentru o mulţime de zone cheie de
proces (key process areas). Aceste zone formează baza controlului
managementului proiectului software şi stabileşte contextul în care sunt
aplicate metodele tehnice, sunt obţinute produsele muncii (modele,
documente, date, rapoarte, forme etc.), sunt stabilite “pietrele de hotar”
(milestones), e asigurată calitatea şi se administrează potrivit schimbările.

Nivelul Metode: răspunde la întrebarea : Cum construim software-ul? şi

cuprinde un spectru larg de sarcini, care includ: analiza cerinţelor,
designul, construirea programului şi testarea. Metodele de inginerie
software includ activităţi de modelare şi alte tehnici descriptive.

Nivelul Instrumente: furnizează suport automat pentru proces şi metode.

Când instrumentele sunt integrate, astfel încât informaţiile create de un
instrument să fie folosite de altul, se creează CASE (Computer Aided
Software Engineering), care combină software, hardware şi o bază de
date a ingineriei software (ce conţine informaţii importante despre analiză,
design, construcţia programului şi testare).
 Modele de procese software

1) Modelul secvenţial liniar

2) Modelul prototipului (prototyping model)

3) Modelul RAD

4) Modele pentru procese software evolutive

a) Modelul incremental

b) Modelul spirală

c) Modelul spiral WINWIN

d) Modelul de dezvoltare concurentă

1) Modelul secvenţial liniar (cascadă)

Presupune activităţile:
i) Ingineria de sistem şi modelarea: stabilirea cerinţelor pentru elementele
sistemului
ii) Analiza cerinţelor software: trebuie înţelese comportarea software-ului,
interfaţa, performanţele dorite etc.
iii) Design: e de fapt un proces în mai mulţi paşi, ce se concentrează pe :
structura datelor, arhitectura software-ului, reprezentarea interfeţei şi
detaliul procedural (algoritmic).
iv) Generarea codului: care translatează design-ul în program.

v) Testarea: depistarea eventualelor erori (errors), defecte (faults) şi

eşecuri (failures)

Obs. Modelul cascadă e cel mai vechi; apar însă problemele:

• Proiectele reale urmează rar acest model
• E foarte dificil pentru client să stabilească cu exactitate cerinţele
• O versiune care să poate fi prezentată poate veni după mult timp
• Natura liniară a modelului poate conduce la stări de blocaj, când o
echipă implicată în proiect este nevoită să aştepte rezultatele altor
echipe

Obs. Modelul secvenţial liniar e cunoscut în literatură sub denumirea

classic life cycle.
2) Modelul prototipului
Adesea, un client defineşte o serie de obiective pentru software, dar nu
identifică în detaliu cerinţele de input, de procesare sau de ieşire. În alte
cazuri, dezvoltatorul poate să aibă îndolieli cu privire la eficienţa
algoritmului, adaptabilitatea la un SO sau la forma de interacţiune
om/calculator. Pentru aceste e indicat acest model.
Clientul şi dezvoltatorul se întâlnesc pentru a stabili obiectivele de
ansamblu şi a identifica oricare dintre cerinţele care sunt cunoscute şi
a stabili zonele unde e obligatorie definirea lor ulterioară.

Se conturează astfel un “quick design”, care se axează pe

reprezentarea acelor aspecte ale software-ului care care sunt vizibile
clientului (ex: ce anume se aşteaptă la input şi formatul output-ului).

Apare un prototip. Prototipul e evaluat de client şi folosit pentru a

rafina cerinţele.

Apare iteraţia, care pune în acord cerinţele clientului cu proiectul şi

ajută pe dezvoltator să înţeleagă mai bine ce se doreşte.
Ce facem cu prototipul dacă îndeplineşte condiţiile?

“In most projects, the first system built is barely usable. It may be too
slow, too big, awkward in use or all three. There is no alternative but to
start again, smarting but smarter, and build a redesigned version in
which these problems are solved . . . When a new system concept or
new technology is used, one has to build a system to throw away, for
even the best planning is not so omniscient as to get it right the first
time. The management question, therefore, is not whether to build a
pilot system and throw it away. You will do that. The only question is
whether to plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers . . .” (Brooks, F., The Mythical Man-
Month, Addison-Wesley, 1975.)

Concluzie. Deşi pot apărea probleme, modelul prototipului poate fi

paradigma eficientă pentru ingineria software.
3) Modelul RAD
Rapid application development (RAD) e un model de proces de
dezvoltare software incrementală, care pune accentul pe ciclul de
dezvoltare extrem de scurt.
Modelul RAD e o adaptare “high-speed” a modelului secvenţial liniar.
Modelul RAD cuprinde următoarele etape:
i) Business modeling. Fluxul informaţiilor printre funcţiile business e
modelat într-un mod ce răspunde la întrebările:
• Ce informaţii conduc procesul de business?
• Ce informaţii sunt generate?
• Cine le generează?
• Unde se duc informaţiile?
• Cine le procesează?

ii) Data modeling. Fluxul informaţiilor ca parte a etapei de business

modeling sunt rafinate într-o mulţime de obiecte de date necesare
pentru a susţine business-ul.
iii) Process modeling. Obiectele de date obţinute în etapa anterioară
sunt transformate pentru a obţine fluxul de informaţii necesar pentru a
implementa o funcţie business. Descrierile de proces sunt create pentru
adăugarea, modificarea, ştergerea şi găsirea unui obiect de date.

iv) Generarea aplicaţiei. RAD presupune folosirea 4GT (fourth

generation technique). Procesul RAD lucrează pentru a refolosi
componentele existente ale programului (unde se poate) sau pentru a
crea componente reutilizabile.

v) Testarea şi predarea. Deoarece RAD încurajează reutilizarea

componentelor, multe dintre ele sunt deja testate, aşa încât timpul total
de testare este redus considerabil. Totuşi noile componente trebuie
testate şi toate interfeţele trebuie atent verificate.
Fiecare funcţie majoră e acoperită separat de o echipă şi apoi e
integrată în întreg.

Concluzii
• Pentru proiecte mari, dar scalabile, RAD necesită resurse umane
importante pentru a crea numărul corect de echipe RAD.

• RAD necesită dezvoltatori şi clienţi care se obligă la activităţi rapide

necesare pentru a obţine un sistem complet într-un timp redus

• Nu toate aplicaţiile sunt potrivite pentru RAD. Dacă un sistem nu poate

fi modularizat, construirea componentelor necesare pentru RAD devine
problematică.

• RAD nu e potrivit când riscurile tehnice sunt mari. Acest lucru apare
când o nouă aplicaţie foloseşte intens o nouă tehnologie sau când un
software nou cere un grad înalt de interoperabilitate cu programele
existente.
Business modeling
Scopul business process engineering (BPE) este să definească
arhitectura ce va permite business să utilizeze eficient informaţiile.
Se analizează şi se specifică Arhitectura datelor
design-ul pentru Arhitectura aplicaţiilor
Infrastructura tehnologică

1) Arhitectura datelor are ca blocuri constitutive obiectele de date (data

object). Un obiect de date conţine o mulţime de atribute care descriu un
anumit aspect, calitate, caracteristică a datelor ce sunt descrise.

Exemplu: obiectul Customer

O relaţie (relationship) indică cum sunt conectate obiectele unul cu altul.

Exemplu: pentru obiectele Customer şi produsA, o relaţie poate fi
cumpără.
2) Arhitectura aplicaţiei cuprinde acele elemente ale sistemului care
transformă obiectele în cadrul arhitecturii datelor pentru un anumit scop
de business.
3) Infrastructura tehnologică asigură fundaţia pentru arhitecturile datelor
şi aplicaţiei. Cuprinde hardware-ul şi software-ul care sunt folosite:
computere, SO, reţele, legături de telecomunicaţii, tehnologii de stocare
şi arhitectura (ex: client – server).
Pentru a modela arhitecturile descrise, se defineşte o ierarhie a
activităţilor ingineriei proceselor business.

World view e obţinută prin Information strategy planning (ISP). ISP vede
întreg întregul business ca o entitate şi izolează domeniile business-ului
(ex: inginerie, manufacturare, marketing etc.). ISP defineşte obiectele
de date care sunt vizibile la nivelul întreprinderii şi relaţiile dintre ele .
Domain view se obţine cu o activitate a BPE numită business area
analysis (BAA), care identifică în detaliu datele (sub forma tipurilor
entităţilor, adică a obiectelor de date) şi cerinţele funcţiilor (sub forma
proceselor) ale domeniilor de business în timpul ISP şi stabileşte
interacţiunile dintre ele.
Odată un information system izolat, BPE face o tranziţie spre ingineria
software. Invocând pasul business system design (BSD), sunt modelate
cerinţele de bază ale unui information system şi aceste cerinţe sunt translatate
în arhitectură de date şi de aplicaţie şi infrastructură tehnologică.
Data modeling
Răspunde la un set de întrebări specifice:
• Care sunt obiectele de date primare procesate iniţial de sistem?
• Care e compoziţia fiecărui obiect de date şi ce atribute descriu
obiectul?
• Unde “stau” în mod curent obiectele?
• Care sunt relaţiile dintre obiecte?
• Care sunt relaţiile dintre obiecte şi procesele care le transformă?
Apelează la diagrama relaţiilor dintre entităţi (ERD – Entity Relationship
Diagram)
4GT (Fourth Generation Techniques)
Termenul 4GT cuprinde o gamă largă de instrumente software care au
un lucru în comun: fiecare permite inginerului software să specifice
anumite caracteristici ale software-ului la un nivel înalt. Instrumentul
(tool) generează apoi automat cod sursă bazat pe specificaţiile
dezvoltatorului.

Paradigma 4GT pentru ingineria software pune accentul pe abilitatea de

a specifica software folosind forme de limbaj specializat sau notaţii
grafice ce descriu problema propusă spre rezolvare în termeni pe care
clientul poate să-i înţeleagă.

În mod curent, un mediu de dezvoltare software ce suportă paradigma

4GT include o parte dintre următoarele instrumente (tools):
• limbaje neprocedurale pentru interogările bazei de date;
• capabilităţi grafice de nivel înalt;
• capabilităţi de tip spreadsheet;
• generare automată a HTML şi a limbajelor similare folosite pentru
crearea site-urilor Web utilizând instrumente software avansate.
4GT (Fourth Generation Techniques) (continuare)

Concluzii privind paradigma 4GT:

1) Folosirea 4GT e o abordare viabilă pentru multe zone de aplicaţii.
Combinată cu alte instrumente CASE şi generatoare de cod, 4GT
reprezintă o soluţie de încredere pentru multe probleme software.

2) Folosind 4GT, timpul necesar pentru producerea software-ului e mult

redus pentru aplicaţii mici şi mijlocii şi de asemenea efortul pentru
design şi analiză pentru aplicaţiile mult e mult redus..

3) Folosirea 4GT pentru dezvoltarea unui software complex necesită la

fel de multă sau chiar mai multă muncă pentru analiză, design şi testări,
în ciuda timpului salvat obţinut din eliminarea codului.
4) Modele pentru procese software evolutive: sunt iterative, adică
permit dezvoltarea crescătoare a unor versiuni din ce în ce mai
complete ale software-ului.
a) Modelul incremental: combină elemente ale modelului cascadă
(aplicat repetat) cu filozofia iterativă a modelului prototipului.

Fiecare secvenţă liniară produce un “increment” livrabil al software-ului.

Exemplu : Software pentru editor de texte, poate livra managementul de
bază al fişierelor şi editarea la primul increment; editare mai sofisticată la
al doilea increment; spelling şi verificare gramaticală în al treilea increment
şi capabilităţi avansate de proiectare a paginii la al patrulea increment.
Obs. Primul increment e adesea un miez al produsului (core product),
adică cerinţele de bază sunt îndeplinite, dar mai multe capabilităţi (unele
cunoscute, altele necunoscute) rămân nepredate.
Acest core product e folosit de client. Ca rezultat al utilizării sau al
evaluării, se dezvoltă un plan pentru următorul increment, care stabileşte
modificarea core product-ului pentru îndeplinirea mai bună a cerinţelor
clientului şi furnizarea funcţionalităţilor adiţionale. Acest proces e repetat
după livrarea fiecărui increment, până se conturează întregul produs.
Concluzii.
• Modelul incremental e iterativ (ca şi modelul prototipului), dar se
concentrează pe livrarea unui produs operaţional la fiecare increment.
Versiunile iniţiale nu se regăsesc în produsul final, dar furnizează
capabilităţi nesecare utilizatorului.
• Modelul incremental e util când echipa de dezvoltatori nu e disponibilă
toată perioada. Core product-ul poate fi realizat cu mai puţini oameni.
b) Modelul spirală: combină natura prototipului cu aspectele sistematice
controlate ale modelului cascadă. Software-ul e dezvoltat într-o serie de
livrări incrementale. În timpul primelor iterări, livrarea poate fi un model pe
hârtie sau un prototip. În timpul iterărilor ulterioare, sunt produse versiuni
don ce în ce mai complexea sistemului.

Sunt între 3 şi 6 task regions într-un proiect tipic.

Cele 6 regiuni reprezentate în figură sunt:

• Comunicarea cu clientul: tasks pentru stabilirea unei comunicări efective

între dezvoltator şi client

• Planificarea: tasks pentru definirea resurselor, a planificărilor temporale

şi a altor informaţii în legătură cu proiectul

• Analiza riscurilor: tasks pentru stabilirea în egală măsură a riscurilor

ehnice şi manageriale

• Tehnologia (engineering): tasks pentru construirea uneia sau a mai

multor reprezentări ale aplicaţiei

• Construirea şi livrarea: tasks pentru construirea, testarea, instalarea şi

asigurarea suportului utilizatorului (ex: documentaţie şi training)

• Evaluarea clientului: tasks pentru obţinerea unui feed-back din partea

clientului, bazat pe evaluarea reprezentărilor software create în timpul
etapei de engineering şi implementate în timpul etapei de instalare
Echipa de dezvoltatori se mişcă în spirală în sensul acelor de ceasornic,
începând din centru.
Primul circuit în jurul spiralei ajută la dezvoltarea specificaţiilor produsului.

Următoarele circuite ajută la dezvoltarea prototipului şi apoi, progresiv, la

versiuni mai sofisticate ale software-ului.

Fiecare trecere prin dreptul zonei de planificare (planning region) produce

rezultate în ajustarea planului proiectului.

Costul şi planificarea temporală sunt ajustate pe baza feedback-ului

derivat din evaluarea clientului.

Managerul proiectului ajustează numărul de iteraţii necesare pentru a

completa software-ul.

Obs. Spre deosebire de modelele clasice, care se termină cu livrarea

software-ului, modelul spirală poate fi adaptat pentru a fi folosit pe
întreaga durată de viaţă a software-ului.
O privire alternativă asupra modelului spirală se obţine examinând axele
punctelor de intrare în proiect (project entry point axis).

Fiecare cub plasat de-a lungul axelor poate fi utilizat pentru a reprezenta
punctul de plecare pentru diferite tipuri de proiect.
Un “concept development project” porneşte de la miezul spiralei şi
continuă până ce devine completă dezvoltarea conceptului.
Concluzii
• Modelul spirală e o abordare potrivită pentru sistemele de mari
dimensiuni.
• Modelul spirală foloseşte prototipul ca un mecanism de reducere a
riscurilor dar, mai important, permite dezvoltatorului să aplice abordarea
prototipului la orice etapă din evoluţia proiectului.
• Modelul spirală menţine abordarea sugerată de ciclul de viaţă clasic, dar
o incorporează într-un cadru iterativ care reflectă mai realist lumea.
• Modelul spirală cere luarea în calcul a riscurilor tehnice în toate etapele
proiectului şi, dacă se aplică corect, ar trebui să reducă riscurile înainte să
devină problematice.
• Modelul spirală nu este folosit aşa cum se folosesc modelul liniar
secvenţial şi modelul prototipului.
c) Modelul WINWIN
“Eliciting software requirements demands negociation. Successful
negotiation occurs when both sides « win ».”

Stakeholder = cineva din organizaţie care are un interes de afaceri direct

în construirea sistemului sau produsului şi care va fi recompensat pentru
succes şi criticat pentru un eşec.

Modelul spiral al lui Boehm (Boehm, B., “Using the WINWIN Spiral Model: A
Case Study,” Computer, vol. 31, no. 7, July 1998, pp. 33–44) defineşte o serie
de activităţi de negociere la începutul fiecărei treceri în jurul spiralei:
1. Identificarea stakeholders ai sistemului sau subsistemului.

2. Determinarea condiţiilor de câştig (“win conditions”) ale stakeholders.

3. Negocierea acestor condiţii pentru a le reconcilia într-un set de condiţii

win-win pentru toţi cei implicaţi (inclusiv pentru echipa proiectului
software).
În afară de cele 3 activităţi de negociere menţionate, modelul spirală mai
introduce 3 anchor points:
• Life cycle objectives (LCO): defineşte un set de obiective pentru
fiecare activitate majoră de inginerie software.
• Life cycle architecture (LCA): defineşte obiectivele de trebuie
îndeplinite când se defineşte arhitectura software-ului.
• Initial operational capability (IOC): defineşte obiective în legătură cu
pregătirea pentru instalarea / distribuirea software-ului şi asistenţă.
d) Modelul de dezvoltare concurentă (numit şi concurrent engineering)
“Most software development process models are driven by time; the later it is,
the later in the development process you are. A concurrent process model is
driven by user needs, management decisions, and review results.” (Davis, A., P.
Sitaram, 1994)

Toate activităţile există concurent,

dar se găsesc în diferite stări.

Modelul concurent se foloseşte ca

paradigmă pentru dezvoltarea
aplicaţiilor client-server.