攻克高分值（坦克级）知识点 通过分析、统计历次集成考试的考点可以发现， 该考试中会频繁考查一些知识点，且这些知识点在 考核上具有高分值、高频率的特点。我们将这些知 识点放在《攻克高分值（坦克级）知识点》中进行 集中讲解。该部分中，我们使用坦克图标标识这类 知识点。
坦 克 级
A 区：信息化基础（暂无高分值知识点）
▲图 A-0-1 信息化基础知识据点图（考点分布） A 区为信息化基础知识区，具体知识点分布的据点图如图 A-0-1 所示。坦 克 级
B 区：信息化服务与管理（暂无高分值知识点）
▲图 B-0-1 信息化服务与管理知识据点图（考点分布） B 区为信息化服务与管理知识区，具体知识点分布的据点图如图 B-0-1 所示。坦 克 级
C 区：软件专业技术知识
▲图 C-0-1 软件专业技术知识据点图（考点分布） C 区为软件专业技术知识区，具体知识点分布的据点图如图 C-0-1 所示。坦 克 级
1
卡片编号 C01-1： 生命周期模型与开发方法
在系统集成项目管理工程师考试中，生命周期模型与开发方法涉及历年考题分值累计达 32 分。其中，上午分值 29 分，下午分值 3 分。该知识点属于坦克级（高分值）的知识点。 第 1 步：自我检测 本小节给出 2 道习题，用于测试对该知识的掌握程度。
习题 1： 从信息系统开发的角度来看，信息系统的生命周期包括 （1） 。 （1）A．立项，开发，运维，消亡 B．启动，计划，执行，控制和收尾 C．总体规划，系统分析，系统设计，系统实验，系统验收 D．招标，投标，执行合同，合同收尾
习题 2： 用户需求在项目开始时定义不清，开发过程密切依赖用户的良好配合，动态响应用户的需求， 通过反复修改来实现用户的最终系统需求，这是 （2） 的主要特点。 （2）A．蒙特卡洛法 B．原型法 C．面向对象方法 D．头脑风暴法 第 2 步：学习卡片 为了方便读者们快速学习和复习，我们将本小节的重要知识点浓缩在 2 张学习卡片中，具体如 图 C-1-1 和图 C-1-2 所示。坦 克 级 图 C-1-1 学习卡片 1 图 C-1-2 学习卡片 2 第 3 步：知识讲解 本节中，我们将详细阐述卡片提到的重要知识点。
坦 克 级 考点 1：信息系统生命周期 从信息系统开发的角度来看，信息系统的生命周期包括：立项、开发、运维、消亡四个阶段。 （1）立项阶段：即需求阶段，是形成概念、需求分析的过程。需求分析是指对要解决的问题 进行详细的分析，弄清项目发起人及其他干系人的要求，即确定待开发信息系统要“做什么”。 （2）开发阶段：开发阶段可以细分为总体规划、分析、设计、实施、验收几个子阶段，具体 如图 C-1-3 所示。 图 C-1-3 开发阶段细分 总体规划子阶段：本阶段是最为重要的一个开发阶段。目标是制定出信息系统的长期 发展方案，提出可行性研究报告，指导生命周期内的开发。 分析子阶段：提供逻辑模型，该阶段应该分析功能、内容、业务流程、数据，得到系 统的初步方案。 设计子阶段：根据分析得出具体实施方案。 实施子阶段：根据设计得出具体实现。该阶段工作量最大。 验收子阶段：依据一定标准对工作成果进行验证。 （3）运维阶段：系统交付用户，进入运维阶段。 （4）消亡阶段。 考点 2：三种开发方法 开发方法是在开发过程中使用的方法。常用的信息系统开发方法有结构化方法、原型法和面向 对象方法。 1．结构化方法 结构化方法把系统开发分为若干阶段。相邻两阶段中，前阶段是后阶段的工作前提。结构化方 法的主要特点是： 用户至上原则，用户必须参与系统建设各阶段的工作。 严格区分工作阶段，每个阶段都有明确任务和成果。 强调系统整体性和开发过程顺序，开发过程工程化。 文档资料标准化。 结构化方法的主要原则有：“用户全程参与”、“先逻辑，后物理”、“自顶向下”、“工作成果描 述标准化”原则。结构化方法的主要应用有面向数据流的分析方法。 2．原型法（又称快速原型法） 一般来说，用户需求较难把握，因此可以使用“原型”来捕获用户的需求。原型法获取基本的 需求，快速构建原型，通过用户试用、补充、修改而构成新系统。反复这一过程，形成最终系统。 原型法用于解决需求不明确的情况。
坦 克 级 原型特点： 原型开发实际可行。 具有最终系统基本特征。 构造快速、廉价。 原型还可以分为演化式和抛弃式两种。 （1）演化式原型：原型的构造从目标系统的部分基本需求出发，通过修改和完善功能的过程 逐渐演化成最终的目标系统。 （2）抛弃式原型：在真正捕获用户的需求后就放弃不用的原型。 3．面向对象方法 把面向对象思想应用到软件开发中，简称 OO 方法。该方法分为分析、设计、实现三个阶段。 考点 3：软件开发生命周期模型 软件开发模型把软件开发分为多个过程，常用的软件开发模型有四种。 （1）瀑布模型 结构化方法常采用瀑布模型，具体如图 C-1-4 所示。 图 C-1-4 瀑布模型 瀑布模型优缺点如下： 优点：阶段划分次序清晰，各阶段人员的职责规范、明确，便于前后活动的衔接，有利于活动 重用和管理。 缺点：太理想，不灵活，无法解决需求不明确或不准确的问题。 （2）螺旋模型 螺旋模型指导的软件开发是通过不断发布新的增量，逐步形成完善的版本的过程。螺旋模型强 调风险分析。螺旋模型具体如图 C-1-5 所示。
坦 克 级 图 C-1-5 螺旋模型 （3）喷泉模型 喷泉模型（Fountain Model）是一种以用户需求为动力，以对象为驱动的模型。该模型认为软 件开发过程是自下而上的，周期中各阶段是相互重叠和多 次反复的，就像水喷上去又可以落下来，类似一个喷泉。 具体如图 C-1-6 所示。 喷泉模型没有特定阶段，各阶段可同步开发。喷泉模 型适用面向对象的软件开发方法。该模型给出了面向对象 软件开发的框架，描述面向对象开发的两个主要特点： 迭代性：每个阶段都执行一次传统的、完整的串 行过程，其中都包括不同比例的需求分析、设计、 编码和测试等活动。各活动会重复多次，每次迭代将加入新功能。 连续性：分析、设计、编码等阶段没有明确的界限。 （4）RUP 模型
软件统一过程（RUP，Rational Unified Process）也是具有迭代特点的模型。依据时间顺序 RUP 生命周期分为 4 个阶段：
初始阶段（Inception）：确定项目边界，关注业务与需求风险。
细化阶段（Elaboration）：分析项目，构建软件结构、计划。该阶段应确保软件结构、需求、 计划已经稳定；项目风险低，预期能完成项目；软件结构风险已经解决。
坦 克 级 构建阶段（Construction）：构件与应用集成为产品，并通过详细测试。 交付阶段（Transition）：确保最终用户可使用该软件。 （5）V 模型 V 模型又称测试驱动模型，反映开发过程与测试过程的关系。关于 V 模型将在“软件测试” 部分详细阐述。 考点 4：其他考点 1．其他相关概念
逆向工程（Reverse Engineering）：根据已有的东西，推导出具体的实现。例如通过 EXE 程序， 通过反汇编、反编译推导出源代码。逆向软件工程的目的是使软件得以维护。 重构（Refactoring）：不改变软件现有功能，只调整程序代码就可改善软件的质量、性能，使 其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。 软件复用（Software Reuse）：利用已有软件成分构造新软件组成。 2．管理信息系统的图表表示 管理信息系统的开发过程中用到很多图表，对这些图表进行有规则的编号，可以方便图表的查 找。在规划图表编号时，编号一般采用分类结构。通过分析图表编号，就可以知道该图表处于系统 开发周期的哪一阶段、属于哪类文档及该文档的哪一部分。 建议的编号方式如图 C-1-7 所示。 图 C-1-7 管理信息系统的图表表示 第 4 步：效果评估 ● 管理信息系统建设的结构化方法中，用户参与的原则是，用户必须参与 （1） 。 （1）A．系统建设中的各阶段工作 B．系统分析工作 C．系统设计工作 D．系统实施工作 ● 典型的信息系统项目开发的过程为：需求分析、概要设计、详细设计、程序设计、调试与 测试、系统安装与部署。 （2） 阶段拟定了系统的目标、范围和要求。 （2）A．概要设计 B．需求分析 C．详细设计 D．程序设计
坦 克 级 ● 常用的信息系统开发方法中，不包括 （3） 。 （3）A．结构化方法 B．关系方法 C．原型法 D．面向对象方法 ● 原型化开发方法强调开发系统的原型，关于原型的特点，下面说法不正确的是 （4） 。 （4）A．原型的开发应该是实际可行的 B．原型应具有最终系统的基本特征 C．原型应构造方便，快速，造价低 D．原型的功能和性能不能低于最终的目标系统 习题 5： 小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人手紧张， 让他作为项目经理独自管理一个类似的项目，他使用瀑布模型来管理该项目的全生命周期，如图 C-1-8 所示。 图 C-1-8 习题图 项目进行到实施阶段，小赵发现在系统定义阶段所制订的项目计划估计不准，实施阶段有许多 原先没有估计到的任务现在都冒了出来。项目工期因而一再延期，成本也一直超出。 【问题】 （1）请简要叙述瀑布模型的优缺点。 （2）请简要叙述其他模型如何弥补瀑布模型的不足。 经过本次学习，您得到该知识点分值的概率大大增加，为通过考试奠定了坚实的基础。建议三 天内在可利用的碎片时间，使用学习卡片来帮助您复习巩固。 1．自我检测参考答案 题号 1 2 参考答案 A B
坦 克 级 2．效果评估参考答案 题号 1 2 3 4 参考答案 A B B D 习题 5 参考答案 （1）瀑布模型优点：阶段划分次序清晰，各阶段人员的职责规范、明确，便于前后活动的衔 接，有利于活动重用和管理。 瀑布模型缺点：过于理想的线性开发模式，缺乏灵活性、缺乏风险分析，无法解决需求不明确 或不准确的问题。 （2）原型化模型（演化模型）：用于解决需求不明确的情况。 螺旋模型：强调风险分析，特别适合庞大而复杂的、高风险的系统。
2
卡片编号 C01-8： 软件工程标准
在系统集成项目管理工程师考试中，软件工程标准涉及历年考题分值累计达 32 分。其 中，上午分值 29 分，下午分值 3 分。该知识点属于坦克级（高分值）的知识点。 “软件工程标准”属于软件专业技术知识域中的重点和难点，涉及到的相关标准有 10 余种。 考 试主要考 查的标准 有《软件 工程产品 质量 第 1 部 分 GB/T16260》、《软 件文档管 理指南 GB/T16680》、《计算机软件质量保证计划规范 GB/T 12504-1990》、《计算机软件可靠性和可维护性 GB/T 14394-2008》、《中华人民共和国标准 GB 1526-1989》、《计算机软件需求说明编制指南 GB/T 9385-2008》、《软件工程术语 GB/T 11457-2006》、《计算机软件产品开发文件编制指南 GB/T 8567-2006》。 而其中《软件工程产品质量第 1 部分 GB/T16260》和《软件文档管理指南 GB/T16680》又是 该知识点中的重点，历次考查的总分值都超过了 10 分。 第 1 步：自我检测 本小节给出 2 道习题，用于测试对该知识的了解程度。
习题 1： 根据《软件文档管理指南 GB/T 16680-1996》，记录开发过程每个阶段的进度和变更的文档属坦 克 级 于 （1） 。 （1）A．开发文档 B．产品文档 C．管理文档 D．质量文档
习题 2： 根据《软件工程产品质量》GB/T 16260.1-2006 定义的质量模型，不属于功能性的质量特性 是 （2） 。 （2）A．适应性 B．适合性 C．安全保密性 D．互操作性 第 2 步：学习卡片 为了方便读者们快速学习和复习，我们将这一小节的重要知识点浓缩在 4 张学习卡片中，具体 如图 C-2-1～图 C-2-4 所示。 图 C-2-1 学习卡片 1坦 克 级
图 C-2-2 学习卡片 2
坦 克 级 图 C-2-4 学习卡片 4 第 3 步：知识讲解 考点 1：软件工程产品质量第 1 部分 GB/T16260 “软件质量”是软件特性的总和，软件满足规定或潜在用户需求的能力。该标准认为软件生命 周期中，不同阶段关注不同的产品质量，度量质量的方法也不同。 1．质量分类 软件质量分为内部质量（开发中）、外部质量（开发过程外）和使用质量（用户角度来看）三 部分。具体如图 C-2-5 所示。 （1）用户质量要求：用户对质量的需求可以是使用质量的度量、外部度量，也可以是内部度 量。用户质量需求将成为产品确认准则。 （2）外部质量需求：从外部视角来规定要求的质量级别，包括用户质量要求派生的需求（包 括使用质量需求）。 （3）内部质量需求：从产品的内部视角来规定要求的质量级别。内部质量需求用来规定中间 产品的特性。这些可以包括静态和动态的模型，以及其他文档和源代码。
坦 克 级 用户质量 要求 使用 质量 外部质量 需求 外部 质量 内部质量 需求 使用和反馈 有助于确定 有助于确定 内部 质量 验证 确认 指示 指示 图 C-2-5 质量分类 （4）外部质量：是基于外部视角的软件产品特征的总和。 （5）内部质量：是基于内部视角的软件产品特征的总和。 （6）使用质量：基于用户观点的质量。使用质量的获得依赖于必需的外部质量，而外部质量 的获得则依赖于取得必需的内部质量。 2．质量模型框架 该标准规定了质量模型框架，将软件质量分为 6 个主要特性和若干子特性。质量模型如图 C-2-6 所示。 图 C-2-6 外部、内部质量模型 MTBF（平均无故障时间）=无故障总时间/故障次数，是指相邻两次故障之间的平均工作时间。 例如，正在运行中的 100 只硬盘，一年之内出了 2 次故障，则每个硬盘的故障率为 0.02 次/年。“可 靠性”可用故障次数指标来简单替代。 可用性=可用时间/总时间，是指在某特定时间段内，系统能正常工作的时间占总时间的百分比。 “可用性”可用平均修复时间来简单替代。 3．使用质量的质量模型 使用质量的属性分为四个特性：有效性、生产率、安全性和满意度。模型如图 C-2-7 所示，简 称“有效生产，安全满意”。
坦 克 级 图 C-2-7 使用质量特性 4．度量 度量分为内部度量和外部度量。 （1）内部度量 内部度量可以应用于设计和编码期间的非执行软件产品（标书、需求定义、规格说明、源代码）。 内部度量用于测试软件产品的中间产品。使得用户、评价者、测试人员和开发者可以在软件产 品可执行之前就能评价软件产品质量和尽早地提出质量问题。 （2）外部度量 外部度量测试、运行和观察可执行的软件或系统。外部度量使得用户、评价者、测试人员和开 发者可以在测试或操作期间评价软件产品质量。 外部度量可以通过测量该软件产品作为其一部分的系统行为来测量软件产品的质量。外部度量 只能在生存周期过程中的测试阶段和任何运行阶段使用。 考点 2：软件文档管理指南 GB/T16680 该协议帮助管理者在机构中产生有效文档。文档讲述了软件文档的作用、管理者的作用、制定 文档的策略与计划、制定文档的标准与流程。 1．项目周期中的文档 软件文档归入如下三种类别，如表 C-2-1 所示。 表 C-2-1 软件文档分类 文档名 文档作用 基本文档 开发文档 描述开发过程本身 《可行性研究和项目任务书》 《需求规格说明》 《功能规格说明》 《设计规格说明，包括程序和数据规格说明》 《开发计划》 《软件集成和测试计划》 《质量保证计划、标准、进度》 《安全和测试信息》 产品文档 描述开发过程的产物 《培训手册》 《参考手册和用户指南》 《支持手册》 《产品手册》
坦 克 级 续表 文档名 文档作用 基本文档 管理文档 记录项目管理的信息 《开发过程的每个阶段的进度和进度变更的记录》 《软件变更情况的记录》 《相对于开发的判定记录》 《职责定义》 2．文档质量分级 每个文档的质量必须在文档计划期间就有明确的规定。文档的质量可以按文档的形式和列出的 要求划分为四级，可以笼统划分为正式文档和非正式文档。 文档质量分级如表 C-2-2 所示。 表 C-2-2 按质量分级的文档 质量级别 适用情况 备注 最低限度文档 （1 级文档） 适合开发工作量低于一个人月的开 发者自用程序 该文档应包含程序清单、开发记录、测试 数据和程序简介 内部文档 （2 级文档） 精心研究后被认为似乎没有与其他 用户共享资源的专用程序 除 1 级文档提供的信息外，2 级文档还包括 程序清单内足够的注释以帮助用户安装和 使用程序 工作文档 （3 级文档） 适于由同单位若干人联合开发的程 序，或可被其他单位使用的程序 正式文档 （4 级文档） 适于要正式发行供普遍使用的软件 产品 关键性程序或具有重复管理应用性质（如 工资计算）的程序需 4 级文档。 应遵守 GB 8567 的有关规定 3．文档评审 需求评审：进一步确认开发者和设计者已了解用户要求什么，及用户从开发者一方了解某些限 制和约束。 设计评审：通常安排两个主要的设计评审，概要设计评审和详细设计评审。 概要设计评审：主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应 根据概要设计评审的结果加以修改。 详细设计评审：主要评审计算机程序和程序单元测试计划。 4．文档编制计划 文档计划一般包括以下几方面内容： （1）列出应编制文档的目录； （2）提示编制文档应参考的标准； （3）指定文档管理员； （4）提供编制文档所需要的条件，落实文档编写人员、所需经费以及编制工具等；
坦 克 级 （5）明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施， 如评审、鉴定等； （6）绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、 完成日期、评审日期等。 5．文档归档 文档归档应满足： （1）归档的文档是经过鉴定或评审的； （2）文档应签署完整、成套、格式统一、字迹工整； （3）印制本、打印本以及各种报告应装订成册，并按规定进行编号和签署。 考点 3：计算机软件质量保证计划规范 GB/T 12504-1990 《计算机软件质量保证计划规范 GB/T 12504-1990》主要考查的条目如下： （1）验证 Verification 验证是指确定软件开发周期中，一个给定阶段的产品是否达到在上一阶段确立的需求的过程。 （2）确认 Validation 确认是指在软件开发过程结束时，对软件进行评价以确定它是否和软件需求相一致的过程。 （3）测试 Testing 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确 认的手段之一。 为了确保软件的实现满足需求，至少需要下列基本文档： 软件需求规格说明书（Software Requirements Specification）。 软件设计说明书（Software Design Description）。
软件验证与确认计划（Software Verification and Validation Plan）。 软件验证和确认报告（Software Verification and Validation Report）。 用户文档（User Documentation）。 其他文档。 除基本文档以外，还应包括：项目实施计划、项目进展报表、项目开发各阶段的评审报表。 考点 4：软件工程术语 GB/T 11457-2006 《软件工程术语 GB/T 11457-2006》主要考查的条目如下： 软件开发方法是软件开发过程所遵循的方法和步骤，它是规则、方法和工具的集成，既支 持开发，也支持以后的演化过程。 基线是已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理 步骤方能加以修改的规格说明或产品。配置管理有以下三种基线：功能基线、分配基线和 产品基线。 确认（Validation）是在开发过程期间或结束时对系统或部件进行评价，通过检查和提供客 观证据，以确定它是否满足特定预期用途的需求的过程。
坦 克 级 验证（Verification）是评价系统或部件，以确定软件开发周期中一个给定阶段的产品是否 满足在阶段的开始确立的需求的过程。 审计是为评估工作产品或工作产品是否符合软件需求、规格说明、基线、过程、指令、代 码以及合同和特殊要求而进行的一种独立的检查。 考点 5：其他知识点 软件工程标准涉及的其他相关考点有： 1．计算机软件可靠性和可维护性 GB/T 14394-2008 《计算机软件可靠性和可维护性管理 GB/T14394-2008》考过的相关条目如下： 在软件运作过程和维护过程中，应分析和提高软件可靠性： （1）制定并实施软件可靠性数据采集规程； （2）实施软件 FRACAS； （3）测量可靠性，分析现场可靠性是否达到要求； （4）跟踪用户满意程度； （5）用可靠性测量数据指导产品和工程过程的改进； （6）软件产品维护时执行适当的维护规程并参照基本文档中实施适用的管理活动。 详细设计评审包含的内容有：各单位可靠性和可维护性目标、可靠性和可维护性设计、测试文 件、软件开发工具。 2．中华人民共和国标准 GB 1526-1989 《中华人民共和国标准 GB 1526-1989》考过的相关条目如下： 数据流程图：表示求解某一问题的数据通路。同时规定处理的主要阶段和所用的各种数据 媒体。 程序流程图：表示程序中的操作顺序。 系统流程图：表示系统的操作控制和数据流。 程序网络图：表示程序激活路径和程序与相关数据的相互作用。在系统流程图中，一个程 序可能在多个控制流中出现；但在程序网络图中，每个程序仅出现一次。 系统资源图：表示适合于一个问题或一组问题求解的数据单元和处理单元的配置。 3．计算机软件需求说明编制指南 GB/T 9385-2008 《计算机软件需求说明编制指南 GB/T 9385-2008》考过的相关条目如下： （1）软件需求规格说明（SRS，Software Requirements Specifications）的编制者
软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用 SRS 的形式，应该由双方联合起草。 （2）SRS 的基本要求 SRS 是对要完成一定功能、性能的软件产品、程序或一组程序的说明。 对 SRS 的描述有两项基本要求： 1）必须描述一定的功能、性能；
坦 克 级 2）必须用确定的方法叙述这些功能、性能。 （3）在 SRS 中嵌入了设计 在 SRS 中嵌入设计说明，会过多地约束软件设计，并且人为地把具有潜在危险的需求放入 SRS 中。 1）SRS 必须描述在什么数据上、为谁完成什么功能、在什么地方、产生什么结果。SRS 应把 注意力集中在要完成的服务目标上。通常不指定如下设计项目： ①把软件划分成若干模块； ②给每一个模块分配功能； ③描述模块间的信息流程或者控制流程； ④选择数据结构。 2）把设计完全同 SRS 隔离开来始终是不现实的。安全和保密方面的周密考虑可能增加一些直 接反映设计约束的需求。例如： ①在一些分散的模块中保持某些功能； ②允许在程序的某些区域之间进行有限的通信； ③计算临界值的检查。 （4）在 SRS 中嵌入了一些项目要求 SRS 应当是描写一个软件产品，而不是描述生产软件产品的过程。项目要求表达客户和开发 者之间对软件生产方面合同性事宜的理解（因此不应当包括在 SRS 中）例如： ①成本； ②交货进度； ③报表处理； ④软件开发方法； ⑤质量保证； ⑥确认和验证的标准； ⑦验收过程。 4．计算机软件产品开发文件编制指南 GB/T 8567-2006 《计算机软件产品开发文件编制指南 GB/T 8567-2006》考过的相关条目如下： （1）软件生存周期与各种文件的编制。 （2）在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定该软件的各项 功能、性能需求和设计约束，确定对文件编制的要求。作为本阶段工作的结果，一般来说，软件需 求说明书、数据要求说明书和初步的用户手册应该编写出来。 第 4 步：效果评估 ● 根据《软件文档管理指南》（GB/T 16680-1996），以下关于软件文档归类的叙述，不正确 的是 （1） 。
