Webアプリケーションのクライアントに提供する成果物は何ですか？
私は基本的にPHPで開発された、もう1つの通常のWebアプリケーションであるWebアプリケーションを完成させました。通常、最終的な製品リリースを配信するとき、クライアントにコードドキュメントとアーキテクチャ情報を引き渡すだけです。ただし、この特定のプロジェクトの場合、クライアントは、プロジェクトに関する完全なデータの入出力を要求します。
だから私はただ疑問に思っています...コードとアーキテクチャのドキュメント以外にクライアントに提供できる必須の技術文書と非技術文書は何ですか？
（また、プロジェクトに関するさまざまな統計とデータについてクライアントに問い合わせて、関与する作業量と製品の実際のクールさを実際に知ることができるのも、ちょっとクールなことです。）
リストには以下を含める必要があると思います。
- 非技術的な要件（そのようなドキュメントがありましたよね？）
- 技術要件
- 一部の決定が他の決定に対して行われた理由を説明する「決定」文書（ある場合）。これはすでに別の要件またはアーキテクチャドキュメントに含まれている可能性がありますが、通常、Big Decisionsでは個別に行います。
- コードとその他のリソース（画像ファイル、CSSなど）
- データベースモデル（図、ドキュメントなど）
- データベースを作成するDDL。
- データベースをシードするDML。
- アプリケーションのセットアップと基本的なトラブルシューティングを説明するドキュメント。
- 重要なユーザー名とそのパスワード（管理者アカウント用）のリスト、およびパスワードの変更方法の説明。理想的には、初めてWebサイトを設定するときに、新しい管理者パスワードを入力するように求められるはずですが、これはアーキテクチャ上のものです。
- システム要件、およびWebアプリの場合、最小ホスティング要件も（アプリはMySQLまたはPostgreSQLを必要としますか？RAMの量など？）
これらすべてがすべてのプロジェクトで利用できる（または必要である）とは限りませんが、これは優れた一般的なガイドだと思います。
FrustratedWithFormsDesignerの本当に良い答えに加えて、（私たちが行ったように）非技術ドキュメントには何が含まれているのかをお伝えしたいと思います。
- 分析データ：要件について最初に話したときに、顧客は何を話しましたか？
あなたがした申し出：
- 製品要件ドキュメント
- および機能仕様書
あなたがしなければならないこととあなたが期待することについての一種の契約として一緒に機能する
開発中に提供するお客様、および推定の時間とコスト。レビュープロトコル、ユースケースとテストプラン、テスト結果を含む仕様
uMLとそれに対応するすべてのドキュメントのデザイン
ソースコードのドキュメント（doxygenなど）
マニュアルとインストールのガイドライン
プロジェクトに使用されたリソースの実際の最終的な量（時間とお金）。請求書を作成できます。
一部の顧客は会議プロトコルも必要としています。これは、上記の「決定文書」の拡張です。
それがあなたが探していたものであることを願っています。
以下から、プロジェクトに該当するドキュメントのいずれかに従ってください。すでにいくつかのドキュメントを持っている場合があります。
技術文書：
- PHPの詳細とそれがプロジェクトにどのように役立つかについての情報
- バックエンドの詳細と、それがプロジェクトにどのように役立つかについての情報
- データベースの接続に関する情報と、データの流れを示す適切な図
- XML、HTMLなど、プロジェクトに関連する他のプログラミング言語またはアプリケーションに関する情報.
- FAQヘルプファイル
スクリーンショット付きのドキュメントを準備し、次の関連コード（必要な場合）を強調表示します。
- オブジェクトやコントロール、オブジェクトプロパティなどのフロントエンドアプリケーションに関する情報.
- データベースクエリに関する情報（まだ存在しない場合）
- 主キー、外部キーなどのデータベースプロパティに関する情報と、データの一貫性と正確性を保証する方法。
- 類似した種類のデータや画面を論理的な順序で繰り返すことなく、サンプルデータで実行した後、フロントエンドとバックエンドの両方を使用して、可能なすべての種類の画面のスクリーンショットを使用して、プロジェクト全体の詳細なガイド。
無効なデータを入力し、フロントエンドとバックエンドでデータの検証を行ったため、それが不可能であることを示します。
/* 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. */関連するコードを説明して、サーバーまたはクライアントシステムに突然の障害が発生した場合に、プログラムにエラーがないこと、またはデータに不整合がないことを示します。
- フロントエンドを介してサンプルデータを提供した後、サーバーから直接データを取得するためのサンプルクエリをバックエンドに含めることができます。また、データの重要な統計の準備に役立つサンプルDMLクエリを含めることもできます。
文書化する前にこれらを自分で確認して、クライアントがサンプルデータを使用してデモを要求した場合に、プロジェクトが実際にどのように機能するかを示すことができるようにします。また、フロントエンドコードに適切なコメント行があることを確認してください。
最後に、コードの合計行数、プロジェクトに費やされた合計日数、プロジェクトをチェックした合計回数、使用されているすべてのアプリケーションのリスト、その他の技術的および非技術的情報などの統計情報で締めくくります。
非技術文書：- 該当する場合、プロジェクトのライセンスの詳細。
- 該当する場合、プロジェクトの商業的側面。
注意する
あなたがクライアントに提供できる可能性のあるドキュメントは事実上無限です。まだ持っていないドキュメントを生成するために必要な追加の時間は未払いです。
なぜクライアントはこのドキュメント（ソースコードに加えて）を必要とするのですか？それで何ができるでしょうか？誰のためですか？
これらの質問に対する回答は、提供する対象の範囲を狭めるのに役立ちます。
提供するドキュメントと、追加の労力が補償されるかどうかについて、お客様とクライアントが正確に合意することが重要です。
推測ゲームをプレイしないでください。ほとんどの技術ドキュメントは、一般的な（技術以外の）クライアントには役に立たないでしょう。
私はおそらくこれをいくつかの文書カテゴリーに分けます：
ガイド：
- インストールガイド、これをサーバーに設定する方法。
- 最適なパフォーマンスを得るためにアプリケーションを構成および実行する方法については、管理者ガイド。このアプリケーションのセキュリティと実行に使用するパスワードがわかるように、セキュリティについてもここで説明します。
サポート：
- 問題がある場合、どのような手順を提案しますか？一定期間サポートを提供していますか？サービスの再起動やサーバーの再起動のような簡単なことを他の誰かが知っているように、私はおそらくこの領域でガイドを1つか2つ与えるでしょう。
統合ポイント：
- このアプリケーションには、コード以外のベンダーに依存するサードパーティ統合ポイントがありますか？