TA的每日心情 | 开心 2014-5-8 07:48 |
---|
签到天数: 33 天 [LV.5]常住居民I
|
本帖最后由 theloxer 于 2010-11-1 13:33 编辑
需求管理、配置管理与项目范围管理
吴吉义
摘 要:需求管理、配置管理和项目范围管理在软件项目管理中具有重要的地位和作用。本文基
于透彻分析需求管理、配置管理和项目范围管理知识理论中的基本概念的主要目的,帮助大家形
成对需求管理、配置管理和项目范围管理的深刻理解,有利于规范和促进日常项目管理工作。
关键字:需求管理,配置管理,项目范围管理
中图法分类号: TP311 文献标识码: A
近年来,信息系统项目的规模越来越大,复杂度越来越高。由于管理上的失误给我们的教训
也越来越深刻。需求管理、配置管理、项目范围管理对于信息系统项目管理而言,都具有举足轻
重的地位。澄清这些基本概念的含义,分析相互间的联系与区别以加深大家的理解,对规范和促
进软件项目管理工作意义不小。
1 需求管理
1.1 需求管理概述
信息系统项目中的需求管理(Requirements Management, RM)包括确保所有项目干系人对需求
的一致理解;管理和控制需求的变更;从需求到最终产品的双向跟踪。词汇“需求管理”可以理
解为对“需求”实施“管理”的活动或过程。
“需求”在 IEEE 软件工程标准词汇表(1997 年)中定义为:
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
与传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性等特点,他
不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件
项目最难把握的问题。
软件需求包括业务需求、用户需求和功能需求(含非功能需求)。业务需求(Business
Requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档
中予以说明。用户需求(User Requirement) 文档描述了用户使用产品必须要完成的任务,这在使用
实例(Use Case)文档或方案脚本(scenario)说明中予以说明。功能需求(Functional Requirement)定义
了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足了业务需求。所谓特性
(feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。
CMM的第二级(可重复级)中将需求管理作为六个关键过程域的一个, 因为它实际上是二级引
入到开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况
下,软件开发才能以一种有计划的有序的方式进行。实际上,没有文档化的需求,在开发工作完
成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级
的其他关键过程域中涉及的原则,都是从一个稳定的基础开始的,那就是文档化的需求基线。
1.2 需求管理、需求分析与需求工程
需求分析(Requirements Analysis)指深入描述软件的功能和性能,确定软件设计的限制和软件
同其他系统元素的接口细节,定义软件的其他有效性需求。RA 的基本任务是准确地回答“系统
必须做什么?”这个问题。需求分析的目的是对各种需求信息进行分析并抽象描述,为目标系统
建立一个概念模型。区分需求管理和需求分析是很重要的。
需求工程(Requirements Engineering,RE)是指应用已证实有效的技术、方法进行需求分析,
确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。RE 是80 年
代中期逐步形成的软件工程子领域。它通过合适的工具和记号系统地描述待开发系统及其行为特
征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。RE 包括所有与需求直
接向关的活动,RE 的活动可以分为需求开发和需求管理两大类。RE 也可以进一步细分为系统需
求工程(如果是针对由软硬件共同组成的整个系统)和软件需求工程(如果仅是专门针对纯软件部
分)。
从完整意义上讲,RE 包括需求获取、需求分析、需求定义、需求验证、需求管理等过程。
从狭义上理解,需求管理关心的是需求管理过程的建立,在信息系统项目组中需要有一套规范的
需求管理过程。从项目经理的角度上看,可能还有 50%甚至更多的精力是用于关注结果的,所以
对需求内容的管理与对需求形式的管理是密不可分的。
2 配置管理
2.1 有关概念
配置管理在信息系统项目管理中具有极其重要的地位和作用。现在,软件配置管理的环境
及其工具越来越得到人们的重视。这里对配置管理中涉及的基本概念进行定义和解释。
产品配置是指一个产品在其生命周期的各个阶段所产生的各种形式和各种版本的文档、计
算机程序、部件及数据的集合。该集合中的每个元素称为该产品配置的一个配置项(Configuraion
Item,CI),配置项的主要属性包括:名称、标识符、文件状态、版本、作者、日期等。配置项
可以分为两类:
(1)属于产品组成部分的工作成果,如需求文档、设计文档、源程序、测试用例等。
(2)属于项目管理和机构支撑过程域产生的文档,如工作计划、项目质量报告、项目跟踪报
告等。这些文档虽然不是产品的组成部分,但又保存的价值。
配置项是配置管理的指定实体,可以分解成若干配置元素和配置单元。但在项目实践中有
时也可以把“配置项”解释为“配置元素”或“配置单元” 。
IEEE对于基线(Baseline)的定义是:已经通过正式复审和批准的某规约或产品,它因此可以
作为进一步开发的基础,并且只能通过正式的变更控制过程进行改变。基线是由一组配置项组
成的一个相对稳定的逻辑实体,基线中的配置项被“冻结”,不能被任何人随意变动。基线通常
对应软件开发过程中的里程碑(Milestone)。里程碑是具有零历时的重要事件,是进度计划中特别
重要的部分。基线的基本属性包括名称、标识符、版本、日期等。向客户交付的一个测试版本
是基线的一个例子。
配置库(Configuraion Library,CL),CL 也称配置项库(Configuraion Item Repository),是配
置管理的有力工具。实践证明,利用配置库实现配置管理是非常有效的。配置库可以分为开发
库(Development Library)、受控库(Controlled Library)和产品库(Product Library)三类。
版本(版本号)是表示一个 CI 具有一组定义的功能的一种标识,由配置管理员负责版本编号
及控制工作。配置项的版本与配置项的状态密切相关,通过一定的规则为配置项指定版本号。
配置项的状态分为三种: “草稿(Draft)” 、 “正式发布(Released)”和“正在修改(Changing)” 。随着
功能的增加,修改或删除,CI 被赋予不同的版本号。一般在配置标识方案中给出版本标记方法。
2.2 对配置管理的不同理解
是否进行配置管理与软件的规模有关,软件的规模越大,配置管理就显得越重要。软件配
置管理(Software Configuration Management,SCM),是在团队开发中,标识、控制和管理软件变
更的一种管理。配置管理的使用取决于项目规模和复杂性以及项目风险水平。 那么什么是软
件配置管理呢?我们可以从以下几个角度理解和掌握它的含义:
(1)PMI 项目管理知识体系指南中的定义
配置管理包括提交变更建议的过程,跟踪变更建议的审查与批准制度,确定变更的批准级
别,以及确认批准的变更方法。配置管理系统作为整个项目管理信息系统的一个子系统。需要
特别说明的一点, “配置管理系统”和“项目管理信息系统”两个概念是基于系统论研究方法提
出的,注意与信息系统软件的区分。
(2)CMMI 中的定义
CMM-SE/SW/IPPD/SS 版本 1.1 中定义:
配置管理是运用配置标识、配置控制、配置状态、配置状态统计和配置审计,建立和维护
工作产品的完整性。
(3)国际标准组织 ISO 的定义
《ISO/IEC 12207(1995)信息技术--软件生存期过程》 :配置管理过程是在整个软件生存期中
实施管理和技术规程的过程,它标识、定义系统中软件项并制定基线;控制软件项的修改和发
行;记录和报告软件项的状态和修改申请;保证软件项的完整性、协调性和正确性;以及控制
软件项的储存、装载和交付。
《ISO 9000-3(1997)质量管理和质量保证标准--第3部分:ISO 9001:1994 在计算机软件
开发、供应、安装和维护中的使用指南》 :软件配置管理是一个管理学科,它对配置项的开发和
支持生存期给予技术上和管理上的指导。配置管理的应用取决于项目的规模、复杂程度和风险
大小。
(4)GB/T 11457:1995《软件工程术语》国家标准
配置管理是标识和确定系统中配置项的过程,在系统整个生存期内控制这些配置项的投放
和变更,记录并报告配置的状态和变更要求,验证配置项的完整性和正确性。
综合以上各种观点,可以把软件配置管理定义为:采用技术手段和行政手段进行管理和监
督的一套规范化方法;对配置项的功能特性和物理特性加以标识,并将其文档化;控制这些特
性的变更;报告变更进行的情况和变更实施的状态以及验证与规定需求的一致性。软件配置管
理是对项目生命周期中的各阶段产品和最终产品演化和变更的管理,是软件项目管理的重要组
成部分。
3 项目范围管理
项目范围管理是确保项目包括成功完成项目所需的全部工作,但又只包括必须完成的工作
的各个过程。它主要关心的是确定与控制哪些应该与哪些不应该包括在项目之内。PMI 最新定
义的项目范围管理包括以下 5 个主要过程:
(1)范围规划——制定项目范围管理计划,记载如何确定、核实与控制项目范围,以及如何
制定与定义工作分解结构(WBS)。
(2)范围定义——制定详细的项目范围说明书,作为将来项目决策的根据。
(3)制定工作分解结构(WBS)——将项目大的可交付成果与项目工作划分为较小的更易管理
的组成部分。
(4)范围核实——正式验收已经完成的项目可脚夫成果。
(5)范围控制——控制项目范围的变更。
就信息系统项目而言,范围这个术语可指产品范围或项目范围。产品范围指产品或服务的
典型特征与功能。项目范围指为提供具有规定特征与功能的产品或服务所需完成的工作。如果
没有因为对产品或服务的需求而形成产品范围,就不需要启动一个项目,也就没有项目范围的
说法了。从总体上看,项目范围是由产品需求或产品范围而引发的,项目范围是为产品范围服
务的。要注意区分产品范围和项目范围这两个概念。项目范围是否完成以项目管理计划作为衡
量标准,而产品范围是否完成则以产品需求作为衡量标准。两种范围的管理必须良好的结合,
以确保项目工作所交付的是规定的产品。
4 综述
需求管理一方面作为对“需求”实施“管理”的活动或过程来理解,而广义上是作为软件
工程子领域――需求工程需求获取、需求分析、需求定义、需求验证四大过程并列的过程。配
置管理是 PMBOK、ISO9000 和 CMMI 中的重要组成元素,它在软件产品开发的生命周期中,
提供了结构化的、有序化的、产品化的管理方法,是项目管理的基础工作。项目范围管理是美
国项目管理协会(PMI)项目管理知识理论体系 PMBOK 中九大知识领域之一,配置管理(系统)作
为项目范围管理知识域范围控制过程的工具而存在,本来是通用项目管理理论体系中两个界定
相对清晰的概念,在《软件工程术语》中没有定义术语“范围管理”或“项目范围管理” 。但当
项目管理理论引入到软件研发过程中后,项目范围管理与配置管理、需求管理三者间的关系变
得有些复杂。
项目范围管理与需求管理属于包含与被包含的关系,分别对应对项目范围和产品范围的管
理。需求分析是逐步清晰产品范围的过程,而需求管理整是对这个产品范围清晰过程的管理过
程。从项目范围和产品范围两者的关系可以看出项目范围管理与需求管理的关系。需求管理与
配置管理都属于软件工程领域的术语和管理过程,前者对应于对产品需求的管理,后者对应于
对项目各阶段交付成果――产品配置的管理,其中需求分析的交付成果――需求文档也作为产
品配置的一个元素――配置项而存在。
项目范围管理与配置管理两者的关系比较模糊,其中涉及一些共同的概念:变更管理、变
更控制系统、变更控制委员会(Change Control Board,CCB)。虽然项目范围管理定义了五个管理
过程,但没有涉及对各阶段交付成果的管理,而配置管理正是要完成对项目各阶段交付成果的
管理,包括属于产品组成部分的工作成果和项目管理支撑过程域产生的文档等。变更控制委员
会之所以也称为配置管理委员会(Configuration Control Board,CCB),是因为项目管理过程中的
变更主要是针对配置项的变更。
总之,深刻理解需求管理、配置管理和项目范围管理基本概念,理顺三者间的联系和区别,
对于规范和改善我们日常项目管理工作都是很有帮助。
主要参考文献
[1] PMI.PMBOK Guide[M].USA roject Management Institute, 2000.
[2] Kim.Heldman.PMP roject Management Professional Study Guide[M].USA:SYBEX Inc, 2002.
[3] 高巍.CMM 关键过程域剖析——成熟度级别 2:需求管理.
[4] 张友生.需求工程概述[M].http://www.uml.org.cn/RequirementProject/yhxq12.htm.
[5] 丁淑颖.需求如何管理?[M].http://www.ccidnet.com.cn.
[6] 柳纯录等.信息系统项目管理师教程[M].北京:清华大学出版社,2005.
[7] 钟铬等.系统分析员重点综述与试题分析[M].北京:中国民航出版社,2002.
[8] [美]美国项目管理协会.项目管理知识体系指南[M]. 北京:电子工业出版社,2004.
[9] [美]凯西.施瓦尔贝.IT 项目管理[M].邓世忠等译. 北京:机械工业出版社,2004.
[10] IBM.第三代配置管理解决方案:统一变更管理(UCM). |
|