応用情報技術者 2016年 春期 午後 問題

共通の文章

Webサイトを用いた書籍販売システムのセキュリティに関する次の記述を読んで,

共通の文章

事業継続計画(BCP)に関する次の記述を読んで,RAI,2に答えよ。 A社は,家電製品の中核部品を組み立てて家電メーカに納品している。A HOR は,経営企画部のF部長から,自然災害に関してリスク分析を行ったところ,AE と工場があるA社の所在地域での大規模地震のリスクレベルが,最も高くなったと 報告を受けた。そこで,A社の社長は,大規模地震を想定したBCPを策定するよう, F部長に指示した。 (A社の現状] A社の組織は,経営企画部,総務人事部,X事業を営むX事業部,及びY事業を 営むY事業部から成り立っつている。X事業部は家電メーカのB社に中核部品Xを納 AL,Y事業部は家電メーカC社に中核部品Yを納入している。中核部品を組み立 てるために使う部品は,A社と同じ地域の部品メーカのD社及びE社から,長期に わたって,安定的に購入しており,他社から同じ部品を購入することは困難な状況 にある。 A社が行っている取引の概要は,図1のとおりである。 ys iti| 図1 A社の取引の概要 中核部品Xは,3年前にA社が独自の技術によって開発した精密部品であり,他 の会社では製造していない。一方,中核部品Yは,A社とは別の地域にある会社で も製造されている。C社は,災害などの発生によってサプライチェーンが途切れて中 核部品が納入されなくなるリスクを低減するために,A社からは全体の50%を購入 している。 Ath,D社,E社とも,経営に大きな影響を及ぼすと想定される事象が発生した場 合の緊急連絡体制は整備済みであるが,現在,BCPは策定していない。 ー10一 (BCPの検討] F部長は,次の方針でBCPを検討するよう,G課長に指示した。 方針1:自社の従業員及びその家族の安全を第一とする。 Fist 2:顧客である家電メーカに深刻な影響が出ないように事業の優先度を考慮し て,できるだけ速やかに自社の事業を再開する。 G課長は,方針1に基づいて,大規模地震が発生した場合の従業員及びその家族の 安否確認・安全確保計画,帰宅計画を策定するとともに,必要な災害用食糧・備品 などの事前準備の検討を完了した。COR,次の1①)~(6)の手順でBCPを検討した。 (1)被害状況の想定と復旧見込み G課長は,A社の所在地域での大規模地震の発生による被害状況と復旧見込みを 次のように想定した。 (社外の被害状況) ・業務に必要な道路,公共交通機関:一部で損壊が発生するが,大規模地震発 生日を1日目として,10日目に復旧する。 ・固定電話,携帯電話,スマートフォン:一部で通信システムの停止が発生す るが,大規模地震発生日を1日目として,一般通話は7日目,電子メールな どのパケット通信は3日目に復旧する。 (A社の被害状況と復旧見込み) ・本社と工場の被害:中核部品双,Yそれぞれの製造ラインと出荷ラインの一部 が損傷し,両方のラインがストップする。社屋の一部も損傷するが,使用は 可能である。 ・電気:停電が発生するが,大規模地震発生日を1日目として,7日目に復旧す る。自家発電装置は未設置である。 ・本社と工場の業務用専用回線:使用できなくなるが,大規模地震発生日を1 日目として,7日目に復旧する。 ・社屋の被害状況の確認:公共交通機関が復旧した翌日に,総務人事部員が到 着して確認が完了する。 ・従業員と修理業者の到着:社屋の被害状況を確認した翌日に到着する。 ・中核部品X,Yの製造ラインの復旧:従業員と修理業者が到着した翌日から, 製造ラインの復旧に着手し,3日目に復旧が完了する。 os PE ms ・出荷ラインの復旧:製造ラインの復旧が完了した翌日から,出荷ラインの復 旧に着手し,3日目に復旧が完了する。 ・部品供給量:必要な復旧が完了して,大規模地震発生前と同等の製造能力で 製造が開始できる時点までには,D社及びE社から,7日分の製造に必要な部 品の25%が到着し,製造の開始時点以後の4週間は,毎週1回,同量の部品 が到着する。5週間以後は,製造に必要な部品が全て到着する。 ・部品の在庫量:7日分の在庫を保有している。 (2)関連事項の整理 ・製造関連の情報システム:毎日,夜間に,1日分の製造関連の実績データを社内 のバックアップシステムにフルバックアップしている。停電が発生すると,無停 電電源装置(UPS)に自動的に切り替わり,情報システムをシャットダウンする。 ⑬|』|の決定 各事業の事業影響度分析(以下,BIAという)を行い,その結果を表1のとおり 取りまとめた。 表1 BIAの結果 Pox|5|6|高|中 |Y|9|6||是 BIAの結果,X事業とY事業は,営業利益,事業の持続性,事業の成長性とも同 じであるが,OY事業よりもX事業を優先して復旧させることにした。 (4)目標復旧時間(QAR,RTOという),目標復旧時点(以下,RPOという),目標 復旧レベル(以下,RLOという)の決定 X事業を最優先で復旧させることにし,大規模地震発生日を1日目として,3日 目にBCPを発動する前提で,X事業の出荷ラインの復旧が完了するまでの時間を 整理した。 その結果を踏まえて,大規模地震発生時点ではなく,BCP発動日を1日目とし て,RTOを| b日に設定することにした。 次に,関連事項の整理を踏まえて,RPOを設定した。 続いて,被害想定における部品の在庫量と供給量から復旧レベルの平均値を算 ー12一 定した。中核部品Xを1週間に7日間製造する条件で算定すると,X事業を再開 してから4週間の復旧レベルの平均値は,平常時の製造量の50%となった。この 平均値を踏まえて,B社と打合せをしたところ,RLOを75%にするように要請が あった。そこで,部品供給量は変わらない前提で,X事業を再開してから4週間の 復旧レベルの平均値を算定した際に用いた算定式を活用して,RLO 75%を達成す るために必要な在庫量を算定した。その結果,最少でも日分の部品を 常に在庫しておくことになった。 (5)非就業時間帯の従業員の駆け付け指示 あらかじめ,復旧活動のため,A社に駆け付ける対象となる従業員を決めておく。 従業員及びその家族の安否確認が完了した後,A社に駆け付ける対象となる従業 員には,労働契約法に基づき,|q』|に違反しないよう,次の条件を満足で きると上司が判断した場合にだけ,駆け付ける指示を行うことにする。 ・会社の社屋の安全が総務人事部によって確認済みであること。 ・余震などによる二次災害の危険がないこと。 ・上司と連絡可能な通信機器を所持していること。 (以下,省略) (6)災害対策本部の設置 大規模地震が就業時間帯に発生した場合には,本社の人災害対策室に災害対策本 部員が集合して,災害対策本部を設置する。また,非就業時間帯に発生した場合 には,災害対策本部員が,会社から貸与されているスマートフォンから電話会議 に,可能な限り参加することによって,災害対策本部を設置する。 (BCPに関する課題と対応策〕 G課長は,BCPの検討結果を事業継続計画書として文書化し,F部長に説明した ところ,大規模地震を想定した今回のBCPについて,次の課題への対応を行うよう 指示を受けた。 ・BCPを実現するために必要な設備投資,大規模地震の発生で事業活動が中断する ことによる|ec|,復旧に掛かる費用,従業員への給与支払,部品メーカへ の支払などへの考慮が必要となる。そのため,営業・投資・財務の諸活動による キャッシュフローの変動を算出し,経営への影響を確認しておくこと。 ー13一 ‘OD社及びE社からの部品購入から中核部品Xの納入までの流れを途切れさせな WC,A社の事業が事業継続計画どおりに復旧できるよう,施策を行うこと。 ・従業員に対して行うBCPの教育・訓練の実施結果を分析してBCPの課題を抽出す るとともに,中長期での経営環境の変化によって生じると考察される現行のBCP への影響を分析し,PDCAの考え方に基づいた対応を定期的に実施すること。 早速,G課長は,F部長から指示された,これらの課題への対応策を事業継続計画 書に盛り込んだ。その後,G課長は自らの考えで,他の自然災害やパンデミックの発 生などで,経営に大きな影響を及ぼす可能性が高いリスクに関するBCPへの取組計 画を立案し,F部長の承認を得て,経営会議に付議することになった。

共通の文章

ライフゲームに関する次の記述を読んで,設問1]ー5に答えよ。 ライフゲームとは,数学者コンウェイが考案した,生命の誕生,生存,死滅など を再現したシミュレーションゲームである。マス目状の盤上の各マスに生命が存在 CX,そのマス自身及び隣接するマスの状態によって次世代の誕生,生存,死滅が 決まる。その条件を表1に示す。 なお,隣接するマスには,斜め方向のマスも含む。また,生命が存在するマスを “EOWA”,生命が存在しないマスを『死のマス"と呼ぶ。 表1誕生,生存,死滅の条件 死のマスに隣接する生のマスが三つならば,死のマスは次の世代では生のマスとなる。 誕生(死のマスに隣接する生のマスが二つ以下又は四つ以上ならば,死のマスは次の世代で も死のマスである。) 生のマスに隣接する生のマスが二つ又は三つならば,生のマスは次の世代でも生のマス 生存 である。 aie生のマスに隣接する生のマスが一つ以下ならば,生のマスは過疎によって次の世代では 死のマスとなる。 過密生のマスに隣接する生のマスが四つ以上ならば,生のマスは過密によって次の世代では 死のマスとなる。 [4X4マスのシミュレーション〕 4X4マスの盤上における第3世代までのシミュレーションを図1に示す。 列 EEE jp 時EE3IIE olxlolxァ|xlolx|9まのマス lxlxlolxl_、lolxlolxl_zilolx|Ov kee 3lolololx||xlololx|olzllx 4 lxlolxlx|klol:| 第1世代第2世代第3世代 図1 4X4マスの盤上における第3世代までのシミュレーション 第1世代は,初期値として設定されたものである。例として,第1世代の2行目1 列目のマスを考える。現在,このマスは死のマスである。このマスに隣接するマス を網掛けで示す。これら五つのマスの中に生のマスが三つある。これは表1の“HE A”の条件に該当するので,第2世代の2行目1列目のマスは生のマスになる。同 様に,第1世代の各マスについて,そのマス自身及び隣接するマスの状態を確認す ることで第2世代が決まる。次の世代への状態の更新は,全てのマスについて同時 に行われる。 〔(盤上のマスのデータ構造] NXNマスの盤上の状態を表現するデータ構造を考える。多次元配列が利用できな いプログラム言語を考慮し,盤上の各マスの生死状態を管理するデータ構造として1 次元配列mを用いる。配列mのデータ構造のイメージを図2に示す。. 列 1 2-i本N |ーー ais cc ee 2| Ne oa 図2配列mのデータ構造のイメージ [配列mを次世代に更新するプログラム】〕 使用する定数,配列及び関数を表2に,配列mを次世代に更新する関数updateを 図3に示す。 なお,関数に配列を引数として渡すときの方式は参照渡しである。 表2使用する定数,配列及び関数 Ea od rr 1が,死の場合は0が入る。 ー17一| function update(m) copy(m,temp)//配列mを配列tempにコピーして退避する clear(m)//配列mの全ての要素の値を9にする for(jiを1からNXNまで1ずつ増やす) if(i-1がNで割り切れる) a<9 b<1 elseif(iがNで割り切れる)Pe a<-l bc 0 else a<-l b=ia endif e<0 for(yを-1から1まで1ずつ増やす) for(xをaからbまで1ずつ増やす) if((yと9が等しくない)or(xと9が等しくない)) c<—i+yXN+x if((cが1以上)and(cがNXN以下)) rc eとe+] endif endif endif endfor endfor //生死を判定する m[i]と1 elseif((temp[i]と1が等しい)and((eと2が等しい)or(eと3が等しい))) endif endfor endfunction 図3関数updateのプログラム [テストプログラム〕 図3のプログラムをテストするために,配列mに第1世代が与えられたときの第 p世代が,机上で作成した正しい結果である配列rと等しいことを確認するプログラ ムを作成した。作成した関数shouldBeを図4に示す。ここで,pには2以上の整数 が入る。 1:function shouldBe(m,p,r) 2:for(ijを1からpまで1ずつ増やす) 3:update(m) 4:endfor 5:for(iを1からNXNまで1ずつっ増やす) 6:if(m[i]とr[i]が等しくない) 7:return false//テスト失敗 8:endif 9:endfor 19:return true//テスト成功 11:endfunction 図4関数shouldBeのプログラム 図3のプログラムが正しく動作する状態で図4のプログラムを実行したところ, テストが失敗した。原因を調査した結果,図4の|ケ ]行目に問題があること が判明したので,①プログラムを修正してテストを成功させることができた。

共通の文章

冗長構成をもつネットワークに関する次の記述を読んで,設問ユー4に答えよ。 S社は商社であり,図1のような業務ネットワークを5年前に構築し,現在も利用 している。 <=>. ーーーーーーニーーグーBG hv Ne 業務ネットIL3SW:レイヤ3スイッチ ‘a eiGey kb Ir28W:レイヤ2スイッチ |ESレットノ秒 |にここジン8|ポートのWMeあ6 !! 図1現行の$社ネットワーク(抜粋) 業務サーバで実行する処理は二つある。一つは,社内LANに接続しているPCか ら,L3SWとL2SWを経由して送られる在庫問合せや発注といった処理(以下,対話 処理という)であり,業務サーバとL2SWの間のトラフィックは3台の業務サーバ の間でほぼ均等になっている。もう一つは,3台の業務サーバの間でL2SWを経由し て通信し実行する日次のバッチ処理(以下,バッチ処理という)CHE,バッチ処 理中は対語処理を禁止している。| 経路の障害でこれらの処理を滞らちせないよう,①業務ネットワークでは,スイッ チ類を稼働系及び待機系の冗長構成とし,稼働系のスイッチ(L3SW1,L2SW1)に 障害が発生した場合に,待機系のスイッチ(L3SW2,L2SW2)を経由して対話処理 やバッチ処理を行えるようにしている。各スイッチのスループットは,現行の各処 理が必要とする通信量に見合っている。 現在,営業日の夜間に実行するバッチ処理に8.0時間を要している。バッチ処理が 長引くと対話処理に使える時間が短くなるので,これ以上バッチ処理に要する時間 を延ばせない。 また,対話処理についても,在庫問合せや発注の件数が5年前に比べて増え,営 業日のピーク時には社内LANと業務ネットワークの間の通信量は03Gビットンノ秒 ー20一 に達している。 業務の改善〕 S社は,業務の改善を目的として,MOQ),(②)に取り組むおことにした。 (1)商品や顧客に関して,より詳細なデータを取り扱えるようにする。 (2)取り扱う商品の品目数や数量を増やせるようにする。 ①),(2)を行うと,業務サーバで取り扱うデータ項目数が増加して1レコード当た りのデータサイズが拡大するだけでなく,処理対象のレコード数も増加する。その 結果,処理データ量は次の5年間で現行の10倍に増え,バッチ処理に掛かる時間, 及び対話処理に必要となる社内LANと業務ネットワークの間の通信量もそれぞれ10 倍に増えると予測した。 S社は,②③バッチ処理が次の5年間にわたって現在と同じ時間内に完了することを 目標として,新業務ネットワークを構築するプロジェクトを立ち上げ,業務ネット ワークの管理者であるT君が担当することになった。 [業務サーバの更新検討] 新サーバの候補を選定した。諸元(抜粋)を表1に示す。 表1現行サーバと新サーバの諸元(抜粋) 新サーバの実機を使ったバッチ処理の検証テストを行う前に,次の1)て④が成り 立つものと仮定して,バッチ処理時間を机上で計算した。 (1)新サーバのCPUの1コア当たりの処理速度は,現行サーバの2倍速い。さらに, 内蔵するコア数に比例して速くなる。 2)新サーバのメモリの読み書き速度は,現行サーバの2倍速い。読み書き速度は, メモリサイズの違いによらない。 se HA,っ (3)サーバにおけるバッチ処理のスループットは,CPUの処理速度とメモリの読み 書き速度のそれぞれの増加に比例して増加する。 (4)パッチ処理時間は,バッチ処理のスループットの増加に反比例して短くなる。 現行サーバで8.0時間を要していたバッチ処理時間は,机上計算の結果,新サーバ では短縮されて| 』|時間になる。 〔業務サーバの更新に伴うネットワークの見直し〕 バッチ処理において,新サーバの性能を最大限発揮させるためには,サーバだけ でなくネットワークも見直す必要がある。バッチ処理における新サーバ間の通信に 必要な帯域を最大1.6GCビットノ秒と試算した。 現行のL3SW,L2SW及び新サーバは,複数のリンクを論理的に束ねて1本のリン クとして扱うことができるリンクアグリゲーション機能(以下,LAという)を備え ている。例えばLAを利用して2本のリンクで装置間を接続すると,その帯域は理論 上2倍になる。T君は,図2のアークのように,L3SWとL2SWの間,及びL2SWと 新サーバの間を,LAを利用して1Gビットノ秒のリンク2本で接続することを考え ee <> pap lane |Z||ィいることを示す。 |[eswe|| |{Ses || 図2新S社ネットワーク案(抜粋) T君は,新業務ネットワークの構成について,システムアーキテクトであるU氏 に相談した結果,次の(i),(i)のコメントを受けた。 (i)図2中の新業務ネットワークも,スイッチ類は稼働系と待機系の冗長構成であ OM,アークのうち,営業日のピーク時に帯域不足となるリンクがある。 ー99— (ii)現行のL2SWについて確認しておくべき性能要件がある。確認の結果次第では, L2SWを更新する必要がある。 T君は。これらのコメントについて検討を加え,本プロジェクトを成功裏に完了さ 5 a)kale

共通の文章

スイッチ間の接続経路の冗長化に関する次の記述を読んで,設問1ー4に答えよ。 R社は,社員200名の医療機器の販売会社であり,AC,部署1 NEMS 2 サーバを運用している。本社LANの構成を図1に示す。 サーバサーバ pl p4 L2SW1のVLAN設定 —‘|ie [|| ILe|…[gc]ire][Pe]!sw:vey eatog jiVLAN1O i) VLAN20 pl,p2,…:ポートID 注記L2SW2,L2SW3には,VLANは設定されていない。 図1本社LANの構成(抜粋) 図1に示したように,L2SW1のplとp2にはVLAN10が設定されており,WH1 サーバは部署1のPCだけが利用できる。L2SW1のp3とp4にはVLAN20が設定さ れており,部署2サーバは部署2のPCだけが利用できる。 〔障害の発生と対応作業〕 月末の繁忙時,部署1のPCから部署1サーバが利用できなくなったと情報システ ム課に連絡があった。連絡を受けたS君が対応作業を行った。 S君は,まずL2SW1のLEDランプの状態を確認した。L2SW1の電源LEDランプ は[| 』|]していたが,p2のリンクLEDランプが消灯していたので,L2SW1と |b|の間の経路障害と判断した。そこで,p2に接続されたLANケーブルを, L2SW1の空きポートp10に接続し直したところ,p10のリンクLEDランプが点灯し たので,障害が復旧したと考えた。しかし,部署1のPCから部署1サーバは利用で きないままだった。S君は,①L2SW1に追加設定が必要であったことに気付き,追 加設定を行って障害から復旧させ,後日,L2SW1を交換した。 このような障害を再発させないために,上司のT EES,L2SW間の経路の冗長化 を検討するようS君に指示した。S君は,STP(Spanning Tree Protocol)による L2SW間の経路の冗長化について検討した。 (STPの導入検討] L2SW間にLANケーブルを増設して経路を冗長化すると,経路が|c|構成 になり,| qd|ストームが発生する。STPは,|c|構成となった経路の 一部をフレームが流れないようにブロックすることで論理的にツリー構成に変更し て,経路の冗長化を可能にするプロトコルである。 S Blk,L2SWを3台,サーバとPCを2台ずつ用意し,テストLANを構築して STPの動作確認を行うことにした。テストLANの構成を図2に示す。 3台のL2SWに,図2中の注記に示す設定を行った。注記の設定によって,L2SW1 がルートブリッジになり,L2SW2とL2SW3の間の経路がブロックされてツリー構成 になる。各TL2SWにサーバ又はPCを接続し,その後,L2SW間を接続してSTPを稼 働させた。各サーバとPCには,それぞれ図1と同じネットワーク情報を設定した。 なお,2のテストLANの各機器は,本番環境を想定して図1と同一名称とした。 サーバサーバ pl p4 L2SW1のVLAN設定 ae Oo tt NN ee |1| 1 D i!D 1 |7! iVLAN1O0 ij! VLAN20, 注記1ブリッジ優先度は,L2SW1を最も高くし,続いて,L2SW2,L2SW3の順に設定した。 注記2パスコストは,全てのパスに同じ値を設定した。 図2テストLANの構成 S君は図2のテストLAN構築後,次の手順で動作確認を行った。 ・PC1及びPC2から,それぞれの部署サーバの利用は問題なく行えた。 ・L2SW2のplに接続されたケーブルを抜いて,経路が再構成されるまで約50秒待 つた。 ・PC1から部署1サーバまでの経路は,L2SW3経由で再構成されたが,②PC1から 部署1サーバが利用できなかった。そこで,PC2をL2SW2のp3に接続し直して 部署2サーバにアクセスしたところ,部署2サーバは利用できた。 テスト結果の報告受けた主任は,本社LANのL2SW間の経路を,STPを利用 して図2の構成で冗長化するときは,新たなVLAN設定が必要になることを$S Alc 説明した。和主任が説明した新たなVLAN設定を表1に示す。 表1新たなVLAN ERE Bf WANE|WLAN L2SW1> 2SW2 L2SW3- 注記タグVLAN ld,一つのポートに複数のVLANを共存させるとき使用される。 STPを利用する場合,設定が複雑なので運用が困難になることが考えられた。そ こで,S Ald,別の方法を調査したところ,経路の冗長化にリンクアグリゲーション (以下,LAという)が利用できることが分かったので,LAの導入検討を行った。 (LAの導入検討〕 LAは,複数のイーサネット回線を論理的に束ね,1本の回線であるかのように扱 う技術である。使用中のL2SWを調べたところ,LAに対応していることが分かった。 LAを導入する場合は,図1中のVLAN設定に加え,L2SW1へのVLANの追加設 定とLAの設定を行うことになる。LA導入時の本社LANの構成を図3に示す。 サーバ||サーバ L2SW1のVLAN設定 ME p m Fs.pt 96|yrAN20|ポートwLAN| ie Sra LAD IGE HH 1p 1 pl部署2!LAの設定箇所 !i |[pe]…[Lme]1}[LEe]-[ge]|BES !1)!0 LVEA0O ow eeneedし-。------VPAN0| 1| 3 LA導入時の本社LANの構成 図3中の設定によって,例えば,L2SW1のp2とL2SW2のplを接続する経路に障 害が発生しても,L2SW1のpdとL2SW2のp2を接続する経路だけを使って,部署1 のPCは,継続して部署1サーバを利用できる。 以上の検討から,図1 OA LANでL2SW間の経路を冗長化する場合,③図3の LAの構成は,図2のSTPの構成に比べて利点が多いことが分かった。S君が検討結 果を主任に報告したところ,T主任からLAの導入を進めるよう指示を受けた。

共通の文章

問7飲食店向けタッチ式注文端末に関する次の記述を読んで,設問1ー4に答えよ。 G社は,飲食店向けのタッチ式注文端末(以下,端末という)を開発している。 飲食店向けタッチ式注文システムのシステム構成を図1に示す。管理システムは, ネットワークのアドレスを利用して,端末を識別する。 端末1て端末n無線LAN|mm 図1システム構成 [端末の画面操作 端末の画面はタッチパネルになっている。利用者は,ボタンの領域(以下,ボタ ンという)にタッチして端末を操作する。画面には,選択画面注文画面及び履歴 画面の3種類がある。端末画面の表示概要を図2に示す。 商品詳細注文個数注文履歴合計金額 表示領域表示領域表示領域表示領域 注文個数減 ボタン 商品選択注文履歴注文個数増戻るボタン注文取消戻るボタン ボタン確認ボタンボタン注文ボタンap et (a)選択画面(b)注文画面(c)履歴画面 図2端末画面の表示概要 端末は,利用者がーつのボタンに触れ,離したときに,そのボタンにタッチした と認識する。また,利用者が複数のボタンに同時に触れていた場合,最後に離した ボタンをタッチしたと認識する。 なお,端末の初期化中又は画面の切替え中に,ボタンにタッチした場合,タッチ は無効とする。 [端末の動作概要)〕 端末の主な機能の動作概要を表1に示す。 表1端末の主な機能の動作概要 EE ・選択画面で利用者が商品選択ボタンにタッチすると,注文画面に須移する。 ・注文画面で,利用者は,注文個数増ボタン又は注文個数減ボタンにタッチして,注文個 7数を指定した後,注文ボタンにタッチして,商品を注文する。 ・利用者が商品を注文すると,注文情報として注文D,商品名及び注文個数を注文履歴に 保存する。注文Dは,端末ごとに,1から始まる連番として生成される。 ・注文画面で,利用者が戻るボタンにタッチすると,選択画面に戻る。 ・選択画面で利用者が注文履歴確認ボタンにタッチすると,履歴画面に居移する。履礎 注文履歴確認画面では,注文履歴を閲覧することができる。 ・履歴画面で,利用者が戻るボタンにタッチすると,選択画面に戻る。 —・履歴画面で,利用者が注文取消ボタンにタッチすると,注文履歴から当該の注文情報を 削除し,画面表示を更新する。 [端末一管理システム間の通信】 注文ボタンへのタッチを認識すると,端末は,管理システムに注文メッセージを 送信する。管理システムは,注文メッセージを受信すると,一定時間後に,端末に 注文確定メッセージを送信する。 端末は,注文確定メッセージを受信すると,注文履歴の中から対応する注文を確 定し,管理システムに注文確定完了メッセージを送信する。ただし,対応する注文 が注文履歴の中に存在しなかった場合,端末は注文確定メッセージを破棄する。 RU ATA,注文確定メッセージを送信後,一定時間内に端末から注文確定 完了メッセージを受信できなかった場合,注文が取り消されたものとして扱う。 注文取消ボタンへのタッチを認識すると,当該の注文が確定していない場合に限 り,端末は,管理システムに注文取消メッセージを送信する。 (端末一管理システム間のメッセージの構成 注文メッセージは,メッセージの種別を示すデータ,注文ID及び注文情報から構 成される。それ以外のメッセージは,メッセージの種別を示すデータ及び注文IDか ら構成される。 [端末のソフトウェア〕 端末は,イベントドリブンプリエンプション方式のリアルタイムOSを使用する。 ・端末の初期化 端末の電源を入れると,初期化プログラムが動作する。初期化プログラムは, ハードウェアの初期化,メモリの初期化,端末制御プログラムのRAMへの転送, 及びOSの起動を行う。端末制御プログラムのRAMへの転送速度は1 Mバイトノ 秒,ハードウェア及びメモリの初期化から端末制御プログラムの転送開始までの 所要時間は0.2秒であり,OSの起動には0.3秒掛かる。 ・タスクの機能概要 主なタスクの機能概要を表2に,入力判定タスクの処理を図3に示す。 表2主なタスクの機能概要 ・メインタスクから指示された画面の表示を行う。画面切替え中は,切替え 画面表示フラグを1にする。(sg ーー・情報要求の通知を受け取ると,画面種別及びボタンの座標から成る画面情 He,要求元に通知する。 |タウチバネル|タッチしたを穫すると各し。Cee ANE AD EMOTE.|| ・タッチパネルタスクから通知された情報と,画面表示タスクから通知され 入力判定た画面情報を基に,タッチの有効性を判断する。有効な場合,メインタス クに通知する。 入力判定タスク開始 ①通知された情報を取得 画面表示タスクに情報要求を通知して,画面情報を取得し た後,①通知された情報と画面情報を比較 メインタスクに①②⑫⑰情報を通知 入力判定タスク終了 図3入力判定タスクの処理

共通の文章

問8通信販売用Webサイトにおける決済処理の設計に関する次の記述を読んで,設問 1~4に答えよ。 T社ではインターネットを用いた通信販売を行っている。通信販売用Webサイト (以下,Webサイトという)で利用できる決済方法は,クレジットカードを利用し て決済するクレジット決済だけであったが,顧客の利便性向上を目的に,新たにU 社が運営するコンビニエンスストア(以下,コンビニという)での支払(以下,コ ンビニ決済という)の導入を検討することになった。 顧客は,購入する商品を選択し,顧客IDを入力して商品の配送先を指定した後, 決済方法選択画面から希望する決済方法を選択することが可能となる。 Webサイトでのクレジット決済処理の処理内容を表1に,コンビニ決済処理の処 理内容を表2,表3に示す。 表1クレジット決済処理の処理内容 BS,有効期限,カード名義,セキュリティコード)を入力する。 Webサイトは,クレジットカード会社へカード情報と支払情報を送信し,決 済完了かカード利用不可かの回答を取得する。 Webサイトは,クレジットカード会社の回答が決済完了の場合,配送センタ 知する。 ー36一 表2コンビニ決済処理の処理内容(リアルタイム処理) 処理名和 ea顧客は,Webサイトが表示する決済方法選択画面で,決済方法としてコンビ の所択|決済を選択する。 wins)Webサイトは,U社に購入情報(金額,入金期限日)を送信し,U社から決 決済番号取得eae ats, Webサイトは,U社から回答された決済番号と金額,入金期限日の情報(以 決済情報通知下,決済情報という)を電子メール(以下,メールという)で顧客に通知す る。 顧客は,U社コンビニへ行き,店頭で決済番号を提示して支払を行う。 表3コンビニ決済処理の処理内容(バッチ処理) Webサイトは,U社から1時間に1回送信される入金 REF H eeeデータファイルを1件ずつ読み込み,入金データの決 |済番号がWebサイトで保持している決済番号と一致す るかどうかを確認する。 決済番号が一致し,決済番号に該当する購入情報が購 入金データチェック—AMY UH IC ko TRUS NTWORUBS,Web+ mnイトは,配送センタに商品の発送を指示し,同時にメ ールで顧客に商品の発送を通知する。 エラーファイル|決済番号が一致しない,又は決済番号に該当する購入 生成情報が取り消さぐれている場合,Webサイトは,AST ータの情報を入金エラーファイルに書き込む。 Webサイトは,1日に1回,商品発送前かつ取消前の購 入金期限確認入情報を1件ずつ読み込み,入金期限のチェックを行 入金期限チェックう。 ee Webサイトは,入金期限日が過ぎても入金されていな い購入情報を取り消して,メールで顧客に通知する。 【アクティビティ図〕 現在のアクティビティ図を基に,コンビニ決済処理(リアルタイム処理)を加え たアクティビティ図を図1に,入金データチェック処理のアクティビティ図を図2 に,入金期限チェック処理のアクティビティ図を図3に示す。 |題符| "webサイト。。|配送センタ| 決済方法選択画面 を表示する 決済方法を選ぶ へ[コンビニ決済] [クレジット決済] カード情報入力 クレジットカード会社へ]|U社に購入情報を カード情報と支払情報を送信し決済番号 送信するを取得する [カード利用不可]A[ae TI 再決済を— 依頼する(===)決済情報を 通知する を行う商品を発送する @@ 本 凡例| 人@ase| |ee 1処理の内容)| |[条件] |分岐くつ普行処理 | pI ORD| り| | | |並行処理 | | |(処理の内容)(処理の内容) | |終了OT 図1クレジット決済処理とコンビニ決済処理のアクティビティ図\ |mee|weサイト|mmsz>z| 入金データファイルから 入金データを1件取得する データ終 [入金データあり] [入金データの決済番号が一致し Jy BAMり消されていない] [入金データの 入情報が取り消 ee)[mn しない,又は購= されている] 入金データを入金エラー ファイルに書き込む商品を発送する @@ 図2入金データチェック処理のアクティビティ図 ce|webyイト|mwvz ae 商品発送前かつ取消前の 購入情報を1件取得する [購入情報終了]3S 青報終 [購入情報あり] 購入情報の チェックを行う XS[Lc]] [Ls]] 取り消3顧客に通知する © 図3入金期限チェック処理のアクティビティ図 (FIA) 現在のクラス図を基に,コンビニ決済処理を加えた決済処理に関連するクラス図 を図4に示す。 || Siar 」 アレジ人提|コンピ=前和久本コンボポジション: 入金期限確認():void|!属性はクラス内部からだけ参照可能! HEE JO:void|操作は他のクラスからも参照可能 |作字体は抽象を意味する。ーー|! 図4クレジット決済処理.コンビニ決済処理に関連するクラス図 [入金期限チェック処理の処理タイミング) 図2の入金データチェック処理と図3の入金期限チェック処理の処理タイミング について考察する。 日付が変わった後,入金期限チェック処理の前には必ず入金データチェック処理 を実施する必要がある。これは,①入金期限チェック処理が入金データチェック処 理よりも先に実施された場合に発生する不具合を防止するためである。

共通の文章

品質評価に関する次の記述を読んで,設問1,2に答えよ。 P社は,衣料品を全国の店舗で販売している。P社の情報システム部は,競争力強 化を目的とした販売アイテムの大幅な増加と販売ポイントサービスに関する機能の 拡充のために,商品販売管理システムのサブシステムX,Y,Zへの追加機能の開発 を,短期間で行うことになった。商品販売管理システムは,在庫管理システム,経 理システムなどの社内システムとデータの送受信を行っている。情報システム部のQ 課長は,今回の開発プロジェクトのプロジェクトマネージャ(PM)として,R主任 を指名した。 [プロジェクト開始準備 R主任は,サブシステムの開発に関わる詳細設計・詳細設計レビュー・コーディン グ・単体テスト・結合テストを請負契約で一括して開発請負会社に発注することに した。サブシステムX,Yの開発については,それぞれ,以前からP社の開発案件を 受託しP社の業務仕様を理解しているL tt,M社と契約し,サブシステムZの開発 については,新規に参加するN社と契約した。N社の実施責任者に現在のコーディ ング規約を渡して,その内容を説明した。 R主任は,詳細設計書,ソースプログラム,単体テスト項目,結合テスト項目は, 各社の手順書に従ってレビューするよう各社の実施責任者に依頼した。各社での結 合テスト完了後に,各工程別のテスト成績書による品質判定と納品物の確認を行い, 全ての結果が良好と判断された後に,総合テスト工程へ進むことにした。 各サブシステムは,開発規模が同程度の二つのモジュールで構成され,モジュー ル別の開発の難易度は,表1のとおりである。 表1モジュール別の開発の難易度 aoe|wlemlwlwlwlg 詳細設計に着手する直前に,次の2項目に変更が入ったので,各社の実施責任者 に変更箇所を電子メール(以下,メールという)で通知し,開発メンバに周知する ごfie ように依頼した。 ・在庫管理システムとのインタフェース ・コーディング規約 さらに,インタフェース仕様書は,他の関連システムにも改修があることから, 仕様変更箇所を反映し,各社に再配布した。一方,コーディング規約は,インタフ ェース仕様書の変更に時間が掛かったことから,プロジェクト完了後に全体を修正 することにしたので,再配布はしなかった。 情報システム部が手掛けてきた過去の開発実績のデータに基づき,基本となる工 程別の品質判定基準を表2のとおり設定した。 表2工程別の品質判定基準 (項目数/kステップ)(欠陥数プページ,kステップ)” mmmmyes-|[|ー[=a|7 注詳細設計レビューはページ当たり,単体テスト・結合テストはkステップ当たり R主任は,品質判定基準を盛り込んだ開発計画書を作成し,Q課長の承認を得てか ら,自社のプロジェクトメンバ及び各社の実施責任者に開発着手を指示した。 [品質の評価] 各社の結合テストが完了後,R主任は,プロジェクトの品質管理担当のメンバから, 各社から提出された工程別の品質実績のデータをサブシステム別に整理した表3の 報告を受けた。 表3工程別の品質実績 (項目数/kステップ)(欠陥数プページ,kステップ) mmsres-|-|-|>|wlslsu lmezh|»|=|=[a pu|a ae i xs R主任は,表2の品質判定基準と表3の品質実績から,次のように考えた。 ・サブシステムX ROYは,テスト密度及び欠陥数が,全ての工程で品質判定基準 内であった。しかし,サブシステムX lk,OR 2の工程別の品質判定基準を適用 LT,追加の分析を行った上で品質を判定すべきである。 ・サブシステムZは,| 』|でのテスト項目不足,又は[|b|の可能性 がある。 そこで,R主任は,L社に,追加の分析を依頼した。L社は,分析結果を整理して 次のとおりR主任に報告し,Q課長もその結果を了承した。 ・モジュールX1:テスト密度は品質判定基準内であり,欠陥数は品質判定基準を超 えているが,開発の難易度を考慮すると品質は良好である。 ・モジュールX2:テスト密度と欠陥数は品質判定基準内であり,品質は良好である。 また,R主任は,N社に,欠陥を工程ごとに,開発メンバ別,モジュール別,AK 抽出すべき工程別,作り込み原因別に分析して,その結果を報告するよう依頼した。 N社は,分析結果を整理して次のとおりR主任に報告した。 ・特定の開発メンバの力量不足が,欠陥の原因ではなかった。 ・欠陥の82%はモジュールZ1であった。 ・モジュールZ1の欠陥の作り込み原因別の分析では,コーディング規約の違反によ る欠陥が,単体テストで2件,結合テストで32件抽出された。 ・モジュールZ1の欠陥の工程別分析結果は表4のとおりであった。 表4モジュールZ1の欠陥の工程別分析結果 単位件 eat fae a: [WWWrraー||4』|ぅ2 lmezxト|-|-|a [原因分析と再発防止〕 R主任は,N社に対して,モジュールZ1の欠陥について改修し,原因に基づいて 単体テストの項目を見直して,再テストを行うよう依頼した。さらに,モジュール ー4一 22について,コーディング規約の違反が原因で発生した欠陥と同種の欠陥の摘出を 行うことによって,品質の確保を行うよう依頼した。 COR,R主任が詳細を調査すると,今回の開発直前に変更した箇所に関係する欠 陥が90%であることが判明したので,その結果をQ課長に報告した。 Q課長から,再発防止策を検討するよう指示があったので,まず,R主任は,根本 原因分析の技法(以下,なぜなせぜ分析という)を使って,分析を実施した。なぜな ぜ分析の一部を図1に示す。 なせ? ee? なせ? なぜ?(根本原因)コーディング規約の変更をメールで通知しただけで, [<|を確認するプロセスがなかった。 図1なぜなせぜ分析 そこで,R主任は,根本原因の再発防止策として,コーディング規約などの変更を 開発請負会社に通知した場合には,PMが,開発請負会社の実施責任者に, を確認するよう,開発プロジェクトのルールとして定めることをQ課長 に説明した。 Q課長は,次の点についても見直しを行うようR主任に指示した。 _結合テスト完了時に品質不足が発覚すると,詳細設計やコーディングにまで遡っ て対処する必要があるので,[a|や| 。|を起こすおそれがある。 したがって。,今後新規に開発に参加する会社と請負契約を締結する場合には, 各工程が完了するごとに品質評価結果を提出させることを検討すること。 ・品質が良好であるにもかかわらず,欠陥数が工程別の品質判定基準を超えてしま うという事象が発生した。適切に品質判定ができるよう,と開発請負 会社のスキルレベルを考慮した品質判定基準となるように見直すこと。 ==

共通の文章

問19キャパシティ管理に関する次の記述を読んで,設問1ユー4に答えよ。 X社は,娯楽チケット販売業を営む会社である。2013年1月に策定した中期事業 計画において,“取扱いチケットの種類の増加と新サービスの提供によって,2015年 度(2015年4月1日から2016年3月31日まで)の売上を2012年度の2倍にする" という目標を立てた。中期事業計画どおりの売上の達成は不確実性を含んでいたが 事業目標の達成を見越して娯楽チケットの販売システム(以下,販売システムとい う)を2013年度に再構築した。 [再構築後の販売システムの概要とキャパシティ計画] 販売システムは,再構築以前からイベント会社やコンビニエンスストアの店頭,電 話,インターネット(PC,スマートフォンなど)からの購入に対応していた。サー ビス利用者のチケットの購入手段は,利便性が高い点や購入記録が残る点からインタ ーネットが主流であった。販売システムの再構築によって次のサービスを実現した。 ・遊園地や映画のチケットを,利用する直前でも割引価格で購入できる。 ・購入したチケットをスマートフォンで電子チケットとしても受け取ることができる。 ・会員制度を新設する。会員はチケットの先行購入予約が可能になり,さらに,購 入実績に応じてポイントを受け取る特典を与えられる。 再構築後の販売システムを利用する販売部のチケット担当の資任者は,BAN イントを付与する条件(対象のチケット,MB,購入手段,期間,時間帯など)を 簡単な操作で登録できるようになった。 再構築する販売システムのキャパシティ計画を策定するに当たって,2013年4月 に,サービスに対する和需要となるデータ処理件数を検討した。データ処理件数は売 上に連動すると想定し,2012年度の実績値と2013ー2015年度のチケット売上の計画 値を基に,3年間のデータ処理件数を見積もった。これらを表1に示す。 表1チケット売上の計画と実績及びデータ処理件数の見積りと実績の推移① 日ミニ5二 |2013年度|380億円||-|54百件|-| |2014年度|500億円|-|72百亡件|-| |2015年度|640億円|| "一|90百万件|-| ー48一 次に,販売システムの再構築について,表2に示す二つの案を考えた。 表2販売システムの再構築案 一括構築:再構築前の|初回構築:再構築前の2.0倍の処理能力 an 3.5倍の処理能力追加構築:再構築前の3.5倍の処理能力 サーバ台数の追加で,サービスを停止すること なく容量・処理能力の増強が可能 ①案1と案2を比較検討した結果,案2を選択して初回のシステム構築を行った。 また,データ処理件数が表1の見積りどおりに増加した場合,2016年3月までに 追加構築を完了する予定を立てた。 [追加構築の実施〕 案2での初回構築は,2013年12月に無事完了した。2014年1月に再構築後のシ ステムでのサービスを開始した直後から,遊園地や映画館を利用する直前でも電子 チケットを購入できるサービスが,予想以上に好評だった。それまでは単価が高い コンサートや演劇のチケットが売上の柱だったので平均販売単価は下がったが,販 売件数が大きく増加したので売上が伸びた。その結果,2013年度のチケット売上は, ほぼ計画どおりであった。しかし,データ処理件数は,見積りよりも15%程度上回 っていた。 1年後の2015年4月初旬に,2013年度と2014年度のチケット売上の実績及びデ ータ処理件数の実績を表1に加え,表3を作成した。 表3チケット売上の計画と実績及びデータ処理件数の見積りと実績の推移② seme |2012年度|一|320億円|-|45百万件| |2015年度|640億円|-|sonnet| -| 注'計画欄及び見積り欄の数値は,表1と同じ2013年4月作成のものである。 2実績欄の数値は,該当年度の事業終了時点でまとめられたものである。 2014年度の実績値と2012年度の実績値を比較すると,チケット売上はほぼ計画ど おりの約1.6倍であったが,データ処理件数は見積りを大きく上回る約2.1 ICR ていた。そのまま運用を続けていたところ,2015年5月頃から,②アプリケーショ ンサーバのCPU使用率がしきい値を超え,警告メッセージが出るようになった。そ こで,案2での追加構築を2015年8月に完了させ,その後,警告メッセージは出な 5A le)io 〔サービス運用段階のキャパシティ管理活動] システム部のITサービスマネージャのY Blk,アプリケーションサーバの警告メ ッセージが出た後に販売システムを追加構築する判断をしたことを反省し,キャパ シティに起因したインシデントの発生を抑制するために,キャパシティ管理活動を 次のとおりに定め,実行した。 (1)監視 キャパシティの評価指標を日常のオペレーションレベルで監視する。しきい値 を超えた場合などは,システム運用監視ツールで警告メッセージを出し, |』|管理プロセスを通じて,適切に対処する。 (2)分析 監視活動によって収集された情報を,モデル化などの技法を用いて分析する。 将来の予測を基に,資源の増強の要否や実施時期などを検討する。さらに,OF ャパシティ管理のプロセスを評価するためのKPIを設定する。 Oチューーツダ 分析結果を基に,資源の割当量や利用条件の変更などの対応策を検討し,適切 な状態に調整する。 (4)実装 キャパシティ計画及びチューニング活動に基づき,変更を|b|管理ブロ セスを通じて稼働環境に展開する。 〔追加構築後のキャパシティ対応] 2016年4月,X社はZ社が主催するイベントのチケット販売の独占契約を得た。 これを成功させて,Z社との提携を実現すれば中長期的な売上の拡大が期待できる。 Z社イベントのチケットの申込みにおいて,ピークが予想される18~21時は,他の チケットの販売と合わせるとアプリケーションサーバのCPU使用率が一時的にしき ー50一 い値を超え,応答時間が悪化することが懸念された。しかし,資源の増強を伴う変 更作業は期間が必要なので,当面の間はサービスの提供内容とサービス要求の埋要 との釣合いを取って,インシデントの発生を防ぐことにした。そこでY君は,この 需要管理の方針に基づき,対策を検討した。Z社イベントのチケットの申込みは,イ ンターネットの会員サイト内に専用URLを設け,3日間限定で先着順に受け付ける。 再構築後の販売システムのサービス状況を調査すると,応答時間の悪化が発生した のは18~21時の時間帯の2回だけであった。Z社イベントのチケット販売を優先す るために,Z社イベントのチケットの申込量がピークになる時間帯に:.インターネッ トでの他のチケットの申込量を減らすことができれば,サービス全体に支障が出な いと判断した。Y Ald,このための具体的な対策を販売部と共同で立案し,販売部 の部長の承認を得た。 さらに,経営層から顧客データ活用によるマーケティング強化の指示があった。 これまで一定期間ごとに分散保存していた会員の購入記録を,一括して蓄積できる データウェアハウスを構築する。購入が見込める会員を迅速に選別して優先販売や キャンペーンの案内をする販売促進機能の検討を開始した。⑤この販売促進機能に よって,将来見込まれる販売件数の増加をキャパシティ計画に反映し,処理能力を .増強したり,ストレージの容量を増やしたりする必要がある。

共通の文章

問11業績管理システムの監査に関する次の記述を読んで,設問14に答えよ。 製造業のF社は受注生産を行っており,製品別に五つの事業部がある。また,こ れらの事業部とは別に,営業本部が営業活動を行っている。TF社では,事業部別の業 績を把握するために業績管理システムを構築し,運用している。業績管理システムの 機能改修を昨年度行ったので,その後の運用状況について,監査室による監査を実施 することになった。 [業績管理システムの概要〕 業績管理システムは,部門業績サブシステム及び営業支援サブシステムで構成され ている。 部門業績サブシステムでは,事業部別の受注・売上・利益の計画・実績・見通しな どの業績データを管理している。一方,営業支援サブシステムでは,個々の営業案件 を管理している。 従来,部門業績サブシステムによる業績見通し情報は,各事業部が,それぞれ管理 している資料に基づいて,毎月入力していたが,実績が業績見通しと大きく異なるこ とがあった。そこで,昨年度,業績見通しの精度の向上を図るために,業績管理シス テムを改修した。現在は,営業支援サブシステムの営業案件データを基に,週次で業 績見通しを算出している。改修後の業績管理システムの概要は,図1のとおりであ る。 “a ae営業支援サブプシステム||部門業績サブシステム ics 図1改修後の業績管理システムの概要| [予備調査の結果〕 監査室は,予備調査として業績管理システムの仕様書を閲覧した後,関係者に対し てヒアリングを行った。調査結果は次のとおりである。 ー54一 ①)営業支援サブシステムでの営業案件データの入力 ①システム改修に当たり,営業担当者が,既存の営業案件データを営業支援サブ システムに入力する。入力するデータ項目は,“案件番号",“受注番号",“案件 名称",“担当営業部",“担当事業部",“受注確度",“営業状況",“受注年月", "売上年月",“受注金額'などである。 ②当年度内の営業活動によって,既存案件の内容が変化したり,新規案件が発生 したりすると,営業担当者がその都度,営業支援サブシステムに案件状況を入力 する。入力期限は毎週末であるが,営業担当者が多忙で入力が遅くなる場合もあ る。 @案件の“受注確度”は,AEの五つに区分して入力し,確度Aは受注確定を 意味する。UML,営業本部では,これまで“受注確度”よりも顧客との打合せ 内容などを記載した“営業状況”の内容を重視していた。したがって,営業支援 サブシステムでは,受注管理表に受注確度別の集計は出力していない。 ④営業担当者による案件状況の入力結果は,営業部の課長が承認した後,確定す る。 (2)営業支援サブプシステムから部門業績サブシステムへの営業案件データの取込み ①情報システム部のシステム運用担当者は,週次(週の第一営業日)で,作業手 順書に従って営業案件データの取込み作業を行っている。作業手順書には,営業 支援サブシステムの営業案件データの出力や,部門業績サプシステムへの営業案 件データの取込みなどの実施すべき作業が記載されている。 ②営業案件データと事業部案件データは,データ項目とデータ形式が異なるので, 部門業績サブシステムに取り込むときには,データ変換表を利用して自動変換し ている。データ変換表は,組織,製品の変更があると,システム運用担当者が, 随時更新している。 ③システム運用担当者は,取込み作業終了後に,実施した作業と作業結果をシス テム業務記録簿に記入する。 ④事業部案件データを基に事業部案件一覧表が作成され,各事業部の関係者が作 業計画立案などに利用している。 (3)部門業績サブシステムでの事業部案件データの利用 ①部門業績サブシステムでは,事業部案件データを受注確度別に集計し,受注確 ax BB.= 度別に定めた確率を掛け合わせて,業績データ(事業部別の受注・売上・利益の 見通しなど)を作成している。 ②業績データを基に,週次で業績管理表が作成され,各事業部が内容を確認する とともに,月次で経営企画室が経営会議で報告している。 〔本調査の実施〕 監査室は,予備調査の結果を基に,データ品質の確保と業績管理システムの改修目 的達成の観点から,業務の流れに従ってリスクと監査要点を検討し,“リスクと監査 要点一覧"'にまとめた。その抜粋は,表1のとおりである。 表1リスクと監査要点一覧(抜粋) maT 営業案件データの|①営業担当者に対して,全ての新規案件を入力する 1 |a|が確保され|ように指導されているか。 mu.②新規案件に抜け,漏れがないことを確認するため に,営業日報などの記録と照合されているか。 営業案件データが,最|①営業案件データの|pb|が営業担当者に周 データ入力|2 ONES半半arS知・徹底されているか。 =i@状況に変化がない旨を確認できているか。 業績見通し算出に必要|①営業案件データの| c|について判断基準 4にトンーーが定められ,周知・徹底されているか。 7ータが人人力され全の上長が入力内容をレビューしているか。 営業案件データの|権限のある者が,営業案件データを適切に承認して 承認4|』|が確保され|いるかが。 ない。 営業支援サブシステム|①営業案件データの取込み処理のために利用される データ取込み|5|テムに,正確な営業案|=sgーー から部門業績サブシス[|。|が正しく作成されているか。 件データが取り込まれ②営業支援サブシステムから部門業績サブシステム meetーーへの取込み作業が正しく実施されているか。 業績管理システムの改|改修前と比べて,改修後は|f|が減少して 全般修目的が達成されな|いるか。 YN,