Gestione

Sommario

Questo capitolo verterà sugli aspetti gestionali dell’ingegneria del software: tratterà aspetti quali la pianificazione, la gestione della documentazione, quella delle versioni e le configurazioni.

Pianificazione e gestione del progetto

La pianificazione e la gestione del progetto dà le linee guida per gestire progetti di grandi dimensioni (da 3 a 300 persone). La sua realizzazione offre la capacità di stimare il lavoro e quindi gestire al meglio i contratti di pagamento. Permette di stimare parametri quali tempo e risorse che il progetto richiede.

Processi di gestione

I processi di gestione sono formati da:

Lo sviluppo, con la specifica ed il progetto, che dialoga con il controllo.
Il controllo, con i test e le ispezioni, che dialoga con lo sviluppo.
La gestione, che è trasversale a tutto e permette di governare il processo.

I processi di gestione si articolano in diverse fasi:

Preparare l’offerta
Ricezione e accettazione dell’ordine
Avvio del progetto
Esecuzione con controllo di gestione che monitora l’uso delle risorse, cercando di rientrare nelle previsioni di costo e tempo.
Terminazione del progetto

Preparazione di un offerta

La preparazione di un offerta si compone di vari aspetti:

Studio di fattibilità, include l’analisi dei requisiti e la progettazione architetturale. Ha il compito di definire elementi concreti necessari per stabilire l’elenco dei prodotti e servizi a livello di dettaglio tale da poter stimare tempi e costi
WBS (Work Breakdown Structure), è il risultato dello studio di fattibilità. I servizi e i prodotti da fornire sono decomposti in una struttura gerarchica di attività e/o componenti. Si tratta quindi di suddividere il lavoro e fare una lista della spesa di quello che serve. La WBS è la base per identificare le risorse e i tempi necessari, i costi e i piani. Esistono due tipi di WBS:
- Per componenti, cioè si suddivide il lavoro necessario per ogni componente
- Per attività, cioè si suddivide il lavoro per attività come la specifica, la progettazione, ect.
Stima delle risorse, dei costi e dei tempi
Stesura dell’offerta, a questo punto abbiamo in mano una serie di elementi che ci permetto di fare un’offerta, definendo cosa possiamo dare, a che prezzo (perch´e con il cliente non si parla di costi) e in quanto tempo.

Bisogna tenere ben presente che si stanno stimando costi di un certo tipo di lavoro e non i prezzi. Il prezzo viene definito successivamente introducendo un margine di guadagno.

Stima delle risorse, costi e tempi

Stima delle risorse

La stima delle risorse si effettua con metodi diversi:

Stima analitica a partire da una WBS dettagliata
- il progetto è scomposto in una serie di attività e componenti
- si definiscono le caratteristiche dei componenti nel modo più analitico possibile
- per ogni attività/componente è stimato lo sforzo necessario in termini di giorni/uomo e costo componenti/servizi acquisiti
- la stima è effettuata con i migliori esperti disponibili
- gli errori di stima, separando i lavori, tendono ad annullarsi reciprocamente.

Infatti x componenti sovrastimanti tendono a bilanciarsi con gli y componenti sottostimati:

I programmatori tendono ad essere sempre ottimisti. Si deve valutare l’opportunità di inserire margini per gestire il rischio di difficoltà inattese

Stima globale a partire da progetti analoghi, tecnica molto rischiosa e poco utilizzata
Tecnica DELPHI, la WBS viene effettuata da due persone diverse, in modo dettagliato e completo. I due si riuniscono e confrontano i risultati: se sono simili si valutano i dettagli, mentre se sono significativamente diversi si discute fino a trovare un accordo sulle possibili

soluzioni, e sui motivi delle divergenze;

Modelli COCOMO (Constructive Cost Model), si ricavano dai dati ottenuti dalla classificazione di prodotti esistenti. Si ottengono delle formule parametriche che possono essere adattate a nuovi studi, simili come campo applicativo, per stimare le risorse.

Stima dei tempi

Per effettuare la stima dei tempi si hanno una serie di dati in ingresso:

Sforzo in ore persona per componenti/attività
Tempi di consegna dei componenti acquisiti
Tempo (di calendario) richiesto per la terminazione del progetto, che di solito si tende ad accorciare perch´e il mercato è instabile e il cliente ha dei business da mantenere.

Si ottiene in uscita un piano delle attività. Per accorciare il tempo di rilascio di un prodotto è possibile aumentare il numero di programmatori. Questa però non è una funzione lineare (curva ideale) in quanto se un gruppo di lavoro è formato da troppi elementi, si rischia di perdere tempo prezioso durante lo sforzo di comunicazione e sincronizzazione (curva reale). Questa situazione deve essere evitata dal manager, anche se però rappresenta un tipico errore. Quando ci si accorge che un progetto è in ritardo aggiungere delle risorse umane, può portare ad ottenere l’effetto opposto a quello desiderato. Gli strumenti per effettuare la stima dei tempi sono:

Il piano temporale o carte di GANT: è una rappresentazione della WBS e mostra i vincoli temporali
I grafici di PERT

Analisi dei rischi

Nella fase di analisi dei rischi si identificano gli aspetti critici che possono generare rischi importanti per il progetto (costi, tempi, qualità). Alcuni possono essere:

Instabilità dei requisiti
Utilizzo di tecnologie non consolidate
Possibili dimissioni nel gruppo di progetto
Criticità di componenti sviluppate da subfornitori

In base al tipo di rischi si stabiliscono eventuali azioni da intraprendere.

Organizzazione del gruppo di progetto

Un gruppo di progetto è costituito da più persone che cooperano per raggiungere un fine. La qualità e le motivazioni delle persone sono determinanti e nessuna scelta organizzativa o tecnologica le può sostituire. L’organizzazione e la tecnologia sono fattori abilitanti che permettono alle qualità e motivazioni delle persone di esprimersi. Il capoprogetto è l’amministratore delegato del progetto ed è responsabile:

dei costi dichiarati in fase di pianificazione
dei tempi di consegna
della qualità tecnica
del personale del gruppo di progetto
generare un modello di comunicazione

Deve essere costruire uno stile di comunicazione che, in caso di criticità, generi segnali di allarme per i livelli superiori dell’organizzazione. Si deve organizzare la squadra con un mix opportuno di competenze e con ruoli definiti (una persona può assumere più ruoli) A questo punto può avere inizio la fase di avvio del progetto. In questa fase viene definto il gruppo di progetto (referente del cliente, capoprogetto, responsabili, operativi), vengono allocate le risorse (macchine, spazi), si attua la revisione del piano (tempi, costi, punti di controllo) e ci si riunisce prima dell’avvio effettivo.

Controllo e gestione del progetto

Durante la realizzazione del progetto bisogna tenere sempre sotto controllo l’avanzamento del prodotto e dei costi, effettuando delle raccolte di dati giornaliere (come le ore uomo consumate, le fatture emesse verso i fornitori, ecc) ed effettuare delle verifiche di avanzamento al tempo T (l’avanzamento tecnico e dei costi del progetto), le cosiddette milestone. Si possono cos`ı effettuare delle previsioni ed applicare delle eventuali azioni correttive in tempo. Bisogna effettuare regolarmente anche un controllo finanziario, come:

Flusso di cassa previsto (data di emissione delle fatture, di pagamento dei fornitori, previsione dello stato della cassa, ecc)
Stato delle fatturazioni
Stato dei pagamenti

In base a queste analisi dobbiamo intraprendere delle azioni correttive. Alla terminazione del progetto ci saranno ancora alcune attività da svolgere, come:

Chiusura delle attività
Archiviazione dei risultati del progetto in modo ordinato e facilmente consultabile, cos`ı da non sprecare il know-how acquisito dall’organizzazione durante la realizzazione
Pensare a possibili evoluzioni
De-allocare le risorse non più necessarie

Gestione della documentazione

Standard di documentazione

La documentazione deve essere prodotta utilizzando schemi standard di documenti per le varie tipologie di documenti, come:

Intestazione
Logo per mostrare professionalità
Data di emissione e versione (per identificare il documento)
Autore
Approvazione
Storia delle modifiche
Indice

Database del software

Tutti i documenti prodotti devono essere organizzati in una struttura di dati che ne permetta la gestione ordinata. Deve essere definito uno schema per i dati e utilizzato per tutti i progetti (es. come gestire le sottocartelle dei vari progetti e dei vari clienti). Lo stesso dicasi per gli oggetti cartacei.

Gestione delle versioni e delle configurazioni

Durante il processo di sviluppo e dopo il rilascio, i prodotti software sono soggetti a modifiche, come:

Inserimento di nuove funzionalità
Versione migliorata del manuale utente
Correzione di difetti
Release del prodotto su una piattaforma diversa

Gestione delle versioni e delle configurazioni

Durante il processo di sviluppo e dopo il rilascio, i prodotti software sono soggetti a modifiche, nuove funzionalità, versioni migliorate del manuale utente, correzione di difetti, nuove release del prodotto. Il processo di modifica deve essere gestito ordinatamente. Si deve gestire il flusso delle modifiche applicandole ordinatamente (in un contesto di più sviluppatori) e identificare la versione attuale di ogni componente. Costruire una versione globale del prodotto che incorpora un insieme di modifiche (insieme di componenti in relazione tra di loro, ognuno ad un livello di versione eventualmente diverso). Si dece poter tornare alla versione precedente in caso di problemi.

La gestione delle versioni e delle configurazioni deve essere pianificata:

Regole / strumenti di gestione (es. procedura del sistema qualità)
Ruoli (in ogni progetto è chiaro a tutti come si gestisce il problema ed esiste un responsabile di questo aspetto)

La gestione delle versioni e delle configurazioni deve essere trattata sotto aspetti diversi:

Gestione del database del software, si devono gestire i diritti di accesso e l’accesso concorrente
Gestione delle versioni (version and release management). Ogni componente del prodotto (documento, modulo di codice, piano di test) è identificato da un codice di versione
- Versione.Release.Modifica (es. 2.4.1)
- Versione: modifiche sostanziali
- Release: modifiche minori
- Modifica: correzione di difetti

Esistono regole di modifica del codice di versione ogni volta che il componente è modificato:

Gestione della configurazione (system building). Un prodotto rilasciabile è costituito da una struttura di componenti interconnessi (configurazione).

Essi sono

Documenti di specifica e progetto
Componenti di codice sorgente
Manuali utente
Casi di test
Prodotto installabile
Procedura di installazione
Ogni componente ha una sua versione
Il prodotto globale ha una versione
L’insieme dei componenti che costituiscono una configurazione di prodotto deve essere mantenuto coerente
Ogni volta che viene modificato un componente deve essere aggiornato lo stato (versione) del prodotto
Deve essere possibile costruire il prodotto (installabile) a partire dai suoi componenti

Gestione delle modifiche (change management), si devono gestire le richieste di cambiamento.
- Ricezione delle richieste
- Gestione delle priorità (richieste urgenti, lotti di richieste)
- Approvazione dell’esecuzione delle modifiche
- Esecuzione delle modifiche
- Verifica dei risultati