お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

アジャイル・モデリング (AM)

最新のソフトウェア開発に有効なモデリング技術

Scott W. Ambler (scott_ambler@ca.ibm.com), Practice Leader, Agile Development, Rational Methods Group, IBM　

Scott W. Amblerは、オブジェクト指向ソフトウェア処理の指導、アーキテクチャー・モデリング、およびEnterprise JavaBeans (EJB) 開発を専門とするコンサルタント会社である、Ronin International の社長です。彼は、オブジェクト指向開発に関する本を執筆あるいは共同執筆しています。最近刊行されたものとしては、この記事で要約された主題を詳しく論じた The Object Primer 2nd Edition などがあります。彼の連絡先はscott.ambler@ronin-intl.com およびwww.ambysoft.com にあるサイトです。

概要： アジャイルのモデルを作成する人たちは、複雑なソフトウェアを開発するために、電話帳サイズのドキュメンテーションを作成する必要はないと考えています。

タグを付ける!

日付: 2001年 3月 29日
レベル: 初級
この記事の原文: 英語
アクティビティー： 1175 ビュー
お気軽にご意見・ご感想をお寄せください：

簡単に言うと、アジャイル・モデリング (AM) とは、ソフトウェア開発プロジェクトに、効果的で手軽に適用することができる、ソフトウェア・モデリングのための価値(value)、原則(principles)、およびプラクティス(pracices)を集めたものです。AMの考え方では、この記事で触れているすべての要素は重要ですが、アジャイル方法論に従ったモデリングを行う場合には、特に以下に重点が置かれる必要があります。

プロセスやツールよりも、個人や相互作用
包括的なドキュメントよりも、役に立つソフトウェア
契約上の駆け引きよりも、顧客との協力
計画通りに進めることよりも、変化に対応

アジャイル・モデリングの目的

効果的で手軽なモデリングを行うために一連の価値、原則、およびプラクティスを定義し、さらにその実践方法を示していくこと。
AMを成功させる秘訣は、ユース・ケース・モデル、クラス・モデル、データ・モデル、またはユーザー・インターフェース・モデルなどの、モデリングの技術そのものではなく、それらをどのように適用するのかにあります。
エクストリーム・プログラミング (XP) などのアジャイルな方法論をとっているソフトウェア・プロジェクトに対し、モデリング手法をどのように適用するかという問題に取り組むこと。
Kent Beckの、著書「XP・エクストリーム・プログラミング入門」から引用すれば、「非常に単純なものから始めて、システム設計を絶えず洗練していきます。また、有益とはみなされない柔軟性はすべて取り除いていきます。」ということです。XPを非難する一部の人たちの主張に反し、XP手法を取っていても、モデリングに時間をかける場合があります。しかし、それは他に選択肢がない場合のみです。開発者にとっては、アイディアを突き詰めるために丸や線図を図を描いてみたり、また問題を解決するためのいくつかの方法を比較してみたりする方が、いきなりコードを書き出すよりも大幅に生産性が上がることがあります。
Unified Process (UP) を採用するなどしていて、アジャイルな方法論を採用していないプロジェクトに対し、モデリングに関しアジャイルな方法論を働きかけること。
UPのために拡張されたライフサイクルには、要件、ビジネス・モデリング、分析および設計、インフラストラクチャー管理といったいくつかのモデリング指向のワークフローが含まれますが、これらを額面どおりに適用すると大きな負担になる場合があります。AMは、UPプロジェクトに対するモデリングをより効果的に行うための役に立ちます (これはどのプロジェクトに関しても言えることです)。

ここで主張したいのは、AMは、その核心においては単に、多くの経験豊かなソフトウェア開発者が既に知っている原則や価値を反映したプラクティスの集まりに過ぎないということです。私の経験では、これらのプラクティスはほとんどのソフトウェア開発プロジェクトに適用することが可能です。AMによって説明される方法論の利点を活用するために、XPなどのアジャイルなソフトウェア・プロセスに従って進められているプロジェクトに参加することは必須ではありません。(AMの目標の一つが、XP手法を採用している場合のモデリング方法を説明することですが)利点を活用するために1つのプロジェクト・チームが、AMのプラクティス、原則、および価値のすべてを適用する必要はありません。常に私は、自分の環境に固有なニーズを反映するためには、ソフトウェア・プロセスに手を加えるべきだと信じてきました。個人的な意見ですが、私はXPの場合のようにAMをすべて採用したほうが、成功することが多いと思います。

アジャイル・モデリングの価値、規則、およびプラクティスについては、今後の記事で詳しく掘り下げていく予定です。

参考文献