文章目录

• 第一章
• • 1.1 软件危机
  • • 消除软件危机的途径
  • 1.2 软件工程
  • 1.3 软件工程知识体系
• 第二章
• • 2.1 软件生命周期（SDLC，Systems Development Life Cycle）
  • • 2.1.1 基本任务
  • 2.2 计划驱动的软件过程：Waterfall Model（瀑布模型，或称之为SDLC模型）
  • 2.3 快速原型（Rapid Prototype）
  • 2.4 增量模型（Increment Model）
  • 2.5 螺旋模型（spiral model）
  • 2.6 喷泉模型（Fountain model）
  • 2.7 Ration统一过程
  • • 核心元素
    • 最佳实践
    • RUP的十大要素
  • 2.8 敏捷过程与极限编程
  • • 敏捷宣言
    • • 原则
    • 极限编程
    • • 有效实践
      • 极限编程的整体开发过程
      • 极限编程的迭代过程
  • 能力成熟度模型（capability maturity model，CMM）
  • • 能力成熟度等级
• 第三章
• • 软件原型
  • • 快速地构建和修改原型的方法和工具
  • 数据流图
  • 数据字典
• 第四章
• • SA、SD方法
  • 软件设计的概念和原理
  • • 模块化
    • • 模块化定义的5条标准
    • 抽象
    • 逐步求精
    • 信息隐藏
  • 模块独立
  • • 耦合
    • 内聚
  • 表示软件结构的图形工具
  • • 层次图和HIPO图
    • 结构图
  • 过程设计
  • 过程设计工具
  • • 程序流程图
  • 程序流程图的主要缺点
  • • 盒图（N-S图）
    • PAD图
    • • PAD图主要优点
    • 判定表
    • 判定树
    • 过程设计语言
  • 面向数据结构的设计方法
  • • Jackson图
    • 改进Jackson图
    • Jackson方法
  • 示例
• 第五章 结构化实现
• • 选择程序设计语言
  • • 编码风格
  • 软件测试基础
  • • 测试目标
    • 黑盒测试和白盒测试
    • • 单元测试
    • 测试准则
    • 流图
  • 逻辑覆盖
  • • 语句覆盖
    • 判定覆盖
    • 条件覆盖
    • 判定/条件覆盖
    • 条件组合覆盖
  • 示例
• 第六章 面向对象方法学导论
• • 对象模型
  • • 表示关系的符号
    • 泛化
    • 依赖和细化
  • 动态模型
  • 功能模型
  • 3种模型之间的关系
  • UML
  • 示例
• 参考资料

第一章

1.1 软件危机

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的。实际上，几乎所有软件都不同程度地存在这些问题。概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。

消除软件危机的途径

1.技术措施
使用更好的软件开发技术、开发工具、开发工具。

2.组织管理措施
（1）创造良好的组织、严密的管理与协调工作的机制软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
（2）摆脱软件危机的主要出路是，按工程化的原则和方法组织软件的开发工作。
（3）强调文档的重要性。

1.2 软件工程

概括来讲，软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，吧经过时间考验而证明正确的管理技术和当前能够得到的最好的技术结合起来，经济地开发出高质量的软件并有效的维护它，这就是软件工程。

1993年IEEE（电气电子工程师学会）给出的一个更全面的定义。
软件工程是：1 把系统化的、规范的、可度量的途径用于软件开发、运行和维护的过程，也就是把工程化应用与软件中；2 研究 1 中提到的途径

1.3 软件工程知识体系

IEEE在2004年发布的《软件工程知识体系指南》中将软件工程知识体系划分为以下10个知识领域。

1 软件需求（software requirements）
软件需求表达了为解决某些真实世界问题而施加在软件产品上的要求和约束。软件需求的主要类型包括：产品与过程，功能性与非功能性，突出的属性。软件需求知识领域涉及软件需求的抽取、分析、规格说明和确认。软件工业界一致认同的就是如果这些工作完成得不好，软件工程项目就很容易失败。

2 软件设计（software design）
软件设计是一个过程和这个过程的结果，此过程对一个系统或组件定义架构（architecture，也叫体系结构）、组件、接口以及其他特征。在这项活动中分析软件需求以产生一个软件内部结构的描述，此描述将成为软件构建的基础。

3 软件构建（software construction）
软件构建指的是如何创建产生软件的详细步骤，这其中包括编码、验证、单元测试、集成测试和调试。

4 软件测试（software testing）
测试是一个标识产品的缺陷和问题的活动。测试的目的是为了评估和改进产品质量。
软件测试通过使用有限的测试用例来动态地验证程序是否能达到预期的行为。有限的测试用例是从通常情况下有无限可能性的执行领域中适当地选取出来的。

5 软件维护（software maintenance）
软件开发工作的结果就是交付一个满足用户需求的软件产品。软件产品一旦投入运行，产品的缺陷就会被逐渐地暴露出来，运行的环境会逐渐发生变化，新的用户需求也会不断地浮出水面。软件维护就是要针对这些问题而对软件产品进行相应地修改或演化，从而修正错误，改善性能或其他特征，以及使软件适应变化的环境。

6 软配置管理（software configuration management）
软件配置管理（Software Configuration Management，SCM）是一项跟踪和控制软件变更的活动。

7 软件工程管理（software engineering management）
软件工程管理是软件的开发和维护的管理活动，为了达到系统的、遵循规程的和可量化的目标，它包括计划、协调、度量、监控、控制和报表。

8 软件工程过程（software engineering process）
可以在两个层次上分析软件工程过程领域，第1个层次包括软件生命周期过程中技术的和管理的活动，它们是在软件获取、开发、维护和退出运行中完成的。第2个层次是元层次，涉及软件生命周期过程本身的定义、实现、评估、管理、变更和改进。

9 软件工程工具和方法（software engineering tools and methods）
软件开发工具是用于辅助软件生命周期过程的基于计算机的工具，工具可以将重复并明确定义的动作自动化，减少了软件工程师的认知负担，使软件工程师可以集中在开发过程的创造性方面。
软件工程方法的目标是使软件工程活动系统化并最终更可能成功。

10 软件质量（software quality）
对于Phil Crosby，质量就是“遵从用户需求”，Watts Humphrey认为质量就是
“达到适合使用的卓越层次”。IBM发明了术语“市场驱动的质量”，它基于达到全面的客户满意，关于组织质量的Baldrige准则使用了一个类似的短语“客户驱动的质量”，将客户满意作为主要的考虑。在ISO9001-00中，质量被定义为“一组内在特征满足需求的程度”。

第二章

软件过程

软件工程过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
本章讲述在软件生命周期全过程中应该完成的基本任务，并介绍各种常用的过程模型。

2.1 软件生命周期（SDLC，Systems Development Life Cycle）

1.软件定义：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制订工程进度表。这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件定义时期通常进一步划分为3个阶段，即问题定义、可行性研究和需求分析。

2.软件开发：具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：概要设计、详细设计、编码和单元测试、综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

3.运行维护：当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

2.1.1 基本任务

问题定义
通过调研，系统分析员应该提出关于问题性质、工程目标和工程规模的书面报告，并且需要得到客户对这份报告的确认

可行性研究
确定上一个阶段的问题是否有行得通的解决办法
用最小的代价在尽可能短的时间内确定问题是否能够解决。

需求分析
解决“目标系统必须做什么”这个问题可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法，因此许多细节被忽略了。然而在最终的系统中却不能遗漏任何一个微小的细节
是用正式文档准确地记录对目标系统的需求，该文档通常称为规格说明（specification）。

概要设计
概括地回答“怎样实现目标系统概要设计又称为初步设计、逻辑设计、高层设计或总体设计。
设计几种可能的方案
推荐最佳方案
制定详细计划
模块化

详细设计
将抽象概括的方式具体化
设计出程序的详细规格说明
详细设计也称为模块设计、物理设计或低层设计。在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。

编码和单元测试
这个阶段的关键任务是写出正确的，容易理解、容易维护的程序模块
程序员应该根据目标系统的性质和实际环境，选取一种适当的高级程序设计语言（必要时用汇编语言），把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试编写出的每一个模块。

综合测试
这个阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。最基本的测试是集成测试和验收测试。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验。
集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。
验收测试则是按照规格说明书的规定（通常在需求分析阶段确定），由用户（或在用户积极参加下）对目标系统进行验收。

软件维护
通过各种必要的维护活动使系统持久地满足用户的需要。
改正性维护：也就是诊断和改正在使用过程中发现的软件错误
适应性维护：即修改软件以适应环境的变化
完善性维护：即根据用户的要求改进或扩充软件使它更完善
预防性维护：即修改软件为将来的维护活动预先做准备。

实际上每一项维护活动都应该经过提出维护要求（或报告问题），分析维护要求，提出维护方案，审批维护方案，确定维护计划，修改软件设计，修改程序，测试程序，复查验收等一系列步骤，因此，实质上是经历了一次压缩和简化了的软件定义和开发的全过程。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。

2.2 计划驱动的软件过程：Waterfall Model（瀑布模型，或称之为SDLC模型）

https://blog.csdn.net/az9996/article/details/88064598

1.阶段间具有顺序性和依赖性
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。

传统的瀑布模型

2.3 快速原型（Rapid Prototype）

快速原型（rapid prototype）是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程）

增量模型分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。每次用户都得到一个满足部分需求的可运行的产品，直到最后一次得到满足全部需求的完整产品。

难点：把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便。

从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看做一个整体，另一方面又要求开发人员把软件看做构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。

2.5 螺旋模型（spiral model）

使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型，图中带箭头的点画线的长度代表当前累计的开发费用，螺线旋过的角度值代表开发进度。

为避免使用喷泉模型开发软件时开发过程过分无序，应该把一个线性过程（例如，快速原型模型或螺旋模型中的中心垂线）作为总目标。但是，同时也应该记住，面向对象范型本身要求经常对开发活动进行迭代或求精。

2.7 Ration统一过程

Rational统一过程（rational unified process，RUP）是由Rational软件公司（已被IBM并购）推出的一个软件开发过程框架。所谓软件开发过程框架是指团队可以根据具体的项目组或软件开发企业的不同需求，能够定义、配置、定制和实施一致的软件开发过程。

核心元素

1.用于成功开发软件的一组基本观念和原则。
2.一套关于可重用方法内容和过程构建的框架。
3.基础的方法和过程定义语言。

最佳实践

1.迭代式开发：迭代式开发允许在每次迭代过程中需求发生变化，这种开发方法通过一系列细化来加深对问题的理解，因此能更容易地容纳需求的变更。也可以把软件开发过程看做是一个风险管理过程，迭代式开发通过采用可验证的方法来减少风险。

极限编程的迭代过程

HIPO图是美国

来源：枪枪枪