プロジェクト引継ぎから見るプロジェクトドキュメント管理

二、『計画管理説明文書』：完全なPorject計画があれば最も良いが、この文書はその正確性に注意しなければならない。プロジェクトで計画管理を行う場合、プロジェクトの進展時間が長くなればなるほど、変更が多くなり、計画の維持が難しくなり、その時には計画が実際のプロジェクトの進展状況に反応できなくなる可能性がある。計画管理文書は、プロジェクト全体の計画が適切かどうか、どのタスクが制定されたが完成していないか、どのタスクがキャンセルされたか、これらのキャンセルされたタスクが予定された機能要件に属しているか、どの段階が行われていないか、どの段階が何度も繰り返されているか、どのスタッフの作業中にタスクの中断変化が発生しているか、いずれも計画管理説明文書から見ることができ、これによりプロジェクトの実際の状況、リスクの状況を評価しやすく、前段階の不備な内容に基づいて後続の改善を行うことができる。また、重要な点は、これらのタスクに異常な状況があるかどうか、例えば、難しいと思われている技術開発の作業が短時間で完了しているかどうか、これには注意が必要であり、実際の状況を理解する必要があります。最終的には、計画管理の説明を通じて、ドキュメントが予定されているターゲットがすべて完了しているかどうかを確認します。完了した内容は、上記で提出した成果物の説明と一致している必要があります。このセクションに文書が存在しない場合は、対応する成果物の内容と人員に基づいてプロセス全体を文書で補足する必要があります。このドキュメントが完了すると、最適化処理のための後続の管理の基盤にもなります。

ドキュメントの管理を計画していない場合は、補足する場合は、Projectを使用して完了することをお勧めします。前の成果はドキュメントを提出し、WBSを使用してタスクのスケジュールを組織し、すでに提出された対応を対応するタスクに含めることができます。前の文書状態の説明を通じて、未完成の内容をタグ付けし、同じタスクの異なる成果表現形式が存在するかどうかを見て、この場合は重複タスクに属し、タグ説明も行うべきである。

三、『需要説明書』：製品の最初の需要内容が実際に私が現在引き継いでいるこの製品に対して、需要説明書の重要性はすでに大幅に低下していることを説明しなければならない。製品はすでに研究開発が完了し、完全なユーザーマニュアルを提供しているが、需要説明書を整理する主な目的は2つある：

1、完全なプロジェクトプロセスの遡及プロセスを構築し、後続の仕事のために準備しなければならない。

2、需要検証による成果の有効性と可用性。

需要説明書は簡単で複雑な文書であり、このプロジェクトでは、需要説明書はユーザーマニュアルから需要を抽出することが多く、実際の意味はそれほど大きくありません。しかし、新しいプロジェクトを行う場合は、需要説明書は、個人的な理解をドーピングしないで、ユーザーのビジネスを復元することができるのは最大の可能性しかないはずです。実現できるかどうかは、どのように実現するかは後続の仕事のことであり、この一環の内容ではない。

四、『システム設計説明書』：システム設計説明書は今の時点では設計の問題を考慮することはできないが、この時は以下の内容を提供すべきである：

1、システムのアーキテクチャ設計及びアーキテクチャの応用過程での調整。また、アーキテクチャの弊害分析の説明を提供することができることが望ましい。

2、インタフェース設計説明及びインタフェースの詳細な仕様及び設計説明。現在のシステムは基本的に緩んでおり、インタフェース標準を通じて最終的にシステムの統合を実現するため、インタフェース部分は非常に重要であり、この部分の内容は非常に明確で正確でなければならない。

3、現在設計文書を提供できない場合は、サードパーティのツールを通じて、成果コードに基づいて設計を逆生成し、その上で文書補充を行うことをお勧めします。設計を見るのはコードを見るよりずっと良いので、この部分は提供すべきです。新しいプロジェクトの場合、このセクションのコンテンツページでは、主にインタフェース呼び出し、オブジェクト機能、およびオブジェクト関係のプランニングを推奨します。

五、『データベース設計説明書』

私自身はデータベース設計を非常に重視しています。現在はDAOのツールが多く、オブジェクトモデリングも提唱していますが、実際に応用する過程で、完全に実現しているのはごくわずかで、特にデータ分析の一部の内容に対してです。だからこの文書は非常に重要だと思います。ドキュメントのフォーマットについては、この点では非常に「標準」化されているため、説明していません。