软件工程概述 | 软件工程1

软件工程概述

软件危机

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

具体问题:

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

软件工程

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

具体定义

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

软件工程的基本原理

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

软件工程方法学

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

传统方法学

面向对象方法学

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

软件生命周期

三个周期、八个阶段

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

软件定义

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

软件开发

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

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

运行维护

• 运行维护

软件过程

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

瀑布模型

特色：顺序性、依赖性

瀑布模型（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)是系统设计的一个重要组成部分。

敏捷过程与极限编程

敏捷过程

客户和价值驱动的模型

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

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

极限编程

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

极限编程的有效实践

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