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

共通の文章

マルウェア対策に関する次の記述を読んで,設問1ー5に答えよ。 T社は,社員60名の電子機器の設計開発会社であり,技術力と実績によって顧客 の信頼を得ている。社内のサーバには,設計資料や調査研究資料など,営業秘密情 報を含む資料が多数保管されている。 T社の社員は,社内LANのPCからインターネット上のWebサイトにアクセスし て,情報収集を日常的に行っている。ファイアウォール(LAR,FWという)には, 業務上必要となる最少の通信だけを許可するパケットフィルタリングルールが設定 されており,社内LANからのインターネットアクセスは,DMZのプロキシサーバ経 由だけが許可されている。TT社の現在のLAN構成を図1に示す。 eae.|[|=|Brae i ee.|(teed|。| !|_DNSサーバサーバサーバ!DNSサーバ||サーバ||メールサーバ (8d ew}Ow Eel 社内LAN LEC|“LPC||L3SW:レイヤ3スイッチ |se|gc|ーーL2SW:レイヤ2スイッチ 1 T社の現在のLAN構成 T社では,マルウェアの感染を防ぐために,PCとサーバでウイルス対策ソフトを 稼働させ,情報セキュリティ運用規程にのっとり,最新のウイルス定義ファイルと セキュリティパッチを適用している。 [マルウェア対策の見直し〕 最近,秘密情報の流出など,情報セキュリティを損ねる予期しない事象(以下, インシデントという)による被害に関する報道が多くなっている。この状況に危機 感を抱いたシステム課のM課長は,運用担当のS君に,情報セキュリティ関連のコ ンサルティングを委託しているY氏の支援を受けて,マルウェア対策を見直すよう 指示した。 S君から相談を受けたY氏がT社の対策状況を調査したところ,マルウェアの活 ーー4= 動を押止する対策が十分でないことが分かった。Y氏はS君に,特定の企業や組織内 の情報を狙ったサイバー攻撃(以下,標的型攻撃という)の現状と,T社が実施すべ き対策について説明した。Y氏が説明した内容を次に示す。 [標的型攻撃の現状と対策) 最近,標的型攻撃の一つである| a』|攻撃が増加している。|。|攻 は,攻撃者が,攻撃対象の企業や組織が日常的に利用するWebサイトの|b| を改ざんし,WebサイトにアクセスしたPCをマルウェアに感染させるものである。 これを回避するには,WebブラウザやOSのセキュリティパッチを更新して,最新の 状態に保つことが重要である。しかし,ゼロデイ攻撃が行われた場合は,マルウェ |アの感染を防止できない。 マルウェアは,PCに侵入すると,攻撃者がマルウェアの遠隔損作に利用するサー バ(以下,攻撃サーバという)との間の通信路を確立した後,企業や組織内のサー バへの侵入を試みることが多い。サーバに侵入したマルウェアは,攻撃サーバから 送られる攻撃者の指示を受け,サーバに保管された情報の補取,破壊などを行うこ とがある。①マルウェアと攻撃サーバの間の通信(以下,バックドア通信という) ik,HTTPで行われることが多いので,マルウェアの活動を発見するのは容易ではな い。 Y氏は,このようなマルウェアの活動を抑止するために,次の3点の対応策をSA に提案した。 ・DMZに設置されているプロキシサーバとPCでの対策の実施 ・ログ検査の実施 ・インシデントへの対応体制の構築 (DMZに設置されているプロキシサーバとPCでの対策の実施] S君はtプロキシサーバとPCで,次の3点の対策を行うことにした。 ・プロキシサーバで,MMT S WebサイトをT社が独自に設定できる|c|] 機能を新たに稼働させる。 ・プロキシサーバで利用者認証を行い,攻撃サーバとの通信路の確立を困難にする。 ・プロキシサーバでの利用者認証時に,②PCの利用者が入力した認証情報がマルウ ェアによって悪用されるのを防ぐための設定を,Webブラウザに行う。 =%= [ログ検査の実施] S君は,ログ検査について検討し,次の対策と運用を行うことにした。 プロキシサーバは,社内LANのPCとサーバが社外のWebサーバとの間で通信し た内容をログに記録している。業務サーバ,ファイルサーバ,FWなどの機器も,ロ グインや操作履歴をログに記録しているので,プロキシサーバだけでなく他の機器 のログも併せて検査する。③ログ検査では,複数の機器のログに記録された事象の 関連性も含めて調査することから,DMZにNTP(Network Time Protocol)サーバを 新規に導入し,ログ検査を行う機器でNTPクライアントを稼働させる。導入する NTPサーバは,外部の信用できるサーバから時刻を取得する。NTPサーバの導入に MoT,表1に示すパケットフィルタリングルールをFWに追加する。 表1 FWに追加するパケットフィルタリングルール 注記FWは,最初に受信して通過させるパケットの設定を行えば,応答パケットの通過を 自動的に許可する機能をもつ。 ログ検査では,次の2点を重点的に行う。 ・プロキシサーバでの利用者認証の試行が,短時間に大量に繰り返されていないか どうかを調べる。この検査によって,マルウェアによるサーバへの[| i|x 繋が行われた可能性があることを発見できる。 ・セキュリティベンダやセキュリティ研究調査機関が公開した,バックドア通信の 特徴に関する情報を基に,プロキシサーバのログに記録された通信内容を調べる。 この検査よって,バックドア通信の痕跡を発見できることが多い。 [インシデントへの対応体制の構築〕 S Blk,④インシデントによる情報セキュリティ被害の発生,拡大及び再発を最少 化するために社内に構築すべき対応体制についてまとめた。 以上の検討を基に,S Blk,マルウェア対策の改善案をまとめてM課長に報告し ー生計 た。改善案は承認され,実施に移すことになった。

共通の文章

経営分析とバランススコアカードに関する次の記述を読んで,設問1,2に答えよ。 A社グループは,セルフサービス方式(以下,セルフ型という)のコーヒー店チェ ーンを全国展開するA社と,ファミリーレストランチェーンを展開するA社の子会 社で構成される大手の外食グループである。セルフ型は,顧客回転率を上げて来客 数を増やすために,店舗の立地環境が他の業種に比べて重要である。A社は,長年に わたって出店数を増加させ続けたことによって,駅前やオフィス街を中心に約900 の直営コーヒー店舗を展開してきた。主な顧客は会社員や学生である。 喫茶店市場では縮小傾向が続いているが,A社は長年業界トップグループの位置を 維持している。しかし,コンビニエンスストアが安価でおいしいコーヒーの販売を 開始したので,対抗策として新機軸の戦略を打ち出すことにした。 [B社との比較による現状確認] 現状を確認するために,A社と同じセルフ型コーヒー店チェーンを運営するB社 をベンチマークとして比較検討を行った。B社は,海外の最大手コユーヒー店チェーン 運営会社と日本国内において独占的にフランチャイズ契約を結び,全て直営で約600 店舗を展開している。A社と出店地域は似ているが,B社はおしゃれな雰囲気や全席 を禁煙とすることで,若者や女性の支持を得ている。コーヒーの単価はA社よりも5 割程度高い。前年度示のA th(コーヒー店チェーン事業単体)とB社の貸借対照表, 損益計算書,及び諸指標の比較を表1て4に示す。 表1 A社の貸借対照表表2 B社の貸借対照表 (単位:百万円)(単位:百万円) (資産の部)(負債の部)15,000(資産の部)(負債の部)16,000 流動資産31,000|流動負債11.000||流動資産20,000|流動負債13,000 現金及び預金~22.000|買掛金4,000現金及び預金11,000]買掛金2,000 売掛金4.000|その他7,000売掛金3,000]その他11,000 有価証券-|固定負債4.000有価証券2,000|固定負債3,000 棚卸資産2,000棚卸資産2,000 繰延税金資産1,000|(純資産の部)58,000繰延税金資金1,000|(純資産の部)28,000 その他2,000|株主資本58,000その他1,000|株主資本28,000 固定資産42,000|資本金7.000||固定資産24,000|資本金5,000 有形固定資産26,000)資本剰余金17,000有形固定資産10,000]資本剰余金7,000 無形固定資産1,000|利益剰余金34.000無形固定資産1,000|利益剰余金16,000 投資その他資産15.000投資その他資産13.000 ーー8ーー 表3 A社とB社の損益計算書表4 A社とB社の諸指標の比較 (単位:百万円) 売上高72,000|79.000||自己資本比率(9%) 売上原価32.000|23.000||流動比率(%)[にょ|(省略) 売上総利益40.000|56.000||固定比率(%) 販売費及び一般管理費35,000|49000||総資本回転率(%)|099|180| 人件費12,000]|21000||固定資産回転率(回転)||5]|(省略)| 賃借料及び水道光熱費10000|19000 その他13,000}9000|[ROA(%)|eC) 営業利益5,000|7.000||売上高総利益率(%) 営業外収益400 200||売上高営業利益率(%)|69|89l 営業外費用100 100||売上高経常利益率(%)|74|90 経常利益5,300|7100||売上高当期純利益率(%) 特別利益300 300||店舗平均売上高(千円ノ年) 特別損失700 800||店舗数(店)|935|606| 税金等調整前当期純利益4900|6,600 法人税等の税金等2.100|2,800]|店舗平均来店客数(人/日) 当期純利益2,800 3,800 安全性の視点から見ると,両社とも自己資本比率,流動比率が高く,固定比率は 低い。さらに,固定負債額も小さいので,短期,長期ともに問題がかがいといえる。© 収益性の視点から見ると,両社の売上高総利益率の差が大きい。A社は,世界中の じかばい 主要生産地からコーヒー豆を買い付け,直火式知煎を大量に行う仕組みを確立して WS,コーヒー豆の品質管理を徹底することで,おいしいコーヒーを提供すること ができ,それが顧客満足の向上につながっている。しかし,このためのコストに対 し,コーヒーの単価を低く設定しているので,売上高総利益率が低くなっている。 一方,B社は提携している海外のコーヒー店チェーン運営会社からコーヒー豆を安価 で仕入れている。 A社は,安価な商品による売上を,出店数の多さ,人件費の低さ,顧客回転率の高 さで補うことで利益を生み出すビジネスモデルであることを再認識した。しかし,A 社はこれらに過剰に依存せず,新たな方法で営業利益率を向上させることが必要で |あると感じていた。 経営の効率性の視点から見ると,ROEで大きな差が出ている。ROEは,自己資本 比率,売上高当期純利益率及び| q|に分解できるが,売上高当期純利益率と osgny =9= 〔ロードサイド型店舗の出店検討] A社の子会社の事業であるファミリーレストランの市場規模は,低価格競争,大量 出店戦略の限界によって縮小傾向にあり,A社の子会社も売上高が減少して苦戦して いた。一方,コーヒー店チェーンを運営するC tlt,ロードサイド型と呼ばれる幹 線道路の沿線での出店を促進し,売上を伸ばしていた。セルフ型に比べて顧客1人 当たりの平均売上単価(以下,客単価という)は高く,広い空間でゆっくりとくつ ろげる独自のサービス形態で,特に家族連れやシルバー層に人気があった。C社は全 て直営で約300店舗を展開し,売上高営業利益率は約100%であった。 A社は,C社の事例を参考にし,子会社が運営するファミリーレストランをロード サイド型のコーヒー店に業態変更する検討を始めた。ロードサイド型の出店は,商 圏は広いが,潜在顧客数が駅前などのセルフ型店舗よりも少ないので,売上高と営 業利益を拡大するためには客単価を上げる必要があった。そこで,一手間加えた軽 食メニューを充実させることで他社との差別化を図ろうと,従来のファミリーレス トランで採用していたセントラルキッチン方式から,店舗調理方式に切り替えるこ とにした。切替後の運用コストについては,大きく増加しないことを確認済みであ る。 〔(バランススコアカード戦略マップの作成 売上高と営業利益を拡大するために,新たな事業戦略を次のとおり策定した。 ・ファミリーレストラン事業を客単価が高いロードサイド型コーヒー店に業態変更 する。 ・ゆっくりとくつろげる空間を提供する。 ・おいしいコーヒーと,店舗調理方式による一手間加えた軽食こよって,顧客満足 を高める。 過去に事業戦略を策定した際は,その事業戦略が書かれた資料を店舗の貢任者に 送付しただけだったので,店舗の従業員まで十分に浸透せず,事業戦略に基づいた 現場の活動につなげることができなかった。今回は,店舗の従業員まで浸透させる ことが重要であると考えた。 次に,新たな事業戦略を実現する手段を可視化するために,図1に示す,子会社 を含めたA社グループのバランススコアカード(以下,BSCという)戦略マップを 作成した。 =9H= ESIP> /人ーーー eel|ESOT DSP ED ふいしい||,'とくつろげる空間で 効率が良い出店増大うNL Le]コーヒー豆の方式での の視点画一的な品質管理を軽食メニュー 飲食メニュー(iの提供 の提供 学習と成長)Ge品質管理)Gat)店舗調理 大量接客5のルール4技術の 簡素なN i=z し/ の視点技術社員増員最適化策定の向上向上 1 A社グループのBSC戦略マップ BSC戦略マップを作成することで,①既にレストランの店舗を保有していること, レストラン事業で得たロードサイド型店舗の運営ノウハウがあること,実務経験が ある従業員を引き続き雇用できることなど,今回の業態変更にはA社グループなら ではの強みがあることを確認できた。 次に,BSC戦略マップを基に全社のCSF(重要成功要因)とKPI(重要業績評価 指標)を設定した。さらに,これらのめBSC戦略マップ,CSF及びKPIを基に,店 舗の従業員を巻き込んだ店舗ごとのアクションプランを策定するように,全てのロ ードサイド型店舗の責任者に指示した。

共通の文章

探索アルゴリズムに関する次の記述を読んで,設問1ー5に答えよ。 1個ずつの重さが異なる商品を組み合わせ,合計の重さが指定された値になるよう にしたい。 この間題を次のように簡略化し,解法を考える。 [問題〕 指定されたn個の異なる数(自然数)の中から任意の個数の数を選択し,それら の合計が指定された目標Xに最も近くなる数の組合せを1組選択する。その際, 合計はXより大きくても小さくてもよい。ただし,同じ数は1回しか選択できな いものとする。 例えば,指定されたn ORAS(10,34,55,77),目標Xが100とすると,選択 した数の組合せは(10,34,55),選択した数の合計(以下,合計という)は99と なる。 この間題を解くためのアルゴリズムを考える。 指定されたn個の数の中から任意の個数を選択することから,各数に対して,B 択する,選択しなかない,の二つのケースがある。数を一つずつ調べて,次の数がなく なるまでHERTS”,“選択しない”の分岐を繰り返すことで,任意の個数を選択 する全ての組合せを網羅できる。この場合分けを図1に示す。 初期状態(A) 次の数を選択する次の数を選択しない 状態B)状態(C) | 選択する|次の数:34|選択しない選択する|次の数34|選択しない 状態D)状態(E)状態(F)状態(G) 選択した数:10,34選択した数:なし 選択する選択しない\/選択する選択しない\/選択する選択しない\/選択する選択しない 図1問題を解くための場合分け [データ構造の検討] 図1の場合分けをプログラムで実装するために,必要となるデータ構造を検討す る。 まず,図1の場合分けを木構造とみなしたときの各ノード(状態)を構造体Status で表す。構造体Statusは要素として"合計",“選択した数",“次の数”をもつ必要 がある。| プログラムで使用する配列,変数及び構造体を表1に示す。 表1プログラムで使用する配列,変数及び構造体 問題で指定されるn個の数を格納する配列。配列の添字は1から始まる。 問題で指定される目標Xを格納する変数。 次の三つの要素をもつ構造体。状態を表す。 total:合計を表す変数。初期値は0。 ・selectedNumbers[]:選択した数を表す配列。各要素の初期値はnullとする。 。ae|配列の添字は1から始まる。 tatu‘a nextIndex:次の数のnumbers[]における添字を格納する変数。初期値は1。 次の数がない場合は0。 構造体の要素は“.”を使った表記で表す。“.”の左に,構造体全体を表す変数を 書き,“"の右に,要素名を書く。 構造体Statusの値を格納する変数。“取得した状態”を表す。 snes捕"という)を表す。初期値はnullとする。 se,|MBER Statusの値を格納する変数。“*現時点での解答の候補"(LT,“HBO [探索の手順] 図1に示した場合分けの初期状態(A)からの探索手順を,次の(1)て(3)に示す。 ①これから探索する状態を格納しておくためのデータ構造として,キューを使用す る場合とスタックを使用する場合で,探索の順序が異なる。また,②データ構造に よってメモリの使用量も異なる。ここではキューを使用することにする。 (1)初期状態(A)を作成し,キューに格納する。キューが空になるまで②⑫,(3)を 繰り返す。 ②)キューに格納されている状態を一つ取り出す。これを“取得した状態"と呼ぶ。 “取得した状態”の評価を行う(状態を評価する手順は次の"取得した状態"の 評価】に示す)。 (3)“取得した状態”"に次の数がある場合,次の数を選択した状態と,次の数を選 択しない状態をそれぞれ作成し,順にキューに格納する。 取得した状態”の評価] "取得した状態"を評価し,“解答の候補"”を設定する手順を,MO),(②)に示 す。 (1)“ARE OR”がnullの場合,“取得した状態”を“解答の候補”にする。 (2)“解答の候補”がnullでない場合,“解答の候補”の合計と“取得した状態”の 合計をそれぞれ目標Xと比較して,後者の方が目標Xに近い場合,“取得した状態" を解答の候補"にする。 探索の手順が終了した時点の“解答の候補”を解答とする。 探索を行うための関数を表2に示す。 表2探索を行うための関数 引数として与えられる構造体Satusの値5をキューに追加する。 キューから構造体Satusの値を取り出して返す。 PNDキューが空ならば1を,そうでなければ0を返す。 isE)キューが空かどうかを判定する。 引数として与えられる構造体Statusの値sに対して,次の数を選択した状態を表す構造 体Statusの値を返す。戻り値の各要素に次の内容を設定する。 (StatsTts)・total:s.total++numbers[s.nextIndex]を設定する。 ical・selectedNumbers[]:s.selectedNumbers[]にnumbers[s.nextIndex]を追加した配列を設 定する。 ・nextIndex:s.nextIndexがnならば0を,そうでなければsnextIndex+1を設定する。 引数として与えられる構造体Statusの値sに対して,次の数を選択しない状態を表す構 造体Statusの値を返す。戻り値の各要素に次の内容を設定する。 nextStatus2(S)・total:s.totalを設定する。 ・selectedNumbers[]:s.selectedNumbers[]を設定する。 ・nextIndex:snextindexがnならば0を,そうでなければs.nextIndext+1を設定する。 引数として与えられる数nの絶対値を返す。 [探索処理関数treeSearch) 探索処理を実装した関数treeSearchのプログラムを図2に示す。 ここで,表1で定義した配列及び変数は,グローバル変数とする。 function treeSearch() currentStatusを初期化する//初期状態を作成する enqueue(currentStatus)//初期状態をキューに格納する wi currentStatus<—dequeue()//キューから状態を取り出す if(ansStatusがnullである) elseif(abs(target-ansStatus.total)がabs(target-currentStatus.total)よりも大きい) endif@(a) .)(の) enqueue(nextStatus1(currentStatus)) //次の数を選択した状態をキューに追加する enqueue(nextStatus2(currentStatus)) //次の数を選択しない状態をキューに追加する endif endwhi le endfunction 図2関数treeSearchのプログラム [探索回数の削減] 関数treeSearchで実装した方法では,nが大きくなるにつれて“取得した状態"を 評価する回数(以下,探索回数という)も増大するが,不要な探索処理を行わない ようにすることによって,⑧③探索回数を削減することができる。探索回数の削減の ために,探索を継続するかどうかを示すフラグを新たに用意し,次の(1①1)て(3)の処理 を追加することにした。 (1)“取得した状態”の合計が目標X以上の場合,以降の状態で数を選択しても合 計は目標Xから離れてしまい,“解答の候補"にはならない。以降の状態の探索を 不要とするために,フラグを探索中止に設定する。 (2)Q)以外の場合,フラグを探索継続に設定する。 (3)フラグが探索中止の場合,“取得した状態"からの分岐を探索しないようにする。 探索回数の削減のために追加する変数を表3に示す。 表3探索回数の削減のために追加する変数 探索回数の削減を実装するために,図2中の(a)の行と(8)の行の間に図3 のプログラムを追加し,(8)を“it([__=_],かっ,nextFlagが“Y”TH る)”に修正した。 nextFlagで else nextFlagで endif 図3探索回数の削減のための追加プログラム

共通の文章

仮想環境の構築に関する次の記述を読んで,設問1ー4に答えよ。 N会計事務所は,数十人の公誰会計士,税理士,司法書士を有する,中堅の公認会 計士事務所である。所内では,業務用の会計システム,法務システム,契約管理シ ステム及び総務システムが稼働している。業務拡大に合わせて所内システムの改修 を行ってきたが,サーバ類の老朽化が顕著になってきたことから,サーバなどの業 務システムラ基盤を再構築することになった。 [現行システムの構成 N会計事務所の所内システムは,各業態の顧客経理支援業務に利用されるので24 時間稼働している。業務要件として,会計システムは24時間無停止での稼働が必要 で,業務が集中したときでも一定の性能が求められる。法務システムは30分以内の 停止が許容されている。 会計システムと法務システムは,それぞれアプリケーションサーバ(以下,APサ ーバという)とデータベースサーバ(以下,DBサーバという)の2種類のサーバで 構成されており,契約管理システムと総務システムは,それぞれAPサーバとDBサ ーバを兼用するサーバで構成されている。会計APサーバは負荷分散装置によるアク ティブプアクティブ方式,法務APサーバは手動によるアクティブスタンバイ方式 で冗長化され,DBサーバは両システムともアクティブンプアクティブ方式のクラスタ リング構成となっている。会計APサーバで処理するトランザクションは,Bit AP サーバ1と会計APサーバ2に均等に分散される。法務APサーバで現用系サーバが 故障した場合,20分以内に待機系を手動で起動し.アクティブな状態にできる。現 行システムの構成を図1に示す。 「会計システム=。|!法務システム ! |Eat ESI (ore)(|ee el 図1現行システムの構成(抜粋) システム課のB課長は,現行システムのそれぞれのサーバの稼働状況を調査した。 現行システムは,10台のサーバから構成されており,いずれのサーバもCPU数は1 ==if= でコア数が2の機器である。現行システムのリソース使用状況を表1に示す。 表1現行システムのリソース使用状況 サーバ システム|sag,|周波数|平均使用率|容量|平均使用率|容量|平均使用率 (GHz)(%)|(Gバイト)|(%)|I(Tバイト)|(%) |サーバ1|会計|AP|3|eo|s|zo|2|7| |サーバ2|会計|AP|3|eo|s|7|2|~~| |サーバ3|会計|DB|3|eo|6|eo|4|es| |サーバ4|会計|pp|3|ceo|6|eo|4|«| |サーバ5|法務|AP|2|7?70|38|7|2|zo| |サーバ6|法務|AP|2|5|3|5|2|7| |サーバ7|法務|DB|2|eo|6|eo|4|so| |サーバ8|法務|DB|2|eo|6|eo|4|so| |サーバ9|契約管理|AP,DB|2|50|s|7|2|4| |サーバ10|総務[ap ppt 2|5|8|7|2|so| [仮想化システムの機能〕 B課長は,仮想化システムを利用して仮想サーバ環境を構築し,現行サーバ群を仮 想サーバ上で稼働させることを検討した。各現行サーバは,再構築後の仮想サーバ 環境において,いずれかの物理サーバに仮想サーバとして割り当てる。このとき仮 想化システムの機能である,複数の物理サーバのリソースをグループ化して管理す るリソースプールと呼ぶ仕組みを利用する。例えば,ある仮想サーバにCPUやメモ リといったリソースを追加する場合,1台の物理サーバのリソースの制限にとらわれ ることなく,リソースプールからリソースを割り当てればよい。表2は,仮想化シ ステムの機能の説明を抜粋したものである。 表2仮想化システムの機能の説明(抜粋) オーバコミット各仮想サーバに割り当てるリソース量の合計が,物理サーバに搭載された物理リソース量 *の合計を超えることができるようにする機能である。 物理サーバに障害が発生した場合に,その物理サーバ上で稼働していた仮想サーバを,別 自動再起動の物理サーバで自動的に再起動させる機能である。再起動には数分の時間を要する。処理 中のトランザクションは破棄される。 稼働中の仮想サーバを,停止させることなく別の物理サーバ上に移動させる機能である。 ストレージを仮想化することによって,実際に使用している量だけを割り当てる機能であ シンプロビジョニング|る。この機能を利用することによって,物理的な容量を超えるストレージ容量を仮想サー バに割り当てることができる。 ー21一 仮想化システムでは,各仮想サーバに割り当てるリソース量に上限値と下限値を 設定できる。上限値を設定した場合は,設定されたリソース量までしか使用できな い。下限値を設定した場合は,設定されたリソース量を確保し,占有して使用でき る。上限値も下限値も設定しない場合は,起動時にリソースを均等に分け合う。 [業務システム基盤の構成 B課長は仮想化システムの処理能力を次のように仮定して,業務システム基盤の構 成を設計した。 ・物理サーバで仮想サーバを動作させるための仮想化システムに必要なCPUとメモ Vik,十分な余裕をもたせて,物理サーバのCPUとメモリ全体の50%と想定する。 CPUとメモリ以外のリソースの消費は無視する。 ・仮想サーバのCPUの1コア1 GHz当たりの処理能力は,現行システムのCPUの1 コア1GHz当たりの処理能力と同等とする。 ・CPUの処理能力は,コア数に比例する。 ・CPU使用量は処理能力とその平均使用率の積とする。これをGHz相当として表す。 B課長は,業務システム基盤の拡張性を考慮し,クロック周波数が4.0 GHzの8コ |アプロセッサを1個と646バイトのメモリを搭載した物理サーバを3台同一機種で |用意することにした。また,2台以上の物理サーバが同時に停止しない限りは,シス |テム性能の低下は発生させないことにし,全業務無停止でのメンテナンスを可能と する。現行システムの業務要件を踏襲し,今回導入する仮想サーバの構成から,各 物理サーバのCPUとメモリの使用率は,65%以下の目標値を定めた。 共有ディスクは,RAIDS構成のストレージユニットとし,20 Tバイトの実効容量 をもたせることにした。 会計システムの冗長化構成は維持する。具体的には会計システムを負荷分散装置 によるアクティブンノアクティブ方式の構成とする。法務APサーバの待機系であるサ ーバ6は廃止する。サーバ6以外の全ての仮想サーバのリソース使用量は,対応す る現行サーバと同じとするが,上限値と下限値の設定は行わずに,仮想サーバに移 行することにした。B課長の考えた業務システム基盤の構成案を図2に示す。 ー99一 ps|ps2][ps3]ーーoes (ERE om ュストレージュニット||L40GHe[406Hz]1)gag 20バイト)||![aocr][noon]}]7*4 b PSI PS物理サーバ上LOGmg][xocmgl バ!|法務DB|サーバ7| CPUメモリPS2 物理サーバの構成 |会計DB|サーバ3| PSS|法務DB|サーバ8| |総務|サーバ10| 図2業務システム基盤の構成案 (CPU,メモリの使用率について〕 QQ)業務システム基盤は,仮想化システムの稼働に必要なリソースを差し引いて, CPUの処理能力の合計が48 GHz相当,メモリ容量の合計が96 Gバイトのリソー スプールで構成される。現行システムのCPU使用量は26.2 GHz相当,メモリ使用 量は42.8 Gバイトとなるが,サーバ6を廃止することからリソースプールの使用 iz,CPU使用率が| 』|%,メモリ使用率が[b|]%となる。 (2)ストレージユニットは物理サーバの共有ディスクとして接続する。各仮想サー バには現行システムと同容量をストレージユニットから割り当てるので,各仮想 サーバに割り当てるストレージ容量の合計はストレージユニットの容量を超える。 [資産査定システムの追加について〕 B課長が業務システム基盤の構成の設計を完了した後に,会計業務を統括する事務 所長から,資産査定システムの追加を検討してほしいとの要望があった。B課長は資 産査定システムを会計システムと同様なサーバ構成で構築することにし,必要なり ソース量を調査した。資産査定システムのリソース使用量の見込みを表3に示す。 表3資産査定システムのリソース使用量の見込み ‘|Sg&サーバ|CPU使用量メモリ使用量|ストレージ使用量 けサーバ[mmme[pe|12|es|』 |サーバ14[wma]vB|12|65|1| Pex[as|%|+4| 資産査定システムを業務システム基盤に加えた場合,メモリ使用量は68.4Gバイ トとなることから,リソースプールのメモリ使用率が[|c|%となり,WAY ーバが1台停止すると,N会計事務所の全システムの処理性能が低下してしまうこと が判明した。B課長は,当面の間,会計以外のシステムについては,障害発生時の性 能低下を容認し,①1台の物理サーバが停止したとしても,物理サーバの増設やリ ソースの拡張をせずに,会計システムの性能を低下させないための対策を採ること pad Oy com

共通の文章

レイヤ3スイッチの故障対策に関する次の記述を読んで,設問1ー4に答えよ。 R社は,社員50名の電子機器販売会社であり,本社で各種のサーバを運用してい る。本社のLAN構成とL3SW1の設定内容を図1に示す。 Pra L3SW1の設定内容 |172.16.1.0/24 VLAN10!TL pl|lp4 h !172.16.11 172.16.12 17216.1.3 17216.14!)。-VLANIO! 6ーバーバーバ||サーバ|!pT Ter eat 8ンジーーー-"L内部ルータ pl p4 cor)a 1 VLAN20} p10 1 1 i172.16.2.0724 VLAN20|L2SW:レイヤ2スイッチ L3SW:レイヤ3スイッチ |pl~p4,p10:ポートTD |pc|人@:内部ルータのVLANインタフェース 注記172.16.1250,172.16.2.250 Ik,L3SW1の内部ルータのVLANインタフェースに設定され たIPアドレスである。 図1本社のLAN構成とL3SW1の設定内容(抜粋) 〔障害の発生と対応〕 HSH,社員のK君は顧客先から帰社した後,自席のPCで営業支援サーバとフ ァイルサーバを利用して提案資料を作成した。その後,在庫を確認するために業務 サーバを利用しようとしたが,利用できなかった。そこで,K君は情報システム課の JR,ファイルサーバと営業支援サーバは利用できるが,業務サーバが利用できな いことを報告した。君は,]君の席のPCからは業務サーバが利用できるので,業務 サーバに問題はないと判断した。そこで,J]君は①K君の席に行き,K AD PCで pingコマンドを172.16.1.1宛てに実行した。業務サーバからの応答はあったものの, 利用できないままであった。しばらくすると,一部の社員から,業務サーバだけで なくファイルサーバや営業支援サーバも利用できないという連絡が入ってきた。 これらの連絡を受け,J君は②DNSサーバの故障又はDNSサーバへの経路の障害 ではないかと考え,本君の席のPCでpingコマンドを| a』|移てに実行したと ころ応答がなかった。そこで,君はサーバルームに行って調査し,L3SW1のp4が 故障していることを突き止め,保守用のL3SWと交換して問題を解消した。 (JRE REE) 故障による業務の混乱が大きかったので,J Ald,LISW故障時もサーバの利用を 中断させない改善策を検討した。]君が考えた,L3SWの冗長構成を図2に示す。 '17216.1.02= VLANO | |PLーーラー|L3SW1のルーティングテーブル(抜粋) L-------一ーー項番ネツットワーク|インタフェースVLAN名ホップ ed ie EE ee |5w||SW| 172.16.2.250てン172.16.2.251 L3SW2のルーティングテーブル(抜粋) ||基|ネットワーク|インタフェース|ANA oy 注記1網掛け部分は,新規に導入する機器を示す。 注記2 172.16.1.250,172.16.1.251,172.16.2.250及び172.16.2.251は,L3SWの内部ルータのVLANインタフ ェースに設定するIPアドレスである。 図2 J君が考えたL3SWの冗長構成 2では,L3SWを冗長化するためのL3SW2と,サーバを接続するためのL2SW2 を新規に導入する。L3SW1とL3SW2に必要な設定を行い,L3SW1とL3SW2の間で OSPFによる| b|経路制御を稼働ささる。PCとサーバに設定されたデフォル トゲートウェイなどのネットワーク情報は,図1の状態から変更しない。 ]君は,2に示した冗長構成案を上司のN主任に説明したところ,サーバが利用 できなくなる問題は解消されないとの指摘を受けた。N主任の指摘内容を次に示す。 PCのデフォルトゲートウェイには,L3SW1の内部ルータのVLANインタフェー スアドレス| c|が設定されており,PCによるサーバアクセスは,L3SW1の p10経由で行われる。L3SW1のpl故障時には,@図2中のL3SW1のルーティング テーブルが更新され,ネクストホップにIPアドレス| d|]がセットされる。 その結果,PCから送信されたサーバ宛てのパケットがL3SW1の内部ルータに届く と,L3SW1は当該PC宛てに,経路の変更を指示する| e|パケットを送信す る。PCは|ec|パケットの情報によって,サーバに到達可能な別経路のゲー トウェイのIPアドレスを知り。サーバ宛てのパケットを| d|に信し直す ことによって,パケットはサーバに到達する。しかし,サーバからの応答パケット は,L3SW1の内部ルータのVLANインタフェースに届かないので,サーバは利用で きない。L3SW1のp10の故障の場合.又はp10への経路に障害が発生した場合も, 同様にサーバが利用できなくなる。 このような問題を発生させないために,N主任は,VRRP(Virtual Router Redundancy Protocol)を利用する改善策を示した。 (N主任が示した改善策〕 VRRPは,ルータを冗長化する技術である。L3SWでVRRPを稼働させると, L3SWの内部ルータのVLANインタフェースに仮想Pアドレスが設定される。本社 LANでVRRPを稼働させるときの構成を,図3に示す。 i172161024。 VLANO |: !ーバーバーバ||サーバ|! | ieee cessesーースーee し條想IPアドレス:172.16.1.200|-----@---]||一-@-ーーーコ|| 1 |仮想IPアドレス:172.16.2.200|'----@--'|ーーー.やーーニーニーJ|| EE eee ee aan 7216.2.024、VLAN20, :[ @:内部ルータのVLANインタ!|pc| フェースmm 図3本社LANでVRRPを稼働させるときの構成 3に示したように,L3SW1とL3SW2の間で二つのVRRPグループを設定する。 VRRPグループ1,2とも,L3SW1の内部ルータの優先度をL3SW2の内部ルータよ りも高くして,L3SW1の内部ルータのVLANインタフェースに仮想IPアドレスを設 定する。L3SW1 OKMMOBA,Mik L3SW1への経路に障害が発生した場合は, VRRPの機能によって,L3SW2の内部ルータのVLANインタフェースに仮想IPアド レスが設定される。PC及びサーバは,パケットを仮想IPアドレスに向けて送信する ことによって,L3SW1経由の経路に障害が発生してもL3SW2経由で通信できるので, PCによるサーバの利用は中断しない。 3の構成にするときは,OPCとサーバに設定されているネットワーク情報の一 De,図1の状態から変更することになる。 J Alt,N主任から示された改善策を基に,Att LANのL3SWの故障対策案をま とめ,N主任と共同で情報システム課長に提案することにした。

共通の文章

理議申請システムに関する次の記述を読んで,設問ユン4に答えよ。 S社では,機器の購入や他社との契約の金額が10万円を超える場合には,承認権 をもつ者による承認が必要である。承認を得る際,担当者は決まった書式に従った 東議申請書を作成し,裏議申請をする。 裏議申請には,大きく分けて購買東議と契約斉議がある。購買齋議の場合は,申 請者の所属部署の部長,購買部の担当者,購買部の部長の順で,承認が必要となる。 また,契約東議の場合は,申請者の直属の上司,所属部署の部長の順で,承認が必 要となる。東議申請書の書式は,PRRMCRHRMACCRE),書式の種類は今 後増える可能性がある。ただし,申請者自身が承認者になるような東議申請は行え ARV, S社では,これまで紙の帳票で齋議申請を行っていたが,社内業務を効率化するた めに,東議申請システムを開発して,Webシステム上で東議を行うことにした。 [東議申請システムの概要) 東議申請システムには,ログイン画面,作成画面,一覧画面及び詳細画面の四つ の画面がある。 ログイン画面では,利用者がユーザIDとパスワードを入力し,ログインする。 作成画面では,申請者が東議申請に必要な事項を入力し,申請する。 一覧画面では,現在申請されている東議申請を一覧の形式で見ることができる。 齋議申請の一覧には,自分が申請した課議申請と,自分が承認者に含まれている東 議申請が表示される。一覧から東議申請を選択すると詳細画面が表示される。 詳細画面では,東議申請の内容と現在の承認の状態を確認できる。承認者が詳細 画面を参照すると,東議申請の内容のほかに承認入力欄が表示され,承認又は否認 の入力を行うことができる。 〔作成画面] 齋議申請は,書式ごとに必要な入力項目が一部異なる。申請者は,あらかじめ書 式を選択してから内容を入力する。作成画面のレイアウトを図1に示す。 申請者は,東議申請の内容を入力した後,申請を行う。承認の申請先は定義に従 |ってシステムが自動で設定するので,申請者が指定する必要はない。 ー30一 申請者IPA太郎申請者"IPA次朗 所属部署開発部所属部署開発部 タイトル|開発用PCの購入タイトル|開発用のライセンス契約 at aE {fils Ee BES FA FH)[22K Bik 3) 品名契約先|[O〇サービス株式会社 i初回支払日|20170620。| 支払先[OOM初回支払額|112000。| 支払日月々支払額II2000=| 説明開発用PC更新のため,説明導入手数料:¥100,000 ¥125,000 x 20台が必要月額:12,000 です。ご検討ください。年間総額:\244.000 承認順承認順 1.所属部長2.購買担当3.購買部長1.直属の上司2.所属部長 図1作成画面のレイアウト 齋議申請の入力項目は申請書項目と呼ばれ,書式ごとに項目を一意に識別する項 目キーと,項目値の組合せで管理される。項目の定義を表1に示す。 表1申請書項目と項目キー [詳細画面 詳細画面では,図1の内容が編集不可の状態で表示される。また,現在ログイン 中の利用者に承認順が回ってきている香議申請の場合は,画面に承認コメントの入 力欄と,承認・否認のボタンが表示される。 承認者は,齋議申請の内容を確認し検討した上で,必要に応じてコメントを入力 し,承認又は否認のボタンを押す。東議申請は,承認者全員が承認すると可決とな り,承認者のうち1人が否認した時点で否決となる。理議申請が否決された場合, 申請者は内容を修正して再度申請するか,申請を取りやめるかを判断する。 [データベースの設計] 齋議申請システムのデータベースの設計を行った。設計したデータベースのER 図を図2に,エンテイティの概要を表2に示す。 AERA 部長ユーザIDーー|sxe承認申請ID 部署DユーザD承認者情報D 部署名上司ユーザJDし|ARHI-7ID =PH aad承認状態 基和申請ID|a_|KA 申請書項目LD mW||ヒーューmA sR ID rca)ARNE申請書項目マスタ aa申請者ユーザID-mas— 項目値wren項目 wl書式名表示順 注記属性名の実線の下線____-は主キー, ーーー:1対1属性名破線の下線___--は外部キーを示す。 ーー:1対多|pres,主キーの実線が付いている属性名には, ,多対多属性名外部キーの破線を付けない。 4h 3 5さい 図2 E-R図(一部) 表2エンティティの概要(一部) ユーザの情報を管理する。上司ユーザIDには,直属の上司のユーザIDを設定する。 中請書1件の評議申請についての情報を格納する。書式によらず共通の項目はこのエンティティにも -ち,書式ごとに異なる項目は申請書項目にもつ。 齋議申請の書式ごとに異なる項目の内容を,書式ごとに一意に特定する項目キーと,項目値の 申請書項目|組合せで格納する。項目値は全て文字列で格納し,アプリケーション側で必要に応じて型を変 換して用いる。 nari:|東織申請の承各者の情報を管理する。承説状態には承認,承認BUNS),KBR “承認で,承認順の値が最も小さい承認者が,現在承認順が回ってきている承認者になる。 東譜申請の承説申請状態を格納する。承語申請状態には承認中,可決否決がある。 例えば図1の購買課議申請の金額欄の場合,申請書項目マスタには,項目キーが ‘amount’,項目名が'金額',項目値の型が整数”のタプルが,申請書項目には, 項目キーが‘amount’,項目値が"2500000"のタプルが登録される。 このデータベースでは,E-R図のエンティティ名を表名にし,属性名を列名にして, 適切なデータ型で表定義した関係データベースによって,データを管理する。 〔一覧画面 東議申請の一覧画面には,申請書ID,タイトル,申請日,申請者のユーザ名及び 所属部署名を表示する。画面に表示する情報を検索するSQL文を図3に示す。ログ イン中の利用者のユーザIDは,埋込み変数“:ユーザID"に設定されている。 SELECT申請書.申請書ID,申請書.タイトル,申請書.申請日,ユーザ.ユーザ名,部署マスタ.部署名 FROM申請書INNER JOIN承認申請ON申請書.申請書ID=承認申請.申請書ID INNER JOINユーザON申請書.申請者ユーザID=ユーザ.ユーザID INNER JOIN部署マスタONユーザ.部署ID=部署マスタ.部署ID WHERE(承認申請.承認申請状態NOT IN('可決','否決'))AND ((申請書.申請者ユーザID=:ユーザID)OR (申請書.申請書ID IN(SELECT DISTINCT申請書ID FROM承認者情報INNER JOIN承認申請 a wiし』 )> 図3齋議申請を検索するSQL文 また,経理部からの要望で,可決された東議申請について,金額と支払日の一覧 を出力できる機能を追加することになった。ただし,契約東議については初回支払 額だけ出力されればよい。金額と支払日の一覧を検索するSQL文を図4に示す。購 買裏議申請の書式IDは"購買',契約豆議申請の書式IDはBH’TCHS, SELECT申請書.申請書ID,申請書.タイトル,|。]AS金額AS支払日 FROM SEERA IMMER JOIN ARAL 1 0N INNER JOIN申請書項目t2 ON,承認申請 WHERE ((申請書.書式ID=購買AND t1.項目キー=’amount’AND 12.項目キー='pay_date')OR (申請書.書式ID=’324’AND t1.項目キー="pay_initial AND t2.項目キー="start_date)) AND(承認申請.申請書ID=申請書.申請書ID AND承認申請.承認申請状態='可決') 図4金額と支払日の一覧を検索するSQL文 [組織の改廃〕 運用開始後,利用者の部署暴動や部署名の変更が行われることが想定されるが, システムの画面上で過去の齋議申請を参照した際には,申請時の情報が表示される 必要がある。しかし,図2の設計では①この要件を満たせない部分があるので,あ るエンティティに属性を追加すると同時に図3のSQL文も修正することにした。

共通の文章

スマートウォッチに関する次の記述を読んで,設問13に答えよ。 G社は,腕時計型のスマートウォッチ(以下,ウォッチという)を開発している。 ウォッチは,スマートフォン(以下,フォンという)と連携して,電子メール(以 下,メールという)の内容表示などを行う。ウォッチとフォンから成るシステムの 構成を図1に示す。ウォッチは,フォンを経由してインターネットに接続できる。 |ペーーーテ|ラン|キーーーテブシターネッ 近距離無線通信携帯電話回線 図1システムの構成 [ウォッチの構成 ウォッチは,MPU及び日付時刻用タイマを内蔵しており,マイク,通信部,画面 表示部及び音声入力スイッチを備えている。画面表示部には,タッチパネルが付随 している。 (VAY FORE) ウォッチは,タッチパネルへのタッチとマイクへの音声入力によって,機能を切 り替えることができる。ウォッチの機能を表1に示す。 表1ウォッチの機能 現在の日付及び時刻を表示する。 フォンが受信したメールの内容を表示する。 着信情報表示フォンに着信した電話の発信者情報を表示する。 天気予報情報を表示する。天所予報情報は。フォンから送信される。 [ウォッチの動作仕様 ウォッチは,利用者の操作及びフォンからの通信によって,次のとおり動作する。 ・電源が投入されると,時計機能を実行する。 ・フォンから時計表示指示,メール受信通知,電話着信通知又は天気予報表示指示 を受信すると,対応する表1中の機能を実行する。| ・タッチパネルへのタッチを認識すると,機能選択画面を表示する。MIRA Clk,"時計"及び“天気予報"の二つのボタンが表示される。ボタンへのタッチ を認識すると,対応する表1中の機能を実行する。 ・機能選択画面では,ボタン以外の部分へのタッチは無効である。 ・利用者が音声入力スイッチを押すと,フォンに対して音声受付開始通知を送信し, 利用者が音声入力スイッチを押し続けている間は,音声受付状態となる。音声受 付状態では,音声受付画面を表示し,マイクが感知した音声を,フォンに送信す る。利用者が音声入力スイッチを離すと,音声受付状態は解除される。 ・音声受付状態では,タッチパネルへのタッチは無効である。 ・音声受付状態で.。フォンから各種通知又は指示を受信した場合は,音声受付状態 は解除ぐれ,受信した通知又は指示に対応する,表1中の機能を実行する。この一 連の処理の間,利用者が音声入力スイッチを離さずに押し続けていたとしても, 音声受付状態は解除されたままである。再びウォッチを音声受付状態にするには, 利用者は,一度,音声入力スイッチを離して,BE,押す必要がある。 [フォンにおける音声処理] フォンは,ウォッチから音声受付開始通知を受信すると,音声処理アプリケーシ ョンを起動して,ウォッチからの音声情報の受信を待つ。 ウォツチから音声情報を受信すると,音声処理アプリケーションは,受信した音 声情報を解析する。解析の結果,“RE”という音声を認識した場合には,ウォッチ に時計表示指示を送信する。“天気"という音声を認識した場合には,ウォッチに天 気予報表示指示を送信する。いずれの音声も認識できなかった場合には何もしない。 〔ウォッチのソフトウェア構成〕 ウォッチは,イベントドリプンプリエンプション方式のリアルタイム0Sを使用す る。ウォッチのタスク構造を図2に,ウォッチのタスク一覧を表2に,ウォッチの割 込みハンドラ一覧を表3に,それぞれ示す。 ー37一 A A 注記1実線の矢印は,メールボックスを使用したタスク間のメッ セージ通信の方向を示す。 注記2破線の矢印は,メモリに対する書込み及び読出しを示す。 図2ウォッチのタスク構造 表2ウォッチのタスク一覧 ・ウォッチ全体を制御し,ウォッチの機能を実行する。 ー画面の更新が必要な場合,必要な情報を画面作成タスクに通知する。 ー画面作成タスクから画面作成完了通知を受けると,画面更新指示を画面 表示タスクに通知する。 ー画面人カタスクから受けた座標情報に応じた処理を行う。 iteー適切なタイミングで,タッチ操作割込みのマスクを解除する。 ー音声入力開始通知を受けると,音声情報送信開始指示を通信タスクに通 知する。 ー音声入力終了通知を受けると,音声情報送信終了指示を通信タスクに通 知する。 ーフォンからの通知又は指示を受信すると,音声入力終了指示を音声入力 タスクに通知する。 site・メインタスクから受けた情報を基に,表示画面を作成し,画面情報に書き込 む。その後,画面作成完了通知をメインタスクに通知する。 ・画面情報の内容を基に,画面の更新を行う。 ・フォンとの通信を管理する。 |画面入力|・タッチを認識した科所の座標情報を,。メインタスクに通知する。 ・割込みハンドラから起床されると,音声入力開始通知をメインタスクに通知 し,音声情報書込処理を開始する。 ・音声情報書込処理では,入力された音声を,サンプリング周波数8kHz,量子 化ビット数16ビット,チャネル数1チャネルのデータとして,音声情報に書 音声入力き込む。 ・音声情報書込処理を実行中に,音声入力スイッツチが離されたことを検知する と,音声情報書込処理を終了し,音声入力終了通知をメインタスクに通知す る。 ・音声入力終了指示を受けると,音声情報書込処理を終了する。 表3ウォッチの割込みハンドラ一覧 = 音声入力・音声入力スイツッチが押されると,起動される。 ・タッチ操作割込みをマスクし,通信タスクを起床する。 タッチ操作割込みをマスクし,画面入力タスクを起床する。

共通の文章

アジャイル型開発に関する次の記述を読んで,設問1ー4に答えよ。 U社は,コンビニエンスストアを全国展開する企業である。自社ブランド商品のフ ァンを作るために,オリジナルのゲームなどが楽しめる専用のSNS(以下,本シス テムという)を開発することになった。 本システムでは,利用者を引き付け続けるために,コンテンツを頻繁にリリース していく必要がある。そのため,ソフトウェア開発モデルとしてアジャイル型開発 を採用する。 [採用するプラクティスの検討 アジャイル型開発で用いられるチーム運営や開発プロセス,プログラミングなど の実践手法をプラクティスと呼ぶ。、本システム開発における,システム要件や開発 体制の特徴は次のとおりである。これに基づいて,採用するプラクティスを検討す る。 ・スコープの変動が激しい テレビやコマーシャルなどの影響によって,要求の変更が頻繁に発生する。そ のために,本システムの品質に責任をもち,優先順位や仕様を素早く決める役割 をもつプロダクトオーナを任命する。そして,本システムの要求全体と優先順位 を管理するために|a|を採用し,反復するーつの開発サイクル(以下,イ テレーションという)において,開発対象となる要求を管理するために |b|を採用する。 ・求められる品質が高い 一般消費者向けSNSという性質上,その不具合は利用者離れを引き起こしかね ない。一定レベル以上の品質を保つために,継続的インテグレーション(以下, CIという)を採用する。 ・チームメンバの半数のスキルが未成計 アサインされたプロジェクトメンバには,アジャイル型開発のベテラン社員と, スキルが未成熟な若手社員が含まれる。チームの中で業務知識やソースコードに ついての知識をお互いに共有して,品質や作業効率を向上させるために, |c|を採用する。 =比一 この検討結果のレビューを社内の有識者から受けたところ,チーム全体の状況を 共有するために,その①作業状態を可視化した環境を作り,メンバ全員が集まって 必要な情報を短い時間で共有する日次ミーティングも採用するように,との指摘を 受けた。 [開発環境の検討] 本システムは,不特定多数の一般消費者に対して速いレスポンスを提供するため に,コンパイル型言語を用いてWebシステムとして開発する。 想定される開発環境の構成要素を表1に示す。 表1想定される開発環境の構成要素 Of 開発用PCとのテストを行う。 Web及びAPサーバはオープンソースソフトウェア,DBサーバは商用の コーディングを行う。また,PC内のWeb/AP/DBサーバを用いて画面ご ソフトウェアを使用する。 プロジェクトを構成する作業などを細分化し,チケットとして管理す るものなどがある。 処理を継続的に行う。 注記AP:アプリケーション,DB:データベース 表1のレビューを社内の有識者から受けたところ,開発用DBサーバは,ライセン ス及び@構成管理上のメリットを考慮して,各開発用PC内ではなく,共用の開発用 DBサーバを用意し,その中にスキーマを一づつ作成して共有した方がよい,との指摘 を受けた。また,ベテラン社員から,⑨開発者が一つのスキーマを共有してテスト =ag を行う際に生じる問題を避けるためのルールを決めておくとよい,とのアドバイス を受け,開発方針の中に盛り込むことにした。 (CIサーバの実装】 高い品質と迅速なでリリースの両立のために,自動化された回帰テスト及び継続的 デリバリを実現する処理をCIサーバ上に実装する。その処理手順を次に示す。 (1)ソースコード管理サーバから最新のソースコードを取得する。 (2)インターネットから最新のオープンソースライブラリを取得する。 ⑬[| q』]に,WE⑫で取得したファイルをコピーして処理させて,モジュ ールを生成する。 (4)(3)で生成されたモジュールに,結合テスト環境に合った設定ファイルを組み込 み,結合テスト用サーバに配置する。 (5)Webテストサーバに登録されているテストシナリオを実行する。 6)⑤)の実行結果を|e|に登録し.その登録した実行結果へのリンクを電 子メールでプロダクトオーナとプロジェクトメンバに報告する。 (7)プロダクトオーナが(6)の報告を確認して承認すると,(3)で生成したモジュー ルに,本番環境に合った設定ファイルを組み込み,本番用サーバに配置する。 〔回帰テストで発生した問題] イテレーションを複数サイクル行い,幾つかの機能がリリースされて順調に次の イテレーションを進めていたある日,CIサーバからテストの失敗が報告された。失 敗の原因を調査したところ,インターネットから取得したオープンソースライブラ りのインタフェースに問題があった。最新のメジャーバージョンへのバージョンア ップに伴って,インタフェースが変更されていたことが原因であった。このオープ ンソースライブラリのバージョン管理ポリシによると,マイナーバージョンの更新 ではインタフェースは変更せず,セキュリティ及び機能上の不具合の修正だけを行 う。のてととであった。 そこで,インターネットから取得するオープンソースライブラリのバージョンに ④適切な条件を設定することで問題を回避することができた。 a gif

共通の文章

システムの移行レビューに関する次の記述を読んで,設問1,2に答えよ。 P社は,家電量販店を営む会社である。約20店舗での店頭販売に加え,インター ネットや電話による通信販売を行っている。電話応対は,コールセンタに勤務する 約50名のオペレータが,商品の注文受付,問合せ対応などの業務を行っている。 [コールセンタの新CTIシステム開発プロジェクトの概要〕 現在P社で運用しているコールセンタのシステム(以下,現行システムという) は,コンピュータと電話を統合したCTIシステムであり,Q社が提供するソフトウ ェアパッケージ(以下,現行パッケージという)を導入している。現行システムは 顧客の属性情報や購買履歴などを管理するCRMシステムや商品在庫管理システムな どの関連システムと,オンライン処理又はバッチ処理でデータ連携している。 現行システムのハードウェアが年度末に保守期限を迎えるので,Q社が新たに開発 したソフトウェアパッケージ(以下,新パッケージという)に更改することに決め, 新CTIシステム(以下,新システムという)開発プロジェクトを立ち上げた。プロ ジェクトマネージャにはシステム部開発課のX課長が選任された。プロジェクトの スコープは,現行パッケージに施されていたP社独自のカスタマイズを新パッケー ジに取り込んで導入すること,及び既存の関連システムとデータ連携できるように することである。 今回,新たなP社独自のカスタマイズ要件はない。新パッケージでは,主要なデ ータベース(WE,DBという)の一つである顧客属性管理テーブルの一部のコード の値が細分化された。新システムでは,新パッケージのコードの値を使用するが, 今回は関連システムとの接続仕様を変更せず,新パッケージのコードの値を現行パ ッケージのコードの値に変換してから関連システムに引き渡すことにした。新パッ ケージで細分化されたコードの値の例を,図1に示す。 (現行パッケージの職業分類)(新パッケージの職業分類) |10[ata 図1新パッケージで細分化されたコードの値の例 ーJR= [移行判定会議の開催と報告] プロジェクトは順調に進み,システム適格性確認テスト(以下,システムテスト という),運用者による受入れテスト(以下,運用テストという)及び利用者による 受入れテストが終了したので,新システムへの移行の可否を判定する会議(以下 移行判定会議という)を開催することになった。X課長は,前工程のソソフトウェア適 格性確認テストの終了判定会議への出席者に加え,プロジェクトオーナであるE常 務,プロジェクト責任者であるシステム部の部長,営業部のG部長,及び①コー ルセンタの責任者であるHセンタ長に出席を依頼するように,部下のW君に指示し ie; 移行判定会議では,各担当リーダから次のとおり報告があった。 (1)システムテストの実施結果及び評価(報告者:X課長) ・システムテストの実施と検証,及び検出したバグの対応を完了した。バグ検出 件数,バグ検出密度ともP社の品質基準を満たした。バグの検出状況を分析し た結果,異常はなかった。 ・システムテストは,新システムが稼働を予定している環境を使用して実施した。 性能テストでは,関連システムも時間帯を調整して稼働環境を使用する予定で あったが,商品在庫管理システムだけは時間帯の調整ができなかった。商品在 庫管理システムのテスト環境の構成を調べたところ,性能テストをテスト環境 で実施しても問題ないと判断できたので,稼働環境と同一のソソフトウェアとDB をコロピーしてデストを行った。 ・業務機能のテストでは,業務要件に基づく業務フローの正当性を,関連システ ムを含めて検証した。さらに,新システムで現行機能が正しく動作することを 保証するために,新パッケージにおけるコードの値の細分化を考慮した上で現 行システムと新システムに同一データを投入し,主要なテーブルの処理結果を 比較した。②顧客属性管理テーブルのコードの値を自動的に比較するために 比較検証ツールを作成して検証を行った。結果は良好であった。 ・性能要件やデータボリューム要件など,| 』|を満たしていることを検証 するテストでの実測結果は目標値を満たし,システム全体の処理性能やデータ ボリュームに関する間題はなかった。 ー47一 ・新システムのメンテナンスマニュアルを整備し,保守チームに引き継いだ。 (2)運用テストの評価(報告者:システム部運用課C課長) ・システム部運用課の担当者も参加してテストを行い,結果は良好であつった。 ・新システムの運用スケジュール,手順書,障害発生時の連絡体制など,必要な ドキュメントを全て作成し,システム運用担当者に説明済みである。 (3)利用者による受入れテストの評価(報告者:X課長,コールセンタDリーダ) ・顧客属性管理画面のレイアウトが見づらいなどの指摘が2件あった。業務運用 への影響は軽微なので,稼働後にプログラムを改修することを条件にHセンタ 長から了承を得た。これらは,申し送り事項として管理する(X課長)。 ・新システムを使用して業務運用を行った。新パッケージの新機能や関連システ ムとの連動処理など,全ての業務を問題なく実施することができた(Dリーダ)。 (4)利用者訓練の状況と評価(報告者:Dリーダ) ・コールセンタのオペレータの運用訓練を完了した。訓練のカリキュラムに従っ た業務運用を行い,参加者全員が一定の水準に達したことを確認した。 ・新システムの業務オペレーションマニュアルを整備した。 (5)移行計画(報告者:X課長) ・稼働開始前日の業務終了後,現行システムから新システムへ移行する。 ・稼働開始日の午前9時に,新システムのサービスを開始する。 ・移行作業に必要な時間は,十分に確保している。 ・新システムの稼働開始日に,現行システムの運用を停止する。 6)|b|の達成度確認(報告者:F部長) ・新システムの品質と性能,利用者の業務運用の習得度が,移行可能な基準に達 しており,移行作業の準備が十分であることを確認した。 [移行判定会議での指摘事項] 各担当リーダからの報告後,次の質疑応答があった。| G部長:新システムへの移行及び稼働開始時に,不測の事態が発生した場合の とその発動条件を定めていますか。 X課長:はい。F部長に承認していただいたものを,文書化して共有しています。 F部長:性能テストで,商品在庫管理システムはテスト環境を使用して実施しても ごig= 問題ないと判断した理由を説明してください。 X課長:商品在庫管理システムのテスト環境の構成を調べ,|d|であぁること を確認できたからです。 F部長:⑨新システムの稼働後に行うシステム関連作業を整理してください。 X課長:承知しました。引継ぎが必要な場合は,打合せを設定します。 E常務は,会議の報告内容と|.b|の達成度から,新システムの稼働までに 対応すべき残課題を解決することを条件に,新システムへの移行を承認した。 また,X課長は,F部長からの指摘を受けて,新システムが安定稼働していること を確認した後に実施すべきである| e ]の計画を集定することにした。そこで, 運用及び保守の組織だけでなく利用者も参加させて,この活動を開始した。

共通の文章

関する次の記述を読んで,設問1ー4に答えよ。 K社は,5年前に関西で創業した流通業の会社で,国内に本社と8か所の支店をも っている。K社の情報システム部は,受注機能と配送管理機能を備えた流通業務シス テムを開発し,流通業務サービスとして社内に提供している。K社の社員は,1人に 1台与えられたPCを使って流通業務サービスを利用している。 [サービスデスクの運用) 流通業務サービスの提供に当たって,情報システム部に所属する,本サービスに 精通した4人のメンバから成るサービスデスクを組織し,利用者からのインシデン トの解決依頼やサービス要求を受け付けた。K社では,ITサービスに対する計画外 の中断やITサービスの品質の低下をインシデントと定義している。一つ以上のイン シデントの根本原因を| 。|と呼び,“根本原因が特定されているか,若しく は回避策によってサービスへの影響を低減又は除去する方法がある|』|]"を [| b|と呼んでいる。 サービスデスクのメンバは,依頼内容や対応状況を,表計算ソフトを使って一つ のインシデント管理ファイルに記録していた。インシデント管理ファイルはファイ ルサーバにあって,メンバ全員で利用されていた。インシデント管理ファイルに更 新要求がある場合,表計算ソフトはファイルに対して排他ロックを施すアクセス制 御を行って,整合性を確保している。 ーつのインシデントに対するサービスデスクの対応が1回で終わらずに,利用者 が再度サービスデスクに問い合わせる場合がある。メンバが個別に問合せに対応し ていたので,最初に対応したメンバ名や日時を利用者がサービスデスクに伝える必 要があり,利用者から“組織として対応してほしい"との要求があった。 [マネジメントプロセス及びツールの整備〕 利用者からの要求を受けて,ITサービスマネージャである情報システム部のAK は“インシデント及びサービス要求管理プロセス”の整備と,プロセスを支援する ツールの整備を行った。 ー59一 整備された,インシデントに関する対応手順を表1に示す。 表1インシデントに関する対応手順 ・インシデントにはユニークなインシデント番号を割り当て,利用者に案内する。 デント管理ファイルを更新する。 ・利用者が対処すべき作業がある場合は,利用者に作業を依頼する。 ・回答内容などの記録を更新し,終了する。 注)対処手順書は,インシデントに対応して実施すべき解決処理の詳細が記載されている手順書の こと。対処手順書にはサービスへの影響を低減又は除去する方法を特定した場合に,対応手順が 記載される。 インシデント管理ファイルを用いたサービスデスク業務の運用には,次のような _不都合があった。 ・誰がいつファイルを更新したかの履歴管理ができない。 ・メンバが誤ってファイルを削除してしまった場合,直近のバックアップからデー タを復元する作業を行う必要があり,バックアップ時点以降の情報が失われる。 また,表計算ソフトのアクセス制御方式の制約から,①サービスデスク業務に支 障を来す事象が発生していたので,RDBMSを用いてインシデント管理を運用するよ うに変更した。 〔【インシデント事例) K社では,セキュリティパッチ(以下,パッチという)をPCに展開する場合,自 動で行う設定にしていた。ある日,“業務時間中にPCでパッチが自動的に展開され た。パッチの展開が完了するまでは,PCの応答が遅くなり業務に支障がある。"と いったインシデントが多くの利用者に発生した。対応を行ったサービスデスクのメ ー53一 ンバは,インシデント管理担当として,本インシデントに対して②ある作業を実施 することによって,インシデントを速やかに解決し,業務を再開させた。 また,別の利用者から“OSアップデートの終了後,流通業務サービスの一部の入 力画面が正常に利用できない。"”とのクレームを受けた。情報システム部で問題管理 を担当しているZ氏が,OSアップデートに関するインシデントの根本原因を究明す ることになった。当該PCの設定を調べたところ,パッチだけでなく,OSアップデ ートが0Sメーカから配信されたとき,自動的にこれを展開する設定となっていた。 そこで,直ちにこの設定を止めることとした。 さらに,Z氏が過去1年間に発生したOSアップデートに関わるインシデントの状 況を調査したところ,流通業務サービスの一部の機能が正常に利用できない事象が 数回あったことを確認できた。そこで,OSメーカからOSアップデートが配信され たときは,利用者のPCに展開する前に,情報システム部で③ある作業を実施するこ とをルールとして定めた。 問題管理担当の業務として,このように日頃から,発生するインシデントの内容 や状況を把握してインシデントの| c分析を行い。インシデントの発生を事 .前予防的に防止する活動が必要となる。 [マネジメントプロセスの改善 サービスデスクへの問合せには,流通業務サービスに関するものだけでなく,PC に関するものもあった。しかし,PCのハードウェア障害については,情報システム 部のPC担当要員が対応する規定となっており,サービスデスクは対応していなかっ た。そのため,PCのハードウェア障害でサービスデスクに問い合わせた利用者は, PC担当要員に連絡し直す必要があった。利用者からは,“内容に応じて連絡先を選 別しなければならないのは大変なので改善してほしい。”と情報システム部に要望が 挙がった。 そこでA氏は,窓口を一本化し,利用者からの全てのインシデントをサービスデ スクで受け付ける提案を情報システム部長に行った。提案の内容は,“サービスデス クは,流通業務サービスに関するインシデントについてはサービスデスク内部で対 応し,サービスデスクのメンバでは解決できないPCのハードウェア障害に関するイ ンシデントについては,サービスデスクで受け付けた後,| d|を行う。"とい ごBy os ったものである。この提案は情報システム部長によって承認され,利用者に通知さ れた後,実施されている。 また,情報システム部長は,管理項目を設けてサービスマネジメントの活動を管 理するようA氏に指示した。A氏は,“インシデント及びサービス要求管理プロセス" のCSF(重要成功要因)として“インシデントをできるだけ迅速に解決し,業務へ の影響を最小限にする。”を挙げ,③④このCSFに対応したKPI(重要業績評価指標) を設定して活動を管理することにした。

共通の文章

新会計システム導入に関する監査について,次の記述を読んで,設問1こ5に答えよ。 L社は,中堅の総合商社であり,子会社が6社ある。L社及び子会社6社は,長い 間,同じ会計システム(以下,旧会計システムという)を利用してきたが,ソフト ウェアパッケージをベースにした新会計とシステムに,2年掛かりで移行させる予定で ある。ただし,子会社のM社だけは,既に新会計システムを導入して3か月が経過 している。 L社の監査室は,Lt,ROM社を除く子会社5社が新会計システムの導入に着 手する前に,M社の新会計システムに関する運用状況のシステム監査を実施し,検 討すべき課題を洗い出すことにした。 〔予備調査の概要】 新会計システムについて,M社に対する予備調査で入手した情報は,次のとおり である。 1.伝票入力業務の特徴及び現状 旧会計システムでは,経理部員が手作業で起票し,経理課長の承認印を受けた後, 起票者が伝票入力して,仕訳データを生成していた。このため,手作業が多く,紙 の帳票も大量に作成されていた。 新会計システムでの伝票入力業務の特徴及び現状は,次のとおりである。 (1)新会計システムでは,経費の請求などは各部署で直接伝票を入力することに した。そのために,経理部は各部署に操作手順書を配布し,伝票入力業務説明 会を実施した。また,各部署で入力された伝票データ(以下,仮伝票データと いう)に対して各部署の上司が承認入力を行うことで仕訳データを生成し,請 求書などの証ひょう以外に紙は一切使用しないようにした。び①新会計システム に承認入力を追加することによって,旧会計システムにおいて不正防止のため に経理部が伝票入力後に実施していたコントロールは,不要となった。 (2)新会計システムでは,各利用者に対し,権限マスタで,伝票の種類(経費請 求伝票,支払依頼伝票,振替伝票など)ごとに入力権限と承認権限が付与される。 (3)経理部によると,“各部署で入力された仕訳データの消費税区分,交際費勘定 科目などに誤りが散見される”"ということであった。 ー58一 2.伝票入力業務の手続 新会計システムにおける伝票入力業務の手続は,MOLE)CHS, (1)担当者が入力すると伝票番号が自動採番され,仮伝票データとして登録され る。このとき,担当者は証ひょうに伝票番号を記入する。 (②)承認者が仮伝票データの内容を画面で確認し,適切であれば承認入力を行う。 (3)承認入力が済むと,仮伝票データから仕訳データが生成され,仮伝票データ は削除される。仕訳データには,仮伝票データの入力日と承認日が記録される。 (4)承認された伝票の証ひょうは,経理部に送られる。 (5)経理部は,各部署から送られてきた証ひょうを保管する。 3.仕入販売システムとのインタフェース M社は,大量の仕入・販売取引を仕入販売システムで処理している。旧会計シス テムでは,仕入販売システムから出力した月次集計リストに基づいて,経理部が手 作業で伝票入力をしていた。これに対し,新会計システム導入後は,夜間バッチ処 理で仕入販売システムから会計連携データを生成した後に,経理部員が新会計シス テムへの“取込処理”を実行するように改良した。 (1)会計連携データは,システム部が日次の夜間バッチ処理で生成している。会 _計連携データには,必須項目の他に,各子会社が必要に応じて設定した任意項 目が含まれている。これらの項目は仕訳データに引き継がれ,新会計システム の情報として利用される。 2)夜間バッチ処理の翌朝,経理部員が取込処理を実行することで,会計連携デ ータが新会計システムに取り込まれる。 (3)経理部によると,“新会計システム導入当初には,取込処理の漏れ,及びエラ 一発生などによる未完了が発生していた。また,夜間バッチ処理のトラブルで 会計連携データが生成されず,前日と同じ会計連携データを取り込んでしまっ たこともある"ということであった。この対策として,経理部では,当月から 取込処理の実施前と実施後に追加の手続を実施することにした。 4.管理資料 新会計システムでは,各部署の利用者が自ら分析ツールを利用して仕訳データの 抽出・集計が可能であることから,効果的な管理資料が作成でき,各部署での会計 情報の利用増加が期待されていた。しかし,一部の利用者からは,“新会計システム ー59一 -では仕入・販売取引に関する情報が不足しており,必要な分析ができない"という 意見があった。 【本調査の計画) L社の監査室では,予備調査の情報に基づいて監査項目を検討し,本調査の監査手 続を表1にまとめた。 Rl本調査の監査手続(抜粋) |の各部署の承認者が伝票の正確性をどのように確認しているか, 複数の承認者に質問する。 ②各部署で直接伝票を入力することから,各部署の承認者が伝票 Fnの正確性についてチェックできるように,適切な内容の on aie[a]ativsnnmes menos, ⑨仕訳データの仮伝票データの入力日と承認日の比較,及び |5 joと監査実施日の比較を行って,承認 入力の適時性について分析する。 。|伝時入力業務の不正が|〇職務分離の観点から,RBA(a|が設定されていな 防止されているか。いことを確かめる。 ,|処理が條のに実生|のa Lara)IAD oe 前にの結をチ¥クしているかどうかを されているか。° Qumeéic[f|をチェックしているかどうかを確かめる。 |効果的な管理資料が作1①設計時にについて適切に検討していたかどうかを 成されているか。確かめる。