软件开发过程管理.ppt

《软件开发过程管理.ppt》由会员分享，可在线阅读，更多相关《软件开发过程管理.ppt（120页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、华中科技大学软件学院华中科技大学软件学院 THE SCHOOL OF SOFTWARE ENGINEERING OF HUST第第 3 章章 软件开发过程管理软件开发过程管理 2THE SCHOOL OF SOFTWARE ENGINEERING OF HUST本章内容提要本章内容提要CMMCMM和和ISO9000ISO9000 传统软件开发生命周期模型传统软件开发生命周期模型 扩展软件开发生命周期模型扩展软件开发生命周期模型 3.1质量计划质量计划 3.4案例分析案例分析 3.5本章小结本章小结 3.6复习思考题复习思考题 3.73.23.33THE SCHOOL OF SOFTWARE E

2、NGINEERING OF HUSTn 软件过程软件过程是指人们用于开发和维护软件及其相关产品的一系列活动、方是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。法、实践和革新。n 软件开发过程管理软件开发过程管理是指在软件开发过程中，除了先进技术和开发方法外，还有一是指在软件开发过程中，除了先进技术和开发方法外，还有一整套的管理技术。整套的管理技术。n 软件过程改进软件过程改进是针对软件生产过程中会对产品质量产生影响的问题而进行的，是针对软件生产过程中会对产品质量产生影响的问题而进行的，它的直接结果是软件过程能力的提高。它的直接结果是软件过程能力的提高。现在常见的软件过程改

3、进方法：现在常见的软件过程改进方法：ISO 9000，SW-CMM和由多和由多种能力模型演变而来的种能力模型演变而来的CMMI。3.1 CMM和和ISO9000 4THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.1 SW-CMM和和CMMI nSW-CMMSW-CMM简介简介 为了保证软件产品的质量，为了保证软件产品的质量，19911991年美国卡内基年美国卡内基梅隆大学软梅隆大学软件工程研究所（件工程研究所（CMU/SEICMU/SEI）将软件过程成熟度框架进化为软件能）将软件过程成熟度框架进化为软件能力成熟度模型（力成熟度模型（Capabilit

4、y Maturity Model For SoftwareCapability Maturity Model For Software，简，简称称SW-CMMSW-CMM），并发布了最早的），并发布了最早的SW-CMM 1.0SW-CMM 1.0版。版。SW-CMMSW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。，阶梯共有五级。5THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.1 SW-CMM和和CMMI 1 初始级2 可重复级3 已定义级4 已管理级5 优化级无序、混乱的软件过

5、程。依赖个别人的努力和机遇。建立基本的项目管理过程。相似项目，重复以往成果。文档化、标准化和标准的软件软件过程。软件过程和产品质量有详细的度量标准。持续的对过程进行改进。图 CMM分级标准6THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.1 SW-CMM和和CMMI n KPA KPA及及KPKP除第一级外，除第一级外，SW-CMM的每一级都是按完全相同的结构组成的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域（的。每一级包含了实现这一级目标的若干关键过程域（KPA），每），每个个KPA进一步包含若干关键实施活动（进一步

6、包含若干关键实施活动（KP），无论哪个），无论哪个KPA，它，它们的实施活动都统一按六个公共属性进行组织，即每一个们的实施活动都统一按六个公共属性进行组织，即每一个KPA都包都包含六类含六类KP：1. 目标目标2. 实施保证实施保证3. 实施能力实施能力 4. 执行活动执行活动 5. 度量分析度量分析6. 实施验证实施验证7THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.1 SW-CMM和和CMMI n CMMI CMMI简介简介由于不同领域能力成熟度模型存在不同的过程改进，重复的由于不同领域能力成熟度模型存在不同的过程改进，重复的培训、评估和改进活

7、动以及活动不协调等一些问题。于是由美国培训、评估和改进活动以及活动不协调等一些问题。于是由美国国防部出面，美国卡内基国防部出面，美国卡内基梅隆大学软件工程研究所（梅隆大学软件工程研究所（CMU/SEI）于）于2001年年12月发布的月发布的CMMI 1.1版本包括四个领域：软件工程版本包括四个领域：软件工程（SW）、系统工程（）、系统工程（SE）、集成的产品和过程开发（）、集成的产品和过程开发（IPPD）、）、采购（采购（SS）。）。8THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.1 SW-CMM和和CMMI n CMMICMMI有两种不同的实施方

8、法有两种不同的实施方法n连续式主要是衡量一个企业的项目能力连续式主要是衡量一个企业的项目能力n阶段式主要是衡量一个企业的成熟度阶段式主要是衡量一个企业的成熟度连续式与阶段式所包含的过程域是完全一致的。两者的区别主要在于过程域的组织方式不同，阶段式是用来描述组织整体上的成熟度，而连续式关注的是组织单个过程域的能力。如果组织注意力主要集中在某几个过程域上时，则采用连续式比较合适9THE SCHOOL OF SOFTWARE ENGINEERING OF HUSTn CMMICMMI的五个台阶的五个台阶n 完成级完成级n 管理级管理级 n 定义级定义级 n 量化管理级量化管理级 n 优化级优化级 n

9、 每一个台阶都是上面一阶台阶的基石。要上高层每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶台阶必须首先踏上较低一层台阶。 10THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 与与SW-CMM 的结构相比，的结构相比， CMMI 的模型结构显得更的模型结构显得更加复杂与精细。加复杂与精细。 CMMI 从过程域所有的实践提炼出从过程域所有的实践提炼出了多个过程域所共有的实践，称为一般实践，将其目了多个过程域所共有的实践，称为一般实践，将其目标称为一般目标，其余特定于某个过程域的实践与目标称为一般目标，其余特定于某个过程域的实践与目标称为

10、特定实践与特定目标。这样模型取得了相对标称为特定实践与特定目标。这样模型取得了相对 SW-CMM 更高的抽象度与适应范围。更高的抽象度与适应范围。 目标（一般目标与特定目标）首次作为模型构成成分目标（一般目标与特定目标）首次作为模型构成成分出现，这表明出现，这表明CMMI 对过程活动的结果投入了更多的对过程活动的结果投入了更多的关注。关注。 11THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.2 ISO9000质量标准质量标准 n ISO9000ISO9000 所谓所谓“ISO9000”不是指一般意义上的一个质量保证标准，而是一不是指一般意义上的一个

11、质量保证标准，而是一族系列标准的统称。族系列标准的统称。 n作用作用强化品质管理，提高企业效益；增强客户信心，扩大市场份强化品质管理，提高企业效益；增强客户信心，扩大市场份额；额；获得了国际贸易获得了国际贸易“通行证通行证”，消除了国际贸易壁垒；，消除了国际贸易壁垒；节省了第二方审核的精力和费用；节省了第二方审核的精力和费用；在产品品质竞争中永远立于不败之地；在产品品质竞争中永远立于不败之地；有效地避免产品责任；有效地避免产品责任；有利于国际间的经济合作和技术交流。有利于国际间的经济合作和技术交流。12THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.1.

12、3 三者之间的比较三者之间的比较 n 选择选择SW-CMMSW-CMM还是还是CMMICMMI的考虑的考虑实施企业的业务特点。实施企业的业务特点。实施企业的业务特点：实施企业的业务特点： 如果企业的规模不是很大，业务又集中在如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较适用。如果企业的规模比较大（开发人员比较大（开发人员100人以上），并且业务不仅仅集中在软件开人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。13T

13、HE SCHOOL OF SOFTWARE ENGINEERING OF HUST 实施企业对过程改进的熟悉程度：实施企业对过程改进的熟悉程度： 如果企业已经实如果企业已经实施过施过ISO 9000，并且取得了较好的效果，那么可以，并且取得了较好的效果，那么可以考虑实施考虑实施CMMI。如果企业虽然没有实施过。如果企业虽然没有实施过CMM，但，但是对于过程改进一直比较关注，接受过不少相关培训是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考，甚至能够自发的进行一些过程改进，那么也可以考虑实施虑实施CMMI。如果过去没有接触过类似的工作，那。如果过去没有

14、接触过类似的工作，那么最好先从软件么最好先从软件CMM 2级开始，首先建立持续过程级开始，首先建立持续过程改进的思路。另外，软件改进的思路。另外，软件CMM的要求也比的要求也比CMMI要稍要稍低一些。可以适当降低实施的难度低一些。可以适当降低实施的难度14THE SCHOOL OF SOFTWARE ENGINEERING OF HUST实施企业对过程改进的熟悉程度。实施企业对过程改进的熟悉程度。实施企业对过程改进的熟悉程度：实施企业对过程改进的熟悉程度： 如果企业已经实施过如果企业已经实施过ISO 9000，并且，并且取得了较好的效果，那么可以考虑实施取得了较好的效果，那么可以考虑实施CMM

15、I。如果企业虽然没有实施。如果企业虽然没有实施过过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过。如果过去没有接触过类似的工作，那么最好先从软件去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建级开始，首先建立持续过程改进的思路。另外，软件立持续过程改进的思路。另外，软件CMM的要求也比的要求也比CMMI要稍低一要稍低一些。可以适当降低实施的难度些。可以适当降低实施的难度15THE SCHOOL OF

16、SOFTWARE ENGINEERING OF HUST实施企业对过程改进项目的预算。实施企业对过程改进项目的预算。实施企业对过程改进项目的预算：实施企业对过程改进项目的预算： 不论怎样，几乎可以肯定地说，实施不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施的费用肯定要比实施CMM高出一些。而就模型本身来看，高出一些。而就模型本身来看，CMMI的的2级级7个过程区域在内容上并不比软件个过程区域在内容上并不比软件CMM的的2级级6个关键过程区域多个关键过程区域多多少。这样的话，我们完全可以多少。这样的话，我们完全可以“少花钱、多办事少花钱、多办事”，也就是说可以，也就是说可以采用采用C

17、MM的实施和评估方法，但可以在过程改进的时候参考的实施和评估方法，但可以在过程改进的时候参考CMMI的的要求，这样就经济很多。要求，这样就经济很多。16THE SCHOOL OF SOFTWARE ENGINEERING OF HUST -实施企业是否可以使用阶段式的演进路线实施企业是否可以使用阶段式的演进路线 ： 如果企业只希望单方面的提高自己在项目管理、如果企业只希望单方面的提高自己在项目管理、工程活动、支持活动或者过程管理四个方面中的某些工程活动、支持活动或者过程管理四个方面中的某些方面的能力，那么就只能应用方面的能力，那么就只能应用CMMI的连续表示方法的连续表示方法。如果实施企业可以

18、接受成熟度级别的思路（目前看。如果实施企业可以接受成熟度级别的思路（目前看国内大多数企业还是比较习惯于成熟度级别的），那国内大多数企业还是比较习惯于成熟度级别的），那么就不一定必须选择么就不一定必须选择CMMI了。了。17THE SCHOOL OF SOFTWARE ENGINEERING OF HUST-实施实施CMM与与CMMI可以平滑的转换。可以平滑的转换。 CMMI并不要求一家企业必须先做并不要求一家企业必须先做CMMI的的2级然后再级然后再向更高的成熟级别演进，评估的时候也没有这样的要向更高的成熟级别演进，评估的时候也没有这样的要求。求。 另外，另外， CMMI的评估都会根据被评估的

19、成熟度级别，的评估都会根据被评估的成熟度级别，检查所有不高于该级别的过程区域。换句话说，一个检查所有不高于该级别的过程区域。换句话说，一个企业在企业在CMM正式评估中达到了正式评估中达到了2级的成熟度，将来改级的成熟度，将来改为基于为基于CMMI进行过程改进。在进行过程改进。在CMMI 3级的正式评级的正式评估时，估时，CMMI 2级的内容同样要进行检查。如果我们级的内容同样要进行检查。如果我们能够在做能够在做CMM 2级的时候就按照级的时候就按照CMMI的要求实施，的要求实施，效果没有任何的折扣，但对于实施企业来说，会节省效果没有任何的折扣，但对于实施企业来说，会节省很多在培训和评估方面的很

20、多在培训和评估方面的“额外额外”费用。（此处的费用。（此处的“额外额外”费用是指费用是指CMMI收费比收费比CMM高出的部分）高出的部分）18THE SCHOOL OF SOFTWARE ENGINEERING OF HUSTn ISO9001ISO9001与与CMMCMM的关系的关系ISO9001和和CMM既有区别又相互联系，两者不可简单地互相替既有区别又相互联系，两者不可简单地互相替 代。代。取得取得ISO9001认证并不意味着完全满足认证并不意味着完全满足CMM某个等级的要求。某个等级的要求。取得取得CMM第第2级级(或第或第3级级)不能笼统地认为可以满足不能笼统地认为可以满足ISO90

21、01的要求。的要求。19THE SCHOOL OF SOFTWARE ENGINEERING OF HUST案例案例1 W公司为了推行公司为了推行CMM，组建了独立的，组建了独立的QA部门。尽管部门。尽管在在W公司的内部宣传材料上对公司的内部宣传材料上对QA的作用进行了大肆的作用进行了大肆的宣传，认为其对于的宣传，认为其对于CMM的推行和项目管理都具有的推行和项目管理都具有重要作用，但是实际上重要作用，但是实际上QA人员的资历都相对较浅，人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不

22、认照搬一些条文来要求开发人员，开发人员对此并不认账，认为账，认为QA人员是没事找事。另外，人员是没事找事。另外，QA这个岗位在这个岗位在薪酬和升迁方面毫不吸引人薪酬和升迁方面毫不吸引人20THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 为了避免为了避免QA部门成为新手和项目组淘汰人员的集中部门成为新手和项目组淘汰人员的集中地，地，QA部门经理设法推行项目经理锻炼制度，让项部门经理设法推行项目经理锻炼制度，让项目经理到目经理到QA部门锻炼一段时间，然后继续担任项目部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支经理或者升迁。但

23、是因为此项制度没有得到有效的支持，项目经理在持，项目经理在QA部门工作一段时间以后竟然没有部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。开发部门愿意接收，就更谈不上升迁了。QA部门在部门在W公司的威望江河日下。公司的威望江河日下。21THE SCHOOL OF SOFTWARE ENGINEERING OF HUST QA人员对于质量保证和人员对于质量保证和CMM的实施至关重要，如果的实施至关重要，如果我们认可我们认可QA人员对于公司的价值，那就必须在人才人员对于公司的价值，那就必须在人才和待遇上向和待遇上向QA部门倾斜部门倾斜22THE SCHOOL OF SOFTWARE

24、 ENGINEERING OF HUST H公司和公司和Z公司都在研发相同类型的公司都在研发相同类型的C产品。产品。H公司在公司在推广推广CMM，采用了相对严格的过程规范，并且把相，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的对重要的部分外包给了印度的CMM5级公司。这些手级公司。这些手段段Z公司都没有采用，但是公司都没有采用，但是Z公司却抢在了前面。公司却抢在了前面。Z公司的公司的“秘密武器秘密武器”是一种形式化语言是一种形式化语言SDL，Z公司采用公司采用SDL作为设计工具，这样作为设计工具，这样C产品的相当一部产品的相当一部分代码可以由分代码可以由SDL工具自动生成，而且

25、在设计阶段就工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。了缺陷。H公司虽然采用了相对严格的过程规范，但公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是是因为全部代码为手工编制，所以，无论是效率还是质量，质量，H公司都落后了公司都落后了23THE SCHOOL OF SOFTWARE ENGINEERING OF HUST H公司显然忽视了先进技术可能为生产率带来的进步公司显然忽视了先进技术可能为生产率带来的进步，通过了，通过了CMM高级别的评估，只能说明被评估的组高级别的评估

26、，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于证你的开发过程是高效的。某些沉迷于CMM的组织的组织机构忘记了先进的软件工程技术的重要性机构忘记了先进的软件工程技术的重要性24THE SCHOOL OF SOFTWARE ENGINEERING OF HUST本章内容提要本章内容提要CMMCMM和和ISO9000ISO9000 传统软件开发生命周期模型传统软件开发生命周期模型 扩展软件开发生命周期模型扩展软件开发生命周期模型 3.1质量计划质量计划 3.4案例分析案例分析 3.5本章小结本章小结

27、3.6复习思考题复习思考题 3.73.23.325THE SCHOOL OF SOFTWARE ENGINEERING OF HUSTn软件生命周期软件生命周期软件从需求确定、设计、开发、测试直至投入使用，并在使用中不软件从需求确定、设计、开发、测试直至投入使用，并在使用中不断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的全过程。全过程。n可划分为以下子阶段可划分为以下子阶段 1.可行性研究可行性研究2.需求分析和定义需求分析和定义3.总体设计总体设计4.详细设计详细设计5.编码（实现）编码（实现）6.软件测试、运行软

28、件测试、运行/维护维护据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。 3.2 传统软件开发生命周期模型传统软件开发生命周期模型 26THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.1 瀑布模型瀑布模型系统需求系统需求软件需求软件需求分析分析设计设计编码编码测试测试运行运行n瀑布模型总结瀑布模型总结n文档驱动的模型文档驱动的模型n阶段间具有顺序性和依阶段间具有顺序性

29、和依赖性赖性n项目开发周期较长项目开发周期较长n实际项目很少按照该模实际项目很少按照该模型给出的顺序进行型给出的顺序进行27THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 瀑布模型是最早出现的软件开发模型，在软件工程中瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为最后得到软件产品，也称为“线性顺序模型线性顺序模型”或者或者“传统生命周期传统生命周期”。

30、其过程是从上一项活动接收该项。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果。动应完成的内容给出该项活动的工作成果。 并作为输出传给下一项活动。同时评审该项活动的实并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，中人员的组织及管理， 28THE SCHOOL OF SOFTWARE EN

31、GINEERING OF HUST 瀑布模型的优点：瀑布模型的优点： （1）它提供了一个模版，这个模板使得分析，设计，）它提供了一个模版，这个模板使得分析，设计，编码，测试和支持的方法可以在该模板下有一个共同编码，测试和支持的方法可以在该模板下有一个共同的指导标准。（的指导标准。（2）虽然有不少缺陷但比在软件开发）虽然有不少缺陷但比在软件开发中随意的状态要好的多。中随意的状态要好的多。29THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 缺点：缺点： 大部分情况下，实际的项目难以按照该模型给出的顺大部分情况下，实际的项目难以按照该模型给出的顺序进行，而且这种

32、模型的迭代是间接的，这很容易由序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。微小的变化而造成大的混乱。 顾客的需求难以表达真正的额外需要。顾客的需求难以表达真正的额外需要。 客户要等到开发周期的晚期才能看到程序运行的测试客户要等到开发周期的晚期才能看到程序运行的测试版本，如果发生错误，有可能是灾难的。版本，如果发生错误，有可能是灾难的。 采用这种线性模型，会经常在过程的开始和结束时碰采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去。到等待其他成员完成其所依赖的任务才能进行下去。 30THE SCHOOL OF SOFTWARE

33、 ENGINEERING OF HUST3.2.2 原型模型原型模型 31THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.2 原型模型原型模型 nPrototyping modelPrototyping model特点特点n在需求定义之前，需要快速构建一个系统在需求定义之前，需要快速构建一个系统n根据构建系统的优缺点，用户给开发人员提出反馈意根据构建系统的优缺点，用户给开发人员提出反馈意见见n根据反馈意见修改软件需求规格，以便系统可以更正根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求确地反映用户的需求n减少各种假设以及风险减少各种假

34、设以及风险32THE SCHOOL OF SOFTWARE ENGINEERING OF HUST33THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 原型的分类原型的分类 废弃型：先构造一个功能简单而且质量要求不高废弃型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。型系统

35、就被废弃不用。 追加型或演化型：先构造一个功能简单而且质量要追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最不断地扩充修改，逐步追加新要求，最后发展成为最终系统。终系统。 34THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.3 增量模型增量模型 当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程

36、在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示： 35THE SCHOOL OF SOFTWARE ENGINEERING OF HUST1.4.3 增量模型增量模型图图1.5 增量模型增量模型36THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 所示的增量模型表明，必须在开始实现各个构件之前就所示的增量模型表明，必须在开始实现各个构件之前就全部完成全部完成需求分析、规格说明和概要设计的工作需求分析、规格说明和概要设计的工作。由于在开始构建第一个。由于在开始构建第一个构件之

37、前已经有了总体设计，因此风险较小构件之前已经有了总体设计，因此风险较小37THE SCHOOL OF SOFTWARE ENGINEERING OF HUST图图1.6 风险更大的增量模型风险更大的增量模型1.4.3 增量模型增量模型38THE SCHOOL OF SOFTWARE ENGINEERING OF HUST描绘了一种描绘了一种风险更大的增量模型风险更大的增量模型：一旦确定了用户需求之后，就着：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后规格说明组将转向第手拟定第一个构件的规格说明文档，完成后规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构

38、件二个构件的规格说明，与此同时设计组开始设计第一个构件用这种方式开发软件，不同的构件将并行地构建，因此有可能加用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。39THE SCHOOL OF SOFTWARE ENGINEERING OF HUST渐增模型与快速原型渐增模型与快速原型 的相同之处是其的相同之处是其迭代迭代的特征，不同之处是的特征，不同之处是渐增模型

39、渐增模型的每的每一轮都得到一个用户可真正使用和操作的一轮都得到一个用户可真正使用和操作的完整版本完整版本，而，而快速原型快速原型每一轮得到每一轮得到的是在性能和功能上大大的是在性能和功能上大大简化的版本简化的版本。优点优点:(1)渐增模型渐增模型 对项目组的组成人对项目组的组成人员不是非常充裕的情况下十分有用员不是非常充裕的情况下十分有用。早。早期对基本系统的开发需要的人员比较少，后续的各轮开发可以根据需要补充期对基本系统的开发需要的人员比较少，后续的各轮开发可以根据需要补充人员。此外，这种增量式的开发，可以有效地防止技术风险。人员。此外，这种增量式的开发，可以有效地防止技术风险。 (2)渐增

40、模型每一轮都可以向用户发布一个渐增模型每一轮都可以向用户发布一个高质量的可操作的版本高质量的可操作的版本。用户容。用户容易接受并可以提出中肯的意见，不需要非常大的原始资金投入。易接受并可以提出中肯的意见，不需要非常大的原始资金投入。缺点：由于要求下一轮新增的功能能够无缝集成到上一轮系统中去，如果整缺点：由于要求下一轮新增的功能能够无缝集成到上一轮系统中去，如果整体结构设计不当，则有可能导致整个软件的结构变差。体结构设计不当，则有可能导致整个软件的结构变差。1.4.3 增量模型增量模型实例三实例三 基于工作流的科技项目管理系统基于工作流的科技项目管理系统 项目信息发布项目信息发布 项目信息分类项

41、目信息分类 项目信息集成项目信息集成 项目协同工作项目协同工作 项目过程支持项目过程支持 个性化设置个性化设置 项项目管理信息数据服务目管理信息数据服务 项目监控与评价数据服项目监控与评价数据服务务 应用系统应用系统 集成服务集成服务 通讯服务通讯服务 统一编码体系统一编码体系 项目组织管理项目组织管理 项目过程控制项目过程控制 项目数据分析项目数据分析 项目流程管理项目流程管理 项目知识管理项目知识管理 生命周期管理生命周期管理 工作流定义工作流定义 消息组件消息组件 权限与安全权限与安全 工作流工作流 平台平台 动态工作流引擎动态工作流引擎 协同工作引擎协同工作引擎 资源管理资源管理 29

42、 40THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 优点优点 1) 由于能够在较短的时间内向用户提交一些有用的由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。工作产品，因此能够解决用户的一些急用功能。 2）由于每次只提交用户部分功能，用户有较充分的）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。时间学习和适应新的产品。 3）对系统的可维护性是一个极大的提高，因为整个）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只系统是由一个个构件集成在一起的，当需求变更时只

43、变更部分部件，而不必影响整个系统。变更部分部件，而不必影响整个系统。 缺点缺点41THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 增量模型存在以下缺陷：增量模型存在以下缺陷： 1） 由于各个构件是逐渐并入已有的软件体系结构中由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。这需要软件具备开放式的体系结构。 2） 在开发过程中，需求的变化是不可避免的。增量在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于模

44、型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。改模型，从而使软件过程的控制失去整体性。 3）如果增量包之间存在相交的情况且未很好处理，）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。开发的方法较适应于需求经常改变的软件开发过程。42THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.3 增量模型

45、增量模型 增量模型总结增量模型总结n融合了瀑布模型和原型的迭代特征。融合了瀑布模型和原型的迭代特征。n每一个增量均发布一个可操作产品。每一个增量均发布一个可操作产品。43THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.4 进化模型进化模型 建造建造/ /修改修改原型原型听取用户听取用户意见意见用户测试用户测试运行原型运行原型这个模型这个模型可看作是重复执可看作是重复执行的多个瀑布模行的多个瀑布模型。型。 44THE SCHOOL OF SOFTWARE ENGINEERING OF HUST3.2.5 螺旋模型螺旋模型原型原型1原型原型2原型原型3可

46、运行可运行原型原型需求计划需求计划 生存期生存期 计划计划开开发发计计划划集集成成与与测测试试软件软件需求需求需求需求确认确认设计确认设计确认与验证与验证 软件软件 产品产品设计设计详细设计详细设计风风险险分分析析风风险险分分析析风风险险分分析析验收验收测试测试实现实现集成集成与与测试测试单元单元测试测试编码编码开发、验证开发、验证下一产品下一产品实施工程实施工程提交线提交线评审评审累计累计成本成本风险分析风险分析评价方案，识别评价方案，识别风险、消除风险风险、消除风险制订计划制订计划决定目标决定目标方案和限制方案和限制客户评估客户评估45THE SCHOOL OF SOFTWARE ENGI

47、NEERING OF HUST 构建原型是一种能使某些类型的风险降至最低的方法。为构建原型是一种能使某些类型的风险降至最低的方法。为了降低交付给用户的产品不能满足用户需要的风险，一种行之了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法是在需求分析阶段快速地构建一个原型。在后续的有效的方法是在需求分析阶段快速地构建一个原型。在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能原型并不能“包治百病包治百病”，对于某些类型的风险，原型方法是，对于某些类型的风险，原型方法是无能为力的。无能为力的。 螺旋模型的

48、螺旋模型的基本思想基本思想: :使用原型及其他方法来尽量降低风使用原型及其他方法来尽量降低风险险。理解这种模型的一个简便方法，是把它看作在每个阶段之。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。完整的螺旋模型如前都增加了风险分析过程的快速原型模型。完整的螺旋模型如图。图。螺旋模型螺旋模型46THE SCHOOL OF SOFTWARE ENGINEERING OF HUST图：简化的螺旋图：简化的螺旋模型模型47THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 优点优点：对可选方案和约束条件的强调：对可选方案和约束

49、条件的强调有利于已有软件的有利于已有软件的重用重用，也，也有助于把软件质量作为软件开发的一个重要目标有助于把软件质量作为软件开发的一个重要目标；减少减少了过多测试（浪费资金）或了过多测试（浪费资金）或测试不足测试不足（产品故障多）（产品故障多）所所带来的风险带来的风险；更重要的是，在螺旋模型中；更重要的是，在螺旋模型中维护只是模型的另维护只是模型的另一个周期，在维护和开发之间并没有本质区别。一个周期，在维护和开发之间并没有本质区别。 主要优势主要优势:它是它是风险驱动风险驱动的，但这也可能是其弱点。除非的，但这也可能是其弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，软件开发人

50、员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险。当项目实际上正在走向灾难时，开否则将出现真正的风险。当项目实际上正在走向灾难时，开发人员可能还认为一切正常。发人员可能还认为一切正常。48THE SCHOOL OF SOFTWARE ENGINEERING OF HUST 螺旋模型主要螺旋模型主要适用于内部开发的大规模软件项目适用于内部开发的大规模软件项目。如。如果进行风险分析的费用接近整个项目的经费预算，则风险分果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析