平成25年度 秋期 午前Ⅱ

解説

UML のクラス図では，属性や操作の名前の前に付ける記号で可視性を表す。“＋”は公開（public）で，どのクラスからも参照できる。“－”は非公開（private）で，そのクラスの中だけから参照できる。“#”は限定公開（protected）で，そのクラスとサブクラスから参照できる。図で“＋”が付いているのは操作 A だけなので，イが正しい。

アは，操作 B と操作 C が公開ではないので誤りである。ウの操作 B は“－”が付いた private，エの操作 C は“#”が付いた protected の操作である。なお，“～”はパッケージ内に公開する package を表す。

解説

インスペクションは，作業成果物の欠陥を早期に見つけるための公式なレビューである。レビューアが作成者個人を非難すると，作成者が防御的になって欠陥を隠したり議論が感情的になったりして，欠陥の発見という目的が損なわれる。指摘は人ではなく作業成果物の内容に向け，課題や欠陥を客観的に指摘する。ウが適切である。

アは作成者の技術力に遠慮して指摘を控えるもので，欠陥が見逃される。イのインスペクションは欠陥の検出に集中する場であり，解決策や修正方法の検討は作成者がレビューの後に行う。エの指摘件数を作成者の能力評価に使うと，作成者が欠陥を指摘されないように振る舞うようになるので，レビュー結果は人事評価に用いないのが原則である。

解説

シーケンス図は，UML の相互作用図の一つで，オブジェクトの間でやり取りされるメッセージを時間の流れに沿って縦方向に並べて表す。どのイベントがどの順序で発生し，誰がいつ処理するかが読み取れるので，イベント駆動型のアプリケーションでイベント処理のタイミングを設計するのに有用である。イが該当する。

アの E-R 図はエンティティと関連によってデータの構造を表す図，ウのデータフロー図はプロセスの間のデータの流れと変換を表す図で，いずれも処理の時間的な順序は表さない。エのペトリネットは，プレースとトランジションとトークンによって並行して進む事象の同期や因果関係を表すモデルで，オブジェクト間のメッセージのやり取りを時間順に表すものではない。

解説

ストラテジパターンは，アルゴリズムをそれぞれ別のクラスとしてカプセル化し，共通のインタフェース（帳票出力ストラテジ）を通して交換できるようにするパターンである。コンテキストは具体的なクラスを意識せず帳票出力ストラテジの帳票出力() を呼び出すだけなので，新しいフォーマットに対応するときは，帳票出力ストラテジを汎化したクラスを追加すればよく，既存のクラスを変更せずに済む。イが適切である。

アは誤りで，どの具体的なストラテジを使うかはクライアントが選んでコンテキストに設定するので，クライアントはどのクラスがどのフォーマットに対応するかを知っている必要がある。ウのフォーマットごとの振分けは，条件分岐ではなく，どのサブクラスのオブジェクトを使うかによって決まる。エのアルゴリズムは各ストラテジクラスに記述し，コンテキストには記述しない。

解説

デザインパターンは，オブジェクト指向設計で繰り返し現れる典型的な問題と，その解決策となるクラスやオブジェクトの構造を，名前を付けて整理し再利用できるようにしたものである。代表的なものに GoF の 23 のパターンがある。エが適切である。

アは共通する性質を抽出して上位のクラスを定義する汎化，イは同じ性質をもつオブジェクト群をクラスとしてまとめる抽象化（分類），ウはデータを内部に隠して仕様と実装を分離するカプセル化（情報隠蔽）の説明である。

解説

モジュール強度は弱いほうから，暗号的・論理的・時間的・手順的・連絡的・情報的・機能的の順に分類される。アは，木構造データとそれを扱う機能を一つにまとめ，データを外から見えないようにしたもので，情報的強度に当たる。選択肢の中では最も強い。

イは初期設定という「実行される時期が同じ」という理由でまとめた時間的強度。ウは共通部分をまとめて引数で機能を切り替える論理的強度。エは A の結果を B が使うという連絡的強度で，いずれも情報的強度より弱い。なお最も強い機能的強度は，単一の機能だけを実現するモジュールを指す。

解説

クロス開発は，組込みシステムのように実行する機器（ターゲット）の資源が限られている場合に，開発ツールの整ったパソコンなど別の機器（ホスト）の上でプログラムの作成・コンパイル・デバッグを行い，できたプログラムをターゲットに転送して実行する開発方式である。ホスト上ではクロスコンパイラやエミュレータ，シミュレータなどを使う。ウが適切である。

アは 2 人 1 組で交代しながら開発するペアプログラミング，イは設計と試作を繰り返すプロトタイピングの説明である。エは派生開発を変更と追加のプロセスに分けて進める XDDP（eXtreme Derivative Development Process）の説明である。

解説

ブラックボックステストは，プログラムの内部構造を考慮せず，仕様書に記述された機能に基づいて，入力と出力の関係が正しいかを確認するテストである。プログラムが果たすべき機能を仕様書で調べてテストケースを設計するウが適切である。

エのプログラムの全命令が少なくとも1回は実行されるように設計するのは，内部構造に着目するホワイトボックステストの命令網羅である。アの無作為な抽出やイの使用頻度が高い実データの抽出だけでは，仕様の境界値や異常な入力を網羅的に確かめることができない。

解説

全数検査を実施すると，検査費用は 500個×1万円＝500万円。検査で見つかる故障品は 500×2%＝10個で，出荷前の修理費用は 10×50万円＝500万円。それでも出荷後に故障する製品が 500×1%＝5個あり，その修理費用は 5×200万円＝1,000万円。合計は 500＋500＋1,000＝2,000万円になる。

全数検査をしなければ，出荷後に 500×3%＝15個が故障し，修理費用は 15×200万円＝3,000万円。低減できる費用は 3,000−2,000＝1,000万円で，アが正しい。検査費用や出荷前の修理費用を足し忘れると，低減額を大きく見誤る。

解説

3 項目がそれぞれ二つの状態をとるので，任意の 2 項目の状態の組合せは 2×2＝4 通りある。これらが全て同じ回数ずつ現れるには少なくとも 4 件が必要で，直交表（L4）の考え方で 4 件を選べば条件を満たせる。例えば No.1，4，6，7 を採択すると，学生番号と科目コード，学生番号と得点，科目コードと得点のどの組でも，4 通りの組合せがちょうど 1 回ずつ現れる。最少は 4 件で，ウになる。

ア（2 件）とイ（3 件）では，4 通りの組合せを全て含めることができない。エ（6 件）は 4 の倍数ではないので，4 通りを同じ回数ずつにすることができず，条件を満たさない。

解説

テスト項目の消化に伴うバグ累積件数は，品質が安定してくると新たに見つかるバグが減り，曲線が寝てきて一定値に近づく（収束する）。図の曲線は，X の時点で傾きがかえって急になっており，テスト項目を消化するほどバグが多く見つかっている状態である。目標の件数に到達していても収束の兆しがないので，まだ多くのバグが内在している可能性がある。ウが適切である。

アとエは，目標のバグ累積件数に到達したことだけでテストの終了や出荷を判断しており，曲線が収束していない状況を見落としている。イは，事前の机上チェックやシミュレーションが十分であれば，テストで見つかるバグは少なく，終盤に急増することはないので，図の状況とは合わない。

解説

MTTR（平均修復時間）は，故障が発生してから修理が完了するまでの平均時間で，保守要員の駆付け時間も含む。保守センタを分散配置して駆付け時間を短縮すれば，MTTR は短くなる。ウが適切である。

アの遠隔保守で駆付け時間が不要になると短くなるのは，MTBF ではなく MTTR である。イの故障時の修理は機器を元の状態に戻すもので，故障の間隔を示す MTBF（平均故障間隔）を長くするものではない。エの予防保守は，故障の発生を減らして MTBF を長くするための保守である。

解説

ドメインエンジニアリングは，銀行の勘定系のような特定の分野（ドメイン）のシステムに共通する業務知識や要件の共通性と変動性を分析し，再利用できる部品（資産），アーキテクチャ，ツールなどを体系的に整備して，その分野のシステムの開発に再利用することで開発の効率を上げる活動である。共通フレームにもドメインエンジニアリングプロセスが定められている。イが該当する。

アのコンカレントエンジニアリングは，設計や生産準備などの工程を並行して進め，開発期間を短縮する手法である。ウのフォワードエンジニアリングは，要件や設計から順にプログラムを作り出す通常の方向の開発である。エのリバースエンジニアリングは，既存のプログラムを解析して，その仕様や設計を導き出す手法である。

解説

BABOK（ビジネスアナリシス知識体系ガイド）の要求の分類で，ソリューション要求は，ステークホルダ要求を満たすためにソリューションがもつべき能力や品質であり，振る舞いや扱う情報を表す機能要求と，性能や使用性などの非機能要求からなる。出題当時の BABOK 2.0 では要求アナリシスの活動で定義する。ウが該当する。

アは組織の目標や目的を表すビジネス要求で，エンタープライズアナリシスで定義する。イは現状から将来の状態への移行に必要な一時的な能力を表す移行要求，エは利害関係者のニーズを表すステークホルダ要求である。なお，現行の BABOK v3 では知識エリアが再編され，エンタープライズアナリシスは戦略アナリシスに改められている。

解説

NPV（正味現在価値）は，将来のキャッシュインを割引率で現在価値に換算して合計し，投資額（キャッシュアウト）を差し引いた値である。割引率を r とすると，t 年後の金額は (1＋r)^t で割って現在価値にする。r＝0.025 なので，NPV＝－200＋100/1.025＋90/1.025²＋80/1.025³＋60/1.025⁴＋50/1.025⁵ となる。ウが正しい。

アは (1＋r)^t ではなく r^t（0.025 のべき乗）で割っており，現在価値の換算になっていない。エは 1 年目の 100 を 5 年分，5 年目の 50 を 1 年分割り引いており，年数と指数の対応が逆である。イは r^t で割る誤りと，年数と指数が逆になる誤りの両方を含む。

解説

CRUD マトリックスは，行（又は列）にプロセス（機能），列（又は行）にデータ（エンティティ）を並べ，交点にそのプロセスがデータを作成（Create），読取り（Read），更新（Update），削除（Delete）のどれで扱うかを記入した表である。作成されないデータや，どのプロセスからも使われないデータなどを発見でき，データとプロセスの対応関係を検証できる。アが該当する。

イの FURPS＋モデルは，要求を機能性，使用性，信頼性，性能，保守性（サポート性）と，設計・実装などの制約に分類するモデルである。ウの KAOS 法は，ゴールを段階的に詳細化して要求を導くゴール指向の要求分析手法，エの MoSCoW 分析は，要求を Must，Should，Could，Won't に分けて優先順位を付ける手法である。

解説

プログラムマネジメントは，事業目標の達成という共通の目的に向けて，互いに関連する複数のプロジェクトをまとめて管理する考え方。個々のプロジェクトの成果を足し合わせるだけでなく，プロジェクト間の連携や統合，相互作用を通じて全体の価値を高め，組織の戦略を実現する。アが適切である。

イは個々のプロジェクト管理を細かくする話で，複数のプロジェクトを束ねる視点がない。ウは一つのシステム開発の技術選定によるリスク低減の話。エはプロジェクトマネジメントを組織的に支援する PMO（プロジェクトマネジメントオフィス）の説明である。

解説

有機 EL ディスプレイは，有機化合物の発光層に電圧をかけ，注入された電子と正孔が再結合するときのエネルギーで素子自体が発光する表示装置である。自発光なのでバックライトが不要で，薄型化しやすく，コントラストが高い。アが適切である。

イの電子ビームを蛍光体に当てて発光させるのは CRT（ブラウン管）ディスプレイ，ウのバックライトなどの光の透過量を液晶で制御するのは液晶ディスプレイ，エの放電で発生した紫外線で蛍光体を発光させるのはプラズマディスプレイの説明である。

解説

P＝n／(1＋(n−1)a) の分子と分母を n で割ると，P＝1／(1／n＋a−a／n) となる。n を幾らでも大きくすると，1／n と a／n はいずれも 0 に近づくので，P は 1／a に近づく。

a＝0.1 のとき，1／a＝1／0.1＝10 なので，マルチプロセッサの性能は幾ら CPU を増やしても 10 以上には大きくならない。イになる。

例えば n＝100 でも P＝100／(1＋99×0.1)＝100／10.9≒9.2 であり，10 には届かない。

解説

平均アクセス時間＝主記憶のアクセス時間＋ページフォールト発生率×オーバヘッド時間 で求める。現状は 300 ナノ秒＋10^－6×200 ミリ秒＝300＋200＝500 ナノ秒である。a は 300＋10^－6×40 ミリ秒＝300＋40＝340 ナノ秒，b は 300/4＋1.2×10^－6×200 ミリ秒＝75＋240＝315 ナノ秒，c は 300/3＋200＝100＋200＝300 ナノ秒となる。平均アクセス時間が短いほど効果が高いので，c，b，a の順になり，エになる。

ア，イ，ウはいずれも a を c より上位に置いているが，a の 340 ナノ秒は c の 300 ナノ秒より長く，効果は c の方が高い。また，b の 315 ナノ秒は a より短いので，イのように a を b より上位にする順序にもならない。

解説

同姓同名の社員の氏名を求めるには，氏名でグループ化して，グループ内の行数が 2 以上のものを選べばよい。GROUP BY 氏名 で同じ氏名の行を一つのグループにまとめ，HAVING COUNT(*) > 1 でグループ内の行数が 1 より多いグループだけを残す。図の表では“鈴木 太郎”が抽出される。アが正しい。

イとウの WHERE 氏名 = 氏名 は，同じ行の同じ列どうしを比べているので，氏名が NULL でない全ての行で真になり，全社員の氏名が出力される（ウは並べ替えるだけ）。エは氏名ごとの件数を出力するが，件数が 1 の社員も含めて全ての氏名が出力されるので，同姓同名だけを抽出したことにならない。

解説

原子性（Atomicity）は，トランザクション内の処理が全て実行されるか，全く実行されなかった状態に戻されるかのどちらかであり，途中までの処理だけが反映されることはないという性質である。ウが該当する。

アの同じ処理を何度実行しても結果が同じになるのはべき等性で，ACID 特性ではない。イのトランザクション完了後に障害が発生しても更新内容が保証されるのは耐久性（Durability）。エの他のトランザクションの影響を受けないのは独立性（Isolation）である。

解説

SAN（Storage Area Network）は，サーバと外部記憶装置を，業務用の LAN とは別に用意した高速な専用ネットワークで接続する構成。ファイバチャネルなどを使い，記憶装置へのアクセスが LAN の通信と干渉しない。

アの DAFS はネットワーク越しにファイルを共有するためのプロトコル，イの DAS はサーバに記憶装置を直結する方式，ウの NAS は通常の LAN に接続して使うファイルサーバ専用機であり，いずれも専用ネットワークで接続する構成ではない。

解説

CRL（Certificate Revocation List，証明書失効リスト）は，有効期間内であっても秘密鍵の漏えいなどの理由で失効させたディジタル証明書を，シリアル番号で列挙したリストである。認証局（CA）などが署名して発行・公開し（RFC 5280），利用者は証明書の検証のときに失効していないかを確認する。エが正しい。

アの CA（Certification Authority，認証局）は，ディジタル証明書を発行・失効させる機関である。イの CP（Certificate Policy，証明書ポリシー）は証明書の適用範囲や運用の方針，ウの CPS（Certification Practice Statement，認証局運用規程）は，認証局が証明書の発行・失効などの業務をどのように運用するかを定めた文書である。

解説

RPO（目標復旧時点）は，障害や災害で失ったデータを，過去のどの時点の状態まで復旧させるかの目標値である。RPO を短くするには，メインサイトの最新のデータを DR サイトにできるだけ遅れなく複製しておく必要がある。同期レプリケーションは，メインサイトへの書込みと同時に DR サイトへの書込みも完了させるので，被災直前までのデータが DR サイトに残り，RPO を最も短くできる。アが該当する。

イの夜間バッチ転送では最大で約 1 日分，ウの定期的なテープバックアップではバックアップ間隔分のデータが失われる。エの待機サーバへの接続の仕組みは，業務を再開するまでの時間（RTO）を短くする対策であり，どの時点のデータまで戻せるかには関係しない。