managementul si dezvoltarea pro duselor software

Managementul si Managementul si dezvoltarea dezvoltarea proproduselorduselor software software

HOSTIUC IULIANgrupa 341C5

[email protected]

CuprinsCuprins IstoricCiclul de viata al unui produs

software Modele de dezvoltare software

Integrarea Sistemelor Informatice (2010-2011)

1. 1. IstoriIstoricc Programarea modulara PascalPascal

Programarea orientata obiect C++/JavaC++/Java

Programarea cu ajutorul componentelor

Entreprise Java BeansEntreprise Java Beans


Criza dezvoltarii software 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 Constructia podurilor si dezvoltarea software 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


2.12.1 Cum se desfasoara în general un Cum se desfasoara în general un proiect ?proiect ?Entuziasm general la începutUn punct de criza în care se constientizeaza ca

proiectul nu poate fi predat la timp Spre sfârsit : un volum de munca impresionabil

(24h/24h), resurse umane suplimentare, 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 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 2.3 Ciclul de viata optim pentru derularea unui proiectunui 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 2.3.1 Culegerea de informatii 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)

Realizata prin caietul de sarciniAnaliza functionala


2.3.1.1.Stabilirea 2.3.1.1.Stabilirea obiectivelorobiectivelorSe 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 2.3.1.2 Definirea necesitatilor 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 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 2.3.2.1 Analiza necesitatilor 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 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 si faza de 2.3.3 Proiectarea si faza de concepere 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 Implementarea2.3.4 ImplementareaAlegerea 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


2.3.4.1 Testarea 2.3.4.1 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.

Testarea întregii aplicatii este o alta etapa din ciclul de viata si trebuie facuta aceasta distinctie.

Rezultate Module testate Rezultatele testarilor unitare


2.3.5 Integrarea si validarea 2.3.5 Integrarea si validarea aplicatieiaplicatieiFiecare 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.Integrarea Sistemelor Informatice

(2010-2011)

2.3.6 Calificarea 2.3.6 Calificarea produsului soft produsului soft Teste de amploare realizate în

conditii normale de utilizare.Teste non-functionale - Teste de încarcare- Teste de tolerantaRezultate Raportul de anomalii


2.3.7 Punerea în functiune 2.3.7 Punerea în functiune Livrarea produsului finalInstalarea produsului la clientSfârsit sau nu ?!

….


2.3.8 Mentinerea aplicatiei 2.3.8 Mentinerea aplicatiei Raporturi de incidente sau

anomaliiCerere de modificari corective Cereri de evolutie a aplicatieiCod si documentatie modificataO noua serie de teste - Unitare- De integrare- Non – regresive


3. Modele ale ciclului de 3. Modele ale ciclului de viata viata Modelul în cascada Modelul în VRADRUP2TUPXP


3.1 Modelul în cascada 3.1 Modelul în cascada Analiza necesitatilor

Specificatii functionale

Planificare

Concepere

Implementare

Integrare

Calificare

Exploatare

Retragere

Modificarea

necesitatilor


Problemele modelului în Problemele modelului în cascada 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 3.2 Modelul în V

Specificatii functionale si planificare

Conceptie globala

Conceptie detaliata

Programare

Teste unitare

Integrare

Calificare


Comparatie Comparatie Modelul în V permite- O buna anticipare în dezvoltare- Evita întoarcereaDar - Cadrul de dezvoltare este foarte

rigid - Durata este adesea foarte lunga - Produsul soft apare adesea foarte

târziuIntegrarea Sistemelor Informatice

(2010-2011)

3.3 RAD 3.3 RAD Rapid Aplication DevelomentRapid Aplication Develoment Discutii si interactiuni cu utilizatorulVerificarea eficacitatii reale a unui

algoritmVerficarea specificatiei interfetei cu

utilizatorul (GUI) Metoda utilizata adesea pentru

stabilirea si identificarea necesitatilor

Utilizata adesea de catre generatoarele de coduri


3.4 RUP 3.4 RUP Rational Unified ProcessRational Unified Process


VVăă mul mulţţumesc ! umesc !

Intrebări?


managementul si dezvoltarea pro duselor software

Documents