Eclipse Process Framework Composer

前々からじっくりと触りたかったEclipse Process Framework（EPF：コードネームは、Beacon）にやっと触る機会を得ることができました。

ここでは、EPFの詳細説明などはしませんが、2005年10月に、IBM RationalがRUPのコンテンツの一部とツールをEclipse Fundationに寄贈したことで生まれたものになります。

EPFについては、ググってみるとIBMのサイトをはじめ、日本語でもそれなりに情報があります。

これにより、RUP（Rational Unified Process）の一部コンテンツによる、OpenUP/Basic、そしてオーサリングツールである Eclipse Process Framework Composerが提供されました。  

プロセス・エンジニアリング・メタモデルとしてUMA（Unified Method Architecture）は、OMGによりSPEM 2.0として採用される予定とか。

すばらしいと感じるのは、これでプロセスの表記などが共通化されていく方向に拍車がかかるということ、今まで大変な作業であったプロセスの開発がオーサリングツールにより効率的にできるということです。

元々RUPは、テーラリングを前提としてプロセスであり、HTML形式で提供されるツールでもあるわけで、Process Workbench、RUP Builderといったオーサリングのためのツールも提供されていました。これをEclipseベースで、よりメソッド・コンテンツやプロセスを開発しやすくしたものとしてEPF Composerを提供してくれています。

また、EPF Composerは何もRUPに特化したツールではないので、どんな開発プロセスでもこのツールで開発することができます。

要するにプロセスの基本要素（人、作業、成果物）は、プロセスに依存することなく、一致しているということですね。

で、このツールによる“とっつき易い使い方”をいろいろと模索しているのですが、プロセスが確立している、もしくは確立しつつある、あるいは、明文化されていないが、かなり確立されているっぽいと言った場合は、早速EPF Composerを使ってみるのがいいかと思います。きっとプロセスがより明確化されると思いますし、プロセスの“アラ”も顕在化されるのではないでしょうか。その後には、各プロジェクトでプロセスのテーラリングするときにより効果を発揮することでしょう。

ただ、プロセスが確立していない組織やプロジェクトも多くあります。そんな場合は、まずはどの作業分野でもプロセスエリアでもいいので、EPF Composerを使って定義してみるのはいかがでしょうか。例えばソフトウェア構成管理や変更管理のプロセスだけ（また、さらにその中の一部分だけ）に的を絞って定義してしまうとか。きっと効果あると思います。

時間があったら、汎用利用可能な構成管理か要求管理のプロセスを定義してみようと画策中です。

また、EPF Composerは、Eclipseベースですので、バージョン管理/構成管理が可能な点も非常に魅力です。以前にもちょっと書きましたが、プロセスも変更が避けられないため、構成管理や変更管理は必須といっても過言ではないわけです。変更するには、以前のプロセスの構成を知る必要がありますし、何をどんな理由でどう変更したのかをプロセスエンジニアだけではなく、プロセスを使う側にも周知するための材料を提供する必要があります。変更の影響範囲やそもそもの変更作業の効率化も含めてプロセスの策定・開発でEPF Composerの登場により、われわれのようなコンサルタントも、標準化組織や、改善チーム、現場プロジェクトも少しでも楽ができるようになることを期待してます。