全部科目 > 信息系统项目管理师 >
2021年上半年 上午试卷 综合知识
第 64 题
知识点 需求变更管理   评估  
章/节 项目整体管理  
 
 
项目小组正在对项目需求变化数量、变化频率以及变化方式等进行评估,该工作属于( )的管理范畴。
 
  A.  配置管理计划
 
  B.  范围管理计划
 
  C.  变更管理计划
 
  D.  质量管理计划
 
 




 
 
相关试题     要点详解 

  第49题    2013年下半年  
表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。如果软件开发人员发现,有一个孤立的设计元素在需求跟踪能力矩阵中不能回溯到需求,但其表明一个正当的功能,则说明(..

  第61题    2009年下半年  
某软件开发项目在项目的最后阶段发现对某个需求的理解与客户不一致,产生该问题最可能的原因是(61)工作不完善。

  第62题    2012年下半年  
在软件项目中,(62)是确保需求不在开发过程中“丢失”的一个有效措施。

 
知识点讲解
· 需求变更管理
· 评估
 
        需求变更管理
        控制项目范围扩展
        扩展需求是指在软件需求基线已经确定后又要增添新的功能或进行较大改动。
        控制范围扩展的技术:
        .把新系统的视图、范围、限制文档化并作为业务需求的一部分,将每一项建议的需求与项目的视图和范围相比较决定是否应该采纳。
        .原型法:能够给用户提供预览所有可能的实现,以帮助用户与开发方沟通从而准确把握用户的真实需求。
        控制范围扩展的方法是要敢于说“不”。
        变更控制过程
        变更控制策略有:
        .所有需求变更必须遵循的过程,按照此过程,如果一个变更需求未被采纳,则其后过程不再予以考虑。
        .对于未获批准的变更,除可行性论证之外,不应再做其他设计和实现工作。
        .简单请求一个变更不能保证能实现变更,要由项目变更控制委员会决定实现哪些变更。
        .项目风险承担者应该了解变更数据库的内容。
        .决不能从数据库中删除或修改变更请求的原始文档。
        .每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
        变更控制状态报告是用报告、图表来总结变更控制数据库的内容和按状态分类的变更请求数量。项目管理人员通常使用这些报告来跟踪项目状态。
        变更控制过程可以通过自动工具来执行,挑选工具时应该注意以下几个方面:
        .可以定义变更请求的数据项。
        .可以定义变更请求生存期的状态转换图。
        .可以加强状态转换图,使经授权的用户仅能作出所允许的状态变更。
        .记录每一种状态变更的数据,确认作出变更的人员。
        .可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
        .可以根据需要生成标准的或定制的报告和图表。
        变更控制委员会
        变更控制委员会可以由一个小组担任,也可由多个不同的组担任,负责做出决定究竟将哪一些已建议需求变更或新产品特性付诸应用,其人员可以包括:
        .产品或计划管理部门
        .项目管理部门
        .开发部门
        .测试或质量保证部门
        .市场部或客户代表
        .制作用户文档的部门
        .技术支持部门
        .帮助桌面或用户支持热线部门
        .配置管理部门
        度量变更活动
        需求变更活动的度量需要考虑下列方面的内容:
        .接收、未做决定、结束处理的变更请求的数量。
        .已实现需求变更(包括增、删、改)的合计数量。
        .每个方面发出的变更请求的数量。
        .每一个已应用的需求建议变更和实现变更的数量。
        .投入处理变更的人力、物力。
 
        评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。



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

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