共通フレームの概要
共通フレームの目的
共通フレームとは、情報システムの企画から開発、運用、保守、廃棄にいたるライフサイクルにおいて、それらの各プロセスを明確にすることにより、関係者が「共通の言葉」で話すための「共通のものさし」を定義したものです。
関係者の間で用語や概念が異なることがトラブルの原因になることがあります。
たとえば「保守」という用語を、受注者は、納入した情報システムのエラーを修正することだと限定しているのに対して、発注者は、業務の変化に対応することまでも含むと解釈しているとします。無料保守期間に後者による保守が生じたとき、発注者は無料で対処することを要求するでしょうし、受注者は費用を要求するでしょう。
このようなトラブルを回避するためには、用語や概念を明確に定義し、双方が共通認識することが必要です。共通フレームでは、各プロセスにおいて、取得者と供給者が行うべき作業を明確にしています。
規格や基準との関係
ＩＳＯやＪＩＳの規格では、ソフトウェアレベルでのライフサイクルプロセスを対象としたISO/IEC 12207（JIS X 0160）があります。共通フレームは、この規格を包含し、それに日本でのソフトウェア取引に必要とされている部分を追加しています。また、経済産業省のシステム監査基準やステム管理基準などに合致した内容にしています。
共通フレームの構成
共通フレームの構成を下図に掲げます。
共通フレームでは、ISO/IEC 12207（JIS X 0160）に従い、
プロセス＞アクティビティ＞タスク＞リスト
の階層になっています。
下表では、プロセスを掲げています。そのうちのいくつかについては、（→アクティビティ）や（→タスク）も掲げました。
１．主ライフサイクルプロセス
［契約関連のプロセス群」
１．１ 取得プロセス
（→アクティビティ）
１．１．２ 提案依頼書の準備
１．１．３ 契約準備及び更新
１．１．４ 供給者の監視
１．１．５ 受入れ及び完了
１．２．２ 提案書の準備
１．２．３ 契約締結
１．２．４ 計画立案
１．２．５ 実行及び管理
１．２．６ レビュー及び評価
１．２．７ 納入及び完了
１．３．２ 契約の変更要求
１．３．３ 影響の調査分析
１．３．４ 協議の実施と合意の形成
１．３．５ 契約の変更
１．４ 企画プロセス
（→アクティビティ）
１．４．２ システム化構想の立案
（→タスク）
１．４．２．２ 事業環境、業務環境の調査分析
１．４．２．３ 現行業務、システムの調査分析
１．４．２．４ 情報技術動向の調査分析
１．４．２．５ 対象となる業務の明確化
１．４．２．６ 業務の新全体像の作成
１．４．２．７ 対象の選定と投資目的の策定
１．４．２．８ システム化構想の文書化と承認
１．４．２．９ システム化推進体制の確立
１．４．３．２ 対象業務の内容の確認
１．４．３．３ 対象業務のシステム課題の定義
１．４．３．４ 対象システムの分析
１．４．３．５ 適用情報技術の調査
１．４．３．６ 業務モデルの作成
１．４．３．７ システム化機能の整理とシステム方式の策定
１．４．３．８ システム化に必要な付帯機能、付帯設備に対する基本方針の明確化
１．４．３．９ サービスレベルと品質に関する基本方針の明確化
１．４．３．１０ プロジェクトの目標設定
１．４．３．１１ 実現可能性の検討
１．４．３．１２ 全体開発スケジュールの作成
１．４．３．１３ システム選定方針の策定
１．４．３．１４ 費用とシステム投資効果の予測
１．４．３．１５ プロジェクト推進体制の策定
１．４．３．１６ 経営事業戦略、情報戦略、システム化構想との検証
１．４．３．１７ システム化計画の策定と承認
１．４．３．１８ プロジェクト計画の作成と承認
１．５．２ 利害関係者要件の定義
１．５．２．１ 利害関係者のニーズの識別と制約事項の定義
１．５．２．２ 業務要件の定義
１．５．２．３ 組織及び業務環境要件の具体化
１．５．２．４ 機能要件の定義
１．５．２．５ 非機能要件の定義
１．５．２．６ スケジュールに関する要件の定義
１．５．２．７ 実現可能性とリスクの検討
１．５．３ 利害関係者要件の確認
１．６．２ システム要件定義
（→タスク）
１．６．２．２ システム要件の評価
１．６．２．３ システム要件の共同レビューの実施
１．６．３．２ 利用者文書（暫定版）の作成
１．６．３．３ システム結合のためのテスト要求事項の定義
１．６．３．４ システム方式の評価
１．６．３．５ システム方式設計の共同レビュー
１．６．５ ソフトウェア方式設定
１．６．６ ソフトウェア詳細設計
１．６．７ ソフトウェアコード作成及びテスト
１．６．８ ソフトウェア結合
１．６．９ ソフトウェア適合性確認テスト
１．６．１０ システム結合
（→タスク）
１．６．１０．２ システム結合テストの実施
１．６．１０．３ 利用者文書の更新
１．６．１０．４ システム適格性確認テストの準備
１．６．１０．５ システム結合テストの評価
１．６．１０．６ システム結合計画の共同レビュー実施
１．６．１１．２ システムの評価
１．６．１１．３ システム適格性確認テストの共同レビューの実施
１．６．１１．４ 利用者文書の更新
１．６．１１．５ 監査の支援
１．６．１１．６ 各納入ソフトウェア製品の準備
１．６．１１．７ 運用、保守に引き継ぐソフトウェア製品の準備
１．６．１２．２ ソフトウェア導入の実施
１．６．１３．２ ソフトウェア製品の納入
１．６．１３．３ 取得者への教育訓練及び支援
１．７．２ 運用テスト
１．７．３ 業務及びシステムの移行
１．７．４ システム運用
１．７．５ 利用者教育
１．７．６ 業務運用と利用者支援
１．７．７ システム運用の評価
１．７．８ 業務運用の評価
１．７．９ 投資効果及び業務効果の評価
１．８．２ 問題把握及び修正分析
１．８．３ 修正の実施
１．８．４ 保守レビュー及び受入れ
１．８．５ 移行
１．８．６ システム又はソフトウェア廃棄
２．１ 文書化プロセス
２．２ 構成管理プロセス
［品質管理の視点でのプロセス群］
２．３ 品質保証プロセス
２．４ 検証プロセス
２．５ 妥当性確認プロセス
２．６ 共同レビュープロセス
２．７ 監査プロセス
２．８ 問題解決プロセス
２．９ ユーザビリティ（使用性向上）プロセス
３．組織に関するライフサイクルプロセス
４．システム監査プロセス
５．修整プロセス
対象の階層
共通フレームでは、対象を事業＞業務＞システム＞ソフトウェアに階層化しています。これは、責任の明確化でもあります。
- 事業
- 事業とは、企業経営のことです。事業達成すなわち経営戦略の策定や実現の観点から、ソフトウェアを調達し利用するのです。
- 業務
- 事業は販売業務、生産業務などからなっています。また、販売業務を受注業務、在庫管理業務のように細分化して定義することもできます。
- システム
- 業務は、人による活動と、ＩＴを利用した活動にわかれます。後者をシステムといいます。システムはソフトウェア、ハードウェア、ネットワーク、入力・出力する人間などから構成されます。
システム要件定義とは、業務の観点から開発すべき情報システムの機能や機能、信頼性などについて決定することです。応答時間の目標値の決定などもこれに含まれます。これらが適切に実現しているかどうかは、システストで確認されます。
システム方式設計とは、システム要件を実現するために必要なハードウェアやソフトウェア構成を明確にすることです。汎用コンピュータを用いるのかクラウドコンピューティングで実現するのか、独自仕様で開発するのかＥＲＰパッケージを用いるのかなどの基本的な方式を決定します。 - ソフトウェア
- ソフトウェアはシステムを構成する一部ですが、情報システムをコンピュータに実装する工程です。大雑把には「システム」が外部設計、「ソフトウェア」が内部設計だといえます。
ソフトウェア要件定義とは、システム要件をプログラムやデータベースのレベルにブレークダウンしたものであり、それが適切に実現しているかは結合テストで確認されます。
ソフトウェア方式決定とは、具体的なプログラミング言語やデータベースの選定、システム開発技法の選定などです。
ソフトウェア詳細設計とは、プログラミングのアルゴリズム、データベースでのクラス図、画面や帳票のデザイン、プログラム間のデータ受渡しなどを決定することです。この結果に基づいてプログラムのコーディングが行われます。
共通フレームでは、要件定義を「システム要件定義」と「ソフトウェア要件定義」に分けるなど、「システム」と「ソフトウェア」を明確に区分しています。
共通フレームは、システム開発の順序を規定するものではありませんが、一般的に次のようなＶ字型になります。
