あらけす屋＞情報処理技術者試験
午前問題対策（システム開発）
システム化計画/評価指標
システム化計画
- 全体計画
- 全体計画立案
- 業務モデルと必要な情報システム体系モデルの定義
- 情報システム開発課題の分析
- 情報システム開発の必要度の分析
- システム開発上で予想される阻害要因の分析
- 中長期情報システム化計画の立案
- 経営戦略、情報戦略からの情報サブシステム開発の優先順位
- 情報システム基盤の整備計画
- 組織体制
- 情報システムの開発と運用計画
- 開発スケジュール
- 情報システムの効果と費用
- 計画の評価・承認
- 全体計画立案の体制
- 経営トップ（CIO）の参加を得る
- トップダウン体制
部門目標や部門利益よりも全社的経営目標や経営戦略を反映させる
- 全体計画の評価
- 開発投資への合目的性、有効性、投資効果、技術水準の先進性、技術標準の整合性などを評価する
- CIOが中心となりトップマネジメントと内部管理者にフィードバックする
- 評価項目
- 経営戦略に対する合目的性
- 実現可能性（制約要因）
- 開発の合理性・妥当性
- 運用の容易性
- 技術的整合性
- 立案するときに考慮すべき事項
-
情報システムの有効性及び投資効果を明確にする
- 業務プロセスの改善では関係者全てが合意するわけではないが、企業全体としての判断に基づいて進める
- 重要な経営課題に直結したシステムには、高い開発優先順位を与える
- 情報システムの中長期計画の構成要素
経営戦略や事業戦略遂行に対する貢献効果、情報基盤や情報システム開発・運用に関わる経営資源の継承発展に対する貢献効果などに基づいて優先順位を決定する
- 経営戦略に基づく情報戦略の骨子
- あるべき業務モデル、情報システムの概要
- 情報システム基盤の整備計画
- 情報システムの集中化・分散化の検討
- データベース
- 情報機器
- ネットワーク
- 情報システムの開発・運用計画（スケジュールなど）
経営戦略に対する時期的対応の貢献度、BPRに対応する貢献度、他のシステムとの整合性などに基づいて開発順序を決定する
- 開発・運用方針
- 開発・運用の組織体制
- 開発・運用による効果と費用回収計画
- 個別システムの開発計画
- 全体計画内容の確認
- システム化の目的・範囲の定義
- 主要機能の定義
- システム概要の設計
- 開発推進体制の立案
- 業務・組織変革の推進事項の明確化
- 開発スケジュールの作成
- 費用対効果の分析
- 開発計画書の作成
- 開発計画書の評価
- トップマネジメントの承認
- モデル化
- 業務モデル
- 企業活動を全社的に分析し、企業が遂行すべき業務を定義してその相互関係を明らかにし、企業活動とその活動に必要な情報、その情報の持ち方を構造化したもので、企業のあり方を論理的にモデル化する
-
企業の主要活動分野ごとに、本来あるべき業務機能を明確化したもの
- 業務モデル作成の目的
- 達成すべき経営課題と関係する業務の関連を把握する
-
現状の業務機能の問題点を抽出する
- 業務と情報サブシステムの整合性を図る
- 業務モデル策定手順
- ビジネスプロセスの定義
- データクラスの定義
- ビジネスプロセスとデータクラスの関連づけ
- 策定される業務モデル
ビジネスプロセスとデータクラスを関連付ける
- 論理モデル
業務のあるべき姿を現すために経営目標の達成に必要な業務機能を定義し体系化する
- 論理データモデル作成
最終的な論理データモデルは、正規化され、かつすべての属性を備えていなければならない
- 新システムのモデル化を行う場合のDFD作成の手順
現物理モデル → 現論理モデル → 新論理モデル → 新物理モデル
- システム分析の段階で、現行物理モデルを基に現行論理モデルを作成するときには重複した機能を統合する
- 情報システムの全体計画立案のためにE-Rモデルを採用して全社のデータモデルを作成する場合の手順
- 企業の全体像を把握するため、基本的なエンティティだけを抽出
- それらの相互間のリレーションを含めて、鳥瞰図を作成
- エンティティを詳細化し、すべてのリレーションを明確にしたものを全社のデータモデルとする
- システム分析時の業務プロセスモデルの適切な定義方法
実在する組織や現実の業務にとらわれることなく、必要な業務プロセスを定義する
- リスク分析
経営資源に損失をもたらすリスクが情報システムのどこに、どのように潜在しているのかを発見・確認し、その影響の大きさを測定する
- リスク…脅威が情報資産のぜい弱性を利用して、情報資産への損失または損害を与える可能性のこと
- 脅威：情報資産に対して、悪影響を与える要因
- 脆弱性：情報資産が持っているセキュリティ上の弱い部分
- リスクの分類
- 投機的リスク
利益と損失の両方をもたらす可能性のあるリスク
- 純粋リスク
損失だけをもたらす可能性のあるリスク
- リスクのタイプ
- リスク分析
-
現実に発生すれば損失をもたらすリスクが、情報システムのどこに、どのように潜在しているかを識別し、その影響の大きさを測定する
-
セキュリティレビュー、リスク分析、セキュリティ対策の計画策定、セキュリティ対策の実施のプロセスにおいて、リスク分析で得られる結果：損失の大きさと発生頻度
-
リスクの発見・確認とそれがもたらす損失を算出する
- 予想損失額には、直接損失、業務継続、復旧費用の他に、逸失利益などの間接損失も含める
- 手順
- リスクの識別（リスクの選定）
- リスクの評価
- リスクの対応策の策定
- リスク処理
- 手順（情報システムのリスク分析）
- 分析対象の理解と分析計画
- 脆弱性の発見と識別
- 事故態様の関連分析と損失額予想
- 損失の分類と影響度の評価
- 対策の検討・評価と優先順位の決定
- リスク管理（リスクマネジメント）
考えられる全てのリスクに対応することは、時間と費用がかかりすぎるので、そのリスクが発生したときの損失額と発生確率を予想し、その大きさの順に優先順位をつける
情報システムの機能特性を損なう不安定要因やシステムに内在する脆弱性を識別して、企業活動に生じる損失を防止、軽減するとともに、合理的なコストでの対策を行う
- リスクコントロール
- リスク回避
- 損失予防
- 損失軽減
火災に対して、コンピュータ室に消火設備を設置する
- リスク分離
- リスク移転
- リスク受容
- リスクファイナンス
リスクが顕在化して生じる損失に備えて、経済面の対策を講じる手段
- リスク対策
- 予防的対策
- 防止的対策
リスクを発見し被害を軽減するための対策
- 事後的対策
発生後の次善策
- リスク管理体制
リスク対策の実施は、権限と機能をもつ各部門にゆだね、全体管理は経営層に直結したリスク管理部門が行う
- 可用性が損なわれることで発生する直接的損失
システムが復旧するまでの間、代替の手段にかかる費用
- 災害対策（コンティンジェンシープラン）
- バックアップテープ
バックアップ対象の装置の破損と同時に破損しないように、別の場所に保管する
- コンティンジェンシープランにおける留意点
企業のすべてのシステムを対象とするのではなく、システムの重要度と対策コストを勘案して決定する
- 情報システムの災害時対応計画の策定における留意点
災害対応計画はリスク分析の結果に基づいて策定し、組織体の長が承認する
- 顧客管理システム、受発注管理システム及びコールセンタシステムをそれぞれ別の拠点で稼働させ、これらをネットワークで接続し、障害時には相互に補完する
運用はそれぞれの拠点で実施する
- コンピュータセンタ
障害復旧までの見込み時間の長さによって、いくつかの対応方法を盛り込んだコンティンジェンシープランを策定する
- システム開発を外部に委託する場合の配慮すべき事項
開発の進捗状況を自社でも把握することで、問題点を早期に発見して対処する
- プロジェクトマネージャがプロジェクト計画を策定する際の留意事項
システム化計画書の内容を自己の責任において十分に確認し、問題点が見つかった場合は、上位の管理者に報告し調整する
- SOA(Service Oriented Architecture)
ユーザに提供するサービスの集まりとして、システムを構築する考え方
評価指標
- 情報システムの評価指標
- 信頼性
情報システムの品質並びに障害の発生、影響範囲及び回復の度合い
- 安全性
情報システムの自然災害、不正アクセス及び破壊行為からの保護の度合い
- 効率性
情報システム資源の活用及び費用対効果の度合い
- システム企画段階の評価指標
- 有効性
- 採算性
- 信頼性（安全性、セキュリティ）
- 生産性
- 準拠性
- 機密性
- 適時性
- 柔軟性
- システムの処理性能評価
- ギブソンミックス
CPUが科学技術に使われたときの処理能力を示す指標
- コマーシャルミックス
CPUが事務計算に使われたときの処理速度を示す指標
- ベンチマーク
-
コンピュータシステムの評価法の一つ
- 使用目的に合わせて選定した標準的な（典型的な）プログラムを実行させ、入出力や制御プログラムを含めたシステムの総合的な処理性能の評価を行う
- 性能評価のための複数種類のベンチマークテストを実行することは、システム性能の特徴を理解することができるので、導入機種の選定に有効である
- TPC (Transaction Processing Performance Council)
トランザクションシステムの性能評価用ベンチマーク
- TPC-A
単純なオンライントランザクション処理
現在は、現状に合致しなくなったためベンチマーク結果の公表が禁止されている
- TPC-B
単純なデータベース処理
現在は、現状に合致しなくなったためベンチマーク結果の公表が禁止されている
- TPC-C
複雑なオンライントランザクション処理
端末、ネットワーク、ソフトウェアなども含んだ、システム全体としての性能を評価する
トランザクション処理やデータベースに関する性能評価用ベンチマークモデルで、現在の受発注トランザクション処理に近い環境におけるOLTPシステムの評価用に使われる
- TPC-D
意志決定支援処理
TPC-HとTPC-Rに分化
- TPC-H
特定状況下の意志決定支援処理（アドホック処理）
- TPC-R
特定状況下の意志決定支援処理（レポーティング処理）
- TPC-W
Webベースのeコマース処理
- TPC-App
アプリケーションサーバ、及びウェブサービスの性能評価
- Dhrystone/MIPS
CPUやコンパイラの性能を評価
- Linpack
浮動小数点演算中心のベンチマークテスト
- SPECint
整数演算性能の評価
- SPEC-fp
浮動小数点演算性能の評価
- ソフトウェアプロセス評価 ( SPA ； Software Process Assesment
)
- プロセス習熟度モデル/プロセス成熟度モデル(CMM：Capability Maturity
Model / CMMI：Capability Manturity Model Integration)
W.ハンフリーが提唱
会社や組織、プロジェクトなどのソフトウェア開発能力や習熟度を客観的に示す品質評価基準
プロジェクトやソフトウェア開発工程を評価・改善するのに用いられる
- レベル１（初期）：プロセスが確立されていない
- レベル２（反復可能）：特定のプロジェクトリーダーや技術者に依存している
- レベル３（定義）：首尾一貫したプロセスを標準として持っている
システム開発の経験が組織として共有され、標準プロセスが確立している
- レベル４（管理）：標準化されたプロセスを定量的に測定し、洗練化していく
プロセスの実績が定量的に予測可能である
- レベル５（最適化）：技術、要件環境の違いによって、標準プロセスを最適化して用いられる、プロセスそれ自体を改善していくための仕組みが規定されている