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.

Structuri de program Flow Chart

1. Secvente

2. Selectie

3. Bucla

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)