没头没尾--项目开发笔记：UML，IDEF在我们项目中的失败应用 (转)

没头没尾--项目开发笔记：UML，IDEF在我们项目中的失败应用 (转)[@more@]

标题：没头没尾--项目开发笔记：UML，ideF在我们项目中的失败应用

关键词：分布式开发 C# 项目分工 UML IDEF

  11月21号：下午，有些感慨不吐不快

先声明，我是第一次做这种进销存项目的整体设计，以前多多少少用过一点UML，用过一点IDEF。不过都不精。

项目一开始我是试图用User case来画出用户的需求，然后兴致很高的和同志们一起讨论（我记得当时我先把几个大的模块定义出来，然后针对基础设置与一个单据的提交各做了一个User case的图。对应画了几张顺序图）。可以想向出来是什么回应吗？哈，我告诉你们，同志们的反应是：“哦…………，这玩意你应该去和客户说，和我们说干嘛？”；“这玩意太虚了！”；“我觉得我还是想看见一棵大树，可以知道我们一共要干多少事情！”。搞的我晕头转向。

然后我直接在白板上画了画总体的IDEF图，有位同志大欢喜，说：“这图好，这图好，这种图才说明问题呀！”。郁闷！

又花了三天把UML转成画IDEF0，给同志们讲了讲，然后大家看了看，谈了谈，然后就放在sourcesafe里没有人看了。

那么项目还是在按需求写出来的向下做，向下做…………。

从上面这点来看，从开始阶段我想项目实际上就已经有很多的问题，比如由于项目人员的组织中可能没有人很懂这些。（主要是我不懂业务，对UML与IDEF也是一知半解）。然后又试图在不当的场合去使用这样东东，（比如我试图拿这些图去给客户讲，我感觉客户的感觉就是，这小子在讲什么呀，这不都是我告诉他的，他又来告诉我干嘛？有病！）开发人员对这玩意也不感冒（靠，不画图我也能做，你的图我还要跳来跳去的看，我要做的你的图上又画不全，玩那虚的没用。）浪费了很多的时间。

没有时间去感慨为什么人家的工具用的好，我们咋就用不好，工程还是要向下走。一些契机使用采用了另一种开发方式。下一次我会对这个开发方式做个描述。

这里想谈一下我对开发这件事本身的感受。

l  开发使用的设计工具选择：

流行的说法是开发时用UML来整，传统的说法是用IDEF来整，可是你要是没有本事就别去用这些东东来做。能看懂需求，画出几个大家都看的懂的图就好，形式真的不重要。（特别是对小屁的公司，我们公司的需求业务水平极高，客户要什么他都清楚，不过你把你的理解用ROSE画出的case图给他们看，他们还是会说，这个是什么狗*……），如果你的文档要存档，有必要与其它人，其它的公司什么的进行交流，那么可能一定要用一种这类的东东来搞清思路。如果不是这样，老板又天天在屁股后问你的进度如何，程序员告诉你他看你那个图还要好几天才能完全的理解！！真的让我想骂娘。

l  开发目的

开发是为了什么？这个问题一定所有人都会有自己的回答。想听听我以前怎么跟我的一个当老板的朋友说的。“开发一个产品的目的就是要让客户满意，最低要满足客户的需求，最好是可以满足客户的期望！如果可能的话，可以把开发的经验存在公司，而不把开发的经验放在每个程序员身上”。当我还在对我说的这些深信不疑的时候，朋友告诉我：“小同志，我告诉你呀，如果你要认认真真的去做一个项目的话，是一定会赔钱的！！！！！”（巨寒）。一开始真是接受不了这句话，但是后来静下心来想想，其实如果这句话应该加上一个前提，这才是真理呀“如果你要去开发一个新的类型的项目，如果你开发完以后公司可能并不会再在这个方面发展自己的业务的话，那么你认认真真的去做一个项目是一定会赔钱的。”。这就是现实，如果你没有办法用关系搞来项目，而只能用你公司的技术力量来接这种类型的项目，你的前期投入是一定会赔钱的。我记不清楚我学这个半调子的UML用了多长时间，学会理解IDEF用了多长时间，不过如果在这种类型的公司，这种类型的项目中，我的感觉就是用这些还不如不用。不要被这些东东的美好的假象给蒙了。项目开发的目的是在于你可以在指定的时间做出一个客户要的东东，其它的先一边放。（靠，这样来当一个项目技术经理是不是太不负责了？！）

l  牢骚

还有就是要谈谈我对开发过程的理解了。如果看过上一篇的笔记的朋友应该了解。我对开发的划分从设计上来说就是两种，一种是面向业务的用户需求，一种是面向对象的数据库设计。然后要做的事说是把这两个东东联系起来。如果把这两个在实现上当做一对矛盾的话。为什么会出现这种矛盾？我们如果用CASE工具是不是可以解决这些矛盾？不能，从我的实践来看是不能。

RUP我看过几眼。但现在已经记不清楚了。不过我记得大概是把一次的开发分成需求、设计、开发、测试、实施这么几个过程，然后再做迭代的开发，进行这样的过程反复，以期达到客户需求。当我已经渐渐的把这个过程当成真理时，有一天我反问自己，为什么要经过这几个步骤？如果这个过程是完美的话，那么为什么还要迭代？是因为客户总在变化吗？还是因为一开始不能保证完全去理解需求，还是因为本身这个过程就有问题。中间我想过一些时间，这里就不去罗嗦了。反正极有可能是不对的。不过我想把我的结论与大家分享一下，如果大家有意见可以讨论。

1.  这个过程的假设前提是做这事的人在一开始完全不懂业务（至少这个过程的default值是开发的人不懂业务。）

2.  这个过程设计之初应该是基于我们已经非常的习惯用关系数据库来开发软件。面向对象的关系与关系数据库的关系是混然天成的。如果业务简单的都可以不用关系数据库呢？（这是个假设）

3.  做这种类型的项目总是思路上很不连贯，从需求来看看，用户要的是实现业务，然后设计的人员开始去提炼，找出对象，从对象中挖空心思来写数据库，这个范式那个范式的。写完了数据库，设计完事了开始写程序。写程序以前的过程是一人一块事，顶多有个人写中间的支持之类。这样搞就搞的每个人都会比较混乱，每一个开发阶段都有不同的任务，效率不高（特别是对小公司5555555）

4.  这些步骤其实非常明显的说明了一个问题，那就是在基于这种过程的开发中，我们最有把握的是从设计到实施的过程，最没有把握的是需求，用户的需要。这也是为什么我们要迭代开发之所在（不是技术问题，是业务问题。）开发过程所能解决的问题只是把你的数据存好，组织好。而不是将你的业务做好。这个过程一点都不爽。

5.  我总是不自觉得把自己当成一个不是程序员的角色，当我意识到如果我们只是提交给客户一个纯粹与彻底的面向对象的系统（包括界面，界面上只有一个对象叫XXX系统，点进去之后发现有一个对象叫单据，再点进去发现有一个对象叫采购单，再点去告诉你有一堆方法，其中一个叫做新增。点一下让你修改一堆属性…………），用户一定会说你是白痴。我不觉回头看看为什么我们要使用面向对象的技术。为什么？可以给一个答案是这样子，从七十年代的关系数据库的思路出来之后我们就被迫走到面向对象的路子上。满足程序员写出精彩程序的虚荣。满足sales要卖产品时需要说产品中应用了什么好的新的技术，而去忽略真正软件的意义。

 XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

牢骚也发了一通，发牢骚也解决不了问题，事情还是要接着干的。下一节我会写我们是采用什么过程来搞的。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-993141/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752043/viewspace-993141/