1 Fundamente in Ingineria Programarii PDF

Obiectivele
pentru capitolul I - Fundamente

Obiectivele și principiile
ingineriei software. Ciclul
de viață
viață..
•Câțiva termeni
•Misiunea inginerilor software
•Abordări specifice
•Obiective
•Principii
•Produse pentru dezvoltare software,
procese si resurse
•Modele ale procesului de dezvoltare
software
•Standarde
IP
IP-- Vasile Stoicu-
Stoicu-Tivadar 1 / 53
Sistem de calcul utilizat pentru conducerea unor
Câțiva termeni părţi sau în totalitate unor părţi sau în totalitate a

unui proces în sens larg (sau numai proces
Sisteme de conducere cu calculatorul a tehnologic) cu scopul realizării şi menţinerii unor
tehnologice)) (computers in
proceselor (tehnologice performanţe tehnice şi economice şi care
prezintă anumite cerinţe specifice obligatorii
(industrial) process control) (răspuns rapid, siguranţă în funcţionare).
Echipament
Interfețe
de
proces
Proces
Operator
uman
Software
Proceduri de
operare
IP - Vasile Stoicu-
Câțiva termeni Def.: un sistem on-line (legat de proces)
caracterizat printr-o valoare prescrisă a
timpului de răspuns (de cele mai multe
ori de ordinul secundelor sau fracţiuni
Sisteme în timp real de secundă) fiind capabil să
urmărească şi să răspundă în timp util
la solicitările din exterior.
Este vorba de acele sisteme la

care o abatere de la limita maximă a
timpului de răspuns să însemne
incidente grave în mediul controlat.
IP
IP-- Vasile Stoicu-
Câțiva termeni
Stil de programare modul de aplicare a tehnicilor de programare,
mod de documentare a programului, de aşezare
în pagină a textului sursă, în general totalitatea
atributelor care conferă unui program o anumită
personalitate urmărind realizarea unor anumite
performanţe.
IP - Vasile Stoicu-
Demn de atenție !
Programarea nu este o artă ci o activitate

inginerească pretenţioasă:
•nu poate fi realizată decât în echipă
•programele obţinute trebuie să fie user-
friendly şi nu pentru specialişti
•trebuie să poată fi înţelese si modificate
de către alte persoane decât proiectanții
IP - Vasile Stoicu-
Câțiva termeni
Ingineria programării Proiectarea și dezvoltarea aplicațiilor software
(Software Engineering)
Domeniu al informaticii ce se ocupă cu

determinarea celor mai adecvate soluţii,
procedee şi instrumente care să conducă în
condiţii optime la elaborarea unui produs
program astfel ca acesta să satisfacă toate
cerinţele impuse de specificaţiile de
definire.
IP - Vasile Stoicu-
CE ESTE de fapt Ingineria Programării?
Programării?
Ca și Inginer Software,
Software, ne folosim
cunoștințele despre calculatoare, prelucrarea
informațiilor și altele pentru a ajuta la
rezolvarea problemelor.
problemelor.
Câteodată problema e din domeniul

calculatoarelor dar de multe ori e din alte
domenii – este esnțial să înșelegem întâi
natura problemei, apoi vom folosi
tehnologia ca o unealtă pentru a implementa
soluția.
IP - Vasile Stoicu-
Rezolvarea problemelor
(analiză
(analiză))
Problemele sunt mari ->
trebuie să începem prin a
investiga, prin anal
analiză,
iză,
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
.
IP
IP-- Vasile Stoicu-
Rezolvarea problemelor
(sinteză
sinteză))
După ce am analizat problema,
trebuie să construim soluția
din componente care rezolvă
aspecte diferite ale
problemei ->
Sinteză- punem
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ă)
9 / 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 1. United States’ Internal Revenue Service – sistemul Creșterea
federal de calcul al taxelor “un fiasco de 4 miliarde” nepermisă a
text, poșta electronică, , din cauza proastei planificări costurilor
INTERNET etc. ? 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
Există câteva tehnici de a crește calitatea software (testare cu date de test, revizia colegială -
peer review etc.) 10 / 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
IP
IP-- Vasile Stoicu-
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
IP - Vasile Stoicu-
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)
13 / 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)
IP - Vasile Stoicu-
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
IP - Vasile Stoicu-
ABORDAREA SISTEMICĂ
Often, the hardware and software we put toghether must interact with
users, with other software tasks, with other pieces of
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 Any collection of component elements
that work together to perform a task.
Examples are a hardware system
A system - a collection of objects and activities consisting of a microprocessor, its allied
plus a description of the relationships that tie the
chips and circuitry, input and output
objectives and activities together. Typically: for each
devices, and peripheral devices; an
activity, a list of inputs required, actions taken,
operating system consisting of a set of
outputs produced.
programs and data files; or a database
management system used to process
specific kinds of information
IP - Vasile Stoicu-
ELEMENTELE UNUI SISTEM
Descriem un sistem enumerând
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.
IP
IP-- Vasile Stoicu-
Stoicu-Tivadar ieșiri
17 / 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
18 / 53
ABORDAREA INGINEREASCĂ
Îndată ce am înțeles natura unui sistem, putem să îl construim. Aici, partea
“inginereasc
inginerească
ă” a ingineriei programării
programării devine mai importantă.
Proiectele software avansează într

într--un mod similar cu procesul de construire a unei
case::
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. 19 / 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 20 / 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
IP - Vasile Stoicu-
Stoicu-Tivadar
fi utilizat de oameni. 21 / 53
SOFTWARE, obiective si
INGINERIA SOFTWARE,
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.
IP
IP-- Vasile Stoicu-
OBIECTIVE ALE INGINERIEI SOFTWARE
(unele dintre ele
ele))
Obiectivele sunt deziderate pe care proiectanții software le au
în vedere tot timpul ciclului de via viață
ță
al programelor
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.
IP
IP-- Vasile Stoicu-
(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) 24 / 53
(continuare 2)
Perceptibilitatea (readability
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.
IP
IP-- Vasile Stoicu-
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.
IP
IP-- Vasile Stoicu-
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. Uniformi
Uniformitatea
tatea - asigura consistenta programelor, este specifica fiecarui
inginer in programare
Examplu: conventiile proprii ale fiecarui programator in notatii
6. Completitudinea
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) 27 / 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)
IP
IP-- Vasile Stoicu-
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.
IP
IP-- Vasile Stoicu-
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
IP
IP-- Vasile Stoicu-
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-
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
IP
IP-- Vasile Stoicu-
In economia unei lucră

lucrări
ri,, în cadrul primelor 3 etape 40%
reprezintă analiza
analiza,, elaborarea specificarea şi proiectarea
proiectarea,,
20% implementarea şi 40% testarea.testarea.
Codificarea reprezintă de regulă între 16- 16-20 %
Întreţinerea poate să reprezinte până la 60% din costul total.

Întreţ
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.
IP
IP-- Vasile Stoicu-
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
,,procesului de
rezolvare a problemelor
problemelor’’ ’’ ((producerea
producerea
softului nu este o rutina ci un proces de
creatie))
creatie 33 / 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
IP
IP-- Vasile Stoicu-
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)
IP
IP-- Vasile Stoicu-
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
IP
IP-- Vasile Stoicu-
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: Dezavantaje:
• Putem evita riscul unui model • Clientul crede ca aplicatia finala nu este
cascada – identificand departe de prototip deoarece acesta nu
neintelegerile despre cerinte, stie deaspre partile ascunse ale
dintre programator si client
aplicatiei
• Imbunatatirea dialogului cu
clientul • Programatorul are tendinta sa neglijeze
sau sa uite parti ale aplicatiei care
lipsesc in prototip
IP
IP-- Vasile Stoicu-
SPECIFICARILE OPERATIONALE
Pentru multe sisteme, nesiguranta in
privinta cerintelor duce la
schimbãri si probleme mai tarziu
în aplicatia respectiva.
Aceasta abordare( Zave, 1984)
permite programatorilor si
clientilor sa examineze cerintele
si implicãrile lor în dezvoltare,
unde ei pot sã discute si sa
rezolve unele dintre probleme.
Cerintele sunt evaluate într-un mod
care demonstreazã comportarea
sistemului - se poate incepe
evaluarea folosind un pachet de
soft, astfel incat implicarea lor sã
poata fi evaluata înaintea
începerii proiectului (dar se
foloseste un alt mediu si limbaj
decat cel de implementare). Acest tip este foarte diferit de modelele traditionale.
Modelul cascada desparte functionalitatea sistemului de
proiectare( ''ce'' este separat de ''cum''), intentionând sã
Exemplu: Dacã specificatia cere
ca sistemul propus sa poata fi pãstreze clientii departe de implementare. Specificatia
manipulat de catre 20 utilizatori, o operationalã permite ca functionalitatea si proiectarea sa
forma executabila a specificatiei fie unite.
poate sã ajute analistii pentru a Specificatia operationalã este asemãnãtoare cu
determina dacã acest numãr de prototipul. Procesul permite utilizatorului si
utilizatori solicita prea mult programatorului sa examineze cerintele mai devreme.
sistemul.
IP
IP-- Vasile Stoicu-
MODELUL TRANSFORMATIONAL
Încearcã sã reducã posibilitatile de

eroare eliminând câtiva pasi de
dezvoltare majori (Balzer, 1981).
Folosind suportul de automatizare,
procesul transformational aplica o
serie de transformãri pentru a
schimba o specificatie într-un
sistem gata de livrare.
Exemple de transformãri:
- Schimbând reprezentarea de
date selectând algoritmii
- optimizând
- compilând.
Un dezavantaj major este nevoia

pentru o specificatie formala
realizata cu precizie.
IP
IP-- Vasile Stoicu-
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-
SE- Vasile Stoicu
Stoicu--Tivadar 40 / 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.
41 / 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.
IP
IP-- Vasile Stoicu-
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.
IP
IP-- Vasile Stoicu-
MODELUL SPIRALA – continuare 1
IP
IP-- Vasile Stoicu-
MODELUL SPIRALA–
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).
45 / 53
Dezvoltare AGILĂ
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
46 / 53
Dezvoltare AGILĂ–
AGILĂ– continuare
PRINCIPII
Satisfacerea nevoilor clientului prin livrar
livrarea continuă
continuă și rapidă
de software util
Software
Software--ul este livrat frecvent (săptămâni)
Software
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ță

permanență între indivizi
motivați
Atenție continuă la buna proiectare și calitatea din punct de
vedere tehnic
Simplitate
Echipe care se auto-

auto-organizează
47 / 53
DOD--STD
DOD STD--2167 un standard
Existã multe standarde pentru dezvoltarea software, dar multe din acestea sunt neoficiale
sau specifice companiilor respective.
Unul din primele este standardul DOD-
DOD-STD-
STD-2167 A sau MIL
MIL--STD-
STD-2167 de la US Dept. of
Defense (Dod).
Standardul este permis de asemenea pentru 8

Specificã un model ca si cel ‘’cascadã’’: verificari sau treceri în revistã si 17 tipuri de
rapoarte oficiale si documentaþie.
• Analiza/proiectarea cerintelor de
sistem Lista de verificari:
• Analiza cerintelor • inspectia cerintelor soft

• inspectia proiectarii soft
• Proiectarea preliminara
• inspectia specificatiilor soft
• Codarea si testarea (CSU)
• inspectia proiectarii preliminare
• Computer Software Component • inspectia proiectarii finale
(CSC) integrare si testare • revizuirea configuratiei functionale
• Computer Software Configuration • revizuirea configuratiei fizice
Item (CSCI) testare • inspectia variantei oficiale
• Integrarea si testarea de sistem

IP
IP-- Vasile Stoicu-
DOD-STD
DOD- STD--2167 un standard -
continuare 1
Dezvoltarea sistemului
49 / 53
DOD-STD
continuare 2
Lista rapoartelor si documentatiei:

In USA multe aplicatii dificile
•continutul documentului sistem/segment
sunt dezvoltate folosind 2167
•plan de dezvoltare soft
A, dar multe sisteme sunt
•specificatiile cerintelor soft
implementate folosind un
•specificatia cerintelor interfetei
subset mult mai mic al
•documentul de concepere a interfetei
modelului.
•Specificatiile de producere soft
•Documentul de descriere a versiunii Acest standard a fost partial
•Planul de testare a soft-ului depasit de catre standardul
•Planul de descriere a soft-ului IEEE 839 si ISO 9000.
•Raportul de testare soft
•Manualul operatorului
•Manualul programatorului
•Manualul suportului tehnic
•Propunerea de eventuale schimbari
•Notificarea specificatiilor de schimbare
IP
IP-- Vasile Stoicu-
DOD-STD
continuare 3
Predarea rapoartelor si documentatiilor formale :
SE-
SE- Vasile Stoicu
Stoicu--Tivadar 51 / 53
ISO 9000
ISO 9000 (International Standard Organisation), este un standard international pentru
imbunatatirea calitatii, care a fost adoptat in Europa, SUA, Asia.
Standardul a fost conceput pentru aplicarea sa pentru o larga varietate de producatori. ISO 9001 -9003 se
aplica intreprinderilor, in conformitate cu scopul activitatilor lor. Familia ISO 9004 si ISO 9000-X sunt
documente care asigura indrumarea pentru aplicatiile specifice anumitor domenii.
Pentru dezvoltarea soft ISO 9000-3 este documentul de interes.

ISO 9000 este mai bine situata decat 2167 A pentru dezvoltare produselor comerciale. Chiar
unele unitati ingineresti soft de aparare au trecut la ISO 9000 in echivalent militar, MIL-STD-498.
Standardele ISO sunt orientate pe proces,
ele ajutand companiile sa-si creeze un •Inspectie si testare
mediu care sa garanteze o anumita calitate •Controlul inspectiei, masurarea si testarea
echipamentelor
a produselor sale. •Inspectia si nivelul testarii
Principalele campuri ale calitatii care •Controlul non-conformitatii produselor
intereseaza: •Actiuni de corectare si prevenire
•responsibilitatea managementului •manipulare, stocare, impachetare, pastrare si livrare
•Calitatea sistemului •Controlul inregistrarilor de calitate
•Revizia contractelor •calitatea interna a contabilitatii
•controlul proiectarii •instruire
•Controlul documentelor si datelor •Service (intretinere)
•Identificarea si trasabilitatea produselor •tehnici statistice
•Controlul proceselor
Pentru a obtine certificarea ISO standard, este cerut un volum semnificativ de
documente. Pentru a implementa intr-o companie acest standard, este necesara in
prealabil o analiza a beneficiilor, pentru a nu cheltui mai mult decat poate fi obtinut. 52 / 53
IEEE 830
IEEE 830-1993 contine recomandarile practice pentru Software Design Descriptions
(SDDs).
Ghidul este descris ca si o “coperta” a activitatilor de-a lungul proiectarii. Aspectul recomandat al
continutului proiectului include combinatii de decompozitii, dependenta, interfata, si descriere a detaliilor.
Descrierea decompozitiei este folosita pentru a incadra

entitatile de proiectare in sistem. Fiecare entitate de
acest fel este descrisa de catre identificarea sa, tip, scop,
functie si subordonare.
Sectiunea ’’dependentelor’’ este o descriere a relatiilor

dintre entitati si resurse sistem. Atributele entitatii includ
identificare, tip, scop, dependente si resurse (structuri,
diagrame de date, etc)
Descrierea interfetei asigura o lista cu tot ceea ce

proiectantul trebuie sa stie despre folosirea entitatilor
(fiecare inregistrare cu identificare, functie sau interfete-
dictionare de date, liste cu parametri, etc.)
Descrierea detaliata este folosita pentru a arata detaliile

interne ale fiecarei entitati a sistemului ale caror atribute
includ identificarea, descrierea procesarilor si descrierea
detaliata a datele
Standardul este incomplet (el specifica doar cererile legate de

53 / 53
proiectare si descriere. Sunt necesare informatii suplimentare.
CE MODEL DE PROCES FOLOSIM ?
Modelele prezentate sunt doar cateva din cele

folosite
Alte modele ale proceselor pot fi definite si
concepute pentru nevoile utilizatorilor, clientului
si proiectantilor. Ar trebui sa percepem procesul
de dezvoltare software ca o colectie a modelelor
proceselor, mai degraba decat a unui singur
model.
Indiferent de modelul procesului folosit, multe
activitati sunt similare.
Adesea, modelul procesului este impus de catre
organizatiile soft (in functie de “cultura” interna,
uneltele software disponibile, instruire etc).
IP
IP-- Vasile Stoicu-
Care sunt concluziile acestui capitol
Puteti folosi concepte ale acestui capitol in felul urmator:
urmator:
individual -
• pentru ghidarea comportamentului cand lucrati in echipa
• va ajuta sa invatati cum sa colaborati si sa va coordonati cu colegii
• va puteti concentra asupra aspectelor procesului de dezvoltare pentru a va
imbunatati cunstintele (functional, comportamental si a altor
perspective)
ca echipă
echipă –
• un model bun arata fiecarui membru al echipei ce activitati apar intr-
intr-un proiect
pentru a si le putea imparti
• managerul proiectului poate folosi tehnicile specifice procesului pentru a
imbunatati procesul,
procesul, simuland activitati si urmarind resurse pentru
determinarea echipei optime si activitatile pentru a se incadra in bugetul si
termenele stabilite
IP
IP-- Vasile Stoicu-

1 Fundamente in Ingineria Programarii PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

1 Fundamente in Ingineria Programarii PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Obiectivele

pentru capitolul I - Fundamente

Câțiva termeni părţi sau în totalitate unor părţi sau în totalitate a

Este vorba de acele sisteme la

Programarea nu este o artă ci o activitate

Domeniu al informaticii ce se ocupă cu

Câteodată problema e din domeniul

Important: relațiile sunt la

Exemple punctuale pentru lipsa calității:

Calitatea este privită Returnarea investiției (RI)

RI include aspecte precum:

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

Where does the project begin

Putem pune în evidență

și pentru un sistem pentru salarii

Proiectele software avansează într

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

Ingineria software intentioneaza sa treaca de la arta programarii la o

Flexibilitatea– posibilitatea de adaptare (mai usoara)

Exista cateva tehnici pentru a creste siguranta (redundanta statica si

De asemenea, gestionarea unui proiect soft este posibila doar daca

Obiectivele pot fi atinse prin imprimarea in practica curenta a principiilor

Este de altfel redata Semnalizare avarie Masuratori

Motive pentru modelarea unui proces:

In economia unei lucră

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

Asigura ca sistemul are

Prototipul este folositor pentru Asigura ca fiecare functie

Prototipizarea poate fi ea insasi baza pentru un model efectiv.

Sunt posibile iteratiile printre cerinte si proiectare.

Încearcã sã reducã posibilitatile de

Un dezavantaj major este nevoia

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

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

Instruirea utilizatorilor poate incepe la primele versiuni ale programului,

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

Accent pe cod mai degrabă decât pe un

Livrare rapidă și flexibilitate pentru a

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

Încrederea trebuie construită în permanență

Echipe care se auto-

Standardul este permis de asemenea pentru 8

• Analiza cerintelor • inspectia cerintelor soft

Item (CSCI) testare • inspectia variantei oficiale

• Integrarea si testarea de sistem

Lista rapoartelor si documentatiei:

Pentru dezvoltarea soft ISO 9000-3 este documentul de interes.

Descrierea decompozitiei este folosita pentru a incadra

Sectiunea ’’dependentelor’’ este o descriere a relatiilor

Descrierea interfetei asigura o lista cu tot ceea ce

Descrierea detaliata este folosita pentru a arata detaliile

Standardul este incomplet (el specifica doar cererile legate de

Modelele prezentate sunt doar cateva din cele

S-ar putea să vă placă și