软件危机（understanding）
软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题
软件危机的表现
- 对开发成本和进度的估计往往很不准确
- 用户对“已完成的”软件系统不满意的现象时常发生
- 软件质量差
- 软件通常难以维护
- 软件没有适当的文档资料
- 软件成本在计算机系统的总成本中所占的比例逐年上升（软件成本日益增长）
- 软件开发速度跟不上计算机发展速度
产生软件危机的原因
消除软件危机的途径
软件工程(understanding)
1968第一届NATO会议：
软件工程称就是为了经济的获得可靠的且在实际机器上有效运行的软件，而建立和使用的完善的工程原理
1993年IEEE：
- 把系统的、规范的、可度量的途径应用于软件开发、运行和维护的过程，也就是把工程应用于软件
- 研究1中提到的途径
主要目标：高效开发高质量软件
软件工程的基本原理
- 用分阶段的生命周期计划严格管理
- 坚持进行阶段评审
- 错误发现的越晚，所需付出的代价也越大
- 对每个已完成的阶段进行评审，以便尽早发现错误
- 实行严格的产品控制
- 软件开发过程中不应该随意改动需求，对修改意见需要经过严格的评审后才能实施
- 采用现代化程序设计技术
- 结果应该能清楚的审查
- 开发小组的成员应该少而精
- 承认不断改进软件工程实践的必要性
软件工程方法学
通常把在软件生命周期全部过程各种使用的一整套技术方法的集合称为方法学（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
- 适用范围：
- 项目团队的人数不能太多
- 项目经常发生变更
- 高风险的项目实施
- 开发人员可以参与决策
- 敏捷软件开发宣言
