- トップページ
- プロジェクトマネージャ 午前2
- 平成21年度春季問題
- 平成21年度春季解答・解説
平成21年度春季解答
問題1
次のシステム開発において、コードインスペクションを行うことによって期待できる効果(削減できる時間)は何時間か。ここで、NCSSはソースコードの注釈を除いた文の個数とする。また、バグ発見率=発見したバグ数÷すべてのバグ数 とする。
- システムの規模:6,000NCSS
- システムに存在するバグの推定値:1,000NCSS当たり5件
- バグ発見率:コードインスペクションを行った場合、バグ発見率は90%であり、残りのバグは単体テスト以降で発見される。
コードインスペクションを行わなかった場合、すべてのバグは単体テスト以降で発見される。 - コードインスペクションに要する時間:1,000NCSS当たり4時間
- コードインスペクションでバグが発見された場合の1件当たりの修復時間:1時間
- 単体テスト意向でバグが発見された場合のバグ1件当たりの修復時間:5時間
ア | 66 |
イ | 84 |
ウ | 99 |
エ | 108 |
解答:イ
<解説>
コードインスペクションとは、ソフトウェアを開発する際に、品質向上を目的として実施するレビューのひとつで、作成したプログラムのソースコードを間違いがないかを確認・検証していくことである。
コードインスペクションを行った場合の時間とコードインスペクションを行わなかった場合の時間を比較する。
- コードインスペクションを行った場合の時間
-
- システムに存在するバグの推定値は、30件である。(推定値:1,000NCSSあたり5件。システムの規模は:6,000NS)
- 30件のバグ修復時間は、150時間である。(5時間/件×30件)
- コードインスペクションを行わなかった場合の時間
-
- システムに存在するバグの推定値は、30件である。(推定値:1,000NCSSあたり5件。システムの規模は:6,000NS)
- コードインスペクションに要する時間は、24時間である。(1,000NCSS当たり4時間。システムの規模は:6,000NS)
- コードインスペクションで発見できるバグ数は、27件である。(30件×0.9(バグが発見される確率:90%))
- コードインスペクションで発見できないバグ数は、3件である。(30件×0.1件(バグが発見されない確率:10%))
- コードインスペクションで発見したバグの修復時間は、27時間である。(1時間/件×27件)
- コードインスペクションで発見できないバグの修復時間は、15時間である。(5時間/件×3件)
- よってバグ修復時間は、66時間(24時間+27時間+15時間)である。
したがって、コードインスペクションを行うことによって期待できる効果は、150時間-66時間=(イ)84時間となる。
問題2
プロジェクトの進捗管理をEVM(Earned Value Management)で行っている。コストが超過せず、納期も遅れないと予想されるプロジェクトはどれか。ここで、それぞれのプロジェクトの開発の生産性は今までと変わらないとする。
解答:ウ
<解説>
EVM(Earned Value Management:アーンドバリュー分析)とは、プロジェクトマネジメントにおいて進捗状況の把握・管理を行う手法である。
EVMでは、コスト,スケジュール(進捗)の両面からプロジェクトの状況とパフォーマンスを数値化することができる。
EVM の基本となる 3 つの値である PV (実行予算) 、EV (達成額) 、AC (実績コスト) を見ていくことで、コストの超過やスケジュールの遅延を数値的に分析することができる。
- PV(Planned Value:実行予算)
- 計画時点で見積もった予算コスト
- EV(Earned Value:達成額)
- 現時点までに完成した作業の予算コスト
- AC(Actual Cost:実績コスト)
- 現時点までに完了した作業の実コスト
したがって、コストが超過せず、納期も遅れないと予想されるプロジェクトとは、
- 「コストが超過しない」⇒AC(Actual Cost:実績コスト)がEV(Earned Value:達成額)以下である。
- 「納期も遅れない」⇒EV(Earned Value:達成額)がPV(Planned Value:実行予算)以上である。
となる。
よって、ウが正解である。
問題3
ソフトウェアの開発規模見積りに利用されるファンクションポイント法の説明はどれか。
ア | WBSによって作業を洗い出し、過去の経験から求めた作業ごとの工数を積み上げて規模を見積もる。 |
イ | 外部仕様から、そのシステムがもつ入力、出力や内部論理ファイルなどの5項目に該当する要素の数を求め、さらに複雑さを考慮した重みを掛けて求めた値を合計して規模を見積もる。 |
ウ | ソフトウェアの開発作業を標準作業に分解し、それらの標準作業ごとにあらかじめ決められた標準工数を割り当て、それらを合計して規模を見積もる。 |
エ | プログラム言語とプログラマのスキルから経験的に求めた標準的な生産性と、必要とされる手続きの個数と乗じて規模を見積もる。 |
解答:イ
<解説>
ファンクションポイント法は、ソフトウエアの規模や開発工数を見積もるための手法の1つである。
ファンクション・ポイント法では開発する業務システムが扱う外部入力などの5種類のデータを拾い上げ、さらに処理の複雑さなどの14項目から定めた補正係数を掛け合わせてファンクション・ポイント数を求める。その上で過去に開発したシステムのファンクション・ポイント数と照合して工数を決める。
ア | × | 積上げ法(ボトムアップ法)の説明である。 |
イ | ○ | ファンクションポイント法の説明である。 |
ウ | × | 標準タスク法の説明である。 |
エ | × | COCOMO法の説明である。 |
問題4
工数が500人日と見積もられた開発プロジェクトを4人で開始したが、開発に遅れが出てきた。あと25日残すところで、まだ160人日の工数が必要と見込まれるので、プログラマを増やすことにした。次のような条件がある場合、予定どおり、あと25日で開発プロジェクトを完了するには、すくなくとも何人のプログラマを増やせばよいか。
[条件] | ||
(1) | 増員するプログラマは最初の10日間はプロジェクトの学習をそれぞれ行うものとする。 | |
(2) | プログラマを増員することによる作業の再分割やその後のコミュニケーションのオーバヘッドなどは無視できる。 | |
(3) | 増員するプログラマの生産性は、当初からのプログラマの生産性と変わらないものとする。 |
ア | 3 |
イ | 4 |
ウ | 7 |
エ | 8 |
解答:イ
<解説>
- 当初投入された要員4人の残りの25日で実施可能な工数を計算する。
4人×25日=100人日 - プロジェクト完了までに追加投入が必要となる工数を計算する。
160人日-100人日=60人日 - プロジェクト作業の為の実働期間を計算する。
※増員されるメンバは最初の10日はプロジェクトの学習を行う。
25日-10日=15日 - 増員するプログラマの人数を計算する。
60人日÷15日=4人
問題5
JIS X 0129-1で規定されるソフトウェアの品質特性のうち、“効率性”の定義はどれか。
ア | 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力 |
イ | 指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力 |
ウ | 修正のしやすさに関するソフトウェア製品の能力 |
エ | 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力 |
解答:エ
<解説>
JIS X 0129-1は、ソフトウェアの品質の考え方を示すものである。
内部品質および外部品質の特性としては次の6特性がある。
- 機能性(functionality)
- ソフトウェアが、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力
副特性:合目的性,正確性,相互運用性,セキュリティ,機能性標準適合性 - 信頼性(reliability)
- 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力
副特性:成熟性,障害許容性,回復性,信頼性標準適合性 - 使用性(usability)
- 指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力
副特性:理解性,習得性,運用性,魅力性,使用性標準適合性 - 効率性(efficiency)
- 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力
副特性:時間効率性,資源効率性,効率性標準適合性 - 保守性(maintainability)
- 修正のしやすさに関するソフトウェア製品の能力。修正は、是正若しくは向上、又は環境の変化、要求仕様の変更及び機能仕様の変更にソフトウェアを適応させることを含めてもよい。
副特性:解析性,変更性,安定性,試験性,保守性標準適合性 - 移植性(Portability)
- ある環境から他の環境に移すためのソフトウェア製品の能力。
副特性:環境適応性,設置性,共存性,置換性,移植性標準適合性
ア | × | 信頼性は、指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力 |
イ | × | 機能性は、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力 |
ウ | × | 移植性は、修正のしやすさに関するソフトウェア製品の能力 |
エ | ○ | 効率性は、明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力 |
お問い合わせ