软件项目基线

基线（base line）是软件工程活动从一个环节转入另外一个环节时对阶段产品或组件的标识。因为软件规模的膨胀和分工的细化，软件开发过程变得越来越复杂，每个阶段可能由不同类型的角色和人员来完成，因此有必要清晰标识上一阶段完成的成果和下阶段开始工作的基础。这种标识活动就是建立基线。

根据同行评审或阶段评审的结果建立基线是质量保证人员（Quality Assurance，QA）的职责，项目参与人员（设计、开发、测试、配置管理、PSO）有责任配合QA建立各项基线。

通常一个项目（工程）需要建立如下几种基线：

  需求基线

  设计基线

  测试基线

  发布基线

需求基线在需求分析规格说明书通过同行评审后建立，此时客户需求和产品需求应该是全面、清晰、准确并且文档化的。必要的文档包括《需求分析规格.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个字母）及两位阿伯数字标识基线的不同版本（按序递增），缺省情况下为第一版本，可省去不标；在下一阶段之前,当基线发生变更,重新建立基线时将增加版本信息。