Alternative concrete alla relazione inversa tra il tempo di completamento del progetto e il numero di sviluppatori?

4

Sfondo

Ora è ben compreso (se non sempre ben comunicato) che la seguente logica non si applica alle stime del progetto di sviluppo software:

A project that would take 1 developer 12 days,
               would take 2 developers 6 days,
               would take 3 developers 4 days,
               etc.

o come eloquentemente messo da Fred Brooks in "The Mythical Man-Month",

Nine people can't make a baby in a month.

Ci sono, naturalmente, diversi fattori che causano questo, tra cui compiti necessariamente sequenziali, comunicazioni più difficili, ecc.

Matematicamente, questo modello equivale a suggerire che il tempo di completamento del progetto T è correlato al numero di sviluppatori assegnati N da un'equazione del modulo

T = E/N

dove E è il tempo richiesto per uno sviluppatore solista per completare il progetto.

Domanda

Ci sono altre relazioni proposte tra il tempo di completamento del progetto T e il numero di sviluppatori assegnati N che

  1. può essere espresso in un'equazione matematica ragionevolmente succinta;
  2. sono stati confrontati favorevolmente (o almeno più favorevolmente rispetto a T = E/N ) a dati provenienti da progetti software reali?

Le risposte supportate da citazione sono preferite. Grazie!

    
posta stkent 26.02.2016 - 00:13
fonte

2 risposte

5

Stai parlando di stima del software.

I riferimenti canonici e canonici sulla stima del software sono "Economia di ingegneria del software" di Barry Boehm e Tom DeMarco "Controllo dei progetti software" .

Il libro di Boehm è il punto di partenza, anche se ha 35 anni. I suoi maggiori contributi sono (1) il riconoscimento che l'equazione di stima è intrinsecamente non lineare, (2) l'uso di dati reali su un numero significativo di progetti per calibrare una metodologia di stima e (3) il riconoscimento che alcuni fattori come strumenti, squadra capacità e programmare la compressione o l'espansione cambierà lo sforzo stimato. (Comprime la pianificazione e aumenta il numero totale di ore uomo. Espandi la pianificazione e le ore uomo totali aumentano.)

Il primo passo consiste nello stimare lo sforzo, in qualcosa come l'uomo o l'uomo. Il passaggio 2 consiste nel trasformare la stima uomo-ora in un programma stimato nominale, in genere in giorni, settimane o mesi e una dimensione nominale del team. Il passaggio 3 è quello di rivedere la stima uomo-ora, utilizzando il programma effettivo dettato da ciò che alcuni hanno chiamato i pipistrelli high-rafter (ovvero la gestione superiore, o forse le vendite o il marketing).

Il più grande contributo di DeMarco è l'idea di una "regione impossibile": alcuni programmi sono semplicemente impossibili da soddisfare, indipendentemente da quanti corpi li proiettano, indipendentemente da quanto siano bravi.

Poco dopo l'uscita del libro di Boehm, la divisione General Dynamics Fort Worth ha adottato la sua metodologia e ha calibrato il proprio stimatore sui propri dati effettivi per lo sviluppo del software F-16. Quindi hanno continuato a scommettere sul risultato finale della società ogni volta che stimavano un compito di modifica del software F-16.

La mia prima esperienza con COCOMO è stata mentre ero lì: ero più che un po 'sorpreso quando, in un progetto interno, ho scoperto che la metodologia di Boehm's "punch in the numbers and turn the manovk" ha prodotto una stima che era abbastanza vicina con il mio personale istinto.

Trovo più che un po 'sgomento quando vedo persone che usano stimatori lineari ("10 linee per uomo al giorno" o alcune di queste) ANCHE OGGI, 35 anni dopo la pubblicazione del libro di Boehm.

Dopo aver passato un passaggio nel libro di Boehm, puoi consultare l'aggiornamento: "Stima dei costi del software con COCOMO II" . Il COCOMO originale, dal 1981 o giù di lì, non si adattava a progetti "più moderni" (tradurre: molte volte più grandi).

Dopo aver digerito i tre libri di cui sopra, QUINDI puoi guardare la "Stima del software: Demistificare l'arte nera" di Steve McConnell . NON provare a saltare direttamente al libro di McConnell.

    
risposta data 26.02.2016 - 02:07
fonte
2

Penso che tu stia sbagliando un po 'con le tue ipotesi.

Credo che sia generalmente accettato che l'aggiunta di nuovi sviluppatori velocizzi lo sviluppo, ma solo fino a un certo punto. Questo punto è generalmente considerato attorno a 5 sviluppatori. Dopodiché, come presumi, il sovraccarico della comunicazione e la mancanza di attività paralizzabili non riducono il tempo o addirittura lo aumentano.

Se dovessi citare un "Mythical Man-Month" come fai tu, Brooks suggerisce un modello di sviluppo, in cui le squadre sono composte da 5-7 sviluppatori e quindi quelle squadre fanno parte di "team più grande" dove solo i rappresentanti selezionati comunicare da ciascun team comunicare tra loro. Ciò mantiene bassi i costi di comunicazione, consentendo al tempo stesso l'enorme quantità di sviluppatori che lavorano su un progetto.

    
risposta data 26.02.2016 - 06:50
fonte

Leggi altre domande sui tag