システム監査
この章では下記を押さえておいていただくと、役に立つと思います。
・システム監査
システム監査は情報システムやそれに関連する業務を、情報システム部門の関係者とは独立した立場にある第三者が、総合的に検証・評価し、情報システムの改善のための助言や勧告を行うことです。
・システム管理
システム管理とは、経営戦略に沿って効果的な情報システム戦略を立案し,その戦略に基づき,効果的な情報システム投資のための,またリスクを低減するためのコントロールを適切に整備・運用することをいいます。またそのための項目を取りまとめたものをシステム管理基準といい、経済産業省によって策定されています。
・システム設計
システム設計とは、システム開発の中の一つの工程です。システムの構成やデータ項目などを設計します。
・システムテスト
システムテストは、システム全体が正常に機能するかをテストします。また、システム要件定義で定められた機能や処理時間などの要件が満たされているかのテストを行います。
・システム監査は情報システムやそれに関連する業務を、情報システム部門の関係者とは独立した立場にある第三者が、総合的に検証・評価し、情報システムの改善のための助言や勧告を行うことです。
・内部統制とは、業務の有効性及び効率性、財務報告の信頼性、事業活動に関わる法令等の遵守、資産の保全の4つの目的を達成していくための体制を自ら構築し、運用していくための仕組み(マネジメントシステム)です。つまりは、仕事を正しく運営する為の仕組みのことです。
内部統制の基本要素には以下の6つの要素があります。
・統制環境:組織の目標や行動規範などを明確にし周知することで、統制に対する組織内の意識を高めます。
・リスクの評価と対応:組織の目標達成に影響を与えるリスクを識別し、分析・評価します。
・統制活動:内部統制に関する指示が適切に実行されるよう定める方針や手続きを決定します。
・情報と伝達:組織内外の関係者に、情報が正しく伝達される環境を整備します。
・モニタリング:内部統制が正しく機能しているかを評価します。
・ITへの対応:業務の実施に必要な情報システムを適切に取り入れます。
・システム監査は情報システムやそれに関連する業務を、情報システム部門の関係者とは独立した立場にある第三者が、総合的に検証・評価し、情報システムの改善のための助言や勧告を行うことです。
・システム監査は、情報システムについて検証・評価するものですから、情報システムを使っていない業務は監査の対象外となります。また、監査は、一般企業や官公庁などすべての企業が対象になります。
マネジメント~プロジェクトマネジメント~
こちらも目を通していただくといいかと思います。
プロジェクトマネジメントのガイドラインであるPMBOK(Project Management Body of Knowledge:ピンボック)では、プロジェクトの制約条件について、プロジェクト・スコープ、タイム、コストの3つをあげています。プロジェクトマネージャは、これらの3つの制約条件のバランスをうまく保ちながら、プロジェクトを進めていかなければなりません。
この3つの条件に加えて、プロジェクトの成果物の「品質」をマネジメントすることがプロジェクトマネージャの役割です。
一般的に、コストと時間をかければ品質は向上します。しかし、プロジェクトを遂行するにあたり、予算の関係でコストをかけられなかったり、納期の関係で時間をかけられなかったりします。品質は出来るだけ良くしたいが、他の制約条件のためにそれができないということです。コスト、時間、品質はそれぞれがお互いに関連しています。
したがって、プロジェクトごとにコストや時間、求められる品質は異なりますので、これらの条件をバランスよく組合せてプロジェクトを推進していくことが必要となります。
プロジェクトとは、ある目的や目標を達成するために遂行される一時的な活動や計画のことをいいます。別の言い方をすれば、独自の成果物、またはサービスを作り出すための期限のある活動ということになります。またプロジェクトマネジメントのガイドラインであるPMBOK(Project Management Body of Knowledge:ピンボック)の定義では「プロジェクトとは、独自の製品、サービス、所産を創造するために実施される有期性の業務である。」とされています。有期性とは期間が決まっているという意味ですから、プロジェクトには明確な開始点と終了点があるということです。
"PERT(Program Evaluation and Review Technique)"
→作業の順序関係を表現するための図で、作業工程の管理などに使用されます。
"WBS(Work Breakdown Structure)"
→プロジェクトマネジメントにおける計画フェーズで使用する手法で、プロジェクトで行う作業や成果物を細かく分割し、階層化された図に表すことで、プロジェクト全体の作業や成果物の関係を把握していくという手法です。
"構造化プログラミング"
→繰返し処理、分岐処理などの基本的な制御構造を用い、プログラムを細かな単位に分割して記述していく技法です。
"ファンクションポイント法"
→ソフトウェアの規模を見積もる手法で、ソフトウェアの持つ機能の数を定量的に算出し、ソフトウェアの規模を見積もります。
マネジメント~ソフトウエア開発管理技術~
こちらも覚えておくといいかと思います。
国際規格であるISO/IEC 12207のシステム開発プロセスは、以下のように実行されていきます。
1.システム要件定義:システムの対象範囲を決定し、必要な機能や能力、運用方法を決定します。
2.システム方式設計:システムを構成するハードウェアやソフトウェア構成、手作業で行う項目、関係する外部システムを具体的に検討します。
3.ソフトウェア要件定義:システム方式設計に基づいて、ソフトウェアの利用者から見える部分(画面やデータ項目など)を定義します。
4.ソフトウェア方式設計:ソフトウェア要件定義に基づいて、ソフトウェアの構成要素を定義します。
5.ソフトウェア詳細設計:ソフトウェア方式設計に基づき、プログラムの内部構造を設計します。
6.コーディング・テスト:ソフトウェアのプログラミングと単体テストが実施されます。
一般的なシステム開発プロジェクトでは、ソフトウェアライフサイクルプロセス(SLCP:Software Life Cycle Process)を考慮して作業が進められます。ソフトウェアライフサイクルプロセスとは、企画、要件定義、開発、運用、保守のそれぞれのプロセスについて、各プロセスで行うべきことをまとめたガイドラインです。
●企画プロセス:
経営事業の目的、目標を達成するために必要なシステムの機能をまとめシステム化構想を立案し、各システムの開発順序や概算コスト、費用対効果やリスク、納期などを分析して、システムを実現するための計画である、システム化計画を立案します。
●要件定義プロセス:
利用者のニーズを把握し、システムが満たすべき性能や、機能などを明確にし、業務要件を定義します。コストや運用の面から実現可能であるかの検討も行います。また、それらの内容について利害関係者間で合意します。ユーザインターフェイスやデータ項目についてもこのプロセスで決定します。
●開発プロセス:
システムに必要なソフトウェアの要件を定義し、それらのソフトウェアの開発を行います。システム要件定義,システム方式設計,ソフトウェア要件定義,ソフトウェア方式設計,ソフトウェア詳細設計,コーディング,テスト,システム結合,ソフトウェア導入,ソフトウェア受入れ支援などの作業が行われます。
●運用プロセス:
開発したシステムを実環境でシステムを運用します。運用テスト,システム移行,システム運用および評価などの作業が行われます。
●保守プロセス:
ソフトウェア欠陥の改善や性能改善など、システム納入後にソフトウェアを修正する作業を実施します。
マネジメント~システム開発技術~
こちらも一緒に覚えておくといいかと思います。
一般的に、システムの開発は次のような流れで作業が行われます。
要件定義 → システム設計 → プログラミング → テスト
この中の行程で、システム設計はさらに下記のように細かく分類できます。
外部設計 → 内部設計 → プログラム設計
各工程で行う作業は主に下記の通りとなります。
・要件定義:顧客が求めているシステムの目標と範囲、機能、性能、業務処理手順などの要件を決めます。
・外部設計(システム設計):システムを機能ごとのサブシステムに分けたり、画面やハードウェア・ネットワーク構成を決めたりなど、利用者から見た業務機能を中心に設計を行います。
・内部設計(システム設計):外部設計に基づいて、それをコンピュータ上でどのように実現するかを決めます。ソフトウェア内部の仕組み、データ構造・管理方法、アルゴリズムなどを開発者の視点で設計します。
・プログラミング:実際にプログラミング言語などを用いてプログラムを作成します。
・テスト:作成したプログラムの機能を検査し、システムの動作確認を行います。
ソフトウェア保守とは、運用が始まったシステムの機能改善、不具合の修正、使用環境の変化に対応するためのプログラム改修などを行うことです。保守の目的により、次のように分類できます。
・適応保守: 使用環境の変化に適応するためにソフトウェアの修正を行います。
・修正保守: ソフトウェアの不具合の修正を行います。
・予防保守: ソフトウェアの潜在的な不具合を検出し修正を行います。
ソフトウェア品質の評価に関する国際規格である「ISO 9126」において、ソフトウェアの品質特性を以下のようにまとめています。
●機能性:必要な機能が期待通りに実装されているかの度合いを表す特性です。
●信頼性:障害が発生する頻度や回復能力がどの程度あるかを表す特性です。
●使用性:ソフトウェアの使いやすさに関する特性です。
●効率性:ソフトウェアの処理能力や資源の有効利用に関する特性です。
●保守性:ソフトウェアの修正のしやすさに関する特性です。
●移植性:別の環境へのソフトウェアの移しやすさに関する特性です。
システム開発における開発プロセスの成熟度を5段階のレベルで定義したモデルをCMMI(Capability Maturity Model Integration)といいます。
CMMIは、組織が開発プロセスを適切に管理するための指針となります。
レベル1:プロセスが確立しておらず、無秩序な状態(初期)
レベル2:基本的なプロセスが備わっている状態(管理された)
レベル3:標準化されたプロセスが備わっている状態(定義された)
レベル4:プロセスの効率などを評価できる状態(定量的に管理された)
レベル5:定期的なプロセスの改善が実施され最適化されている状態(最適化している)
コンピュータシステムの品質などを評価する指標の一つにRASIS(レイシス)があります。RASISは、システムの評価指数を意味する5 つの英単語の頭文字をつなげた略語です。
・R (Reliability) 信頼性:故障や不具合が発生せずに、安定して稼働し続けられることを表します。
・A (Avalability) 可用性:サービス時間中に実際にサービスをどれくらい利用できるかを表します。
・S (Serviceability) 保守性:メンテナンスや障害からの復旧のしやすさを表します。
・I (Integrity) 完全性:情報が正しい状態を保っていられるかを表します。
・S (Security) 機密性:許可された利用者だけがシステムを使用できることを表します。
これらの指標を用いてシステムの能力や品質を表すことが一般的に行われています。設問では、上記に加えて「性能」もシステムの評価指標に加えています。
ストラテジ~システム戦略~
こちらも一緒に覚えておくといいかと思います。
RFI(Request For Information:情報提供依頼書)
システムの導入や業務委託を行う際に、発注先の候補であるベンダ企業に対して情報提供を依頼するための文書です。発注元企業はRFIの返答をもとにRFPを作成します。
RFP(Request For Proposal:提案依頼書)
システムの導入や業務委託を行う際に、システムの発注元の企業が作成し、開発ベンダに対して提出される文書で、システムの概要や調達条件等を明示し、開発ベンダにシステムの提案や検討を依頼するための文書です。
NDA
→NDA(Non-Disclosure Agreement:秘密保持契約)とは、自社の機密情報を外部の取引先などに提示する際に、その情報を特定の目的以外で使用したり、第3者に漏洩したりすることがないよう、事前に約束をする契約のことです。
RFI
→RFI(Request For Information:情報提供依頼)とは、システムの導入や業務委託を行う際に、発注先の候補であるベンダ企業に対して情報提供を依頼するための文書です。発注元企業はRFIの返答をもとにRFPを作成します。
SLA
→SLA(Service Level Agreement:サービスレベル契約)とは、サービスの提供者が自社のサービスの品質を保証するための文書で、サービス提供者とその利用者との間で交わされる契約です。サービスの内容と提供範囲、品質水準、課金内容、提供時間帯とそれを達成できなかった場合の取り決めなどが記載されます。
ストラテジ~システム戦略~
こちらも一緒に覚えていただくといいかと思います。
一般的なシステム開発プロジェクトでは、ソフトウェアライフサイクルプロセス(SLCP:Software Life Cycle Process)を考慮して作業が進められます。ソフトウェアライフサイクルプロセスとは、企画、要件定義、開発、運用、保守のそれぞれのプロセスについて、各プロセスで行うべきことをまとめたガイドラインです。
・企画プロセス:
経営事業の目的、目標を達成するために必要なシステムの機能をまとめシステム化構想を立案し、各システムの開発順序や概算コスト、費用対効果やリスク、納期などを分析して、システムを実現するための計画である、システム化計画を立案します。
・要件定義プロセス:
利用者のニーズを把握し、システムが満たすべき性能や、機能などを明確にし、業務要件を定義します。コストや運用の面から実現可能であるかの検討も行います。また、それらの内容について利害関係者間で合意します。ユーザインターフェイスやデータ項目についてもこのプロセスで決定します。
・開発プロセス:
システムに必要なソフトウェアの要件を定義し、それらのソフトウェアの開発を行います。システム要件定義,システム方式設計,ソフトウェア要件定義,ソフトウェア方式設計,ソフトウェア詳細設計,コーディング,テスト,システム結合,ソフトウェア導入,ソフトウェア受入れ支援などの作業が行われます。
・運用プロセス:
開発したシステムを実環境でシステムを運用します。運用テスト,システム移行,システム運用および評価などの作業が行われます。
・保守プロセス:
ソフトウェア欠陥の改善や性能改善など、システム納入後にソフトウェアを修正する作業を実施します。
システム化計画の立案は企画プロセスで行う作業で、
・対象業務の分析と業務機能のモデル化
・全体のスケジュールの作成
・システム導入の費用対効果の分析
・システム導入のリスクの分析
・品質に対する基本方針の明確化
などが行われます。
・BPR
BPR(Business Process Reengineering)とは、業務効率や生産性を上げるために、仕事の流れややり方だけではなく、組織の構造や管理体制等も抜本的に見直して、再構築することです。
・ERP
ERP(Enterprise Resource Planning)とは、企業活動の中で発生する経営資源を、一元化して管理し、迅速に利用することで経営の効率化を図る経営手法です。
・RFP
RFP(Request For Proposal:提案依頼書)とは、システムの導入や業務委託を行う際に、システムの発注元の企業が作成し、開発ベンダに対して提出される文書で、システムの概要や調達条件等を明示し、開発ベンダにシステムの提案や検討を依頼するための文書です。RFPを受け取った開発ベンダは、RFPに基づいてシステム内容を検討し、作成した提案書を発注元の企業へと提出します。
・SLA
SLA(Service Level Agreement:サービスレベル契約)とは、サービスの提供者が自社のサービスの品質を保証するための文書で、サービス提供者とその利用者との間で交わされる契約です。
サービスの内容と提供範囲、品質水準、課金内容、提供時間帯とそれを達成できなかった場合の取り決めなどが記載されます。
・SaaS
SaaS(Software as a Service)とは、サービス提供事業者がインターネット経由で業務ソフトウェアの一部の機能を提供するサービスです。インターネットを使える環境であれば、利用する場所を意識することなく、それらのサービスを利用することができます。クラウドコンピューティング環境で提供されるサービスの一つです。
・エスクロー
エスクロー(escrow)とは、主にインターネットでの商品売買などにおいて、「売り手」と「買い手」の間に入り、安全な取引を保証する仲介サービスのことです。買い手は商品代金を一旦、エスクローを提供する事業者(エスクローサービス事業者)に預け、その後売り手は商品を買い手に発送し、買い手が商品到着・確認した後、エスクローサービス事業者が代金を売り手に送金する、というような仕組みになっています。
・システムインテグレーション
システムインテグレーション(System Integration)とは、システムの企画、開発、運用、保守などの一連の作業を一括して請け負う事業またはサービスです。
・ハウジング
ハウジングサービス(housing service)とは、サービス提供事業者が自社の通信設備の整っている敷地内に利用者の通信機器やサーバなどの機材を設置して運用・管理するサービスです。