La misurazione delle metriche dei progetti software è popolare nell'industria di oggi?

Ho incontrato uno sviluppatore che voleva alcuni consigli esterni sul progetto dei loro team. Ho scoperto che stanno sviluppando un'enorme suite di software per dirigenti, project manager e sviluppatori delle aziende in grado di calcolare automaticamente le metriche e rappresentarle graficamente per iterazione.

Come studente di informatica, conosco molto poco le metriche e la loro importanza, ma le mie domande sono:

1. La maggior parte delle aziende ha un modo, non deve essere un programma elegante, per misurare metriche significative?
2. Quali metriche, singole o combinate, ti aiutano a restringere l'ambito e le stime dei tuoi progetti?
3. Come persona che analizza le metriche, con quale frequenza prendi le decisioni su di esse? IE. I test falliti a settimana stanno aumentando drasticamente?
4. Ritieni che l'introduzione dello studio delle metriche ti abbia aiutato a capire meglio il progetto?

Non so perché, ma il progetto degli sviluppatori mi ha incuriosito e devo saperne di più. Se y

Alcuni libri sulle metriche che probabilmente la tua biblioteca universitaria ha probabilmente includono Metriche e metriche e modelli nell'ingegneria della qualità del software . Quei 2 dovrebbero darti un punto di partenza. Nel mondo industriale, pochissime aziende hanno una sorta di programma di misurazione metrica.

La maggior parte delle aziende ha un modo, non deve essere un programma elegante, per misurare metriche significative?

Visual Studio include alcuni strumenti di analisi del codice che possono iniziare. La maggior parte delle aziende non ha nemmeno qualcosa per misurare la peggiore metrica possibile: righe di codice. "Fallo e basta" sembra essere la forza trainante del settore e le preoccupazioni di manutenibilità ricevono un'attenzione molto breve alle preoccupazioni dei manager di "riceverò il mio bonus quest'anno?" e "sarà fatto nel tempo che ho promesso?" Anche con prodotti che si ripercuotono di anno in anno con cambiamenti incrementali, queste 2 preoccupazioni hanno sminuito gli sviluppatori riguardo alla manutenibilità e alla rilevazione / prevenzione dei bug.

Quali metriche, singole o combinate, ti aiutano a restringere l'ambito e le stime dei tuoi progetti?

Trovo che la complessità e l' accoppiamento ciclomatici siano forti indicatori di quanto il buggy o quanto difficile sarà mantenere il codice. Se la complessità ciclomatica è di circa 20, trovo che sarà quasi impossibile testarlo (poiché avrà fino a 2 ^ 20 percorsi attraverso il codice) e dovrebbe essere scomposto in pezzi più piccoli. Non è possibile eliminare la complessità, ma è possibile suddividerla in blocchi più gestibili.

Se stai cercando una stima , probabilmente vorrai studiare i punti funzione .

La copertura del codice% sta riducendo drasticamente ogni iterazione, avvisate gli sviluppatori del problema

Trovo che la maggior parte dei manager si preoccupi del numero di check-in e del numero di bug che vengono corretti. Il mio attuale manager si oppone ai test unitari (pensa che sia una perdita di tempo) e il mio precedente manager pensava che il tempo speso per i test unitari fosse il tempo che avrebbe dovuto essere impiegato a scriverlo in primo luogo.

L'argomento canonico utilizzato dagli sviluppatori è che se si misura qualcosa, questo è solo ciò che si otterrà. Questo argomento nasce dall'idea che l'unica metrica sia la riga di codice.

Stavo parlando di una metrica del software in cui l'oratore ha espresso alcuni punti, IMHO, approfonditi. Avendo poca esperienza con queste cose da solo, ero ancora intrigante e ispirato, ma non posso dire se è sbagliato o giusto.

Le idee principali erano:

• Nessuna metrica singolare è utile a sé stante.
• L'impostazione di un target assoluto (ovvero una copertura del codice del XX%) non è significativa.
• Una metrica senza cronologia è utile.

Quindi, per risolvere questo:

• Mostra diverse metriche, come ad esempio:
  • Numero di righe totali / modificate
  • Numero di commit
  • % di copertura del codice
  • Numero di test
  • complessità ciclomatica
  • dipendenza file / pacchetto / ...
  • ...
• Mostra dati da QA / CI:
  
  • Numero di bug / miglioramento / modifiche (personalmente ritengo che questa classificazione sia importante)
  • # totale / aggiunto / fisso
• Mostra queste metriche su grafici che mostrano le tendenze nel tempo

In questo modo, quando i ticket vengono risolti rapidamente, si può vedere se la qualità del codice diminuisce. Inoltre, quando non sembra accadere molto con il database dei bug, la qualità del codice potrebbe aumentare, mentre si stanno effettuando i refactoring.

Riassumendo: è questo tipo di comportamento dinamico che è importante e ciò che ti dà informazioni piuttosto che dati grezzi (che sarebbe il valore di una singola metrica).

Sto progettando di mettere alcuni grafici secondo questo schema su un televisore widescreen vicino alle nostre lampade lava connesse CI. ;)