現在位置:
Top/シスアド学習メモ/基幹業務システム
[[シスアド学習メモ]]
基幹業務システムとの関わり
*基幹業務システムとの関わり
■基幹業務
・基幹業務は、企業全体としての目的を実現するための業務活動。活動内容によって次の2つに分類される。
①直接的業務活動:企業の目的を直接実現するための業務活動。製造業における購買、生産、販売活動など。直接的業務活動を行う部門を直接部門という。
②間接的業務活動:直接部門の活動を支援・管理する業務活動。会計、人事、研究開発など。間接的業務活動を行う部門を間接部門という。
■基幹業務システム
・基幹業務システムは、基幹業務をコンピュータを中心にシステム化したもの。業務の効率化や、意思決定の支援などを目的に構築される。
※このようなコンピュータを利用した意思決定支援システムをDSS(Decision Support System)という。
・一般に基幹業務システムは次のような特徴を備えている。
①定型業務のシステム化:基幹業務システムは、一般に定型業務のシステム化を目的として構築される。
②データの共用管理・セキュリティ管理:基幹業務システムは複数部門で共用されるため、データの共用管理や、機密情報のセキュリティ管理が必要となる。
③情報システム部門の設置:基幹業務システムの開発・維持には、専門の技術者によって構成される情報システム部門を設置することが多い。
※最近では、情報システム部門を外部委託するアウトソーシングが増加しつつある。
・基幹業務システムに対して、特定部門の固有業務や非定型業務を処理するシステムを部門内業務システム(エンドユーザーシステム)という。
・部門内業務システムはエンドユーザー(利用者)が主体となって開発・維持される。ただしシステムに関する全社ルールがある場合は、これに準拠しなければならない。
■基幹業務システムの開発
・基幹業務システムの開発は、一般に情報システム部門または専門の外部委託業者によって行なわれる。
・主な開発方法には、ウォータフォールモデル、プロトタイピング、スパイラルモデルなどがある。
■ウォータフォールモデル
・ウォータフォールモデルは、もっと一般的なシステムの開発方法。システムの計画・設計から最終的なテストまで、一方向に滝(ウォータフォール)が流れるように進むことからこの名称が付けられた。
・ウォータフォールモデルでは、各工程が完全に終了しなければ次の工程に進まない。また各工程の最終過程では、工程が開発要件を満たして確実に終了したことを確認するためのレビューが実施される。
<ウォータフォールモデルの開発工程>
◇基本計画 システムに対するユーザの要求(ユーザ要件)をまとめ、システムの開発スケジュールを計画する。
◇外部設計 ユーザ要件に基づきシステムの機能を確定し、画面や帳簿などの設計を行う。
◇内部設計 システムの機能をプログラムに分割し、プログラム間の処理の流れを決める。
◇プログラム設計 プログラムの内部構造を設計し、モジュールに分割する。
◇プログラミング モジュールの処理手順を設計し、プログラム言語で記述する(これをコーディングという)。
◇テスト 製作した各プログラムおよびシステム全体のテストを行う。
■プロトタイピング
・プロトタイピングは、開発の初期段階でプロトタイプ(試作品)を作成し、ユーザーに対して画面や操作性などのユーザーインタフェース部分を確認しながら開発を進める方法。
・開発期間・コストが短縮削減できるが、「試作品の作成→ユーザ確認」が繰り返し行なわれるため開発工程の管理が難しい。
・比較的小規模なシステムの開発に適する。
■スパイラルモデル
・スパイラルモデルは、ウォータフォールモデルとプロトタイピングを折衷した方法。
・開発の初期の段階で独立性の高い小さなモジュールを作成・テストし、これを徐々に拡張する形でシステムを開発する。
・開発工程の流れが渦巻き(スパイラル)に似ていることから、スパイラルモデルと呼ばれる。
※プロトタイピングやスパイラルモデルのように、システムの設計段階からユーザが主導的な立場で関わるシステム開発技法をJAD(Joint Applocation Design)という。
■ファンクションポイント法
・システム開発のコスト見積もりは、従来ステップ数(プログラムの行数)基準に行われてきた。これに対してシステムに要求される機能(ファンクション)を基準に見積もりを行う方法をファンクションポイント法という。
・ファンクションポイント法が採用されるようになった背景には、GUIによる画面開発の増加やオブジェクト指向によるプログラム部品を利用した開発手順の普及などがある。
■システム開発工程におけるシステムアドミニストレータの役割
・システム開発工程ではシステムアドミニストレータはエンドユーザの代表として次のような役割を担う。
①システム要件の取りまとめと提言
システム計画段階でエンドユーザのシステム要件(機能、性能、操作性などへの要望)を取りまとめ、開発者に伝える。
②システムの完成度の確認
システム開発過程で各種テストに参加し、システム要件が実現されているかどうかを確認する。
③システムテストへの参加
システムのテストにエンドユーザの代表として参加し、システム要件が実現されているかどうかを確認する。
■レグレッションテストと負荷テスト
・システムアドミニストレータが参加する代表的なテストとして、レグレッションテストと負荷テストがある。
①レグレッションテスト(退行テスト)
機能テストの一つ。システムの修正や機能追加などを行った際に、他の部分に影響が及んで新たなる問題が発生していないかどうかを確認するテスト。
②負荷テスト(ラッシュテスト)
システムに量的な負荷を与えて、これに耐えられるかどうかを確認するテスト。負荷には、データ量、同時利用者数、稼動時間などがある。
■テスト結果の検収
・テスト結果がテスト仕様書に基づくすべてのテスト項目を満たしている場合、テストを終了し検収(発注者がシステムの完成を承認すること)となる。
・テストと検収が終了すると、次にシステムの導入・運用のための準備を行う。主な作業は、データの移行、運用マニュアルの作成・整備、ユーザ教育などである。
■信頼度成長曲線(ゴンペルツ曲線)
・信頼度成長曲線は、システムの品質を評価する方法の一つ。予測したエラー数が実際にいくつ発見されたかによってシステムの信頼性を把握する。
・テスト時間を横軸、発見したエラーの累積数を縦軸としてグラフに描く。曲線がS字型であれば、テストは順調であると判断される。S字型にあてはまらない場合は、テストの実施が不適切であると判断される。
■稼働率
・稼働率は、システムの品質を評価する方法の一つ。テスト時にシステムが無故障で稼動している時間の割合からシステムの信頼性を把握する。一般的に次のいずれかの計算式で求められる。
①稼働率=(全運転時間-故障時間)/全運転時間
②稼働率=MTBF/(MTBF+MTTR)
※MTBF(平均故障間隔):故障が回復してから次の故障が生じるまでの平均時間。
※MTTR(平均修復時間):故障が発生してから修復するまでに要する平均時間。
■複数装置で構成されるシステムの信頼度
・複数装置が直列、並列に接続されている場合のシステム全体の信頼度は次の計算式によって計算される。
①機器が直列に接続されたシステムの信頼度
信頼度=a1*a2
②機器が並列接続されたシステムの信頼度
信頼度=1-(1-a1)*(1-a2)
