[软工]此EUP非彼EUP

去北京前,跟阿阮家的David 聊起RUP,David是IBM SCM的认证专家,常常会被邀请了去客户那里解决他们的配置管理问题,英文特帮,跟Ivar 非常熟悉。他忽然问我,是否有EUP的资料,我拍脑门说有,忙找给他,却发现,此EUP非彼EUP。

我的EUP,是2005年,scott ambler等人写的,主要目的,是作为RUP的补充,提供一个tailoring的框架(里面有若干的新的discipline);而David说的EUP,是Ivar 感觉UP太复杂,提出的一个精简的版本 (Essential UP)。这是Ivar在本次软件大会上的发言内容,据说,为了在中国推广,他甚至挖到了rational 中国的原总经理。。。

联想到Martin 的敏捷行,我们不难看出,越来越多的国外公司,看好中国的软件开发管理市场。这也从一个侧面,反映出我们的开发过程和方法还存在这样或者那样的问题。

partech说RUP不实用,我个人不是非常赞同,看一下RUP的定义就知道了,RUP是一个框架,这就意味着,RUP就是一个半成品(因为框架是一个半成品)。现在,我们可以找到很多RUP的plug-in ,这些Plug-in  包括 agile,xp,FDD。。。 因此,我还是比较倾向将RUP做为我们思考起点。

人们对RUP的垢病,大多聚集在产生太多的工件上,那么,让我们来看一下RUP自己怎么说:

economy of artifact

  • 1 只创建有用的artifact
  • 2 最好有工具支持
  • 3 使用工具创建形成snapshot --report
  • 4 将重点放在可以形成产品部分的工件上。

记得在DDD中,有一章,提出释意接口,梁问我,难点把类或者方法名字写得长点自然点,就可以做好交流工作吗?我想,这个问题,首先要从环境上来思考:在英语国度中,把类和方法写成自然语言的方式,当然可以促进交流了。在国内的环境中,这种交流效果是要打折扣的。如果,从代码上进行交流,效果打了折扣,那么,我们应该用什么来保证或者增强交流的效果呢?什么才是有用的工件呢?

我想这个问题,只能根据具体情况来回答了。因此,对RUP进行裁减,势在必行。

此EUP非彼EUP,但是殊途同归。经过tailoring 后的UP,会根植在中国广大开发团队中。

阅读更多
个人分类: 瞭望站
上一篇[领域]Party/PartyRole/Classification及其它...
下一篇[软工]近距离接触RUP plug-in
想对作者说点什么? 我来说一句

Andriod项目之"CJJ"系列教程(三)

2014年05月29日 16.64MB 下载

没有更多推荐了,返回首页

关闭
关闭