软件研发流程0.2

卓朗科技

软件产品（项目） 简化研发流程

编号：

版本：V0.1 语言：中文

文件状态：草稿 保密级别：绝密 文件标识： 软件产品研发流程 当前版本： 0.1 作 者： 张雁佳 审 核： 完成日期： 2010年5月 变更记录

日期 2010-5-18

填表说明：

1. 日期：文档变更的日期。 2. 版本：对应文档的版本号。 3. 变更说明：简单的变更说明。 4. 作者：文档编写与修改者。

版本 0.1 变更说明 创建 作者 张雁佳 目录

1

引言 .......................................................................................................................................... 5 1.1 1.2 1.3 2

管理理念 ....................................................................................................................... 5 说明 ............................................................................................................................... 5 一些约定 ....................................................................................................................... 5

产品管理过程........................................................................................................................... 5 2.1

产品生命周期管理 ....................................................................................................... 5 2.1.1 产品策划 ........................................................................................................... 6 2.1.2 调研分析 ........................................................................................................... 7 2.1.3 产品立项与开发 ............................................................................................... 8 2.1.4 产品销售与服务 ............................................................................................... 8 2.2 销售管理 ....................................................................................................................... 8

2.2.1 营销策划 ........................................................................................................... 9 2.2.2 销售跟踪 ........................................................................................................... 9 2.2.3 合同管理 ......................................................................................................... 11 2.3 客户服务 ..................................................................................................................... 11

2.3.1 受理 ................................................................................................................. 12 2.3.2 处理 ................................................................................................................. 12 2.3.3 审核关闭 ......................................................................................................... 12 2.3.4 客户反馈 ......................................................................................................... 13 2.4 客户信息管理 ............................................................................................................. 13

3 项目管理过程......................................................................................................................... 14 3.1

立项管理 ..................................................................................................................... 14

3.1.1 立项申请 ......................................................................................................... 14 3.1.2 质量管理部受理 ............................................................................................. 15 3.1.3 立项评审 ......................................................................................................... 16 3.1.4 项目启动 ......................................................................................................... 17 3.2 结项管理 ..................................................................................................................... 18

3.2.1 结项申请 ......................................................................................................... 18 3.2.2 质量管理部受理 ............................................................................................. 19 3.2.3 结项评审 ......................................................................................................... 20 3.2.4 遗留问题跟踪 ................................................................................................. 20 3.2.5 项目工作总结 ................................................................................................. 21 3.3 项目计划与监控 ......................................................................................................... 21

3.3.1 项目人员角色 ................................................................................................. 21 3.3.2 任务进度管理 ................................................................................................. 21 3.3.3 项目成本管理 ................................................................................................. 22 3.3.4 项目评审（决策评审和技术评审） ............................................................. 23 3.4 变更控制 ..................................................................................................................... 24 3.5 沟通管理 ..................................................................................................................... 25 3.6 风险控制 ..................................................................................................................... 26

3.7 4

问题跟踪 ..................................................................................................................... 27

项目研发过程......................................................................................................................... 28 4.1

需求开发与管理 ......................................................................................................... 28 4.1.1 需求调研 ......................................................................................................... 29 4.1.2 需求分析 ......................................................................................................... 30 4.1.3 需求定义 ......................................................................................................... 30 4.1.4 需求评审 ......................................................................................................... 31 4.1.5 需求跟踪 ......................................................................................................... 31 4.2 系统设计 ..................................................................................................................... 31

4.2.1 软件系统设计 ................................................................................................. 31 4.2.2 设计评审 ......................................................................................................... 33 4.3 模块开发与集成 ......................................................................................................... 33 4.4 测试与缺陷跟踪 ......................................................................................................... 33

4.4.1 协商并提交测试 ............................................................................................. 34 4.4.2 测试准备 ......................................................................................................... 34 4.4.3 执行测试 ......................................................................................................... 35 4.4.4 缺陷跟踪（可以使用mantis等工具执行） ................................................ 35 4.4.5 消除缺陷 ......................................................................................................... 36 4.5 交付与验收 ................................................................................................................. 36

4.5.1 撰写文档 ......................................................................................................... 37 4.5.2 软件部署 ......................................................................................................... 37 4.5.3 用户培训 ......................................................................................................... 37 4.5.4 试用和验收 ..................................................................................................... 38 4.6 软件维护 ..................................................................................................................... 38

4.6.1 接受维护请求 ................................................................................................. 39 4.6.2 分析维护请求 ................................................................................................. 39 4.6.3 执行维护 ......................................................................................................... 39

5 支持过程................................................................................................................................. 40 5.1

软件配置管理 ............................................................................................................. 40 5.1.1 软件配置管理的概念 ..................................................................................... 40 5.1.2 软件代码管理的一般规则 ............................................................................. 40 5.2 文档管理 ..................................................................................................................... 41

5.2.1 文档管理的特征 ............................................................................................. 41 5.2.2 项目文档管理的一般规则 ............................................................................. 41 5.3 质量保证 ..................................................................................................................... 42 5.4 日志和周报 ................................................................................................................. 42 5.5 研发绩效评估 ............................................................................................................. 43

5.5.1 定义绩效体系 ................................................................................................. 43 5.5.2 填写绩效表格 ................................................................................................. 43 5.6 知识库管理 ................................................................................................................. 44

1 引言

1.1 管理理念

服务于公司的商业利益，诚实守信，人性化管理，做到规章制度标准化、人员配备标准化、过程控制标准化。

1.2 说明

该研发流程规定了四大过程的若干最佳实践。这里面的许多实践内容涉及技巧性与能力性，这些内容是对部门经理，产品经理，项目经理等角色的能力的考验，它直接关系到项目的成败。

该研发流程集成了作者在不同公司的经验与教训而成，文中参考了行业内2个咨询机构的研究成果，并对ISO9000系列、PMBOK、CMMI3 L1.2进行了适当的裁剪与整合。

1.3 一些约定

 产品生命周期：这里的产品生命周期并不是指从策划产品到产品消亡的整个过程，而是

指从产品策划到产品销售与售后服务的这一段过程。  项目生命周期：特指从项目立项、需求、设计、编码、测试、交付、结项与维护的整个

过程。  产品经理：对市场以及对产品所涉及的业务有独到的理解，对产品的开发、常规项目管

理、宣传、销售负责。  项目经理：传统意义上的项目经理在本约定中是产品经理的一个子集。  质量管理：立项与结项、QA过程监控、配置管理、测试团队，标准化。

2 产品管理过程

产品管理过程与项目管理过程、项目研发过程有重叠，重叠部分请阅读相关说明。

2.1 产品生命周期管理

产品生命周期管理流程如图2-1所示，主要活动有：产品策划，调研分析，产品立项与开发，产品销售与服务。该流程的主要工作成果和责任人见表2-1。

产品经理（产品组）销售与客服企业目标（战略）产品策划产品立项与开发调研分析图2-1 产品生命周期管理流程

产品销售与服务

主要活动 产品策划 调研分析 产品立项与开发 产品销售与服务 主要工作成果 产品建议书 产品调研分析报告 立项申请书，最终产品 产品宣传材料，销售合同，客服单 产品经理 产品经理 产品经理 主要责任人 产品经理，销售人员，客服人员。 表2-1 产品生命周期管理流程的活动及成果清单和责任人对应表

2.1.1 产品策划

活动描述：

产品经理或是由产品经理指定的人负责产品策划活动。产品经理应主动寻求研发部门的帮助，主要是技术层面上的支持，由产品经理牵头，撰写《产品建议书》，见表2-2。

特别注意：本产品立项之后，项目团队将进一步细化产品需求、设计方案和开发计划等。 “产品策划（产品建议书）” 的主要内容有：  产品概述  产品开发背景  消费群体特征  产品主要功能和特色  产品设计方案和关键技术  产品开发和上市计划 简要说明如下表所示：

产品建议书 1. 产品概述

用简练的语言说明本产品“是什么”，“什么用途”。 2. 产品开发背景 从内因、外因两方面阐述产品开发背景，重点说明为什么要开发本产品。 （1）内因方面着重考虑：开发方的短期、长期发展战略；开发方的当前实力。 （2）外因方面着重考虑：市场需求及发展趋势；技术状况及发展趋势。 3. 消费群体特征 （1）阐述本产品消费群体的特征； （2）说明消费者对产品的功能性需求和非功能性需求； （3）说明本产品如何满足消费者的需求，以及给消费者带来什么好处。 4. 产品主要功能和特色 （1）产品的主要功能列表； （2）说明本产品的特色。 5. 产品设计方案和关键技术 （1）阐述设计方案及原理，如果有多种方案，需比较优缺点。 （2）阐述本产品的一些关键技术，评价技术实现的难易程度。 （3）确定哪些产品部件应当采购、外包开发或者自主研发，说明理由，分析相应的风险。 6. 产品开发和上市计划 如果产品有多个版本，产品的版本是单支方式还是差异化主干分支方式，估算各版本的开发时间和上市时间，以及人员和资金。 表2-2 产品建议书

2.1.2 调研分析

活动描述：

产品经理在做产品策划时，应同步进行调研分析。产品经理撰写《产品调研分析报告》，目的是为公司决策提供充分的、有价值的信息。见表2-3。

特别注意：如果不做调研分析的话，那么产品建议和立项管理都建立在空想之上。 调研者应当客观地对待被调查的事物，不可有意往“好处”或者“坏处”设想。所获取的数据、图表等信息要真实并且有据可查，不可凭空捏造。

“调研分析（产品调研分析报告）” 的主要内容有：  消费者调研

 竞争对手与同类产品调研  调研

 技术和时间可行性分析  知识产权分析  成本—效益分析 简要说明如下表所示：

产品调研分析报告 1. 消费者调研 （1）购买者的特征和需求。 （2）使用者的特征和需求。 （3）影响者的特征和需求。 2. 竞争对手与同类产品调研 （1）各竞争对手在研发、销售、资金、品牌等方面的实力。 （2）同类产品的功能、质量、价格，以及主要优点和主要缺点。 3. 调研 （1）有无“支持”或者“”。 （2）有无地方（或其它机构）的“扶持”或者“干扰”。 （3）如何利用（应对）。 4. 技术和时间可行性分析 （1）本产品“做得了吗？”、“做得好吗？”。 （2）按照正常的运作方式，能及时开发完成本产品吗？投入市场的时间合适吗？ 5. 知识产权分析 （1）分析是否已经存在某些专利将妨碍本产品的开发与推广； （2）分析本产品能否得到知识产权保护，如何获得？ 6. 成本—效益分析 （1）估算总成本。 （2）估算总收益。 表2-3 产品调研分析报告

2.1.3 产品立项与开发

活动描述：请参考第三章项目管理过程与第四章项目研发过程。

特别注意：开发团队建议采用增量模式来开发产品，每次发布新的版本，既要请测试人员进行测试，又要请相关人员模拟来体验（试用）。同样，产品经理以及相关试用人员在项目研发的过程中应当站在用户的角度来体验（试用）当前产品。

如果发现产品中的缺陷，则向开发人员报告缺陷，开发人员及时消除缺陷。

若试用人员向产品经理提出改进建议，双方应先就需求和改进措施达成共识，然后开发人员执行相应的改进措施。

2.1.4 产品销售与服务

活动描述：

产品开发的完成之后，产品经理应着手进行如下几项工作： 撰写产品介绍文件（如ppt文件）。（也可在产品研发的末期进行） 制作本产品的宣传网页，设法在某些网站发布产品信息。 可能需要设计和制作宣传页（印刷品）。

产品经理对本公司销售人员进行产品培训，使销售人员充分了解本产品的特性。（也可在产品研发的末期进行）

上述工作完成之后，进入销售管理流程和客户服务流程。产品经理跟踪销售和客服过程，收集并分析客户意见，及时改进产品策划。

2.2 销售管理

销售管理流程如图2-2所示，主要活动有：营销策划，销售跟踪，合同管理。该流程的主要工作成果和责任人见表2-4。

销售经理销售人员销售人员销售跟踪产品或项目营销策划接触客户客户分析售前服务与跟踪签订合同合同管理实施计划与跟踪收款计划与跟踪付款计划与跟踪

图2-2 销售管理流程

主要活动 营销策划 销售跟踪 合同管理 营销方案 客户分析报告，销售跟踪表，销售合同 合同实施、收款、付款跟踪表 表2-4 销售管理流程的成果清单和责任人

主要工作成果 主要责任人 销售经理 销售人员 销售人员 2.2.1 营销策划

活动描述：

销售部门商议营销方案，销售经理分配任务给执行人（可以多人）。每个执行人填写执行情况，如表2-5：

营销方案 方案名称 起止日期 销售计划内容 执行人 A B 执行情况 状态 未开始，进行中，完成 表2-5 营销方案

日期 制定人 执行人 A, B 2.2.2 销售跟踪

活动描述：

销售人员负责销售本公司的产品；销售人员从客户那里承接项目。

第一步，接触潜在客户。销售人员通过各种途径接触潜在客户，了解客户信息和客户的需求。

第二步，客户分析。销售人员应当撰写《客户分析报告》，为公司提供充分的客户信息（同时也记录了自己的工作业绩），格式参见表2-6。同时，这也是由于售前服务会消耗公

司的资源（人力、金钱、时间），如果客户最终不签订采购合同，那么无效的售前服务将给公司增加成本。为了避免浪费公司的资源，节约成本，销售部门需商议是否为潜在客户提供进一步的售前服务，以及服务的程度。

客户分析报告 1. 客户介绍 2. 客户需求 客户分析 3. 采购可能性 4. 成本－效益分析 5. 风险分析 部门意见 说明是否为潜在客户提供进一步的售前服务，以及服务的程度。 表2-6 客户分析报告

第三步，售前服务与跟踪。销售人员根据潜在客户需求，提供产品演示、讲解、答疑等服务。如果承接客户的招标项目，则按客户规定的程序进行“投标、答辩、商务谈判”。如果需要，销售人员应主动向研发部门申请技术支持，研发部门也要积极的响应。

销售人员填写销售跟踪表，见表2-7：

销售跟踪表 客户 销售单内容 对客户的承诺 跟踪人 销售单状态 跟踪说明 表2-7 销售跟踪表

跟踪日期 第四步，签订合同。如果客户确定采购，可能有2种方式：

（1）商务谈判结束后，双方责任人将签订正式的合同。双方责任人仔细审查合同中的每个条款，确保合同没有错误和隐患，然后签字、盖章，使合同生效。

（2）客户承诺采购，但是目前不能签订合同。遇此情况，销售部门需请示公司领导，决定做还是不做。

特别注意：如果公司销售产品，则需制定《产品销售合同》模板。如果公司承接客户项目，则需制定《项目销售合同》模板。

2.2.3 合同管理

活动描述：

销售人员根据合同信息，制定实施计划、付款计划、收款计划，并跟踪这些计划的执行情况，见表2-8：

合同管理 客户名称 合同名称 合同签订日期 合同摘要 计划实施日期 计划收款日期 计划付款日期 计划说明 金额及用途说明 金额及用途说明 执行人 执行人 执行人 表2-8 合同管理表（实施、收款、付款）

执行状态/情况说明 执行状态/情况说明 执行状态/情况说明 客户方负责人 我方负责人 计划完成日期 2.3 客户服务

客户服务流程如图2-3所示，主要活动有：受理，处理，审核关闭，客户反馈。该流程的主要工作成果和责任人见表2-9。

客服人员指定处理人客服人员客户客户报告问题需求受理处理审核关闭客户反馈生成项目缺陷，项目任务，项目需求，版本合并等指定处理人图2-3 客户服务流程

主要活动 受理 处理 客服跟踪表 审核关闭 客户反馈 客服人员 客户 表2-9 客户服务流程的成果清单和责任人

主要工作成果 客服人员 指定处理人 主要责任人 2.3.1 受理

活动描述：

客户通过各种途径报告问题（包括问题、需求、建议等）。客服人员将这些问题记录在客服跟踪表中，通过与产品经理协商，并指定处理人。见2.3.4中表2-10（客服跟踪表）。

2.3.2 处理

活动描述：

如果处理人能够直接解决客户问题，则填写处理说明，把状态置为“解决待关闭”。如果问题比较复杂，可以生成“项目任务、项目缺陷、项目需求”最后是否要合并到主版本等。若“任务、缺陷、需求”都已经完成，再把客户问题的状态置为“解决待关闭”。见2.3.4中表2-10（客服跟踪表）。

2.3.3 审核关闭

活动描述：

当客户问题的状态为“解决待关闭”时，客服人员验证这个问题，如果的确已经解决，则把状态置为“关闭”，并填写关闭说明。见2.3.4中表2-10（客服跟踪表）。

2.3.4 客户反馈

活动描述：

客服人员告知客户其问题已经解决，同时更新客户方的程序（补丁或重新部署方式），并获取客户的反馈意见。

客服跟踪表 标题 客户/联系人 内容 受理人 受理说明 处理人 处理说明 关闭人 关闭说明 客户反馈 表2-10 客服跟踪表

关闭时间 处理时间 受理时间 编号 客服类型 2.4 客户信息管理

活动描述：

营销人员和客服人员均可填写客户公司信息和客户联系人信息。用于日后的分析与决策活动。见表2-11。

客户信息表 客户公司简称 客户公司全称 电话 传真 邮政编码 地址 客户公司简介 客户状态 客户类型 所属区域 所属行业 所属城市 试用或者使用 客户分析 联系人姓名 简要说明对该客户短期、长期分析；有哪些潜在的因素。 部门/职务 联系电话 表2-11 客户信息

Email /即时通信 3 项目管理过程

3.1 立项管理

立项管理的流程如图3-1所示，主要活动有：立项申请、质量管理部受理、立项评审和项目启动。该流程的主要工作成果和责任人见表3-1。

产品经理项目团队资料不合格（修改补充）自主研发产品立项申请合同项目立项申请资料不合格（修改补充）质量管理部受理合格立项评审通过项目启动未通过项目暂停销售人员图3-1 立项管理流程

主要活动 自主产品立项申请 主要工作成果 立项申请书，产品建议书（参见表2-2），调研分析报告（参见表2-3） 立项申请书，相关合同文件 立项评审通知 立项评审结论 项目总体计划 产品经理 主要责任人 合同项目立项申请 质量管理部受理 立项评审 项目启动 合同项目的销售人员 质量管理部 立项评审委员会 产品经理或项目经理 表3-1 立项管理流程的主要工作成果和责任人

3.1.1 立项申请

活动描述：

对于自主研发产品类项目，产品经理撰写《立项申请书》，并将相关附件（主要是产品

建议书，产品调研分析报告）一起提交给质量管理部。

对于合同项目，销售人员撰写《立项申请书》，并将相关附件（主要是合同文件）一起提交给质量管理部。（一般合同都签了，这一项也就是走走形势了）

《立项申请书》的主要内容见表3-2。

立项申请书 项目名称 申请人 1. 项目介绍 2. 本项目对公司的价值 3. 项目进度要求 4. 项目所需人力资源 5. 项目成本估算 6. 立项可行性分析 6.1 技术可行性分析 6.2 成本-效益分析 6.3 竞争分析 6.4 风险分析 6.5 SWOT分析：优势（Strength）、劣势（Weakness）、机会（Opportunity）、威胁（Threat） 项目类型 申请日期 合同项目 / 自主产品 表3-2 立项申请书的格式

3.1.2 质量管理部受理

活动描述：

质量管理部受理人审阅《立项申请书》和相关附件，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。之后，质量管理部受理人将文件转交给专管研发副总。

特别注意：中层队伍加强后，专管研发副总在这里的职责将会过渡给研发部门经理。 专管研发副总根据项目的特征（例如规模大小，技术方向等），选定“立项评审委员会”，确定评审时间。并至少提前一天将相关文件发给“立项评审委员会”成员。

质量管理部受理人发起立项评审通知，如表3-3所示。特别注意：如果项目涉及面很广，难以一次性在立项评审会议上决定，那么专管研发副总可以先召开“预评审”会议，之后再进行正式的立项评审。

立项评审通知 项目名称 评审文件 评审时间地点 评审人员 评审负责人 部门和职务 申请人 评委 其他参加人员 评审内容 表3-3 立项评审通知

3.1.3 立项评审

活动描述：

质量管理部通知相关人员在既定的时间参加立项评审会议，《立项评审报告》如表3-4所示。

评审负责人主持评审会议，把控会议进程。（评审负责人与评审记录员原则上由质量管理部人员担任）

立项申请人陈述《立项申请书》和相关文件的主要内容。评审委员提出疑问，立项申请人解答。双方应当对有争议的内容提出处理意见、达成共识。

每个评委发表（填写）自己的评审意见。

评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意立项”或者“不同意立项”。特别注意：评审期间应当商议“项目人力资源计划”，如表3-4中所示。避免立项之后人员不能到位的问题。

记录员（质量管理部指定人员）填写会议记录。

评审结束后，由公司领导（或专管研发副总）给出“终审结论和意见”。

XXX立项评审报告 评委姓名 评审负责人 评审意见 说明同意或者不同意的理由 评审结论、汇总意见和人力资源计划 评审结论： [ √ ] 同意立项 [ ] 不同意 汇总意见和人力资源计划： 记录员 领导 会议记录 终审结论和意见 评审结论： [ √ ] 同意立项 [ ] 不同意 意见： 表3-4 立项评审报告

3.1.4 项目启动

活动描述：

 第1步：确定项目团队

如果是自主研发产品类项目，则由专管研发副总配合产品经理确定该项目主要成员。 如果是合同项目，专管研发副总根据项目特征和立项评审报告，任命合适的项目经理，并配合项目经理确定该项目的主要成员。

特别注意：由于产品经理与项目经理在这一阶段职责重叠，因此约定这里统称“项目经理”。 项目经理对立项之后的项目进度和质量负责。项目成员向项目经理汇报工作。项目经理向部门经理汇报工作。

特别注意：中层队伍加强后，专管研发副总在这里的职责将会过渡给研发部门经理。  第2步：确定项目总体计划

项目经理和项目成员共同商议，制定初步的《项目总体计划》（也称为高层计划或里程碑计划），如表3-5所示。项目总体计划制定好之后，项目经理要准备召开项目启动会，目的是与公司相关领导、部门经理及项目组成员对项目总体计划进行评审，已形成对项目总体计划的承诺。项目总体计划要至少提前一天发送给公司相关领导、部门经理以及项目组成员。 特别注意：在项目正式启动之后，项目经理可以不断细化项目计划和修改项目计划，详见“3.3项目规划与监控”过程域。

项目总体计划 项目名称 项目经理 1.项目介绍 说明项目目标、关键因素及优先级 2.项目成员表 姓名 3.任务进度表 名称（阶段/任务/评审点） 4.项目成本估算 成本估算列表 5.部门经理审批 审批意见… 执行人 计划起止日期 角色 说明（主要职责和工作时间） 计划开始日期 计划结束日期 表3-5 项目总体计划

 第3步：召开项目启动会（总体计划的评审）

如果会上不能通过评审，项目经理要根据与会者的意见进行修改，修改后再由部门经理审批签字。

 第4步：统一标准化开发环境

包括文档工具，开发工具，配置管理工具，沟通工具，以及是否项目合同或产品规划中的某些特殊约定（如保密规范等）。

3.2 结项管理

结项管理的流程如图3-2所示，主要活动有：结项申请、质量管理部受理、结项评审、遗留问题跟踪和项目工作总结。该流程的主要工作成果和责任人见表3-6。

项目经理资料不合格（改进）指定处理人结项申请质量管理部受理合格结项评审通过遗留问题跟踪未通过处理相关问题所有项目组成员项目经理项目工作总结：个人工作总结→分析提炼→知识入库图3-2 结项管理流程

关键活动 结项申请 质量管理部受理 结项评估报告 结项评审 遗留问题跟踪 项目工作总结 问题跟踪表 个人工作总结，知识库 项目经理，质量管理部 所有项目成员 质量管理部，（结项评审委员会） 结项申请书 主要工作成果 项目经理 主要责任人 表3-6 结项管理流程的主要工作成果和责任人

3.2.1 结项申请

活动描述：

正常情况下，当项目开发工作结束时，项目经理撰写《结项申请书》，递交给质量管理部。《结项申请书》如表3-7所示。 对于异常结束的项目，部门经理应当明确指示项目经理，确定何时结束项目。部门经理应当向员工们解释为什么要异常终止项目。异常中止项目的结项流程与正常结项流程相同。

结项申请书 项目名称 1. 项目完成情况 主要功能 项目起止日期 人员和工作量 项目成本 应递交的成果 计划情况 项目经理 实际情况 说明、处理建议 阐述：项目质量，市场价值，成本效益，对机构的贡献 工作业绩描述 表3-7 结项申请书

评价人 2. 资产清单（资金和设备，软件等） 3. 专利和版权 4. 项目价值体现 5. 人员业绩 人员A 人员B 项目经理签字 3.2.2 质量管理部受理

活动描述：

质量管理部受理人审阅《结项申请书》和相关附件，如果发现文件内容不合流程要求或者质量不合格，则退还给申请人重新改进，直到文件合格为止。之后，质量管理部受理人将文件转交给专管研发副总。

特别注意：中层队伍加强后，专管研发副总在这里的职责将会过渡给研发部门经理。 专管研发副总根据项目的特征（例如规模大小，技术方向等），选定“结项评审委员会”，确定结项评审时间。并至少提前一天将相关文件发给“结项评审委员会”成员。

质量管理部受理人发起结项评审通知，结项评审通知单与立项评审通知单相同，如表3-3所示。

3.2.3 结项评审

活动描述：

质量管理部通知相关人员在既定的时间参加结项评审会议，《结项评审报告》如表3-8所示。

评审负责人主持评审会议，把控会议进程。（评审负责人与评审记录员原则上由质量管理部人员担任）

结项申请人陈述《结项申请书》的主要内容。评审委员提出疑问，结项申请人解答。双方应当对有争议的内容提出处理意见、达成共识。

每个评委发表（填写）自己的评审意见。

评审负责人汇总所有评审委员的评审意见，给出评审结论：“同意结项”或者“不同意结项”。

记录员（质量管理部指定人员）填写会议记录。

XXX结项评审报告 评委姓名 评审负责人 评审意见 评审结论和汇总意见 评审结论： [ √ ] 同意结项 [ ] 不同意 汇总意见： （1）项目任务完成情况。 （2）项目资产处理意见。 （3）发掘可以重复利用的知识财富，给出应用建议。 （4）项目的价值：市场价值、成本效益、技术积累等 记录员 会议记录 表3-8 结项评审报告

特别注意：项目结项后，该项目的人力资源和设备资源将被释放，应用于新的项目。原则上应该在一定的时间内保留一名开发人员用于维护项目，其他人员也有义务在必要的时刻维护自己参与的项目。

3.2.4 遗留问题跟踪

活动描述：

项目结项后，尚有一些遗留问题，项目经理填写“问题跟踪表”，质量管理部人员跟踪

该问题表，确保所有问题得到妥善处理。详见“3.6问题跟踪”过程域。 3.2.5 项目工作总结

活动描述：

 第1步：所有项目成员都要撰写《个人工作总结》，如表3-9所示。在公司范围内共享

经验教训。  第2步：项目经理召集所有项目成员，讨论每个人的工作总结，提炼出知识财富。  第3步：把知识财富按照一定的格式保存在指定位置。

项目名称 — 个人工作总结 撰写人 1. 本人在项目中的主要任务 工作总结 2. 遇到哪些问题，如何解决 3. 经验教训和建议 表3-9 个人工作总结

日期 3.3 项目计划与监控

项目计划是指对本项目的人力资源、任务进度、成本等做出合适的安排，制定出一些计划（包括宏观的和细节的），使大家按照计划行事，最终顺利地达到预定的目标。 项目监控是将项目实际情况与项目计划进行对比，如果发现某些因素（如人力资源、任务进度、成本等）的偏差比较大，那么及时分析原因，给出纠正措施。项目监控至少有两个好处：（1）避免原本合理的计划在实施过程时落空；（2）避免“执迷不悟”地按照原本不合理的计划行事。

项目计划与监控的重点是：“人员角色”、“任务进度”、“项目成本”、“项目评审”。

3.3.1 项目人员角色

活动描述：

项目经理向部门争取“完成本项目充分必要的人员”，项目人员到位后，项目经理确定每个人员在本项目的角色、工作内容和时间，格式见表3-10。

姓名 角色 工作描述（简要说明工作内容和时间） 表3-10 项目人员角色表

3.3.2 任务进度管理

活动描述：

特别注意：本项中需要更多的技巧性与能力性。

项目经理根据“本项目需求和人力资源”分解任务，和项目成员协商后，把任务交给最合适的人员去执行。简而言之，就是要“知人善用”。“知人”是指领导者应当非常了解他的团队成员，包括知识技能和性格爱好等等。“善用”是指让团队各成员扬长避短，使团队战斗力达到最强。

项目经理还要有意识地锻炼、提升成员们全局开发的能力，要保证至少有一人可以替换别人的工作。否则万一某人缺席（如离职、休假等），将导致工作被中断。

任务进度管理的流程如图3-3所示，主要活动和步骤如下：

纠正偏差调整制定任务计划填写执行信息

图3-3 任务进度管理的流程

 第1步：制定任务进度计划

项目经理和项目成员们共同协商任务，大家达成共识后制定任务进度计划，每个任务的主要数据如下：

 任务名称，任务描述，预计工作成果  开始日期，计划完成日期

 任务执行人（可以多个），计划工作量 可以使用MS project 作为工具。

 第2步：填写执行信息（填写与补充project）

每个任务的执行人（可以多个）填写执行信息，主要数据如下：  执行人，填写日期

 任务状态（进行中，已完成）  当前进度（百分比）  实际工作量，执行说明  第3步：纠正偏差

比对偏差最好以周为单位，如果任务的执行情况和计划之间的偏差比较大（例如工作量、完成日期的误差超过20％），项目经理应当和执行人交流，分析原因并给出解决措施：（1）若原计划太乐观了，那么适当修改原计划；（2）若执行人工作不得力，那么要求执行人加班追赶进度。

纠正偏差的原因与调整方案或解决方案要记录在项目的周报中。

3.3.3 项目成本管理

项目经理应当懂得“非财务人员”的项目成本管理。项目成本管理的流程如图3-4所示，

主要活动和步骤如下：

对比分析控制成本调整制定项目预算记录实际开支

图3-4 项目成本管理的流程图

 第1步：制定项目预算

项目经理制定项目预算表，这里的预算包括两大方面，一是基于功能点进行的项目估算而得到的人力成本，二是其他成本，预算类型参考内容如下：

薪金；奖金；员工福利(含旅游生活、保险、补贴等)；税；培训；租赁；差旅；电信（含手机、固话、电信网络）；办公用品；娱乐；设备；场地；折旧；

项目经理要记录下这些预算，包括预算类型，金额，用途说明。  第2步：记录实际开支

项目经理和项目成员每周记录实际开支，以便周例会时进行预算执行说明以及成本比对，记录的内容包括时间，预算类型，金额，说明。  第3步：对比分析、控制成本

项目经理随时对比分析“成本预算表”和“实际开支表”，尽量避免超支。项目经理应当在周报中向上级领导解释为什么超支以及采取什么措施。

3.3.4 项目评审（决策评审和技术评审）

项目评审分两类：决策评审和技术评审，两者的流程相同，但是目的不同。

决策评审的目的是利用集体（所有评审人员）的智慧，做出正确的决策，决定项目工作继续进行还是终止。

技术评审的目的是及时发现工作成果中问题，提出改进建议，使工作成果变得更好。  第1步：发起评审通知

发起人根据项目计划（或者项目经理的指示）发出评审通知，明确评审会议的内容、参加人员、时间、地点等信息，并将待评审的成果至少提前一天发送到评审人员的手中，《评审通知》的格式参见表3-3。一般地，默认的评审负责人是项目经理，如果项目经理不能做出决定，可以重新指定其他人担任评审负责人。  第2步：评审负责人召开评审会议  发起人讲解待评审的成果。

 评审人员现场提问和讨论，发起人解答疑问。  所有评审人员给出评审意见。

 评审负责人汇总评审意见，给出评审结论。

 记录员输入会议记录。（对于项目中的技术评审记录员一般为项目组内成员） 《评审报告》的格式如表3-4所示。

特别注意：如果采用增量式或迭代式开发的话，那么每个增量区模块或每个迭代周期都要进行重要工作成果的评审。

3.4 变更控制

项目开发过程中发生变更是司空见惯的事情。这里“变更”是指改变已经发布的工作成果（如文档、代码或者计划等），修改草稿不叫变更。变更控制的目的不是为了“预防变更”，而是为了“防止变更失去控制产生坏的后果”。变更控制的最大困难在于“如何拒绝客户或上级领导提出的不合理变更要求”。

变更控制的流程如图3-5所示，主要活动有：变更申请、评审和审批和执行变更。

申请人评审人和审批人执行人同意变更变更申请拒绝变更评审和审批执行变更

图3-5 变更控制流程

特别注意：一般情况下，先申请，审批通过后，再执行变更。在实际工作中，由于时间紧迫，对于低风险的变更，允许先执行变更，后补写变更申请，也就是说，即便是补的，这个过程也一定要完整。

《变更控制报告》的内容如表3-11所示。 活动描述：

 第1步：变更申请

项目开发过程中，所有人员（包括销售人员、项目成员和上级领导）提出的变更申请，必须说明“变更内容和原因”。由项目经理受理，指定多个评审人（至少3人）和一位“审批负责人”，一般情况下，项目经理担任审批负责人。 如果对项目的技术方案、进度、质量、成本产生重大影响的变更，项目经理做不了决定，那么可以指定上级领导担任审批负责人。  第2步：评审和审批

评审时主要从以下几个方面考虑，技术方案是否易于执行，时间与工作量估算，产生成本，对其他模块的影响。每个评审人都可以发表意见（但是不做决定）。由“审批负责人”做决定：“同意变更”或者“拒绝变更”，并给出指示。  第3步：执行变更

审批负责人同意变更后，由项目经理安排人员执行具体的变更工作，调整相应的任务进度计划，通知给受变更影响的相关人员。

变更申请 项目名称 变更原因和内容 变更申请人 评审人 审批负责人 2. 变更审批 评审人 评审意见 [ √ ] 同意变更 [ ] 拒绝变更 审批负责人 指示： 3. 执行变更 执行人 说明

表3-11 变更控制报告

说明变更原因和变更内容，估计此变更对项目造成的影响。 技术方案是否易于执行，时间与工作量估算，产生成本，对其他模块的影响。 可以多人 可以逐级审批 3.5 沟通管理

活动描述：

沟通管理包括项目内部沟通（如项目例会等）、跨部门沟通、与上级领导沟通（如定期座谈等）、与客户沟通等，要及时记录重要的沟通信息，避免遗忘，如表3-12所示。沟通中最重要的还是与客户进行沟通，这里主要说明的是与客户的沟通。

沟通记录（也可作为会议既要） 标题 沟通对象 沟通方式 沟通结果 详细信息 客户或公司内部人员 面谈 / 电话 / email / 网络交流 / 会议 达成共识 / 存在异议 / 搁置

表3-12 沟通记录 会议记录 沟通日期 填写人 会议名称 参加人员 缺席人员 会议记录 待解决问题 会议日期 记录人 表3-12附属会议记录

项目开发过程中存在各种各样的风险，需要项目经理（和销售人员）及时地和客户沟通。“客户沟通”主要目的是“消除摩擦、增进关系”、“处理不合理的变更”和“发掘新的商机”。

 消除摩擦、增进关系

项目经理（和销售人员）应经常和客户沟通，尽可能地消除客户对需求、进度、质量的不满。如果双方工作人员之间发生摩擦，项目经理（和销售人员）应及时消除摩擦。 为了不断改善开发方和客户方的人际关系，项目经理（和销售人员）在时间、经费允许的前提下，主动邀请客户方人员参加友谊活动，例如运动、聚餐、娱乐等等。

 处理不合理的变更

项目经理（和销售人员）要设法“拒绝客户提出的不合理变更”。

所谓“不合理的变更”是指：客户提出的变更不是由于开发方的过错引起的，此变更造成开发方承担了额外的成本，但是客户不愿意支付相应的费用。

客户会想当然地以为变更是他的权利，通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发团队陷入困境。推荐三种常用应对方法：

方法1：依据合同处理变更，合同中要详细写明变更处理的原则。 方法2：设法拖延到下个版本。 方法3：让客户欠下人情。  发掘新的商机

项目经理（和销售人员）和客户交往的过程中，不仅要关注已经签订合同的项目进展情况，还要不断发掘新的商机，例如：

发掘客户更深层次的需求，吸引客户继续采购（例如不断升级）。 将合同项目的成果转化成为通用的产品或构件，卖给其它客户。 请老客户推荐其新客户。

3.6 风险控制

风险是未来有可能发生的事件，它有可能出现并对项目造成潜在的损失。风险控制是保证软件项目在一个透明的和可预见的环境下有序进行的重要手段。

风险控制是项目管理的很核心的内容，合理的风险控制可以使项目进展过程更加平稳，可以更清晰的跟踪与监控项目，可以在问题发生之前做出相对周密的计划。

风险控制的流程如图3-6所示，关键活动是“识别风险”、“处理风险”、“关闭风险”。风险跟踪的表格见表3-13。

识别风险处理风险关闭风险

 第1步：识别风险

图3-6 风险控制的流程

有些风险是已知的和可预测的（这些可以参考《风险来源和分类列表》），任何项目成员发现风险，应当立即告知项目经理，并填写风险表格。新建风险的主要属性有：严重性、可能性、风险描述、报告者。

 风险严重性：指风险对项目造成的危害程度，例如可以划分为5个等级：5－很严重， 4－比较严重，3－中等，2－轻度，1－低微。

 风险可能性：指风险发生的几率，可以用百分比表示。（这个百分数完全来自于经验）  第2步：处理风险

项目经理指定人员（包括自己）处理该风险，随时记录风险状态。风险的状态有：新建、正在处理、解决待关闭、关闭、无法解决。

在项目的周例会中，项目经理要对本阶段内以及后面阶段的风险进行必要的通报。 如果不能在项目内部消除该风险的话，则请示上级领导，由上级领导给出解决措施。  第3步：关闭风险

当风险的状态处于解决待关闭时，项目经理核查后确信该风险已经被消除，那么关闭该风险。

风险控制跟踪表格 风险编号 严重性 可能性 风险描述 报告者 处理者 当前状态 解决措施 表3-13 风险控制跟踪表格

3.7 问题跟踪

与风险的区别是，问题是已经实际发生的。问题跟踪的范围包括：开发过程中的各种问题，建议，以及结项后遗留的问题。问题跟踪的一般步骤如图3-7所示，问题跟踪表见3-14所示。

报告者接受者接受者报告者报告问题处理问题解决待关闭审核关闭重新打开图3-7 问题跟踪流程

 第1步：报告者创建问题，指定接收者，此时状态为“新的”。  第2步：接受者处理问题，状态为“正在处理”。

 第3步：如果已经解决了问题，则把状态置为“解决待关闭”。

 第4步：报告者审核这个问题，如果确定该问题已经解决，则把状态设置为“关闭”。

如果发现问题没有解决，则可以“重新打开”问题，回到第2步。

问题跟踪表 问题编号 重要性 问题描述 报告者 接受者 问题处理方案 当前状态 审核关闭意见 表3-14 问题跟踪表

实际完成日期 报告时间 期望完成日期 问题类型 紧急程度 4 项目研发过程

4.1 需求开发与管理

需求开发与管理是指通过“调研、分析、定义、评审、跟踪”等活动，使开发方和委托

方（客户或本公司领导）对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。

项目经理根据本项目的人力资源来确定需求分析员（可以多人）。需求分析员负责开展调研、分析、定义、评审、跟踪等活动。

4.1.1 需求调研

活动描述：

需求分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得漫无边际。

需求分析员确定需求调研的方式，例如：  与用户交谈，向用户提问题。

 参观用户的工作流程，观察用户的操作。  向用户群体发调查问卷。

 与同行、专家交谈，听取他们的意见。  分析已经存在的同类软件产品，提取需求。  从行业标准、规则中提取需求。  从Internet上搜查相关资料。

技巧：需求分析员要清楚地掌握某个需求,应该能够清楚某项业务的4W和1H ,4W是“What、Who、When、Why”,1H是“How”。

What：业务内容是什么。 Who：业务过程会有哪些相关者。

When：业务过程什么时候发生,周期有多长。 Why：为什么会出现这样的问题。 How：为完成业务目标所采用的方法。

需求分析员在调研过程中随时填写“客户需求记录”，参考格式如表4-1所示。

项目名称 调研方式 时间、地点 需求标题 客户需求记录 需求分析员 被调研者 表4-1 客户需求记录

需求分析员整理所有客户需求记录，归纳与总结共性的需求，为撰写详细的《需求规格说明书》作准备。

4.1.2 需求分析

活动描述：

需求分析是对各种来源的需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。

问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。

对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。

现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。

世上不存在一个包罗万象的图用以完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。

4.1.3 需求定义

活动描述：

需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，撰写《需求规格说明书》，如表表4-2所示。特别注意：如果客户要求使用其他格式类型的需求规格说明书，可以不使用公司的模板。

软件需求规格说明书 1概述 1.1编写目的 1.2 读者对象 1.3 参考文献 1.4 术语与缩写解释 2系统说明 2.1 产品开发背景和目标 2.1.1 背景 2.1.2 目标 2.2 产品目标客户和最终用户 2.2.1 目标客户 2.2.2 最终用户 2.3 软件系统的约束 2.5 软件系统的角色 2.4 软件系统当前版本的范围 2.6 软件系统的功能列表 3功能需求描述 4其它需求说明 4.1 软件硬件环境 4.2 用户界面要求 4.3 非功能性需求 5签字确认 表4-2 软件需求规格说明书

4.1.4 需求评审

活动描述：

需求分析员（或项目经理）邀请项目成员和客户代表以及其他相关业务专家共同评审《需求规格说明书》，大家尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。

需求评审的流程见“项目评审流程”。一般地，需求分析员（或项目经理）为申请人，项目经理为评审负责人，项目成员、其他相关业务专家和客户代表可以担任评审员。所有评审人员认真检查需求文档，力求使需求文档达到正确、清楚、无二义性、一致、必要、完备、可实现、可验证。

4.1.5 需求跟踪

活动描述：

 第1步：需求分析员创建需求的目录结构，便于人们阅读。

 第2步：需求分析员输入每条需求的详细内容，可以多次细化修改，每次修改后应通知

相关项目成员。  第3步：需求分析员跟踪每条需求的进展状况，填写需求跟踪记录（当前状态和情况说

明），需求跟踪表的格式见表4-3。

需求跟踪表 需求目录/名称 优先级 状态 责任人 关联信息（文档，任务，缺陷等） 表4-3 需求跟踪表

4.2 系统设计

4.2.1 软件系统设计

活动描述：

软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计等，在需求与代码之间建立桥梁，指导工作人员开发能够满足用户需求的软件系统。

项目经理根据本项目的人力资源来确定软件设计师（可以多人），设计人员原则上应参与需求开发过程。

软件设计师撰写《软件系统设计说明书》，并构造可运行的软件系统框架，所有的模块都是在该系统框架上开发和运行。（目前暂试行简化版的设计文档，其功能应该算作简化版的详细设计）

《软件系统设计说明书》如表4-4所示。

软件系统设计说明书 1 概述 1.1 编写目的 1.2 读者对象 1.3 参考文献 1.4 术语与缩写解释 2 系统说明 2.1 说明 2.2 主要功能 2.3 设计约束 2.4 开发、测试与运行环境 3 软件系统结构设计 3.1 总体架构 3.2 逻辑结构 3.3 物理结构 3.3.1 软件部署结构（可选） 3.3.2 硬件部署结构 3.4 实施步骤 4 综合考虑 4.1 稳定性和可扩展性 4.2 性能分析 4.3 复用和移植 4.4 防错与出错处理 4.5 其它 5 数据库设计概述 5.1 数据库环境说明 5.2 数据库命名规则 5.3 安全性设计说明 5.4 数据库对象设计 5.4.1 逻辑结构 5.4.2 对象汇总 5.4.3 对象清单 6 功能模块设计概述 6.1 模块设计 6.1.1 模块名 6.2 模块汇总 7 用户界面设计概述 表4-4 软件系统设计说明书

4.2.2 设计评审

活动描述：

设计评审的目的是在同行专家的帮助下，尽早地发现本系统中存在的设计缺陷，及时消除设计缺陷。

当软件设计师撰写完成《软件系统设计说明书》，并构建可运行的系统框架之后，由软件设计师（或项目经理）邀请项目成员和本公司技术专家开展设计评审。

设计评审的流程见“项目评审流程”。

4.3 模块开发与集成

活动描述：

项目经理分配合适的模块开发任务给开发人员，开发人员对自己承担模块的质量和开发进度负责。

开发人员阅读《需求规格说明书》和《系统设计说明书》中自己承担的模块需求与设计。 所有开发人员按照既定的规范（如编程规范）来实现自己承担的模块，并在系统框架中和其它模块集成一起。

开发人员完成模块开发后，必须先进行自我测试（单元测试），必须走通模块的所有功能，消除自己已经发现的缺陷，然后交付给下个环节。

4.4 测试与缺陷跟踪

测试与缺陷跟踪的流程见下图4-1。

开发负责人测试负责人测试人员提交测试测试准备执行测试缺陷跟踪消除缺陷审核关闭图4-1 测试与缺陷跟踪的流程

4.4.1 协商并提交测试

活动描述：

开发负责人把待测试物品（如软件包）交付给测试组之前，必须完成以下工作（否则测试人员可以拒绝接受）：

 配置库中已打标记的待测试物品（如软件包）（建议包含年月日时分的信息）。  说明该版本要测试什么，注意事项等。

 开发人员必须测试自己开发的功能，通过后才可以交付给测试人员。

4.4.2 测试准备

活动描述：

 第1步：分配测试任务。

测试负责人和测试人员商议测试计划，安排合适的测试人员执行测试任务。  第2步：设计测试用例

测试用例是用于检验目标系统是否符合需求的一种“示例”，基本要素有：前提条件、输入数据或动作、期望的响应。《测试用例》就是描述各种测试用例的文档，相当于一本“测试操作手册”。关于测试用例的一些注意点如下：

 设计测试用例的目的是找出需求、设计、代码中的毛病，因此最好尽可能早地设计

测试用例。

 不同的测试用例其用途应当不一样，不要累赘。

 显而易见的测试用例不必完整地用文字描述，因为此时文字描述的价值不大、反而消耗时间。

测试人员根据模块的需求和设计说明书，撰写《测试用例》，如表4-6所示。最好由开发人员审阅《测试用例》，提出改进建议，双方达成共识。

测试用例 用例名称 对应模块 前提条件 输入 / 动作 示例：典型值… 示例：边界值… 示例：异常值… 审阅人 / 意见 表4-6 测试用例

期望的输出 项目名称 撰写人  第3步：搭建测试环境

测试人员搭建测试环境，注意测试环境要尽可能接近用户的实际运行环境。

4.4.3 执行测试

活动描述：

测试人员执行测试，填写测试报告，如表4-7所示。

测试报告 目录/用例名称 测试人员 测试记录/结论 表3-7 测试报告

测试时间 4.4.4 缺陷跟踪（可以使用mantis等工具执行）

活动描述：

缺陷跟踪如图4-2所示，缺陷跟踪表如表4-8所示（缺陷跟踪也可以由其他缺陷管理工具辅助完成）。  第1步：测试人员（或其他报告者）如果发现缺陷，则记录缺陷的详细信息，报告给开

发人员（接受者）。此时缺陷的状态是“新的”。  第2步：开发人员处理缺陷，此时缺陷的状态是“”正在处理”。特别注意：如果开发人员把缺陷状态设置为“不做处理或延后处理”，则项目经理召集相关人员评审那些“不做处理或延后处理”的缺陷，给出“处理”还是“不处理”决定。  第3步：如果开发人员消除了缺陷，则把缺陷的状态设置为“解决待关闭”。  第4步：测试人员重新测试该缺陷对应的功能，如果确定缺陷已经消除，则把状态设置

为“关闭”。如果发现该缺陷没有解决，则可以“重新打开”缺陷，回到第2步。

报告者接受者接受者报告者报告缺陷处理缺陷解决待关闭审核关闭重新打开图4-2 缺陷跟踪的流程

缺陷跟踪表 缺陷编号 严重性 缺陷类型 紧急程度 缺陷描述 报告者 接受者 缺陷解决方案 当前状态 审核关闭意见 表4-8 缺陷跟踪表

实际完全日期 报告时间 期望完成日期 4.4.5 消除缺陷

活动描述：

消除缺陷的第一步是找出缺陷的根源，如同医生治病，必须先找出病因才能“对症下药”。开发人员必须从结果出发，逆向思考。一旦找到了根源，开发人员通常知道如何消除缺陷。 查找缺陷的基本方法是“粗分细找”。对于隐藏得很深的Bug，应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。

开发人员在改错时，要注意以下事项：

 找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？如果没有问题，可以放心修改。如果有问题，可能要改动程序结构，而不止一行代码。  有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。好不容易逮住一个，应当乘胜追击，全部歼灭。

 在改错之后一定要马上重新测试，以免引入新的错误。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原先程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要重新测试。  上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。

4.5 交付与验收

如果是合同项目，那么由客户方负责人指定“试用人员和验收人员”。如果是自主研发产品，那么由产品经理（或公司领导）指定“试用人员和验收人员”。

交付与验收的流程见图4-3。

项目组成员项目组成员试用人员验收人员软件部署撰写文档用户培训试用验收图4-3 交付与验收的流程

4.5.1 撰写文档

活动描述：

当项目开发完成并通过测试之后，项目经理指定项目成员及时撰写《安装手册》、《使用手册》、《软件部署说明书》等必需文档。

4.5.2 软件部署

活动描述：

项目经理审阅《软件部署说明书》，如表4-9所示，如果发现问题，则及时指正。项目经理确认无误后，再指定项目成员为客户（或者本公司）部署软件系统：

 安装（或更新）软件系统，迁移数据；  初始化业务数据，确保软件能够正常运行；

特别注意：部署的软件系统必须是从配置库中提取已经测试通过的软件包。最好通过Internet进行远程部署，节省交通费用和时间。

软件部署说明书 软件名称 撰写人 1. 部署环境说明（硬件和软件系统） 2. 需要初始化的数据 3. 需要迁移（升级）的数据 4. 注意事项 项目经理审阅意见 部署过程中的 主要事项记录 表4-9 软件部署说明书

4.5.3 用户培训

活动描述：

项目经理指定项目成员（即讲师）负责给用户培训。讲师和用户商定培训计划（确定时间、地点、人员批次等）。 讲师按照计划给客户培训，并填写《客户培训记录》，如表3-10所示，作为培训服务的依据。

客户培训记录 讲师 课程名称 培训时间 地点 客户名称 学员 培训内容介绍 相关资料 客户签字确认 表4-10 客户培训记录

4.5.4 试用和验收

活动描述：

项目成员把软件部署到用户指定的机器上，用户试用软件。

在试用期间内，如果用户发现软件中存在严重的Bug（如死机、数据丢失、无法运行等），则开发方应当在24小时之内给出解决问题的措施。如果超过试用期，开发方仍然没有完全消除用户报告的Bug，那么试用期顺延，直到开发方完全消除用户报告的Bug为止。

如果用户在试用期间内没有报告严重Bug，那么试用期结束时，视为顺利通过试用。 如果试用期间，用户提出改进需求、以及报告了一些不严重的缺陷，开发方作为正常维护工作来处理，不延误用户验收产品。

用户在试用软件的过程中，将发现的Bug以及对软件的建议及时告知开发方。项目经理和开发人员及时处理用户反馈来的Bug和建议。

 对于用户发现的Bug，开发方应当立即纠正。

 对于一些难以马上实现的有益建议，由项目经理（或上级领导）决定如何处理。  开发方应当及时把处理结果回复给用户，否则用户可能因得不到开发方的重视而降低试用的积极性。

4.6 软件维护

软件维护可以划分为两大类：

 纠错性维护。由于前期的测试不可能揭露软件系统中所有潜伏的Bug，用户在使用软件时仍将会遇到Bug，诊断和改正这些Bug的过程称为纠错性维护。

 完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。如果需求变更很大，那么完善性维护将转变为软件新版本的开发（即新的项目）。 软件维护的一般流程见图4-4，主要活动有“接受维护请求”、“分析维护请求”和“执行软件维护”。

客服人员维护负责人指定维护人员接受维护请求分析维护请求执行软件维护

图4-4 软件维护的一般流程

4.6.1 接受维护请求

活动描述：

公司应当建立通畅的软件维护通信渠道，包括网站、电话、Email、MSN与QQ等及时通讯工具。

客户通过各种渠道向公司的客服人员提出软件维护请求。本公司客服人员记录这些维护请求，然后指定维护负责人：

 如果公司有专门的维护小组，那么客服人员把维护请求转发给维护小组负责人。  如果公司没有专门的维护小组，那么客服人员把维护请求转发给该软件的项目经理，如果项目已经结束，则转交给开发部门的领导。

4.6.2 分析维护请求

活动描述：

维护负责人接受到维护请求后，进行分析：

 对于“纠错性维护”，首先确认Bug的真实情况，然后合并到缺陷管理系统（Bug系统）并指定维护人员，协商安排修改Bug的任务进度。然后告知客户相应的维护计划。

 对于“完善性维护”，负责人要综合分析“客户需求建议”的价值，以及本公司的开发资源，然后决定“何人、何时”修改软件。

4.6.3 执行维护

活动描述：

维护人员根据商定的计划执行维护（修改Bug或改进软件）。并注意以下几点：  维护人员修改软件后，必须通过测试，确保没有引入新的错误之后，再去更新那些受影响的客户的软件，例如发行“软件补丁”。  维护人员必须严格遵循“软件配置管理”规范，避免软件代码版本发生混乱。  维护人员及时填写“维护记录”，说明自己做了什么事情和相应的工作量，不仅便于对维护工作进行统计分析，将来在业绩考核时候也用得上。如表4-11所示。

软件维护记录 所属项目/产品 所属客户 维护内容 维护工作量 维护日期 表4-11 维护记录

5 支持过程

5.1 软件配置管理

5.1.1 软件配置管理的概念

软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。

软件开发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被妥善地保管起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item），配置项主要有两大类：软件代码（包括源代码和二进制代码）和文档。

每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（即变更控制）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。

5.1.2 软件代码管理的一般规则

开发人员应当采用专业配置管理工具来管理所有的软件代码，常见配置管理工具有CVS、SVN、VSS、ClearCase等（这里建议采用含有主干分支功能的免费配置管理软件SVN）。软件代码管理的一般规则如下：

 项目经理（或上级领导）指定项目的配置管理员。

 配置管理员创建本项目对应的配置库，其目录结构与开发环境的目录结构保持一致。  配置管理员为每个项目成员分配配置库的操作权限。一般地，项目成员拥有“检出/检入”等权限，但是不能拥有“删除”权限。具体操作视所采用的配置管理工具而定。  项目成员根据自己的权限操作代码，建议时间间隔不能超过1天。

 如果要修改已经发布了的代码，必须遵循“申请－审批－执行”的变更管理流程。在开发进度压力比较大的情况下，为了提高工作效率，允许先行改动，但是至少要得

到项目经理的口头批准，并告知受影响的相关人员，日后补充“变更控制报告”。  配置管理员定期备份代码库。

 相关人员上传代码或文档时必须要写明注释，由修改Bug所做的提交动作必须注明Bug号以及相关Bug的描述。

5.2 文档管理

5.2.1 文档管理的特征

文档管理的特征：

 文档的主要用途是交流，交流越充分则文档的价值就越高。所以除了开发人员，不少相关人员（例如领导、营销客服人员等）都可能访问文档库。

 人们一般不会频繁地修改文档，文档的版本结构很简单（一般不会产生版本分支），对文档管理工具的功能要求不高。

 人们并不局限在办公室里使用文档，可能出差在外地、也可能在家里使用文档。  一般地，企业领导和营销客服人员不会使用CVS、SVN、VSS、ClearCase查看文档（对他们而言这些工具都太复杂了），使用Web方式对他们而言最方便。 尽管专业的配置管理工具既可以管理软件代码也可以管理文档，由于软件代码和文档有比较大的差异，业界倾向于将软件代码和文档分开管理。

 采用专业配置管理工具（如CVS、SVN、ClearCase等）来管理软件代码。  采用基于Web的文档管理工具来管理文档，文档管理工具通常和本公司的网站链接。这样人们可以在任何地方通过 Web 方式访问他需要的文档（前提条件是拥有访问权限），非常方便。  如果没有文档管理工具，配置管理员可以采用服务器目录管理方式，通过分配目录访问的权限，来管理文档。

5.2.2 项目文档管理的一般规则

项目文档管理的一般规则如下：

 项目经理创建项目文档库，至少确定文档库的第一级目录。

 项目经理为每个项目成员分配文档库的操作权限。一般地，项目成员拥有上传、下载、更新等权限，但是不能拥有“删除”权限。具体操作视所采用的文档管理工具而定。

 项目成员根据自己的权限操作文档（建议时间间隔不超过1周）。

 项目经理用文件袋或文件柜妥善保管纸质文档（例如客户提供的纸质文件）。  如果要修改已经发布了的重要文档（例如需求文档、设计文档、项目计划），必须遵循“申请－审批－执行”的变更管理流程。在开发进度压力比较大的情况下，为了提

高工作效率，为了提高工作效率，允许先行改动，但是至少要得到项目经理的口头批准，并告知受影响的相关人员，日后补充“变更控制报告”。  配置管理员定期备份文档库。

5.3 质量保证

质量保证（QA）是指检查项目的“工作过程和工作成果”是否符合既定的规范。 活动描述：

符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果极可能是不合格的。质量保证的要点是：找出明显不符合规范的工作过程和工作成果，及时督促相关人员纠正问题。

公司指定QA人员检查所有项目的过程质量和成果质量。QA人员根据项目特征，制定“质量保证检查表”，如表5-1所示。每个检查点的检查结论有3种：通过，未通过，免检。

QA人员要参加项目的例会，里程碑会议，以及可以随时检查。

QA人员在检查的时候，如果发现问题，应该立即记录下来。QA人员首先设法在项目内部解决已经发现的质量问题，与项目经理协商，给出解决措施。在项目内难以解决的问题，由上级领导给出解决措施。

过程域 / 检查点 计划检查日期 最新检查结果 通过，未通过，免检 表5-1 质量保证检查表格式

最新检查人 最新检查日期 5.4 日志和周报

项目成员应每天撰写工作日志，记录每天的主要工作内容，如表5-2所示。

工作日志 撰写人 所属项目 1. 当天主要工作记录 日志内容 2. 遇到的问题和对策 表5-2 工作日志的格式

日期 工作量 项目经理在每周例会后撰写《项目周报》，抄送给领导和项目成员，如表5-3所示。

项目周报 报告名称 报告人 所属项目 报告日期 1.任务进度情况 2.项目成本情况 3.项目质量情况 本周工作汇报 4.客户情况 5.存在的问题和对策 6.风险情况 表5-3 项目周报的格式

5.5 研发绩效评估

5.5.1 定义绩效体系

绩效体系的构成要素如表5-4所示：

 绩效评估类型。企业里不同的岗位可能要采用不同的绩效评估方法，先要确定有多少种绩效评估类型。

 每个绩效评估类型细分为若干个绩效指标。

 每个绩效指标限定了最高分值（体现了权重），并给出详细的评分标准。  将业绩分数划分若干等级，每个等级对应某个分数范围。 

绩效评估类型 绩效类型X 绩效指标名称 X1 X2 X3 绩效类型Y Y1 Y2 Y3 绩效等级 分数范围 A级（优） B级（良） 最高分值 C级（及格） 表5-4 绩效体系的格式

D级（差） E级（很差） 评分标准（一段文本） 5.5.2 填写绩效表格

绩效评估的一般流程：按照指定的绩效评估表，员工先自我评估，再由上级领导评估（可以多级评估），格式见表5-5。

姓名： 绩效类型： 绩效起止时间： 指标名称 总分 绩效等级 自我评价 领导甲评价 领导乙评价 最高分值 一段文本 一段文本 一段文本 标题： 所属项目： 填写时间： 自评分 领导甲评分 领导乙评分 表5-5 绩效评估表

5.6 知识库管理

活动描述：

 第1步：知识库分类，例如流程制度、缺陷知识、可复用模块、经验教训等。  第2步：任何员工都可以填写“知识入库申请单”，如表5-6所示。

 第3步：项目经理与配置管理员审批“入库申请单”（挑选有价值的知识，避免信息泛

滥）。  第4步：凡是应用了知识库的人员，都要填写应用记录。  第5步：对知识库的学习、应用情况和员工贡献，进行统计分析。

1. 申请 * 名称 类型 * 描述 * 申请人 * 申请入库时间 字符串 选择模块类型 Word格式文本 2. 审批 * 审批人 * 评审结论 * 审批意见 同意 / 不同意 一段文本 3. 应用记录 应用说明 表5-6 知识库表格

应用时间 应用负责人