某市石油销售公司计划实施全市的加油卡联网收费系统项目。该石油销售公司选择了系统集..

2010年下半年下午试卷案例

第 3 题

知识点	项目管理项目管理计划测试过程分包风险管理石油实施阶段项目计划

某市石油销售公司计划实施全市的加油卡联网收费系统项目。该石油销售公司选择了系统集成商M作为项目的承包方，M公司经石油销售公司同意，将系统中加油机具改造控制模块的设计和生产分包给专业从事自动控制设备生产的H公司。同时，M公司任命了有过项目管理经验的小刘作为此项目的项目经理。
小刘经过详细的需求调研，开始着手制定项目计划，在此过程中，他仔细考虑了项目中可能遇到的风险，整理出一张风险列表。经过分析整理，得到排在前三位的风险如下：
1、项目进度要求严格，现有人员的技能可能无法实现进度要求；
2、现有项目人员中有人员流动的风险；
3、分包商可能不能按期交付机具控制模块，从而造成项目进度延误。
针对发现的风险，小刘在做进度计划的时候特意留出了20%的提前量，以防上述风险发生，并且将风险管理作为一项内容写进了项目管理计划。项目管理计划制定完成后，小刘通知了项目组成员，召开了第一次项目会议，将任务布置给大家。随后，大家按分配给自己的任务开展了工作。
第四个月底，项目经理小刘发现H公司尚未生产出联调所需要的机具样品。H公司于10天后提交了样品，但在联调测试过程中发现了较多的问题，H公司不得不多次返工。项目还没有进入大规模的安装实施阶段，20%的进度提前量就已经被用掉了，此时，项目一旦发生任何问题就可能直接影响最终交工日期。

问题：3.1 请从整体管理和风险管理的角度指出该项目的管理存在哪些问题。

问题：3.2 项目经理小刘为了防范风险发生，预留了 20%的进度提前量，在风险管理中这叫做（1）。
在风险管理的各项活动中，头脑风暴法可以用来进行（2），风险概率及影响矩阵可用来进行（3）。

问题：3.3 针对“项目进度要求严格，现有人员的技能可能无法实现进度要求”这条风险，请提出你的应对措施。

问题：3.4 针对“分包商可能不能按期交付机具控制模块，从而造成项目进度延误”这条风险，结合案例，分别按避免、转移、减轻和应急响应四种策略提出具体应对措施。

知识点讲解

· 项目管理

· 项目管理计划

· 测试过程

· 分包

· 风险管理

· 石油

· 实施阶段

· 项目计划

项目管理

项目管理定义

项目管理就是将知识、技能、工具与技术应用于项目活动，以满足项目的要求。

管理一个项目通常包括（但不限于）：

.识别需求。

.在规划和执行项目时，处理干系人的各种要求、关注和期望。

.在干系人之间建立、维护和开展积极、有效和合作性的沟通。

.有效管理干系人。

.平衡相互竞争的项目制约因素，如范围、质量、进度、成本、资源和风险等。

项目管理需要的专业知识和技术

除了专门的项目管理技术以外，项目管理团队至少应能理解和使用以下六方面的知识：

.项目管理知识体系。

.项目应用领域的知识、标准和规定。

.项目环境知识。

.通用的管理知识和技能。

.软技能或处理人际关系技能。

.经验、知识、工具和技术。

项目管理环境

项目管理团队应该考虑的项目环境包括：

.社会环境：经济、人口、教育、道德、种族、宗教和其他特征等。

.政治环境：法律、风俗和政治风气等。

.自然环境：生态和自然地理等。

项目经理

项目经理是负责实现项目目标的个人。

对项目经理的一般要求有：

.足够的知识（项目管理知识、丰富的IT知识、客户行业知识、其他必要的知识）。

.丰富的项目管理经验。

.良好的协调和沟通能力。

.良好的职业道德。

.一定的领导和管理能力。

一个好的项目经理能够使项目完成得出色，把握项目计划包括成本、进度、范围以及质量等，把客户的满意度提到最高。要做好一个项目经理，需要：

.真正理解项目经理的角色。

.领导并管理项目团队。

.依据项目进度的阶段，组织制订详细程度适宜的项目计划并监控项目执行，对计划的变更进行管理。

.真正理解“一把手工程”。

.注重客户和用户参与。

项目干系人

项目干系人（Project Stakeholder），也称为项目利害相关者，是积极参与项目，或其利益因项目的实施或完成而受到积极或消极影响的个人或组织，他们还会对项目的目标和结果产生影响。项目管理团队必须明确项目的干系人，确定其需求，然后对这些需求进行管理和施加影响，确保项目取得成功。

项目干系人对项目的影响包括积极的影响和消极的影响。项目管理团队不仅要关注产生积极影响的项目干系人，也不能忽略产生消极影响的项目干系人。项目关键干系人包括：

.项目经理：负责管理项目的人。

.客户/用户。

.执行组织：其员工直接参与项目工作的单位。

.项目团队成员：执行项目工作的群体。

.项目发起人：为项目分配资金或实物等财力资源的个人或组织。

.职能经理：可以为项目经理提供专业技术支持，提供及时及合格的资源。

.有影响力的人：在客户组织内的地位可能正面或负面影响项目的进程。

.项目管理办公室（PMO）：直接或间接地对项目结果负有责任。

项目管理系统

项目管理系统是指用于管理项目的工具、技术、方法、资源和过程组的集合。项目管理计划中说明如何使用项目管理系统。

事业环境因素

事业环境因素是指项目团队不能控制的，将对项目产生影响、限制或指令作用的各种条件。事业环境因素是大多数规划过程的输入，可能提高或限制项目管理的灵活性，并可能对项目结果产生积极或消极的影响。

事业环境因素包括（但不限于）：

.组织文化、结构和治理。

.政府或行业标准，如监管机构条例、行为准则、产品标准、质量标准和工艺标准。

.基础设施，如现有的设施和固定资产。

.现有人力资源状况、人事管理制度、公司的工作授权系统。

.市场条件。

.项目干系人风险承受力。

.政治氛围。

.组织已有的沟通渠道。

.商业数据库，如标准化的成本估算数据、行业风险研究资料和风险数据库。

.项目管理信息系统。

组织过程资产

组织过程资产是执行组织所特有并使用的计划、流程、政策、程序和知识库，包括来自任何（或所有）项目参与组织的，可用于执行或治理项目的任何产物、实践或知识。组织过程资产是大部分规划过程的输入。

组织过程资产可分成以下两大类：

.流程与程序：组织用于执行项目工作的流程与程序。

.共享知识库：组织用来存取信息的知识库，如财务数据库、历史项目信息、经验教训等。

项目管理计划

项目管理计划是说明项目将如何执行、监督和控制的一份文件，它整合了其他各规划过程所输出的所有子管理计划和基准。

项目管理计划中的子管理计划包括：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人力资源管理计划、沟通管理计划、风险管理计划、采购管理计划和干系人管理计划。

项目管理计划中的项目基准包括：范围基准、进度基准和成本基准。

另外，项目管理计划还可能包括以下内容：

.项目所选用的生命周期及各阶段将采用的过程。

.项目管理团队做出的裁剪决定，包括：

项目管理团队所选择的项目管理过程。

每个所选过程的执行程度。

对这些过程所需的工具与技术的描述。

对如何利用所选过程来管理具体项目的描述，包括这些过程间的依赖关系和相互影响，以及这些过程的主要输入和输出。

.关于如何执行工作以实现项目目标的描述。

.变更管理计划，用来明确如何对变更进行监控。

.配置管理计划，用来明确如何开展配置管理。

.对如何维护绩效测量基准的完整性的说明。

.干系人的沟通需求和适用的沟通技术。

.为处理未决问题和制订决策所开展的关键管理审查，包括内容、程度和时间安排等。

项目管理计划可以是概括的或详细的，可以包括一个或多个子管理计划。每个子计划的详细程度取决于具体项目的要求。项目管理计划一旦被确定为基准，就只有在提出变更请求并经实施整体变更控制过程批准后才能变更。

测试过程

软件测试过程一般包括：测试需求分析、测试策划、测试设计和实现、测试执行、测试总结（包括评价过程和总结），如下图所示。

软件测试过程

测试需求分析

根据被测软件的需求规格说明或设计文档，进行测试需求分析，包括：

（1）确定需要的测试类型及其测试要求并进行标识（编号），标识应清晰、便于识别。测试类型包括功能测试、性能测试等类型；测试要求包括状态、接口、数据结构、设计约束等要求。确定的测试类型和测试要求均应与要求的测试级别（单元测试、部件测试、配置项测试、系统测试）、测试类型相匹配。

（2）确定每个测试项的优先级。

（3）确定每个测试项的测试充分性要求。

（4）根据被测软件的重要性、测试目标和约束条件，确定每个测试项应覆盖的范围及范围所要求的覆盖程度。

（5）确定每个测试项测试终止的要求，包括测试过程正常终止的条件（如测试充分性是否达到要求）和导致测试过程异常终止的可能情况。

（6）确定测试项与软件需求规格说明或设计文档的追踪关系。

将测试需求分析结果按所确定的文档要求，形成测试需求规格说明或写入测试计划。

应对测试需求规格说明或测试需求分析结果进行评审，评审内容如下：

（1）测试级别和测试对象所确定的测试类型及其测试要求是否恰当。

（2）每个测试项是否进行了标识，并逐条覆盖了测试需求和潜在需求。

（3）测试类型和测试项是否充分。

（4）测试项是否包括了终止要求。

（5）文档是否符合规定的要求。

测试策划

根据软件需求规格说明或设计文档等进行测试策划，策划一般包括：

（1）确定测试策略，如部件或配置项测试策略。

（2）确定测试需要的技术或方法，如测试数据生成与验证技术、测试数据输入技术、测试结果获取技术。

（3）确定要受控制的测试工作产品，列出清单。

（4）确定用于测试的资源要求，包括软硬件设备、环境条件、人员数量和技能等要求。

（5）进行测试风险分析，如技术风险、人员风险、资源风险和进度风险等。

（6）确定测试任务的结束条件。

（7）确定被测软件的评价准则和方法。

（8）确定测试活动的进度。应根据测试资源和测试项，确定进度。

应将测试策划结果，按所确定的文档要求形成测试计划。

测试设计和实现

应根据测试需求规格说明和测试计划进行测试设计和实现，应完成如下工作：

（1）按需要分解测试项。将需要测试的测试项进行层次化的分解并进行标识，若有接口测试，还应有高层次的接口图说明所有接口和要测试的接口。

（2）说明最终分解后的测试项。说明测试用例设计方法的具体应用、测试数据的选择依据等。

（3）设计测试用例。

（4）确定测试用例的执行顺序。

（5）准备和验证所有的测试用数据。针对测试输入要求，设计测试用的数据，如数据类型、输入方法等。

（6）准备并获取测试资源，如测试环境所必须的软、硬件资源等。

（7）必要时，编写测试执行需要的程序，如开发部件测试的驱动模块和桩模块以及测试支持软件等。

（8）建立和校核测试环境，记录校核结果，说明测试环境的偏差。

应将测试设计与实现的工作结果，按照所确定的文档要求编写测试说明，测试说明一般应包括：

（1）测试名称和项目标识。

（2）测试用例的追踪。说明测试所依据的内容来源，并跟踪到相应的测试项的标识（编号）。

（3）测试用例说明。简要描述测试的对象、目的和所采用的测试方法。

（4）测试用例的初始化要求，包括硬件配置、软件配置（包括测试的初始条件）、测试配置（如用于测试的模拟系统和测试工具）、参数设置（如测试开始前对断点、指针、控制参数和初始化数据的设置）等的初始化要求。

（5）测试用例的输入。每个测试用例输入的描述中应包括的内容：

①每个测试输入的名称、用途和具体内容（如确定的数值、状态或信号等）及其性质（如有效值、无效值、边界值等）。

②测试输入的来源（如测试程序产生、磁盘文件、通过网络接收、人工键盘输入等），以及选择输入所使用的方法（如等价类划分、边界值分析、猜错法、因果图以及功能图等）。

③测试输入是真实的还是模拟的。

④测试输入的时间顺序或事件顺序。

（6）测试用例的期望测试结果。期望测试结果应有具体内容（如确定的数值、状态或信号等），不应是不确切的概念或笼统的描述。必要时，应提供中间的期望结果。

（7）测试用例的测试结果评估准则。评估准则用以判断测试用例执行中产生的中间或最后结果是否正确。评估准则应根据不同情况提供相关信息，如：

①实际测试结果所需的精确度。

②允许的实际测试结果与期望结果之间差异的上、下限。

③时间的最大或最小间隔。

④事件数目的最大或最小值。

⑤实际测试结果不确定时，重新测试的条件。

⑥与产生测试结果有关的出错处理。

⑦其他有关准则。

（8）实施测试用例的执行步骤。编写按照执行顺序排列的一系列相对独立的步骤，执行步骤应包括：

①每一步所需的测试操作动作、测试程序输入或设备操作等。

②每一步期望的测试结果。

③每一步的评估准则。

④导致被测程序执行终止伴随的动作或指示信息。

⑤需要时，获取和分析中间结果的方法。

（9）测试用例的前提和约束。在测试用例中还应说明实施测试用例的前提条件和约束条件，如特别限制、参数偏差或异常处理等，并要说明它们对测试用例的影响。

（10）测试终止条件。说明测试用例的测试正常终止和异常终止的条件。

（11）确定测试说明与测试计划或测试需求规格说明的追踪关系，给出清晰、明确的追踪表。

（12）测试说明应经过评审，得到相关人员的认同，测试说明评审内容如下：

①测试说明是否完整、正确和规范。

②测试设计是否完整和合理。

③测试用例是否可行和充分。

测试执行

应按照测试计划和测试说明的内容和要求执行测试，主要完成下列工作：

如实填写测试记录，当结果有量值要求时，应准确记录实际的量值。

（1）测试记录应受到严格管理，并规范格式，至少包括测试用例标识、测试结果和发现的缺陷。

（2）应根据每个测试用例的期望测试结果、实际测试结果和评估准则，判定测试用例是否通过。

（3）当测试用例不通过时，应根据不同的缺陷类型，采取相应的措施：

①对测试工作中的缺陷，如测试说明的缺陷、测试数据的缺陷、执行测试步骤时的缺陷、测试环境中的缺陷等，记录到相应的表格中，并实施相应的变更。

②对被测软件的缺陷应记录到软件问题报告中。

③软件问题报告的格式应规范。

（4）当所有的测试用例都执行完毕后，实验室应根据测试的充分性要求和有关记录，分析测试工作是否充分，是否需要进行补充测试：

①当测试过程正常终止时，如果发现测试工作不足，或测试未达到预期要求时，应进行补充测试。

②当测试过程异常终止时，应记录导致终止的条件、未完成的测试或未被修正的错误。

测试总结

应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录、测试问题及变更报告和软件问题报告等，对测试工作和被测软件进行分析和评价，主要完成下列工作：

（1）对测试工作进行分析和评价，分析和评价内容应包括：

①总结测试需求规格说明、测试计划和测试说明的变化情况及其原因。

②在测试异常终止时，说明未能被测试活动充分覆盖的范围及其理由。

③确定无法解决的软件测试事件并说明不能解决的理由。

（2）对被测软件进行分析和评价，分析和评价内容应包括：

①总结测试中所反映的被测软件与软件需求（或软件设计）之间的差异。

②可能时，根据差异评价被测软件的设计与实现，提出改进的建议。

③当进行配置项测试或系统测试时，当需要时，测试总结中应对配置项或系统的性能做出评估，指明偏差、缺陷和约束条件等对于配置项或系统运行的影响。

（3）分析测评项目中的数据和文档，以供以后的测试使用。数据如：缺陷数据（包括缺陷描述、类型、严重性等）、用例数据、管理数据（如生产率、工作量、进度等）；文档如：好的用例设计、好的需求规格说明等。

（4）应根据被测软件文档、测试需求规格说明、测试计划、测试说明、测试记录和软件问题报告等有关文档，对测试结果和问题进行分类和总结，按所确定的文档要求编写测试报告。测试报告除了应包括对测试结果的分析，还应包括对被测软件的评价和建议。

测试总结评审应在测试报告编制工作完成后进行，以确定是否达到测试目的，给出评审结论。评审的具体内容和要求包括：

（1）审查测试文档与记录内容的完整性、正确性和规范性。

（2）审查测试活动的独立性和有效性。

（3）审查测试环境是否符合测试要求。

（4）审查软件测试报告与软件测试原始记录和问题报告的一致性。

（5）审查实际测试过程与测试计划和测试说明的一致性。

（6）审查测试说明评审的有效性，如是否评审了测试项选择的完整性和合理性、测试用例的可行性和充分性。

（7）审查测试结果的真实性和正确性。

分包

中标人应当按照合同约定履行义务，完成中标项目。中标人不得向他人转让中标项目，也不得将中标项目肢解后分别向他人转让。中标人按照合同约定或者经招标人同意，可以将中标项目的部分非主体、非关键性工作分包给他人完成。接受分包的人应当具备相应的资格条件，并不得再次分包。中标人应当就分包项目向招标人负责，接受分包的人就分包项目承担连带责任。

风险管理

没有绝对安全的环境，每个环境都有一定程度的漏洞和风险。风险是指某种破坏或损失发生的可能性。潜在的风险有多种形式，并且不只同计算机有关。考虑信息安全时，必须重视的几种风险有：物理破坏；人为错误；设备故障；内、外部攻击；数据误用；数据丢失；程序错误，等等。在确定威胁的时候，不能只看到那些比较直接的容易分辨的外部威胁，来自内部的各种威胁也应该引起高度重视，很多时候来自内部的威胁由于具有极大的隐蔽性和透明性导致更加难以控制和防范。

风险管理是指识别、评估、降低风险到可以接受的程度，并实施适当机制控制风险保持在此程度之内的过程。风险评估的目的是确定信息系统的安全保护等级以及信息系统在现有条件下的安全保障能力级别，进而确定信息系统的安全保护需求；风险管理则根据风险评估的结果从管理（包括策略与组织）、技术、运行三个层面采取相应的安全控制措施，提高信息系统的安全保障能力级别，使得信息系统的安全保障能力级别高于或者等于信息系统的安全保护等级。

风险分析

风险分析的方法与途径可以分为：定量分析和定性分析。定量分析是试图从数字上对安全风险进行分析评估的方法，通过定量分析可以对安全风险进行准确的分级，但实际上，定量分析所依靠的数据往往都是不可靠的，这就给分析带来了很大的困难。定性分析是被广泛采用的方法，通过列出各种威胁的清单，并对威胁的严重程度及资产的敏感程度进行分级。定性分析技术包括判断、直觉和经验，但可能由于直觉、经验的偏差而造成分析结果不准确。风险分析小组、管理者、风险分析工具、企业文化等决定了在进行风险分析时采用哪种方式或是两者的结合。风险分析的成功执行需要高级管理部门的支持和指导。管理部门需要确定风险分析的目的和范围，指定小组进行评估，并给予时间、资金的支持。风险小组应该由不同部门的人员组成，可以是管理者、程序开发人员、审计人员、系统集成人员、操作人员等。

风险评估

进行风险评估时需要决定要保护的资产及要保护的程度，对于每一个明确要保护的资产，都应该考虑到可能面临的威胁以及威胁可能造成的影响，同时对已存在的或已规划的安全管制措施进行鉴定。仅仅确定资产是不够的，对有形资产（设备、应用软件等）及人（有形资产的用户或操作者、管理者）进行分类也是非常重要的，同时要在两者之间建立起对应关系。有形资产可以通过资产的价值进行分类，如：机密级、内部访问级、共享级、未保密级。对于人员的分类类似于有形资产的分类。信息安全风险评估的复杂程度将取决于风险的复杂程度和受保护资产的敏感程度，所采用的评估措施应该与组织对信息资产风险的保护需求相一致。

控制风险

对风险进行了识别和评估后，可通过降低风险（例如安装防护措施）、避免风险、转嫁风险（例如买保险）、接受风险（基于投入／产出比考虑）等多种风险管理方式得到的结果来协助管理部门根据自身特点来制定安全策略。制定安全策略时，首先要识别当前的安全机制并评估它们的有效性。由于所面临的威胁不仅仅是病毒和攻击，对于每一种威胁类型要分别对待。在采取防护措施的时候要考虑如下一些方面：产品费用、设计／计划费用、实施费用、环境的改变、与其他防护措施的兼容性、维护需求、测试需求、修复、替换、更新费用、操作／支持费用。

石油

石油行业物联网系统主要是使用监控设备和信息系统采集运输油轮数据、码头设备和环境数据、油库数据、原油管道数据等，对这些数据进行整理和分析，将原油运输各个环节的数据进行关联和分析，合理安排船期、实现计算机排罐，提高整个原油运输的效率，同时通过对相关设备和环境的监测，及时掌握设备运行情况，保证整个运输过程的安全可靠。

石油行业物联网系统的总体解决方案包括：油库监测系统、原油管道监测系统、原油管道无人机巡线系统等。

实施阶段

项目实施阶段，监理进行进度控制的主要内容如下。

（1）按合同要求，适时发布开工令，确保按时开工，以此计算施工工期。

（2）审查和批准所有承包商、供货商按合同要求提交的各自的总进度计划及年、季、月实施进度计划，此计划必须符合项目总进度计划和里程碑计划的要求。

（3）将承包商、供货商提交的总进度计划合成为项目实施总进度计划。

（4）严格控制关键线路上的关键工序、关键的分部分项工程和单项工程的工期。

（5）定期检查施工单位的实时进度是否与原定计划相符。

（6）协调建设项目各参与方的计划安排，尽可能减少相互间的干扰，努力实现各方的均衡生产。

（7）协调和控制材料、设备按计划供货，使其与总进度计划相吻合。

（8）控制并及时处理设计变更，适时调整进度计划，严格控制和处理工期延误，督促和优化投入资源，保障里程碑计划的实现。

（9）及时组织单项工程验收，使已完成的单项工程尽早投入使用，督促下个工序能及时进行。

项目计划

项目计划阶段，监理的主要工作如下。

（1）对软件计划的相关内容（重点是组织、技术标准、开发计划和进度要求等）、项目计划过程、项目计划组织和文档格式等进行审查，确认是否满足要求。

（2）给出符合要求的结论。

（3）确定其可否作为软件开发的前提和依据。

项目计划监理的基本准则如下。

（1）承建单位制订了软件项目计划，同时该项目计划通过了正式的评审，软件项目计划对项目组织、进度计划、工程标准进行了承诺，项目的风险分析合理，风险管理方案可行。

（2）项目的阶段划分是明确的。

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

京B2-20210865 | 京ICP备2020040059号-5