转自：http://www.cnblogs.com/ecoboy/archive/2005/11/10/152113.html
第一部分 概述
1 目的
本规范的目的是使整个软件产品开发阶段清晰，要求明确，任务具体，便于规范化、系统化及工程化，有利于提高软件生命周期的控制及管理，提高所开发软件的质量，缩短开发时间，减少开发和维护费用，使软件开发活动更科学、更有成效。
2 适用范围
本规范适用于公司范围内所有以正式的项目形式进行的软件产品的开发；不包括需求获取、现场调试等内容。
本规范分为两个部分：技术过程规范和管理过程规范，分别适用于软件开发过程中的技术性活动和管理性活动。
3 过程模型
本规范所采用的软件开发过程模型为裁剪的RUP开发过程模型。
4 环境
建模语言
采用UML作为建模语言
建模工具
采用Rational Rose作为建模工具
配置管理工具
采用SourceSafe/Cvs作为配置管理工具，由项目经理根据具体情况自行决定。
变更和缺陷管理工具
采用ClearQuest作为变更和缺陷管理工具
需求管理工具
采用RequisitePro作为需求管理工具
单元测试工具
推荐使用Purify、Quantitify、PurifyCovervage、BoundChecker等工具，具体选择何种工具由项目经理自行决定。
引用规范
《C++编码规范》
指南
《需求建模指南》、《分析指南》、《设计指南》、《实现建模指南》、《数据库建模指南》
5 角色划分与组织机构
软件过程的每一个活动都由具体的角色执行；本过程所涉及的角色和组织机构及其职责如下：
系统分析员
管理需求
查找参与者和用例
确定性能要求
建立用例模型结构
用例工程师
详细说明用例
详细说明软件需求
用例分析
用例设计
需求复审员
复审需求
用户界面设计员
设计用户界面原型
确定边界类
* 一般界面设计员不参与界面部分的实现
构架设计师
确定需求优先级
构架分析
构架设计
构架实现
制定和组织学习编码规范
设计员
类的设计
子系统设计
数据库设计员
生成数据模型
设计复审员
复审设计
构架复审员
复审构架
程序员
实现构件
调试
单元测试
实现测试
开发安装软件
代码复审员
复审代码（该角色可以由技术监督小组成员兼任）
测试员
制定测试计划
设计测试
执行测试
评估测试
配置管理员
建立变更控制流程
复审变更请求
确认重复或拒绝的变更请求
管理基线
流程工程师
编制开发案例
启用开发案例
项目经理
制定软件开发计划
制定迭代计划
制定风险管理计划
协调项目运行
项目复审与变更控制委员会
该委员会是负责监督项目和控制变更的行政管理团队；在执行复审任务时，可由该委员会主席指派专人（项目复审员）负责。
建议该委员会由项目经理、构架设计师、需求提供方及有项目审批权限的3~5人组成，其中主席一职应当在需求和技术方面都有一定权威性。主席根据实际需要召开会议评估变更请求，对项目进行审批和项目计划复审。
该委员会有三个基本任务：
变更控制
明确产品的基线、复审对基线的变更、最后批准、否决变更或延期执行。由他们批准对已建立基线的配置项的所有变更。该团队的目的在于确保所有提出的变更都得到了妥善的技术分析与复审，并已记录备查。
项目审批与计划复审
项目审批；项目计划复审；迭代计划复审。
验收复审
迭代验收复审；生命周期里程碑复审；项目验收复审；
技术监督小组
与项目经理一起监控小组技术状态，建议每周由研发人员轮流执行技术小组组长职责，定期负责召开技术讨论会，审查上周进展情况及技术状态（软件模型完整性、代码规范性等内容），讨论本周工作计划、技术问题等内容并监督各规范的执行情况。
6 制品
该部分列出了工作流程所涉及的制品及这些制品的格式。（该部分的表格不太容易画，若有需要该部分的同志，可以向我索取ZXHSCOTT@SINA.COM）
(第一部分结束)
第二部分 管理过程规范
管理规程规范分为两个部分：项目管理过程规范、配置与变更管理过程规范。
7 项目管理过程规范
7.1 过程概述
项目管理过程如下图所示
管理过程贯穿于软件开发过程的始终，它也随着开发过程的迭代进行自身的迭代。
7.2 项目准备7.3
7.3.1 概述
项目准备活动在软件开发过程中只进行一次，即在项目初始阶段的第一个迭代中，而且它是最早进行的活动。
7.3.2 确定并评估风险
执行角色
项目经理
活动描述
项目经理 确定潜在的风险，分析风险、确定风险的优先级并制定风险规避和降低策略，填写《风险列表》；
制品
《风险列表》（草拟）
7.3.3 启动项目
执行角色
项目经理
活动描述
指派项目复审与变更控制委员会成员；
由项目复审与变更控制委员会正式任命项目经理；
指派项目计划团队（项目计划团队是将要执行先启阶段工作的项目团队初始成员。计划团队由项目经理和项目复审与变更控制委员会共同确定、批准和指派。通常，项目计划团队可能会包括项目经理、构架设计师、系统分析员、开发负责人、测试负责人、配置管理员、领域专家）；
已正式或非正式的形式规定技术监督小组及组长的任命规则；
批准项目验收标准，对于有明确合同要求的软件项目，合同的要求可以作为验收标准；
由以上内容形成《软件开发计划》的“组织结构”部分；
制定用于初始阶段的第一次迭代的迭代计划，形成《迭代计划》；
制品
《软件开发计划》初稿；
初始阶段第一次迭代的《迭代计划》。
7.3.4 定义项目组织与人员配备7.3.5
执行角色
项目经理
活动描述
项目经理决定项目组的梯次，即管理、需求、分析设计、质量保证等，并决定每个梯次所需的角色和职责。对于规模较小的项目，项目经理可以直接定义所需人员的数量、人员的技能，将该部分内容写入《软件开发计划》的“人员配备计划”部分。
制品
更新的《软件开发计划》；
7.3.6 制定质量保证计划
执行角色
项目经理
活动描述
确保制定了项目的质量目标（项目经理部需要制订质量目标，但应确保已经由该目标存在）；
确定质量保证角色与职责；
确定质量保证任务与时间表，质量保证活动主要指各种复审，即计划复审和验收复审；
形成《质量保证计划》；
制品
《质量保证计划》；
7.3.7 计划阶段和迭代
执行角色
项目经理
活动描述
定义项目阶段里程碑；
定义里程碑目标；
定义阶段内迭代的数量、长度和目标（确定将为每个项目阶段安排多少次迭代、确定分配给各次迭代的相对工作量、确定每次迭代的目标）；
改进里程碑日期和规模（根据在先启阶段结束时获得的信息来对估计加以改进）；
确定项目资源需求（确定角色及数量），定义该项目所需的资源数量和类型（按阶段/迭代分配）；
根据以上内容更新《软件开发计划》。
制品
更新的《软件开发计划》；
7.3.8 制定软件开发计划
执行角色
项目经理
活动描述
根据以上内容形成《软件开发计划》。
制品
更新的《软件开发计划》；
7.3.9 编制开发案例
执行角色
流程工程师
活动描述
根据项目的性质、进度要求等形成《开发案例》；
制品
《开发案例》
7.3.10 项目计划复7.3.11 审
执行角色
项目复审员
活动描述
安排召开项目计划复审会议的时间；
分发会议材料（风险列表、软件开发计划）；
召开项目计划复审会议；
根据复审会议的决定形成《复审记录》。
制品
《复审记录》
7.4 计划下一次迭代
7.4.1 概述
对下一次迭代进行规划。
7.4.2 计划下一次迭代
执行角色
项目经理
活动描述
确定迭代的范围，即确定哪些用例需要优先实现、哪些非功能要求需要优先考虑；
定义迭代活动，即根据以上确定的范围确定要执行的活动集（核心工作流中的那些部分）；
确定该次迭代要产生的制品；
将这些职责与人员对应；
形成《迭代计划》；
制品
《迭代计划》
7.4.3 制定软件开发计划
执行角色
项目经理
活动描述
改进里程碑日期和规模，制定更准确的阶段计划（要考虑已确定的用例数量、已确定的用例复杂性、已确定的风险等）；
制品
更新的《软件开发计划》；
*注：该活动并非必需的
7.5 管理迭代
7.5.1 概述
进行迭代日常的管理。
7.5.2 人员配备7.5.3
执行角色
项目经理
活动描述
将人员与角色对应；
任命技术监督小组组长和其他组员；
将对应关系写入《软件开发计划》的“人员配备”部分；
制品
更新的《软件开发计划》；
7.5.4 启动迭代
执行角色
项目经理
活动描述
将人员分配给工作包；
获取并分配非人员资源（例如工位、计算机等）；
发出工作单；
制品
《工作单》；
7.5.5 评估迭代
执行角色
项目经理
活动描述
评估迭代结果，检验是否已实现迭代目标，书写《迭代评估》；
考虑外部变更，拟定《变更请求》；
制品
《变更请求》；
7.5.6 迭代验收复7.5.7 审
执行角色
项目复审员
活动描述
安排召开项目计划复审会议的时间；
分发会议材料（风险列表、软件开发计划）；
召开项目计划复审会议；
根据复审会议的决定形成《复审记录》。
制品
《复审记录》；
7.6 监测与控制项目
7.6.1 概述
该活动主要是监控项目变更，处理变更请求；并非所有的变更都需要正式向项目复审与变更控制委员会提交并复审；一般影响较小的变更，比如轻微缺陷的修复可以由项目经理直接决定。
7.6.2 检测项目状态
执行角色
项目经理
活动描述
根据《迭代计划》和《软件开发计划》对项目的状态（包括进展、风险化解情况等）进行检测，并通过各种方式向项目复审员汇报。
制品
无；
7.6.3 安排和分配工作
执行角色
项目复审员
活动描述
将变更请求分配到迭代（一般重要的扩展请求会被延期到下一个迭代甚至更迟的迭代中，而缺陷修复一般在本次迭代中完成）；
分配职责；
说明工作和预期结果；
制定时间表；
如果必要，修改当前迭代计划，并在软件开发计划中反映出对将来迭代的影响；
发出工作单；
制品
《工作单》；
7.7 确定并评估风险
执行角色
项目经理
活动描述
项目经理 确定潜在的风险，分析风险、确定风险的优先级并制定风险规避和降低策略，填写《风险列表》。
制品
《风险列表》（更新）
7.8 阶段收尾
7.8.1 概述
该活动仅在阶段收尾时执行。
7.8.2 为阶段收尾做准备7.8.3
执行角色
项目经理
活动描述
检查所需工件的状态；
向涉众交付制品（具体制品见“附录一 项目里程碑”）；
制品
《软件开发计划》（交付）；
《状态评估》（最近的迭代形成的，交付）；
《迭代评估》（最近的迭代形成的，交付）；
7.8.4 生命周期里程碑复7.8.5 审
执行角色
项目复审员
活动描述
安排生命周期里程碑复审会议日程；
分发会议材料；
召开生命周期里程碑会议；
记录决定；
制品
《复审记录》；
7.9 项目收尾
7.9.1 概述
该活动仅在项目收尾时执行。
7.9.2 为项目收尾作准备7.9.3
执行角色
项目经理
活动描述
为活动安排时间表，此时间安排表应包含在软件开发计划中；
进行项目事后检查复审；
完成验收操作项；
项目收尾；
制品
《软件开发计划》（交付）；
《状态评估》（最近的迭代形成的，交付）；
《迭代评估》（最近的迭代形成的，交付）；
7.9.4 项目验收复7.9.5 审
执行角色
项目复审员
活动描述
安排项目验收复审会议的日程；
分发会议材料；
召开项目验收复审会议；
记录决定；
制品
《复审记录》；
8 配置与变更管理过程规范
8.1 过程概述
配置与变更管理过程如下图所示，其中前两个活动，即“计划项目配置与变更控制”和“创建项目CM环境” 主要在项目开发开始时调用，其他工作流程根据软件开发生命周期的进展情况进行调用。
8.2 计划项目配置与变更控制
8.2.1 概述
8.2.2 制定CM策略
执行角色
配置管理员
活动描述
确定配置标识方法；
确定建立基线方法：建立基线的里程碑、建立基线标记；
确定产品目录结构；
确定备份保存方法；
确定配置状态报告需求：选择基于变更请求的报告、确定报告频率；
制品
无。
8.2.3 建立变更控制流程
执行角色
配置管理员
活动描述
建立变更请求流程：
（1）完成变更请求单，提交变更请求
（2）分析、评估变更请求
（3）分配角色解决变更请求
（4）保存变更历史记录
制定变更复审通知协议；
制品
《配置管理计划》。
8.2.4 编写CM计划
执行角色
配置管理员
活动描述
编写CM计划；
复审并批准CM计划；
维护CM计划；
制品
《配置管理计划》。
8.3 创建项目CM环境
8.3.1 概述
8.3.2 设置CM环境
执行角色
配置管理员
活动描述
编设置硬件环境；
根据配置管理计划在项目储存库上建立产品目录结构；
制品
项目储存库。
8.3.3 创建集成工作区
执行角色
配置管理员
活动描述
在配置管理员设置好项目储存库后，创建集成工作区；
制品
集成工作区。
8.4 交付与变更配置项
8.4.1 概述
8.4.2 创建开发工作区
执行角色
任意角色
活动描述
任意角色在开始进行自己的日常工作前，应该在设置好的项目储存库上创建自己的开发工作区；
制品
开发工作区。
8.4.3 进行日常开发
执行角色
任意角色
活动描述
根据项目经理分配的工作单在自己的开发工作区上进行日常开发与变更工作，这些工作包括：检出、检入、添加、交付、更新工作区；
制品
更新的开发工作区。
8.4.4 交付开发
执行角色
任意角色
活动描述
完成分配工作单上工作内容后，向集成工作区交付开发（变更）内容，这些工作包括：从开发工作区检出，并检入到集成工作区、通知其他人员；
制品
更新的集成工作区。
8.4.5 更新开发工作区
执行角色
任意角色
活动描述
根据配置管理员的通知，从集成工作区check out其他人员的工作内容更新自己的开发工作区；
制品
更新的开发工作区。
8.4.6 建立基线
执行角色
配置管理员
活动描述
根据任意角色交付的已完成工作单，从开发工作区check in他的工作内容到集成开发工作区，
并建立基线，同时通知其他人员更新自己的开发工作区；
制品
基线。
8.4.7 晋升基线
执行角色
配置管理员
活动描述
当产品达到一定的成熟度、稳定性或质量级别，或某个里程碑，集成员与项目经理协商后可以晋升产品基线，这些工作包括：确定基线标记、在集成工作区晋升基线；
制品
基线。
8.5 管理基线与发布
8.5.1 概述
建立基线和晋升基线同上。
8.5.2 创建部署单元
执行角色
配置管理员
活动描述
配置管理员根据材料清单所列出的可交付工件从项目储存库中创建工件的拷贝；
配置管理员在项目储存库中对可交付工件建立或晋升基线；
制品
部署单元。
8.6 审核报告配置状态
8.6.1 概述
8.6.2 报告配置状态
执行角色
配置管理员
活动描述
根据配置管理计划中规定阶段和时间报告统计项目储存库中配置项状态的变化，并给出量化的配置报告（可以由ClearQuest直接生成）；
制品
《配置状态报告》。
8.6.3 执行配置审核
执行角色
配置管理员
活动描述
物理配置审核：
准备一份开发案例中给出的所有工件的列表
审核产品目录结构包含每一个工件
报告结果
功能配置审核：
列出产品功能
审核每项功能是否都有一个测试结果
报告结果
制品
《配置审核结果》。
8.7 管理变更请求
8.7.1 概述
变更会对项目项目产生影响，尤其是扩展性的变更以及需求的其他变更往往会对项目产生较大的影响。当这种变更出现时应当严格遵循该过程。较小的变更，尤其一些修复性的变更，项目经理可以自行组织处理。
8.7.2 提交变更请求
执行角色
任意角色
活动描述
完成变更请求单
提交变更请求，变更请求单状态为已提交
制品
《变更请求单》（已提交）。
8.7.3 更新变更请求
执行角色
任意角色
活动描述
接收变更请求表单（已重复或已拒绝）
更新并重新提交变更请求
制品
《变更请求单》（已更新）。
8.7.4 复8.7.5 审变更请求
执行角色
项目复审与变更控制委员会
活动描述
准备要复审的变更需求；
安排召开复审会议的时间；
复审已提交的变更请求；
制品
《变更请求单》（已复审）。
8.7.6 确认重复8.7.7 活拒绝的变更请求
执行角色
项目复审与变更控制委员会
活动描述
准备经复审怀疑认为重复或已拒绝的变更请求；
指定CCB代表确认重复或拒绝的变更请求；
更新变更请求状态：
（1）已确认重复或拒绝的变更请求应该关闭，同时通知变更请求提交者；
（2）要求提交者提供更多信息，或更新变更请求信息，说明不是重复或拒绝的理由，重新提交以备CCB复审；
制品
《变更请求单》（已拒绝）。
第三部分技术过程规范
本规范中将软件开发的整个技术过程分为五个顺序实施的工作流程，分别为需求、分析、设计、实现和测试。在一次迭代过程中，这五个工作流程从总体上是顺序的，但彼此之间又存在交叉和重叠。
9 需求
9.1 管理需求
执行角色
系统分析员
活动描述
通过访谈、问卷、审阅合同等形式收集用户需求；
通过走查等非正式形式评估需求收集结果，确保无需求重复、不一致、不清晰等问题；
*对于需求的变更请求，此时的变更请求应当已经过变更控制与项目复审委员会复审，可直接作为正式的需求；
在模型元素与需求之间建立可追踪性链接；
建立需求属性；
制品
需求集；
9.2 查找参与者和用例
执行角色
系统分析员
活动描述
命名并简述已发现的主角；
命名并简述已发现的用例，概述事件流并收集非功能性需求（记录在《增补需求》中）；
形成用例模型（描述用例间的关系并将参与者和用例打包）；
制品
用例模型（概要的）；
《增补需求》；
9.3 排列用例优先顺序
执行角色
构架设计师
活动描述
一般根据用例的重要性、风险来确定用例优先级；优先级可用数字表示，该数字表示该用例在那一次迭代中实现；优先级也可以用关键、重要、辅助等级来表示；
制品
用例模型（更新的）；
9.4 详细说明用例
执行角色
用例工程师
活动描述
建模某用例与其他用例、用例与参与者的关系；
详细说明用例事件流；
制品
用例（详细说明的）；
《SRS》；
9.5 原型化用户界面
执行角色
用户界面设计员
活动描述
用各种界面元素形成用户界面原型；
制品
用户界面原型；
9.6 组织用例模型
执行角色
系统分析员
活动描述
描述用例间的关系（包含、扩展、泛化），优化用例模型；
制品
用例模型（结构化的）；
9.7 复9.8 审需求
执行角色
需求复审员
活动描述
正式核实需求结果符合客户对系统的看法，建议召开复审会议，复审如下内容：
影响现有需求集的变更请求；
整个用例模型；
对用例及其图表的复审（适合每个用例）；
制品
《复审记录》；
10 分析
10.1 构架分析
执行角色
构架设计师
活动描述
编写构架概述，采取了使用大量图片、示意板或图标化图形的非正规形式来对构架进行概述，这部分工作通常只在项目早期进行；
定义子系统的高层组织，在构架分析中通常侧重于两个高层层次，即应用程序层和业务专用层；
根据该层次组织形成分析包，将一些紧密联系的用例分配给一个具体包，然后在该包中实现相应的功能，确定服务包，同一服务包中的分析类都用于相同的服务；
确定明显的实体类；
确定特殊需求，如分布与并发、永久性机制、安全性机制等；
制品
分析包（概要的）；
实体类（概要的）；
分析模型；
10.2 用例分析
执行角色
用例工程师
活动描述
确定边界类、实体类和控制类；为每个由人或其他系统充当的参与者确定一个主要的边界类；将参与某个用例实现的分析类收集到一个类图中；
描述分析类间的交互（主要用协作图实现）；
确定每个用例实现的所有需求（非功能性需求）；
制品
分析类（概要的）；
用例实现-分析；
10.3 形成分析类
执行角色
设计员
活动描述
确定分析类的职责，可以用类的成员函数来表示，但仅仅是概念上的；
确定分析类的属性，可以用类的成员变量来表示，但仅仅是概念上的；
确定分析类间的关系；
确定分析类特殊需求；
制品
分析类（完整的）
10.4 形成分析包
执行角色
设计员
活动描述
将相关性较强的分析类打包成一个分析包；
包间应遵循高内聚、低耦合的原则；
制品
分析包（完整的）
10.5 分析复10.6 审
不要求正式复审，但应当对分析过程的制品进行检查
执行角色
建议由构架设计师执行
活动描述
检查或复审分析类、分析包、用例实现-分析、分析模型；
制品
无
11 设计
11.1 构架设计
执行角色
构架设计师
活动描述
识别节点和网络配置，将这些元素映射到实施模型；
识别子系统及其接口（一般来讲一个子系统映射到一个分析包，子系统对应到一个可执行构件）；
识别对构架有重要意义的类（不要设计细节，数目不要太多），识别主动类（进程和线程），考虑并发要求，将这些主动类分布到具体的节点上；
制品
子系统（概要的）；
接口（概要的）；
设计类（概要的）；
实施模型（概要的）；
构架描述（设计模型和实施模型视图）；
11.2 用例设计
执行角色
用例工程师
活动描述
识别设计类，使用类图来表示参与某一用例的类；
描述设计对象间的交互（可以用序列图来表示对相间的交互）；
识别参与的子系统和接口；
描述子系统间的交互作用（用序列图）；
捕获实现性需求（非功能性需求）；
制品
子系统（概要的）；
接口（概要的）；
设计类（概要的）；
用例实现-设计；
11.3 形成设计类
执行角色
设计员
活动描述
根据分析类或接口来勾画一个设计类：边界类à用户界面类；实体类à数据库管理类；控制类à一个或一组类；
识别操作（跟踪分析类的职责、分析类的非功能性需求及接口）；
识别属性；
识别类之间的关系；
要对方法进行描述，尤其要对复杂的方法进行详细描述，可以由自然语言或伪码进行描述，也可以用状态图进行描述；
对于状态控制的设计对象，可以用状态图进行描述；
制品
设计类（完整的）；
11.4 形成设计子系统
执行角色
设计员
活动描述
形成设计子系统；
形成设计子系统的接口；
制品
子系统（完整的）；
接口（完整的）；
11.5 数据库设计
执行角色
数据库设计师
活动描述
在组件视图中创建数据库模型；
在逻辑视图中创建方案，将该方案分配给数据库；
在该方案中创建对象模型视图；
在方案中创建表、视图等；在表中创建列；
在数据模型视图中创建表之间的关系；
为数据库分配存储过程、触发器等行为；
制品
数据模型；
11.6 复11.7 审设计
执行角色
设计复审员
活动描述
复审设计模型总体，在先启阶段和精化阶段的早期，总体复审着重检测模型的整体结构，尤其重点检查分层和接口；
复审每个用例实现；
复审每个子系统（及其内容）或类（如果系统很小）；
制品
无；
11.8 复11.9 审构架
执行角色
构架复审员
活动描述
进行软件构架评估的最佳时机就是在精化阶段结束的时候。该阶段主要集中在对需求进行详尽研究，并建立构架的基线。构架复审由在该阶段的里程碑的流程确定。在此情形下，可以进行大范围的构架质量检查。
制品
无；
12 实现
12.1 构架实现
执行角色
构架设计师
活动描述
确定在生命周期早期对构架有重要意义的构件，以启动实现工作；
建立实现模型；
把可执行构件映射到节点上；
制品
实现模型；
构件（概要的，可能被映射到节点上）；
构架描述（实现模型和实施模型的视图）；
12.2 制定集成构造计划
执行角色
任意角色
活动描述
计划应实施哪些子系统，以及在当前迭代中按照什么顺序集成子系统；
根据一个完整的用例实现寻找要实现的构件并分配给不同的构造；
制品
实现模型；
《集成构造计划》；
12.3 实现一个子系统
执行角色
程序员
活动描述
当前构造所需的子系统内的每个类应当由实现子系统中的构件来实现；
当前构造所需的子系统的每个接口也应当由实现子系统实现；
制品
实现子系统（已完成设计的）；
接口；
12.4 实现一个类
执行角色
程序员
活动描述
实现成员函数；
制品
构件（完整的）；
12.5 单元测试
略。
12.6 集成系统
执行角色
任意角色
活动描述
验证工作版本并晋升基线；
制品
工作版本（更新的）；
12.7 复12.8 审代码
执行角色
代码复审员（可以由技术监督小组成员兼任）
活动描述
走查/审查代码是否符合《编码规范》，提出更改/返工意见；
制品
无；
13 测试
13.1 制定测试计划
执行角色
测试员
活动描述
确定测试需求，包括功能性需求（参与测试的用例）和性能需求；
确定测试优先顺序，一般分为：
H - 必须测试
M - 应该测试，只有在测试完所有 H 项后才进行测试
L - 可能会测试，但只有在测试完所有 H 和 M 项后才进行测试；
制定测试策略；
确定测试资源，包括人员、测试环境等；
制定测试进度；
形成《测试计划》；
制品
《测试计划》；
13.2 设计测试
执行角色
测试员
活动描述
确定并说明测试用例，测试用例应考虑分支情况；
构造用户说明如何执行测试用例的测试规程（若测试用例足够详细，测试规程可以省略）；
制品
测试用例；
《测试规程》；
13.3 实现测试
执行角色
程序员
活动描述
该部分主要用来产生测试构件以使测试自动化；该部分常用来产生测试数据、显示测试结果等；该步骤不是必需的；
制品
测试构件；
13.4 执行集成测试
执行角色
测试员
活动描述
对当前构造的每一个用例执行测试规程，或运行测试构件自动执行测试规程；
将测试结果与预期结果比较；
记录并提交缺陷；
制品
缺陷；
13.5 执行系统测试
执行角色
测试员
活动描述
与集成测试类似；
制品
缺陷；
13.6 评估测试
执行角色
测试员
活动描述
分析测试结果并提交变更请求；
评估基于需求的测试覆盖；
评估基于代码的测试覆盖；
确定是否达到了测试的完成标准和成功标准；
生成测试评估摘要；
制品
《测试评估摘要》；
浙公网安备 33010602011771号