需求的管理

feiyang10086

需求的管理

     近年来,信息系统项目的规模越来越大,复杂度越来越高。由于管理上的失误给人们的教训也越来越深刻。需求管理、配置管理、项目范围管理对于信息系统项目管理而言,都具有举足轻重的地位。澄清这些基本概念的含义,分析相互间的联系与区别以加深大家的理解,对规范和促进软件项目管理工作意义不小。
    信息系统项目中的需求管理RM(Requirements Management)包括确保所有项目干系人对需求的一致理解;管理和控制需求的变更;从需求到最终产品的双向跟踪。词汇“需求管理”可以理解为对“需求”实施“管理”的活动或过程。“需求”在IEEE软件工程标准词汇表(1997年)中定义为:
    (1)用户解决问题或达到目标所需的条件或权能(Capability)。
    (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
    (3)一种反映(1)或(2)所描述的条件或权能的文档说明。
    与传统的生产企业相比较,软件的需求具有模糊性、不确定性、变化性和主观性等特点,软件的需求不像生产汽车、电脑等硬件的需求,是有形的、客观的、可描述的、可检测的,软件需求是软件项目最难把握的问题。软件需求包括业务需求、用户需求和功能需求(含非功能需求)。业务需求(Business Requirement)反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。用户需求(UserRequirement)文档描述了用户使用产品必须要完成的任务,这在使用实例(Use Case)文档或方案脚本(scenario)说明中予以说明。功能需求(Functional Requirement)定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合,给用户提供处理能力并满足业务需求。
    CMM的第二级(可重复级)中将需求管理作为六个关键过程域的一个,因为它实际上是二级引入到开发过需求管理及配置管理与项目范围管理程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下,软件开发才能以一种有计划和有序的方式进行。实际上,没有文档化的需求,在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在二级的其他关键过程域中涉及的原则,都是从一个稳定的基础开始的,那就是文档化的需求基线。
    需求分析RA(Requirements Analysis)指深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统元素的接口细节,定义软件的其他有效性需求。RA的基本任务是准确地回答“系统必须做什么?”这个问题。需求分析的目的是对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型。区分需求管理和需求分析是很重要的。

需求工程RE(Requirements Engineering)是指应用已被证实有效的技术、方法进行需求分析,确定客户需求,帮助分析人员理解问题并定义目标系统的所有外部特征。RE是80年代中期逐步形成的软件工程子领域。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束,形成需求文档,并对用户不断变化的需求演进给予支持。RE包括所有与需求直接相关的活动,RE的活动可以分为需求开发和需求管理两大类。RE也可以进一步细分为系统需求工程(如果是针对由软硬件共同组成的整个系统)和软件需求工程(如果仅是专门针对纯软件部分)。
    从完整意义上讲,RE包括需求获取、需求分析、需求定义、需求验证、需求管理等过程。从狭义上理解,需求管理关心的是需求管理过程的建立,在信息系统项目组中需要有一套规范的需求管理过程。从项目经理的角度上看,可能还有50%甚至更多的精力是用于关注结果的,所以对需求内容的管理与对需求形式的管理是密不可分的。
    配置管理在信息系统项目管理中具有极其重要的地位和作用。现在,软件配置管理的环境及其工具越来越得到人们的重视。这里对配置管理中涉及的基本概念进行定义和解释。
    是指一个产品在其生命周期的各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每个元素称为该产品配置的一个配置项CI(Configuraion Item),配置项的主要属性包括:名称、标识符、文件状态、版本、作者、日期等。配置项可以分为两类:
    ①属于产品组成部分的工作成果,如需求文档、设计文档、源程序、测试用例等。
    ②属于项目管理和机构支撑过程域产生的文档,如工作计划、项目质量报告、项目跟踪报告等。这些文档虽然不是产品的组成部分,但又有保存的价值。
    配置项是配置管理的指定实体,可以分解成若干配置元素和配置单元。但在项目实践中有时也可以把“配置项”解释为“配置元素”或“配置单元”。
    IEEE对于基线(Baseline)的定义是:已经通过正式复审和批准的某规约或产品,它可以作为进一步开发的基础,并且只能通过正式的变更控制过程进行改变。基线是由一组配置项组成的一个相对稳定的逻辑实体,基线中的配置项被“冻结”,不能被任何人随意变动。基线通常对应软件开发过程中的里程碑(Milestone)。里程碑是具有零历时的重要事件,是进度计划中特别重要的部分。基线的基本属性包括名称、标识符、版本、日期等。向客户交付的一个测试版本是基线的一个例子。
    配置库CL(Configuraion Library)也称配置项库(Con-figuraion Item Repository),是配置管理的有力工具。实践证明,利用配置库实现配置管理是非常有效的。配置库可以分为开发库(Development Library)、受控库(ControlledLibrary)和产品库(Product Library)三类。
版本(版本号)是表示一个CI具有一组定义的功能的一种标识,由配置管理员负责版本编号及控制工作。配置项的版本与配置项的状态密切相关,通过一定的规则为配置项指定版本号。配置项的状态分为三种:“草稿(Draft)”、“正式发布(Released)”和“正在修改(Changing)”。随着功能的增加、修改或删除,CI被赋予不同的版本号。一般在配置标识方案中给出版本标记方法。
    是否进行配置管理与软件的规模有关,软件的规模越大,配置管理就显得越重要。软件配置管理SCM(Software Configuration Management)指在团队开发中,标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模、项目复杂性以及项目风险水平。软件配置管理可以从以下几个角度理解和掌握它的含义:配置管理包括提交变更建议的过程,跟踪变更建议的审查与批准制度,确定变更的批准级别,以及确认批准的变更方法。配置管理系统作为整个项目管理信息系统的一个子系统。需要特别说明的一点是,“配置管理系统”和“项目管理信息系统”两个概念是基于系统论研究方法提出的,注意与信息系统软件的区分。