全部科目 > 信息系统项目管理师 >
2016年下半年 上午试卷 综合知识
第 64 题
知识点 需求管理概述   基线   需求管理  
关键词 版本号   基线   软件开发   需求管理   开发   需求  
章/节 项目整体管理  
 
 
在进行项目需求管理时,某需求的状态描述是“该需求已被分析,估计了其对项目余下部分的影响,已用一个明确的产品版本号或创建编号分配到相关的基线中,软件开发团队已同意实现该需求,则这个需求状态值是(64)。
 
  A.  已建议
 
  B.  已验证
 
  C.  已实现
 
  D.  已批准
 
 




 
 
相关试题     要点详解 

  第65题    2014年下半年  
下图为需求跟踪过程中的相互影响能力链的局部示意图,图中空缺部分内容①、②分别应为()。


  第1题    2008年上半年  
需求规格说明书的内容不应当包括(1)。

  第36题    2017年下半年  
依据变更的重要性分类,变更一般分为( )、重要变更和一般变更。

 
知识点讲解
· 需求管理概述
· 基线
· 需求管理
 
        需求管理概述
        需求和需求管理
        需求是指由项目接受的或项目产生的产品和产品构件需求,包括由组织征集的对项目的需求。有技术性的,也有非技术性的。
        需求管理的目的是确保各方对需求的一致理解;管理和控制需求的变更;从需求到最终产品的双向跟踪。
        需求工程
        需求工程是所有与需求直接相关的活动的通称,它的活动可分为两大类:需求开发和需求管理。
        需求开发的目的是通过调查和分析获取用户需求并定义产品需求。
        需求基线:软件项目需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型,经评审批准,这些文档就定义了开发工作的需求基线。
        需求开发的主要活动:
        .需求获取。与用户进行交流,捕捉、分析用户对目标系统的需求,提炼出符合解决问题的用户需求,产生《用户需求说明书》。
        .需求分析。对各种需求信息进行分析并抽象描述,为目标系统建立一个概念模型。
        .需求定义。根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《需求规格说明书》。
        .需求验证。指开发方和用户共同对需求文档评审,经双方对需求达成共识后作出书面承诺,使需求文档具有商业合同效果。
        需求管理和需求开发密切合作,需求开发涉及把项目关系人的需要转换成产品需求和决定如何在各个产品构件之间安排或分配需求;需求管理要收集需求的变更和变更的理由,并且维持对原有需求和所有产品及产品构件需求的双向跟踪。
        CMMI中的需求管理流程
        CMMI中的需求管理流程如下:
        (1)制订需求管理计划。
        (2)求得对需求的理解。
        (3)求得对需求的承诺。
        (4)管理需求变更。
        (5)维护对需求的双向跟踪性。
        (6)识别项目工作与需求的不一致。
        需求属性
        除了文本,每个功能需求应该有一些相关的信息或属性与之相联系。这些属性在它的预期功能性之外为每个需求建立了一个上下文和背景资料。
        需求文档中需要考虑的属性包括:
        .创建需求的时间。
        .需求的版本号。
        .创建需求的作者。
        .负责认可该需求的人员。
        .需求状态。
        .需求的原因或根据。
        .需求涉及的子系统。
        .需求涉及的产品版本号。
        .使用的验证方法或接受的测试标准。
        .产品的优先级或重要程度。
        .需求的稳定性。
 
        基线
        基线(baseline)是项目生存期各开发阶段末尾的特定点,也称为里程碑(milestone),在这些特定点上,阶段工作已结束,并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确,使得本来连续开展的开发工作在这些点上被分割开,从而更加有利于检验和肯定阶段工作的成果,同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果,并且认为建立了里程碑,有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品,基线应该是稳定的,如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿,就不能作为基线,不能被冻结。
        如果把软件看作是系统的一个组成部分,以下3种基线最受人们关注的:功能基线、分配基线、产品基线。
        (1)功能基线:指在系统分析与软件定义阶段结束时,经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明;或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        (2)分配基线(指派基线):指在软件需求分析阶段结束时,经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        (3)产品基线:指在软件组装与系统测试阶段结束时,经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外,交付给外部顾客的基线一般称为发行基线,内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        :提出基线的概念本来是为了更好地实现变更控制,但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如,假定某个大型软件中的一个模块修改了,如果将这一变更当做整个软件产品基线的变更,就很不方便。
 
        需求管理
        需求管理通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。根据考试大纲和培训指南的规定,本节要求考生掌握需求变更、需求跟踪和需求变更风险管理3个方面的知识。本节只简单介绍有关需求跟踪方面的知识。有关定义需求基线和需求变更的知识,请阅读12.7.3节;有关风险管理方面的知识,请阅读12.11节。
        需求跟踪的主要目的如下:
        (1)审核。跟踪能力信息可以帮助审核确保所有需求被应用。
        (2)在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素。
        (3)使得维护时能正确、完整地实施变更,从而提高生产率。
        (4)获得计划功能当前实现状态的记录。
        (5)再工程。可以列出旧系统中将要替换的功能,记录它们在新系统的需求和软件组件中的位置。
        (6)重新利用跟踪信息可以帮助开发人员在新系统中对相同的功能利用旧系统相关资源。
        (7)可以减少由于关键成员离开项目带来的风险。
        (8)可以在测试出错时指出最可能有问题的代码段。
        在信息系统项目中,需求变更是不可避免的,如何以可控的方式管理软件的需求,对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析,则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理,则主要使用需求变更流程和需求跟踪矩阵的管理方式。
        需求跟踪包括编制每个需求与系统元素之间的联系文档。这些元素包括别的需求、约束、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪分为正向跟踪和逆向跟踪,一般合称为“双向跟踪”。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵(即表格)。需求跟踪矩阵保存了需求与后续工作成果的对应关系,通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程,即从需求源到实现的前后生存期。它跟踪的是已明确的需求的实现过程,不涉及需求开发人员的职责,也无法用于防止变更矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂,最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时,要及时更新需求跟踪矩阵。



更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5
京公网安备 11010502032051号 | 营业执照
 Copyright ©2000-2023 All Rights Reserved
软考在线版权所有