软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 ISO 9000对过程的定义: 使用资源将输入转化为输出的活动所构成的系统。

 瀑布模型：

 瀑布模型的特点：

• 阶段间具有顺序性和依赖性
  •  必须等前一阶段的工作完成之后，才能开始后一阶段的工作
  •  前一阶段的输出文档就是后一阶段的输入文档
• 推迟实现的观点
  • 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现
• 质量保证的观点
  • 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
  • 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

瀑布模型的优点：

• 可强迫开发人员采用规范的方法（例如，结构化技术）
• 严格地规定了每个阶段必须提交的文档
• 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证
• 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型

瀑布模型的缺点：

• 要求用户不经过实践就提出完整准确的需求，在许多情况下都是不切实际的
• 仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品
• 将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况
• 软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的。
• “由文档驱动”的这个事实也是瀑布模型的一个主要缺点,这可能导致最终开发出的软件产品不能真正满足用户的需要

---

V模型：

瀑布模型的改进，强调测试活动与分析和设计之间的关联：

• 单元测试和集成测试－>校验程序设计；
• 系统测试－>校验（verify）系统设计；
• 验收测试－>确认（validate）需求；

与瀑布模型关注文档和工作产品不同，V模型的关注点是软件开发各阶段的活动以及正确性，因此V模型是以活动驱动的。

Tips：验证与确认

• 验证（Verification）
  • 目标是确定系统中各项功能可以正常工作，实质上是检查实现的质量如何。
• 确认（Validation）
  • 目标是确定系统实现了全部的需求，确保开发方建造的是正确的、用户需要的产品。

V模型的改良之处与存在的问题：

本质是把瀑布模型中一些隐含的迭代过程明确出来，使开发活动和验证活动的相关性更加明显；

V模型使抽象等级的概念也更明显：所有从需求到实现部分的活动关注的是建立更多的系统详细表述，而所有从实现到交付运行的活动关注的是对系统的验证和确认。

和瀑布模型一样，都是对软件开发过程过于简单、理想化的抽象，对需求变化的适应性差。

---

原型/快速原型模型：

所谓原型，是一个可以实际运行的模型，它在功能上可以看作是最终产品的一个子集（展示了目标系统的关键功能）。 快速原型化的软件开发大体可以如下图所示：

所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

原型模型的优势：

• 快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。
  • 原型系统已经通过与用户交互而得到验证
  • 开发人员通过建立原型系统已经学到了许多东西
• 利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认；
• 可以考虑结合瀑布模型，二者互补性强。用快速原型做为需求分析的一种技术，用于收集客户的真实需求，然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补。

使用原型必须注意的问题：

• 由于要求能够快速建立可供运行的模型，原型不可能像最终产品一样面面俱到；
• 客户：不可把原型当作软件的正式运行版本；
• 开发人员：同上。还必须牢记原型中没有考虑质量因素的部分；
• 使用前要与用户达成一致：原型只是模型而已。

---

阶段式开发（演化模型）

• 软件系统和其他所有复杂系统一样，是随着时间不断演化的。业务需求和产品需求随着开发向前推进经常发生改变，这使得直线式的开发模型不切实际。
• 来自时间、成本、人力以及技术等方面的压力往往使得演化成为软件开发的必经之路。
• 阶段式开发大体分为两种：
  • 渐增式开发
  • 迭代式开发（螺旋式开发） 

增量模型（渐增模型）

• 增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。
• 每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
• 使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。

增量模型的优点 

• 适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况；
• 能有计划地管理技术风险；
• 每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能；
• 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新的软件可能给客户带来的冲击。

 增量模型的难点

• 软件体系结构必须是开放的，使得每个新的增量构件能够无缝地集成到现有的软件体系结构中，增加了设计阶段的投入；
• 本身具有矛盾性，一方面要求开发人员把软件看作一个整体，另一方面要求开发人员把软件看作构件序列，且构件间彼此独立。需要开发人员协调这一矛盾。

螺旋模型

• 软件项目中的风险：
  • 人员        
  • 硬件设备
  • 项目的生存能力等
• 螺旋模型的基本思想：使用原型及其他方法来尽量降低风险。
• 可以把螺旋模型看作在每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型沿着螺线旋转，在四个象限上分别表达四个任务区域，即：

• 制定计划──确定软件目标，选定实施方案，弄清项目开发的限制；
• 风险分析──分析所选方案，考虑如何识别和消除风险；
• 实施工程──实施软件开发；
• 客户评估──评价开发工作，提出修正建议，并计划下一个阶段的任务；

螺旋模型的优点：

• 螺旋模型是对瀑布模型的发展，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；
• 由于引入风险分析等活动，测试活动的确定性增强了；
• 螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视。

螺旋模型的缺点：

• 主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；
• 只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；
• 对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟。 

---

喷泉模型

注意事项  

• 为避免使用喷泉模型开发软件时开发过程过于无序，应该把一个线形过程作为总目标；
• 面向对象范型本身要求经常对开发活动进行迭代或求精。 

---

统一软件开发过程 RUP（Rational Unified Process）

What is RUP?

• Process Framework and a detailed prescriptive process model

  • Meta Process / Must customize

• Software engineering knowledge base

  • Covers almost all activities of software development

• Well defined structure for object-oriented design and development

  • Based on OO and UML

• Like a software product, the Rational Unified Process is designed and documented using the Unified Modeling Language (UML)

  • Well documented

开发经验（最佳实践）：

• 迭代式开发：容纳需求变更/减少风险
• 管理需求：使用用例和脚本
• 使用基于构件的体系结构
• 可视化建模
• 验证软件质量：质量评估内建在贯穿于整个开发过程的、由全体成员参与的所有活动中
• 控制软件变更

 RUP软件开发生命周期的静态结构

• 核心工作流
  • 业务建模
  • 需求
  • 分析与设计
  • 实现
  • 测试
  • 部署：生成目标系统的可运行版本，移交给用户
  • 配置与变更管理：跟踪维护开发过程中Artifacts的完整性和一致性
  • 项目管理：提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用准则，并为风险管理提供框架
  • 环境：软件开发环境，包括过程管理和工具支持

RUP软件开发生命周期的动态结构

• 工作阶段
  • Inception（先启）：生命周期目标里程碑 建立业务模型，定义最终产品视图，确定项目的范围
  • Elaboration（精化）：生命周期架构里程碑 设计并确定系统的体系结构，制定项目计划，确定资源需求
  • Construction（构建）：初始可操作性能里程碑 开发所有构件和程序，集成为客户需要的产品，测试所有功能
  • Transition（移交）：产品发布里程碑 把开发出的产品提交给用户使用

 RUP迭代式开发

• 整个项目开发过程由多个迭代过程组成。
• 每次迭代只考虑一部分系统需求。
• 每个迭代都是风险驱动的。
• 每个迭代都可以看作是一个“小型的瀑布模型”过程。
  • 以一个交付版本结束
  • 其结果是一个增量，增加一些新的功能
• 每次迭代以不同的重点和强度访问核心工作流。

 RUP生命周期的特点：

• 与螺旋模型相比

  • 相似：重复一系列组成系统生命周期的循环

  • 差异：

    • RUP给出了每个阶段内的若干次迭代过程完成后交付的增量的具体要求，即四个阶段的里程碑

    • RUP详细阐述了不同阶段的不同迭代过程经历的九大核心工作流程中活动内容的重点和强度不同

    • RUP提供了对每次迭代过程中不同核心工作流程活动的并行化支持

  • 优点：用于指导需求不明确、不稳定的项目开发时具有更强的可操作性。

• 与瀑布模型相比

• 优点：
  • RUP将成本风险进一步降低为获得一次增量所需的费用
  • RUP进一步降低了产品不能按计划投放市场的风险
  • RUP使项目开发更能适应项目需求的变化

RUP的人员-------角色及其活动

• 角色的划分及相关活动 RUP定义了五大类角色集：分析员、开发人员、测试员、经理、其他角色。每一类角色集又包括多个角色，并给出了每个角色对应的活动。
• 角色的意义
  • 将角色和个体区分开来，有效提高了项目中人力资源的利用率。
• 角色方面的缺陷
  • 未给出角色的组织管理方式、角色间的相互地位关系和交互方式。

RUP的方法------方法和工具

• 方法： 用例及用例驱动    
  • 用例是捕获需求的有效方法
  • 用例驱动整个RUP过程
  • 以架构为中心
  • 在面向对象的分析设计中采用UML进行可视化建模
  • 面向对象的设计与构件实现
• 工具： Rational Solutions

RUP的特点

• 优点：
  • 用例驱动、以架构为中心、迭代和增量；
  • 具有二维迭代性，有利于降低风险、适应需求变化；
  • 是可配置的，具有通用性；
• 缺点：
  • 在理想的项目开发环境下软件过程的一种完美模式；
  • 未给出具体的剪裁、扩充等配置实施的方法准则。