【软件工程】第二讲软件过程

1. 软件过程概述

1.1 软件工程的金三角

• 人：完成软件开发的主体
• 技术：提供了建造软件在技术上需要“如何做”的方法
• 管理：提供了质量管理、成本管理、时间管理、范围管理等知识和技能

过程：这是将人、技术、管理结合在一起的凝聚力；过程是产品成本、进度和质量的主要决定因素

1.2 软件过程的定义

Defines who is doing what, when to do it, and how to reach a certain goal.

1.3 软件过程的组成

软件过程，也称为软件生存周期过程，是指软件生存周期中的一系列相关过程，其中过程就是活动的集合，活动是任务的集合，任务要起到把输入加工成输出的作用

活动的执行可以是顺序的、迭代的（重复的）、并行的、嵌套的，或者是有条件地引发的

2. 软件生命周期模型

软件生存周期模型，又称软件开发模型，是软件生命周期的一个框架，规定了软件开发、运作和维护等所需的过程、活动和任务

软件生存周期模型分类：

• 瀑布模型Waterfall Model
• 增量模型Incremental Model
• 演化模型Evolutionary Model

2.1 瀑布模型

最早的软件开发模型，又称为线性顺序模型

• 特点
  • 强调阶段的划分及其顺序性
  • 强调各阶段工作及其文档的完备性
  • 每个阶段结束之前，都从技术和管理两个角度进行严格的审查
  • 是一种严格线性的、按阶段顺序的、逐步细化的开发模式
• 适用时机
  • 所有功能、性能等要求能一次理解和描述时
  • 所有的系统功能一次交付时
  • 必须同时淘汰全部老系统时
• 瀑布模型的价值
  • 结构简单明了；历史悠久、应用面广泛、为广大软件工作者所熟悉；已有与之配套的一组十分成熟的开发方法和丰富的支撑工具
  • 一种较为有效的管理模式：订计划、成本预算、组织开发人员、阶段评审、文档管理，从而对软件质量有一定的保证
• 瀑布模型的风险
  • 获得完善的需求规约是非常困难的
  • 难以适应快速变化需求
  • 系统太大时，难以一次做完
  • 反馈信息慢
  • 极可能引起开发后期的大量返工，如返工到需求、设计等早期活动

2.2 增量模型

需求和架构确定后，增量式进行开发，构造一系列可执行的版本

• 增量模型的风险
  • 需求未被很好地理解
  • 一次要求所有功能
  • 需求迅速发生变化
  • 事先打算采用的技术迅速发生变化
  • 长时期内仅有有限的资源/人员/资金
• 增量模型的适用时机
  • 需要早期获得所有需求
  • 根据需求建立稳定的软件架构
  • 中间产品可以提供使用
  • 系统被自然地分割成增量
  • 工作人员/资金可以逐步增加

2.3 演化模型

• 增量现状

  • 软件需求在软件开发过程中常常发生改变，想要一次迭代就开发出最终产品是不可能的
  • 紧迫的市场期限使得难以一下子完成一个完善的软件产品

• 解决方案：演化模型：只要核心能够被很好地理解，就可以进行渐进式开发，其余需求可以在后续的迭代中进一步定义和实现。这种过程模型称为演化模型，它能很好地适应随时间演化的产品的开发

• 特点

  • 迭代的开发方法，渐进地开发各个可执行版本，逐步完善软件产品。每个版本在开发时，开发过程中的活动和任务顺序地或部分重叠平行地被采用
  • 与增量模型地区别是：需求在开发早期不能被完全了解和确定，在一部分被定义后开发就开始了，然后在每个相继的版本中逐步完善

• 迭代设计

  • 每次迭代都应产生一个可执行的软件版本，每次迭代都包括计划、需求、设计、编码、测试、总结等活动
  • 要求有计划的迭代
    • 通常有3-9个迭代组成
    • 风险驱动：项目的风险越高，迭代就越多；风险越高的工作，越在早期的迭代中执行
    • 迭代可以并行、重叠、串行
    • 迭代内部的活动可以交叉并行

• 演化模型已称为主流

  • 现代软件过程都采用演化模型

    • 统一软件过程RUP
    • 敏捷过程（SCRUM、XP等）
    • 净室（Cleanroom）软件过程

  • 演化模型的“子类”

    • 原型Prototyping

      

    • 螺旋模型Spiral Model

      

3. 统一软件过程RUP

3.1 RUP最佳实践

• 迭代式开发：迭代式开发允许在每次迭代过程中需求都可以有变化，这种开发方法通过一系列细化来加深对问题的理解，因此能更容易地容纳需求的变更
• 管理需求：RUP描述了如何提取、组织系统的功能性需求和约束条件并把它们文档化
• 使用基于构件的体系结构：RUP提供了使用现有的或新开发的构件定义体系结构的系统化方法，从而有助于降低软件开发的复杂性，提高软件重用率
• 可视化建模：与可视化建模语言UML紧密地联系在一起，在开发过程中建立起软件系统的可视化模型，可以帮助人们提高管理软件复杂性的能力
• 验证软件质量：软件质量评估不再是事后型的或由单独小组进行的孤立活动，而是内建在贯穿于整个开发过程的、由全体成员参与的所有活动中
• 验证软件变更：RUP描述了如何控制、跟踪和监控修改，以确保迭代开发的成功

3.2 统一软件过程RUP

一个二维的生命周期模型，纵轴代表核心工作流，横轴代表时间；共有9各核心工作流，前六个为核心过程工作流程，后三个为核心支持工作流程

RUP是一个风险驱动的、基于UML和构件式架构的演化开发过程

• RUP的四个阶段

  

  • INCEPTION: Define the scope of project
  • ELABORATION: Plan project, specify features, baseline architecture
  • CONSTRUCTION: Build the product
  • TRANSITION: Transition the product into end user community
  • 每个阶段的结束都是一个大的里程碑

• 阶段和迭代

  

  An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release ( internal or external )

• 一个迭代周期：一个小的瀑布模型

  

4. 敏捷过程

4.1 敏捷过程

• 敏捷过程
  • 敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，实现企业效益的最大化
  • 敏捷过程在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品
  • 2001年2月，新方法的一些创始人在美国犹他州成立Agile联盟
• 敏捷宣言
  • 较之于过程和工具，更注重人及其相互作用的价值
  • 较之于无所不及的各类文档，更注重可运行的软件的价值
  • 较之于合同谈判，更注重与客户合作的价值
  • 较之于按计划行事，更注重响应需求变化的价值
• 敏捷过程的适用范围：不是到处可适用的
  • 需求不稳定、易挥发
  • 有责任感和积极向上的开发人员
  • 用户容易沟通并能参与
  • 小于10个人的项目团队

4.2 SCRUM

• Scrum — 敏捷的软件项目管理

  • 1994年由Ken Schwaber和Jeff Sutherland提出
  • Scrum一词来源于橄榄球运动，意为两队并列争球
  • 过程核心：
    • 一个体育队加小队长，全体团队负责拿球向前冲
    • 团队成员能够独立地、集中地在创造性地环境下工作

• Scrum的核心准则

  • 迭代开发
  • 自我管理

• Scrum的过程框架
  

  • Sprint：周期为30天的迭代
  • Backing：待办事项表（功能和非功能需求清单）
  • Daily Scrum：每日15分钟简会

• Scrum团队

4.3 喷泉模型

• “喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特性。迭代是软件开发过程中普遍存在的一种内在属性。用面向对象方法学开发软件时，工作重心应该放在生命周期中的分析阶段
• 图中代表不同阶段的圆圈互相重叠，这明确表示两个活动之间存在交迭
• 图中在一个阶段内的向下箭头代表该阶段内的迭代
• 图中较小的圆圈代表维护，圆圈较小象征着采用了面向对象泛型之后维护时间缩短了