近年来,信息系统项目的规模越来越大,复杂度越来越高。由于管理上的失误给人们的教训也越来越深刻。需求管理、配置管理、项目范围管理对于信息系统项目管理而言,都具有举足轻重的地位。澄清这些基本概念的含义,分析相互间的联系与区别以加深大家的理解,对规范和促进软件项目管理工作意义不小。

1 需求管理

1.1 需求管理概述
信息系统项目中的需求管理RM(Requirements Management)包括确保所有项目干系人对需求的一致理解;管理和控制需求的变更;从需求到最终产品的双向跟踪。词汇“需求管理”可以理解为对“需求”实施“管理”的活动或过程。

“需求”在IEEE软件工程标准词汇表(1997年)中定义为:

(1)用户解决问题或达到目标所需的条件或权能(Capability)。

(2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。

(3)一种反映(1)或(2)所描述的条件或权能的文档说明。

与传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性等特点,软件的需求不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题。

软件需求包括业务需求、用户需求和功能需求(含非功能需求)。业务需求(Business Requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。用户需求(UserRequirement)文档描述了用户使用产品必须要完成的任务,这在使用实例(Use Case)文档或方案脚本(scenario)说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。

CMM的第二级(可重复级)中将需求管理作为六个关键过程域的一个,因为它实际上是二级引入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下,软件开发才能以一种有计划和有序的方式进行。实际上,没有文档化的需求,在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则,都是从一个稳定的基础开始的,那就是文档化的需求基线。

1.2 需求管理、需求分析与需求工程

需求分析RA(Requirements Analysis)指深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节,定义软件的其他有效性需求。RA的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析的目的是对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型。区分需求管理和需求分析是很重要的。

需求工程RE(Requirements Engineering)是指应用已被证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征。RE是80年代中期逐步形成的软件工程子领域。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。RE包括所有与需求直接相关的活动,RE的活动可以分为需求开发和需求管理两大类。RE也可以进一步细分为系统需求工程(如果是针对由软硬件共同组成的整个系统)和软件需求工程(如果仅是专门针对纯软件部分)。

从完整意义上讲,RE包括需求获取、需求分析、需求定义、需求验证、需求管理等过程。从狭义上理解,需求管理关心的是需求管理过程的建立,在信息系统项目组中需要有一套规范的需求管理过程。从项目经理的角度上看,可能还有50%甚至更多的精力是用于关注结果的,所以对需求内容的管理与对需求形式的管理是密不可分的。

2 配置管理

2.1 配置管理中的基本概念

配置管理在信息系统项目管理中具有极其重要的地位和作用。现在,软件配置管理的环境及其工具越来越得到人们的重视。这里对配置管理中涉及的基本概念进行定义和解释。

(1)产品配置

是指一个产品在其生命周期的各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每个元素称为该产品配置的一个配置项CI(Configuraion Item),配置项的主要属性包括:名称、标识符、文件状态、版本、作者、日期等。配置项可以分为两类

①属于产品组成部分的工作成果,如需求文档、设计文档、源程序、测试用例等.

②属于项目管理和机构支撑过程域产生的文档,如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分,但又有保存的价值。

(2)配置项
配置项是配置管理的指定实体,可以分解成若干配置元素和配置单元。但在项目实践中有时也可以把“配置项”解释为“配置元素”或“配置单元”。

(3)基线和里程碑

IEEE对于基线(Baseline)的定义是:已经通过正式复审和批准的某规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变更控制过程进行改变。基线是由一组配置项组成的一个相对稳定的逻辑实体,基线中的配置项被“冻结”,不能被任何人随意变动。基线通常对应软件开发过程中的里程碑(Milestone)。里程碑是具有零历时的重要事件,是进度计划中特别重要的部分。基线的基本属性包括名称、标识符、版本、日期等。向客户交付的一个测试版本是基线的一个例子。

(4)配置库

配置库CL(Configuraion Library)也称配置项库(Configuraion Item Repository),是配置管理的有力工具。实践证明,利用配置库实现配置管理是非常有效的。配置库可以分为开发库(Development Library)、受控库(Controlled Library)和产品库(Product Library)三类。

(5)版本
版本(版本号)是表示一个CI具有一组定义的功能的一种标识,由配置管理员负责版本编号及控制工作。配置项的版本与配置项的状态密切相关,通过一定的规则为配置项指定版本号。配置项的状态分为三种:“草稿(Draft)”、“正式发布(Released)”和“正在修改(Changing)”。随着功能的增加、修改或删除,CI被赋予不同的版本号。一般在配置标识方案中给出版本标记方法。

2.2 对配置管理的不同理解

是否进行配置管理与软件的规模有关,软件的规模越大,配置管理就显得越重要。软件配置管理SCM(Software Configuration Management)指在团队开发中,标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模、项目复杂性以及项目风险水平。软件配置管理可以从以下几个角度理解和掌握它的含义:

(1)PMI项目管理知识体系指南中的定义配置管理包括提交变更建议的过程,跟踪变更建议的审查与批准制度,确定变更的批准级别,以及确认批准的变更方法。配置管理系统作为整个项目管理信息系统的一个子系统。需要特别说明的一点是,“配置管理系统”和“项目管理信息系统”两个概念是基于系统论研究方法提出的,注意与信息系统软件的区分。

(2)CMMI中的定义
CMM-SE/SW/IPPD/SS版本1.1中定义:
配置管理是运用配置标识、配置控制、配置状态、配置状态统计和配置审计,建立和维护工作产品的完整性。

(3)国际标准组织ISO的定义
①《ISO/IEC 12207(1995)信息技术——软件生存期过程》:配置管理过程是在整个软件生存期中实施管理和技术规程的过程,它标识、定义系统中软件项并制定基线;控制软件项的修改和发行;记录和报告软件项的状态和修改申请;保证软件项的完整性、协调性和正确性;以及控制软件项的储存、装载和交付。②《ISO 9000-3(1997)质量管理和质量保证标准——第三部分:ISO 9001:1994在计算机软件开发、供应、安装和维护中的使用指南》:软件配置管理是一个管理学科,它对配置项的开发和支持生存期给予技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险大小。

(4)GB/T 11457:1995《软件工程术语》国家标准配置管理是标识和确定系统中配置项的过程,在系统整个生存期内控制这些配置项的投放和变更,记录并报告配置的状态和变更要求,验证配置项的完整性和正确性。
综合以上各种观点,可以把软件配置管理定义为:采用技术手段和行政手段进行管理和监督的一套规范化方法;对配置项的功能特性和物理特性加以标识,并将其文档化;控制这些特性的变更;报告变更进行的情况和变更实施的状态以及验证与规定需求的一致性。软件配置管理是对项目生命周期中的各阶段产品和最终产品演化和变更的管理,是软件项目管理的重要组成部分。

3 项目范围管理
项目范围管理(Project Scope Management)是指确保项目能够包括成功完成项目所需的全部工作,但又只包括必须完成的工作的各个过程。它主要关心的是确定与控制哪些应该与哪些不应该包括在项目之内。PMI最新定义的项目范围管理包括以下五个主要过程:

(1)范围规划:制定项目范围管理计划,记载如何确定、核实与控制项目范围,以及如何制定与定义工作分解结构(WBS)。

(2)范围定义:制定详细的项目范围说明书,作为将来项目决策的根据。

(3)制定工作分解结构(WBS):将项目大的可交付成果与项目工作划分为较小的更易管理的组成部分。

(4)范围核实:正式验收已经完成的项目可交付成果。

(5)范围控制:控制项目范围的变更。

就信息系统项目而言,范围这个术语可指产品范围或项目范围。产品范围指产品或服务的典型特征与功能。项目范围指为提供具有规定特征与功能的产品或服务所需完成的工作。如果没有因为对产品或服务的需求而形成产品范围,就不需要启动一个项目,也就没有项目范围的说法了。从总体上看,项目范围是由产品需求或产品范围而引发的,项目范围是为产品范围服务的。要注意区分产品范围和项目范围这两个概念。项目范围是否完成以项目管理计划作为衡量标准,而产品范围是否完成则以产品需求作为衡量标准。两种范围的管理必须良好地结合,以确保项目工作所交付的是规定的产品。

4 综述
需求管理一方面作为对“需求”实施“管理”的活动或过程来理解,而广义上是指软件工程子领域——需求工程(需求获取、需求分析、需求定义、需求验证四大过程并列的过程)。配置管理是PMBOK、ISO9000和CMMI中的重要组成元素,它在软件产品开发的生命周期中,提供了结构化的、有序化的、产品化的管理方法,是项目管理的基础工作。项目范围管理是美国项目管理协会(PMI)项目管理知识理论体系PMBOK中九大知识领域之一,配置管理(系统)作为项目范围管理知识域范围控制过程的工具而存在,两者本来是通用项目管理理论体系中两个界定相对清晰的概念,在《软件工程术语》中没有定义术语“范围管理"或“项目范围管理”。但当项目管理理论引入到软件研发过程中后,项目范围管理与配置管理、需求管理三者间的关系变得有些复杂。

项目范围管理与需求管理属于包含与被包含的关系,分别对应于对项目范围和产品范围的管理。需求分析是逐步清晰产品范围的过程,而需求管理正是对这个产品范围清晰过程的管理过程。从项目范围和产品范围两者的关系可以看出项目范围管理与需求管理的关系。需求管理与配置管理都属于软件工程领域的术语和管理过程,前者对应于对产品需求的管理,后者对应于对项目各阶段交付成果——产品配置的管理,其中需求分析的交付成果——需求文档也作为产品配置的一个元素——配置项而存在。
项目范围管理与配置管理两者的关系比较模糊,其中涉及一些共同的概念:变更管理、变更控制系统、变更控制委员会CCB(Change Control Board)。虽然项目范围管理定义了五个管理过程,但没有涉及对各阶段交付成果的管理,而配置管理正是要完成对项目各阶段交付成果的管理,包括属于产品组成部分的工作成果和项目管理支撑过程域产生的文档等。变更控制委员会之所以也称为配置管理委员会CCB(Configuration Control Board),是因为项目管理过程中的变更主要是针对配置项的变更。
总之,深刻理解需求管理、配置管理和项目范围管理基本概念,理顺三者间的联系和区别,对于规范和改善日常项目管理工作都是很有帮助的。