免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2017年下半年 信息系统项目管理师 下午试卷 案例
  第3题      
  知识点：   项目管理   测试阶段   监控   系统测试   系统测试阶段   项目管理计划   项目验收   中标

 
【说明】
甲公司中标一个城市轨道交通监控系统开发项目，公司领导决定启用新的技术骨干作为项目经理，任命研发部软件开发骨干小王为该项目的项目经理。
小王技术能力强，自己承担了该项目核心模块开发任务，自从项目管理计划发布以后，一直投身于自己的研发任务当中。除了项目阶段验收会之外，没有召开过任何项目例会，只是在项目出现问题时才召开项目临时会议。经过项目团队共同努力，该项目进展到系统测试阶段。
在系统测试前，发现该项目有一个指示灯显示模块开发进度严重滞后，小王立刻会同该模块负责人小李一起熬夜加班赶工，完成了该模块。
小王在项目绩效考核时，认为小李的工作态度不认真，给予较差评价并在项目团队内公布考核结果。小李认为自己连续熬夜加班，任务也已完成，觉得考核结果不公平，两人就此问题发生了严重冲突，小李因此消极怠工，甚至影响到了项目验收。
 
问题：3.1   （11分）
（1）基于以上案例，请指出小王在项目团队管理和沟通管理过程中的不恰当之处。
（2）针对小李在项目中的问题，请说明小王该如何预防和改进。
 
问题：3.2   （4分）
结合案例，说明项目经理小王应当重点学习哪些项目团队管理的方法？
 
问题：3.3   （2分）
结合案例中小王和小李的冲突，请指出他们之间的冲突属于_____（从候选答案中选择一个正确选项，将该选项编号填入答题纸对应栏内）。
A.项目优先级冲突 B.资源冲突 C.个人冲突 D.技术冲突
 
问题：3.4   （6分）
请简要描述项目冲突管理的方法。
 
 
 

   知识点讲解    
   · 项目管理    · 测试阶段    · 监控    · 系统测试    · 系统测试阶段    · 项目管理计划    · 项目验收    · 中标
 
       项目管理
        定义
        把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求。管理一个项目包括：
        .识别要求。
        .确定清楚而又能实现的目标。
        .权衡质量、范围、时间和成本方面的要求，使技术规格说明书、计划和方案适合于各干系人的不同需求与期望。
        项目管理需要的知识领域
        除了专门的项目管理技术以外，项目管理组至少应能理解和使用以下5方面的知识领域：
        .项目管理知识体系。
        .应用领域的知识、标准和规定。
        .项目环境知识。
        .通用的管理知识和技能。
        .软技能（处理人际关系技能）。
        项目管理体系
        项目管理体系是指用于管理项目的工具、技术、方法、资源和规程。项目管理计划说明如何使用项目管理体系。
        项目管理环境
        项目管理团队应该考虑的项目环境包括：
        .社会环境：经济、人口、教育、道德、种族、宗教和其他特征等。
        .政治环境：法律、风俗和政治风气等。
        .自然环境：生态和自然地理等。
        项目管理办公室
        项目管理办公室（PMO）是在管辖范围内集中、协调地管理项目的组织单元。也可指“大项目管理办公室”、“项目办公室”或“大项目办公室”。PMO监控项目、大项目或各类项目组合的管理。由PMO管理的项目不必要有特定的关系，PMO关注与上级组织或客户的整体业务目标相联系的项目或子项目之间的协调计划、优先级和执行情况。
        PMO执行的职责可以是一个宽广的范围，包括从以培训、软件、标准政策和规程、模板的形式提供项目管理支持功能，到实际直接管理项目和项目的结果。
        PMO可以存在于任何组织结构中，包括职能型组织。
        项目经理和项目管理办公室的区别如下：
        .追求的目标不同。项目经理关注于特定项目的目标，而PMO管理主要的大项目范围的变化，并将之视为更好地达到业务目标的潜在机会，其工作目标包含组织级的观点。
        .项目经理控制赋予项目的资源以最好地实现项目目标，而PMO对所有项目之间的共享资源进行优化使用。
        .项目经理管理本项目的范围、进度、费用和质量，而PMO管理整体的风险、整体的机会和所有项目的依赖关系。
        过程和过程组
        过程就是一组为了完成一系列事先指定的产品、成果或服务而必须执行的互相联系的行动和活动。
        项目管理过程由项目团队实施，包括两大类：
        .面向管理的过程。即项目管理过程，其目的是启动、规划、执行、监控和结束一个项目。
        .面向产品的过程。一般由项目生命期规定，并因领域而异。
        项目管理过程和创造产品的过程从项目开始到结束始终彼此重叠交互。
        任何项目都必须执行5个项目过程组，它们与应用领域或特定行业无关。过程组不是项目阶段，每一阶段或子项目都要重复过程组的所有子过程。
        .启动过程组。定义并批准项目或阶段。在多阶段项目中，后续阶段进行的启动过程是为了确认在指定项目章程与拟定初步项目范围说明书过程中所做的原假设与决策的合理性。启动过程组也定义了项目意图，确定了目标，并授权项目经理进行项目。
        .规划过程组。定义和细化目标，规划最佳的行动方案，即从各种备选方案中选择最优方案，以实现项目或阶段所承担的目标和范围。项目团队应让所有项目干系人参与项目计划过程。当项目计划工作结束时，不管是由组织还是由项目团队负责，都要有明确的指导方针，否则将无法确定如何进行后续的反馈和细化。项目管理计划的渐进明细经常被称作“滚动式计划”，这意味着计划是一个迭代和持续的过程。
        .执行过程组。整合人员和其他资源，在项目的生命期或某个阶段执行项目管理计划。
        .监控过程组。要求定期测量和监控项目进展，识别与项目管理计划的偏差，以便在必要时采取纠正措施，确保项目或阶段目标达成。
        .收尾过程组。正式接受产品、服务或工作成果，有序地结束项目或阶段。
        项目管理过程组和“计划-执行-检查-行动（即PDCA）”循环的对应关系如下图所示。
        
        项目管理过程组和PDCA循环的对应
        规划过程组与PDCA循环中的“计划”对应；执行过程组与循环中的“执行”对应；监控过程组与循环中的“检查”和“行动”对应。启动过程组是这些循环的开始，而收尾过程组是其结束。
        过程的交互
        项目管理过程组通过它们各自所产生的结果而联系起来——一个过程的结果或者输出通常会成为另一个过程的输入或者整个项目的最终结果。在项目过程组之间以及项目过程本身当中，这种联系是迭代的。
        如果一个项目被划分成阶段，每个阶段中的过程经常会反复进行。项目中过程组的相互作用如下图所示。
        
        过程组的相互作用
        5个项目过程组与44个项目管理过程及9个项目管理知识域的映射关系如下表所示。
        
        过程组、过程和类知识域的映射关系
        注：1．在《信息系统项目管理师教程》中，“团队组建”被划分为规划过程组。在PMBOK 2004版中，“团队组建”在执行过程组中，笔者认为划分在执行过程组中更合理。
        2．发包规划在《信息系统项目管理师教程》中也称为计划签约和编制合同。
 
       测试阶段
        . 可靠性测试（含于集成测试、系统测试）；
        . 排错；
        . 可靠性建模；
        . 可靠性评价；
        . 调整可靠性活动计划；
        . 收集可靠性数据；
        . 明确后续阶段的可靠性活动的详细计划；
        . 编制可靠性文档。
 
       监控
        主要包括故障监控和性能、流量、负载等状态监控，这些监控关系到集群的健康运行及潜在问题的及时发现与干预。
        （1）服务故障、状态监控：主要是对服务器自身、上层应用、关联服务数据交互监控；例如针对前端Web Server，就可以有很多种类型的监控，包括应用端口状态监控，便于及时发现服务器或应用本身是否崩溃、通过ICMP包探测服务器健康状态，更上层可能还包括应用各频道业务的监控，这些只是一部分，还有多种监控方式，依应用特点而定。还有一些问题需解决，如集群过大，如何高性能地进行监控也是一个现实问题。
        （2）集群状态类的监控或统计，为合理管理调优集群提供数据参考，包括服务瓶颈、性能问题、异常流量、攻击等问题。
 
       系统测试
        系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试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）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。
               文档测试
               文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试，包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如，系统需求分析和系统设计说明书中的错误将直接导致编码的错误，用户手册作为软件的一部分，将直接影响用户对系统的使用效果。
               文档测试强调文档的表述应该清楚、准确，主要包含：
               .正确地按照文档描述的方法使用系统。
               .测试每一个提示和建议信息。
               .使用文档作为测试用例的来源。
               .测试每一个在线帮助的超链接。
               .测试每条语句。
               .测试文档中提供的每一个样例。
               .把缺陷写入缺陷跟踪库。
               .检查所有的错误信息。
 
       系统测试阶段
        UML模型可作为测试阶段的依据。系统的测试通常分为单元测试、集成测试、系统测试和验收测试几个不同级别。
        .单元测试是对几个类或一组类的测试，通常由程序员进行。
        .集成测试集成组件和类确认它们之间是否恰当的协作。
        .系统测试将系统当成一个黑箱，验证系统是否具备用户所要求的所有功能。
        .验收测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。
        不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用组件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
 
       项目管理计划
        项目管理计划是说明项目将如何执行、监督和控制的一份文件，它整合了其他各规划过程所输出的所有子管理计划和基准。
        项目管理计划中的子管理计划包括：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人力资源管理计划、沟通管理计划、风险管理计划、采购管理计划和干系人管理计划。
        项目管理计划中的项目基准包括：范围基准、进度基准和成本基准。
        另外，项目管理计划还可能包括以下内容：
        .项目所选用的生命周期及各阶段将采用的过程。
        .项目管理团队做出的裁剪决定，包括：
        项目管理团队所选择的项目管理过程。
        每个所选过程的执行程度。
        对这些过程所需的工具与技术的描述。
        对如何利用所选过程来管理具体项目的描述，包括这些过程间的依赖关系和相互影响，以及这些过程的主要输入和输出。
        .关于如何执行工作以实现项目目标的描述。
        .变更管理计划，用来明确如何对变更进行监控。
        .配置管理计划，用来明确如何开展配置管理。
        .对如何维护绩效测量基准的完整性的说明。
        .干系人的沟通需求和适用的沟通技术。
        .为处理未决问题和制订决策所开展的关键管理审查，包括内容、程度和时间安排等。
        项目管理计划可以是概括的或详细的，可以包括一个或多个子管理计划。每个子计划的详细程度取决于具体项目的要求。项目管理计划一旦被确定为基准，就只有在提出变更请求并经实施整体变更控制过程批准后才能变更。
 
       项目验收
        项目验收是项目收尾管理中的首要环节。项目的正式验收包括验收项目产品、文档及已经完成的交付成果。
        系统集成项目的验收依据是项目前期所签署的合同内容以及对应的技术工作内容，如果在项目执行过程中发生了合同变更，还应将变更内容也作为项目验收的评价依据。对于软件类型的系统集成项目而言，验收依据除了项目前期的合同内容，还包括甲乙双方签署或认可的软件需求规格说明书。
        系统集成项目在验收阶段主要包含以下四方面的工作内容，分别为：
        .验收测试：对信息系统进行全面的测试，依照双方合同约定的系统环境，以确保系统的功能和技术设计满足建设方的功能需求和非功能需求，并能正常运行。验收测试阶段应包括编写验收测试用例，建立验收测试环境，全面执行验收测试，出具验收测试报告以及验收测试报告的签署。
        .系统试运行：信息系统通过验收测试后，可以开通系统试运行。系统试运行期间主要包括数据迁移、日常维护以及缺陷跟踪和修复等方面的工作内容。
        .系统文档验收：系统经过验收测试后，系统的文档应当逐步、全面地移交给客户。客户也可按照合同或者项目工作说明书的规定，对所交付的文档加以检查和评价；对不清晰的地方可以提出修改要求。系统集成项目所涉及的文档一般包括：
        系统集成项目介绍。
        系统集成项目最终报告。
        信息系统说明手册。
        信息系统维护手册。
        软硬件产品说明书、质量保证书等。
        .项目终验：在系统经过试运行以后的约定时间，例如三个月或者六个月，双方可以启动项目的最终验收工作。最终验收的工作包括双方对验收测试文件的认可和接受、双方对系统试运行期间的工作状况的认可和接受、双方对系统文档的认可和接受、双方对结束项目工作的认可和接受。
        项目最终验收合格后，应该由双方的项目组撰写验收报告提请双方工作主管认可。这标志着项目组开发工作的结束和项目后续活动的开始。
 
       中标
        中标人的投标应当符合下列条件之一：
        （1）能够最大限度地满足招标文件中规定的各项综合评价标准。
        （2）能够满足招标文件的实质性要求，并且经评审的投标价格最低。但是投标价格低于成本的除外。
        评标委员会经评审，认为所有投标都不符合招标文件要求的，可以否决所有投标。依法必须进行招标的项目的所有投标被否决的，招标人应当重新招标。
        在确定中标人前，招标人不得与投标人就投标价格、投标方案等实质性内容进行谈判。评标委员会成员应当客观、公正地履行职务，遵守职业道德，对所提出的评审意见承担个人责任。评标委员会成员不得私下接触投标人，不得收受投标人的财物或其他好处。评标委员会成员和参与评标的有关工作人员不得透露对投标文件的评审和比较、中标候选人的推荐情况，以及与评标有关的其他情况。
        中标人确定后，招标人应当向中标人发出中标通知书，并同时将中标结果通知所有未中标的投标人。中标通知书对招标人和中标人具有法律效力。中标通知书发出后，招标人改变中标结果的，或者中标人放弃中标项目的，应当依法承担法律责任。招标人和中标人应当自中标通知书发出之日起30日内，按照招标文件和中标人的投标文件订立书面合同。招标人和中标人不得再行订立背离合同实质性内容的其他协议。招标文件要求中标人提交履约保证金的，中标人应当提交。
        依法必须进行招标的项目，招标人应当自确定中标人之日起15日内，向有关行政监督部门提交招标投标情况的书面报告。
   题号导航      2017年下半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第3题    在手机中做本题