Penso che la lista dovrebbe includere:

• I requisiti non tecnici (c'era un tale documento, giusto?)
• I requisiti tecnici
• Un documento "decisioni" (se ce n'è stato uno) che spiega perché alcune decisioni sono state prese rispetto ad altre. Questo potrebbe già essere in un diverso requisito o documento di architettura, ma di solito lo facciamo separatamente per Big Decisions.
• Il codice e altre risorse (file immagine, CSS, ecc.)
• Il modello di database (come diagramma, documento, qualunque cosa)
• DDL per creare il database.
• DML per inizializzare il database.
• Un documento che spiega la configurazione dell'applicazione e la risoluzione dei problemi di base.
• Un elenco di tutti i nomi utente importanti e le relative password (per gli account di amministrazione), nonché istruzioni su come modificare la password. Idealmente, quando impostano il sito Web per la prima volta, dovrebbero essere invitati a inserire una nuova password di amministratore, ma questa è più una questione di architettura.
• Requisiti di sistema, e per le app Web, anche i requisiti minimi di hosting (l'app ha bisogno di MySQL o PostgreSQL? Quanta RAM? ecc.)

Non tutte queste cose potrebbero essere disponibili (o necessarie) per ogni progetto, ma penso che questa sia una buona guida generale.

Oltre alla buona risposta di FrustratedWithFormsDesigner, vorrei dire cosa includono i documenti non tecnici (come abbiamo fatto):

• i dati dell'analisi: cosa ti ha detto il cliente quando hai parlato per la prima volta dei requisiti?

• l'offerta che hai fatto:

  • il documento sui requisiti del prodotto
  • e il documento delle specifiche funzionali

  che insieme agiscono come una sorta di contratto su cosa devi fare e cosa ti aspetti da il cliente da consegnare durante lo sviluppo, nonché i tempi e i costi stimati.

• le specifiche inclusi i protocolli di revisione, i casi d'uso e i piani di test, testresults

• il design in UML e tutti i documenti corrispondenti

• la documentazione di sourcecode (doxygen o qualsiasi altra cosa)

• il manuale e le linee guida per l'installazione

• la quantità effettiva finale di risorse (tempo e denaro) utilizzate per il progetto, quindi puoi scrivere una fattura

• alcuni clienti desiderano anche i protocolli della riunione, che è quindi un'estensione del "documento decisionale" menzionato sopra

Spero che sia quello che stavi cercando.

Segui qualsiasi documentazione sia applicabile al tuo progetto tra le seguenti. Potresti già averne alcune.

Documentazione tecnica:

• Dettagli su PHP e informazioni su come è utile per il progetto
• Dettagli sul back-end e informazioni su come è utile per il progetto
• Informazioni sulla connettività del database con le foto adatte che descrivono il flusso di dati
• Informazioni su altri linguaggi di programmazione o applicazioni coinvolte nel progetto come XML, HTML ecc.
• File della guida delle FAQ

Prepara i documenti con schermate ed evidenzia il codice pertinente (se necessario) per quanto segue:

• Informazioni sull'applicazione front end come oggetti o controlli, proprietà dell'oggetto ecc.
• Informazioni sulle query del database (se non già presenti)
• Informazioni sulle proprietà del database come chiave primaria, chiave esterna ecc. e in che modo garantiscono coerenza e accuratezza dei dati.
• Guida dettagliata per tutto il progetto utilizzando schermate di tutti i possibili tipi di schermo utilizzando sia il front-end che il back-end dopo averlo eseguito con dati di esempio, senza ripetere tipi di dati o schermate simili, in un ordine logico.

• Inserisci dati non validi e mostra che è impossibile farlo in quanto hai eseguito la convalida dei dati nel front-end e nel back-end.
  /* This step is not applicable if you have not used any object for getting direct input from the user like Text Field as it is obvious that you cannot get invalid data through indirect input. */

• Mostra che non vi sono errori nel programma o incongruenze nei dati in caso di errore improvviso nel server o nel sistema client spiegando il codice pertinente.

• Dopo aver fornito dati di esempio attraverso il front-end, puoi includere query di esempio nel back-end per il recupero diretto dei dati dal server e includere anche query DML di esempio che possono aiutare a preparare statistiche importanti dei tuoi dati.

Dovresti controllarli prima di documentarli in modo che se il tuo cliente richiede una demo con dati di esempio, puoi mostrare come funziona effettivamente il progetto. Inoltre, assicurati che il tuo codice di front-end abbia linee di commento appropriate.

• Infine concludi con le statistiche come il numero totale di righe di codice, il numero totale di giorni spesi per il progetto, il numero totale di volte che hai controllato il progetto, un elenco di tutte le applicazioni utilizzate e altre informazioni tecniche e non tecniche.

  
  Documentazione non tecnica:

• Dettagli sulla licenza del progetto, se applicabile.
• Aspetti commerciali del progetto, se applicabile.

Fai attenzione

La potenziale documentazione che potresti dare al cliente è praticamente infinita. Il tempo aggiuntivo necessario per generare la documentazione che non hai ancora non è pagato.

Perché il cliente desidera questa documentazione (oltre al codice sorgente)? Cosa sarà fatto con esso? Per chi è?

Le risposte a queste domande contribuiranno a restringere la portata di cosa consegnare.

È fondamentale che tu e il cliente concordiate esattamente su quale documentazione consegnare e se eventuali ulteriori sforzi saranno compensati.

Non giocare a indovinelli. La maggior parte della documentazione tecnica sarebbe inutile per il tipico client (non tecnico).

Probabilmente lo suddividerei in alcune categorie di documenti:

Guide:

• Guida all'installazione, come configurarlo su un server.
• Guida dell'amministratore, per come configurare ed eseguire l'applicazione per prestazioni ottimali. La sicurezza sarebbe anche qualcosa da coprire qui solo in modo che sia noto quali password ha questa applicazione e utilizzare per l'esecuzione.

Supporto:

• Se ci sono problemi, che tipo di procedure suggeriresti? Stai fornendo supporto per un certo periodo di tempo? Probabilmente darei comunque una guida o due in quest'area solo così qualcun altro conosce alcune delle cose più semplici da provare come riavviare i servizi o riavviare un server.

Punti di integrazione:

• Ci sono dei punti di integrazione di terze parti per questa applicazione che fanno affidamento su altri fornitori oltre al tuo codice?