免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2021年下半年 系统集成项目管理工程师 下午试卷 案例
  第2题      
  知识点:   培训   三点估算   数据准备   系统测试   预算

 
某公司拟建设一个门户平台,根据工作内容,该平台项目分为需求调研、系统实施、系统测试数据准备(培训)、上线试运行、验收六个子任务,各子任务预算三点估算工期如下表所示。

到第6周周末时,对项目进行了检查,发现需求调研已经结束,共计花费1.8万元,系统实施的工作完成了一半,已花费17万元。
 
问题:2.1   (5分)
(1)请采用三点估算法估算各个子任务的工期:
(2)请分别计算系统实施和系统测试两个任务的标准差。
 
问题:2.2    (9分)
该项目开发过程中采用瀑布模型,请评估项目到第六周周末时的执行绩效。
 
问题:2.3   (4分)
如果项目从第7周开始不会再发生类似的偏差,请计算此项目的完工估算EAC和完工偏差VAC。
 
问题:2.4   (2分)
为了提升项目的执行绩效,项目组成员提出采取并行施工的方法加快进度,请指出采取该方式的缺点。
 
 
 

   知识点讲解    
   · 培训    · 三点估算    · 数据准备    · 系统测试    · 预算
 
       培训
        培训包括旨在提高项目团队成员能力的全部活动。
        培训可以是正式或非正式的。培训方式包括课堂培训、在线培训、计算机辅助培训、在岗培训(由其他项目团队成员提供)、辅导及训练。
        应按人力资源管理计划中的安排来实施预定的培训。也应根据管理项目团队过程中的观察、交谈和项目绩效评估的结果,来开展必要的计划外培训,培训成本通常应该包括在项目预算中,或者由执行组织承担(如果增加的技能有利于未来的项目)。培训可以由内部或外部培训师来执行。
 
       三点估算
        通过考虑估算中的不确定性和风险,可以提高活动历时估算的准确性。这个概念源自计划评审技术(PERT)。PERT使用三种估算值来界定活动持续时间的近似区间。
               活动历时估算
               对活动进行最乐观、最悲观及最可能时间估算:
               To(Optimistic Time,最乐观时间)
               Tm(Most likely Time,最可能时间)
               Tp(Pessimistic Time,最悲观时间)
               假定三个估值服从β分布,由此可算出每个活动的期望历时Tei为:
               
               其中i表示第i项活动。
               根据β分布的方差计算方法,第i项活动的持续时间方差为:
               
               标准差为:
               
               总工期估算
               PERT方法中总工期期望值为各活动期望历时之和,且服从正态分布。
               总工期期望值:Te=∑Tei
               总工期方差:
               标准差:
               总工期的正态分布示意图如下图所示。
               
               总工期的正态分析
               正态分布图的X轴代表工期,Y轴代表工期发生的概率密度,曲线下的面积代表了累积概率分布。由正态分布图可以得到下面的信息:
               .以工期期望值Te为中心,概率分布曲线对称分布。
               .如果需要了解某一天完成项目的可能性,只要看对应的概率密度即可,特殊点的可以通过计算得到,其他点的需要查正态分布表。
               .如果需要了解某一段时间内完成项目的可能性,需要求解该段时间内累积概率密度和,即该段时间内曲线下的面积。
               .以工期期望值为中心,±1σ范围内完成的概率为68%,±2σ范围内完成的概率为95%,±3σ范围内完成的概率为99%。
               例1:A活动历时的悲观估计是36天,乐观估计是6天,最可能估计是21天,那么该活动在16~26天完成的概率有多大?在16天以前完成的概率有多大?
               A活动的期望工期为TeA=(36+4×21+6)/6=21天
               标准差为σA=(36-6)/6=5
               根据正态分布规律,A活动在16~26天完成正好落在±1σ范围内,所以完成的概率为68%。
               16天恰好是Te-1σ,所以A活动在16天之前完成的概率为50%-68%/2=16%。
               例2:下图所示为一个项目的关键路径,图中标出了每个活动的ToiTmiTpi,计算项目在57天内完成的概率为多少。
               
               某项目的关键路径
               分别对每个活动计算期望工期及方差,得到下表中的数据。
               
               各活动的期望工期及方差
               该项目的期望工期为Te=4+11+25+12=52天
               总方差为σ2=0.444+2.778+20.25+2.26=25.732
               标准差为σ=5.072
               因为Te+1σ=52+5.072=57.072,57天落在正态分布的Te+1σ处,所以项目在57天内完成的概率为50%+68%/2=84%。
 
       数据准备
        数据的收集、整理、录入是一项既繁琐、劳动量又大的工作。而没有一定基础数据的准备,系统调试不能很好地进行。一般说来,确定数据库物理模型之后,就应进行数据的整理、录入。这样既分散了工作量,又可以为系统调试提供真实的数据。实践证明,这方面的工作往往容易被人忽视,甚至系统完成后只能作为摆设放在那里而不能真正运行。这等于建好工厂,但缺乏原料而不能投产。这类例子虽然不能说司空见惯,但也不是绝无仅有。因此,要特别强调这一点,不能把系统的实现仅仅归结为编程序或买机器。这几方面的任务是相互联系、彼此制约的。它们的关系可概括为下表。
        
        系统实施阶段的主要活动及相互关系
        
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来,以需求规格说明为依据,在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段,系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。
        系统测试由独立测试小组在测试组长的监督下进行,测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。
               负载测试
               负载测试是通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
               负载测试的加载方式通常有如下几种。
               (1)一次性加载。一次性加载某个数量的用户,在预定的时间段内持续运行。例如,在早晨上班的时间访问网站或登录网站的时间非常集中,基本属于扁平负载模式。
               (2)递增加载。有规律地逐渐增加用户,每几秒增加一些新用户,交错上升。借助这种负载方式的测试,容易发现性能的拐点,即性能瓶颈。
               (3)高低突变加载。某个时间用户数量很大,突然降到很低,过一段时间,又突然加到很高,反复几次。借助这种负载方式的测试,容易发现资源释放和内存泄露等问题。
               (4)随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载,这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期,但可以模拟系统长时间的运行过程的状态。
               压力测试
               压力测试又称为强度测试,是在强负载(加大数据量、大量并发用户等)下的测试,用于查看应用系统在峰值使用情况下的操作行为,目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间(如24小时以上)的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
               微软测试实践经验表明,如果软件产品通过72小时压力测试,则在72小时后出现问题的可能性微乎其微。所以,72小时成为微软产品压力测试的时间标志。
               负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载,测试其变化,看最后在满足性能的情况下,系统最多能接受多大负载的测试。压力测试是在满足性能的情况下,能使系统处于失效的状态,通俗来说,就是发现在什么条件下,系统的性能会变得不可接受。
               压力测试的一般步骤如下:
               ①进行简单多任务测试。
               ②简单压力缺陷修正后,增加系统的压力直到系统崩溃。
               因此,负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中,通过实时性能监测来确认和查找问题,并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试,通过这些测试,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。
               可靠性测试
               软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会(IEEE)将软件可靠性定义为:系统在特定的环境下,在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性,以及可维护性等多方面特性,是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
               可靠性测试一般伴随着强壮性测试,是评估软件在运行时的可靠性,通过测试确认平均无故障时间(Mean Time to Failure,MTTF)、故障发生前平均工作时间(Mean-Time-To-First-Failure,MTTFF)或因故障而停机的时间(Mean Time To Repairs,MTTR)在一年中应不超过多少时间。可靠性测试强调随机输入,并通过模拟系统实现,很难通过实际系统的运行来实现。
               安全性测试
               安全性测试是测试系统在应付非授权的内部/外部访问、非法侵入或故意的损坏时的系统防护能力,检验系统有能力使可能存在的内/外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性,但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。
               安全性测试需要设计一些测试用例试图突破系统的安全保密措施,检验系统是否有安全保密漏洞,验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中,测试者扮演成试图攻击系统的角色,尝试获取系统密码,利用能够瓦解任何防守的客户软件攻击系统;或者把系统“制服”,使别人无法访问。
               安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用,有无漏洞。破坏系统保护机构的主要方法有以下几种:
               (1)正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。
               (2)以系统输入为突破口,利用输入的容错性进行正面攻击。
               (3)申请和占用过多的资源压垮系统,以破坏安全措施,从而进入系统。
               (4)故意使系统出错,利用系统恢复的过程,窃取用户口令及其他有用的信息。
               (5)通过浏览残留在计算机各种资源中的垃圾(无用信息),以获取如口令、安全码和译码关键字等信息。
               (6)浏览全局数据,期望从中找到进入系统的关键字。
               (7)浏览那些逻辑上不存在,但物理上还存在的各种记录和资料等。
               一般情况下,网络软件的安全评估包括以下情况;
               (1)检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。
               (2)会话跟踪是否足够。
               (3)是否正确使用了加密技术。
               (4)变量限制的设定。
               (5)在服务器端执行程序中的安全漏洞。
               (6)HTML源码中是否有敏感的信息或没有必须出现的信息。
               兼容性/配置测试
               兼容性/配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。
               可以从如下几个方面进行兼容性测试。
               (1)检查版本是否兼容。检查新版本操作习惯与老版本是否兼容,目的是使老版本的用户很快地适应新版本的变化。
               (2)检查数据格式是否兼容。数据格式有许多种形式,如文件格式、网络协议和共享数据等。例如,通信协议软件版本升级后,检查升级版本和老版本的通信协议是否一致等。
               (3)检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用,是否属于某个平台或版本独有,是否在不同平台上有差异。
               (4)检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例,检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。
               容错性测试
               容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时,能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。
               可用性测试
               可用性是指系统正常运行的能力和用户接受的程度,一般用如下公式表示。
               可用性=平均正常工作时间/(平均正常工作时间+平均修复时间)
               影响可用性的因素有如下几个:
               (1)不充分的测试。
               (2)更改管理问题。
               (3)缺少在线监视和分析。
               (4)操作错误。
               (5)弱编码。
               (6)与外部服务或应用程序的交互。
               (7)不同的操作条件(使用级别更改、峰值重载)。
               (8)异常事件(安全性失败、广播风暴)。
               (9)硬件故障(硬盘、控制器、网络设备、服务器、电源、内存和CPU)。
               (10)环境问题(电源、冷却、火、洪水、灰尘、自然灾害)。
               下面给出提高系统可用性的一些办法。
               (1)使用集群。集群是指将至少两个系统连接到一起,像一个系统那样工作。当某一系统出现失效时,集群提供即时故障转移服务。
               (2)使用网络负载平衡。当检测某服务器失败后,网络负载平衡自动将通信量重新分发给仍然运行的服务器。
               (3)使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如,“该应用程序应每周运行7天,每天24小时,年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟,不足1个小时。
               (4)提供实时的监视。监视系统的工作负荷和失败数据,实时监视对于发现趋势和改善服务至关重要。
               (5)使用数据备份,保证数据安全。
               (6)检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用,还意味着使得应用程序使用的所有分布式组件和资源受到保护。
               文档测试
               文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试,包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如,系统需求分析和系统设计说明书中的错误将直接导致编码的错误,用户手册作为软件的一部分,将直接影响用户对系统的使用效果。
               文档测试强调文档的表述应该清楚、准确,主要包含:
               .正确地按照文档描述的方法使用系统。
               .测试每一个提示和建议信息。
               .使用文档作为测试用例的来源。
               .测试每一个在线帮助的超链接。
               .测试每条语句。
               .测试文档中提供的每一个样例。
               .把缺陷写入缺陷跟踪库。
               .检查所有的错误信息。
 
       预算
        预算是指组织按照一定的业务量水平及质量水平,估计各项成本、计算预算成本,并以预算成本为控制经济活动的依据,衡量其合理性。当实际状态和预算有了较大差异时,要查明原因并采取措施加以控制。编制预算是以预算项目的成本预测及IT服务工作量的预测为基础的。
        预算的编制方法主要有增量预算和零基预算,其选择依赖于企业的财务政策。增量预算是以去年的数据为基础,考虑本年度成本、价格等的期望变动,调整去年的预算。在零基预算下,组织实际所发生的每一活动的预算最初都被设定为零。为了在预算过程中获得支持,对每一活动必须就其持续的有用性给出有说服力的理由。即详尽分析每一项支出的必要性及其取得的效果,确定预算标准。零基预算方法迫使管理当局在分配资源前认真考虑组织经营的每一个阶段。这种方法通常比较费时,所以一般几年用一次。
        .预算项目的成本预测。预算项目一般按照成本项目划分,一旦确定一般要保持稳定,这样一是可以使企业了解其成本变动趋势,进行纵向比较,也可以与其他企业之间进行横向比较,二是为成本管理活动提供了一个简单的处理基础,如折旧可以按照成本类型的不同分别进行处理。
        在预算编制时,各预算项目的成本一般都是未知的,如加班工资、外部网收费等,因此必须对其进行预测。预测这些成本是以从前IT会计年度的成本数据为基础或以未来工作量的预测为基础进行的。IT成本管理必须谨慎地估计不可控制的成本的变化。
        .IT服务工作量预测。IT工作量是成本变化的一个主要原因之一,因此,在编制预算的时候,要预测未来IT工作量。不仅成本管理活动需要估计工作量,在服务级别管理和容量管理中也需要对工作量进行预测。工作量预测将以工作量的历史数据为基础,考虑数据的更新与计划的修改,得出未来的IT工作量。
   题号导航      2021年下半年 系统集成项目管理工程师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第2题    在手机中做本题