Managementul si dezvoltarea proiectelor software

UNIT 1. Managementul proiectelor

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 ntrziere 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 civila
Esecuri mai putine Surparea unui pod este foarte perculoasa pentru oameni

Ingineria software
Sistemele informatice devin foarte repede extrem de complexe Esecuri foarte numeroase Craparea este un fenomen des ntlnit 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

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 pe cunostinta de a face,produce ceva si de a face sa se stie pentru a produce n mod industrial aplicatii software (teorie) (pragmatica) (comunicare) (dezvoltare) (marime) (produse)

de cea mai buna calitate

2.Ciclul de viata al unui produs software

Cum se va desfasura proiectul de la Inginerie Software ?

ntlniri la 3F, C15, Zambara Craciunul , deci nu facem nimic Sesiunea . Oau , mi se nvrte totul n cap 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 sfrsit : un volum de munca impresionabil (24h/24h), resurse umane suplimentare (colegul de camera de anul 4), 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

Punct de criza Termen de predare

Efort
10

Pas 1

Pas 2

Pas 3

2.3 Ciclul de viata optim pentru derularea unui proiect

1. 2. 3. 4. 5. 6. 7. 8. 9. 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

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; - constrngeri 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; - constrngeri 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, ntrzieri, 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, constrngeri 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 nct 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 pana Rezultate Raportul de anomalii

2.3.7 Punerea n functiune

Livrarea produsului final Instalarea produsului la client Sfrsit 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 Modificarea necesitatilor

Planificare Concepere Implementare Integrare Calificare

Exploatare Retragere

Problemele modelului n cascada

Proiectele adevarate rar urmeaza o dezvoltare secventiala Este dificil a stabili toate necesitatile proiectului la nceputul sau Produsele soft dezvoltate urmnd un model n cascada apar de cele mai multe ori cu ntrziere Acest model este aplicabil pentru proiectele care sunt bine ntelese

3.2 Modelul n V
Specificatii functionale si planificare

Calificare

Conceptie globala

Integrare

Conceptie detaliata

Teste unitare

Programare

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 trziu

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

Workflow= disciplina

Definitii
Initiere : este faza n care se : Stabileste domeniul proiectului; Stabilesc criteriile pentru stabilirea reusitei; Evalueaza riscurilor; 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 : sosftul este livrat utilizatorilor pentru testarea ( versiune beta a sistemului )

Faze de dezvoltare

Initiere

Elaborare

Constructie

Tranzitie

Obiective (Viziune)

Arhitectura

Capacitate operationala initiala

Produs fabricat

timp

Elemente RUP

Workflow: Requirements

Workflow Detail:Analyse the Problem

Workers

Activities

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 recomndabila 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.Constngeri 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. Pna aum n majoritatea cazurilor studentii s-au confruntat cu probleme simple a caror rezolvare se rezuma la maxim cteva 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 TimisoaraBudapesta, 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 . Gnditi-va ca un client poate nu va

pricepe tot ceea ve-ti 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

Etapa

Functionalitati

Distribuirea sarcinilor (adica ce sarcina are fiecare)

Microsoft Office Project

Editor si utilitar pentru organizarea taskurilor

4.2.3 Gestiune
Obiective si prioritati Ipoteze,dependente si constrngeri 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 utilitarea 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 Constrngeri non-functionale

Va multumesc !