软件开发模型

第一次接触软件工程还是在学校的课本上，初识软件开发模型（或软件生命周期模型），工作几年之后对其终于有了一些了解。
趁着这次读《系统架构设计师教程》，做个读书笔记。

¶软件开发生命周期

​ 传统的软件生命周期是指软件产品从形成概念开始，经过定义、开发、使用和维护，直到最后被废弃（不能再使用）为止的全过程。

¶软件开发模型

​ 软件生存周期模型又称软件开发模型（software develop model）或软件过程模型（software process model），它是从某一个特定角度提出的软件过程的简化描述。

​ 软件过程模型的基本概念：软件过程是制作软件产品的一组活动以及结果，这些活动主要由软件人员来完成，软件活动主要如下：

• 软件描述

• 软件开发

• 软件有效性验证

• 软件进化

软件过程模型是软件工程的重要内容，它为软件工程管理提供里程碑，为软件开发过程提供原则和方法。

¶瀑布模型

瀑布模型（waterfall model）可以说是最早使用的软件生命周期模型之一。该模型描述的活动从一个阶段到另一个阶段逐次下降，它的工作流程形式上又很想瀑布，该模型如下图所示：

特点:

• 阶段间具有顺序性和依赖性:
  • 因果关系紧密相连：前一阶段完成后，才能开始后一阶段。
  • 前一个阶段工作的结果是后一个阶段工作的输入
• 质量保证:
  • 每个阶段必须交付出合格的文档
  • 对文档进行审核

缺点：

• 软件需求分析的准确性很难确定
• 初始版本周期长
• 如果改变需求，代价巨大

¶原型模型

​ 原型模型（prototype model）又称快速原型。由于瀑布模型的缺点，人们借助建筑师、工程师建造原型的经验，提出了原型模型。原型模型主要有两个阶段，如下图所示：

• 原型开发阶段：根据用户提出的软件系统定义，快速地开发一个原型。
  • 利用模拟软件系统的人机界面和人机交互方式。
  • 真正开发一个原型。
  • 找一个或多个正在运行的类似软件进行比较。
• 目标软件开发阶段。

使用原型模型应该注意：

• 要有一定的开发环境和工具支持。

• 经过对原型的若干次修改，应收敛到目标范围内，否则可能会失败。

• 用户对系统模糊不清，无法准确回答目标系统的需求。

• 对于大型软件来说，原型可能非常复杂而难以快速形成，如果没有现成的，就不应该考虑原型法。

¶螺旋模型

​ 螺旋模型（Spiral Model）是在快速原型的基础上扩展而成，实际上，它是软件生命周期模型与原型模型的一个结合，如下图所示：

该模型将整个软件开发流程分为多个阶段，每个阶段都由4部分组成：

• 目标设定
• 风险分析
• 开发和有效性验证
• 评审

螺旋模型的软件开发过程实际上是上述4个部分的迭代过程，每迭代一次，螺旋线就增加一周，代表软件的一个新版本。经过若干次迭代后，系统应尽快收敛到用户允许或可以接受的目标范围。

优点:

• 设计上的灵活性,可以在项目的各个阶段进行变更。
• 以小的分段来构建大型系统，使成本计算变得简单容易。
• 客户始终参为保证了项目不偏离正确方向以及项目的可控性。
• 客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。
• 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点:

​ 很难让用户确信这种演化方法的结果是可以控制的。建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

¶增量模型

增量模型（Incremental Model）把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件，如下图所示：

每个新的构件集成到现有的软件结构中必须破坏原来以开发的产品，所以必须定义很好的接口。

优点:

• 短时间内向用户提供可完成部分工作的产品。
• 逐步增加产品功能可以使用户有时间了解和适应新产品。
• 开放结构的软件拥有的维护性明显好于封闭结构的软件。

缺点：

• 容易退化为边做边改模型，从而使软件过程的控制失去整体性。
• 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析。

¶喷泉模型

​ 喷泉模型（fountain model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性，该模型如下图所示：

优点:

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

缺点:

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

¶敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，其核心思想主要有以下三点：

• 适应型，而非可预测型。
• 以人为本，而非已过程为本。
• 迭代增量式的开发过程。

敏捷开发知识体系整体框架

¶敏捷软件开发宣言

• 个体和交互胜过过程和工具。

  以人为本，强调个体及个体间的沟通与协作在软件开发过程中的重要性。

• 可以工作的软件胜过面面俱到的文档。

  目标导向，自解释的友好的代码和架构。

• 客户合作胜过合同谈判。

  客户为先，理解客户的需求，懂得如何与客户合作。

• 响应变化胜过遵循计划。

  拥抱变化，在客户断变化的需求中了解其真正的需要。

¶敏捷宣言遵循的原则

• 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

• 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

• 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

• 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

• 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

• 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

• 工作的软件是首要的进度度量标准。

• 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

• 不断地关注优秀的技能和好的设计会增强敏捷能力。

• 简单——使未完成的工作最大化的艺术——是根本的。

• 最好的构架、需求和设计是出自于自组织的团队。

• 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

¶敏捷设计

¶拙劣设计的症状

僵化性：设计难以改变。

脆弱性：设计易于遭到破坏。

牢固性：设计难以重用。

粘滞性：难以做正确的事情。

不必要的复杂性：过分设计。

不必要的重复：复制黏贴。

晦涩性：混乱的表达。

这些症状在本质上和代码的臭味相似，但是它们所处的层次稍高一些。它们是遍及整个软件结构的臭味，而不仅仅是一小段代码。

¶面向对象的设计原则

• SRP 单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。

• OCP 开放-封闭原则：软件实体（类、模块、函数等）应该是可以扩展的，但是不可修改。

• LSP Liskov替换原则：子类型必须能够替换掉它们的及类型。

• DIP 依赖倒置原则：抽象不应该依赖于细节，细节应该依赖于抽象。

• ISP 接口隔离原则：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。

23种设计模式：http://www.runoob.com/design-pattern/design-pattern-intro.html

我们最常用的spring框架就使用了很多种设计模式，例如BeanFactory中的工厂模式，AOP中的代理模式。

参考文献：

• 《系统架构设计师教程》
• 《敏捷软件开发(原则模式与实践)》