Mdsi C4 C5 C6 PDF

Metodologii pentru dezvoltarea
sistemelor încorporate
RUP
<Metodologii ptr. dezv. sist. încorporate>
Definirea dezvoltării iterative <Florin Ostafi>
RUP - Rational Unified Process

Metodă de management iterativă - conducerea unui proiect pe baza
evaluării periodice a obiectivelor şi replanificarea pe baza acestor
evaluări
Un management iterativ bun presupune:
Luarea în considerare a riscurilor încă din faza incipientă a
proiectului;
Utilizarea unei abordări Ńintite pe arhitectura produsului;
Evaluări obiective.
2
RUP versus Waterfall <Florin Ostafi>
Modelul Proces
Waterfall iterativ
Bazat pe cerinŃe Bazat pe arhitectură şi componente

SoluŃionare târzie a riscurilor SoluŃionare timpurie a riscurilor
Analiza
cerinŃelor Proiectare Implement.
şi testare
unităŃi Integrare Testare
sistem
3
RUP - Etape <Florin Ostafi>
Procesul iterativ poate fi descompus în două etape :

Etapa inginerească (tehnică)
Se dezvoltă planuri, se stabilesc cerinŃele şi arhitectura sistemului, rezolvând problema
riscurilor ce pot apărea la dezvoltarea proiectului.
Se încheie cu o arhitectură executabilă de bază.
Proiectarea este realizată de echipe de dimensiuni mici.
Etapa de producŃie
Se construieşte o versiune utilizabilă a în contextul furnizat de etapa anterioară.
ConstrucŃia, testarea şi implementarea activităŃilor este realizată de echipe de dimensiuni
mai mari.
4
RUP – DiferenŃe între etape <Florin Ostafi>
Aspecte din ciclul de viaŃă Etapa inginerească Etapa de producŃie
Reducere riscuri Orar, fezabilitate tehnică Cost
Produse Arhitectură de bază Livrabil de bază
Analiză, proiectare, Implementare, testare

ActivităŃi planificare
DemonstraŃii, inspecŃii, Testare

Evaluări analize
Rezolvarea creşterii Exploatarea economiilor

Economie costurilor
Management Planificare OperaŃii
5
Ciclul de viaŃă iterativ <Florin Ostafi>
Etapa inginerească Etapa de producŃie

IniŃiere (Pornire) Elaborare (Rafinare) ConstrucŃie TranziŃie
timp
Milestone Milestone Milestone Milestone

Obiective Arhitectură Capabilitate Livrarea
operaŃională iniŃială produs
În ciclul de dezvoltare iterativ:

Fiecare fază descrie starea proiectului;
Fiecare fază are importanŃa sa şi include activităŃi în proporŃii diferite;
Fază: timpul dintre două milestone-uri majore ale proiectului, de-a lungul căruia
sunt atinse obiective bine definite şi sunt luate decizii de trecere sau nu la faza
următoare;
Produsul este implementat în principal în fazele de Elaborare şi ConstrucŃie.
6
Obiectivele fazelor – IniŃierea <Florin Ostafi>
IniŃiere Elaborare ConstrucŃie TranziŃie

timp
Milestone
Obiective
Faza de IniŃiere
Scop: echipa de dezvoltare stabileşte obiectivele esenŃiale ale proiectului.
Rezultate:
enumerare a cerinŃelor principale, posibil în formă de cazuri de utilizare;
imagine de ansamblu asupra arhitecturii programului;
descriere a obiectivelor proiectului;
un plan preliminar de dezvoltare.
Riscurile determinate de extragerea cerinŃelor trebuie identificate înainte de
pornirea proiectului.
7
Obiectivele fazelor – Elaborarea <Florin Ostafi>

timp
Milestone
Arhitectură
Faza de Elaborare
Scop: se hotărăşte arhitectura programului, se stabileşte echipa de lucru, se
elimină situaŃiile cu risc mare.
Rezultate:
un prototip evoluŃionar al arhitecturii programului;
teste care verifică funcŃionarea programului;
cazuri de utilizare care descriu majoritatea funcŃionalităŃilor sistemului;
un plan de proiect detaliat pentru iteraŃiile următoare.
8
Obiectivele fazelor – ConstrucŃia <Florin Ostafi>

timp
Milestone
Capabilitate
operaŃională iniŃială
Faza de ConstrucŃie
Scop: adăugarea cerinŃelor neimplementate încă şi dezvoltarea completă a
sistemului.
Rezultate:
Programul propriu-zis;
Teste;
Manuale de utilizare.
9
Obiectivele fazelor – TranziŃia <Florin Ostafi>

timp
Milestone
Livrare
produs
Faza de TranziŃie
Scop: programul este îmbogăŃit mai departe cu caracteristici, însă accentul se pune
pe îmbunătăŃirea şi rafinarea celor existente pe baza reacŃiilor de la client.
Sfârşitul acestei activităŃi şi a întregului proces de dezvoltare are loc atunci când:
Obiectivele propuse în cadrul fazei de pornire sunt îndeplinite;
Clientul este satisfăcut.
10
IteraŃii în interiorul fazelor <Florin Ostafi>

IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie
preliminară Arhitectură Arhitectură Dezvoltare Dezvoltare Dezvoltare TranziŃie TranziŃie
Livrabile executabile
Un proiect bazat pe RUP evoluează în paşi numiŃi iteraŃii.

IteraŃia: SecvenŃă distinctă de activităŃi bazate pe un plan stabilit şi pe criterii de evaluare din care rezulta un
livrabil executabil (intern sau extern).
Reprezintă punctul la care proiectul este evaluat şi sunt realizate ajustările necesare.
Livrabil: versiune stabilă, completă şi executabilă a sistemului.
Scopul unei iteraŃii este să dezvolte un program funcŃional care să poată fi prezentat clientului, iar clientul să
îl poată evalua.
Întinderea în timp a unei iteraŃii depinde de tipul de proiect la care se lucrează, de experienŃa echipei etc.
Este de preferat ca iteraŃiile să fie cât mai scurte.
ObservaŃie: faza de iniŃiere poate să nu necesite un livrabil executabil
11
ActivităŃi în interiorul iteraŃiilor <Florin Ostafi>
12
AplicaŃii ale ciclului de viaŃă iterativ <Florin Ostafi>
Produce livrabile în fiecare iteraŃie

Livrabile interne şi externe
Identică scenarii de realizat sau de refăcut pe baza riscurilor celor mai mari ale
proiectului
Atribuie taskuri clare echipei pentru a putea îndeplini condiŃiile de livrare.
Pentru atribuirea taskurilor se folosesc Cazurile de Dezvoltare – descriu procesul
de dezvoltare al proiectului.
Dacă procesul de dezvoltare nu este realizat, atunci managerul de proiect trebuie
să determine:
Taskurile pentru echipa de dezvoltare
RelaŃiile care există între taskuri si artefacte
Stabilirea de jaloane şi puncte de analiză adecvate
ForŃează închiderea unei iteraŃii prin integrare şi livrare a livrabilelor executabile
13
Rafinările succesive <Florin Ostafi>
Fiecare livrabil trebuie marcat de:
Creşterea capabilităŃii, constând în implementarea unor funcŃionalităŃi

suplimentare de-a lungul fiecărei iteraŃii
O profunzime mai mare, constând într-o implementare mai completă a produsului
O stabilitate mai mare, constând în reducerea numărului de schimbări ale

produsului
O iteraŃie presupune:
Terminarea muncii planificate pentru iteraŃie
O evaluare a proiectului la sfârşitul fiecărei iteraŃii
14
Durata unei iteraŃii şi numărul de iteraŃii <Florin Ostafi>
Durata unei iteraŃii poate varia funcŃie de

obiectivele proiectului;
faza proiectului.
În general, iteraŃiile din faza de Elaborare sunt mai mari decât iteraŃiile din faza de ConstrucŃie.
În interiorul unei faze, iteraŃiile au în general aceeaşi lungime.
Număr total de iteraŃii [I,E,C,T]

Mic 3 [0,1,1,1]
Tipic 6 [1,2,2,1]
Mare 9 [1,3,3,2]
Foarte mare 10 [2,3,3,2]
Pentru majoritatea proiectelor durata unei iteraŃii este între 1 lună şi 2 luni.
IteraŃiile mai mari de 6 săptămâni au nevoie de jaloane intermediare.
Reducerea obiectivelor unei iteraŃii duce la reducerea duratei şi la o înŃelegere mai clară a scopurilor.
IteraŃiile mai mici de o lună trebuie planificate cu atenŃie. În general, iteraŃiile scurte sunt mai convenabile în
faza de ConstrucŃie unde gradul de includere de noi funcŃionalităŃi şi gradul de noutate sunt mici. IteraŃiile
scurte pot să nu necesite analiză formală şi proiectare.
15
CondiŃii pentru creşterea numărului de iteraŃii <Florin Ostafi>
IniŃiere Elaborare
Lucrul cu funcŃionalităŃi noi Lucrul cu sisteme noi (caracteristici
arhitecturale noi)
Mediu necunoscut
Elemente arhitecturale netestate
Obiective cu grad mare de volatilitate
Nevoia de prototipuri ale sistemului
Decizii “make/buy”
ConstrucŃie TranziŃie
Cantitate mare de cod de scris şi Necesitatea unor variante alpha şi beta
verificat
Schimbarea clienŃilor
Tehnologii sau instrumente de
Livrare incrementală către client
dezvoltare noi
16
Prima iteraŃie <Florin Ostafi>

IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie IteraŃie
preliminară Arhitectură Arhitectură Dezvoltare Dezvoltare Dezvoltare TranziŃie TranziŃie
Prima iteraŃie?
Prima iteraŃie este în general cea mai grea

Necesită participarea şi consensul liderilor de proiect
Trebuie rezolvate problemele de integrare şi de organizare a echipei.
Pentru a fi siguri de succes trebuie ca în prima iteraŃie să se încerce asigurarea unei minime
funcŃionalităŃi. În caz contrar:
Terminarea primei iteraŃii va fi întârziată
Va exista presiunea reducerii numărului de iteraŃii, pierzându-se avantajele abordării iterative
17
Strategii de iterare <Florin Ostafi>
“Wide and Shallow” Problemă

Se analizează întregul domeniu al problemei dar se iau în considerare doar
detaliile de suprafaŃă. S
o
Se definesc toate cazurile de utilizare şi majoritatea se completează la un l
nivel de detaliu ridicat pentru o înŃelegere exactă a problemei. u
Ń
Se defineşte în linii mari arhitectura sistemului şi serviciile şi mecanismele i
cheie oferite de componentele arhitecturale. e
Se definesc interfeŃele, dar detaliile interne se detaliază doar dacă trebuie
luat în considerare un risc.
Majoritatea iteraŃiilor - faza de ConstrucŃie
“Narrow and Deep” Problemă

Se analizează o porŃiune a domeniului problemei S
Cazurile de utilizare se definesc şi se completează în detaliu o
l
Se defineşte arhitectura necesară asigurării comportării dorite a sistemului u
Ń
Se proiectează şi se implementează sistemul i
IteraŃiile care urmează se focalizează pe analizarea, proiectarea şi e
implementarea domeniilor verticale suplimentare
Hibridă
Mixtură a strategiilor anterioare
18
Profiluri ale riscului <Florin Ostafi>
Avantaj major al RUP: se iau în considerare la început riscurile majore ale proiectului
Risc: Eveniment incert care are o probabilitate semnificativă de a afecta succesul

milestone-urilor majore.
IniŃiere Elaborare ConstrucŃie – TranziŃie
Mare
Profil risc – proiect convenŃional (cascadă)

Expunerea la risc
Profil risc - proiect iterativ
Mică
Ciclul de viaŃă al proiectului
19
Profiluri ale riscului <Florin Ostafi>
Dezvoltarea iterativă produce în primul rând arhitectura sistemului, deci:

Integrarea apare ca “activitate de verificare” a fazei de proiectare;
Defectele de proiectare sunt detectate şi rezolvate la începutul ciclului de viaŃă.
Are loc o integrare continuă, evitându-se integrarea de tip “big bang” la sfârşitul
proiectului.
Permite o abordare mai bună a conceptului de calitate deoarece o mare parte a

caracteristicilor sistemului (performanŃă, toleranŃa la defecte) sunt tangibile la
începutul procesului
Problemele sunt corectate fără a periclita Ńintele de cost şi orarul proiectului
20
Diminuarea riscurilor prin
dezvoltarea interativă <Florin Ostafi>
Dezvoltarea iterativă permite diminuarea a două riscuri inerente proiectelor software:
Modificarea cerinŃelor - obiectivele produsului (cerinŃele) se schimbă pe parcursul dezvoltării

proiectului.
Descriere:
Stakeholderii şi utilizatorii îşi dau seama de ceea ce vor mai exact pe măsură ce
studiază specificaŃiile documentate.
Echipa se focalizează pe descoperirea obiectivelor – pot apărea obiective pe parcurs.
Dezvoltatorii realizează că nu pot satisface, d.p.d.v. economic, unele cerinŃe.
Strategie de diminuare a riscului:
Validarea frecventă a stării curente a cerinŃelor şi a specificaŃiilor produsului – evaluări

iterative
Ajustări frecvente al direcŃiei proiectului astfel încât produsul să satisfacă cerinŃele

stakeholderilor – ajustări iterative ale obiectivelor produsului
21
Diminuarea riscurilor prin
dezvoltarea interativă <Florin Ostafi>
NemulŃumirea stakeholderilor – aceştia nu sunt de acord cu produsul livrat.

Descriere:
Stakeholderii descoperă că produsul nu are unele dintre caracteristicile cerute.
Strategie de diminuare a riscului:
Furnizarea unor pre-livrabile ale versiunilor produsului – prezentare iterativă.
Stakeholderii trebuie să participe şi să aprobe schimbările în specificaŃiile produsului –

implicarea iterativă
22
Alocarea resurselor în dezvoltarea interativă <Florin Ostafi>
Exemplu
Efort 5% 20% 65% 10%
Timp/Orar 10% 30% 50% 10%
O fază este considerată terminată atunci când este îndeplinit setul de obiective ⇒
resursele trebuie alocate astfel încât să contribuie la îndeplinirea obiectivelor ⇒ se
reduce confuzia şi refacerea muncii.
Spre exemplu, la începutul fazei de ConstrucŃie arhitectura sistemului este definită în
linii mari şi trebuie diminuate riscurile tehnice majore ⇒ se pot adăuga membri în
echipă pentru a termina faza de ConstrucŃie.
23
Evaluare costuri <Florin Ostafi>
COCOMO II:
Efort = (Personal)(Mediu)(Calitate) (DimensiuneProces)
Efort: luni-om necesare terminării proiectului

Personal: factori ce iau în considerare abilităŃile membrilor echipei
Mediu: factori ce iau în considerare instrumentele şi tehnicile de lucru
Calitate: factori ce iau în considerare calitatea produsului
Dimensiune: Număr de linii de cod din produsul final
Proces: reflectă eficacitatea procesului utilizat pentru realizarea sistemului
Deoarece exponentul proces este în general mai mare decât 1, există o creştere pe
termen lung a costului mediu a producŃiei – “diseconomy of scale” (dimensiune mare →
costuri mai mari)
ObservaŃie: Factorii nu sunt independenŃi
24
ÎmbunătăŃire costuri <Florin Ostafi>
Reducerea Dimensiunii sau complexităŃii aplicaŃiei

ÎmbunătăŃirea procesului de dezvoltare
ÎmbunătăŃirea calificărilor Personalului
ÎmbunătăŃirea Mediului de dezvoltare
Optimizarea CalităŃii
ObservaŃii:
Utilizarea dezvoltării iterative poate avea un impact favorabil asupra exponentului Proces.
Aplicarea dezvoltării iterative au o influenŃă puternică asupra costului final
25
Navigare prin proiect <Florin Ostafi>
START: Idee generală asupra SFÂRŞIT: Satisfacerea cerinŃelor

direcŃiei proiectului; necesită stakeholderilor, în parametrii de cost
implicarea stakeholderilor. şi calitate ceruŃi.
E-end
START
C-end
T-end
I-end
Definire Obiective* Arhitectură Dezvoltare Cod, Documente, Tutoriale

AplicaŃie etc.
Creare Plan Proiect Gestionare Completă*
Schimbări CerinŃe* EXPEDIERE: Cod,
Creare Arhitectură Gestionare
Produs Verificări/ Măsurări Schimbări DocumentaŃie, Help-uri,
Creare Business Ajustare CerinŃe* Tutoriale
Case* Proces/Instrumente Verificări / PĂSTRARE: Cazuri de
Estimări Costuri* Actualizare Riscuri Măsurări test, Proiectare, CerinŃe
Creare Proces / Ajustare posibilă Actualizare amânate, Măsurări proiect
Instrumente Business Case* Riscuri
Identificare Riscuri
* Implicare Stakeholder
26
Echipa proiectului <Florin Ostafi>
Echipa de management Echipa de dezvoltare

Echipa de arhitecŃi Echipa de evaluare
CompoziŃia echipelor
Echipă FuncŃii Echipă FuncŃii
Management • Analist sistem Evaluare • Specialist aplicaŃie
• Manager proiect • Manager configuraŃie
• Inginer de proces • Manager controlul schimbării
• Arhitect • Proiectant teste
• Stakeholder • Manager plasare
• Realizator curs
• Realizator documentaŃie
ArhitecŃi • Arhitect Dezvoltare • Analist sistem
• Proiectant baze de date • Proiectant baze de date
• Dezvoltator
ObservaŃie: Analistul de sistem poate îndeplini şi funcŃia de inginer de cerinŃe
27
ResponsabilităŃi echipe <Florin Ostafi>
Echipă ResponsabilităŃi Echipă ResponsabilităŃi

Management • Alocare resurse Dezvoltare • Proiectare componente
• Alocare personal • Implementare componente
• Planuri, priorităŃi • Testare componentă
• Satisfacerea stakeholderilor • ÎntreŃinere componentă
• Definire obiective • Documentare componentă
• Management risc
• Control proiect
ArhitecŃi • Optimizare cerinŃe Evaluare • Infrastructură produs
• Optimizare proiectare • Testare independentă
• Selectare componente • Verificare cerinŃe
• Integrare iniŃială • Analize, măsurători
• SoluŃionare riscuri tehnice • Control configuraŃie
• Management schimbare
• Plasare la utilizatori
28
EvoluŃia echipei <Florin Ostafi>
Management Management
10%
50%
Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare

software software software 20% 20%
20% 20% 10% 50%
IniŃiere Elaborare
10% 10%
Arhitectură Dezvoltare Evaluare Arhitectură Evaluare

5% 35%
Dezvoltare
10% 30%
50% 50%
TranziŃie ConstrucŃie
29
Diagrama ciclului de viaŃă al echipei <Florin Ostafi>
ciclul de viaŃă al echipei
30
Orar şi formarea echipelor <Florin Ostafi>
Fază Orar Staff

IniŃiere Dacă proiectul va dura Echipă de dimensiuni reduse ce include:
în jur de un an, această
fază va dura o lună. • Managerul de proiect
• Arhitectul sistemului
• Un membru al echipei de testare
• CâŃiva dezvoltatori care vor continua proiectul
Elaborare Dacă proiectul va dura Echipă de dimensiuni reduse ce include:
în jur de un an, această
fază va dura de la • Managerul de proiect
două la patru luni. • Arhitectul sistemului
• O echipă de proiectanŃi şi dezvoltatori
• O echipă mică de testare
• Unul sau doi experŃi în domeniu sau utilizatori
finali
• Specialişti aplicaŃie
31
Orar şi formarea echipelor <Florin Ostafi>
Fază Orar Staff

ConstrucŃie • Dacă proiectul va dura în jur de • Personalul atinge maximul. 80% din
un an, această fază va dura de la echipă participă direct la livrare.
cinci la şase luni.
• Restul echipei realizează taskuri
• Pentru un proiect de dimensiuni referitoare la riscurile noi şi pregătesc
reduse, se planifică o livrare nouă baza livrărilor viitoare.
la 2-3 luni.
• Pentru un proiect complex, la 6-9
luni.
TranziŃie • Variază foarte mult funcŃie de • Managerul software
cum este definit sfârşitul fazei.
• Arhitectul software
• Dacă acceptarea de către client
marchează sfârşitul tranziŃiei • O echipă mică de dezvoltatori şi testeri
atunci, pentru un proiect de un an, • Personal de suport tehnic
faza nu trebuie să dureze mai mult
de o lună. • Un realizator de documentaŃie (pentru
actualizare)
• Dacă sfârşitul vieŃii produsului
marchează sfârşitul tranziŃiei, faza • Personal de marketing, fabricaŃie,
poate dura mult mai mult. instructaj etc.
32
InteracŃiuni tipice în interiorul echipei <Florin Ostafi>
Taskuri principale proiect Roluri

Analist sistem
Colectare cerinŃe stakeholderi
Stakeholderi
Organizare şi dezvoltare cerinŃe Analist sistem
Dezvoltare soluŃii tehnice Arhitect / Dezvoltator
Manager proiect
Stabilire plan dezvoltare Analist sistem
Arhitect / Dezvoltator
Manager proiect
Analist sistem
Determinare obiective proiect
Stakeholderi
Test Manager
Verificare progres funcŃionalitate / utilitate Analist sistem
Inginer Proces
Analist sistem
Determinare procese proiect, artefacte şi instrumente Arhitect / Dezvoltator
Manager proiect
Manager testare
33
Stakeholderii principali externi <Florin Ostafi>
Managerul executiv
Stabileşte viziunea aprobă finanŃarea proiectului;
asupra proiectului poate avea o viziune asupra proiectului sau
Manager Manager poate fi persoana care forŃează
executiv Stabileşte scopul proiectului
Marketing/Utilizator îmbunătăŃirile proiectului;
furnizează evaluări asupra viabilităŃii
produsului pe piaŃă.
Alocă resurse Plasează spre vânzare sau
utilizare rezultatele proiectului
Managerul de Marketing / Utilizator
(Marketing - produsul se vinde sau Utilizator - se
foloseşte intern)
Stabileşte
controlează resursele ce vor fi folosite pentru
Utilizator realizarea produsului ;
sistem specificaŃii detaliate
conduce departamentele ce vor beneficia de
pe urma implementării produsului;
furnizează cerinŃele proiectului (eventual în
InterfaŃarea
InterfaŃarea cu
cu echipa
echipa de de dezvoltare:
dezvoltare: termeni generali).
Managerul
Managerul de proiect -- livrează
de proiect livrează caracteristici
caracteristici ce
ce
îndeplinesc
îndeplinesc specificaŃiile
specificaŃiile de cost şi
de cost şi calitate.
calitate. Utilizatorii sistemului
Analistul
Analistul de sistem -- colectează,
de sistem colectează, utilizează direct produsul ⇒ pot furniza
documentează şi
documentează şi furnizează
furnizează specificaŃiile
specificaŃiile tehnice
tehnice specificaŃii detaliate;
ale
ale proiectului.
proiectului. eficienŃa personală se va îmbunătăŃi prin
utilizarea produsului.
34
Artefacte <Florin Ostafi>
Artefact – cantitate de informaŃie care este produsă, modificată sau utilizată de un

proces
Artefactul poate fi de tipul:
Model – realizat cu instrumente de modelare din care se pot crea automat rapoarte
Document – creat utilizând procesoare de texte
Artefactele furnizează:
DocumentaŃie permanentă a structurii şi comportării sistemului:
CărŃi tehnice, ghiduri de utilizare, descriere arhitectură;
DocumentaŃie pentru utilizatorii finali, personal de întreŃinere.
DocumentaŃie folosită în procesul de dezvoltare:
DocumentaŃie internă de proiectare;
Evaluări stare proiect;
Raportări defecte.
Scop: minimizarea creării artefactelor
35
DocumentaŃia <Florin Ostafi>
Un proiect reuşit furnizează documentaŃie suficientă pentru:

Viziunea asupra proiectului
Comunică viziunea generală asupra proiectului
Reducerea riscurilor
Promovează dialogul între stakeholderi şi dezvoltatori
Puncte de control pentru management
Luarea deciziilor şi progres explicit şi observabil
Integritatea conceptuală a arhitecturii
Comunicarea ideii proiectului către arhitectul software / echipă
36
DocumentaŃia <Florin Ostafi>
Exemple artefacte Proiecte mici Sisteme mari
Business case Memoriu scurt Ofertă completă
Idee Scurtă descriere a conceptului 20 pagini cu prototip GUI -

graphical user interface
Plan de dezvoltare software 10 pagini plan general Plan dezvoltare, Plan CM,
Plan QA etc.
Plan iteraŃii ŞedinŃă la început Scenarii detaliate, Ńinte de
calitate etc.
Document arhitectură software Prezentare – 5 slide-uri 120 pagini documentaŃie
Evaluări iteraŃii Note livrare Analiza rezultatelor testării,

rezultate măsurători, demo-uri
etc.
Plan plasare Help on-line, marketing Help on-line, tutoriale,
colateral manuale utilizare, curs
instruire, campanie publicitară
etc.
37
Artefacte echipă <Florin Ostafi>
Echipă Artefacte Echipă Artefacte

Business case
Idee
Caracteristici proiectare
Plan dezvoltare
Management Dezvoltare Caracteristici implementare
Work breakdown structure
Caracteristici plasare
Evaluări stare sistem
Caracteristici cerinŃe
Caracteristici plasare
Bază de date a schimbărilor
Descriere arhitectură
Manual utilizare
Caracteristici cerinŃe
Arhitectură Evaluare Mediu
Caracteristici proiectare
SpecificaŃii livrare
SpecificaŃii livrare
Descriere livrabile
Documente plasare
38
EvoluŃia artefactelor de-a lungul ciclului de viaŃă <Florin Ostafi>
39
Ciclul de viaŃă al artefactului <Florin Ostafi>
EvoluŃie – Schimbări minore EvoluŃie – Schimbări majore Snap-shot – Nou creat pentru
aşteptate aşteptate fiecare iteraŃie
Exemplu: Viziune, Cazuri de dezvoltare Exemplu : Model cerinŃe Exemplu : Plan iteraŃii
Viziune: Cazuri de dezvoltare: Model CerinŃe: Plan iteraŃii:

EvoluŃie – Schimbări minore EvoluŃie – Schimbări minore EvoluŃie – Schimbări majore Snap-shot
aşteptate aşteptate aşteptate
Sfârşitul fazei de iniŃiere: Sfârşitul fazei de iniŃiere : Sfârşitul fazei de iniŃiere : Planul iteraŃiei X+1 creat la
Aprobat de stakeholderi Aprobat de echipă Identificare de bază a use sfârşitul iteraŃiei X
case-urilor
IteraŃii Elaborare: două IteraŃii Elaborare : Verificate şi Nu se face nici o schimbare,
caracteristici înlocuite de o modificate de echipă Elaborare timpurie: Detalii de este creat un nou plan pentru
nouă caracteristică aprobată bază ale use case-urilor şi iteraŃia următoare
de CCB IteraŃie ConstrucŃie : Verificată scenariilor semnificative
şi modificată de echipă d.p.d.v. arhitectural
IteraŃie ConstrucŃie: O
schimbare minoră aprobată de IteraŃii TranziŃie : Verificate şi Sfârşitul Elaborării: use case-
CCB modificate de echipă uri semnificative d.p.d.v.
arhitectural, identificarea
IteraŃii TranziŃie: Nici o (posibilă) a tuturor use case-
schimbare urilor pentru sistemul final
Sfârşitul construcŃiei: toate use

case-urile detaliate
40
Artefacte versus efort <Florin Ostafi>
Impactul artefactelor asupra efortului

Artefactele cresc factorul Dimensiune în formulă, deci creşte efortul general
ExcepŃie: artefactele de tip raport, care sunt generate automat
41
Anexă – DependenŃele între membrii echipei <Florin Ostafi>
Diagrama dependenŃelor
între membrii echipei
42
Conducerea echipei <Florin Ostafi>
Elementele principale ale conducerii unei echipe:

Cadrul: atribuirea funcŃiilor adecvate, asignarea staff-ului, instrumente şi procese;
Imaginea de ansamblu: asigurarea faptului că efortul echipei se focalizează pe
realizarea obiectivelor proiectului – îndeplinire activităŃi, orar, buget;
Dinamismul echipei: asigurarea comunicării între membrii echipei.
Rolul managerului:
Priveşte proiectul ca un tot unitar, neimplicându-se în detalii, acestea fiind atribuite
dezvoltatorilor;
Tratează proiectul ca un sistem dinamic, folosindu-şi autoritatea pentru a asigura o
conducere adecvată.
43
Evaluare şi Comandă IteraŃie <Florin Ostafi>
Porneşte iteraŃia utilizând Artefact: Evaluare

Planul iteraŃiei
IteraŃie
Realizează IteraŃia
planificată
Evaluează În cazul deciziei de continuare:

iteraŃie
Reducere Se analizează schimbările aprobate
Proiect riscuri de CCB;
Continuă Stop oprit
Acceptare Se revizuieşte lista riscurilor;
Ajustează Ajustează schimbare Se modifică (eventual) obiectivele
obiective produs (cerinŃele) produsului sau specificaŃiile
Conducere (arhitectură şi design);
proiect Pe baza acestui set de obiective
Ajustare plan rămas ajustate se poate planifica iteraŃia
următoare.
Planifică iteraŃia Planul IteraŃiei şi Evaluarea IteraŃiei

următoare facilitează deciziile ce duc la
reducerea riscurilor, acceptarea
Artefact: Plan
Porneşte iteraŃia următoare IteraŃie
schimbării şi conducerea proiectului
de-a lungul fiecărei iteraŃii.
44
Principii ale managementului software <Florin Ostafi>
Proces bazat pe o abordare de tip “architecture-first”

Stabilirea unui proces iterativ de dezvoltare care ia în considerare riscurile din faza
incipientă
Metode de proiectare care pun accentul pe dezvoltarea bazată pe componente
Stabilirea unui mediu pentru managementul schimbării
Accentuarea libertăŃii de schimbare printre instrumentele care suportă inginerie
“round-trip”
Realizarea riguroasă, printr-o notaŃie pe baza unor modele, a artefactelor de
proiectare
Instrumentarea proceselor pentru controlul calităŃii şi evaluarea progreselor
Utilizarea abordării bazate pe demonstraŃie
Planificarea livrărilor în grupuri de scenarii utilizabile la nivel de detaliu
Stabilirea unui proces configurabil
45
Principii ale MS şi cele mai bune practici RUP <Florin Ostafi>
Principii Practici RUP

Architecture-first
Ciclu de viaŃă iterativ Dezvoltare iterativă
Dezvoltarea bazată pe componente

Managementul cerinŃelor
Mediu management schimbare
Inginerie “Round-trip” Arhitectură pe bază de componente
NotaŃie pe bază de modele

Modelare vizuală UML
Controlul calităŃii
Abordare bazată pe demonstraŃie Verificarea continuă a calităŃii
Nivele de dezvoltare detaliate
Managementul schimbării
Proces configurabil
46
Principii ale managementului software <Florin Ostafi>
Dezvoltarea la nivel de Abordarea timpurie a Procesele iterative şi

detaliu şi abordarea bazată conceptului “architecture configurabile îmbunătăŃesc
pe demonstraŃie first” şi managementului managementul riscurilor şi
îmbunătăŃesc comunicarea schimbării îmbunătăŃesc reutilizarea între proiecte
între stakeholderi. calitatea multiple.
Ingineria “Round-trip” Dezvoltarea bazată pe

îmbunătăŃeşte nivelul de componente şi notaŃia
automatizare şi înŃelegerea bazată pe modele ajută la
controlului calităŃii reducerea dimensiunii şi
complexităŃii soluŃiei.
47
Managementul Riscului <Florin Ostafi>
Procesul se adresează aspectelor cunoscute ale proiectului.

Managementul riscului se adresează aspectelor necunoscute ale proiectului.
este un proces continuu deoarece riscurile se schimbă pe parcursul proiectului.
Riscul poate fi:
Direct: Proiectul are un grad mare de control
Indirect: Proiectul are un grad mic de control sau nu are deloc control
Atributele riscului:
Probabilitatea de apariŃie;
Impactul asupra proiectului (severitatea) .
((Probabilitatea
Probabilitatea riscului)
riscului) xx (Severitatea
(Severitatea riscului)
riscului) == ImportanŃa
ImportanŃa riscului
riscului
Mare
Mare
Semnificativă
Semnificativă
Moderată
Moderată
Minoră
Minoră
Mică
Mică
48
Managementul Riscului <Florin Ostafi>
Strategii
Evitarea riscului: reorganizarea proiectului astfel încât acesta să nu fie afectat
Transferul riscului: reorganizarea proiectului astfel încât altcineva să suporte riscul
Acceptarea riscului
Plan de acŃiune în situaŃii neprevăzute – cum se procedează dacă riscul devine real (“Planul B”)?
Plan de diminuare a riscului – reduce probabilitatea sau impactul
Exemple de riscuri
Riscuri tehnice: Tehnologie sau obiective nesigure. . .
Riscuri de timp: ziua are doar 24 de ore. . .
Riscuri de resurse: Oameni, abilităŃi, fonduri. . .
Riscuri de afaceri: CompetiŃie, ROI, furnizori. . .
DependenŃe critice de o a treia parte
Recomandări ale dezvoltării iterative:
Crearea unei liste a riscurilor (ordonate) şi actualizarea acesteia pe parcursul proiectului.
Diminuarea mărimii riscurilor cât de repede posibil
Ieşirea din faza de Elaborare presupune ca riscurile majore (tehnice sau de alt fel)
trebuie diminuate.
49
Arhitectura software <Florin Ostafi>
Produsul critic d.p.d.v tehnic al proiectelor software: infrastructura, controlul şi

interfeŃele de date care permit:
Componentelor software să coopereze ca sistem;
Designerilor software să coopereze ca echipă.
ConŃine setul de decizii semnificative referitoare la organizarea unui sistem software
Determină soluŃia fără să violeze constrângerile
Necesită inovare şi nu poate fi automatizată
Este baza deciziilor referitoare la:
“Make/buy”
Reutilizare componente
Control: Administrare complexitate, MenŃinere integritate
Management de proiect: Planificare, Echipă, Livrare
50
Arhitectura – bază pentru Management <Florin Ostafi>
O arhitectură stabilă reprezintă un milestone semnificativ al proiectului.
O arhitectură necorespunzătoare este adesea un motiv al eşecului

proiectului.
Arhitectura este premisă pentru o planificare predictibilă.
Arhitectura este sursa a numeroase decizii de mare risc.
În RUP, arhitectura este rezultatul Analizei şi Proiectării.
Se realizează în principal în iteraŃiile fazei de Elaborare
51
Măsurători în proiectele software <Florin Ostafi>
Porneşte iteraŃia utilizând Planul

iteraŃiei
Furnizează:
Realizează IteraŃia
planificată O evaluare a
MĂSURĂTORI progresului la un
Evaluează anumit moment dat
iteraŃie
O evaluare a calităŃii
Proiect produsului software
Bază pentru
Ajustează Ajustează estimarea costului şi
obiective produs orarului
Ajustare plan rămas

Măsurătorile sunt
Măsurătorile sunt
utilizate pentru
utilizate pentru
evaluarea iteraŃiilor
evaluarea iteraŃiilor
Planifică iteraŃia
următoare
Porneşte iteraŃia următoare
52
METRICĂ SCOP
Muncă şi progres Planificare iteraŃie, planuri versus actual
Indicatori
Cost bugetat şi cheltuieli Financiar, planuri versus actual
Management
Dinamica echipei Planuri versus actual, rata angajări, rată uzură
Planificare iteraŃie, indicator al convergenŃei

Schimbare şi stabilitate
orarului
Modularitate ConvergenŃă, rebuturi software

Indicatori
Calitate Refacere şi adaptabilitate ConvergenŃă, refacere
MTBF (Mean time between

failures) şi maturitate (rata de Acoperire teste, robusteŃe
defectare)
53
Recomandări ale dezvoltării iterative:

Măsurarea progresului şi a calităŃii produselor software de-a lungul întregului ciclu de
dezvoltare
Extragerea din artefactele elaborate, deoarece acestea sunt cele mai utile măsurători
Artefacte esenŃiale în managementul de proiect:
IniŃiere (în ordinea importanŃei) Elaborare

Plan de afaceri Listă riscuri
Listă riscuri Plan de dezvoltare
Plan de dezvoltare Plan iteraŃie/ Evaluare iteraŃie
Plan iteraŃie/ Evaluare iteraŃie
ConstrucŃie TranziŃie
Plan iteraŃie/ Evaluare iteraŃie Plan iteraŃie/ Evaluare iteraŃie
54
Planul de dezvoltare software - esenŃial:

Descrierea proiectului
Organizarea proiectului
Procese de management
Estimări proiect
Plan proiect
Plan iteraŃii
Monitorizare şi control proiect
Planurile proceselor tehnice şi de suport
Este important pentru colectarea tuturor informaŃiilor necesare pentru a controla
proiectul şi pentru a direcŃiona efortul de dezvoltare
55
Planul iteraŃiei - esenŃial:

Plan la nivel de task
Resurse
Use Case-uri
Criterii de evaluare
Este important pentru:
Managerul de proiect – pentru a panifica taskurile, activităŃile şi necesarul de

resurse la fiecare iteraŃie şi pentru a urmări progresul la fiecare iteraŃie
Membrii echipei proiectului – pentru a înŃelege ce trebuie să facă, când trebuie

să facă şi de ce alte activităŃi depind
56
Evaluarea iteraŃiei - esenŃială:

Obiective iteraŃie atinse
Stricta respectare a planului
Use Case-uri implementate
Rezultata raportate la criteriile de evaluare
Rezultate teste
Schimbări externe
Refacere necesară
57
<Florin Ostafi>
IniŃierea
58
IniŃierea <Florin Ostafi>
Obiective principale:
Stabilirea obiectivelor proiectului (scope) şi a condiŃiilor limită
Determinarea use case-urilor critice ale sistemului şi a scenariilor principale de
operare
Prezentarea a cel puŃin unei arhitecturi posibile pentru scenariile principale
Estimarea costului şi a orarului proiectului
Estimarea riscurilor potenŃiale
ActivităŃi esenŃiale:
Formularea obiectivelor proiectului
Sinteza arhitecturii
Planificarea şi realizarea planului de afaceri
59
EvoluŃia echipei – faza de IniŃiere <Florin Ostafi>
10%
50%

50% 20% 20%
20% 20% 10%
IniŃiere Elaborare
10% software
10%

5% 35% 10% 30%
50% 50%
60
Modelul iteraŃiei <Florin Ostafi>
Focalizare Porneşte iteraŃia utilizând Planul

iteraŃiei
Scope / CerinŃe Măsurători
Planul fazei Progres 5%
Riscuri Realizează IteraŃia
Cheltuieli (rate) Mici
planificată
Plan afacere Staff Echipă mică
Suport Stakeholderi Stabilitate Volatilă
Proces dezvoltare şi Evaluează Modularitate 50%-100%
instrumente iteraŃie Adaptabilitate Variază
Maturitate Prototip
Proiect
Ajustează Ajustează
obiective produs
Ajustare plan rămas
următoare
61
Decizii ale iniŃierii artefactelor <Florin Ostafi>
În faza de iniŃiere este necesar:

Să se decidă
Care artefacte se utilizează în proces
Cum se tratează
Unde se potrivesc în ciclul de viaŃă
Ce instrumente se utilizează
Să se precizeze explicit cum se analizează fiecare artefact
Să se rafineze planul pentru fiecare artefact
Să se decidă ce rapoarte se utilizează
62
Artefact: Caz de dezvoltare <Florin Ostafi>
Responsabilitatea Inginerului de proces

Descrie:
Ce discipline se utilizează
Faze şi milestone-uri
Ce artefacte se utilizează
Cum se utilizează artefactele
Ce activităŃi se realizează
ActivităŃi suplimentare
Cum se lucrează în fiecare disciplină
Planul iteraŃiei
63
Caz de dezvoltare: Exemplu <Florin Ostafi>
BusCase.doc
ItAssess.doc
ItPlan.doc
RiskList.doc
RskMgtPln.doc
SDP.doc
SDP.proj
StatAssess.doc
64
Estimarea efortului şi a timpului <Florin Ostafi>
Se estimează
Efortul total al proiectului (luni persoană)
Timpul total (luni)
Probleme ce apar:
Ce model de estimarea a costurilor se utilizează?
Există în jur de 50 de instrumente de estimare
Aceste instrumente utilizează modele de cost variate
Cum se măsoară dimensiunea proiectului?
Linii de cod?
Puncte funcŃionale?
Use Case-uri?
Altele?
65
Procesul de estimare a costurilor <Florin Ostafi>
Practica predominantă – managerul de proiect defineşte Ńintele de cost, apoi

manipulează parametrii şi dimensiunea până Ńintele de cost pot fi justificate.
Manager,
Manager arhitectură, Acest proiect trebuie să
Manager dezvoltare, coste $X pentru a obŃine
Manager evaluare profit din afacere
Aici se justifică
respectivul cost
Modelări cost
Riscuri, opŃiuni,
optimizări,
alternative Cost estimat
66
Procesul de estimare a costurilor <Florin Ostafi>
4X
Erori în estimarea finală a costurilor
Supra-estimat
0
Sub-estimat
X/4
67
COCOMO II <Florin Ostafi>
Etapa tehnică (IniŃiere şi Elaborare) EArch EApp

RELY – Fiabilitate software cerută
Efort = 2.94 EArch (Dimensiune)ProcesE
DATA – dimensiune bază de date
Etapa de producŃie (ConstrucŃie şi RCPX – fiabilitate şi
complexitate produs CPLX – complexitate produs
TranziŃie) DOCU – documentaŃie potrivită cerinŃelor
Efort = 2.94 EApp (Dimensiune)ProcesE ciclului de viată
RUSE – dezvoltare pentru
reutilizare RUSE – dezvoltare pentru reutilizare
Efort: număr de luni-persoană TIME – constrângeri timp de execuŃie

PDIF – dificultate platformă de
Dimensiune: dimensiune proiect în dezvoltare STOR – constrângeri capacitate de stocare
puncte funcŃionale sau mii PVOL – volatilitate platformă de dezvoltare
de linii de cod ACAP – capacitate analist
ProcesE: formulă bazată pe 5
PERS – capacitate personal PCAP – capacitate programator
parametri (>1.0)
PCON – continuitate personal
EArch: produsul a 7 costuri din
faza de proiectare APEX – experienŃă în aplicaŃie
timpurie PREX – experienŃă personal PLEX – experienŃă în platformă
EApp: produsul a 17 costuri LTEX – experienŃă în limbaj programare
post-arhitectură
TOOL – utilizare instrumente software
FCIL – facilităŃi
SITE – dezvoltare multi-site
SCED – orar de dezvoltare
cerut SCED – orar de dezvoltare cerut
68
Estimarea exponentului ProcesE <Florin Ostafi>
Pe baza scope-ului proiectului şi pe arhitectura curentă se poate estima

dimensiunea codului ce trebuie dezvoltat
Dimensiunea poate fi estimată pe baza:
Liniilor de cod
Punctelor funcŃionale
Use case-urilor
Dimensiunea poate fi estimată de asemenea şi pe baza experienŃei

personale
69
Estimarea dimensiunii <Florin Ostafi>
Efort = 2.94 Ex (Dimensiune)ProcesE

ProcesE = 0.91 + 0.01 Sumă (5 parametri)
Parametri:
PREC – precedenŃă (6.20 → 0.00)
FLEX – flexibilitate (5.07 → 0.00)
RESL – rezoluŃie arhitectură / risc (7.07 → 0.00)
TEAM – coeziune echipă (5.48 → 0.00)
PMAT – maturitate proces (7.80 → 0.00)
70
Estimarea timpului <Florin Ostafi>
Se bazează pe estimarea efortului

Timp = ((EfortProcesT)/SCED)*(SCED%/100)
Termeni:
Efort – calculat cu una din formulele de estimare a efortului;
SCED – orar dezvoltare cerut;
SCED% - procent comprimare orar;
ProcesT – formulă bazată pe cei 5 parametri utilizaŃi în estimarea efortului:
ProcesT = 0.28 + 0.002 Sumă (5 parametri)
Efort 5% 20% 65% 10%
Timp/Orar 10% 30% 50% 10%
DistribuŃie tipică pentru proiectele software noi
71
Efort – activitate pe fiecare fază <Florin Ostafi>
IniŃiere % Elaborare % ConstrucŃie % TranziŃie %
Management 14 12 10 14
Mediu 10 8 5 5
CerinŃe 38 18 8 4
Proiectare 19 36 16 4
Implementare 8 13 34 19
Evaluare 8 10 24 24
Plasare 3 3 3 30
Total 100 100 100 100
72
Artefacte esenŃiale în faza de IniŃiere <Florin Ostafi>
Business Case (Manager proiect)

Listă riscuri (Manager proiect)
Plan de dezvoltare software (Manager proiect)
Plan IteraŃie / Evaluare iteraŃie (Manager proiect)
Work Breakdown Structure (Manager proiect)
Viziune (Analist sistem)
Glosar (Analist sistem)
Model Use-Case (Analist sistem)
Stocare proiect (Manager configuraŃie)
Cerere schimbare (Manager controlul schimbării)
Caz dezvoltare (Inginer proces)
Instrumente (Specialist)
73
Business Case
Descriere produs
Context afacere
Obiective produs
Prognoze financiare
Constrângeri
Listă riscuri
Descriere
Rang
Impact
Indicatori
Strategie diminuare
Timing
Versiune iniŃială la sfârşitul fazei de iniŃiere
Actualizată la fiecare iteraŃie
74
Planul de management al riscurilor

Detaliază administrarea riscurilor asociate proiectului
Detaliază taskurile managementului riscurilor
Atribuie responsabilităŃi
Atribuie resurse suplimentare necesare activităŃilor de management al riscurilor
La proiectele de dimensiuni mici, planul de management al riscurilor poate fi inclus
în Planul de dezvoltare software
Atributele cerinŃelor
stochează cerinŃele proiectului, atributele şi dependenŃele necesare realizării
managementului cerinŃelor
Planul de asigurare a calităŃii
ConŃine Planul de verificare şi Planul de audit
Se menŃine pe toată durata proiectului
75
Plan Proiect Plan Fază

Plan IteraŃie curentă
Faze şi milestone-uri
majore Inclus în planul proiectului
Realizat la începutul IteraŃiile fiecărei faze
fazei de iniŃiere • Număr de iteraŃii
Actualizat de câte ori • Obiective
este necesar • Durată Plan IteraŃie următoare
Work Breakdown Structure Set de activităŃi şi taskuri secvenŃiate în timp
Diagramă Gantt ConŃine resursele alocate şi dependenŃele
Identificare milestone-uri între taskuri
majore şi criteriile de Un proiect are două planuri ale iteraŃiilor active
îndeplinire la un moment dat:
Definirea punctelor de • Planul iteraŃiei curente
livrare importante • Planul iteraŃiei următoare - realizarea
începe la jumătatea iteraŃiei curente şi se
termină la sfârşitul iteraŃiei curente
76
Criterii de evaluare a fazei de IniŃiere <Florin Ostafi>
Stakeholderii sunt de acord cu definirea scope-ului şi cu estimările

de cost şi timp?
CerinŃele sunt înŃelese de către stakeholderi?
Estimările de cost şi timp, priorităŃile, riscurile şi procesele de
dezvoltare sunt credibile?
Cheltuielile actuale cu resursele sunt acceptabile în raport cu
cheltuielile planificate?
77
<Florin Ostafi>
Elaborarea
78
Elaborarea <Florin Ostafi>
Stabilirea unei arhitecturi a proiectului;
Stabilirea unui plan pentru faza de ConstrucŃie; creşterea acurateŃei prin eliminarea
riscurilor de nivel mare;
Demonstrarea faptului că arhitectura propusă poate fi realizată la un cost rezonabil într-un
timp rezonabil.
Elaborarea unei viziuni asupra proiectului – stabilirea unei înŃelegeri fidele a use case-urilor
critice care conduc la decizii arhitecturale şi de planificare;
Elaborarea proceselor şi a infrastructurii – se stabilesc: procesul de construcŃie,
instrumentele, automatizarea proceselor, milestone-uri intermediare şi criterii de evaluare
ale acestora;
Elaborarea arhitecturii şi selectarea componentelor – componentele arhitecturale potenŃiale
sunt evaluate; se iau decizii de tipul “make or buy”; componentele arhitecturale selectate
sunt integrate şi evaluate conform scenariului principal; pot rezulta decizii de reproiectare
sau de reconsiderare a cerinŃelor.
79
EvoluŃia echipei – faza de Elaborare <Florin Ostafi>
50%
10%

20% 20% 10%
50% 20% 20%
IniŃiere Elaborare
10% software
10%

5% 35% 50% 10% 50% 30%
80
Elaborarea <Florin Ostafi>

iteraŃiei
Arhitectură testată Măsurători
Arhitectură stabilită Progres 25%
Riscuri arhitectură diminuate Realizează IteraŃia
Cheltuieli (rate) Medii
planificată
CerinŃe produs rafinate Staff Creşte
Stabilitate Medie
Evaluează Modularitate 25%-50%
iteraŃie Adaptabilitate Variază
Maturitate Fragilă
Proiect
obiective produs
CCB –
cereri
schimbare
aprobate Ajustare plan rămas
următoare
81
Artefacte esenŃiale în faza de Elaborare <Florin Ostafi>
Listă riscuri (Manager Proiect)

Plan de dezvoltare software (Manager Proiect)
Plan IteraŃie / Evaluare IteraŃie (Manager Proiect)
Prototipuri arhitectură (Arhitect)
Document arhitectură software (Arhitect)
Model proiectare (Arhitect)
Model implementare (Arhitect)
Se actualizează lista riscurilor
Viziune (Analist sistem)
Model Use-Case (Analist sistem) Se încearcă diminuarea riscurilor
SpecificaŃii suplimentare (Analist sistem)
Ghid (FuncŃii diferite)
Model date (Proiectant bază de date)
Serii de test (Proiectant teste)
Arhitectură automatizare testare (Proiectant teste)
82
Artefacte cerinŃe principale <Florin Ostafi>
ActivităŃile specifice Ingineriei cerinŃelor încep în faza de IniŃiere

Ingineria cerinŃelor în RUP - crearea unei viziuni asupra proiectului şi translatarea într-
un model use-case. Use case-urile definesc cerinŃele detaliate ale sistemului.
Caracteristici: servicii ce satisfac cerinŃele clienŃilor
AudienŃi principală: stakeholderi şi echipa proiectului
Documentate în artefactul Viziune
CerinŃe funcŃionale: specificarea interacŃiunilor cu utilizatorii sistemului
AudienŃi principală : utilizatori şi echipa proiectului
Modelate în artefactul Modelul Use-Case
CerinŃe suplimentare: specificarea funcŃionalităŃii, fiabilităŃii, performanŃelor, şi
constrângerilor de proiectare
AudienŃi principală : arhitecŃi şi proiectanŃi
Documentate în artefactul SpecificaŃii suplimentare
83
Use case-urile în planificarea iteraŃiilor <Florin Ostafi>
RestricŃii
Planificare proiect
Model Use-Case
( Manager / Arhitect Plan IteraŃie
Proiect)
Plan detaliat pentru
o singură iteraŃie
SpecificaŃii
suplimentare
În timpul
În timpul fazei
fazei de
de Elaborare,
Elaborare, use
use case-urile
case-urile
sunt implementate
sunt implementate pentru
pentru aa valida
valida arhitectura
arhitectura
sistemului
sistemului
84
Schimbarea unui artefact de bază <Florin Ostafi>
CerinŃe schimbare Arhitectură / Design

produs Schimbare produs
Cerere schimbare Cerere schimbare

cerinŃe propusă arhitectură/design propusă
Structură CCB:
Acceptare schimbare
Manager executiv
de către CCB
Manager marketing
Manager proiect
Cerere schimbare Arhitect
amânată Analist sistem
Cerere schimbare
aprobată
Înregistrare pentru Cerere schimbare
următoarea livrare respinsă
Încorporare schimbări
Planificare iteraŃie următoare

pe baza noilor schimbări
85
Criterii de evaluare a fazei de Elaborare <Florin Ostafi>
Viziunea asupra proiectului este stabilă?

Arhitectura sistemului este stabilă?
Elementele majore de risc au fost luate în considerare şi rezolvate
acceptabil?
Planul fazei de ConstrucŃie este suficient de detaliat şi estimat
credibil?
Stakeholderii sunt de acord cu faptul că viziunea curentă asupra
proiectului poate fi îndeplinită dacă se execută planul curent de
dezvoltare a sistemului în contextul arhitecturii curente?
86
<Florin Ostafi>
ConstrucŃia
87
ConstrucŃia <Florin Ostafi>
Minimizarea costurilor de dezvoltare prin optimizarea resurselor şi evitarea
rebuturilor şi a refacerii;
ObŃinerii unei calităŃi adecvate;
Realizarea unor versiuni utile (alpha, beta, şi alte livrări de test).
Managementul resurselor, controlul, optimizarea proceselor;
Terminarea dezvoltării componentelor şi testarea potrivit criteriilor de evaluare;
Evaluarea livrabilelor potrivit criteriilor de acceptare.
Riscurile majore ale proiectului trebuie diminuate şi se fixează

arhitectura sistemului pe baza rezultatului fazei de Elaborare.
88
EvoluŃia echipei – faza de ConstrucŃie <Florin Ostafi>
50% 10%

20% 20% 10% 20% 20%
50%
IniŃiere Elaborare
10%
10%
Arhitectură Dezvoltare Evaluare

5% 35%
Arhitectură Dezvoltare Evaluare
50% 10% 50% 30%
89
ConstrucŃia <Florin Ostafi>

iteraŃiei
Controlul managementului Măsurători
resurselor şi optimizarea Progres 90%
proceselor Realizează IteraŃia
Cheltuieli (rate) Mari
planificată
Terminarea dezvoltării Staff StaŃionar
componentelor Stabilitate Medie
Evaluarea livrabilelor potrivit Evaluează Modularitate <25%
criteriilor de acceptare iteraŃie Adaptabilitate Medie
Maturitate Utilizabilă
Proiect
obiective produs
CCB –
cereri
schimbare
următoare
90
Refacerea în ciclul de viaŃă iterativ <Florin Ostafi>
O refacere extinsă de-a lungul fazei de ConstrucŃie este evitată prin

realizarea unei arhitecturi solide în faza de Elaborare.
O refacere prea extinsă
“Placare cu aur”
CerinŃe instabile
O focalizare insuficientă asupra costurilor şi orarului
O refacere insuficientă
Presiune excesivă asupra orarului
Calitate mică a testării
PercepŃia refacerii ca fiind dovadă de incompetenŃă sau de eşec
91
Refacerea în ciclul de viaŃă iterativ <Florin Ostafi>
100
Prototipul conceptual poate fi

aruncat ⇒ limita superioară poate
75 ajunge la 100%.
Refacere Refacerea după stabilirea bazei
(% din total) Dacă sistemul va încorpora o
arhitecturale trebuie să fie în
cantitate mare de cod folosit în alte
50 total <= 25% din refacerea sistemului
sisteme se va observa un procent
mic al refacerii.
25
Procentajele sunt relative la
sistemul total, nu la conŃinutul celei
mai recente iteraŃii.
92
ImportanŃa testării: Perspectiva managerului <Florin Ostafi>
Testele reprezintă o parte a criteriilor de ieşire din fazele dezvoltării

sistemului.
Testele furnizează posibilităŃi de diminuare a riscurilor.
Testele aplicate codului executabil dau o măsură cuantificabilă a progresului
proiectului.
Rezultatele testelor furnizează măsuri ale calităŃii sistemului.
Testarea este importantă în toate fazele, dar importanŃa se poate schimba
de-a lungul acestor faze:
În fazele de IniŃiere şi Elaborare, când activitatea este focalizată pe rezolvarea
problemelor legate de arhitectură, se pune accentul pe testarea la încărcare;
Testele funcŃionale şi de performanŃă sunt utilizate în faza de Elaborare şi devin
de o mare importanŃă de-a lungul fazei de ConstrucŃie.
93
Artefacte esenŃiale în faza de ConstrucŃie <Florin Ostafi>
Planul IteraŃiei / Evaluarea iteraŃiei (Manager proiect)
“Sistemul“ (Arhitect)
Model proiectare (Arhitect)
Model implementare (Arhitect)
Plan plasare (Manager plasare)
Serii de test (Proiectant teste)
Model date (Proiectant bază de date)
Materiale de instruire (Dezvoltator curs)
94
Criterii de evaluare a fazei de ConstrucŃie <Florin Ostafi>
Baza produsului este suficient de matur pentru a fi plasat în

comunitatea utilizatorilor?
Baza produsului este suficient de stabilă pentru a fi plasat în

comunitatea utilizatorilor?
Există artefacte colaterale gata pentru tranziŃia către comunitatea

utilizatorilor?

95
<Florin Ostafi>
TranziŃie
96
TranziŃia <Florin Ostafi>
ObŃinerea acordului stakeholderilor că plasarea este completă şi

consistentă, în acord cu criteriile de evaluare.
ObŃinerea unei baze pentru produsul final.
Sincronizarea şi integrarea componentelor într-o plasare de referinŃă

consistentă.
Ingineria specifică plasării.
Evaluarea referinŃei de plasare potrivit viziunii proiectului şi a

criteriilor de acceptare.
97
EvoluŃia echipei – faza de TranziŃie <Florin Ostafi>
50% 10%

20% 20% 10% 20% 20%
50%
IniŃiere Elaborare
software
10% 10%

10% 50% 30%
5% 35% 50%
98
TranziŃia <Florin Ostafi>

Planuri de plasare iteraŃiei
Măsurători
Materiale suport pentru
Progres 100%
utilizatorii finali Realizează IteraŃia
Cheltuieli (rate) Mare
Creare produs livrabil planificată
Staff Variază
Se face produs disponibil
Stabilitate Stabil
utilizatorilor finali Evaluează Modularitate 5 - 10%
Se rafinează fin produsul pe iteraŃie Adaptabilitate Medie
baza reacŃiilor primite
Maturitate Robustă
Proiect
obiective produs
CCB –
cereri
schimbare
următoare
99
Criterii de evaluare în faza de tranziŃie <Florin Ostafi>
Utilizatorul este mulŃumit?

100

Mdsi C4 C5 C6 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mdsi C4 C5 C6 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Metodologii pentru dezvoltarea

RUP - Rational Unified Process

Bazat pe cerinŃe Bazat pe arhitectură şi componente

Procesul iterativ poate fi descompus în două etape :

Aspecte din ciclul de viaŃă Etapa inginerească Etapa de producŃie

Reducere riscuri Orar, fezabilitate tehnică Cost

Produse Arhitectură de bază Livrabil de bază

Analiză, proiectare, Implementare, testare

DemonstraŃii, inspecŃii, Testare

Rezolvarea creşterii Exploatarea economiilor

Management Planificare OperaŃii

Etapa inginerească Etapa de producŃie

Milestone Milestone Milestone Milestone

În ciclul de dezvoltare iterativ:

IniŃiere Elaborare ConstrucŃie TranziŃie

IniŃiere Elaborare ConstrucŃie TranziŃie

IniŃiere Elaborare ConstrucŃie TranziŃie

IniŃiere Elaborare ConstrucŃie TranziŃie

Obiectivele propuse în cadrul fazei de pornire sunt îndeplinite;

Clientul este satisfăcut.

IniŃiere Elaborare ConstrucŃie TranziŃie

Un proiect bazat pe RUP evoluează în paşi numiŃi iteraŃii.

Produce livrabile în fiecare iteraŃie

Fiecare livrabil trebuie marcat de:

Creşterea capabilităŃii, constând în implementarea unor funcŃionalităŃi

O profunzime mai mare, constând într-o implementare mai completă a produsului

O stabilitate mai mare, constând în reducerea numărului de schimbări ale

Terminarea muncii planificate pentru iteraŃie

O evaluare a proiectului la sfârşitul fiecărei iteraŃii

Durata unei iteraŃii poate varia funcŃie de

Număr total de iteraŃii [I,E,C,T]

IniŃiere Elaborare ConstrucŃie TranziŃie

Prima iteraŃie este în general cea mai grea

“Wide and Shallow” Problemă

“Narrow and Deep” Problemă

Risc: Eveniment incert care are o probabilitate semnificativă de a afecta succesul

IniŃiere Elaborare ConstrucŃie – TranziŃie

Profil risc – proiect convenŃional (cascadă)

Profil risc - proiect iterativ

Dezvoltarea iterativă produce în primul rând arhitectura sistemului, deci:

Defectele de proiectare sunt detectate şi rezolvate la începutul ciclului de viaŃă.

Permite o abordare mai bună a conceptului de calitate deoarece o mare parte a

Dezvoltarea iterativă permite diminuarea a două riscuri inerente proiectelor software:

Modificarea cerinŃelor - obiectivele produsului (cerinŃele) se schimbă pe parcursul dezvoltării

Echipa se focalizează pe descoperirea obiectivelor – pot apărea obiective pe parcurs.

Dezvoltatorii realizează că nu pot satisface, d.p.d.v. economic, unele cerinŃe.

Strategie de diminuare a riscului:

Validarea frecventă a stării curente a cerinŃelor şi a specificaŃiilor produsului – evaluări

Ajustări frecvente al direcŃiei proiectului astfel încât produsul să satisfacă cerinŃele

NemulŃumirea stakeholderilor – aceştia nu sunt de acord cu produsul livrat.

Stakeholderii descoperă că produsul nu are unele dintre caracteristicile cerute.

Strategie de diminuare a riscului:

Furnizarea unor pre-livrabile ale versiunilor produsului – prezentare iterativă.

Stakeholderii trebuie să participe şi să aprobe schimbările în specificaŃiile produsului –

IniŃiere Elaborare ConstrucŃie TranziŃie

Efort 5% 20% 65% 10%

Timp/Orar 10% 30% 50% 10%

Efort = (Personal)(Mediu)(Calitate) (DimensiuneProces)

Efort: luni-om necesare terminării proiectului

Efort = (Personal)(Mediu)(Calitate) (DimensiuneProces)

Reducerea Dimensiunii sau complexităŃii aplicaŃiei

START: Idee generală asupra SFÂRŞIT: Satisfacerea cerinŃelor

Definire Obiective* Arhitectură Dezvoltare Cod, Documente, Tutoriale