Cuprins:
1.Analiza de sistem -Ancu Alina-442 A
2.Definirea cerintelor - Petrache Victor-441 A
3.Ingineria cerintelor - Serb Ramona-442A
4.Niveluri formale de specificare a cerintelor - Stoian Adriana-441 A
5.Calitatea analizei de sistem - Bogdan Rata-441 A
6.Documente cu cerinte - Sirbu Adelina -442 A
7.Evolutie cerinte - Bogdan Zaharie-441 A
8.Etape ale fazei de specificare - Marius Dragan-441 A
9.Structura documentului de definire a cerintelor si de specificare a
cerintelor -Tona Enis-441 A
10.Validarea cerintelor si folosirea prototipului-Dobre Marius-442 A
1. Analiza de sistem
În zilele noastre, calculatoarele au devenit indispensabile, fiecare
persoana are un calculator, laptop sau un telefon ce indeplineste functiile unui
calculator.Putem spune ca traim intr-o era informatizata,intalnind
calculatoarele la orice pas, domeniul acesta fiind intr-o dezvoltare continua.De
ce au devenit calculatoarele atat de folosite?Deoarece ne usureaza munca,
prelucreaza informatia pe care noi i-o transmitem. Astfel ia nastere sistemul
informational si sistemul informatic.
Sistem informatic este prin definitie un sistem care permite atat
introducerea,stocarea, prelucrarea cat si extragerea informației in diverse
forme.
In schimb,sistemul informational este definit ca fiind un ansamblul de
elemente care fac parte din procesul de transmisie,colectare sau prelucrare a
informatiei.Putem spune ca sistemul informatic cuprinde sistemul
informational.
Informatia este transmisa cu ajutorul sistemului informational. In orice
unitate, societate sistemul informational ocupa un rol important, informand
personalul cu privire la deciziile, schimbarile ce au loc in cadrul organizatiei.
Astfel in sistem se poate gasi informatia, documentele cu privire la informative,
personalul cu mijloacele de comunicare, etc.
În cadrul sistemului informational, tehnica de calcul joaca un rol important,
cu ajutorul ei putandu-se prelucra datele primare, care sse pot transmite mai
departe. Transferul de date se poate face si prin intermediul unei retele de
calculatoare,electronic.
Daca sistemul informational, era alcatuit in principiu din informative, sistemul
informatic este alcatuit din dispositive capabile sa stocheze informatia cum ar
fi: calculatoarele,hard-urile,sistemele de transmisie a datelor.
Sistemele informatice acopera cele mai diverse domenii.În functie de
specializare, avem :
Sisteme specializate, rezolvand doar un anumit tip de problem;
Sisteme de uz general-rezolva mai multe tipuri de probleme din mai multe domenii;
Sisteme locale, programele necesare prelucrarilor de date si datele se afla pe un singur sistem de calcul;
Sisteme pe retea, sistemul functioneaza într-o retea de calculatoare, caz în care, datele si programele pot fi distribuite mai multor statii de lucru
ce fac parte din acea retea.1
Sistemele conectate in retea sunt din ce in ce mai numeroase, avand mai multe
avantaje, in principal viteza de transfer a datelor.
În functie de localizarea datelor si de locul în care sunt efectuate prelucrarile, putem avea sisteme informatice :
Cu date centralizate, datele se afla pe un singur sistem de calcul; Cu date distribuite, datele se afla distribuite pe mai multe calculatoare în
retea;
Cu prelucrari centralizate, prelucrarea datelor se face pe o singura statie de lucru, indiferent de numarul statiilor pe care sunt informatiile de
prelucrat; Cu prelucrari distribuite, mai multe calculatoare prelucreaza datele
provenite de la unul sau mai multe calculatoare din retea;
Dupa domeniul în care functioneaza, sistemele pot fi clasificate :
De baze de date, specializate în gestiunea unor cantitati mari de date; Pentru prelucrari stiintifice, specializate pe anumite domenii stiintifice;
Pentru conducerea proceselor tehnologice, pentru conducerea unor masini,scule,unelte computerizate;
Dupa nivelul ierarhic ocupat de sisteme informatice în structura
organizatorica a societatii, putem avea :
Sisteme informatica pentru conducerea activitatilor la nivelul unitatilor economice;
Sisteme la nivelul organizatiilor cu structura de grup; Sisteme informatice teritoriale; Sisteme informatice la nivel de ramura si subramura si la nivel economic
national; Sisteme de uz general.
Dupa activitatea ce o automatizeaza, sistemele pot fi :
1 http://www.referatele.com/referate/informatica/online6/sistemul-
informational-si-sistemul-informatic-referatele-com.phphttp://www.biblioteca-
digitala.ase.ro/biblioteca/pagina2.asp?id=cap1
Pentru conducerea productiei; Pentru activitatea comerciala;
Pentru evidenta contabila; Pentru evidenta materialelor si marfurilor;
Pentru evidenta personalului si salarizare; Pentru evidenta mijloacelor fixe.
Sistemele informatice au o mare importanta in ramura economica,
aceasta fiind ramura ea mai informatizata. Astfel, ele, ajuta la administrarea datelor intr-un mod strategic pentru succesul in afaceri.” Sistemele informatice devin astăzi tot mai mult o componentă vitală a succesului în afaceri pentru
oorganizaţie sau un întreprinzător.”
Aceste sisteme au o aplicare in economie, economia devenind una dintre cele mai informatizate ramuri.
Înca din cele mai vechi timpuri, omul, chiar fara sa stie, era preocupat de acest domeniu - economia. Cum apare conceptual economic: conceptul este generat de necesitatile omului, de nevoia de hrana, de apa, de haine, de
comunicare.
Pentru a-si satisfice anumite nevoi, apare si nevoia de consum, de folosire a anumitor resurse. Asa apare notiunea de resurse economice, singurul dezavantaj al acestor resurse este faptul ca sunt limitate, gestionarea lor
trebuie sa se faca corespunzator.
Omul este nevoit sa isi dozeze energia in mod corespunzator, sa aleaga
cel mai bine prioritatea nevoilor si sa foloseasca in mod corespunzator resursele.
In cazul companiilor , acestea desfasoara o activitate de productie, ventiturile obtinute in urma activitatii permit companiilor sa se dezvolte.In
cazul lor, nevoile sunt de a ramane pe piata, beneficiind de resurse, de forta de munca, de mijloace de productie, compania urmarind obtinerea unui profil cat mai mare.Astfel, utilizarea tehnicii de calcul, mareste considerabil eficienta
economica..
În cadrul unitatilor economice sunt o multitudine de activitati ce pot fi supuse informatizarii. Acestea pot fi împartite în grupe, în functie de compartimentele în care se desfasoara.
Spre exemplu, în cadrul compartimentului productie se poate informatiza activitatea de stabilire a structurii productiei si de dimensionare a sa, programarea si urmarirea productiei, etc. În cadrul compartimentului
financiar-contabil, activitatea ar putea fi informatizata aproape în totalitate, la fel ca si activitatea din cadrul compartimentului personal-salarizar. Fiecare
dintre compartimentele unei unitati economice poate fi informatizat într-o
masura mai mare sau mai mica, ideal însa ar fi ca toate acestea sa fie înglobate într-un sistem informatic global de gestiune economica la nivelul întregii
intreprinderi. Pentru realizarea unui sistem informatic eficient , trebuiesc avute în vedere
unele reguli de baza, ce au fost deduse din practica:
Abordarea globala modulara- cand se proiecteaza sistemul, trebuie
sa se tina cont de legatura acestuia cu lumea exterioara, posibilitatile de comunicare cu alte sisteme si mai ales compatibilitatea cu alte sisteme, sistemul proiectat sa poata fi
inclus intr-un sistem mai complex sau el sa contina mai multe sisteme.
Criteriul eficientei economice: sta la baza realizarii sistemului. Se urmareste ca sistemul sa fie rentabil
Orientarea spre utilizatori: cerintele si preferintele utilizatorilor
sunt 2 mari criteria ce trebuie avute in vedere la proiectarea unui sistem.
Asigurarea uniticitatii introducerii datelor: cand se proiecteaza un
sistem informatics, acesta foloseste aceleasi date de mai multe ori, asadar un sistem trebuie proiectat in asa fel incat,datele sa fie
introduce o singura data, sistemul sa distribuie automat datele unde sunt necesare.
Antrenarea beneficiarului la realizarea sistemului: acest principiu
apare tot datorita utilizatorilor, sistemul sa fie user friendly Solutie generala, independent de configuratia actuala a sistemului
informatizat: sistemul trebuie proiectat in asa fel incat sa nu fie dependent de dotarea tehnica, sa fie intr-o continua dezvoltare.
Posibilititatea de dezvoltare ulterioara: sistemul poate fi
imbunatatit in raport cu cerintele viitoare ale utilizatorilor.
Analiza preliminara a sistemului
Analiza preliminara este o etapa distincta in activitatile desfasurate
pentru perfectionarea sistemului informational. Presupune identificarea si
definirea ariei de intindere a sistemului informational.
Etapa de analiza preliminara a unui studiu de perfectionare de sistem
informational nu este intotdeauna necesara, ea fiind impusa în situatiile în
care se abordeaza sistemul în ansamblul sau sau la nivelul societatii.
Analiza detaliata a functionarii sistemului informational
Aceasta etapa presupune cunoasterea in detaliu a principiului de
functionarea a sistemului informational, precum si a particularitatilor sale, a
evaluarii. Aceasta etapa presupune la randul ei mai multi pasi: cunoasterea si
analiza documentelor din sistem, evidentierea tuturor cerintelor ce stau la baza
sistemului, etc.
Proiectarea noului sistem informational si a componentelor
sale informatice
In vederea proiectarii noului sistem, se ia in calcul solutiile de
imbunatatire a sistemului informatics, definit in faza precedent, proiectarea
logica a sistemului, proiectarea detaliata a subsitemelor informatice care fac
parte din noul sistem.
Experimentarea sistemului proiectat
Implementarea noului sistem presupune punerea la punct a
activitatilor desfasurate pentru inlocuirea vechiului sistem cu cel
proiectat.
Exploatarea si mentinerea in functiune a sistemului.
Pentru a implementa un sistem informatic eficient trebuie sa avem in
vedere anumite strategii, pentru rezultate bune.
Exemple de strategii de implementare:
Strategie ascendenta(“bottom-up”)- se rezolva problemele cele mai
mici in detaliu, solutiile fiind date in vederea rezolvarii unor
problem mai complex. Se procedeaza la fel, pana cand intreg
sistemul este solutionat, fara problem
Strategie descendenta(“top-down”)- este o strategie opusa celei
ascendente, deci porneste de sus in jos. Descompune problemele,
in problem mai mici, pana cand ajungem la o singura problema.
Apoi se incearca rezolvarea ei.2
De exemplu, daca vrem sa dezvoltam o aplicatie pentru o intreprindere
cu un numar de 200 de salariati, dintre care 150 sunt muncitori calificati si angajati pe o perioada nedeterminata, restul de 50 sunt muncitori necalificati, folosim un limbaj de programare cat mai eficient- Fox Pro.
Visual FoxPro este un limbaj de programare orientata pe obiect şi
procedurala produs de Microsoft. Este derivat din FoxPro (cunoscut iniţial ca FoxBASE), care a fost dezvoltat de începutul Software Fox în 1984. Fox Tehnologii fuzionat cu Microsoft în 1992, după care software-ul achiziţionat
caracteristicile suplimentare şi prefixul "Visual". Ultima versiune de FoxPro (2.6) a lucrat sub Mac OS, DOS, Windows, şi Unix: Visual FoxPro 3.0, primul "Visual" versiune, platforma de suport reduse la numai Mac şi Windows, şi
versiunile ulterioare au fost doar Windows. Versiunea curentă a Visual FoxPro este bazate pe COM si Microsoft a declarat că nu intenţionează să creeze o
versiune Microsoft NET..3
Trecem deci la analizarea problemei de la general la particular prin asa
numita metoda descendenta sau top-dpwn.
Construim programul principal cu meniurile aplicatiei. Stabilim deci
modulele necesare.
In urma discutiilor cu utilizatorul principal, s-a stabilit ca aceasta aplicatie sa fie implementata într-o retea informatica formata dintr-un server aflat chiar în biroul "Personal-salarizare" si cinci statii de lucru aflate în
teritoriu (2 în interiorul intreprinderii, câte unul pentru fiecare sectie si unul la punctul de lucru "Constanta", altul la “Pitesti” si ultimul la “Sibiu”.
Statiile care se gasesc pe teritoriu, au posibilitatea doar de introducere a datelor, prelucrarea datelor se face in statia server-ului.
Se stabileste deci ca aplicatia va avea ca optiuni:
2 http://www.scritube.com/stiinta/informatica/Reguli-de-baza-in-
implementare13488.php
3 http://en.wikipedia.org/wiki/Visual_FoxPro
1. Introducere date - cu ajutorul acestui modul se vor introduce datele referitoare la personal în sistem. Introducerea datelor este permisa de pe toate
statiile de lucru.
2. Vizualizare/modificare date - permite vizualizarea si/sau
modificarea/corectia anumitor date introduse.
3. Listare - cu acest modul se vor lista la imprimanta diferite liste cu pontaje, liste de personal, etc
4. Prelucrare date – este posibila doar pe statia server
5. Liste centralizate - se vor scoate listele finale, obtinute dupa
centralizarea si prelucrarea datelor.
Structura bazelor de date:
Cod angajat
Nume
Prenume
Functia
Locul de munca
Salariul
Adresa
Telefonul
Cod numeric personal
Data angajarii
Astfel se proiecteaza modul de introducere a datelor,de vizualizare a datelor si de modificare, avand in vedere structura bazei de date.
Odata terminate si testate blocurile ce urmeaza a fi implementate pe statiile de lucru, se trece la proiectarea aplicatiilor de pe server si anume la
blocul de centralizare a datelor si la modulul de liste centralizate.
Centralizarea datelor se face pe o structura de baza de date asemanatoare cu cea în care s-au facut actualizari pe statiile de lucru, având aceleasi câmpuri ca acestea si ân plus altele necesare calcularii salariilor, etc.
Acest subprogram adauga deci la baza de date de pe server bazele de date de pe statiile de lucru, le sorteaza dupa tipul angajatului (TESA sau muncitor), dupa locul de munca, etc, pregatind astfel baza de date pentru listele
centralizate - obiectivul final al aplicatiei.
Dupa terminarea si testarea aplicatiei, urmeaza instructajul beneficiarului si în final darea în folosinta cu asigurarea întretinerii aplicatiei.
În linii mari acesta este proiectul de realizare a unei aplicatii pe teme de personal într-o intreprindere.
2. Definirea Cerintelor
Ingineria cerintelor este procesul de stabilire a serviciilor cerute
sistemului de catre clienti precum si a constrangerilor sub care acesta va fi
dezvoltat si va opera [def. Sommerville 2004]
Cerintele, in sine, sunt descrieri ale serviciilor oferite de sistem si a
constrangerilor ce sunt generate pe parcursul desfasurarii intregului proces de
inginerie a cerintelor. Acestea pronesc de la afirmatii abstracte, de nivel inalt
pana la specificatii matematice functionale.
Cerintele indeplinesc mai multe functii: Pot forma baza negocierilor
pentru un contract deci trebuiesc sa fie deschise diverselor interpretari ce pot
aparea, pot forma baza contractului deci trebuiesc sa fie cat mai detaliat
definite, sau pot fi acoperite ambele afirmatii anterioare cu aceleasi cerinte.
Cerintele utilizatorului sunt:
Afirmatii in limbaj natural si/sau diagrame a serviciilor oferite
de sistem impreuna cu constrangerile operationale
Scrise pentru clienti
Cerintele utilizatorului se adreseaza:
Utilizatorilor finali
Inginerilor clientului
Managerilor clientului sau managerilor de contracte
Proiectantilor de sistem
Cerintele sistemului sunt:
Un document ce stabilieste descrierea detaliata a functiilor
sistemului, serviciilor oferite si constrangerilor operationale.
Cerintele de sistemul sunt adresate:
Utilizatorilor finali
Programatorilor
Proiectantilor de sistem
Cerintele se impart in cerinte functionale si cerinte nefunctionale.
O cerinta functionala defineste o functie a unui sistem software sau a
unei componente ale acestuia.
Cerintele functionale pot fi:
Calcule
Detalii tehnice
Manipulare de date si procesare
Alte functionalitati specifice care definlesc ce trebuie ca un
sistem sa efectueze.4
Cerintele functionale5 sunt sustinute de cerintele nefunctionale (cerinte
de calitate) care impun anumite constrangeri asupra design-ului sau a
implementarii (precum performanta, securitate sau fiabilitate). In general
cerintele functionale sunt exprimate in forma “Sistemul trebuie sa <cerinta>”
comparativ cu cele nefunctionale care sunt exprimate in forma “Sistemul va fi
<cerinta>”.
4 http://en.wikipedia.org/wiki/Requirements_analysis
5 http://en.wikipedia.org/wiki/Functional_requirement
Planul pentru implementarea cerintelor functionale este detaliat in
design-ul sistemului pe cand cel pentru implementarea cerintelor nefunctionale
este detaliat in arhitectura sistemului.
Cerintele functionale specifica un anume rezultat al unui sistem. Acesta
trebuie sa fie contrastat cu cerintele nefunctionale care specifica caracteristicile
generale precum costul sau fiabilitatea. Cerintele functionale ne conduc catre
arhitectura unei aplicatii pe cand cele nefunctionale catre arhitectura tehnica a
unei aplicatii.
O cerinta functionala tipica va contine un nume si un numar de
indentificare unic si un sumar. Aceste informatii sunt utilizate pentru a ajuta
cititorul sa inteleaga de ce este necesara aceasta cerinta si cum sa poata
urmari cerinta de-alungul dezvoltarii softului.
Cerintele nefunctionale6 sunt un tip ce cerinte ce specifica criteriul
care poate fi folosit pentru a decide o operatie a unui sistem. Cerintele
nefunctionale mai sunt numite calitati ale unui sistem si pot fi divizate in 2
categorii:
1. Calitati de executie precum securitatea sau cat de usor este de
utilizat un sistem), acestea pot fi observate la rularea programului
2. Calitati ale evolutiei precum cat de usor este de testat programul, cat
de usor este de intretinut, scalabilitate si respectiv extensibilitate
toate acestea fiind inglobate in structura statica a unui sistem
software.
Use Cases (Cazuri de utilzare)i
Un caz de utilizare defineste un set de interactiuni orientate pe scop intre
participantii externi (actori) si sistemul aflat in consideratie.
Actorii sunt parti exterioare sistemului, care interactioneaza cu sistemul.
Un actor poate fi o clasa de utilizatori, rolurile utilizatorilor sau alt sistem.
Cockburn (1997) face distinctia dintre actori primari si secundari. Un actor
primar are ca are o cerinta ce necesita asistenta sistemului. Un actor secundar
este unu din partea caruia sistemul are nevoie de asistenta.
6 http://en.wikipedia.org/wiki/Non-functional_requirement
Un caz de utilizare este initiat de catre un utilizator cu un scop anume si
se termina cu succes cand scopul a fost satisfacut. Un caz de utilizare descrie
secventa de interactiuni dintre actori si sistemul necesar pentru a furniza
scopul. Acesta include, de asemenea, posibile variatiuni ale acestei secvente
sau secvente alternative care pot satisface acelasi scop, dar si secvente care pot
conduce la esuarea terminarii serviciului datorita unui comportament
exceptional, tratarea erorilor. Sistemul este tratat ca o cutie neagra, si
interactiunile cu sistemul, incluzand raspunsurile sistemului, sunt percepute
din exteriorul sistemului.
In general pasii cazurilor de utilizare sunt scrise intr-un vocabular nativ,
usor de inteles. Scopul fiind ca utlizatorii sa poata urmari si valida cazurile de
utilizare, si accesibilitatea incurajeaza utilizatorii sa se implice activ in
definirea cerintelor.
Scenarii
Un scenariu este o instanta a unui caz de utilizare si reprezinta o
singura cale printr-un caz de utilizare, asadar se poate construi un scenariu
pentru principala parcurgere a unui caz de utilizare si alte scenarii pentru
fiecare posibila variatie a parcurgerii unui caz de utilizare. Scenariile pot fi
scrise folosind diagrama de secvente.
Structurarea cazurilor de utilizare
UML (1999) propune trei relatii care pot fi utilizate pentru a structura
cazurile de utilizare. Acestea sunt generalizare, includere si extindere.
Includerea relatiei dintre doua cazuri de utilizare inseamna ca secventa
comportamentului descrisa, este inclusa in secventa de baza a cazului de
utilizare (echivalentul unei subrutine).
Extinderea relatiei presupune un mod de capturarea unei variatii la un
caz de utilizare. Extinderile nu sunt adevarate cazuri de utilizare, ci sunt
schimbari ale unor pasi dintr-un caz de utilizare existent. Extinderile sunt tipic
utilizate pentru a specifica schimbari in pasii care apar cu scopul de a
acomoda o presupunere daca aceasta este falsa (Coleman, 1998).
Generalizarea unei relatii intre doua cazuri "implica faptul ca copilul
unui caz de utilizare contine toate atributele, secventa de comportamente si
extinderea punctelor definite in parintele unui caz de utilizare si participa in
toate relatiile parintelui cazului de utilizare" (UML, 1999).
Diagrama cazurilor de utilizare
Figura 1 - Exemplu de diagrama a cazurilor de utilizare (UML, 1999, pp. 3-83 la 3-88)
Efectuarea unei comenzi
------------
Punct de extindere, cereri aditionale: dupa crearea
comenzii
Datele venite de la
consumator Comandare produs
Catalogarea Cererilor
Plata Serviciului
Credit Stabilit
Supervizor
Personal Vanzare
Verificare status
Consumator
includere
includere
includere
extindere
Template pentru cazuri de utilizare7
Caz de utilizare Identificator, numar de referetina si istoricul modificarilor Fiecare caz de utilizare trebuie sa aiba un nume unic sugerand scopul acestuia. Numele trebuie sa exprime ce se intampla
cand cazul de utilizare este efectuat. Este recomandat ca numele sa fie o fraza activa gen (Plasare Comanda). Este convenabil sa se includa un numar de referinta pentru a
indica cum este relationat cazul prezent de un alt caz de utilizare. Campul de nume trebuie sa contina crearea si istoria
modificarilor cazului de utilizare utilizand cuvantul cheie "history"
Descriere Scopul ce trebuie atins de catre cazul de utilizare si sursele pentru dependente Fiecare caz de utilizare trebuie sa contina o descriere a
principalelor scopuri de business pentru cazul de utilizare. Descrierea trebuie sa listeze sursele pentru dependente precedate de cuvantul cheie "sources"
Actori Lista actorilor implicati in cazul de utilizare Liste ale actorilor implicati in cazul de utilizare. Optional, un
acotor poate fi indicat ca fiind primar sau scundar.
Presupuneri Conditii ce trebuie sa fie adevarate astfel incat cazul sa fie efectuat cu succes Listeaza toate presupunerile necesare pentru ca scopul cazului de utilizare sa fie atins cu succes. Fiecare presupunere trebuie
sa fie inceputa intr-o maniera declarativa, ca o afirmatie care se poate evalua ca fiind adevarata sau falsa. DAca o
presupunere este falsa atunci nu este specificat ce trebuie sa efectuze cazul. Cu cat sunt mai putine presupuneri intr-un caz de utilizare cu atat cazul este mai robust.
Pasi Interactiuni intre actori si sistem care sunt necesare pentru atingerea scopului. Secventa interactiunilor necesara pentru ca scopul sa fie atins. Inteactiunile intre sistem si actori sunt structurate in unul sau mai multi pasi care sunt exprimati in limbaj natural. Un pas
are forma <numar secventa><interactiune>
Afirmatiile conditionale pot fi utilizate pentru a exprima cai alternative prin cazul de utilizare
Variatii (optional) Orice variatie in pasii unui caz de utilizare Se pot da mai multe detalii despre un pas listand variatiile acestuia.
7 Derek Coleman 1998
<referinta pas><lista variatii separate prin sau>
Non-functionale Lista tuturor cerintelor nefunctionale pe care cazul de utilizare trebuie sa le indeplineasca Sunt listate in forma:
<cuvant_cheie>:<cerinta> Cuvintele cheie includ, dar nu sunt limitate la Performanta,
Fiabilitate, Toleranta, Frecventa, Prioritate. Fiecare cerinta este exprimata intr-un limbaj naturat sau un formalism potrivit.
Probleme Lista problemelor ce raman a fi rezolvate Lista problemele ce asteapta o solutionare. Pot fi de asemenea
note asupra unor posibile strategii de implementare sau impactul asupra altor cazuri de utilizare.
3. Ingineria Cerintelor
"Cea mai dificila parte in realizarea unui sistem software este de a decide exact ceea ce trebuie realizat. Nici o altă parte din lucrarea propriu-zisa nu este la fel de dificila ca stabilirea cerinţelor tehnice detaliate, aici fiind incluse toate interfeţele catre oameni, maşini şi alte sisteme software. Nici o altă parte a operei nu poate schilozi mai rau sistemul rezultat dacă este făcută greşit. Nici o altă parte nu este mai dificil de reparat ulterior."8 Fredrick Brooks
8http://www.westfallteam.com/Papers/The_Why_What_Who_When_and_How_
Of_Software_Requirements.pdf
3.1 Prezentare generala
Ingineria software este o disciplina de inginerie care se ocupă cu toate
aspectele legate de producţia de software. Inginerii software ar trebui să adopte o abordare sistematică şi organizată pentru munca lor şi sa foloseasca
instrumente şi tehnici adecvate, în funcţie de problema care trebuie rezolvată, de constrângerile de dezvoltare şi resursele disponibile.
Economiile tuturor naţiunilor dezvoltate sunt dependente de software.
Din ce in ce mai multe sisteme sunt controlate de software. Ingineria Software este imbina teorii, metode şi instrumente pentru
dezvoltarea de software profesional. Cheltuielile de inginerie software reprezintă o parte semnificativă din PIB
în toate ţările dezvoltate.
Ingineria cerintelor este procesul de stabilire a serviciilor cerute
sistemului de catre clienti precum şi a constrângerilor sub care acesta va fi
dezvoltat şi va opera. Cerintele sunt descrieri ale serviciilor oferite de sistem şi a constrângerilor care sunt generate de-a lungul desfaşurarii procesului de
inginerie a cerintelor. Cerintele pornesc de la afirmatii abstracte de nivel înalt pâna la specificatii matematice functionale detaliate.
O cerinta poate varia de la o frază abstractă care descrie un serviciu sau
o constrângere de sistem până la o specificare matematică detaliată. Cerinţele sunt baza tuturor aplicaţiilor software în care acestea se
concentreaza pe ceea ce trebuie să facă cererea. Cerinţe sunt provocate de
client subliniind ceea ce doresc să facă sistemul, şi înregistrate într-o limbă pe care clientul o poate înţelege. Un document cerinţele poate deveni contractul
încheiat dintre client şi dezvoltatorii de software pe produsul care va fi livrat. Această situaţie este inevitabilă deoarece ele au două funcţii principale:
Pot sta la baza unei licitaţii, prin urmare trebuie să fie uşor de interpretat;
Pot sta la baza unui contract, deci trebuie definite în detaliu;9
9 Software Engineering de Ian Sommerville
3.2 Tipuri de cerinte
Cerinţele pot fi descrise in mai multe moduri. Pentru documente de
cerinţe formale, modul cel mai comun de impartire este în cerinţe funcţionale şi
cerinte non-funcţionale. Cerinţele funcţionale descriu modul în care un sistem
interactioneaza cu mediul său, serviciile pe care sistemul le oferă, cum să
reacţioneze la intrări, etc. Cerintele non-funcţionale descriu restricţiile de
sistem. Acestea includ constrângeri de timp pentru anumite activităţi,
securitate, şi confidenţialitate. Alte constrângeri asupra sistemului, cum ar fi
sistemul de operare, limbajul de programare, sau alte aplicaţii software, sunt
de asemenea incluse într-un document de cerinţe. Priorităţile pot fi atribuite la
fiecare cerinţă de către client pentru a ajuta la definirea dezvoltarii sistemului.
Cerinţele trebuie să fie determinate şi a agreeate de către clienţii,
utilizatorii, şi furnizorii unui produs software înainte de software-ul sa fie
construit.
Cei mai multi practicanti software-ul doar vorbesc despre toate aceste
cerinţe. Prin recunoaşterea faptului că există diferite niveluri şi tipuri de
cerinţe, aşa cum este ilustrat în figura de mai jos, adaptata de la Karl Wiegers
(2004), practicanţii obţin o mai bună înţelegere despre ce informaţii au nevoie
pentru a obţine , analiza, specifica şi valida atunci când acestia isi definesc
cerinţele software.
Cerinţele de afaceri definesc problemele de afaceri care urmează să fie
rezolvate sau oportunităţile de afaceri ce vor fi adresate produsului software. În
general, cerinţele de afaceri definesc de ce produsul software este în curs de
elaborare.
Cerinţele utilizatorilor privesc funcţionalitatea produsului software din
perspectiva utilizatorului.
Cerinţele funcţionale ale produsului ce definesc funcţionalitatea
software-ulului trebuie să fie construite în produs pentru a permite
utilizatorilor să-si îndeplinească sarcinile, totodata îndeplinind si cerinţele de
afaceri.
Fig. 1 Niveluri şi tipuri de cerinţe
Cerinte utilizator
Afirmatii în limbaj natural şi diagrame ale serviciilor oferite de sistem laolalta cu constrângerile operationale scrise pentru clienti. Programul trebuie
să ofere mijloace de reprezentare şi accesare a fişierelor externe create de alte instrumente.
Cerintele sistemului
Un document structurat stabilind descrierea detaliata a functiilor sistemului, serviciile oferite şi constrângerile operationale. Poate fi parte a contractului cu clientul.
Specificatii:
Utilizatorul trebuie să aibă mijloace de a defini tipul fişierelor externe
Fiecare tip de fişier exterior poate avea un instrument asociat cu care
poate fi deschis acel fişier
Fiecare tip de fişier exterior poate fi reprezentat cu un icon specific pe
ecran
Trebuie oferite mijloace ca pozele ce reprezintă tipurile de fişiere externe
să poată fi definite de utilizator
Când utilizatoru selectează o poză ce reprezintă un fişier, efectul
selecţiei este aplicarea instrumentului asociat acelui tip de fişier asupra fisierului selectat
Cerintele utilizator se adreseaza:
Managerilor clientului
Utilizatorilor finali
Inginerilor clientului
Managerilor de contracte
Proiectantilor de sistem
Cerintele de sistem se adreseaza:
Utilizatorilor finali
Inginerilor clientului
Proiectantilor de sistem
Programatorilor
Cerinte functionale: Afirmatii despre servicii pe care sistemul trebuie sa le contina, cum
trebuie el sa raspunda la anumite intrari şi cum reactioneze în anumite situatii.
Descriu funcţionalitatea sau serviciile sistemului software.
Depind de tipul de software şi de tipul de utilizator ce vor folosi sistemul. Cerinţele funcţionale pot fi fraze abstracte de descriu ceea ce face
sistemul. Ele pot descrie deasemenea sistemul în detaliu.
Cerinte non-functionale
Constrângeri ale serviciilor si functiilor oferite de sistem cum ar fi
constrângeri de timp, constrângeri ale procesului de dezvoltare, standarde, etc.
Acestea definesc proprietăţile şi constrângerile 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 fi specificate cerinţe de proces care impun un anumit sistem CASE,
un limbaj de programare sau o metodă de dezvoltare. Cerinţele ne-funcţionale pot fi mai critice decât cele funcţionale. Dacă
primele nu sunt îndeplinite, sistemul este inutilizabil.
Clasificare: Cerinţe de produs
Sunt cerinţele care specifică lucruri pe care produsul trebuie să le îndeplinească legat de viteza de execuţie, fiabilitate, etc.
Cerinţe de organizare Cerinţele 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ţele 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
Cerinte ale domeniului
Cerinte impuse de domeniul aplicatiei care reflecta caracteristicile
acestuia.
Descrie functionalitatea sistemului şi serviciile oferite. Depind de tipul softului, de utilizatorii avuti în vedere şi de tipul sistemului pe care softul este
utilizat. Cerintele functionale ale utilizatorilor pot fi descrieri de ansamblu dar
cerintele functionale ale sistemului trebuie sa descrie în detaliu serviciile
oferite.Trebuie evitate cerintele ambigue.
Cerinte ale produsului Cerinte care specifica un anumit comportament al produsului (ex: viteza
de executie, fiabilitatea etc.) Cerinte legate de organizare
Cerinte care sunt consecinte ale politicilor de organizare a productiei
software (ex: standarde utilizate, cerinte de implementare etc.) Cerinte externe
Cerinte asociate unor factori externi (ex. cerinte de interoperabilitate, cerinte legislative etc.).
Cerinte ale produsului:
cerinte legate de gradul de utilitate
cerinte de eficienta (performanta/spatiu)
cerinte de fiabilitate
cerinte de portabilitate
Cerinte legate de organizare
cerinte de livrare
cerinte de implementare
cerinte legate de standarde
Cerinte externe
cerinte de interoperabilitate
cerinte legate de etica
cerinte legislative10,11,12
3.3 Procesul Ingineriei Cerintelor
Ingineria cerinţelor software este o inginerie disciplinata, orientată pe proces si se apropie ca mod de abordare de definiţia, documentatia şi de
întreţinerea cerinţelor de software pe întregul ciclu de viaţă al spatiu de dezvoltare al software-ului. După cum este ilustrat în Figura 3, ingineria cerinţelor software este alcătuita din două procese majore: dezvoltarea
cerinţelor şi gestionare lor. Dezvoltarea cerinţelor cuprinde toate activităţile implicate în provocarea, analiza, specificatia şi validarea cerinţelor.
10 Software Engineering de Ian Sommerville
11
http://openseminar.org/se/modules/8/index/screen.do 12 Software Requirements Engineering: What, Why, Who, When, and How de
Linda Westfall
Procesul Ingineriei Cerintelor (Wiegers 2003)
Pasul de o obtine cele necesare include toate activităţile implicate în
identificarea cerinţelor părţilor interesate, in selectarea reprezentanţilor din fiecare clasă a părţilor interesate şi in determinarea nevoilor a fiecarei clase a părţilor interesate. Acest proces reprezinta pasul strângerii de informaţii din
procesul de dezvoltare a cerinţelor. Diverse tehnici pot fi utilizate pentru a obtine cerinţe, inclusiv interviuri cu părţile interesate, observaţiile ale
proceselor de lucru curent, chestionare şi sondaje, analiza produselor concurente şi analiza comparativă a industriei de practici.Cerinţele pot implica, de asemenea, studii de documentare.13
3.4 Concluzii Practicanţii trebuie să înţeleagă diferitele tipuri şi niveluri de cerinţe pentru a face o treaba buna in ingineria cerinţelor. Este nevoie de o înţelegere a
beneficiilor de a avea cerinţe bune, astfel încât resursele adecvate şi de timp sa
13http://www.westfallteam.com/Papers/The_Why_What_Who_When_and_How_
Of_Software_Requirements.pdf
fie dedicate procesului de ingineria cerinţelor pe tot parcursul ciclului de viaţă al dezvoltarii de software. A trata corect ingineria cerinţelor necesită o abordare
interdisciplinară, care consideră că are nevoie de mai multe grupuri de părţi interesate. Aceasta necesită, de asemenea, expertiză în diferite abilităţi de
ingineria cerinţelor, inclusiv cerinţele de suscitare, analiza cerinţelor, specificarea cerinţelor, cerinţele de validare, de gestionare a cerinţelor.
4. Niveluri formale de specificare a cerintelor
“ ... limbaje, tehnici ¸si unelte matematice pentru specificarea¸ si verificarea sistemelor” [Clarke & Wing, 1996]
Sau, mai in detaliu: “un set de unelte si notatii,
cu o semantica formala,
folosite pentru a specifica neambiguu cerintele unui sistem,
care admite demonstrarea de proprietati ale acelei specificatii
si demonstrarea corectitudinii unei implementari ın raport cu acea
specificatie”
[Hinchey & Bowen, Applications of Formal Methods, 1995]
Tendinta lumii contemporane este de a se baza din ce in ce mai mult pe
procesare si transmitere de informatie, lucru care duce la aparitia unei noi forme comunicationale (comunicatiile tehnice).
Analiza formala se refera la o gama larga de tehnici bazate pe diverse instrumente care, utilizate de sine statator sau combinat, pot explora, depana si verifica specificatiile formale ale sistemelor si astfel predictiona, calcula si
rafina comportamentul acestora.
Metodele formale se pot define ca fiind un set de intrumente si tehnici bazate pe logica formala si modelare matematica, utilizate pentru verificare
cerintelor si a specificatiilor pentru sistemele de calcul si software.
Acestea pot fi utilizate pentru modelarea comportamentelor sistemelor si
pentru verificarea matematica a proiectarii sistemului, si daca aceasta corespunde functionalitatii acestuia si nivelului de siguranta cerut. Specificatiile, modelele si verificarile se pot realize prin diverse tehnici cu un
grad diferit de rigoare.
O specificatie este formala daca este scrisa dupa o sintaxa bine definita
(limbaje de programare) si daca este insotita de o semantica riguroasa. Specificatiile formale descriu ce se asteapta sa faca sistemul, nu precizeaza si cum. Aceste specificatii pun in evident ambiguitatile existente in specificatiile
neformale, ambiguitati care daca ar fi descoperite tarziu, ar avea efecte neplacute, daca nu dezastruoase14.
Clasificarea gradului de rigoare:
a) Nivel 1: Specificatii formale pentru întreg sistemul sau pentru parti
ale acestuia. Aceasta implica utilizarea logicii matematice sau a limbajelor de specificare care au o semantica formala pentru specificarea sistemului. Acest lucru se poate realiza pe mai multe nivele de abstractizare. De exemplu, un
nivel poate enunta cerintele abstracte ale sistemului pe când un altul descrie o implementare de o maniera algoritmica.
b) Nivel 2. Specificatii formale pe unul sau mai multe nivele de
abstractizare si o verificare a faptului ca specificatia detaliata implica cea mai abstracta specificatie. Metodele formale depasesc nivelul 1 prin dezvoltarea
probarii ca cele mai concrete nivele implica logic nivelele orientate pe cea mai abstractizata forma a proprietatilor.
c) Nivelul 3. Controlul probarilor formale prin probatorul de teoreme
mecanizat. Este cea mai riguroasa forma de aplicare a metodelor formale. Se utilizeaza un probator de teoreme, semiautomat, pentru a se asigura ca
probarile sunt valide.
Logica formală va face referire la metode de raţionare valide în virtutea formei lor şi independente de conţinutul lor. Aceste metode se bazează pe
discipline care cer în mod explicit enumerarea tuturor ipotezelor şi a paşilor raţionamentului. În completare, fiecare pas al raţionamentului trebuie să fie o instanţiere a unui număr mic de reguli de inferenţă permis. Cele mai riguroase
metode formale aplică aceste metode pentru a da substanţă raţionamentului utilizat, pentru justificarea cerinţelor sau a altor aspecte ale proiectării sau
implementării sistemelor, fie complexe, fie critice. Atât în logica formală cât şi în metodele formale obiectivele vor fi aceleaşi: reducerea apelării intuiţiei umane în evaluarea argumentelor. Aceasta va însemna reducerea
acceptabilităţii unui argument pentru o calculaţie care poate, în principiu, să fie verificat mecanic, prin aceasta ajungându-se la înlocuirea unei subiectivităţi inerente a revizuirii proceselor cu un exerciţiu repetabil.
Dinamica erorilor in software [dupa John Rushby, SRI]
• 20-50 erori/kloc inainte de testare, 2-4 dupa
• examinarea formala a codului poate reduce erorile inainte de testarede cca 10 ori
Studiu de caz pe 10kloc timp real, distribuit:
• verificare si validare: 52% cost (57% timp)
• din acesta, 27% cost in examinare, 73% in testare
14
C.L. Heitmeyer, D. Mandrioli (editors): Formal Methods for Real-Time Computing. Volume 5 of Trends in Software, John Wiley & Sons, 1996.
• 21% pt. 4 defecte in testarea finala, din care 1 de proiectare
• eliminarea erorilor la examinari detaliate ale codului: de 160 de ori mai
eficienta decat la testare
In momentul in care si cerintele si specificatiile sunt formalizate, un
argument formal poate fi construit care dovedeste ca specificatiile formale satisfac cerintele formale. Acest argument formal nu dovedeste ca sistemul este valid: daca cerintele sunt invalide, la fel sunt si specificatiile. Cu toate acestea,
furnizarea legaturii formale dintre cerinte si specificatii identifica rolul specific al validarii: este procesul de asigurare a cerintelor nu a specificatiilor, si documenteaza precis ce se doreste sa se faca cu sistemul.
Argumentul formal ofera deasemenea oportunitatea sa elimine, prin analiza, a unei clase mari de erori potentiale care pot fi prezente sau care se
pot ridica in dezvoltarea specificatiilor15.
5. Calitatea analizei de sistem
Qualitity Assurance(QA) asigura ca proiectele vor fi finalizate bazate pe
niste termeni specificati la inceputul proiectului, cum ar fi standarde de
programare si functionalitati care trebuiesc implementate fara a avea defecte
sau cu un numar cat mai mic de defecte. Se monitorizeaza si se incearca o
imbunatatire a procesului de dezvoltare de la inceputul testari si se asigura
finalizarea proiectului in timp util. Se realizeaza acest pentru a se prevenii
15
A. van Lamsweerde: “Formal specification: a roadmap”. Proceedings of ICSE - Future of Software Engineering Track 2000: 147-159, 2000
viitoarele probleme care pot aparea pe parcusul procesului de dezvoltare si
eventual rectificate dupa o iteratie de testare.
QA imbunatateste are ca scop imbunatatirea proiectelor de la inceputul.
Acesta ajuta ca sa se faca o comunicare mai buna intre echipele de dezvoltare
si se incearca o intelegere a problemelor si a conceptelor noi care apar in acest
proiect, de asemenea ofera timp pentru a se seta un mediu de testare si de
configurare. O alta idee testarea incepe odata ce planul de testare a fost scris
este reviziuit si sunt aprobate functionalitatile in functie de documentatie.
Testarea soft este orientata pe dectectie. Se examineaza sistemul sau
aplicatia in mediu controlat si conditionat. Se are in vedere ca lucrurile
evidente care ar putea merge gresit cand acestea ar trebui sa functioneze
corect.
Softul de calitate este un soft fara bug-uri si sa fie livrat la timp si sa
nu se depaseasca bugetul sa se indeplineasca toate criteriile specificate si sa
poate fi ulterior modificata sau reparata.
Verificarea se realizeaza pentru a se preveni ulterioarele probleme care
pot aparea inainte ca sa inceapa perioada de testare. Aceasta presupune citirea
documentatilor, intalnire intre membri echipei, realizarea unui plan, discutarea
tehnologiei folosite discutarea specificatiilor etc. Validarea are loc atunci cand
se incepe testarea si reprezinta testarea propriuzisa care gaseste erori in
functionalitate ori in specificati.
Planul de testare(Test plan) reprezinta documentul prin care se
specifica modul in care se va face testarea si obiectivele testari: nivelul de la
care se incepe(Teste unitare etc), toolurile folosite in testare mediul in care se
vor face testele, modurile prin care se vor aborda erorile teste automate, teste
manuale.
Cazurile de testare(Test Case) este documentul care descrie actiunile
vor avea loc pentru a testa o anumita functionalitate. Se va testa input-ul,
actiunile care au loc, evenimentele care au loc ce se astepta de la
functionalitate respectiva pentru a determina buna functionare. Un Test case
va trebui sa contina urmatoarele atribute pentru a putea fi unul valid: un
numar unic de identificare, numele test case-ului, obiectivele, conditiile de
testare/setup-ul, datele de intrare care trebuiesc, pasi are trebuiesc urmati si
rezultatele asteptate.
Un cod bun(Good software coding) este acela prin care se respecta
cerintele, nu contine bug-uri si este usor de citit se poate imbunatati usor este
usor de citit si este usor de intretinut.
Un bun design(Good Design) are o structura usor de citit, usor de
inteles, usor de modificat si usor de intretinut. Sa se poate modifica in functie
de noile functionalitati care se vor si implementate de catre end useri.
Un bun testar este acela care poate sa aiba o viziune foarte buna asupra
proiectului, sa se gandesca la erorile erori la care sa nu te fi gandit, sa fie
transant in gasirea bug-urilor, si sa fie atent la detali si la calitatea produselor.
Un ciclu a unei aplicatii soft incepe atunci cand aplicatia a fost pentru
prima oara conceputa pana cand si se termina ciclul atunci cand numai este
folosita. Acesta include asptecte cum ar fi concepte initiale, o analiza a
cerintelor, un design de functionalitati, un design intern, creerea unei
documentati cu planurile despre dezoltarea aplicatiei a unui plan de testare,
alegerea unei tehnologi de dezvoltare, integrare, testare, managementul
update-urilor, retestarea si alte aspecte.
Dupa ce s-au creat documentele se vor face o inspectie asupra
documentatilor pentru a se cauta defectele si problemele care apar in general:
erori de specificare, planul de testare, cazurile care vor fi testate. Acest
procedeu are loc pentru a ajuta la gasirea defectelor si a le repare inca din faza
de proiectare. In general acest pas are loc cu 3 tipologii de oameni un
moderator, un cititor, un om care ia notite aceste sesiuni sunt obligatori sa
aiba loc.
Tipuri de testare functionala
5.1.Black-box
Black-box este testarea care se ocupa cu testarea functionalitatilor
externe fara a intra in verificarea codului. Testarea Black-box este de mai
multe tipuri:
1. Equivalence partioning. Fiecare aplicatie se poate imparti pe mai
multe multimi de valori care pot fi introduse/selectate. Din fiecare partitie se
va lua cate un reprezentant si se vor face testarea asupra campului respectiv.
Ex. Un program care are ca intrari valabile valori intrebi de la 100 la
200.
Se vor imparti in urmatoarele categori pentru a fi testat. Valori mai
mici de 100, valori mai mare de 200, valori in intervalul 100 si 200, o intrare
numerica de tip Real(cu virgula), o intrare non-numerica. Pentru fiecare partie
se vor nota rezultatele obtinute.
2. Testarea valorilor marginale(Boundary value analysis). Se vor
testa toate valorile care sunt la marginea intervalelor de testare.
Ex. Un program care are ca intrari valabile valori intrebi de la 100 la
200.
Se vor testa valorile 99,100,101 si 199,200,201 chiar valori reale
99.99,100.1 si 199.9,200.1
3. Decision table testing. Se va face o tabela de adevar cu toate
posibilitatile care pot avea loc. Se foloseste algebra booleana pentru a se face o
optimizare a ciclurilor de testare.
4. Testarea starilor de tranzitie. Se vor face o un graf cu toate
starile posible care pot aparea la un moment dat pe utilizari aplicatiei.
Tranzitia este o schimbare de
Stare si este declansata de un
Eveniment. Evenimentele sunt
declansate de intrarile
sistemului si pot declansa o
iesire sau o tranzitie.
5. Use case. Se
descrie comportamentul unui
sistem si cum raspunde acesta
la cerintele care vin din afara
sistemului. Descrierea de
interactiuni se face prin actori
care pot fi utilizatori sau un
sistem. Process flows reprezinta
procesul pe care vrea un utilizator sa il realizeze. Se vor creea tipologi pentru a
fi testate aplicatia care s-ar potrivi pentru testarea aplicatiei. Fiecare tipologie
vor avea urmatoarea proprietati behavoir pattern, teluri, aptitudini, atribute si
mediu social.
social.
5.2.White-testing
In acest gen de testare sunt testate informati legate de softul cu care a
fost construit, folosit pentru a se putea face cazurile de testare, codul si
designul. Se bazeaza pe identificarea structuri a sistemului sau a softului.
Bucle de control
Test coverege este o unitate prin care se masoara daca un cod a fost
testat sau prin toate ramurile de decitie care pot avea loc. Cu ajutor Flow
charturilor si a buclelor de control se poate verifica daca un cod a fost
strabatut pe toate ramurile.
Tipuri de testare non-functionala
Load test se foloseste un test pentru a incarca systemul.
Performance testing se astepta un comportament normal.
Stress testing se face o testare cu un numar foarte mare de utilizatori
pentru a se vedea cum se comporta sistemul.
Volume testing
Usability testing se verifica sa se vada daca un utilizator poate sa opereze
cu sistemul proiectat.
Storage Testing
Maintainability se verifica daca se pot face introducere de noi functii care
sa aiba un impact redus asupra sistemului si asupra altor
functionalitati.
Reliability
Portability se verifica pe diferite sisteme de operare sa vada cum
reactioneaza sistemul.
Recovery se verifica comportamentul in cazul unei erori
Security (Confidentiality, Integrity, Authentification, Authorization,
Availability, Non-repudiation/ Audibility)
Accesibility se verifica cum poate fi folosite de oameni cu dezabilitati.
Nivele de testare
Nivele de testare sunt urmatoarele:
o Unit testing
o Integration Testing
o System Testing
o Acceptance Testing
o
Bibliografie :
Wikipedia
Practica vara -Qualitance
6. Documente cu cerinte
Analiza cerintelor este prima etapa în procesul de parametrizare si
customizare a unui sistem software. Cele mai multi indivizi denumesc acest
proces de parametrizare si customizare proces de implementare, desi
implementarea este doar o faza a acestuia. Analiza cerintelor cuprinde
operatiuni care au ca scop determinarea necesitatilor unei companii, tinând
cont de eventualele divergente ce pot aparea din partea diferitelor parti in
cauza, cum ar fi beneficiari sau utilizatori. Analiza cerintelor este esentiala
pentru succesul unui proiect de dezvoltare. Cerintele trebuie sa fie aplicabile,
masurabile, testabile, legate de nevoile de bussiness sau de oportunitatile
identificate, mai mult decat atat, definite la un nivel de detaliu suficient pentru
ca sistemul sa poata fi proiectat. Activitatea specifica acestei etape este
extragerea (captura) cerintelor. [1]
6.1 Extragerea cerintelor
Analiza cerintelor poate fi un proces lung si dificil în care mai multe
competente sunt implicate. Noile sisteme aduc schimbarea mediului si a
relatiilor dintre oameni, de aceea este important de a se identifica toate partile
interesate, sa se ia în considerare toate nevoile lor si sa se asigure ca acestea
înteleg implicatiile noului sistem. Analistii pot folosi mai multe tehnici pentru a
obtine cerintele de la client. În trecut, aceasta se efectua prin tinerea de
interviuri, de ateliere de lucru, sau intocmirea de liste de cerinte.
Mai multe tehnici moderne includ dezvoltarea de prototipuri si de use-cases. În
cazul în care este necesar, analistul va folosi o combinatie a acestor metode de
stabilire a cerintelor exacte ale partilor interesate, astfel încât sistemul sa
corespunda nevoilor de afaceri. [1]
Sursele cerintelor:
studiul de piata
studiul de fezabilitate
domeniul in care va opera produsul
actorii (stakeholders)
procesul business
Tehnici de extragere a cerintelor
- Studiul produselor software existente
- Interviuri cu actorii - Scenarii - Prototipuri ale viitorului sistem
- Intalniri cu grupuri de persoane - Observarea directa [3]
6.2. Tipuri de cerinte utilizator
2 categorii de cerinte utilizator:
Cerinte operationale
Constrangeri
6.2. 1. Cerinte operationale (Capability requirements)
Descriu functionalitatile pe care utilizatorii le asteapta de la sistem.
Sunt calificate cu valori ca:
Viteza:
Capacitatea
Precizia
6.2.2. Constrangeri
Probleme ale analistilor si consultantilor de implementare
Posibile probleme cauzate de ingineri si programatori în timpul analiza
cerintelor sunt: Personalul tehnic si utilizatorii finali pot avea diferite
vocabulare. În consecinta, ei pot în mod eronat considera ca se afla în in
perfect acord pâna la livrarea produsului finit. Inginerii si programatorii pot
încerca sa faca cerintele sa se supuna unui sistem existent sau model, mai
degraba decât sa dezvolte un sistem pe nevoile specifice ale clientului. Analiza
poate fi deseori efectuata de ingineri programatori sau, mai degraba de
personal cu abilitati si cunostinte in domeniu pentru a întelege un client în
mod corespunzator. [1]
Solutii posibile
O solutie pentru problemele de comunicare a fost de a angaja specialisti în
afaceri sau in analiza de sistem. Tehnicile introduse în anii 1990, cum ar fi
prototipurile, Unified Modeling Language (UML), use-cases, etc. sunt destinate
de asemenea ca solutii la problemele întâmpinate cu metodele anterioare. De
asemenea, o noua clasa de simulatoare de aplicatii sau instrumente de definire
a aplicatiilor au intrat pe piata. Aceste instrumente sunt concepute pentru a
construi un pod de comunicare care sa umple decalajul dintre utilizatori si
consultanti si, de asemenea, pentru a permite aplicatiilor sa fie "test
marketed", înainte de a fi definite efectiv. [1]
Cerinte de interfata
o Interfete de comunicare o Interfetele hardware
o Interfete software o Interfata utilizator
Cerinte de calitate
o Portabilitatea
o Adaptabilitatea o Disponibilitatea o Securitatea
o Siguranta in functionare o Standarde
Cerinte de planificare a proiectului – care se includ in Planul de
Management al Proiectului Software [3]
6.3. Documentul cerintelor utilizator (URD)
- lista cerintelor
- o descriere a mediului de functionare a viitorului sistem (hard+soft) - interfetele produsului software cu sistemele externe (mediul) - rolurile diferitelor categorii de utilizatori ai viitorului sistem:
Documentarea Cerintelor
Un mod traditional de documentare a cerintelor a fost Lista de cerinte stil
contract. Într-un astfel de sistem complex listele de cerinte pot ajunge la sute
de pagini. [2]
Definirea de Obiective masurabile
Cele mai bune practici recomanda utilizarea listelor de cerinte create
doar ca indicii, si folosirea în mod repetat a intrebarii "de ce?" pâna cand este
descoperit adevaratul scop. Partile interesate si implementatiorii pot apoi sa
conceapa teste pentru a masura nivelul in care fiecare obiectiv a fost atins
astfel. Astfel de obiective se schimba mai lent decât lista lunga de cerinte
specifice, dar care nu pot fi masurabile. Odata ce un mic set de obiective
critice masurabile a fost stabilit, se pot dezvolta rapid prototipuri si scurta
fazele de implementare iterative. Astfel, se poate livra efectiv partilor interesate
obiective de valoare cu mult înainte de a se ajunge la jumatatea proiectului . [1]
Sablonul pentru URD definit in standardele ESA (European State Agency)
a. Abstract
b. Tabel Continut
c. Document Status Sheet Status sheet pentru control
configuratie.
d.
Inregistrati ale schimbarilor in
documente de la problema
anterioara
Lista de schimbari in documente.
1. Introduere
1.1 Scop Citire intentionata
1.2 Tinta Indentificarre produs dupa nume
1.3 Lista definitii Definitiile tuturor termenilor ,
acronime
1.4 Lista refefinte Toate documentele aplicabile
1.5 Overview Scurta descriere a restului de URD
2. descrirere generala
2.1 Perspectivele produsului Relatie cu alte sisteme
2.2 Capabilitati generale Capabilitatile principale
2.3 Constarngeri generale Motivele pentru care acestea exista
2.4 Caracteristicile utilizatoruluiu Caracteristicile diferitilor useri
2.5 Descriere environment descriere environment operational
2.6 Asumari si dependente Asumarile care se iau
3. Cerinte specificae
3.1 Cerintele capabilitatilor Lista de remarci generale asupra
cerintelor
3.2 Cerintele constrangerilor Lista de remarci generale asupra
cerintelor
Document Status Sheet
Este o pagina de inceput care da informatii despre document. Identificarea
(nume, tip, versiune) este unica si permite localizarea documentului in baza de date.
Pentru un modul de cod sursa informatia de stare este inclusa sub forma de
comentariu in antetul modulului:
// Document Title: xxxx // Document Identification: Ext/tools/ext.cxx
// Original Author: nnnn // // Change history:
// Version: Date: Author: Description: // 1.0 2/ 5/2006 nnnn Creation.
// 1.1 15/ 9/2006 nnnn Adapted for DVT 2.0 event interface. // 1.2 22/ 9/2006 yyyyy Maximum test changed // 1.3 5/12/2006 wwww Font size adapted
Document Status Sheet
Document Title Software Requirements Document
Document Identification Projectname/SRD/DOC/1.2
Author A.Jansen
Document Status draft / internally accepted / approved
Document History
Version Date Reason for change
1.0 4/8/1997 First version
1.1 17/9/1997 Review 11/8/1997, RID 1-5
1.2 22/10/1997 New version of URD (1.1)
Depends on Documents
Projectname/URD/DOC/1.1
Descrierea mediului operational
Produse software sunt uneori dezvoltate pentru a fi utilizate in cadrul unui
sistem – sistemul obiect. De exemplu:
Baza de date pentru un spital
Un compilator pentru un sistem de dezvoltare
Aplicatie de control al unui proces
Pentru intelegerea locului/rolului noului produs in mediul sau operational este
necesar:
Sa se descrie mediul operational
Sa se defineasca interfetele sale cu sistemele externe
Sa se defineasca rolurile utilizatorilor [3]
Rolurile utilizatorilor
o caracteristicile fiecarui grup de utilizatori
o operatiile care sunt permise/interzise fiecarui grup o profilul de utilizare tipic pentru fiecare grup ( de ex. frecventa de
utilizare a sistemului)
In URD fiecare cerinta trebuie sa:
aiba un identificator unic – folosit pentru urmarirea cerintei in celelalte
faze
fie marcata ca esentiala sau nu
aiba o prioritate
fie marcata ca stabila sau instabila
aiba sursa precizata
6.4. Cerinte impuse descrierii Cerintelor Utilizatorilor
Clare. Verificabile.
Complete. Precise
Realizabile
Identificarea partilor interesate
Un nou accent major în anii 1990 a fost pus pe identificarea partilor interesate.
Este din ce în ce mai recunoscut faptul ca partile interesate nu sunt limitate la
compania care va deveni beneficiarul noului sistem. Alte parti interesate pot fi:
• acele organizatii care se integreaza (sau ar trebui sa se integreze)
orizontal cu organizatia beneficiara
• orice sistem de back office sau care este folosit la nivel organizational
• Senior management. [1]
Probleme ale partilor interesate
Utilizatorii insisi pot inhiba colectarea cerintelor:
• Utilizatorii care nu înteleg ceea ce doresc sau utilizatorii care nu au o
idee clara a cerintelor.
• Utilizatorii nu vor sa se angajeze la o serie de cerinte în scris
• Utilizatorii care insista asupra noilor cerinte dupa ce costul si programul
de implemnetare au fost stabilite
• Comunicarea cu utilizatorii este lenta
• Utilizatorii care trebuie de multe ori sa participe la interviuri si sunt în
incapacitate de a face acest lucru
• Utilizatorii nu sunt din punct de vedere tehnic avansati
• Utilizatorii care nu înteleg procesul de implementare
• Utilizatorii care nu stiu despre tehnologia prezenta
Acest lucru poate duce la situatia în care cerintele utilizatorilor sa fie in
continua schimbare, chiar si atunci când sistemul a fost început a fi
implementat. [1]
6.5. Metode de specificare a cerintelor utilizator
Limbajul natural – este ambiguu
Limbaj natural structurat Tabele, formule Diagrame de flux de date
Elemente de modelare UML: cazuri de utilizare, diagrame de cazuri de utilizare pentru delimitarea sistemului in mediul sau de operare, diagrame de secventa pentru descrierea scenariilor de utilizare a
sistemului, diagrame de stari [2]
Diferite sabloane pentru documentul de definire a cerintelor precum si exemple
pot fi gasite la: http://www.jiludwig.com/Template_Guidance.html.
La mijlocul anilor 1980, prototipurile au fost percepute ca o solutie la problema
Analizei Cerintelor. Prototipurile sunt machete ale sistemului final. Machetele
permit utilizatorilor de a vizualiza o aplicatie care nu a fost înca implementata.
Prototipurile ajuta utilizatorii în a avea o idee despre cum va arata sistemul
fara a astepta ca sistemul sa fie implementat. Odata cu introducerea de
prototipuri, s-au remarcat imbunatatiri majore în comunicarea dintre
utilizatori si implementatori. Vizualizarea initiala a permis rafinarea cerintelor
si a dus la mai putine modificari mai târziu si, prin urmare, a redus
considerabil costurile totale. Cu toate acestea, în urmatorul deceniu, în timp ce
s-au dovedit a fi o tehnica utila, prototipurile nu a rezolvat problema cerintelor:
Managerii, odata ce vor vedea un prototip, pot intelege greu ca finalizarea
proiectului va dura ceva timp. Implementatorii de multe ori se simt obligat sa
foloseasca patch-uri ale prototipului în sistemul real, pentru ca se tem sa nu
"piarda timpul" luind-o de la inceput. Prototipurile ajuta in principal la luarea
deciziilor de dezvoltare si proiectare a interfetei cu utilizatorul. Cu toate
acestea, ele nu pot spune ce cerinte au fost initial. Implementatorii si
utilizatorii finali se pot concentra prea mult pe interfata si prea putin cu privire
la producerea unui sistem care serveste în procesele de bussiness. Prototipurile
sunt folositoare pentru definirea interfetei pentru utilizator, dar nu sunt la fel
de utile pentru procesele de prelucrare in masa sau asincrone care pot implica
actualizari complexe a bazei de date si / sau a calculelor. Prototipurile pot fi
realizate prin schite draft fie prin aplicatii cu functionalitati sintetizate. Schitele
draft adesea elimina elementele de culoare din versiunea finala (de exemplu, se
utilizeaza o paleta de culori in tonuri de gri) în cazurile în care software-ul final
este de asteptat sa aiba design grafic aplicat. Aceasta ajuta la prevenirea
confuziei cu privire la aspectul final vizual. [1]
[1] http://www.gmc-group.ro/index.php/ro/articole/63-analiza-cerintelor
[2]http://andrei.clubcisco.ro/cursuri/3ip/curs/3.1_Definirea_cerintelor/3.1a_
Definirea%20cerintelor%20utilizator.doc
[3] http://bigfoot.cs.upt.ro/~dan/curs/fis/Cap3_Cerinte.pdf
7.Evoluția cerințelor software
Observațiile si regulile relevante pentru planificarea și gestionarea
evoluției sistemelor software au fost identificate pentru prima oară în timpul
studiului evoluției sistemului OS/36070 și a altor sisteme intre anii 1968-1985.
Mai recent, odată cu colaborarea între ICL, Logica si Matra BAe Dynamics,
proiectul FEAST/1 (1996-1998) a putut sa confirme, rafineze și să extindă
rezultatele anterioare. Acestea au putut fi posibile datorită analizei de date
asupra evoluției sistemelor respective, VME Kernel, sistemul „FW Banking
Transaction” și sistemul de apărare Matra-BAe. Date referitoare la două
sisteme în timp real Lucent Technologies au devenit, de asemenea, disponibile
în această perioadă. Larg vorbind, evoluția pe termen lung a acestor sisteme a
fost echivalentă din punct de vedere calitativ, deși variază în detaliu. Toate
acestea în ciuda aplicațiilor foarte diferite și a domeniilor de implementare în
care aceste sisteme au fost dezvoltate, au evoluat, operat si au fost folosite,
precum și a seturilor de date care au fost comparate. În plus, rezultatele au fost
compatibile și susțineau pe scară largă pe cele din anii „70. Astfel de
similitudini in comportamentul evoluționar pe termen lung a unor sisteme cu
diferențe pe scară largă și care aparțin unor domenii de dezvoltare diferite de-a
lungul unei perioade de evoluție rapidă a tehnologiei sugerează că acest
comportament obervat și regulile derivate nu sunt cauzate in principal de
tehnologia folosită. Comportamentul global, observat din exteriorul procesului,
pare să fie determinat, cel puțin în parte, de alte forțe. Astfel este posibila
extinderea concluziilor pentru obținerea unor rezultate de validare largă în
domeniul software, și în cele din urmă în evoluția organizatorică și a afacerilor.
Cele opt legi a evoluției software formulate de-a lungul anilor „70 și ‟80
sunt listate în Tabelul 1. Enunțurile primelor trei legi au apărut din
continuarea unor studii a evoluției IBM OS/360 și a succesorului său IBM
OS/370. Aceste rezultate au fost consolidate în anii ‟70 de rezultatele studierii
evoluției altor sisteme. Suport adițional a venit din partea studiului ICL din anii
‟80, dar a primit niște criticism legat de insuficiența sprijinului statistic venit de
la Lawrence. Această listare prezintă modificări minore care reflectă perspective
noi dobândite în timpul proiectului FEAST/1.
De-a lungul anilor, legile au fost recunoscute treptat drept folositoare,
oferind informații utile pentru înțelegerea procesului software și și-au gasit locul
în programele de studiu a unui număr de universitați de inginerie software.
Suport adițional pentru sașe din cele opt legi a fost acumulat odată cu
modelarea și analiza datelor obținute de la colaboratorii proiectului FEAST/1.
Cele două legi rămase n-au fost nici susținute, dar nici negate de către probele
obținute de la studiile recente, din cauza absenței unor date relevante. Ele par,
totuși, să reflecte un adevăr de bază a cărei natură precisă mai trebuie
clarificată.
Nr. Nume Enunțul legii
I
1974
Schimbarea
Continuă
Sistemele E-type trebuiesc adaptate constant, altfel
acestea devin progresiv mai putin folositoare in uz
II
1974
Creșterea
complexitații
Odată cu evoluția unui sistem E-type, complexitatea
sa crește cu exceptia în care se dorește mentinerea
sau reducerea ei
III
1974
Auto-reglementare Evoluția globală a sistemelot E-type este auto-
reglementabilă
IV
1978
Conservarea
Stabilitații
Organizaționale
Media eficace a ratei de activitate globală a unui
sistem E-type care evoluează tinde sa rămână
constant de-a lungul duratei de viață a produsului,
asta daca mecanisme de feedback nu sunt ajustate
în mod corespunzător
V
1978
Conservarea
Familiaritații
În general, creşterea incrementală şi rata de creştere
pe termen lung a sistemelor E-type tinde să fie în
declin
VI
1991
Creșterea
Continuă
Capabilitatea funcțională a sistemelor E-type trebuie
crescută în mod continuu pentru a satisface
utilizatorii pe întreaga durată a sistemului
VII
1996
Scăderea Calitații Cu excepția cazului adaptărilor riguroase asupra
mediului operațional, calitatea sistemelor E-type vor
parea în declin
VIII
1996
Sistem de
Feedback
(recunoscut în
1971, formulat în
1996)
Procesele de evoluție E-type sunt sisyeme feedback
multi-nivel, multi-loop și multi-agent
Din moment ce aceste legi nu sunt independente, nu ar trebui
considerate ca fiind liniar ordonate. Astfel, numerotarea din Tabelul 1 are doar
semnificație istorică. Problema dependenței și a relației dintre legi este în
prezent subiectul unor investigații suplimentare și gîndurile inițiale cu privire la
această temă sunt acum disponibile. Dacă această dezvoltare va reprezenta un
succes, ar trebui să raspundă criticilor principale la care legile au fost supuse
de-a lungul anilor.
Principiul Incertitudinii – Rezultatul în lumea reală e execuției
oricărui software E-type este în mod inerent incert cu aria precisă a
incertitudinii de asemenea necunoscută
Acest principui, formulat pentru prima oară la sfârșitul anilor ‟80 ca o
observație de sine stătătoare, este vazută acum drept o consecință directă a
legilor. Aceasta afirmă că rezultatul execuției unui program E-type nu este
absolut predictibilă. Probabilitațile unei execuții nesatisfăcătoare pot fi mici,
dar garanția unor rezultate satisfăcătoare nu poate fi dată indifirent cât de
impecabile au fost operațiile anterioare. Această declarație poate suna
alarmistă sau trivială dar nu este o problemă. Un fapt dovedit este un fapt și
prin acceptarea acestui lucru, identificarea surselor incertitudinii și luarea
unor măsuri adecvate, chiar si un risc mic mai poate fi redus.
Discuția asupra incertitudinii software s-a bazat pe ipoteze. Există, de
asemenea, și alte surse de incertitudine în comportamentul sistemului dar
probabilitatea de a contribui la eșecul sistemului este mică în comparație cu
cele rezultate din ipoteze invalide încorporate în cod sau documentație. Drept
urmare nu sunt luate în considerare.
În general, rezultă că:
a. La developarea unei aplicații de calculator și a sistemelor asociate, se
estimează și se documentează probabilitatea schimbării în diferitele
zone de domeniu ale aplicației și răspândirea lor în întregul sistem
pentru simplificarea detectarea ulterioară a ipotezelor care pot deveni
invalide ca rezultat al schimbării
b. Urmărirea capturii prin orice mijloc, ipotezele făcute în cursul
dezvoltării sau schimbării programului
c. Stocarea informațiilor necesare într-o formă structurată, legate,
eventual, la posibilitatea unei schimbări ca la punctul “a”, pentru a
facilita detectarea în revizuirea periodică a oricăror ipoteze care au
devenit invalide
d. Validarea tuturor ipotezelor de către persoane fizice cu obiectivele
necesare și cunoștințele contextuale în minte
e. Revizuirea bazei de date ce conține ipotezele pe categorii, așa cum am
identificat la “c”, și asa cum sunt reflectate în structura bazei de date,
la intervale ghidate de probabilitatea sau așteptările schimbării sau
declanșate de evenimente
f. Developarea și apovizionarea ustensilelor sau metodelor pentru a
facilita punctele de mai sus
g. Echipe separate de validare și implementare pentru a îmbunătați
controlul ipotezelor
h. Garantarea accesului echipelor la specialiști în domeniu
În final, așa cum am mai notat, Principiul Incertitudinii reprezintă o
consecință a caracterului nelimitat a domeniului operațional și de aplicație a
sistemelor E-type și că totalitatea ipotezelor cunoscute înglobate în acesta
trebuie sa fie finite. Cu toate acestea, multă înțelegere este atinsă, oricât de
complet am urmari recomandarile enumerate, rezultatul execuției unui sistem
E-type va fi mereu incert. Nu există scapare. Aderare la recomandări, însă,
reduce comportamentul neadecvat și eșecurile surpriză, ba chiar evitarea lor.
Și atunci când au loc, sursa problemei poate fi localizată rapid și remediată.
Având în vedere penetrarea tot mai mare a computerelor în activitatea umană,
fie ea organizațională sau individuală, sau în rolurile sociale sau economice
criticale, orice astfel de reducere a șanselor de eșec este importantă și nu
trebuie ignorată.1617
8. Etape ale fazei de specificare
Specificarea este una dintre cele mai importante faze in ingineria
software. Aceasta reprezintă aducerea soluţiei alese la o formă standardizată ,
detaliată comunicabilă în scopul obţinerii repetabilităţii produsului. In faza de
specificare :
- trebuie clarificate conceptele prin intelegerea domeniului problemei
(problema ca sistem);
- soluţia va avea caracter general, va fi adaptată in domeniul problemei si
robustă la modificari.
Institute of Electrical and Electronics Engineers (IEEE)
menţioneaza un set de bune practici in elaborarea specificaţiilor cerintelor
pentru software numite in lucrare SRS (Software Requirements Specifications).
- 16 http://www.ieee.org
- “Rules and Tools for Software Evolution Planning and Management”,
M. M. Lehman, Department of Computing, Imperial College, London
17
Lucrarea isi propune să „descrie continutul si calitătile unor specificatii bine
executate si prezinta cateva exemple de SRS” .
Consideraţii pentru producerea unor specificaţii de calitate
Informaţiile care ar trebui luate în considerare la scrierea unui SRS sunt
urmatoarele:
a) Natura specificatiilor pentru software;
b) Mediul SRS;
c) Caracteristicile unui bun SRS;
d) Pregătirea în comun a specificaţiilor;
e) Evolutia SRS;
f) Prototipare;
g) Integrarea designului în SRS;
h) Includerea cerinţelor proiectului in SRS.
Natura SRS
SRS este un set de specificaţii pentru un anumit produs software,
program, sau un set de programe care efectuează anumite funcţii într-un
mediu specific.SRS poate fi scris de către unul sau mai mulţi reprezentanţi ai
furnizorului, unul sau mai mulţi reprezentanţi ai clientului, sau de ambele
parti implicate.
Problemele de bază care scriitorul SRS (e) se adresă sunt următoarele:
1)Funcţionalitate. Ce ar trebui să facă software-ul?
2)Interfeţe externe. Cum interacţionează software-ul cu oamenii,
hardware-ul sistemului, alte componente hardware şi alte programe?
3)Performanţă. Care este viteza, disponibilitatea, timpul de raspuns,
timpul de refacere a diferitelor funcţii ale software-ului, etc?
4)Atributele.Care sunt caracteristicile de portabilitate, corectitudine,
întreţinere, securitate, etc?
5)Constrângerile de design impuse la implementare.
Mediul SRS
Este important să se ia în considerare rolul pe care SRS-ul îl joacă în
planul de proiect total.Software-ul poate conţine în esenţă, toate
funcţionalitatea proiectului sau poate fi parte dintr-un sistem mai mare. În
acest ultim caz există de obicei un SRS, care va specifica interfeţele dintre
sistem şi partea de software, şi va aplica cerinţele de funcţionalitate şi
performanţă externe pentru software. Acest lucru înseamnă că specificatiile :
1) ar trebui să definească în mod corect toate cerinţele software-ului.
2) nu trebuie să descrie orice desen sau detalii de implementare. Acestea
ar trebui să fie descrise în etapa de design a proiectului.
3) nu trebuie să impună constrângeri suplimentare cu privire la
software. Acestea sunt specificate în mod corespunzător în alte documente
cum ar fi un plan de asigurare a calitatii softwareului.
Prin urmare, un set de specificaţii scris în mod corespunzător limitează
gama de modele viabile, dar nu se specifică un anumit design.
Caracteristicile unui SRS de calitate
Un set de specificaţii ar trebui să fie
1) corect;
2) fără ambiguitaţi;
3) complet;
4) conform;
5) marcat cu niveluri de importanţa şi stabilitate;
6) usor de verificat;
7) modificabil;
8) usor de urmarit.
Un SRS este corect dacă, şi numai dacă, fiecare cerinţă prevăzută în
cuprinsul său poate fi îndeplinită de software.
Un SRS este lipsit de ambiguitate, dacă, şi numai dacă, fiecare cerinţă
declarata in acesta are o singură interpretare. Cerinţe sunt adesea scrise în
limbaj natural (de exemplu, în engleză). Limbajul natural este în sine
ambiguu. O modalitate de a evita ambiguitatea inerentă limbajului natural
este aceea de a scrie SRS-ul într-un limbaj specific pentru descrierea
specificaţiilor cerinţelor software.
Un SRS este completă dacă, şi numai dacă, aceasta include următoarele
elemente:
a) Toate cerinţele semnificative cu privire la funcţionalitate,
constrângerile de performanţă, de proiectare, atribute, sau interfeţe externe. În
special, orice cerinţe impuse de o specificaţie de sistem, ar trebui să fie
recunoscute şi tratate.
b) Definiţia răspunsurilor software-ului pentru toate categoriile
realizabile ale datelor de intrare în toate clasele de situaţii realizabile. Este
important să se precizeze răspunsurile atat la valori de intrare valide cat şi
nevalide.
c) Etichetari complete şi referinţe la toate figurile, tabelele,
diagramele din SRS şi definiţia tuturor termenilor şi unităţilor de măsură.
Conformitatea se referă la coerenţa internă. Dacă un SRS nu este in
acord cu unele documente de nivel superior, cum ar fi specificaţiile cerinţelor
de sistem, atunci nu este corect.
Un SRS este clasat cu niveluri de importanţă şi / sau stabilitate, dacă
fiecare cerinţă are un identificator pentru a indica fie importanţa sau
stabilitatea acestei cerinţe.
Un SRS este verificabil dacă, şi numai dacă, fiecare cerinţă declarata este
verificabilă. O cerinţă este verificabilă dacă, şi numai dacă, există un proces
eficient cu care o persoană sau maşină poate verifica faptul că produsul
software îndeplineşte cerinţa. În general, orice cerinţă ambiguă nu este
verificabilă.
Un SRS este modificabil dacă, şi numai dacă, structura şi stilul sunt de
aşa natură încât orice modificare a cerinţelor poate fi făcută cu uşurinţă,
complet, şi în mod constant în timp ce structura şi stilul sunt menţinute.
Un SRS este usor de urmărit în cazul în care originea fiecăreia din
cerinţele sale este clară şi în cazul în care facilitează afilierea fiecărei cerinţe în
dezvoltările viitoare.
Pregătirea în comun a specificaţiilor
Procesul de dezvoltare software ar trebui să înceapă cu acordul intre
furnizor şi client în privinta a ceea ce trebuie să facă software-ul. Acest acord,
ar trebui să fie pregătit în comun sub forma unei SRS. Acest lucru este
important, deoarece, de obicei, nici clientul, nici furnizorul nu este calificat
pentru a scrie singur un SRS bun.
Evolutia SRS
Un SRS ar putea fi necesar să evolueze pe masura ce progreseaza
dezvltarea produsului software. Poate fi imposibil să specifice unele detalii în
momentul în care proiectul este initiat (de exemplu, poate fi imposibil să se
definească toate formatele pe ecran pentru un program interactiv în timpul
fazei de cerinţe). Modificări suplimentare pot surveni daca deficienţele,
neajunsurile, iar inexactităţile sunt descoperite în SRS.
Folosirea de prototipuri
Prototipurile sunt utile pentru următoarele motive:
a) clientul este mai înclinat să vadă prototipul şi poate reacţiona la el mai
usor decât prin a citi şi a reacţiona la SRS. Astfel, prototipul oferă feedback
rapid.
b) prototipul afişează aspecte neprevăzute in comportamentul sistemelor.
Astfel, se produc nu numai răspunsuri, dar, de asemenea, noi întrebări. Acest
lucru ajută la completarea cu succes a specificatiilor.
c) Un SRS bazat pe un prototip are tendinţa de a suferi mai puţine
schimbări în timpul dezvoltării, astfel scurtand timpul de dezvoltare.
Integrarea designului în SRS
SRS-ul ar trebui să specifice ce funcţii trebuie să fie efectuate, pe ce date
pentru a produce ce rezultate la ce locatie si pentru cine. SRS ar trebui să se
concentreze pe serviciile care urmează să fie implementate.
Exemple de constrângeri de proiectare valide: cerinţele fizice, cerinţele de
performanţă, standarde de dezvoltare software, standardele de asigurare a
calităţii. Prin urmare, cerinţele ar trebui să se precizeze din punct de vedere
pur extern. Atunci când se utilizează modele pentru a ilustra cerinţele,
modelul indică doar comportamentul exterior, şi nu specifică un design.
Includerea cerinţelor proiectului in SRS
SRS-ul ar trebui să abordeze produsul software nu, procesul de
producere a produsului software.Cerinţele de proiect reprezintă o înţelegere
între client şi furnizorul despre detalii contractuale legate de producţia de
software şi, prin urmare, nu ar trebui să fie incluse în SRS elemente cum ar fi
a) cost;
b) termenele de livrare;
c) procedurile de raportare;
d) metodele de dezvoltare software;
e) asigurare a calităţii;
f) validarea şi criteriile de verificare;
g) procedurile de acceptare
Parţile constituente ale unui set de specificaţii de cerinţe software
Desi un SRS nu trebuie să urmeze această schiţă sau să folosească
numele date aici pentru componentele sale, un SRS bun ar trebui să includă
toate informaţiile prezentate mai jos.
Cuprins
1. Introducere
1.1 Scopul
1.2 Domeniul de aplicare
1.3 Definiţii, acronime şi abrevieri
1.4 Referinţe
1.5 Prezentare
2. Descriere generală
2.1 Perspectivele produsului
2.2 Funcţiile produsului
2.3 Caracteristici pentru utilizare
2.4 Constrângeri
2.5 Ipoteze şi dependenţe
3. Cerinţe specifice
Anexe
Index
Scopul fiecarui paragraf este evident si conduce la completarea
caracteristicilor unui set de specificatii(SRS) de calitate. Printre cele mai
importante sectiuni ale SRS-ului se afla „Cerinţele specifice” care pot avea o
varietate de forme de prezentare.
Exemplu de elaborare a specificaţiilor
Specificaţii NASPInet - un pas important spre implementare
Efotul celor de la North American Synchro-Phasor Initiative de a crea o
infrastructură de control al informatiilor, robustă, disponibilă pe scară largă,
sincronizată numita de ei NASPInet si care avea să asigure interconectarea
sistemului electric nord-american , a dus la iniţierea unui proiect de
specificaţii ale NASPInet în 2008, finanţat de catre Departamentul de Energie
(DOE) al Statelor Unite ale Americii.
Setul de specificatii emis pentru NASPInet conţine un cadru conceptual
propus pentru arhitectura sistemului NASPInet şi cerinţele funcţionale
majore aferente designului NASPInet propuse de echipa de proiect
Arhitectura NASPInet
Principalele cerinte ale NASPInet
In viziunea NASPI , NASPInet avea să fie construita în primul rând
pentru a facilita schimbul de date în timp real, sincrofazat, între entităţile
conectate. DNMTT a identificat şi a definit cinci clase diferite de date pe care
NASPInet este necesar să le suporte.
Clasa A Serviciu de date pentru feedback
Controlul stabilitatii de semnal mic, controlul puterii reactive sunt cateva
aplicatii ale acestei clase
Clasa B Serviciu de date pentru control Feed-forward
De exemplu estimatori pentru imbunatatirea operatiilor sistemului si
control.
Clasa C Serviciu de date pentru aplicatii de vizualizare
Clasa D Serviciu de date pentru analiza post-eveniment
Clasa E Serviciu de date pentru cercetare si dezvoltare
Atributele specifice acestor clase de date sunt prezentate in tabelul
urmator:
4-importanta critica
3-important
2-importanta medie
1-importanta scazuta
Organizarea specificatiilor pentru NASPInet
Cerintele functionale ale NASPInet sunt organizate in doua documente de
specificatii separate: specificatiile necesitatile functionale Data Bus (DB) si
specificatiile Phasor Gateway (PG)
Ambele documente cu specificatii au urmatorul continut:
1. Introducere
2. Arhitectura de sistem NASPInet
3. Cerinte functionale generale ale NASPInet
4. Cerinte functionale ale DB (sau PG)
5. Cerinte de integrare in sistem
6. Cerinte pentru lucrul in retea si Comunicatii
7. Cerinte de Securitate
8. Dimensionari, Performanta si Disponibilitate.
Sectiunile 2 si 3 sunt identice in ambele specificatii
Ca un atasament sunt adaugate la fiecare document 3 seturi noi de
cerinte:
9. Cerinte Hardware
10. Cerinte Software
11. Implementare si mantenanta a serviciului.
Concluzie
Realizarea si acceptarea specificatiilor pentru NASPInet marcheaza un
pas important in implementarea unei retele de schimb de date sincrofazoriale,
cu un QoS garantat si securitate sporita care sa deserveasca industria
electrica americana.
9. Structura documentului de definire a cerintelor si de specificare a
cerintelor
Documentul de specificare a cerintelor este actul official care specific a ce
se asteapta de la dezvoltatori. Acesta contine:
- lista cerintelor
- o descriere a mediului de functionare a viitorului sistem (hard+soft) - interfetele produsului software cu sistemele externe (mediul) - rolurile diferitelor categorii de utilizatori ai viitorului sistem
a. Abstract
b. Table of Contents
c. Document Status Sheet Status sheet for configuration control.
d. Document Change Records
since previous issue A list of document changes.
1. Introduction
1.1 Purpose The purpose of this particular URD and its
intended readership.
1.2 Scope Scope of the software. Identifies the product by
name, explains what the software will do.
1.3 List of definitions The definitions of all used terms, acronyms and
abbreviations.
1.4 List of references All applicable documents.
1.5 Overview Short description of the rest of the URD and
how it is organized.
2. General description
2.1 Product perspective The relation to other systems.
2.2 General capabilities The main capabilities.
2.3 General constraints Reasons why constraints exist: background
information and justification.
2.4 User characteristics The characteristics of the different user roles.
2.5 Environment description A description of the operational environment.
2.6 Assumptions and The assumptions upon which the specific
dependencies requirements (in the next section) are based.
3. Specific requirements
3.1 Capability requirements A list of all capability requirements. Note the
general remarks about requirements.
3.2 Constraint requirements A list of all constraint requirements. Note the
general remarks about requirements.
Document Status Sheet 18
Este o pagina de inceput care da informatii despre document. Identificarea
(nume, tip, versiune) este unica si permite localizarea documentului in baza de date.
Pentru un modul de cod sursa informatia de stare este inclusa sub forma de
comentariu in antetul modulului:
// Document Title: xxxx // Document Identification: Ext/tools/ext.cxx // Original Author: nnnn
//
// Change history: // Version: Date: Author: Description: // 1.0 2/ 5/2006 nnnn Creation. // 1.1 15/ 9/2006 nnnn Adapted for DVT 2.0 event interface. // 1.2 22/ 9/2006 yyyyy Maximum test changed // 1.3 5/12/2006 wwww Font size adapted \
18
http://lhcb-comp.web.cern.ch/lhcb-comp/Support/Documentation/Templates/URDTemplate.html
10. Validarea cerintelor si folosirea prototipului 19Activităţile de process pentru un produs software se impart in 4 etape:
1. Specificarea produsului software 2. Proiectarea şi implementarea propriu zisa a produsului software
3. Validare produsului software
4. Evoluţia produsului software
Etapa de specificare software este un proces de stabilire a serviciilor necesare,
cat si a costrangerilor asupra dezvoltarii si operarii sistemului.
Procesul de specificare a cerinţelor presupune:
• Studiu de fezabilitate;
• Identificarea şi analiza cerinţelor; • Specificarea cerinţelor; • Validarea ceinţelor.
Ian Sommerville, Software Engineering, 7
th edition, Chapter 4, 2004
Michael R. Lyu, Handbook of Software Reliability Engineering, IEEE Computer Society, 1996.
http://en.wikipedia.org/wiki/Verification_and_validation_(software)
Proiectarea si implementarea software este procesul de a converti specificaţiile
sistemului într-un sistem executabil.
Presupuune:
Proiectare software (Design)
• Proiectarea unei structuri software care să realizeze specificaţiile; Implementare
• Translatarea acestei structuri într-un program executabil; Activităţile de proiectare şi implementare sunt strâns legate şi deseori se
suprapun.
Activităţile procesului de proiectare:
1. Proiectare architecturală
2. Specificare abstractă 3. Proiectare a interfeţei 4. Proiectare a componentelor
5. Proiectare a structurilor de date 6. Proiectare a algoritmilor
Programare şi corectare:
Este translatarea proiectului într-un program şi eliminarea erorilor de
program.
20Programarea este o activitate personală – nu există un proces generic
de programare.
Programatorii efectuază unele teste pentru a descoperi erori în program
şi elimină aceste erori în procesul de corectare (debugging).
Ian Sommerville, Software Engineering, 7
th edition, Chapter 4, 2004
Michael R. Lyu, Handbook of Software Reliability Engineering, IEEE Computer Society, 1996.
http://en.wikipedia.org/wiki/Verification_and_validation_(software)
Validare software:
Verificarea şi validarea (V & V) trebuie să arate dacă un sistem software
este conform cu specificaţiile şi dacă respectă cerinţele clientului.
Implică procese de verificare, revizuire şi testare a sistemului.
Testarea sistemului implică execuţia sistemului într-un caz de utilizare
cu date reale.
Este deasemenea cusoscuta sub forma termenului de “Controlul de
calitate al produsului software”
Validarea verifica daca designul produsului satisface sau se potriveste
intentiilor sale de utilizare (cazul cel mai fericit: construirea unui produs
correct). Aceasta este facuta prin testarea dinamica si alte forme de revizie.
Potrivit “Capability Maturity Model” (CMMI – SW v1.1), verificarea
presupune alte doua definitii:
1. procesul de evaluare software pentru a determina daca
produsul unei faze de dezvoltare specificate satisface conditiile impuse la inceputul fazei. [Standardul IEEE – 610 ].
2. procesul de evaluare software in timpul sau la sfarsitul procesului de dezvoltare pentru a determina daca satisface cerintele. [Standardul IEEE – 610 ].
Cu alte cuvinte, validarea asigura ca produsul chiar indeplineste
cerintele utilizatorului si ca speficatiile au fost corecte in prima faza, in timp ce
verificarea asigura ca produsul este construit potrivit cerintelor si designului
specificat.
Validarea asigura ca “este construit produsul potrivit”. Verificarea
asigura ca “este construit cum trebuie”. Validarea confirma ca produsul va
indeplini functia pentru care a fost construit.
Din perspective testarii:
- greseala: functie eronata sau lipsa in cod
- esec: manifestarea unei greseli in timpul executiei - greseala de functionare: potrivit specificatiilor, sistemul nu
indeplineste functionalitatea respective
Din perspectiva cominitatii de simulare si modelare, definirea validarii,
verificarii si acreditarii sunt similare:
Validarea este procesul de determinare al gradului de acuratete pentru
reprezentarea in lumea reala din perspectiva functionarii deliberate a datelor
asociate modelarii, simularii sau federatiei de modelare si simulare.
Acreditarea este certificatul formal prin care modelul sau simularea este
acceptata spre utilizarea specifica.
Verificarea este procesul prin care se asigura ca implementarea si datele
asociate acesteia reprezinta precis descrierea conceptuala si specificatiile
prgramatorului pentru modele si simulari sau federatii de modele si simulari.
21
Etape de testare
1. Testarea componentelor sau a unităţilor
• Componentele individuale sunt testate independent; • Componentele pot fi funcţii sau obiecte sau grupuri coerente ale
acestor entităţi.
2. Testarea sistemului
• Testarea sistem în ansamblu (ca un întreg). Este importantă testarea unor cazuri concrete de utilizare.
3. Testele de acceptaţă
• Testarea cu datele clientului pentru a verifica dacă sistemul
indeplineşte cerinţele clientului
Fazele testării:
Ian Sommerville, Software Engineering, 7
th edition, Chapter 4, 2004
Michael R. Lyu, Handbook of Software Reliability Engineering, IEEE Computer Society, 1996.
http://en.wikipedia.org/wiki/Verification_and_validation_(software)
În ingineria software, un prototip este folosit atât pentru validarea cât si
pentru identificarea cererilor utilizatorilor, pentru verificarea solutiei de
proiectare si a oferi baza dezvoltarii ulterioare a proiectului de sistem
informatic. Apelarea la utilizarea prototipului este consecinta faptului ca un
model functional este mai usor de înteles de catre viitorul utilizator decât un
set de diagrame însotite de documentatie.
Prototipul functional presupune proiectarea sistemului, realizarea
primului prototip functional, verificarea masurii în care raspunde cererilor
formulate de utilizator si rafinarea acestei prime solutii, prin dezvoltari viitoare
care adauga noi functionalitati pâna la obtinerea variantei finale a sistemului.22
Ian Sommerville, Software Engineering, 7
th edition, Chapter 4, 2004
Michael R. Lyu, Handbook of Software Reliability Engineering, IEEE Computer Society, 1996.
http://en.wikipedia.org/wiki/Verification_and_validation_(software)