3. managementul proiectelor informatice complexe

8/11/2019 3. Managementul Proiectelor Informatice Complexe

1/80

Modulul: Managementul proiectelor

informatice complexe

Constanta Bodea

Gheorghe Sabau

Claudia Georgeta Cirstea


2/80

Obiectivul modului

Obiectivul modului este de a pregati

studentii in managmentul unui proiectinformatic complex, alegerea modelului de

dezvoltare, organizarea proiectului, a

echipei, elaborarea planului proiectului,cunoasterea consturilor, stabilirea pretului

pentru produsul software.


3/80

Tematica

Notiunea de proiect si de proiectcomplex

Tipuri de proiecte informatice

Ciclul de viata al unui proiect informatic

Managementul unui proiect informatic Maturitatea organizatiilor de realizare a

produselor software


4/80

Notiunea de proiect.

Proiect complex


5/80

Proiect complex

Mai multe entitati organizationale

Mai multe tipuri de expertiza tehnica, mai multe categoriide specialisti in echipa de proiect

Reclama utilizarea unei multitudini de metode siinstrumente de managementul proiectelor

Un buget si o perioada de executie semnificative.


6/80

Tipuri de proiecte informatice - exemple

Proiecte organizationale (organizarea/ reorganizarea unuidepartament IT, infiintare companie IT)

Proiecte de dezvoltare software

Proiecte de implementare pachete software

Proiecte de realizarea retea locala de calculatoare

Proiecte de audit informatic

Proiecte de achizitie calculatoare


7/80

Ciclul de viata al unui

proiect informatic


8/80

Dezvoltarea sistemelor software

modele de realizare Programare & Testare

Cascada

Cu suprapunere Cu subproiecte

Realizare evolutiva Pe baza de prototip

stadiala Realizare secventiala

Realizare in spirala


9/80

Modelul Programare & Testare

Development/QA

Release

Requirements

Avantaje

-birocratie scazuta-ciclu rapid de realizare

-cerinte scazute de planificare

-complexiate scazuta


10/80

Modelul in cascada (normal)

Requirements

Design

Development

QA/Test

Release

Requirements Document

Design Document

Code

Test Plans

Test Cases

Avantaje:

-se potriveste pentru proiecte mari

-se asigura o buna documentare a procesulelor

Dezavantaje

-srtuctura birocratica de coordonare

-ciclu lent


11/80

Modelul in cascada cu subproiecte

Requirements

Design

DevelopmentQA/Test

Release


Design Document

Code

Test Plans

Test Cases

Module1

Development

QA/Test

Module2

DevelopmentQA/Test

Module3


12/80

Modelul in cascada cu

suprapunerea fazelor

Requirements

Design

Development

QA/Test

ReleaseRequirements Document

Design Document

Code Test Plans

Test Cases


13/80

Modelul de dezvoltare pe baza de

prototip

Requirements

Design

Development

Release


Code

Design Document


14/80

Modelul stadial

Requirements

Design

DevelopmentAlpha Release


Design Document

Code

Test Plans

Test Cases

QA/Test

Beta Release

QA/Test

Final Release


15/80

Modelul de realizare secventiala

Requirements

Design

Development QA/Test Release


Design Document

Code

Test Plans

Test Cases

Development

Development

QA/Test Release

QA/Test Release


16/80

Modelul in spirala

Design

Development

QA/Test

ReleaseRequirements

DesignDevelopment

QA/Test

Design

Development

QA/Test

Design

Development

QA/Test

Design

Development

QA/Test


17/80

Compararea modelelor

C&F Waterfall RAD Spiral

Overhead L H M M/HSize S L M M

Time S L S/M M

Complexity S L M M/LBudget S L M M


18/80

Managementul

cerintelor


19/80

Documentarea cerintelor

Pentru clienti/pentru echipa de dezvoltare

Specificatii functionale

Pentru echipa de dezvoltare


20/80

Documentarea cerintelor-structura1. Introduction

- need for the software program, context, brief functionality.

2. Hardware-special hardware, minimal, optimal configurations.

3. Conceptual model

- high level view of the software program4. Functional Requirements

-services provided to the user

5. Database Requirements-logical organization of the data

6. NonFunctional Requirements

-other functionality that the software program should have (speed, size, ease of use,reliability,rebustness, portability)

7. Maintenance/evolution-anticipated changes due to hardware evolution, changing user needs

8. Glossary-technical terms used

9. Index


21/80

Documentarea cerintelor-stilul de

redactare Propozitii scurte Numar de referinta si descriere

Diagrame pentru descrieri complexe

Termeni precis definiti

Paragrafe scurte

Titluri si subtitluri

Corect gramatical


22/80

Comunicare -

Raportare


23/80

Ocuparea timpului de lucru adezvoltatorului de software

50

35

15

Programare

Comunicarea cumembri echipei

Instruire/Dezvoltare


24/80

Raportare/Comunicare

PM

Management executiv

Reports, presentations, meetings, Q&A

Echipa

Meetings, Action Items, CC, Minutes, Q&A

Clienti

Requirements, visits,

demos, Q&A,

development updates,

tests


25/80

Proiectare software


26/80

Architectura

De ansamblu Functionala

Orientata obiect

Documentarea proiectarii De detaliu

UML

GeneralitatiDiagrame


27/80

Diagrama de architectura

HTML GUI

WMLGUI

SQL Database

ServerWAP

Terminal

Web

Terminal

JDBC

HTML

WML Template

files

ASCII


28/80

Arii functionale standard Interfete externe Interfata utilizator Organizarea bazei de date Memorarea datelor

Algoritmi cheie Managementul memoriei Concurenta Securitate Localizare

Distribuire in retea Portability Limbaje de programare Tratarea erorilor


29/80

Proiectarea detaliata

Formal

Design Approach

Formal

Design Approach

Very Formal

Design Approach

Informal

Design Approach

Pe fiecare subrogram/modul

Complexitate

proiect

Experienta

programator

HIGHLOW

HIGH

LOW


30/80

Diagrame UML

Diagrama cazurilor de utilizare Diagrame statice de structura

Class/Object Diagram

Diagrame de comportament Interaction Diagrams

Sequence diagram

Statechart Diagrams

Activity Diagrams Diagrame de implementare

Component Diagram

Deployment Diagram


31/80

Use Case Diagram

CheckGrade

Register

Classes

Database

Query

Authorize

Student

Input

Grades

Student

Professor

Registrar

Staff

Max

Credits

Include

Generalization

Use Case


32/80

Class Diagram

Student

name : String

address : String

ID : Long IntegerisCurrent():String

Graduate

department: String

isCurrent():String

Catalog Entry

exam date : Date

grade : String

passed():Boolean

Classsubject : String

professor : String

gradedPNP():String

1*

*

1

If CatalogEntry.Student.isCurrent is n

then Catalog.Entry.grade must be N

Multiplicity: mandatory

Association

Generalization

Class

ConstraintUndergraduate

major: String

isCurrent():String

Job0..1 Multiplicity:

optional

Attribute

Operation

Multiplicity:

Many-valued

Navigability


33/80

Object/Class Diagrams

Employee

name

Male

Female

Developer

QA/Test

DesignJob

Sex

{complete}Discriminator

Manager Software: MGMT

name = Name

MGMT*

1

Software PM: MGMT

name = Name

QA Manager: MGMT

name = Name

Software PM: MGMT

name = Name

Engineer: Developer

name = Name

Engineer: Design

name = Name

Engineer: QA/Test

name = Name

Engineer: Developer

name = Name

Object Diagramshowing instances of

the above class diagram

Class Diagramwith Multiple and

Dynamic Classification

Sex: M/F

Sex: M/F

Sex: M/FSex: M/FSex: M/FSex: M/F

Sex: M/F Sex: M/F


34/80

Statechart Diagram

State C

State BState A

State D

Trigger

condition

A to B

Trigger

condition

B to D

Trigger

condition

C to ATrigger

condition

C to B

Trigger

condition

B to C

start

self-transition

transition

state


35/80

Sequence Diagram

Initiate

request Init servletnew Gdocument();

Connect to the database

servlet.setDomaine();servletgetConnection();

HTTP request on the server

TCP/IP port 80

Database call

prepareStatement()

executeQuerry()

Response to the

SQL requestDatabasecall return

Read data

getString();

Generate HTML output

doc.p();

HTML return

return();Display

WEB page

Web Client Web Server Database


36/80

Activity Diagram

Present

lecture

Prepare

slidesTurn on

the projector

Tune the

projector

[found projector]

[no projector]

Use

blackboard

Begin

lecture

Start

Fork

Join

End


37/80

Component Diagram

WML Interface

Search Engine

Database

query


38/80

Deployment Diagram

WAP Terminal

WML Interface

Server Search Engine

Database

query

Component

Communication

Interface

Application

Connection

Contained object(s)

Node


39/80

Planificarea

calendaristica si a

costurilor


40/80

Work Breakdown StructureWBS

Analiza drumului critic - ADC

Tehnica diagramelor GANTT

Jaloane

Tehnici pentru identificarea si

documentarea rolurilor in proiecte


41/80

Metode si instrumente de baza

Work Breakdown StructureWBS

Analiza drumului critic - ADC

Tehnica diagramelor GANTT

Jaloane

Metoda Earned Value


42/80

WBSTehnica de grupare a activitatilor pe pachete in raport de

rezultate pe diferite niveluri de detaliere prin care se asigura

organizarea si definirea completa a sferei de cuprindere a

proiectului.

Are asociata o reprezentare grafica de tip arbore si un

dictionar al specificatiilor pachetelor.

Nivelul 0: un pachet, reprezentand intregul proiect.

Nivelul 1: Uzual, 5-7 pachete de activitati, care acopera, de

regula, diferitele faze din ciclul de viata al proiectului. Exista,in mod obligatoriu, un pachet pentru managementul

proiectului.

Nivelul 2: Fiecare pachet din nivelul 1 se detaliaza in 5-7

pachete de nivel 2, dupa rezultatele activitatilor s.a.m.d.


43/80

0. Implementare de sistem

1. Analiza 2. Proiectare siConstructie

3. Tranzitia catre

Productie4. Managementul

proiectului

1.1 Definire cerinte

de Business

1.2 Definire

Arhitectura Tehnica

1.2 Definire Acces la

date

2.1 Colectarea datelor

din sistemele GL

2.2 Proiectarea sirealizarea accesului la

date

2.3 Proiectarea si

Constructia BD

Consolidate

2.4 Documentatie

3.1 Testare

3.2 Instruire

3.3 Pregatire Platforma

Productie / Lansare

Productie

4.1Demarare

4.2 Planificare

4.3 Coordonare

4.4 Control

4.5 Terminare

WBS -exemplu


44/80

0. Implementare de sistem

1. Analiza 2. Proiectare siConstructie

3. Tranzitia catre

Productie4. Managementul

proiectului

1.1 Definire cerinte

de Business

1.2 Definire

Arhitectura Tehnica

1.2 Definire Acces la

date

2.1 Colectarea datelor

din sistemele GL

2.2 Proiectarea sirealizarea accesului la

date

2.3 Proiectarea si

Constructia BD

Consolidate

2.4 Documentatie

3.1 Testare

3.2 Instruire

3.3 Pregatire Platforma

Productie / Lansare

Productie

4.1Demarare

4.2 Planificare

4.3 Coordonare

4.4 Control

4.5 Terminare

WBS -exemplu


45/80


46/80

Planul jaloanelor

Denumire jalon Data planificat

Demararea proiectului 1.06.2004

Obinerea schielor de proiect 31.08.2004

Finalizarea reelelor tehnice 31.05.2005

Terminarea proiectului 31.10.2005


47/80

Managementul costurilor

Managementul costurilor proiectelor presupune:

- Estimarea costurilor, prin tehnici de estimare - Planificarea costurilor, prin tehnici de bugetare

- Controlul costurilor, prin metoda Earned Value


48/80

Indicatorii metodei Earned Value

Costul planificat al activitilor programate

(BCWS - Budget Cost of Work Scheduled)

Suma estimrilor de cost aprobate, pentru activitile sau

prile de activitate planificate a fi realizate ntr-operioad dat. Se utilizeaz i denumirea de costconform bugetului pentru activitile programate.

Costul planificat al activitilor realizate

(BCWP - Budget Cost of Work Performed)Suma estimrilor de cost aprobate pentru activitile sauprile de activitate realizate ntr-o perioad dat. Seutilizeaz i denumirea de cost conform bugetului pentruactivitile realizate.


49/80

Costul total estimat la terminare

(EAC - Estimate at completion)Costul total estimat pentru o activitate, grup de activiti sauproiect, la momentul finalizrii sale. De regul, se recurge laajustarea estimrii iniiale a costului, pe baza nivelului deexecuie al proiectului la momentul respectiv.

Costul estimat pentru terminare

(ETC - Estimate to complete)

Costul adiional la costul curent preconizat a fi necesar pentrufinalizarea unei activiti, grup de activiti sau a unui proiect.Cele mai multe tehnici pentru realizarea acestei estimriinclud ajustri ale estimrii iniiale a costului pe baza nivelului

de execuie a proiectului la momentul respectiv. Costul efectiv al activitilor realizate

(ACWP - Actual cost of work performed)

Costurile totale (directe i indirecte) ocazionate de realizareaunor activiti pe parcursul unei perioade date.


50/80

EAC

BAC

Diferen datoratcostului

BCWS

ACWP

Momentul actual

Unitate monetar

Timp

BCWP (EV)

Diferen datorat

ntrzierii

Diferen final

estimat


51/80

Indice de performan a costului

(CPI - Cost Performance Index)

Raportul dintre costul planificat i costul efectiv. Exprim

mrimea relativ a depirii costurilor.

Indice de performan a planului

(SPI - Schedule performance index -)

Raportul dintre costul planificat al activitilor realizate icostul planificat al activitilor programate.

Analiza


52/80

timp

cost

uri BCWS

ACWP

BCWP


53/80

timp

co

sturi BCWS

ACWP

BCWP


54/80

timp

cost

uri BCWS

ACWP

BCWP


55/80

Metode de estimare

Estimari ale expertilor/echipei

Algoritmice

Pe baza de regresie: COCOMO


56/80

Estimari COCOMOOrganic mode

-small teams-familiar environment-familiar applications

Semi-detached mode-experienced andinexperienced staff

Embedded mode

-tight constraints-complex projects

PM = 2.4(KDSI)1.05

TDEV = 2.5(PM)0.38

PM = 3.4(KDSI)1.12

TDEV = 2.5(PM)0.35

PM = 3.6(KDSI)1.20

TDEV = 2.5(PM)0.32

KDSI = number of thousands delivered instructionsPM = number of persons monthTDEV = development time (months)

N = (PM/TDEV) number of personnel


57/80

Exemplu

Pentru un proiect de 50.000 instructiuni,

modul organic:

PM = 2.4(50)1.05 = 146 p.m.

TDEV = 2.5(146)0.38 = 17 luni

N = (PM/TDEV) = (146/17) = 9 persoane


58/80

Asigurarea calitatii

software /Testare


59/80

Aspecte organizatorice ale testarii

Asigurarea calitatii

Planuri de testare Cazurile de test


60/80

Procesul de testare

Function testingModule testing

Subprogram testing

Program testing

Acceptance testing


61/80

Echipa redusa pentru asigurarea

calitatii

TL/QA Lead

Test Engineer

Developer Developer

PM

-QA/Test este parte a echipei de dezvoltare


62/80

Echipa de dimensiuni medii pentru

asigurarea calitatii

Developer Developer

PM

Development Team Leader

Test Engineer Test Engineer

QA leader


63/80

Echipa de dimensiuni mari pentru

asigurarea calitatii

QA Manager

Test Engineer Test Engineer

PM PM

Development

Manager


64/80

Procesul de asigurare a calitatii

Unit testing Developer Subroutine, module, class,

informallySource-code testing

Technical reviews

Program testing

Developer

Development team

Test/QA team

Line by line in a debugger

Walk through inspection,

code reading

Test plan/Test cases

Integration testing Developer of thenew code

Process Responsabil Descriere

Test of the module after theinsertion of the new code


65/80

Plan de testare - template Overview - architecture of the program under test, test approach, goals, methodologies,

arguments

Definition - table: terms and acronyms related to the testing plan

Bounds

Scope- what will be tested and what not

Setting- location where the test will be performed

Quality risks

Component testing - states, transactions, data flow, functionality, UI

Integration testing -APIs, error handling, functionality, UI, performance

System and acceptance testing - states, transactions, data flow coverage, functionality, UI,

error handling, operations, reliability, date/time, localization, installation and configurationoptions, compatibility, documentation

Proposed schedule/milestones - milestones from the Gantt chart (high level

deliverables)

Test Development and Configuration - Test plan complete, Test lab configured, Test suite

complete

Testing - Phases - Test cycles


66/80

Tracking

test tracking - list to manage the test cases, and the way the process is

documented Test suites table- sequence of test case for all the test suites

defect tracking - tool/database, classification and the way communication

occurs (dev team, QA, mgmt)

Phases (1,2,3,4,5) - for each phase, the criteria essential for

beginning/completing various test phases

Release management - how a software component should be identified

release (revision) number- compatibility, os version, tested/not testes, test

phase/cycle

Risks and contingencies

training needs

availability of additional development support

Change history - changes and revisions made to the test plan

Referenced documents


67/80

Cazurile de test

Use Case Test - against a/several given usage/s System & Acceptance Test - program as a whole,

real data

Functional Test - functionality (module, program)

Structural Test - driven by the structure of the

program Boundary Test - test the boundary conditions

Requirements-based Test - test against the originalrequirements

Behavioral Test - a set of possible user actions

Fault-based Test - error input response Regression Test - re-testing


68/80

Testare distribuita

A

B

A B AB

BA

A and B test

different

conditions

A and B test

the same

conditions

A and B testsome similar

conditions andsome

independent

A testconditions

coverB tests

conditions


69/80

Echipa de

dezvoltare software


70/80

Avantajele lucrului in echipa

furnizeaz opinii i cunotine pentru problemecomplexe ;

reprezint un bun mediu de nvare;

sunt mult mai orientate ctre obiective; valorific mai bine resursele individuale; pot fi mai uor formate, dizolvate, reorganizate; cultiv loialitatea; favorizeaz delegarea; controleaz comportamentul prin norme proprii.


71/80

Neajunsurile lucrului in echipa

consum timp;

par confuze, dezordonate, scpate de sub control;

pot cauza confuzii de roluri; sunt percepute negativ de cei care apreciaz

ordinea i controlul;

necesit transformarea oamenilor;

au nevoie de timp pentru a produce efecte.


72/80

Tipuri de echipe

echipe specializate n rezolvarea unor

probleme;

echipe autoconduse;

echipe interfuncionale.


73/80

Ciclul de viata al unei echipe

Modelul Tuckman:

constituirea (formarea);

furtuna (rbufnirea);

normalizarea (normarea);

funcionarea (performana);

suspendarea (desfiinarea).


74/80

Roluri in echipa

conductorul;

adjunctul;

nonconformistul; evaluatorul;

muncitorul;

investigatorul; coechipierul;

finalizatorul.


75/80

Matricea de asignare a

responsabilitatilor

Tehnica prin care elementele din structura

organizatorica a proiectului sunt asociate

cu elemente din structura detaliatorientat pe activiti, astfel incat sa se

garanteze faptul c exist o persoan

responsabil pentru fiecare pachet de

activitati.


76/80

Matricea de asignare a

responsabilitatilor - exempluRoluri si elemente de mediu

Denumirea pachetului de activitati ProprietarulProiectului

Managerulp

roiectului

ArhitectdeS

istem

AnalistProg

ramator

AnalistFinanciar

SuportTehn

ic

1.Analiza

1.1 Definire Cerinte de Business C C R

1.2 Definire Arhitectura Tehnica R C

1.3 Definire Acces la Date R C

2. Proiectare si Constructie

2.1 Colectare date din sistemele GL R C

2.2 Proiectarea si Constructia Accesului la DateR C

2.3 Proiectarea si Constructia BD Consolidate R C

2.4 Documentatie R C

3. Tranzitia catre Productie

3.1 Testare C R

3.2 Instruire R

3.3 Pregatire Platforma Productie / Lansare Productie R

4. Management de proiect C R

Versiune:1.1

Managerl Executiv


77/80

client

Coordonator Proiect din partea clientului

Manager Financiar

client

Manager IT / MIS

client

Analist Financiar Suport Tehnic

Manager de Proiect

Arhitect de sistem

Analist Programator

Manager partener

Echi pa de proiect

Manager echipa consultanti

implementator

Manager executiv

implementator


78/80

Referinte


79/80

References

Sabau Gh, Lungu ISistemeinformatice pentru conducere, EdituraEconomica, bucuresti 2004

Asociaia Project Management RomniaManagementul proiectelor. Glosar,Editura Economic, Bucureti, 2002.

PMIPMBOK Guide,A Guide to theProject Management Body ofKnowledge, draft 2003.


80/80

References

IPMAInternational CompetenceBaseline, 2000,http://ipma.kingsquare.nl/?page=155.

3. managementul proiectelor informatice complexe

Documents