Problemi nella comprensione del modello COCOMO

Prima di andare troppo lontano due libri che dovresti davvero leggere:

• Mese Mythical Man
• Stima del software: Demistificare l'arte nera: demistificare l'arte nera

Il modello base COCOMO ha alcuni problemi con esso che sono stati superati e affrontati nel modello COCOMO II. Dalla pagina wikipedia citata:

COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability, and the use of off-the-shelf software components.

Mentre lo sforzo di "10 mesi uomo" è una stima dello sforzo, assume il compito perfettamente divisibile. Se stai scavando 10 buche nel terreno, puoi fare una persona scavare 10 buche o 10 persone scavare una buca - e le 10 persone lo faranno circa 10 volte più velocemente. Come è stato spesso notato, questo non funziona bene con la programmazione del software.

Di particolare interesse è il documento "Effetto della compressione del programma sullo sforzo del progetto" [ link ] che analizza il costo relativo della percentuale della pianificazione più efficiente.

Un'altra cosa da leggere è Come funzionano gli Strumenti di valutazione software scritti da una delle persone che viene spesso citato gli algoritmi per gli strumenti di stima del software.

Effort / staff = time period

Come si nota, non funziona bene per la programmazione.

Da qualcosa ho scritto molto tempo fa e non ho citato bene I ha avuto la seguente tabella per affrontare fino alla fine dello sforzo stimato (scavando un po 'di più, sembra un po' qualcosa dal COCOMO II Schedule Equation ). Prendi un moltiplicatore di pianificazione predefinito (3.67) moltiplica la radice cubica della stima del tempo (il tuo caso 10 mesi).

3.67 * 10 ^1/3 = 7.9

Questo rappresenta il caso migliore per una timeline del progetto di sviluppo del software.

Da dove vengono questi numeri? Adatta 20 progetti a una curva.

Da questo 7.9 abbiamo alcune cose che possiamo ottenere da questo:

• Minimo sforzo = 2x tempi di consegna ottimali (15,8 mesi)
• Regione di impossibilità = < 75% dei tempi di consegna migliori (5,9 mesi)

Ci sono molte cose dietro al modello COCOMO e COCOMO II. Questi numeri sono adatti per un campionamento di un numero enorme di progetti software e, a meno che tu non comprenda cosa stai nutrendo nel modello (per corrispondere a quello che il modello si aspetta), i numeri che uscirai non corrisponderanno a nulla che assomigli vagamente alla realtà.

Comprendi anche che hai ottenuto circa 2/3 del processo di stima. Non termina con lo sforzo stimato (10 mesi uomo) e continua con la pianificazione. L'ultima parte della Durata viene spesso lasciata cadere o dimenticata quando esce la stima di 10 falene e loro vi gettano solo 3 persone e lo fanno in 3 mesi (e poi fallisce perché è nella zona di impossibilità)

Ulteriori letture:

• Una validazione empirica dei modelli di stima dei costi del software
• Manuale di definizione del modello COCOMO II
• Effetto della compressione della pianificazione sullo sforzo del progetto

Dieci mesi persona significa che una persona può svolgere il lavoro in dieci mesi, ma anche che dieci persone possono svolgere il lavoro in un mese. Questa è pura finzione. Il seguente esempio canonico è politicamente scorretto, ma è illustrativo. Ci vogliono nove mesi per avere un bambino. Nove donne non ridurranno questo intervallo di nove mesi di una virgola. Leggi Il mese di Mythical Man . Hai bisogno di leggere questo a fianco di Boehm.

La stima dei costi, fatta bene, tiene conto di vincoli come l'intervallo di nove mesi tra concepimento e nascita. Fatto ancora meglio, è necessario tenere conto degli eventi casuali che inevitabilmente aumentano le loro brutte teste in un grande progetto software. Lo stato della pratica ( non dello stato dell'arte) nella gestione del progetto software è quello di spiegare i vincoli noti e le sciocchezze casuali che inevitabilmente rallentano le cose. Un altro nome per questo: stima dei costi del software Monte Carlo.

Addendum
Pensa ai mesi persona come al software equivalente ai kilowattora utilizzati dalla tua azienda elettrica come base per la tua bolletta elettrica.

Supponiamo che tu faccia un contratto per costruire dieci widget. Supponiamo che questa attività sia completamente automatizzata. Getta un interruttore su un apparecchio da un chilowatt e un'ora dopo, voilà, hai un widget. Lo sforzo totale per questo lavoro è di dieci kilowattora (dieci widget per un chilowattora per widget). Puoi portare a termine il lavoro in dieci ore se usi un apparecchio, cinque ore se usi due apparecchi. Puoi fare il lavoro in un'ora con dieci apparecchi? In teoria, sì. In pratica, no. Per prima cosa devi procurarti quegli elettrodomestici extra, e poi farai saltare le micce quando accendi tutti e dieci contemporaneamente. Rendere la materia quando si va al negozio di ferramenta locale sarà fuori dalle dimensioni necessarie. Finirai per passare ore a cercare quella miccia delle dimensioni. Sarebbe stato meglio usare i due dispositivi che hai già a portata di mano.

La dimensione della squadra è uno degli input per il modello; puoi usare i buoni coefficienti solo se hai un team esistente, piccolo ed esperto. Ciò significa che una squadra ha esperienza nel lavorare insieme, l'una con l'altra, su questa classe generale di problemi.

Puoi forse aggiungere 1 o 2 membri, ma qualcosa di più e hai invalidato i presupposti del modello. Torna indietro e ricalcola con i nuovi coefficienti e in genere fornirà una stima di quanto ritardi il progetto aggiungendo più persone.

Per l'esempio di una donna che ha un bambino, farlo sposterebbe il progetto da "routine, all'interno delle capacità personali" a "sforzo di ricerca genetica open-scale di scala mondiale della seconda guerra che può essere o non essere fisicamente possibile".

Non esiste una riga nel grafico, ma puoi estrapolare ...

L'oggetto dell'esercizio con COCOMO, come qualsiasi altra metodologia di stima del software, è di rispondere a due domande: quanto costerà e quanto ci vorrà?

Che cosa significano i risultati mensili di sforzo di COCOMO e mesi di durata è che, quando il progetto è finito, si stima che avrai pagato l'equivalente di molti mesi mensili in stipendio e così tanti mesi sarà passato sul calendario.

NON significa che un uomo può farlo in tanti mesi e NON significa che molti uomini possano farlo in un mese.

Le stime di COCOMO si basano su linee sorgente di stime di codice consegnabili e producono risultati in mesi-uomo, poiché sia le linee di codice sorgente consegnabili che i mesi-uomo consumati sono facili da misurare dopo il fatto. Uno di questi proviene direttamente dal codice consegnato e l'altro proviene direttamente dai dati del libro paga del progetto. I numeri magici in COCOMO sono stati sviluppati eseguendo misurazioni postmortem sui dati di timecard e il numero di linee per un numero elevato di progetti.

Ciò consente di calibrare lo stimatore per la propria organizzazione specifica e migliorare la qualità generale delle stime della propria organizzazione specifica. Boehm et al consiglia vivamente a tutte le organizzazioni di farlo. I numeri che danno sono buoni punti di partenza per un'organizzazione individuale, ma sono incisi in tavolette di pietra e non sono la risposta definitiva.

Basic COCOMO ti dà ENTRAMBI lo sforzo totale nominale, in man-month, E la durata nominale del progetto, in mesi. Per ottenere il numero nominale di persone richiesto per quella durata, dividi lo sforzo per durata.

Questo è nominale. Basic COCOMO NON INDIRIZZA programmi off-nominali, compressi o allungati. Per tenere conto dell'effetto della gestione che strappa il calendario, devi utilizzare COCOMO intermedio o COCOMO dettagliato.

Per rispondere alla tua seconda domanda: Non è possibile assegnare unità ai singoli numeri magici di Basic COCOMO, perché il sistema è formalmente sottodescritto. Non hai modo di decidere quali unità vanno con quale numero magico e quali unità vengono cancellate nell'analisi delle dimensioni (etichetta del fattore).