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:
- Documento concettuale - utilizzato per vendere l'idea alla gestione. Senza questo non sarai in grado di ottenere il finanziamento per iniziare
- 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.
- Budget (s) e / o documenti di analisi dei costi, disponibilità del personale, ecc.
- Analisi del rischio - Specialmente su sistemi di sicurezza critici
- Requisiti Cattura documenti - non sempre fatto
- Specifiche del sistema - Che cosa farà il prodotto finale a grandi linee.
- Da questo dovresti essere in grado di scrivere le specifiche di accettazione del sistema
- Documento di controllo dell'interfaccia - Essenziale se esiste più di un sottosistema o qualsiasi interfaccia esterna.
- Standard di codifica - se non sono già presenti
- Se esiste un'interfaccia utente, quindi linee guida UX o documenti di progettazione
- Documenti di progettazione dettagliata, (storie in Agile).
- Specifiche del test unitario / Criteri di accettazione della storia
- Codice e amp; Recensioni di prova
- Note per gli sviluppatori, principalmente come commenti nel codice & readme file ma possibilmente anche in un Wiki.
- Risultati test unità
- Risultati copertura test
- Bug e amp; Suggerimenti di miglioramento, idealmente un sistema di ticketing è specificato dal piano di gestione.
- Risultati dei test di sistema / integrazione
- Manuali
- Note sulla versione
- Materiali di marketing
- Rivedi i documenti su tutto quanto sopra
- Lezioni apprese
- Proposte / procedure di manutenzione
- 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.