日语刚学，有很多问题，请指正。
１．
設計書の作成について
1
つの設計書は１つのレビューできる成果物です。不同の使用者向け、設計書に該当の内容を明記すべきであります。
・
SD
の方面
SD
階段の設計書は構成設計書です。書く時に、以下の観点を注意されます。
①
この設計書の使用者は
MK1
の担当者と
MK3
の担当者です。この設計書によって、ソースは作成することができます。しかも他の問題を考慮する必要がありません。
MK3
の担当者はこの設計書よりテスト設計書を作成することができます。
②
この設計書の詳しい程度、品質の要求の高低と時間に係ります。最低の要求は、すべてのクラスとメソッドにインタフェースやパラメータをはっきり書きなければならなくて、簡単な処理フローを書きます。しかも言語は曖昧な意味があることができません。
③
この設計書を書く時、きっと先にクラスとメソッドの一覧を作成して、且つ根拠を書き出します。また、
FD
の設計書のすべての機能を全部含ます。
④
設計書を書く時、条理があって、入力から出力まで
1
つのステップずつを説明します。一足飛びのロジックがあることができません。
⑤
言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い点を注意します。
・
BD
の方面。これらは近日
FJ
殿の
BD
設計書から習いました。間違いの場所を指摘してください。
①
BD
階段の設計書は基本設計書です。ユーザ（例えば：本製品の使用者）の立場からこの設計書を作成します。ユーザのすべての需要に対応して、説明を行います。
②
システムのソフトウェア、ハードウェアの規模性と複雑性に対して、設計書に対応することがあるかどうか。
③
システムの拡張性、設計書に対応することがあるかどうか。
④
使用された技術の複雑性と難しくに対して、製品の高い品質のために、設計書に対応することがあるかどうか。
⑤
性能とセキュリティなど方面、設計書に対応することがあるかどうか。
⑥
この製品はどれくらいの時間を使うことができます。設計書に対応することがあるかどうか。
⑦
ユーザの需要が曖昧の場合、設計書に対応することがあるかどうか。そして増えるまたは減らす作業量、複雑性などに対して、考えることがあるかどうか。
⑧
言語は分かり易くなって、多義性があることができません。設計書を書く時、どのようにレビューし易いと考えます。
・
FD
の方面。
①
FD
階段の設計書は機能設計書です。主に基本設計書を対応して、コンピュータの上でどのように実現します。
②
基本設計書と構成設計書の間すべての設計は機能設計書の内容だと思います。この設計書は開発者の根拠です。内容必ずは合理的と正しいです。
③
言語は分かり易くなって、多義性があることができません。且つレビューし易いために多くの細い点を注意します。
２．
レビューについて
①
設計書では、プロジェクトと会社の規約によって、
Excel
版文書または
Word
版文書があります。
Excel
版の文書は分かり易くて、しかしレビューに役立ちません。
Word
版の文書はレビューに役立って、しかし分かることは苦労しています。
②
設計書の難しい程度と会社のデータによって、予定するバッグ数を確定します。
③
設計書を書き終わった後に、自己レビューして、向かうしレビューすることが必要です。
④
レビュー前に、本回のレビュー観点を明確します。
⑤
レビューの時に、担当者は設計書を読むんで、レビュー者は問題を指摘します。問題のタイプによって、分類します。
⑥
レビュー終わったから、レビュー結果報告書と結果分析報告を作成します。指摘されたバッグ、バッグの原因、予定するバッグ数によって、分析して、見解を提出します。また、もう一回レビューが必要かどうかとレビュー観点を確定します。合計するバッグ数は予定するバッグ数より大きくまたは少なく場合、管理者はこの問題を重視する必要があります。
⑦
レビュー結果報告書と結果分析報告によって、管理者は設計書の品質と担当者の問題を見ます。
３．
プロジェクト管理について。
①
オフショアので、プロジェクト内容は明確にしなければなりません。明確しない作業があることができません。
②
プロジェクトの開発の中で、
2
つの表を保守する必要があります。問題一覧表と作業一覧表です。
③
それぞれのデータを取得します。例えば：新規開発
1k
ステップ当たり各階段の指標、レビューのバッグ数等。
④
MK2
、
MK3
、
CT
、
ST
それぞれのテスト観点を明確しました。テストされる内容はソース、構成設計書、機能設計書、基本設計書です。
⑤
線票で進捗情報を表示します。
⑥
プロジェクト会議に問題を記録して、次の会議にすべての問題を確認します。