Quali sono le cose che metti in un documento di analisi dell'impatto?

Quindi stai correggendo i bug, quindi ne hai riscontrato uno che potrebbe influenzare altri moduli del prodotto software. I tuoi dati non sono sufficienti per supportare la tua richiesta sugli effetti della correzione e ti è stato chiesto di creare un documento di analisi dell'impatto.

1. Esiste un processo definito su come farlo?
2. Quali sono le informazioni chiave necessarie?
3. Esistono formati / modelli noti per questo documento?

I modelli che ho visto per l'analisi dell'impatto sono stati realizzati all'interno dell'azienda per cui lavoro. Lo usiamo per valutare le richieste di modifica e prima di lavorare su di esse (e possibilmente per respingerne alcune). Aveva sezioni come questa:

• Impatto sui requisiti: in questa sezione l'analista scrive ciò che deve essere modificato nei casi d'uso per supportare la modifica richiesta.
• Impatto sul design e sull'architettura: in questa sezione l'architetto e il progettista menzionano quali parti del modello devono essere modificate o rifatte per supportare il cambiamento.
• Impatto sul test: il controllo qualità scrive che i casi di test devono essere aggiornati.
• Stima e impatto sulla pianificazione: il project manager stima lo sforzo necessario e il costo della modifica e l'impatto sulla pianificazione del progetto.

Per coprire tutti i possibili impatti è necessario esaminare le dipendenze. Se si dispone di una matrice di tracciabilità bidirezionale, sarà più semplice.

Abbiamo utilizzato l'ordine sopra indicato perché il progettista dovrà conoscere l'impatto dal punto di vista dell'analista per ottenere una migliore comprensione del cambiamento e così anche il tester deve conoscere l'opinione dell'analista e dell'architetto. Allo stesso modo, il PM ha bisogno di tutte le informazioni per conoscere il costo e il programma.

Lo abbiamo usato con CR ma puoi usarlo con i bug allo stesso modo. Inoltre, se è necessario eseguire questa operazione per scegliere tra diverse soluzioni di correzione per risolvere il bug, sarà necessario ripetere l'analisi dell'impatto per ogni possibile soluzione e consolidare tutti i dati in un modulo di analisi e risoluzione delle decisioni (DAR) per sapere quale soluzione è il migliore. Nel modulo DAR è necessario aggiungere alcuni fattori di valutazione come la manutenibilità futura o altri fattori che non sono inclusi implicitamente nell'analisi di impatto. Quindi assegna il peso a ciascun fattore e dai il punteggio di ogni soluzione in ciascun fattore. Infine moltiplica e somma il punteggio * peso e scegli il migliore. Si noti che il costo può essere incluso nei fattori o il PM può avere un'altra opinione.

Credo con qualsiasi documentazione che l'approccio agile sia valido. Ora, ci sono alcune idee sbagliate là fuori che agile significa "nessuna documentazione o analisi", ma non è così. Le cose che ho letto su Agile dicono: "usa ciò che funziona". Presumo che ciò significhi che il documento dovrebbe essere di lunghezza e dettaglio commisurato all'attività.

I modelli possono essere utili come elenco di controllo, ma non richiederei che ogni sezione venga compilata per modifiche piccole o a basso rischio. Per un cambio di riga, forse non hai bisogno di un documento. Non ho mai usato un modello per un documento di analisi dell'impatto, ma mi occupo regolarmente di requisiti aziendali o specifiche tecniche. Un modello può essere troppo restrittivo; una buona linea guida è invece quella di considerare chi sarà il pubblico. Se è per manager che non sono tecnici, concentrati sulla giustificazione aziendale per il cambiamento. Se è per tecnici, fornisci un po 'di background in modo che una nuova persona nella squadra non si perda e dai loro abbastanza per andare avanti se devono supportare il cambiamento. Inoltre, se vuoi qualcosa di ancora più leggero e privo di attriti, non usare affatto un documento, inseriscilo in un wiki.

Informazioni da includere:

• Breve descrizione del problema
• Spiegare o mostrare esempi di come il difetto stia causando guasti e / o inefficienza
• Includi la stima della complessità
• Includi la stima di costi e tempi per la correzione

Questo è un minimo decente. L'altro post ha messo in evidenza alcune cose CMMi piuttosto pesanti di IBM; è fantastico se hai il tempo e le risorse per farlo (e quando stai costruendo sistemi per la NASA in cui è in gioco la vita umana, allora è meglio che la gente sia seria al riguardo) ma per i piccoli team probabilmente non devi essere così pesante . Fai attenzione al preventivo, come sempre. I manager sono propensi ad assumere che una stima sia effettiva.

Si noti che ci sono pericoli nell'approccio agile. Alcuni sviluppatori pensano che significhi "non è necessario alcun documento, basta iniziare l'hacking" (che potrebbe essere OK in alcune situazioni). Inoltre, altri prenderanno la latitudine data l'attività e semplicemente scriveranno documenti davvero scadenti che non aiutano davvero (non necessariamente OK nella maggior parte delle situazioni). Parte del problema è che scrivere bene richiede uno sforzo, abilità e tempo; la maggior parte di noi è a corto di almeno due di queste cose;)

Sono sempre stato grande nella documentazione perché ti dimostra almeno di aver pensato abbastanza per qualificarti come avere un piano. Ma nella mia vecchiaia ho anche capito che troppa documentazione può di per sé diventare una seccatura per la manutenzione e che non c'è abbastanza gente che si preoccupa abbastanza per mantenere la documentazione aggiornata.

Il documento di analisi dell'impatto è effettivamente richiesto in progetti su larga scala, specialmente dove i programmatori lavorano geograficamente in luoghi diversi.

Il documento di analisi dell'impatto deve essere approvato dal responsabile per assicurarsi che la modifica non influisca sull'altro componente che funziona correttamente nella produzione.

L'analisi dell'impatto è necessaria per assicurarsi che il requisito sia completamente compreso e che tutti i componenti da modificare siano identificati per evitare rilavorazioni

L'analisi dell'impatto è richiesta anche per la responsabilità delle parti interessate dei clienti. Altrimenti, quando si verifica un problema dopo la distribuzione, lo sviluppatore diventa il capro espiatorio.

L'analisi dell'impatto è la base per la stima. Senza di ciò la stima non ha alcuna posizione. Potrebbe essere troppo alto o potrebbe essere troppo basso. Con Impact Analysis se lo sforzo effettivo supera, è anche facile da spiegare.

Qui hai un modello normato per un rapporto di analisi dell'impatto. È personalizzato per un settore specifico del settore, ma ha comunque sezioni utili che possono essere d'ispirazione per scrivere il tuo documento.

Il link: http://www.itu.int/en/itu-d/projects/documents/templateimpactanalysis.pdf

Saluti