智心天空–Life In Blogcn

个人信息


zhaoshouzhong(zhaoshouzhong)
状态:
等级:
性别:男	年龄: 22
城市: 保密
签名:
加为好友	给我消息
评价好友

我的相册

最新日志

·软件核心竞争力(2006-01-12)

·微内核研究(2006-01-12)

·XPDL2.0正式版发布(2005-11-22)

·基于基线的版本管理和质量控制(2005-11-13)

·计划管理(2005-11-13)

我的评论

·访客167667(访客)/2006-11-03

·访客921058/2006-07-20

·访客248125/2006-03-27

·访客427256/2006-02-14

我的日历

我的链接

2005-10-31 18:51:53

谈瀑布模型和迭代模型

瀑布模型是应用较多，较为广泛的一种开发模型。一般的程序员都知道开发的几个阶段：需求、设计、开发、测试。早期的瀑布模型，是单方向的，即需求—〉设计—〉开发—〉测试。下一个阶段对上一个阶段没有反馈，要求上一个阶段的工作做得足够好。如需求要求一次做好后，就不需要再调整了。这种模式，缺点很多，已经不再使用了。
国内的软件开始时，最为常见的问题是需求难做，需求老是频繁变动。经常导致项目脱期，后期维护困难。有时候软件上线后，用户的需求还是调整来调整去，做到最后，项目成了烂摊子。
因此，改进后的瀑布模型，有了反馈途径。需求<—>设计<—>开发<—>测试。如测试发现问题后，如果是编码有问题，则反馈到开发人员。开发人员发现是设计的问题，就会找设计人员，设计人员如果发现是由于需求不明确引起的，就会找业务分析人员。
有了反馈，并不意味着万事大吉了，瀑布模型有个前提是，必须做好该阶段的工作，才能进入下一个阶段。即必须等需求全部做好后，才能进入设计阶段，而必须等设计做好后，才能进入开发阶段。其实，这时一种很理想的设想，开发中，我们很难做好需求，也很难一次性做好设计。举例来说，做设计时，普遍感觉设计很难写的很详细，就是写好了，开发时往往发现设计不够合理，或者考虑不周，需要重写设计文档。开发—发现设计不合理—修改设计—再开发—再次发现设计不合理—再次修改设计…….这样的过程往往反复多次，往往的结果是先开发，等开发完成后，在写设计的一个恶果。
当然，瀑布模型并不一无是处，如果软件产品已经开发出来，处于维护和功能增强阶段，我个人认为使用瀑布模型，还是很好的。如果新开发一个产品，瀑布模型不是很合适。
笔者参与制定的瀑布模型如下，可以供大家参阅一下：
客户需求整理（按照角色形成客户需求文档）—>编写开发需求（确定功能点和用户界面）—>编写设计（详细设计）—>编写测试用例—>开发—>开发人员单元测试—>测试人员单元测试和流程测试—>顾问测试—>QA抽查—>结束
每个阶段都需要审核后，才能进入下一个阶段。
注意：
1、需求分为两部分：客户需求和开发需求。给客户划分角色，整理每个角色的功能需求，是零散的客户需求整理，面向顾问和客户。开发需求，相当于需求分析。根据客户需求，确定要开发的功能点，用户阶段等元素，该需求面向开发人员。
2、界面部分，按照标准的软件定义，应该放到概要设计部分。而我们在实践中发现，界面部分用户往往调整较多，如果放到设计文档，界面调整时，需求和设计文档需要同步修改。因此，界面部分放到开发需求文档中
3、去掉概要设计阶段：写设计文档，比较难以把握设计写到什么程度。设计写的太详细了，就变成了详细设计，写简单了，往往描述不清楚。
4、设计完成后，马上写测试用例，而不是开发。这样可以验证需求和设计合理性。

当然，瀑布模型，不限于我描述的模式，可以根据实际开发需要，进行变通处理。

迭代模式，是Rational重点推荐的一种模式。它的一个核心理念是，项目开发要进行多次迭代。一个项目的开发，分为多个里程碑，每个里程碑进行一次需求、设计、开发、测试的迭代。
具体的资料可以参考： ::URL::

http://www-128.ibm.com/developerworks/cn/rational/products/rup/
应用迭代开发，首先要进行整体的项目规划，制定项目要达到的目标，产品应该具有的最终功能。然后根据实际需要，划分产品开发里程碑。
迭代开发和增量开发比较类似，他们都遵循“化整为零”的原则，路要一步步走，饭要一口一口吃。
但是迭代式开发有个弱点，如果控制不好，就变成了修修补补的开发模式。这样增加新的功能时，不是基于原有设计框架的新增，而是对原有功能的修补。而修补的开发，会经常大幅度修改原来已经开发好的代码，造成软件的质量不稳定和开发延期。
总结：任何开发模式，都有利有弊，关键在于如何应用。而不能一味的强调这个模式好，哪个模式不好。

标签: 瀑布模型,迭代模型

返回顶部