Tempo dedicato ai requisiti e ai suoi effetti sul successo del progetto e sui tempi di sviluppo


15

Esistono prove che suggeriscono che il tempo impiegato per scrivere o pensare ai requisiti avrà qualche effetto sul tempo di sviluppo? Uno studio condotto da Standish (1995) suggerisce che i requisiti incompleti (13,1%) hanno contribuito in parte al fallimento dei progetti. Sono stati condotti studi che dimostrano che il tempo speso per l'analisi dei requisiti avrà alcun effetto sui tempi di sviluppo di un progetto o sulla riuscita del progetto.


3
Come si adattano qui i modelli agili? Si può sostenere che trascorrono il tempo dei requisiti (acceso e spento) ma non esiste una "fase" dei requisiti in quanto tale.
Raffaello

1
Sono d'accordo con @Raphael. Risponderemo alle domande sull'ingegneria del software? O è la politica ufficiale del sito che non vale la pena distinguere tra "informatica" e "ingegneria del software" in questo momento?
Patrick87

1
@ Patrick87 Spostiamo questo su meta .
Raffaello

Mi sembra che questa domanda si adatterebbe meglio ai siti esistenti di ingegneria del software e gestione dei progetti .
Adam Lear

Risposte:


10

Vedi codice completo, di Steve McConnell, tabella 3-1. Confronta il costo medio per correggere i difetti in base a quando vengono introdotti e rilevati. Il rilevamento in fase di costruzione costa 5-10 volte in più rispetto al rilevamento in fase di fabbisogno e 10-100 volte in più dopo il rilascio.

La tabella si basa sulle seguenti fonti:

  1. "Ispezioni di progettazione e codice per ridurre gli errori nello sviluppo del programma" (Fagan 1976)

  2. Rimozione dei difetti del software (Dunn 1984)

  3. "Miglioramento dei processi software presso Hughes Aircraft" (Humphrey, Snyder e WIllis 1991)

e molti altri ancora


Questo da solo non è sufficiente. Gli errori costosi devono accadere abbastanza spesso e devono essere colti abbastanza spesso trovando requisiti adeguati. In caso contrario, il costo aggiuntivo derivante dall'elaborazione dei requisiti potrebbe comunque superare i costi degli errori.
Raffaello

È vero. Dobbiamo presumere che fino a un certo punto, non affrettarsi sui requisiti significa che ci sono meno errori nei requisiti, ma ciò non sembra troppo lungo.
Joe

10

Sì, ci sono molti studi su questo argomento. Naturalmente, la domanda è troppo generica per rispondere a tutti i tipi di progetti di sviluppo software, ma ci sono prove da diversi contesti che supportano l'idea che una corretta analisi dei requisiti avrà un impatto positivo sulla fase di implementazione. Questa prova è stata parzialmente raccolta in "leggi", e qui ci sono tre esempi:

Legge sul vetro: le carenze dei requisiti sono la fonte principale dei fallimenti del progetto.

Questa legge è supportata da prove di casi studio di grandi progetti di sviluppo software. Glass ha scoperto che nei casi falliti c'erano troppi requisiti, erano instabili a causa di cambiamenti tardivi ed erano ambigui e incompleti.

Ciò suggerisce che esiste una relazione tra la qualità dei requisiti e il risultato del progetto.

La prima legge di Boehm: gli errori sono più frequenti durante i requisiti e le attività di progettazione e sono più costosi quanto più vengono rimossi.

Questo è anche supportato da prove di casi studio e contribuisce a rispondere alla domanda nel modo seguente: fare i requisiti in modo corretto ridurrà il numero di errori nel sistema e correggere gli errori prima di iniziare l'implementazione sarà meno costoso che cercarli giù quando l'implementazione è già iniziata (o peggio, quando il sistema è già stato spedito).

La seconda legge di Boehm: la prototipazione (in modo significativo) riduce i requisiti e gli errori di progettazione, in particolare per le interfacce utente.

Ciò è supportato da esperimenti controllati in un contesto studentesco. Una possibile interpretazione è che i requisiti e le fasi di progettazione non devono essere interamente basati sulla documentazione e teorici. Invece, eseguire la prototipazione come parte dei requisiti e delle fasi di progettazione - il che equivale a dedicare tempo e pensare ai requisiti - influenzerà il successo del progetto e i tempi di implementazione.

Ci sono anche molte altre prove che puntano nella stessa direzione: passare il tempo a prepararsi per l'implementazione paga sotto forma di meno rischi e meno possibilità di superamento del programma a causa di sorprese. Sebbene la domanda non riguardasse i test, anche una preparazione adeguata influisce positivamente sui test.

I riferimenti per queste leggi sono:

Legge Glass: Glass, RL: Software Runaways. Lezioni apprese da enormi fallimenti di progetti software. Upper Saddle River, NJ: Prentice Hall 1998

La prima legge di Boehm: Boehm, BW, McClean, RK, Urfrig, DB: alcune esperienze con gli aiuti automatici alla progettazione di software affidabile su larga scala. IEEE Trans on Software Engineering 1, 1 (1975), 125-133

La seconda legge di Boehm: Boehm, BW, Grey, TE, Seewaldt, T .: Prototipazione contro specifica: un esperimento multiprogetto. IEEE Trans on Software Engineering 10, 3 (1984), 290–302

Inoltre, potrebbero essere interessanti i seguenti riferimenti: Endres, A. e Rombach, D. Un manuale di ingegneria del software e dei sistemi. Osservazioni empiriche, leggi e teorie. La serie IESE Fraunhofer sull'ingegneria del software. Addison Wesley, 2003.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.