Etapele procesului software

Etapele procesului software

Specificare Software

Dezvoltare Software (Design si Implementare)

Validare Software

Evolutie Software

Specificare software

Etape:

Studiu de fezabilitate: Studiul decide daca sistemul propus va fie eficient din punct de vedere al costului pentru satisfacerea cerintelor si daca poate fi dezvoltat in cadrul bugetului alocat. Trebuie sa informeze daca sistemul merita sau nu sa fie facut

Capturare si Analiza Cerinte: Acesta este procesul in care se stabilesc cerintele prin observatia sistemelor existente, discutii cu utilizatorii potentiali, etc. Poate fi necesara dezvoltarea unor modele si prototipuri care pot ajuta analistul sa inteleaga sistemul ce trebuie specificat.

Specificare Cerinte: Specificarea cerintelor este activitatea care transforma informatiile colectate in faza de analiza intr-un document care defineste un set de cerinte (care poate folosi o anume notatie).

Validare Cerinte: Se verifica cerintele din punctul de vedere al realismului, consistentei si completitudinii. Erorile care sunt gasite sunt corectate in documentul de cerinte

Rezultat: document de specificare a cerintelor

Dezvoltare software (design si implementare)

2.1 Design

Descriere a structurii sistemului software ce urmeaza a fi implementat, a datelor care fac parte din sistem, a interfetelor dintre componente si uneori a algoritmurilor folosite.

Proces iterativ, deobicei fiind nevoie de mai multe versiuni

Un model foarte general de proces de design include urmatoarele activitati:

Design Arhitectural: Sunt identificate subsistemele si relatiile dintre ele.

Specificatie Abstracta: Pentru fiecare subsistem este produsa o specificatie abstracta a serviciilor si constrangerilor sub care opereaza.

Design de Interfata: Interfata fiecarui subsistem este conceputa si documentata. O interfata trebuie sa permita fiecarui subsistem sa fie folosit fara a avea cunostinta de celelalte subsisteme

Design de Componente: Serviciile sunt alocate diferitelor componente si sunt concepute interfetele dintre acestea.

Design de Baze de Date: Structurile de Date folosite sunt concepute si detaliate

Design de Algoritm: Algoritmurile folosite sunt concepute si detaliate

Acesta este un model foarte general, acesta trebuind adaptat la cazul specific din practica. De exemplu, designul de algoritm poate fi inclus in faza de implementare. Pe de alta parte, daca se folosesc componente refolosibile, acest lucru va constrange arhitectura sistemului si interfetele dintre modulele acestuia.

Metode de design

In multe proiecte, activitatea de design este un proces ad hoc.

Se porneste cu un set de cerinte, de obicei in limbaj natural, de la care se produce un design informal.

Se incepe apoi implementarea, designul fiind apoi modificat pe masura ce implementarea evolueaza.

Nu exista un control al schimbarilor (change control), astfel incat atunci cand implementarea este gata, designul va fi schimbat intr-o asemenea masura incat documentul original va reprezenta o descriere incorecta si incompleta a sistemului.

O abordare mai metodica este oferita de metodele structurate:

metode orientate pe functie: incearca sa identifice componentele functionale de baza ale sistemului: Structured Analysis, Yourdan, Merise, SSADM

metode orientate pe obiect: Booch, OMT (Object Modeling Technique) (James Rumbaugh), OOSE (Object Oriented Software Engineering) si Objectory (Ivar Jacobson);

unificarea metodelor OO prin UML (Unified Modeling Language) si Unified Process (Booch, Rumbaugh, Jacobson)

Metoda structurata include un model de proces si un set de notatii pentru representarea designului insotite de reguli si indrumari pentru folosirea acestora.

Folosirea unei metode structurate presupune producerea de modele grafice ale sistemului si a unui volum mare de documentatie. In general pentru fiecare metoda exista utilitare CASE.

Metodele structurate sunt folosite cu succes in proiecte de dimensiune mare. Ele asigura o reducere a costurilor pentru ca folosesc notatii standard si asigura ca este produsa documentatia standard pentru design.

Nu se poate spune ca o metoda este mai buna decat alta, succesul aplicarii lor depinzand de domeniul aplicatiilor in care sunt folosite.

Desi exista un mare numar de metode, ele au destule in comun. Intre tipurile de modele cele mai des intalnite se numara:

Modele structurale (arhitecturale), care prezinta componentele sistemului si interactiunile dintre acestea

Modele comportamentale, care descriu comportamentul de ansamblu al sistemului

Modelul fluxului de date (data-flow model), care descrie fluxul de date intre procese in cadrul sistemului (specifice sistemelor economice)

Modelul masinii cu stari (state machine model), care descrie comportamentul sistemului ca raspuns la evenimente externe sau interne (specifice sistemelor interactive)

Modele de date, care definesc forma logica a datelor procesate de catre sistem

Modelul entitate-legatura, care descrie entitatile din sistem si relatiile dintre acestea. Acesta reprezinta principala tehnica de descriere a bazelor de date.

Modele obiectuale (specifice tehnologiei orientate pe obiect), care identifica obiectele, clasele din care fac parte si interactiunile dintre acestea

Modele structurale, care identifica clasele si legaturile dintre ele (diagrame de clase, ierarhii de mostenire)

Modele comportamentale, care arata modul de utilizare a operatiilor din diagrama de clase: in UML diagrame de interactiune (secventa sau colaborare)

Exemplu: Diagrama de flux de date pentru inscrierea la un curs

Elipsele reprezinta entitati externe, care sunt surse sau destinatii de date.

Dreptunghiurile reprezina procese, care preiau date la intrare, le proceseaza si produc date la iesire

Sagetile reprezinta fluxuri de date, care pot fi electronice sau fizice

Dreptunghiurile fara capat reprezinta suporturi de date (data stores) precum baze de date, fisiere XML sau suporturi fizice precum hartie, dosare

Programare si testare primara (debugging)

Dezvoltarea unui program care implementeaza sistemul urmeaza in mod natural dupa procesul de design.

Desi in cazul unor tipuri de sisteme (precum cele safety-critical) faza de design este terminata pana in cele mai mici detalii inainte de implementare, de obicei aceste doua faze (design si implementare) se intrepatrund.

Utilitare CASE pot fi folosite pentru a genera scheletul programului (care cuprinde interfata cu utilizatorul) pe baza designului existent.

In mod normal, programatorii efectueaza o testare primara (debugging) a codului.

Validare

Validarea, sau mai general verificarea si validarea (V & V) are ca scop sa arate ca sistemul este conform cu specificatia si satisface asteptarile clientului.

Aceasta faza implica proceduri de verificare precum inspectii (inspections) si revederi (reviews) care au loc in fiecare faza a procesului de dezvoltare, de la definirea cerintelor la implementare.

Activitatea ce mai importanta si mai costisitoare insa a fazei de validare are loc insa dupa faza de implementare, atunci cand este testat sistemul operational.

Cu exceptia programelor de mica dimensiune, sistemele nu trebuie testate ca o unitate monolitica.

Sistemele de mai mare dimensiune sunt formate din module, care la randul lor sunt formate din proceduri si functii.

Procesul de testare trebuie deci efectuat incremental in etape in functie de structura implementarii sistetemului.

l        Testare la nivel de unitate (unit testing)

Sunt testate componentele individuale pentru a se asigura ca acestea functioneaza corect.

l        Testare la nivel de modul (module testing)

Un modul este o multime de componente dependente, precum o clasa, un tip de date abstract (ADT), un pachet de proceduri si functii.

l        Testare la nivel de sub-sistem (sub-sistem testing)

Modulele sunt integrate in sub-sisteme si testate. In aceasta faza accentul cade pe testarea interfetelor dintre module

l        Testare la nivel de sistem (system testing)

Se testeaza sistemul ca un intreg, cautandu-se erorile care provin din interactiunea dintre subsisteme. In plus, se valideaza ca sistemul indeplineste cerintele functionale si nefunctionale.

l        Testare pentru acceptare (acceptance testing)

Sistemul este testat cu date furnizate de catre client. Aceasta faza poate scoate in evidenta omisiuni in definirea cerintelor, facilitati care nu corespund nevoilor utilizatorului sau probleme de performanta ale sistemului.

Testarea la nivel de unitate si la nivel de modul sunt de obicei responsabilitatea programatorului. Fac parte din implementare.

Fazele ulterioare implica integrarea lucrului mai multor programatori si trebuiesc planificate in avans. Sunt efectuate de catre testeri care vor lucra pe baza unor planuri de testare pre-formulate, create pe baza designului si a specificatiei sistemului.

Testarea pentru acceptare este numita si testare alfa (alpha testing). Testarea alfa continua pana cand clientul si dezvoltatorul cad de acord ca sistemul reprezinta o implementare acceptabila a cerintelor. Acest tip de testare se aplica in cazul sistemelor facute la comanda.

Cand un sistem este comercializat ca un produs software, adeseori se foloseste un proces de testare numit testare beta (beta testing). Acesta presupune livrarea unui sistem unui numar de clienti potentiali care au fost de acord sa utilizeze sistemul.

4. Evolutie

procesul de schimbare a acestuia in timp dupa ce acesta a fost dat in functiune

presupune atat corectarea unor erori de functionare cat si adaugarea unor noi functionalitati.

Software vs. hardware

Pentru sistemele software, schimbarile pot fi facute in orice moment in timpul sau dupa dezvoltarea acestuia.

Aceste schimbari pot fi foarte costisitoare, dar totusi mult mai ieftine decat schimbarile corespunzatoare de hardware.

Dezvoltare vs. evolutie

In trecut a existat intotdeauna o linie de demarcatie intre procesul de dezvoltare a unui sistem software si acela de evolutie.

Dezvoltarea este considerata o activitate creativa, care presupune crearea unui sistem pornind de la un concept initial.

Activitatea de mentenanta, pe de alta parte, desi foarta adesea costa de cateva ori mai mult decat cea de dezvoltare propriu zisa, este considerata mai putin interesanta decat aceasta.

In prezent, acesta demarcatie devine din ce in ce mai putin vizibila. Putine sisteme software mai sunt acum sisteme complet noi, fiind mult mai rezonabil de a privi mentenata ca o continuare a dezvoltarii.

In loc de a considera doua procese separate, este mult mai realist ca totul sa fie considerat un singur proces de evolutie, in care sistemul este schimbat continuu in cursul vietii sale in functie de schimbari ale cerintelor si nevoile utilizatorilor.