平成21年度 秋期 午前Ⅱ

解説

アクティビティ図は，処理（アクション）の流れを開始から終了まで制御フローで表す UML の図である。フォークとジョインで並行して進む処理を，分岐とマージで条件による流れの分かれ目を表せるので，業務の手順や現実のビジネスプロセスで生じる並行処理の記述に向いている。ウが正しい。

アのメッセージのやり取りを時系列で表すのはシーケンス図，イのオブジェクト群の相互作用を協調関係として表すのはコミュニケーション図（UML 1.x ではコラボレーション図），エの一つのオブジェクトの状態遷移を表すのはステートマシン図の特徴である。

解説

階層化された DFD では，親のプロセスを子プロセスに分割しても，親のプロセスに出入りするデータフローと子の DFD 全体に出入りするデータフローが一致していなければならない（バランスの原則）。図のプロセス 1 には外部からの入力が 2 本あり，プロセス 2 とプロセス 3 への出力が 2 本ある。イは入力が 1－1 と 1－2 に 1 本ずつ，出力が 1－1 と 1－3 から 1 本ずつで，親と一致し，各子プロセスにも入力と出力がある。イが適切である。

アは入力が 1 本しかなく，親の入力 2 本と一致しない。ウは出力が 1 本しかなく，1－2 は出力をもたない（データを受け取るだけで何も出さない）プロセスになっている。エは入出力の本数は合うが，1－2 に入力がなく，何も受け取らずにデータを生み出すプロセスになっている。

解説

BPMN（Business Process Model and Notation）は，OMG が標準化した業務プロセスの表記法である。イベント，アクティビティ，ゲートウェイ（分岐・合流）などのフローオブジェクトを，シーケンスフローなどの矢印で結んで業務プロセスを図に表す。業務担当者にも技術者にも理解しやすいフローチャートに似た表記を目指している。アが該当する。

イは木構造で機能や組織の階層を上から下へ分割して表す構造化チャート（階層図）の説明である。ウは外部の信号や事象によるシステムの状態の推移を表す状態遷移図，エはプログラムをモジュールに分割し，その階層構造とモジュール間のインタフェースを表す構造化設計のモジュール構造図の説明である。なお，BPMN は 1.x 版では Business Process Modeling Notation の略だったが，2.0 版で現在の名称になった。

解説

SQL インジェクションは，入力値に SQL の構文として意味をもつ文字（' など）を含めて，アプリケーションが組み立てる SQL 文の構造を変え，データベースを不正に操作する攻撃である。入力文字列をエスケープ処理して特殊文字を無効にすれば，入力値は文字列リテラルとして扱われ，SQL 文の構造が変わらなくなる。ウが対策である。なお，現在の IPA“安全なウェブサイトの作り方”では，SQL 文の組立てをすべてプレースホルダで実装することが根本的解決の第一に挙げられている。

アの POST メソッドは入力値が URL に現れないだけで，値の中身は変わらないので攻撃を防げない。イの利用者認証は，認証済みの利用者による攻撃を防げない。エの HTTPS は通信路上の盗聴や改ざんへの対策であり，送られた値を SQL 文に埋め込む処理の問題は解決しない。

解説

引数で受け渡すデータを，どの関数からでも参照できる共通域（グローバルな領域）に移すと，複数のモジュールが同じデータに依存する共通結合になり，あるモジュールでの変更が，そのデータを使うほかのモジュールに波及しやすくなる。スタックの使用量が減っても“良いプログラム”と見なされないのは，モジュールの独立性が下がるからであり，“良いプログラム”の特徴は，一部を変更しても残りへの影響が少ないことである。ウが正しい。

アのメモリ使用量やイの実行速度は，共通域を使えばむしろ有利になりうる観点であり，“良いプログラム”と見なされない理由にはならない。エのステップ数の少なさも，共通域を使うかどうかとは直接関係しない。

解説

モジュール設計書のモジュールは，上位から渡される処理コード（I，U，D）によって，挿入・更新・削除のいずれかの機能を選んで実行する。関連した複数の機能をもち，引数で実行する機能を選択するモジュールは論理的強度であり，処理コードという制御情報を受け渡すため上位モジュールとの結合も強くなる（制御結合）。機能ごとに分けるか入口点を設けるのが望ましいので，エが適切である。

アの暗合的強度は，互いに関係のない機能を一つにまとめたもので，挿入・更新・削除という関連した機能をもつこのモジュールには当たらない。イの情報的強度は，同じデータを扱う機能ごとに入口点を設けたもので，処理コードで機能を選ぶこのモジュールとは構造が違う。ウの連絡的強度は，データを受け渡しながら複数の機能を逐次に実行するもので，一つの機能だけを選んで実行するこのモジュールには当たらない。

解説

ブラックボックステストは，プログラムの内部構造を考慮せず，仕様に基づいて入力と出力の関係を確かめるテストである。機能仕様から，同じ処理になる入力の範囲（同値クラス）や，その境目の値（限界値）を識別してテストデータを作るのが代表的な方法で，イが最も適切である。

エのプログラムの流れ図の分岐条件に基づくテストデータの作成は，内部構造に着目するホワイトボックステストの方法。アの実データの無作為抽出やウのデータの発生頻度の分析では，仕様の境界や例外条件を網羅的に確認できない。

解説

テスト仕様書は，全体から詳細へと順に具体化していく。まず a のテスト環境やテスト方法などの概要を記述し，c でテストすべき項目をすべて洗い出す。次に d で，テスト効率を考えて項目から適切なテストケースを設定し，b でテストケースごとのテストデータと予想結果を作る。最後に e で，テストを実行する詳細な手順を決める。a，c，d，b，e の順になり，アが正しい。

イとウは，テストケースやテストデータが決まる前に e の詳細な実行手順を設定しており，手順の前提となる内容が決まっていない。エは，項目を列挙する c を最後に置いており，テストケースやデータを作る前提となる項目の洗い出しが後回しになっている。

解説

全数検査を実施すると，検査費用は 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万円で，アが正しい。検査費用や出荷前の修理費用を足し忘れると，低減額を大きく見誤る。

解説

特許を受けるには，出願前に発明が公然と知られていないこと（新規性）が必要である。顧客と守秘義務を確認した上で技術内容を説明しても，秘密を守る義務のある者に知られただけなので公然と知られたことにはならず，製品発表前に出願すれば新規性は失われていない。イが特許権を取得できる。

アの学会発表とエの製品の販売は，発明を公然と知られた状態にする行為である。出題当時（平成21年）の特許法第30条では，新規性喪失の例外は学会での文書発表などから6か月以内の出願に限られ，販売は対象外だったので，どちらも新規性を失って取得できなかった。ウの暗号の生成式は数学的な公式で，自然法則を利用した技術的思想の創作ではないので発明に当たらない。

なお，現行の特許法第30条第2項では，特許を受ける権利を有する者の行為によって公知になった発明は，1年以内に出願し，証明書を提出するなどの手続を取れば新規性を失わなかったものとみなされる。現在は，アの11か月目の出願やエの販売後1年以内の出願でも，この手続によって特許を受けられる場合がある。

解説

アウトソーシングは，情報システムの開発，運用，保守などの業務の全部又は一部を，外部の専門企業に委託することである。自社で資源をもたずに専門的な能力を活用でき，コアとなる業務に経営資源を集中できる。アが正しい。

イは情報システム部門を分社化した情報システム子会社が，親会社以外の業務（外販）も受託する形態の説明である。ウは労働者派遣で，派遣労働者は派遣先の指揮命令を受けて働くので，業務を外部に任せる委託とは異なる。エは業務をユーザ部門に移管するもので，外部への委託ではない。

解説

共通フレーム 2007 の企画プロセスは，システム化構想の立案とシステム化計画の立案からなる。業務要件の定義は，企画プロセスの後に置かれた要件定義プロセスのタスク（1.5.2.2 業務要件の定義）であり，システム化計画の立案よりも後で実施する。エが正しい。

アの現行業務，システムの調査分析はシステム化構想の立案のタスクで，システム化計画の立案より前に行う。イの開発組織の編成方針と責任部署の決定はシステム化計画の立案のタスクであるプロジェクト推進体制の策定に，ウのシステム稼働時期の設定と全体開発スケジュールの作成は同じく全体開発スケジュールの作成に当たる。

解説

共通フレームでは，企画プロセスの目的を，経営・事業の目的，目標を達成するために必要なシステムに関係する要件の集合とシステム化の方針，及び，システムを実現するための実施計画を得ることとしている。企画プロセスには，システム化構想の立案とシステム化計画の立案が含まれる。イが正しい。

アは，業務やシステムの仕様を明確にして IT 化の範囲と機能を示し，利害関係者間で合意するもので，要件定義プロセスの目的である。ウは，新旧の業務の違いを明確にして移行計画を作成・実行するもので，運用プロセスの業務及びシステムの移行の内容である。エは，ハードウェア，ソフトウェア及び手作業の構成品目を識別してシステム要件を割り振るもので，開発プロセスのシステム方式設計の内容である。

解説

非機能要件は，システムが提供する機能そのものではなく，可用性，性能，信頼性，保守性，セキュリティなど，品質や運用に関する要件である。稼働率を一定の水準に維持するために障害から半日以内に回復するというイは，可用性に関する要件で，非機能要件に該当する。

アの与信残金額の計算と警告メッセージの表示，ウの在庫の自動引当，エの受注承認入力を経たものだけを出荷可能とすることは，いずれもシステムが行う処理の内容を定めたもので，機能要件である。

解説

システム管理基準（平成 16 年版）は，企画業務の最初の項目に開発計画を置き，“開発計画は，全体最適化計画との整合性を考慮して策定すること”としている。関連する情報システムと役割を分担し，組織体として効果を上げるために策定する開発計画は，企画業務の段階で策定するものである。アが正しい。なお，システム管理基準は平成 30 年に改訂され，現行版の構成は“IT ガバナンス”“企画フェーズ”“開発フェーズ”などに改められている。

イの全体最適化計画は，企画業務より前の“情報戦略”で，方針及び目標に基づいて策定するものである。ウの運用手順は“運用業務”で，運用設計及び運用管理ルールに基づいて策定する。エの開発手順は“開発業務”で，開発方法に基づいて作成するものである。

解説

共通フレームの要件定義では，まず利害関係者のニーズを整理し，新しい業務の在り方や運用をまとめた上で，業務上実現すべき要件を明らかにする（業務要件の定義）。機能要件は，この業務要件を実現するために必要なシステムの機能を明らかにするものなので，業務要件の定義が機能要件を定義する前提となる。ウが正しい。

アの業務モデルからシステム化機能を整理し，システム方式を策定する作業と，イの対象業務の問題点を分析してシステムで実現すべき課題を定義する作業は，要件定義より前の企画プロセス（システム化計画の立案）の作業である。エの利害関係者要件を技術的に実現可能なシステム要件に変換する作業は，要件定義の後のシステム要件定義の作業である。

解説

契約は，契約の内容を示して締結を申し入れる意思表示（申込み）に対して，相手方が承諾をしたときに成立する（民法第 522 条第 1 項。2020 年施行の改正で明文化された規定で，出題当時も同じ考え方である）。発注者が注文書で申込みをし，受注者が注文を引き受ける旨の請書を渡すと，請書が承諾に当たり，契約が成立する。ウが正しい。

アの RFI（情報提供依頼書）は，発注者がベンダに技術や製品の情報の提供を求める文書，イの RFP（提案依頼書）は，発注者がシステムの要件などを示してベンダに提案を求める文書である。エの提案書は，RFP に応じてベンダが作成し発注者に提出する文書で，いずれも請書を渡して契約を成立させる書類ではない。

解説

品質機能展開（QFD）は，顧客が求める品質（要求品質）を，製品の設計品質や品質特性などの管理できる要素に順に変換，展開していく方法である。要求品質展開表と品質特性展開表を組み合わせた二元表（品質表）を作り，両者の関係の強さから，重要性の高い品質特性を明らかにする（JIS Q 9025）。エが正しい。

アの FMEA（故障モード影響解析）は，構成要素の故障モードを挙げて，それが上位の機能に及ぼす影響を解析する手法である。イの FTA（故障の木解析）は，好ましくない事象を頂上に置き，その原因を論理記号で木構造に分解していく手法である。ウの田口メソッド（品質工学）は，直交表や SN 比を用いて，ばらつきの影響を受けにくい設計条件を求める手法である。

解説

EA のビジネスアーキテクチャ（政策・業務体系）の機能情報関連図（DFD）は，業務・システムの機能と情報の流れを明確化するためのもので，各機能について情報の発生源と到達点，処理，保管とそれらの間を流れる情報を統一記述規則に基づいて表す（業務・システム最適化計画策定指針）。アが正しい。

イの業務・システムの目的・機能，情報システムの管理・運用体制を明らかにするのは，同じビジネスアーキテクチャの業務説明書である。ウの情報システム間でやり取りされる情報の種類と方向を明確化するのは，アプリケーションアーキテクチャ（適用処理体系）の情報システム関連図である。エの物理的なデータ構造を明らかにするのは，データアーキテクチャ（データ体系）のデータ定義表である。

解説

BI（Business Intelligence）は，企業内の基幹システムなどに蓄積された膨大なデータを，データウェアハウスなどに集めて分類・加工・分析し，経営者や担当者の迅速な意思決定に役立てる手法である。OLAP やデータマイニング，レポーティングなどのツールが使われる。エが正しい。

アの業務の流れを可視化し，改善サイクルを回して継続的に業務を改善する手法は BPM（Business Process Management）である。イの異なるシステムを連結してデータやプロセスを統合するのは EAI（Enterprise Application Integration）である。ウの戦略目標の達成度を測る指標を把握，分析して進捗管理に活用するのは，KPI（重要業績評価指標）による業績管理の説明である。

解説

シリアル ATA は，PC の内部で磁気ディスク装置や DVD ドライブなどの記憶装置を接続するためのシリアルインタフェースであり，パラレル ATA に代わって高速なデータ転送を実現する。イが適切である。

アのキーボード，マウス，プリンタなど多岐にわたる周辺機器を接続するのは USB，ウのルータやモデムを接続するシリアルインタフェースは RS-232C，エのディジタル AV 機器を接続するシリアルインタフェースは IEEE 1394 の説明である。

解説

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 には届かない。

解説

自然結合は，二つの表の同じ名前の列（ここでは顧客番号）の値が等しい行どうしを結合し，結合に使った列を 1 列だけ残す演算である。エは，納品.顧客番号 = 顧客.顧客番号 を条件に結合し，顧客番号を 1 列だけにして，納品の列と顧客名を取り出しているので，自然結合の結果になる。エが正しい。

アは結合条件は正しいが，SELECT * なので顧客番号が 2 列とも出力され，自然結合ではなく等結合の結果になる。イは条件が <> なので，顧客番号が一致しない行どうしを組み合わせてしまう。ウは顧客表に存在する顧客番号の納品の行を選ぶだけで，顧客名が含まれず，結合の結果にならない。

解説

ARP（Address Resolution Protocol）は，宛先の IP アドレスをもつ機器の MAC アドレスを，同じネットワーク内へのブロードキャストで問い合わせて取得するプロトコルである。同一のネットワーク内でフレームを送るには相手の MAC アドレスが必要なので，IP アドレスから MAC アドレスを求めるのに使う。アが正しい。

イの DHCP は，ネットワークに接続した機器に IP アドレスなどの設定情報を自動で割り当てるプロトコルである。ウの ICMP は，IP 通信のエラー通知や到達確認（ping など）に使うプロトコルである。エの RARP は，ARP とは逆に，自分の MAC アドレスから IP アドレスを取得するプロトコルである。

解説

パケットフィルタリング型ファイアウォールは，パケットのヘッダにある IP アドレスやポート番号などを見て通過の可否を判断する。外部に公開しないサービスのポート番号宛てのパケットを遮断すれば，公開している必要なサービスに影響を与えずに，そのサービスへのアクセスを防げる。アが適切である。

イの脆弱性を突く攻撃は，公開しているサービスの正規のポートへの通信に紛れて届くので，ヘッダの情報だけでは区別できない。ウのマクロウイルスは電子メールの添付ファイルの中身にあり，パケットのヘッダでは判断できない。エの電子メール爆弾も正規のメールの通信として届くので，メールサービスを止めずに遮断することはできない。