私はエクササイズを理解しようとしていますが、それはあまり意味がありません。私は誰かに解決策を提供するように頼んでいません。これを解決するために何をする必要があるかを分析しようとするだけです。どのPSP1.01.1プロセスを使用すべきかを理解しようとしています。調査?または、他の何か?パーソナルソフトウェアプロセス方法論の経験がある人から、これについて助けていただければ幸いです。
ここに質問があります。
リファレンスケース(「code1.c」)の場合、次のs/wメトリックが提供されます。
- 実装フェーズに費やされた工数(モジュールごと):2,7 mh/file
- テストフェーズに費やされた工数(モジュールごと):4,3 mh/file
- 残りのバグの推定数(モジュールごと):0,3エラー/機能、4エラー/モジュール(残り)
参照ケースに提供された対応する値に基づいて、次の各タスクは、テストケース(「code2.c」)に対して推定されるいくつかのs/wメトリックに焦点を当てています。[25マーク]
- (推定)実装フェーズで必要な工数(モジュールごと)[8マーク]
- (推定)テスト段階で必要な工数(モジュールごと)[8マーク]
- (推定)テストフェーズの終了時に残っているバグの数(モジュールごと)[9マーク]
タスク4から6は、パーソナルソフトウェアプロセスレベル1(PSP-1)のコンテキスト内で参照ケースに提供されたデータを使用し、それらをシングルポイントの履歴データログとして使用する必要があります。具体的には、基本的な推定モデルとしてPSPを使用して、テストケース(「code2.c」)に対して同じs/wメトリックを推定します。
上記のタスクを実行するために、学生は、特にレベルPSP0およびPSP1で、PSPソフトウェア開発プロセスのすべてのフェーズを検討することをお勧めします。どちらのケースも、従来のソフトウェア開発のコンテキストでは、個別のケーススタディとして扱われます。
プロキシベースの見積もり(PROBE)の使用は、実際にPSP1.0で導入されています。 PROBEも推奨される推定手法ですが、プロセス改善フレームワークとしてのPSPの観点からは、必須ではありません。適用できる他の多くの推定手法があります。ただし、PSPに関するコースでは、該当する場合はPROBEを使用することをお勧めします。
ソフトウェア工学の分野 からのこの一節が当てはまると思います。この本は、アカデミックな環境でPSPを研究するための伝統的なテキストであり、同様の議論が PSP:ソフトウェアエンジニアのための自己改善プロセス にあると思います。これはより応用的な議論です。職場のエンジニア向けです。
もう1つの問題は、特にPSPの初期段階では、履歴データがほとんどないことです。線形回帰法を使用するには、少なくとも3セットの履歴データが必要です。これは、オブジェクトLOC推定を行ったプログラムが少なくとも3つあるまで、ここで説明するPROBEメソッドを使用できないことを意味します。これだけの履歴が得られるまで、実際のオブジェクトLOCと新規および変更されたLOCデータからBeta_0およびBeta_1パラメーターを計算し、平均化方法を使用してサイズを推定する必要があります。
ソフトウェア工学の分野の第6章には、4つの計画方法が示されています。あなたが尋ねる必要がある3つの質問があります:
1の答えが「いいえ」の場合、推定方法として専門家の判断を使用する必要があります。
1の答えが「はい」で、2の答えが「はい」の場合、PROBEを使用できます。
1の答えが「はい」で、2の答えが「いいえ」の場合は、3に質問します。3の答えが「はい」の場合は、推定された新規および変更されたLOCと実際の開発時間を使用します。測定可能な精度を得るには、少なくとも3つのプロジェクトが必要です。 3の答えが「いいえ」の場合は、推定または実際の新規および変更されたLOCと実際の時間に関するデータを使用し、1つの前のプロジェクトのみが必要です。
この時点で、開発時間を見積もることができます。他のタスクを見積もるには、PROBEと直感的な専門家の判断オプションのどちらかを決定します。サイズを見積もる場合は、PROBEを使用してください。サイズベースの見積もり方法を使用できない場合は、正式なPROBE方法論を使用せずに、専門家の判断と他のプロジェクトとの比較を使用してください。以前のデータは、履歴データ(推奨)または関連する可能性のあるケースの例から取得されます。
PSPのコンテキスト内で見積もりを行う方法がわかったので、データ分析を実行し、適切な見積もりを作成し、特定のケース、例、および履歴データを指摘して回答を正当化する責任があります。