软件工程学习笔记Ⅰ_常用的软件工程方法范形-CSDN博客

软件危机（understanding）

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

软件危机的表现
- 对开发成本和进度的估计往往很不准确
- 用户对“已完成的”软件系统不满意的现象时常发生
- 软件质量差
- 软件通常难以维护
- 软件没有适当的文档资料
- 软件成本在计算机系统的总成本中所占的比例逐年上升（软件成本日益增长）
- 软件开发速度跟不上计算机发展速度
产生软件危机的原因
- 技术原因
```
*   软件规模越来越大
```
  - 软件复杂度越来越高
  - 管理原因
    - 软件开发缺乏正确的理论指导，过分依赖个人技巧和创造性
  - 对用户需求没有完整准确的认识，就匆忙着手编写程序
  - 引入统一变动付出代价随时间变化的趋势

上图展示的就是软件开发过程中，需求变化出现在开发过程的后期将会带来巨大的修改代价
所以应该在软件开发的早期，甚至是定义的时候就尽量的接近用户的真是需求
但通常，用户的牙膏不会一下子挤完（甚至一开始，大多数用户对自己的需求都不是很明确）> 如何克服软件危机？ ==> 软件工程
消除软件危机的途径
- 对计算机软件的正确认识
  - 1983年IEEE对软件的定义：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必须的数据
  - 软件 ≠ 程序
  - 软件工程三要素
    - 推广使用开发软件成功的技术和方法，并且研究探索更好有效的技术和方法
  - 开发和使用更好的软件工具
  - 需要组织管理措施（过程）
  - 总之，为了解决软件危机，既要有技术措施（方法和工具），有要有必要的组织管理措施。
  无章法（个人英雄主义）=> 工程项目管理模式（团队合作开发）

软件工程(understanding)

1968第一届NATO会议：
软件工程称就是为了经济的获得可靠的且在实际机器上有效运行的软件，而建立和使用的完善的工程原理

1993年IEEE：

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

主要目标：高效开发高质量软件
软件工程的基本原理
1. 用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
```
    *   错误发现的越晚，所需付出的代价也越大
```
  - 对每个已完成的阶段进行评审，以便尽早发现错误
  1. 实行严格的产品控制
```
*   软件开发过程中不应该随意改动需求，对修改意见需要经过严格的评审后才能实施
```
  2. 采用现代化程序设计技术
3. 结果应该能清楚的审查
4. 开发小组的成员应该少而精
5. 承认不断改进软件工程实践的必要性
软件工程方法学

通常把在软件生命周期全部过程各种使用的一整套技术方法的集合称为方法学（methodology）
,也称为泛型（paradigm）

软件工程方法学3要素

方法：“如何做？”
工具：“用什么做？”
过程：“如何控制、协调、保证质量？”
传统方法学（静态分析）
- 传统方法学也称为生命周期方法学或结构化泛型，它采用结构化技术
这种方法学把软件生命周期的全过程依次划分为若干阶段，然后顺序的完成每个阶段的任务
特点：
```
        *   生命周期模型
```
- 软件过程划分为若干个阶段
- 每个阶段有各自的任务
- 阶段之间有某种顺序性
  - 局限：
```
*   当软件规模较大，或对软件的需求是**模糊**的或随时间**变化**的时候，使用结构化泛型开发软件往往不成功
```
- 此外，使用传统方法学开发出的软件通常维护起来都很困难

面向对象方法学（动态分析）

*   特点：

            *   面向对象方法学的出发点和基本原则，是**尽可能模拟人类的思维方式**
*   用面向对象方法学开发软件的过程，是一个**主动**多次**反复迭代**演化的过程
*   概念和表示方法上的**一致性，阶段间平滑（无缝）过度**
*   特殊到一般的**归纳**思维过程；一般到特殊的**演绎**思维过程（继承的思想）

软件生命周期 (重点)

概括的说，软件生命周期由软件定义、软件开发和运行维护（也称为软件维护）3个过程

问题定义

要解决什么问题？

可行性研究

对上一阶段确定的问题是否有行之有效的解决方案？

需求分析

目标系统必须做什么？

用正式的文档记录对目标系统的需求（**规格说明**）

总体设计（概要设计）

概括的说，应该怎样实现目标系统？（从此阶段开始设计实现和技术的细节）
又称为**初步设计、逻辑设或、概要设计或高层设计**

详细设计

把上阶段提出的解决方案具体化，回答“应该如何具体的实现这个系统？”
又称为**模块设计、物理设计或低层设计**

编码和单元测试

具体coding。写出正确的容易理解、容易维护的程序模块，并测试

综合测试

集成测试、验收测试、系统测试

软件维护

通过各种必要的维护活动使系统持久地满足用户的需要

*   #### [](#四类维护活动 "四类维护活动")四类维护活动

        *   **改正性维护**：诊断和改正真在使用过程中发现的软件错误
    *   **适应性维护**：即修改软件以适应环境的变化
    *   **完善性维护**：即根据用户的要求改进或扩充软件使它更完善
    *   **预防性维护**：即修改软件为将过来的维护活动预先做准备

软件过程（重点）

软件过程是为了获得赶工质量软件所需要完成的一些列的任务的框架，它规定了完成各项任务的工作步骤

瀑布模型
- 阶段间具有顺序性和依赖性
- 推迟实现的观点
  
  清楚的区分逻辑设计与物理设计，尽可能推迟程序的物理实现
  - 质量保证的观点
    - 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务
  - 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误> 瀑布模型的成功过在很大程度上由于它基本上是一种文档驱动的模型
- 优点：
  可强迫开发人员采用规范的方法（例如，结构化技术）；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
- 缺点：
  瀑布模型是由文档驱动的。由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
- 适用范围：
  应用需求明确的项目
快速原型模型
- 快速建立起可以运行的程序，其功能往往是最终产品功能的子集
- 通过将简单的模型给用户试用，以获取到用户更多更详细的需求（努力挤牙膏）
- 快速原型的本质是“快速”
- 原型的用途是获取用户的真正需求，一旦需求确定了，原型将被抛弃（原型通常没有严格的规范化，缺少文档，难以维护）。
- 优点：软件产品的开发基本上是线性顺序进行的
```
    *   原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求，，不会因为规格说明文档的错误而进行较大的返工。
```
  - 开发人员通过建立原型系统已经学到了许多东西，在设计编码阶段发生错误的可能性比较小，自然减少了反馈。
  - 缺点：
```
*   缺乏丰富而强有力的软件工具和开发环境。
```
  - 缺乏有效的管理机制，还未建立起自己的开发标准。
  - 对设计开发环境要求较高。
  - 在多次重复改变原型的过程中，程序员会感到厌倦。
  - 系统的易变性对测试有一定影响，难于做到彻底测试，更新文档较为困难。
  - 适用范围：有结构的系统或者需求不明确的系统
增量模型
- 增量模型也称为渐增模型。把软件产品作为一系列增量构件来设计、编码、集成和测试
- 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
- 使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。(滚雪球方式)
- 与瀑布模型相比：
```
    *   瀑布模型：力求一次性给用户完整的系统。
```
  - 增量模型：逐步增加系统功能。
  - 增量模型：
- 一种风险更大的增量模型
  - 优点：
    - 能在较短时间内向用户提交可完成部分工作的产品
  - 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
  - 缺点：待解决的问题必须允许有一个可递增的软件解决方案。如果需要的软件必须将所有的功能表现出来，那么递增的模型是不合适的。还有就是为了递增模型成功，必须找出整个系统的体系结构。
- 适用范围：不能在设定的期限内完成产品时，先推出核心产品
  - 使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开过程
螺旋模型
- 螺旋模型的基本思想是使用原型及其他方法尽量降低风险。
- 简化的螺旋模型
- 可以在一定程度上降低风险，但对有些风险也是无能为力的
- 需要专业的风险评估人员
- 完整的螺旋模型
- 优点：
```
    *   对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
```
  - 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险
  - 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别
  - 缺点：仅适用于内部项目，大型项目受限，需要风险分析专家。
- 适用范围：主要适用于内部开发的大规模软件项目。
喷泉模型
- 迭代是OO开发过程的主要特性。
- 喷泉模型是典型的面向对象生命周期模型。
- “喷泉” 体现了面向对象软件开发过程迭代和无缝的特性。
- 为避免喷泉模型的过分无序，把一个线性过程作为总目标。
- 迭代：逐步求精
- 阶段间没有明显的界限－面向对象的思想保证了各个阶段开发的一致性。
- 喷泉模型：
Rational统一过程
敏捷过程与极限编程
- 敏捷软件开发宣言
```
    *   **个体和交互胜过过程和工具**（Individuals and interactions over processs and tools）
```
  - 可以工作的软件胜过面面俱到的文档（Working software over comprehensive socumentation）
  - 客户合作胜过合同谈判（Customer collaboration over contract negotiation）
  - 响应变化胜过遵循计划（Responding to change over following a plan）
  - 敏捷软件开发的原理（The principles of agile methods）
```
*   客户参与（Customer involvement）
```
  - 增量交付（Incremental delivery）
  - People not process
  - 拥抱变化（Embrace change）
  - 保持简单（Maintain simplicity）
  - 极限编程有效实践（极限编程是敏捷过程中最富盛名的一个）
```
*   Incremental planning
```
  - Small releases
  - Simple design
  - Test-first development
  - Refactoring
  - Pair programming
  - Collective ownership
  - Continuous integration
  - Sustainable pace
  - On-site customer
  - 适用范围：
```
1.  项目团队的人数不能太多
```
  1. 项目经常发生变更
  2. 高风险的项目实施
  3. 开发人员可以参与决策