3. SOFTWARE MANAGEMENT - dsi.unive.itcortesi/ingsw/l3.pdf · A.Cortesi Ingegneria del Software...

A.Cortesi Ingegneria del Software Slide 1

3. SOFTWARE MANAGEMENT

Introdurre caratteristiche e problematiche della direzione di progetto software (software management)Discutere la pianificazione di un progetto e latemporizzazione (scheduling)Presentare rappresentazioni grafiche della pianificazione di un progetto


Sono le attività necessarie per assicurare che un prodotto software sia sviluppato rispettando le scadenze fissate e risponda a determinati standardInterazione di aspetti economici e tecniciUn progetto diretto bene qualche volta fallisce, uno diretto male fallisce sicuramenteL’importanza dell’esperienza

Software project management


Che cos’è un progetto…

Un progetto è un insieme ben definito di attività cheha un inizioha una finerealizza un obiettivoè realizzato da un’equipe di personeutilizza un certo insieme di risorsenon è riconducibile a “routine”


Il prodotto software è “intangibile”: per valutare i progressi ci si deve basare sulla documentazioneL’ingegneria del software non è ancora riconosciuta come disciplina “solida”al pari dell’ingegneria meccanica, elettrica, Non ci sono standard per il processo di produzione softwareOgni progetto ha una storia a sé (problemi discheduling)

Problemi


I giocatori in campo...

Senior managersdefiniscono i termini economici del progetto

Project managerspianificano, motivano, organizzano e controllano lo sviluppo

Practitionershanno le competenze tecniche per realizzare il sistema

Customersspecificano i requisiti del software da sviluppare

End usersinteragiscono con il sistema una volta realizzato


Perché c’è bisogno di un team?

La maggior parte dei progetti software sono troppo impegnativi per essere realizzati da una sola persona


The mythical man/month

Perché non calcolare la “forza lavoro” in termini di mesi uomo necessari?

Persone/mese * Tempo allocato = Numero_Persone_Necessarie

Questa equazione non può essere utilizzata perché:

Alcuni compiti possono essere condivisi, altri noEsempio: raccogliere fragole vs. produrre un bambinooverhead necessario per il coordinamento e la comunicazione


Tipologie di team (1)Democratico Decentralizzato

Assenza di un leader permanenteConsenso di gruppo sulle soluzioni e sulla organizzazione del lavoro Comunicazione orizzontale

VantaggiAttitudine positiva a ricercare presto gli erroriFunziona bene per problemi “difficili” (ad esempio per la ricerca)

SvantaggiÈ difficile da imporre… Non è scalabile...


Tipologie di team (2)Controllato Decentralizzato

Un leader riconosciuto, che coordina il lavoroLa risoluzione dei problemi è di gruppo, ma l’implementazione delle soluzioni è assegnata a sottogruppi da parte del leaderComunicazione orizzontale nei sottogruppi e verticale con il leader


Tipologie di team (3)Controllato Centralizzato

Il team leader decide sulle soluzioni e sull’organizzazioneCounicazione verticale tra team leader e gli altri membri


Ruoli in un team Controllato Decentralizzato

Project Managerpianifica, coordina e supervisiona le attività del team

Technical staffconduce l’analisi e lo sviluppo (da 2 a 5 persone)

Backup engineersupporta il project manager ed è responsabile della validazione

Software librarianmantiene e controlla la documentazione, i listati del codice, i dati...


spazio condiviso & risultati condivisi

Un team deve prima di tutto decidere gli strumenti che permettono la cooperazione

La pianificazioneChi fa cosaLe scelte fatteCosa è stato fatto


Stesura della proposta di progettoStima del costo del progettoPianificazione (planning) e temporizzazione(scheduling)Monitoraggio e revisioni del progettoSelezione e valutazione del personaleStesura di rapporti e presentazioni

Le attività del project manager


Stimare i costi di un progetto

Dilaziona la stima fino a quando il progetto non è in stato avanzato di sviluppo- modello non praticabile: la stima dev’essere fatta

all’inizioBasa la stima su progetti simili già sviluppati- similarità di problemi, clienti, ecc.

Usa tecniche di decomposizione per generare stime di costo e di risorse necessarie- approccio “divide et impera”, calcolando il costo delle

componentiUsa uno o più modelli empirici- basati su dati storici, es. COnstructive COst MOdel

(Boehm, 1981)


Stime quantitative: LOC

KLOC = Migliaia di linee di codiceMetriche:

$ per KLOCerrori o difetti per KLOC LOC per mese/personapagine di documentazione per KLOCerrori/mese-persona$/pagina di documentazione

Il codice è il prodotto tangibile del processo di sviluppo, ed esiste già letteratura in propositoDipende dal linguaggio di programmazione e penalizza programmi scritti bene e concisi


Stime quantitative: FPFunction Points: la funzionalità offerta dall’applicazione, a partire dal dominio informativo e da un giudizio sulla complessità del software

Parametri Fattori di Peso Finumero di user inputs 3 4 6numero di user output 4 5 7numero di richieste 3 4 6numero di files 7 10 15numero di interfacce esterne 5 7 10

FP = totale * [0.65 + 0.01 * Σ Fi]dove gli Fi sono fattori di aggiustamento


LOC/FP

Linguaggio di programmazione LOC/FP mediaAssembler 320C 128Fortran 105Cobol 105Pascal 90Ada 70linguaggi orientati agli oggetti 30fogli di calcolo (spreadsheets) 6linguaggi grafici 4


Struttura del piano di progetto

1. Introduzione2. Organizatione del Progetto3. Processi Gestionali4. Processi Tecnici5. Pianificazione del lavoro, delle risorse umane e del

budget.


1. Introduzione

1.1 Overview del ProgettoDescrizione di massima del progetto e del prodotto.

1.2 Deliverables del ProgettoTutti gli items che saranno consegnati, con data e luogo di consegna

1.3 Evoluzione del SPMPPiani per cambiamenti ipotizzabili e non

1.4 Materiale di riferimentoLista dei documenti cui ci si riferisce nel SPMP

1.5 Definizioni e Abbreviazioni


2. Organizzazione del progetto

2.1 Modello del ProcessoRelazioni tra le varie fasi del processo

2.2 Struttura OrganizzativaGestione interna, chart dell’organizzazione

2.3 Interfacce OrganizzativeRelazioni con altre entità

2.4 Responsabilità di ProgettoPrincipali funzioni e attività; Di che natura sono?Chi ne è il responsabile ?


3. Processi gestionali

3.1 Obiettivi e Priorità3.2 Assunzioni, Dipendenze, Vincoli

Fattori esterni3.3 Gestione dei rischi

Identificazione, Valutazione, Monitoraggio dei rischi3.4 Meccanismi di monitoraggio e di controllo

Meccanismi di reporting, format, flussi di informazione, revisioni

3.5 Pianificazione dello staffSkill necessari (cosa?, quanto?, quando?)


4. Processi tecnici

4.1 Metodi, Strumenti e TecnicheSistemi di calcolo, metodi di sviluppo, struttura del team, ecc.Standards, linee guida, politiche.

4.2 Documentazione del SoftwarePiano di documentazione, che deve includere milestones, e revisioni

4.3 Funzionalità di supporto al progettoPianificazione della qualitàPianificazione della gestione delle configurazioni


5. Pianificazione del lavoro, delle risorse umane e del budget.

5.1 Work Packages (Work breakdown structure)Il progetto è scomposto in tasks; definizione di ciascun task

5.2 DipendenzeRelazioni di precedenza tra funzioni, attività e task

5.3 Risorse NecessarieStima delle risorse necessarie, in termini di personale, di tempo di computazione, di hardware particolare, di supporto software ecc.

5.4 Allocazione del Budget e delle RisorseAssocia ad ogni funzione, attività o task il costo relativo

5.5 Pianificazione Deadlines e Milestones


Analisi dei rischiIdentificazione dei rischi

legati alla taglia del prodotto da costruire o modificarelegati ai vincoli importi dal mercato o dal contrattolegati alle caratteristiche del clientelegati alla buona definizione del processolegati all’ambiente di sviluppo (qualità e affidabilità degli strumenti)legati alla complessità del sistema da costruire e alle novità tecnologiche legate al sistemalegati alla dimensione e all’esperienza del team di sviluppo

Sviluppare una tabella: probabilità e impattoStrategia di gestione: evitare/monitorare/gestire


Pianificazione del lavoro

p:Project

f1:Function

f2:Function

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task


Attività

Unità principali di lavoro, con date di consegna precise

Culminano in una milestone

Scomponibili in una serie di tasks

p:Project

f1:Function

f2:Function

a1:Activity a2:Activity

a2.1:Activity a2.2:Activity

t1:Task t2:Task t3:Task


Organizzazione delle attività

In un progetto le attività devono essere organizzate in modo da produrre risultati valutabili dal managementMilestones sono i punti finali di ogni singola attività di processoDeliverables sono i risultati che sono forniti al committenteIl modello a cascata suggerisce una definizione ovvia di “milestone”


Milestones & deliverables

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��Evaluation

report

��Prototype

development

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��Requirements

definition

��Requirements

analysis

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��Feasibility

report

��Feasibility

study

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��Architectural

design

��Design

study

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��Requirements

specification

��Requirements

specification

ACTIVITIES

MILESTONES


Funzioni

Actività o insiemi di attività che coprono tutta la durata del progetto

Project managementConfiguration ManagementDocumentationQuality Control (Verification and validation)Training


Tasks

Unità di lavoro “atomiche”Hanno durata stimabile, necessitano di certe risorse, producono risultati tangibili (documentazione, codice, ...)

Specifica di un task: Work packageNome e descrizione del lavoro che deve essere fattoPrecondizioni per poter avviare il lavoro, durata, risorse necessarieRisultato del lavoro e criteri di accettabilitàRischi


Scheduling di progetto

Dividi il progetto in attività e mansioni (tasks) estima il tempo e le risorse necessarie per completare ogni singola mansioneOrganizza le mansioni in modo concorrente, per ottimizzare la forza lavoroMinimizza la dipendenza tra le singole mansioni per evitare ritardi dovuti all’attesa del completamento di un’altra mansioneSono necessari intuito ed esperienza


Problemi nello scheduling

E’ difficile stimare la difficoltà dei problemi ed il costo di sviluppo di una soluzioneLa produttività non è proporzionale al numero di persone che lavorano su una singola mansione Aggiungere personale in un progetto in ritardo può aumentare ancora di più il ritardoImprevisti succedono sempre...


Grafico a barre, grafo delle attività e diagramma di Gannt

Diversi tipi di rappresentazione grafica delloscheduling del progettoMostrano la suddivisione del lavoro in mansioni. Le mansioni non devono essere troppo piccole (una settimana o due di lavoro)Il grafo delle attività evidenzia le dipendenze e il cammino criticoIl grafico a barre mostra lo scheduling come calendario lavoriIl diagramma di Gannt per la temporizzazione


Mansioni: durata e dipendenze

Mansioni Durata (giorni) DipendenzeT1 8T2 15T3 15 T1T4 10T5 10 T2, T4T6 5 T1, T2T7 20 T1T8 25 T4T9 15 T3, T6T10 15 T5, T7T11 7 T9T12 10 T11


Network delle attività��

��

��

��

��

��

��s tart ��

��

��

��

��T2

��M 3

��

��

��

��

��T6

��Finish

��

��

��

��T1 0

��M 7

��

��

��

��

��T5

��T7

��M 2

��

��

��

��T4

��

��

��

��M 5

��T8

4/7/94

8 day s

1 4/7/94 1 5 d ay s

4/8/94

1 5 d ay s

2 5/8/94

7 day s

5/9/94

10 days

1 9/9/94

1 5 d ay s

1 1/8/94

2 5 d ay s

1 0 d ay s

2 0 d ay s

5 d ays2 5/7/94

1 5 d ay s

2 5/7/94

1 8/7/94

1 0 d ay s

T1

M 1 T3T9

M 6

T1 1

M 8

T1 2

��

M 4


Temporizzazione delle attività4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T1T2

M1

T7T3

M5T8

M3M2

T6T5

M4T9

M7T10

M6T1 1

M8T12

Start

Finish


Allocazione della forza lavoro4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T8 T11

T12T1

T3T9

T2T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim


Pianificazione collaborativa



Sommario parte introduttivaProdotto software & processo software

Modelli di processo: a cascata, evolutivi, a spiraleVisibilità del processo di sviluppo software

Progettazione di sistemiambienteacquisizione di sistemiProcesso di sviluppo di un sistemaModello di architettura di un sistemaAffidabilità di un sistema

Project ManagementPianificazione di progettoOrganizzazione e scheduling

3. SOFTWARE MANAGEMENT - dsi.unive.itcortesi/ingsw/l3.pdf · A.Cortesi Ingegneria del Software...

Documents

Transcript of 3. SOFTWARE MANAGEMENT - dsi.unive.itcortesi/ingsw/l3.pdf · A.Cortesi Ingegneria del Software...