ICONIXプロセスというものを知った
前回の日記（id:paz3:20090608）の続き。『「ソフトウェア工学」は矛盾語法か？』を読んで思ったことのメモです。
真のソフトウェア工学はまだ未来のものだ。一年とかけずに三千人以下でエンパイアステートビルを造り上げるようなものは、現在のソフトウェア工学に存在しない。
先日も書きましたが、「ソフトウェア作りは、最初から最後まで工業製品でいう設計に当たる」という意見に私は賛成です。設計の中でも、顧客の要望から設計図まで自然に落とし込み、ある程度のレベルのものを作成するということを毎年たくさんやっているという点で、建築設計には見習うべきものがあると思います。
ソフトウェアを作成する際に、顧客の要望から設計（コード）までスムースに持って行く方法があればいいなあと思っていました。顧客の要望を明確にする方法には、ユースケースを使うのが良いようです。
さて、ユースケースから必要なオブジェクトを抽出するにはロバストネス分析をするといいと、はてなキーワードに書いてありました。
そこで私もロバストネス分析をしてロバストネス図を描いてみましたが、うまくいきませんでした。それは、画面全体をバウンダリにしたとき、処理内容が大きく抽象的になってしまうことがあるということと、コントローラをどこまで分割してよいのかわからなくなってしまったからです。
さらに色々と調べてみたところ、id:shuji_w6e さんのエントリで「ICONIXプロセス」というものを知りました（id:shuji_w6e:20081116）。また、Googleで「オブジェクト・モデリング ICONIXプロセス (PDF)」というPDF文書も発見しました。これを読んで目からウロコが落ちました。ロバストネス図のバウンダリを「ボタン1個」の単位まで小さくし、コントローラはクラスのメソッドに対応するというICONIXの考え方は、上記の悩みを解決するものでした。
ICONIXプロセスは「ユースケース駆動開発実践ガイド」という本で学ぶことができると知り、さっそく買ってきました。今日から読んでみます。
ユースケース駆動開発実践ガイド
