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

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

1.1 De ce inginerie software ?

Pentru a se trece

de la dezvoltarea ad-hoc si imprevizibila

la

o dezvoltare strucurata, constructiva si sistematica

Istorie Programarea modulara Pascal

Programarea orientata obiect C++/Java

Programarea cu ajutorul componentelor Entreprise Java Beans

Criza dezvoltarii software Erori grave • Sonde spatiale pierdute (Venus

’60, Marte 99)• Criza rachetelor – Cuba 1979• Rachetele Patriot 1991• Primul zbor Ariane 5 1996 artificii

de 5 miliarde $ • Aeroportul Denver 1994-1996• Anul 2000• Incidente în fiecare luna - bursa din Tokyo … - accidente de circulatie

Proiectarea software • Livrarea în întârziere a tuturor

proiectelor • Cost mult ridicat fata de cel

prevazut • Livrarea unui produs de proasta

calitate• Esuarea în majoritatea cazurilor • Studiu american din 1995 : 81

miliarde $ / an datorat esecului software

Constructia podurilor 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

Ingineria civila • Esecuri mai putine• Surparea unui pod este foarte

perculoasa pentru oameni• O experienta de mai multe

milenii• Un pod stricat în general nu se

repara ci se reconstruieste • Podul rezista la 99% din conditii • Daca un pod este inutilizabil

atunci schimbam traseele drumurilor

1.2 Definitia Ingineriei Software Disciplina ( = metode, tehnici, utilitare ) bazata pe cunostinte (teorie) pe cunostinta de a face, produce ceva (pragmatica) si de a face sa se stie (comunicare) pentru a produce

(dezvoltare) în mod industrial (marime) aplicatii software

(produse) de cea mai buna calitate

2.Ciclul de viata al unui produs software

Cum se va desfasura proiectul de la Inginerie Software ?

Întâlniri la EC101, EG405 … Craciunul Sesiunea … criza de timp, iadul studentesc

….

2.1Cum se desfasoara în general un proiect ? Entuziasm general la început Un punct de criza în care se constientizeaza ca proiectul nu

poate fi predat la timp Spre sfârsit : un volum de munca impresionant (24h/24h),

resurse umane suplimentare (colegul de camera de anul 2), tensiune si relatii încordate

Acest ciclu se repeta si în marile companii de soft la primele proiecte realizate de catre o companie.Principala cauza este incapacitatea de planificare si gestionare a resurselor (timp, oameni, documentatie, utilitare, cunostinte, etc) .

2.2 Asa da, asa nu

10

Punct de criza

Termen de predare

Efort

Pas 1 Pas 2 Pas 3

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 : 1. Culegerea de specificatii2. Analiza3. Proiectarea4. Implementarea si Testarea 5. Validare si Integrare6. Calificare7. Punerea în functiune 8. Mentinerea 9. Retragerea sau înlocuirea

2.3.1 Culegerea de informatii Definirea problemei, adica a ceea ce se da în

problema, a resurselor de care dispunem (alte sisteme informatice sau BD pe care le putem utiliza, tehnici utilizabile, persoane care ar putea lucra, etc)

Specificarea detaliata a functionalitatilor ce trebuiesc suportate de catre sistemul informatic (adica realizarea diagramei de cazuri de utilizare)

Este de fapt realizata prin caietul de sarcini

Analiza functionala (vezi Curs 2 UML)

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.

2.3.1.2 Definirea necesitatilor Un caiet de sarcini este stabilit de catre

client în colaborare cu utilizatorul si dezvoltatorul :

- descrierea functionalitatilor asteptate de la aplicatie;

- constrângeri non-functionale (timp de raspuns, utlizarea memoriei, etc );

- posibilitatea utilizarii Diagramei de Cazuri de utilizare;

Rezultatul acestei etape : Caietul de sarcini

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.

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 ;

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)

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 )

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 ;

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

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

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.

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 panaRezultate Raportul de anomalii

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

….

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

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

3.1 Modelul în cascada Analiza necesitatilor

Specificatii functionale

Planificare

Concepere

Implementare

Integrare

Calificare

Exploatare

Retragere

Modificarea

necesitatilor

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

3.2 Modelul în V Specificatii functionale

si planificare

Conceptie globala

Conceptie detaliata

Programare

Teste unitare

Integrare

Calificare

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

Mini-concluzie

Clientul încearca prototipul

« Ascultarea » clientului

Construirea sau ameliorarea prototipului

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

3.4 RUP Rational Unified Process

Definitii Initiere : este faza în care se :- Stabileste domeniul proiectului;- Stabilesc criteriile pentru validarea reusitei;- Evalueaza riscurile;- Estimeaza resurselor necesare;- Un grafic de executie preliminar,raportat la cele patru

faze principale. Elaborare :stabilirea unei arhitecturi robuste,adica se

realizeaza planul proiectului si se elimina factorii de risc majori.

Constructie : în mod iterativ si incremental se va implementa un produs complet.

Tranzitie : softul este livrat utilizatorilor pentru testarea ( versiune beta a sistemului )

Faze de dezvoltare

timp

Obiective(Viziune)

Arhitectura Capacitate operationala initiala

Initiere Elaborare Constructie Tranzitie

Produs fabricat

Elemente RUP

Detaliu Workflow: Analiza problemeiWorkflow: cerinte

Activities Workers Artefactos

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

3.6. XP EXtreming Programming • Este recomandabila

pentru echipele de maxim 10 persoane

• 4 valori :• Comunicare• Simplitate• Feedback• Curaj

4.Caietul de sarcini Ce este un caiet de sarcini ? Structura 1. Introducere 2. Organizarea proiectului 3. Gestiune 4. Tehnici 5. Calendar si Buget 6. Functiile produsului 7. Constângeri non-functionale

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 În cazul 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.

4.2.1 Introducere Rezumatul contine o descriere detaliata a aplicatiei,

asupra scopului aplicatiei respective, a directiilor de cercetare pentru atingerea obiectivelor aplicatiei si alte amanunte considerate esentiale în întelegerea aplicatiei .

Materiale ce trebuiesc livrate clientului, adica produsul soft, bibliotecile asociate, documentatie tehnica, manualul utilizatorului,etc.

Definitii si acronime . Gânditi-va ca un client poate nu va pricepe tot ceea veti scrie în acest caiet, mai ales termenii specifici.În aceasta rubrica aveti sansa sa faceti cunoscut limbajul utilizat.

4.2.2 Organizarea proiectului

Stabilirea etapelor de dezvoltare

Stabilirea relatiilor dintre diferitele etape de dezvoltare

Distribuirea sarcinilor(adica ce sarcina are fiecare)

Etapa Functionalitati

Microsoft Office Project: Editor si utilitar pentru organizarea task-urilor

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

4.2.4 Tehnici Metode si utilitare utilizate - Metode si utilitare utilizate în proiectare- Metode si utilitare utilizate în dezvoltare- Metode si utilitare utilizate în crearea documentatiei - Metode si utilitare utilizate în testare- Metode si utilitare utilizate în integrarea modulelor- Utilitar pentru asigurarea gestiunii proiectului

Documentatie - Documentatia utilizata pentru folosirea metodelor si

utilitarele de mai sus - Documentatia proiectului (JavaDoc sau Doxygen) http://www.stack.nl/%7Edimitri/doxygen/index.html Doxygen http://java.sun.com/j2se/javadoc/ JavaDoc

4.2.5 Calendar si buget Calendarul desfasurarii proiectului, adica

perioada în care trebuie efectuata o anumita sarcina,cine trebuie sa o efectueze si care va fi rezultatul muncii din acea etapa, cum vom evalua rezultatul acelei etape.

Bugetul alocat Resurse, adica de ce avem nevoie pentru a realiza

acest proiect: resurse umane, calculatoare, soft-uri, resurse de documentare,etc.

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.

4.2.7 Constrângeri non-functionale Timp de raspuns Garantare raspuns in timp real Utlizarea memoriei Utilizarea retelei Utilizarea scalabilitatii

Intrebari?

Va multumesc !