Inginerie Software Pentru Conducerea Proceselor Industriale: Universitatea Piteşti 1

Inginerie Software pentru
conducerea proceselor industriale
Universitatea Piteşti 1
Bibliografie Curs
 Main text:“Software Engineering: A Practitioner’s
Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-
Hill, 2001
 Reference book:“Software Engineering” by Ian

Sommerville, Addison-Wesley, 2001
Obiective curs
 Definirea conceptului de inginerie software
 Înţelegerea importanţei ingineriei software
 Abordarea şi discutarea caracteristicilor importante în
software
 Înţelegerea faptului că aprecierea diferitelor aplicaţii
se poate evalua diferit
Un program simplu
“Scrie un program care obţine studenţii care au
promovat în ordinea rezultatelor obţinute pe parcursul
anilor de studiu şi tipăreşte o listă cu aceştia”
Abordări tipice
 Merge la calculator şi scrie un program
 Găseşte un program vechi şi-l modifică
 Discută cu prietenii cum trebuie realizat programul
 Întreabă profesorul pentru a afla mai multe informaţii
despre program
Ce este Ingineria Software?
 Software?
 Programe care oferă funcţii şi performanţă
 Structuri de date pentru manipularea datelor
 Documente care descriu operaţii şi cum sunt utilizate
programele
 Ingineria?
 O disciplina care aplică metode tehnice şi ştiinţifice în
proiectarea şi realizarea unui produs
Diferenţe între ingineria software şi
ştiinţa calculatoarelor
 Știința calculatoarelor se ocupă cu partea ştiinţifică
în timp ce ingineria software se ocupă cu dezvoltarea,
proiectarea şi livrarea software-ului în timp util
 Teoria din ştiinţa calculatoarelor este insuficientă
pentru a fi considerată o bază completă în ingineria
software (ex. ingineria fizicii şi electrică)
Diferenţe între ingineria
software şi ingineria de sistem
 Ingineria de sistem este concentrată asupra
tuturor aspectelor cu privire la dezvoltarea
sistemelor de calcul incluzând hardware, software
şi procese inginereşti. Ingineria software este o
parte din ingineria de sistem care dezvoltă
infrastructura software, controlul, aplicaţiile şi
bazele de date în sistem
 Ingineria de sistem este implicată în
specificaţiile de sistem, integrare şi implementarea
sistemului.
Definiţia Ingineriei Software
Definiţie IEEE :
Aplicarea unei abordări sistematice, organizată şi
cuantificabilă pentru dezvoltarea, operarea şi
întreţinerea software-lui.
IEEE - Institute of Electrical and Electronics Engineers
Altă definiţie a ingineriei software
Aplicarea practică a cunoştinţelor ştiinţifice în
proiectarea şi realizarea programelor software, precum
şi asocierea la acestea documentaţiei necesare pentru
dezvoltarea, operarea şi întreţinerea lor. (Boehm).
Obiectivele ingineriei Software
 Îmbunătăţirea calităţii produselor software
 Creşterea mulţumirii clienţilor
 Creşterea productivităţii
 Creşterea satisfacţiei locului de muncă
Ingineria Software nu este programare.

Programarea este o parte importantă a
ingineriei software.
“Acesta nu este un curs de programare”
Context istoric
 În primii ani ai calculatoarelor, programele erau
scrise pentru a înlocui munca grea de calcul.
 Programarea nu reprezenta o disciplină, mai mult
era un hobby “arta de a…”
 Cu toate acestea, evoluţia calculatoarelor necesită
programe mai mari ce urmează a fi dezvoltate, de
ex. compilatoare, sisteme de operare
 Programarea devine o profesie.
Caracteristicile programelor
 Programele, înainte erau mici, create de către o persoană
calificată pentru un algoritm. Datele de intrare erau date
numerice şi cele de ieşire erau tipărite la imprimantă.
Dificultăţile apărute erau la nivel de memorie şi
registrele.
 Programele, acum sunt mari şi complexe scrise de un
grup de oameni.
Costurile de software
100%
Hardware Maintenance Software

Development
Total cost
Software Maintenance
1955 1980s
Întârzieri şi instabilitate
 Din 600 de firme, 35% aveau proiecte informatice
scăpate de sub control din punctul de vedere al
bugetului de execuţie;
 Raportul Standish Group privind finalizarea
proiectelor IT din SUA
Lipsa de încredere
 Software care:
 Nu face ce trebuie
 Face ce nu trebuie
 În sistemele complexe (incluzând componente
electronice, electrice, mecanice, hidraulice), de cele
mai multe ori, software-ul este problema cea mai mare
Reprogramarea
 Cerinţele nu sunt specificate complet
 Schimbarea lor conduce la refacerea tuturor fazelor
ulterioare
 Pentru proiectare cu durată lungă, cerinţele clientului
se modifică
 Reprogramarea consumă 30%-40% din efortul total de
dezvoltare
Miturile clienţilor
 Miturile propagate din istoria timpurie a
programării produc aşteptări nerealiste din partea
clienţilor şi nemulţumiri din partea dezvoltatorilor
 Exemple de mituri ale clienţilor:
 O descriere generală a obiectivelor este suficientă pentru
începerea scrierii programului
 Cerinţele se schimbă permanent pentru că software-ul
este flexibil şi se adaptează.
Mituri ale dezvoltatorilor
 În primii ani ai programării, programarea este
văzută ca o formă de artă și nu o profesie
 Exemple de mituri:
 Odată ce programul este scris şi funcţionează, rolul
nostru s-a încheiat
 Până când nu merge programul, nu îi putem evalua
calitatea
 Singurul produs util este programul funcţional
 Ingineria software va crea documentaţie voluminoasă şi
inutilă şi va produce întârzieri
Industria software
 2800 de firme de servicii software
 45 cu mai mult de 100 de programatori şi
venituri până la 100 milioane de dolari
 Până în anii 70, producătorii de calculatoare
vindeau software-ul inclus în preţ (sisteme de
operare, compilatoare, alte utilitare)
 De la 1 ianuarie 1970, IBM a vândut separat
software-ul
Criza software
 La proiectele mari de programare erau necesari
mulţi programatori care lucrau în echipă
 Proiectele care nu erau livrate la timp sau costul
mult mai mare decât a-l bugetului initial
 Software-ul costă de 2-4 ori mai mult decât
hardware-ul.
 Puterea hardware-ului creştea continuu iar
software-ul nu putea ţine pasul.
Criza software
 Un raport arată că:
 2% din sistemele software contractate au funcţionat de
la predare
 3% din sistemele software au putut funcţiona după
câteva modificări
 29% au fost predate dar n-au funcţionat niciodată
 19% au fost folosite dar au fost abandonate
 47% au fost plătite dar niciodată predate
Abordare sistemică
Problema
Analiză
Proiectare
Modele
Dezvoltare
Soluții
Testare/Validare
Caracteristici software
 Software-ul este proiectat și dezvoltat, şi nu fabricat în
sensul clasic
 Software-ul nu se uzează
 În general, cele mai multe programe software sunt
personalizate pe aplicaţii decât să fie asamblate în
componente deja existente.
Ce se înţelege printr-un un
software bun?
Software-ul este intangibil?
Software-ul bun este subiectiv?
Pentru a evalua un software dacă este bun, trebuie să
îndeplinească:
 Corectitudine: un program îndeplineşte
specficaţiile de proiectare.
 Fiabilitate: un program îndeplineşte funcţiile
pentru care este destinat.
 Utilizare: efortul necesar pentru a învăţa,
opera, prepararea datelor de intrare şi
interpretarea datelor de ieşire.
 Integritate: Controlul accesului persoanelor
neautorizate.
Ce se înţelege printr-un un
software bun?
 Eficienţă: cantitatea de resurse de calcul necesare.
 Mentenanţă: efortul necesar pentru a localiza şi depana
erorile într-un program operaţional.
 Portabilitate: efortul necesar pentru a transfera un
program dintr-un mediu software sau hardware în altul.
 Testablitate: efortul necesar pentru a testa un program
pentru a fi sigur că îndeplineşte funcţiile pentru care este
destinat.
 Interoperabilitate: efortul necesar pentru cuplarea
programelor între ele.
 Reutilizare: efortul de a reutiliza programul în alte
aplicaţii.
Aplicaţii software
 Sisteme software
 Real-time Software
 Business Software
 Engineering & Scientific Software
 Embedded Software
 Personal Computer Software
 Telecommunication Software
References
 “Software Engineering: A Practitioner’s Approach” 5th
Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
 “Software Engineering” by Ian Sommerville, Addison-
Wesley, 2001
Ciclul de viaţă
“Ce se întâmplă cu ‘viaţa’ software-ului”
“Să fi foarte atent în cazul în care nu ştii pe

unde mergi, pentru că s-ar putea să nu mai
ajungi acolo.”
Yogi Berra
Obiective curs
 Înţelegerea conceptului de ‘ciclu de viaţă’ al software-
ului
 Înţelegerea proceselor software şi elementele sale
specifice
 Abordarea diferitelor paradigme de inginerie
Ciclul de viaţă al unui software
Ciclul de viaţă al dezvoltării unui produs software
reprezintă o secvență de etape care sunt parcurse
pentru finalizarea acestuia. Sunt incluse toate
activitatile necesare pentru dezvoltarea produsului si
relatiile temporale dintre ele.
Ideea ce ciclu de viaţă a pornit de la considerentul că

fiecare sistem îşi are propria sa viaţă pe parcursul
realizării lui.
Etape principale
 Etapa de definire
 Ce face software-ul
 Etapa de dezvoltare
 Cum lucrează software-ul
 Etapa de validare și verificare
 Cum funcționează software-ul
 Etapa de întreţinere
 Cum poate fi modificat software-ul
Etapa de definire
 Identifică informaţia ce urmează a fi procesată
 Identifică comportamentul sistemului – funcţii şi
performanţă
 Determină constrângeri, interfeţe, criterii de
validare
 Sarcini importante:
 Inginerie de sistem
 Planificarea proiectelor software
 Analiza cerinţelor
Etapa de dezvoltare
 Defineşte structuri de date, implementări de funcţii,
detalii procedurale, interfeţe
 Translatează proiectul în limbaj de programare
 Stabileşte cum se va realiza testarea
 Sarcini importante:
 Proiectare software
 Generare cod
 Testare software
Etapa de validare si verificare
 Validare – ne asigurăm ca produsul software
îndeplinește cerințele utilizatorului
 Verificare - ne asigurăm că programul este
stabil și că funcționează corect din punctul de
vedere al dezvoltatorilor
Etapa de întreţinere
 Reaplică etapele anterioare software-ului existent
 Sunt descoperite greseli si corectate
 Pot apărea schimbări în specificații
 Pot apărea noi cerințe
 Instruirea utilizatorului produsului software
 Tipuri de modificări:
 Corecţii
 Adaptări
 Îmbunătăţiri
 Prevenire
Nivelele ingineriei software
unelte soft
metode
procese
calitate
Uneltele software
Uneltele software reprezintă un suport automat sau semi-
automat pentru crearea metodelor şi a proceselor
 Sisteme software care sunt realizate pentru a furniza

suport automat activităţile proceselor software
 Sisteme CASE care generează automat cod sursă
modele de sistem şi uneori pentru îndrumarea în
realizarea proceselor
Metode software
Metodele constau în tehnicile de realizare a software-ului
 Abordări pentru organizarea dezvoltării software-lui ce
includ modele de sistem, notaţii, reguli, sfaturi şi
îndrumări în procesul de proiectare.
 Modele de descriere – descrierea modelelor grafice ce
trebuie realizate;
 Reguli – constrângeri aplicate modelelor de sisteme
 Recomandări – sfaturi privind practici pe proiectare
eficientă
 Îndrumare – specifică ce activităţi urmează
Procese software
 Procesele reprezintă un set de activităţi ce se referă
dezvoltarea sau evoluţia software-lui.
 Procesele sunt reprezentate de:
 Activităţi cadru – set de task-uri, sarcini comune la
toate procesele
 Activităţi particulare pentru procese în parte
 Procese mature reprezintă un set de capabilități deja
cunoscute pentru dezvoltarea unor produse software
de calitate
Procese fundamentale
• Specificare – ce trebuie sistemul să facă şi care
sunt constrângerile de dezvoltare
• Dezvoltarea – realizarea sistemelor software
• Validarea – verificarea dacă software-ul este ceea
ce-şi doreşte clientul
• Evoluţia – modificarea software-lui ca răspuns la
cererile de schimbare ale acestuia.
Alte tipuri de procese
 Managementul proiectelor software
 Recenzii tehnice formale
 Asigurarea calităţii software-lui
 Configurarea managementrului software
 Prepararea documentelor şi producţiei
 Management reutilizabilitate
 Măsurare
 Management de risk
Calitatea software-lui
 Calitatea software-ului este definită ca un domeniu
de studiu care descrie atributele dezirabile a
produselor software.
 Calitatea funcțională a software-ului reflectă cât de
bine se conformează unui proiect dat, pe baza
cerințelor sau specificațiilor funcționale
 Calitatea structurală a software-ului se referă la modul
în care îndeplinește cerințele non-funcționale cum ar
fi robustetea sau mentenanța
Modele de procese software
 Constă într-o reprezentare simplificată a proceselor
software. Reprezintă o descriere a acestora pentru o
formă particulară dintr-o anumită perspectivă.
 Modele generice de procese
 Modelul în cascadă
 Modelul în V
 Modelul în siprală, etc...
Modelul Waterfall
System
Engineering
Analysis
Design
Code
Testing
Maintenance
Descrire Model
 Descris de Royce în 1970, a fost larg utilizat de atunci,
pentru descrierea generală a procesului de dezvoltarea
programelor.
 Ciclul de viață al modelului în cascadă prezintă dezvoltarea
unui program ca o succesiune de faze ce se înlănțui într-o
derulare liniară, de la analiza cerințelor și până la livrarea
produsului către client.
 Fiecare fază corespunde unei activități ți trebuie să se
termine la o anumită dată prin producerea anumitor
documente sau programe.
 Rezultatele fazei sunt supuse unei revizii aprofundate și nu
se trece la faza următoare decăt atunci când sunt
considerate satisfăcătoare.
Avantaje ale modelului Waterfall
 Uşor de înţeles și de utilizat
 Activităţile decurg dintr-o fază în alta
 Dacă apare o corecţie, se întoarce la faza anterioară după
care intră în ciclul normalProblemele principale sunt uşor
de înţeles
 Bun pentru controlul managementului (organizare,
personal, urmărire)
 Este preferat atunci când pe primul loc este calitatea în
raport cu costul şi timpul de realizare
Probleme ale modelului Waterfall
Model
• Toate cerinţele trebuie să fie cunoscute înainte
• Rezultatele create pentru fiecare etapă sunt
considerate definitive - inhibă flexibilitatea
• Poate da o falsă impresie de progres
• Integrarea este doar o problemă importantă la
sfârşit
• Slabe şanse pentru beneficiar de a previzualiza
sistemul (până când nu va fi prea târziu)
Aplicarea modelului Waterfall
• Cerinţele sunt cunoscute foarte bine
• Definirea produsului este clară
• Tehnologia este bine înţeleasă
• Este o nouă versiune a unui produs existent
• Portarea unui produs existent pe o platformă
nouă.
Management-ul Proiectului
Software
“Ce se întâmplă în cadrul proiectului?”
Universitatea Pitesti 1
Obiective curs
 Discuţii despre diverse aspecte ale managementului
de proiect
 Înţelegerea sarcinilor în managementul proiectelor
software
 Descrierea titulaturilor personalului cu atribuţii de
coordonare în proiect
 Descrierea cerinţelor unui plan de proiect
Project
 Definiţie: reprezintă un grup de sarcini realizate într-o
ordine şi timp predefinite pentru a îndeplinii un set de
obiective.
 Caracteristici proiect:
 este unic (un singur program)
 are un început şi un sfârşit(ciclul de viaţă)
 poate fi împărţit în sarcini separate şi bine definite
 are un buget, necesită resurse
Implică
 Personalul — cel mai important element pentru

succesul unui proiect
 Produsul — software-ul care va fi construit
 Procesele — un set de activităţi comune şi sarcini de
inginerie software pentru a duce treaba la bun sfârşit
 Proiect — toată munca necesară pentru a se realiza
produsul
Un proiect simplu
“Mergând la film cu prietenii”
Managementul
 Planificarea, organizarea, personalul, conducerea şi
controlul resurselor unei companii pentru a întrunii
obiectivele companiei.
Definiţie: Managementul
Proiectelor software
 Planificarea, organizarea, conducerea şi controlul
resurselor pe parcursul unei perioade specificate
pentru a îndeplinii un set specific de obiective la un
moment dat.
Obiectivele primare ale
managementului unui proiect
 întrunirea performanţei specificate
 ... cu un cost
 ... şi pe un program
Activităţi ale Managementului de
proiect
 Stabilirea obiectivelor de proiect
 Definirea cerinţelor de lucru
 Determinarea timpului de lucru
 Stabilirea resurselor disponibile şi a cerinţelor
 Stabilirea costurilor de bază
 Evaluarea şi optimizarea liniilor de bază ale planului
de proiect
Activităţi ale managementului de
proiect (Continued)
 Îngheţarea planului de proiect iniţial
 Extragerea costului actual
 Compararea progresului şi costului pentru planul
iniţial
 Evaluarea performaţelor
 Previzionarea, analiza şi recomandări de corecţie

Beneficiile Managementului de
proiect
 Identificarea tuturor funcţiilor de responsabilitate
pentru a se asigura că toate activităţile sunt
contabilizate, indiferent de schimbările personal.
 Minimizarea nevoii de raportare continua
 Identificarea termenelor limită
 Identificarea unor metodologii pentru analiza
proiectului

Beneficiile Managementului de
proiect
 Măsuri contra planurilor nerealizate
 Identificarea timpurie a problemelor
 Îmbunătăţirea estimărilor pentru viitoarele planuri
 Cunoaşterea obiectivelor care nu pot fi îndeplinite sau
care sunt prea complexe, mari.

Proiectele Software
Factori care influențează rezultatele finale
...
• mărime
• timpul limită de livrare
• bugetul şi costul
• domeniul de aplicare
• tehnologia cu care va fi
implementat
• constrângeri sistem
• cerinţe client
• resurse disponibile

Preocupări ale
managerului de proiect
calitatea produsului?
evaluările riscurilor?
măsurare?
estimare cost?
programarea etapelor pr.?
comunicarea cu clientul?
personalul?
alte resurse?
monitorizare proiect?

Problemele managerului de proiect
 Resurse inadecvate
 Termene de finalizare nerealiste
 Scopuri, direcţii neclare
 Membrii echipei necalificaţi
 Planificări insuficiente
 Probleme de comunicaţie
 Schimbarea scopului şi a resurselor
 Conflicte între departamente sau funcţii

Resursele unei companii
 Bani
 Putere de lucru personal
 Echipament
 Facilităţi
 Materiale
 Informaţii, tehnologie

Obstacole în managementul
proiectului
 Complexitate proiect
 Cereri speciale de la client
 Restructurare organizatorică
 Riscuri de proiect
 Schimbări în tehnologie
 Replanificare şi stabilire a costului

Abilităţi ale manager-ului de
proiect
 Abilităţi de comunicare
 Abilităţi organizaţionale
 Abilităţi de realizare a echipei
 Abilităţi de conducere
 Abilităţi de depăşirea obstacolelor
 Abilităţi tehnologice

Titlu de proiect
 Selectează unul din titlurile de mai jos:

Planificare Proiect
“Ce ai de gând să faci în proiect?”

Elemente planificare proiect
 Scopul şi obiectivele proiectului
 Program activităţi
 Organizare echipă
 Standarde şi proceduri proiect
 Planificare documentare
 Planificare Asigurarea Calităţii
 Planificare managementul resurselor
 Configuraţia planului de management

Paradigme organizare
Paradigme închise — structura echipei este organizată

după o ierarhie de autoritate tradiţională.
Organizare ierarhică

Paradigme Organizare
Paradigmă aleatorie — structura echipei depinde de

iniţiativa individuală a membrilor echipei.
Organizare democratică

Alte structuri organizaţionale
 Paradigmă deschisă — încercările de a structura o
echipă într-o manieră în care controlul se realizează
după paradigma închisă, dar, de asemenea, realizările
care apare sunt asociate după paradigma aleatoare
 Paradigmă sincronă —se bazează pe
comportamentul natural de aliere a membrilor
echipei iar aceştia sunt organizaţi astfel încât sa
lucreze pe porţiuni ale proiectului astfel încât
comunicarea activă dintre ei sa fie minimă.

Liderul de echipă
 Comunicarea cu Lecturer
 Coordonarea activităţilor de proiect
 Are ultimul cuvănt de spus în deciziile în cazul în care
echipa este în imposibilitatea de a ajunge la o decizie

Lider programare
 Responsabil cu activităţile de programare
 Coordonează sarcinile de coordonare în dezvoltarea
software-lui
 Are cunoştinţe de limbaje de programare şi unelte
software

Manager Calitate
 Responsabil pentru calitatea muncii în cadrul
proiectului
 Coordonator în activităţile de testare şi revizuire
 Se asigură că standardele de calitate sunt respectate,
ex. controlul versiunii şi formatul documentelor

Manager Documentare
 Responsabil cu activităţile de documentare
 Coordonator cu sarcinile de preparare a documentelor
 Deţine o copie a tuturor documentelor proiectului

Manager resurse
 Responsabil cu resursele proiectului
 Contabilizează cheltuielile din cadrul proiectului
 Asigură că resursele sunt obţinute pentru sarcinile din
cadrul proiectului, ex. resurse de calcul

Exemplu de proiect standard
 Toate documentele trebuie să aibă un număr de
versiune
 Toate documentele trebuie să fie preparate în MS
Word
 Toate întâlnirile trebuie să fie de ordinul minutelor
 Extensiile fişierelor de proiect au sufixe şi prefixe.

Configuraţia software
 Programele de calculator
 Cod sursă
 Cod executabil
 Documente care descriu programele de calculator
 Pentru personalul tehnic
 Pentru utilizatori
 Datele
 Din program şi externe acestuia

Paragraf din configurarea soft.
 Un document sau artefact care este creat explicit sub o
configuraţie de control şi care se poate referii la
modificarea unei unităţi de bază.
 Exemple:
 Documentele necesare
 Documente de proiectare
 Codul modulelorcode of a module
 Planul de testare

References
 “Software Engineering: A Practitioner’s Approach”
5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
 “Project Management: A Managerial Approach” by
Jack R. Meredith & Samuel J. Mantel, Jr. , John
Wiley, 1989
 “Project Management: Principles and Practices” by
M. Pete Spinner, Prentice-Hall, 1997
 “Goal Directed Project Management”, 2nd Edition,
by Erling S. Andersen, Kristoffer V. Grude & Tor
Haug, Kogan Page, 1995
Planul de proiect
“Ce ai de gând sa faci în proiect?”
Universitatea Pitesti 1
Obiective Curs
 Discuţii asupra sarcinilor pentru planificarea unui
proiect
 Descrierea de unelte care pot fi utilizate pentru
dezvoltarea unui plan de proiect
 Utilizarea reprezentărilor grafice pentru ilustrarea
activităţilor de proiect
Planificarea
Înseamnă:
“Organizarea proiectului într-o ordine logică şi
identificarea sau definirea activităţilor de lucru în aşa
fel încât să ajute la îndeplinirea obiectivelor
proiectului”
Motivele de bază pentru planificare
 Eliminarea incertitudinii
 Îmbunătăţirea eficienţei operaţiilor
 O mai bună înţelegere
 Furnizarea unor elemente de bază pentru
monitorizarea şi controlul muncii
Planificarea proiectului şi controlul
sistemului
Descrierea
Scop/
activităţilor Programări
Obiective
şi instrucţiuni
Managementul Detalierea
În realizarea programărilor
deciziilor
Urmărire
Rapoarte
Timp/Cost/ Buget
sistem
Performanţă
Paşi planificare
1. Stabilirea obiectivelor
2. Dezvoltarea unui plan
3. Construirea unei diagrame de planificare
4. Identificarea perioadelor de timp pentru fiecare
activitate în diagrama de planificare
5. Identificarea costurilor şi a forţei de
muncă/personalul asociat fiecărei activităţi
Stabilire obiective
 Obiective de stare
 Datele de început şi sfârşit ale proiectului
 Bugetul
 Rezultate tehnice
 Listă cu puncte din proiect dificile (milestone)
 Milestone: un eveniment programat pentru care o
persoană este tras la răspundere şi care este utilizat
pentru a măsura progresul şi control
 Desemnarea personalului responsabil pentru
îndeplinirea obiectivelor proiectului
Dezvoltarea unui plan
 Listă activităţi
 Dezboltarea Work Breakdown Structure (WBS):
WBS reflectă descompunerea proiectului în
subactivităţi până la nivelul de control şi
planificare optime
 Determină relaţiile între activităţi
 Prioritate locuri de muncă/succesiune
 Locuri de muncă concurente
Structura WBS - (Work Breakdown
Structure)
 Împarte activităţile proiectului pe mai multe nivele:
Program – Proiect – Sarcini – Unitate de lucru (Work
Package - Work Unit)
 Fiecare unitate de lucru
 Interval de timp scurt
 Specificarea începerea şi sfârşitul activităţii
 Buget în termeni de bani, resurse
 Poate fi atribuită o responsabilitate individuală
 Poate fi realizat un calendar de lucru
Scopul WBS într-un proiect
 Gestionabil
 Independent
 Integrabil
 Măsurabil
Exemplu WBS
Nivel 1
Proiect ABC
Nivel 2
Definiţii Analiză Proiectare Programare ...
Nivel 3
Cerinţe Studiu Analiză ...
documentare Fezabilitate risc
WBS unui proiect simplu
Proiect
Proiectare Plan testare Cod Test
Cod A Cod B
•Fiecare activitate are o perioadă şi consumă resurse.

•Fiecare activitate a constrângeri (de ex. : trebuie ca o
activitate să fie terminată ca să se înceapă la alta,
activităţile sunt executate în ordine).
Program de evaluare şi Tehnică de revizuire
Program Evaluation and Review Technique (PERT) diagram
Plan Test10
Proiect 15 Cod A 18
Test 15
Cod B 18
•Numerele reprezintă durata fiecărei activităţi.

•PERT se bazează, în general, pe timpul fiecărei
activitate şi relaţiilor dintre acestea.
Metoda drumului critic
Critical Path Method (CPM)
 Prin trasarea unei graf a-l activităţilor unui
proiect, poate fi previzionată calea cea mai critică
din acesta.
 Drumul critic este drumul cel mai lung din
cadrul grafului. Dacă o activitate din drumul
critic nu se mai poate încadra în timp,
întregul calendar a-l proiectului.
 Este uşoară ajustarea anumitor activităţi (alocarea
mai multor sau puţine activităţi) când sunt
cunoscute interdependenţele dintre acestea.
Realizarea diagramei de planificare
a unui proiect
 Trasarea succesiunii logice între activităţi
 Precedence Diagramming Method (PDM)
 Activitatea pe nod - Activity on Node (AON)
 Arrow Diagramming Method (ADM)
 Activitatea pe săgeată - Activity on Arrow (AOA)
Termeni
 Activitate – o sarcină care are nevoie de timp şi
utilizează resurse
Este reprezentată printr-o săgeată A
 Eveniment – Momentul în care se termină sau începe o
activitate şi se notează cu nod 1
 Slack time indică ecartul de timp care poate fi alocat
în plus pentru o activitate fără a afecta durata totală a
proiectului.
 Drum critic: calea pe care activităţile nu au slack time.
Activity-on-Arrow (AOA) Diagram
D
2 5
A G
E
B
1 3 6
F
C
4
Fiecare activitate are doar o săgeată

asociată ei.
Precedarea activităţilor
Activitate Predecesor Durată
imediat
A - 2
B - 1
C - 3
D A 2
E B,C 4
F C 5
G D,E 3
Caracteristicile graficelor
 Sunt construite de la stânga la dreapta
 Fiecare activitate poate avea doar un nod de start
 Nu pot fi două activităţi care au aceleaşi noduri de
start şi sfârşit
 În AOA sunt folosite activităţi formale
 Se începe prin căutarea în grafic acele actitivăţi care
nu au nici-un predecesor
 Timpul consumat de activităţi se calculează folosind
mijloace probabilistice sau deterministe.
Activităţi formale DUMMY
 Sunt reprezentate printr-o săgeată punctată
 Sunt utilizate atunci relaţiile dintre activităţi nu
necesită munca.
 Se aplică atunci când:
 două activităţi încep şi se încheie în mod similar
 activităţile ulterioare au dependenţe parţiale cu
activităţile predecesoare.
PERT şi CPM (critical path method)
PERT CPM
 Dezvoltare R&D  Construţie
 Original focalizate numai  Timp şi cost
pe timp  Utilizează estimări
 Utilizează estimări deterministe ale timpului
probabilistice ale timpului  Bazate pe AON
 Bazate pe AOA  Cale critică şi ecartul de
 Cale critică şi timp timp (slack)
pierduţi  Utilizate adesea în
software
Hărţi GANTT
 Reprezentare pe orizontală a timpului pentru hărţi
PERT/CPM, aka Timeline
 Timpi de ecart (Slack) trasaţi prin linii punctate
 Evenimentele din calea critică sunt adesea jaloane
(milestones)
 Inadecvată pentru arătarea dependențelor
 PERT/CPM sunt necesare pentru a controla
programarea în timp.
 Poate fi utilizată ca un mecanism de programare a
timpului.
Exemplu Hartă Gantt
A
D
B
C
F
time
Milestone
Rezumat, planificarea proiectelor
Obiective,
Structură
scop, Criterii tehnice
organizaţională
specificaţii
Documentare
Hartă
WBS Plan Proiect
responsabilităţi
Materiale &
Pachete lucru
Mână de lucru
Grafuri Programări
Arbori de decizie
 Managerii în ingineria software, adesea sunt poziţia
de a lua decizii referitoare de a realiza sau achiziţiona
produse software
 Aceste decizii pot fi soluţionate prin arbori de
decizie.
 Exemplu : Sistem X, poate fi construit (proiectant
locuinţe), reutilizat, cumpărat sau contractat
(angajaţi din afara vânzătorilor).
Realizarea unui arbore de decizie
Calculul costului estimat
Cost estimat =
(calea probabilă) x (estimare cost cale)
i i
Pentru exemplu, costul estimat de a construi este:
cost estimat build = 0.30($380K)+0.70($450K)
= $429 K
similar,
cost estimat reuse = $382K
cost estimat buy = $267K
cost estimat contr = $410K
References
 “Software Engineering: A Practitioner’s Approach”
5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
 “Project Management: A Managerial Approach” by
Jack R. Meredith & Samuel J. Mantel, Jr. , John
Wiley, 1989
 “Project Management: Principles and Practices” by
M. Pete Spinner, Prentice-Hall, 1997
 “Goal Directed Project Management”, 2nd Edition,
by Erling S. Andersen, Kristoffer V. Grude & Tor
Haug, Kogan Page, 1995
Software Metrics
“Cum se măsoară software-ul ?”
Obiective curs
 Înţelegerea importanţei conceptului de măsurare în
ingineria software
 Descrierea şi compararea diverselor metrici care pot fi
utilizate în măsurarea software-ului.
 Înţelegerea factorilor care afectează măsurarea
software-ului
Metodă inginerească
 Ştiinţific
 Precizie
 Acurateţe
 Repetabilă
 Controlabilă
 Calitate
De ce este nevoie de măsurare?
 Să indice calitatea produsului
 Pentru a evalua productivitatea membrilor echipelor
care dezvoltă produsul software
 Pentru a evalua avantajele aduse de noile metode şi
instrumente ale ingineriei software
 Pentru a forma o referinţă de la care se face evaluarea
 Ajută la justificarea unor cerinţe de noi instrumente
software sau formări suplimentare
Definiţii
 Măsură – indicarea cantitativă a unei cantităţi,
dimensiuni, capacitate sau mărimi a unor atribute
de produse sau procese.
 Măsurare – acţiunea prin care se determină măsura
 Metric – o măsură cantitativă în care un sistem,
componentă sau proces dispune de un anumit
atribut (IEEE)
Ce se poate măsura?
 Măsurări directe
 Linii de cod (LOC), viteză, cost, capacitate memorie,
erori, ...
 Măsurări indirecte
 Calitate, funcţionalitate, complexitate, fiabilitatea,
eficienţa, mentenanţa, …
Exemplu: numărul de linii de cod ale unui program este o

măsurare directă.
calitatea scrierii codului poate fi măsurată
indirect prin căutarea raportului dintre calităţile şi
deficienţele pe care le are programul.
Măsurări orientate pe mărime
 Bazat pe “mărimea” software-ului produs.
 Datele proiectului sunt măsurate incluzând costul,
efortul, pagini, defecte…etc.
 În principal se foloseşte LOC (line of cod) ca valoare
de normalizare.
 Avantaje: uşor de numărat, o mare parte din
literatura de specialitate şi date sunt bazate peLOC
 Dezavantaje: depinde de limbaj, depinde de
programator.
 Folositor pentru proiectele care au un mediu
similar.
 Prin urmare, măsurătorile bazate pe mărime sunt
universal acceptate ca fiind cea mai bună
modalitate de a măsura procesele software.
Exemplu de măsurare proiect
Proiect efort cost kLOC Doc. erori personal
(persoana ($) (pag.
- luni) )
aaa-01 24 168,000 12.1 365 29 3
ccc-03 62 440,000 27.2 1224 86 5
Exemplu de metrici orientate pe
mărime
 Productivitate = Mărime / Efort
= kLOC / om-lună
 Calitate = Erori / Mărime
= Erori / kLOC
 Cost = $ / kLOC
 Documentare = pagini / kLOC
 Alte metrici pot fi de astfel create, precum:
erori/KLOC, pagini/KLOC...etc.
 sau erori/om-lună, LOC/om-lună, cost/pagini.
Efort om - lună
 Reprezintă un metric pentru exprimarea efortului
(perioadă de timp) dedicat de către o persoană unui
proiect.
 Calculul om - lună se face prin multiplicarea
numărului de luni cu efortul asociat proiectului.
 Ex.
 25% x 9 luni (an academic) = 2.2.5
 10% x 12 luni (an calendaristic) = 1.2
 35% x 3 luni (sezonul de vară) = 1.05
Metrici orientate pe funcţii
 Bazate pe “funcţionalitate” furnizată de software ca
valoare normalizată.
 Funcţionalitatea este măsurată indirect
 Măsurarea funcţiilor (Function points - FP) măsură
derivată utilizând o relaţie empirică bazată pe
numărarea (directă) a măsurii domeniului de
informare şi evaluări complexităţii software-lui
Valori ale domeniului de informare
software
 Numărul intrărilor utilizator: utilizatori intrare.
 Numărul ieşirilor utilizator : rapoarte, ecrane,
mesaje de eroare, etc.
 Numărul cerinţelor utilizator: o cerinţă de intrare
care generează automat un răspuns la ieşire .
 Numărul de fişiere: fiecare fişier (grupare logică a
datelor) este numărat.
 Numărul interfeţelor externe: sunt numărate
toate interfeţele maşină (e.g. fişierele de date după
dispozitivele de salvare date) care sunt utilizate
pentru transmiterea informaţiei la alt sistem.
Paşi de calcul
1. Numărarea informaţiilor de domeniu.
2. Evaluarea complexităţii valorilor.
3. Calcularea coloanei FP-Function points (tabelul
următor).
4. Evaluarea “factorilor de complexitate” pentru a
rezulta valoarea “ajustare a complexitate”
(complexity adjustment value - CAV)
CAV = ∑ Fi i = 1 to 14
5. Calculul FP ajustat după cum urmează:
FP = raw FP x [0.65 + 0.01 x CAV]
Function Point (FP) Metrics
Weighting Factor
Factor de ponderare
Parameter Count Simple Average Complex
Inputs x 3 4 6 =
Outputs x 4 5 7 =
Inquiries x 3 4 6 =
Files x 7 10 15 =
Interfaces x 5 7 10 =
Count-total (raw FP)
Factorul ratei de complexitate
Pentru fiecare factor de ajustare a complexităţii se dă o
valoare pe o scară cuprinsă între 0 şi 5
0 – Nu influențează
1 - Accidental
2 - Moderat
3 - Mediu
4 - Semnificativ
5 - Important
Factorul de ajustare a
complexităţii(F )
i
1. Are nevoie sistemul de backup sau

recovery?
2. Sunt necesare linii de transfer date?
3. Sunt funcţii de procesare distribuită?
4. Performanţa este critică?
5. Va funcţiona sistemul într-un mediu
operaţional dificil?
Factorul de ajustare a complexităţii
6. Necesită sistemul date de intrare prin interfeţe
cu utilizatorul?
7. O intrare se realizează prin realizarea mai
multor ecrane sau operaţii?
8. Fişierele de date sunt actualizate de fiecare
dată?
9. Sunt fişierele de intrare, ieşire sau cerinţele
complexe?
Factorul de ajustare a complexităţii
10. Procesare internă este complexă?
11. Codul proiectat este reutilizabil?
12. În proiect sunt incluse conversii sau instalări
de pachete software?
13. Sistemul este proiectat pentru instalări
multiple în organizaţii diferite?
14. Aplicaţia este proiectată pentru şi uşor de
manipulat de către client?
Valoarea de ajustare a
complexităţii
 Evaluarea tuturor factorilor, F1 la F14, este realizată prin
valoarea de ajustare a complexităţii (CAV)
 CAV este utilizată pentru calcularea function point
(FP) al software-lui.
Exemple de metrici orientate pe
funcţii
 Productivitate = Functionalitate / Efort
= FP / persoană-lună
 Calitate = Erori / Functionalitate
= Erori / FP
 Cost = $ / FP
 Documentare = pagini / FP
Caracteristici ale FP
 Avantaje: independent de limbaj, bazate pe date din
proiect cunoscute din timp, bune pentru estimare
 Dezavantaje: complexitate calcul, evaluări subiective,
FP nu are un sens fizic (precum numerele)
Extended Function Point Metrics
 Feature points
 applied to systems and engineering software.
 includes assessment for complex algorithms.
 3D Function points
 applied to real-time systems and engineered products
(by Boeing)
 integrates data dimension (normal FP) with functional
and control dimensions
Abordarea metricii
 O serie de studii au încercat să se refere la măsuri de
tip FP şi LOC.
 Relaţia depinde de limbajul de programare şi calitatea
proiectării
 Exemple: un LOC în Ada este aproximativ de 1.4 ori
mai multa ca “funcţionalitate” (în medie) pentru un
LOC în Fortran
Comparaţie dintre LOC şi FP
Limbaje de programare LOC/FP (medie)
Assembly Language 320
C 128
Cobol 105
Fortran 105
Pascal 90
Ada 70
Object-oriented language 30
Fourth-generation language 20
Code generators 15
References
Wesley, 2001
Estimarea costului Software-lui
“Ce avem nevoie pentru un proiect?”
Obiective curs
 Descrierea diferitelor metode de estimarea costului
proiectelor software
 Înţelegerea factorilor care afectează estimarea
dezvoltării unui proiect software
Ce trebuie estimat?
 Timp (programare)
 Resurse
 Cost
Tehnica de estimare în 3 puncte
 Estimează 3 valori pentru fiecare funcţie,
numărare sau valoare informaţie de domeniu
 Valoare optimită (sopt)
 Valoare medie (sm)
 Valoare pesimistă (spess)
 Calculează valoarea aşteptată (expected value -
EV) pentru variabila estimată (mărime), s is:
( sopt + 4 sm + spess )
EV =
6
Exemplu estimare timp
Activitate Predecesor Optimist Mediu Pesimist Durată
imediat (zile)
A - 6 7 14 8
B - 8 10 12 10
C A 2 3 4 3
D A 6 7 8 7
E B,C 4 6 8 6
F B,C 5 7 9 7
G D,E 4 6 8 6
H F 3 3 3 3
Calendar proiect
Calculul duratei proiectului şi calea critică utilizează
următorii termeni de timp:
 Prima dată de început (Earliest Start Time - EST)
 Începerea cât mai curând posibil a proiectului fără a
interfera cu alte proiecte care nu au fost finalizate
 Ultima dată de sfârşit (Latest Finish Time - LFT)
 Cea mai târzie dată de terminare a proiectului fără a
întârzia data de sfârşit a acestuia
Calculul datei de început EST
 Porneşte cu primul nodStart with the first node care
are referinţa de timp 0
 Dacă o săgeată duce într-un nod, EST la acel nod este
EST de la nodul anterior + timpul estimat
A B
5 2
EST=0 EST=5 EST=7
Calculul datei de început EST
 Dacă mai multe săgeţi duc la un nod, atunci EST din
nod este valoarea drumului cel mai mare.
EST=5
C
2
EST=7
D
3
EST=3
Durata proiectului
 Când toate valorile EST au fost calculate, valoare EST
de la ultimul nod va fi durata proiectului
 De asemenea durata poate fi valoarea LFT a ultimului
nod
 Calculul este apoi inversat la nodurile anterioare
pentru valoarea LFT
Calculul datei de sfârşit LFT
 Începe cu ultimul nod, care reprezintă LFT=durata
proiectuluI
 Dacă dintr-un nod pleacă (îşi are originea) doar o
săgeată, valoarea LFT din nod este valoarea LFT din
nodul următor – timpul estimat.
E F
3 1
LFT=6 LFT=9 LFT=10
Calculul datei de sfârşit LFT
 Dacă dintr-un nod pleacă mai multe săgeţi, valoarea
LST a nodului este valoarea cea mai mică a drumurilor
care duc în nodurile următoare
LFT=12
G
3
LFT=5
H
5
LFT=10
Timpul unei activităţi
X
4 LFT=12
EST=5
 Timp activitate = LFT – EST

 Exemplu, timp activitate pentru X = 12 - 5 = 7
 Timp disponibil(float) = Timp activitate - timp estimat
 Exemplu, timpul disponibil pentru X = 7 - 4 = 3
 Timpul activităţii X care are un ‘slack’ 3
 Poate începe mai târziu cu cel mult 3 zile/săptămână
Calea critică
 Toate activităţile şi variaţiile timpului disponibil
incluse constituie calea critică
 Orice întârziere de la aceste activităţi pot afecta durata
proiectului.
Exemplu de cale critică
8 8 17 17
D
2 7
4
A G
8
C 6
E
00 1 3 6 23 23
6
B
H
10 3
F
3 7
5
11 11 18 20 EST LFT
Factori care variază costul
produselor software
 Abilitate programator
 Complexitate produs
 Mărime produs
 Timp disponibil
 Gradul de încredere, siguranţă
 Nivelul tehnologiei utilizate
Estimarea opţiunilor
 Gândire expert
 Estimarea este dată de un panel de experţi
 Abordare Bottom-Up
 Project separated into components
 Estimate components, then combined
 Algorithmic Models
 Use of software metrics, formulas
 Historical models
Gândire expert
 Unul sau mai mulţi experţi sunt consultaţi pentru a
face o estimare asupra proiectului
 În mod inerent abordare top-down
 O abordare comună este de a avea un panel de experţi,
care vor convenii asupra estimării prin consens
 Poate fi afectată de dinamica grupului
 Variaţii interesante: Tehnica Delphi
Tehnica Delphi
 Dezvoltată de Rand Corporation
 Coordonatorul furnizează informaţii estimatorilor
 Estimatorii furnizează estimări individuale, fără
discuţii între aceştia
 Coordonatorul evaluează estimările şi alte răspunsuri,
apoi face distribuiri pentru o altă rundă de estimări
 Estimările se repetă de câte ori este necesar
Abordarea Bottom-Up
 Produsele sau cerinţele sunt împărţite în componente
mici
 Estimările se fac pe componente după care se
realizează estimarea globală
 Aplicabilă structurii de împărţire a muncii (Work
Breakdown Structure), sau alte metode similare de
împărţire a proiectului pe mai multe activităţi
Abordarea Bottom-Up
 Uşor de estimat, se pot face estimări mai detaliate şi
precise
 Cu toate acestea, proiectul poate fi mai mult decât
totalul tuturor componentelor
 Preţul adiţional poate fi necesar pentru îmbunătăţirea
componentelor
Modele algoritmice
 Estimarea utilizează formule matematice care fac
legătura între costuri şi metrici
 Metoda cea mai utilizată kLOC
 Exemplu: estimarea în 3 puncte
 Sunt necesare studii detaliate ale software-ului care
oferă modele empirice de estimare
 Exemplu: COCOMO
Modelul de cost constructiv
Constructive Cost Model (COCOMO)
 Introdus de Barry Boehm
 Foarte des utilizat pentru estimări asupra estimării şi a
costului
 3 modele:
 Basic COCOMO
 Intermediate COCOMO
 Advanced COCOMO
 Selectează modelul pentru estimare, identifică ‘mode’,
estimează kLOC, efortul (şi costul) sunt calculate
după model
Categorii proiecte
Categorie Mărime Inovaţie Constrânge Echipă
ri
Organic mode Mic Puţin Puţine Buna
Semi-detached Mare Multă Multe Mixtă
mode
Embedded Mediu Mediu Foarte -
mode multe
Basic COCOMO
 Calculează efortul dezvoltării software (şi costul)
funcţie de mărimea programului exprimată în linii de
cod.
 Model:
Category ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Ecuaţiile Basic COCOMO
bb
E = abkLOC
db
D = cbE
where
 E este eforul persoană-lună
 D este timpul de dezvoltare în luni
 kLOC reprezintă numărul estimativ de linii de cod
Intermediate COCOMO
 Calculează efortul dezvoltării software în funcţie de
mărimea programului incluzând evaluările subiective de
“cost driver” precum mărimea hardware-lui, personal,
atribute proiect şi atribute proiect
 Se evaluează 15 atribute, de la “very low” la “extra high”,
prin multiplicatorul de efort (din tabel) şi produsul
tuturor multiplicatorilor de efort and product of all
effort multipliers se dă un factor de ajustare a efortului
(effort adjustment factor - EAF)
Atribute “cost driver”
 Product attributes
 Required reliability
 Database size
 Product complexity
 Computer attributes
 Execution time constraint
 Main storage constraint
 Virtual machine volatility
 Computer turnaround time
Atribute “cost driver”
 Atribute personal
 Capacitatea de analist, capacitate de programator
 Experienţă în aplicaţii
 Experienţă pe maşini virtuale
 Experienţă în limbaje de programare
 Atribute proiect
 Utilizarea practicilor moderne de programareUse of
modern programming practices
 Utilizarea uneltelor software
 Necesitatea dezvoltării de programări ale activităţilor
Ecuaţia Intermediate COCOMO
Categorie ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
bi
E = aikLOC × EAF
 unde
 E este efortul persoană – lună ,
 kLOC este numărul estimativ al liniilor de cod
Advanced COCOMO
 Incorporează toate caracteristicile ale intermediate
COCOMO la care se adaugă impactul de “cost driver”
la fiecare proces de inginerie software.
Estimation Issues
 Historical Data
 Accuracy
 Estimation Technique
 Automation
 Improving the Estimate
References
Wesley, 2001
Ingineria de sistem şi analiza
“Care este rolul produsului software?”
Obiective curs
 Examinarea elementelor unui sistem bazat pe calcul
 Înţelegerea şi dezvoltarea procesele unui sistem
 Prezentarea informaţiilor de afaceri ale unui sistem
Definiţie sistem
“O colecţie de componente interconectate pentru
atingerea unor obiective”
Obiectiv: a dezvolta un produs, a suporta

unele funcţii de afaceri…etc.
Informarea despre tipurile de sisteme
 Manuală (citeşti textul cu ochii tăi şi apoi

rezumi utilizând creionul)
 Automat (cauţi informaţia cu ajutorul unui
sistem de calcul)
Proces
Data Informaţie
Medii de sistem
 Interne, de exemplu utilizatorii, structura de
organizare şi procedurile
 Externe, constă în toţi factorii din afara organizaţiei

care afectează sistemul
Elemente de sistem
 Software: programe de calculator, structuri de date şi
documente asociate acestora.
 Hardware: dispozitive electronice de calcul şi dispozitive
de conectare şi interfaţare ale acestora.
 Personal: utilizatori şi operatori.
 Baza de date: o colecţie de informaţii organizate care
sunt accesate prin intermediul unui software.
 Documentare: informaţii descriptive pentru utilizatori şi
operatori (ex. manuale, fişiere)
 Proceduri: paşi care definesc utilizarea specifică a
fiecărui element.
Ciclul de viaţă al unui sistem
Strategie
iniţială
Mentenanţă Cerinţe
Verificare
Studiu
Implementare Fezabilitate
Proiectare Analiză
Fazele ciclului de viaţă al unui sistem
 Strategie iniţială
• Identificarea trebuinţelor, problemelor,
oportunităţilor, obiective şi scopul.
• Critic succesul proiectului.
• Analistul trebuie să fie onest.
• Analistul trebuie să descopere ceea ce
business încearcă să facă.
Fazele ciclului de viaţă ale unui sistem
 Determină cerinţele(Informaţii şi scule software)

• Sunt utilizate mai multe instrumente software
pentru a definii cerinţele iniţiale în afaceri care
constau în eşantionare şi prelevare de probe,
interviuri, chestionare, observare, prototipuri.
• Analiştii se străduiesc să înţeleagă de ce
informaţie au nevoie utilizatorii pentru a-şi
îndeplinii munca lor.
Fazele ciclului de viaţă ale unui sistem
 Studiul de fezabilitate
• Fezabilitate economică, tehnică, juridică (ce poate fi făcut
sau nu).
• Analiză cost – profit, Cost-benefit analysis, evaluare risc
• Decizii de a face sau nu
 Analiză
• Cerinţe de definiţii şi specificaţii
• Aici sunt câteva instrumente şi tehnici speciale care sunt
folositoare în cadrul analizei ca DFD, Data Dictionary
Fazele ciclului de viaţă ale unui
sistem
 Proiectare
• Proiectare logică şi fizică (Proiectare interfeţe, intrări/ieşiri,
fişiere sau baze de date)
• Specificaţii sistem
 Implementare
• Instalare
• Formare, pregătire
• Conversie fişiere
• Testare sistem, securitate
Fazele ciclului de viaţă ale unui
sistem
 Mentenanţă, Verificări şi Test
• Amendamente date de programatori
• Audit de sistem format din programatori şi analişti
Ierarhia ingineriei de
Domeniul de producţie
sistem
Domeniu sau afaceri Vedere generală
de interes
Elemente sistem
Vedere pe domenii
Vedere pe elemente
Vedere detaliată
Ierarhia ingineriei de sistem
 Vedere generală: este studiat întregul mediu de
afaceri şi tehnologic.
 Vedere la nivel de domeniu: domenii specifice de
interes.
 Vedere la nivel de element: sunt analizate
trebuinţele pentru elementele de sistem (e.g. date,
software, hardware, personal) is analyzed.
 Detailed view: analiză, proiectare şi construcţie a
elementului de sistem “ţintă”.
Modelarea sistemelor
Inginerul creează modele care:
 Definesc procese pentru a fi luate în considerare.
 Reprezintă comportamentul proceselor
 Definesc în mod explicit intrările exogene şi endogene
ale modelului
 Reprezintă toate legăturile (incluzând ieşirile) pentru
o mai bună înţelegere a punctului de vedere
Intrări Exogene & Endogene
 Intrările exogene leagă componente de la acelaşi sau
alte nivele .
 Intrările endogene leagă componente individuale un
caracteristici particulare
Factori care afectează modelul de
sistem
 Ipoteze
 Simplificări
 Limitări
 Constrângeri
 Preferinţe
Modelare Enterprize
 Structură organizaţională
 Modelare date la nivel de afaceri
 Modelare procese
 Modelarea fluxului de informaţii
Structura organizaţională
Compania
XYZ
Suport la nivel Vânzări &

Inginerie Fabricare
De corporaţie Comercializare
…..
Finanţe Planificare
Modelare date la nivel de afaceri
descrieri
Produs A vânzări Vânzători
Cumpărări
contracte
evaluări
Întrebări despre
Clienţi asistenţă
Modelare procese
Stabileşte
Prepară comandă
contactul cu
pentru livrare
clientul Furnizează
informaţii
produs
Caută
Furnizează disponibilitate
evaluări produs Adresări produs
întrebări/
referinţe
Acceptă
comandă
vânzător
Modelare fluxului de informaţii
Înregistrare contact
Stabileşte Informaţii produs

Prepară comandă
contactul cu
pentru livrare
clientul Funnizează
Descrieri
informaţii Client
produs d.o. info
produs
Caută
Furnizează
interogări disponibilitate
evaluări
Adresări produs
produs comandă
întrebări/
referinţe disponibilitate
Acceptă
comandă
vânzător Iventar
configurare
Rezumat
 Analiza sistemului furnizează o vedere de ansamblu a
sistemelor bazate pe tehnică de calcul în care sunt
utilizate programe software
 Înţelegerea sistemului conduce la realizarea de
software mult mai performant
 Identificarea elementelor de sistem conduce la
formarea unui cadru pentru cerinţele software
Specificarea cerinţelor software
 Pasarea problemei
 Referinţe sistem, arie de probleme
 Model date
 Diagrame ce arată relaţiile între entităţi
 Cerinţe funcţionale
 Listă de funcţii, Diagrame de contex, DFD
 Model comportamental
 Diagrame de tranziţii stări
 Glosar de termeni
References
Wesley, 2001
Analiza cerinţelor software
“Ce trebuie să facă clientul?”
Obiective curs
 Înţelegerea importanţei specificării corecte a cerinţelor
 Abordarea diferitelor tipuri de reprezentări a cerinţelor
după modele de analiză
 Ilustrarea modelelor în contextul de problemă
Într-o zi la micul dejun...
Nasi Lemak!
Ce se serviţi?
 Nasi Lemak
 Sambal
 Cucumber
 Peanuts ?
 Egg?
 Ikan Bilis ?
 Chicken ?
 Sotong ?
Aşteptări
 Standard: Nasi Lemak + Sambal + Cucumber +
Peanuts + Ikan Bilis
 Preferabil: All above + Egg + Chicken/Sotong
 Dezamăgitor: Nasi Lemak + Sambal + Cucumber
Ce facem
ABC Software!
Primele sarcini
Problemă
analiză
proiectare
Modele
dezvoltare
Soluţii
testare
Analiza cerinţelor software
 Dezvoltatorul şi clientul comunică între ei detaliile
despre software
 Dezvoltatorul - interogator, rezolvator de probleme
 Clientul – cere funcţii şi performanţă
 Probleme:
 Interpretări greşite
 Informări eronate
 Ambiguităţi
Activităţi de analiză a cerinţelor
1. Identificarea problemelor: aşa cum le percepe clientul.
2. Evaluare şi sinteză: analistul definește obiectele de date,
evaluează fluxul de informaţie, defineşte toate funcţiile
software, înţelege comportamentul sistemului şi descrie
constrângerile.
3. Modelare: modele de date, fluxuri informaţionale şi de
control, comportamente operaţionale.
4. Specificări: un model software este creat şi evaluat
împreună de inginerii software şi client.
5. Revizuire: a cerinţelor software date de către dezvoltator
şi client.
Principii în analiza cerinţelor
 Domeniul de informare a unei probleme trebuie
reprezentat şi înțeles.
 Trebuie definite funcţiile cerinţelor
 Trebuie reprezentat comportamentul software-ului
 Modele care descriu informaţii, funcţii sau
comportamente trebuie partiţionate pe nivele sau
ierarhic.
 Procesul de analiză trebuie să se facă de la informaţiile
esenţiale până detalii de implementare.
Recomandări
 Înţelegerea problemelor înainte de crearea modelului
de analiză
 Dezvoltarea unui prototip
 Consemnarea originii şi motivul cerinţelor
 Utilizarea mai multor puncte de vedere
 Prioritizarea cerinţelor
 Eliminarea ambiguităţilor
Model de analiză
Diagramă de
relaţii între Diagrame
entităţi Flude de
date
Dicţionar date
Diagrame de
stări tranziţii de stări
Elementele modelului de analiză
 Dicţionar de date
 Conţine descrierea tuturor obiectelor de date utilizate
 Diagrame de relaţii între entităţi (Entity-Relationship
Diagram - ERD)
 Descrie relaţiile între obiectele de date
 Diagramă flux de date (Data Flow Diagram - DFD)
 Descrie fluxurile de date şi transformari
 Diagramă stări tranziţie (State Transition Diagram -
STD)
 Descrierea comportamentului sistemului
Modelare date
 Identificarea elementelor relevante din domeniul
problemelor
 Reprezentare grafică prin diagrame de relaţii între
entităţi
Diagrame care conţin:
 Entităţi
 Atribute
 Relaţii
Entităţi
 Reprezentarea de articole din domeniul de probleme
care sunt aplicabile pentru sistem
 Au un set de atribute prin care sunt descrise
 Sunt trasate cu etichete dreptunghiulare în diagramele
de relaţii între entităţi (ERD)
Client Membru
Exemple entităţi
 Entităţi externe – (orice care produce sau consumă
informaţie)
 Lucruri (ex. rapoarte sau afişări)
 Apariţii sau evenimente (ex. apel telefonic)
 Rol (ex. agent vânzări)
 Unitate organizaţională (ex. departamentul contabil)
 Loc (ex. depozit)
 Structură (ex. fişier)
Atribute
 Proprietăţi ale entităţii
 Nume de o instanţă
 Descrierea unei instanţe
 Referinţă la altă entitate
 Unul sau mai multe atribute trebuie să fie definite
printr-un identificator keie pentru a fi găsită o
instanţă într-o entitate (ex. numărul ID al unui
student).
 Setul de atribute trebuie să nu fie la fel în diferite
analize.
Relaţii
 Asocieri între instanţele uneia sau mai multor tipuri
de entităţi
 De obicei, înseamnă că evenimentul a avut loc sau
există unele legături naturale între instanţele
entităţilor
 Sunt reprezentate ca linii între entităţi si etichetate
este atribuit Loc de

Angajat
este atribuit la parcare
Cardinalitatea
 Specifică numărul de apariţii a unui obiect care
poate fi asociat unui număr de apariţii din alt obiect
 Expresii uzuale ‘unu’ sau ‘mai multe’
 Posibile rapoarte:
 Unu - la - Unu
 Unu - la mai multe
 Mai multe - la - mai multe
Raport unu la unu
este căsătorit
Membru Soţie
este soţul
“Fiecare membru are o soţie”
Raport unu la mai multe
este căsătorita
Membru Soţ
este soţia
“Fiecare membru are unu sau mai mulți soți”
Raportul mai multe la mai multe
este părintele
Părinţi Copii
sunt copii
“Fiecare are unul sau mai mulţi copii,

fiecare copil are unul sau mai muţi prinţi”
Modalitatea
 Specifică dacă relaţia este opţională sau
obligatorie
 Modalitatea este 0 dacă relaţia este opţională
 Reprezentată prin linii punctate în ERD
 Modalitatea este 1 dacă relaţia este obligatorie
 Reprezentată prin linii continue ERD
Rapoarte opţionale
este căsătorit cu
Membru Soţie
Este soţul
“Fiecare membru are o soţie”
este căsătorit cu
Membru Soţie
Este soţul
“Fiecare membru are una sau mai multe soţii”
Exemplu de diagramă de relaţii
între entităţi
plasează
Client Comandă
plasat la
conţine
parte din
descrieri Comandă
Produs
este o articol
References
Wesley, 2001
 “Modern Systems Analysis and Design” by Jeffrey A.
Hoffer, Joey F. George & Joseph S. Valacich,
Benjamin/Cummings, 1996
Ciclul de viaţă
“Ce se întâmplă cu ‘viaţa’ software-ului”
“Să fi foarte atent în cazul în care nu ştii pe

unde mergi, pentru că s-ar putea să nu mai
ajungi acolo.”
Yogi Berra
Obiective curs
 Înţelegerea conceptului de ‘ciclu de viaţă’ al software-
ului
 Înţelegerea proceselor software şi elementele sale
specifice
 Abordarea diferitelor paradigme de inginerie
Modelul V
Descrierea modelului V
• Este o varianta a modelului cascada, care pune
in evidenta corelarea dintre activitatile de
specificare si cele de testare, inlantuirea in timp
a activitatilor fiind aceeasi
• Partea din stanga reprezinta lantul de specificare a

sistemului iar cea din dreapta lantul de testare. Partea
de jos a v-ului reprezinta implementarea
Etapele modelului V
• Definirea cerintelor • Testarea de acceptare– prevederea
utilizator/sistem – alocare resurse pentru îmbunătăţiri şi corecţii
• Testare sistem – specifică testele la
• Definirea cerintelor software – nivel de sistem
reprezintă specificarea completă a
sistemului
• Integrare şi testare– se verifică dacă
• Proiectarea arhitecturală – toate modulele se interconectează
defineşte cum completează întregul corect
proiect funcţiile software
• Testare module – se verifică
• Proiectarea detaliata – dezvoltarea funcţiile fiecărui modul în parte
de algoritmi pentru fiecare
componentă a sistemului • Codarea – transformarea
algoritmilor în software
Avantaje ale modelului V
• Se fac verificări şi validări ale produsului încă din
faze incipiente ale dezvoltare
• Fiecare unitate realizată trebuie testată
• Managerul de proiect poate urmări progresul
proiectului în punctele principale
Probleme ale modelului V
• Nu este uşor de lucrat cu procese paralele
• Nu se poate lucra la nivel de iteraţii sau
faze!!!!
• Nu este uşor de adus modificări ale
proiectului dacă cerinţele se schimbă
• Nu conţine activităţi de analiză a riscurilor
Aplicarea modelului V
• Proiecte care trebuie să aibă o fiabilitate
ridicată – aplicații software în domeniul
medical
• Toate cerințele trebuie cunoscute de la început
• Soluţiile de dezvoltare pe tehnologii cunoscute
sau deja utilizate
Model de proiectare evolutiv
Start
Culege
Proiectare Construire
cerinţe şi
selectare rapidă prototip
Rafinare Evaluare
Produs prototip clienţi
Stop
Etapele de proiectare ale
modelului evolutiv
• Este realizat un plan preliminar al proiectului
• Este trasat în linii mari un model
• Modelul este sursa pentru realizarea parţială a
specificaţiilor proiectului
• Este construit un prototip pe baza atributelor de
bază
• Proiectantul prezintă prototipul, beneficiarul il
evaluează pentru prevenirea problemelor şi
propunerea de îmbunătăţiri.
• Acest ciclu continuă până când beneficiarul este
mulţumit
Avantaje ale modelului evolutiv
 Beneficiarul poate vedea cerinţele sistemului în
modul în care acestea sunt colectate
 Proiectanţii învaţă de la clienţi
 Un produs mult mai uşor de realizat
 Nu apar cerinţe neaşteptate
 Dă o flexibilitate proiectării şi dezvoltării
 Se văd semne vizibile de proges
 Interacţiunea cu prototipul stimulează gradul de
conştientizare a funcţiilor suplimentare ce
trebuie aduse acestuia
Probleme ale modelului evolutiv
 Tendinţa de abandonare a programării struturate
de către programatori
 Reputaţii slabe pentru folosirea metodelor rapide
de programare şi neconvenţionale
 Intreţinerea sistemului poate fi trecută cu vederea
 Beneficiarul doreşte ca să fie scos ca produs final
prototipul
 Procesul poate continua la infinit
Aplicarea modelului evolutiv
• Cerinţele sunt încă necunoscute şi urmează să se
clarifice
• Cum ar fi etapa de clarificare a cerinţelor în
modelul de cascadare
• Dezvoltarea interfeţelor cu utilizatorul
• Demonstraţii scurte
• O dezvoltare nouă, originală
• Porţiuni de analiză şi proiectare prin proiectarea
orientată pe obiecte
Modelul Incremental
Descrierea modelului Incremental
 Realizarea parţială a întregului sistem
 Completarea pe parcurs a funcţionalităţii
 Modelul incremental pune accent pe
cerinţele de sistem şi apoi implementarea
acestora pe grupuri
 La fiecare versiune ulterioară a sistemului se
adaugă funcţii noi până când acesta este
terminat.
Caracteristici ale modelului
incremental
 Dezvoltarea prioritară a funcţiilor importante şi de risc înalt
 Fiecare versiune de produs trebuie să fie operaţională
 Utilizatorul poate răspunde pentru fiecare versiune
 Utilizează metoda “divide and conquer” de împărţire a
sarcinilor
 Costul iniţial al primului produs este mic
 Timpul de finalizare a primei versiuni este mic
 Utilizatorii pot să utilizeze repede funcţiile importante ale
sistemului
 Riscul apariţiei de cerinţe noi este mic
Probleme ale modelului
incremental
 Necesită o bună planificare şi proiectare
 Necesită definirea rapidă a sistemului
complet şi pe deplin funcţional pentru
definirea cerinţelor
 Este necesară definirea cât mai bună a
interfeţelor ( unele vor fi dezvoltate cu
mult mai înainte)
 Costul total al întregului sistem nu este mic
Aplicarea modelului incremental
 Risc de finanţare, planificare în timp,
complexitate mare sau este necesară realizarea
unei prime versiuni cât mai repede.
 Mare majoritate a cerinţelor este deja cunoscută
dar se aşteptă la apariţia altor noi cerinţe.
 Este necesară obţinerea unui funcţionalităţi de
bază pentru a fi plasat pe piaţă
 Proiecte care prezintă timpi mari de realizare
 Proiectele care au la bază tehnologii noi
Spiral Model
Descrierea modelului
 Adaugă analiza de risc
 Fiecare ciclu implică aceeaşi secvenţă
de etape ca la modelul în cascadă
Cadranul obiective, alternative şi constrângeri
 Obiective: funcţionalitate, performanţă, interfaţă
hardware/software, factori de succes critici
 Alternative: realizare, reutilizare, cumpărare,
sub-contractarebuild,etc.
 Constrângeri: cost, timp realizare interfaţă, etc.
Cadranul evaluare a alternativelor,
identificare şi rezolvare a riscurilor
 Studiul alternativelor relative la obiective şi

constrângeri
 Identificare risc (experienţă, tehnologie nouă,
timp scurt, procese slabe, etc.
 Rezolvare risc (evaluarea cazulului în care ar
putea fi fierduţi bani prin dezvoltarea în
continuare a proiectului
Cadranul dezvoltarea la nivelul următor al
produsului
 Tipuri de activităţi:
 Creare proiect
 Revizuire proiect
 Dezvoltare cod
 Verificare cod
 Testare produs
Cadranul Planificarea fazei următoare
 Tipuri de activităţi:
 Dezvolarea unui plan de proiect
 Devoltarea configuraţiei unui plan managerial
 Dezvoltarea unui plan de test
 Dezvoltarea unui plan de instalare
Caracteristici ale modelului spirală
 Oferă indicaţii din timp asupra riscurilor foarte mari
fără costuri prea mari
 Utilizatorii au acces la system repede datorită
uneltelor de prototipizare rapidă
 Sunt dezvoltate prima dată funcţiile de risk major
 Nu se urmăreşte ca sistemul să fie perfect
 Utilizatorii pot urmării toate etapele ciclului de
dezvoltare
 Răspunsuri şi reacţii rapide de la utilizatori
 Se pot evalua mereu costurile cumulative
Probleme ale modelului spirala
 Timp pierdut pentru evaluarea riscurilor prea mari la
proiecte mici cu risc scăzut
 Timp mai mult pierdut pentru planificare, pentru reluarea
obiectivelor, realizând analiza de risc şi prototipizarea
 Modelul este complex
 Este necesară o expertiză pentru riscul de evaluare
 Spirala poate continua la infinit
 Proiectanţii trebuie să realoce timpul în fazele în care nu
se dezvoltă proiectul
 Este greu de definire a obiectivelor pentru a verifica dacă
procesul necesită o iteraţie următoare
Aplicarea modelului
 Când se creează un prototip
spirala
 Când este importantă evaluarea costului şi a
riscului
 Pentru proiecte cu risc mediu
 Când se schimbă priorităţile economice în
proiecte pe termen lung
 Utilizatorii nu sunt siguri pe ceea ce doresc sa
realizeze
 Cerinţele sunt complexe
 O linie noua de producţie
 Se aşteptă la schimbări semnificative (cercetare şi
exploatare)
Modelul Asamblare pe
componente
Extrage
componentă
yes
Identifică Caută
componente componente sunt? Construieşte
candidate în librării sistem
no
Construieşte
componentă
Component Assembly
Characteristics
 Utilizează tehnologii orientate pe obiect
 Componente – clase care încapsulează date şi
algoritmi în acelaşi timp
 Componente dezvoltate pentru a fi reutilizate
 Paradigmă similară modelului spiral, dar implică
componente în activitatea inginerească
 Sistemul creat este rezultatul asamblării de
componente
References
Wesley, 2001

Inginerie Software Pentru Conducerea Proceselor Industriale: Universitatea Piteşti 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Inginerie Software Pentru Conducerea Proceselor Industriale: Universitatea Piteşti 1

Încărcat de

Drepturi de autor:

Formate disponibile

Inginerie Software pentru

conducerea proceselor industriale

 Reference book:“Software Engineering” by Ian

IEEE - Institute of Electrical and Electronics Engineers

Ingineria Software nu este programare.

Hardware Maintenance Software

“Să fi foarte atent în cazul în care nu ştii pe

Ideea ce ciclu de viaţă a pornit de la considerentul că

 Sisteme software care sunt realizate pentru a furniza

“Ce se întâmplă în cadrul proiectului?”

 Personalul — cel mai important element pentru

Universitatea Pitesti 10

Universitatea Pitesti 11

Universitatea Pitesti 12

Universitatea Pitesti 13

Universitatea Pitesti 14

Universitatea Pitesti 15

Universitatea Pitesti 16

Universitatea Pitesti 17

Universitatea Pitesti 18

Universitatea Pitesti 19

“Ce ai de gând să faci în proiect?”

Universitatea Pitesti 20

Universitatea Pitesti 21

Paradigme închise — structura echipei este organizată

Universitatea Pitesti 22

Paradigmă aleatorie — structura echipei depinde de

Universitatea Pitesti 23

Universitatea Pitesti 24

Universitatea Pitesti 25

Universitatea Pitesti 26

Universitatea Pitesti 27

Universitatea Pitesti 28

Universitatea Pitesti 29

Universitatea Pitesti 30

Universitatea Pitesti 31

Universitatea Pitesti 32

“Ce ai de gând sa faci în proiect?”

Definiţii Analiză Proiectare Programare ...

Proiectare Plan testare Cod Test

•Fiecare activitate are o perioadă şi consumă resurse.

•Numerele reprezintă durata fiecărei activităţi.

Fiecare activitate are doar o săgeată

“Cum se măsoară software-ul ?”

Exemplu: numărul de linii de cod ale unui program este o

ccc-03 62 440,000 27.2 1224 86 5

1. Are nevoie sistemul de backup sau

“Ce avem nevoie pentru un proiect?”

 Timp activitate = LFT – EST

“Care este rolul produsului software?”

Obiectiv: a dezvolta un produs, a suporta

 Manuală (citeşti textul cu ochii tăi şi apoi

 Externe, constă în toţi factorii din afara organizaţiei

 Determină cerinţele(Informaţii şi scule software)

Suport la nivel Vânzări &

Stabileşte Informaţii produs

“Ce trebuie să facă clientul?”

este atribuit Loc de

“Fiecare membru are o soţie”

“Fiecare membru are unu sau mai mulți soți”

“Fiecare are unul sau mai mulţi copii,

“Fiecare membru are o soţie”

“Fiecare membru are una sau mai multe soţii”