Obiectivele pentru capitolul I - Fundamente

Obiectivele i principiile ingineriei software. Ciclul de via. via. Civa termeni Misiunea inginerilor software Abordri specifice Obiective Principii Produse pentru dezvoltare software, procese si resurse Modele ale procesului de dezvoltare software Standarde
IP- Vasile Stoicu-Tivadar IPStoicu1 / 53

Civa termeni
(industrial) process control)

Sisteme de conducere cu calculatorul a proceselor (tehnologice) (computers in tehnologice)

Sistem de calcul utilizat pentru conducerea unor pri sau n totalitate unor pri sau n totalitate a unui proces n sens larg (sau numai proces tehnologic) cu scopul realizrii i meninerii unor performane tehnice i economice i care prezint anumite cerine specifice obligatorii (rspuns rapid, siguran n funcionare).

Echipament

Interfee de proces

Operator uman

Proces

Proceduri de operare
IP - Vasile Stoicu-Tivadar Stoicu-

Software

2 / 53

de proces) Civa termeni Def.: un sistem on-line (legatprescris a caracterizat printr-o valoare timpului de rspuns (de cele mai multe ori de ordinul secundelor sau fraciuni de secund) fiind capabil s urmreasc i s rspund n timp util la solicitrile din exterior. Este vorba de acele sisteme la care o abatere de la limita maxim a timpului de rspuns s nsemne incidente grave n mediul controlat.

Sisteme n timp real

IP- Vasile Stoicu-Tivadar IPStoicu-

3 / 53

Civa termeni
Stil de programare
modul de aplicare a tehnicilor de programare, mod de documentare a programului, de aezare n pagin a textului surs, n general totalitatea atributelor care confer unui program o anumit personalitate urmrind realizarea unor anumite performane.

IP - Vasile Stoicu-Tivadar Stoicu-

4 / 53

Demn de atenie !
Programarea nu este o art ci o activitate inginereasc pretenioas:

nu poate fi realizat dect n echip programele obinute trebuie s fie userfriendly i nu pentru specialiti trebuie s poat fi nelese si modificate de ctre alte persoane dect proiectanii

IP - Vasile Stoicu-Tivadar Stoicu-

5 / 53

Civa termeni
Ingineria programrii (Software Engineering)
Domeniu al informaticii ce se ocup cu determinarea celor mai adecvate soluii, procedee i instrumente care s conduc n condiii optime la elaborarea unui produs program astfel ca acesta s satisfac toate cerinele impuse de specificaiile de definire. Proiectarea i dezvoltarea aplicaiilor software

IP - Vasile Stoicu-Tivadar Stoicu-

6 / 53

CE ESTE de fapt Ingineria Programrii? Programrii?

Ca i Inginer Software, ne folosim Software, cunotinele despre calculatoare, prelucrarea informaiilor i altele pentru a ajuta la rezolvarea problemelor. problemelor.

Cteodat problema e din domeniul calculatoarelor dar de multe ori e din alte domenii este esnial s nelegem nti natura problemei, apoi vom folosi tehnologia ca o unealt pentru a implementa soluia.

IP - Vasile Stoicu-Tivadar Stoicu-

7 / 53

Rezolvarea problemelor (analiz) (analiz)

Problemele sunt mari -> trebuie s ncepem prin a investiga, prin analiz, analiz, adic prin mprirea problemei n buci pe care le putem nelege i trata.
Important: relaiile sunt la fel de eseniale ca i subproblemele nile .

IP- Vasile Stoicu-Tivadar IPStoicu-

8 / 53

Rezolvarea problemelor (sintez) sintez)

Dup ce am analizat problema, trebuie s construim soluia din componente care rezolv aspecte diferite ale problemei ->

Sintez-

punem mpreun punem o structurp mare din blocuri constructive mai mici

Important: Compunerea unor soluii individuale poate s fie la fel de provocatoare ca i gsirea soluiei nsei. (a se vedea scrierea unui roman: dicionarul cuprinde toate cuvintele care vor fi folosite n roman, dar partea dificil a scrisului const n a decide cum s fie compus i organizat cartea ntreag)
9 / 53

DE CE calitatea produselor software este important ?

Sunt utilizatorii mulumii cu calitatea produselor software
Deseori sistemele nu funcioneaz aa cum am dori i ne-am atepta: codul conine erori dar este suficient de bun pentru a demostra viabilitatea unei abordri

DA

NU

Cum era nainte de a exista procesoarele de text, pota electronic, , INTERNET etc. ?

Exemple punctuale pentru lipsa calitii: 1. United States Internal Revenue Service sistemul Creterea federal de calcul al taxelor un fiasco de 4 miliarde nepermis a din cauza proastei planificri costurilor 2. Un sistem SDI (Initiavtiav de Aparare Strategica Razboiul Stelelor) ar necesita cel puin 10 miloane linii de cod (unii estimeaz chiar 00 mil.) -> testarea unui asemenea volum de cod este aproape imposibil 3. Software-ul pentru Therac 25 X-ray machine - > utilizarea neateptat , neobinuit a tastelor sgei -> a omort civa pacieni

Probleme de testare

Pericol n utilizare Exist cteva tehnici de a crete calitatea software (testare cu date de test, revizia colegial 10 / 53 peer review etc.)

CE este un software BUN?

Contextul determin

rspunsul

Erori tolerate la procesoarele de text pot s nu fie acceptabile n sisteme safety-critical

Calitatea produsului

Calitatea procesului care conduce la produs

Calitatea produsului n contextul mediului (ca afacerebusiness) n care produsul va fi utilizat

Urmtorul

IP- Vasile Stoicu-Tivadar IPStoicu-

11 / 53

Calitatea produsului software

Software-ul poate fi evaluat de utilizarori de exemplu dup numrul i tipul cderilor (minore, majore, catastrofice), dac realizeaz ce doresc, dac este uor de nvat, uor de folosit etc. Software-ul poate fi evaluat de asemenea de ctre proiectani (caracteristicii interne: numrul i tipul erorilor ca i msur a calitii produsului)

Model care leag perspectiva proiectantului (perspectiva intern) de cea a utilizatorului (perspectiva extern)
Modelul de calitate al lui McCall napoi IP - Vasile Stoicu-Tivadar Stoicu12 / 53

Calitatea procesului software

Multe activiti afecteaz calitatea produsului. E demn de atenie rspunsul la ntrebri precum: Unde i cnd gsim mai degrab un anume tip de erori ? Cum s gsim erorile, ct mai degreme n cadrul procesului de dezvoltare software ? Cum s realizm sisteme tolerante la defectare astfel nct s minimizm posibilitatea ca o eroare s devin o cdere ? Exist posibiliti alternative care s duc la un proces mai eficient n asigurarea calitii ? Putem mbunti calitatea unui produs prin utilizarea unor metodologii i standarde de calitate precum Capability Maturity Model (CMM) sau varianta mai modern CMM Integrated napoi (CMMI), ISO 9000 i variantele sale adaptate la neceesitile dezvoltrii software , Software Process Improvement and dEtermination (SPICE)
13 / 53

Calitatea produsului n contextul afacerii

Calitatea este privit din punctul de vedere al produselor i serviciilor furnizate de afacerea n care software-ul este nglobat
RI include aspecte precum:

Returnarea investiiei (RI) Return on investment (ROI) Efort

(companiile suint interesate n a economisi timp sau a n utiliza ct mai puin personal):

instruire programare risc calitate afacere (rentabilitate)

productivitate proces clieni costuri

napoi

IP - Vasile Stoicu-Tivadar Stoicu-

14 / 53

Cine practic Ingineria Programrii ?

Un element cheie al dezvoltrii software este comunicarea dintre client i dezvoltator.
Situaii: - clientul nu este utilizator - utilizatorul , clientul i dezvoltatorul sunt aceai entitate - clientul poate decide s achiziioneze software comercial ( commercial off-the-shelf software COTS ) pentru a fi ncorporat n produsul final - utilizarea unor dezvoltatori suplimentari (subcontractori) care vor elabora subsisteme - ca i soluii la cheie Participanii n procesul de dezvoltare software - pot s necesite un proces separat de integrare
15 / 53

IP - Vasile Stoicu-Tivadar Stoicu-

ABORDAREA SISTEMIC
Often, the hardware and software we put toghether must interact with users, with other software tasks, with other pieces of hardware, with of existing databases, with other computer systems -> with the boundaries of the project.
Example: a program for printing paychecks for the employees; we must know whether the program simply reads hours worked from another system and calculate the results or also calculate taxes, pensions etc.

Where does the project begin and end ? The same question -> applies to any system A system - a collection of objects and activities
plus a description of the relationships that tie the objectives and activities together. Typically: for each activity, a list of inputs required, actions taken, outputs produced.

Any collection of component elements that work together to perform a task. Examples are a hardware system consisting of a microprocessor, its allied chips and circuitry, input and output devices, and peripheral devices; an operating system consisting of a set of programs and data files; or a database management system used to process specific kinds of information
16 / 53

IP - Vasile Stoicu-Tivadar Stoicu-

ELEMENTELE UNUI SISTEM

Descriem un sistem enumernd prile sale i identificnd modul n care se enumernd manifest relaiile dintre componente. Acesta este primul pas n analiza unei probleme.
intrri

Elemente: Activiti i obiecte activitate ceva ce ce ntmpl n sistem (de regul descris ca un eveniment iniiat de un trigger transform ceva n altceva schmibndu-i caracteristicile prin translatare, schimbare, combinare etc. ) obiect sau entitate elementele implicate n activiti uzual relaionate cumva (tabele, matrici, nregistrri etc. sau vzute independent, avnd asociat o list de caracteristici ex. Abordarea Orientat pe Obiecte) Relaii i marginile sistemului -unele elemente traverseaz marginile pentru a intra n sistem, altele sunt produse ale sistemului i l prsesc pentru a fi utilizate de alt sistem etc.
IP- Vasile Stoicu-Tivadar IPStoicuieiri
17 / 53

ELEMENTELE UNUI SISTEM - EXEMPLE

Putem pune n eviden prile componente ale Sistemului Respirator: margini entiti activiti

i pentru un sistem pentru salarii

18 / 53

ABORDAREA INGINEREASC
ndat ce am neles natura unui sistem, putem s l construim. Aici, partea inginereasc a ingineriei programrii devine mai important. inginereasc programrii Proiectele software avanseaz ntr-un mod similar cu procesul de construire a unei ntrcase: case: analiza i definirea cerinelor proiectarea sistemului (descrie doar aparenele poate fi revizuit de client) proiectarea programului implementarea programului (scrierea programului) testele de modul testele de integrare testele de sistem livrarea sistemului ntreinerea n realitate, muli din aceti pai se repet (de exemplu, revizuind proiectarea sistemului, pot s apar noi cerine). Definim un proces de dezvoltare software ca orice descriere a dezvoltrii software care conine unele din activitile de mai sus, organizate astfel nct mpreun s produc cod testat. 19 / 53

MEMBRII ECHIPEI DE DEZVOLTARE SOFTWARE

Dezvoltatorii unei aplicaii software sunt ingineri software (sau informaticieni) dar fiecare poate fi specializat n unele din aspectele particulare ale dezvoltrii, conform pailor din procesul de dezvoltare software: analiti (de cerine) genereaz o descriere la nivel sistem mpreun cu proiectanii proiecani - descriu sistemul astfel nct programatorii s poat scrie linii de cod care s implementeze cerinele programatori testori instructori pentru client echipa de ntreinere bibliotecari (pentru ntreinerea bibliotecile de module de program) echipa de gestiune a configuraiilor implicat n ntreinerea unei corespondene ntre cerine, prioiectare, implementare i 20 / 53 testare

Aspecte etice
n activitatea de dezvoltare soft trebuie urmrite i aspectele etice i sociale ale consecinelor utilizrii produselor proiectate. De aceea, n activitatea de proiectare trebuie s dea de gndit urmtoarele aspecte: a) nlocuirea rezolvrii de probleme ale clienilor prin alte probleme (adic le crem acestora noi probleme)
Ex: cuplu pervers: masina de tuns iarba, bicicleta ergonomic.
Un reprezentant al clasei de mijloc i cumpr main de tuns iarba (scump) pentru a ntreine gazonul; deoarece folosind aceast main nu depune efortt, este sedentar deoarece i risipete unica posibilitate de a depune efort, neavnd timp n afar de tunsul ierbii i i cumpr n consecin i o biciclet ergonomic (scump) pentru a-i menine sntatea, n loc s i cumpere o coas (ieftin) pentru a rezolva ambele probleme.

b. s nu crem false necesiti (exemplu: aparat video programabil cu prea multe i prea complicate posibiliti care nu vor fi aproape niciodat exploatate); c) din punct de vedere strategic s orientam corect resursele disponibile; d) s nu se uite nici un moment c produsul este realizat pentru a IP - Vasile Stoicu-Tivadar Stoicu21 / 53 fi utilizat de oameni.

INGINERIA SOFTWARE, obiective si SOFTWARE, principii

Producerea si intretinerea aplicatiilor software, in special cea a sistemelor in timp real, reprezinta un efort important din punct de vedere: tehnic al managementului financiar Sunt foarte multe cereinte antagonisce spre rezolvare. Acesta este un motiv pentru care s-a nascut ingineria software (inca din 1968 - la conferinta NATO) Ingineria software intentioneaza sa: stabileasca ciclul de viata al programleor si continutul etapelor acestora elaboreze metode potrivite si tehnici pentru usurarea proiectarii soft conform unor diferite cicluri de viata elaboreze metode pentru activitatile de concepere si administrare Ingineria software intentioneaza sa treaca de la arta programarii la o activitate sistematica care poate permite performante sigure. Ingineria software presupune folosirea in mod sistematic a uneltelor software, in conformitate cu principiile si obiectivele de baza.
IP- Vasile Stoicu-Tivadar IPStoicu22 / 53

OBIECTIVE ALE INGINERIEI SOFTWARE

(unele dintre ele) ele) Obiectivele sunt deziderate pe care proiectanii software le au n vedere tot timpul ciclului de via via Exemplul 1 al programelor: programelor: Flexibilitatea posibilitatea de adaptare (mai usoara)
la noile cerinte. Motivele pentru noile cerinte : schimbarile la nivel fizic noile functii aparute extensiiile (volumele de date )

Exemplul 2

Implementarea prin: parametrizari Structuri de date potrivite, Tehnici speciale de programare, Scrierea codului pentru refolosire etc.
IP- Vasile Stoicu-Tivadar IPStoicu23 / 53

OBIECTIVE ALE INGINERIEI SOFTWARE (continuare 1)

Eficienta este un indice calitativ cu doua intelesuri :
ca performanta a softului insusi (eficienta ca viteza de calcul, memorie ocupata, etc.) asociata cu calitatea software ca si cost de producere (productivitate) asociata cu punctul de vedere al afacerilor (presiunea pietei) Producatorii trebuie sa obtina un soft mai bun (prin asigurarea unui standard de calitate) si cat mai rapid posibil (cereri antagonice).Tehnicile ingineriei software ajuta la rezolvarea acestora.

Fiabilitatea

se refera la evitarea, gasirea si repararea greselilor cat de repede permite procesul de proiectare, si restabilirea functionarii corecte daca apar erori de functionare. Nu putem impune aceasta prin adaugarea, mai tarziu, de componente speciale pentru a creste siguranta; - este foarte important pentru procesul de control software Exista cateva tehnici pentru a creste siguranta (redundanta statica si dinamica, etc.). Eficienta si siguranta sunt puternic influentate de catre tehnicile ingineriei software folosite. Statisticile arata ca 60% din erori apartin etapei de analiza si doar 40% apar in conceperea propriu-zisa (adica de fapt nu s-a inteles bine ce trebuie facut) 24 / 53

OBIECTIVE ALE INGINERIEI SOFTWARE (continuare 2)

Perceptibilitatea (readability)readability)
proprietate a programelor de a fi intelese de catre alti programatori, altii decat autorii (sau chiar de catre autori, la un timp dupa realizarea unor programe) Acest atribut creste fiabilitatea dar si adaptabilitatea.

De asemenea, gestionarea unui proiect soft este posibila doar daca inginerii soft din cadrul echipei de programare asigura o forma standard usor accesibila a produsului lor. O proiectare soft buna, care tine cont de toate aceste obiective, este influentata puternic de catre metode, tehnici si unelte descrise si impuse de catre inginerul soft. Obiectivele pot fi atinse prin imprimarea in practica curenta a principiilor ingineriei soft.

IP- Vasile Stoicu-Tivadar IPStoicu-

25 / 53

PRINCIPII ALE INGINERIEI SOFT

1. Modularitatea - presupune dividerea programului in entitati diferite cu intrari si iesiri bine delimitate, numite module program si structurarea programului in module pentru o mai usoara obtinere a unor obiective sigure. Un modul este cu atat mai independent de hardware cu cat este mai sus in ierarhia modulelor -> urmariti diferenta dintre obiective ale modulelor din ierarhie
Nivel superior in ierarhie Obiective (comenzi) rapoarte Nivel scazut in ierarhie Nivel tactic Nivel strategic

2. Abstractizarea- identificare a proprietatilor

esentiale ale unor entitati aparent diferite

Procesarea controlata a semnalelor proceselor industriale

Este de altfel redata ierarhic.

Starea semnalelor

Semnalizare avarie

Masuratori

IP- Vasile Stoicu-Tivadar IPStoicu-

26 / 53

PRINCIPII ALE INGINERIEI SOFT continuare

3. Localizarea punerea in vecinatatea fizica a elementelor cu unele legaturi intre ele Examplu: functiile unei biblioteci (calcule matematice, interfete grafice, etc.), functii langa structurile de date folosite, etc.

4. Ascunderea

accentuarea elementelor esentiale si ascunderea detaliilor care nu afecteaza alte componente ale sistemului Exemplu: abordarea orientata pe obiecte - incapsularea Observatie: diferenta dintre abstractizare si ascundere: amandoua accentueaza aspecte esentiale dar ascunderea defineste restrictiile de acces. 5. Uniformitatea - asigura consistenta programelor, este specifica fiecarui Uniformitatea inginer in programare Examplu: conventiile proprii ale fiecarui programator in notatii

6. Completitudinea Completitudinea
omise.
uniformitate)

asigura ca nici una din elementele esentiale nu sunt

Examplu: - notatiile trebuie sa exprime tot ce este necesar (referitor si la

7. Confirmabilitatea

informatiile cerute de catre procesul de testare sa

27 / 53

fie formulate explicit si de asemenea disponibile . Exemplu: necesitatea procedurilor de testare (ca document)

INSEMNATATEA PROCESULUI Am vazut deja ca procesul de proiectare are cativa pasi.

Orice proces are urmatoarele caracteristici: Descrie toate activitatile majore ale procesului Foloseste resurse, fiind supus unor serii de constrangeri si produce o serie de produse intrermediare si finale Pot fi formate din subprocese (fiecare are propriul model de proces) Fiecare activitate a procesului are criterii de intrare si iesire Activitatiile sunt organizate in secvente Fiecare proces are un set de principii de ghidare care explica obiectivele fiecarei activitati Constrangerile pot fi aplicate unei activitati, resurse sau produs (exemplu: bugetul sau programarile pot constrange timpul unei activitati)
IP- Vasile Stoicu-Tivadar IPStoicu-

O serie de sarcini cerute: O serie de pasi implicand activitati, constrangeri, resurse care produc un produs dorit.
Cand procesul implica crearea unui anume produs, ne referim la proces ca la un ciclu de viata. . Totusi, procesul de dezvoltare soft este numit ciclu de viata soft, deoarece descrie viata unui produs soft de la conceptie la implementare, livrare, folosire si intretinere.

28 / 53

MODELELE PROCESULUI SOFT

Multe modele ale proceselor sunt descrise in literatura ingineriei soft. Construirea unui model si discutarea subproceselor ajuta echipa sa distanta dintre ceea ce ar trebui sa fie si ceea ce este.

Motive pentru modelarea unui proces: Cand un grup scrie o descriere a procesului sau Fiecare proces de dezvoltare a de dezvoltare, formeaza o intelegere comuna a modelului soft include cerintele sistemului ca intrare si livrarea activitatilor, resurselor si constrangerilor produsului ca iesire. Ajuta la gasirea discordantelor si a omisiunilor Multe asemenea modele au fost Modelul trebuie sa reflecte scopurile dezvoltarii propuse de-a lungul anilor. (calitate ridicata, gasirea de erori, incadrarea in buget); pe masura ce aplicatia este finalizata, echipa evalueaza cerintele necesare pentru o apropiere de obiectivului propus Fiecare proces trebuie creat pentru situatia speciala in care va fi folosit; crearea unui model al procesului ajuta echipa de programatori sa inteleaga unde este folosita aplicatia lor.
IP- Vasile Stoicu-Tivadar IPStoicu-

29 / 53

MODELUL CASCADA (WATERFALL)

Unul din primele modele
Pasii sunt descrisi in cascada unul dupa altul Un stagiu de dezvoltare trebuie terminat inainte dea incepe urmatorul Prezinta un nivel mare de vizualizare a ceea ce se intampla in timpul dezvoltarii Sugereaza programatorilor secventa evenimentelor pe care ei ar trebui sa se astepte sa le intalneasca
IP- Vasile Stoicu-Tivadar IPStoicu30 / 53

MODELUL CASCADA (WATERFALL)

Programele trebuie proiectate, testate, implementate i exploatate. n general se consider c fazele prin care trece un program sunt: Analiza cerinelor - faza colaborrii dintre beneficiar i echipa de elaborare pentru a se stabili definiia exact a problemei (cerine i restricii) rezultnd n general o tem de proiectare Elaborarea specificaiilor - faza n care se elaboreaz un set de specificaii formale (descrieri abstracte) pentru programe cuprinznd o descriere detaliat pentru toate entitile funcionale precum i pentru toate restriciile. Proiectarea programelor - se stabilete structura pe module, raporturile dintre ele, modul de comunicare, parametrii de intrare-ieire, tipuri de date etc.. intrareImplementarea programului - programarea conform celor stabilite la punctele anterioare. Se folosete un limbaj adecvat pe un calculator gazd (host computer) Instalarea i verificarea pe calculatorul int, al beneficiarului, n condiii de exploatare ntreinerea programului - asigur eliminarea erorilor ce se manifest dup pornirea aplicaiei
IP- Vasile Stoicu-Tivadar IPStoicu-

31 / 53

MODELUL CASCADA (WATERFALL)

In economia unei lucrri, n cadrul primelor 3 etape 40% lucrri, reprezint analiza, elaborarea specificarea i proiectarea, analiza, proiectarea, 20% implementarea i 40% testarea. testarea. Codificarea reprezint de regul ntre 16-20 % 16ntre ntreinerea poate s reprezinte pn la 60% din costul total. De aceea trebuie acordat o atenie deosebit minimizrii numrului de erori prin: utilizarea unor metode de elaborare i testare care s asigure un numr minim de erori i structurarea programelor astfel nct acestea s permit modificarea ct mai uor.

IP- Vasile Stoicu-Tivadar IPStoicu-

32 / 53

MODELUL CASCADA - continuare

Poate fi foarte folositor pentru programatori in a produce ceea ce doresc Simplitatea lui il face mai usor de explicat clientilor Multe modele complexe sunt derivate din modelul cascada

dar (inconveniente)
nu reflecta intotdeauna modul in care este implementeat codul Modelul nu asigura ghidarea sefilor de proiecte referitor la cum sa faca fata schimbarilor si activitatilor care probabil vor aparea neasteptat in timpul implementarii (nu ne pregateste pentru surprize ) Lipsa tratarii soft a ,,procesului de ,,procesului rezolvare a problemelor (producerea problemelor (producerea softului nu este o rutina ci un proces de creatie) creatie)

33 / 53

PROTOTIPURILE
Procesul de implementare soft poate ajuta pentru a controla caderile prin includerea de activitati si subactivitati care sporesc intelegerea; prototipul este un asemenea subproces Un prototip este un produs partial finalizat care face posibila o examinare a unor aspecte ale sistemului propus de catre cumparator si producator pentru a decide daca este convenabil sau se apropie de produsul final. Adesea, interfata cu utilizatorul este construita si testata ca un prototip, de aceea utilizatorul intelege cum va arata noul sistem si designerii au o imagine mai clara despre cum doreste utilizatorul sa interactioneze cu sistemul.

Asigura ca sistemul are implementate toate cerintele Prototipul este folositor pentru verificare si validare. Asigura ca fiecare functie functioneaza corect
IP- Vasile Stoicu-Tivadar IPStoicu34 / 53

MODELUL V
Este o variatie a modelului Cascada care demonstreaza cum activitatile de testare sunt legate de analiza si proiectare (Ministerul de Aparare German, 1992) Forma ciclului de viata dupa modelul V este cu analiza si proiectarea in stanga, iar testarea si intretinerea in dreapta. Sugereaza ca testele de integrare vor fi folosite de asemenea pentru a verifica continutul programului --> in timpul testelor, programatorii si echipa de testare trebuie sa se asigure ca toate aspectele conceperii programului au fost implementate corect cu ajutorul codului. De asemenea, testarea sistemului trebuie sa verifice proiectarea sistemului. Testul de acceptanta, care este efectuat mai degraba de client decat de programator(i), valideaza cerintele prin asocierea unor pasi de testare cu fiecare element din lista de cerinte (inainte ca sistemul sa fie acceptat sau platit).
Partea dreapta a modelului V poate fi reexecutata pentru a repara si imbunatati cerintele, designul si codul inainte ca pasii de testare din partea dreapta sa fie finalizati . Focus -> documente & produse (Waterfall) -> activitati & corectitudine (V Model)
35 / 53

IP- Vasile Stoicu-Tivadar IPStoicu-

MODELUL DE PROTOTIPIZARE

Prototipizarea poate fi ea insasi baza pentru un model efectiv. Prototipizarea permite partilor sistemului sa poata fi construite repede pentru a intelege sau clarifica problemele aparute. Cerinta de repetare a investigatiilor asigura ca programatorul, utilizatorul si clientul ajung la un acord comun atat in ceea ce este necesar cat si in ceea ce este propus. Una sau mai multe bucle pentru cerintele prototipului, designului sau sistemului pot fi eliminate, asta depinzand de cerintele prototipului. Oricum, toate cerintele raman aceleasi: reducerea riscului si incertitudinea in programare IP- Vasile Stoicu-Tivadar IPStoicu36 / 53

PROTOTIPIZAREA - continuare
Caile: Prototipul facut pe hartie (schite, desene, tabele, rapoarte) Construirea unui prototip functional (exemplu: interfete construite in Visual Basic doar acestea, fara prelucrari) Folosirea altor programe existente ca modele de referinta

Sunt posibile iteratiile printre cerinte si proiectare.

Avantaje:

Dezavantaje:

Putem evita riscul unui model cascada identificand neintelegerile despre cerinte, dintre programator si client Imbunatatirea dialogului cu clientul

Clientul crede ca aplicatia finala nu este departe de prototip deoarece acesta nu stie deaspre partile ascunse ale aplicatiei Programatorul are tendinta sa neglijeze sau sa uite parti ale aplicatiei care lipsesc in prototip
37 / 53

IP- Vasile Stoicu-Tivadar IPStoicu-

SPECIFICARILE OPERATIONALE
Pentru multe sisteme, nesiguranta in privinta cerintelor duce la schimbri si probleme mai tarziu n aplicatia respectiva. Aceasta abordare( Zave, 1984) permite programatorilor si clientilor sa examineze cerintele si implicrile lor n dezvoltare, unde ei pot s discute si sa rezolve unele dintre probleme. Cerintele sunt evaluate ntr-un mod care demonstreaz comportarea sistemului - se poate incepe evaluarea folosind un pachet de soft, astfel incat implicarea lor s poata fi evaluata naintea nceperii proiectului (dar se foloseste un alt mediu si limbaj decat cel de implementare). Exemplu: Dac specificatia cere ca sistemul propus sa poata fi manipulat de catre 20 utilizatori, o forma executabila a specificatiei poate s ajute analistii pentru a determina dac acest numr de utilizatori solicita prea mult sistemul.

Acest tip este foarte diferit de modelele traditionale. Modelul cascada desparte functionalitatea sistemului de proiectare( ''ce'' este separat de ''cum''), intentionnd s pstreze clientii departe de implementare. Specificatia operational permite ca functionalitatea si proiectarea sa fie unite. Specificatia operational este asemntoare cu prototipul. Procesul permite utilizatorului si programatorului sa examineze cerintele mai devreme. IP- Vasile Stoicu-Tivadar IPStoicu38 / 53

MODELUL TRANSFORMATIONAL

ncearc s reduc posibilitatile de eroare eliminnd ctiva pasi de dezvoltare majori (Balzer, 1981). Folosind suportul de automatizare, procesul transformational aplica o serie de transformri pentru a schimba o specificatie ntr-un sistem gata de livrare. Exemple de transformri: - Schimbnd reprezentarea de date selectnd algoritmii - optimiznd - compilnd. Un dezavantaj major este nevoia pentru o specificatie formala realizata cu precizie.
IP- Vasile Stoicu-Tivadar IPStoicu39 / 53

DEZVOLTAREA BAZATA PE FAZE

Intervalul de timp dintre cerintele aplicatiei si livrarea sistemului se numeste 'durata de ciclu'' . Un mod pentru a reduce acest interval este dezvoltarea bayata pe faze: sistemul este proiectat ca el sa poata fi livrat n bucti (sau versiuni), permitandu-le utilizatorilor o parte functionala n timp ce restul este dezvoltat. Astfel, exist dou sisteme ce functioneaza n paralel - sistemul in exploatare (folosit de client) si sistemul in dezvoltare. Sistemul in dezvoltare este versiunea urmtoare care este pregtit s nlocuiasc sistemul in exploatare curenta.

SE- Vasile Stoicu-Tivadar SEStoicu-

40 / 53

Incrementari si iteratii
Abordari : Dezvoltarea incrementala Sistemul este impartit n subsisteme dupa functionalitate iar varianta finala este la nceput dintr-un subsistem de mici dimensiuni, si dup aceea cu fiecare noua imbunatatire i se adauga functionalitatati noi. Dezvoltarea iterativ - livreaz un sistem intreg la nceput si dup aceea schimb functionalitatea fiecarui subsistem cu fiecare varianta nou (o imbunatateste)
Exemplu: Un program de procesare de text, cu trei tipuri de functionalitate (creare de text, organizare - taie & lipeste, formare fonturile). Pentru incrementarea programului, 'varianta 1' contine doar functiile de creare a textului apoi crearea si organizarea, apoi toate functiile. Pentru dezvoltarea iterativ, 'varianta 1' contine toate functiile ntr-o forma primitiva ( exemplu taie & lipeste este lenta), pe cand 'varianta 2' sporeste calitatea functiilor etc. Fiecare noua versiune mbuntteste una anterioara ntr-un anume fel.
41 / 53

Incrementari si iteratii - continuare

n realitate, multe companii folosesc o combinatie de dezvoltare iterativ si incrementala. O varianta nou poate s includ o functionalitate nou, dar se poate si ca o functionalitatea existenta sa fie imbunatatita. Motive pentru aceasta abordare: Instruirea utilizatorilor poate incepe la primele versiuni ale programului, chiar daca unele functii lipsesc; acest proces permite urmarirea in exploatare si imbunatatirea programului Piata poate fi creata inainte ca produsul sa fie aparut Frecvent produsele permit programatorilor remedierea problemelor neanticipate repede, pe msura ce ei sunt avertizati de la activitatea de mentenanta. Echipa de dezvoltare se poate concentra pe domenii diferite de expertiz cu diferite versiuni Exemplu: un produs imbunatateste interfata, celalalt, performanta.
IP- Vasile Stoicu-Tivadar IPStoicu42 / 53

MODELUL SPIRALA
Combin activitatea de dezvoltare cu managementul de risc pentru a minimiza si controla riscul (Boehm, 1988). Modelul acesta este ntr-un fel asemenea dezvoltarii iterative. ncepnd cu o schit initial, procesul insereaz un pas pentru a evalua riscul si o alternativa de prototip naintea ca un document de ''concept al operatiilor'' sa fie creat pentru a descrie la un nivel nalt cum ar trebui s functioneze procesul de dezvoltare al sistemul. Apoi, cu fiecare iteratie, analiza riscurilor cantareste diferitele alternative din punct de vedere al cerintelor si constrangerilor, iar prototipizarea verifica fezabilitatea inainte ca o anumita alternativa sa fie aleasa. Cnd riscurile sunt identificate, managerii de proiect trebuie s se hotrasc cum sa-l elimine sau sa-l minimizeze.

Exemplu: Proiectantii nu pot s fie siguri dac utilizatorii vor prefera un tip de interfat sau altul; pentru a minimaliza riscul, ei pot produce o interfata pentru fiecare prototip si sa efectueze testele pentru a vedea care este cea preferata.
IP- Vasile Stoicu-Tivadar IPStoicu43 / 53

MODELUL SPIRALA continuare 1

IP- Vasile Stoicu-Tivadar IPStoicu-

44 / 53

MODELUL SPIRALA continuare 2 SPIRALA

(sau alta reprezentare simplificata)

Acest model este folosit pentru proiecte la scara mare, care implica un risc deosebit (adica resurse financiare mari).

45 / 53

Dezvoltare AGIL AGIL

Accent pe cod mai degrab dect pe un proiect predefinit Dezvoltare iterativ Livrare rapid i flexibilitate pentru a ndeplini cerine n schimbare Manifesto AGILE
Mai degrab indivizi i interaciuni dect procese i unelte Software care funcioneaz mai degrab dect o bun documentaie Colaborare cu clientul mai degrab dect negociere contractual Rspuns la schimbri mai degrab dect urmrirea unui plan

46 / 53

Dezvoltare AGIL continuare AGIL

PRINCIPII Satisfacerea nevoilor clientului prin livrarea continu i rapid livrar continu de software util SoftwareSoftware-ul este livrat frecvent (sptmni) SoftwareSoftware-ul care lucreaz este principala msur a progresului Chiar i schimbri trzii sunt acceptate Cooperare apropiat (zilnic) ntre dezvoltatori i cei implicai n business Conversaia fa n fa forma de comunicare dorit ncrederea trebuie construit n permanen ntre indivizi permanen motivai Atenie continu la buna proiectare i calitatea din punct de vedere tehnic Simplitate Echipe care se auto-organizeaz auto47 / 53

DOD-STDDOD-STD-2167 un standard
Exist multe standarde pentru dezvoltarea software, dar multe din acestea sunt neoficiale sau specifice companiilor respective. Unul din primele este standardul DOD-STD-2167 A sau MIL-STD-2167 de la US Dept. of DOD-STDMIL-STDDefense (Dod).

Specific un model ca si cel cascad: Analiza/proiectarea cerintelor de sistem Analiza cerintelor Proiectarea preliminara Codarea si testarea (CSU) Computer Software Component (CSC) integrare si testare Computer Software Configuration Item (CSCI) testare Integrarea si testarea de sistem

Standardul este permis de asemenea pentru 8 verificari sau treceri n revist si 17 tipuri de rapoarte oficiale si documentaie.

Lista de verificari:
inspectia cerintelor soft inspectia proiectarii soft inspectia specificatiilor soft inspectia proiectarii preliminare inspectia proiectarii finale revizuirea configuratiei functionale revizuirea configuratiei fizice inspectia variantei oficiale

IP- Vasile Stoicu-Tivadar IPStoicu-

48 / 53

DOD-STDDOD-STD-2167 un standard continuare 1

Dezvoltarea sistemului

49 / 53

DOD-STDDOD-STD-2167 un standard continuare 2

Lista rapoartelor si documentatiei: continutul documentului sistem/segment plan de dezvoltare soft specificatiile cerintelor soft specificatia cerintelor interfetei documentul de concepere a interfetei Specificatiile de producere soft Documentul de descriere a versiunii Planul de testare a soft-ului Planul de descriere a soft-ului Raportul de testare soft Manualul operatorului Manualul programatorului Manualul suportului tehnic Propunerea de eventuale schimbari Notificarea specificatiilor de schimbare

In USA multe aplicatii dificile sunt dezvoltate folosind 2167 A, dar multe sisteme sunt implementate folosind un subset mult mai mic al modelului. Acest standard a fost partial depasit de catre standardul IEEE 839 si ISO 9000.

IP- Vasile Stoicu-Tivadar IPStoicu-

50 / 53

DOD-STDDOD-STD-2167 un standard continuare 3

Predarea rapoartelor si documentatiilor formale :

SE- Vasile Stoicu-Tivadar SEStoicu-

51 / 53

ISO 9000
ISO 9000 (International Standard Organisation), este un standard international pentru imbunatatirea calitatii, care a fost adoptat in Europa, SUA, Asia.
Standardul a fost conceput pentru aplicarea sa pentru o larga varietate de producatori. ISO 9001 -9003 se aplica intreprinderilor, in conformitate cu scopul activitatilor lor. Familia ISO 9004 si ISO 9000-X sunt documente care asigura indrumarea pentru aplicatiile specifice anumitor domenii.

Pentru dezvoltarea soft ISO 9000-3 este documentul de interes. ISO 9000 este mai bine situata decat 2167 A pentru dezvoltare produselor comerciale. Chiar unele unitati ingineresti soft de aparare au trecut la ISO 9000 in echivalent militar, MIL-STD-498. Standardele ISO sunt orientate pe proces, ele ajutand companiile sa-si creeze un mediu care sa garanteze o anumita calitate a produselor sale. Principalele campuri ale calitatii care intereseaza:
responsibilitatea managementului Calitatea sistemului Revizia contractelor controlul proiectarii Controlul documentelor si datelor Identificarea si trasabilitatea produselor Controlul proceselor Inspectie si testare Controlul inspectiei, masurarea si testarea echipamentelor Inspectia si nivelul testarii Controlul non-conformitatii produselor Actiuni de corectare si prevenire manipulare, stocare, impachetare, pastrare si livrare Controlul inregistrarilor de calitate calitatea interna a contabilitatii instruire Service (intretinere) tehnici statistice

Pentru a obtine certificarea ISO standard, este cerut un volum semnificativ de documente. Pentru a implementa intr-o companie acest standard, este necesara in prealabil o analiza a beneficiilor, pentru a nu cheltui mai mult decat poate fi obtinut.

52 / 53

IEEE 830
IEEE 830-1993 contine recomandarile practice pentru Software Design Descriptions (SDDs).
Ghidul este descris ca si o coperta a activitatilor de-a lungul proiectarii. Aspectul recomandat al continutului proiectului include combinatii de decompozitii, dependenta, interfata, si descriere a detaliilor. Descrierea decompozitiei este folosita pentru a incadra entitatile de proiectare in sistem. Fiecare entitate de acest fel este descrisa de catre identificarea sa, tip, scop, functie si subordonare. Sectiunea dependentelor este o descriere a relatiilor dintre entitati si resurse sistem. Atributele entitatii includ identificare, tip, scop, dependente si resurse (structuri, diagrame de date, etc)

Descrierea interfetei asigura o lista cu tot ceea ce proiectantul trebuie sa stie despre folosirea entitatilor (fiecare inregistrare cu identificare, functie sau interfetedictionare de date, liste cu parametri, etc.) Descrierea detaliata este folosita pentru a arata detaliile interne ale fiecarei entitati a sistemului ale caror atribute includ identificarea, descrierea procesarilor si descrierea detaliata a datele Standardul este incomplet (el specifica doar cererile legate de proiectare si descriere. Sunt necesare informatii suplimentare.
53 / 53

CE MODEL DE PROCES FOLOSIM ?

Modelele prezentate sunt doar cateva din cele folosite Alte modele ale proceselor pot fi definite si concepute pentru nevoile utilizatorilor, clientului si proiectantilor. Ar trebui sa percepem procesul de dezvoltare software ca o colectie a modelelor proceselor, mai degraba decat a unui singur model. Indiferent de modelul procesului folosit, multe activitati sunt similare. Adesea, modelul procesului este impus de catre organizatiile soft (in functie de cultura interna, uneltele software disponibile, instruire etc).
IP- Vasile Stoicu-Tivadar IPStoicu54 / 53

Care sunt concluziile acestui capitol

Puteti folosi concepte ale acestui capitol in felul urmator: urmator: individual pentru ghidarea comportamentului cand lucrati in echipa va ajuta sa invatati cum sa colaborati si sa va coordonati cu colegii va puteti concentra asupra aspectelor procesului de dezvoltare pentru a va imbunatati cunstintele (functional, comportamental si a altor perspective)

ca echip echip un model bun arata fiecarui membru al echipei ce activitati apar intr-un proiect intrpentru a si le putea imparti managerul proiectului poate folosi tehnicile specifice procesului pentru a imbunatati procesul, simuland activitati si urmarind resurse pentru procesul, determinarea echipei optime si activitatile pentru a se incadra in bugetul si termenele stabilite
IP- Vasile Stoicu-Tivadar IPStoicu55 / 53