Care este diferența dintre o eroare și o cerere de modificare în MSF pentru CMMI?

În prezent, evaluez șablonul de proces MSF pentru CMMI sub TFS pentru a fi utilizat de echipa mea de dezvoltare și am probleme cu înțelegerea nevoii de lucru separat tipuri de elemente.

Înțeleg că este benefic să se poată face diferența între erorile (erorile) și cererile de schimbare (modificarea cerințelor) atunci când se generează rapoarte.

În sistemul nostru actual, totuși, avem doar un singur tip de solicitare de modificare și folosim doar un câmp pentru a indica dacă este vorba despre un bug, modificarea cerințelor etc. (acest câmp poate fi folosit pentru a crea interogări de raportare).

Care sunt avantajele unui flux de lucru separat pentru bug-uri?

Sunt, de asemenea, confundat de faptul că dezvoltatorii pot depune o lucrare împotriva unei erori sau unei cereri de modificare, credeam că fluxul de lucru intenționat a fost acela ca bug-urile să genereze cereri de schimbare, ceea ce dezvoltatorii se referă la efectuarea modificărilor.

0
fr hi bn

5 răspunsuri

Prezumția mea este incorectă, atunci că cererile de modificare ar trebui generate de bug-uri? Sunt confuz, pentru că nu cred că toate bug-urile ar trebui să fie aprobate automat pentru implementare - ele pot fi banale și cel puțin în cazul nostru vor trece prin același proces de revizuire ca și o cerere de modificare înainte de a fi alocate unui dezvoltator.

0
adăugat

O eroare este ceva care este rupt într-o cerință care a fost deja aprobată pentru implementare.

O solicitare de schimbare trebuie să treacă printr-un ciclu în care impactul și efortul trebuie estimate pentru această schimbare și apoi trebuie aprobat pentru implementare înainte de începerea lucrului.

Cele două sunt fundamental diferite în cadrul CMM.

0
adăugat

În general, deși nu pot vorbi despre CMM, cererile de schimbare și bug-urile sunt tratate și luate în considerare diferit, deoarece acestea se referă, în mod obișnuit, la diferite piese ale ciclului de viață al aplicației.

Un bug este un defect în implementarea programului. De exemplu, dacă proiectați programul pentru a putea adăuga două numere și a da utilizatorului suma, un defect ar fi că acesta nu gestionează corect numerele negative și, deci, o eroare.

O solicitare de modificare este atunci când aveți un defect de proiectare. De exemplu, este posibil să fi spus în mod specific că programul dvs. nu ar trebui să gestioneze numere negative. O cerere de modificare este apoi depusă pentru a reproiecta și, astfel, a reimplementa acea parte. Defectele de proiectare ar putea să nu fie intenționate, dar ar putea fi cu ușurință pentru că tocmai nu ați luat în considerare acea parte când proiectați inițial programul dvs. sau dacă au fost inventate sau descoperite cazuri noi care nu existau la momentul creării designului original de cand.

Cu alte cuvinte, un program ar putea funcționa exact așa cum a fost proiectat, dar trebuie schimbat. Aceasta este o cerere de modificare.


În mod tipic, fixarea unui bug este considerată o acțiune mult mai ieftină decât executarea unei cereri de modificare, deoarece bug-ul nu a fost niciodată destinat să facă parte din programul dvs. Proiectul a fost totuși.

Astfel, un flux de lucru diferit ar putea fi necesar pentru a face față celor două scenarii diferite. De exemplu, este posibil să aveți o altă modalitate de a confirma și de a depune erori decât pentru cererile de modificare, ceea ce ar putea necesita mai multă muncă pentru a stabili consecințele modificării.

0
adăugat

@Luke

Nu sunt de acord cu dvs., dar această diferență este, de obicei, explicația dată de ce există două procese diferite disponibile pentru tratarea celor două tipuri de probleme.

Aș spune că dacă culoarea paginii principale a fost concepută inițial pentru a fi roșu și pentru un motiv oarecare este albastră, este ușor o reparație rapidă și nu trebuie să implice mulți oameni sau ore de lucru pentru a face schimbarea. Doar verificați fișierul, schimbați culoarea, verificați-l din nou și actualizați eroarea.

Cu toate acestea, dacă culoarea paginii de pornire a fost concepută pentru a fi roșu și este roșu, dar cineva crede că trebuie să fie albastru, adică, pentru mine, oricum, un alt tip de schimbare. De exemplu, cineva sa gândit la impactul pe care l-ar putea avea asupra altor părți ale paginii, cum ar fi imagini și logo-uri care suprapun fundalul albastru? Ar putea exista granițe de lucruri care ar părea rău? Sublinierea link-ului este albastră, va apărea?

De exemplu, sunt roșu / verde culoarea orb, schimbarea culorii ceva este, pentru mine, nu ceva ce iau ușor. Există suficiente pagini web pe web care îmi dau probleme. Doar pentru a arăta că chiar și schimbarea cea mai trivială poate fi netrivială dacă luați în considerare totul.

Schimbarea reală a implementării finale este probabil aceeași, dar pentru mine o cerere de modificare este o fiară diferită, tocmai pentru că trebuie gândită mai mult pentru a vă asigura că va funcționa așa cum era de așteptat.

O eroare, totuși, este că cineva a spus cum o să facem asta și apoi cineva a făcut-o diferit.

O solicitare de modificare este mai mult ca , dar trebuie să luăm în considerare și acest lucru ... hmm ... .

Există desigur excepții, dar permiteți-mi să vă despart exemplele.

Dacă serverul a fost proiectat pentru a gestiona mai mult de 300.000.000.000 de afișări de pagini, atunci da, este un bug pe care nu îl are. Dar proiectarea unui server care să se ocupe de multe vizualizări de pagină este mai mult decât să spună că serverul nostru ar trebui să gestioneze 300.000.000.000 afișări de pagină , ar trebui să conțină o specificație detaliată foarte pentru modul în care poate face acest lucru până la garanțiile timpului de procesare și timpii medii de acces la discuri. În cazul în care codul este apoi implementat exact așa cum a fost proiectat și în imposibilitatea de a efectua cum era de așteptat, atunci întrebarea devine: am proiectat-o ​​incorect sau am implementat-o ​​incorect? .

Sunt de acord că în acest caz, dacă este vorba despre un defect de proiectare sau o eroare de implementare, depinde de motivul real pentru care nu reușește să se ridice la înălțimea așteptărilor. De exemplu, dacă cineva a presupus că discurile au fost de 100 de ori mai rapide decât acestea, și acesta este considerat motivul pentru care serverul nu reușește să funcționeze așa cum era de așteptat, aș spune că acesta este un bug de design și cineva trebuie să reproiectat . Dacă cerința inițială a numeroaselor vizualizări de pagină este încă în curs de desfășurare, ar trebui să se realizeze o reproiectare majoră, cu date suplimentare în memorie și altele similare.

Cu toate acestea, dacă cineva nu a reușit să ia în considerare modul în care funcționează discurile raid și cum să beneficieze în mod corect de mediile dungate, este un bug și s-ar putea să nu aibă nevoie de o schimbare mare pentru remediere.

Din nou, vor exista desigur excepții.

În orice caz, diferența inițială pe care am declarat-o este cea pe care am găsit-o în multe cazuri adevărată.

0
adăugat

Rețineți că o parte a definiției tipului de articol de lucru pentru TFS este definiția "fluxului de lucru", care înseamnă stațiile pe care poate fi elementul de lucru și tranzițiile dintre stări. Acest lucru poate fi asigurat prin rolul de securitate.

Deci, în general, o "cerere de schimbare" va fi inițiată și aprobată de o persoană relativ înaltă într-o organizație (cineva cu drepturi de "sponsorizare", legate de cheltuirea resurselor pentru a face o schimbare (eventual foarte mare) a sistemului. persoana ar fi cea care să aprobe faptul că schimbarea a fost făcută cu succes.

Cu toate acestea, pentru un "Bug", orice utilizator al aplicației ar trebui să poată iniția un Bug.

La o organizație la care am implementat TFS, numai departamentele departamentale pot fi inițiatorii unei "solicitări de modificare" - dar "Bugs" au fost create de bilete de ajutor (nu sunt automatizate, doar prin proces ...)

0
adăugat