昨日の、
UMLからNoUMLというのは、青い鳥な図を探していると思う
http://blog.goo.ne.jp/xmldtp/e/8ee5111962a4e2067bf00dbc9a9234d6
の続きみたいな話。
ソフトウェア工学の傾向として、はじめの志はいいかもしれない。
でも、ある方法、理論ができてしまうと、今度、「その理論を守ればいいのね」というカタチになりがちだと思う。
ER図など
エンティティを作って、属性を埋めて、線(リレーション)でつなげばいいのよね
UMLだと、
UMLで書いて、図を埋めればいいのよね。
TDDだと
JUintで緑にすればいいのよね
しかし、これらは、本質的に違ってきてしまう。
たとえば、ER図をかくにしても、UMLをつくるにしても、お客さんの要望を聞いて、ステークホルダーが理解しやすくするためのモノだったけど、お客さんの要望を聞くことや、みんなの理解はさておき、図を書くことに集中してしまう。
この結果として、本質的な、「要望を聞く能力」や「理解してもらうために必要な能力」とかは、あまり研究されず、整理術、整理法とでも言うべき図の書き方などが発展し、いろいろな概念が出てくるが、肝心な部分が発展しにくくなってきていると思います。
う~ん、ソフトウェア工学は、違った方向に行っているのかもしれませんね?
UMLからNoUMLというのは、青い鳥な図を探していると思う
http://blog.goo.ne.jp/xmldtp/e/8ee5111962a4e2067bf00dbc9a9234d6
の続きみたいな話。
ソフトウェア工学の傾向として、はじめの志はいいかもしれない。
でも、ある方法、理論ができてしまうと、今度、「その理論を守ればいいのね」というカタチになりがちだと思う。
ER図など
エンティティを作って、属性を埋めて、線(リレーション)でつなげばいいのよね
UMLだと、
UMLで書いて、図を埋めればいいのよね。
TDDだと
JUintで緑にすればいいのよね
しかし、これらは、本質的に違ってきてしまう。
たとえば、ER図をかくにしても、UMLをつくるにしても、お客さんの要望を聞いて、ステークホルダーが理解しやすくするためのモノだったけど、お客さんの要望を聞くことや、みんなの理解はさておき、図を書くことに集中してしまう。
この結果として、本質的な、「要望を聞く能力」や「理解してもらうために必要な能力」とかは、あまり研究されず、整理術、整理法とでも言うべき図の書き方などが発展し、いろいろな概念が出てくるが、肝心な部分が発展しにくくなってきていると思います。
う~ん、ソフトウェア工学は、違った方向に行っているのかもしれませんね?