Misurazione del rischio di modifiche al codice sorgente?

Il tuo manager non vuole numeri per i rischi.

Un manager di solito vuole sapere che non rovinerai il software.

Le due aree di rischio ammontano a "sai tutto ciò che devi sapere?" e "spezzerai qualcos'altro?"

Probabilmente dovresti dare un'analisi qualitativa dei rischi.

Elenca le domande che hai - le aree misteriose - le cose che potrebbero richiedere un follow-up o che potresti rompere perché non le capisci.

I "numeri" sono 1.0. Avrai cambiamenti di follow-up (ci sono sempre modifiche di follow-up) e introdurrai nuovi bug precedentemente sconosciuti (a meno che tu non abbia una vera e propria disciplina di test, che sembra improbabile dalla situazione e dalla domanda ).

Idealmente, capisci l'intero problema e non avrà bisogno di follow-up. È proprio vero? Che prove puoi dare che capisci tutto? Se si dispone di prove, presentarlo e affermare che non vi è alcun rischio di follow-up. Se non hai le prove che capisci l'intero problema, elenca le cose che non capisci. Questo è il rischio.

Idealmente, non romperai nient'altro. È proprio vero? Che prove puoi dare che il tuo cambiamento è isolato e non rompere qualcos'altro? Di nuovo, elenca le cose che potrebbero rompersi; questo è il rischio.

Tieni presente che le perfette conoscenze possono venire solo dopo in realtà hai completato tutte le modifiche. Solo dopo fai cambiare il codice, saprai se hai saputo o meno tutto e non hai infranto qualcos'altro.

Guardando nel futuro inconoscibile, puoi solo immaginare se sai tutto e non romperà nulla.

Di conseguenza, c'è un livello di rendimenti decrescenti. Puoi fornire prove che comprendi la modifica e non infrangerà nulla, ma non puoi essere assolutamente sicuro della tua analisi se non effettuando effettivamente il cambio di codice effettivo.

Il miglior punto di partenza sarebbe con alcuni esempi concreti. Scegli alcune aree della tua applicazione e calcola il costo di qualcosa che non va in quella zona e la probabilità che ciò accada.

Ad esempio, se hai apportato una modifica al processo di accesso, i costi potrebbero essere:

1. Utenti che non riescono ad accedere.
2. Chiunque sia in grado di accedere.
3. Utenti che accedono ma non hanno accesso alla funzionalità corretta, ovvero hanno il ruolo sbagliato.

La probabilità di ciascuna viene quindi valutata:

1. Improbabile: lo raccoglierai abbastanza rapidamente.
2. Improbabile - ancora questo è (o dovrebbe essere) facile da raccogliere.
3. Più probabile - a seconda della complessità con cui la tua applicazione individua che qualcuno ha accesso a qualcosa che non dovrebbe o non ha accesso a qualcosa che dovrebbero essere più difficile da individuare.

Quindi la necessità di "modifiche al codice di follow-up" e "potenziale perdita di stabilità" per i primi due è bassa (ma continuerà a esistere), mentre per il terzo è più alta.

Dopo averlo fatto per alcune aree ad alto e basso rischio, sarai in grado di assegnare qualsiasi cosa in una di queste aree.

Anche se ritengo che la "stima del rischio" sia per lo più una metrica errata, è ancora peggio se viene data a uno sviluppatore, specialmente lo stesso sviluppatore che lavorerà. Il tuo manager potrebbe anche chiederti di eseguire da solo test di accettazione e la tua revisione del codice.

Se esiste un metodo giusto per eseguire analisi dei rischi per un'attività o funzione, lo farei con alcune misure:

1. Quanti componenti indipendenti o punti di funzione toccherà la funzione?
2. Le funzionalità oi componenti interessati presentano una documentazione di progettazione chiara o completa o specifiche tecniche?
3. Le funzioni oi componenti interessati sono coperti dai test delle unità automatizzate?
4. Quali altre misure di debito tecnico stanno strangolando il sistema che potrebbe essere problematico?

Forse, se puoi rendere conto numericamente di questo genere di cose e formularle in una sorta di forum BS per determinare un rapporto di rischio, il tuo manager sarà probabilmente soddisfatto. Formule come quella che ho descritto, mentre per lo più prive di significato, sono come un porno manageriale.