- PR -

「プロジェクト成功のキーポイント」投稿室

«前のページへ 1|2|3|4|5 次のページへ»
投稿者投稿内容
矢崎
会議室デビュー日: 2001/10/05
投稿数: 4
投稿日時: 2001-10-05 18:28
こんにちは、ウルシステムズの矢崎と申します。

引用:

モデルをがっちり決めてしまうことは諸刃の剣で、実装段階に入っているのに、そのモデルを理解していない顧客がモデルを崩してしまうような仕様変更を要求してくることはままある気がします。そしてモデルのなかに「例外」が発生し、コーディングは泥沼の様相を…

なんてことにならないために、モデルを考える時点で

- 要求仕様
- 潜在要求仕様(顧客が仕様変更する可能性がある要求。口先は信用できない:b)
- 実装言語の特性に応じたものであること
- 潜在要求仕様が出てきても対応できるようにすること
を考えておかないといけないのでは。おそらくこれが「上手なモデリング」であって、これをできるためには、顧客の業務要件全般に造詣が深いだけでなく、実装言語の特性を知っており、抽象的なモデルの考え方ができるといった能力が必要になるでしょう。

うまい職人的プログラマは、この後半部分を無意識に行なっています。事実上、仕様をみながら、クラス階層図(まぁUMLと同等と思ってもいいかも)を思い浮かべ、具体的な実装ではなくAPIから作っていくでしょう。
Javaで作るっていってんのにC/S系COBOL実装みたいなモデルっぽいものが出てきて、なんだよこれっていうことはまぁよくあることで。



私は、クラス図による概念モデリングは要求を明確にするために行うものだと思っています。クラス図による概念モデリングだけで要求全てを表現する、というのはできませんが、少なくとも要求の場に登場する概念を洗い出し、概念と概念の間の関係を明確にするのには有効です。
なので、「モデルをがっちり決めてしまう」という表現には少し違和感を覚えます。モデルは誰かが勝手に決めるというよりは要件から決まってくる、あるいは定まってくるものだと思っています。確かにモデリングする人の主観がはいるものではありますが、いくら主観的行為であっても要件の世界を正しく表現しているモデルは正しいモデルで、要件の世界を正しく表現していないモデルはまちがったモデルです。そして、まちがったモデルはいずれにしろ修正しなければなりません。あるいは使ってはいけません。

それと、モデルを理解していない顧客がモデルをくずしてしまう、ということはもともとのモデルが正しく要件を表していなかったか、あるいは要件が変わってしまったかなので、それはモデルをどうこうするかということの前に、正しくない要件でそのまま進むか、あるいは要件をその段階で変更するか、という話になるのではないでしょうか。もし要件変更を受け入れるとすれば、当然、そのために（一部の）モデリングをやり直さなければならないでしょう。要件をあらためてきちんと整理するために、、、、

最後に私は、概念モデリングにおいては実装要件を考慮することは原則的にいらない、と思っています。それはあくまでも設計モデルあるいは実装モデルの話にすべきという考えです。要件の世界を正しく理解しかつ表現するというだけでも結構大変な作業で、かつそれをみんなで共有しようとするときには焦点を絞ったほうがいいでしょう。実装の話は混乱をまねくのでは、という考えです。だいたいが要件の世界になぜ実装の話が必要かが今いちピンときません。
#あるいはコントローラ系の話なのかもしれませんね。そうならその部分に関しては多少実装系のことは必要かもしれません。

えーともしかしたら、しょむさんは概念モデリングとは別のモデリングについて議論されているのかもしれません。その場合はごめんなさい、です。
しょむ
ぬし
会議室デビュー日: 2001/09/06
投稿数: 430
投稿日時: 2001-10-08 22:06
なーる。理解してきました。
要件定義のモデリング、ですね。

私がイメージしてたのは、モジュール設計とかそのあたり。
たぶん waterfall だと、概要設計? とかになるかと。

幸か不幸か、OOPだとOO概念モデルを素直にOO実装モデルに落とし込めるので、ついついコードを頭に思い浮かべながらモデルを考えてしまいます。
概念モデルと実装モデルを分けて考えるべし、だとすっきり頭に入ります。

「要件定義でのモデリング方法論」とか面白いかもしれませんね。
にわとり
ベテラン
会議室デビュー日: 2001/08/30
投稿数: 70
投稿日時: 2001-10-09 13:01
XPって残業しない、というのは本当ですか。
maru
常連さん
会議室デビュー日: 2001/10/09
投稿数: 23
投稿日時: 2001-10-09 15:22
引用:

にわとりさんの書き込み (2001-10-09 13:01) より:
XPって残業しない、というのは本当ですか。

経験者ではありませんが
本やホームページを読んだ範囲では

残業をあてにして開発計画を立てないようです
しかし、ユーザの都合では長時間労働もしたようです
その結果は最悪だったと書いてありましたが・・・

週４０時間労働という数字を出して
長時間労働では品質の高いコードは生産できないよというメッセージです
ピンク色のXP本には長時間労働の経験談が載っていました

[ メッセージ編集済み 編集者: maru 編集日時 2001-10-09 15:27 ]
矢崎
会議室デビュー日: 2001/10/05
投稿数: 4
投稿日時: 2001-10-09 16:05
引用:


「要件定義でのモデリング方法論」とか面白いかもしれませんね。


リプライありがとうございます。

要件定義のためのモデリングの仕方をできるだけ、俗人的ではなく、
標準化（定型化）することについては、私も非常に関心があります。
そのポイントの１つが集合論や関数等を使って数学的な理論を背景に
持たせること、と思っています。概念モデリングについてはOdellさん
がこのあたりの議論を昔やっていましたが、最近は少なくともメジャー
なところではやられなくなって、残念ですね。
Odellさんの本は日本訳のものはトッパンの出版からの撤退により、
手にはいらなくなってしまいましたし、、、、
にわとり
ベテラン
会議室デビュー日: 2001/08/30
投稿数: 70
投稿日時: 2001-10-09 21:25
引用:

maruさんの書き込み (2001-10-09 15:22) より:
引用:

にわとりさんの書き込み (2001-10-09 13:01) より:
XPって残業しない、というのは本当ですか。

経験者ではありませんが
本やホームページを読んだ範囲では

残業をあてにして開発計画を立てないようです
しかし、ユーザの都合では長時間労働もしたようです
その結果は最悪だったと書いてありましたが・・・

週４０時間労働という数字を出して
長時間労働では品質の高いコードは生産できないよというメッセージです
ピンク色のXP本には長時間労働の経験談が載っていました

[ メッセージ編集済み 編集者: maru 編集日時 2001-10-09 15:27 ]


ということは、XPしてても悲惨な結果は有り得るのですね。
ユーザーの都合とは制御できないものなのか。
：
：
なにかうまい方法はないものか．．．。
漆原
会議室デビュー日: 2001/09/27
投稿数: 7
投稿日時: 2001-10-09 21:47
引用:

にわとりさんの書き込み (2001-10-09 13:01) より:
XPって残業しない、というのは本当ですか。


漆原です。

XPって、残業もExtremeに!? いえ、冗談です。

残業をあてにはしない、というのは本当ですが、
朝遅ければ夜も遅い・・・（ほら、そこらへんのヒト!!）

誰かXPの現場の方のコメントを待ちたいと思います。
にわとり
ベテラン
会議室デビュー日: 2001/08/30
投稿数: 70
投稿日時: 2001-10-10 22:18
残業をあてにしないスケジュールって、XPでなくてもあたりまえですよね(本当は)
。
«前のページへ 1|2|3|4|5 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）