Leggi la Rivista Telematica nel sito web

QUALITA' ONLINE!

QUALITA' ON LINE N° 2-2009, novembre

Powered by

Risultati dei progetti software e best practice
Modello di valutazione dei risultati dei progetti software in base alle best practice utilizzate

Ercole Colonese, Consulente di Direzione ed organizzazione, socio Aicq-ci e membro del sottocomitato per la qualità del software e dei servizi IT.

La realizzazione di un progetto software rappresenta sempre un investimento importante per un’azienda; per un’organizzazione di piccole o medie dimensioni può anche pregiudicare il suo sviluppo; al successo del progetto sono legate aspettative legate al business, alla crescita, alla produttività, alla competitività.
Le statistiche parlano chiaro ma sono anche impietose: molti, troppi progetti non raggiungono gli obiettivi. Le cause sono ben identificate studi e ricerche: requisiti mal indirizzati o per niente sviluppati, stime errate e piani poco realistici, test insufficienti, continui rifacimenti e modifiche in corso d’opera non gestiti, ecc.
Dovendo spiegare il fenomeno agli studenti di un corso di Ingegneria del Software tenuto all’Università di Roma, ho utilizzato un numero consistente di dati su progetti che avevo registrato negli ultimi anni. Abbiamo così sviluppato, insieme agli studenti, un modello che mette in relazione i risultati ottenuti dai progetti con l’utilizzo di dieci “best practice”.
Il risultato dell’analisi conferma quanto già rilevato dalle statistiche: una percentuale alta di progetti non raggiunge gli obiettivi; ma fa luce al contempo su un punto: i risultati migliorano con l’adozione di buone pratiche. I risultati conseguiti dai progetti seguono un andamento “lineare” con l’adozione delle pratiche. L’analisi mette in luce anche i legami tra risultati e competenza e motivazione delle persone. Un secondo fenomeno mette in luce che a parità di adozione delle pratiche si possono ottenere risultati variabili, anche in maniera significativa. Al crescere del livello di maturità dell’organizzazione corrispondono risultati di  eccellenza e la forbice si chiude.
La conclusione: lo sviluppo del software è un’attività intellettuale a grande contenuto tecnico ed umano. Conoscere le buone pratiche ed adottarle in maniera corretta e coerente garantisce risultati di valore; ogni altra tecnica o scorciatoia porta a risultati scadenti, poco profittevoli dal punto di vista economico e dannosi per l’immagine e la crescita.
  

La metodologia

Indagine sull'utilizzo di buone pratiche del software

L'indagine è stata condotta negli anni per valutare il beneficio sui risultati dei progetti software dall’adozione delle buone pratiche disponibili ("best practice").
Il lavoro di consulenza ha permesso di entrare in contatto con moltissime realtà organizzative, alcune di grande capacità ed altre meno. In particolare, lo sviluppo software ho messo in risalto risultati negativi anche in realtà ben strutturate, come pure buoni risultati in organizzazione meno strutturate. Il più delle volte l’intervento consulenziale mirava a sanare situazioni negative, progetti in difficoltà, risultati al di sotto delle attese, organizzazioni in crisi. I casi in esame sono quindi significativi ai fini dell’indagine.
La necessità di analizzare in dettaglio il fenomeno prima ancora di suggerire le azioni correttive ha portato ad acquisire nel tempo una notevole mole di dati. Questi, organizzati in maniera sistematica (in un foglio elettronico), hanno dato vita ad un insieme di informazioni utili ad intraprendere l’analisi di dettaglio del fenomeno in oggetto.
L’occasione per sistematizzare i dati ed iniziare l’analisi di dettaglio è nata durante una serie di lezioni sull’Ingegneria del software tenute presso un ateneo romano. L’idea di coinvolgere gli studenti direttamente nell’analisi dei progetti si è rilevata una tecnica didattica molto efficace ed utile. Cosa di meglio (ed istruttivo) che “toccare con mano” gli effetti del modo di lavorare sui risultati dei progetti?
I dati a disposizione non sono moltissimi (il numero totale di progetti analizzati è 35) ma costituiscono un insieme sufficientemente ampio da permettere alcune considerazioni anche generali.

Formalizzazione del modello

L’analisi si è formalizzata nel tempo con la progettazione di un questionario da sottoporre alle aziende. Ai dati iniziali rilevati direttamente durante l’analisi dei progetti si sono così aggiunti altri ricavati dai questionari compilati dai partecipanti all’indagine (il questionario è riportato in fondo all’articolo).
Il questionario consta di 10 domande su altrettante “best practice” considerate importanti ai fini del successo dei progetti e di 5 domande sui risultati raggiunti e sulle caratteristiche del progetto.
Le pratiche sono ricavate dagli studi effettuati dall'ingegneria del software sulle cause principali del fallimento di moltissimi progetti.
Le risposte fornite con i questionari permettono di quantificare l'aderenza (o lo scostamento) da un'organizzazione "ideale" in cui le dieci pratiche siano completamente e correttamente utilizzate.
I risultati ottenuti non sono confortanti e la media generale risulta essere bassa (6,65 su di un punteggio massimo di 10). Pensiamo che una buona organizzazione software debba collocarsi intorno ad un punteggio non inferiore a 8,0 per garantire il successo dei progetti realizzati come dimostrato anche dai risultati dell’indagine.

Le 10 domande

Le domande si riferiscono al grado di utilizzo nei progetti software delle migliori pratiche disponibili ("best practice"); queste dovrebbero evitare gli errori più ricorrenti che generano i problemi maggiori: ritardo nei tempi di consegna, spese oltre il budget, qualità finale poco soddisfacente.
I dieci argomenti trattati nel questionario rappresentano le "best practice" e riguardano:

  1. Gestione accurata dei requisiti.
  2. Adeguatezza della progettazione.
  3. Stima accurata dei progetti.
  4. Pianificazione realistica dei progetti.
  5. Gestione attenta dei rischi.
  6. Adeguatezza delle risorse impegnate nei progetti per numero e competenza.
  7. Revisione tecnica dei prodotti di fase realizzati.
  8. Adeguatezza dei test alla criticità del business.
  9. Gestione delle modifiche, della configurazione e degli errori.
  10. Gestione della qualità durante l’intero ciclo di vita.

Per ciascun elemento sono proposte più domande che permettono di assegnare un punteggio da uno a dieci.
Il punteggio "medio" delle dieci pratiche esprime il grado di adozione delle best practice suggerite nel progetto.

Le atre 5 domande

Alle domande sulle dieci pratiche elencate sopra seguono altre cinque sui risultati del progetto e sull’organizzazione.
Le cinque domande aggiuntive riguardano:

  1. Numero totale di persone coinvolte direttamente nel progettoe sua durata in numero di mesi.
  2. Livello di raggiungimento degli obiettivi del progetto (espresso in percentuale) in termini di rispetto dei tempi di consegna, mantenimento dei costi entro il budget prefissato e livello di qualità finale inteso come piena implementazione dei requisiti concordati, sia funzionali che prestazionali.
  3. Livello di soddisfazione espresso dal cliente relativamente al progetto in esame.
  4. Livello di soddisfazione, motivazione ed interesse del personale coinvolto nel progetto.
  5. Certificazione ISO 9001 dell'organizzazione.

Obiettivi dell’analisi

L’analisi tende a mettere in correlazione l’utilizzo delle best practice con i risultati dei progetti e le caratteristiche dell’organizzazione. In particolare si cerca di verificare se alcune pratiche possano avere una maggiore influenza e quali siano le varianze.
Si cerca inoltre di analizzare l’influenza di altre componenti dei progetti come, ad esempio, il team di lavoro, la sua adeguatezza in termini di competenza e numero e la sua motivazione ed interesse.
Altro elemento da analizzare è la corrispondenza del livello di soddisfazione del cliente sull’esito del progetto.
Per finire si cerca di valutare l’influenza della certificazione ISO 9001 sui risultati finali dei progetti.

I risultati dell’indagine

Correlazione risultati pratiche adottate

La prima analisi (spinti dalla curiosità innata) è stata quella di verificare l’andamento dei risultati in base al diverso utilizzo delle pratiche.
La figura che segue mostra l’andamento che ci si aspettava: i risultati migliorano con l’adozione delle best practice.


Figura 1. Andamento dei risultati in base alle pratiche adottate

La media dei valori è evidenziata nel grafico e corrisponde ad un risultato di 69,7% a fronte di un utilizzo medio di 6,7 delle pratiche.
La linea tratteggiata diagonale indica l’andamento lineare intorno al quale si distribuiscono i valori rilevati.
La distribuzione è leggermente spostata al di sopra della linea tratteggiata ad indicare che si ottengono risultati leggermente superiori rispetto al livello di adozione delle best practice. Anche il valore medio si posiziona leggermente al di sopra della linea.
La distribuzione mostra inoltre una dispersione orizzontale ed una verticale. Quella orizzontale indica che lo stesso risultato è ottenuto da organizzazioni con diverso livello di adozione delle pratiche. Al risultato medio di 69,7%, ad esempio, corrispondono livelli di adozione delle pratiche che variano da 5,5 a 8,4. Organizzazioni che sappiano ben interpretare le pratiche possono ottenere anche risultati di rilevo; certamente un risultato positivo non sarà ripetibile in altri progetti senza aver consolidato pratiche di rilevo. La dispersione verticale rappresenta il concetto analogo: a parità di adozione di buone pratiche possono corrispondere risultai diversi. Nel grafico al valore medio di utilizzo delle pratiche (6,7) corrispondono risultati che variano da un minimo di 69,7% ad un massimo di 75,0%.
E' bene ricordare che il valore 100% significa avere mantenuto gli impegni in termini di tempi di consegna, contenimento dei costi entro il budget di progetto e rilascio del software con il livello di qualità atteso. Un valore accettabile per un'organizzazione che fa dei progetti il proprio business non può essere inferiore al 95%. Ciò equivale ad una deviazione negativa dagli obiettivi definiti inferiore al 5%, limite oltre il quale viene inficiato il profitto, intaccato il rapporto di fiducia.

Utilizzo delle pratiche

Una pratica è considerata efficace se utilizzata almeno per l’ 80% delle sue specifiche. Utilizzare una pratica significa seguire tutte le sue raccomandazioni. Seguirne solo alcune e trascurarne altre potrebbe vanificare la sua efficacia.
Le domande del questionario poste per ciascuna pratica forniscono una sorta di linea guida di ciò che si intende per adozione completa di una buona pratica.
Nei progetti esaminati tutte le pratiche sono sotto-utilizzate e sembra non riescano a produrre l'effetto positivo desiderato. Il grado di utilizzo delle singole pratiche è esposto nella tabella che segue.

Pratica

Valore medio

1. Analisi dei requisiti

7,3

2. Qualità della progettazione

7,0

3. Stima delle dimensioni del progetto

6,5

4. Pianificazione del progetto

6,5

5. Gestione dei rischi

5,7

6. Risorse impegnate nel progetto

6,1

7. Ispezione dei prodotti intermedi

6,1

8. Test e collaudo

7,0

9. Modifiche, configurazione e difetti

6,4

10. Gestione della qualità

6,2

Una prima valutazione dei dati suggerisce una interpretazione “qualitativa” del fenomeno che potrebbe essere riassunta così: si sa bene cosa fare (requisiti), si altrettanto bene come fare (progettazione), si hanno meno capacità per stimare e pianificare realisticamente il progetto, si dispone di risorse insufficienti per numero e competenza, si trascura totalmente la gestione dei rischi, si spende molto nella correzione degli errori (test), si curano poco le modifiche e la qualità.
L’intuito porterebbe a concludere che un siffatto atteggiamento porti a risultati poco positivi. Ed è proprio così, purtroppo. Gli obiettivi sono raggiunti solo per il 69,7%. Circa il 30% degli obiettivi non è raggiunto!

Anagrafe dei progetti

Segue una breve analisi delle caratteristiche dei progetti e delle organizzazioni corrispondenti.
I dati a disposizione si riferiscono a 35 progetti software realizzati da piccole o medie organizzazioni. Alcuni progetti si riferiscono anche a grandi aziende ma affidati ad organizzazioni interne (reparti, divisioni, ecc.) paragonabili ad imprese di piccole o medie dimensioni. E’ interessante notare come anche grandi aziende con modelli e processi di elevato livello di maturità si comportino al loro interno con metodi e tecniche per niente allineati agli standard aziendali. I modelli sono teorici oppure utilizzati solo in grandi progetti; nel quotidiano ci si comporta in maniera destrutturata e/o improvvisata.
Le dimensioni dei progetti, in termini di durata (numero di mesi) è mostrata nella tabella che segue. Il 40% ha una durata tra 7 e 10 mesi, mentre la media è di 10 mesi.

Durata (mesi)

Progetti

tra ...

e

Numero

%

1

6

8

23%

7

10

14

40%

11

20

11

31%

21

30

2

6%

 

Totale 

35

100,00

Per quanto riguarda le dimensioni dei gruppi di lavoro l’analisi mostra una media di 11,1 persone con la percentuale di progetti più alta (57%) costituita da gruppi di lavoro tra 1 e 10 persone.

Persone

Progetti

tra …

e

Numero

%

1

10

20

57%

11

20

14

40%

21

50

1

3%

 

Totale 

35

100,00

Un ultimo dato riguarda la certificazione ISO 9001 conseguita da 29 organizzazioni su 35 (pari all’ 89% delle aziende). Molti progetti realizzati da organizzazioni certificate mostrano una netta carenza in termini di aderenza alla norma in oggetto dimostrando ancora una volta (se ce ne fosse bisogno) dell’adozione della norma ISO 9001 come mera conformità formale e poco sostanziale). I risultati dell’indagine dimostrano purtroppo tale affermazione.

Competenza e motivazione dei gruppi di lavoro

L’analisi dei progetti evidenzia una netta carenza, in termini generali, di personale adeguato alle dimensioni e complessità del lavoro richiesto.
L’analisi del livello di soddisfazione e di motivazione del gruppo di lavoro dimostra inoltre che tale carenza viene percepita negativamente dalle persone che evidentemente fanno fatica a lavorare in progetti che richiedano competenze non possedute.
Tale problema è sicuramente da indirizzare a livello manageriale: la gestione delle risorse, in termini di competenza, produttività e motivazione, è un aspetto cruciale per aziende in cui il lavoro intellettuale come lo sviluppo software è il “core business”.
 La tabella che segue mostra i risultati dell’analisi di tali fattori.

Elemento di valutazione

Valore

Adeguatezza del team

6,7

Motivazione del team

6,9

La correlazione che esiste tra livello di raggiungimento degli obiettivi dei progetti e livello di motivazione delle persone è mostrata qui di seguito. E’ evidente quanto siano strettamente correlati questi due fattori.

Obiettivi

Motivazione

69,1

6,9

Risultati conseguiti dai progetti

Il livello con cui sono raggiunti gli obiettivi pianificati viene espresso in termini di “rispetto dei tempi di consegna”, “mantenimento dei costi entro il budget stabilito” e “piena realizzazione dei requisiti concordati, sia funzionali che prestazionali”.
Tale livello è espresso in termini percentuali (% di raggiungimento degli obiettivi).
Dei 35 progetti analizzati solo una bassa percentuale (11%) raggiunge pienamente i risultati attesi (100% degli obiettivi).
La maggior parte dei progetti (55%) raggiunge solo parzialmente i risultati attesi (tra il 60% ed il 70%).
La tabella che segue mostra il numero e la percentuale di progetti che raggiungono risultati parziali.

Risultati

Progetti

tra …

e

Numero

%

100

100

4

11%

90

99

3

9%

80

89

1

3%

70

79

10

29%

60

69

9

26%

50

59

6

17%

40

49

2

6%

 

Totale

35

100,00

Anche sommando i risultati delle prime tre righe il numero di progetti che raggiungono gli obiettivi per un valore tra l’80% ed il 100% sale ad appena 23% del numero totale.

Analisi economica dei progetti

L’analisi rivela aspetti preoccupanti quando i dati sono tradotti in termini economici.
La media dei valori dei progetti analizzati (11,1 risorse impegnate per 10 mesi ad un costo medio giornaliero di € 350,00) costituisce un investimento di € 38.850,00. Il ritardo medio del 31% (pari a 34,1 giornate di lavoro aggiuntivo) comporta uno sforamento del budget iniziale di circa € 12.043,50. Tale extra costo è stato assorbito nella maggior parte (circa il 73%) dei progetti analizzati dall’organizzazione erodendo i margini di profitto. Nel restante numero dei casi (27%) è stato concordato un adeguamento dei costi con il cliente.
Una cattiva gestione dei progetti, come si vede, non conviene a nessuno.
L’impatto negativo sul business cresce all’aumentare del livello di “non raggiungimento” degli obiettivi. Nella tabella riportata all’inizio dell’articolo si possono notare livelli di raggiungimento degli obiettivi anche inferiore al 50%. E’ facile intuire l’impatto devastante di un tale progetto per la fragile economia di una organizzazione di piccole o medie dimensioni.

Soddisfazione del cliente

L’analisi dimostra una stretta correlazione tra risultati conseguiti e soddisfazione del cliente, come era da aspettarsi. Non tutti i progetti, tuttavia, rilevano il livello di soddisfazione finale del cliente (questo aspetto è in netta contraddizione con la certificazione ISO 9001).
La media dei valori rilevati è pari a 7,2 (su una scala da 1 a 10). Il valore risente del fatto che il livello di soddisfazione è stato rilevato solo nel 54% dei progetti e molti di quelli con risultati inferiori alle attese non hanno effettuato la rilevazione.

Conclusioni

Occorre prendere coscienza del fatto che lo sviluppo del software è un'attività intellettuale con una grande componente tecnica ed una altrettanto importante componente di professionalità.
Il ciclo di vita del software comprende diverse fasi. Ciascuna di esse ha un obiettivo specifico e richiede competenze altrettanto specifiche. Ogni fase del ciclo di vita, se non effettuata correttamente, crea problemi e genera errori. Questi, se non risolti immediatamente, sono trasmessi alle fasi successive generando ulteriori problemi ed errori, con un fattore moltiplicativo .
Risolvere i problemi e correggere gli errori comporta un dispendio di tempo e risorse che gravano sui costi del progetto. Attività di rifacimento, correzione di errori in numero superiore alla media, riciclo su attività già svolte incidono su costi in maniera negativa e pericolosa. Lo slogan potrebbe essere: "Fare bene ed una sola volta!"
E' fondamentale, quindi, eseguire ciascuna fase nel modo corretto e risolvere i problemi sul nascere, evitando che errori generino altri errori in modo esponenziale.
Ciascun progetto è sempre diverso dagli altri: nel contesto culturale ed organizzativo del cliente, nella criticità della soluzione per il business, nelle problematiche da risolvere e nelle soluzioni prospettate, nei tempi e nei costi da rispettare, ecc.
Occorre quindi - e ciò è imperativo - maturare le competenze necessarie, tecniche e professionali, ad affrontare le diverse situazioni che nei vari progetti si prospettano durante la loro realizzazione.
Per garantire progetti di successo che rispettino i tempi di consegna e contengano i costi nei budget, che sviluppino soluzioni efficaci e rispondenti alle esigenze del business dei clienti ci vogliono professionisti del software, persone con le competenze tecniche adeguate e la conoscenza delle migliori pratiche del settore.
Di seguito è riportato il questionario completo sottoposto alle aziende.


10 domande sulle “best practice”

Pratica (Best practice)

Punteggio

1. Gestione corretta dei requisiti.
a)    L’analisi dei requisiti è condotta con sufficiente cura ed attenzione tanto da assicurare che tutti i requisiti, espliciti ed impliciti, funzionali e qualitativi, siano raccolti, documentati e rivisti con il cliente?
b)    E’ prevista inoltre la gestione delle modifiche ai requisiti iniziali con relativa stima degli impatti sui tempi, i costi e la qualità prima della loro inclusione nel piano di sviluppo?

 

2. Bontà della progettazione.
a)    La progettazione assicura che tutti requisiti, funzionali e qualitativi, siano correttamente indirizzati?
b)    Si adottano tecniche e metodi che assicurino la qualità della progettazione?
c)    La progettazione è affidata a personale tecnico con sufficiente competenza ed esperienza per indirizzare correttamente la complessità dell’architettura prevista?

 

3. Accuratezza delle stime.
a)    Le stime delle dimensioni dei progetti sono “realistiche” (cioè confortate da progetti precedenti e simili)?
b)    Le stime sono condotte da persone con competenza ed esperienza sufficienti?
c)    Al termine dei progetti si valutano gli scostamenti dei valori a consuntivo dalle stime iniziali?
d)    Si tiene traccia degli eventuali scostamenti e si tiene conto in progetti analoghi futuri?

 

4. Pianificazione realistica del progetto.
a)    La pianificazione dei progetti è “realistica” (il piano risulta privo di condizionamenti ed imposizioni di terze parti: management, marketing, clienti, ecc.)?
b)    La pianificazione è prodotta da persone con competenza ed esperienza adeguate alla complessità del progetto?
c)    La pianificazione è fatta in base alle stime ed ai requisiti da sviluppare nei vari rilasci?
d)    Si prevede in fase di pianificazione una “contingency” per gli imprevisti?

 

5. Gestione attenta dei rischi.
a)   Si effettua un’attenta gestione dei rischi di progetto (individuazione, valutazione, adozione di misure opportune)?
b)    Si controllano con regolarità, durante l’intero svolgimento del progetto, i rischi individuati e eventuali nuovi rischi?

 

6. Adeguatezza delle risorse (per numero e competenza).
a)    Si mettono a disposizione di risorse adeguate, come numero e competenze, alle necessità del progetto?
b)    Si valutano le necessità formative, si realizza e si esegue un piano di formazione adeguato alle necessità, e si valuta l’efficacia finale?
c)    Si motiva a sufficienza il personale comunicando con periodicità e chiarezza gli obiettivi da raggiungere ed i risultati conseguiti, i programmi e le iniziative di miglioramento?

 

7. Utilizzo sistematico di revisioni tecniche (ispezioni).
a)    Si pianificano e si eseguono con regolarità “revisioni tecniche” dei prodotti intermedi realizzati?
b)    Si registrano i risultati delle revisioni tecniche e si eseguono analisi statistiche sugli errori rilevati in modo da migliorare i processi e le attività svolte dalle persone?

 

8. Adeguatezza dei test (copertura dei requisiti e rimozione degli errori).
a)    Si pianifica e si spende in attività di test una percentuale adeguata (per esempio, non meno del 20%) del costo complessivo del progetto?
b)    Si assicura che i test indirizzino tutti i requisiti, funzionali e qualitativi (per esempio, realizzando una “Matrice di tracciabilità dei requisiti”)?
c)    Si progettano i casi di test in modo da garantire, oltre alla piena copertura dei requisiti, anche la gestione di tutte le condizioni di errore, i casi limite, i vincoli?
d)    Si utilizza un qualche strumento automatico per la registrazione dei casi di test e degli errori rilevati permettendone analisi statistiche?

 

9. Utilizzo di procedure e strumenti adeguati alla complessità e criticità del business.
a)    Si utilizzano procedure e strumenti per la gestione delle modifiche, della configurazione e degli errori?
b)    Si utilizzano procedure e strumenti per la gestione delle modifiche, della configurazione e degli errori?

 

10. Gestione attenta della qualità dei prodotti e servizi realizzati.
a)    Si assicura che la pianificazione della qualità del software sia fatta in base ai requisiti qualitativi documentati e concordati?
b)    Si assicura che il controllo della qualità verifichi i risultati di tutte le attività pianificate: completamento delle revisioni tecniche di tutti i prodotti intermedi da consegnare, completamento dei test pianificati, livello di copertura dei test dei requisiti, delle condizioni di errore e delle condizioni limite, correzione degli errori rilevati dalle revisione tecniche e dai test, audit della configurazione, risoluzione delle non conformità, )?

 

Atre 5 domande di carattere generale sull’organizzazione e sui risultati del progetto:

Domanda

Risposta

1. Quali sono le dimensioni del progetto analizzato in termini di numero di persone coinvolte e durata?
a)    Numero totale di addetti coinvolti nel progetto, incluso lo staff ed il management.
b)    Durata del progetto, in mesi.

 

2. In che percentuale il progetto analizzato ha raggiunto gli obiettivi stabiliti?
(Fornire una risposta globale oppure singolarmente per ciascun obiettivo elencato)
a)    Rispetto dei tempi di consegna,
b)    Contenimento dei costi nel budget stabilito,
c)    Raggiungimento della qualità attesa.

 

3. Quale livello di soddisfazione ha dimostrano il clienti al termine del progetto?
(Fornire un valore da 1 a 10,  dove 10 rappresenta il massimo di soddisfazione)

 

4. Quale livello di soddisfazione, motivazione, interesse ha dimostrano il personale coinvolto nel progetto?
(Fornire un valore da 1 a 10, dove 10 rappresenta il massimo della soddisfazione)

 

5. L’organizzazione è certificata ISO 9001 e quanto ciò ha aiuta il progetto a raggiungere gli obiettivi?
a)    Certificazione: “Si” o “No”
b)    Aiuta a raggiungere gli obiettivi (“Si”, “No”, “Parzialmente”)

 



 

Per maggiori dettagli sull’argomento specifico (propagazione degli errori nel ciclo di sviluppo del software) si invita a leggere l’articolo sull’argomento scritto dallo stesso autore e pubblicato nella nostra rivista “Qualità On Line n°3, Novembre 2007”.

A cura della redazione della Rivista "Qualità" di AICQ
Direttore Responsabile: Giovanni Mattana
Redazione: Rossi Annalisa
Realizzazione tecnica a cura di Elinet S.r.l.
Redazione tecnica:Alberto Bobbo, Enrico Ladogana, Marco Bolzoni, Claudia Bordin