概述

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

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

软件开发方法

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

软件开发模型

大体来说，有3类：

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

瀑布模型

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

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

优点：

原理简单，容易掌握
各阶段间都有验证和确认环节，以便进行质量管理
主要用于支持结构化方法
缺点：
缺乏灵活性，不能适应用户的需求变化
缺乏演化性，返回上一级的开发需要付出十分高昂的代价
是线性的软件开发模型，回溯性差

适用场合：

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

原型模型

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

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

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

优点：

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

缺点：

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

适用场合：

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

渐增模型

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

优点：

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

缺点：

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

适用场合：

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

喷泉模型

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

特点：

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

螺旋模型

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

单选题，有瀑布和原型两个选项，选择原型。螺旋模型是在（快速）原型的基础上扩展而成的。

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

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

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

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

适用场合：

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

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

在这里插入图片描述

RUP

RUP软件开发生命周期是一个二维的软件开发模型，其中有9个核心工作流：业务建模、需求、分析与设计、实现、测试部署、配置与变更管理、项目管理以及环境。

RUP把软件开发生存周期划分为多个循环，每个循环生成产品的一个新版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务：

初始阶段：定义最终产品视图和业务模型，并确定系统范围
细化阶段：设计及确定系统的体系结构，制定工作计划及资源要求
构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交
移交阶段：把产品提交给用户使用

每个阶段都有一个或多个连续的迭代组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对工作流中的行为进行裁剪。在每个阶段结束前有一个里程碑评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续该阶段的工作。

RUP特点：用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。

4+1视图

由Philippe kruchten提出，被 RUP 采纳。现在已经成为架构设计的结构标准。

逻辑视图：逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的“辅助功能模块”；它们可能是逻辑层、功能模块等。
开发视图：实现视图，开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方 SDK 和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
进程视图：处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。
物理视图：部署视图。物理视图关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个 IT 系统相互影响的架构视图。
场景视图：用例视图。架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例（use cases）或场景（scenarios）来说明，从而形成第五个视图。

不同的人员会关心不同的视图：

分析人员和测试人员关心的是系统的行为，侧重于用例视图
最终用户关心的是系统的功能，侧重于逻辑视图
程序员关心的是系统的配置、装配等问题，侧重于实现视图
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，侧重于进程视图
系统工程师关心的是系统的发布、安装、拓扑结构等问题，侧重于部署视图

其他

形式化方法

形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难以为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。

结构化分析

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

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

净室软件工程

Cleanroom Software Engineering，CSE。
软件开发的一种形式化方法，使用盒结构规约（或形式化方法）进行分析与设计建模，并将正确性验证作为发现和消除错误的主要机制，采用统计测试来获取验证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，以及使用基于数学的正确性来证明对设计模型的每个元素进行形式化验证。还强调统计质量控制技术，包括基于客户对软件的预期使用测试。

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

V模型

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

构件开发模型

基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段髙效率、髙质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。

敏捷开发

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

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

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