CMMI软件开发流程1
cmmi流程
cmmi流程
CMMI （Capability Maturity Model Integration）是由美国国家工
程技术研究所（Software Engineering Institute，SEI）发展的一种通
用的、结构化的框架，旨在帮助组织提高软件开发和维护的质量。
它的定
位是要建立一个良好的组织管理结构，以提高团队的绩效。
CMMI流程主
要包括进程定义、基线定义、过程实施和评价等步骤：
（1）进程定义：定义组织内部工作流程、角色分配、进程激励机制、进程技术实施指南等。
（2）基线定义：引入CMMI有效工作流程，建立和维护组织内各级进
程基线，确保内部进程流程实施有序,确保组织内部进程流程有效可控。
（3）进程实施：在组织内部落实CMMI的各级流程标准，确保完善的
进程实施，为组织提供更稳定、可控的运行空间。
（4）评价：定期进行组织内部的进程流程评估，及时发现和解决进
程相关的问题，确保组织内部进程流程完善、可靠、有效。
cmmi项目流程
cmmi项目流程CMMI项目流程CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是一种用于评估和改进组织软件和系统工程能力的国际标准。
CMMI项目流程是指按照CMMI模型的要求进行软件和系统工程项目管理的具体过程。
本文将介绍CMMI项目流程的主要内容。
一、项目立项项目立项是指确定项目的目标、范围和约束条件，制定项目计划和资源分配的过程。
在CMMI项目流程中，项目立项阶段需要明确项目的业务目标、计划和相关要求，形成项目章程和项目计划，并进行项目风险评估和资源分配。
二、需求分析需求分析是指根据项目的业务需求，明确产品或系统的功能、性能和可靠性要求的过程。
在CMMI项目流程中，需求分析阶段需要收集、分析和确认项目的需求，制定需求规格说明书，并与相关利益相关者进行沟通和协商。
三、系统设计系统设计是指根据需求规格说明书，设计产品或系统的结构、组件和接口的过程。
在CMMI项目流程中，系统设计阶段需要制定系统架构和模块设计，编写详细设计文档，并进行设计评审和验证。
四、编码与单元测试编码与单元测试是指根据系统设计文档，进行程序编写和单元测试的过程。
在CMMI项目流程中，编码与单元测试阶段需要根据设计要求进行编码，编写单元测试用例和执行单元测试，并进行代码评审和缺陷修复。
五、集成测试集成测试是指将各个模块或组件集成到整个系统中，进行功能测试和性能测试的过程。
在CMMI项目流程中，集成测试阶段需要编制集成测试计划和测试用例，执行集成测试并记录测试结果，对测试中发现的问题进行跟踪和解决。
六、系统测试与验证系统测试与验证是指对整个系统进行功能、性能和可靠性等方面的综合测试和验证的过程。
在CMMI项目流程中，系统测试与验证阶段需要编制系统测试计划和测试用例，执行系统测试和验证，并记录测试结果，对测试中发现的问题进行跟踪和解决。
七、系统交付与运维系统交付与运维是指将已经完成的系统交付给用户，并进行系统运维和技术支持的过程。
cmmi软件开发流程图
软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
➢对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。
➢关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
CMMI评估流程
CMMI评估流程引言概述：CMMI（Capability Maturity Model Integration）是一种用于评估和改进组织软件开发和工程能力的模型。
它提供了一个框架，帮助组织了解自己的软件开发过程，并提供了改进的指导。
本文将介绍CMMI评估流程的五个部分，包括：目标设定、准备评估、数据收集、评估结果分析和改进计划。
一、目标设定：1.1 确定评估的目的和范围：在开始评估之前，需要明确评估的目的和范围。
例如，是为了了解组织的软件开发能力，还是为了达到某个特定的CMMI级别。
1.2 确定评估的时间和资源：评估需要一定的时间和资源，因此在目标设定阶段需要确定评估的时间范围和所需的人力、物力资源。
1.3 制定评估计划：评估计划是评估流程的指导文件，包括评估的具体步骤、参与人员和时间安排等。
评估计划的制定需要根据实际情况和目标设定来确定。
二、准备评估：2.1 建立评估团队：评估团队由具有相关经验和专业知识的成员组成，他们将负责执行评估流程中的各个步骤。
2.2 确定评估的依据：评估依据是评估流程中的重要组成部分，它包括组织的文档、流程和记录等。
评估团队需要收集和分析这些依据，以了解组织的软件开发过程。
2.3 确定评估的方法和工具：评估方法和工具对评估的有效性和准确性有很大的影响。
评估团队需要选择适合的方法和工具，以确保评估的可靠性和有效性。
三、数据收集：3.1 进行访谈和观察：评估团队将与组织的相关人员进行面对面的访谈和观察，以了解软件开发过程中的实际情况和存在的问题。
3.2 收集和分析数据：评估团队将收集和分析组织的数据，包括项目的进展情况、质量指标和问题报告等。
通过数据的收集和分析，评估团队可以评估组织的软件开发能力。
3.3 进行评估报告：评估团队将根据数据收集和分析的结果，编写评估报告，对组织的软件开发能力进行评估，并提出改进建议。
四、评估结果分析：4.1 分析评估报告：评估报告是评估结果的主要输出，评估团队需要对评估报告进行详细的分析，了解组织的软件开发能力和存在的问题。
软件开发过程
软件开发过程CMMI着重于软件项目的质量管理，强调过程控制，确保产品在软件开发的每一个阶段的质量都要达到客户的要求，这里我们就按项目的开发阶段详细讲述CMMI是如何在项目中监控并把握项目质量的。
（按照软件工程理论，项目一般划分为立项阶段、需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、集成测试阶段、产品形成&验收测试阶段）。
1项目立项阶段项目立项阶段CMMI主要管理工作有：1、建立项目组：同时为了确保项目能够如期完成，在立项阶段，将由高层管理者（总经理室成员）召开正式的项目启动会议，共同商讨确定项目组成员，主要包括项目经理、产品管理、程序管理、开发人员、技术支持人员；为了确保项目的质量，还要确定相关独立于项目组之外的成员（其活动不受项目组约束，便于监督项目质量），主要包括独立测试人员、SQA（质量保证人员）、SCCB配置管理委员会成员，这些组织成员将按照CMMI要求形成正式项目文档（立项书），立项书将向所有项目组相关人员及客户公布。
2、制定SOW ：已经和客户签定了合同，为了确保客户的利益，CMMI要求项目组建立SOW（目标范围定义说明书），确定客户的需要什么，不需要什么，以及需要的技术目标和业务目标（比如项目工期、成本、功能需求等等），客户有权利和项目组技术管理委员会一起评审SOW。
3、项目初期计划制定：项目经理确定后，根据CMMI软件项目策划要求，项目经理将根据合同需求、合同工期等内容采用科学的计算方法（目前采用国际上知名的Delphi法）估计项目的规模、工作量、进度、风险、关键计算机资源，并依据集团本身的历史项目数据计算生产率，根据以上数据计算项目的进度及人员安排，最后才制定出符合项目实际情况的计划。
所有的这些规程，在CMMI软件项目策划中有明确规范的定义。
4、项目跟踪及监督计划制定：为了确保制定的项目计划能够反映项目的实际情况，CMMI要求项目经理有责任制定项目的跟踪监督计划，根据本计划，项目所有活动都能够得到合理的监控，及时发现项目组出现的各类偏差。
cmmi流程
cmmi流程CMMI流程是一种用于评估、改进和管理组织软件开发过程的框架。
它是由美国国防部软件工程研究所所开发的，并在全球范围内得到广泛应用。
CMMI流程适用于各种规模和类型的企业，可以帮助其提高软件开发的质量和效率。
CMMI流程包括五个层次，分别是初始级、被管理级、被定义级、被量化级和优化级。
每个级别都有其特定的目标和要求，组织可以根据自身的实际情况选择适合的级别进行评估和改进。
首先是初始级，该级别表示组织尚未建立成熟的软件开发过程。
在这个级别，组织可能缺乏标准化的过程和规范，且项目的成功主要依赖于个人技能和经验。
为了进入下一个级别，组织需要建立起适合自身需求和目标的软件开发过程。
被管理级是CMMI流程的第二个级别。
在该级别，组织已经建立了一些基本的软件开发过程，并且能够对其进行管理和监控。
组织需要确保过程的一致性和可重复性，以提高项目的可管理性和稳定性。
被定义级是CMMI流程的第三个级别。
在该级别，组织需要进一步明确定义和记录软件开发过程的各个环节。
这样可以确保项目团队的清晰工作流程和责任分工，从而提高项目的协同性和效率。
被量化级是CMMI流程的第四个级别。
在该级别，组织需要建立起一套有效的度量方法，以评估和监控软件开发过程的性能和效果。
通过定期收集和分析关键的度量数据，组织可以更好地了解其软件开发过程的强弱项，从而进行相应的改进和优化。
最后是优化级，该级别是CMMI流程的顶级级别。
在这个级别，组织已经建立了一套成熟和稳定的软件开发过程，并且能够持续改进和优化。
组织需要通过不断地学习和创新来提高自身的软件开发能力，以应对日益变化的市场和技术需求。
总之，CMMI流程是一种标准化的软件开发过程评估和改进框架。
它可以帮助组织建立起稳定和高效的软件开发过程，提高软件质量和项目管理能力。
通过逐步实现不同的级别，组织可以不断提升自身的软件开发能力，并与其他企业保持竞争优势。
应用CMMI模型改进软件项目开发流程
随 着软 件工 程 的深 入发 展 ，世 界各 国的软 件 企 量 认 证 机 构 国 家 认 可 委 员 会
（ ｈｎ Ｎ ｔ ｎ ｌ Ｃｉ ａ ａｉ ａ ｏ
ｃｅ ｉ ｔ ｏｎ ｉ ｆｒ Ｒ ｇｓ ａｓ Ｎ Ｃ ） ａｏ ｌ ｔ 业 越来 越重 视软 件工 程技 术 在软 件 开 发项 目中的 应 Ａ ｒｄｔ ｉｎ Ｃ ｕ ｃ ｏ ｅ ｉ ｒｒ，Ｃ Ａ Ｒ 决 定
ＭＭＩ 主要 是 针 对 大 型 Ｉｓｔｔ，Ｓ Ｉ 则 于 １９ ｎｔｕｅ Ｅ ） ｉ ９ ３年 正 式 发 表 了 能 力 成 熟 程 。同 时我 们也 应 该看 到 ，Ｃ
０ 度 模 型 （ａ ａ ｉｔ ｉ ｔｒｙ ｉ ｄ ｌ Ｃ ｃｐ ｂｌｙ ｎ ｕｉ ｎ ｅ， ＭＭ） ｉ ａ ｔ ｏ ，用 于 软件机构和软件项 目制定的标准 ，而我国 ９ ％的软
维普资讯
１ ４
深圳信息职业技 术学 院学报
件 开发过 程进 行监 督 和 管理 。本 文针 对 中小 软 件企
ＭＭＩ 所遇 到 的 障碍 以及 Ｃ ＭＭＩ 型 在 中小 模 Ｃ ＭＭＩ ，Ｃ ） ＭＭＩ 不但 包 括 了软 件 开 发过 程 改 进 ，还 业实 施 Ｃ 包 含 系统 集 成 、软 硬 件 采 购 等 方 面 的 过 程 改 进 内 项 目中实 施时 暴露 的 缺陷进 行 剖析 ，并 给 出了相 应
ＭＭＩ 的正 式 使 用 。Ｃ ＭＭＩ 有 分 共 的 发展 和 国际 化进 程 ，１ ９ ９ ７年 ６月 １ １日， 中国质 这 次发 布 标 志着 Ｃ
［ 收稿 日 期］２ ０ 一 卜２ ０６Ｏ ０ ［ 作者简介］李晓堂 （９ ８ ） １７ 一 ，女 （ ，辽 宁辽 阳人，助教 ，Ｅ ｍ ｉ 汉） —ａ
自 １９ 年 Ｓ Ｃ ９１ Ｗ— ＭＭ 首 次 发 布 后 ，Ｓ Ｉ Ｅ 又开 发
产品研发流程
为提高软件产品质量，提升客户满意度，打造软件生产线，增强市场竞争能力，我公司产品研发流程遵循CMMI软件开发过程体系。
产品研发流程整个开发流程分为：可研、需求获取、技术准备、编码、系统测试、系统实施、项目总结、维护。
可研1.由公司或者部门领导派发《项目任务书》2.产品经理分析任务书，确定项目范围、分析技术可行性、确认可行技术方案和技术难点、初步预估工作量、确定项目进度可行性和经济可行性3.整理为《可行性研究报告》或《项目建议书》4.对报告或建议书进行评审，生成《评审报告》需求获取1.根据《项目建议书》，产品经理准备和项目相关的资料，如果是升级项目，需要获取原项目的《用户需求说明书》。
2.通过各种方式，和客户进行多方面的交流，获取用户的原始需求，生成组织架构图、角色分类、功能描述、用例图描述，编写《用户需求说明书》草案。
3.产品经理和需求分析师根据草案，生成系统原型，并展示给用户，确认需求的正确性，并随时修改。
4.完成最终《用户需求说明书》和《需求跟踪矩阵》。
5.组织专家、测试人员等对说明书等进行评审，通过后生成《评审报告》。
6.《用户需求说明书》提供给用户确认，并签字确认。
需求分析1.根据《用户需求说明书》、《需求跟踪矩阵》、《项目建议书》，由产品经理和系统分析师，完成系统功能划分、用例建模分析、数据建模分析、过程建模分析、识别接口需求，最终编写出《软件需求说明书》。
2.由中心经理、开发经理、质量经理、系统分析师、软件工程师、测试工程师共同评审《软件需求说明书》，生成《评审报告》。
技术准备1.根据《软件需求说明书》等文档，由产品经理、系统设计师、软件工程师分析、制定、选择技术解决方案。
2.如选择的最佳技术方案中有陌生技术和新技术，则生成《技术攻关任务单》。
组织软件工程师攻关，解决后编写《技术攻关报告》以及相关Demo等。
3.中心经理、质量经理、系统设计师、软件工程师对《技术攻关报告》进行评审。
4.产品经理根据《技术攻关报告》调整《项目计划》。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件开发流程软件项目生命周期模型需求分析需求分析流程图过程描述1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。
2、PM制定需求阶段日程表，该表须通过研发经理审核。
3、PM指示配置管理员建立配置库。
4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。
5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。
6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。
7、项目组人员与客户进行沟通，编写需求清单列表。
8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。
架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。
对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。
关于自行开发和采购复用的分析，如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用；本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购；否则，由项目组自行开发。
架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。
9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。
10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。
11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。
12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。
13、PM、测试负责人与临时项目组确定项目关键参数。
工作量、工期、日程、人数成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的管理。
）质量目标14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。
15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。
16、PM、测试负责人编制项目计划书。
17、PM、测试负责人编制项目日程表。
18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。
19、PM指示配置管理员建立配置基线。
20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
设计设计流程图过程描述1)项目经理组织项目组人员学习需求规格书；2)项目经理组织项目组中的开发人员确定设计约束，这些约束可能包括一下几个方面：需求约束，需求规格书中约定的设计约束；隐含约束，需求规格书中没有，但对系统的设计或者使用带来潜在影响的特殊约束。
3)项目经理及开发人员根据需求规格书、架构设计书进行设计，编制《设计说明书》。
基于对业务和现有系统结构的理解，划分/调整系统模块。
描述各系统模块协作实现各业务场景的处理流程(可用序列图)。
必要时(通常要反复几轮)，修正系统模块划分和处理流程。
描述各处理流程中的各活动的输入、处理、输出和可能的异常。
系统模块构成及其相互关系。
(可用类图、包图。
)系统模块内部设计。
(功能、管理的数据、对外的服务、对内的服务,要求明确各模块的对外接口。
)4)开发人员根据《需求规格书》、《架构设计书》进行设计、《设计说明书》进行用户界面和数据库以及接口等方面的详细设计，纳入《设计说明书》。
用户界面设计。
(建议使用Visio中的窗口和对话框、工具栏和菜单、公共控件这几个形状组来绘制，具体操作方法是：点击“文件”选项→选定“形状”→选定“软件和数据库”→选定“软件”→依次选定上述三类形状组。
)数据库设计。
文件设计(文件的存贮位置与名称、格式与内容定义。
)。
接口设计。
(含内部通讯接口、外部通讯接口、用户图形界面、报表、其它接口。
)5)项目经理组织开发人员、测试人员及其他技术骨干评审《设计说明书》。
6)配置管理员建立设计阶段配置基线；7)项目经理编制阶段报告(项目总结报告中的度量数据页面)，组织项目组人员并邀请部门经理召开阶段会议，并形成会议纪要。
编码流程编码流程图过程描述a)根据准入条件中的设计文档，绘制详细类图，以指导编码。
b)对生成的类图进行审核。
c)项目经理组织开发人员学习编码规范、用户界面规范，以保障程序的可靠性、可读性、可修改性、可维护性、一致性以及界面的规范性。
d)开发环境的配置项目经理或其指定人员在公司的《开发环境指南》的基础上编制开发环境配置说明，项目组成员遵照开发环境配置说明配置统一的开发环境。
e)编写及调试开发人员根据设计说明书和编码规范、用户界面规范的要求编写代码，自行进行检查、调试并解决BUG。
f)评审代码项目经理组织开发人员、项目组外的专家等对本项目修订的所有代码进行评审或审批。
g)进行自测开发人员对代码进行联调，对照测试人员编制的测试用例中的正常业务流程部分（在测试用例中已明确标出）进行测试，并全部通过测试。
联调测试中，不要求记录BUG，不须编制测试报告。
h)编写阶段报告项目经理编制阶段报告，召开阶段会议。
编码规范（见规范说明书）测试流程测试流程图过程描述1、测试负责人组织测试人员学习、评审《用户需求列表》、《需求规格书》。
在学习、评审过程中充分理解客户及业务需求，确保文档信息的正确性、充分性、一致性。
2、测试负责人组织测试人员完成编写整个项目的测试方案。
3、测试负责人组织测试人员基于《需求规格书》编写测试用例。
当《设计说明书》通过评审后，测试人员基于《设计说明书》对测试用例进行必要的调整。
测试用例的组织分类须遵循以下原则：测试用例的组织分类(例如，文档名、页面名、一级标题、二级标题等)必须与需求规格书中的各需求点明确对应起来。
4、测试负责人组织测试人员、开发人员、PM评审测试方案、测试用例。
5、测试负责人指示配置管理员将测试方案及测试用例文档入库。
6、测试负责人组织PM、开发人员、测试人员召开阶段会议并形成阶段报告。
验收流程验收流程图过程描述1)项目经理与客服人员沟通验收事项。
2)客服人员在客户指定的环境下参照《安装维护手册》进行产品安装调试，并把合同约定的文档、源程序等交给客户。
3)客服人员对客户进行系统操作方法培训。
4)客户试用系统开展业务，测试人员收集客户反馈的问题；如果客户验收测试环境与生产环境差异明显时，要进行性能测试，以保证满足系统性能需求。
5)测试人员在验收中发现缺陷并告知项目经理，项目经理将缺陷记录到BugFree中。
某些情况下（例如，缺陷描述不详、明显不是缺陷等）项目经理可以向相关人员（测试人员、客户）解释、说明，达成一致后驳回相关人员（测试人员、客户）提出的问题。
6)项目经理将缺陷分派给适合的开发人员。
7)开发人员分析缺陷的原因及解决该缺陷，并将该缺陷的解决方法及解决状态更新BugFree。
8)项目经理将所有已处理的缺陷转移至测试人员进行缺陷修复的确认。
如果测试结果表明缺陷仍未解决，项目组内测试人员通过项目经理将该缺陷返回给处理该缺陷的开发人员。
如果测试结果表明缺陷已解决，项目组内测试人员告知项目经理，项目经理关闭该缺陷。
9)在更新验收版本之前，测试人员要进行一次回归测试。
对即将发布的新版本，进行一次整体的测试。
10)验收中发现的缺陷累积到一定程度或严重缺陷导致验收无法继续时，应更新验收版本。
必须解决的缺陷全部解决后，配置管理员更新代码及配套文档并标识验收的产品版本，项目经理指定人员更新验收版本并部署至验收环境中。
测试人员分析本次更新涉及的范围，确定回归测试的范围，并在此范围内进行回归测试。
如果更新验收版本之后，要回到活动4，直至验收通过。
11)项目经理和客户代表根据验收期间的测试记录等依据验收通过准则，达成一致，根据所签署的商务合同，向客户交付合同中要求提供的交付物，包括《用户手册》、《安装维护手册》等，并取得客户验收通过的书面确认。
12)项目经理收集整理项目相关的资料和数据，在项目组内分配项目关闭各项工作，包括技术总结、软件产品总结，相关数据整理等。
13)配置管理员对配置库进行更新，整理相关工作产品。
14)项目经理收集项目组成员反馈的建议，根据对项目的监控过程进行项目总结，编制项目总结报告。
15)项目经理召开项目总结会议，邀请项目组成员、QA、技术总监、技术部骨干人员参加。
必要时可邀请客户参加。
16)项目经理向QA、配置管理员发出项目结束通知，申请配置库归档。
配置管理员收回该项目配置库权限，在《研发部配置项列表》中更新相关信息，并通知项目组、QA。
研发部释放项目组占用资源。
项目正式关闭。
2012/2/16zsinba。