平成27年度春季解答

問題11

ファンクションポイント法の一つであるIFPUG法では、機能を機能種別に従ってデータファンクションとトランザクションファンクションとに分類する。

機能種別を適切に分類したものはどれか。

[機能種別]
E1：外部入力	EIF：外部インタフェースファイル
EO：外部出力	EQ：外部参照
ILF：内部論理ファイル

解答：ウ

＜解説＞

ファンクションポイント法は、ソフトウエアの規模や開発工数を見積もるための手法の1つである。ファンクションポイント法には、数十種類の計測方法があるが、現在では IFPUG法(International Function Point Users Group)が主流となっている。

IFPUG法では機能をデータファンクション(計測対象となるソフトウェアから参照または更新を行う論理的なデータのまとまり)とトランザクションファンクション(ソフトウェアに対するデータの入出力を伴う処理)に分類される。

データファンクション

内部論理ファイル（ILF）

アプリケーション境界内にあるデータのまとまり。

外部インタフェースファイル（EIF）

アプリケーション境界外にあるデータのまとまり。

トランザクションファンクション

外部入力（EI）

アプリケーション境界外からデータを受け取り、内部論理ファイルを変更したり、システムの動作を変える処理を行う。

外部出力（EO）

アプリケーション境界外にデータを計算等によって加工して提供する処理。システムの動作を変える処理を含む場合もある。

外部照会（EQ）

アプリケーション境界外にデータを提供する処理。データの加工やシステムの動作を変える処理は行わない。

したがって、ウが正解である。

問題へ

問題12

PMBOKのリスクマネジメントでは、定性的リスク分析でリスク対応計画の優先順位を設定し、定量的リスク分析で数値によるリスクの等級付けを行う。 定性的リスク分析で使用されるものはどれか。

ア	感度分析
イ	期待金額価値分析
ウ	デシジョンツリー分析
エ	発生確率・影響度マトリックス

解答：エ

＜解説＞

ア	×	感度分析は定量的リスク分析で使用される技法である。 ※ リスクアセスメント手法の説明参照より
イ	×	期待金額価値分析は定量的リスク分析で使用される技法である。 ※ リスクアセスメント手法の説明参照より
ウ	×	デシジョンツリー分析は定量的リスク分析で使用される技法である。 ※ リスクアセスメント手法の説明参照より
エ	○	発生確率・影響度マトリックスは定性的リスク分析で使用される技法である。 ※ リスクアセスメント手法の説明参照より

問題へ

問題13

プロジェクトの品質コストを適合コストと不適合コストに分類するとき、適合コストに属するものはどれか。

ア	クレーム調査費
イ	損害賠償費
ウ	品質保証教育訓練費
エ	プログラム不具合修正費

解答：ウ

＜解説＞

ア	×	クレーム調査費は外部不良コストになる
イ	×	損害賠償費は外部不良コストになる
ウ	○	品質保証教育訓練費は予防コストになる
エ	×	プログラム不具合修正費は内部不良コストになる

問題へ

問題14

品質の定量的評価の指標のうち、ソフトウェアの保守性の評価指標になるものはどれか。

ア	(最終成果物に含まれる誤りの件数)÷(最終成果物の量)
イ	(修正時間の合計)÷(修正件数)
ウ	(変更が必要となるソースコードの行数)÷(移植するソースコードの行数)
エ	(利用者からの改良要求件数)÷(出荷後の経過月数)

解答：イ

＜解説＞

ア	×	この計算式で求めるのは、最終成果物1単位当たりに含まれる誤りの件数である。 →ソフトウェアの信頼性の評価指標である。
イ	○	この計算式で求めるのは、1件当たりの修正時間である。 →ソフトウェアの保守性の評価指標である。
ウ	×	この計算式で求めるのは、移植の難易度である。 →ソフトウェアの移植性の評価指標である。
エ	×	この計算式で求めるのは、出荷後1ヶ月あたりの利用者からの改良要求件数である。 →ソフトウェアの機能性（合目的性）の評価指標である。

問題へ

問題15

次の調達の要領で、ソフトウェア開発を外部に委託した。

ほぼ計画通りの日程で全工程を終了して受入れテストを実施したところ、委託した範囲の設計不良によるソフトウェアの欠陥が多数発見された。

プロジェクト調達マネジメントの観点から、取得者が実施すべき再発防止策として、最も適切なものはどれか。

[調達の要領]

• 委託の範囲はシステム開発の一部分であり、ソフトウェア方式設計からソフトウェア結合までを一括して発注する。
• 前年度の実績評価を用いて、ソフトウェア開発の評価が最も高い供給者を選定する。
• 毎月1回の進捗確認を実施して、進捗報告書に記載されたソフトウェア構成品目ごとの進捗を確認する。
• 成果物は、委託した全工程が終了したときに一括して検査する。

ア	同じ供給者を選定しないように、当該供給者のソフトウェア開発の実績評価の評価点を下げる。
イ	各開発工程の区切りで工程の成果物を提出させて検査し、品質に問題がある場合は原因を特定させて、是正させる。
ウ	進捗確認で、作成した設計書のページ数、作成したプログラムの行数、実施したテストケース数など、定量的な報告を求める。
エ	進捗確認の頻度を毎月1回から毎週1回に変更して、進捗をより短い周期で確認する。

解答：イ

＜解説＞

ア	×	ほかの業者でも同じことが起きる可能性があるため、再発防止策ではない。
イ	○	「成果物は、委託した全工程が終了したときに一括して検査する。」をした結果製品品質に問題があってもそのままソフトウェアの作成に入ることになってしまった。これを防止するためには、各開発工程の区切りで工程の成果物を提出させて検査し、品質に問題がある場合は原因を特定させて、是正させる。
ウ	×	品質確認ではなく、進捗の確認である。
エ	×	品質確認ではなく、進捗の確認である。

問題へ