【系统架构设计师】-软件开发方法

一、软件开发生命周期

传统的软件生命期（software lift cycle）是指软件产品从形成概念（构思）开始，经过定义、开发、使用和维护，直到最后被废弃（不能再使用）为止的全过程。按照传统的软件生命周期方法学，可以把软件生命周期划分为软件定义、软件开发、软件运行与维护三个阶段。

1、软件定义时期

软件定义包括可行性研究和详细需求分析过程，任务是确定软件开发工程必须完成的总目标。具体分成问题定义、可行性研究、需求分析等。

2、软件开发时期

软件开发时期就是软件的设计与实现，可分成概要设计、详细设计、编码、测试等。
概要设计是再软件需求规格说明的基础上，建立系统的总体结构（含子系统的划分）和模块间的关系，定义功能模块与各功能模块之间的关系。
详细设计对概要设计产生的功能模块逐步细化，把模块内部细节转化为可编程的程序过程性描述。详细设计包括算法与数据结构、数据分布、数据组织、模块间接口信息和用户界面等的设计，并写出详细设计报告。
编码又称为编程，编码的任务是把详细设计转化为能在计算机上运行的程序。
测试可分为单元测试、集成测试、确认测试和系统测试等。通常把编码和测试成为系统的实现。

3、软件运行和维护

软件运行就是把软件产品移交给用户使用。软件投入运行后的主要任务是使软件持久满足用户的要求。
软件维护是对软件产品进行修改或对软件需求变化做出响应的过程，也就是尽可能地延长软件的寿命。
当软件已没有维护的价值时，宣告退役，软件生命随之宣告结束。

二、软件开发模型

1、瀑布模型（Waterfall Model）

一种线性的开发模型，各阶段按照顺序进行，通常在开始阶段就定义了所有的需求和设计。
在瀑布模型中，每个阶段都必须完成其任务，然后才能进入下一阶段。
这种模型通常在需求和设计变更较少的情况下使用。

2、原型模型（Prototyping Model）

一种迭代式的开发模型，通常在需求定义阶段就开始创建原型。
通过原型，开发人员可以获取早期反馈，并在实际开发过程中逐步完善和调整原型。
原型模型通常用于高度定制化的系统。
与瀑布模型相反，原型针对的就是需求不明确的情况，首先快速构建一个功能模型，演示给用户看，并按要求及时修改，中间再通过不断的演示与用户沟通，最终设计出项目，就不会出现与用户要求不符合的情况，采用的是迭代的思想，不适合超大型项目的开发

3、增量模型（Incremental Model）

在增量模型中，系统的功能被分解为一系列的增量或模块。
每个增量或模块都独立地开发、测试和部署。
这种模型允许开发人员逐步地添加功能，而不是一次性地实现所有功能。

4、螺旋模型（Spiral Model）

一种迭代和风险驱动的开发模型。
在螺旋模型中，开发过程被划分为一系列的迭代或周期。
每个迭代都包括四个主要活动：制定计划、风险评估、开发和测试。
这种模型特别适用于大型、高风险的系统。

5、V模型（V-Model）

一种瀑布模型的扩展，特别强调测试活动的重要性。
在V模型中，测试活动被分为单元测试、集成测试、系统测试和验收测试。
这种模型强调在开发过程中进行早期和频繁的测试。

6、喷泉模型（Fountain Model）

一种迭代、需求驱动的开发模型，特别适用于面向对象系统的开发。
在喷泉模型中，软件开发活动被分为一系列的迭代或阶段。
在每个迭代中，开发人员根据需求文档进行开发，然后进行评审和修改。
这种模型强调需求分析和文档化。

7、基于构件的开发（Build-Based Development）

基于构建的开发是一种以代码为中心的开发模型。强调复用性，
在这种模型中，开发人员通常先编写代码，然后进行编译、测试和部署。
基于构建的开发通常用于小型到中型的项目，强调快速开发和迭代。

8、形式化方法模型（Formal Methods Model）

形式化方法是一种基于数学模型的软件开发方法。
在形式化方法模型中，需求、设计、实现和测试都被明确地定义和描述。
这种模型强调通过形式化方法来保证软件开发的精确性和一致性。
这种模型通常在安全性要求极高的系统中使用，例如航空航天系统。

9、快速应用开发（Rapid Application Development，RAD）

是一种敏捷开发模型，强调快速构建可运行的软件原型，然后逐步完善和优化。
比传统生命周期法（瀑布模型）快得多的开发方法，它强调极短的开发周期。在RAD模型中，也采用了基于构件的开发方法，利用已有的程序结构或使用构件进行复用，以提高开发进度和效率。

在RAD模型中，每个主要功能可以由一个单独的RAD组来实现，最后集成形成整体。这种基于构件的开发方法，使得RAD模型具有高效、灵活和可复用等优点。

此外，RAD模型还使用CASE（Computer-Aided Software Engineering）工具辅助软件构建，这有助于提高软件开发的效率和精度。

总的来说，快速应用开发模型通过基于构件的开发方法和CASE工具的使用，能够快速构建可运行的软件原型，然后逐步完善和优化，以适应需求的变化并提高开发效率。

三、RUP

1、RUP概述

RUP（Rational Unified Process）根据字面理解，可以知道RUP包括三个方面的意思，即Rational 、Unified 、Process。Rational表示RUP是由Rational公司提出来的，Unified表示RUP是最佳开发经验总结，而process表示RUP是一个软件开发过程。

2、RUP的生命周期

RUP软件生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，这9个核心工作流如下：

• 业务建模：理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
  -需求：定义系统功能及用户界面，使客户指导系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
• 分析与设计：把需求分析的结果转化为分析与设计模型。
• 实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
• 测试：检查各子系统的交互与继承，验证所有需求是否被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
• 部署：打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。
• 配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
• 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
• 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持

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

• 初始阶段：定义最终产品视图和业务模型，并确定系统范围。
• 细化阶段：设计及确定系统的体系结构，指定工作计划及资源要求。
• 构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
• 移交阶段：把产品提交给用户使用。
  每一个阶段都由一个或多个连续的迭代组成。迭代并不是重复地做相同地事，而是针对不同用例地细化和实现。每一个迭代都是一个完整地开发过程，他需要项目经理根据当前迭代所处地阶段以及上次迭代地结果，适当对核心工作流中地行为进行裁剪。

3、RUP中的核心概念

RUP中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。

• 角色（Role）——who的问题：角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，例如体系结构师（architect）、设计人员（designer）、实现人员（implementer）、测试员（tester）和配置管理人员（configurationmanager）等，并对每一个角色的工作和职责都做了详尽的说明。
• 活动（activity）——how的问题：活动是一个有明确目的的独立工作单元。
• 制品（artifact） ---------what的问题：制品是活动生成、创建或修改的一段信息。也有些书把artifact翻译为产品、工件等，和制品的意思差不多。
• 工作流（workflow）—when的问题：工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP2003对这些概念有比较详细的解释，并用类图描述了这些概念之间的关系，除了role、activity、artifact和workflow这4个核心概念外，还有其他一些基本概念，如工具教程（toolmentor）、检查点（checkpoints）、模板（template）和报告（report）等。

4、RUP的特点

与别的软件开发过程相比，RUP具有自己的特点，即RUP是用例驱动的、以体系结构为中心、迭代和增量的软件开发过程。

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

四、能力成熟度模型

1、能力成熟度模型CMM

对软件组织化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。

• 1 初始级：软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖跟人的努力和英雄式核心任务的作用。
• 2 可重复级：建立了基本的项目管理过程和实践来跟踪项目的费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中的成功。
• 3 已定义级：管理和工程两方面的软件过程已经文档化、标准化、并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。
• 4 已管理级：制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员掌控。
• 5 优化级：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改造。

2、能力成熟度模型CMMI

是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。

CMMI的两种表示方法：

• 1 阶段式模型：类似于CMM，他关注组织

成度等级	过程域
初始的	过程不可预测且缺乏控制
已管理	需求管理、项目计划、配置管理、项目监督与控制、、供应商合同管理、度量和分析、过程和产品质量保证
已定义	需求开发、技术解决方案、产品集成、验证、确认、组织级过已定义级 焦点、组织级过程定义、组织级培训、集成项目管理、风险管理、集成化的团队、决策分析和解决方案、组织级集成环境
定量管理级	组织级过程性能、定量项目管理
优化级	组织级改革与实施、因果分析和解决方案

• 2 连续式模式：关注每一个过程域的能力，一个组织不同过程域可以达到不同的过程域能力等级