Esiste una metrica che può essere equiparata alla complessità in parole povere? [chiuso]

La maggior parte dei progetti di programmazione contemplati da una singola persona o da un piccolo team non sono caratterizzati dalla loro complessità, sono meglio caratterizzati semplicemente dalla loro dimensione.

Per stimare qualcosa in base alla sua dimensione:

• trova una tipica "unità"
• stimare il tempo impiegato per costruire una "unità" come T
• conta il numero di "unità" come N
• moltiplica N x T
• se ci sono più tipi di unità, ripetere per ciascuna e aggiungere insieme
• aggiungi alcuni fattori fondenti per l'integrazione, la complessità, i sovraccarichi, la rilavorazione, ecc.

Un sistema aziendale di base potrebbe avere 20 moduli, 30 tabelle di database, 10 rapporti, 2 connessioni ad altri sistemi. Il risultato finale potrebbe essere di 10.000 righe di codice. Potrebbe richiedere 200 pagine di documentazione. Ognuno di questi può essere usato come "unità".

Mostra al cliente l'elenco di "unità", il conteggio e la stima per ciascuno e il totale. Quindi confrontalo con una grande casa o un piccolo condominio con un numero simile di "unità".

Le dimensioni contano più della complessità, ma è ancora molto più difficile scrivere un compilatore o una libreria di framework rispetto a un sistema aziendale di base e le "unità" sono molto più difficili da identificare.

L'approssimazione più vicina è il tempo. Se un sistema è piccolo ma richiede molto tempo, ciò è in genere dovuto alla sua complessità. Tuttavia, questa è una metrica molto difficile da catturare.

Ciò che ho trovato utile è stimare il progetto. Rompi questa stima in pezzi. L'idea è di scomporla nei pezzi più piccoli che hanno senso, che normalmente sono storie nella metodologia Agile.

Nessuno può davvero comprendere che un sistema richiede 5000 ore di lavoro da completare. È troppo grande di un numero. Ma analizzalo in storie individuali e ognuna è più facile da digerire. Se una storia è complessa e richiede più tempo, ciò sarà più facile da spiegare a livello di storia piuttosto che ad es. il livello epico o di sistema.

Una cosa è dire che un grattacielo è un edificio complesso: penso che noi come laici siamo d'accordo su questo fatto, ma è difficile spiegare perché. È più significativo dire che un sottocomponente è complesso. Ad esempio, l'impianto elettrico è complesso perché nell'edificio ci saranno 5.000 uffici separati che vengono misurati individualmente. Il sistema fognario è complesso perché ci saranno 400 servizi igienici in un edificio verticale che devono essere scaricati correttamente.

Quando decomponi un grosso problema in piccoli, diventa più facile allegare stime a loro e spiegare perché un componente è complesso.

Quindi no, non esiste un numero di proiettili d'argento che puoi usare per valutare la complessità. Tuttavia, puoi scomporre un problema in parti più piccole, più facili da capire e spiegarle.

Non proprio.

Finora, è stato dimostrato che OGNI metrica di complessità del software che è stata proposta, su dati reali da progetti reali, da correlare strongmente con molto strongmente con SLOC grezzo: numero grezzo di righe di codice sorgente . La complessità ciclomatica di McCabe risulta essere degna di nota in questo senso di colpa, con tutte le metriche di Halstead che gli stanno alle calcagna.

Potresti creare una metrica di fantasia e dire che i programmi con un valore McWizzBang di 42 sono più complessi (o complicati) dei programmi con McWizzBang = 7, ma stai solo dicendo che un programma con un milione di righe di codice è più complesso di un programma con mille righe di codice. Bene, DUHHHH!

Per inciso, anche se non lo stavi chiedendo, lo stesso vale per la stima dei costi del software. Indipendentemente da ciò che cerchi di stimare, per ottenere la tua stima dei costi, si scopre che puoi ottenere lo stesso botto per molto meno buck stimando lo SLOC grezzo.