平成26年度 春期 午前Ⅱ問題の解答と解説

問1 の解答と解説

【答え】ア

SPA（Software Process Assessment）は，ソフトウェアプロセス評価と日本語訳されるように，ソフトウェア開発や保守などのソフトウェアプロセスが，どの程度の能力水準にあり，どのようにして継続的に改善されているのかの評価・判定するものである。

問2 の解答と解説

【答え】ア

プロジェクトにおける開始から終結までの時間の経過に伴って，ステークホルダの影響力は小さくなるが，要求変更への対応コストは大きくなる。

問3 の解答と解説

【答え】エ

PMBOK において，プロジェクト憲章は，プロジェクト統合マネジメントの立上げプロセス群で作成する。

問4 の解答と解説

【答え】イ

各プロジェクトで作成されたパフォーマンス測定のベースラインや品質のベースラインなどのプロジェクトファイルは，企業の知識ベースに含まれる。

問5 の解答と解説

【答え】エ

PMBOK での定義におけるプロジェクトとステークホルダの関係は，以下のとおり。

サプライヤ

サプライヤは，契約に基づいてプロジェクトに必要な構成アイテムやサービスを提供する。

スポンサ

スポンサは，プロジェクトに対して資金や現物などの財政的資源を提供する。

プログラムマネージャ

プログラムマネージャは，関連するプロジェクトの調和がとれるように，個々のプロジェクトの支援や指導をする。

問6 の解答と解説

【答え】ウ

プロジェクトスコープマネジメントにおいて，WBS の作成に用いるローリングウェーブ計画法では，将来実施予定の作業については，上位レベルの WBS にとどめておき，詳細が明確になってから，要素分解して詳細な WBS を作成する。

問7 の解答と解説

【答え】ア

RACI チャートは，RAM（責任分担マトリックス）の一種で，二次元の表の各軸に要員名と作業を設定し，それぞれの要員が担う役割および負う責任を作業別に一覧にしたものである。プロジェクト内での責任を明確化するとともに，作業が適切に割り振られる手助けをする。

• Responsible（実行責任）
• Accountable（説明責任）
• Consulted（相談対応）
• Informed（報告先，情報提供）

問8 の解答と解説

【答え】イ

プロジェクトの標準所要日数を求める。

プロジェクトの所要日数を 3 日間短縮すると 12 日になる。まず，作業 B と作業 E のいずれを短縮するか検討する。

作業 B は，短縮可能な日数は 4 日で 1 日短縮するのに必要な追加費用は 3 万円である。3 日間短縮は可能で，追加費用は 9 万円である。

一方，作業 E は，短縮可能な日数は 2 日で 1 日短縮するのに必要な追加費用は 6 万円であり，3 日間短縮できず，2 日間短縮する費用も 12 万円である。

よって，作業 B を 3 日間短縮する。

次に，作業 A または 作業 D を 1 日短縮する必要があるが，追加費用 2 万円と作業 D に比べて安価な作業 A を 1 日短縮する。

したがって，このプロジェクトの所要期間を 3 日間短縮するためには，追加費用は 9 万円 + 2 万円 = 11 万円である。

問9 の解答と解説

【答え】エ

クリティカルチェーン法（CCM : Critical Chain Method）は，TOC（制約理論）で有名なゴールドラット博士が 1997 年に発表した "Critical Chain" の中で提唱した概念である。TOC の考え方をプロジェクトマネジメントに取り入れたもので，クリティカルパス法（CPM : Critical Path Method）では考慮していなかった「資源の制約（資源の競合）」，すなわち "人（要員）" や "機械（開発サーバや開発端末）" などの依存関係を加味してスケジュールを作成する。

プロジェクトのスケジュール管理で使用する "クリティカルチェーン法" の実施例として，限りある資源とプロジェクトの不確実性に対応するため（クリティカルパスを守るため），フィーディングバッファ（合流バッファ）と所要期間バッファ（プロジェクトバッファ）を設ける。

問10 の解答と解説

【答え】ウ

差異分析は，プロジェクトマネジメントの実績報告のプロセスにおいて，スコープ，コスト，スケジュールに関して，ベースラインと実績のかい離を明確にするために使用される。

問11 の解答と解説

【答え】ウ

コミュニケーションはチームのメンバが総当たりでとり，その工数は 2 人 1 組の組合せごとに週当たり 4 人時（1 人につき 2 時間）であるので，一週間のコミュニケーションの時間は次式で求められる。

1 週間のうちプログラム開発に当てられる時間は 220 時間（= 40 時間/人 × 10 人 - 180 時間）である。

一方，1 人で開発する場合はコミュニケーションが不要なので 400 時間プログラム開発に当たられるが，10 人で開発する場合は 220 時間しかプログラム開発に当てられない。すなわち，コストは次式のとおり 1.8 倍になる。

問12 の解答と解説

【答え】ア

EMV（Expected Monetary Value，期待金額価値）は，定量的リスク分析で用いられるリスクレベルの算定方法で，リスクが顕在化したときの影響金額に発生確率を乗じて求める。リスクは好機と脅威に分けられるため，プラスの結果をもたらすリスクは正の値，マイナスの結果をもたらすリスクは負の値で表す。

問13 の解答と解説

【答え】ウ

脅威への戦略

プロジェクトにマイナスの影響を与えるリスク（脅威）への対応戦略には，回避，転嫁，軽減，受容の 4 種類がある。

回避

リスクそのものを取り除いたり、プロジェクトに影響がないようにスコープや目標を縮小・変更する方策。

転嫁

リスクによるマイナスの影響を第三者へ移転する戦略。リスクのある業務・作業のアウトソーシングや、損害保険の契約によってリスクの影響を自社から他社に移転する。

軽減

リスクの影響範囲を狭くしたり、発生確率を低減するような方策。

受容

リスクが現実化した時の影響が許容可能範囲内である時やリスクの除去が困難である場合に、特段対策をせずにそのままにしておくこと。対策費用が予想される損失金額を上回っているときなどに採られる方策。

好機への戦略

プロジェクトにプラスの影響を与えるリスク（好機）への対応戦略には，活用，共有，強化，受容の 4 種類がある。

活用

好機が確実に到来するように、現実化の不確実性を取り除くための戦略

共有

好機を得られる能力の高い第三者にプロジェクトの実行権限の一部、または全部を与える戦略

強化

好機のプラスの影響を増加させたり、その発生確率を高めたりする戦略

需要

積極的な利用はしないが、好機が現実化したときにはその利益を享受しようとする戦略

問14 の解答と解説

【答え】エ

COCOMO の式より，曲線の式を求める。

開発規模が大きくなるにつれて，開発生産性は減少していく。

問15 の解答と解説

【答え】イ

パレート図は，現象別に層別してデータをとることにより，重要な不良や問題点を見つけ出す。プロジェクトの状況を把握するために使用するパレート図の用途として，項目別に層別して出現度数の大きさの順に並べるとともに累積和を示した図であり，主要な原因を識別するために用いる。

問16 の解答と解説

【答え】ア

検査グループが発見した 30 個のエラーの内訳は故意に埋め込んでおいたエラー 20 個，真のエラー 10 個である。故意にプログラムに埋め込んだエラーは 100 個あるので，真のエラーは 10 × 100/20 = 50 個と推定できる。真のエラーのうち 10 個は発見できているので，プログラムには埋込みエラーを除く残存エラーは 40 個と推定できる。

問17 の解答と解説

【答え】エ

エクストリームプログラミング（XP : eXtreme Programming）とは、迅速で柔軟性の高いソフトウェア開発手法の一つ。いわゆるアジャイル開発手法と総称される軽量で柔軟な手法の先駆けとなったもので、1999年に米著名プログラマのケント・ベック（Kent Beck）氏らが提唱した。

XP には年々いくつかのプラクティスが追加されているが，基本となった 12 のプラクティスは次の通り。

計画ゲーム

求める機能のコンセプトを短い文章で記したストーリーカードを作成する。そのカードをもとに、開発者・管理者を含めたチームとのミーティングを行い詳細を決定する。

短期リリース

動くソフトウェアを 1～3 ヶ月というできるだけ短い時間間隔でリリースする。

共通の用語

開発メンバ・顧客・管理者全員でイメージや理解を共有するため、用語集や図表を作成する。

単純さ優先

品質低下のもとと複雑な実装の組込みを避け最も単純な実装を優先する。

テスト駆動開発

求める機能を明確化するため、テスト対象コードを実装するよりも前に単体テストを作成する。

リファクタリング

完成済みのものでもソフトウェアの機能を変えずにソースコードの品質を良くすることを随時行う。

ペアプログラミング

これは二人一組で実装を行い、一人が実際のコードをコンピュータに打ち込み、もう一人はそれをチェックしながら補佐するという役割を随時交代しながら作業を進める。

ソースコードの共同所有

開発チーム全員がどのコードに対しても改善処置を行えるようにするため、ソースコードの所有者を決めない。

常に統合

あるコードが単体テストをパスする度にすぐに結合テストを行い問題点や改善点を探す。

週 40 時間労働

集中力を高め、開発効率を高めるためには心身の健康を保つ必要があるため残業を認めない。

顧客も一緒

顧客は開発チームと同室（または近く）で開発の見守りを行う。

コーディング規約

上記を実現するためのにコーディング規約を決めて遵守する。

問18 の解答と解説

【答え】イ

ウォータフォールモデル，段階的モデル，進化的モデルは，次のとおり。

ウォータフォールモデル

ウォーターフォールモデルとは、システム開発の手順を模式化したモデルの一つで、設計やプログラミングといった各段階を一つずつ順番に終わらせ、次の工程に進んでいく方式。最も古典的な開発モデルの一つで現代でも広く普及している。

要件定義、外部設計、内部設計、開発（実装）、試験、本番稼働（納品）、運用といった各工程を時系列に沿って順に並べ、一つ前の工程が終わったらその成果物をもとに次の工程を始める、という単純なルールで進めていく方式である。滝（waterfall）を水が流れ落ち、逆戻りしないという意味合いでこのように呼ばれるようになった。

段階的モデル（Incremental Model）

最初に小さなシステムを作成し，それを段階的に発展させていく手法。要求を全部一度に実現するのではなく，複数に分割し，順次実現していくアプローチをとる。

進化的モデル（Evolutionary Model）

開発プロセスの一連のアクティビティを複数回行う反復型のモデルである。要求に従ってソフトウェアを作成し，出来栄えを評価する。その結果改訂された要求に従って作成し，また出来栄えを評価する，というように，要求事項やソフトウェアを改訂しながら，反復を繰り返し，ユーザが本当に求めている要求に近づけていくといった特徴をもつ。

問19 の解答と解説

【答え】イ

サービルライフサイクルの段階を次表に示す。

問20 の解答と解説

【答え】ウ

案 1 ～ 案 4 の評価点は，それぞれ 3 点，1 点，7 点，-13 点となる。よって，総合評価点が最も高い改善策は案 3 である。

問21 の解答と解説

【答え】ウ

IP（知的財産）ライセンス契約の中で規定されるランニングロイヤリティは，特許発明の実施の実績に応じて額が決まる使用料である。

問22 の解答と解説

【答え】ウ

ソフトウェア開発を下請事業者に委託する場合，下請代金支払遅延等防止法に照らして，「顧客が求める仕様が確定していなかったので，発注の際に，下請事業者に仕様が未記載の書面を交付し，仕様が確定した時点では，内容を書面ではなく口頭で伝えた。」という行為は禁止されている。

問23 の解答と解説

【答え】ア

コンティンジェンシープランにおける留意点として，企業の全てのシステムを対象とするのではなく，システムの復旧の重要性と緊急性を勘案して対象を決定する。

問24 の解答と解説

【答え】イ

メールサーバ（SMTP サーバ）の不正利用を防止するために，メールサーバにおいて行う設定は，「第三者中継を禁止する」である。

問25 の解答と解説

【答え】イ

TLS（Transport Layer Security）では，サーバ認証の終了後，オプションでクライアント証明書によるクライアント認証を行う機能がある。クライアント認証を実施する際の，クライアントとサーバの間のメッセージのやり取りは，以下の手順となる。

1. サーバが，クライアントにサーバ証明書を送付する。
2. クライアントが，サーバにクライアント証明書を送付する。
3. サーバがクライアントを認証する。

SSL 証明書には，DV，OV，EV の種類がある。

ドメイン認証（DV : Domain Validation）は，ドメイン名が正しいかどうかを認証する。

企業認証（OV : Organization Validation）は，ドメイン名に加え，会社名も証明する。

実在証明拡張型（EV : Extended Validation）は，DV，OV よりも厳格な審査を受けて発行される。発行された証明書は，ドメイン名，実在証明を行い，Web ブラウザのアドレスバーに，組織情報が表示されるようになる。

コモンネーム（CN : Common Name）は，サーバ証明書に含まれる登録情報で，証明書が有効な FQDN，または，その IP アドレスが格納される項目である。クライアント側ではアクセスした URL のドメイン名と証明書のコモンネームを比較することで証明書の正当性を検証する。

FQDN (Full Qualified Domain Name)

ドメイン名・サブドメイン名・ホスト名の全てを指定する記述形式で「完全修飾ドメイン名」とも呼ばれる。