软件工程概述

软件危机

是指在计算机软件的开发和维护过程中所遇见的一系列严重问题。

具体问题:

• 对软件开发成本和进度估计不准
• 用户对已完成的软件系统不满意
• 软件产品质量靠不住
• 软件不可维护
• 软件没有适当的文档资料
• 软件成本逐年上升
• 软件生产速度跟不上计算机应用普及速度

软件工程

软件工程就是指导计算机软件开发和维护的一门工程学科。

具体定义

• 把系统、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；
• 研究一中提到的途径。

软件工程的基本原理

• 用分阶段的生命周期计划严格管理
• 坚持进行阶段评审
• 实行严格的产品控制
• 采用现代程序设计技术
• 结果应能清楚的审查
• 开发小组的人员应该少而精
• 承认不断改进软件工程实践的必要性

软件工程方法学

包含三个要素：方法、工具和过程

传统方法学

面向对象方法学

• 把对象作为融合了数据及在数据上的操作行为统一的软件构件
• 把所有的对象都划分为类
• 按照父类和子类的关系，把若干个相关类组成一个层次结构的系统。
• 对象彼此间仅能通过发送消息互相联系。

软件生命周期

三个周期、八个阶段

软件定义、软件开发、运行维护

软件定义

• 问题定义
• 可行性研究
• 需求分析

软件开发

• 总体设计
• 详细设计
• 编码和单元测试
• 综合测试

前两个称为系统设计，后俩称为系统实现

运行维护

• 运行维护

软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定类完成各项任务的工作步骤
通常使用生命周期模型简洁地描述软件过程

瀑布模型

特点：顺序性、依赖性

瀑布模型（Waterfall Model） 是一个软件生命周期模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

核心思想

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

优缺点

优点

可强迫开发人员采用规范的方法（如结构化技术）；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

缺点

瀑布模型是由文档驱动，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。

分类

传统瀑布模型

特点

(1) 阶段间具有顺序性和依赖性

必须等前一阶段的工作完成之后，才能开始后一阶段的工作。前一阶段的输出文档就是后一阶段的输入文档。

(2) 推迟实现的观点

清楚的区分逻辑设计与物理设计，尽可能推程序的物理实现，是因为编码之前阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性的后果。实践也表明，对于规模较大的软件项目来说，往往编码开始得越早最终完成开发工作所需要的时间反而越长。

(3) 质量保证的观点

每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。

每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

加入迭代过程的瀑布模型

原因：

传统的瀑布模型过于理想化，人在工作过程中不可能不犯错误。

特点：

当后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。

快速原型模型

快速原型模型（Rapid prototype）是需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。

核心思想

快速原型模型是快速建立一个能反映用户主要需求的原型系统（prototype），让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户在试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用。一旦用户认为这个原型系统确实能做到他们所需要的工作。开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。

优缺点

优点

快速原型模型是不带反馈环的，软件产品的开发基本上是按线性顺序进行的。

原型系统已经通过与用户交互而得到验证，据此产生的规格说明正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。

开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎么不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

缺点

快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

增量模型

增量模型也称为渐增模型，把软件产品作为一些列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。分解时唯一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。

优点

能在较短时间内向用户提交可完成一些有用的工作的产品。

逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

缺点

使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品，软件体系结构必须是开放的，相比其他的开发模型需要更精心的设计。

从某种意义上说，增量模型本身是自相矛盾的。它一方面要求开发人员把软件看做一个整体，另一方面又要求开发人员把软件看做构件序列，每个构件本质上都独立于另一个构件。因此需要项目管理人员对全局把握的水平较高。

螺旋模型

特点：瀑布模型（系统化）+快速原型（迭代过程）+风险分析。

螺旋模型（Spiral Model）的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简单方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。

一个螺旋式周期：

确定目标，选择方案，选定完成目标的策略

风险角度分析该策略

启动一个开发阶段

评价前一步的结果，计划下一轮的工作

优缺点

优点

对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。

减少了多个测试（浪费资金）或测试不足（产品故障多）所带来的风险。

更重要的是，在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。

螺旋模型主要适用于内部开发的大规模软件项目。

缺点

螺旋模型的主要优势在于，它是风险驱动的。除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常。

喷泉模型

优缺点

优点

喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动.该模型的各个阶段没有明显的界限,开发人员可以同步进行开发.其优点是可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程.

缺点

由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理.此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况.

Rational统一过程

RUP总结了经过多年商业化验证的6条最有效的软件开发经验，这些经验称为“最佳实践”

最佳实践

• 迭代式开发
• 管理需求
• 使用基于构件的体系结构
• 可视化建模
• 验证软件质量
• 控制软件变更

核心概念

• 角色：RUP预先定义了许多角色，角色描述了在项目开发中，一个人或者一个开发团队的工作职能与任务。
• 活动：它是一个有明确功能的独立模块，反映了系统的某个功能。
• 工件：是在活动进行过程中产生、创建或修改的一段信息，同时也是项目开发的文档资料。
• 此外，与这些核心概念相关的内容还有检查点、模板、工作指南、报告、工具指南等。

三大特点

RUP最重要的它有三大特点：

1）软件开发是一个迭代过程

2）软件开发是由Use Case驱动的

3）软件开发是以架构设计（Architectural Design）为中心的

迭代模型

RUP强调软件开发是一个迭代模型(Iterative Model)，它定义了四个阶段(Phase)：初始(Inception)、细化(Elaboration)、构造(Construction)、交付(Transition)。其中每个阶段都有可能经历以上所提到的从商务需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段，例如开发实现的高峰期是发生在构造阶段。实际上这样的一个开发方法论是一个二维模型，这种迭代模型的实现在很大程度上提供了及早发现隐患和错误的机会，因此被现代大型信息技术项目所采用。

用例驱动

RUP的另一大特征是用例驱动。用例是RUP方法论中一个非常重要的概念。简单地说，一个用例就是系统的一个功能。在系统分析和系统设计中，用例被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是用例。然后以每个小的单元为对象进行开发。按照RUP过程模型的描述，用例贯穿整个软件开发的生命周期。在需求分析中，客户或用户对用例进行描述，在系统分布和系统设计过程中，设计师对用例进行分析，在开发实现过程中，开发编程人员对用例进行实现，在测试过程中，测试人员对用例进行检验。 [2]

以架构为中心

RUP的第三大特征是它强调软件开发是以构架为中心的。构架设计(ArchitecturalDesign)是系统设计的一个重要组成部分。

敏捷过程与极限编程

敏捷过程

客户和价值驱动的模型

四个简单的价值观声明组成

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

极限编程

极限编程是敏捷过程中最有名的一个

极限编程的有效实践

• 客户作为开发团队的成员
• 使用用户素材
• 短交付周期
• 验收测试
• 结对编程
• 测试驱动开发
• 集体所有
• 持续集成
• 可持续的开发速度
• 开放的工作空间
• 及时调整计划
• 简单的设计
• 重构
• 使用隐喻