Procedura per la documentazione del software

-2

Sto cercando di scrivere la documentazione per un progetto e ho difficoltà a trovare informazioni sull'elenco di documenti che devono essere scritti. So che ci sono Vision and Scope, Requisiti degli utenti, Requisiti funzionali ecc., Ma non sono stato in grado di trovare una descrizione concreta su quali documenti dovrebbero essere scritti e in quale ordine.

Quali sono i documenti necessari per descrivere completamente una soluzione software? C'è qualche ordine raccomandato di scrivere quei documenti? C'è qualche libro che descrive questo processo in dettaglio?

    
posta Boris 15.05.2017 - 09:29
fonte

1 risposta

0

Esistono numerosi libri diversi, spesso in conflitto tra loro in un modo o nell'altro, a seconda della metodologia utilizzata, peggio ancora alcuni usano nomi diversi per fondamentalmente la stessa cosa e alcuni sostituiscono documenti specifici con altri concetti. Molto dipende anche dalla complessità del sistema / progetto e dal campo in cui deve essere utilizzato - con piccole e semplici utility in aree non critiche si aspettano meno, ma per progetti importanti e / o medici, militari, spazio, aviazione, ecc aspettiamo molto di più.

Sinceramente generalizzare per un progetto ragionevolmente complicato in un ambiente ragionevolmente formale aspettati:

  1. Documento concettuale - utilizzato per vendere l'idea alla gestione. Senza questo non sarai in grado di ottenere il finanziamento per iniziare
  2. Piano di gestione - Definisce come funzionerà, Controllo versione, ecc. può essere saltato in alcune organizzazioni / progetti o include il piano di qualità o ne fa riferimento uno.
  3. Budget (s) e / o documenti di analisi dei costi, disponibilità del personale, ecc.
  4. Analisi del rischio - Specialmente su sistemi di sicurezza critici
  5. Requisiti Cattura documenti - non sempre fatto
  6. Specifiche del sistema - Che cosa farà il prodotto finale a grandi linee.
  7. Da questo dovresti essere in grado di scrivere le specifiche di accettazione del sistema
  8. Documento di controllo dell'interfaccia - Essenziale se esiste più di un sottosistema o qualsiasi interfaccia esterna.
  9. Standard di codifica - se non sono già presenti
  10. Se esiste un'interfaccia utente, quindi linee guida UX o documenti di progettazione
  11. Documenti di progettazione dettagliata, (storie in Agile).
  12. Specifiche del test unitario / Criteri di accettazione della storia
  13. Codice e amp; Recensioni di prova
  14. Note per gli sviluppatori, principalmente come commenti nel codice & readme file ma possibilmente anche in un Wiki.
  15. Risultati test unità
  16. Risultati copertura test
  17. Bug e amp; Suggerimenti di miglioramento, idealmente un sistema di ticketing è specificato dal piano di gestione.
  18. Risultati dei test di sistema / integrazione
  19. Manuali
  20. Note sulla versione
  21. Materiali di marketing
  22. Rivedi i documenti su tutto quanto sopra
  23. Lezioni apprese
  24. Proposte / procedure di manutenzione
  25. Documenti per l'impostazione o la disattivazione del sole

Aspettatevi tutto quanto sopra per passare attraverso diverse iterazioni, (eventualmente con rilasci).

Potresti avere documenti aggiuntivi come i piani di sicurezza informatica e amp; Rapporti di prova, vari documenti per soddisfare la società, conformità e requisiti normativi, ecc.

Un paio di cose che ti esorto a fare mentre procedi:

  • Rilasciare i documenti anche se sai che probabilmente cambieranno - questo ti dà una scommessa sul terreno su cui lavorare e ti consente di gestire le modifiche che inevitabilmente si verificano, (se puoi confrontare Rev 4 con Rev 3 puoi vedere cosa è cambiato ma se non hai copie vecchie ...)
  • Acquisisci e utilizza i sistemi di controllo delle versioni e di controllo delle versioni in atto al più presto.
risposta data 15.05.2017 - 10:16
fonte

Leggi altre domande sui tag