【信息系统项目管理师】18年~23年案例概念型知识

18上

请简述 ISO 9000 质量管理的原则
领导作用、 过程方法、 管理的系统方法、 与供方互利的关系、 基于事实的决策方法、 持续改进、 全员参与、 以顾客为关注焦点

概念
国家标准(GB/T 1 9000 2008)对质量的定义为:一组固有特性满足要求的程度。

质量管理是指确定质量方针、 目标和职责， 并通过质量体系中的质量管理过程来使其实现所有管理职能的全部活动。

在质量管理的技术和工具中，流程图用来显示在一个或多个输入转化成一个或多个输出的过程中， 所需要的步骤顺序和可能分支:帕累托图用于识别造成大多数问题的少数重要原因： 散点图可以显示两个变量之间是否有关系， 一条斜线上的数据点距离越近， 两个变量之间的相关性越密切。

采用虚拟团队形式的利与弊
虚拟团队的利：
1 、 在组织内部地处不同地理位置的员工之间组建团队。
2、 为项目团队增加特殊技能， 即使相应的专家不在同一地理区域。
3、 将在家办公的员工纳入团队。
4、 在工作班次、 工作小时或工作日不同的员工之间组建团队。
5、 将行动不便者或残疾人纳入团队。
6、 执行那些原本会因差旅费用过高而被否决的项目。
虚拟团队的弊：
可能产生误解， 有孤立感， 团队成员之间难以分享知识和经验， 采用通信技术的成本。

18下

将整个项目分解为工作包， 需要开展哪些主要活动
1、 识别和分折可交何成果及相关工作。
2、 确市 WBS 的结构和编排方法。
3、 自上而下逐层细化分解。
4、 为 WBS 组件制定和分配标识编码。
5、 核实可交付成果分解的程度是否恰当。

概念
项目活动之间的依赖关系分为四种：

1.强制性依赖关系是法律或合同要求的或工作的内在性质决定的依赖关系。
2.选择性依赖关系是基于具体应用领域的最佳实践或者基于项目的某种特殊性质而设定， 即便还有其他顺序可以选用， 但项目团队仍缺省按照此种特殊的顺序安排活动。
3.外部依赖关系是项目活动与非项目活动之间的依赖关系。
4.内部依赖关系是项目活动之间的紧前关系， 通常在项目团队的控制之中。

请简述项目管理、 项目集管理和项目组合管理的概念。
项目管理综合应用知识、 过程、 技能、 工具以及技术来对项目活动进行管理， 以便满足项目需求。

项目集管理综合应用知识、 过程、 技能、 工具以及技术来对其所包含的项目进行管理， 以便满足项目集的需求， 并能获取采用单一项目管理方式所达不到的收益和控制。

项目组合管理是对一组或者多组项目集进行管理， 以达成组织的战略目标。

19上

请说明采购管理的主要步骤
项目采购管理的主要过程包括编制采购计划、 实施采购、 控制采购、 结束采购等4 个过程， 细化来讲包含如下步骤：

1. 需求确定与采购计划的制订
2. 供应商的搜寻与分析
3. 定价
4. 拟定并发出定单
5. 定单的跟踪和跟催
6. 验收和收货
7. 开票和支付货款
8. 记录管理

请简述采购货物入库的三个条件
采购产品验证完毕后， 检验合格的产品，《进货检验记录单》 作为办理入库的条件之一。

库房核对采购设备对应项目准确无误， 作为办理入库条件之二。

供应商提供的运货单或者到货证明， 作为办理入库条件之三。

概念
供应商选择的三大主要因素是供应商的产品价格、质量、 和服务。

经进货验证确定为不合格的产品， 应采取的处理包括退货、调换 和降级改作他用（需主管领导批准， 并在相关部门备案）。

采购需求通常包括标的物的配置、， 性能， 数量、 服务等， 其中配置 和性能最为关键。

团队成员发生冲突后， 有哪些冲突解决办法
撤退/回避。 从实际或潜在冲突中退出， 将问题推迟到准备充分的时候， 或者将问题推给其他人员解决。
缓和/包容。 强调一致、 淡化分歧(甚至否认冲突的存在) ； 为维持和谐与关系而单方面退让一步。
妥协/调解。为了暂时或部分解决冲突， 寻找能让各方都在一定程度上满意的方案。
强迫/命令。 以牺牲其他方为代价， 推行某一方的观点； 只提供赢输方案。 通常是利用权力来强行解决紧急问题。
合作/解决问题。 综合考虑不同的观点和意见， 采用合作的态度和开放式对话引导各方达成共识和承诺。 这是冲突双方最理想的结果。

19下

帕累托分析原理
帕累托图来自于 80/20 定律， 该定律认为大多数的问题或缺陷产生于相对有限的原因， 即 20%的原因造成了 80%的问题。

一致性成本和非一致性成本的定义
一致性成本： 在项目期间用于防止失败的费用；非一致性成本： 项目期间和项目完成后用于处理失败的费用

管理者的权利来源
职位 权力
惩罚权力
奖励 权力
专家 权力
参照 权力

20上

无考试

20下

范围说明书的内容和作用
范围说明书的内容：
（1） 产品范围描述
（2） 验收标准
（3） 可交付成果
（4） 项目的除外责任
（5） 制约因素
（6） 假设条件
范围说明书的作用：
（1） 确定范围
（2） 沟通基础
（3） 规划和控制依据
（4） 变更基础
（5） 规划基础

需求变更过程中需要完成的具体工作内容
（1） 接受（受理或响应） 需求变更申请；
（2） 变更初审；
（3） 变更影响分析， 制定应对方案， 将需求由技术要求转化为资源需求；
（4） CCB 审查；
（5） 发生变更通知并组织实施变更；
（6） 变更实施监控；
（7） 变更效果评估；
（8） 判断发生需求变更后的项目是否已纳入正常轨道。

概念
（1） 在每个项目任务的分解单元中都存在可交付成果和里程碑 ， 标志着某个可交付成果或阶段的正式完成。
（2） 创建WBS是将项目的可交付成果和项目工作分解为较小的、 更易管理的组件的过程， 其主要作用是对所要交付的内容提供一个结构化的视图。 其最底层的可交付成果或项目工作组成部分称为工作包。
（3） 项目干系人提出变更申请后， 一般由项目经理或项目配置管理员进行初审。

黑盒测试、 白盒测试和灰盒测试， 请阐述三种测试的含义和用途
黑盒测试： 黑盒测试也称为功能测试， 主要用于集成测试、 确认测试和系统测试中。 黑盒测试将程序看作是一个不透明的黑盒， 完全不考虑（或不了解） 程序的内部结构和处理算法， 而只检查程序功能是否能按照 SRS 的要求正常使用， 程序是否能适当地接收输入数据并产生正确的输出信息， 程序运行过程中能否保持外部信息的完整性等。

白盒测试： 白盒测试也称为结构测试， 主要用于软件单元测试中。 它的主要思想是， 将程序看作是一个透明的白盒， 测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例， 检测程序中的主要执行通路是否都能按预定要求正确工作。

灰盒测试： 介于白盒测试与黑盒测试之间的测试。 灰盒测试关注输出对于输入的正确性， 同时也关注内部表现。 灰盒测试是基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例， 执行程序并采集程序路径执行信息和外部用户接口结果的测试技术。

测试方案
（1） 测试目的： 在真实系统工作环境下， 检验完整的软件配置项能否和系统正确连接， 并发现软件与系统设计文档或软件开发合同规定不符合或与之矛盾的地方。 而且， 还要检验系统的文档等是否完整、 有效； （2 分）
（2） 测试对象： 系统的软件及其各种依赖的资源； （1 分）
（3） 测试内容： 功能测试、 压力测试、 安全性测试、 容错测试、 恢复性测试；（2 分）
（4） 测试过程： 测试计划， 测试设计、 测试实施、 测试执行、 测试评估；（2 分）
（5） 测试用例设计依据： 需求规格说明书（1 分）
（6） 测试技术： 黑合测试、 白盒测试（2 分）

21上

概念
风险按可预测性可以分为已知风险、 可预测风险和不可预测风险， 为了预防原材料价格波动， 提前储备了一批原材料， 结果原材料价格出现了下跌。 该风险属于已知风险。

21下

WBS分解时， 需要注意的事项
1、 WBS必须是面向可交付成果的。 项目的目标是提供产品或服务， 仅仅是一连串特别的活动。
2、 WBS必须符合项目的范围。 WBS必须包括， 也仅包括为了完成项目的可交付成果的活动。 100%原则， 要分解全面不能遗漏
3、 WBS的底层应该支持计划和控制。 WBS是项目管理计划和项目范围之间的桥梁， WBS的底层不但要支持项目管理计划， 而且要让管理层能够监视和控制项目的进度和预算。
4、 WBS中的元素必须有人负责， 而且只由一个人负责， 尽管实际上可能需要多个人参与
5、 WBS的指导。 作为指导而不是原则， WBS应控制在4-6层。 当然， 大项目可以超过6层。 一个工作单元只能从属于某个上层单元， 避免交叉从属。
6、 WBS应包括项目管理工作,也要包括分包出去的工作。
7、 WBS的编制需要所有（主要） 项目干系人的参与， 需要项目团队成员的参与。
8、 WBS并非是一成不变的。 在完成了WBS之后的工作中,仍然有可能需要对WBS进行修改。

范围说明书的内容
(1） 产品范围描述
(2） 验收标准
(3） 可交付成果
(4） 项目的除外责任
(5） 项目的制约因素
(6） 假设条件

概念
项目范围是否完成要以范围基准 来衡量， 包括WBS,WBS字典,范围说明书

配置库变更控制流程
(1） 将待升级的基线从产品库中取出， 放入受控库。
(2） 程序员将欲修改的代码段从受控库中检出（cheekout） ， 放入自己的开发库中进行修改。 代码被Checkout后即被“锁定”， 以保证同一段代码只能同时被一个程序员修改， 如果甲正对其修改， 乙就无法Checkout。
(3） 程序员将开发库中修改好的代码段检入（Checkin） 受控库。 Cheekin后， 代码的“锁定”被解除， 其他程序员可以Checkout该段代码了。
(4） 软件产品的升级修改工作全部完成后， 将受控库中的新基线存入产品库中

质量审计的目标
1． 识别全部正在实施的良好/最佳实践；
2、 识别全部差距/不足；
3、 分享所在组织和/或行业中类似项目的良好实践；
4、 积极、 主动地提供协助， 以改进过程的执行， 从而帮助团队提高生产效率；
5、 强调每次审计都应对组织经验教训的积累作出贡献。

22年上

范围确认和质量确认的不同点
检查内容：

确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求(质量标准)。

检查的时间点：

质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段未进行

执行人员：

质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人(客户或发起人)对项目可交付成果进行检查验收。

详略程度：

核实产品、确认范围和质量控制是递进的、越来越细的检查过程。

项目变更的决策机构，并坚持其成员和职责
项目变更的决策机构是CCB(或变更控制委员会)

成员：公司高层、项目经理、甲方负责人、配置管理负责人、质量保证负责人、测试负责人。

项目经理：响应变更提出者的要求，评估变更对项目的影响及应对方案，将要求由技术要求转化为资源需求，供授权人决策；并据评审结果实施即调整项目基准，确保项目基准反映项目实施情况。

公司高层与甲方负责人：根据项目经理提供的影响评估及应对方案来决定是否实施变更。

配置管理员：把变更过程的相关产物更新到配置管理系统中。

项目变更应开展哪些工作
1.提出与接受变更申请

2.对变更的初审

3.变更方案论证

4.项目管理委员会审查

5.发出变更通知并组织实施

6.变更实施的监控

7.变更效果的评估

8.判断发生变更后的项目是否已纳入正常轨道

pkl技术采用双密钥双证书机制请简述双密钥证书生成的过程
(1)用户使用客户端产生签名密钥对。

(2)用户的签名私钥保存在客户端。

(3)用户将签名密钥对的公钥传送给CA中心。

(4) CA中心为用户的公钥签名,产生签名证书。

(5) CA中心将签名证书传回客户端进行保存。

(6) KMC (密钥管理中心)为用户生成加密密钥对。

(7)在KMC中备份加密密钥以备以后进行密钥恢复。

(8) CA中心为加密密钥对生成加密证书。

(9) CA中心将用户的加密私钥和加密证书打包成标准格式PKCS#12。

(10)将打包后的文件传回客户端。

(11)用户的客户端装入加密公钥证书和加密私钥。
概念
SWOT技术从项目的每个优势、劣势、机会和威胁出发，对项目进行考察，把产生与内部的风险都包含在内，从而更全面的考虑风险

22年下

项目建议书的内容 说明项目建议书的作用

常用的沟通方法一般分为几类
交互式沟通、拉式沟通、推式沟通

23年上

团队成员选择的多标准
经验、可用性、知识、技能、态度、成本、能力、国际因素

进度跟进措施
1.赶工，投入更多的资源或增加工作时间，以缩短关键活动的工期

增加资源有可能导致产生额外的问题并且降低效率，也可能由于经常加班，造成员工心理问题。（成本超支时不可用）

2.使用高素质的资源或经验更丰富的人员

3.改进方法或技术，以提高生产效率

4.快速跟进，并行施工，以缩短关键路径的长度

可能出现质量问题，造成返工

5.加强质量管理，及时发现问题，减少返工，从而缩短工期

6.缩小活动范围或降低活动要求

需要客户同意

制定数据元标准的步骤
(1)描述

(2)界定业务范围

(3)开展业务流程分析与信息建模

(4)借助信息模型，提取数据元，并按照一定的规则规范其属性

(5)对于代码型的数据元，编制其值域，即代码表

(6)与现有的国家标准或行业标准进行协调

(7)发布实施数据元标准并建立相应的动态维护管理机制

十四五规划中，数字产业化发展重点
云计算、大数据、物联网、工业互联网、区块链、人工智能、虚拟现实和增强现实