共通フレーム2013(SLCP-JCF2013)

共通フレームの最新版は、共通フレーム2013(SLCP-JCF2013)である、
この前の版である共通フレーム2007(SLCP-JCF2007)に関しては以前の記事で紹介済みなので、ここでは2007からの変更点を中心にSLCP-JCF2013を概観する。
2013のフレームワークは下図に示すとおりであるが、2007のフレームワークから大幅に変更・拡張されているように見える。
共通フレームは、もともとはソフトウェアライフサイクルのプロセスを定義するものであったが、これに要件定義工程などが加えられ、さらにハードウェアを含むシステムへと拡張され、2013ではさらに範囲が拡大している。
例えば、2013ではプロジェクト・ポートフォリオ管理の枠組みが新たに追加されているが、これは企業のITプロジェクト全体に関わるテーマであり、1つのプロジェクトにおけるシステム/ソフトウェア・ライフサイクルの範囲を逸脱している。
このように範囲が広がったこともあり、説明図書のページ数も随分と増えている。
これだけボリュームが増えてしまうと、通読する目的ではなく、チェックリストとして関心のある部分だけ参照する方が現実的だと感じる。
共通フレーム2013は、ソフトウェアライフサイクルプロセスの規格であるJIS X 0160:2012をベースにしている。
JIS X  0160:2012は、国際規格ISO/IEC 12207に対応した最新の規格である。
SLCP2013のフレーム
SLCP-JCF2007からの変更点として、まず最上位のプロセスの構成と名称が幾つか変更されている。これは全体の枠組みが見直されたと言って良いレベルの変更である。
例えば、「企画プロセス」や「要件定義プロセス」は、共通フレーム2007では「主ライフサイクルプロセス」の枠組みの中(配下)にあったが、共通フレーム2013では「テクニカルプロセス」の枠組みの中(配下)に変わっている。
プロセスの名称が変わったもの、及びアクティビティからプロセスに変更になったものは以下のとおり。

  • 改善プロセスが、ライフサイクルモデル管理プロセスに名称変更された
  • 環境整備プロセスが、インフラストラクチャ管理プロセスに名称変更された
  • 資産管理プロセスが、再利用資産管理プロセスに名称変更された
  • 測定アクティビティが測定プロセスに変更された
  • システム又はソフトウェア廃棄アクティビティが、廃棄プロセスに変更された
  • 開発プロセスのアクティビティが、プロセスに変更された
  • ソフトウェアコード作成及びテストアクティビティが、ソフトウェア構築プロセスに変更された
次に、共通フレーム2013で追加になったプロセスを見ていく。
共通フレーム2013では、運用プロセスの中に「サービスマネジメントプロセス」が追加されている。
「サービスマネジメントプロセス」は、JIS Q 20000を引用しており、
  • 合意されたサービスレベルに従ってサービスが提供されていること、
  • インシデント、サービス要求、問題の解決がなされていること、
  • 事業側と供給側との関係が維持されていること、
  • 構成管理、変更管理、リリースおよび展開が統合的な制御のもとで実施されていること、
が求められている。
共通フレーム2013では、「プロジェクトプロセス」という管理系のプロセスの配下に、「意思決定管理プロセス」と「リスク管理プロセス」、「情報管理プロセス」が追加されている。
プロジェクトプロセスは、「プロジェクトマネジメントの視点」と「プロジェクトサポートの視点」に分けられる。
「意思決定管理プロセス」は、文字通り意思決定のことであり、複数の代替案のなかから好ましい行動を選定することを指している。
「情報管理プロセス」は、プロジェクトで管理すべき情報の定義と管理(情報の生成、収集、変換、保持、検索、配信、廃棄)に関するプロセスである。
「情報管理プロセス」と「文書化管理プロセス」の関係であるが、文書化管理プロセスは情報管理プロセスを特化したもので、支援プロセスに含まれる、とされる。
共通フレーム2013では、「プロジェクトポートフォリオ管理プロセス」が追加されている。
組織では複数のプロジェクトが同時並行的に実施されることが一般的である。プロジェクトポートフォリオ管理プロセスでは、組織が実施中、及び実施を検討しているプロジェクトを横並びで評価し、資金及び資源に制約がある中で組織目標の達成に向けて最適なプロジェクトの組み合わせを決定するための作業を定義している。
プロジェクトの実施中は、組織により定期的に進捗と成果が評価され、必要があれば軌道修正のための措置が取られる。
場合によっては、プロジェクトの中断や凍結の意思決定が行われる。
共通フレーム2013では、「品質管理プロセス」が追加されている。
品質管理プロセスは、製品、サービス及びライフサイクルプロセスが組織の品質目標に合致し、顧客満足度を達成するためのフレームワークである。品質管理プロセスを適切に実施することにより、組織の品質管理方針、手順、品質目標が定義され、品質目標が達成されていないときに適切な処置をとることが可能となる。
品質管理システムのプロセスモデルとしてJISQ9001(ISO9001)が参照可能である。

共通フレーム2013では、2007の「ソフトウェア導入」が、システム開発プロセスの中の「システム導入プロセス」に拡張されている。同様に「ソフトウェア受入れ支援」が「システム受け入れ支援プロセス」に拡張されている。
単なるソフトウェアの導入からシステムの導入へと拡張されたことから、これはいわゆる本番移行を意味するようになったと考えられる。
このため、「運用プロセス」のなかの「業務及びシステムの移行」との違いが分かり難くなった(個人的には同じ工程を指していると思うのだが・・・)。
「システム導入プロセス」では、既存システムを新システムで置き換える場合は、並行運用の有無や並行運用期間を明確にし、リリースバックに備えてバックアップと手順を準備する旨が記されている。
共通フレームでは、リリースバックを「直前の稼働システムの版に戻す戦略」と表現している。
システム導入は、取得者が作業主体となり、供給者(開発者)がそれを支援する形が望ましい、としている。
「システム受け入れ支援プロセス」とは、供給者(開発者)が納品し、取得者が受け入れ試験を実施して検収する段階を想定している。取得者の受け入れテストやレビューを、供給者(開発者)が支援することを想定している。
さらに、供給者が取得者に対して実施する教育訓練やその他の支援作業が含まれるとされる。

共通フレーム2007の紹介の中で、少々説明があやふやだった「ドメイン技術プロセス」に関して、 2013では「ドメイン(領域)エンジニアリングプロセス」として解説があるので、その一部を引用しておく。
ドメイン(domain)は、再利用を目的として管理される資産を提供・適用できるように分割された技術領域または応用領域のことであり、ドメインエンジニアリングは再利用に基礎を置いた、
  1. 範囲決定(→ドメイン決定)
  2. 構造規定(→ドメインの基本構造の定義)
  3. 資産構築(→ソフトウェアコードや設計、要求事項、文書化に対する取組)
を指す。
ドメインエンジニアリングは、ドメインに関する分析や設計に関するすべてを含む。
プロジェクト管理のINDEX

トラックバック

このブログ記事に対するトラックバックURL:

コメント & トラックバック

コメントはまだありません。

Update

2018年8月
« 7月    
 12345
6789101112
13141516171819
20212223242526
2728293031  

Navigation