项目周期模型选择

刘小备如何做项目－关于生命周期模型

2009-04-18 03:38:57| 分类：程序文摘| 标签：|字号大中小订阅

关键字: 软件工程生命周期模型

摘自：这里

文章不错，至少是从理论的角度，用通俗的语言讲述了软件工程木常见的“原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP”等软件过程。值得学习！

进行完软件估计后，刘小备开始启动下一阶段的工作选择软件生命周期，可供软件生命周期模型这么多，有原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP，还有什么“V”模型、“W” 模型，到底选择哪一种呢？刘小备想起来头大，索性就不想了，直接去找昔日故交孔小明，如今的孔小明已经是“孔氏项目管理咨询有限公司”的总经理，毕竟有前些年大大小小几十个项目的丰富经历，再加上孔小名扎实的软件开发理论功底，经过孔小明咨询的项目都取得了成功，虽然公司只有十几个人，“孔氏项目管理咨询有限公司”在业界也小有名气了，孔小明早就把他的羽毛扇送到博物馆去了，不离手的是有蓝牙/WLAN/GSM/GPRS/WCDMA的多模智能手机，代步的两轮车也换成了“奔驰2008”。刘小备到“孔氏项目管理咨询有限公司”时，正赶上孔小明给一家叫什么“新盛”的系统集成公司新接的一个千万级的项目做咨询结束，对方的公司老总握着孔小明的手不放，技术总监和项目经理也一脸崇拜的看着孔小明，孔小明很客气的把他们送走，然后转身把刘小备请进办公室。还没坐下刘小备就直奔主题（以下是两个人的对话，刘小备用刘代替，孔小明用孔代替）

刘：孔总，虽然我也做过几个项目，但对于生命周期模型一直也没有搞清楚孰优孰劣，所以在选择时往往是跟着感觉走，今天来就是想把这个问题彻底弄清楚，一劳永逸。

孔：在讲各种生命周期模型前，我想强调一下，任何项目，不管采用什么模型有四项活动都是必不可少的。不管是有意识还是无意识，这些活动都会出现在项目过程中。

刘：哪四项活动？

孔：就是需求、设计、编码和测试。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、还是风险管理、还是评审等等。

刘：哦！这个问题没有考虑过，不过你说出来再一想确实是这么回事。

孔：生命周期的定义咱们就不讨论了，我直接就常用的模型的优缺点和使用条件进行说明。

刘：太好了！

孔：我先说第一种：编码-修改模型。也称Code And Fix方法，是历史最悠久一种模型，从人类开始写程序的第一天这种模型就出现了，我们每个人开始学写程序时也不自觉的采用了这种模型。

刘：这个我知道了。这种模型没有规划、没有控制、开发过程混乱，软件质量完全依靠程序员个人的能力，后期基本不能维护，尤其是有人员变动，这应该是造成上世纪70年代软件危机的主要根源。

孔：即便在现在，这种模型也很有市场的，很多的中小型公司采用的仍然是这种开发模型。

刘：那是不是说，这个模型应该彻底的抛弃？

孔：那到不尽然。毕竟个人在开始学习编程时，这种方法是一个很好的选择，即使对于企业也不是完全不可取，比如有些项目对质量要求不高，但需要把东西攒起来，否则就丢单，这时如果在四平八稳的好好的规划和设计，那么到时候“黄瓜菜都凉了”。

刘：看来真是“尺有所短，寸有所长”

孔：原型法属于一种用户需求驱动的方法，首先根据技术人员对需求的理解构建一个系统，然后跟用户交流、进行测试，征集用户意见，根据用户意见进行修改，再跟用户交流……，直到用户满意位置。

刘：如果用户不专业，朝令夕改怎么办？

孔：你的担心是合理的。这也是这种方法的一个缺点。他的优点也和明显，能快速满足用户需求，用户早晨提的修改意见到晚上就可以看修改后的效果了，如果做好好，用户的满意度是比较高的。

刘：用户是上帝，如果用户满意了，那项目就成功了，如果这么来看，这种方法是一个很好的方法。

孔：你说对了一部分。还有另外一个缺点我还没说，由于这种方法就是“摸着石头过河”，缺乏对所开发系统的全面的、系统的认识，开发过程也没有规划，返工现象一般比较严重，如果在加上用户本身的成熟度比较低，那么这种做法最后的结果往往是费力不讨好。

刘：这样一说这种方法基本是一无是处了。

孔：也不是。它也有用武之地。比如系统规模比较小，容易把握和理解，此时用这种方法就是一个不错的选择，毕竟管理成本大大降低了。另外，原型法思想也可以跟其他软件生命周期模型结合，比如在其他比较复杂的生命周期中，在需求分析过程中，可以先搭建一个原型，用这个原型去跟用户交流，去把需求明确和细化。

刘：你太有才了：）。

孔：哈哈。咱们接下来说瀑布模型。瀑布模型应该是最经典的生命周期模型，为解决上世纪70年底的软件危机作出了很大的贡献，如果说原型发是用户需求驱动，那么瀑布模型可以说是文档驱动。它的优缺点也同样明显。

刘：愿闻其详。

孔：其优点为，阶段分明、活动明确，彻底改变了编码-修改方法和原型法的的混乱无序局面，同时开发过程中的文档也降低了沟通的成本，同时要求每一阶段是在上一阶段彻底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工。而且，在瀑布模型中的很多的过程、文档和方法，都是其他生命周期模型的很好的参考。

刘：这个模型我用的比较多，效果应该是比较不错，但离理想有一定差距，尤其是如果需求不稳定。

孔：这就是我要说的它的缺陷。主要有两点，第一是不能回溯（其实根本就不现实，尤其是在中国），第二是文档多，花费了很多的成本（当然，从整体来看，在开发过程中尤其到后期维护，这些文档的伟大性就体现出来了）。针对第一个缺陷，有人提出了改进瀑布模型，就是允许回溯，这样虽然更灵活了，但回溯必然带来返工，尤其到后期，越是前期的缺陷带来的返工就越大。

刘：我所做的大部分项目应该用的是改进瀑布模型。那么，瀑布模型的使用条件是什么？

孔：有三个前提。第一是需求稳定度比较高。第二是质量要求高。第三工期相对较充裕。

刘：很好，加深了我的认识，请继续往下说。

孔：如果说瀑布模型是完全串行，那么增量模型就引入了并行。可以根据系统功能，划分为多个增量，这多个增量可以并行进行开发，每个增量其实质就是一个瀑布模型。由于每个增量都不大，那么复杂度自然降低，需求变化对该增量的开发影响也见效很多。增量并行可分为全并行和部分并行，如果两个增量之间没有依赖关系，则可以全并行，如果有依赖关系则只能部分并行。