免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2015年上半年 系统集成项目管理工程师 上午试卷 综合知识
  第57题      
  知识点:   消极风险或威胁的应对策略   分包   风险应对措施   技术实力   监控   评估   用户需求
  关键词:   传输   分包   风险应对   软件开发   图像   项目团队   需求   风险   开发        章/节:   规划风险应对       

 
因时间紧,任务急,经过评估,某智能监控软件涉及的图像传输速度与精度指标难以满足用户需求,故项目团队欲将该软件开发分包技术实力很强的企业完成。这种风险应对措施被称为风险(57)。
 
 
  A.  接受
 
  B.  规避
 
  C.  减轻
 
  D.  转移
 
 
 

 
  第47题    2010年下半年  
   71%
在信息系统试运行阶段,系统失效将对业务造成影响。针对该风险,如果采取“接受”的方式进行应对,应该(47)。
  第57题    2014年下半年  
   56%
在应对风险的基本措施中,( )属于消极风险应对策略。
  第47题    2013年上半年  
   56%
风险转移是设法将风险的后果连同应对的责任转移到他方的风险应对措施,(47)不属于风险转移的措施。
   知识点讲解    
   · 消极风险或威胁的应对策略    · 分包    · 风险应对措施    · 技术实力    · 监控    · 评估    · 用户需求
 
       消极风险或威胁的应对策略
        下表列出了针对消极风险或威胁的四种常用应对策略。
 
       分包
        中标人应当按照合同约定履行义务,完成中标项目。中标人不得向他人转让中标项目,也不得将中标项目肢解后分别向他人转让。中标人按照合同约定或者经招标人同意,可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件,并不得再次分包。中标人应当就分包项目向招标人负责,接受分包的人就分包项目承担连带责任。
 
       风险应对措施
        到目前为止,我们先后介绍了制定风险管理计划、识别并分析风险。我们最终的目的是减少项目中风险发生的可能性、降低风险带来的危害、提高风险带来的收益。可见,还必须针对识别出的风险制定相应的措施来防范风险的发生或增加风险收益,这些措施就体现在风险应对计划中。在风险应对计划中,包括了应对每一个风险的措施、风险的责任人等内容。项目经理可以将风险应对措施和责任人编排到项目进度表中,并进行跟踪和监控。
        制定风险应对计划时有多种不同的策略,对于相同的风险,采用不同的应对策略会有不同的应对方法。通常可以把风险应对策略分为两种类型:防范策略和响应策略。防范策略指的是在风险发生前,项目组会采取一定的措施对风险进行防范;而响应策略则是在风险发生后采取相应措施以降低风险带来的损失。
               制订风险防范策略
               消极的风险(负面风险,威胁)防范策略是最常用的策略,其目的是降低风险发生的概率或减轻风险带来的损失。例如:避免策略、转移策略和减轻策略。
               (1)避免策略。指想方设法阻止风险的发生或消除风险发生的危害。避免策略如果成功则可以消除风险对项目的影响。例如,针对技术风险可以采取聘请技术专家的方法;针对项目进度风险可以采取延长项目时间或缩减项目范围的办法。
               (2)转移策略。指将风险转嫁给其他的组织或个体,通过这种方式来降低风险发生后的损失。例如,在固定成本的项目中,进行需求签字确认,对于超出签字范围的需求变更需要客户增加费用。这种方式就是一种将需求风险转移的策略。经过转移的风险并没有消失,其发生的可能性也没有变化,但对于项目组而言,风险发生后的损失降低了。
               (3)减轻策略。当风险很难避免或转移时,可以考虑采取减轻策略来降低风险发生的概率或减轻风险带来的损失。风险是一种不确定因素,可以通过前期的一些工作来降低风险发生的可能性,或者也可以通过一些准备来降低风险发生的损失。例如,对于需求风险,如果认为需求变化可能很剧烈,那么可以考虑采用柔性设计的方法降低需求变更的代价。尤其对于IT项目而言,越早发现问题越容易解决。例如,对于需求风险带来的问题,在设计阶段发现要好过编码阶段才发现。针对这种特点,也可以采用尽早暴露风险的方法降低风险发生的损失。
               对于正向风险(机会)的应对策略也有3种,分别是开拓、分享和强大。
               (1)开拓。当组织希望更充分地利用机会的时候采用开拓策略,其目的是创造条件使机会确实发生,减少不确定性。一般的做法是分配更多的资源给该项目,使之可以提供比计划更好的成果。
               (2)分享。包括将相关重要信息提供给一个能够更加有效利用该机会的第3方,使项目得到更大的好处。
               (3)强大。目的是通过增加可能性和积极的影响来改变机会的大小,发现和强化带来机会的关键因素,寻求促进或加强机会的因素,积极地加强其发生的可能性。
               需要说明的是,制定出的风险防范措施需要对应到项目进度表中,安排出专门的人员来执行一些工作来防范风险的发生。否则制定出风险防范措施也不会对项目有太大的意义。
               制订风险响应策略
               虽然我们采用了很多方法来防范风险的发生。但风险本身就是一种不确定因素,不可能在项目中完全消除。那么,我们还需要制定一些风险发生后的应急措施来解决风险带来的问题。例如,对于系统性能的风险,由于不清楚目前的系统体系结构是否能够满足用户的需求,可能在系统发布后出现系统性能不足的问题。对于这个风险,我们可以定义其风险响应策略来增加硬件资源以提高系统性能。
               风险响应策略与风险防范策略不同,无论风险是否发生,风险防范策略都需要体现在项目计划中,在项目过程中需要有人来执行相应的防范策略;而风险响应策略是事件触发的,直到当风险发生后才会被执行,如果始终没有发生该风险,则始终不会被安排到项目活动中。
 
       技术实力
        .有明确的系统集成业务领域,在主要业务领域内技术实力、市场占有率等居国内前列。
        .对主要业务领域的业务流程有深入研究,有自主知识产权的基础业务软件平台或其他先进的开发平台,有自主开发的软件产品和工具,且在已完成的系统集成项目中加以应用。
        .有专门从事软件或系统集成技术开发的高级研发人员及与之相适应的开发场地、设备等,并建立完善的软件开发与测试体系。
        .用于研发的经费年均投入在300万元以上。
 
       监控
        主要包括故障监控和性能、流量、负载等状态监控,这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
        (1)服务故障、状态监控:主要是对服务器自身、上层应用、关联服务数据交互监控;例如针对前端Web Server,就可以有很多种类型的监控,包括应用端口状态监控,便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态,更上层可能还包括应用各频道业务的监控,这些只是一部分,还有多种监控方式,依应用特点而定。还有一些问题需解决,如集群过大,如何高性能地进行监控也是一个现实问题。
        (2)集群状态类的监控或统计,为合理管理调优集群提供数据参考,包括服务瓶颈、性能问题、异常流量、攻击等问题。
 
       评估
        评估测试不只针对物理设备,更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统(如路由器)和网络技术(如ATM或FDDI等)的评估。评估测试不适用于全局网络,因为全局网络拓扑负载、网络设备太多,不好准确定位引起问题的原因和位置,不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商,如路由器、集线器或交换机的供应商,通常很少再做设备比较测试,但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题,所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时,除了使用专用于待测设备或技术的工程负载外,有经验的程序员也使用真实负载,使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较,可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能/特征测试一样,用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础,评估测试中对几种设备或技术进行比较;衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划/设计阶段进行测试是非常好的方法,最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试,在设备选型、技术选型,以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形(工程负载)和真实负载模式进行测试,两种方式都提供了唯一的、重要的检测结果,测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果,因此不能在真实运行环境里显示它们的运行性能;真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能,但无法预测设备的总容量。如果时间允许,两种测试都要做。通常测试人员只有时间进行一种测试,一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形(工程负载)下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置,任何有效、公正的测试配置都能对被测产品进行很好的比较。然而,测试配置和负载越接近运行网络的配置和负载,测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意:要确保配置中所有测试组件都是最新版本,使测试尽可能地公正和统一,以取得最好的测试结果。在测试非正式版时一定要小心,因为发布日期经常有错误。测试配置中安装了非正式版后,它还可能会变,所以非正式版的测试结果和正式版的测试结果经常不一致,分析非正式版的设备经常会延误项目的进行。
        进行评估测试时,除了被测设备,测试配置中的所有网络组件都要保持不变。这一点非常重要,只有这样才能保证被测设备可以进行公平比较。对于子网,这一点很容易做到(一个网络设备很容易被另一个设备所替代)。
        网络技术评估要比较各种网络技术,因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换,路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务,逐步完成测试、数据收集和数据解释。在评估测试中,各测试进行的先后次序没有关系,因为它们不是线性关系,而是多次重复进行的。当在测试中发现了新的信息时,以前所做的测试可能要重新进行以确定它的测试结果,或要对以前的测试稍作改变以检验网络运行的其他方面。此外,在评估期间设备提供商经常发布新的版本或非正式的版本,所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时,不仅要参考评估测试所得的测试结果数据,还要综合考虑其他一些信息,如各设备的性能价格比,但由于没有运行网络的持续和峰值负载要求,所以缺少比较基准,往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估,并撰写网络系统评估报告。
 
       用户需求
        收集用户需求是要找出用户需要的重要服务和功能。收集用户需求的机制主要包括与用户群的交流、用户服务和需求归档3个方面。
        收集用户需求最常用的方式有观察和问卷调查、集中访谈、采访关键人物。在整个设计和实施阶段,应始终保持与关键人员之间的交流,以确保网络工程建设不偏离用户需求。
        用户服务表用于表示收集和归档的需求信息,也用来指导管理人员和网络用户进行讨论。
   题号导航      2015年上半年 系统集成项目管理工程师 上午试卷 综合知识   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
5 /
6 /
7 /
8 /
9 /
10 /
11 /
12 /
13 /
14 /
15 /
 
16 /
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
27 /
28 /
29 /
30 /
 
31 /
32 /
33 /
34 /
35 /
36 /
37 /
38 /
39 /
40 /
41 /
42 /
43 /
44 /
45 /
 
46 /
47 /
48 /
49 /
50 /
51 /
52 /
53 /
54 /
55 /
56 /
57 /
58 /
59 /
60 /
 
61 /
62 /
63 /
64 /
65 /
66 /
67 /
68 /
69 /
70 /
71 /
72 /
73 /
74 /
75 /
 
第57题    在手机中做本题