tuti http://tuti.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区 你做不做？做什么啊——软件工程（旧作留念） tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/210611  发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

曾泛泛地看过本叫《代码大全》的书，其他都没记住，只记得讲到一个类比的问题，即“软件的研发”和哪种人们比较熟知的事务有可比性，以便不熟悉软件研发的人（各级管理层，客户等）能够得到个大致合适概念。很多人都把“软件研发”类比成“房屋的建筑”，我也很同意这个类比。
在上海有很多在建的高楼大厦，路过那些工地，我常常会想：即便是100万行规模的软件研发，难道就比造一幢10来层的楼难度更大吗？ 虽然也有劣质的楼房，但我武断地认为，豆腐渣的软件系统要比豆腐渣的楼多得多。我常自问这是为什么。
我不知道，是否有刚入行2年的建筑工去主持厂房的设计建造。 但我知道常有
刚入行2年1年甚至几个月的人在担当软件项目的负责人。
我不知道，是否有心急的建筑商看不得设备的闲置，而在没有设计图纸的情况，就让施工队开始建筑“商务楼DEMO”。 但我常看见，管理精英们看不得资源的闲置，而在无研发设计的情况下，驱动研发团队先做个“商务软件DEMO”出来。
我不知道，是否常会有客户需要把3年的盖楼工程期，压缩到1年（新闻联播中到是常有）。但我常听到管理人员心急如焚地需要把3个月的研发时间，压缩到1个月。
昨晚在看《非程式员》第9期， Alan Cooper的访谈里面有段对话(翻译稿):
smilemac: 例如市场压力、预算、管理水平等等，这些都可能造成项目时间限制，许 多产品是他们之间相互妥协的结果。
alancooper: “...市场压力，预算...”，任何的都是管理者掩饰他对程式不了解的借口。
看似偏激，但我觉得说得是一语中的。现实这东西就是个样子，无论您如何臆想他，或忽视他，现实始终还在那里。而真正要面对现实是很不容易的，因为现实总是残酷的。而比现实更残酷的是，管理层往往都很激情洋溢地盘算着商业计划，他们信奉的是“跳一下才能完成的计划才是好计划”，至于您原来能达到哪里他却并不清楚。而研发人员几乎都是天生的乐观主义者，对于他们来说没有“Mission Impossible”。任务越是困难越含糊不清，越能激发他们克服困难的热情和所谓的创造自由度。这有点象我们这些单身汉在灯光昏暗的酒吧里看到一位线条突兀,衣着似露未露的性感MM，所激发得某种生理反应。而当一个相信电脑能算命的客户+ 激情洋溢的管理人员+ 一个（群）乐观向上的研发人员，基本上大概一幕悲剧的演员就全齐了，然后大家一起想象着项目会自然出落得丽质天成，结果多半是“为什么受伤的总是我"。
抱怨了半天，又要提到软件工程了。现在有这样一种情况，
每次项目挫折总结的时候，上上下下都会说“这是因为没有执行软件工程的原因”。
这时候“软件工程”就象是个大垃圾袋，任何令人讨厌的东西都能够往里扔。至于什么是软件工程，很多数人只怕只有个模糊的概念。多半自己也分不清“软件工程” 和“幸福生活”之间有什么区别。不少人站出来说：“软件工程就是要把研发中的一切文档化可交流可维护，而不要搞心口相传。” “要出一些什么样的文档呢？” 有不少人沉默了，仍然有一些勇敢的人站出来列出一串文档名列表，或拿出“CMM”或“RUP”的文档模板来。“那怎么才能填写好这些文档，并使这些文档的资料足以做为进一步研发的基石呢？"。“...”一片寂静。角落里有几个声音说到“找个咨询公司来做方案，或找个行业专家”。也许有人有这样的好运气，但对大多数项目来说，这几乎是要老鼠给猫去挂个铃铛,把一个问题偷换成另一个问题。
为什么一幢幢楼能建起来，而一个个软件项目在泥潭中挣扎下去。我只能说和建筑和其他产业相比，软件研发几乎没有工程。因为在如此短暂产业的时间里，还没有足够多的失败和教训来让大家摸索出一条被广为接受的工程方法来。请注意，总结出一是回事情，被大家知道是一回事，而被大家采纳执行就是完全不同的别的事情了。到幼儿园走一圈，我们可能知道健康的孩子是什么样，但我们却不知道怎么才能生出并养育个健康的孩子来。知道目的地，和知道如何到达目的地，也是完全不同的两件事情，虽然他们之间有关系。说到这里，突然想起那些信誓旦旦要在多久时间里，通过CMM X 级的老总们，即便他们生过孩子，只怕由于工作繁忙也没养过孩子。
出路何在呢？只有去试验、去试错，土法上马。代价是什么？代价就是痛苦和失败。软件工程方面的试验是困难的。一个人一台机器1、2个小时就能够试出一个 API的使用来,而4、5个人1、2个月也未见得，试出一个工程方法的优劣来。而在一个新软件工程方面的导入在初期，引起研发混乱度的增加也是很常见的，谁也无法确保某个别人行之有效的方法就一定适合您的项目团队。况且，也很少有哪个老板愿意给您个项目试着玩。难归难，日子还要过。有前辈说了：痛苦的经历是改善流程的源动力。
这里我推荐两本书,管不管用就看各人的造化了。
1.《软件需求》机械工业，书很薄，有操作性。薄书就能说清的事，为什么要去看厚书呢?
2.《软件创新之路》电子工业 . 程式写多的人应该看看。想以MS为模仿对象的人也该看看。
也许我们知道未来是怎么样，但不知道怎么样能活到未来。
鼠目寸光，挂一漏万，见笑见笑。


后记：
多年前写的篇东西，只是找个地方挂一下。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 02 Jul 2008 14:42:30 +0800 http://tuti.javaeye.com/blog/210611 http://tuti.javaeye.com/blog/210611 从金融学的角度看“重构” tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/190154  发表时间: 2008年05月06日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

前些日子在InfoQ看到篇文章 "抛砖引玉——重构是必要的浪费" http://www.infoq.com/cn/news/2007/12/refactoring-is-waste.
文中认为 “重构并不能为客户创造可衡量的价值。所以将重构归为必要的浪费。
个人觉得这样的解读很牵强，也有悖于精益的基本精神。

我觉得问题核心在于重构对于客户创造了什么价值。
近日从金融学的角度来进行分析，略有所悟。

重构其实提供了“需求变化”的“看多期权”（call）--事实上还提供了其他多种变化的看多期权。需求变化的可能性越大，这份期权就价值越高。而在金融市场上充满了明码标价的期权交易。

以TDD的三步骤(不可运行，可运行，重构)为例，可以看做实现一个功能的“现货价值”并附加该功能需求变化的“看多期权”。 而只完成功能要求程序，不进行重构，只能看单纯含有一个功能的“现货价值”。
对于客户而言，附加有“需求变化看多期权”的程序价值要高于只含“现货价值”的程序。
对于“需求变化看多期权”最坏的情况也就是“需求不变化”，这份期权就没必要行使。
这就是“需求稳定项目（如：学校大作业）”和“需求总是与时俱进的项目”在开发行为上存在差异的原因之一。

事实上，我觉得软件项目开发，充满了时间序列上的发生的不确定性，项目的过程中需要不断的吸收这种不确定性，并追求项目达到更高的价值。这种情况很适合以金融学的视角进行分析。


--------------------------------------------------------------------
有人回复EMAIL，做点补充：
引用
Steven Mak <stevenmak@gmail.com>
回复 agilechina@googlegroups.com
发送至 敏捷中国 <agilechina@googlegroups.com>

你說的其實跟文中其中一位討論者差不多呢:

-------------
Dec 18, 2007 1:13 PM by Kent Beck

While it's true that refactoring doesn't deliver features to
customers, features aren't the only source of value in software.
Another source of value is the option value of the software--software
that could be made to do any one of five things next is more valuable
than software that can only be made to do two things next. Refactoring
can add to the option value of software. This perspective can also
help teams select the most valuable refactorings out of the seemingly
infinite pool of possibilities. Perform refactorings that add to the
set of available and useful options, defer those that don't.




此回复是在出现在该文的英文版中 http://www.infoq.com/news/2007/12/refactoring-is-waste
提出的时间也要早得多，本来还以为想出点新意，却原来早有前人。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 06 May 2008 13:07:22 +0800 http://tuti.javaeye.com/blog/190154 http://tuti.javaeye.com/blog/190154 书摘--外交与爱国主义（标题自加） tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/188198  发表时间: 2008年04月29日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

今后中国外交一个较大的问题是，如何在保持必要的尊严的前提下，争取到一个较长的和平环境。由于自鸦片战争以来，西方列强对中国的百年欺凌给中国民众心理带来严重的扭曲，加之以这段历史为主的几十年的爱国主义思想的灌输，使得中国在处理与外部冲突时，外交上难以把握“合理的、必要的让步”和“摇尾乞怜、屈膝求和”之间的差别。这种因羞愤而严重扭曲的心理经常会影响外交策略的正确选择。

以国民政府抗战前的外交为例，在收回租界、关税等问题上，不知英、美、日在中国长远利益的差别，被对英美交涉成功而冲昏头脑，以没有国家实力（主要是军事实力）为前提的强硬姿态对日交涉，由于国家实力同所持有的强硬态度和预期目标存在极大差距，刺激、诱发了日本国内强硬派上台，不仅没有收回失地，反被占了东北，此时方知这是一场真正的实力较量，不是开会、游行、呼口号所能替代的，于是发现争取时间，增强国力才是当务之急，所以在“九一八事件”时采取“不抵抗政策”。但却难向充满爱国激情而失去理智的民众做出交代，被视作“卖国行为”，陷于内外被动的困境。笔者认为：当时情况下外交思路、策略得当的话，纵然日本侵略中国之心不死，中日战争不可避免，但争取20年的准备时间还是有可能的，20年或更长时间后，综合国力提高的情况下，中国抗战形势显然会有力得多。需要声明一点，笔者绝无为日本侵略中国的行径开脱之意，只是为了探讨当时在弱势对强势的情况下，弱势的中国是否在外交政策、策略上做到了最佳、最明智的选择？以便今天在同样是弱势对强势的中美格局中，提供一种经验和启示。历史的教训是：若把必要的妥协、暂时的让步在爱国主义情绪支配下等同于“屈膝投降”，将会招致国家利益更大的损失，并带来更大的屈辱。保持实力与强硬态度之间的合理平衡是外交艺术的核心问题，但在国家内部政治派别斗争激烈的情况下，一项合理的外交政策很难达成共识和付诸实施，并经常被歪曲。

摘自P20《寻找敌人--战争文化与国际军事问题透视》倪乐雄
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 29 Apr 2008 22:21:06 +0800 http://tuti.javaeye.com/blog/188198 http://tuti.javaeye.com/blog/188198 股市体会 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/182951  发表时间: 2008年04月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

tuti股市第一定理： 和老百姓一样肯定死路一条

tuti股市第二定理： 其他分析结果如与第一条冲突，以第一条为准

tuti股市第三定理： 和老百姓反向，也未必是活路
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 15 Apr 2008 16:28:55 +0800 http://tuti.javaeye.com/blog/182951 http://tuti.javaeye.com/blog/182951 书摘1--难道这就是传说中的pair programming tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/156163  发表时间: 2008年01月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

摘自 《质量.软件.管理--协调行动》
第19章 成长的团队 中文版P254

下面是Jensen的研究：
研究1.
当前有5个任务需要执行,这些任务的目的是建立一个30000行的军队标准的实时
执行系统。系统有一个领导者率领10个程序员创建。在这个项目之前,这些人的
平均效率是大约75行每人月。项目领导把他们分成5组，每组2个人并象征性地
发了一支铅笔。意思是让这些团队开发每一行代码并且和他的伙伴做文档记录。
结果是以每人175行每人月的速度完成了这个系统，并且错误数不到从前每人产
生的错误数量的1%。


注：根据书中提及，这项研究应该不晚于1980年。
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Tue, 15 Jan 2008 17:40:09 +0800 http://tuti.javaeye.com/blog/156163 http://tuti.javaeye.com/blog/156163 毫不含糊地反对结构性忽悠 (与钱有关2 ) tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/146924  发表时间: 2007年12月08日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

总有人忽悠我们说现在是结构性的物价上涨,言下之意这都没什么大不了的.
宣传部门的造词能力和对汉语丰富的所做出的贡献,令人叹为观止.

转载一篇"毫不含糊地反对通货膨胀"

http://www.zhouqiren.com/eco_56.html
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Sat, 08 Dec 2007 17:31:49 +0800 http://tuti.javaeye.com/blog/146924 http://tuti.javaeye.com/blog/146924 与钱有关 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/141810  发表时间: 2007年11月19日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

2007-11

目前国内的经济形势大多都可以归结到人民币汇率被低估.
为什么人民币汇率是被低估的呢, 看来当前世界其他经济体需要中国的东西,多于中国需要其他经济体。
这使得人民币特别对于美元有升值压力。
而在当前人民币对美元汇率缓步上升的情况下，造成了人民币对外升值，对内贬值的情形。
下面要怎么走呢？可能的几个方案：
1. 人民币加快升值速度。
2. 全面通货膨胀。
3. 股价继续上涨。
4. 楼价继续上涨。
5. 把资金引到境外。

 

2008-3

平安巨额融资，看来政策是要做大中国股市市值。

 

208-7

  看来通胀和股市成负相关


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Mon, 19 Nov 2007 16:51:32 +0800 http://tuti.javaeye.com/blog/141810 http://tuti.javaeye.com/blog/141810 Ajax 压力测试问题的一些讨论 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/66048  发表时间: 2007年03月28日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

tut 说:
请教个问题, 一个ajax的程序, 怎么做负载测试呢.  一般的都WEB负载测试工具,都是以form的request/response形式,但ajax很多异步的操作,好象不能那样干
神秘人X 说:
如果你用rails的话
神秘人X 说:
最简单的做法就是REST客户端
神秘人X 说:
ActiveResource，去跑，去压
tut 说:
是个gwt的程序
神秘人X 说:
这个也可以用form
神秘人X 说:
不过我不太了解gwt
神秘人X 说:
根本没用过....所以我也不知道怎么测....
tut 说:
其实是不是gwt都无所谓
神秘人X 说:
那你一样用form提交就好了
tut 说:
我本来想用你们那个Selenium那个
神秘人X 说:
那个做不了压力
tut 说:
但后来想,那个好象只能测单个
tut 说:
就比如说,做了个  类似C/S风格的ajax应用
tut 说:
一个response回来,只是会来很小一部分数据
tut 说:
大部分数据都是ajax异步调用返回的
tut 说:
比如说我现在用jmeter去做这个压力测试
tut 说:
我觉得就模拟不出来这个ajax的过程
神秘人X 说:
en，的确是很难
tut 说:
其实我主要遇到一个 负载问题, 一个目标400人同时在线会议系统
tut 说:
WEB会议系统
tut 说:
但只能撑到120人
tut 说:
按优化的做法
tut 说:
就要先做压力测试,找neck
tut 说:
但一个C/S ajax以后
tut 说:
这件事情就没想出来怎么做
tut 说:
到是觉得你们那个工具, 到是可以扩展成个AJAX压力负载测试的工具
tut 说:
因为AJAX调用往往基于比较复杂JS
神秘人X 说:
恩，有一个简单的办法
神秘人X 说:
以前我也实验国
神秘人X 说:
把selenium rc包装成jmeter的一个driver
神秘人X 说:
就可以了
神秘人X 说:
但是问题在于，取不到数据了
神秘人X 说:
你可以模拟，但是压力结果出不来
tut 说:
其实我也不要能给我很多统计数据,只要能模拟出 大量的AJAX客户端就可以
神秘人X 说:
后来从项目走了，也就没继续做
tut 说:
其实我也不要能给我很多统计数据,只要能模拟出 大量的AJAX客户端就可以
tut 说:
有了这个,我就可以实际登陆进去操作,直接感受效果
tut 说:
就可以知道改动是否有效


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 28 Mar 2007 13:52:54 +0800 http://tuti.javaeye.com/blog/66048 http://tuti.javaeye.com/blog/66048 使用Influence diagram 对房价进行分析 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/60108  发表时间: 2007年03月15日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

  先介绍一下Influence diagram

         影响图(Influence diagram ) 的理念源于Gerald Wenberg所著的绝佳的《Quality Software Management》系列图书，

        尤其是第一册《System Thinking》。

         影响图的目的是展示系统中一个因素对其他因素的影响。

          影响图有3个要素：
               活动，    用单词或短语标识。
               正连接，在两个活动之间用箭头标记；表示源活动越多，所造成的目的活动也越多，或者是源活动越少，所造成的目的活动也越少。
                负连接，在两个活动之间用带有园圈的箭头标志；表示源活动越多，目的活动越少，或者源活动越少，目的活动越多。

                                                                                                    以上 摘自 Kent Beck 《测试驱动开发》(中文版), 附录A, 影响图。

 中午与同事讨论房价的问题，觉得可以用 Influence diagram来揭示一下相关的因素的互动作用。

由此图可见，整个系统是一个正反馈系统。

如果坚持以增加“税收”和减少“土地供应量”为主要房价调控手段，那么只会推高房价，

而且在这些因素的互动中把房价推得更高。

如果希望降低房价，由此图分析，需要的是减少税收，和增加土地供应量。

 

也可将此法，纳入我们的项目管理工具箱之中。


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Thu, 15 Mar 2007 18:34:39 +0800 http://tuti.javaeye.com/blog/60108 http://tuti.javaeye.com/blog/60108 New Feature Review Question List (Draft) tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/59799  发表时间: 2007年03月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

听取一个客户的功能后,可以参考以下问题对功能进行审核.
审核重点在于该功能的来源,而非具体实现方式.

-------------------------------------------------
明确功能点所针对的问题来源
-------------------------------------------------
Q1. 谁是这个功能点的原始提出者?
Q2. 这个功能点期望解决一个什么问题?
Q3. 这个问题是谁(role)所面临的问题?
Q4. 目前的工作流程是如何处理这个问题的?

--------------------------------------------------
寻找问题点的解决方案
--------------------------------------------------
Q5. 已有的设计是否能解决这个问题?
Q6. 是否还有其他方式可以解决这个问题?


----------------------------------------------------
寻找解决方案带来的新问题
----------------------------------------------------
Q7. 采用某种解决方案后,带来什么样的新问题?(请列举3个新问题)

 

 
本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 14 Mar 2007 14:43:51 +0800 http://tuti.javaeye.com/blog/59799 http://tuti.javaeye.com/blog/59799 学一点 科学方法 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/58610  发表时间: 2007年03月14日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

程序开发人员，多被认为逻辑清晰，思维严密。

但由于教育内容安排的问题，只怕大都没有学习过“科学方法”方面的内容。

特别对于比较复杂的问题的讨论，时常也会有一些偏差。

这在网络论战中，时常可见。往往论战几方，文不对题，各说各话，无助于对问题的探求。

我自读过 张五常《经济解释》的第一章“科学的方法”后，大有醍醐灌顶之感，收益颇多。

起码对于不同的看法，可以更为本包容理解，不会简单将其对立起来。时常也可以警醒自己

不要步入逻辑的歧途之上。

书中的思想宝藏，只有亲身阅读方可汲取。

 


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Wed, 14 Mar 2007 00:16:00 +0800 http://tuti.javaeye.com/blog/58610 http://tuti.javaeye.com/blog/58610 风险控制工具 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/58603  发表时间: 2007年03月09日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

因为项目的原因,这几天在重读
《与熊共舞-软件项目风险控制》（Waltzing With Bears）--TomDeMarco,Timothy Lister.

第13章“软件项目的核心风险”中，根据采集到的大量数据,选出了5种核心风险：
1.进度安排的先天错误
2.需求变化
3.人员流失
4.规约崩溃
5.低生产率

更有实际意义的是,根据这5种核心风险的统计数据,
提供了项目预测的风险模拟器Riskology Simulator.

该工具可在http://www.systemsguild.com/riskology 下载.
该工具是个EXCEL表格,只需要输入
1.预测项目名字
2.项目开始时间
3.项目最乐观情况的完成时间
就可以计算出项目完成时间的可能性.
这次试用了一下，结果很有些意思。

大家可以把自己的项目数据输入,看看结果是否有借鉴意义.
也许对大家的项目计划安排，有所启发。


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 09 Mar 2007 14:07:07 +0800 http://tuti.javaeye.com/blog/58603 http://tuti.javaeye.com/blog/58603 谬种流传--瀑布模型 tuti 作者: tuti  链接：http://tuti.javaeye.com/blog/58602  发表时间: 2007年03月09日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

一些历史事实:

20世纪80年代
美国国防部(US Department of Defense,DoD)就针对软件开发颁布了标准DOD-STD-2167.
这是基于瀑布型与文档驱动的方法.有调查报告表明总成本370亿美元的项目样本中,75%的项目失败或者无法使用,
只有2%的项目能够不做进行一步修正就可使用.

1988年2月
改良的DOD-STD-2167A 发布, 该版本改进了2167标准,更加亲迭代开发(Iterative and Incremental Development (IID)).
由于军方后勤部门不同意,无法将瀑布型流程剔除.但该标准仍被许多人解释为优先采用瀑布型.

1994年12月
2167A被MIL-STD-498取代,该标准描述了递增式的构建,倡导渐进的需求和设计.

2000年
美国国防部颁发了新的软件项目"指导意见" DoD 5000.2,再次推荐渐进交付和IID的应用.

遗憾的是,STD-2167影响了其他国家的标准定义.这些国家还没有了解到DoD后来摒弃了2167标准和瀑布型.

为什么还有人在推行瀑布型?
"对于任何的复杂问题，都有一个简单干净但是错误的解决之道" H.L.Mencken


以上资料源自 Agile&Iterative Development A Manager's Guide-- Craig Larman


本文的讨论也很精彩，浏览讨论>>


JavaEye推荐



]]> Fri, 09 Mar 2007 14:03:50 +0800 http://tuti.javaeye.com/blog/58602 http://tuti.javaeye.com/blog/58602