拟    制：                  

审    核：                  

批    准：                  

版    号：       A/0        

受控状态：                  

2007年2月12日发布                   2007年3月1日实施

XXXX公司  发布

为了指导公司有关的项目管理工作，协调各方面关系，确保软件项目始终按功能目标进行。使软件项目管理过程规范，使过程过程中相关人员明确任务。

2  适用范围

该程序适用于本公司软件项目的开发。

3  职责

技术总监：规划项目总体框价，建议项目负责人的人选。

软件开发部总监：指定项目负责人或项目经理，成立项目组。

软件开发部经理：协助参与项目的部分组织工作。

项目负责人：项目技术指导、编程规范、底层构件、关键技术问题解决、组织系统设计说明（概要设计、详细设计内容）的编写。

项目经理：负责项目的计划、组织、控制、协调和指挥工作。组织项目的开发工作并编写项目开发进度表。

项目分析小组：参与项目系统分析说明的编写。主要是需求分析调研，需求分析报告等。

项目设计小组：参与项目系统设计说明的编写。主要是总体设计报告，概要设计报告，详细设计报告。

项目开发小组：参与项目系统程序代码编写。编写数据库设计报告，数据字典，程序代码设计报告。

产品/（测试)组：参与项目产品测试工作。编写包括测试计划、测试大纲和测试报告。

项目实施小组：参与项目的实施工作。编写包括实施计划和实施报告。

4　工作程序

4.1 需求管理

4.1.1 需求管理概述

客户需求管理过程指识别、分析、建立客户需求，监控客户需求的状态，控制客户需求的变更过程，进行客户需求的追溯等。

为项目在需求方面建立和维护与客户的共识，并将所建立的客户需求作为估算、策划、实施和管理项目的基础；控制管理客户需求及其变更，使项目开发计划、工作产品和活动与客户需求保持一致；进行客户需求的追溯，可改善产品质量、降低维护成本、实现重用。客户需求管理的活动贯穿项目的整个生命周期。

4.1.2 本阶段需要产生的过程产品

客户需求（客户提供的原始需求，格式不限）

会议讨论纪要

客户需求登记表

系统架构与业务需求规格说明书（偏向总体的技术架构与业务说明）

系统需求规格说明书（将技术架构细化、业务需求分析分解形成软件开发用语）

同行评审记录、报告

4.2 项目策划

为了对项目实施有效的管理，通常将整个项目划分成三个大的阶段，即：策划阶段、开发阶段和收尾阶段。在策划阶段，要进行项目策划，其结果将作为项目后续开发和管理活动的基础；在项目开发阶段，为了确保项目能按预定计划、预定成本完成开发任务，需要对其进行跟踪和监控；在项目收尾阶段，项目验收交付后应进行项目总结。

项目策划、项目跟踪与监控、项目总结和项目开发各阶段之间的关系如下图所示：

（图10-10）项目策划、项目跟踪与监控、项目总结和项目开发之间的关系

项目策划分为项目初期策划、项目开发策划。

4.2.1项目初期策划

（1）概述

项目策划从早期就应进行，通常在获得客户需求后进行的策划工作称为项目初期策划。

本元素在整个项目策划过程中的位置如下图所示：

（图10-11）项目初期策划在项目策划过程中的位置

（2）主要过程

项目启动

获得客户需求后，需要正式启动项目，一般可以以项目大纲的形式启动一个项目。项目大纲是用简洁、准确的语言对项目的要求进行描述的一份文件，由高层经理批准后就可以正式启动一个项目。

项目初期策划

项目的初期策划主要对系统需求分析阶段要开展的工作进行策划。根据项目的具体情况，初期策划的内容可能会有不同，一般应对以下工作进行必要的策划：

组建项目开发队伍；

进行系统需求分析；

建立客户需求基线等。

（3）过程产品

项目大纲；

系统需求分析计划；

客户需求基线建立计划

4.2.2项目开发策划

（1）概述

当系统架构与业务需求规格说明书、系统需求规格说明书已批准成为项目的客户需求基线后，项目经理对项目的整个开发活动进行策划。

（2）主要过程

●过程定义

选择合适的软件生命周期模型同时定义项目的生命周期；

根据选定的软件生命周期模型，按裁剪指南对公司的标准软件过程进行裁剪，形成适合项目实际情况的软件过程；

识别各项目阶段应该产生的工作产品，对所定义的项目过程进行描述。

●任务拆分

         技术活动拆分：常用的拆分方法是WBS，对整个开发任务逐步进行分解形成WBS拆分表；项目经理根据WBS拆分表采用任务描述表的格式进行任务的下达、任务完成情况跟踪；

         管理和支持活动拆分：参考上述方法对管理和支持活动进行定义，包括项目管理、质量保证、配置管理等。将拆分结果填写到工作任务拆分表中。

●项目估算

在任务拆分的基础上，进行项目的估算，估算的内容和次序是：

●软件规模估算

人力估算

外部成本估算（开发或侧使用的硬件设备及软件工具，需要集成到产品上的其它软件，人员培训，外包等）

关键计算机资源估算（计算机内存容量，CPU速度，磁盘容量，网络能力等）

●日程编制

根据以上工作成果，采用“Microsoft Project”工具制定开发进度日程表。

●制定风险管理计划

为了管理项目可能存在的风险，在进行项目策划时需进行风险分析并制订风险管理计划，该计划可作为项目开发计划的一部分进行描述。风险管理应贯穿于项目工程的始终。包括风险识别、风险分析、风险对策；采用风险对策登录表的形式对风险进行跟踪管理。

●编写项目开发计划

项目计划包括：项目开发计划、质量保证计划和配置管理计划。

建立项目开发的基准线：为了在项目开发过程中对项目的进度、成本进行监控，需要根据项目策划的结果（包括任务拆分、项目估算、日程编制等）确定项目开发的基准线；

编写项目开发计划：其中包括，项目概述、参考文件、项目组织机构、工程过程模型、工作任务拆分结构、风险管理计划、培训计划、规模、人力和成本估算、开发进度日程和定义里程碑。

●项目开发计划的评审和批准

评审活动通常由项目经理组织，并由以下人员参与对项目开发计划的评审及批准：

项目经理；

开发组的代表；

测试组的代表；

项目质量保证负责人；

项目配置管理负责人；

组织规定或项目约定的其他人员。

建立项目控制数据库：项目控制数据库通常由项目经理维护，用于：

存放项目数据；

对项目的进度、成本、质量进行控制；

评价项目的状况和业绩；

进行项目总结。

过程产品

项目开发计划；

配置管理计划；

质量保证计划。

4.3 项目跟踪与监控

项目跟踪与监控以项目开发计划为基础进行，对一个项目开发计划已被批准的项目如何对其进行跟踪与监控提供指导，说明具体的方法，为项目的实际进展提供足够的可见度。包括：项目过程数据的收集、项目进度和成本的跟踪、项目变更管理以及风险管理等。

项目跟踪与监控的过程结构如下

（图10-12）项目跟踪与监控的过程结构图

4.3.1产品批准

（1）概述

产品批准是项目控制的一种重要机制。“获得批准”表示任务或活动的完成以及下一阶段任务或活动的开始，也就是说，任务的完成是指当该任务所产生的产品已获批准时，才能认为该任务已完成。

（2）主要过程

将要提交批准的产品和《产品批准表》提交合适的产品批准人；

批准人在规定期限内批准所提交的产品，在《产品批准表》上签字；

如果产品未被批准，必须说明理由。存在的不一致意见获得解决后，应再一次提交批准。

（3）主要职责

项目经理或项目组长或质量保证负责人：负责利用产品批准表批准产品；

产品开发人员：产品经评审或测试后，提交产品批准表。

4.3.2项目数据收集

（1）概述

为掌握项目的状况，收集与项目执行有关的数据。项目数据还应包括QA和CM提供的有关数据。项目数据收集工作贯穿于整个项目开发过程。

（2）主要过程

项目数据收集：主要方法是个人周报，即项目组成员利用个人周报报告他们每周活动的结果。个人周报中记录本周每个任务的预估工时、各任务所花费的实际工时、迄今已花费的总工时，估计离任务完成还需要的工时及完成日期，是否符合进度要求等；

项目数据管理：各项目组长每周一前负责收集本组上一周的《个人周报》，汇总后提交给项目经理，由项目经理最后统计并更新项目控制数据库。

（3）主要职责

项目经理：负责收集项目的状态和进度数据；

项目组成员：每周提交《个人周报》。

4.3.3数据统计分析

（1）概述

本环节的主要工作是对收集的项目过程数据进行统计分析，贯穿于整个项目开发过程。

（2）主要过程

数据分析的基本任务是：分析现状，找出偏差，在此基础上对项目的剩余阶段进行估算。因此可以分四步进行项目的数据统计分析：

进度和成本的统计分析；

偏差分析；

任务完成点估算；

数据汇总：汇总上述分析结果，形成项目周报（初稿）；项目周报将作为项目例会的输入材料，并根据例会的结果，完善或修改问题、风险、变更及下周计划。

（3）主要职责

项目经理：对数据统计分析负有责任，并完成项目周报的编写。

4.3.4项目日常管理

（1）概述

项目日常管理所涉及的内容包括：工作量和成本管理、规模管理、关键计算机资源管理、关键路径控制及风险管理等。本元素是整个项目跟踪与监控过程的重要组成部分，它贯穿于整个项目开发过程。

（2）主要过程

项目日常管理的具体方法可以采取项目周例会的形式。周例会以项目周报的内容为基础，对项目的执行情况进行讨论、协调和控制，并根据具体情况作出一些决定。

（3）主要职责

项目经理：对项目的日常管理、监控负有责任；

项目组成员：对项目的日常管理、监控负有参与和配合的责任。

4.3.5项目变更管理

（1）概述

在项目的跟踪和监控过程中，对所发生的变更进行管理。根据变更所涉及的方面，可以分为两大类：涉及项目的变更和对产品配置的变更。本环节对项目的变更管理提出要求，产品配置变更的管理和控制过程可详见配置管理部分。任何对项目的变更都可能引起项目开发计划中各部分的变更，必须一并考虑。项目变更管理是整个项目跟踪与监控过程的重要组成部分，贯穿于整个项目开发过程。

项目变更管理的控制流程如下图。

（图10-13）项目变更管理的控制流程

（2）主要过程

每一个变更请求都应在《项目变更申请表》中进行说明，并包括对项目影响程度的评估；

变更请求由所有受到变更影响的组进行评审、协商和批准。项目计划的变更批准的权限和项目开发计划批准的权限相同；

项目经理就经批准的变更请求，使用管理预留、修改项目计划、执行已批准的变更；

对变更实施结果进行验证，验证通常可由质量保证人员进行。

（3）主要职责

变更申请人：负责以书面形式提出变更申请；

项目经理：接受变更申请，并根据变更所涉及的内容组织评审；

相关组：即变更可能受影响的组，参与对变更的评审；

高层经理：参与对涉及软件项目承诺的变更，以及对组织外部承诺的变更的评审。

4.4 配置管理

配置管理（CM）的目的是确保产品在开发过程中的完整性和可追溯性，配置管理活动包括标识配置项、建立基线、版本控制和变更控制，使开发人员、测试人员、项目管理者、质量保证人员以及客户能方便地通过配置管理获得有用的信息。

配置管理过程的体系结构如下图所示，它贯穿于项目整个生命周期。

（图10-14）配置管理过程的体系结构

4.4.1配置管理策划

（1）概述

配置管理策划和项目开发策划同步进行，内容包括明确项目的配置管理职责和配置基线建立的时机，确认需要纳入配置管理的要素即配置项，制定配置项的标识规范和配置管理规程，选择配置管理工具，建立配置管理系统、安排必要的配置管理活动等。

（2）主要过程

建立项目的配置管理组织，确定配置管理策划的主要内容：

识别配置项：包括客户需求、测试计划和测试用例、软件需求、设计文档、源代码、制订配置项命名规则；

选择配置管理工具；

确定配置基线；

下图为一组典型的软件项目配置基线。各基线随着项目的进展逐步建立，所有基线将被集中保存到基线库。

（图10-15）典型的软件配置基线

         建立配置控制区；

         确定报告基线建立与变更的方式；

         确定备份与归档规则；

         确定重要的配置管理活动。

         编写配置管理计划

         配置管理计划的评审与批准：

         项目经理、质量保证负责人、相关组的负责人进行评审和批准；

         在配置管理活动执行过程中配置管理计划需要变更，则按项目变更控制程序的要求进行。

         建立配置管理系统

（3）主要职责

项目经理：负责配置管理的策划活动，建立项目的配置管理组织；

配置管理负责人：制订配置管理计划，创建和管理项目的配置管理系统。

4.4.2基线管理

（1）概述

项目按照配置管理计划规定的职责和任务，在项目的进展过程中逐步建立各配置基线，包括：对配置项的标识、建立配置项间的追溯关系、基线建立与发布、配置状态统计等。

（2）主要过程

标识配置项

建立配置项间的追溯关系

基线建立与发布

当项目的每一条基线按批准权限被批准建立时，配置管理负责人对基线所包含的配置项进行配置评审；

通过评审之后，将该基线的所有配置项从开发区转移到基线库；

审核《追溯表》新追加的内容；

配置管理负责人负责发布基线，维护《产品发布清单》。

配置状态统计

当一个新的配置项被加到基线中或者当从基线库发布基线时，配置管理负责人进行配置状态统计；将配置状态统计的结果登记到《配置状态统计报告》。

（3）主要职责

配置控制委员会（CCB）：批准客户需求基线和运行基线的建立和变更；

项目经理：负责审核批准开发基线，并履行CCB的职责；

配置管理负责人：审查、指导开发人员进行配置项标识，建立和维护配置项间的追溯关系，维护配置库和配置管理库；建立基线；进行配置状态统计；

开发人员：配合配置管理人员进行配置项的标识、配置状态统计，维护配置《追溯表》；

质量保证负责人：审查项目基线建立活动，以验证它与配置管理计划和配置管理程序文件的符合性。

4.4.3变更管理

（1）概述

在项目的进展过程中如果发生正式基线、非正式基线及特定配置项的变更要求，则需进行变更控制，其中包括变更的申请与批准、变更的实施、配置项间追溯关系的维护、配置状态统计等活动。

变更控制流程如下图所示：

（图10-16）变更控制流程图

（2）主要过程

基线变更控制：按照上图中的流程进行；

版本管理；

配置状态统计：配置管理负责人定期或以事件驱动方式填写《配置状态统计报告》，对所有处在变更实施状态中的变更申请和变更完成情况予以公布；

配置管理计划的变更：详见项目开发计划的变更；

维护阶段的软件配置管理活动：产品开发完成并已进入运行基线后，所有与配置项标识、变更控制、状态统计、配置审计和基线发布有关的要求都应继续执行。CCB对在运行基线建立后为确保其完整性的变更批准负责。

（3）主要职责

配置控制委员会（CCB）：批准客户需求基线和运行基线的变更；

项目经理：负责审核批准开发基线的变更，并履行SCCB的职责；

配置管理负责人：执行配置管理计划规定的各项配置管理活动，对配置库、配置管理库的变更负责；

开发人员：按照配置管理规程，配合配置管理人员实施配置管理工作；

质量保证负责人：审查项目配置变更管理活动，以验证它与配置管理计划和配置管理程序文件的符合性。

4.4.4配置审计

（1）概述

配置审计的目的是要证实软件产品在其整个生命周期中，各配置项在技术上和管理上的完整性，并确保在基线发布之前，所有质量和配置活动都已经完成，其中基线发布包括基线建立时的发布和变更实施后的发布。

（2）主要过程

配置管理负责人对审计活动进行必要的准备和协调，包括配置记录的整理和收集、必要的检查。审计的结果形成《配置审计报告》，由配置审计人员直接提交给项目经理。

（3）主要职责

配置管理负责人：协助配置审计人员进行配置审计；

配置审计人员（可由质量保证负责人担任）：审计项目配置管理活动。

5 相关文件

02-02软件开发管理规程

02-03软件研发管理规程

02-05软件开发策划控制规程

02-06软件需求控制规程

02-07软件配置控制规程

02-08软件设计控制规程

02-09软件变更控制规程

02-10软件测试控制规程

6 记录

可行性分析说明

需求分析说明

系统总体设计

系统详细设计

系统开发计划

软件开发阶段进度表

系统测试报告

用户手册

系统验收测试报告

软件维护实施计划

相关记录的内容可以根据具体软件产品进行合并。

以上记录由软件开发部保存，保存期限为3年，必要时可按需要延长。下载本文