Vasile Stoicu-Tivadar 1 / 53

Managementul
proiectelor
software în aplicaţii
medicale
Ţine cu tărie învăţătura şi nu o părăsi,
păzeşte-o căci ea este viaţa ta.
(Pilde, 4;12)
 Obiective
Învăţăm
ce e un proiect (“cu se se mănâncă”) şi cum se
derulează
despre munca în echipă
cum se conduce un proiect în general şi un
proiect software în special
care sunt particularităţile proiectelor software de
informatică medicală ?
un pic de psihologie aplicată

şi vom exersa acestea ca şi cum am lucra la o

companie (vom realiza proiecte în echipă, pe
bune, vom lucra ca la o companie, vom dobândi
experienţă de muncă în echipă şi de conducere
 Conţinut
Noțiuni de bază (proiecte, management, manager, clienții,
succesul)
Despre comunicare
Specificul unui proiect software. Ciclul de viață. Procese,a
ctivități și taskuri
Specificul proiectelor de informatică medicală
Etapele unui proiect software
Echipa
Mecanisme de management . Conducere si planificare
Gestiunea configurațiilor
Metodologii de la companii (Microsoft, Oracle, IBM)
Standarde
 Examen
La examen:
 se răspunde la un test-grilă cu 40-50 întrebări (< 1
min/întrebare)
 trebuie realizat un mic eseu de management de proiect,
pe baza unei teme de proiectare date– timp 1 oră.
Nota examen: media celor două note dar ambele probe
trebuie promovate
La proiect: se va lucra în echipă şi se va primi un punctaj
global care va fi împărţit de membrii echipei între ei
Nota finală = 0.4 p + 0,6 ex
 Universitatea “Politehnica” Timişoara Bul. V. Pârvan nr. 2
Departamentul de Automatică şi Informatică Aplicată 300223 Timisoara
România
http://www.aut.utt.ro

Altele

Managementul proiectelor
software în SIS

Altele
Aplicaţii de e- Opţionale

Health

Evidenţa electronică
a stării de sănătate
a pacientului

Cunoştinţe anterioare
Ingineria programării
mai ales de programare

7
 Condiţii
Cursuri marți 16-18, A115
Titular: Vasile Stoicu-Tivadar
Prezenţa obligatorie la curs și proiect !
Proiect: joi 18-20 (dar într-un stil mai
flexibil, mixat cu prelegerile, din 2 in 2 sapt.)

Vasile Stoicu-Tivadar
Sala proiect: B019

Bibliografie:
•curs în format pdf
•alte documente necesare pentru proiect, în Word sau pdf
 FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE, TIMISOARA
Departamentul de Automatică şi Informatică Aplicată
http://www.aut.utt.ro

Nu
suportăm:
Înşelătoria

Pilele, intervenţiile

Limbajul agramat, lipsa de

cultură

Lipsa de caracter

Complacerea în mediocritate, lipsa de capacitate de

finalizare

9 / 53
FACULTATEA DE AUTOMATICĂ ŞI CALCULATOARE, TIMISOARA
Departamentul de Automatică şi Informatică Aplicată
http://www.aut.utt.ro

Interzis :
Bună !
(Bună ce? ...) bună să-ți fie
inima...

Laborant

Chestie

10 / 53
 Introducere

Ingineria programării: abordări, obiective,

principii
Ciclul de viaţă al progamelor
 Rezolvarea problemelor
(analiză)
Problemele sunt mari ->
trebuie să începem prin a
investiga, prin analiză,
adică prin împărțirea
problemei în bucăți pe care
le putem înțelege și trata.

Important: relațiile sunt la

fel de esențiale ca și
subproblemele înșile
.

12 / 53
 Rezolvarea problemelor
(sinteză)
După ce am analizat problema,
trebuie să construim soluția
din componente care rezolvă
aspecte diferite ale
problemei ->
Sinteză- punem împreună
o structurp mare din blocuri
constructive mai mici
Important: Compunerea unor
soluții individuale poate să fie la
fel de provocatoare ca și găsirea
soluției înseși.
(a se vedea scrierea unui roman: dicționarul cuprinde toate
cuvintele care vor fi folosite în roman, dar partea dificilă a
scrisului constă în a decide cum să fie compusă și organizată
cartea întreagă)
13 / 53
 DE CE calitatea produselor
software este importantă ?
Deseori sistemele nu
Sunt utilizatorii funcționează așa cum am
mulțumiți cu dori și ne-am aștepta:
calitatea produselor codul conține erori dar este
software suficient de bun pentru a
demostra viabilitatea unei
DA și NU abordări

Exemple punctuale pentru lipsa calității:

Cum era înainte de a
exista procesoarele de
text, poșta electronică, ,
INTERNET etc. ?
Există câteva tehnici de a crește calitatea software (testare cu date de test, revizia colegială -
peer review etc.)
1. United States’ Internal Revenue Service – sistemul Creșterea
federal de calcul al taxelor “un fiasco de 4 miliarde” nepermisă a
din cauza proastei planificări costurilor
2. Un sistem SDI (Initiavtiav de Aparare Strategica –
Razboiul Stelelor) ar necesita cel puțin 10 miloane
linii de cod (unii estimează chiar 00 mil.) -> testarea unui Probleme
asemenea volum de cod este aproape imposibilă de testare
3. Software-ul pentru Therac 25 X-ray machine - > Pericol
utilizarea neașteptată , neobișnuită a tastelor săgeți -> a
în
omorât câțiva pacienți
utilizare
14 / 53
 CE este un software BUN?
Contextul determină •Erori tolerate la
procesoarele de text pot
răspunsul să nu fie acceptabile în
sisteme safety-critical

Calitatea
produsului Calitatea
produsului în
contextul
Calitatea mediului (ca
procesului afacere-
care conduce business) în care
la produs produsul va fi
utilizat

Următorul

15 / 53
 Calitatea produsului software

• Software-ul poate
fi evaluat de
utilizarori de
exemplu după
numărul și tipul
căderilor (minore,
majore,
catastrofice), dacă Model care
realizează ce leagă
doresc, dacă este perspectiva
ușor de învățat, proiectantului
ușor de folosit etc. (perspectiva
internă) de cea
•Software-ul poate
a utilizatorului
fi evaluat de
(perspectiva
asemenea de către
externă)
proiectanți
(caracteristicii
interne: numărul și Modelul de calitate al lui
tipul erorilor ca și McCall
măsură a calității
produsului) Înapoi
16 / 53
Calitatea procesului software
Multe activități afectează calitatea produsului.
E demn de atenție răspunsul la întrebări precum:
•Unde și când găsim mai degrabă un anume
tip de erori ?
•Cum să găsim erorile, cât mai degreme în
cadrul procesului de dezvoltare software ?
•Cum să realizăm sisteme tolerante la
defectare astfel încât să minimizăm
posibilitatea ca o eroare să devină o cădere ?
•Există posibilități alternative care să ducă la
un proces mai eficient în asigurarea calității ?
Putem îmbunătăți calitatea unui produs prin
utilizarea unor metodologii și standarde de
calitate precum Capability Maturity Model (CMM)
sau varianta mai modernă CMM Integrated
Înapoi
(CMMI), ISO 9000 și variantele sale adaptate la
neceesitățile dezvoltării software , Software
Process Improvement and dEtermination (SPICE)
17 / 53
 Calitatea produsului în contextul afacerii

Calitatea este privită Returnarea investiției (RI)

din punctul de vedere Return on investment (ROI)
al produselor și
Efort
serviciilor furnizate de
“afacerea” în care (companiile suint
software-ul este interesate în a economisi
înglobat timp sau a în utiliza cât
mai puțin personal):

RI include aspecte precum:

instruire productivitate
programare proces
risc clienți
Înapoi
calitate costuri
“afacere” (rentabilitate)

18 / 53
 Cine practică Ingineria Programării ?
Un element cheie al dezvoltării software este comunicarea dintre client
și dezvoltator.
Situații:
- clientul nu este utilizator
- utilizatorul , clientul și
dezvoltatorul sunt aceași entitate
- clientul poate decide să
achiziționeze software comercial (
commercial off-the-shelf software -
COTS ) pentru a fi încorporat în
produsul final
- utilizarea unor dezvoltatori
suplimentari (subcontractori) care
vor elabora subsisteme
- ca și soluții “la cheie”
Participanții în procesul de dezvoltare software
- pot să necesite un
proces separat de
integrare

19 / 53
 ABORDAREA SISTEMICĂ
Often, the hardware and software we put toghether must interact with
users, with other software tasks, with other pieces of hardware, with
existing databases, with other computer systems -> with the
boundaries of the project.

Example: a program for printing paychecks for the employees; we must

know whether the program simply reads hours worked from another system
and calculate the results or also calculate taxes, pensions etc.

Where does the project begin

and end ? The same question ->
applies to any system
A system - a collection of objects and activities
plus a description of the relationships that tie the
objectives and activities together. Typically: for each
activity, a list of inputs required, actions taken,
outputs produced.
Any collection of component elements
that work together to perform a task.
Examples are a hardware system
consisting of a microprocessor, its allied
chips and circuitry, input and output
devices, and peripheral devices; an
operating system consisting of a set of
programs and data files; or a database
management system used to process
specific kinds of information

20 / 53
 ELEMENTELE UNUI SISTEM
Descriem un sistem enumerând părțile sale și identificând modul în care se
manifestă relațiile dintre componente. Acesta este primul pas în analiza unei
probleme.

intrări
Elemente:
Activități și obiecte
activitate – ceva ce ce întâmplă în sistem
(de regulă descris ca un eveniment inițiat de
un trigger – transformă ceva în altceva
schmibându-i caracteristicile – prin translatare,
schimbare, combinare etc. )
obiect sau entitate – elementele implicate în
activități – uzual relaționate cumva (tabele,
matrici, înregistrări etc. sau văzute
independent, având asociată o listă de
caracteristici – ex. Abordarea Orientată pe
Obiecte)
Relații și marginile sistemului -unele elemente
traversează marginile pentru a intra în sistem, altele sunt
produse ale sistemului și îl părăsesc pentru a fi utilizate
de alt sistem etc.
ieșiri
21 / 53
 ELEMENTELE UNUI SISTEM - EXEMPLE

Putem pune în evidență

părțile componente ale
Sistemului Respirator:
•margini
•entități
•activități

și pentru un sistem pentru salarii

22 / 53
 ABORDAREA INGINEREASCĂ
Îndată ce am înțeles natura unui sistem, putem să îl construim. Aici, partea
“inginerească” a ingineriei programării devine mai importantă.

Proiectele software avansează într-un mod similar cu procesul de construire a unei

case:
analiza și definirea cerințelor
proiectarea sistemului (descrie doar aparențele – poate fi revizuit de client)
proiectarea programului
implementarea programului (scrierea programului)
testele de modul
testele de integrare
testele de sistem
livrarea sistemului
întreținerea
În realitate, mulți din acești pași se repetă (de exemplu, revizuind proiectarea sistemului,
pot să apară noi cerințe).
Definim un proces de dezvoltare software ca orice descriere a dezvoltării software care
conține unele din activitățile de mai sus, organizate astfel încât împreună să producă
cod testat. 23 / 53
 MEMBRII ECHIPEI DE DEZVOLTARE
SOFTWARE
Dezvoltatorii unei aplicații software sunt ingineri software (sau informaticieni)
dar fiecare poate fi specializat în unele din aspectele particulare ale dezvoltării,
conform pașilor din procesul de dezvoltare software:
analiști (de cerințe)
– generează o
descriere la nivel
sistem împreună cu
proiectanții
proiecanți - descriu
sistemul astfel încât
programatorii să
poată scrie linii de
cod care să
implementeze
cerințele
programatori
testori
bibliotecari (pentru întreținerea bibliotecile de module de
instructori – pentru
program)
client
echipa de gestiune a configurațiilor implicată în întreținerea
echipa de
unei corespondențe între cerințe, prioiectare, implementare și
întreținere
testare 24 / 53
 Aspecte etice
În activitatea de dezvoltare soft trebuie urmărite şi aspectele
etice şi sociale ale consecinţelor utilizării produselor proiectate. De
aceea, în activitatea de proiectare trebuie să dea de gândit următoarele
aspecte:
a) înlocuirea rezolvării de probleme ale clienților prin alte
probleme (adică le creăm acestora noi probleme)
Ex: cuplu pervers: masina de tuns iarba, bicicleta ergonomică.

Un reprezentant al clasei de mijloc își cumpără mașină de tuns iarba (scumpă) pentru a
întreține gazonul; deoarece folosind această mașină nu depune efortt, este sedentar
deoarece își risipește unica posibilitate de a depune efort, neavând timp în afară de tunsul
ierbii și își cumpără în consecință și o bicicletă ergonomică (scumpă) pentru a-și menține
sănătatea, în loc să își cumpere o coasă (ieftină) pentru a rezolva ambele probleme.

b. să nu creăm false necesități (exemplu: aparat video

programabil cu prea multe și prea complicate posibilități care nu vor fi
aproape niciodată exploatate);
c) din punct de vedere strategic să orientam corect resursele
disponibile;
d) să nu se uite nici un moment că produsul este realizat pentru a
fi utilizat de oameni. 25 / 53
INGINERIA SOFTWARE, obiective si
principii

Producerea si intretinerea aplicatiilor software, in special cea a sistemelor in timp

real, reprezinta un efort important din punct de vedere:
tehnic
al managementului
financiar

Sunt foarte multe cereinte antagonisce spre rezolvare. Acesta este un motiv
pentru care s-a nascut ingineria software (inca din 1968 - la conferinta NATO)
Ingineria software intentioneaza sa:
• stabileasca ciclul de viata al programleor si continutul etapelor acestora
• elaboreze metode potrivite si tehnici pentru usurarea proiectarii soft
conform unor diferite cicluri de viata
• elaboreze metode pentru activitatile de concepere si administrare

Ingineria software intentioneaza sa treaca de la arta programarii la o

activitate sistematica care poate permite performante sigure.
Ingineria software presupune folosirea in mod sistematic a uneltelor
software, in conformitate cu principiile si obiectivele de baza.
26 / 53
 OBIECTIVE ALE INGINERIEI SOFTWARE
(unele dintre ele)
Obiectivele sunt deziderate pe care proiectanții software le au
în vedere tot timpul ciclului de viață
al programelor: Exemplul 1

Flexibilitatea– posibilitatea de adaptare (mai usoara)

la noile cerinte. Motivele pentru noile cerinte :
• schimbarile la nivel fizic
• noile functii aparute
• extensiiile (volumele de date )

Exemplul 2
Implementarea prin:
•parametrizari
•Structuri de date potrivite,
•Tehnici speciale de
programare,
•Scrierea codului pentru
refolosire etc.
27 / 53
OBIECTIVE ALE INGINERIEI SOFTWARE
(continuare 1)
Eficienta – este un indice calitativ cu doua intelesuri :
• ca performanta a softului insusi (eficienta ca viteza de calcul,
memorie ocupata, etc.) – asociata cu calitatea software
• ca si cost de producere (productivitate) – asociata cu punctul de vedere
al afacerilor (presiunea pietei)
Producatorii trebuie sa obtina un soft mai bun (prin asigurarea unui standard de
calitate) si cat mai rapid posibil (cereri antagonice).Tehnicile ingineriei software
ajuta la rezolvarea acestora.
Fiabilitatea – se refera la evitarea, gasirea si repararea greselilor cat de repede
permite procesul de proiectare, si restabilirea functionarii corecte daca apar erori
de functionare. Nu putem impune aceasta prin adaugarea, mai tarziu, de
componente speciale pentru a creste siguranta;
- este foarte important pentru procesul de control software

Exista cateva tehnici pentru a creste siguranta (redundanta statica si

dinamica, etc.).
Eficienta si siguranta sunt puternic influentate de catre tehnicile ingineriei
software folosite. Statisticile arata ca 60% din erori apartin etapei de analiza si
doar 40% apar in conceperea propriu-zisa (adica de fapt nu s-a inteles bine ce
trebuie facut) 28 / 53
OBIECTIVE ALE INGINERIEI SOFTWARE
(continuare 2)

Perceptibilitatea (readability)- proprietate a programelor de a fi intelese

de catre alti programatori, altii decat autorii (sau chiar de catre autori, la un timp
dupa realizarea unor programe)
Acest atribut creste fiabilitatea dar si adaptabilitatea.

De asemenea, gestionarea unui proiect soft este posibila doar daca

inginerii soft din cadrul echipei de programare asigura o forma standard usor
accesibila a produsului lor.

O proiectare soft buna, care tine cont de toate aceste obiective, este
influentata puternic de catre metode, tehnici si unelte descrise si impuse de catre
inginerul soft.

Obiectivele pot fi atinse prin imprimarea in practica curenta a principiilor

ingineriei soft.

29 / 53
 PRINCIPII ALE INGINERIEI SOFT
Nivel
1. Modularitatea - presupune dividerea Nivel
strategic
superior
programului in entitati diferite cu intrari si iesiri in ierarhie
bine delimitate, numite module program si
structurarea programului in module pentru o mai Obiective
usoara obtinere a unor obiective sigure. (comenzi)
Un modul este cu atat mai independent de
rapoarte
hardware cu cat este mai sus in ierarhia
modulelor -> urmariti diferenta dintre Nivel
Nivel tactic
obiective ale modulelor din ierarhie scazut in
ierarhie
Procesarea
2. Abstractizarea- identificare a proprietatilor controlata a
esentiale ale unor entitati aparent diferite semnalelor
proceselor
industriale

Este de altfel redata Semnalizare avarie Masuratori

Starea semnalelor
ierarhic.

30 / 53
PRINCIPII ALE INGINERIEI SOFT
continuare
3. Localizarea – punerea in vecinatatea fizica a elementelor cu unele
legaturi intre ele
Examplu: functiile unei biblioteci (calcule matematice, interfete grafice,
etc.), functii langa structurile de date folosite, etc.
4. Ascunderea – accentuarea elementelor esentiale si ascunderea detaliilor
care nu afecteaza alte componente ale sistemului
Exemplu: abordarea orientata pe obiecte - incapsularea
Observatie: diferenta dintre abstractizare si ascundere: amandoua
accentueaza aspecte esentiale dar ascunderea defineste restrictiile de acces.
5. Uniformitatea - asigura consistenta programelor, este specifica fiecarui
inginer in programare
Examplu: conventiile proprii ale fiecarui programator in notatii
6. Completitudinea– asigura ca nici una din elementele esentiale nu sunt
omise.
Examplu: - notatiile trebuie sa exprime tot ce este necesar (referitor si la
uniformitate)
7. Confirmabilitatea – informatiile cerute de catre procesul de testare sa
fie formulate explicit si de asemenea disponibile .
Exemplu: necesitatea procedurilor de testare (ca document) 31 / 53
INSEMNATATEA PROCESULUI
Am vazut deja ca procesul de
proiectare are cativa pasi.
Orice proces are urmatoarele caracteristici:
O serie de sarcini cerute:
•Descrie toate activitatile majore ale procesului O serie de pasi implicand
•Foloseste resurse, fiind supus unor serii de activitati, constrangeri,
constrangeri si produce o serie de produse resurse care produc un
intrermediare si finale produs dorit.
•Pot fi formate din subprocese (fiecare are
propriul model de proces)
Cand procesul implica crearea
•Fiecare activitate a procesului are criterii de unui anume produs, ne referim la
intrare si iesire proces ca la un ciclu de viata.
Totusi, procesul de dezvoltare soft
•Activitatiile sunt organizate in secvente
este numit ciclu de viata soft,
•Fiecare proces are un set de principii de deoarece descrie viata unui produs
ghidare care explica obiectivele fiecarei activitati soft de la conceptie la
implementare, livrare, folosire si
•Constrangerile pot fi aplicate unei activitati,
intretinere.
resurse sau produs (exemplu: bugetul sau
programarile pot constrange timpul unei
activitati)

32 / 53
MODELELE PROCESULUI SOFT
Multe modele ale proceselor sunt descrise in literatura ingineriei
soft. Construirea unui model si discutarea subproceselor ajuta
echipa sa distanta dintre ceea ce ar trebui sa fie si ceea ce este.

Motive pentru modelarea unui proces:

•Cand un grup scrie o descriere a procesului sau Fiecare proces de dezvoltare a
de dezvoltare, formeaza o intelegere comuna a modelului soft include cerintele
activitatilor, resurselor si constrangerilor sistemului ca intrare si livrarea
produsului ca iesire.
•Ajuta la gasirea discordantelor si a omisiunilor
Multe asemenea modele au fost
•Modelul trebuie sa reflecte scopurile dezvoltarii propuse de-a lungul anilor.
(calitate ridicata, gasirea de erori, incadrarea in
buget); pe masura ce aplicatia este finalizata,
echipa evalueaza cerintele necesare pentru o
apropiere de obiectivului propus
•Fiecare proces trebuie creat pentru situatia
speciala in care va fi folosit; crearea unui model
al procesului ajuta echipa de programatori sa
inteleaga unde este folosita aplicatia lor.

33 / 53
MODELUL CASCADA (WATERFALL)
 Unul din primele
modele
 Pasii sunt descrisi
in cascada unul
dupa altul
 Un stagiu de
dezvoltare trebuie
terminat inainte de-
a incepe urmatorul
 Prezinta un nivel
mare de vizualizare
a ceea ce se
intampla in timpul
dezvoltarii
 Sugereaza
programatorilor
secventa
evenimentelor pe
care ei ar trebui sa
se astepte sa le
intalneasca

34 / 53
MODELUL CASCADA (WATERFALL)
Programele trebuie proiectate, testate, implementate şi exploatate. În general se
consideră că fazele prin care trece un program sunt:
 Analiza cerinţelor - faza colaborării dintre beneficiar şi echipa de elaborare
pentru a se stabili definiţia exactă a problemei (cerinţe şi restricţii) rezultând în
general o temă de proiectare
 Elaborarea specificaţiilor - faza în care se elaborează un set de specificaţii
formale (descrieri abstracte) pentru programe cuprinzând o descriere detaliată
pentru toate entităţile funcţionale precum şi pentru toate restricţiile.
 Proiectarea programelor - se stabileşte structura pe module, raporturile dintre
ele, modul de comunicare, parametrii de intrare-ieşire, tipuri de date etc..
 Implementarea programului - programarea conform celor stabilite la punctele
anterioare. Se foloseşte un limbaj adecvat pe un calculator gazdă (host
computer)
 Instalarea şi verificarea – pe calculatorul ţintă, al beneficiarului, în condiţii de
exploatare
 Întreţinerea programului - asigură eliminarea erorilor ce se manifestă după
pornirea aplicaţiei

35 / 53
MODELUL CASCADA (WATERFALL)

 In economia unei lucrări, în cadrul primelor 3 etape 40%

reprezintă analiza, elaborarea specificarea şi proiectarea,
20% implementarea şi 40% testarea.
 Codificarea reprezintă de regulă între 16-20 %

 Întreţinerea poate să reprezinte până la 60% din costul total.

De aceea trebuie acordată o atenţie deosebită minimizării
numărului de erori prin: utilizarea unor metode de elaborare
şi testare care să asigure un număr minim de erori şi
structurarea programelor astfel încât acestea să permită
modificarea cât mai uşor.

36 / 53
MODELUL CASCADA - continuare
 Poate fi foarte folositor pentru programatori in a
produce ceea ce doresc
 Simplitatea lui il face mai usor de explicat clientilor
 Multe modele complexe sunt derivate din modelul
cascada

dar (inconveniente)
 nu reflecta intotdeauna modul in care
este implementeat codul
 Modelul nu asigura ghidarea sefilor de
proiecte referitor la cum sa faca fata
schimbarilor si activitatilor care
probabil vor aparea neasteptat in timpul
implementarii (nu ne pregateste pentru
« surprize »)
 Lipsa tratarii soft a ,,procesului de
rezolvare a problemelor’’ (producerea
softului nu este o rutina ci un proces de
creatie) 37 / 53
PROTOTIPURILE
Procesul de implementare soft poate ajuta
pentru a controla ‘’caderile’’ prin
includerea de activitati si subactivitati
care sporesc intelegerea; prototipul este
un asemenea subproces
Un prototip este un produs partial finalizat
care face posibila o examinare a unor
aspecte ale sistemului propus de catre
cumparator si producator pentru a
decide daca este convenabil sau se
apropie de produsul final.
Adesea, interfata cu utilizatorul este
construita si testata ca un prototip, de
aceea utilizatorul intelege cum va arata
noul sistem si designerii au o imagine
mai clara despre cum doreste utilizatorul
sa interactioneze cu sistemul.

Asigura ca sistemul are

implementate toate cerintele

Prototipul este folositor pentru Asigura ca fiecare functie

verificare si validare. functioneaza corect
38 / 53
MODELUL V
Este o variatie a modelului Cascada care
demonstreaza cum activitatile de testare
sunt legate de analiza si proiectare
(Ministerul de Aparare German, 1992)
Forma ciclului de viata dupa modelul V este
cu analiza si proiectarea in stanga, iar
testarea si intretinerea in dreapta.
Sugereaza ca testele de integrare vor fi
folosite de asemenea pentru a verifica
continutul programului --> in timpul
testelor, programatorii si echipa de
testare trebuie sa se asigure ca toate
aspectele conceperii programului au fost
implementate corect cu ajutorul codului.
De asemenea, testarea sistemului
trebuie sa verifice proiectarea
sistemului.
Partea dreapta a modelului V poate fi reexecutata
Testul de acceptanta, care este efectuat mai pentru a repara si imbunatati cerintele, designul si
degraba de client decat de codul inainte ca pasii de testare din partea dreapta
programator(i), valideaza cerintele prin
sa fie finalizati .
asocierea unor pasi de testare cu
fiecare element din lista de cerinte Focus -> documente & produse (Waterfall)
(inainte ca sistemul sa fie acceptat sau
platit). -> activitati & corectitudine (V Model)

39 / 53
 MODELUL DE PROTOTIPIZARE

Prototipizarea poate fi ea insasi baza pentru un model efectiv.

Prototipizarea permite partilor sistemului sa poata fi construite repede pentru a intelege sau clarifica problemele
aparute. Cerinta de repetare a investigatiilor asigura ca programatorul, utilizatorul si clientul ajung la un
acord comun atat in ceea ce este necesar cat si in ceea ce este propus.
Una sau mai multe bucle pentru cerintele prototipului, designului sau sistemului pot fi eliminate, asta
depinzand de cerintele prototipului. Oricum, toate cerintele raman aceleasi: reducerea riscului si
incertitudinea in programare

40 / 53
 PROTOTIPIZAREA - continuare
Caile:
Prototipul facut pe hartie (schite, desene, tabele, rapoarte)
Construirea unui prototip functional (exemplu: interfete construite in Visual
Basic – doar acestea, fara prelucrari)
Folosirea altor programe existente ca modele de referinta

Sunt posibile iteratiile printre cerinte si proiectare.

Avantaje:
• Putem evita riscul unui model
cascada – identificand
neintelegerile despre cerinte,
dintre programator si client
• Imbunatatirea dialogului cu
clientul
Dezavantaje:
• Clientul crede ca aplicatia finala nu este
departe de prototip deoarece acesta nu
stie deaspre partile ascunse ale
aplicatiei
• Programatorul are tendinta sa neglijeze
sau sa uite parti ale aplicatiei care
lipsesc in prototip

41 / 53
DEZVOLTAREA BAZATA PE FAZE
Intervalul de timp dintre cerintele aplicatiei si livrarea sistemului se numeste '‘durata de ciclu'' .
Un mod pentru a reduce acest interval este dezvoltarea bayata pe faze: sistemul este proiectat ca el sa
poata fi livrat în bucãti (sau versiuni), permitandu-le utilizatorilor o parte functionala în timp ce restul este
dezvoltat. Astfel, existã douã sisteme ce functioneaza în paralel - sistemul in exploatare (folosit de client) si
sistemul in dezvoltare.
Sistemul in dezvoltare este versiunea urmãtoare care este pregãtitã sã înlocuiascã sistemul in exploatare
curenta.

SE- Vasile Stoicu-Tivadar 42 / 53

 Incrementari si iteratii
Abordari :
Dezvoltarea incrementala -
Sistemul este impartit în
subsisteme dupa functionalitate
iar varianta finala este la început
dintr-un subsistem de mici
dimensiuni, si dupã aceea cu
fiecare noua imbunatatire i se
adauga functionalitatati noi.
Dezvoltarea iterativã - livreazã un
sistem intreg la început si dupã
aceea schimbã functionalitatea
fiecarui subsistem cu fiecare
varianta nouã (o imbunatateste)
Exemplu: Un program de procesare de text, cu trei tipuri de functionalitate (creare de text,
organizare - taie & lipeste, formare fonturile).

Pentru incrementarea programului, 'varianta 1' contine doar functiile de creare

a textului apoi crearea si organizarea, apoi toate functiile.

Pentru dezvoltarea iterativã, 'varianta 1' contine toate functiile într-o forma
primitiva ( exemplu taie & lipeste este lenta), pe cand 'varianta 2' sporeste
calitatea functiilor etc. Fiecare noua versiune îmbunãtãteste una anterioara
într-un anume fel.
43 / 53
 Incrementari si iteratii - continuare

În realitate, multe companii folosesc o combinatie de dezvoltare iterativã si

incrementala. O varianta nouã poate sã includã o functionalitate nouã, dar
se poate si ca o functionalitatea existenta sa fie imbunatatita.
Motive pentru aceasta abordare:

 Instruirea utilizatorilor poate incepe la primele versiuni ale programului,

chiar daca unele functii lipsesc; acest proces permite urmarirea in
exploatare si imbunatatirea programului
 Piata poate fi creata inainte ca produsul sa fie aparut
 Frecvent produsele permit programatorilor remedierea problemelor
neanticipate repede, pe mãsura ce ei sunt avertizati de la activitatea de
mentenanta.
 Echipa de dezvoltare se poate concentra pe domenii diferite de expertizã cu
diferite versiuni
Exemplu: un produs imbunatateste interfata, celalalt, performanta.

44 / 53
 MODELUL SPIRALA

Combinã activitatea de dezvoltare cu managementul de risc pentru a minimiza si

controla riscul (Boehm, 1988). Modelul acesta este într-un fel asemenea
dezvoltarii iterative.
 Începând cu o schitã initialã, procesul insereazã un pas pentru a evalua
riscul si o alternativa de prototip înaintea ca un document de ''concept al
operatiilor'' sa fie creat pentru a descrie la un nivel înalt cum ar trebui sã
functioneze procesul de dezvoltare al sistemul.
 Apoi, cu fiecare iteratie, analiza riscurilor cantareste diferitele alternative din
punct de vedere al cerintelor si constrangerilor, iar prototipizarea verifica
fezabilitatea inainte ca o anumita alternativa sa fie aleasa.
 Când riscurile sunt identificate, managerii de proiect trebuie sã se hotãrascã
cum sa-l elimine sau sa-l minimizeze.
Exemplu: Proiectantii nu pot sã fie siguri dacã utilizatorii vor prefera un tip de
interfatã sau altul; pentru a minimaliza riscul, ei pot produce o interfata
pentru fiecare prototip si sa efectueze testele pentru a vedea care este cea
preferata.

45 / 53
MODELUL SPIRALA – continuare 1

46 / 53
MODELUL SPIRALA– continuare 2

(sau alta
reprezentare
simplificata)

Acest model este folosit pentru proiecte la scara mare, care implica
un risc deosebit (adica resurse financiare mari).
47 / 53
Dezvoltare AGILĂ

 Accent pe cod mai degrabă decât pe un

proiect predefinit
 Dezvoltare iterativă

 Livrare rapidă și flexibilitate pentru a

îndeplini cerințe în schimbare
Manifesto AGILE
 Mai degrabă indivizi și interacțiuni decât procese și unelte
 Software care funcționează mai degrabă decât o bună documentație
 Colaborare cu clientul mai degrabă decât negociere contractuală
 Răspuns la schimbări mai degrabă decât urmărirea unui plan

48 / 53
Dezvoltare AGILĂ– continuare

 PRINCIPII
 Satisfacerea nevoilor clientului prin livrarea continuă și rapidă
de software util
 Software-ul este livrat frecvent (săptămâni)

 Software-ul care lucrează este principala măsură a progresului

 Chiar și schimbări târzii sunt acceptate

 Cooperare apropiată (zilnică) între dezvoltatori și cei implicați

în business
 Conversația față în față – forma de comunicare dorită

 Încrederea trebuie construită în permanență între indivizi

motivați
 Atenție continuă la buna proiectare și calitatea din punct de
vedere tehnic
 Simplitate

 Echipe care se auto-organizează

49 / 53
 Exemple de dezvoltare AGILĂ
SCRUM- 1
1. SCRUM
Teoria Scrum
 Scrum este bazat pe o teorie empirică de control a proceselor, sau
empirism. Empirismul afirmă faptul că sursa cunoștințelor este experiența,
și luarea deciziilor se bazează pe ceea ce este știut. Scrum folosește o
abordare iterativă, incrementală cu scopul de a optimiza predictibilitatea și
de a controla riscul.

Trei piloni susțin orice implementare a controlului procesului empiric:

transparența, inspecția și adaptarea.
Transparența Aspecte semnificative ale procesului trebuie să fie vizibile celor
responsabili de rezultate. Transparența necesită ca aceste aspecte să fie
definite de un standard comun astfel încât observatorii să împărtășească
puncte de vedere comune asupra a ceea ce văd.
De exemplu:
 Un limbaj comun referitor la proces trebuie să fie împărtășit de către toți
participanții; și,
 O definiție comună a statusului “Finalizat” trebuie împărtășită de către cei
care efectuează munca și cei care acceptă munca rezultată.

50 / 53
 Exemple de dezvoltare AGILĂ
SCRUM - 2
Inspecția Utilizatorii Scrum trebuie să inspecteze în mod firesc
progresul făcut către îndeplinirea obiectivului, astfel încât să
detecteze abaterile nedorite. Inspecția lor nu trebuie să fie atât de
frecventă încât să afecteze modul de lucru. Inspecțiile sunt cele mai
benefice atunci când sunt efectuate în mod sârguincios la locul de
muncă.
Adaptarea Dacă un inspector stabilește că unul sau mai multe aspecte
ale procesului deviază în afara unor limite acceptabile, și că produsul
rezultat va fi inacceptabil, procesul sau materialul procesat trebuie
să fie ajustat.

Scrum recomandă patru oportunități formale pentru inspecție și

adaptare
  Ședința de Planificare a Sprint-ului
  Ședința Scrum Zilnică
  Ședința de Revizuire a Sprint-ului
  Retrospectiva Sprint-ului

51 / 53
 Exemple de dezvoltare AGILĂ
SCRUM - 3
 Sprint-ul (The Sprint) Inima Scrum-ului este un Sprint, cu o durată de maxim o
lună, în timpul căruia este creat un Increment al produsului, cu statusul "Finalizat"
("Done"), utilizabil și potențial livrabil. Sprint-urile au durate consistente pe toată
durata efortului de dezvoltare. Un Sprint nou începe imediat după aflarea concluziilor
Sprint-ului anterior.
Sprint-urile conţin şi constau din Ședința de Planificare a Sprint-ului (Sprint Planning
Meeting), Ședința Scrum Zilnică (Daily Scrums), activitatea de dezvoltare, Ședința de
Revizuire a Sprint-ului (Sprint Review Meeting) și Retrospectiva Sprint-ului (Sprint
Retrospective).
 În timpul Sprint-ului:
  Nu se aduc modificări care ar putea afecta ținta Sprint-ului;
  Componenţa echipei de dezvoltare şi obiectivele de calitate rămân constante; şi,
  Posibilitățile (scope) pot fi clarificate şi re-negociate între Product Owner şi echipa
de Dezvoltare (Development Team) pe masură ce se progresează.

Fiecare Sprint poate fi considerat un proiect cu un orizont de timp nu mai mare de o

lună. La fel ca și proiectele, Sprint-urile sunt folosite pentru a realiza ceva. Fiecare
Sprint are o definiţie a ceea ce urmează să fie construit, un design și un plan flexibil,
care îl vor ghida în procesul de realizare cât și în produsul rezultat.

52 / 53
 Exemple de dezvoltare AGILĂ –
CLEANROOM - 1
 Numele “cleanroom” vine de la procesul de fabricare a
semiconductorilor (“camera curată”)
 Filosofia este mai degrabă evitarea defectelor decât
înlăturarea lor
 Metodă de dezvoltare software bazată pe metode
formale
 Verifică specificaţiile de proiectare folosind demonstrarea
corectitudinii, cu metode matematice (v. cap. Testare)
 Se bazează puternic pe metode de testare statistice
pentru a descoperi erorile de impact major
 În general se bazează pe metode de dezvoltare
incrementale
53 / 53
 Exemple de dezvoltare AGILĂ –
CLEANROOM - 2
ETAPE
 Cerinţe – se defineşte, pentru fiecare increment, o descriere a
cerinţelor la nivelul clientului
 Specificarea structurii de cutie (box) – descriu specificaţiile
funcţionale
 Proiectarea Formală – specificaţiile (“cutii negre”) sunt rafinate
iterativ (cu un increment, astfel ca să devină analoge cu proiectarea
arhitecturală şi cea procedurală (“cutii de stare”, respectiv “cutii
transparente”)
 Verificarea corectitudinii – prin chestionare, de către echipă
 Testare Statistică – un eşantion al tuturor cazurilor de test
posibile este mai degrabă utilizat decât testarea exhaustivă
 Certificarea – după ce verificarea, inspecţia şi testele de uzanţă
sunt terminate şi toate defectele înlăturate, incementul este
certificat şi gata pentru integrare
54 / 53
 Exemple de dezvoltare AGILĂ –
CLEANROOM - 3
Formally Error rework
specify
system

Define Construct Formally

Integrate
software structured verify
increment
increments program code

Develop
operational Design Test
profile statistical integrated
tests system

55 / 53
 PROIECT (în general)

Ce este un proiect ?
 Are de-a face cu realizarea unor schimbări într-o manieră organizată.

Definiții:
O formă temporară de organizare căreia i se alocă resurse pentru a realiza
activitățile menite să aducă o schimbare benefică.
Un demers cu caracter unic și tranzitoriu, constituit în vederea atingerii unui
rezultat dorit.
Un proces unic, constând dintr-un set de activități coordonate și controlate,
cu date de începere și finalizare, având scopul realizării unui obiectiv
conform anumitor cerințe specifice, încluzând constrângeri de timp, costuri
și resurse.

56 / 53
Proiect

Pentru a putea reliza o schimbare dorită, un proiect trebuie să aibă

următoarele caracteristici:
 Să fie un demers unic (fiecare proiect trebuie să fie altfel decât
celelalte)
 Să aibă obiective specifice de îndeplinit

 Să aibă la dispoziție resurse

 Să aibă un buget

 Să aibă un calendar de activități

 Să beneficieze de efortul unor oameni

 Să i se aplice criterii de calitate

Metafora călătoriei: deplasarea cotidiană cu mașina de acasă la

serviciu este o rutină, dar o excursie făcută special pentru a vedea
un anumit loc este un proiect.

57 / 53
Proiect
Justificare economică:
 Ce doriți să realizați

 De ce

 Cum aveți de gând să procedați

 Cînd

 Cine va fi afectat

 Ce resurse sunt necesare

Succesul unui proiect

 și-a îndeplinit obiectivele de calitate, durată, cost
 a îndeplinit cerințele clientului, așa cum le percepe
 reușește rezultatul să-l convingă pe client să revină să contracteze
un nou proiect
 după încheierea proiectului, a rămaas organizația capabilă să-și
continue cum tebuie activitatea
58 / 53