Ich habe eine Webanwendung fertiggestellt, die im Wesentlichen in PHP entwickelt wurde und nur eine weitere reguläre Webanwendung ist. Normalerweise übergebe ich bei der Lieferung der endgültigen Produktionsversion nur die Codedokumentation und die Architekturinformationen an den Client. Für dieses spezielle Projekt besteht der Kunde jedoch darauf, dass die vollständigen Ein- und Ausgangsdaten über das Projekt vorliegen.

Ich frage mich also nur ... Was sind die obligatorischen technischen und nicht technischen Dokumente, die ich meinem Kunden geben kann, abgesehen von den Code- und Architekturdokumentationen?

(Es wäre auch ziemlich cool, den Kunden über verschiedene Statistiken und Daten zum Projekt zu informieren, damit er tatsächlich weiß, wie viel Arbeit erforderlich ist und wie cool das Produkt tatsächlich ist.)

Ich denke, die Liste sollte enthalten:

• Die nichttechnischen Anforderungen (es gab ein solches Dokument, oder?)
• Die technischen Anforderungen
• Ein "Entscheidungs" -Dokument (falls vorhanden), in dem erläutert wird, warum einige Entscheidungen über andere getroffen wurden. Dies ist möglicherweise bereits in einem anderen Anforderungs- oder Architekturdokument enthalten, dies wird jedoch normalerweise für große Entscheidungen separat durchgeführt.
• Der Code und andere Ressourcen (Bilddateien, CSS usw.)
• Das Datenbankmodell (als Diagramm, Dokument, was auch immer)
• DDL zum Erstellen der Datenbank.
• DML zum Setzen der Datenbank.
• Ein Dokument, in dem die Einrichtung der Anwendung und die grundlegende Fehlerbehebung erläutert werden.
• Eine Liste aller wichtigen Benutzernamen und ihrer Passwörter (für Administratorkonten) sowie Anweisungen zum Ändern des Passworts. Idealerweise sollten sie beim erstmaligen Einrichten der Website aufgefordert werden, ein neues Administratorkennwort einzugeben. Dies ist jedoch eher eine Sache der Architektur.
• Systemanforderungen und für Web-Apps auch minimale Hosting-Anforderungen (Benötigt die App MySQL oder PostgreSQL? Wie viel RAM? Usw.)

Möglicherweise sind nicht alle diese Dinge für jedes Projekt verfügbar (oder erforderlich), aber ich denke, dies ist ein guter allgemeiner Leitfaden.

Zusätzlich zu der wirklich guten Antwort von FrustratedWithFormsDesigner möchte ich sagen, was die nicht technischen Dokumente enthalten (wie wir es getan haben):

• Die Analysedaten: Was hat Ihnen der Kunde gesagt, als Sie zum ersten Mal über Anforderungen gesprochen haben?

• das Angebot, das Sie gemacht haben:

  • das Produktanforderungsdokument
  • und das Funktionsspezifikationsdokument

  die zusammen eine Art Vertrag darüber bilden, was Sie tun müssen und was
  der Kunde während der Entwicklung liefern soll, sowie die geschätzte Zeit und die geschätzten Kosten.

• Die Spezifikation enthält Überprüfungsprotokolle, Anwendungsfälle und Testpläne sowie Testergebnisse

• das Design in UML und allen entsprechenden Dokumenten

• die Dokumentation des Quellcodes (Sauerstoff oder was auch immer)

• das Handbuch und die Installationsrichtlinien

• Die endgültige tatsächliche Menge an Ressourcen (Zeit und Geld), die für das Projekt verwendet werden, sodass Sie eine Rechnung erstellen können

• Einige Kunden möchten auch die Besprechungsprotokolle, die dann eine Erweiterung des oben genannten "Entscheidungsdokuments" darstellen

Hoffe das ist was du gesucht hast.

Befolgen Sie die für Ihr Projekt geltenden Unterlagen aus den folgenden Abschnitten. Möglicherweise haben Sie bereits einige davon.

Technische Dokumentation:

• Details zu PHP und Informationen darüber, wie es für das Projekt nützlich ist
• Details zum Backend und Informationen darüber, wie es für das Projekt nützlich ist
• Informationen zur Datenbankkonnektivität sowie geeignete Bilder, die den Datenfluss darstellen
• Informationen zu anderen am Projekt beteiligten Programmiersprachen oder Anwendungen wie XML, HTML usw.
• FAQ-Hilfedatei

Bereiten Sie Dokumente mit Screenshots vor und markieren Sie den entsprechenden Code (falls erforderlich) für Folgendes:

• Informationen zur Front-End-Anwendung wie Objekte oder Steuerelemente, Objekteigenschaften usw.
• Informationen zu Datenbankabfragen (falls nicht bereits vorhanden)
• Informationen zu Datenbankeigenschaften wie Primärschlüssel, Fremdschlüssel usw. und wie diese die Datenkonsistenz und -genauigkeit gewährleisten.
• Detaillierte Anleitung während des gesamten Projekts, indem Screenshots aller möglichen Bildschirmtypen verwendet werden, wobei sowohl das Front-End als auch das Back-End verwendet werden, nachdem sie mit Beispieldaten ohne Wiederholung ähnlicher Daten oder Bildschirme in logischer Reihenfolge ausgeführt wurden.

• Geben Sie ungültige Daten ein und zeigen Sie, dass dies nicht möglich ist, da Sie die Datenüberprüfung am Front-End und Back-End durchgeführt haben.
  /* 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. */

• Zeigen Sie, dass bei einem plötzlichen Ausfall des Server- oder Client-Systems kein Fehler im Programm oder keine Inkonsistenz der Daten vorliegt, indem Sie den entsprechenden Code erläutern.

• Nachdem Sie Beispieldaten über das Front-End bereitgestellt haben, können Sie Beispiel-Abfragen in das Back-End einfügen, um Daten direkt vom Server abzurufen, sowie Beispiel-DML-Abfragen, mit denen Sie wichtige Statistiken Ihrer Daten erstellen können.

Sie sollten diese selbst überprüfen, bevor Sie sie dokumentieren, damit Sie, wenn Ihr Kunde eine Demo mit Beispieldaten anfordert, zeigen können, wie das Projekt tatsächlich funktioniert. Stellen Sie außerdem sicher, dass Ihr Front-End-Code über geeignete Kommentarzeilen verfügt.

• Schließen Sie abschließend die Statistiken wie die Gesamtzahl der Codezeilen, die Gesamtzahl der für das Projekt aufgewendeten Tage, die Gesamtzahl der Überprüfungen des Projekts, eine Liste aller verwendeten Anwendungen und andere technische und nichttechnische Informationen ab.

  
  Nichttechnische Dokumentation:

• Gegebenenfalls Lizenzdetails des Projekts.
• Gegebenenfalls kommerzielle Aspekte des Projekts.

Sei vorsichtig

Die potenzielle Dokumentation, die Sie dem Kunden geben könnten , ist praktisch endlos. Zusätzliche Zeit, die zum Generieren von noch nicht vorhandener Dokumentation erforderlich ist, wird nicht bezahlt.

Warum möchte der Kunde diese Dokumentation (über den Quellcode hinaus)? Was wird damit gemacht? Für wen ist das?

Die Antworten auf diese Fragen werden dazu beitragen, den Umfang der zu liefernden Produkte einzugrenzen.

Es ist wichtig, dass Sie und der Kunde genau vereinbaren, welche Unterlagen zu liefern sind und ob zusätzlicher Aufwand kompensiert wird.

Spiele keine Ratespiele. Die meisten technischen Unterlagen wären für den typischen (nicht technischen) Kunden nutzlos.

Ich würde dies wahrscheinlich in einige Dokumentkategorien aufteilen:

Anleitungen:

• Installationsanleitung, wie dies auf einem Server eingerichtet wird.
• Administratorhandbuch zum Konfigurieren und Ausführen der Anwendung für eine optimale Leistung. Sicherheit sollte hier ebenfalls behandelt werden, damit bekannt ist, über welche Kennwörter diese Anwendung verfügt und welche ausgeführt wird.

Unterstützung:

• Welche Verfahren würden Sie bei Problemen vorschlagen? Bieten Sie für einige Zeit Unterstützung an? Ich würde wahrscheinlich noch ein oder zwei Anleitungen in diesem Bereich geben, damit jemand anderes einige der einfacheren Dinge kennt, die zu versuchen sind, wie das Neustarten von Diensten oder das Neustarten eines Servers.

Integrationspunkte:

• Gibt es Integrationspunkte von Drittanbietern für diese Anwendung, die sie von anderen Anbietern als Ihrem Code abhängig machen?