ObjectSquare [2005 年 3 月号]

[レポート]


モデル駆動は開発プロセスをどう変えるか?

〜 第III期 第4回 MDAテクノロジー・フォーラム 参加レポート 〜

(株)オージス総研 水野正隆

第 III 期 第 4 回 MDA テクノロジー・フォーラム (以下、MTF) が、2005 年 2 月 1 日に青山テピア (東京/青山) で開催されました。MTF は、オブジェクトテクノロジー研究所が主催するイベントで、第 I 期 第 1 回目から数えて今回で 12 回目の開催になります。MTF は、UML や MOF 等の MDA の要素技術を、様々な技術テーマとの関連で取り上げ、情報の提供/交換を行なってゆく場として企画されています。今回のフォーラムは開発プロセスにフォーカスが置かれており、「モデル駆動は開発プロセスをどう変えるか?」というテーマが掲げられていました。

開発プロセスがどのように変わろうとしている (変わった) のかという視点で、本フォーラムをレポートしたいと思います。

はじめに

本カンファレンスは、以下のプログラムで構成されていました。始めの 2 つの講演が、開発プロセスに関する標準化にまつわるもの。残りの 3 つが、開発プロセスを現場にどのように適用するかという内容の講演になっていました。

プログラム

  1. 開発プロセスの標準化動向:SPEM 2 (Software Process Engineering Metamodel)
  2. IBM の開発プロセス戦略〜現状と今後
  3. アジャイル開発における MDA
  4. 組込系システムにおける開発プロセスの最適化-SPOの適用-
  5. レガシーマイグレーションにおける効果的な UML の使い方

開発プロセスの標準化動向:SPEM 2 (Software Process Engineering Metamodel)

講師: 和田 周氏/オブジェクトテクノロジー研究所 技術ディレクター

SPEM 2.0 における SPEM 1.1 からの変更点の紹介でした。和田氏の講演の内容に入る前に、SPEM とは何だったかをまず確認したいと思います。

SPEM のおさらい

SPEM (=Software Process Engineering) は、開発プロセスのメタモデルです。SPEM を使うことで様々な開発プロセスを UML で記述することができます。もちろん、メタモデルなどなくても好き勝手に記述することは可能でしょう。しかし、メタモデルが存在することで、ルール(=メタモデル)に沿って修正できたり、モデルの検証ができたりします。もし、そのメタモデルを解釈できるツールがあれば、エディタ感覚で簡単にモデルの更新ができるようにもなるでしょう。具体的な例で言うと、あるアクティビティを今回のプロセスから削除すれば、そのアクティビティとそれを実行するロールが全てのビューから削除されたりするということです。

昨年のオブジェクトの広場でも SPEM の解説記事「UML でソフトウェアプロセスを定義する - SPEM を使って - 」を掲載しました。詳細を知りたい方は、そちらの記事もご覧ください。

講演内容

SPEM 2.0 をユーザ (=SPEM の利用者) の立場から見たとき、SPEM 1.1 と殆ど変わらないそうです。主に変わった (変わる) 点は、「UML 2.0 対応」と「SW-CMM との連携」の 2 点となります。

SW-CMM との連携

SPEM 2.0 は、そのプロセス改善のリファレンスモデルとして、SW-CMM を採用しているそうです。「今後、SW-CMM にのっとった評価をなんらかの形でサポートするしくみ (ツール) が出るかもしれない。」とのことでした。

SPEM 2.0 の今後

SPEM 2.0 はまだ提案段階なので、全容が見えるようになるまであと 1 年はかかるそうです。

参考

IBMの開発プロセス戦略〜現状と今後

講師: 榊原 彰氏/日本アイ・ビー・エム(株) サービス事業 ストラテジー&コンピテンシー ICP エグゼクティブ IT アーキテクト

この講演では、IBM の開発プロセス標準化の事例紹介がありました。

講演内容

IBM の GSMethod (IBM Global Services Method) は、共通の開発プロセス体系です。先に開発プロセスのメタモデルの紹介をしましたが、IBM には独自のメタモデルがあり、GSMethod はそれに沿った開発モデル群だそうです。GSMethod には顧客に提供するサービスや契約形態別にモデル (エンゲージメントモデル) があり、各プロセスはトレーニングされた技術者の下、案件毎にさらにカスタマイズして使用します。カスタマイズされたプロセスが有用である場合、その事例とともに 社内の Knowledge Base に登録され、再利用されるそうです。

IBM では、 RUP と GSMethod のマージ作業を進行中とのことです。ただし RUP は製品でもあるので、それを今後も IBM が提供することに変化はないそうです。

プロセスの現場への適用

午後には、「開発プロジェクトのタイプによって、現場でのプロセスの適用はどのように行うべきなのか」という点にフォーカスをした講演がありました。以下の 3 つの講演は内容こそ違いますが、その主張のポイントはほぼ同じでした。その主張は、「万能な開発プロセスや手法はなく、案件に応じて調整する必要がある」ということでした。

アジャイル開発における MDA

講師: 嶋 英彦氏/アゾラテクノロジーズ(株) 副社長 プロフェッショナル・サービス

嶋氏によると、どんなプロセスもそのアジャイル度が違うだけで、どれもイテレーティブでアジャイルなプロセスであるとのことです。つまり従来型開発 (RUP 等) も一般にアジャイル開発と言われているプロセス (XP 等) も、同じアジャイル「な」開発だそうです。プロジェクトを上手くすすめるには、それらの中から 1 つのプロセスを選ぶのではなく、様々なアジャイル度を持った開発プロセスを"調合"することが必要となります。なぜなら 1 つのプロジェクトであっても、アジャイル度の違うサブプロジェクトが存在するからだそうです。

サブプロジェクト毎にアジャイル度は違う

図 1: プロジェクト

また、システムの納期が短かくなっている状況なので、「アジャイルにならざるを得ない」とも仰っていました。そこで、アジャイルモデリング駆動開発 (Agile Modeling Driven Development) を推奨されていました。

MDA はビジネスプロセスレベルでのモデリングからコードまで、その変更管理をサポートしています。つまり、モデルをコードにまで変換できます。ですから、アジャイルにモデリングし開発してゆく手法を取った場合、MDA は有用な仕組みなので、「MDA 開発はアジャイル開発と従来型開発の有効な橋渡しとなりうる」と結論づけられていました。

組込系システムにおける開発プロセスの最適化 - SPO の適用-

講師: 伊藤昌夫氏/(株)ニルソフトウェア 代表取締役CEO

プロジェクトに合った開発プロセスを考えるときに、メタなモデルから導出するのではなく、システムの性格から逆にプロセスを導出する必要があるというのが、伊藤氏の主張です。本講演で紹介された SPO (Software Process Optimization) は、対面する問題を分析・モデル化し、その解決策を考え出す問題解決手法です。この手法をソフトウェア開発において繰り返して実行し、プロセスを最適化してゆくことが必要であると、伊藤氏は述べられていました。

講演では SPO は簡単に紹介されただけなので、ここでも SPO の細かい説明はできませんが、下記のページに参考になります。SPO の中に活動理論を使った分析方法がありますが、それに関して解説されたコラムです。ところで、講演タイトルに"組込系"と書かれてありますが、(講演者も話されていたように) 組み込みに限った話ではありませんでした。(笑)

参考

レガシーマイグレーションにおける効果的な UML の使い方

講師: 鈴木高弘氏/データリンク(株) CTO 取締役

本講演では、レガシーシステムを置き替える場合において、鈴木氏がこれまでの経験から得たノウハウの発表がありました。ポイントとなる点をいくつか列挙します。

*1 CRC カード: クラス(Class)、その責務(Responsibility)、協調関係のあるクラス(collaborator)を一枚のカードに書いたもの。参考 :CRC (Class Responsibility Collaborator) モデルの概要

*2 アセンブリライン図: オブジェクトとプロセスとの関係を表現するための図。

まとめ・所感

今回の MTF は、開発プロセスがテーマでした。講演も開発プロセスがテーマとなっていましが、"MDA" という単語を聞くことはあまりありませんでした。もちろん、それぞれの講演の中で、MDA or MDD が触れられることはありましたが、メイントピックではありませんでした。少なくとも私はそう感じました。私は、開発プロセスに MDA がどのように折り込まれるのか、MDA というアーキテクチャが開発プロセスどのように支えるのかということに興味があったのですが、「開発プロセス自身のモデル」のお話が多かったのが残念でした。

MDA は、開発の上流から下流までを視野に入れたアーキテクチャです。MDA をモデルからコードを生成する仕組みに終らせないためには、MDA が開発プロセスに織込まれ、ビジネス分析・ビジネスモデリングからコーディングまでの各アクティビティーの基盤になる必要があるでしょう。

開発プロセス分野における MDA が、今後どのようになっていくか注目したいと思います。

参考




© 2005 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP