软件开发过程管理课件

第3章软件开发过程管理第3章软件开发过程管理本章内容提要CMM和ISO9000

传统软件开发生命周期模型

扩展软件开发生命周期模型

3.1质量计划

3.4案例分析

3.5本章小结

3.6复习思考题

3.73.23.3本章内容提要CMM和ISO9000传统软件开发生命周期模型

软件过程是指人们用于开发和维护软件及其相关产品的一系列活动、方法、实践和革新。软件开发过程管理是指在软件开发过程中，除了先进技术和开发方法外，还有一整套的管理技术。软件过程改进是针对软件生产过程中会对产品质量产生影响的问题而进行的，它的直接结果是软件过程能力的提高。现在常见的软件过程改进方法：ISO9000，SW-CMM和由多种能力模型演变而来的CMMI。3.1CMM和ISO9000软件过程3.1CMM和ISO90003.1.1SW-CMM和CMMI

SW-CMM简介为了保证软件产品的质量，1991年美国卡内基·梅隆大学软件工程研究所（CMU/SEI）将软件过程成熟度框架进化为软件能力成熟度模型（CapabilityMaturityModelForSoftware，简称SW-CMM），并发布了最早的SW-CMM1.0版。

SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架，阶梯共有五级。3.1.1SW-CMM和CMMISW-CMM简介3.1.1SW-CMM和CMMI1初始级2可重复级3已定义级4已管理级5优化级无序、混乱的软件过程。依赖个别人的努力和机遇。建立基本的项目管理过程。相似项目，重复以往成果。文档化、标准化和标准的软件软件过程。软件过程和产品质量有详细的度量标准。持续的对过程进行改进。图CMM分级标准3.1.1SW-CMM和CMMI1初始级2可重复级3.1.1SW-CMM和CMMIKPA及KP除第一级外，SW-CMM的每一级都是按完全相同的结构组成的。每一级包含了实现这一级目标的若干关键过程域（KPA），每个KPA进一步包含若干关键实施活动（KP），无论哪个KPA，它们的实施活动都统一按六个公共属性进行组织，即每一个KPA都包含六类KP：

1.目标

2.实施保证

3.实施能力

4.执行活动

5.度量分析

6.实施验证3.1.1SW-CMM和CMMIKPA及KP3.1.1SW-CMM和CMMICMMI简介由于不同领域能力成熟度模型存在不同的过程改进，重复的培训、评估和改进活动以及活动不协调等一些问题。于是由美国国防部出面，美国卡内基·梅隆大学软件工程研究所（CMU/SEI）于2001年12月发布的CMMI1.1版本包括四个领域：软件工程（SW）、系统工程（SE）、集成的产品和过程开发（IPPD）、采购（SS）。3.1.1SW-CMM和CMMICMMI简介3.1.1SW-CMM和CMMI

CMMI有两种不同的实施方法连续式－－主要是衡量一个企业的项目能力阶段式－－主要是衡量一个企业的成熟度连续式与阶段式所包含的过程域是完全一致的。两者的区别主要在于过程域的组织方式不同，阶段式是用来描述组织整体上的成熟度，而连续式关注的是组织单个过程域的能力。如果组织注意力主要集中在某几个过程域上时，则采用连续式比较合适3.1.1SW-CMM和CMMICMMI有两种

CMMI的五个台阶完成级管理级定义级量化管理级优化级

每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。

CMMI的五个台阶与SW-CMM

的结构相比，

CMMI

的模型结构显得更加复杂与精细。

CMMI

从过程域所有的实践提炼出了多个过程域所共有的实践，称为一般实践，将其目标称为一般目标，其余特定于某个过程域的实践与目标称为特定实践与特定目标。这样模型取得了相对

SW-CMM

更高的抽象度与适应范围。目标（一般目标与特定目标）首次作为模型构成成分出现，这表明CMMI

对过程活动的结果投入了更多的关注。

与SW-CMM

的结构相比，

CMMI

的模型结构显得更加复3.1.2ISO9000质量标准

ISO9000

所谓“ISO9000”不是指一般意义上的一个质量保证标准，而是一族系列标准的统称。

作用强化品质管理，提高企业效益；增强客户信心，扩大市场份额；获得了国际贸易“通行证”，消除了国际贸易壁垒；节省了第二方审核的精力和费用；在产品品质竞争中永远立于不败之地；有效地避免产品责任；有利于国际间的经济合作和技术交流。3.1.2ISO9000质量标准ISO9000作用3.1.3三者之间的比较

选择SW-CMM还是CMMI的考虑实施企业的业务特点。实施企业的业务特点：如果企业的规模不是很大，业务又集中在软件开发为主，那么还是软件CMM比较适用。如果企业的规模比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI。3.1.3三者之间的比较选择SW-CMM还是CMM实施企业对过程改进的熟悉程度：如果企业已经实施过ISO9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度实施企业对过程改进的熟悉程度：如果企业已经实施过ISO9实施企业对过程改进的熟悉程度。实施企业对过程改进的熟悉程度：如果企业已经实施过ISO9000，并且取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过去没有接触过类似的工作，那么最好先从软件CMM2级开始，首先建立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一些。可以适当降低实施的难度实施企业对过程改进的熟悉程度。实施企业对过程改进项目的预算。实施企业对过程改进项目的预算：不论怎样，几乎可以肯定地说，实施CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的要求，这样就经济很多。实施企业对过程改进项目的预算。----实施企业是否可以使用阶段式的演进路线：如果企业只希望单方面的提高自己在项目管理、工程活动、支持活动或者过程管理四个方面中的某些方面的能力，那么就只能应用CMMI的连续表示方法。如果实施企业可以接受成熟度级别的思路（目前看国内大多数企业还是比较习惯于成熟度级别的），那么就不一定必须选择CMMI了。----实施企业是否可以使用阶段式的演进路线----------实施CMM与CMMI可以平滑的转换。

CMMI并不要求一家企业必须先做CMMI的2级然后再向更高的成熟级别演进，评估的时候也没有这样的要求。另外，CMMI的评估都会根据被评估的成熟度级别，检查所有不高于该级别的过程区域。换句话说，一个企业在CMM正式评估中达到了2级的成熟度，将来改为基于CMMI进行过程改进。在CMMI3级的正式评估时，CMMI2级的内容同样要进行检查。如果我们能够在做CMM2级的时候就按照CMMI的要求实施，效果没有任何的折扣，但对于实施企业来说，会节省很多在培训和评估方面的“额外”费用。（此处的“额外”费用是指CMMI收费比CMM高出的部分）----------实施CMM与CMMI可以平滑的转换。

C

ISO9001与CMM的关系ISO9001和CMM既有区别又相互联系，两者不可简单地互相替代。取得ISO9001认证并不意味着完全满足CMM某个等级的要求。取得CMM第2级(或第3级)不能笼统地认为可以满足ISO9001的要求。ISO9001与CMM的关系案例1W公司为了推行CMM，组建了独立的QA部门。尽管在W公司的内部宣传材料上对QA的作用进行了大肆的宣传，认为其对于CMM的推行和项目管理都具有重要作用，但是实际上QA人员的资历都相对较浅，对开发过程，技术和工具都缺乏必要的了解。只能够照搬一些条文来要求开发人员，开发人员对此并不认账，认为QA人员是没事找事。另外，QA这个岗位在薪酬和升迁方面毫不吸引人案例1W公司为了推行CMM，组建了独立的QA部门。尽管在W公为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经理设法推行项目经理锻炼制度，让项目经理到QA部门锻炼一段时间，然后继续担任项目经理或者升迁。但是因为此项制度没有得到有效的支持，项目经理在QA部门工作一段时间以后竟然没有开发部门愿意接收，就更谈不上升迁了。QA部门在W公司的威望江河日下。为了避免QA部门成为新手和项目组淘汰人员的集中地，QA部门经QA人员对于质量保证和CMM的实施至关重要，如果我们认可QA人员对于公司的价值，那就必须在人才和待遇上向QA部门倾斜QA人员对于质量保证和CMM的实施至关重要，如果我们认可QAH公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，采用了相对严格的过程规范，并且把相对重要的部分外包给了印度的CMM5级公司。这些手段Z公司都没有采用，但是Z公司却抢在了前面。

Z公司的“秘密武器”是一种形式化语言—SDL，Z公司采用SDL作为设计工具，这样C产品的相当一部分代码可以由SDL工具自动生成，而且在设计阶段就可以进行仿真运行，这样就大大地提高了效率并减少了缺陷。H公司虽然采用了相对严格的过程规范，但是因为全部代码为手工编制，所以，无论是效率还是质量，H公司都落后了H公司和Z公司都在研发相同类型的C产品。H公司在推广CMM，H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM高级别的评估，只能说明被评估的组织机构在过程控制上做得更加细致，但是并不能够保证你的开发过程是高效的。某些沉迷于CMM的组织机构忘记了先进的软件工程技术的重要性H公司显然忽视了先进技术可能为生产率带来的进步，通过了CMM本章内容提要CMM和ISO9000

传统软件开发生命周期模型扩展软件开发生命周期模型

3.1质量计划

3.4案例分析

3.5本章小结

3.6复习思考题

3.73.23.3本章内容提要CMM和ISO9000传统软件开发生命周期模型

软件生命周期软件从需求确定、设计、开发、测试直至投入使用，并在使用中不断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的全过程。

可划分为以下子阶段

1.可行性研究

2.需求分析和定义

3.总体设计

4.详细设计

5.编码（实现）

6.软件测试、运行/维护据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。

3.2传统软件开发生命周期模型软件生命周期3.2传统软件开发生命周期模型3.2.1瀑布模型系统需求软件需求分析设计编码测试运行瀑布模型总结文档驱动的模型阶段间具有顺序性和依赖性项目开发周期较长实际项目很少按照该模型给出的顺序进行3.2.1瀑布模型系统需求软件需求分析设计编码测试运行瀑瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果。并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。瀑布模型有利于大型软件开发过程中人员的组织及管理，

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位瀑布模型的优点：（1）它提供了一个模版，这个模板使得分析，设计，编码，测试和支持的方法可以在该模板下有一个共同的指导标准。（2）虽然有不少缺陷但比在软件开发中随意的状态要好的多。瀑布模型的优点：缺点：大部分情况下，实际的项目难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。顾客的需求难以表达真正的额外需要。客户要等到开发周期的晚期才能看到程序运行的测试版本，如果发生错误，有可能是灾难的。采用这种线性模型，会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去。

缺点：3.2.2原型模型3.2.2原型模型3.2.2原型模型Prototypingmodel特点在需求定义之前，需要快速构建一个系统根据构建系统的优缺点，用户给开发人员提出反馈意见根据反馈意见修改软件需求规格，以便系统可以更正确地反映用户的需求减少各种假设以及风险3.2.2原型模型Prototypingmodel特软件开发过程管理课件原型的分类①废弃型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。②追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心，然后通过不断地扩充修改，逐步追加新要求，最后发展成为最终系统。

原型的分类3.2.3增量模型当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。采用增量模型的软件过程如下图所示：3.2.3增量模型当使用增量模型时，第1个增量往往是核1.4.3增量模型图1.5增量模型1.4.3增量模型图1.5增量模型所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作。由于在开始构建第一个构件之前已经有了总体设计，因此风险较小所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求图1.6风险更大的增量模型1.4.3增量模型1.4.3增量模型描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件……用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手渐增模型与快速原型的相同之处是其迭代的特征，不同之处是渐增模型的每一轮都得到一个用户可真正使用和操作的完整版本，而快速原型每一轮得到的是在性能和功能上大大简化的版本。优点:(1)渐增模型对项目组的组成人员不是非常充裕的情况下十分有用。早期对基本系统的开发需要的人员比较少，后续的各轮开发可以根据需要补充人员。此外，这种增量式的开发，可以有效地防止技术风险。(2)渐增模型每一轮都可以向用户发布一个高质量的可操作的版本。用户容易接受并可以提出中肯的意见，不需要非常大的原始资金投入。缺点：由于要求下一轮新增的功能能够无缝集成到上一轮系统中去，如果整体结构设计不当，则有可能导致整个软件的结构变差。1.4.3增量模型实例三•

基于工作流的科技项目管理系统项目信息发布项目信息分类项目信息集成项目协同工作项目过程支持个性化设置项目管理信息数据服务项目监控与评价数据服务应用系统集成服务通讯服务统一编码体系项目组织管理项目过程控制项目数据分析项目流程管理项目知识管理生命周期管理工作流定义消息组件权限与安全工作流平台动态工作流引擎协同工作引擎资源管理29渐增模型与快速原型的相同之处是其迭代的特征，不同之处是渐增优点1)由于能够在较短的时间内向用户提交一些有用的工作产品，因此能够解决用户的一些急用功能。2）由于每次只提交用户部分功能，用户有较充分的时间学习和适应新的产品。3）对系统的可维护性是一个极大的提高，因为整个系统是由一个个构件集成在一起的，当需求变更时只变更部分部件，而不必影响整个系统。缺点优点增量模型存在以下缺陷：1）由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。2）在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。增量模型存在以下缺陷：3.2.3增量模型

增量模型总结融合了瀑布模型和原型的迭代特征。每一个增量均发布一个可操作产品。3.2.3增量模型增量模型总结3.2.4进化模型建造/修改原型听取用户意见用户测试运行原型

这个模型可看作是重复执行的多个瀑布模型。3.2.4进化模型建造/修改听取用户用户测试这个模3.2.5螺旋模型原型1原型2原型3可运行原型需求计划生存期计划开发计划集成与测试软件需求需求确认设计确认与验证

软件产品设计详细设计风险分析风险分析风险分析验收测试实现集成与测试单元测试编码开发、验证下一产品实施工程提交线评审累计成本风险分析评价方案，识别风险、消除风险制订计划决定目标方案和限制客户评估3.2.5螺旋模型原型1原型2原型3可运行需求计划开发计构建原型是一种能使某些类型的风险降至最低的方法。为了降低交付给用户的产品不能满足用户需要的风险，一种行之有效的方法是在需求分析阶段快速地构建一个原型。在后续的阶段中也可以通过构造适当的原型来降低某些技术风险。当然，原型并不能“包治百病”，对于某些类型的风险，原型方法是无能为力的。螺旋模型的基本思想:使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。完整的螺旋模型如图。螺旋模型构建原型是一种能使某些类型的风险降至最低的方法。为了图：简化的螺旋模型图：简化的螺旋模型优点：对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

主要优势:它是风险驱动的，但这也可能是其弱点。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险。当项目实际上正在走向灾难时，开发人员可能还认为一切正常。优点：对可选方案和约束条件的强调有利于已有软件

螺旋模型主要适用于内部开发的大规模软件项目。如果进行风险分析的费用接近整个项目的经费预算，则风险分析是不可行的。事实上，项目越大，风险也越大，因此，进行风险分析的必要性也越大。此外，只有内部开发的项目，才能在风险过大时方便地中止项目。

3.2.5螺旋模型

螺旋模型总结

基于风险驱动的开发模型,使用原型法或其它方法来尽量降低风险。适用于需求不明确的大规模软件项目3.2.5螺旋模型螺旋模型总结本章内容提要CMM和ISO9000

传统软件开发生命周期模型

扩展软件开发生命周期模型

3.1质量计划

3.4案例分析

3.5本章小结

3.6复习思考题

3.73.23.3本章内容提要CMM和ISO9000传统软件开发生命周期模型3.3.1极限模型极限模型简介

2001年，为了避免许多公司的软件团队陷入不断增长的过程泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：SCRUM，Crystal，特征驱动软件开发（FeatureDrivenDevelopment，简称FDD），自适应软件开发（AdaptiveSoftwareDevelopment，简称ASD），以及最重要的极限编程（eXtremeProgramming,简称XP）。

3.3.1极限模型极限模型简介3.3.1极限模型极限编程将开发阶段的4个活动（分析、设计、编码和测试）混合在一起，在全过程中采用迭代增量开发、反馈修正和反复测试。

3.3.1极限模型极限编程将开发阶段的4个活动（分析、探索阶段探索阶段的主要工作是开发初始的用户故事（UserStories）和体系结构骨架（architecturespike）。用户故事描述了系统高层的需求，它是制订发布计划的输入。在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用。探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用。探索阶段计划阶段计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划。使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之间的关系。通常图形方式（可以是草图）比文字描述更直观。尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定其工作量估算。计划阶段迭代到发布阶段迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本。根据在探索阶段编写的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作。在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或调整。迭代到发布阶段产品化阶段产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备。在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等。另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调“可运行软件高于详尽的文档”，但是，必要的文档仍是需要的。产品化阶段可能要写的文档：系统文档系统文档的目的在于为系统提供一个总览，来帮助人们理解它。主要包括：系统技术体系结构和业务体系结构的总览、高层次的系统需求、关键设计决策的总结、体系结构图以及重要的设计模型（如果有的话）等。操作文档操作文档的内容包括：系统涉及的依赖关系，与其他系统、数据库以及文件文互的特性，对备份流程的参考引用，系统的联系人列表以及联系方法，系统的适用性及可靠性需求的总结，系统预期负载情况概况，以及排错指导原则。可能要写的文档：支持文档支持文档的内容包括：支持人员专用的培训教材，解决问题时作为参考的用户文档，排错指导原则，解决疑难问题时的上报流程，以及维护团队的联系列表。用户文档参考手册用于快速查询；用户指南用于指明系统的工作方式；支持指南用于指导如何获取其他的帮助；培训资料则主要用于培训。支持文档维护阶段维护阶段涵盖了计划阶段、迭代到发布阶段和产品化阶段通常这个阶段主要包括面向产品的活动，如系统的运行和支持。维护阶段3.3.1极限模型XP开发模型核心思想：交流（Communication）简单（Simplicity）反馈（Feedback）进取（Aggressiveness）

3.3.1极限模型XP开发模型核心思想：交流（Communication）实践表明，项目失败的重要原因之一是交流不畅，使得客户的需求不能准确地传递给开发人员，造成开发人员不能充分理解需求；模型或设计的变动未能及时告知相关人员，造成系统的不一致和集成的困难所有项目相关人员之间充分的有效的交流是软件开发成功所必不可少的XP方法提倡面对面的交流，这是一种有效的也是效率最高的交流方式交流（Communication）简单（Simplicity）指在确保得到客户满意的软件的前提下，做最简洁的工作（简单的过程、模型、文档、设计和实现）在开发中不断优化设计，时刻保持代码简洁、无冗余体现了敏捷开发的“刚刚好(Justenough)”思想，即开发中的活动及制品既不要太多也不要太少，刚好即可简单（Simplicity）反馈（Feedback）及时有效的反馈能确定开发工作是否正确，及时发现开发工作的偏差并加以纠正。强调各种形式的反馈，如非正式的评审（走查，Walkthrough）、小发布等反馈（Feedback）进取信任合作的同事，也相信自己做能做到的最简单的事只有在绝对需要的时候才创建文档让业务人员制定业务决策，技术人员制定技术决策用可能的最简单的工具，例如白板和纸，只有在复杂建模工具能提供可能的最好价值时才去使用它们相信程序员能制定设计决策，不需要给他们提供过多的细节需要勇气来承认自己是会犯错误的，需要勇气来相信自己明天能克服明天出现的问题。进取XP方法的12个核心实践1.完整的团队（WholeTeam）所有的小组成员应在同一个工作地点工作成员中必须有一个现场用户（On-siteUser）由他提出需求，确定开发优先级通常还设一个“教练”（Coach）角色

教练指导XP方法的实施，以及与外部的沟通和协调2.计划对策（PlanningGame）

包括两类：发布计划和迭代（Iteration）计划XP方法的12个核心实践1.完整的团队（WholeTeam3.系统比喻（Metaphor）

系统比喻是待开发软件的一个每个成员都熟悉的形象化比喻，相当于一个粗略的软件体系结构4.小发布（Smallrelease）

经常、不断地发布可运行的、具有商业价值的小软件版本，供现场用户评估或最终使用

5.测试（testing）

XP方法提倡测试优先，即先写测试后编代码（testingthencoding）6.简单设计（SimpleDesign）设计只考虑当前定义的功能而不考虑以后需求的变化该设计是完成目前功能所需的最简洁的设计3.系统比喻（Metaphor）7.结对编程（PairProgramming）一个程序员编程的同时，另一个程序员负责检查程序的正确性和可读性结对的伙伴可以动态调整8.

设计改进（DesignImprovement）在不影响程序的外部可见行为的情况下，按高内聚低耦合的原则对程序结构进行改进，保持代码简洁、无冗余持续集成（ContinuousIntegration）每完成一个模块的开发（包括该模块的单元测试）后，立即将其组装到系统中，并进行集成测试，完成该集成测试后才能进行下一次集成7.结对编程（PairProgramming）10.

代码全体共享（CollectivecodeOwnership）

团队中的任何人可以在任何时候修改系统任何位置上的任何代码团队的成员都可以参加模型的开发，又有系统比喻、结对编程、编码标准、持续集成等实践，这些都为代码全体共有提供了支持编码标准（CodingStandard）

XP方法强调制订一个统一的编码标准，包括命名、注释、格式等编程风格12.可持续步调（SustainablePace）

每周40小时工作制10.

代码全体共享（CollectivecodeOwn3.3.1极限模型优点采用简单计划策略，不需要长期计划和复杂模型，开发周期短；在全过程采用迭代增量开发、反馈修正和反复测试的方法，能够适应用户经常变化的需求。

缺点目前主要在小规模项目上应用并取得成功，但是否适用于中等规模或大规模软件产品，需慎重考虑；由于这个模型较新产品交付后维护成本是否降低，不能确定；对编码人员的经验要求高

3.3.1极限模型优点缺点1.4.6Rational统一过程

最佳实践RUP充分体现了6条经过多年实践检验的软件开发经验：1)迭代式开发：允许每次迭代过程中需求发生变化，加深对问题的理解，易于满足需求的变化。2)管理需求：描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化。3)使用基于构件的体系结构：构件使软件重用称为可能。RUP提供了使用现有的或新开发的构件定义体系结构的系统化方法，降低开发复杂性，提高软件重用率。

3.3.2Rational统一过程（RUP）1.4.6Rational统一过程

最佳实践3.3.21.4.6Rational统一过程

4)可视化建模：建模是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。可视化的图形形式更易于理解。5)验证软件质量：RUP中软件质量评估贯穿于整个开发过程中，由全体成员参与所有活动中。6)控制软件变更:RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功。1.4.6Rational统一过程

4)可视化建模3.3.2Rational统一过程（RUP）3.3.2Rational统一过程（RUP）(1)核心工作流

前6个为核心过程工作流程，后3个为核心支持工作流程。(2)工作阶段

划分为4个连续的阶段，每阶段都有明确的目标，并且定义了用来评估是否达到这么目标的里程碑。每个目标都是通过迭代实现。(3)迭代式开发

采用迭代或渐增的方法开发软件。RUP重复一系列组成软件生命周期的循环，每次循环经历一次完整的生命周期且交付可运行版本。(1)核心工作流3.3.2Rational统一过程（RUP）

用例驱动

Concise,simple,andunderstandable

以体系结构为中心

Effectivebasisforlarge-scalereuse

增量和迭代开发基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。3.3.2Rational统一过程（RUP）用

一、问题陈述

有一个对外营业的会议中心，有各种不同规格的会议室，为用户提供以下服务：

1、用户可以按照会议人数、会议时间预订会议室。可以只预订１次，也可预订定期召开的会议。

2、开会前允许修改会议时间、人数，重新选择会议室，甚至取消预订的会议。

3、确定会议预订后，会议中心负责会务管理：包括通过邮寄或电子邮件，通知开会人员有关会议信息，制作代表证等。

4、系统根据会议室的使用情况（紧张与否），调整、更改会议室和会议时间，并调整修改预订会议的时间。会议管理系统退出下页末页案例一一、问题陈述会议管理系统退出下页末页案例一二、建立用例模型1、识别角色

找出所有可能与系统发生交互行为的外部实体、对象、系统。考虑系统的主要功能的使用者，就会想到用户和系统管理者，但如果直接将用户定义为角色，系统的所有功能几乎都由用户使用。根据问题的描述，系统要求将会议和会议的召开分开来。从会议的角度看，允许用户定义、更改或删除一个会议。从会议召开的角度看，允许用户为某个会议定义召开时间、参加人数、更改相应的数据或删除已定义的会议召开。因此，将用户识别为“会议管理者”和“会议申请者”两个角色。本系统定义以下角色：会议管理者（MeetingAdministrator）会议申请者（MeetingInstanceRequester）邮局（PostOffice）会议人员管理（AttendeeManagement）系统维护者（SystemMaintainer）退出上页首页下页末页二、建立用例模型1、识别角色退出上页首页下页末页

在识别角色的基础上，列出与角色相关的用例，有的用例与多个角色相关，经过分析，确定系统的用例（打）。⑴与会议管理者相关的用例：

定义一个会议（DefineMeeting

）更改一个会议（AlterMeeting

）

删除一个会议（RemoveMeeting

）

⑵与会议申请者相关的用例：

申请会议召开（RequestMeetingInstance

）

更改申请（ChangRequest

）

取消申请（CancelRequest

）

定义参加人员（AddAttendee

）

归还会议室（ReleaseRoom

）

2、用例识别退出上页首页下页末页在识别角色的基础上，列出与角色相关的用例，有的用例与多个3、会议管理系统的Usecase图图1会议管理系统的Usecase图归还会议室申请会议召开更改申请取消申请定义参加人员会议召开申请者邮局会议人员管理设置预定时限会议室维护定义会议更改会议删除会议系统维护者会议管理员

退出上页首页下页末页3、会议管理系统的Usecase图图1会议管理系统的Us用例1、定义会议（DefineMeeting）输入会议名称确定会议规模确定会议类型其中会议规模是指参会人数范围。用例２、更改会议（AlterMeeting）改变会议名称改变会议规模改变会议召开频度用例３、删除会议（RemoveMeeting）如果该会议没有召开申请从会议列表中删除如果该会议有召开申请取消与之相关的会议召开信息删除该会议使用：用例8删除参加人员（RemoveAttendee）用例6取消申请（CancelRequest）4、对用例的进一步描述用例4、申请会议召开（RequestMeetingInstance)

确定召开时间（年、月、日）确定参加人员确定侯选会议室发会议通知使用：用例11发会议通知（InformofMeeting）用例13选择参加组（SelectGroupAttendee）扩展：①如果召开时间在申请时限之外用例12申请拒绝(RequestRejection）②如果还没定义参加人员用例7定义参加人员(AddAttendee

)用例5：更改申请（ModifyRequest）更改召开时间更改参加人员更改取得会议室发会议更改通知使用：用例13选择参加组（SelectGroupAttendee）用例11发会议通知(InformofMeeting)

扩展：①如果更改的时间不合法用例12申请拒绝（RequestRejection）②用例7定义参加人员(AddAttendee)退出上页首页下页末页用例1、定义会议（DefineMeeting）用例２、更用例6：取消会议召开（CancelRequest）、取消申请归还会议室发会议取消通知使用：用例8归还会议室（ReleaseRoom）用例14发会议取消通知（InformRejection）扩展：①如果会议已召开用例12申请拒绝（RequestRejection）用例7：定义参加人员(AddAttendee)输入参加人员的详细信息定义参加组用例9：会议维护（MeetingRoomMaintenance）加入一个会议室（用例15)标记一个会议室不可用（用例16)查询会议室预定情况（用例17)用例10：设置预定时限制（SetReservationTomeLimit）设置时间限用例11：发会议通知(InformofMeeting)

从会议人员管理获得参加人员的投递地址填写通知（会议召开时间、会议室号码）发送通知用例12：申请拒绝（RequestRejection）作废当前的一切输入中字止用户当前的操作用例13：选择会议参加人员组(SelectGroupAttendee)浏览会议组成员选择参加组用例14:会议取消通知（InformofCancellation)从会议人员管理处获取参加人员地址填写通知发送通知

用例８：归还会议室（ReleaseRoom）输入会议室号码输入使用时间删除参加人员归还会议室使用：用例９会议室维护（MeetingRoomMaintenance）用例18删除参加人员（RemoveAttendee）退出上页首页下页末页用例6：取消会议召开（CancelRequest）、用例7用例15:增加会议室（AddMeetingRoom）输入会议室号码输入会议室规模输入会议室可使用状态（可使用、不可使用）加入该会议室用例16:设置会议室不可使用（SetUnusableFlag）输入会议室号码通知该会议室的预定者标记该会议室的可所以状态为不可用用例17:查询会议室的使用情况(BrowseMeetingroomusage)输入会议室号码查询本用例返回会议室的使用状态（已使用、空闲）和会议室的可否使用情况。用例18：删除会议参加人员（RemoveAttendee）删除参加人员删除参加组图2描述了会议管理系统完整的用例模型。退出上页首页下页末页用例15:增加会议室（AddMeetingRoom）退出5、完整的会议管理系统的Usecase图图2完整的会议管理系统Usecase图退出上页首页下页末页5、完整的会议管理系统的Usecase图图2完整的会议管

除了用例模型外，其他模型都依赖于类模型，因此，类模型是ＯＯ方法的核心，类模型从对象的角度描述系统的组成，描述类（对象）及相互间的关系。为了建立类模型，首先要识别类，鉴于篇幅，这里就不再讨论类的识别过程。通过分析，识别以下类：

1、Meeting类，标识一个会议（名称、类型、规模）。

2、MeetingInstance类,Meeting类的子类，对会议时间、人数等进行描述。

3、MeetingRoom类,描述会议室的有关信息。

4、MeetingAdministration类，管理会议。

5、Attendee类，描述参会人员（姓名、性别、地址、头衔等）。

6、GroupAttende类，创建一个参加会议的组。

7、Address类，描述邮寄地址E-mail地址。

8、PostOffice类，负责发送邮寄通知。

9、AttendeeManagement类，数据库管理。

10、ReservationCriteria类，定义会议室预定准则。

11、Information类，构造一条通知。三、建立类模型退出上页首页下页末页除了用例模型外，其他模型都依赖于类模型，因此，类模型是Ｏ

该类与会议召开不同，它标识了一个会议（图3），因此，其属性包括会议名称、类型、规模（参加会议的人数）。其操作则有：增加会议、取消会议。一个会议往往有多个子会议（子类）的召开，因此，必须描述Meeting类与其子类MeetingInstance类之间的关联，如图4所示。2、

MeetingInstance类

MeetingInstance类是Meeting类的子类，描述会议的具体情况，会议的开始(StartTime)、结束时间(EndTime)，参会的人数(AttendeeNumber)，其操作有：添加参加人员AddAttendee()、添加参加人员组AddGroupAttendee()，而AttachMeetingRoom()表示为该类分配一个会议室，而Cancel()则表示取消该会议的召开。MeetingMeetingInstanceStartTimeEndTimeAttendeeNumberAddAttendee()AttachMeetingRoom()AddGroupAttendee()Cancel()Meeting

Name

Type

SizeAddMeetingInstance()CancelMeetingInstance()图3Meeting类图图4MeetingInstance类图1、

Meeting类退出上页首页下页末页该类与会议召开不同，它标识了一个会议（图3），因此MeetingRoomCapacityBuildingCodeDoorCodeStatusAssignMeetingInstance()SetInvalidate()Release()MeetingInstanceMeeting图5MeetingRoom类图该类描述了有关会议室的情况，因此MeetingRoom类的属性包括：会议室的规模Capacity，位置BuildingCode、DoorCode，使用状态Status（正在使用、已预定、空闲和不可用）等。该类的操作有：AssignMeetingInstance()将MeetingRoom分配给MeetingInstance对象,而SetInvalidate()则表示当会议室出现故障时，将其状态设置为不可用。Release()为归还会议室。当会议被预定后，为了便于查询某个会议室预定给了哪个会议，应建立类MeetingRoom与类MeetingInstanc之间的双向关联，这里定义为1：1。3、MeetingRoom类退出上页首页下页末页MeetingRoomCapacityAssignMeetiAttendeeNameSexPostaddressEmailAddressTitleMeetingInstance11..*图6Attendee类图

Attendee类描述参加会议人员的有关信息，如：姓名、性别、地址、E-mail地址、头衔等。MeetingInstance类与Attendee类之间有一对多的关联“1..*”

。

5、GroupAttendee类MeetingInstanceGroupAttendeeMemberNumberGroupNameAddAttendee()DeleteAttendee()10..*Attendee11..*图7GroupAttendee类图该类可创建一个参加会议的组，便于按照小组选择参加会议的人员。MeetingInstance类与GroupAttendee类之间有一对多的关联“0..*”。4、Attendee类退出上页首页下页末页AttendeeName11..*图6Attendee类图系统中有两种地址：电子邮件地址（EmailAddress

）和邮寄地址（PostAddress），而且，每个参加会议的人，可以有一个或者多个邮寄地址，有0个或多个E-mail地址。有关地址的属性，在再内这里不再讨论。负责发送邮寄通知。PostOffice类分别与PostAddress、EmailAddress和Information之间有一对多的关联。

7、PostOffice类1..*InformationEmailAddress1..*PostAddress1..*(fromUseCaseView)DelieverInformation()图9PostOffice类图PostOfficeAddress

PostAddressEmailAddressAttendee图8Address类图1..*0..*6、Address类退出上页首页下页末页系统中有两种地址：电子邮件地址（EmailAddres

InformationNoticeTopicReceiverTitleReceivernameTimeEventExplanationSendTimeSendrSignatureCreate()MeetingRoom图10Information类图该类用于构造一条通知，由于在本系统中，通常有三种：会议召开通知，会议更改通知，会议取消通知。如下例所示，通知的内容常包括标题、接受者、会议内容、会议时间及发通知的时间等。XXXX会议召开通知XX先生：定于2005年9月15日在樱都会议中心召开XXXX会议。

XXXX会议筹备组

2005年8月20日8、Information类退出上页首页下页末页InformationMeetingRoom图1GroupAttendeeAttendeeAttendeeManagement(fromUseCaseView)AttendNumber()GroupAttendeeNumber()AddAttendee()ChangeAttendee()AddGroupAttendee()DeleteGroupAttendee()图11AttendeeManagement类图该类使用数据库对参加会议的人员进行管理。分析阶段只确定该类与系统的接口，有关数据库的设计在设计阶段解决。该类与GroupAttendee类及Attendee类的关联如图11所示。

10、

ReservationCriteria类

该类定义了预定会议室的准则(如时间)，并建立会议实例（MeetingInstanee类）与该类之间的联系。ReservationCriteriaTimeCriteriasetCrieria()GetCriteria()MeetingInstanee图12ReservationCriteria类图9、

AttendeeManagement类退出上页首页下页末页AttendeeManagement(fromUseCa该类管理系统中由用户定义的所有会议，并提供给用户友好的用户界面。由于该类有定义会议（DefineMeeting）、更改会议（AlterMeeting）、删除会议（RemoveMeeting）等操作，建立与Meeting类之间的关联关系。MeetingName:stringMeetingAdministration(fromeetingPack)MeetingNumber:intDefineMeeting()AlterMeeting()RemoveMeeting()Meeting(fromMeetingPack)图13MeetingAdministration类图11、MeetingAdministration类退出上页首页下页末页该类管理系统中由用户定义的所有会议，并提供给用户友好的用MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstance

InformationMeetingRoom1..*1..*1..*PostOfficeGroupAttendeeAttendeeManagement

Address

PostAddressEmailAddressAttendee1..*0..*1..*0..*110..*0..*0..*111图14会议管理系统类图会议管理系统类图退出上页首页下页末页MeetingName:stringMeetingAdmin四、建立系统包图引入包图来对类进行管理，图15为本系统的包图。系统由会议包(MeetingPack)、人员包(AttendeePack)和邮寄包(PostOfficePack)三类包组成。图16、图17、图18分别描述了这三类包的构成。PostOfficePack图15系统包图MeetingPackAttendeePack退出上页首页下页末页四、建立系统包图引入包图来对类进行管理，图15为本系统的1、会议包（MeetingPack）2、人员包（AttendeePack）3、邮寄包（PostOfficePack）GroupAttendeeAddress

PostAddressEmailAddressAttendee图17人员包构成0..*1..*1..*1图18邮寄包构成

InformationPostOffice（fromUseCaseView）1..*0..*MeetingMeetingName:stringMeetingAdministrationReservationCriteriaMeetingInstanceMeetingRoom图16会议包构成111包图退出上页首页下页末页1、会议包（MeetingPack）2、人员包（Att

静态模型关注的是系统各成分的组织结构，而动态模型则要描述系统各成分之间的交互行为，即系统的动态特征。结合本系统，建立动态模型，包括交互图、合作图、活动图。（一）对象交互模型

在面向对象的方法中，一切元素都与对象紧密相关，事件也不例外。因此，对象在其生命期中不断地与其它对象交互。使用对象交互模型来描述用例图中的每个用例，从对象观点来描述用例的动态交互过程。在UML中，交互模型由两类图来描述：顺序图（Sequencediagram）强调的是对象交互行为的时间“顺序”，直观描述了对象的生存期，用消息传送来清晰地描述了在对象生存期中某一时刻的动态行为。只适宜描述简单的对象交互情况。合作图（Collaborationdiagram）强调的是对象合作的交互行为关系，对象间由各种关联连接，对象之间的合作情况（交互情况）使用消息流来表示，但消息没有发送时间和传送时间的概念。适宜描述对象数目较多，交互情况教复杂的情况。五、建立动态模型退出上页首页下页末页静态模型关注的是系统各成分的组织结构，而动态模型则要描述系：MeetingAdministration：Meeting：MeetingAdministrattor1:DefineMeeting(meeting)[IsMeetingExisted=.T.]3:Fail(MeetingExisted)2:{new(meeting)}图19定义会议的顺序图当用户向会议中心申请召开会议时，首先要定义一个会议。会议管理者发送DefineMeeting消息给MeetingAdministration对象,消息参数是有关会议的一个临时对象(meeting)，根据该临时对象检查会议是否存在？若不存在，创建新会议：2:{new(meeting)}，若当条件表达式为真时：[IsMeetingExisted=.T.]，表示会议已经被定义，不需要再定义。1、用例：定义会议(DefineMeeting)的顺序图退出上页首页下页末页：Meeting1:DefineMeeting(meetin当用户确定要取消某个会议时，首先检查会议是否定义，如果没有可以直接删除，否则要先取消相关的会议。如图20所示,首先系统用户对象MeetingAdministrator发出RemoveMeeting(MeetingName)消息给对象MeetingAdministration，通过消息的参数检索要取消的会议对象，并向该对象发出取消会议召开的消息。表达式“[IsOpen=.F.]”表示如果会议不处于召开状态，就取消它。表达式“[IsAllMeetingInstancesCanceled=.T.]”表示该会议的所有会议召开都已经被取消，则会议管理就发出取消会议召开的消息。否则返回取消失败（如会议正在召开）的消息。2、用例：取消会议(RemoveMeeting)的顺序图图20取消会议的顺序图：MeetingAdministration：MeetingInstance：MeetingAdministrator1：RemoveMeeting(MeetingName)[IsAllMeetingInstancesCanceled=.F.]5:Fail(MeetingExisted)2:CancelMeetingInstance()：Meeting[IsAllMeetingInstancesCanceled=.T.]4:Fail(MeetingExisted)[IsOpen=.F.]3:Cancel()退出上页首页下页末页当用户确定要取消某个会议时，首先检查会议是否定义，如３、用例：撤消会议召开（CancelRequestment）的顺序图：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom：PostOffice1:CancelMeetingInstance(Instance)[IsOpen=.F.]2:Cancel()3:Release()4:DelieverInformation(cancellation)图21撤消会议召开的顺序图要撤消某个会议召开，发送Cancel信息给MeetingInstance对象。该对象先要在Meeting对象中注销自己，再归还已分配的会议室，并向参会人员发撤消会议的通知。图21中会议管理对象发送给会议对象的消息CancelMeetingInstance(Instance)中的参数用于检索会议召开。条件表达式[IsOpen=.F.]表示如会议召开未进行，则撤消会议召开。如果会议已进行，则返回失败消息（图中未列出）。退出上页首页下页末页３、用例：撤消会议召开（CancelRequestment图22撤消会议召开的顺序图：PostOffice：MeetingAdministration：Meeting：MeetingInstance：MeetingRoom1:AddMeetingInstance(instance)2:{new}6:AssignMeetingInstance()7:DelieverInformation(info)5:AttachMeetingRoom(room)4:AddGrooupAttendee(group)3:AddAttendee(member)如果时间合法，就创建一个会议召开对象。４、用例：申请会议召开（RequestMeetingInstance）的顺序图用户申请一个会议召开时，应该指定会议召开的名称，召开的时间，及会议参加人员。图22中instance、member、group、room、info都是临时对象，instance记录了用户指定的会议属性（时间、参加人数等），member为一个参会代表，是Attendeegroup参会人员组的对象；而room是满足要求的会议室。４、用例：申请会议召开退出上页首页下页末页图22撤消会议召开的顺序图：PostOffice1:Ad六、合作图与活动图对于简单的对象交互情况，顺序图可以作很好的描述，可是，当交互对象数目增加，交互情况复杂时，顺序图就很难描述清楚了，可用合作图来描述。合作图描述了系统中所有对象之间的交互合作关系，注重对象之间的整体交互情况，交互关系由消息流来表示。在Rose中，还可以将顺序图与合作图进行转换。本案例不再给出合作图。

七、活动图

活动图模型主要用于描述系统在问题域空间中的活动流程，活动图可以方便地描述系统中的并发活动。由于本例中并没有复杂的并发活动，而且也也没有明显的基于核心的、具有复杂状态和行为的对象，所以可以不必画出合作图和活动图。六、合作图退出上页首页六、合作图与活动图对于简单的对象交互情况，顺序图可以作很3.3.3微软产品开发周期模型微软产品周期模型产品规划阶段测试阶段产品开发阶段发布阶段M1…MnCCZBBRTM/WRC1…RCnAlphaGoldenMastersBetaProductVisionFunctionSpecQFEsRTM/WQAMnM03.3.3微软产品开发周期模型微软产品周期模型产品规划MSF过程模型将里程碑分为两大类：主要里程碑（Majormilestone）和临时里程碑（Interimmilestone）。主要里程碑是在项目阶段和阶段之间设置的，用于审核前一阶段工作完成情况的里程碑。如图3‑4所示，MSF过程模型包含5个主要里程碑：前景/范围得到认可项目计划得到认可开发完成可发布版本准备就绪发布完成这5个主要里程碑适用于大多数IT项目。临时里程碑用于将较大的工作阶段或工作任务划分为较小的、可管理的单元，并对每个单元的完成情况进行审核。临时里程碑的设置是根据项目的类型和具体情况而定的。项目组可根据项目的目标、范围和进展，在项目过程中设置和使用临时里程碑。MSF过程模型将里程碑分为两大类：主要里程碑（Majorm软件开发过程管理课件本章内容提要CMM和ISO9000

传统软件开发生命周期模型

扩展软件开发生命周期模型

3.1质量计划

3.4案例分析

3.5本章小结3.6复习思考题

3.73.23.3本章内容提要CMM和ISO9000传统软件开发生命周期模型3.4.1质量与质量规划

软件质量是“所有描述计算机软件优秀程度的特性的组合”。软件质量度量模型由三层组成第一层为质量特性第二层为质量子特性第三层称为度量3.4.1质量与质量规划软件质量3.4.1质量与质量规划ISO／IEC9126–1991（GB／T16260–1996）标准标准定义的6个质量特性功能性可靠性易使用性高效性可维护性可移植性

质量规划指识别哪些质量标准适用于软件项目，并确定如何满足这些标准的要求

3.4.1质量与质量规划ISO／IEC9126–3.4.2质量体系、质量手册和质量计划

质量体系指为保证产品、过程或服务质量，满