▲备注：以上内容由项目督导小组填写，并由公司运营经理签字有效。

第二篇：项目流程

A.1 总则

最大限度提高Q&P（质量与生产率），提高Q&P的课预见性，市每一个软件开发机构的最大目标。而Q&P以来于三个因素；过程、人和技术，因此要时间Q&P的提高，出了加强技术能力，引进、培育更多优质技术人才之外，规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准，并在软件开发实践中不断地完善、修订，提高Q&P和Q&P的可预见性。

本规范采用CMMI/PSP/TSP的指导，吸收了RUP、MSF、XP等过程规范指南的思想、方法及实践，充分结合本公司的实际情况，引如先进适用的技术、方法和工具，为公司软件开发工程提供一部详细、可操作的过程指南，在本规范中，主要包括管理过程和开发过程俩个部分，管理过程包括项目管理过程、需求变更管理过程以及配置管理过程。

A.2 项目管理过程规范

项目管理过程是对软件项目过程进行计划、监控/管理、总结的辅助过程，包括需求、配置、成本、进度、质量和风险等的管理。项目管理过程主要包括3个阶段：项目立项与计划、项目实施和项目结束。

A.2.1 项目立项与计划

1.参与人员：公司指定的项目负责人（如项目经理）、立项申请人(如产品经理)、[相关最终客户]（中括号表示可选项，下同）以及相关部门的负责人（如开发部经理、测试部经理等）。

2.入口准则：接到公司批准的市场部门的《软件开发立项申请表》。

3.出口准则：立项申请人签字确认的正式《软件项目计划》，并通过《任务书》下达了开发任务。

4.输入：进审批的《软甲开发立项申请表》与需求相关的业务资料。

5输出：《软件项目计划》、《软件需求规格说明书》和《任务书》。

6.活动：

（1）接到《软件开发立项申请表》后，项目管理部制定项目经理，并告知立项申请人。

（2）项目经理阅读《软件开发立项申请表》后，通过与立项申请人的沟通、范围与基本需求；并形成最初的《软件需求规格说明书》。

（3）项目经理会同有关部门经理、其他先关人员，制定最初的《软件项目计划》并组织评审。

（4）向立项申请人提交最初的《软件项目计划》、

（5）最初额的《软件项目计划》通过立项申请人的确认后，项目经理开始安排需求分析。

（6）需求分析完成后，形成正式的《软件需求说明书》。提交立项申请人确认；需求确认未通过，立项申请人与项目经理进行协商解决。无法达成共识的，向上级提交问题。

（7）根据立项申请人确认后的《软件需求说明书》，项目经理组织软件构架设计，并对工作任务进行分解，并根据使实际需要向有关不猛申请资源，组建项目组。

（8）项目经理根据工作任务分解，下发《项目任务书》，并协同项目组成员进行任务估算。

（9）任务估算完成后，项目组成员向项目经理提交《个人进度安排》（一甘特图的形式表示），项目经理根据每个成员的《个人进度安排》修订《软件项目计划》，并提交立项申请人确认。

（10）立项申请人确认后，项目经理根据软件项目计划基线，补充《项目任务书》，下发到每个项目组成员，开始工作。

A.2.2项目实施

1.参与人员：项目经理，项目组成员。

2.人口准则：项目计划基线已建成，并通过立项申请人确定，带有工作进度要求的《工作任务卡》已下发到每个项目组成员。

3.出口准则：立项申请人在《验收报告》上签字确认。

4.输入：《软件需求规格说明书》、《软件项目计划》和《任务书》。

5.输出：经验收测试的可交付的程序、源代码及相关文档。

6.活动：

（1）在开发勤俭，项目成员每周提交周报告和《个人缺陷状态报告》，每天向羡慕经理口头汇报工作任务进度。

（2）在开发勤俭，项目经理负责填写《项目进度周报》和《项目总体缺陷状态报告》，抄送公司管理层和有关部门。

（3）项目经理必须根据实际的进度情况，即使调整项目计划，若发现进度厌恶，需采取措施。

A2.3 项目结束

1. 参与人员：项目经理，项目组成员、立项申请人、[相关客户、公司副总和部门经

理]。

2. 入口准则：立项申请人在《验收报告》上确认。

3. 出口准则：形成《项目总结》，完成项目绩效考核，项目数据存入“过程数据库“。

4. 输入：《测试报告》、《缺陷和质量分析报告》和《项目开发计划》。

5. 输出：《醒目总结》、《项目绩效考核表》和过程数据库的记录。

6. 活动：

（1） 项目经理主持召开项目总结会，交流项目实施过程中得新的体会，对项目实施

中得成功之处、不足之处进行总结，并有项目经理形成《项目总结报告》。

（2） 项目管理部会同各个部门经理对该项目进行绩效考核，并填写相应的《项目绩

效考核表》。

（3） 项目经理组织所有成员对项目过程中得文档、源程序等资料进行整理、归档；

并整理相应的过程数据，提交SEPG，存入过程数据库。

A.4 需求变更管理过程规范

在项目生命周期中需求变更很容易发生，而且肯定会发生。不要希望不会发生变更，而是通过流程来有效地管理的所带来的质量风险、成本等。

A.4.1 过程总述

需求变更管理过程定义了一系列活动，需要立项申请人、[客户]意识到变更对项目影响的后果，可以有好的奖变更反应到协商好的条款中。需求变更管理过程，从某程序上说，试图保证在需求变更影响下项目依然可以成功。

需求变更管理有俩个方面，一方面与立项申请人、[客户]就怎样处理变更（包括方法、工作量、对时间和成本影响等）达成一致，另一方面世界进行变更的过程，如在做项目计划时，留有10%的余地来应付变更。

A.4.2 过程规范

1.参与人员：项目经理，立项申请人、[库户]、开发团队。

2.入口准则：收到立项申请人提交的《需求变更请求单》。

3.出口准则：变更已列入《软件需求说明书》，并体现在《软件项目计划》中，并得到用户的确认签字。

4.输入：《需求变更请求单》。

5.输出：变更的《软件需求说明书》和《软件项目计划变更表》。

6.活动：

（1）记录需求变更请求，包括变更请求数、简要描述、带来的影响、请求的状态等。

（2）分析变更请求对工作的影响、估计变更请求所带来的额外工作量和成本。

（3）修改项目计划，重新估计交付时间。

（4）将修改过的项目计划提交立项申请人和客户，并获得确认。

A.5 配置管理过程规范

软件项目在其执行过程会产生大量的工作，包括各种文档、程序、数据和手册。所有这些工作都是易于改变的。为避免项目在变更是失控，正确控制和管理变更是很必要地，这就依赖于软件配置管理（SCM）。SCM就是有识别软件产品配置项、建立基线并控制其修改的一系统活动构成，包括版本控制（分支和合并）、需求变更管理等。

A.5.1 配置管理的目标

配置管理过程，需要达到以下目标：

（1） 能够随时给出程序的最新版本‘

（2） 能够处理并发的文档、程序的更新/修改请求。

（3） 能够根据需要撤销程序的修改。

（4） 能够有效防止未授权的程序员对文档、程序进行变更或删除。

（5） 能够有效地显示变更的情况。

A.5.2 配置管理过程规范

配置管理过程包括俩个主要阶段：配置管理计划、实施配置管理。

1. 配置管理计划

（1） 参与人员：项目经理，配置管理组。

（2） 入口准则：《软件需求规则说明书》已经确认。

（3） 出口准则：完成项目配置管理计划。

（4） 输入：《软件需求规则说明书》。

（5） 输出：《配置管理计划》。

（6） 活动：

?

?

?

?

?

? 建立SCM组，并确定SCM组成员的责任和权力。 识别配置项，配置项的典型例子包括需求规格、设计文档、源代码、测试计划、测试脚本、用户接口规范和各类文档等。 配置项命名和编号的计划，包括定义版本号、正确用SCM工具。 确定将配置项转移到基线的原则。 定义SCM所需的目录结构、访问控制权限。 定义变更控制过程和跟踪配置项状态的具体措施和方法。

? 定义备份制度、发布制度。

2. 实施配置管理

（1） 参与人员：项目经理，SCM组和项目组其他成员。

（2） 入口准则：项目开始《SCM计划》已批准。

（3） 出口准则：项目结束。

（4） 输入：《软件配置管理计划》

（5） 活动：

?

?

? 接受变更请求。 Check out需要变更、修改的配置项，并进行球该。 Check in变更、修改的配置项。