Come documentare un software i cui requisiti sono mal gestiti? [chiuso]

3

Diciamo che ho un prodotto software complesso su cui le informazioni o le conoscenze sono disperse in tutta l'organizzazione che lo ha creato. Ci sono requisiti e caratteristiche su cui anche il reparto Controllo qualità / test non è molto sicuro.

Ci sono anche molte sfaccettature dello stesso prodotto software generico e il prodotto viene continuamente personalizzato secondo i requisiti aziendali del cliente. Inoltre, quando si tenta di esplorare il software con le mani, spesso tendono a perdersi a causa della sua complessità.

Quello che voglio sapere esattamente è come si può documentare le guide dell'utente finale secondo lo scenario sopra menzionato.

    
posta Maxood 07.01.2017 - 15:44
fonte

1 risposta

4

Cerca di convincere il tuo manager o chiunque sia arrivato a tale compito che non è una buona idea scrivere la documentazione per l'utente finale per software che è in uno stato così squallido. Aumenterà persino il debito tecnico perché crei un altro documento che presenterà delle lacune e che contiene errori fin dall'inizio e che deve essere aggiornato con il software.

A lungo termine sarà più economico documentare prima i requisiti del software, definire i casi di test, implementare test automatici e refactoring laddove ha senso. Con requisiti ragionevoli e gestione delle modifiche, sarà molto più facile scrivere la documentazione per l'utente finale e mantenerla sincronizzata con il software.

Se questa non è un'opzione, parla con alcuni utenti chiave e scopri come stanno usando il software, documenta i loro casi d'uso, aggiungi alcuni diagrammi che mostrano i moduli principali del software per quanto è ovvio, incolla alcuni screenshot, spiega i file di input e di output nel miglior modo possibile. Finirai con un documento che sembra almeno una guida per l'utente e potrebbe anche essere utile per un periodo limitato di tempo. Ma assicurati di non essere la persona responsabile della gestione del documento.

In alcuni casi questa è davvero l'opzione migliore perché la documentazione per l'utente finale ha una priorità molto bassa dal punto di vista del business in molti progetti software. Questo perché tende ad avere poca influenza sul successo del progetto.

    
risposta data 07.01.2017 - 17:25
fonte

Leggi altre domande sui tag