学信息系统项目管理师第4版系列35_补遗

题外话：1. 计划没有变化快，10月18日软考出了通告，10月28日和29日分别是信息系统项目管理师第一批次和第二批次考试，比原先11月4日提前一周，祝贺那一批敢为人先的幸运儿。

2. 该系列也进入了尾声，补遗是正文的最后一部分，如果按照10月28日考试，也算提前一周完成更新了。之后就是结语了，预计在11月5日之后结合首次计算机考试的情况适时进行更新。

3.最后，预祝各位考生都能考出好成绩。

1. 软件质量模型

1.1. 功能性

1.1.1. 适合性

1.1.2. 准确性

1.1.3. 互操作性

1.1.4. 保密安全性

1.2. 可靠性

1.2.1. 成熟性

1.2.2. 容错性

1.2.3. 易恢复性

1.2.4. 可靠性依从性

1.3. 易用性

1.3.1. 易理解性

1.3.2. 易学性

1.3.3. 易操作性

1.3.4. 吸引性

1.3.5. 易用性依从性

1.4. 效率

1.4.1. 时间特性

1.4.2. 资源利用性

1.4.3. 效率依从性

1.5. 维护性

1.5.1. 易分析性

1.5.2. 易改变性

1.5.3. 稳定性

1.5.4. 易测试性

1.5.5. 维护性依从性

1.6. 可移植性

1.6.1. 适应性

1.6.2. 易安装性

1.6.3. 共存性

1.6.4. 易替换性

1.6.5. 可移植性依从性

1.7. 【高18下选13】

1.7.1. 【高18上选13】

2. 5 阶段的生命周期

2.1. 【高18下选03】

2.2. 系统规划阶段

2.3. 系统分析

2.3.1. 【高18上选03】

2.4. 系统设计阶段

2.5. 系统实施阶段

2.6. 系统运行和维护阶段

3. 软件研发

3.1. 系统分析阶段的任务是回答系统“做什么”

3.1.1. 系统设计阶段要回答的问题是“怎么做”

3.1.1.1. 【高22下选01】

3.1.2. 系统实施阶段是将设计的系统付诸实施的阶段

3.2. 一般使用实体联系图（E-R 图）表示数据模型，用数据流图（DataFlowDiagram, DF—D)表示功能模型，用状态转换图（State Transform Diagram, STD)表示行为模型

3.2.1. 【高20下选08】

3.2.1.1. 【高19下选07】

3.3. 原型法对于需求的响应是动态的

3.3.1. 【高22下选17】

3.3.2. 指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程,直到得出系统的“精确解”，即用户满意为止

3.3.2.1. 【高21上选02】

3.4. 面向对象

3.4.1. 面向对象的方法(OO)的应用构建在类和对象之上，随后发展起来的建模技术将相关对象按照业务功能进行分组，就形成了构件的概念

3.4.1.1. 【高22上选02】

3.4.2. 使系统的描述及信息模型的表示与客观实体相对应，符合人们的思维习惯， 有利于系统开发过程中用户与开发人员的交流和沟通，缩短开发周期

3.4.2.1. 【高20下选01】

3.4.3. 类是对象的抽象，而对象是类的具体实例

3.4.3.1. 【高19下选01】

3.4.4. 在用例图中执行者与用例之间是关联关系

3.4.4.1. 【高19上选25】

3.4.5. 对于顺序图，还可以按执行者角色、控制类、用户接口、业务层、后台数据库进行分层，由左向右分别排列

3.4.5.1. 【高19上选26】

3.4.6. 类图一般包括三个组成部分，第一个是类名；第二个是属性；第三个是该类提供的方法

3.4.6.1. 【高19上选27】

3.4.7. 面向对象的三大特征

3.4.7.1. 【高18下选26】

3.4.8. UML2.0 包括 14 种图

3.4.8.1. 【高18下选27】

3.4.8.1.1. 【高18上选27】

3.4.8.2. 一种可视化的建模语言

3.4.8.2.1. 【高18上选26】

3.4.9. 消息( Message)是对象间的交互手段

3.4.9.1. 【高18上选25】

3.4.10. 常用的 OOD 原则包括：

（1）单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。 （2）开闭原则：对扩展开放，对修改封闭。 （3）李氏替换原则：子类可以替换父类。 （4）依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。 （5）接口隔离原则：使用多个专门的接口比使用单一的总接口要好。 （6）组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。 （7）迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低 耦合原则是一致的。

3.4.10.1. 【高23上选09】

3.5. 结构化开发方法(SA)

3.5.1. 其建立的模型的核心是数据字典，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)

3.5.1.1. 【高22上选09】

3.6. B/S 架构， 也就是基于 Web 的架构

3.6.1. 【高21下选17】

3.7. 根据处理范围不同，设计模式可分为类模式和对象模式

3.7.1. 【高18下选08】

3.8. 调用/返回风格：调用/返回风格包括主程序/子程序、数据抽象和面向对象，以及层次结构

3.8.1. 【高19上选07】

3.9. 独立构件风格：独立构件风格包括进程通信和事件驱动的系统。

3.9.1. 【高18上选07】

4. 测试管理

4.1. 测试管理是为了实现测试工作预期目标，以测试人员为中心，对测试生命周期及其所涉及的相应资源进行有效的计划、组织、领导和控制的协调活动

4.1.1. 【高22下选61】

4.2. 测试监控

4.2.1. 目的

4.2.1.1. 为测试活动提供反馈信息和可视性

4.2.2. 内容

4.2.2.1. 测试用例执行的进度

4.2.2.2. 缺陷的存活时间

4.2.2.3. 缺陷的趋势分析

4.2.2.4. 缺陷分布密度

4.2.2.5. 缺陷修改质量

4.2.2.6. 【高22上选60】

4.3. Alpha 测试是指由用户在开发环境下进行测试

4.3.1. 【高21上选11】

4.4. Beta 测试是指由用户在实际使用环境下进行测试

4.4.1. 在通过 Beta 测试后，才能把产品发布或交付给用户

4.5. 白盒测试也称为结构测试，主要用于检测软件编码过程中的错误

4.6. 黑盒测试又称为功能测试，主要检测软件的每一个功能是否能够正常使用

4.6.1. 【高19下选09】

4.7. 执行效率、缺陷发现率是测试执行中的工作效率相关指标

4.7.1. 【高21上选61】

4.7.2. 缺陷发现率=Σ缺陷数(系统测试)(个)÷Σ执行系统测试的有效时间(小时）

4.7.2.1. 【高20下选61】

4.7.3. 测试进度

4.7.3.1. 【高19下选61】

4.7.3.2. 进度偏离度

4.7.3.2.1. 【高19上选62】

4.8. 由开发组织实施的软件测试，应将测试工作产品纳入软件项目的配置管理；由独立测试组织实施的软件测试，应建立配置管理库，将被测试对象和测试工作产品纳入配置管理

4.8.1. 【高18上选10】

4.9. 预计就是趋势

4.9.1. 【高18上选62】

4.10. 【高20下案三】

5. 可用性战术

5.1. 错误检测：用于错误检测的战术包括命令/响应、心跳和异常

5.2. 错误恢复：用于错误恢复的战术包括表决、主动冗余、被动冗余

5.3. 错误预防：用于错误预防的战术包括把可能出错的组件从服务中删除、引入进程监视器

5.3.1. 【高21下选04】

6. 测试主要的风险

6.1. 【高18下选63】

6.2. ①需求风险。对软件需求理解不准确，导致测试范围存在误差，遗漏部分需求或者执行了错误的测试方式：另外需求变更导致测试用例变更，同步时存在误差。

6.3. ②测试用例风险。测试用例设计不完整，忽视了边界条件、异常处理等情况，用例没有完全覆盖需求；测试用例没有得到全部执行，有些用例被有意或者无意的遗漏。

6.4. ③缺陷风险。某些缺陷偶发，难以重现，容易被遗漏。

6.5. ④代码质量风险。软件代码质量差，导致缺陷较多，容易出现测试的遗漏。

6.6. ⑤测试环境风险。有些情况下测试环境与生产环境不能完全一致，导致测试结果存在误差。

6.6.1. 【高21下选61】

6.7. ⑥测试技术风险。某些项目存在技术难度，测试能力和水平导致测试进展缓慢，项目延期。

6.8. ⑦回归测试风险。回归测试一般不运行全部测试用例，可能存在测试不完全。

6.9. ⑧沟通协调风险。测试过程中涉及的角色较多，存在不同人员、角色之间的沟通、协作，难免存在误解、沟通不畅的情况，导致项目延期。

7. 软件测试

7.1. 软件测试从已知的条件开始,有预知的结果

7.1.1. 【高20下选10】

7.1.2. 软件测试过程可以事先设计,进度可以事先确定

7.2. 国家标准 GB/T15532—2008

7.3. 软件测试分单元测试、集成测试、确认测试、系统测试、配置项测试和回归测试等

7.3.1. 【高18下选10】

7.4. 单元测试

7.4.1. 模块测试

7.4.2. 技术依据是软件详细设计说明

7.5. 集成测试

7.5.1. 技术依据是软件概要设计文档

7.5.2. 检查模块之间，以及模块和已集成的软件之间的接口关系，并验证己集成的软件是否符合设计要求

7.6. 确认测试

7.6.1. 用于验证软件的功能、性能和其他特性是否与用户需求一致

7.6.2. 用户的参与程度划分

7.6.2.1. 内部确认测试

7.6.2.1.1. 软件开发组织内部按照 SRS 进行测试

7.6.2.2. Alpha 测试和 Beta 测试

7.6.2.3. 验收测试

7.6.2.3.1. 针对 SRS,在交付前以用户为主进行的测试

7.7. 系统测试

7.7.1. 真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求

7.8. 配置项测试

7.8.1. 检验软件配置项与 SRS 的一致性

7.9. 回归测试

7.9.1. 【高22下选08】

7.9.2. 测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性

7.10. 对代码的静态测试一般采用桌前检查、代码走查和代码审查

7.10.1. 【高21下选11】

7.10.1.1. 【高18上选09】

7.10.1.2. 【高19上选09】

7.11. V 模型

7.11.1. 主要思想是开发和测试同等重要

7.11.2. 针对每个开发阶段，都有一个测试级别与之相对应

7.11.3. 测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应

7.11.4. 适用于需求明确和需求变更不频繁的情形

7.11.4.1. 【高18上选32】

8. 系统相关

8.1. 业务需求反映客户高层次的目标要求，通常由项目投资人、客户提出

8.1.1. 【高19上选10】

8.1.1.1. 【高18下选07】

8.2. 系统规划是立项阶段的

8.2.1. 【高19上选03】

8.3. 面向服务方法

8.3.1. 【高18下选28】

8.3.2. 关注的是业务，以业务驱动技术，强调 IT 与业务的对齐，以开放标准封装业务流程和已有的应用系统，实现应用系统之间的相互访问。

8.3.2.1. 【高21下选02】

8.4. 数据流风格

8.4.1. 【高21下选09】

8.5. 控制集成可能需要添加附加的代码来实现控制集成与表示集成、数据集成相比，灵活性更高

8.5.1. 【高21下选12】

8.6. 控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。控制集成的集成点存于程序代码中，集成处可能只需简单使用公开的 API(应用程序编程接口)就可以访问，当然也可能需要添加附加的代码来实现。控制集成是黑盒集成

8.6.1. 【高18上选11】

8.7. 控制集成也称为功能集成或应用集成，是在业务逻辑层上对应用系统进行集成的。

8.7.1. 【高19上选11】

8.8. 表示集成通常应用于以下几种情况

8.8.1. 在现有的基于终端的应用系统上配置基于 PC (Personal Computer， 个人计算机)的用户界面

8.8.2. 为用户提供一个看上去统一，但是由多个系统组成的应用系统

8.8.2.1. 【高21上选12】

8.8.2.1.1. 【高19下选10】

8.8.3. 当只有可能在显示界面上实现集成时

8.9. 业务流程集成也称为过程集成，这种集成超越了数据和系统，它由一系列基于标准 的、统一数据格式的工作流组成

8.9.1. 【高20下选11】

8.10. 计算机系统的可用性用平均无故障时间（MTIF)来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障

8.10.1. 【高18下选22】

8.11. 负载均衡设备的主要功能扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性

8.11.1. 【高22下选02】

8.11.2. 负载均衡服务器通过某种调度算法将流量分配到不同的应用程序服务器

8.11.3. 可以实现服务高可用性、数据安全监控、弹性业务伸缩、实现流量均衡

8.12. IT 审计的目的是指通过开展 IT 审计工作，了解组织 IT 系统与 IT 活动的总体状况，对组织是否实现 IT 目标进行审查和评价，充分识别与评估相关 IT 风险，提出评价意见及改进建议，促进组织实现 IT 目标

8.12.1. 【高23上选06】

9. 人力资源管理

9.1. 发生人员的变更

9.1.1. 【高22上选41】

9.2. 人事评测工具能让项目经理和项目团队洞察成员的优势和劣势。这些工具可帮助项目经理评估团队成负的偏好和愿望，团队成员如何处理和整理信息，团队成员如何制订决策，以及团队成员喜欢如何与人打交道

9.3. 人力资源管理的过程

9.3.1. 【高18下选49】

10. 战略管理

10.1. 组织战略

10.1.1. 【高21下选57】

10.1.2. 防御者（Defender）战略

10.1.2.1. 【高22下选57】

10.1.2.2. 相对成熟行业中的成熟组织，组织内部产品线较窄，同时组织高层也不愿意积极探索熟知领域以外的机会

10.1.3. 探索者（Prospector）战略

10.1.3.1. 致力于组织发现和发掘新产品、新技术和新市场可能为组织提供的发展机会

10.1.3.2. 组织的核心技能是市场能力和研发能力，它可以拥有较多的技术类型和较长的产品线，同时也可能会面临较大的风险

10.1.4. 分析者（Analyser）战略

10.1.4.1. 保证组织在规避风险的同时，又能够提供创新产品和服务

10.1.4.2. 应用于两种市场有效运作的组织类型

10.1.4.2.1. 在较稳定的环境

10.1.4.2.2. 变化较快的环境

10.1.5. 反应者（Reactor）战略

10.1.5.1. 对外部环境缺乏控制，不敏感的组织类型，它既缺乏适应外部竞争的能力，又缺乏有效的内部控制机能

10.2. 战略管理

10.2.1. 【高22下选74】

10.3. 系统规划依据企业的战略目标进行

10.3.1. 【高22上选15】

10.4. 平衡计分卡（BSC）

10.4.1. 一种绩效评价体系

10.4.2. 从财务、客户、内部运营、学习和成长四个角度

10.4.2.1. 【高22上选56】

10.5. BPR 流程再造与优化

10.5.1. 【高21下选58】

10.5.2. 业务流程图。TFD 是分析和描述现有系统的传统工具，是业务流程调查结果的图形化表示

10.5.2.1. 【高20下选58】

10.6. 合作型组织战略模式克服了指挥型模式和变革型模式存在的局限性，使组织高层能够接近一线管理人员获得比较准确的信息

10.6.1. 【高21上选57】

10.7. 文化型战略组织模式。这种组织战略模式的特点是组织高层是从如何动员全体成员都参与战略实施活动的角度来考虑战略的制定和执行。

10.7.1. 【高20下选57】

10.7.1.1. 【高19上选55】

10.8. 企业战略管理包括战略制订、战略执行、战略控制等过程

10.8.1. 企业战略规划是科学评价企业面临的现状、未来的发展环境和空间，进而确定企业发展的总体和长远目标，制定各个阶段目标以及行动方案

10.8.1.1. 【高19下选23】

10.9. 企业资质是不能共享的

10.9.1. 【高19下选54】

10.10. 摒弃“以企业为中心”的传统管理模式，代之以现代战略合作的管理模式

10.10.1. 【高18上选53】

10.11. 战略实施能力。组织战略实施能力是组织战略实施的物质基础。这种物质基础既可以是组织自身拥有的，也有可能是组织外部的，但可以被组织通过协商获得的资源，根据组织战略目的和战略方针的要求，确定战略的规模、发展方向和重点，并能够与组织的总体力量保持协调发展

10.11.1. 【高18上选55】

10.12. 增值性分析。利用模型的对象属性尤其是活动的价值系数分析流程的运营合理性和潜在问题。该分析方法可用于对现有业务流程建模和业务流程实施后的效果进行分析

10.12.1. 【高18上选56】

11. 其他

11.1. 从项目管理的角度来看，探索阶段有三个关键的活动域

11.1.1. 通过管理工作量和使用适当的技术方法和风险降低策略，交付计划的功能

11.1.1.1. 【高22下选58】

11.1.2. 建立协作的、自我组织的项目团队，这是每个人的责任，但需要由项目经理推动

11.1.3. 管理团队与客户、产品经理和其他项目干系人的相互交流

11.2. 问题管理求进行根本原因调查，以确定什么原因导致了确定的趋势

11.2.1. 【高19下选71】

11.3. 服务转换为在受支持的环境中引入新的及已更改的服务能力的开发及改进提供指导

11.3.1. 【高19下选72】