ソフトウェア開発に携わっていると、しばしば「要件定義」「概要設計」などの言葉を耳にします。しかしながら、これらの用語の定義は意外とあいまいだと感じていました。自分の会社は自主開発をメインにしているものの、受託の相談を受けることもあるので、これらの用語の定義を調べたところ、IPA(情報処理推進機構)の「共通フレーム2007」という書籍がよくまとまっていました(自分が買ったのは第1版ですが)。
共通フレーム2007―経営者、業務部門が参画するシステム開発および取引のために (SEC BOOKS)
- 発売日: 2009/10/01
- メディア: 単行本
この書籍には、受託開発の発注側・受注側双方でこなすべきタスクが、初期の企画段階から保守まで、さらに補助的な構成管理まで含めて記述されており、契約時に参考にするには非常に便利です。詳しくは書籍を購入していただきたいのですが、概要をまとめておきます。
なお、共通フレーム2007は、主として受託開発を想定したものになっており、自主企画の場合にはアレンジが必要になります。
主ライフサイクルプロセスの概要
共通フレーム2007では、数多くのタスクを、プロセス ＞ アクティビティ ＞ タスク ＞ リストという階層関係で細分化しています。そして、プロセスは以下の4つに分類されています。
- 主ライフサイクルプロセス(契約、開発に関連するプロセス群)
- 支援ライフサイクルプロセス (文書化、構成管理などのプロセス群)
- 組織に関するライフサイクルプロセス (人的資源、資産管理などのプロセス群)
- システム監査プロセス
このうち、「主ライフサイクルプロセス」に分類されるプロセス群が、開発案件の中心になります。まずは、これらの概要をまとめます。なお、各プロセスの「目的」の記述は、「共通フレーム2007(初版)」からの引用です。
全アクティビティをまとめた図のPDFは、下記URL(経産省のサイト)で見られます。
http://www.meti.go.jp/policy/it_policy/si_so/slcp_2007.pdf
契約関連のプロセス
- 取得プロセス(要するにシステムを「購入」すること)
- 目的: 取得プロセスは、顧客が示したニーズを満足する製品及び／又はサービスを得ることを目的とする。取得プロセスは、顧客ニーズの特定から始まり、顧客が必要とする製品及び／又はサービスの受入れで終わる。
- アクティビティの例: 提案依頼書の準備、契約準備及び更新、受入れなど
- 供給プロセス(システムを「提供」すること)
- 目的: 供給プロセスは、合意した要求を満たす製品又はサービスを顧客へ提供することを目的とする。
- アクティビティの例: 提案書の準備、契約締結、計画立案、納入など
- 契約の変更管理プロセス
- 目的: 契約の変更管理プロセスの目的は、取得者と供給者の二者間で締結した契約内容に影響を与える変更要求が生じた場合、二者間で合意できる新たな契約内容を導くことにある。このプロセスは取得者又は供給者の変更要求の提示で始まり、変更要求の取下げ、全部又は一部了承など二者が合意する結論で終わる。
システム開発関連
- 企画プロセス
- 目的: 企画プロセスの目的は、経営事業の目的、目標を達成するために必要なシステムに関係する要求事項の集合とシステム化の方針、及び、システムを実現するための実施計画を得ることである。
- アクティビティの例: システム化構想の立案、システム化計画の立案など
- 要件定義プロセス
- 目的: 要件定義プロセスの目的は、新たに構築する(あるいは再構築する)業務、システムの仕様を明確化し、それをベースにIT化範囲とその機能を具体的に明示することである。また、関連する組織およびシステムに対する制約条件を明確にし、定義された内容について取得者側の利害関係者間で合意することである。
- アクティビティの例: 業務要件の定義など
- 開発プロセス
- 目的: 開発プロセスは、一組の要件を、顧客が記述したニーズに合ったソフトウエア製品又はソフトウェアを中心とするシステムに変換することを目的とする。開発プロセスの活動は、システム開発者の役割及びソフトウェア開発者の役割からなる。
- アクティビティの例: システム要件定義、ソフトウェア要件定義、コード作成、ソフトウェア導入など
- 運用プロセス
- 目的: 運用プロセスは、意図された環境下でシステム、ソフトウェア製品を運用すること、及びシステム、ソフトウェア製品の顧客に支援することを目的とする。
- アクティビティの例: 運用テスト、システム運用、利用者教育など
- 保守プロセス
- 目的: 保守プロセスは、障害の訂正、性能又は他の属性の改善を行うため納入後のシステム、ソフトウェア製品を修正すること、又は変更された環境に適合させることを目的とする。
- アクティビティの例: 問題把握及び修正分析、修正の実施など
保守に関する補足説明
特にWebアプリケーションの場合、開発完了後の運用・保守の比重が重いため、さらに補足説明します。
運用・保守の定義については前述の通り、「運用」が想定内の定常的な作業で、「保守」は開発後に意図しない何かが起きたときに行う修正のことです。さらに「保守」には、以下の4つのタイプがあると紹介されています。最初の2つが「訂正保守」に分類され、残る2つが「改良保守」に分類されます。以下、該当部分の説明を引用します。
- 是正保守
- ソフトウェア製品の引渡し後に発見された問題を訂正するために行う受身の修正。
- 予防保守
- 引渡し後のソフトウェア製品の潜在的な障害が顕在化する前に発見し、是正を行うための修正。
- 適応保守
- 引渡し後、変化した又は変化している環境において、ソフトウェア製品を使用できるように保ち続けるために実施するソフトウェア製品の修正(OSの更新に合わせた変更など)。
- 完全化保守
- 引渡し後のソフトウェア製品の性能又は保守性を改善するための修正。
保守契約を検討する際には、これらの保守のどこまで対応するのかを明確にしておく必要がありそうです。
