刘小备如何做项目-关于生命周期模型
进行完软件估计后,刘小备开始启动下一阶段的工作选择软件生命周期,可供软件生命周期模型这么多,有原型法、编码-修改法、传统瀑布、改进瀑布、增量、螺旋、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条原则组成,最大限度的减少与编码无关的工作,比如写需求分析文档、写设计文档,但分析、设计、编码和测试工作一个都不能少,同时项目计划、度量、配置管理、评审检查等在其他生命周期模型中很好的实践也都引入到该方法中,同时。
刘:这种方法很好。减少了文档工作量,编码效率会有提高,而且质量还有保证。你快说说这种方法的适用条件。
孔:该方法适用与小规模的团队,有的人说20人以下,有的人说10人以下,我倾向于后者。同时,由于没有产生文档,后期维护会比较麻烦,人员流动影响也比较大,虽然结对编程客观上做了人员的备份。
刘:哦,我明白了。你分析的太精彩了,让我从整体上对生命周期模型有了认识,多谢你的指点。今天还有事,改日谢你。
孔:No problem!
分享到:
相关推荐
对于采用不同软件生命周期模型的项目在实施CMM 当中遇到的实际问题及其产生机理进行了深入分析,并提出初步的解决方案,主要涉及:采用迭代式生命周期模型的项目在实施需求管理过程域的部分内容时难以满足CMM 的要求...
软件生命周期模型和项目开发过程有非常紧密关系,它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法,它按照软件生命周期的各个阶段划分任务,依照一定的规则和步骤,有效地进行软件开发。...
本文描述组织级定义的软件生命周期模型,供项目策划时根据项目的具体情况选择或裁剪使用,由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。 但是“所有的模型都是错误,有些模型是有用的”。模型是...
传统软件项目投标的风险评估往往局限在投标过程的某个阶段,且...实例分析表明:所建立的风险评估模型克服了主观判断的弊端,使投标者明确整个项目生命周期及生命周期各阶段的风险控制的重点领域,具有良好的适用性。
为了填补这一空白,该研究基于生命周期评估(LCA)和建筑信息模型(BIM),提出了一种估算建筑物生命周期碳排放量(BLCCE)的快速方法。 以中国安徽省Chu州市的一栋医院大楼为例,它检验了估计BLCCE的可能性。 结果...
瀑布型生命周期模型
软件生命周期中不含哪个阶段、关于瀑布模型说法正确的是、下面关于软件过程模型说法错误的是、软件项目计划中不需要制定下面哪个内容的方案、开发软件的高成本和软件产品的低质量之间的矛盾,这种现象称为、产生软件...
(a)软件生命周期模型 本人收藏了3年的资源 现放出 都是总结了很多系统 软件项目实施过程中的经验的 慢慢积累的
第4章 ASP.NET的网页代码模型及生命周期 从本章开始,就进入了ASP.NET应用程序开发的世界。在了解了C#的结构,以及面向对象的概念后,就可以从面向对象的思想开发ASP.NET应用程序。在ASP.NET中,能够使用面向对象的...
V模型是在快速应用开发模型基础上演变而来,由于将整个开发过程构造成一个V字形而得名。V模型适用于传统信息系统应用的开发,而一些高性能高风险的系统、互联网软件,或一个系统难以被具体模块化的时候,则不建议...
生命周期与组织结构的关系,以及二者如何相互影响
第二章软件生命周期与开发模型 软件企业选取软件生命周期模型的方法是:软件企业在创业时期,由于没有项目或产品的积累,所以他们常常会选取瀑布模型和增量模型。
项目生命周期管理研究毕业论文题目,项目管理论文
基于项目团队生命周期理论的全面激励模型研究,于文静,徐娟,根据项目团队生命周期理论,项目团队的发展会经历形成、震荡、正规和表现阶段。本文根据马斯洛层次需求理论、双因素理论、理性经
为了有效揭示项目生命周期管理的内在作用机理,把价值链的概念引入项目管理,建立项目生命周期管理价值链模型,分析了项目生命周期内价值源泉、价值创造、价值评价及价值分配的全过程,结果表明,项目发展的全过程贯穿着...
传统软件生命周期模型资料,适合传统行业
信息系统项目管理师生命周期模型:瀑布模型、螺旋模型、V模型、迭代模型、增量模型。职能型、项目型、矩阵型组织结构;
从科技项目全生命周期的视角出发,提出了科技项目后评价概念模型,研究了项目的目标、实施过程、影响和效益、可持续性等主要后评价内容,以期为科技项目全过程管理和后评价工作的开展提供参考和借鉴。
Maven非常强大的重要原因是它有十分完善的生命周期模型 lifecycle 这个生命周期可以从两方面来理解 第一 顾名思义 运行Maven的每个步骤都由它来定义的 这种预定义的默认行为使得我们使用Maven变得简单 相比而言 Ant...
20世纪上半叶,程序化计算机的使用量变得巨大。 结果,软件编程变得越来越不同和复杂。... 此外还研究了迭代推进技术,我们还将推进生命周期模型与编程设计中两个新兴领域的关联复杂化:编程设计和基于部件的编程推进。