软件开发过程模型综述
软件开发过程模型的含义
（1）、软件过程模型：软件过程模型是软件过程的简化表示。每个过程模型都是从一个特定的侧面表现软件过程。软件过程模型是软件开发全部过程工程、活动和任务的结构框架。能直观的表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
（2）、常见模型：瀑布模型、增量模型、原型模型、螺旋模型、瀑布模型、RUP、敏捷开发
各种典型软件开发过程模型
瀑布模型：瀑布模型是将软件生存周期中的各个活动规定为依线性连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。由前至后、相互衔接的固定次序，如同瀑布流水逐级下落。
产生背景：1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
核心思想：瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
优点：
- 顺序性和依赖性：前结束，后开始；前输出，为后输入；
- 推迟实现的观点：前阶段工作必须做扎实，方可开展后续工作；
- 质量保证的观点：必须完成规定文档；必须完成对完成的文档进行评审，以便尽早发现问题；
- 容易理解，管理成本低；
- 强调开发的阶段性早期计划及需求调查和产品测试。
缺点：
- 不适应需求变化；
- 最终才能见到可执行系统，风险高；
- 项目结束时，出现大量的集成和测试工作；
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
瀑布模型中的主要阶段直接映射的基本开发活动：
- 需求的分析和定义：通过咨询系统用户建立的系统的服务、约束和目标。并对其进行详细的定义形成系统描述
- 系统和软件设计：系统设计过程通过建立系统的总体体系结构将需求区分为硬件需求和软件需求。软件设计包括识别和描述一些基本的软件系统抽象及其之间的关系；
- 实现和单元测试：在此阶段，将软件设计实现为一组程序或程序单元；
- 集成和系统测试：集成单个的程序单元或一组程序，并对系统整体进行测试以确保其满足了软件的需求，在测试之后，软件系统将交付给客户使用；
- 运行和维护：正常情况下，这是一个具有最长生命周期的阶段，系统被安装并且投入实际的使用中。维护包括改正那些在早期阶段没有被发现的错误，改善系统各个单元的实现，并当新的需求出现的时候提高系统的服务能力。
现状：瀑布模型过于强调对于文档的使用，并且要求每个阶段都要仔细验证，太过理想化，现在已经基本被外界抛弃，主要问题如下：
- 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
- 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
- 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
以上都是瀑布模型的缺点所导致的。
增量模型：先完成一个系统子集的开发，再按照同样的开发步骤增加功能，入戏递增下去直至满足全部系统需求。
优点：
- 软件逐次交付，用户可以早日使用产品并从中获得收益；
- 早期增量可以作为原型使用，有助于获取后面增量的需求；
- 核心功能率先被开发，降低了项目失败的风险；
- 容易理解，管理成本低；
- 强调开发的阶段性早起计划及需求调查和产品测试；
- 减少用户需求变更；
- 运行增量投资，即在项目开始时，可以仅对一个或者两个增量投资。
缺点：
- 系统体系结构必须最先确定，并在增量式开发中保持稳定；
- 如果没有对用户的变更需求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。
- 如果需求不想早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。
- 管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
原型模型：原型是软件系统的初期版本，用于展示概念，验证设计方案，发现存在的问题和寻找可能的解决办法。
适用领域：事先不能完整定义需求的领域。
优点：
- 通过快速开发工具短时间构造出可以运行的样品；
- 通过运行原型可以更好解决开发中的不确定因素：需求工程阶段有助于启发和验证系统需求；软件设计阶段有助于探索和验证设计方案；
- 原型最终的结局：被抛弃或者被作为最终产品发布。
缺点：
- 原型的快速开发往往忽略了非功能方面的因素，如性能、健壮性和可靠性等；
- 缺乏必要的开发文档，不利于后期维护；
螺旋模型：螺旋模型不是将软件过程用一个伴随着有从一个活动到另一个活动的回溯活动序列来表示，而是将过程用螺旋线表示。在螺旋线中每个回路表示软件过程中的一个阶段。因此，最里面的回路可能与系统可行性研究有关，下一个回路与系统需求定义有关，在下一个回路与系统设计有关，等等。在螺旋线中每个回路被分成四个部分：目标设置、风险评估和规避、开发和有效性验证、规划。
优点：将风险分析与处理引入到软件开发中，有助于降低软件的开发风险，适合于大型软件开发。
缺点：
- 螺旋模型强调风险分析，并做出关反应是不容易的，往往仅适用于内部的大规模软件开发；
- 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
Rational统一过程：Rational统一过程是新式过程模型中的一个实例，该新式过程模型来自于UML上的工作以及相关的统一软件开发过程。
3个视角：
- 动态视角：给出模型中随时间经历的各个阶段；
- 静态视角：给出所进行的过程活动；
- 实践视角：提出在过程中可以采用的良好实践建议
RUP是一个阶段化的模型，识别出软件过程中的4个独立阶段：
- 初始化阶段：主要任务是构思未来系统的概貌、确定项目的必要性和可行性。建立系统的一个业务案例，要识别所有与系统交互的外部实体并且定义这些交互。然后使用这些信息评估系统对业务的贡献，如果贡献小就取消。焦点为：业务建模和需求
- 细化阶段：增进对问题域的理解，捕获系统的大部分的功能需求，建立系统的体系框架，给出项目计划并识别关键项目风险。完成该阶段后就得到了系统的需求模型。焦点为：需求、分析和设计工作流。
- 构造阶段：主要关心的是系统设计、编程和测试。系统的各个部分并行开发，然后集成在一起，在这个阶段完成时，就得到了一个能工作的系统软件，还有能交付给用户的相关文档。
- 交付阶段：主要任务是将开发的软件发布给用户，在用户的实际生产环境安装部署开发好的软甲，进行用户培训，获取用户的反馈意见，并对软件做必要的调整和优化。
RUP的6个过程工作流和3换个支持工作流：
- 商业建模：对系统的商业环境和范围进行建模，确保所有的参与人员对开发系统有共同的认识。
- 需求分析：定义系统功能及其他非功能需求，成果是软件需求说明书。
- 分析和设计：根据系统需求给出实现方案，成果为软件设计说明书。
- 实施：定义代码的组织结构、实现代码、单元测试、集成系统。
- 测试：验证各子系统的交互和集成。测试分别从可靠性、功能性和系统性来进行。
- 部署：成功的生成版本并将软件分发给最终用户
- 配置和变更管理：管理并行开发、分布式开发；自动化创建工程；记录产品修改原因、时间、人员、审计记录。
- 项目管理：为计划、执行和监控软件开发项目提供有效支持。
- 环境：为组织提供过程管理和工具支持。
RUP的特点：
- 面向对象：使用和支持面向对象，且建立的设计、实现模型均是对象模型；
- Use Case驱动：系统开发从建立业务领域的用例模型开始，用例模型表达了系统的需求，后面的工作围绕如何实现用例模型展开；
- 以体系结构为中心：系统开发过程中，体系结构用作开发的基石。系统的概念化、构造和管理均围绕系统的体系结构进行；
- 迭代式、增量式的开发过程；
- 以质量控制和风险管理为目标；
- 与UML配套；
- 适用性强。
敏捷开发：
开发背景：
传统的开发方法有详细的项目规划，受控的过程管理和严格的质量保证，在规划、设计及文档编写方面投入巨大，仅适合大型、长寿命周期的软件开发，无法中小型软件的开发需要；敏捷开发提出在20世纪90年代，该方法以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，从而让开发团队将主要的精力集中在软件本身而不是设计和编写文档上。敏捷开发适合系统需求在开发过程中快速变化的应用类型。
敏捷基本原则：
- 尽早。持续的交付有价值的软件；
- 欢迎改变需求，保持客户竞争优势；
- 业务人员全程参与开发过程；
- 最有效果的信息传达方式是面对面的交谈；
- 可以工作的软件是进度的最主要度量标准；
- 敏捷过程提倡可持续开发；
- 不断追求卓越技术与良好设计有助于提高敏捷性；
- 简单—尽可能减少工作量的艺术至关重要；
- 最好的架构、需求和设计都源自自我组织的团队。
极限编程：极限编程是目前最流行的敏捷开发方法。该方法推行最佳工程实践，如迭代开发、结对编程、测试驱动开发等，致力于积极响应用户的需求变化，并能高效率开发出高质量软件。适合于小团队开发。
需求：
- 客户是项目开发队伍中的一员；
- 把需求编程一个个用户故事；
- 客户根据商业价值来指定故事的优先级，开发人员确定开发风险；
- 根据优先级及业务风险，制定开发计划；
- 每发布一次开发的软件，用户都能得到一个可以开始使用的系统；
- 开发团队经过各个小的迭代中实现。