analisi-disegno.com
I meccanismi di controllo per i progetti di sviluppo software sono di due tipi: controlli sulla qualità di quanto viene prodotto e controllo sull'avanzamento dei lavori. Entrambi possono avvenire all'interno al gruppo di lavoro oppure essere rivolti a fornire visibilità esterna.
Qualunque attività "operativa" (es. definizione dei requisiti e dei casi d'uso, progettazione dei componenti, codifica, definizione e progettazione dei test) può produrre errori.
I controlli possono essere più o meno formalizzati, e la loro frequenza può dipendere da vari fattori (criticità intrinseca del progetto, esperienza del gruppo di lavoro, relazioni tra ruoli, ecc.). Possono consistere, a seconda del modello organizzativo, in "ispezioni" sugli avanzamenti e sui prodotti effettuate dal capo progetto, o coinvolgere l'intero gruppo di lavoro.
La tecnica più efficace (oltre che meno costosa) per ridurre il numero e la gravità degli errori nelle attività operative è comunque semplice: confrontare reciprocamente, all'interno del gruppo di lavoro, gli output prodotti dai singoli partecipanti al progetto. Questa modalità di controllo interno può assumere due forme diverse:
Quanto più queste forme di "controllo interno" sono effettuate in modo anticipato, tanto più sono efficaci.
Il livello essenziale di controllo, nell'ambito di sviluppo custom, è costituito dai collaudi di accettazione da parte del cliente. Nei casi di progetti software meno semplici, oltre a questo livello di controllo ne esiste un altro effettuato all'interno dell'organizzazione che sviluppa il sistema, ma da parte di un'area separata, nella forma di collaudo interno o comunque di independent testing.
Devono fornire all'intero gruppo di lavoro la visibilità su quanto sta accadendo, e la possibilità di contribuire a migliorare efficacia ed efficienza.
Come per la maggioranza dei controlli avanzamento lavori, è opportuno che anche quelli interni al gruppo di progetto avvengano con periodicità predefinita. Lo stato avanzamento lavori interno ideale è frequente e dura poco.
Un modello efficace è rappresentato dagli stand-up meeting quotidiani previsti dai processi agili.
Nell'ambito del progetto è essenziale anche il controllo sull'avanzamento dei costi, per il quale è possibile ricorrere alla tecnica dell'Earned Value Management (sono disponibili su web numerose fonti informative, tra cui questa), che fornisce elementi utili per dare visibilità sugli avanzamenti anche all'esterno del progetto.
Per aumentare al massimo la visibilità sull'avanzamento lavori all'interno del gruppo di progetto sono inoltre utili le burn chart. Vedere ad esempio Alistair Cockburn, Earned-value and burn charts.
Hanno lo scopo di verificare, con periodicità predefinita, l'avanzamento del progetto. Consistono in riunioni alle quali possono partecipare, oltre al al gruppo di lavoro, anche altri stakeholder (es. management, PMO, committente).
Negli stati avanzamento lavoro formali vengono effettuate:
Gli stati avanzamento lavoro sono momenti di sincronizzazione essenziali tra il gruppo di progetto e gli altri stakeholder.
“Non tutti i progetti necessitano di verifiche di avanzamento mensili formali. Per questi tipi di progetti sono necessarie:
- progetti i cui costi totali di sviluppo sono rilevanti (>$1,000,000)
- progetti i cui tempi totali di sviluppo superano 12 mesi di durata
- progetti con valore strategico importante per l’azienda
- progetti in cui il rischio di dilazioni può essere troppo elevato (come i progetti militari)
- progetti molto importanti per i vertici aziendali
- progetti nell’ambito di contratti con penali sul rispetto dei tempi
- progetti la cui data di rilascio è stata resa pubblica, o è comunque importante per l’azienda
Il tempo dedicato alle verifiche di avanzamento lavori è uno dei migliori investimenti software possibili per un’azienda.” (Fonte: Capers Jones, Social and Technical Reasons for Software Project Failures, CrossTalk, June 2006)
Nei processi di sviluppo software che prevedono una suddivisione in fasi, la conclusione delle singole fasi è un naturale momento di controllo in cui fornire visibilità sull'andamento e sui risultati ottenuti dal progetto.
Nel caso di Unified Process e delle sue derivazioni, le conclusioni di fase costituiscono degli "anchor point" essenziali per il controllo del progetto e la sincronizzazione tra gli stakeholder:
Vedere anche Barry Boehm, "Using the WinWin Spiral Model: A Case Study”, in IEEE Computer, July 1998, pp. 33-44.
Pagina principale sui processi di sviluppo software
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.