《《=[前の記事に] 《=[前ページ]       [次ページ]=》 [次の記事に]=》》



UMLはプロセスから独立していますから,極端なことを言えば,
  • モデリング言語にUML 
  • プロセスにDOA(あるいはSA/SD) 
ということも可能です.

とはいえ,オブジェクト指向のパラダイムから出てきたモデリング言語ですから,ベストマッチはオブジェクト指向のプロセスです.UMLを効果的に活用するためのプロセスとしては,Booch法,OMT,Objectory,Catalysisなどがあります.あるいは同じ紙面で西中さんから紹介されている(であろう:-p)../XP/XPを使うのもいいかと思います.ここではUMLの生みの親であるRational Software社が提唱しているRUP(Rational Unified Process)をご紹介します.*1

1.RUPの歴史

RUPはUMLの生みの親であるG.Booch,J.Rumbaugh,I.Jacobsonによって提唱されたプロセスで,Jacobsonの方法論であるObjectoryをベースにしています.



*1)最近,RUP vs ../XP/XPといったキーワードを見かけることがありますが,プロジェクトに応じて(あるいは作業に応じて)使い分ける事が得策でしょう.90年代に起こった不毛なOO方法論争のようなことにならないでほしいものです.

 

また,RUPはHTMLとJava Appletで提供され,新しい技術等に対応するため,半年毎に更新されています.ついでにUMLの歴史も.

2.6つの原則

ソフトウエアを開発する上でよく出会う問題点として,以下の項目が挙げられます.
  • エンドユーザニーズを正確に理解できていない
  • ソフトウエアの変更依頼に対応できない
  • モジュール間の整合性がない
  • 保守,拡張が困難なソフトウエア
  • プロジェクトの重大な問題の発見が遅れる
  • ソフトウエアの品質が悪い
  • ソフトウエアのパフォーマンスが悪い
  • チームメンバがそれぞれ勝手な方法で開発しているため,誰が,何を,いつ,どこで,どのように変更したかが再現できない
  • ビルドしてリリースするプロセスが信頼できない
これらは問題の表層であり,根本的な原因は次のところにあると考えられます.
  • 要求管理が場当たり的に行われている
  • コミュニケーションが曖昧で不正確
  • 著しく複雑
  • 要求,設計,実装間の矛盾を発見できない
  • テストが不十分
  • プロジェクトのステータス評価が主観的

《《=[前の記事に] 《=[前ページ]       [次ページ]=》 [次の記事に]=》》