Qual è la differenza tra un bug e una richiesta di modifica in MSF per CMMI?

Question

Attualmente sto valutando il MSF for CMMI modello di processo sotto TFS da utilizzare nel mio team di sviluppo e ho difficoltà a comprendere la necessità di tipi separati di elementi di lavoro per bug e richieste di modifica.

Capisco che sia utile poter distinguere tra bug (errori) e richieste di modifica (modifica dei requisiti) durante la generazione di report.

Nel nostro sistema attuale, tuttavia, abbiamo un solo tipo di richiesta di modifica e utilizziamo semplicemente un campo per indicare se si tratta di un bug, di una modifica dei requisiti, ecc. (questo campo può essere utilizzato per creare query di report).

Quali sono i vantaggi di avere un flusso di lavoro separato per i bug?

Sono anche confuso dal fatto che gli sviluppatori possano inviare lavori contro un bug O una richiesta di modifica, pensavo che il flusso di lavoro previsto fosse che i bug generassero richieste di modifica che sono ciò a cui fa riferimento lo sviluppatore quando apporta modifiche.

Answer 1

@Luca

Non sono in disaccordo con te, ma questa differenza è in genere la spiegazione fornita del motivo per cui sono disponibili due diversi processi per gestire i due tipi di problemi.

Direi che se il colore della home page è stato originariamente progettato per essere rosso e per qualche motivo è blu, si tratta facilmente di una soluzione rapida e non è necessario coinvolgere molte persone o ore di lavoro per apportare la modifica.Basta controllare il file, cambiare il colore, ricontrollarlo e aggiornare il bug.

Tuttavia, se il colore della home page è stato progettato per essere rosso, ed è rosso, ma qualcuno pensa che debba essere blu, questo, almeno per me, è un diverso tipo di cambiamento.Ad esempio, qualcuno ha pensato all'impatto che ciò potrebbe avere su altre parti della pagina, come immagini e loghi sovrapposti allo sfondo blu?Potrebbero esserci confini tra le cose che sembrano brutte?La sottolineatura dei link è blu, verrà visualizzata?

Ad esempio, sono daltonico rosso/verde, cambiare il colore di qualcosa non è, per me, qualcosa che prendo alla leggera.Ci sono abbastanza pagine web sul web che mi danno problemi.Giusto per sottolineare che anche il cambiamento più banale può non essere banale se si considera tutto.

L'effettiva modifica dell'implementazione finale è probabilmente più o meno la stessa, ma per me è una richiesta di modifica È una bestia diversa, proprio perché bisogna pensarci di più per essere sicuri che funzioni come previsto.

Un bug, però, è che qualcuno ha detto ecco come lo faremo e poi qualcuno ha fatto diversamente.

Una richiesta di modifica è più simile ma bisogna considerare anche quest'altra cosa...Hmm....

Naturalmente ci sono delle eccezioni, ma lasciami fare i tuoi esempi a parte.

Se il server fosse progettato per gestire più di 300.000.000.000 di visualizzazioni di pagina, allora sì, è un bug che non lo faccia.Ma progettare un server per gestire così tante visualizzazioni di pagina è molto più che semplice dire il nostro server dovrebbe gestire 300.000.000.000 di visualizzazioni di pagina, dovrebbe contenere a molto specifiche dettagliate su come è possibile farlo, fino alle garanzie sui tempi di elaborazione e ai tempi medi di accesso al disco.Se il codice viene quindi implementato esattamente come progettato e non è in grado di funzionare come previsto, la domanda diventa: l'abbiamo progettato in modo errato o lo abbiamo implementato in modo errato?.

Sono d'accordo che in questo caso, se sia da considerare un difetto di progettazione o un difetto di implementazione dipende dal motivo effettivo per cui non è all'altezza delle aspettative.Ad esempio, se qualcuno presumesse che i dischi fossero 100 volte più veloci di quanto lo siano in realtà, e questo è considerato il motivo per cui il server non funziona come previsto, direi che si tratta di un bug di progettazione e qualcuno deve riprogettarlo .Se il requisito originale di così tante visualizzazioni di pagina deve ancora essere mantenuto, potrebbe essere necessario intraprendere un'importante riprogettazione con più dati in memoria e simili.

Tuttavia, se qualcuno non ha preso in considerazione il funzionamento dei dischi raid e come trarre vantaggio correttamente dai supporti con striping, si tratta di un bug e potrebbe non essere necessario un cambiamento così grande per essere risolto.

Anche in questo caso ci saranno ovviamente delle eccezioni.

In ogni caso, la differenza originale che ho affermato è quella che ho riscontrato essere vera nella maggior parte dei casi.

Answer 2

Tieni presente che una parte della definizione del tipo di elemento di lavoro per TFS è la definizione del suo "flusso di lavoro", ovvero gli stati in cui può trovarsi l'elemento di lavoro e le transizioni tra gli stati.Ciò può essere garantito dal ruolo di sicurezza.

Quindi, in generale, una "Richiesta di modifica" verrebbe avviata e approvata da qualcuno relativamente in alto in un'organizzazione (qualcuno con diritti di "sponsorizzazione" relativi alla spesa delle risorse per apportare una modifica (possibilmente molto ampia) al sistema.Alla fine sarà questa persona ad approvare che la modifica sia stata apportata con successo.

Per un "Bug", tuttavia, QUALSIASI utente dell'applicazione dovrebbe essere in grado di avviare un Bug.

In un'organizzazione in cui ho implementato TFS, solo i capi dipartimento possono essere gli autori di una "richiesta di modifica", ma i "bug" sono stati creati dai ticket "Help Desk" (non automatizzati, solo attraverso il processo...)

Answer 3

In generale, anche se non posso parlare a nome di CMM, le richieste di modifica e i bug vengono gestiti e considerati in modo diverso perché in genere si riferiscono a parti diverse del ciclo di vita dell'applicazione.

Un bug è un difetto nell'implementazione del programma.Ad esempio, se progetti il ​​tuo programma in modo che sia in grado di sommare due numeri e fornire la somma all'utente, un difetto sarebbe che non gestisce correttamente i numeri negativi, e quindi un bug.

Una richiesta di modifica avviene quando si riscontra un difetto di progettazione.Ad esempio, potresti aver detto specificamente che il tuo programma non dovrebbe gestire numeri negativi.Viene quindi presentata una richiesta di modifica per riprogettare e quindi reimplementare quella parte.Il difetto di progettazione potrebbe non essere intenzionale, ma potrebbe facilmente essere dovuto al fatto che semplicemente non hai considerato quella parte quando hai progettato originariamente il tuo programma, o che sono stati inventati o scoperti nuovi casi che non esistevano al momento in cui è stato creato il progetto originale Da.

In altre parole, un programma potrebbe funzionare esattamente come progettato, ma necessitare di modifiche.Questa è una richiesta di modifica.

---

In genere, correggere un bug è considerata un'azione molto più economica rispetto all'esecuzione di una richiesta di modifica, poiché il bug non è mai stato concepito per far parte del tuo programma.Il design, tuttavia, lo era.

Pertanto potrebbe essere necessario un flusso di lavoro diverso per gestire i due diversi scenari.Ad esempio, potresti avere un modo diverso di confermare e segnalare i bug rispetto alle richieste di modifica, il che potrebbe richiedere più lavoro per definire le conseguenze della modifica.

Answer 4

Un bug è qualcosa che non funziona in un requisito di cui è già stata approvata l'implementazione.

Una richiesta di modifica deve passare attraverso un ciclo in cui devono essere stimati l'impatto e l'impegno per tale modifica, quindi deve essere approvata per l'implementazione prima che possa iniziare il lavoro su di essa.

I due sono fondamentalmente diversi sotto CMM.

Answer 5

La mia ipotesi è quindi errata secondo cui le richieste di modifica dovrebbero essere generate da bug?Sono confuso perché non penso che tutti i bug dovrebbero essere automaticamente approvati per l'implementazione: potrebbero essere banali e almeno nel nostro caso passeranno attraverso lo stesso processo di revisione di una richiesta di modifica prima di essere assegnati a uno sviluppatore.