Sunteți pe pagina 1din 100

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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Obiectivele fazelor – Elaborarea <Florin Ostafi>

IniŃiere Elaborare ConstrucŃie TranziŃie


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
<Metodologii ptr. dezv. sist. încorporate>
Obiectivele fazelor – ConstrucŃia <Florin Ostafi>

IniŃiere Elaborare ConstrucŃie TranziŃie


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
<Metodologii ptr. dezv. sist. încorporate>
Obiectivele fazelor – TranziŃia <Florin Ostafi>

IniŃiere Elaborare ConstrucŃie TranziŃie


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
<Metodologii ptr. dezv. sist. încorporate>
IteraŃii în interiorul fazelor <Florin Ostafi>

IniŃiere Elaborare ConstrucŃie TranziŃie


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
<Metodologii ptr. dezv. sist. încorporate>
ActivităŃi în interiorul iteraŃiilor <Florin Ostafi>

12
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Prima iteraŃie <Florin Ostafi>

IniŃiere Elaborare ConstrucŃie TranziŃie


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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Alocarea resurselor în dezvoltarea interativă <Florin Ostafi>

Exemplu

IniŃiere Elaborare ConstrucŃie TranziŃie

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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
ÎmbunătăŃire costuri <Florin Ostafi>

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

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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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

Management Management
10% 10%

Arhitectură Dezvoltare Evaluare Arhitectură Evaluare


5% 35%
Dezvoltare
10% 30%
50% 50%

TranziŃie ConstrucŃie

29
<Metodologii ptr. dezv. sist. încorporate>
Diagrama ciclului de viaŃă al echipei <Florin Ostafi>

ciclul de viaŃă al echipei

30
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
Arhitect / Dezvoltator
Stakeholderi
Test Manager
Verificare progres funcŃionalitate / utilitate Analist sistem
Arhitect / Dezvoltator
Inginer Proces
Analist sistem
Determinare procese proiect, artefacte şi instrumente Arhitect / Dezvoltator
Manager proiect
Manager testare

33
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
EvoluŃia artefactelor de-a lungul ciclului de viaŃă <Florin Ostafi>

39
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Artefacte versus efort <Florin Ostafi>

Impactul artefactelor asupra efortului

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


Artefactele cresc factorul Dimensiune în formulă, deci creşte efortul general
 ExcepŃie: artefactele de tip raport, care sunt generate automat

41
<Metodologii ptr. dezv. sist. încorporate>
Anexă – DependenŃele între membrii echipei <Florin Ostafi>

Diagrama dependenŃelor
între membrii echipei

42
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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.

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

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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
Continuă Stop oprit

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
<Metodologii ptr. dezv. sist. încorporate>
Măsurători în proiectele software <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Măsurători în proiectele software <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Măsurători în proiectele software <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Măsurători în proiectele software <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Măsurători în proiectele software <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
<Florin Ostafi>

IniŃierea

58
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
EvoluŃia echipei – faza de IniŃiere <Florin Ostafi>

Management Management
10%
50%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


50% 20% 20%
20% 20% 10%

IniŃiere Elaborare

Management Management
10% software
10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


5% 35% 10% 30%
50% 50%

TranziŃie ConstrucŃie

60
<Metodologii ptr. dezv. sist. încorporate>
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
Continuă Stop oprit

Ajustează Ajustează
obiective produs

Ajustare plan rămas

Planifică iteraŃia
următoare

Porneşte iteraŃia următoare

61
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Caz de dezvoltare: Exemplu <Florin Ostafi>

BusCase.doc

ItAssess.doc

ItPlan.doc

RiskList.doc

RskMgtPln.doc

SDP.doc
SDP.proj

StatAssess.doc

64
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Procesul de estimare a costurilor <Florin Ostafi>

4X
Erori în estimarea finală a costurilor

Supra-estimat

0
IniŃiere Elaborare ConstrucŃie TranziŃie

Sub-estimat

X/4

67
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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)

IniŃiere Elaborare ConstrucŃie TranziŃie

Efort 5% 20% 65% 10%

Timp/Orar 10% 30% 50% 10%

DistribuŃie tipică pentru proiectele software noi

71
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
Artefacte esenŃiale în faza de IniŃiere <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Artefacte esenŃiale în faza de IniŃiere <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
Artefacte esenŃiale în faza de IniŃiere <Florin Ostafi>

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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
<Florin Ostafi>

Elaborarea

78
<Metodologii ptr. dezv. sist. încorporate>
Elaborarea <Florin Ostafi>

Obiective principale:
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.
ActivităŃi esenŃiale:
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
<Metodologii ptr. dezv. sist. încorporate>
EvoluŃia echipei – faza de Elaborare <Florin Ostafi>

Management Management
50%
10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


20% 20% 10%
50% 20% 20%

IniŃiere Elaborare

Management Management
10% software
10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


5% 35% 50% 10% 50% 30%

TranziŃie ConstrucŃie

80
<Metodologii ptr. dezv. sist. încorporate>
Elaborarea <Florin Ostafi>

Focalizare Porneşte iteraŃia utilizând Planul


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
Continuă Stop oprit

Ajustează Ajustează
obiective produs
CCB –
cereri
schimbare
aprobate Ajustare plan rămas

Planifică iteraŃia
următoare

Porneşte iteraŃia următoare

81
<Metodologii ptr. dezv. sist. încorporate>
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)
Caz dezvoltare (Inginer proces)
Instrumente (Specialist)
Model date (Proiectant bază de date)
Serii de test (Proiectant teste)
Arhitectură automatizare testare (Proiectant teste)

82
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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?
Cheltuielile actuale cu resursele sunt acceptabile în raport cu
cheltuielile planificate?

86
<Metodologii ptr. dezv. sist. încorporate>
<Florin Ostafi>

ConstrucŃia

87
<Metodologii ptr. dezv. sist. încorporate>
ConstrucŃia <Florin Ostafi>

Obiective principale:
 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).

ActivităŃi esenŃiale:
 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
<Metodologii ptr. dezv. sist. încorporate>
EvoluŃia echipei – faza de ConstrucŃie <Florin Ostafi>

Management Management
50% 10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


20% 20% 10% 20% 20%
50%

IniŃiere Elaborare

Management Management
10%
10%

Arhitectură Dezvoltare Evaluare


5% 35%
Arhitectură Dezvoltare Evaluare
50% 10% 50% 30%

TranziŃie ConstrucŃie

89
<Metodologii ptr. dezv. sist. încorporate>
ConstrucŃia <Florin Ostafi>

Focalizare Porneşte iteraŃia utilizând Planul


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
Continuă Stop oprit

Ajustează Ajustează
obiective produs
CCB –
cereri
schimbare
aprobate Ajustare plan rămas

Planifică iteraŃia
următoare

Porneşte iteraŃia următoare

90
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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.

IniŃiere Elaborare ConstrucŃie TranziŃie

92
<Metodologii ptr. dezv. sist. încorporate>
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
<Metodologii ptr. dezv. sist. încorporate>
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)

Caz dezvoltare (Inginer proces)

Instrumente (Specialist)

Materiale de instruire (Dezvoltator curs)

94
<Metodologii ptr. dezv. sist. încorporate>
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?

Cheltuielile actuale cu resursele sunt acceptabile în raport cu


cheltuielile planificate?

95
<Metodologii ptr. dezv. sist. încorporate>
<Florin Ostafi>

TranziŃie

96
<Metodologii ptr. dezv. sist. încorporate>
TranziŃia <Florin Ostafi>

Obiective principale:

 ObŃinerea acordului stakeholderilor că plasarea este completă şi


consistentă, în acord cu criteriile de evaluare.

 ObŃinerea unei baze pentru produsul final.

ActivităŃi esenŃiale:

 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
<Metodologii ptr. dezv. sist. încorporate>
EvoluŃia echipei – faza de TranziŃie <Florin Ostafi>

Management Management
50% 10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


20% 20% 10% 20% 20%
50%

IniŃiere Elaborare

Management Management
software
10% 10%

Arhitectură Dezvoltare Evaluare Arhitectură Dezvoltare Evaluare


10% 50% 30%
5% 35% 50%

TranziŃie ConstrucŃie

98
<Metodologii ptr. dezv. sist. încorporate>
TranziŃia <Florin Ostafi>

Focalizare Porneşte iteraŃia utilizând Planul


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
Continuă Stop oprit

Ajustează Ajustează
obiective produs
CCB –
cereri
schimbare
aprobate Ajustare plan rămas

Planifică iteraŃia
următoare

Porneşte iteraŃia următoare

99
<Metodologii ptr. dezv. sist. încorporate>
Criterii de evaluare în faza de tranziŃie <Florin Ostafi>

Utilizatorul este mulŃumit?

Cheltuielile actuale cu resursele sunt acceptabile în raport cu


cheltuielile planificate?

100