TEMA 5: MODELE ALE CICLULUI DE VIA A SI

DEFINIREA NOIUNII
Indiferent de numarul i numele etapelor ciclului de viata, este mai importanta ordinea i modul in care se parcurg etape, ceea ce n literatura de specialitate se trateaza sub numele de model al ciclului de via a SI. Ordinea etapelor n cadrul CV este secventiala, ceea ce nu este confirmat de realitate. Revenirile la etapele anterioare sunt frecvente. Uneori etapele se pot derula iterativ, alteori iterativ, dar cu posibilitatea revenirii la etapele anterioare sau uneori, unele etape, putndu-se derula n paralel.

MODELUL CASCAD CV
model clasic, de referinta, Definirea cerintelor asigur trecerea, mai mult teoretica de la o etapa Analiza la alta, n ordine secventiala fazele sunt structurate pe Proiectarea i realizarea activitati si subactivitati Implementarea fiecare etapa se sfarseste atunci cand se termina tot lucrul Testarea asupra ei, inclusiv elaborarea documentatiei complete necesare cercetarii urmatoarei etape modelul se aplica la nivel de sistem punct slab

Utilizarea si intretinerea

MODELUL CASCAD A CV
Avantaje: Un control total asupra fazelor, sunt ordonate si previzibile, prin evidentierea clara a ariei de intindere a fiecarei etape sau subcomponente ale ei; Este usor de nsuit de membrii echipelor de analiza i proiectare, inclusiv de cei noi, cu o experien mai putin vast; Fiecare etapa este insotita de o documentatie perfect structurat i complet. Dezavantaje: Se ntrzie mult cu obinerea rezultatelor. Utilizatorii isi pot expune pretentiile doar dupa ce sistemul s-a finalizat totalmente. Iar daca se intampla ca utilizatorul sa nu-si expuna corect cerintele sau sa si le schimbe in timpul elaborarii sistemului, beneficiarul primeste un sistem care nu satisface cerintele acestuia??? Nu este deschis schimbarilor ce pot interveni pe parcurs.
Ideea de baza a acestui model este regasita si in altele (V, X, fantana arteziana etc).

MODELUL n V A CV
o alta varianta a modelului cascada se introduc conceptele de sistem si componente latura din stanga, parcurs descendent, contine etapele Definirea Validare cerintelor propriu-zise latura din dreapta, se parcurge ascendent, realizindu-se Proiectare Testare sistem sistem verificarile i validarile elementelor create se face diferena intre verificare si validare Proiectare Testare utilizatorul este implicat n partea subsisteme subsisteme (componente) (componente) superioara a V-ului arhitectura sistemului este surprins n partea de mijloc partea inferioara se refer la faza de realizare Codificare/asamblare componente modelului tot i se reproseaza ca lasa validarea prea tarziu, dupa ce sistemul s-a construit

MODELUL INCREMENTAL A CV
permite livrarea sistemului pe componente sau n ntregime definirea cerinelor i analiza se execut la nivelul ntregului sistem descompunerea proiectului n subproiecte o metod de tip top-down (ceea ce i implic cunoaterea cerinelor pentru ntregul sistem nc din faza de nceput, chiar dac ulterior se vor rezolva doar pri din el) adugarea unei pri presupune testarea a tot ce a fost realizat pn n acel moment (ceea ce poate duce la modificri multiple ale componentelor realizate printre primele)
sistemul poate fi livrat i pe componente realizate la perioade scurte de timp sistemul final poate fi realizat de mai multe echipe sau persoane datorit modularizrii Iui imposibilitatea aplicrii lui n toate cazurile, uneori neexistnd posibilitatea descompunerii ntregului eforturile de integrare a componentelorn ntreg sunt destul de mari (vorbindu-se chiar despre o aa-zis testare multipl de sisteme, cu trimitere la faptul c de fiecare dat cnd se adaug o nou component, sistemul poate fi considerat unul nou).

Avantaje:

Dezavantaje:

MODELUL INCREMENTAL al CV

MODELUL SPIRAL A CV
Prototip - un sistem sau un sistem partial finisat, care este construit rapid pentru a exploara anumite aspecte ale cerintelor fata de sistem i care nu este considerat sistem gata de livrarea finala la utilizator. Cerinte model clasic dezvoltare iterativ riscurile se evalueaz la nivel ImplemenAnaliza de iteraie tare Start produsul soft este pus repede Evaluare prototip 1 n exploatare avnd ns posibiliti Evaluare limitate prototip2 Testare se rafineaz soluia prin Proiectare ... adugarea de noi funcionaliti Evaluare Stop prototip n pn la obinerea variantei finale a SI modelul cascada se regaseste la Realizare fiecare iteratie

MODELUL SPIRAL al CV
Avantaje: Modelul spirala pune accentul pe analiza i proiectare; Are loc colaborarea intens cu beneficiarul n timpul crerii SS; Solutiile tehnice sunt propuse la nivel de prototip; Fiecare ramura a spiralei corespunde crearii unui fragment sau versiuni a SI; aici se precizeaza scopurile si caracteristicile proiectului; se determina calitatea i se planific sarcinile pentru cel de-al doilea prototip (ram al spiralei). La elaborarea iterativ a SI sarcinile care nu au fost realizate n cadrul unei iteraii, pot fi ndeplinite n urmtoarele iteraii, scopul fiind: prezentarea cat mai repede utilizatorului a unui sistem apt sa realizeze ceva, prin aceasta avnd posibilitatea concretizarii cerintelor utilizatorului. Principala problem a modelului spiral - determinarea momentului trecerii la iteraia urmtoare. Pentru soluionarea acestei probleme este necesar o planificare riguroas a fiecrei iteraii, adic orice iteraie are granie temporale clar definite. Trecerea se face conform planului, chiar dac nu au fost ndeplinite toate sarcinile. Planul se elaboreaz n baza datelor statistice, din cadrul proiectelor anterioare sau n baza experienei membrilor echipei de dezvoltare. Standardul RM recomand alegerea modelului de dezvoltare n dependen de complexitatea sistemului, de termenele stabilite de realizare ale proiectului, metoda principal fiind cea iterativ. Alte modele: RUP, RAD etc.

TEMA 6: METODE DE DEZVOLTARE A SI

MODELE ale SI
Un model - o abstractizare a realitii - un sistem teoretic sau material care reproduce un sistem complex ce nu poate fi cercetat n stare naturala.
Modelul reprezint viaa subiectiv dar adevrat a realitii, vzut de un anumit observator. Astfel, n modelare nu exist adevr absolut; modelarea presupune abstracie i aducerea n atenie numai a unor aspecte ale realitii studiate i anume acele aspecte care prezint interes pentru modelator. n decursul dezvoltrii a unui SI se construiesc mai multe modele cu scopul de a-i putea studia comportamentul i a-i modifica in consecinta unele dimensiuni sau caracteristici ale prototipului SI. Caracterul abstract al unui model permite uurarea nelegerii sistemului studiat. Modelul reduce esenial complexitatea sistemului studiat, permitnd simularea acestuia, reprezentarea i reproducerea componentelor sale.

METODE DE DEZVOLTARE
La dezvoltarea SI se utilizeaz: metode, tehnici, instrumente, procedee de lucru. Metodele de dezvoltare a SI reprezint modul n care analitii de sistem, programatorii i alte persoane implicate realizeaz procesul de analiz, proiectare realizare i implementare a SI. Ingineria programarii (sau a soft-ului) - un domeniu al informaticii ce se ocupa cu determinarea celor mai bune soluii, metode, procedee i instrumente care s conduc la elaborarea unui produs-program, a.i. acesta sa satisfac toate cerinele impuse prin specificaia de definire.

METODA STRUCTURAT
Metoda structurat este considerat funcional-orientat.
Sistemul informaional i informatic se structureaz n baza funciilor sale Are la baz analiza funcional - fiecare funcie identificat se subdivide ierarhic n subfuncii, continund n aceast manier pn se ajunge la componente suficient de mici astfel nct acestea s poat fi programate cu uurin Se utilizeaz metoda Jackson structura unui sistem soft deriv din structura datelor. Metoda structurat conduce la construirea a dou tipuri de modele: Modelul funcional: SADT (Structured Analysis and Design Technique), DFD
(Data Flow Diagram), JSD (Jackson System Development),

Modelul datelor: ERD (Entity-Relationship Diagrams ).

PRINCIPII ALE METODEI STRUCTURATE

Principiul divide et impera
principiu folosit la rezolvarea problemelor complexe divizindu-le intr-o multime de probleme mici, independente, usor de a fi analizate si solutionate

F1

Principiul structurarii ierarhice principiu de organizare a

componentelor problemei mari sub forma unei structuri ierahice arborescente, adaugand noi detalii la fiecare nivel ierarhic F111

F11

F12

F112

F121

F122

F123

Principiul structurarii datelor

care are la baza ideea de structurare si organizare ierarhica a datelor

METODA OO
Metoda se consider orientat spre date: se acord atenie deosebit structurii datelor (n ultimul timp i funciilor); sistemul informaional i cel informatic este perceput ca o structur de obiecte autonome, ce se organizeaz i coopereaz ntre ele; un obiect are un anumit comportament, definit prin ansamblul operaiilor (serviciilor) pe care le poate efectua; datele i prelucrrile prin care este implementat acest comportament sunt ncapsulate (mascate) i sunt inaccesibile celorlalte obiecte; fiecare obiect poate participa la compunerea altor obiecte mai complexe; fiecare obiect poate interveni n mai multe funcii sau scenarii funcionale diferite.

Metoda OO conduce la construirea a 3 tipuri de modele:

Modelul static are rolul de a descrie obiectele care intervin n problema de rezolvat i relaiile dintre ele. Modelul reprezint descrierea structurii statice a obiectelor, claselor de obiecte, a operaiilor i atributelor, precum i a relaiilor dintre ele. Modelul dinamic are rolul de a descrie strile pe care le poate avea un obiect i evenimentele la trecerea dintr-o structur n alta. Modelul dinamic descrie interaciunea dintre obiecte (prin schimb de mesaje) i este focalizat pe aspecte ce se schimb n timp. Modelul funcional/comportamental are rolul de a descrie prelucrrile i fluxurile de date. Modelul funcional prezint transformrile valorilor datelor, preciznd sursa i destinaia lor.

PRINCIPII SPECIFICE METODEI OO Abstractizarea o descriere a problemei sau a unui obiect la un anumit nivel

de generalizare ce ne permite s ne concentrm atenia asupra aspectelor cheie ale problemei/obiectului, fr detalii. Incapsularea numit i ascunderea de informaii. Asigur faptul c obiectele nu pot schimba starea intern a altor obiecte n mod direct (ci doar prin metode puse la dispoziie de obiectul respectiv); doar metodele proprii ale obiectului pot schimba starea acestuia. Fiecare tip de obiect expune o interfa pentru celelalte obiecte care specific modul cum acele obiecte pot interaciona cu el. Polimorfismul permite folosirea unui obiect n locul altui obiect (o subclas in locul unei superclase). Sau este abilitatea de a redefini metode pentru clasele derivate. Ex: Pentru clasa Pasre, definim metoda Micare. Dac clasele Stru i Lebd vor extinde clasa Pasre, ele pot redefini metoda Micare (fiecare n felul sau Struul se mic prin mers/alergare, iar Lebda prin not/mers/zbor). Motenirea organizeaz i faciliteaz polimorfismul i ncapsularea, permind definirea i crearea unor clase generale care sunt deja definite acestea pot s-i extind comportamentul lor fr a fi nevoie de redefinirea aceluiai comportament. Aceasta se face de obicei prin gruparea obiectelor n clase i prin definirea de clase ca extinderi ale unor clase existente. Agregarea proprietatea obiectelor de a putea incorpora alte obiecte. Aa dar, "datele" continute ntr-un obiect pot fi nu numai date simple, ci si obiecte. Se pot astfel crea obiecte cu structuri din ce in ce mai complexe.

TEMA 7:

ETAPA DE ANALIZ

DEFINIREA NOIUNII
Analiza presupune gsirea i concretizarea aciunilor corecte, n baza cercetrii cerinelor fa de sistem i a problemei Analiza nu const n cutarea cilor de soluionare a problemei. n cadrul etapei de analiz a problemei principalul scop const n crearea i dezvoltarea modelului de analiz. Acesta prezint datele,funciile i comportamentul sistemului informaional, toate acestea reflectndu-se n cerine. Activitile specifice etapei de analiz trebuie s avanseze de la informaii eseniale ctre detalii de implementare pentru SI.

 Se formuleaz problema; Se colecteaz cerinele fa de viitorul SI de la potenialii utilizatori ai acestuia; Se descriu funcionalitile de baz care definesc comportamentul Sistemului Informaional i n baza crora se va dezvolta SI; Se modeleaz funcionalitatea sistemului folosind diagramele FD; Se formuleaz cerinele funcionale i nefuncionale fa de SI; Se evideniaz nivelele de arhitectur ale SI; Se planific la nivel nalt dezvoltarea SI (estimndu-se duratele etapelor i a ntregului proiect i costurile aproximative a lucrrilor); Se poate construi diagrama ER n baza descrierilor anterioare, ca un model conceptual al entitilor despre care se dorete pstrarea datelor.

ACTIVITI SPECIFICE ETAPEI DE ANALIZ

FORMULAREA PROBLEMEI
La nceputul studiului se formuleaz esena problemei. Frecvent diferii participani la proiect i pun diferite scopuri. Participarea utilizatorilor viitorului sistem la formularea i specificarea cerinelor reduce cu mult riscul prbuirii proiectului. Formularea clar a problemei va reduce apariia neclaritilor printre persoanele cointeresate n elaborarea SI. Problema poate fi formulat fiind utilizat textul liber sau conform unei structuri prestabilite:
care este problema propus spre soluionare? cum va influena activitatea ntreprinderii implementarea SI? pe ce se bazeaz soluionarea problemei?

Se formuleaza obiectivele. Se evideniaz aria de ntindere a problemei.

DESCRIEREA I MODELAREA PROCESELOR DE ACTIVITATE

OBS: Pentru excluderea nenelegerilor, funciile sistemului, care va fi supus automatizrii, vor fi doar cele descrise, chiar dac sistemului descris i pot fi atribuite i un ir de alte funcii. n orice organizaie pot fi evideniate 3 tipuri de procese:
de management procese care gestioneaz activitatea ntreprinderii (ex: managementul strategic) operaionale procese care asigur funiile de baz ale organizaiei i conduc la generarea profiturilor (ex: producere, marketing, vnzari); adiionale procese care deservesc procesele de baz (ex: contabilitate, gestiune resurse organizaie, asigurarea cu tehnologii informaionale).

Orice proces de activitate poate fi descompus n subprocese.

Modelarea grafic a activitilor se face folosind:

Notaii structurate: modelul datelor i modelul funcional Notaii OO: modelul funcional, static i dinamic.

DOCUMENTE SPECIFICE ETAPEI DE ANALIZ

Se va exemplifica n baza RT 38370656 - 002:2006, anexa 1.

1. Plan de management al proiectului

Prile care particip la elaborare mputernicirea i responsabilitatea prilor, inclusiv organizaiile externe Conductorii proiectului. Managementul elaborrii i implementrii proiectului Dirijarea cu subantreprenorul, dac exist Completarea cu cadre i resurse materiale Determinarea etapelor de baz. Termenele de elaborare, implementare, ncepere a exploatrii Componena proiectului i determinarea complexitii lui Modul testrii de calificare a sistemului software Sanciunile, specificaiile necesare, de proprietate, drepturile de garanie i de licen, baza juridic a proiectului Instruirea personalului.
se coordoneaz cu beneficiarul i se aprob de ctre furnizor; poate fi realizat n Microsoft Project.

2. Plan calendaristic de realizare a proiectului

DOCUMENTE SPECIFICE ETAPEI DE ANALIZ

3. Concepia sistemului
studiul cadrului juridico-normativ de funcionare a domeniului de activitate, respectiv al sistemului; examinarea structurii organizaionale, care realizeaz managementul domeniului respectiv; determinarea pachetului de documente, care circul n domeniul respectiv; analiza nivelului de informatizare n domeniul respectiv; determinarea funciilor sistemului; determinarea entitilor despre care se dorete pstrarea datelor, a identificatorilor lor i a atributelor; determinarea fluxurilor informaionale, a circulaiei lor i a problemelor integrrii cu alte sisteme; elaborarea propunerilor privind actualizarea cadrului juridico-normativ (n caz de necesitate - elaborarea proiectelor de acte juridico-normative noi), modificarea structurii organizaionale i/sau crearea noilor structuri organizaionale, crearea noilor documente i/sau modelelor noi de documente deja existente; elaborarea propunerilor privind structura tehnologic a sistemului, precum i privind problemele securitii informaionale.

DOCUMENTE SPECIFICE ETAPEI DE ANALIZ

4. Sarcina tehnic
generaliti, referine; terminologie i abrevieri; destinaia sistemului; modelul activitilor sistemului informaional supus automatizrii: procesele de baz ale obiectului automatizat; roluri specifice proceselor de activitate; algoritmii/scenariile de ndeplinire a proceselor; cerine funcionale fa de sistem: modelul funcional al sistemului; cerine fa de funciile sistemului; cerine fa de sistem n ntregime: cerine privind securitatea i protecia; cerine privind integritatea informaiei; cerine fa de hardware i canalele de comunicaie; fiabilitatea sistemului; modul de testare i primire; cerine fa de documentaie.

DOCUMENTUL CU CERINTE
Documentul de cerine este exprimarea oficial a ceea ce se cere de la dezvoltatorii sistemului. Trebuie s includ att definiii ale cerinelor utilizator ct i specificaii ale cerinelor de sistem.
Cerinele utilizator sunt exprimri de nivel nalt a ceea ce trebuie s fac sistemul. Cerinele utilizator trebuie scrise n limbaj natural, eventual folosind tabele i diagrame. Cerinele de sistem trebuie s descrie funciile oferite de sistem.

NU este un document de proiectare. Pe ct este posibil, trebuie s exprime CE trebuie s fac sistemul i nu CUM trebuie s fac.

EXEMPLE
Obiectiv pentru SI:
Sistemul trebuie s fie uor de utilizat de casierii magazinului. SI trebuie organizat astfel nct erorile de utilizare s fie minimizate.

Cerin funcional:
SI trebuie s-i permit casierului s nregistreze toate vnzrile de produse (cash, card) SI trebuie s-i permit casierului s nregistreze returnrile produselor SI trebuie s-i permit casierului s se autentifice i s-i autorizeze accesul la date

Cerin nefuncional:
Casierii trebuie s poat folosi funcionalitatea sistemului dup un total de dou ore de nvare. Dup aceast perioad numrul mediu al erorilor fcute de casieri nu trebuie s depeasc dou pe zi.

??? SI pentru nregistrarea contractelor de asigurare a automobilelor

TEMA 8: ETAPA DE PROIECTARE

DEFINIRE I ETAPE
Proiectarea reprezint a activitate creativ, care asigur corectitudinea activitilor planificate n cadrul etapei de analiz, ndeplinind principalele cerine formulate. Dezvoltarea SI sau modernizarea unui SI se efectueaz n civa pai: 1. Descrierea structurii organizaiei (cum este?) 2. Analiza modelului organizaiei (analizam cum este) 3. Elaborarea structurii i arhitecturii SI (cum trebuie s fie?) 4. Elaborarea planului de trecere a cum este? n cum trebuie s fie? 5. Implementarea celor planificate i construirea SI. Modelul de analiz se transform n model de proiectare, prezentndu -se arhitectura SI, inndu-se cont de componenta hard pentru SI, reprezentnd datele SI, funciile acestuia, componentele i interfeele care realizeaz dialogul sistem -utilizator. De asemenea se proiecteaz logica fiecrei componente a SI.
! Procesul de proiectare nu este deterministic: diferii proiectani pot construi modele diferite pentru soluia unei probleme.

Activiti specifice acestei etape:

Proiectarea arhitecturii SI Proiectarea logicii SI Proiectarea BD a SI Proiectarea interfeelor SI.

PROIECTAREA ARHITECTURII SI
Arhitectura sistemului informatic = entitile mari ale sistemului i interaciunile dintre acestea. Se definete ca fiind tehnologiile/instrumentele folosite, cu specificarea ansamblului de date, procese, interfee i componente de retea folosite. Adic se va cerceta infrastructura, mediul, aplicaiile i datele SI. Proiectarea arhitecturii ncepe cu alegerea tipului retelei i a protocolului de comunicatii, urmat de proiectarea distribuirii aplicatiilor i a datelor n SI.
Ex: dac vom avea arhitectura de tip client-server prezentarea datelor se face de ctre aplicaia client, printr-o interfa grafic, n timp ce aplicaia server asigur accesul la date
Interfata (butoane, elemente grafice) Componente responsabile de accesul la date (logica SI i servicii tehnice)

BD

Trebuie s se in cont, c accesul la date se face att prin intermediul componentelor responsabile de logica SI, Componentele responsabile de serviciile tehnice (precum identificarea, autentificarea utilizatorului sistemului) Pentru fiecare component software se descrie ct mai detaliat posibil detaliile interne ale acesteia: Structurile de date pentru fiecare obiect de date. Detalii algoritmice pentru fiecare prelucrare din component. Interfaa de acces la toate operaiile componentei.

COMPONENTELE ARHITECTURII SI

PROIECTAREA LOGICII SI
Se efectueaz n baza modelelor elaborate la etapa de analiz. n modelul SI vor intra doar acele funcii care vor fi supuse automatizrii, mai nti fiind cercetate funcionalitile care sunt responsabile de arhitectura de baz a sistemului. Pentru elaborarea modelelor se vor utiliza notaiile (structurate sau OO) care s-au utilizat la etapa de analiz. Se va proiecta contextul i apoi toate detaliile, evideniind subsistemele i funciile de baz a SI. Deasemenea se vor descrie algoritmii de baz responsabili de ndeplinirea principalelor funcii ale SI. Algoritmii pot fi descrii n limbaj natural sau grafic, deasemenea folosind notaii grafice specifice celor dou metode. Dac se aplic metoda OO se vor aduga modele care reflect dinamica obiectelor.
! La proiectarea componentelor se va urmri independena funcional a acestora.

PROIECTAREA DATELOR
Se efectueaz n baza modelului conceptual realizat n cadrul etapei de analiz, construind astfel modelul logic al datelor. Pot aparea entiti noi n scopul normalizrii BD. Se completeaz cu atributele necesare entitile de date. Dac se aplic metoda OO modelul datelor se completeaz cu metode, care sunt evideniate din modelul dinamic. Definirea corect a structurilor de date influeneaz: complexitatea componentelor software, complexitatea fluxului de control, eficiena prelucrrilor.

PROIECTAREA INTERFEELOR SI
Activitatea cea mai dificil (n sensul divergenelor care se pot nregistra ntre client i dezvoltatori) i cea mai consumatoare de timp. Unele studii - programarea interfeelor (UI) reprezint aprox. 30-90% din totalul liniilor de cod scrise pentru softul SI. Pentru multi utilizatori interfaa este SI!!! Proiectarea corect, conform cerinelor utilizatorului i ct mai simplu a interfeelorutilizator - impune percepia asupra calitii software-lui.

PROIECTAREA INTERFEELOR SI
Interfaa asigur interaciunea dintre SI i utilizatorul acestuia. HCI - Human-Computer Interaction = interaciunea om-calculator.
! n vest HCI e o profesie aparte, care se nva n universiti, studenii devenind specialiti n HCI.

Prile componente a HCI sunt: omul/utilizatorul, calculatorul i interaciunea dintre acetia. O interfa-utilizator bun este acea interfa pe care utilizatorul nu o observ. El pur i simplu o utilizeaz liber n scopul soluionrii necesitilor sale, dar nu se gndete ce buton s apese. Interfa transparent, deoarece utilizatorul se uit prin ea la sarcinile realizate. Pentru a realiza o interfa eficient, care face lucrul cu softul plcut, este necesar s fie cunoscute cerinele utilizatorului. Esena modelrii interfeei-utilizator const n crearea de prototipuri pentru imaginile care vor aprea pe ecran.

ELEMENTE ALE INTERFEELOR

Formulare - conine opiuni sau informaii necesare folosirii eficiente ale softului, dar deasemenea poate recepiona i comenzi de la utilizator. Formularul conine: Elemente de contol: etichete, text-box-uri, combo-box-uri, butoane Meniuri: asigur accesul la comenzi de nivel mai nalt, comenzi care uneori sunt comune mai multor (sub)formulare. Comenzile meniului pot fi afiate ntro ordine uzual utilizatorului (spre ex ca i n aplicaiile Windows: File, Edit, View etc.) Astfel se creaz modelul comportamental al interfeelor, se definesc obiectele de interfa i mecanismele de control, apoi se revizuiete i se reface (dac este cazul) design-ului interfeei.

ELEMENTE ALE FORMULARULUI PENTRU CULEGEREA DATELOR

DOCUMENTE SPECIFICE ETAPEI DE PROIECTARE

Proiectul tehnic

Introducere Referine Terminologie i abrevieri Descrierea tehnologiei i metodelor de realizare Descrierea arhitecturii, componentei hardware, a sistemului software i a elementelor lui Descrierea modelului de interaciune a elementelor Descrierea structurilor de datelor Descrierea algoritmilor de prelucrare a datelor Descrierea structurii interfeei pentru utilizator

RECOMANDARE
Toate artefactele construite n cadrul etapelor de analiz i proiectare trebuie s fie uor de neles. Ele trebuie s permit comunicarea ntre diferite pri implicate n dezvoltarea SI: programatori testeri personal responsabil de ntreinere Artefactele care in de cerine trebuie s fie clare i clientului.

CALITATEA PROIECTRII
Poate fi definit de atributele de calitate FURPS (acronim pentru modelul de clasificare a cerinelor):

Funcionalitate: - setul de capabiliti/dimensiunea sistemului - generalitatea funciilor oferite - securitatea sistemului n ansamblu Utilizabilitate: - estetic, factorul uman - consisten - documentare, reacie Fiabilitate (Reliability): - robusteea, frecvena i severitatea defectelor - acurateea rezultatelor la ieire - timpul mediu ntre defectri - abilitatea de recuperare din defect - previzibilitatea programului

Performan: - viteza de prelucrare/timpul de rspuns - consumul de resurse - volumul procesrilor (throughput) - eficiena Suportabilitate: - ntreinere (extensibilitate, adaptabilitate, serviabilitate) - testabilitate - configurabilitate - instalare simpl - localizare rapid a problemelor

METRICE PENTRU PRODUSELE SOFTWARE

Se recomand a se face msurtori asupra rezultatelor etapei de analiz, proiectare, realizare i testare. Ofer un mod sistematic de evaluare a calitii pe baza unui set de reguli clar definite. Ofer inginerului software posibilitatea de a descoperi i corecta poteniale probleme n timpul desfurrii procesului software, nainte de a deveni defecte catastrofice. Metrica reprezint o funcie ce returneaz numeric gradul n care un sistem, o component sau un proces posed o careva caracteristic. Metricile ajut n evaluarea modelelor de etapa de analiz i proiectare (asupra funcionalitii oferite, dimensiunii viitorului sistem, realizabilitii acestuia, calitii specificaiilor cerinelor, asupra arhitecturii, modelului intefeelor etc), ofer indicatori ai complexitii modelului comportamental i codului surs (pentru complexitatea codului, lungimii acestuia), faciliteaz proiectarea unei testri mai eficiente (asupra defectelor nregistrate, eficacitii testrii etc.).