Obiective

1. Obiective • Ingineria software ?! • Ciclul de viata al unui produs software • Modele de dezvoltare software • Caietul de sarcini

2. 1.Ingineria software ?! • De ce inginerie software? • Definitia ingineriei software

3. 1.1 De ce inginerie software ? Pentru a se trece • de la dezvoltarea ad-hoc si imprevizibila la • o dezvoltarestrucurata, constructiva si sistematica

4. Istorie • Programarea modulara Pascal • Programarea orientata obiect C++/Java • Programarea cu ajutorul componentelor Entreprise Java Beans

5. Criza dezvoltarii software Erori grave • Sonde spatiale pierdute (Venus ’60, Marte 99) • Crizarachetelor – Cuba 1979 • RachetelePatriot 1991 • Primulzbor Ariane 5 1996 artificii de 5 miliarde $ • Aeroportul Denver 1994-1996 • Anul 2000 • Incidente înfiecareluna - bursadin Tokyo … - accidente de circulatie • Proiectarea software • Livrareaînîntârziere a tuturorproiectelor • Costmultridicatfata de celprevazut • Livrareaunuiprodus de proastacalitate • Esuareaînmajoritateacazurilor • Studiuamericandin 1995 : 81 miliarde $ / an datoratesecului software

6. Constructiapodurilor si dezvoltarea software Ingineria software • Sistemele informatice devin foarte repede extrem de complexe • Esecuri foarte numeroase • « Craparea » este un fenomen des întâlnit si obisnuit • Pierderi minore în general • Cu exceptia sistemelor critice putem spune ca un produs software nu poate anticipa orice situatie • Adaugarea sau schimbarea functionalitatilor, de platforme • Ingineriacivila • Esecuri mai putine • Surpareaunuipod este foarteperculoasapentruoameni • O experienta de mai multemilenii • Un podstricatîngeneral nu se repara ci se reconstruieste • Podulrezista la 99% dinconditii • Daca un pod este inutilizabilatuncischimbamtraseeledrumurilor

7. 1.2 Definitia Ingineriei Software • Disciplina ( = metode, tehnici, utilitare ) • bazatapecunostinte (teorie) • pecunostinta de a face, produceceva(pragmatica) • si de a face sa se stie(comunicare) • pentru a produce (dezvoltare) • înmodindustrial (marime) • aplicatii software (produse) • de cea mai buna calitate

8. 2.Ciclul de viata al unui produs software

9. Cum se va desfasura proiectul de la Inginerie Software ? • Întâlniri la EC101, EG405 … • Craciunul • Sesiunea … criza de timp, iadulstudentesc ….

10. 2.1Cum se desfasoara în general un proiect ? • Entuziasmgeneral la început • Un punct de crizaîn care se constientizeaza ca proiectul nu poate fi predat la timp • Spresfârsit : un volum de muncaimpresionant(24h/24h), resurseumanesuplimentare (colegul de camera de anul2), tensiune si relatiiîncordate • Acestciclu se repeta si înmarilecompanii de soft la primeleproiecterealizate de catre o companie. • Principalacauza este incapacitatea de planificare si gestionare a resurselor (timp, oameni, documentatie, utilitare, cunostinte, etc) .

11. 2.2 Asa da, asa nu Termen de predare Punct de criza Efort 10 Pas 1 Pas 2 Pas 3

12. 2.3 Ciclul de viata optim pentru derularea unui proiect • Ciclu de viata = ansamblul etapelor parcurse în dezvoltarea unui produs software. • Etapele ciclului de viata : • Culegerea de specificatii • Analiza • Proiectarea • Implementarea si Testarea • Validare si Integrare • Calificare • Punerea în functiune • Mentinerea • Retragerea sau înlocuirea

13. 2.3.1 Culegerea de informatii • Definireaproblemei, adica a ceea ce se da înproblema, a resurselor de care dispunem (altesistemeinformaticesau BD pe care le putemutiliza, tehniciutilizabile, persoane care arputealucra, etc) • Specificareadetaliata a functionalitatilor ce trebuiescsuportate de catresistemulinformatic(adicarealizareadiagramei de cazuri de utilizare) • Este de faptrealizataprincaietul de sarcini • Analizafunctionala (veziCurs 2 UML)

14. 2.3.1.1.Stabilirea obiectivelor • Se face de catre managerul de proiect; • Fiecarea idee buna trebuie promovata indiferent de cel care a contribuit la ea; D1 Clientul este cel care doreste acel produs. D2 Utilizatorul este cel care doreste sa utilizeze acel produs software. D3 Dezvoltatorii sunt aceia care intentioneaza sa « fabrice » acel produs.

15. 2.3.1.2 Definirea necesitatilor • Un caiet de sarcini este stabilit de catre client încolaborarecuutilizatorul si dezvoltatorul : - descriereafunctionalitatilorasteptate de la aplicatie; - constrângeri non-functionale (timp de raspuns, utlizareamemoriei, etc ); - posibilitateautilizariiDiagramei de Cazuri de utilizare; Rezultatulacesteietape : Caietul de sarcini

16. 2.3.2 Analiza • Cautarea solutiilor corecte posibile A gasi solutiile corecte posibile înseamna • a alege tehnica de programare ( orientat obiect, procedural, componente); • a gasi algoritmii potriviti si adaptarile lor la necesitatile problemei; • determinarea modelului obiectual necesar dezvoltarii proiectului; • a alege solutia software necesara dezvoltarii;(MySQL sau Oracle,Java sau C#, JavaBuilder sau Eclipse,etc ). • a gasi criteriile de dezvoltare (ergonomie, accesibilitate, rapiditate, etc ) • Identificarea caracteristicilor acestor solutii Pentru solutiile gasite se va încerca o acomodare pe cazuri simple si studierea caracteristicilor (comportamente,raspunsuri, timp de executie,etc ) în aceste situatii de cercetare.

17. 2.3.2.1 Analiza necesitatilor • Este de fapt definitia produsului de realizat • specificatiile precise ale produsului de realizat; • constrângeri ce trebuiesc satisfacute; Rezultatul acestei etape • dosarul de analiza (specificatii functionale si non-functionale) • schita manualului utilizatorului ;

18. 2.3.2.2 Planificare • Defalcarea proiectului în sarcini care se înlantuiesc în mod continu si logic. • Afectarea fiecarui membru al echipei pentru o anumita durata si scop. • Definitia normelor de calitate ce trebuiesc satisfacute . • Alegerea metodelor de concepere si testare. • Stabilirea dependentelor externe (umane, materiale, preturi, calitate a serviciilor) Rezultatul acestei etape • Plan de calitate al produsului, Planul proiectului • Estimarea costurilor reale • Deviz destinat clientului (pret, întârzieri, livrabile)

19. 2.3.3 Proiectarea • La modelele rezultate în urma etapei de analiza se adauga noi elemente pentru a defini o solutie particulara ce « transpune » problema în cauza. • Proiectarea trebuie sa aibe în vedere optimizarea unor criterii de dezvoltare. • Proiectarea este de fapt o rafinare a modelului obiectual ( o diagrama de clasa aproape perfecta, constrângeri pentru atribute si metode, coerenta modelului )

20. Faza de concepere • Definirea arhitecturii software. • Interfete dintre diferite module. • Rolul acestei etape este de a concepe arhitectura de asa natura astfel încât componentele produsului sa fie independente pentru a facilita dezvoltarea. Rezultatul acestei etape • Dosarul de conceptie; • Planul de integrare; • Planul de testare; • Actualizarea planning-ului ;

21. 2.3.4 Implementarea si testarea • Alegerea limbajului potrivit de dezvoltare • Alegerea tehnologiei potrivite de dezvoltare (alegerea serverului de baze de date, alegerea tehnologiei de stocare a datelor, alegerea metodei de transmitere a datelor – protocoale de comunicatii, sincronizare etc ) • Scrierea codului sursa / scripturi ,etc. Rezultatele acestei etape • Module codate • Documentarea fiecarui modul • Actualizarea planning-ului

22. Testarea • Se verifica echivalenta dintre implementare si modelul proiectat. • Validarea implementarii în raport cu criteriile de corectitudine identificate în etapa de analiza. • Implementarea si testarea se face pentru fiecare modul în parte.De fapt testarea se împarte în doua : este vorba de testarea pentru fiecare modul al aplicatiei dar si testarea întregii aplicatii.Testarea întregii aplicatii este de fapt o alta etapa din ciclul de viata si trebuie facuta aceasta distinctie. Rezultate Module testate Rezultatele testarilor unitare

23. 2.3.5 Integrarea si validarea aplicatiei • Fiecare modul este integrat cu celelalte conform planului de integrare. • Ansamblul este testat conform cu planurile de testare. Rezultate • Produs software testat • Manual de instalare • Versiunea finala a manualului de utilizare.

24. 2.3.6 Calificarea produsului soft • Teste de amploare realizate în conditii normale de utilizare. • Teste non-functionale • Teste de încarcare • Teste de toleranta la pana Rezultate Raportul de anomalii

25. 2.3.7 Punerea în functiune • Livrarea produsului final • Instalarea produsului la client • Sfârsit sau nu ?! ….

26. 2.3.8 Mentinerea aplicatiei • Raporturi de incidente sau anomalii • Cerere de modificari corective • Cereri de evolutie a aplicatiei • Cod si documentatie modificata • O noua serie de teste • Unitare • De integrare • Non – regresive

27. 3. Modele ale ciclului de viata • Modelul în cascada • Modelul în V • RAD • RUP • 2TUP • XP

28. 3.1 Modelulîn cascada Analizanecesitatilor Modificarea necesitatilor Specificatiifunctionale Planificare Concepere Implementare Integrare Calificare Exploatare Retragere

29. Problemele modelului în cascada • Proiectele adevarate rar urmeaza o dezvoltare secventiala • Este dificil a stabili toate necesitatile proiectului la începutul sau • Produsele soft dezvoltate urmând un model în cascada apar de cele mai multe ori cu întârziere • Acest model este aplicabil pentru proiectele care sunt bine întelese

30. 3.2 Modelul în V Specificatii functionale si planificare Calificare Conceptie globala Integrare Teste unitare Conceptie detaliata Programare

31. Comparatie • Modelul în V permite • O buna anticipare în dezvoltare • Evita întoarcerea • Dar • Cadrul de dezvoltare este foarte rigid • Durata este adesea foarte lunga • Produsul soft apare adesea foarte târziu

32. Mini-concluzie Clientul încearca prototipul « Ascultarea » clientului Construirea sau ameliorarea prototipului

33. 3.3 RAD Rapid Aplication Develoment • Discutii si interactiuni cu utilizatorul • Verificarea eficacitatii reale a unui algoritm • Verficarea specificatiei interfetei cu utilizatorul (GUI) • Metoda utilizata adesea pentru stabilirea si identificarea necesitatilor • Utilizata adesea de catre generatoarele de coduri

34. 3.4 RUP Rational UnifiedProcess

35. Definitii • Initiere : este fazaîn care se : • Stabilestedomeniulproiectului; • Stabilesccriteriilepentruvalidareareusitei; • Evalueazariscurile; • Estimeazaresurselornecesare; • Un grafic de executiepreliminar,raportat la celepatrufaze principale. • Elaborare :stabilireauneiarhitecturirobuste,adica se realizeazaplanulproiectului si se eliminafactorii de riscmajori. • Constructie : înmoditerativ si incremental se va implementa un produs complet. • Tranzitie : softuleste livratutilizatorilorpentrutestarea ( versiune beta a sistemului )

36. Faze de dezvoltare Initiere Elaborare Constructie Tranzitie Produs fabricat Capacitate operationala initiala Obiective (Viziune) Arhitectura timp

37. Workers Artefactos Activities Elemente RUP Workflow: cerinte DetaliuWorkflow: Analiza problemei

38. 3.5 2TUP : Two Track Unified Process • Se concentreaza în jurul arhitecturii sistemului de proiectat • Propune un ciclu de dezvoltare în Y • Se poate adapta pentru proiecte de orice marime

39. 3.6. XP EXtreming Programming • Este recomandabilapentruechipele de maxim 10 persoane • 4 valori : • Comunicare • Simplitate • Feedback • Curaj

40. 4.Caietul de sarcini • Ce este un caiet de sarcini ? • Structura 1. Introducere 2. Organizareaproiectului 3. Gestiune 4. Tehnici 5. Calendarsi Buget 6. Functiileprodusului 7. Constângerinon-functionale

41. 4.1 Ce este un caiet de sarcini ? • Caietul de sarcini constituie fundamentul pentru orice proiect. • El ne furnizeaza de fapt un ghid despre ce avem de facut în cadrul proiectul la care vom avea de lucru. • Pâna aum în majoritatea cazurilor studentii s-au confruntat cu probleme simple a caror rezolvare se rezuma la maxim câteva • Încazul problemelor de matematica un mic „caiet de sarcini” era reprezentat de ceea ce se scrie înainte de a rezolva problema,adica ipoteza si concluzia. • Daca însa problema pe care o avem de efectuat este una mai complicata atunci trebuie efectuat un adevarat caiet de sarcini. • De exemplu daca trebuie organizata o excursie atunci este necesara realizarea unui caiet de sarcini. • În viata de zi cu zi,conceptul de caiet de sarcini este utilizat frecvent . Daca guvernul doreste sa construiasca autostrada Timisoara-Budapesta, atunci va face un concurs la care firmele care vor dori sa construiasca aceasta autostrada vor participa prin caietul de sarcini.Practic vom avea de-a face cu un concurs al caietelor de sarcini.

42. 4.2.1 Introducere • Rezumatulcontine o descrieredetaliata a aplicatiei, asuprascopuluiaplicatiei respective, a directiilor de cercetarepentruatingereaobiectiveloraplicatiei si alteamanunteconsiderateesentialeînîntelegereaaplicatiei . • Materiale ce trebuiesclivrateclientului, adicaprodusul soft, bibliotecileasociate, documentatietehnica, manualulutilizatorului,etc. • Definitii si acronime . Gânditi-va ca un client poate nu va pricepetotceeavetiscrieînacestcaiet, mai ales termeniispecifici.Înaceastarubricaavetisansa sa faceticunoscutlimbajulutilizat.

43. 4.2.2 Organizarea proiectului • Stabilirea etapelor de dezvoltare • Stabilirea relatiilor dintre diferitele etape de dezvoltare • Distribuirea sarcinilor (adica ce sarcina are fiecare)

44. Microsoft Office Project: Editor si utilitarpentruorganizareatask-urilor

45. 4.2.3 Gestiune • Obiective si prioritati • Ipoteze,dependente si constrângeri • Gestiunea riscului • Mijloace de control

46. 4.2.4 Tehnici • Metode si utilitareutilizate • Metode si utilitareutilizateînproiectare • Metode si utilitareutilizateîndezvoltare • Metode si utilitareutilizateîncreareadocumentatiei • Metode si utilitareutilizateîntestare • Metode si utilitareutilizateînintegrareamodulelor • Utilitarpentruasigurareagestiuniiproiectului • Documentatie • Documentatiautilizatapentrufolosireametodelor si utilitarele de mai sus • Documentatiaproiectului (JavaDocsauDoxygen) http://www.stack.nl/%7Edimitri/doxygen/index.htmlDoxygen http://java.sun.com/j2se/javadoc/JavaDoc

47. 4.2.5 Calendar si buget • Calendaruldesfasurariiproiectului, adicaperioadaîn care trebuieefectuata o anumitasarcina,cinetrebuie sa o efectueze si care va fi rezultatulmunciidinaceaetapa, cum vomevaluarezultatulaceleietape. • Bugetulalocat • Resurse, adica de ce avemnevoiepentru a realizaacestproiect: resurseumane, calculatoare, soft-uri, resurse de documentare,etc.

48. 4.2.6 Functiile produsului • Este de fapt o transpunere a diagramei cazurilor de utilizare. • Pentru fiecare actor vom determina functiile pe care acesta ar intentiona sa le utilizeze.

49. 4.2.7 Constrângeri non-functionale • Timp de raspuns • Garantareraspuns in timp real • Utlizareamemoriei • Utilizarearetelei • Utilizareascalabilitatii

50. Intrebari? Va multumesc !