软件工程

软件工程

软件危机（Software Crisis）。具体表现为：软件开发进度难以预测、软件开发成本难以控制、软件功能难以满足用户期望、软件质量无法保证、软件难以维护和软件缺少适当的文档资料。

软件过程模型

软件过程模型。软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个全过程就是软件的生命周期。软件生命周期描述了软件从生到死的全过程。为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型被称为软件过程模型，有时也称为软件生命周期模型。

瀑布模型

瀑布模型（Waterfall Model），如图所示，是结构化开发方法使用的软件过程模型。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。每一个阶段工作完成后都伴随着一个里程碑。缺点是需求难以一次确定、变更的代价高、结果难以预见、各阶段工作不能并行。

原型模型

原型模型（Prototype Model），如图所示，又称快速原型，是原型方法使用的生命周期模型。原型模型解决了瀑布模型需求难以一次确定、结果难以预见的缺点。

原型模型有 原型开发 和 目标软件开发 两个阶段。

抛弃型原型将原型作为需求确认的手段，在需求确认结束后就被抛弃不用，继续用瀑布模型。

演化性原型在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。

螺旋模型

螺旋模型（Spiral Model），如图所示，是在快速原型的基础上结合瀑布模型扩展而成。把整个软件开发流程分成多个阶段，每一个阶段都由 目标设定、风险分析、开发和有效性验证、评审 4 部分组成。支持大型软件开发，适用于 面向规格说明、面向过程和面向对象 的软件开发方法，强调其他模型忽视的风险分析。

1. 目标设定。 为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。
2. 风险分析。 对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。
3. 开发和有效性验证。 风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。
4. 评审。 对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

敏捷模型

敏捷（Agile）模型，属于敏捷方法使用的模型。敏捷模型主要有极限编程（Extreme Programming，XP）、水晶系列方法、并列争球法（Scrum）、特征驱动开发方法（Feature Driven Development，FDD）等具体的敏捷方法，这些方法的显著特征如下：

• 极限编程（XP）：高效、低风险、测试先行（先写测试代码，再编写程序）。
• 水晶系列方法：不同的项目，采用不同的策略。
• 并列争球法（Scrum）：该方法侧重于项目管理。Scrum 包括一系列实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）。在 Scrum 中，使用产品 Backlog 来管理产品的需求，产品 Backlog 是一个按照商业价值排序的需求列表。根据 Backlog 的内容，将整个开发过程分为若干个短的迭代周期（Sprint），在 Sprint 中，Scrum 团队从产品 Backlog 中挑选最高优先级的需求组成 Sprint Backlog。在每个迭代结束时，Scrum 团队将递交潜在可交付的产品增量。当所有 Sprint 结束时，团队提交最终的软件产品。
• 开放式源码指的是开放源码界使用的一种运作方式，开放式源码项目的一个特别之处就是程序开发人员在地域上分布很广。这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者，然后由维护者将这些“补丁”或新增的代码并入源码库。
• 特征驱动开发方法：该方法会将开发人员分类，分为指挥者（首席程序员）、类程序员等。功能驱动开发方法（FFD）由 Jeff De Luca 和大师 Peter Coad 提出，它致力于短时的迭代阶段和可见可用的功能，在 FDD 中一个迭代周期一般是两周。在 FDD 中程序开发人员分成两类，即首席程序员和“类”程序员（Class Owner）。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者；“类”程序员则主要做源码编写。
• 自适应软件开发（ASD）方法由 Jim Highsmith 提出，其核心是 3 个非线性且重叠的开发阶段，即猜测、合作与学习。

快速应用开发模型

2012 综合知识 29,30

快速应用开发（Rapid Application Development，RAD)是一种比传统生存周期法快得多的开发方法，它强调极短的开发周期。RAD 模型是瀑布模型的一个高速变种，通过使用 基于构件的开发方法 获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快地开发出功能完善的信息系统。但是 RAD 也具有以下局限性：

1. 并非所有应用都适合 RAD。RAD 对模块化要求比较高，如果有哪一项功能不能被模块化，那么 RAD 所需要的构建就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则 RAD 也有可能不能奏效。
2. 开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致 RAD 项目失败。
3. RAD 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统与现有系统有较高的互操作性时，就不适合使用 RAD。

软件统一过程模型

软件统一过程（Rational Unified Process，RUP）模型。RUP 是一种重量级过程模型，属于构件化开发使用的软件过程模型。其生命周期是一个二维的软件开发模型，划分为多个循环（Cycle），每个循环生成产品的一个新的版本，每个循环依次由 初始、细化、构造和移交 4 个连续的阶段（Phase）组成，每个阶段完成确定的任务。

RUP 中有 9 个核心工作流，这 9 个核心工作流分别是：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。

RUP 的特点是 用例驱动的、以架构为中心的、迭代和增量 的软件开发过程。

RUP 用“4+1”视图模型来描述架构，如图所示，后被 UML 吸收采纳。

• 逻辑视图： 对应最终用户，主要支持功能性需求，即在为用户提供服务方面系统所应该提供的功能。逻辑视图常用类图、对象图、状态图、协作图表示。
• 实现视图： 又称为开发视图，对应程序员，关注软件开发环境下实际模块的组织，描述系统的各部分如何被组织为模块和组件即开发环境中软件的静态组织结构。该视图通常包含包图和组件图。
• 进程视图： 又叫过程视图，对应系统集成人员，考虑一些非功能性的需求，如性能和可用性，它可以解决并发性、分布性、系统完整性、容错性的问题。进程视图常用活动图表示。
• 部署视图： 又叫物理视图，对应系统工程师。描述如何将前三个视图中所述的系统设计实现为一组现实世界的实体。展示了如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通信等问题。部署视图常用部署图表示。
• 用例视图： 所有其他视图都依靠用例视图（场景）来指导它们，这就是将模型称为“4+1” 的原因。

RUP 在每次迭代中，只考虑系统的一部分需求，进行 分析、设计、实现、测试和部署 等过程。

软件能力成熟度模型

软件能力成熟度模型（Capability Maturity Model for Software，CMM）。CMM 是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。

软件能力成熟度模型集成

软件能力成熟度模型集成（Capability Maturity Model Integration for Software，CMMI）。CMMI 是在 CMM 的基础上发展而来的。CMMI 提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成 5 个成熟度等级：初始级、已管理级、已定义级、量化管理级、优化级。量化管理级与已定义级的区别是对过程性能的可预测。

需求工程

软件需求包括 3 个不同的层次。

1. 业务需求（Business Requirement），反映了组织机构或客户对系统、产品高层次的目标要求；
2. 用户需求（User Requirement），描述了用户使用产品必须要完成的任务，也就是说，用户需求描述了用户能使用系统来做些什么。通常采用用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求；
3. 系统需求（System Requirement），从系统的角度来说吗软件的需求，包括 功能需求、非功能需求和设计约束 等。功能需求也称为行为需求，它规定开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。

功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、效率等）和其他非功能需求。

需求工程（Requirement Engineering，RE）是指应用已证实有用的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。需求工程由 ** 需求获取、需求分析、形成需求规格（或称为需求文档化）、需求确认与验证、需求管理** 5 个阶段组成。

需求获取

需求获取是获得系统必要的特征，或者是获得用户能接受的、系统必须满足的约束。需求获取的基本步骤：

1. 开发高层的业务模型。
2. 定义项目范围和高层需求。
3. 识别用户角色和用户代表。
4. 获取具体的需求。
5. 确定目标系统的业务工作流。
6. 需求整理与总结。

需求获取的方法包括用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法和头脑风暴法等。

软件需求规格说明书

软件需求规格说明书（Software Requirement Specification，SRS）具体包括功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的 SRS 是需求开发和需求管理之间的桥梁。

需求管理

需求管理是一个对系统需求变更、了解和控制的过程，包括 变更控制、版本控制、需求跟踪 等活动。

需求变更

需求变更管理过程如图所示：

变更控制委员会

变更控制委员会（Change Control Board，CCB）由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。CCB 是决策机构，不是作业机构，通常 CCB 的工作是通过评审手段来决定项目是否能变更，但不提出变更方案。过程及操作步骤为制定决策、交流情况、重新协商约定。

需求跟踪

需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护需求—设计—编程—测试”之间的一致性，确保所有的工作成果符合用户需求。需求跟踪有 正向跟踪 和 逆向跟踪 两种方式，合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护 需求跟踪矩阵。

flowchart LR
    A["客户需求"]
    B[软件需求]
    C[下一级工作产品]
    A -->|追溯到需求从需求回溯| B
    B -->|回溯到需求从需求追溯| C

系统分析与设计

结构化方法

结构化方法（Structured Analysis and Structured Design，SASD）又称为面向功能的软件开发方法或面向数据流的软件开发方法。针对软件生存周期各个不同的阶段，有 结构化分析、结构化设计 和 结构化编程 等方法。

结构化分析

结构化分析（Structured Analysis, SA）利用图形表达用户需求中的功能需求，使用的手段主要有数据流图（Data Flow Diagram, DFD）、数据字典、结构化语言、判定表及判定树等。

数据流图（DFD）由 4 种基本元素组成：数据流、处理/加工、数据存储和外部项。

结构化分析具体的建模过程及步骤为明确目标、确定系统范围、建立顶层 DFD 图、构建第一层 DFD 分解图、开发 DFD 层次结构图、检查确认 DFD 图。

数据字典（Data Dictionary）是一种标记用户可以访问的数据项和元数据的目录，是对系统中使用的所有数据元素定义的集合，包括数据项、数据结构、数据流、数据存储和处理过程。

结构化方法分析模型的核心是数据字典，围绕这个核心，有 3 个层次的模型，分别是数据模型、功能模型和行为模型（也称为“状态模型”）。在实际工作中一般使用 E-R 图表示数据模型；用 DFD 表示功能模型；用状态转换图表示行为模型。这 3 个模型有密切的关系，他们建立不具有严格的时序性，而是一个迭代的过程。

DFD 图需要满足规则：

• 父图数据流必须在子图中出现；
• 一个处理至少有一个输入流和一个输出流；
• 一个存储必定有流入和流出；
• 一个数据流至少有一端是处理端；
• 模型表达的信息是全面的、完整的、正确的和一致的。

结构化设计

结构化设计（Structured Design, SD）是一种面向数据流的设计方法，以 SRS 和 SA 阶段所产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD 分为 概要设计 和 详细设计 两个阶段。

• 概要设计的主要任务是确定软件系统的结构，对系统进行模块划分，确定每个模块的功能、接口和模块之间的调用关系；
• 详细设计的主要任务是为每个模块设计实现的细节。

在 SD 中，模块是实现功能的基本单位，一般具有 功能、逻辑和状态 3 个基本属性。

耦合表示模块之间的联系的程度，耦合度从低到高依次如表所示：

内聚表示模块内部个代码成分之间联系的紧密程度，内聚从高到底依次如表所示：

模块分解中应遵循“高内聚、低耦合”的设计原则。

概要设计使用系统结构图（Structure Chart，SC），又称为模块结构图，反映了系统的总体结构。

详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构。详细设计的表示工具有图形工具、表格工具和语言工具。图形有业务流图、程序流程图、问题分析图（Problem Analysis Diagram，PAD）、NS 流程图等。

结构化编程

结构化编程（Structured Programming, SP）通过顺序、分支和循环三种基本控制结构可以构造出任何单入口单出口程序。

数据库设计（概念结构设计部分）

概念结构设计建立抽象的概念数据模型，通常采用实体-联系图（Entity Relationship Diagram, E-R 图）来表示。

面向对象方法

面向对象的分析方法

面向对象的分析方法（Object-Oriented Analysis，OOA）模型由 5 个层次（主题层、对象类层、结构层、属性层和服务层）和 5 个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成。

OOA 的基本原则有 抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制和行为分析。

OOA 的 5 个基本步骤：确定对象和类、确定结构、确定主题、确定属性、确定方法。

UML 2.0

UML 对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及他们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下 5 个系统视图：逻辑视图、进程视图、实现视图、部署视图、用例视图。

UML 交互图 包括：交互概览图、定时图、顺序图（序列图）与通信图（协作图）。除此之外，动态模型 还包括：状态图和活动图等。

• 类图 展现了一组对象、结构、协作和他们之间的关系；
• 定时图 强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序；
• 部署图 描述软件和硬件组件之间的物理关系以及处理节点的分布情况；
• 包图 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
• 顺序图 亦称为序列图或循序图，是一种 UML 行为图。它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。它以表示用例的行为顺序，当执行一个用例行为时，时序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。

UML 关系：依赖、关联、泛化、实现、组合、聚合

在 UML 用例图中，用例与用例 之间关系有 扩展、包含和泛化（继承） 三种

面向对象设计方法

在面向对象设计方法（Object-Oriented Design，OOD）中，数据结构和在数据结构上定义的操作算法封装在一个对象之中。类封装了信息和行为，是具有相同属性、方法和关系的对象集合的总称。类可以分为 3 种类型：

1. 实体类： 一般来说是一个名词，通常都是永久性需要存储的，例如教师、学生。
2. 控制类： 是用于控制用例工作的类，控制对象（控制类的实例）通常控制其他对象或协调其他对象的行为，例如登录验证。
3. 边界类： 用于封装在用例内、外流动的信息或数据流，例如窗口、通信协议、接口等。

面向对象程序设计

面向对象程序设计（Object-Oriented Programming，OOP）。以对象为核心，该方法认为程序由一系列对象组成。OOP 的基本特点有封装、继承和多态。封装是指将一个计算机系统中的数据以及与这个数据相关的一切操作组装到一起。继承是指一个对象针对于另一个对象的某些独有的特点、能力进行复制或者延续。继承可以分为 4 类，分别为 取代继承、包含继承、受限继承和特化继承。 多态指同一操作作用于不同的对象，可以产生不同的结果。

数据持久化与数据库。

永久保存对象的状态，需要进行对象的持久化（Persistence），把内存中的对象保存到数据库或可永久保存的存储设备中。在多层软件设计和开发中采用持久层（Persistence Layer）专注于实现数据持久化，将对象持久化到关系数据库中，需要进行对象/关系的映射（Object/Relation Mapping，ORM）。目前主流的持久化技术框架包括 Hibernate、iBatis/Mybatis和 JDO 等。

1. Hibernate： 是一个开源的全自动的 ORM 框架，对 JDBC 进行了非常轻量级的对象封装，提供抽象的 HQL 可以自动生成不同数据库的 SQL 语句，优点是具有跨数据库平台的特性。
2. iBatis/Mybatis： 提供手动的 ORM 实现，需要程序员手写 SQL，优点是可以结合特定的数据库特性深度优化。
3. Java 数据对象（Java Data Object，JDO）： 是 Java 标准中的持久化 API，提供了透明的对象存储，并且不仅仅支持关系数据库，还支持普通文件、XML 文件和对象数据库等。

其他设计方法

其他设计方法如构件与软件重用。软件重用是使用已有软件产品来开发新的软件系统的过程，分为 水平式重用 和 垂直式重用 两种类型。

逆向工程

逆向工程是通过分析已有的程序，寻求比源代码更高级的抽象表现形式（比如文档）的活动，是在不同抽象层级中进行的溯源行为。

逆向工程得出的设计称为设计恢复（Design Recovery），但不一定能够抽象还原到原设计。

重构（Restructuring）是在同一抽象层级中转换系统描述的活动。对逆向工程所形成的系统进行修改或重构，生成的新版本称为重构工程。逆向工程信息恢复的级别：

软件测试

测试是确保软件的质量，确认软件以正确的方式做了用户所期望的事情。软件测试通常在规定的时间和成本内完成，以尽量多地发现漏洞，但不能保证发现所有的漏洞。

单元测试

单元测试 主要是对该软件的模块进行测试，往往由程序员自己完成。常采用 白盒的静态测试 如静态分析、代码审查等，也可以采用 自动化的动态测试。

集成测试

集成测试 对通过单元测试的模块进行组装测试，以验证组装的正确性，一般采用 白盒测试和黑盒测试结合 的方法。

系统测试

系统测试 检查组装完成的系统是否符合 SRS 的要求。主要测试内容包括 功能测试、性能测试、健壮性测试、安全性测试等，结束标志是测试工作已满足测试目标所规定的需求覆盖率，并且测试所发现的缺陷都已全部归零。

验收测试

验收测试 是确认系统满足用户需求或者协议的要求，确保系统能支撑业务运行。

净室软件工程

净室软件工程（Cleanroom Software Engineering, CSE）是一种在软件开发过程中 强调在软件中建立正确性的需要的方法。 CSE 的理论基础主要是 函数理论 和 抽样理论。

CSE 使用盒子结构规约进行分析和设计建模，并且强 调将正确性验证（而不是测试）作为发现和消除错误的主要机制，可以生成质量非常高的软件。 CSE 的缺点是太理论化、忽视测试、带有传统软件工程的弊端。

基于构建的软件工程（重要）

基于构建的软件工程（Component-Based Software Engineering, CBSE）是一种基于分布对象技术、强调通过可复用构建设计与构造软件系统的软件复用途径。用于 CBSE 的构件应该具备以下特征：

1. 可组装型：所有外部交互必须通过公开定义的接口进行；
2. 可部署形：必须能作为一个独立实体在提供其构件模型实现的构件平台上运行；
3. 文档化：构件必须是完全文档化的；
4. 独立化：构件应该是独立的，如确实需要其他构件提供服务，则应显式声明；
5. 标准化：必须符合某种标准化的构件模型。

构件模型

构件模型定义了构件实现、文档化以及开发的标准。目前主流的构件模型是 Web Services 模型、Sun 公司的 EJB 模型 和微软的 .NET 模型。构件模型包含了一些模型要素如 接口、使用信息和部署信息。构件模型提供了一组被构件使用的通用服务，包括平台服务和支持服务。容器是构件模型基础设施，是支持服务的一个实现加上一个接口定义，构件必须提供该接口定义以便和容器整合在一起。

构件组装

常见的构件组装有 顺序组装、层次组装和叠加组装 3 种组装方式。构件组装可能面临接口不兼容的问题，常见的有 参数不兼容、操作不兼容和操作不完备 3 种。这时需要编写适配器构件来解决不兼容的问题。

软件项目管理

1. 软件进度管理一般包括活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制 6 个过程。

2. 工作分解结构（Work Breakdown Structure，WBS）是把一个项目，按一定的原则分解成任务，任务再分解成一项项工作，再把一项项工作分配到每个人的活动中，直到分解不下去为止。以可交付成果为导向，对项目要素进行的分组，总是处于计划过程的中心。

   2010 综合知识 22

   项目时间管理包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。

   为了得到工作分解结构（Work Breakdown Structure，WBS）中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就是活动定义。

   鱼骨图（也称为 Ishikawa 图）是一种发现问题“根本原因”的方法，通常用来进行因果分析。

   2010 综合知识 26

   项目时间管理包括使项目按时完成所必须的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。 为了得到工作分解结构（Work Break down Structure,WBS)中最底层的交付物，必须执行一系列的活动，对这些活动的识别以及归档的过程就叫做活动定义。

3. 活动定义是指确定完成项目的各个可交付成果所必须进行的各项具体活动，还需要明确每个活动的前驱、持续时间、必须完成日期、里程碑或可交付成果。

4. 任务活动图是项目进度管理、项目成本管理等一系列项目管理活动的基础，通常采用甘特图等方式来展示和管理项目活动。
5. 软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术。SCM 的目的是使错误降为最小并最有效地提高生产效率。SCM 的核心内容包括版本控制和变更控制。版本控制（Version Control）是指对软件开发过程中各种文件变更的管理，最主要的功能就是追踪和记录文件的变更、并行开发。变更控制（Change Control）是指对变更进行管理，确保变更有序进行。

6. 软件质量管理。软件质量就是软件与明确地和隐含地定义的需求相一致的程度。软件质量保证（Software Quality Assurance，SQA）的目的是使软件过程对于管理人员来说是可见的。

   SQA 的主要任务是

   1. SQA 审计与评审，包括对软件工作产品、软件工具和设备的审计，评审开发组的行为符合预定的过程。
   2. SQA 报告。
   3. 处理不符合问题。

   软件质量认证，国内软件企业主要采用的是 ISO 9001 和 CMM。

   2011 综合知识 23

   软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理 是指对软件开发过程进行的独立的检查活动，由 质童保证、质量规划和质量控制 三个主要活动构成。软件质量保证是指为保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产髙质量的软件。软件评审是软件质量保证的主要活动之一。

7. 软件风险管理。软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。风险管理的主要目标是预防风险，及应对发生的风险。风险管理活动可以分为：

   1. Bochm 把风险管理活动分成风险估计（风险辨识、风险分析、风险排序）和风险控制（风险管理计划、风险处理、风险监督）两大阶段。
   2. Charette 把风险分成分析（辨识、估计、评价）和管理（计划、控制、监督）两大阶段。

• PERT 图是一种图形化的网络模型，描述了一个项目中任务和任务之间的关系，每个节点表示一个任务，通常包括任务编号、名称、开始和结束时间、持续时间和松弛时间。
• Gantt 图是一种简单的水平条形图，他以一个日历为基准描述项目任务，横坐标表示时间，纵坐标表示任务

PERT 图主要描述不同任务之间的依赖关系；Gantt 图主要描述不同任务之间的重叠关系。

关键路径

总浮动时间： 在不延误 项目完工时间 且不违反进度约束因素的前提下，活动可以从最早开始时间推迟或延迟的时间量，就是该活动的进度灵活性。正常情况下关键活动的总浮动时间为零。

最迟开始（LS）-最早开始（ES）或 最迟完成（LF）-最早完成（EF）或 关键路径-非关键路径时长

自由浮动时间： 在不延误任何 紧后活动 的最早开始时间且不违反进度制度约束因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。

紧后活动最早开始时间的最小值-本活动的最早完成时间

配置管理

配置管理是为了系统的控制配置变更，在系统整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。在 GB/T11457-2006 中将配置管理正式定义为：应用技术和管理的指导和监控方法以 标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。

配置管理主要包括 6 个活动：制定配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

配置项

配置项是配置管理设计的硬件、软件或二者的集合，在配置管理中作为一个单一实体来对待。典型的配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各类数据，它们经过 评审和检查 后进入配置管理。每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

配置项可以分为基线配置项和非基线配置项两类，例如：基线配置项包括所有的设计文档和源程序等；非基线配置项包括项目的各类计划和报告等。所有配置项的操作权限应由 CMO（配置管理员）严格管理，基本原则是，基线配置项向开发人员开放读取的权限；非基线配置项向 PM、CCB 及相关人员开放。

配置项的状态

配置项的状态分为草稿、正式、修改三种。配置项刚建立时状态是草稿，通过评审后，状态变为正式。此后若配置项变更，其状态变为修改，当修改的配置项修改完毕并重新通过评审，其状态恢复为正式。如图所示：

flowchart LR
  A[草稿] -->|通过评审| B[正式];
  A -->|修改| A;
  subgraph 变更控制
  B --> C[修改];
  C -->|再次通过评审| B;
  end

配置项的版本

质量管理

质量是软件产品特性的综合，表示软件产品满足明确（基本需求）或隐含（期望需求）要求的能力。质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动；

主要包括以下过程：

1. 质量计划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。
2. 质量保证：一般是每隔一定时间（例如，每个阶段末）进行的，主要通过系统的 质量审计（软件评审）和过程分析 来保证项目的质量。
3. 质量控制：实时监控项目的具体结果，以判断他们是否符合相关质量标准，制定有效方案，以消除产生质量问题的原因。

风险管理

风险管理是要对项目进行认真分析和科学的管理，这样是能够避开不利条件、少受损失、取得预期的结果并实现项目目标，能够争取避免风险的发生或尽量减小风险发生后的影响。完全避开或消除风险，或只享受权益而不承担风险是不可能的。

• 风险管理计划编制：如何安排与实施项目的风险管理，指定下列各步的计划；
• 风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表；
• 风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型；
• 风险定量分析：进一步了解风险发生的可能性具体有多大，后果具体有多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟；
• 风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险（避免策略、转移策略、减轻策略）；积极风险（开拓、分享、强大）；
• 风险监控：监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。

在信息系统项目中，从宏观上看风险可以分为项目风险、技术风险和商业风险。

• 项目风险：指 潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及他们对项目的影响。 项目的复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，项目增加的成本。
• 技术风险：指潜在的 设计、实现、接口、测试和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟） 也是风险因素。技术风险 威胁到待开发系统的质量和预定的交付时间。 如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
• 商业风险 威胁到开发系统的生存能力，主要有以下 5 种不同的商业风险：
  • 市场风险。开发的系统虽然很优秀但不是市场真正所想要的；
  • 策略风险。开发的系统不再符合企业的信息系统战略；
  • 销售风险。开发了销售部门不清楚如何推销的系统；
  • 管理风险。由于重点转移或人员变动而失去上级管理部门的支持；
  • 预算风险。开发过程没有得到预算或人员的保证。