Ho visto il sito di Carnegie Mellon che copre TSP. Sto cercando una guida pratica, non accademica per l'applicazione di TSP nel mondo reale. Mi piacerebbe davvero sapere, in che modo TSP riduce i bug?
Ho visto il sito di Carnegie Mellon che copre TSP. Sto cercando una guida pratica, non accademica per l'applicazione di TSP nel mondo reale. Mi piacerebbe davvero sapere, in che modo TSP riduce i bug?
Se non hai familiarità con il Personal Software Process (PSP), inizierei con il libro di Watts Humphrey PSP: Una guida per l'auto-miglioramento per gli sviluppatori software . Questo libro è rivolto ai professionisti che cercano di applicare la PSP nel loro lavoro. Inizia inoltre a introdurre il Team Software Process (TSP) nei capitoli successivi. Una breve introduzione ad alto livello della PSP può essere trovata anche in Introduzione al processo di personal software , anche da Watts Humphrey. Sebbene io non li possegga, i libri canonici sul Processo software del team sono Introduzione al processo del software del team ( una panoramica di alto livello per iniziare), TSP: Leading a Development Team e TSP: Coaching Development Teams . Poiché hai menzionato il sito web TSP , probabilmente hai già visto Rapporto tecnico sui processi software di Team insieme a altri report pubblicati dal Software Engineering Institute sul TSP .
La PSP e, per estensione, il TSP, riducono i difetti introducendo un processo ripetibile e quantitativamente misurato. Il TSP richiede una squadra (o team) di ingegneri addestrati alla PSP che collaborino su un progetto più ampio. Per capire come il TSP riduce i difetti, devi prima utilizzare la PSP per ridurre i difetti a livello individuale acquisendo intuizioni e apportando modifiche al singolo processo.
In PSP0, inizi a fare misurazioni per capire come sviluppi il software attuale: dimensioni, tempo, numero di difetti e così via. L'atto di registrare semplicemente i dati e di analizzarli può fornire informazioni su quali fasi del ciclo di vita sono più problematiche per l'individuo, sia per singoli elementi di dati sia per una combinazione di essi.
PSP1 non aggiunge alcun aspetto di qualità, ma migliora la stima. Potrebbe esserci un miglioramento della qualità in quanto si ha una maggiore comprensione di come si usa il tempo e si può allocare e utilizzare il tempo in modo più efficiente. Anche se non si utilizzano questi dati fino a PSP2, si inizia a rintracciarlo ora per avere un record storico con cui iniziare. Essere in grado di sapere se è necessario dedicare più tempo a un particolare aspetto del ciclo di vita del prodotto o se il tempo viene sprecato potrebbe aiutarti a migliorare la qualità del processo, se non anche la qualità del prodotto.
In PSP2, aggiungi recensioni per prevenire e rimuovere i difetti. Inoltre, si aggiunge il miglioramento del processo, utilizzando le misurazioni e le stime, nonché la registrazione in cui si verificano i difetti. Prendendo tempo, dimensioni, difetti e dati di stima, così come i dati di iniezione dei difetti appena aggiunti, è possibile rispondere a più domande. Le relazioni si formano tra le dimensioni del programma e i tassi di difetti, il tempo trascorso in recensioni rispetto ai tassi di difetto e così via. L'utilizzo di questo ti consente di agire (ad esempio, se trascorri molto tempo nelle revisioni, ma molti difetti sfuggono alla fase successiva, c'è un problema con il modo in cui conduci le recensioni).
Il Team Software Process coinvolge un team di ingegneri che utilizzano PSP, li ridimensiona e aggiunge attività a livello di gestione per coordinare le loro interazioni ed esplorare misure e metriche rilevanti per un team di sviluppatori software anziché solo a livello individuale. La capacità di identificare misure e metriche rilevanti e quindi applicarle per identificare punti deboli nel processo è l'intero punto sia del TSP che della PSP.
Leggi altre domande sui tag development-process