什么是项目管理中的基线(baseline),其有何作用?

基线(baseline)是项目管理中的一个重要概念,当一个(或一组)配置项(比如:进度计划、范围、预算等)在项目生命周期的不同时间点上通过正式评审并进入受控状态后,就形成了基线。

你可以把基线简单理解为:项目最初设定并保存的各类计划、参数,它相当于一份项目快照(snapshot)。项目的进展应当与基线进行衡量,以评估绩效。基线一旦建立,不可随意更改,其变化需要接受严格的变更控制(change control)。

项目经理对基线进行规范管理,能有效保证项目的合理规划、评估,促进项目严格按照计划完成,防止失控。常用的项目管理软件中(如微软的PPMProject Professional 2016),都有相应的基线设置及控制功能。在微软的Project软件中,允许你最多保存11个基线(见参考链接(2))。

通常一个项目(工程)需要建立如下几种基线:

需求基线

设计基线

测试基线

发布基线

需求基线在需求分析规格说明书通过同行评审后建立,此时客户需求和产品需求应该是全面、清晰、准确并且文档化的。必要的文档包括《需求分析规格.doc》和《功能清单.xls》。通常这些文档由需求调研人员或设计人员提供。

设计基线在详细设计完成并通过同行评审后建立。此时产品需求的实现方式应该是全面、清晰、准确和文档化的。必要的文档包括《总体设计规格.doc》、《详细设计规格.doc》、《数据库设计.pdm》。通常这些文档由设计人员提供,《详细设计规格.doc》可能由开发小组中的核心开发人员提供,面向对象的设计必需提供oom文档。

设计基线建立后,开发人员可以根据设计基线确定的成果进行代码开发。在开发过程中必然会遇到需求变更和设计变更的活动,这些变更需要被完整记录并且变更的内容要及时反应到需求文档和设计文档中。保证需求和设计文档内容完整的有效办法是指定文档的唯一责任人,比如数据库设计的变更只能由一个人控制。

测试基线是开发人员完成开发后,将软件系统交给测试人员测试时对之前所有开发成果的标识。建立测试基线需要设计、开发人员提供《功能清单》、《需求分析规格.doc》、《总体设计规格.doc》、《详细设计规格.doc》、《数据库设计.pdm》、《数据库初始化脚本》、《系统安装配置说明》和源码(含ant编译脚本)。在建立测试基线时,根据测试人员的要求,设计、开发人员还应该提供相应的讲解和培训。

发布基线是在测试人员完成测试工作后建立。建立测试基线时,测试中发现的所有bug应该已经fixed或者未fixed但不影响系统使用。未fixed的bug作为遗留问题被记录下来。软件发布时,测试人员应该提供的文档包括《readme.txt》(描述软件产品信息)、《用户手册.doc》、《安装配置手册.doc》、《软件产品质量报告.doc》和产品安装包。

产品发布后,所有产品的安装根据用户需求从已经发布的版本中选择或者进行增量开发,不能直接从cvs上check源码编译后交付用户。

所有文档、源码、程序包都放在cvs server上,参与软件产品设计、开发、测试、配置管理人员提交的文档以cvs上最新版本为准;每次建立基线时需要打tag并通知软件系统所有参与人员。

基线的命名规则

BL-阶段代号- [-基线级别][-版本号]
例:BL-C -VT-V02
部分定义:
?        BL两位拼音字母,表示基线Baseline;
?       -C短线后跟一位大写字母(阶段的第一位字母)启动阶段用I(Inception)表示,细化阶段用E(Elaboration)表示,构造阶段用C(Construction)表示,移交阶段用T(Transition)表示;
?        -VT 短线后跟两位英文字母,表示某开发过程的完成。开发过程标识同软件过程元素,如VT表示确认测试完成(参见附表:软件过程元素名称列表)。随着产品达到不 同的成熟度,可晋升基线的级别,即在基线标识中加注该部分;通常有以下级别:需求完成(RA)、设计完成(DS)、编码完成(CO)、单元测试通过 (UT)、集成通过(IT)、确认测试通过(VT)、系统测试通过(ST)、验收测试通过(AT)、发布(RL);
?        -V02 短线后跟大写V(version的第1个字母)及两位阿伯数字标识基线的不同版本(按序递增),缺省情况下为第一版本,可省去不标;在下一阶段之前,当基线发生变更,重新建立基线时将增加版本信息。

参考链接:

(1) The Project Baseline – A Project Management Definition

(2) Set and save a baseline

(3) The Power of the Baseline in Microsoft Project