软考高级之系统架构师系列之软件开发模型

概述

如标题所述。本文面向于软考高级，具体来说是系统架构师。

本文几乎是纯粹的理论知识汇总，用于应付软考，在理解基础上注意抠字眼。

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程，叫软件生存周期模型，又叫软件开发方法、软件开发模型（Software Develop Model）、软件过程模型（Software Process Model）。

分类	描述
结构化法	强调用户至上，严格区分工作阶段，每阶段都有任务和成果，强调开发过程的整体性和全局性，开发过程工程化，文档资料标准化，自顶向下逐步求精
原型法	适用需求不明确的开发，分为抛弃型原型和进化型原型
面向对象方法	更好的复用性，关键在于建立一个全面、合理、统一的模型
面向服务方法	SOA方法有三个主要的抽象级别：操作、服务、业务流程。 SOA分为三个层级：底层服务构件、服务接口与协议、服务流程编排。 服务建模：分为服务发现、服务规约和服务实现三部分

软件开发模型

大体来说，有3类：

• 软件需求完全确定为前提，可以采用瀑布模型；
• 软件开发初期阶段只能提供基本需求，可以采用迭代式或渐进式模型，如喷泉模型，螺旋模型、统一开发过程和敏捷方法、极限编程。开发人员对算法的效率，操作系统的兼容性和人机交互的形式不明确等情况下，快速原型开发
• 形式化为基础的变换模型

瀑布模型

特点：
阶段间具有顺序性和依赖性，前一阶段结束后才能开始后一阶段的工作，前一阶段的输出是后一阶段的输入；推迟实现观点，尽可能推迟程序的物理实现；强调质量保证观点，每个阶段必须完成规定的文档，每个阶段结束前完成文档以便及早改正错误。

瀑布模型可以说是最早使用的软件生存周期模型之一。由于这个模型描述软件生存的一些基本过程活动，所以它被称为软件生存周期模型。这些活动从一个阶段到另一个阶段逐次下降，形式上很像瀑布。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。

每一个阶段都是建立在前一个阶段的正确结果之上，前一个阶段的错误和疏漏会隐蔽地带入后一个阶段。这种错误有时甚至可能是灾难性的，因此每一个阶段工作完成后，都要进行审查和确认。

优点：

• 原理简单，容易掌握
• 各阶段间都有验证和确认环节，以便进行质量管理
• 主要用于支持结构化方法

缺点：

• 缺乏灵活性，不能适应用户的需求变化
• 缺乏演化性，返回上一级的开发需要付出十分高昂的代价
• 是线性的软件开发模型，回溯性差

适用场合：

• 适合于软件需求比较明确或很少变化，且开发人员可以一次性获取到全部需求的场合
• 适合开发技术比较成熟，工程管理比较严格的场合
• 一般用于低风险的项目，适合开发人员具有丰富的经验
  

原型模型

又称快速原型模型，是快速建立起来的可以在计算上运行的程序，是软件的一个早期可运行的版本，它的功能是最终产品的子集。用途主要是获取用户的真正的需求。

原型模型主要有两个阶段：

• 原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等
• 目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统

优点：

• 增强开发者于用户间的交流，有助于满足用户的真实需求
• 用户可及早得到有用的产品，可及早发现问题，随时纠正错误
• 减小技术、应用风险，可降低开发费用，缩短开发时间

缺点：

• 缺乏丰富而强有力的软件工具和开发环境
• 对设计人员及开发环境要求较高
• 难于做到彻底测试，更新文档较为困难

适用场合：

• 预先不能确切定义需求的软件系统，或需求多变的系统
• 开发人员对设计方案没信心或对将要采用的技术手段不熟悉或把握性不大
• 原型模型可作为单独的过程模型使用，也常被作为一种方法或实现技术应用于其他的过程模型中。

原型是软件系统的初始版本，用来演示概念并尝试设计选择，通常用来发现更多的问题和可能的解决方案。快速迭代式的原型开发能够有效控制成本，根据原型与最终产品之间的关系，原型开发分为三类：

• 抛弃式原型开发利用原型验证和澄清系统的需求描述，重新构造系统
• 演化式原型开发逐步改进和细化原型，将原型进化直至产生出目标系统
• 增量式原型开发在建立软件总体设计的基础上，采用增量开发方法，使原型成为最终系统

渐增模型

也叫增量模型，其实质上是分段的线性模型，是一种非整体开发模型，渐增模型把软件产品作为一系列增量构件来设计、编码、集成和测试，在项目开发过程中以一系列的增量方式来逐步开发系统。

优点：

• 可分批次提交软件产品，方便用户及时了解软件开发进展情况，及早发现问题
• 以组件为单位进行开发，降低软件开发风险
• 开发顺序灵活，优先级最高的服务首先交付

缺点：

• 由于对整个软件系统的需求没有一个完整的定义，会给总体设计带来麻烦
• 在把每个新的增量构件集成到现有软件结构中时，必须不破坏原来已开发出的产品
• 软件的体系结构必须是开放的，即向产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是可测试的，可扩充的

适用场合：

• 软件产品可以分批次地进行交互
• 待开发的软件系统能够被模块化
• 软件开发人员对应用领域不熟悉、难以一次性地进行软件开发时
• 项目管理人员把握全局的水平较高时
• 对软件需求把握不准确、设计方案有一定风险的项目

喷泉模型

喷泉一词体现迭代和无间隙特性，迭代是指开发软件系统时，某些部分经常要重复多次，相关功能在每次迭代中随之加入演进的系统。

特点：

• 各阶段相互重叠，反映软件过程的并行性
• 以分析为基础，资源消耗呈塔形，在分析阶段消耗的资源最多
• 反映软件过程迭代的自然特性，从高层返回低层无资源消耗
• 强调增量开发，依据分析一点设计一点为原则，不要求一个阶段完成，整个过程是一个迭代的逐步提炼过程

螺旋模型

螺旋模型是在结合瀑布模型与快速原型模型基础上演变而成，加入风险分析。

软考很恶心的地方在于抠字眼（单选题）：

• 有瀑布和原型两个选项，选择原型
• 有快速、原型、瀑布三个选项，选择快速

其基本思想，使用原型及其它方法来尽量降低风险。沿着螺线进行若干次迭代。两个显著特点：

• 采用循环的方式逐步加深系统定义和实现的深度，降低风险
• 确定一系列里程碑，确保项目开发过程中的相关利益者都支持可行的和令人满意的系统解决方案

在螺旋模型中，将软件过程表示为一个螺旋线，在螺旋线上的每一个循环表示过程的一个阶段。整个过程的实现按以下四个步骤完成：

• 指定计划：即目标设定，为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划
• 风险分析：对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险
• 工程实施：即开发和有效性验证，风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品
• 客户评估：即评审，对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。

适用场合：

• 适用于面向规格说明、面向过程和面向对象的软件开发方法
• 也适用于几种开发方法的组合和产生的组合模型

缺点：
要求开发人员必须具有丰富的风险评估经验和专门知识

形式化方法

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。

主要优越性：能够数学（精确）地表述和研究应用问题及软件实现。

但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难以为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。

净室软件工程

Cleanroom Software Engineering，CSE。

软件开发的一种形式化方法，使用盒结构规约（或形式化方法）进行分析与设计建模，并将正确性验证作为发现和消除错误的主要机制，采用统计测试来获取验证软件可靠性所需要的信息。

CSE强调在规约和设计上的严格性，以及使用基于数学的正确性来证明对设计模型的每个元素进行形式化验证。还强调统计质量控制技术，包括基于客户对软件的预期使用测试。

由三大关键技术：统计过程控制下的增量开发，基于函数的规范、设计和验证，以及统计测试和认证。

包含以下几个关键步骤：

• 需求分析：准确地定义软件需求，以确保软件产品满足用户的需求；
• 形式化规范：使用数学方法来描述软件系统的规范，这有助于精确定义系统的行为；
• 增量开发：软件是按照小的、可管理的部分逐步构建的，每一部分都要经过严格的测试和验证；
• 证明正确性：使用数学证明来验证软件的关键部分是否符合其规范；
• 统计质量控制：通过统计方法来控制和评估软件的质量。

结构化方法

结构化分析方法，是一种面向数据流的需求分析方法，其基本思想是自顶向下逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决。结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型：数据模型、功能模型和行为模型（状态模型）。在实际工作中，一般用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。

数据流图是进行结构化分析时所使用的模型，其基本成分包括数据流、加工、数据存储和外部实体。

在结构化设计时，通过对数据流图进行变换分析和事务分析可导出程序结构图。

结构化分析

结构化分析是结构化方法的重要组成部分，一般要依次进行以下工作：

• 目标分析：系统目标是指系统在开发完成后所应达到的境地或标准
• 环境分析：可分为对内部环境的分析和对外部环境的分析两方面。环境分析着重于对较宏观的情况的了解，并不过分要求某些细节问题和情况
• 业务分析：业务或业务活动是对企业或机构的一切专业工作和活动的总的称呼。一般都是将企业业务或业务活动按性质划分，并由若干机构来进行管理。业务分析应该从业务调查入手，首先了解企业的组织结构、绘制组织结构图，从与企业生产经营直接相关的机构开始，进行业务流程的调查，并绘制成业务流程图，并逐步扩展到系统边界内的其他机构
• 数据分析：主要内容为数据流程图和数据字典
• 效益分析：衡量信息系统效益的第一标准应该是系统是否投入使用，因为再好的系统如果放置不用，那就等于没有。使用过的系统，成功与否取决于其效益
• 逻辑模型的建立：逻辑模型即信息系统的功能模型，描述系统的总体构成、子系统划分和子系统的功能模块，并包括各子系统的业务流程和数据流程以及相关的数据定义和结构
• 系统分析报告：一个完整的计算机信息系统的分析报告应包括3个部分，一部分是应用分析；其次是系统的运行平台，它是针对应用所应提供的软件和硬件条件以及它们的结构和配置的分析；最后是系统对网络和通信的要求。3个部分是相互联系和密切相关的

结构化设计

结构化设计是以结构化分析的数据模型、功能模型和行为模型为基础，完成数据设计、体系结构设计、接口设计和过程设计。

数据设计

数据设计是把分析阶段创建的信息域模型转变成实现软件所需要的数据结构。可使用Jackson图来表示。

Jackson图和描绘软件结构的层次图形式相近，但是含义却有很大不同：

• 层次图中的一个方框通常代表一个模块；Jackson图中的一个方框并不代表一个模块，通常只代表几个语句；
• 层次图表现的是模块的调用关系；Jackson图表现的是组成关系。

Jackson图示例：

体系结构设计

体系结构设计确定程序的主要结构元素（即程序构件）之间的关系
。可使用HIPO图和Yourdon提出的结构图来表示。

HIPO图

Hierarchy plus Input-Process-Output，层次图加输入/处理/输出图，IBM发明。

层次图使用矩形框表示一个模块，用框间的连线表示模块的调用关系。如下图所示：

HIPO图在层次图里把除了顶层的方框之外的每个方框都加上编号，然后再使用一张IPO图描述这个方框代表的模块的处理过程。

IPO图的基本形式是在左边的框中列出输入数据，在中间的框中列出数据处理，在右边的框中列出输出数据。如下图所示：

也可使用IPO表来表示：

结构图

结构图和层次图类似，也是用一个方框代表一个模块，在框内注明模块的名字或主要功能，用方框之间的箭头（或直线）表示模块的调用关系。同时，在结构图中通常还用带注释的箭头表示模块调用过程中来回传递的信息，并且用注释箭头尾部的形状来区分数据信息和控制信息：尾部是空心圆表示传递的是数据，实心圆表示传递的是控制信息。此外，还可以使用一些附加的符号表示模块的选择调用或循环调用。结构图示例：

接口设计

接口设计的结果描述软件内部、软件与协作系统之间以及软件与使用它的人之间的沟通方式。接口用于传递数据，数据流图提供接口设计所需要的信息。

过程设计

过程设计把程序体系结构中的结构元素，变换成对软件构件的过程性描述。过程设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。

过程设计工具有很多种，包括图形、表格和语言三类。

程序流程图

程序流程图又称为程序框图，最熟悉、使用最广泛的工具。但由于程序流程图有很多缺点，如：诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构、不易表示数据结构等，所以很多专家都建议停止使用它。

盒图

Nassi和Shneiderman提出的盒图（N-S图）就是一种不允许违背结构程序设计精神的图形工具。程序员在进行设计时必须符合结构设计原则，而不能随意转移控制。

使用盒图可很容易实现以下目标：

• 可以很容易地确定局部和全程数据的作用域
• 可以很容易地表现嵌套关系

盒图的基本符号如下图：

判定表和判定树

判定表能够非常清晰地表示多重嵌套的条件选择关系。

一张判定表由四部分组成，左上部列出所有条件，左下部是所有可能做的动作，右上部是表示各种条件组合的一个矩阵，右下部是和每种条件组合相对应的动作。

如下图所示：

但是当条件变得更多时，判定表会显得很复杂，不够简洁。这时可以使用判定树。

判定树是判定表的变种，以树枝的形式表示复杂的条件组合与应做的动作之间的对应关系。

如下图：

判定树比判定表更直观，但简洁性却不如判定表。但是当数据元素的同一个值往往要重复写很多遍，而且越接近树的叶端重复次数越多。

过程设计语言

过程设计语言（Program Design Language，PDL）也称为伪码，它使用一种语言（通常是某种自然语言）的词汇，同时却使用另一种语言（某种结构化的程序设计语言）的语法，以表示数据和处理过程。

PAD

敏捷开发

敏捷方法是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。其核心思想主要有以下三点：

• 敏捷方法是适应性而非预设性的。传统方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷方法则欢迎变化，其实它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化
• 敏捷方法是以人为本，而不是以过程为本。传统方法以过程为本，强调充分发挥人的特性，不去限制它，并且软件开发在无过程控制和过于严格烦琐的过程控制中取得一种平衡，以保证软件的质量
• 迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化

与UP/RUP相比，敏捷方法的周期可能更短。敏捷方法在几周或几个月的时间内完成相对较小的功能，强调尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，更加强调团队中的高度协作。相对而言，敏捷方法主要适合于以下场合：

• 项目团队的人数不能太多，适合于规模较小的项目
• 项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合
• 高风险项目的实施
• 从组织结构的角度看，组织结构的文化、人员、沟通性决定敏捷方法是否使用。

与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所作的决定得到认可、环境设施满足团队成员之间快速沟通的需要。

敏捷宣言，也叫做敏捷软件开发宣言，包括四种核心价值和十二条原则，可指导迭代的以人为中心的软件开发方法。四个核心价值：

1. 个体和互动高于流程和工具
2. 工作的软件高于详尽的文档
3. 客户合作高于合同谈判
4. 响应变化高于遵循计划

十二条条原则已经应用于管理大量的业务及IT项目中：

1. 通过早期和连续型的高价值工作交付满足客户
2. 大工作分成可以迅速完成的较小组成部门
3. 识别最好的工作是从自我组织的团队中出现的
4. 为积极员工提供他们需要的环境和支持，并相信他们可以完成工作
5. 创建可以改善可持续工作的流程
6. 维持完整工作的不变的步调
7. 欢迎改变的需求，即使是在项目后期
8. 在项目期间每天与项目团队和业务所有者开会
9. 在定期修正期，让团队反映如何能高效，然后进行相应地行为调整
10. 通过完车的工作量计量工作进度
11. 不断地追求完善
12. 利用调整获得竞争优势

Scrum

水晶方法

强调用最少纪律约束而仍能成功

XP

eXtreme Programming，极限编程，适用于费用控制严格的公司。提供几款供开发人员模仿的最佳实践：

• 结对编程
• 测试驱动
• 客户驻场
• 快速设计
• 计划游戏
• 隐喻

驱动开发

TDD

Test Driven Development，测试驱动开发。

FDD

Feature Driven Development，特性驱动开发，功用驱动开发，将程序员分为首席程序员和类程序员（class owner），致力于短时的迭代，阶段和可见可用的功能。

MDD

Metrics Driven Development，度量驱动开发。

核心思想：一切可度量，以度量为基础。所有东西都是可度量的，包括性能、使用模式和收益等。度量不仅用于监控团队的绩效、解决性能瓶颈和估计硬件需求，还可在开发生命周期的任意阶段达成其他目的。

一种以数据为基础的方法，强调通过度量和分析来驱动软件的开发和优化。旨在将度量数据贯穿于整个开发过程中，使团队能够更好地理解软件性能、使用情况和业务影响，从而做出更明智的决策。

CDD

Contract Driven Development，契约驱动开发。Contract Oriented Programming

契约式编程是一种编程范式，强调在软件开发过程中，对于组件之间的交互和依赖关系进行明确的约定和规范。组件之间的合作通过明确的契约来定义，以确保组件之间的交互是正确和可靠的。

核心思想是将组件之间的交互规则以契约的形式进行定义，并在运行时对这些契约进行验证。契约可包括前置条件、后置条件、不变式等，用于描述组件的行为和约束。通过契约的定义和验证，可确保组件之间的交互是符合预期的，从而提高软件的可靠性和稳定性。

常用的契约包括设计时契约和运行时契约。设计时契约是在开发过程中定义的，用于描述组件之间的交互规则和约束。运行时契约则是在软件运行时对这些契约进行验证，确保组件之间的交互符合设计时的规定。

三个关键概念：

• 前置条件：指在执行某个函数或方法之前必须满足的条件。通过在代码中明确定义前置条件，可以确保函数或方法在执行之前的输入符合预期，从而避免出现错误或异常。
• 后置条件：指在执行某个函数或方法之后保证满足的条件。通过在代码中明确定义后置条件，可以确保函数或方法执行后的输出符合预期，从而提高代码的可靠性。
• 类不变量：指在类的生命周期内始终保持不变的条件。通过在代码中明确定义类不变量，可以确保类的状态始终处于有效和一致的状态，从而减少错误和异常的发生。

好处：

• 可提供更清晰、更明确的组件交互规则，有助于减少错误和不一致性；
• 可提高软件的可维护性和可扩展性，因为通过契约可以更容易地理解和修改组件之间的交互规则；
• 还可提供更好的代码文档和自动化测试支持，提高开发效率；
• 改善团队协作：可明确代码的预期行为，减少对其他代码的依赖，从而改善团队协作和代码的可组合性。

总而言之，契约式编程是一种强调明确组件交互规则的编程范式，通过定义和验证契约，可以提高软件的可靠性和稳定性，同时也提供更好的代码文档和测试支持。

开放式源码

开发人员地域分布广，和其他敏捷方法不同，一般的敏捷方法都强调项目组成员在同一地点工作。

DSDM

动态系统开发方法，Dynamic Systems Development Method

ASD

Adaptive Software Development，自适应软件开发。三个非核心的、重叠的开发阶段：猜疑、合作和学习

ADT

敏捷数据库技术，Agile Database Techniques

LSD

精益软件开发，Lean Software Development。

其他

UP/RUP

统一过程开发模型，另起一篇，参考软考高级之系统架构师系列之RUP、4+1视图、JAD、JRP、RAD。

RAD

Rapid Application Development，

构件开发模型

参考软考高级之系统架构师系列之构件开发模型。

V模型

开发和测试相结合，一种典型的测试模型。在V模型中测试过程被加在开发过程的后半部分，包括单元测试、集成测试、系统测试和验收测试。

演化模型

主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助引导出高质量的产品要求。其主要缺点是，如果不控制地让用户接触开发中尚未稳定的功能，可能对开发人员及永固都会产生负面的影响。

参考