软件开发过程模型综述

软件开发过程模型综述

软件开发过程模型的含义；

软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。

 

各种典型软件开发过程模型产生背景、基本策略、适用范围和局限性。

常见的软件开发模型有瀑布模型、增量模型、原型模型、螺旋模型、RUP模型、敏捷开发。

瀑布模型：

产生背景：1970年温斯顿·罗伊斯（WinstonRoyce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

主要优点：1、顺序性和依赖性：前结束，后开始；前输出，为后输入。

          2、推迟实现的观点：前阶段工作必须做扎实，方可开展后续工作。

3、质量保证的观点：必须完成规定文档；必须对完成的文档进行评审，以便今早发现问题。

主要缺点：1、不适应需求变化。

          2、最终才能见到可执行系统，风险高。

应对策略：1、系统原型：借助可工作系统原型明确系统需求，避免不必要变更。

2、增量交付：将系统分解为多个子系统增量式发布给用户，避免和容忍变更。

3、系统重构：根据代码对开发好的系统进行优化设计，从而容忍变更。

局限性：瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃。

 

增量模型：

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点。

1、将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。

2、以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。

3、开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。

增量模型的缺点是要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。

增量模型适用于具有以下特征的软件开发项目：

1、软件产品可以分批次地进行交付。

2、待开发的软件系统能够被模块化。

3、软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。

4、项目管理人员把握全局的水平较高。

增量模型对软件设计有更高的技术要求，特别是对软件体系结构，要求它具有很好的开放性与稳定性，能够顺利地实现构件的集成。在把每个新的构件集成到已建软件系统的结构中的时候，一般要求这个新增的构件应该尽量少地改变原来已建的软件结构。因此增量构件要求具有相当好的功能独立性，其接口应该简单，以方便集成时与系统的连接。

 

原型模型：

原型模型指的是在执行实际软件的开发之前，应当建立系统的一个工作原型。一个原型通常是实际系统的一个比较粗糙的版本。

主要优点：1、通过快速开发工具短时间构造出可运行“样品”；

              2、通过运行原型可更好解决开发中的不确定性因素：需求工程阶段有助于启发和验证系统需求；软件设计阶段有助于探索和验证设计方案；

3、原型最终结局：被抛弃；最为最终产品发布。

主要缺点：1、原型的快速开发往往忽略了非功能方面的因素，如性能、健壮性和可靠性等；

2、缺乏必要的开发文档，不利于后期维护。

 

螺旋模型：

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

螺旋模型沿着螺线进行若干次迭代，四个象限代表了以下活动：

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；

（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；

（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。

 

优点

 

1）设计上的灵活性,可以在项目的各个阶段进行变更。

2）以小的分段来构建大型系统,使成本计算变得简单容易。

3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

4）随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点

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

螺旋模型的项目适用：

对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。

 

RUP模型：

RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。

细化阶段

细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

构造阶段

在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

交付阶段

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

 

核心工作流

RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。

商业建模

商业建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程，角色和责任。

需求

需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。

分析和设计

分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。

实现

实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。

测试

测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。

部署

部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。

配置和变更管理

配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。

项目管理

软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。

环境

环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。

RUP的特点：

1、迭代式的增量开发
受控的迭代式增量开发
1）将软件开发分为一系列小的迭代过程，在每个得带过程中逐步增加信息、进行细化
2）根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流
3）每次迭代都选择目前对风险影响最大的用例进行，以分解和降低风险
2、用例（Use case-driven）驱动
1）采用用例来捕获对目标系统的功能需求
2）采用用例来驱动软件的整个开发过程，保证需求的可跟踪性，确保系统所有功能均被实现
3）将用户关心的软件系统的业务功能实体功能模型和开发人员结合起来，提供一种贯穿整体软件生存周期的开发方式，使得软件开发的各个阶段的工作自然、一致地协调起来
3、以软件体系结构为中心
1））强调在开发过程的早期，识别出软件与软件的体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试，形成体系结构框架；
2）在后续阶段中对已形成的体系结构框架进行不断细化，最终实现整体系统
3）在开发过程中的早期形成良好的软件体系结构，有利于对系统的理解、支持重用和有效的组织软件开发

 

敏捷开发：

产生背景：传统的开发方法有详细的项目规划，受控的过程管理和严格的质量保证，在规划、设计及文档编写方面投入巨大，仅适合大型、长寿命周期的软件开发，无法满足中小学软件的开发需要。

敏捷开发提出在20世纪90年代，该方法以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，从而让开发团队将主要精力集中在软件本身而不是在设计和编写文档上。

敏捷开发适合系统需求在开发过程中快速变化的应用类型。

开发宣言

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

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

客户合作 胜过 合同谈判

响应变化 胜过 遵循计划

虽然右项也有价值，但是我们认为左项具有更大的价值。

基本原则

尽早并持续地交付有价值的软件以满足顾客需求。

敏捷流程欢迎需求的变化, 并利用这种变化来提高用户的竞争优势。

经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。

业务人员和开发人员在项目开发过程中应该每天共同工作。

以有进取心的人为项目核心，充分支持信任他们

无论团队内外，面对面的交流始终是最有效的沟通方式

可用的软件是衡量项目进展的主要指标

敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去。

只有能自我管理的团队才能创造优秀的架构, 需求和设计.