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