Ingineria programării

Curs, anul III Calculatoare

Domeniul general al
ingineriei software
Sumar
Criza software.
 Probleme legate de software. Exemple
Complexitatea sistemelor software
 “Produs” şi “producţie” software: domeniul
ingineriei software
 “Procese” de dezvoltare software (SDP)
Metodele formale ale ingineriei software
 Instrumente CASE
Criza software
Inca inainte de 1970 a devenit clar ca:
 Hardware-ul nu mai reprezinta o restricție importantă;
el permite dezvoltarea de programe tot mai complexe
 Aceasta ridica mari probleme: efortul creste mai mult
decat liniar in comparatie cu dimensiunea programului
 Programul nu e o entitate statica, ci evolueaza in timp
datorita schimbarii cerintelor si a mediului de utilizare
 De aceea el trebuie facut usor de inteles si adaptat
pentru persoane diferite de cele ce l-au dezvoltat
 Metodele de dezvoltare si intretinere existente sunt
inadecvate dezvoltarii de programe mari
 Mai ales in conditiile in care productia software devine
o industrie de sine statatoare
Probleme de bază în dezvoltarea software
Sisteme “moştenite”
 Fiindcă sunt importante,valoroase, dar și pentru că
există o comunitate de utilizatori, trebuie menţinute și
actualizate
Sisteme eterogene
 Distribuite și mixte – “hardware si software”
Cerinţe si termene de livrare
 Există o presiune crescuta privind rafinarea cerintelor
și scurtarea termenelor
Toate aceste probleme pot fi legate
• de ex., poate fi necesar să schimbăm rapid un sistem
moștenit și să-l facem accesibil în rețea
Câteva “mituri” legate de software
(cf. Roger Pressman, Software Engineering: A Practitioner's Approach)

Mitul nr.1: “eroarea este in software, pe acesta putem

ușor sa-l schimbăm”
 Realitate: schimbarea este o cauza majora a

degradării software-ului
Mitul nr.2: “putem remedia rămânerile in urmă prin
angajarea de noi programatori”
 Realitate: poate, dar aceasta mărește eforturile de

coordonare si poate încetini lucrurile si mai mult

Mitul nr.3: “deși nu avem toate cerințele scrise, știm ce
vrem si putem începe sa scriem cod”
 Realitate: definirile incomplete reprezintă cauza

majora a eșecului proiectelor software

Alte “mituri” legate de software
Mitul nr.4: “nu se poate spune dacă software-ul merge
până nu îl rulăm”
 Realitate: reviziile formale din timpul construcției

software-ului sunt utile, chiar critice pentru succes

Mitul nr.5: “singurul livrabil care contează este codul”
 Realitate: si documentațiile, testele, procedurile de

configurare sunt elemente critice la livrare

Mitul nr.6: “un bun programator poate finaliza orice
sarcină, oricât de complexă”
 Realitate: altă cauză a eșecului proiectelor software;

succesul unui proiect e datorat echipei, nu indivizilor,

si cere mai mult decât abilități de codificare
Exemplul 1
Tip de eroare: analiza cerintelor/ specificare ambigua
Descriere: programul de vehicule spatiale a fost dezvoltat
de 2 echipe, de la NASA JPL si Lockheed Martin
 NASA a folosit sistemul metric de unitati
 Lockheed Martin pe cel anglo-saxon
Nimeni nu a observat diferenta!
Rezultat: Mars Climate Orbiter s-a zdrobit de suprafata
planetei Marte pe 23 septembrie 1999
 S-au pierdut 125 milioane US$
 Ani de munca si 10 luni durata de traversare catre Marte
 Misiunea a fost aproape compromisa
Exemplul 2
Tip de eroare: mentenanță/portare superficială
Descriere: programul spatial ESA era unul de succes
 ArianeIV – o racheta de lansare a satelitilor comerciali f. eficienta
 ArianeV trebuia sa fie versiunea ei mai mare, mai buna, rapida
 Pentru a reduce costurile de dezvoltare, o parte din software-ul ArianeIV
a fost reutilizat
 Munca de dezvoltare a durat 10 ani si a costat 8 mld €
Eroare: In cod, reprezentarea vitezei pe 64 biti (floating point) a fost
convertita (cast) intr-una pe 16 biti (integer)
 OK pentru ArianeIV, dar viteza superioara a ArianeV a determinat
activarea conditiei de depasire, corect capturata de catre software (trap)
 Problema: lipsa trap handler (pt. eficienta: “it never happens anyway!”)
 . . . deci software-ul a cedat!
Rezultat: prima racheta ArianeV a iesit de sub control, fiind distrusa
de mecanismul de siguranta (4 iunie 1996)
Exemplul 3
Tip de eroare: proiectare/codificare defectuoasă
Descriere: Therac-25 - aparat medical de iradiere combinata
(electron/X-ray, 1985-1988), capabil sa produca fascicule de
inalta energie de electroni (5-25 MeV) si de raze X (25MeV)
 Utilizare: in radioterapia bolnavilor de cancer
 Componenta software tb. sa asigure siguranta in functionare pentru
intensitatea fasciculului de electroni, de raze X, focalizare si raspandire
Eroare: Unele conditii de urmarire in cod au permis ca anumite
stari nesigure sa poata fi atinse:
 Iradiere cu un fascicul de electroni de inalta energie si intensitate, fara
focalizare si raspandire adecvata
 Conditiile de urmarire nu au fost detectate la testarea software-ului!
Rezultat: Mai multe persoane au murit datorita iradierii
excesive, si multi altii au prezentat arsuri grave
Exemplul 4
Tip de eroare: utilizarea unui algoritm eronat, ce combina
un mutex si prioritati
Descriere: Misiunea Mars Pathfinder a fost proclamata
unanim ca “ireprosabila" in primele zile dupa aterizarea sa
pe suprafata planetei Marte, la 4 iulie 1997; succesele:
 O “sosire” neconventionala, utilizand airbag-uri
 Punerea pe suprafata a unui vehicul (Sojourner)
 Strangerea si transmiterea unui volum mare de date catre Terra,
inclusiv fotografii panoramice
Eroare: La cateva zile, imediat ce a inceput sa adune date
meteorologice, sonda Pathfinder a inceput sa se reseteze
Rezultat: pierderi de date
Complexitatea sistemelor
software actuale
Sistemul de rezervare a biletelor pentru compania
aeriană KLM conţinea, în anul 1992, două milioane
de linii de cod în limbaj de asamblare
Sistemul de operare System V versiunea 4.0 (UNIX)
a fost obţinut prin compilarea a cca 3.700.000 linii
de cod
Programele scrise pentru naveta spaţială NASA au
cca 40 de milioane de linii de cod
Pentru realizarea sistemului de operare IBM OS/360
au fost necesari 5000 de ani-om
Ce înţelegem prin produs software?
Definiţie simpl(ist)ă: Software = Programe de
calculator (+ Date + Documentații asociate)
Definiția IEEE-STD-610:
“Software-ul e reprezentat ca un set complet, sau
individual de fiecare element din acest set, de:
programele de calculator, procedurile, datele de
test necesare livrării lor la client sau utilizator final,
fişierele de configurare şi documentaţia asociată”
Definiția Wikipedia:
“Software-ul este reprezentat de acea parte a sistemului
calculator diferita de hardware  (ce conține dispozitive
fizice necesare pentru memorare si execuție). El include
diverse programe - de sistem si de aplicație, firmware si
middleware -, componente (biblioteci) si documentații.”
Specificul producţiei de software
Software-ul diferă de obiectele “materiale” prin uşurinţa:
 Copierii

 Modificării, etc.

Are un puternic caracter inovativ; cere multa creativitate

Producţia de software poate fi orientată către:
 Un client particular

 Un segment de piață general

Prin aceasta, produsele software pot fi:

 Generice – dezvoltate pentru a fi vândute unor

categorii de clienți destul de largi/ diverse

 Customizate – dezvoltate pentru o singura categorie

de clienți conform cu specificațiile

Diferente intre produsul hardware
si software
Atribute ale produselor software
Funcţionalitate
Performanță
Mentenabilitate - software-ul trebuie sa evolueze
pentru a răspunde unor cerinţe ce se schimba
Fiabilitate
Securitate Software-ul trebuie sa nu determine
pagube in cazul căderilor de sistem
Siguranță
Eficiență - nu trebuie risipite resursele sistem
Utilizabilitate - software-ul trebuie sa fie util
acelor utilizatori pentru care a fost proiectat
Costurile produselor software
Pentru produsele software generice:
 60%: costuri de dezvoltare
 40%: costuri de testare, menţinere si evoluţie
Pentru produsele software customizate, costurile
de evoluţie le depăşesc pe cele de dezvoltare
Costurile variază după:
 Tipul (categoria) sistemului software
 Cerinţele asupra sistemului: performanţa, siguranţa
Distribuţia costurilor depinde de asemenea puternic
de modelul de dezvoltare utilizat
Ponderea costurilor dupa procesul
de obtinere a software-ului
Domeniul ingineriei software
Este legat de toate aspectele producerii de software
 Prima definiţie (F. L. Bauer, 1968):
Ingineria software are ca obiect stabilirea şi utilizarea de principii
inginereşti solide pentru a obţine în mod economic programe
sigure şi care funcţionează eficient pe maşini de calcul reale
 Astăzi:
Ingineria software înseamnă construcţia de software de calitate
in limite de buget si timp, in contextul schimbărilor constante
Definiția Wikipedia:
 “Ingineria software este o aplicare a unor abordări
sistematice, disciplinate, cuantificabile, a dezvoltării,
operării si menținerii unui software, si un studiu al acestor
abordări. Altfel spus, este o aplicare a metodelor ingineriei
in domeniul software.”
Abordarea domeniului SoftEng
Se poate face din doua perspective (ce pot fi si
componente ale unei abordari unice):
 “systems engineering approach“
 “development engineering approach”
In prima, intelegerea unui sistem se face prin SEM
(Systems Engineering and Methodology)
Cea de-a doua se intrepatrunde cu managementul de
proiect software
SEM (Systems Engineering and Methodology)
Intelegerea unui sistem se face in etape, astfel:
 Definirea obiectivelor sistemului
 Definirea frontierelor sistem
 Factorizarea sistemului in componente diferite
 Intelegerea relatiei intre diferite componente
 Definirea relatiilor prin intrari, iesiri si procese
 Intelegerea rolului nivelelor hardware si software
 Identificarea cerintelor operationale si functionale
 Modelarea sistemului pentru analiza si dezvoltare
 Discutia sistemului cu beneficiarul (clientul)
DEM (Development Engineering Methodology)
Scopul dezvoltarii sistemului software este translatarea
cerintelor sistem, iar aceasta se face printr-o secventa
de pasi:
 Definirea si specificarea cerintelor
 Proiectarea solutiei care raspunde cerintelor
 Determinarea arhitecturii care “livreaza” solutia
 Dezvoltarea clientilor (organizarea celorlalte activitati, in
afara constructiei software-ului)
 Testarea componentelor software
 Integrarea componentelor sistem
 Implementarea
Abordarea “pe straturi” a domeniului SEng
Viziunea lui Pressman:
“Software engineering is a layered technology”

Procese

Metode

Instrumente

Focus pe calitate
Procese software
Un proces software este un set de activităţi ce au ca scop
dezvoltarea si evoluţia de software, văzute ca un mod de
producţie, deopotrivă repetabil cât şi controlabil
Activităţi generice in procesele software:
 Specificarea: ce trebuie sa facă sistemul si care sunt
constrângerile sale de dezvoltare?
 Dezvoltarea , sau “Producţia” sistemului software
 Validarea, verificarea ca software-ul sa corespundă cu
cerinţele clientului
 Evoluţia: modificarea software-ului ca răspuns la
schimbarea cerinţelor
Modele de procese software
Reprezentari simplificate de procese software,
proiectate dintr-o perspectiva specifica
 “Workflow” – ca secvenţe de activităţi
 “Dataflow” – ca fluxuri de informatii
 “Rol/actiune” – “who does what?” (prezintă rolurile
celor implicaţi si activităţile de care sunt responsabili)
Modele de procese software generice
 Modelul in cascada (Waterfall)
 Dezvoltare evolutivă
 Transformări formale
 Integrare din componente reutilizabile
Metodele ingineriei software
Sunt moduri “organizate” de producţie software, ce
includ: sugestii, notaţii, reguli, indicaţii etc.
Abordări structurate, inclusiv modele de sistem
Modele descriptive
 Includ descrieri ale modelelor grafice produse
Metode formale
Reguli si constrângeri aplicate modelelor sistem
Recomandări privind practicile de proiectare
Indicaţii privind fluxul proceselor
 Descrierea succesiunii activităţilor
Metodele formale
Sunt aplicabile tuturor fazelor de dezvoltare:
Analiza
Modelare (specificare)
Proiectare
Implementare
Validare (verificare, testare)
... folosind:
Limbaje/notatii cu semantica precisa, matematica
Tehnici bazate pe logica matematica
Instrumente (CASE)
Utilitatea metodelor formale (1)
Importante pentru:
 Sistemele agregate (ce se bazeaza pe componente
software)
 Sistemelor complexe, cu software inglobat
Necesare pentru:
 Mentinerea fiabilitatii sistemelor
 Obtinerea sistemelor software de calitate
 Atingerea unei productivitati cat mai mari
 Reducerea costurilor – paradoxal, dar cat se poate de
adevarat!
 Exemplele urmatoare vor clarifica acest aspect
Utilitatea metodelor formale (2)
In faza de analiza si specificare:
 Specificatiile formale pot fi ne-ambigue
 Pot fi verificate pentru consistenta
 Pot fi folosite pentru a deduce anumite proprietati
La proiectare si implementare:
 Se pot aplica tehnici de verificare si analiza
 Se poate face sinteza automata a programelor, prin
transformari formale ale specificatiilor
La validarea si mentenanta programelor:
 Se poate aplica generarea automata a cazurilor de test
 Poate fi asigurata echivalenta codului vechi cu cel nou
Instrumente CASE
(Computer-Aided Software Eng.)
Sunt sisteme software ce asigura suport automat pentru
metodele/activităţile rutiniere din procesele software,
precum: editarea diagramelor de proiectare, verificarea
consistentei diagramelor, evidenta testelor executate
Upper-CASE
 Instrumente de suport ale activităţilor de proces
initiale (analiza cerinţelor, design)
Lower-CASE
 Instrumente de suport ale activităţilor de proces
finale (programare, depanare si testare)
Există componente de înregistrare si estimare a
costurilor
Zone de cunoștințe
Conform IEEE Computer Society “Software Engineering
Body of Knowledge” (http://www.swebok.org), putem
identifica 10 zone de cunoștințe cheie ale domeniului IP:
1. Cerințele 6. Managementul configurației
2. Proiectarea 7. Managementul proiectului
3. Construcția 8. Procesul
4. Testarea 9. Instrumente și metode
5. Mentenanța 10. Calitatea
Cerinţe şi specificaţii software
Documente/ nivele de specificare
Sumar
Cerinţe software și specificații. Analiza cerinţelor
Tipuri de cerinţe
 Cerinţe funcţionale şi non-funcţionale
 Cerinţe din domeniul aplicaţiei
 Cerinţe utilizator şi cerinţe sistem
Studiu de caz: sistemul LIBSYS
Modalităţi de formulare a specificaţiilor
 Formate: Șabloane de specificații
Organizarea cerinţelor într-un document
 Formate: Standardul IEEE 830-1993 (1998)
Concluzii
Cerințele software
Cerințele sunt caracteristici ale viitorului sistem/
descrieri ale capabilităților sale pentru atingerea
unui anumit obiectiv în funcționarea sa
Descriu “ce” va face sistemul (nu și “cum”)
Procesul determinării cerințelor: Definirea și
Descoperirea și analiza cerințelor specificarea
cerințelor
Analiza Descrierea Prototipizare Documentare
problemei problemei și testare și validare

Captură Revizie Fezabilitate Validare

Cum începe un proiect?
Un proiect poate începe:
 cu o idee a clientului
 cu o idee a unei echipe de dezvoltare
Această idee poate fi:
 clară, bine definită
 vag definită
În primă fază este util să fie colectate, descrise
și analizate cerinţele brute (“raw requirements”)
Ingineria cerinţelor este procesul care permite
continuarea spre obţinerea specificaţiilor
Cerinţe vs. specificații
Ce diferență este între cerințe și specificații?
Opinii:
 Cerințele sunt ceea ce ar trebui să facă un program,
specificațiile sunt modul în care intenționați să faceți
acest lucru
 Cerințele reprezintă aplicația din perspectivă user sau
business, specificația din perspectiva echipei tehnice
 Specificațiile și cerințele comunică aproximativ aceleași
informații, dar către stakeholderi diferiți
 Adam Wuerl (ing.aerospațial): O cerință este o singură
declarație despre ceva ce trebuie să facă produsul sau
sistemul. O specificație poate avea sute de cerințe...
Analiza cerinţelor
Toate etapele depind de analiza cerinţelor, etapă
“iniţială”, în care se stabileşte ce anume vrea clientul
să facă programul
Ea nu poate fi însă total separată de celelalte, fiindcă
cerinţele se schimbă (“A software product is a model
of the real world, which is continually changing”)
Rămâne ca scop al acestei “etape” înregistrarea
cerinţelor într-o manieră cât mai clară, detaliată, ce
pp. analiza lor; probleme posibile:
 Comunicare deficitară
 Negociere dificilă între analist şi client
 Lipsa de consultanţă acordată clientului (dar şi invers,
de către client analistului)
De ce “Analiza cerinţelor”?
Are impact foarte mare asupra succesului sau
insuccesului unui proiect software
Statistica arată că peste 60-80% din costurile non-
calităţii sunt cauzate de culegerea, înţelegerea şi
managementul inadecvat ale cerinţelor
Conform SEI (Software Engineering Institute),
primii factori ce contribuie la eşecul proiectelor, în
privinţa respectării bugetelor/termenelor, sunt:
 specificaţiile inadecvate ale cerinţelor

 schimbările necontrolate ale acestora

Argumente
În România, domeniul industriei IT e recunoscut
ca fiind unul dintre cele mai dinamice
Dar, deşi credem în forţa noastră pe piaţa de IT,
noi de fapt excelăm doar în programare!
Programarea reprezintă doar o parte, 30 – 50%,
din efortul necesar într-un proiect software
Este aproape la fel de mare nevoie de analişti
(specialişti în analiza şi ingineria cerinţelor)
Bunele practici recomandă ca efortul consumat
pentru analiza cerinţelor să fie între 10 - 30% din
efortul total consumat într-un proiect
Responsabilităţile analistului
Să extragă şi să clarifice cerinţele clientului
Să ajute la rezolvarea diferenţelor de opinie intre
clienţi şi utilizatori
Să sfătuiască clientul asupra a ceea ce este tehnic
posibil sau imposibil
Să documenteze cerinţele
Să negocieze şi să obţină o înţelegere cu clientul
Probleme potențiale:
 Negocierile sunt necesare (dar pot fi dificile)
 Diferenţe “culturale” dintre client si analist
 Diferenţe intre cerinţele clientului si ale utilizatorilor
Activităţile analistului
Ascultare : Înregistrează cerinţele clientului
Reflectare : Traduce cerinţele in limbaj tehnic.
Verifica pertinența.
Scriere : Se cade de acord asupra formulărilor
Repetare : pana când se ajunge la o înţelegere
cu clientul in ceea ce priveşte cerinţele
Probleme potentiale:
 Procesul iterativ poate fi lung si complicat
 Diferenţa culturala dintre client si analist
 Diferenţe intre cerinţele clientului si ale utilizatorilor
Nivele de specificare a cerinţelor
(documente
Definirea cerinţelor utilizator (URD/ MRD -
User/ Market Requirements Definition) : scrise
pentru utilizatori sau clienţi (de către contractor)
Specificarea cerinţelor sistem software
(SRS - Software Requirements Specification) : ca
un contract între contractor şi client
Specificarea proiectării software (SDS -
Software Design Specification) : scrise pentru
dezvoltatori
Specificaţiile corecte
Spun ce și pot sugera sau nu cum trebuie făcut (prin
analogie cu programarea declarativă vs. imperativă),
sunt sufic. de detaliate, clare, neambigue, complete
Sunt necesare detalii de implementare la analiză?
 DA (argumente pro)
 Este nevoie să integrăm proiectul într-un sistem existent
 Timpul de dezvoltare depinde de implementare
 Întreţinerea (costurile) depind de implementare
 NU (argumente contra)
 Clientul nu este competent in detalii tehnice
 Clientul nu poate fi de acord in cunoştinţă de cauză cu
stipulările tehnice din specificaţii (Ştiu secretarele .NET?)
 E necesar să restrângem mulţimea soluţiilor tehnice posibile?
Scopul analizei cerințelor
De a răspunde: Ce trebuie să facă produsul?!
O concepție greșită:
 Trebuie să determinăm ce spune clientul că vrea
 “I know you believe you understood what you think I
said, but I am not sure you realize that what you heard
is not what I meant!” (A.client)
 NU! Trebuie să determinăm ce este cu adevărat
necesar clientului
 Este greu și unui analist de sistem să vizualizeze un
produs software viitor, funcționalitatea sa
 Cu atât mai mult este greu pentru un client, care deci nu
poate descrie corect ce vrea, singur
Obiective ale analizei
Înţelegerea problemelor organizaţiei client
Întărirea motivaţiei de a investi în software
Formarea viziunii comune a tuturor participanţilor
în proiect (stakeholderi) asupra problemelor şi
soluţiei viitoare
Formularea cerinţelor viitorului produs software/
actualizarea lor, de către client
Traducerea lor în specificaţii software care pot fi
înţelese şi implementate de către dezvoltatori
Definirea atât a limitelor cât și a constrângerilor
viitorului sistem software
Cerinţele şi proiectarea software
În teorie, cerinţele exprimă ce va face sistemul,
iar proiectarea trebuie să descrie cum va face
sistemul aceste lucruri – deci sunt separate
În practică, cerinţele şi proiectarea sunt de
multe ori inseparabile:
 O arhitectură de sistem poate fi proiectată pentru a
structura cerinţele
 Sistemul poate fi considerat ca inter-operabil cu
alte sisteme care generează cerinţe de proiectare
 Folosirea unei proiectări specifice poate fi o cerinţă
din domeniul aplicaţiei
Depind cerințele de procesul
de dezvoltare software?
O dezvoltare software idealizată (de ex. în modelul WM):
 Liniară, cu etape separate
 Pornește de la început (din scratch)
În orice alt model de dezvoltare al unui proiect software
se pot identifica mai multe etape (faze) distincte:
 specificarea şi analiza cerinţelor
 proiectarea arhitecturală
 proiectarea de detaliu
 scrierea codului
 integrarea componentelor
 validarea şi verificarea
 întreţinerea codului
Sunt ele total separate în realitate?
În practică
Cerinţele clientului se schimbă pe parcursul dezvoltării
Eventual datorită unor erori în funcţionarea software-ului
Mini-studiul de caz Winburg:
 Episodul 1: se implementează prima versiune
 Episodul 2: se găseşte o eroare, de ex. de implementare,
ce face ca execuţia programului sa fie lentă; începe
schimbarea implementării
 Episodul 3: se adoptă un nou design, de ex. un algoritm
mai rapid
 Episodul 4: se modifica cerinţele, de ex. se cere creşterea
preciziei; din nou sunt necesare schimbări in design si
implementare
 Epilog: peste un timp, aceste probleme reapar
Practic, dezvoltarea software poate fi chiar mai haotică!
Modelul arbore de evolutie

Winburg Mini Case Study

Un model de dezvoltare
Dezvoltarea programelor pe baza cerințelor corect
identificate necesită:
O înţelegere clară a ceea ce se cere
Un set de metode şi instrumente de lucru
Un plan de acţiune (şablon/model de dezvoltare),
etapizat: - Analiza cerinţelor
- Proiectarea
- Implementare (scrierea codului)
- Integrare şi testare
- Întreţinere (menţinere)
O comunicare eficientă!
O comunicare deficitară 
Implicarea clienţilor
Insuficienta implicare este principala cauză a
eşecului proiectelor software
Buna înţelegere a problemelor clientului e legată
de împărtăşirea unei viziuni comune între echipa
de dezvoltare şi client
 Fără ea, echipa de dezvoltare nu are referinţele
de bază pentru a putea şti dacă ceea ce dezvoltă
este corespunzător sau nu
 Mesajul acesta poate fi ilustrat printr-un “carton”
despre diferenţa care apare adesea în practică,
între problema clientului, înţelegerea problemei şi
ceea ce se realizează de fapt
O problemă practică…
Tipuri de cerinţe (criteriul 1)
Cerinţe funcţionale
 Descrieri ale serviciilor pe care trebuie să le ofere
sistemul, cum trebuie să reacţioneze şi să se
comporte sistemul în situaţii particulare
Cerinţe non-funcţionale
 Constrângeri asupra datelor, serviciilor, funcţiilor
oferite de sistem (de ex.constrângeri de timp), sau
ale procesului de dezvoltare, standarde, etc.
Cerinţe specifice domeniului problemei
 Cerinţe ce provin din domeniul de aplicaţie al
sistemului, pot fi funcţionale sau non-funcţionale
Cerinţe funcţionale vs. non-funcţionale
Cerinţele funcţionale
 Descriu funcţionalitatea sau serviciile sistemului

 Depind de tipul de software şi de utilizator ce va folosi

sistemul
 Pot fi fraze abstracte ce descriu ceea ce face sistemul

sau pot descrie sistemul în detaliu (ce trebuie sa facă

sistemul)
Cerinţele non-funcţionale
 Cel mai adesea se aplică unui sistem în ansamblul său

 Nu se aplică doar facilităţilor sau serviciilor individuale

ale sistemului
Dinamica cerinţelor (non-funcţionale)
Distincţia între cerinţe nu este atât de clară, de ex.
 O cerinţă de securitate poate părea non-funcţională ,
*

dar pe măsură ce e detaliată generează cerinţe

funcţionale, ca includerea autentificării utilizatorilor
Cerinţele privind datele
 Descriu formatul datelor la i/e, dar şi formatul datelor

din interiorul sistemului, şi pot evolua

Constrângerile
 Sunt cerinţe ce par a fi de respectat ad-literam, ce

influenţează direct implementarea

Recomandări
 Completează alte tipuri de cerinţe şi ajută la luarea
deciziilor de proiectare când  mai multe opţiuni
Cerinţele non-funcţionale nu sunt
secundare!
Pot defini proprietăţi şi constrângeri importante ale
sistemului cum ar fi fiabilitate, timp de răspuns şi
cerinţe de stocare
Constrângerile sunt proprietăţi ale componentelor de
stocare de date, reprezentări ale sistemului, etc.
Pot specifica cerinţe de proces care impun un anumit
sistem CASE, un limbaj de programare sau o metodă de
dezvoltare
Cerinţele non-funcţionale pot fi “mai critice” decât cele
funcţionale
 Dacă nu sunt îndeplinite, sistemul este inutilizabil
“Clase” de cerinţe non-funcţionale
Cerinţe de produs
 Sunt cerinţe care specifică lucruri pe care produsul
trebuie să le îndeplinească legat de viteza de
execuţie, fiabilitate, etc.
Cerinţe de organizare
 Cerinţe care sunt consecinţe ale politicii şi
procedurilor organizaţiei cum ar fi standarde de
proces folosite, cerinţe de implementare, etc.
Cerinţe externe
 Cerinţe care provin din factori externi sistemului şi
procesului de dezvoltare cum ar fi cerinţe de
interoperabilitate, cerinţe legislative, etc.
Tipuri de cerinţe non-funcţionale
Non-functional
requirements

Product Organisational External

requirements requirements requirements

Efficiency Reliability Portability Interoperability Ethical

requirements requirements requirements requirements requirements

Usability Delivery Implementa tion Standar ds Legislative

requirements requirements requirements requirements requirements

Performance Space Privacy Safety

requirements requirements requirements requirements
Studiu de caz: sistemul LIBSYS
Se referă la implementarea unui sistem tip bibliotecă
capabil să ofere o interfaţă unică la un număr mare de
BD cu articole, din diferite biblioteci
Utilizatorii săi trebuie să poată căuta, aduce şi/sau tipări
aceste articole pentru studiu personal
 Utilizatorul trebuie să poată căuta articole în toate
bazele de date sau într-un subset selectat
 Sistemul trebuie să ofere instrumente adecvate de
vizualizare pentru citirea articolelor
 Fiecare comandă trebuie să aibă un identificator
unic (ORDER_ID)
Cerinţe ale sistemului LIBSYS
Cerinţe funcţionale:
 Sistemul se va opri in maxim 5 secunde după ce temperatura
procesorului atinge 80 grade Celsius
 Sistemul va permite căutarea si afişarea titlurilor cărţilor scrise
de un anumit autor
Cerinţe privind datele:
 Datele vor fi exportate in format XML
 Datele din tampoanele de intrare si ieşire vor fi criptate
Constrângeri asupra funcţiilor sau procesului:
 Implementarea se va realiza folosind un limbaj orientat obiect
 Metodologia de dezvoltare va fi bazata pe prototipizare
Recomandări:
 A se folosi cat mai putina memorie
Exemple de cerinţe ne-funcţionale
Cerinţe de produs
8.1 Interfaţa cu utilizatorul pentru sistemul LIBSYS
trebuie să fie implementată ca pagini HTML simple
fără cadre (frames) sau Java applets.
Cerinţe de organizare
9.3.2 Procesul de dezvoltare şi documentele rezultate
se vor conforma celor definite în XYZCo-SP-STAN-
95.
Cerinţe externe
7.6.5 Sistemul nu trebuie să ofere alte informaţii
personale legate de clienţi în afară de numele lor.
Tipuri de cerinţe (criteriul 2)
Cerinţe utilizator
 Sunt fraze în limbaj natural plus diagrame
ale serviciilor pe care le oferă sistemul şi
constrângeri de operare
 Ele sunt scrise de clienţi
Cerinţe de sistem
 Sunt structurate într-un document cu
descrieri detaliate ale funcţiilor sistemului,
servicii şi constrângeri de operare
 Definesc ceea ce va fi implementat deci va
putea fi parte dintr-un contract
Exemple LIBSYS
Definiţie de cerinţă utilizator

1. Programul trebuie să ofere mijloace de reprezentare şi accesare a

1. fişierelor externe create de alte instrumente

Specificaţie de cerinţă sistem

1.1 Utilizatorul trebuie să aibă mijloace de a defini tipul fişierelor externe

1.2
1.2 Fiecare tip de fişier extern poate avea un instrument asociat cu care
1.2 poate fi deschis acel
. fişier
1.3 Fiecare tip de fişier extern poate fi reprezentat cu un icon specific
1.2 pe ecran
1.4 Trebuie oferite mijloace ca pozele ce reprezintă tipurile de fişiere
1.2 externe să poată fi definite de utilizator
1.5 Când utilizatorul selectează o poză ce reprezintă un fişier, efectul
1.2 selecţiei este aplicarea instrumentului asociat acelui tip de fişier
1.2asupra fişierului selectat
Documentul de specificare a
cerinţelor
Reprezintă rezultatul analizei cerinţelor şi principalul
instrument formal de referinţă între client şi contractor
Provocări
 Nivelul de detaliu
 Mare: mai precis, obţinut mai greu, munca inutila
 Mic: prea vag, nu poate ghida eficient dezvoltarea
 Audiența documentelor
 2 versiuni: una pentru client, alta pentru dezvoltatori?
 Notaţia folosita
 Informală, semi-formală, formală
Audiența cerinţelor
Manageri ai clientului
Utilizatori finali de sistem
Cerinţe Ingineri (consultanţi) client
utilizator
Manageri de dezvoltare
Arhitecţi de sistem

Utilizatori finali de sistem

Cerinţe Ingineri ai clientului
sistem Arhitecţi de sistem
Dezvoltatori software

Ingineri ai clientului (posibil)

Specificaţii de
Arhitecţi de sistem
proiectare
Dezvoltatori software
Completitudinea şi consistenţa
cerinţelor
În principiu, cerinţele trebuie să fie:
Complete
 Trebuie să includă descrieri ale tuturor facilităţilor
Consistente
 Nu trebuie să existe conflicte sau contradicţii în
descrierea facilităţilor sistemului
În practică, este imposibilă realizarea unui
document de cerinţe complete şi consistente
Cerinţe vs. scopuri (intenţii)
Mai ales cerinţele non-funcţionale pot fi foarte
greu de exprimat în mod precis, iar cerinţele
imprecise pot fi greu verificate
Scop: O intenţie generală a utilizatorului cum ar
fi uşurinţa în utilizare
Cerinţă non-funcţională verificabilă: o cerinţă ce
foloseşte un sistem de măsură pentru a putea fi
obiectiv testată
Scopurile sunt utile dezvoltatorilor în măsura în
care cuprind intenţiile utilizatorilor de sistem
Exemple
Un scop al sistemului
 Sistemul trebuie să fie uşor de utilizat de operatori
experimentaţi şi trebuie organizat astfel încât
erorile de utilizare să fie minimizate.
O cerinţă non-funcţională verificabilă
 Operatorii experimentaţi trebuie să poată folosi
funcţionalitatea sistemului după un total de două
ore de învăţare
 După această perioadă numărul mediu al erorilor
făcute de operatorii experimentaţi nu trebuie să
depăşească două pe zi
Măsuri pentru cerinţe
Proprietate Unitate de măsură
Viteza Tranzacţii/secundă procesate
Timp de răspuns
Timp de împrospătare pe ecran
Dimensiune M Bytes
Număr de cipuri ROM
Uşurinţă de Timp de învăţare
utilizare Numărul de ferestre de ajutor
Fiabilitate Timpul mediu până la eroare
Probabilitatea de indisponibilitate
Rata de apariţie a erorilor
Disponibilitate
Robusteţe Timp de restart după eroare
Procentul de evenimente ce cauzează erori
Probabilitatea de corupere a datelor la erori
Portabilitate Procentul de instrucţiuni ce depind de
mediul ţintă de implementare
Numărul de medii ţintă de implementare
Interacţiunea cerinţelor
Conflictele dintre diferite cerinţe non-funcţionale
sunt un lucru obişnuit în sistemele complexe
Exemplu: un sistem folosit în navete spaţiale
 Pentru a minimiza greutatea, numărul de cipuri
separate din sistem trebuie minimizat
 Pentru a minimiza consumul de putere, trebuie
folosite cipuri cu consum redus
 Totuşi, folosirea cipurilor cu consum redus poate
însemna că vor fi folosite mai multe cipuri. Care
cerinţă este mai importantă (critică)?
Imprecizii ale cerinţelor
Atunci când cerinţele nu sunt enunţate precis
apar probleme
Cerinţele ambigue pot fi interpretate diferit de
utilizatori şi dezvoltatori
De ex., ‘instrumente adecvate de vizualizare ’:
 Intenţia utilizatorului – instrumente de vizualizare
speciale pentru fiecare tip de document
 Interpretarea dezvoltatorului – oferirea unui editor
de text care să prezinte conţinutul documentului
Sfaturi pentru scrierea cerinţelor
Inventează un format standard şi foloseşte-l
pentru toate cerinţele
Foloseşte limbajul într-un mod consistent
Foloseşte “trebuie” pentru cerinţele obligatorii
şi “ar trebui” pentru cerinţele de dorit
Scoate în evidenţă părţile cheie ale cerinţelor
Evită folosirea jargonului informatic
Modalităţi de formulare a
specificaţiilor
Notaţie Descriere
Limbaj natural Această abordare depinde de definirea unor şabloane standard pentru exprimarea
structurat cerinţelor.
Limbaje de Această abordare foloseşte limbaje asemănătoare cu limbajele de programare dar cu
descriere a facilităţi mai abstracte pentru a specifica cerinţele prin definirea unui model
proiectării operaţional al sistemului. Această abordare nu este prea mult folosită astăzi cu toate
că poate fi utilă pentru specificaţiile de interfeţe.
Notaţii grafice Un limbaj grafic, suplimentat de note de text, folosit pentru a defini cerinţele
funcţionale ale sistemului. Astăzi se folosesc descrieri de tip use-case (cazuri de
utilizare) şi diagrame de secvenţă .
Specificaţii Acestea sunt notaţii bazate pe concepte matematice cum ar fi automate cu stări
matematice finite. Aceste specificaţii ne-ambigue reduc discuţiile dintre client şi contractor
legate de funcţionalitatea sistemului. Pe de altă parte majoritatea clienţilor nu
înţeleg specificaţiile formale şi au mari rezerve în a le accepta ca şi contract.
Specificaţii în limbaj structurat
Avantajul este că se menţine expresivitatea
limbajului natural dar este impus un grad de
uniformizare a specificaţiilor
Libertatea celui care scrie cerinţe este bine să
fie limitată – de ex. de un şablon predefinit
pentru cerinţe
Toate cerinţele trebuie scrise într-o manieră
standard
Terminologia folosită în descrieri trebuie
controlata si poate fi limitată
Şabloane de specificaţii
Cuprind:
Definirea unei funcţii sau entităţi
Descrierea intrărilor şi a provenienţei lor
Descrierea ieşirilor şi a destinaţiei lor
Indicarea altor funcții/ entităţi necesare definirii/
descrierii funcției/ entităţii curente
Pre- şi post-condiţii (dacă este necesar)
Efecte secundare (laterale) ale funcţiei
Şabloane de specificaţii
Insulin Pump/Control Software/SRS/3.3.2

Funcţie Calculează doza de insulină: Nivelul sigur de zahăr

Descriere Calculează doze de insulină ce trebuie administrată când nivelul măsurat de zahăr este în
zona de siguranţă între 3 şi 7 unităţi.
Intrări Citirea nivelul curent de zahăr (r2), şi precedentele două citiri (r0 and r1)
Sursă Nivelul curent de zahăr de la senzor. Alte citiri din memorie.
Ieşiri DozaCalculată – doza de insulină ce trebuie administrată
Destinaţie Bucla principală de control
Acţiune: DozaCalculată este zero dacă nivelul zahărului este stabil sau în cădere sau dacă nivelul
este în creştere dar rata de creştere scade. Dacă nivelul creşte şi rata de creştere creşte şi ea, atunci
DozaCalculată se obţine împărţind diferenţa dintre nivelul curent al zahărului şi nivelul precedent la 4 şi
rotunjind rezultatul. Dacă rezultatul este rotunjit la zero atunci DozaCalculată este doza minimă ce poate
fi administrată.
Necesită Două citiri precedente pentru a putea fi calculată rata modificării nivelului de zahăr.
Pre-condiţie Rezervorul de insulină conţine cel puţin doza maximă de insulină..
Post-condiţie r0 este înlocuit de r1 apoi r1 este înlocuit de r2
Efecte-secundare Nici unul
Documentul de cerinţe
Documentul de cerinţe este exprimarea oficială
a ceea ce se cere de la dezvoltatorii sistemului
Trebuie incluse definiţii ale cerinţelor utilizator
dar şi specificaţii ale cerinţelor de sistem
Cerințele sunt separate (decompoziția!)
NU este un document de proiectare: exprimă
CE trebuie să facă sistemul şi nu CUM face
Există o structură standard recomandată: IEEE
STD 830-1993 (IEEE Recommended Practice
for Software Requirements Specifications)
IEEE Std 830-1998
(Revision of IEEE Std 830-1993)
1.Introducere. 2.Descriere generală.
1.1.Obiectivul 2.1.Locul aplicaţiei în
documentului cerințelor sistemul existent
1.2.Domeniul produsului 2.2.Funcţiile produsului
informatic solicitat
1.3.Definiţii, acronime,
prescurtări 2.3.Caracteristicile
utilizatorilor
1.4.Referinţe
2.4.Restricţii generale
1.5.Prezentarea generală a
documentului 2.5.Ipoteze și dependențe
IEEE Std 830-1998 (cont.)
3.Cerinţe concrete.
3.1.Cerinţe funcţionale
3.2.Cerinţe ptr. interfeţe
3.3.Cerinţe de performanţă
3.4.Restricţii de proiectare
3.5.Atribute și proprietăți
de sistem emergente
3.6.Cerințe logice ale BD
3.7.Atribute de calitate
4.Anexe.
…
5.Index.
…
Obs. Secț.3 e cea mai consistentă
parte a documentului. Datorită
specificității mari a organizațiilor,
structura documentului nu este
standard, începând cu această
secțiune.
1.Introducere
1.1.Obiectivul aplicatiei.
Scopul documentului. Prezintă care termenii din specificaţie
comportarea externă a aplicaţiei, sunt explicaţi în detaliu.
se descriu cerinţele nefuncţionale, 1.4.Referinţe.
restricţiile de proiectare şi alţi
factori necesari pentru descrierea Lista completă a materialelor
completă a cerinţelor software. la care se fac referiri în doc.
Identificarea fiecărui docum.
1.2.Domeniul. prin titlu, dată, autor, editură.
Identifică produsul software prin Precizarea surselor ref.
nume. Explică funcţionalitatea
software-ului. Descrie modul în
1.5.Prezentarea generală a
care produsul va fi utilizat. documentului.
Descrierea conţinutului
1.3.Definiţii, acronime, presc.
restului documentului.
Cu eventuale trimiteri la anexe în
2.Descriere generală
2.1.Locul aplicaţiei în sistemul
existent
Relaţiile cu alte produse software.
In cazul în care produsul este o
componentă a unui sistem amplu
se precizează cerinţele sistemului,
modul de comunicare etc.
2.2.Funcţii produs informatic
Rezumat al principalelor funcţii
realizate de produsul software
2.3.Caracteristicile utilizatorilor
Despre potenţialii utilizatori ai
produsului : nivel de instrucţie,
experienţa, pregătire informatică
2.4.Restricţii generale
Limitări hardware
Interfeţe cu alte aplicaţii
Limbaj de implementare,
Caracterul critic al aplicaţiei
Considerente de siguranţă.
2.5.Ipoteze şi dependenţe.
Factori care pot afecta
cerinţele precizate în SCS.
Schimbarea cerinţelor ,
componente sau sisteme de
operare care se presupun a fi
achiziţionate
3.Cerinţe concrete (1)
3.1.Cerinţe funcţionale 3.1.2. Cerinţa funcţionala 2.
3.1.1.Cerinţa funcţională 1. ……………………………
<Denumirea funcţiei>
3.1.1.1.Introducere.
3.1.1.2.Intrări.
< Verificarea corectitudinii datelor
de intrare>
3.1.1.3.Procesare. 3.1.n. Cerinţa funcţională n.
<Descrierea parametrilor. Secvenţa ……………………………
de operaţii. Relaţia intrări-ieşiri.
Tratare erori.>
3.1.1.4.Ieşiri.
<Format, modul de comunicare>
3.Cerinţe concrete (2)
3.2.Cerinţe pt. interfeţe
3.2.1.Interfeţe utilizator.
Caracteristicile logice pentru
fiecare interfaţă între software
şi utilizatori: formate ecran,
machete de pagini, conţinutul
pag, meniuri, chei funcţionale.
3.2.2.Interfeţe hardware.
Caracteristicile logice pentru
interfeţele produsului software
şi componentele sistem hard.
Caracteristici de configuraţie
(nr.porturi, set de instrucţiuni
etc). Componente hardware
dedicate.
3.2.3.Interfeţe software.
Utilizarea altor produse software:
baze de date, sistem de operare ,
biblioteci de clase (MFC), pachete
de programe matematice, grafice
etc. Pentru fiecare dintre acestea
se specifică numele, mnemonicul,
versiunea. Definirea interfeţelor,
cu precizarea conţinutului şi a
formatului mesajelor. Se poate
face referinţă la documente care
definesc interfaţa cerută.
3.2.4.Interfeţe de comunicaţie.
Precizarea protocoalelor de
comunicaţie în reţele.
3.Cerinţe concrete (3)
3.3.Cerinţe de performanţă
Timpi de răspuns
Capacitate – nr. utilizatori sau
tranzacţii/sec.
Utilizare resurse – memorie,
disc, comunicaţii
3.4.Restricţii de proiectare
3.4.1.Standarde utilizate.
Ciclu de viaţă, testare, codificare
3.4.2.Restricţii software.
Limbaj de implementare
Configurare mediu programare
Baze de date
3.5.Atribute asigurate.
3.5.1.Securitate.
Criptare , parola.. Fisiere de
evidenţă a accesului. Restricţii
privind accesul la anumite
module ale aplicaţiei.
Verificarea integrităţii datelor
pentru anumite variabile cu
caracter critic.
3.5.2.Intreţinere.
Caracteristici ale software-ului
ce permit întreţinerea aplicaţiei
corectivă şi evolutivă.
3.6.Alte cerinţe
Utilitatea standardului de cerinţe
(IEEE)
Un document de cerinţe software este necesar
pt. exprimarea oficială a cerinţelor sistemului
Standardul IEEE este un punct de start pentru
definirea standardelor detaliate de specificare
a cerinţelor (un ex. in continuare)
El defineşte o structură generică asupra unui
document de cerinţe ce trebuie creat pentru
un anumit sistem:
 Introducere
 Descriere generală
 Cerinţe concrete (specifice)
 Apendice
 Index
O structură posibilă(standard de
detaliu) a unui document de cerinţe
Prefaţă
Introducere
Glosar
Definirea cerinţelor utilizator
Arhitectura sistemului
Specificarea cerinţelor de sistem
Modele de sistem
Evoluţia sistemului
Apendice
Index
Utilizatorii documentului de cerinţe
Specify the requirements and
read them to check that they
System
meet their needs. They
customers
specify changes to the
requirements

Use the requirements

document to plan a bid for
Managers
the system and to plan the
system development process

Use the requirements to

S ystem
understand what system is to
engineers
be developed

System test Use the requirements to

engineers develop validation tests for
the system

System Use the requirements to help

maintenance understand the system and
eng ineers the relationships between its
parts
Concluzii
Cerinţele exprimă ce trebuie să facă sistemul şi/
sau definesc constrângerile asupra operării sau
implementării sale
 Cerinţele funcţionale exprimă serviciile pe care le va
oferi sistemul
 Cerinţele non-funcţionale constrâng sistemul sau
procesul de dezvoltare
 Cerinţele utilizator sunt exprimări de nivel înalt cu ce
trebuie să facă sistemul, pot fi scrise în limbaj
natural, eventual folosi tabele, diagrame
 Cerinţele de sistem trebuie să descrie funcţiile
oferite de sistem
Specificațiile reprezintă sistemul din perspectiva
echipei tehnice