软件过程管理指南
软件过程管理指南
Software Process Manage Guide
文档标识：
修订记录
版本
说明
作者
批准
批准日期
V1.0
第一次发布
曾奋瑞
Marco
2007-03-01
目 录
软件过程管理指南.... 1
1.... 序言.... 8
1.1 简介... 8
1.2 目标... 8
1.3 适用范围... 8
1.4 术语... 8
2.... 文件清单.... 9
2.1 软件项目策划PP. 9
2.2 软件项目跟踪与监督PTO.. 9
2.3 需求管理RM... 10
2.4 软件生命周期LC.. 10
2.5 软件质量保证SQA.. 12
3.... 项目过程.... 12
4.... 组间协作.... 15
5.... 关键实践集.... 15
5.1 项目准备... 16
5.2 软件估计... 16
5.3 启动会议... 16
5.4 迭代开发... 17
5.5 设计界面雏形与用例说明... 17
5.6 特征跟踪... 19
5.7 设计领域模型... 19
5.8 详细设计... 19
5.9 使用项目工作管理系统... 20
5.10 里程碑会议... 21
5.11 风险清单... 22
5.12 技术评审... 22
5.13 建立配置库... 24
5.14 变更控制... 25
5.15 组件重用... 26
5.16 持续集成... 27
5.17 单元测试... 27
5.18 启动测试流程... 28
5.19 缺陷管理... 28
5.20 系统发布... 31
5.21 实施管理... 32
5.21.1 实施型项目月计划... 32
5.21.2 实施型项目月报... 33
5.21.3 系统发布说明... 33
5.22 产品与项目管理... 33
5.23 客户问题管理... 34
5.24 软件质量保证... 34
6.... 图表索引.... 37
7.... 引用的过程及规程文件列表.... 37
1 序言
1.1 简介
江西贝思特信息科技有限公司的各级管理人员和各个开发组都认识到，只有通过不断的过程改进才能使我们人员的能力和先进的技术得到充分的发挥。因此，公司决定采用软件能力成熟度模型（CMMI3 ）这一标准来提高软件组织的工作效率、产品质量和项目的可预见性。
为了使公司所有项目组都使用统一的过程和文档，得到的文档和实践集合将被所有大小项目组共同使用。这些文档和实践集合同时也是项目执行绩效考核的指标。
1.2 目标
1、 确定软件开发过程中最基本的文档模板和实践
2、 统一项目组的过程管理
3、 项目执行绩效考核的指标
4、 公司顺利推行CMMI3
1.3 适用范围
公司所有项目组的软件产品开发过程管理要求符合本手册的要求。
1.4 术语
PP：Project Plan项目策划
PTO：Project Tracing and Oversight项目跟踪与监督
RM：Requirement Management需求管理
SQA：Software Quality Assurance软件质量保证
SCM：Software Configuration Management软件配置管理
LC：Life Cycle生命周期
SCCB：Software Change Control Board软件变更控制委员会
NC：NonCompliance不符合问题
2 文件清单
下面列出经过过程裁减后的文件最小集合，文件的使用方法请参见模板。
2.1 软件项目策划PP
以下文件路径为：http://192.168.0.20
序号
文件名称/文档标识
文档类型
使用频率
备注
1.
软件开发计划/
软件工作产品
一个
需要正规技术评审
需要上传到项目工作管理系统
2.
项目估算表
软件工作产品
一个
需要正规技术评审
需要上传到项目工作管理系统
3.
软件主进度计划/
软件工作产品
一个
使用项目工作管理系统，有必要可以导出。需要正规技术评审
需要上传到项目工作管理系统
4.
迭代进度计划/
软件工作产品
每个迭代周期一个本周期的进度计划
使用项目工作管理系统，有必要可以导出
2.2 软件项目跟踪与监督PTO
以下文件路径为：
序号
文件名称/文档标识
文档类型
使用频率
备注
1.
启动会议纪要
软件工作产品
每阶段一个
需要上传到项目工管理系统
2.
周例会纪要/
软件工作产品
每周一个
需要上传到项目工作管理系统
3.
风险状态跟踪表/
软件工作产品
一个
初始评估或者风险影响及状态等发生变化时填写
4.
项目工作总结/
软件工作产品
项目结束时每人一个
需要上传到项目工作管理系统
5.
里程碑工作总结/
软件工作产品
每个里程碑一个
需要上传到项目工作管理系统
6.
项目管理度量报告
软件工作产品
每个里程碑一个
需要上传到项目工作管理系统
2.3 需求管理RM
以下文件路径为：
序号
文件名称/文档标识
文档类型
使用频率
备注
1.
特征状态跟踪表/
软件工作产品
一个
每迭代周期更新。可以使用CaliberRM导出符合格式的文档
2.4 软件生命周期LC
以下文件路径为：
序号
文件名称/文档标识
文档类型
使用频率
备注
1.
工作任务书/
软件产品
一个
需要正规技术评审
需要上传到项目工作管理系统
2.
需求规格说明书/
软件产品
一个
需求规格说明书(SRS)包括：需求项与特征、PowerPoint演示文档、界面雏形(只需要增加原产品中没有的部分)、用例说明。其中对界面雏形变更修改不作要求。需要正规技术评审
3.
领域模型文件
软件工作产品
一个
ROSE的mdl文件，术语表文件
需要正规技术评审
产品模式不需要
新开发项目需要
4.
数据库设计文件(cdm文件)
软件工作产品
一个
有选择值的字段必须加上说明。需要正规技术评审
5.
概要设计说明书/
软件产品
一个
需要正规技术评审
6.
详细设计说明书/
软件产品
多个
1个模块或几个模块1份。需要走查
7.
用户手册/
软件产品
一个
在线帮助，使用帮助文档工具编写，例如robohelp。需要走查
8.
部署说明书/
软件产品
一个
9.
单元测试记录表/
软件工作产品
一个
10.
系统测试用例/
软件工作产品
一个
保存在TD中，项目结束时导出到文档放入项目组的配置库。需要走查
11.
系统测试总结报告/
软件工作产品
每个里程碑一个
12.
系统测试任务单/
软件工作产品
每次提交到测试组测试时一个
填写纸质文件
13.
技术评审报告/
软件工作产品
每次评审一个
14.
系统发布操作手册
软件工作产品
一个
包含多个系统的发布操作说明，和单个系统的发布说明，写明重要的检查内容
15.
系统发布说明
软件工作产品
每次向客户发布时一个
填写电子文件，打印纸质签字
2.5 软件质量保证SQA
以下文件路径为：
序号
文件名称/文档标识
文档类型
使用频率
备注
1.
SQA进度计划/
软件工作产品
一个
走查
2.
SQA报告/
软件工作产品
每月一个
每周更新
3.
项目阶段质量检查表/
软件工作产品
每个里程碑一个，项目结束时一个
4.
SQA质量报告/
软件工作产品
每里程碑及项目结束时一个
3 项目过程
文档必须和过程结合在一起，才能发挥作用。我们可以将项目过程及文档分为技术和管理两个部分。下图描述在软件工程和项目管理的各个步骤文档的输出。
软件工程的文档输出
项目管理的文档输出
4 组间协作
A.软件项目内各组之间（如QA组，CM组，测试组，开发组等）的交流、协调工作由项目经理负责，一般采取项目会议的形式。任何组如果有计划上的变更，需要通过会议、进度报告和内部邮件的方式与各相关组进行约定。
B.需与项目外其它组进行的协作，则通过PM或高层经理完成，协调工作的进展与结果可通过会议、进度报告和内部邮件的方式与各相关组进行沟通。
C.与客户联络工作由客户交流窗口和项目经理（可为同一人）共同负责，必要时，高层经理也会适当参与。如果有计划上的变更，需要通过会议、进度报告和内部邮件的方式与各相关组进行协商。
5 关键实践集
这些关键实践来自于经典软件工程和CMMI的实践方法和经验总结。无论项目组大小，项目采取何种生命周期，项目实施周期长短，熟练运用这些实践可以起到很好的效果，例如缩短原定进度，改善过程可视性，降低项目风险等。因此这些关键实践是每个项目都必须执行的。
5.1 项目准备
项目准备阶段，项目经理与需求分析人员进行初步的需求调研，整理客户需求形成工作任务书，并根据工作任务书制定项目计划(包括软件开发计划、软件主进度计划、软件项目估计)，软件开发计划中必须指明需求规格说明书、概要设计说明书的评审时间。列出初始评估的风险状态跟踪表。工作任务书、项目计划评审通过，配置库和TD库建立之后正式进入第一个迭代周期。
5.2 软件估计
通过功能点估计法可以估算出一个产品的规模。在项目策划初期，根据需求估计出功能点数，由公司的生产率（功能点数/人月），可以得出完成系统所需的工作量，作为人力资源安排的参考。在需求项有变化时也应更新估计。
理解客户需求最好的办法是站在客户的角度分析软件系统产生的结果，从而来确定客户关心的问题。功能点分析的一个主要的目标就是从用户的角度定义系统的能力。从用户的观点来看，系统是从五个基本方面帮助他们进行工作的：
内部逻辑文件、外部接口文件、外部输入、外部输出、外部查询
除了以上五个方面，功能点分析中还要考虑分布式数据处理、在线更新等14项复杂度的调整。
功能点估计的模板参见配置库：\软件过程管理指南(适用于公司所有项目)\pp\template\《软件项目估计模板(comtop-pp-tmp-est).xls》。
5.3 启动会议
启动会议(包括阶段启动会议)的参与人员有：研发中心经理、项目部经理、技术研究部经理、项目经理、软件工程组（包括分析设计、开发、测试、配置管理工程师）、质量保证工程师、文档支持组等。
会前的准备工作：
确定项目经理，挑选合适的人员加入软件工程组，确定项目需要的资源和支持，包括人力资源，设备，工具，文档支持，技术研究部的支持，设备采购的支持等。
启动会议的主要内容：
介绍项目背景，目标，范围以及项目的风险；
正式任命项目经理；
确定项目的组织结构和人员的角色职责；
采用头脑风暴法进行团队建设活动，为团队命名，口号，行动纲领，队徽。
5.4 迭代开发
经过几十年的发展，软件工程领域出现了很多种软件生命周期模型，有瀑布型，迭代型，增量型等等。瀑布模型来源于建筑行业、制造行业等可预测的生产，本来就无法适应需求不稳定的软件项目。因此许多项目尽管在一开始就规定采用瀑布型，却在实践中慢慢变成了迭代型。迭代是一个能够产生内部版本的袖珍项目－或多或少要经历所有的核心工作流。通过循环反复的活动和原则使产生的结果越来越接近期望的结果。
迭代型的开发进度计划可以分为两个层次，第一个层次是总体的计划(主进度计划)，可能历时几年或者几个月，为团队的工作指出了方向。在总体进度计划中主要关注里程碑，每个里程碑要完成的目标或者需求项(可以包括特征)。总体计划划分整个项目的工作到各个迭代周期中，并不关注执行细节，时间跨度较大可能会因为需求的变化而修订。总体计划要确定迭代周期多长，一般为2-3周。第二个层次是短期的详细计划，即各个迭代周期的计划，关注执行细节，将具体的任务落实到人，并且由于时间跨度小相对稳定，可以确定本迭代周期完成时的详细交付物。每次迭代，我们只需要制定当前迭代周期的计划即可，到了迭代的后期才能确定什么需要在下个周期内完成的事情。进度计划中必须包含项目管理的工作，如编写文档、评审、代码走查、周例会等。
总体计划中，2-3个迭代周期要定义一个里程碑。
作为迭代周期完成的标志，每个迭代周期完成后要开会总结，评估迭代的交付物，明确下一个迭代周期的任务。
5.5 设计界面雏形与用例说明
对于产品型的项目，产品中已有的部分不需要编写界面雏形，只需要对产品中没有的模块设计界面雏形，对于非产品型的项目，必须设计界面雏形。
界面雏形作为需求规格说明书的一部分，在与客户或相关人员沟通时，比用一般的书面文字说明更容易被理解，从而更有效的获得用户及相关人员的反馈。
需求或设计变更后，对界面雏形的修改不做要求。
界面雏形使用html编制，使用ppt向客户进行演示。
设计界面雏形用来收集用户的需求有以下好处：
使最终用户更热情的参与到需求活动中来，并且改善系统需求的反馈；
减少项目风险，因为用户接口中具有风险的部分在早期就发现了；
使软件产品和最终用户的需要更接近；
减少系统特性的数量，迅速确定系统的特征和功能；
减少用户需求的变化；
提高项目早期工作进展的可见性。
用户界面雏形要让用户参与，积极征求他们的反馈意见。用户界面雏形要有一个漂亮的外观吸引用户的注意力。最好让经验丰富的开发人员来构建界面雏形。在构建界面雏形时，开发人员要有一个良好的意识，就是要以尽量小的工作量来探明界面雏形中涉及到的风险。
用例描述了在不同条件下，系统对某一系统相关人员的请求所作出的响应。提出请求的人员被称为执行者。执行者通过发起与系统的一次交互来实现某个目标。根据执行作出的请求和请求涉及的条件，系统将执行不同的行为序列（基本流程与可选流程）。
一个用例至少要包括以下几个部分：
用例名称
执行者：启动与被讨论系统的一次交互活动，从而达到某一目标的人或物。
前置条件：在用例执行之前必须满足的条件。
基本流程：一切顺利的情况。
可选流程：执行过程中出现的不同情况
业务规则
用例详细地描述了系统被使用时的行为细节，在需求开发阶段，用例与界面雏形相辅相成，使得用户能够明白新系统到底是什么样的。有利于用户尽早对系统运行的细节作出判断。
用例评审通过后，开发人员据此进行设计与编写代码，测试组参考编写测试用例，文档编写组参考编写用户手册。
当用户需求有变化，必须更新用例说明。
编写用例时，应显示执行者的意图而不是动作，并避免大量描述用户接口，如想象中的界面及其按钮。使得用例变成了用户手册，而不是需求文档。
5.6 特征跟踪
需求项的粒度过大，对于需求项的完成及变更情况难以跟踪，不利于迭代。我们将每个需求项细分为若干个特征，可以很方便的将特征分配到各个迭代周期中，从而对特征的完成情况及变更进行跟踪，使项目更容易被控制。将需求项细分为多个特征，比如：项目审批（需求项）可以分为以下特征：增、删、改、查、关联到申请书、发送、批量发送、默认回退、指定回退、改变申请人等。项目组在需求管理中必须利用特征跟踪表对特征进行跟踪。
5.7 设计领域模型
在概要设计评审之前，项目组必须使用ROSE完成领域模型的设计（*.mdl文件），对领域模型必须划分出包的结构，以类图的形式来表现，类图中要有类的关键属性、类之间的关联关系（聚合，组合，关联，泛化，实现，一对多，多对多等），领域模型不需要描述类的方法。应该使用术语表来说明类图中的英文含义。术语表另附文件。
在系统开发过程中，领域模型设计必须与最新的变化保持一致。
5.8 详细设计
1） 详细设计说明书的定位：起沟通和备忘录的作用
2） 项目组确定哪些模块需要编写详细设计，以及模块的英文简写，并提供清单给QA
3） 详细设计说明书的内容：
ü 各模块之间的联动，对一个模块的操作将引起其他哪些模块做哪些变化
ü 公式(比如资金计算公式等)及算法
ü 实现时候的注意事项，例如性能、数据库事务等
ü 查询、导出的数据的检索条件
ü 权限的分配(数据权限，操作权限等)
ü 新增数据的初始值
ü 数据的状态变化，例如项目的状态值
ü 级联删除
ü 不能重复的信息，例如用户帐号
……
以下内容不必写在详细设计文档中：
ü 系统的操作步骤
ü 界面的跳转
ü 系统的按钮操作
……
4） 详细设计说明书的描述：可以是文字、图形、表格、结构化语言。模板参见\软件过程管理指南(适用于公司所有项目)\lc\template\详细设计说明书模板
5） 项目组要走查详细设计说明书
5.9 使用项目工作管理系统
项目工作管理系统是江西贝思特信息科技有限公司为管理项目而开发的一套管理系统，其中最主要的功能是进度安排、项目文件和工作日志。每个项目组必须使用项目工作管理系统进行项目内部的协作和沟通。具体要求如下：
项目经理制定总体进度计划，确定里程碑。
项目经理制定迭代进度计划，并将工作分配给项目成员。
项目成员在完成工作后必须及时填写进度安排的实际开始和结束时间。
项目发生需求变更或者进度落后时，项目经理必须及时更新进度安排以符合实际情况。
项目过程中产生文档必须及时上传到项目文件中，使相关人员了解到项目的实际情况。必须上传的文件见第2章文件清单，必须上传的文件在“备注”一栏有说明。
项目的所有成员包括项目经理每天都必须填写工作日志。
项目经理必须每天查看项目组员的工作日志。
每周必须有周例会纪要，周例会纪要必须24小时内放入配置库及上传到项目工作管理系统中。
5.10 里程碑会议
项目经理需要确定项目采用何种软件生命周期模型，默认情况下里程碑就是各个阶段点。阶段点太近时可以合并里程碑会议，项目中的一些重要事件也可以设定为里程碑。
里程碑会议之前要完成并通过项目的内部验收。里程碑会议上，项目经理总结该阶段的工作成果和交付项，研发中心经理、项目部经理将出席，就项目的上一阶段工作成果进行阶段性验收。如果有可能，应该邀请客户代表出席该会议。会议上对运行的系统进行演示，如果从项目开始或从上里程碑到当前里程碑有软件测试活动，则里程碑会议上测试组必须提交测试总结报告，SQA组提交阶段质量报告并且汇报内部验收的执行情况。
里程碑会议的主要内容是：
1. 与会人员与会议议程介绍
2. 阶段工作总结
3. 项目度量数据汇报
4. 质量保证工作汇报
5. 测试工作汇报
6. 组员谈本阶段的工作体会
7. 系统演示
8. 下阶段工作安排
9. 自由发言
5.11 风险清单
风险清单是一种能够帮助我们监控软件项目风险的简单的工具。该清单中包括了组织积累的各种等级的风险并对各个风险所制定的预防计划。能够提高项目组的风险意识，同时能提醒大家尽快找到解决方法。
在有风险影响及状态变化时必须更新风险状态跟踪表，风险清单应该由项目组共同维护，包括项目经理、软件工程组、SCM、SQA。
5.12 技术评审
1） 技术评审分为走查（可以是代码走查、文档走查），正规评审
2） 对需要评审的文档项目组内部必须事先达成一致
3） 在正式评审前要有个预备会议，作者进行讲解（或由作者个别沟通讲解），使评审员都对文档了解后再进行评审
4） SQA在正式评审前先询问与会人员是否了解文档的内容，若有人不了解，会议另行择期举行
5） 建议技术评审使用各类检查表（参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\lc\checklist）。评审人员在评审过程中可以对原有的检查表进行完善和补充，将完善后的检查表提交给SEPG审查后入配置库
6） 评审人员在正式评审会议上提出所发现的缺陷
7） 限制评审会的时间，最好不超过2小时
8） 评审会后24小时内将发现的缺陷录入TD，填写技术评审报告并入配置库
a) 文档评审中发现的错别字可以当场改正，不需要作为缺陷录入TD
b) 组内代码走查需要将发现的缺陷录入TD并且填写技术评审报告
9） 跟踪人检查缺陷的修改与关闭
10） 评审发现的缺陷必须在一周内关闭
11） 技术评审的文档与参加角色
文档名称
评审形式
参加角色
工作任务书
正规技术评审
高级经理、项目经理、SQA
软件开发计划、软件主进度计划、软件项目估计
正规技术评审
高级经理、项目经理、SQA、测试人员、技术研究部代表
需求规格说明书
正规技术评审
高级经理、项目经理、SQA、测试人员、技术研究部经理
领域模型文件
正规技术评审
高级经理、项目经理、SQA、技术研究部经理；评审时间在需求规格说明书评审之后，在概要设计说明书评审之前。
数据库设计文件(cdm文件)
正规技术评审
项目经理、技术研究部代表
概要设计说明书
正规技术评审
项目经理、技术研究部代表
详细设计说明书
走查
项目经理、设计人员、开发人员
系统测试用例
走查
项目经理、测试人员、设计人员
用户手册/在线帮助
走查
项目经理、测试人员
12） 项目结束时，必须对领域模型、概要设计说明书、数据库设计进行再次评审
13） 代码走查说明
a) 各个项目无论是开发、实施、维护阶段，都需要进行代码走查
b) 各项目成员至少每周要check in提交一次代码
c) 每个项目组至少有一位代码负责人，代码负责人负责每天检查项目组最新入库的代码，主要检查Action、DAO代码是否有“常见的代码坏味道”(参见公司的BBS上的技术交流区 >> 软件工程>>关于代码走查的讨论)，Action、JSP文件的命名以及所在目录是否正确，并且尽量给出更合理的实现方式
d) 要求各项目组每周举行一次代码走查的会议，会议议程主要是公布代码负责人每天走查的情况和其他项目组走查的代码常见问题，会议中还可以抽查部分代码的规范问题
e) 每周进行代码重构，如没有进行，要说明原因(填写在技术评审报告中)
f) 每周提交一个技术评审报告
g) 代码走查委员会每月举行一次总结会议
5.13 建立配置库
配置管理是软件开发的最重要的基础。配置库在项目启动会议前建立，目录结构参见\软件过程管理指南(适用于公司所有项目)\scm\stadard\配置库目录结构.rar。
其中，配置库存放软件开发整个生命周期中的所有软件工作产品及软件产品。在项目开发的每个迭代周期完成之后，将该迭代周期内的所有完成评审的文档及相对稳定不变的代码进行受控，在配置库中对其文件或目录进行权限控制。
在每个迭代周期完成之后，建立一个产品基线。其中的源代码必须能够正常编译、打包、发布、单元测试及运行。产品基线分为外部产品发布基线和内部发布基线，在需要向客户发布系统时，必须建立外部产品发布基线，否则建立内部发布基线。基线标识请参见：\软件过程管理指南(适用于公司所有项目)\scm\stadard\项目工作产品命名方法
每个项目组都必须使用StarTeam来建立配置库。配置库必须统一目录结构和物理存放位置。配置库由配置管理员负责管理，或者项目经理充当配置管理员角色。开发人员只有在提交变更申请单后才被授权check out配置库中已受控相关配置项，修改提交后由配置管理员收回相应的check in权限。
通过配置项审计和基线审计，能够避免代码和文档丢失，确保配置项的安全。
质量管理部门将定期审计各个项目组的在配置管理方面的执行情况。具体的目录结构请参见：
\软件过程管理指南(适用于公司所有项目)\scm\stadard\项目文件架构
具体的配置项标识规则请参见：\软件过程管理指南(适用于公司所有项目)\scm\standard\项目工作产品命名方法
由公司的专门负责人对所有配置库进行备份。具体方法请参见：\软件过程改进\standard regulation \org level\公司备份制度
项目结束时，项目组必须把通过验收的产品基线(包括文档、代码、重用库组件源代码)刻盘备份
5.14 变更控制
每个项目组都必须建立变更控制委员会(SCCB)，即使该项目组只有2-3人，必须有各方代表组成，包括项目经理、开发人员、测试人员、设计人员、质量保证人员。
SCCB通常进行变更分析，评估进行变更的风险、工作量、影响的配置项等，根据评估结果接受或者拒绝变更。SCCB还能够把一些相关的细小变更打包给开发人员，而不是让开发人员处理一连串不协调的细小变更。
需要修改已经受控的配置项，必须按照变更控制规程执行。具体如下：
变更可能来自项目组内部（例如系统测试）或者客户，由建议者填写变更申请单，由项目经理初审，工作量小的变更项目经理可以直接批准，否则将提交SCCB评审。
SCCB分析出变更所影响的一系列工作，指定验证者和修改者完成变更的工作。
SCM授权相关配置项给修改者。
修改者check-out配置项，执行变更，并且进行技术评审或者单元、系统测试，然后将配置项check-in配置库，SCM收回权限将配置项受控。
验证者跟踪时确认文档经过了评审或者代码经过单元、系统测试。
SCM收回相关配置项的授权。
SCCB授权关闭
具体的变更控制流程如下图：（请参见变更控制规程）
变更控制处理流程
项目上线后一个月集中以会议形式给测试组提交需求变更，更新测试用例。
5.15 组件重用
重用是一个公司建立常用组件库的长远策略，它使新的程序可以很快的用这些已有的组件来集成。另外将现有程序中的代码移植到新程序中的方式，也可以作为短期的重用方式。
公司的重用管理小组直接负责维护可重用的组件库。
在项目开始时在重用库中对可重用组件进行检查，寻找到需要的组件。
在项目进展中发现需要创建可重用组件时，要及时将创建工作移交给重用管理小组来负责或者将项目组自己创建的重用组件交由重用管理小组负责管理。
如果在项目进展中有修改重用组件的需要或者发现重用组件存在缺陷，要通过缺陷管理工具（TD）及时反馈给重用管理小组，项目组无权直接修改重用组件。
在项目开始时，技术研究部必须为项目搭建系统框架，系统框架的内容主要有：登录、系统管理部分、菜单、权限处理以及一些常用的组件和使用功能：分页、字典、文档管理（文件上传下载）。
5.16 持续集成
1） 项目启动后项目经理确定持续集成开始时间，并告诉配置管理员和QA
2） 持续集成采用Ant和CruiseControl工具自动进行
3） 持续集成依次完成以下任务：建数据库表（SQL文件），自动从配置库获取源代码，编译（类＋JSP），打包，部署(EJB/Action/JSP)
4） 从开始时间起每天进行持续集成
5） 配置管理员每天查看持续集成结果，若失败，则查找原因，告知相关人员修改
6） 配置管理员每天把持续集成情况填写在工作日志中，如果失败要记录失败的原因
7） 至少每周成功一次
5.17 单元测试
1） 项目经理预先填写好待测试的功能名称在《单元测试记录表》，记录表模板参见\软件过程管理指南(适用于公司所有项目)\lc\template\单元测试记录表
2） 功能开发完成后，开发人员向项目经理或指定人员演示
3） 项目经理或指定人员在演示过程中检查功能、界面(按照界面规范检查)、数据库（打开数据库查看数据）是否正确
4） 在《单元测试记录表》记录检查情况
5） 《单元测试记录表》采用电子文档，存放于各项目组的配置库中SEDoc\test\testReport目录下
6） 每周更新《单元测试记录表》
5.18 启动测试流程
1） 项目组单元测试通过后填写《系统测试任务单》，列出该版本修改了哪些特征，或者指明测试的要点
2） 项目组向测试人员在测试环境中演示系统，同时讲解需求、特征的变化
a) 系统第一次提交测试时，项目组必须先根据《系统介绍》向测试人员讲解，然后演示系统
b) 在以后系统提交测试时，一般也需要演示，如果项目组与测试人员均认为不需要演示，则必须经过测试组组长的同意
3） 测试人员根据演示的情况决定是否接受测试
4） 如果接受，以后的测试执行按照《软件系统测试规程》中的相关规定进行。规程所在位置：\软件过程管理指南（适用于公司所有项目）\test\《软件系统测试规程》
5） 系统上线后半年内至少一个月要提交一次系统测试，从上次测试完成起算
5.19 缺陷管理
每个项目组都必须使用TestDirector来跟踪和关闭缺陷（包括测试和技术评审发现的缺陷）。
项目经理确定项目组成员名单和相关权限，填写《新建/修改TD库申请表》并提交给TD管理员，TD管理员建立项目TD库。申请表参见：\软件过程管理指南（适用于公司所有项目）\test\template\新建修改TD库申请表
缺陷管理的具体流程如下图(以测试为例)：
测试人员将系统测试中得到的缺陷录入TestDirector，此时任务的状态为New。
项目经理分配具体负责人完成修改缺陷的工作，此时任务的状态为Open。或者拒绝修改，更新状态为Rejected，或者暂缓修改缺陷，更新状态为暂缓。对于暂缓的缺陷，在项目收尾阶段分析、整理后提交到维护组。
负责人判断待修改的配置项是否受控，如果已受控则进入变更控制流程。
负责人完成工作后，修改状态为Fixed。
最后由测试人员验证缺陷是否可以关闭，修改状态为Closed。如果缺陷仍然存在，那么修改状态为Reopen。
有关活动的描述、缺陷等级、缺陷状态请参见：软件过程管理指南（适用于公司所有项目）\test\《软件系统测试规程》
缺陷管理流程
重用库缺陷处理：各项目组在TD库里建一个tr的账号，把测试发现的属于重用库的缺陷分配给他，然后通知（可口头或用工作通知的形式，但一定要通知到）重用库的维护接口人。
5.20 系统发布
若是多个系统(子系统)合并后的大系统（如EIS）发布，发布的子系统至少有一名熟悉的成员在旁协助，否则，可以拒绝系统的发布。
流程如下图所示：
系统发布流程图
1） 可选的步骤：拷贝系统日志
2） 第一版发布到正式服务器上之前，必须进行系统测试与性能测试。
3） 以后修改版发布到客户服务器之前，如果有数据库结构等可能影响到性能的修改，建议在与客户服务器相同(或类似)的环境下通过性能测试
4） 系统发布前必须由项目经理填写电子的《系统发布说明》，放入项目配置库的/SEDoc/deliever/。打印后，签字，交给配置管理员
5） 系统发布时，必须备份客户的数据
6） 系统发布根据《系统发布操作手册》进行
7） 将现场最新版发布文件(发布用的代码、只有表结构的dmp和初始数据的sql语句)打包成zip文件，打包文件命名参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\scm\standard\项目工作产品命名方法(comtop-scm-tmp-naming).doc
8） 将zip文件存放在专用服务器，只须保存最近两次的zip文件
注意：若到客户现场发布系统，项目经理要检查是否将修改的文件放入配置库。
5.21 实施管理
项目的整个生命周期可分为三个阶段：项目开发、项目实施、项目维护。
项目开发就是指系统上线前的阶段，过程管理的要求见本节之前的章节。
项目实施是指系统上线后项目组进行系统修改、完善的阶段。一般在软件开发的主进度计划完成之后进入项目实施阶段。
项目维护是指系统从项目组移交给专人维护后的阶段。
项目实施阶段的实践有：实施型项目月计划、实施型项目月报、系统发布说明。
5.21.1 实施型项目月计划
1） 每月底前制定下月的月计划，Project文件，内容有：任务名称、工期、开始时间、完成时间、前置任务、资源名称
2） 文件命名参见：\软件过程管理指南(适用于公司所有项目)\scm\stadard\项目工作产品命名方法
3） 发给产品经理，由产品经理汇总后发给各领导
4） 文件放入项目配置库/PMdoc/Plan/
5.21.2 实施型项目月报
1） 每月第一周编写上月月报，模板参见：\软件过程管理指南(适用于公司所有项目)\lc\temp\项目月报
2） 文件命名参见：\软件过程管理指南(适用于公司所有项目)\scm\stadard\项目工作产品命名方法
3） 发给产品经理，由产品经理汇总后发给各领导
4） 文件放入项目配置库/PMdoc/ProjectReport/
5.21.3 系统发布说明
1） 每次系统发布前必须由项目经理填写电子的《系统发布说明》，文档模板参见：\软件过程管理指南(适用于公司所有项目)\lc\template\系统发布说明
2） 文件命名参见：\软件过程管理指南(适用于公司所有项目)\scm\stadard\项目工作产品命名方法
3） 文件放入项目配置库/SEdoc/deliever/
4） 打印后，签字，交给配置管理员
5.22 产品与项目管理
本节的项目是指某个产品下的项目。
1） 配置管理
a) 配置库：产品配置库作为主视图，分出的各个项目作为子视图。项目开发在项目视图上进行，更新不反应到产品视图。产品基线建在产品视图上，项目的产品基线建立在项目视图上。
b) 产品变更一定按变更流程进行，通过SCCB会议确定。产品变更的来源：测试的缺陷；项目经理或成员提出的改进项
2） 产品经理必须参加项目前期的调研
3） 项目的工作任务书里记录该项目所来源的产品版本
5.23 客户问题管理
每个项目组一定要把客户问题用电子档形式记录下来，具体形式不拘（可以用TD，Starteam，Excel等）。
5.24 软件质量保证
SQA工程师的活动或任务有以下几类：
1） 参与项目组策划
a) 指导项目组完成启动会议前的工作
b) 协助项目组编写计划、估计等文档
c) 协助项目组确定项目所要遵守的标准、规范
d) 制定SQA进度计划
2） 评审项目组活动
a) 在项目的整个生命周期中，SQA工程师对项目组的软件工程活动、软件过程活动进行评审，验证其与指南、规范的符合性
b) 评审方法和频率参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\sqa\软件过程管理指南所有必备项列表及评审方法
3） 审计项目组工作产品
在项目整个生命周期中，SQA工程师对项目工作产品（软件工作产品和软件产品）进行审计，评估其与适当的模板、规范的符合性。
4） 不符合问题管理
a) 不符合问题：SQA工程师在评审或审计过程中发现的与软件过程管理指南偏离的问题
b)如果项目组成员发现有些做法不符合指南和规程，而又是在特殊情况下需要这么做，要事先跟SQA说明
c) 在评审活动过程中主要从以下几个方面判别是否存在不符合问题：活动是否进行了（与指南比较），活动是否进行得正确（与指南比较），活动是否按照进度进行（与项目计划进度比较）
d) 在审计产品过程中主要以以下几个方面判别是否存在不符合问题：是否符合模板，内容是否填写正确与完整，与相关文档是否一致
e) 不符合问题偏离程度：High－活动没有进行，工作产品没有；Medium－活动进行得不正确，工作产品的重要内容不正确
f) 不符合问题处理流程：
不符合问题处理流程
说明：SQA发现NC并录入NC库后要及时通知项目经理。
g) 不符合问题（NC）关闭：必须在一周内关闭
5） 定期汇报SQA活动
a) 周报：周例会上，向项目报告SQA活动情况，主要说明发现的不符合问题；每周五将所负责项目组的不符合问题报给高级经理和总经理，报告格式参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\sqa\template\SQA报告模板
b) 月报：每月最后一天将所负责项目一月的不符合问题统计上报给高级经理和总经理，报告格式参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\sqa\template\SQA报告模板
c) 阶段报告：项目组里程碑前进行质量检查，参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\sqa\template\项目阶段质量检查表；并且出质量报告，参见软件过程改进配置库：\软件过程管理指南(适用于公司所有项目)\sqa\template\SQA质量报告
6 引用的过程及规程文件列表
序号
类别
所属KPA
文件名称
1
组织级
SCM
《公司备份制度》
2
过程
《软件过程维护指南》
3
规程
LC
《软件系统测试规程》