项目周期模型选择.doc

刘小备如何做项目关于生命周期模型2009-04-18 03:38:57|分类： 程序文摘 |标签： |字号大中小订阅 关键字: 软件工程 生命周期模型 摘自：这里 文章不错，至少是从理论的角度，用通俗的语言讲述了软件工程木常见的“原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP”等软件过程。值得学习！ 进行完软件估计后，刘小备开始启动下一阶段的工作选择软件生命周期，可供软件生命周期模型这么多，有原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、RUP、XP，还有什么“V”模型、“W” 模型，到底选择哪一种呢？刘小备想起来头大，索性就不想了，直接去找昔日故交孔小明，如今的孔小明已经是“孔氏项目管理咨询有限公司”的总经理，毕竟有前些年大大小小几十个项目的丰富经历，再加上孔小名扎实的软件开发理论功底，经过孔小明咨询的项目都取得了成功，虽然公司只有十几个人，“孔氏项目管理咨询有限公司”在业界也小有名气了，孔小明早就把他的羽毛扇送到博物馆去了，不离手的是有蓝牙/WLAN/GSM/GPRS/WCDMA的多模智能手机，代步的两轮车也换成了“奔驰2008”。刘小备到“孔氏项目管理咨询有限公司”时，正赶上孔小明给一家叫什么“新盛”的系统集成公司新接的一个千万级的项目做咨询结束，对方的公司老总握着孔小明的手不放，技术总监和项目经理也一脸崇拜的看着孔小明，孔小明很客气的把他们送走，然后转身把刘小备请进办公室。还没坐下刘小备就直奔主题（以下是两个人的对话，刘小备用刘代替，孔小明用孔代替） 刘：孔总，虽然我也做过几个项目，但对于生命周期模型一直也没有搞清楚孰优孰劣，所以在选择时往往是跟着感觉走，今天来就是想把这个问题彻底弄清楚，一劳永逸。 孔：在讲各种生命周期模型前，我想强调一下，任何项目，不管采用什么模型有四项活动都是必不可少的。不管是有意识还是无意识，这些活动都会出现在项目过程中。 刘：哪四项活动？ 孔：就是需求、设计、编码和测试。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、还是风险管理、还是评审等等。 刘： 哦！这个问题没有考虑过，不过你说出来再一想确实是这么回事。 孔：生命周期的定义咱们就不讨论了，我直接就常用的模型的优缺点和使用条件进行说明。 刘：太好了！ 孔：我先说第一种：编码-修改模型。也称Code And Fix方法，是历史最悠久一种模型，从人类开始写程序的第一天这种模型就出现了，我们每个人开始学写程序时也不自觉的采用了这种模型。 刘：这个我知道了。这种模型没有规划、没有控制、开发过程混乱，软件质量完全依靠程序员个人的能力，后期基本不能维护，尤其是有人员变动，这应该是造成上世纪70年代软件危机的主要根源。 孔：即便在现在，这种模型也很有市场的，很多的中小型公司采用的仍然是这种开发模型。 刘：那是不是说，这个模型应该彻底的抛弃？ 孔：那到不尽然。毕竟个人在开始学习编程时，这种方法是一个很好的选择，即使对于企业也不是完全不可取，比如有些项目对质量要求不高，但需要把东西攒起来，否则就丢单，这时如果在四平八稳的好好的规划和设计，那么到时候“黄瓜菜都凉了”。 刘：看来真是“尺有所短，寸有所长” 孔：原型法属于一种用户需求驱动的方法，首先根据技术人员对需求的理解构建一个系统，然后跟用户交流、进行测试，征集用户意见，根据用户意见进行修改，再跟用户交流，直到用户满意位置。 刘：如果用户不专业，朝令夕改怎么办？ 孔：你的担心是合理的。这也是这种方法的一个缺点。他的优点也和明显，能快速满足用户需求，用户早晨提的修改意见到晚上就可以看修改后的效果了，如果做好好，用户的满意度是比较高的。 刘：用户是上帝，如果用户满意了，那项目就成功了，如果这么来看，这种方法是一个很好的方法。 孔：你说对了一部分。还有另外一个缺点我还没说，由于这种方法就是“摸着石头过河”，缺乏对所开发系统的全面的、系统的认识，开发过程也没有规划，返工现象一般比较严重，如果在加上用户本身的成熟度比较低，那么这种做法最后的结果往往是费力不讨好。 刘：这样一说这种方法基本是一无是处了。 孔：也不是。它也有用武之地。比如系统规模比较小，容易把握和理解，此时用这种方法就是一个不错的选择，毕竟管理成本大大降低了。另外，原型法思想也可以跟其他软件生命周期模型结合，比如在其他比较复杂的生命周期中，在需求分析过程中，可以先搭建一个原型，用这个原型去跟用户交流，去把需求明确和细化。 刘：你太有才了 ：）。 孔：哈哈。咱们接下来说瀑布模型。瀑布模型应该是最经典的生命周期模型，为解决上世纪70年底的软件危机作出了很大的贡献，如果说原型发是用户需求驱动，那么瀑布模型可以说是文档驱动。它的优缺点也同样明显。 刘：愿闻其详。 孔：其优点为，阶段分明、活动明确，彻底改变了编码-修改方法和原型法的的混乱无序局面，同时开发过程中的文档也降低了沟通的成本，同时要求每一阶段是在上一阶段彻底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工。而且，在瀑布模型中的很多的过程、文档和方法，都是其他生命周期模型的很好的参考。 刘：这个模型我用的比较多，效果应该是比较不错，但离理想有一定差距，尤其是如果需求不稳定。 孔：这就是我要说的它的缺陷。主要有两点，第一是不能回溯（其实根本就不现实，尤其是在中国），第二是文档多，花费了很多的成本（当然，从整体来看，在开发过程中尤其到后期维护，这些文档的伟大性就体现出来了）。针对第一个缺陷，有人提出了改进瀑布模型，就是允许回溯，这样虽然更灵活了，但回溯必然带来返工，尤其到后期，越是前期的缺陷带来的返工就越大。 刘：我所做的大部分项目应该用的是改进瀑布模型。那么，瀑布模型的使用条件是什么？ 孔：有三个前提。第一是需求稳定度比较高。第二是质量要求高。第三工期相对较充裕。 刘：很好，加深了我的认识，请继续往下说。 孔：如果说瀑布模型是完全串行，那么增量模型就引入了并行。可以根据系统功能，划分为多个增量，这多个增量可以并行进行开发，每个增量其实质就是一个瀑布模型。由于每个增量都不大，那么复杂度自然降低，需求变化对该增量的开发影响也见效很多。增量并行可分为全并行和部分并行，如果两个增量之间没有依赖关系，则可以全并行，如果有依赖关系则只能部分并行。 刘：部分并行，不太好理解。 孔：比如A和B两个增量，B依赖与A，那么B的需求分析活动，必须至少在A的需求分析活动结束后才能启动。这就是部分并行。如果A和B没有什么关系，那么A和B可以通信进行需求分析、然后同步进行设计，这就是全并行。 刘：这个方法不错，在人手充裕的情况下，通过并行能缩短工期。 孔：没错。但这种方法需要有可执行的底层的框架。如果没有，那么其第一个增量版本，必须实现这个可执行的底层框架。而且因为多个增量并行，增加了管理的复杂度。 刘：越来越复杂了。 孔：是啊。（先画了那张最经典的螺旋模型图）螺旋模型是风险驱动的模型。项目本身有很多的不确定因素、很多的限制和约束、很多的假设条件，所有这些都有可能导致项目的失败。螺旋模型，把风险分析放到最重要的位置，增大了项目成功的可能性。沿螺旋进行若干次迭代。每个迭代包括四个阶段：制定计划、分析风险、实施工程、评估成果。一般做三次迭代，第一次关注需求，第二次关注高层设计，第三次实现（详细设计、编码和测试工作）。 刘：我看你的那个图就晕了。你还是讲讲它的缺点吧。 孔：这个模型本身强调风险，但客户往往是不认可的。而且，风险管理本身也是有成本的，如果风险管理成本过大，严重影响项目利润，那么此时的风险管理还是不做的好。同时，对项目组成员的要求-尤其在风险分析方面很高，需要他们有丰富的经验。 刘：这种模型等我回去再好好的学习一下吧。你接着往下说吧。 孔：RUP应该说是最复杂的一种软件生命周期模型了。对它理解很深的人就更少了，很多的人一知半解就狂吹这种方法怎么怎么样？关于RUP，如果要讲透了，需要几天的时间，今天我把这种方法的框架、优缺点给你说一下。 刘：也好。 孔：（先画了那张最经典的RUP模型图）RUP是以用例为驱动、以架构为核心、以迭代为方法的一种开发模式。实现瀑布与增量模型的有机结合。RUP在横向把项目分成初始、细化、构造、交付四个阶段，在纵向分成6个核心工作流和3个辅助工作流，核心工作流包括建模、需求、分析和设计、实现、测试和部署，3个辅助工作流包括配置和变更管理、项目管理和环境。每个阶段也有很多的交付件。 刘：确实很复杂。不仅过程复杂，而且也需要很多的文档。这种方法的好处是什么？ 孔：RUP采用多次迭代，每次迭代时间都不长，但都形成一个可执行版本，在中间过程中能及时发现功能问题和性能问题，并及时进行调整；可以在开发早期就可以确定风险并及早规避；用户需求的明确是一个逐步的过程，采用RUP可以很好的适应需求的调整和变化。它的缺点同样很明显，管理难度和管理成本增加，如果新引入，那么项目组的学习成本也很高，大量的文档也增加了项目的工作量。 刘：那么什么情况下，采用这种模型呢？ 孔：在系统规模大、复杂度高、用户需求不能在前期明确、质量要求和进度要求都比较高的情况下，这是一个不错的选择。 刘：哦。最后你再给我简单讲讲XP吧。 孔：刚才，你看到了，软件生命周期模型越来越复杂，管理难度越还越高，中间产品越来越多，XP就是本着去繁化简的原则而产生的，XP是以代码为驱动的，主张以“简洁、高效、持续及合作”的方式进行软件开发。它由包括“结对编程，每日构建”内的12条实践和包括“沟通、简单、反馈和勇气”在内的4条原则组成，最大限度的减少与编码无关的工作，比如写需求分析文档、写设计文档，但分析、设计、编码和测试工作一个都不能少，同时项目计划、度量、配置管理、评审检查等在其他生命周期模型中很好的实践也都引入到该方法中，同时。