Sta misurando le metriche del progetto software diffuse nell'industria di oggi?

9

Ho incontrato uno sviluppatore che voleva consigli esterni sui progetti dei propri team. Ho scoperto che stanno sviluppando un'enorme suite software per i dirigenti aziendali, il project manager e gli sviluppatori in grado di calcolare automaticamente le metriche e rappresentarle graficamente per ogni iterazione.

Da 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 lo scope e le stime del tuo progetto?
  3. Come persona che analizza le metriche, quanto spesso decidi di basare le decisioni su di esse? IE. I test falliti a settimana stanno aumentando drasticamente?
  4. Pensi 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

    
posta Russ K 06.02.2011 - 20:40
fonte

2 risposte

6

Alcuni libri sulle metriche che la tua biblioteca del college probabilmente include Metriche software e Metrici 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.

Do most companies have some way, doesn't have to be an elegant program, to measure meaningful metrics?

Visual Studio include alcuni strumenti di analisi del codice che possono aiutarti a iniziare. La maggior parte delle aziende non ha nemmeno qualcosa per misurare la metrica peggiore possibile: linee di codice. "Appena fatto" sembra essere la forza trainante travolgente del settore, e le preoccupazioni di manutenibilità sono date poca attenzione alle preoccupazioni dei manager di "riceverò il mio bonus quest'anno?" e "sarà fatto nel tempo che ho promesso?" Anche con i prodotti che si trasferiscono di anno in anno con cambiamenti incrementali, questi due aspetti sminuiscono le preoccupazioni degli sviluppatori sulla manutenibilità e sulla rilevazione / prevenzione degli errori.

Which metrics, single or combined, help you narrow down your projects scope and estimates?

Trovo che complessità ciclomatica e coupling sono forti indicatori di quanto buggy o quanto sia difficile mantenere il codice. Se la complessità ciclomatica è intorno a 20, trovo che sarà quasi impossibile testare (visto che avrà fino a 2 ^ 20 percorsi attraverso il codice) e dovrebbe essere scomposto in parti più piccole. Non è possibile eliminare la complessità, ma è possibile suddividerla in blocchi più gestibili.

Se stai cercando la stima , probabilmente vorresti approfondire function punti .

Code coverage % is drastically lowering each iteration, do you alert your developers of the issue

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

L'argomento canonico usato dagli sviluppatori è che se misuri qualcosa, è solo quello che otterrai. Questo argomento deriva dall'idea che le sole metriche sono linee di codice.

    
risposta data 06.02.2011 - 21:05
fonte
2

Ero in un discorso sulle metriche del software in cui l'oratore ha fatto alcuni, IMHO, punti perspicaci. Avendo poca esperienza con queste cose, 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 obiettivo assoluto (ovvero la copertura del codice XX%) non è significativa.
  • Una metrica senza cronologia è utile.

Quindi, per risolvere questo:

  • Mostra diverse metriche, ad esempio:
    • numero di righe totali / modificate
    • numero di commit
    • % copertura del codice
    • numero di test
    • complessità ciclomatica
    • file / pacchetto / ... dipendenza
    • ...
  • Mostra dati dal QA / CI:
    • numero di bug / miglioramenti / modifiche (personalmente ritengo che questa categorizzazione sia importante)
    • # totale / aggiunto / corretto
  • Mostra queste metriche sui grafici che mostrano le tendenze nel tempo

In questo modo, quando i ticket vengono corretti rapidamente, si può vedere se la qualità del codice diminuisce. Inoltre, quando non sembra che molto stia succedendo con il database dei bug, la qualità del codice potrebbe aumentare, poiché i refactoring sono in corso.

Riassumendo: è questo tipo di comportamento dinamico che è importante e che ti dà informazioni piuttosto che dati non elaborati (che sarebbero il valore di una singola metrica).

Sto pianificando di mettere alcuni grafici secondo questo schema su una TV widescreen accanto alle nostre lampade laviche connesse al CI. ;)

    
risposta data 06.02.2011 - 22:42
fonte

Leggi altre domande sui tag