系统架构师主题整理之一：软件系统开发模型及其应用

1 软件开发常见模型及其概念

  瀑布模型

  原型模型

  螺旋模型

  基于可重用构件的模型

  面向对象模型

  基于第四代技术的模型

  

新版教材，模型划分有一些变化，如下：

  瀑布模型

  原型化模型

  螺旋模型

  敏捷模型

  统一过程模型

  软件能力成熟度模型

  

下面对这几个点都进行一个简单的说明。

首先是瀑布模型。这个大家都很了解。这是传统软件开发中常用的模型，整个开发过程基本按顺序执行各个阶段的开发活动，如需求分析、系统设计、程序设计、编码实现、单元测试、集成测试、系统测试及运行维护。采用这一开发模型，有其原因。早期软件的复杂度没有那么高，应用领域也是比较受限于专业性或行业性特点比较明显的领域，传统的设计工作方式也深刻影响了软件的开发方式，比如都是先设计图纸，再实施。另外，这种方式与早期结构化开发语言也比较契合，符合人们分模块，从上而下认识事物的习惯，所以早期的软件开发大都采用了这一模型。

整个瀑布模型比较强调需求和设计的重要性。如何开发到后期，发现需求有误差，那么整个开发工作就会受到很大的影响。所以，这种方式比较适合需求比较明确，领域比较成熟，有很多成功的案例或设计可供参考，特别是有基线版本的场景。这样，整个工程的可控性就会比较好，否则，风险会比较大。自然，这种开发方式就不太适合新的领域，需求模糊，变动较大的项目。

  

下一个来看原型化模型。名称中的原型就是用来约束需求的。随着软件开发应用领域面的极速增加，软件开发复杂度的快速提升，软件开发规模的不断扩大，开发稳定可靠的软件产品就越来越难。这其中一个重要的影响因素就是需求的获取和明确。很多时候，客户自己也并不是很清楚需求，特别是对软件能够做到的边界不是很清楚的情况下。这时候就需要开发人员与客户共同挖掘需求。那么这个过程中，需求的变动就会是剧烈的，自然不适用于像瀑布这种先定好需求再开发的场景。为了应对这种情况，我们发展了原型开发模型。通过原型，客户可以对软件有一个大致面貌，这样可以更好的搭建技术人员与用户的桥梁。实际中，有的原型是可以保留下来，不断迭代完善，从而进入最终产品的；有的原型可以对部分技术点的可行性进行验证。

  

第三个看螺旋模型。名字都是很形象的。螺旋形状，既有水平相对固定的截面，又有垂直不断提升的高度。螺旋模型特别强调风险控制。每一个水平截面基本包括目标设定、风险评估、开发和有效性验证以及评审。之后进入下一个目标开发周期。该过程适用于各种开发方法支持的软件系统，比如面向过程和面向对象，以及面向规格说明的开发方法。因为有完善的风险分析控制和评审机制，适用于大型软件开发。

  

下面再来看看迭代和增量。迭代很好理解，就是一个版本一个班不断的演进，每个版本都更加靠近最终版本一点。总体来讲，就是小步快跑的模式，稳中求进。增量也不难理解，每次增加一块功能，集成测试，再增加一块。初看，这两种方式似乎你中有我、我中有你，区别在哪？主要抓住这一点，迭代强调的是总体，每次是最终版本的一个近似，而增量强调的是部分，每次增加一个功能块，有点拼图拼接的意味。

从现实来看，迭代和增量是一种比较小的方法论，对于软件这种大工程，说是迭代还是增量，显得不够准确全面。现代软件工程，迭代和增量的方法一定是在各个模块各个阶段都有应用的，很多都是不自觉的会使用到。

  

面向对象模型，这主要针对结构化开发方法而言。涉及对软件的分析、建模、开发整个过程，都采用到了面向对象的思想。采用UML建模方法，通过用例图（做需求分析）、类图（面向对象设计）、对象图（对象识别）、包图（对象归类）、交互图（消息传递关系，分按时间序列的顺序图和结构序列的协作图。顺序图也叫时序图）、状态图（状态机）、活动图（控制流和信息流）、构件图（文件或库）、部署图（物理层面）等建立对开发过程涉及的需求、设计、实现、部署、更新、维护、测试等全链条活动的支持。UML2.0版本名称有所变化，出现了通信图（协作图）、序列图（顺序图、时序图）、组合结构图（包含部件及关系）、交互概览图（顺序图加活动图）以及计时图。

  

敏捷模型。敏捷模型不是一种具体的开发方法，而是一种开发思想，强调以人为本，面向人而非面向过程的，是适应性的，而非预设性的，因此是拥抱变化而非限制变化的。敏捷模型产生的出发点主要有两点：一是软件工程复杂性带来的需求不确定性。简而言之，就是需求经常变化，敏捷要拥抱这种变化。二是软件工程庞大复杂带来的信息共享困难。信息在传递过程中就会存在损失，传递链条越多，损失就越多。而且，不仅可能损失，还可能产生畸变。这为开发的一致性、可控性带来巨大挑战。敏捷强调以人为本，强调开发人员之间甚至开发人员与用户之间直接的沟通交流。这种直接交流不仅仅是信息直达，而且最好是面对面的，物理空间上的面对面。这种方式在信息传递的准确性和效率提升上是文档、远程会议等方式无法比拟的。在具体实践过程中，敏捷方法以原型开发思想为基础，采用迭代增量式开发，每一个新版本都是在前一个成功版本基础上进行的扩充，因此成功的概率大大增强。

  

统一过程模型，即RUP。软件的复杂性决定了通过任何一个角度，都无法完整的定义这个过程，天生就是需要多角度视角来观察的。可通过4+1视图（逻辑视图、实现视图、进程视图、部署视图+用例视图）多方位看待和控制软件开发。RUP有9个核心工作流，4个周期段，4个核心概念，3个特点。9个核心工作流是业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。大概了解一下即可。4个周期段是初始、细化、构造、移交。4个核心概念是角色who、活动how、制品what和工作流when。3个特点是用例驱动、以体系结构为中心、迭代与增量开发。

RUP与UML建模密不可分，整个过程也是贯穿了面向对象的设计方法。

  

软件能力成熟度模型即CMMI。这是从开发能力角度，对软件开发可控性、可靠性等进行评价的一个技术体系。主要出发点是认为软件开发过程的可控性决定了软件产品质量的可控性。主要分为5个等级：初始级、已管理级、已定义级、量化管理级以及优化级。

  初始级：管理混乱或者说没有管理；

  已管理级：有了管理，有了基本监督和控制，能进行成本、进度、质量目标的管理。

  已定义级：有了管理，且能够因地制宜，将管理体系和流程制度化，软件产品质量有一定可控性。

  量化管理级：在3级基础上实现了定量可控制，过程可预测。

  优化级：继续改进。

软件能力成熟度模型是一个评价标准，不是一个方法体系。强调的是软件开发过程的各个阶段要有质量把控，而具体采取什么方法，并没有统一标准，因此，个人理解，这并不能算是一种开发模型。

  

2 常见开发模型在实际系统中的应用、或实际产品、项目中用到了哪些模型

因为现代软件系统的庞杂特性，实际中，可能存在多个开发方法的使用，而非一种方法从头用到尾。如某电力系统项目中，采用了多种开发模型：

  

终端产品和已有业务模块属于定制开发，主要在配置上进行了优化，因此采用了瀑布模型。因为其适用于成熟业务，按部就班，便于管理和控制。这部分的开发，文档先行，整理需求，让后评审，接着设计，评审，之后开发，进度跟踪，测试介入，确认目标是否达成。虽然整体看着是比较清晰完整的，但是实施过程中，还是有一些问题。比如，支持旋转功能后影响了内存的使用，这是之前没有想到的；支持加密功能后，内网IP地址影响原有节点的搜索功能；删除部分功能代码后，影响了遗留的关联逻辑，产生了多米诺骨牌效应，传导了更多模块。因此，即便是采用瀑布模型，也要对关键需求变更进行充分验证，切不可大意。

集成新业务板块，采用了敏捷开发。因为需要通过可视化方式展示电力线路图，对于线路标准缺乏足够的专业知识，且项目时间紧迫，因此将开发人员和行业客户安排在一起，集中办公，面对面交流，提高开发效率，避免出现专业基础性方面的错误，导致重大事故的发生。具体业务实现上，根据重要性设定backlog，然后按sprint并行进行工作开展，之后进行集成验证，并做retrospective对下一个阶段的工作进行改进。

基础业务与新业务的集成，采用了增量方法。增量模型围绕系统核心，一个模块一个模块不断实现、整合、测试，最终完成整体系统的开发，因此比较适合已有基础业务，需要整合新业务的场景。

当然，每个模块的内部的开发，又是迭代螺旋的过程。每次增加一个特性后设定目标，需要评估风险和影响，然后开发、测试、集成、验证，通过评审后进入下一个目标周期，一次不断完善整个模块。

整体开发方法上来看，又是面向对象的。使用对象建模，结合用例图、类图、对象图、时序图、状态图、构件图、部署图、活动图等指导需求分析、设计、开发、集成、测试、部署等各个开发过程。