Chapter2：Software Processes

2.1 Outline

• Topics covered：
  - Software process models：软件开发活动的组织模式，各种活动展开的顺序，活动的内容。

• Process activities：对软件过程的四个通用活动（specification，development，validation and evolution）加以详细介绍。

• Coping with change：如何应对软件经常发生的变化（主要是需求的变化）。

• The Rational Unified Process：现代的软件过程模式，由Rational公司提出，组合了前面通用的一些模型的优点，更适用于现代软工过程。

2.2 Software Processes 软件过程

2.2.1 房子类比

• 建房子：不同的房子，虽有不同的建造过程，却有相同的生命周期（life cycle）。

• 开发软件：也是一样，**不同开发过程，相同生命周期（5个阶段）：**软件的需求分析、软件设计、软件编码、软件测试、软件维护。

2.2.2 中间过程对用户是否透明

• 两种方式：
  

• 用户提完需求后，什么也不用管，最后开发团队交付产品。用户不知道产品开发的过程。对用户是不透明的。

• 用户提完需求后，开发团队开发过程中会有阶段性的成果和反馈，整个过程是可管理的，可见的。对用户是透明的。

2.2.3 软件过程定义

• 软件过程是开发一个软件所需要的一系列的活动的集合。

  A structured set of activities required to develop a software system.

2.2.4 通用过程活动（4个）

• 软件过程有许多种，但每一种都包含以下四种，我们称之为：通用软件活动。

• 通用软件活动：

  • Specification： defining what the system should do;定义软件做什么
  • Design and implementation： defining the organization of the system and implementing the system;定义系统的结构并且进行实现。
  • Validation： checking that it does what the customer wants;检查当前设计是否满足用户需求
  • Evolution： changing the system in response to changing customer needs.修改系统，响应客户需求变化。

2.2.5 软件过程模型

• 过程模型是一个抽象的表达，它是从特定的角度对过程的描述。

  也就是说过程模型从一些特定的角度将过程的特征抽取并表示，过程的抽象描述。

2.2.6 软件过程描述

• 软件过程是一切软件活动的集合。所以讨论过程就是讨论这些过程中的活动，比如说定义数据模型、定义接口、给活动排序等。
  
• 总体来看，活动的描述要包含：活动的内容、次序、产出、参与人员、活动前应满足哪些条件、活动后的状态和结果。

2.2.7 计划驱动和敏捷开发

• 前面说过，不同的软件类型会有不同的软件过程，那么我们首先把它分成两大类：
  

• Plan-driven processes：

  • 所有的开发活动是预先计划好的，并且进展就是根据这个计划来衡量的。

  • 也就是说，整个软件开发过程有一个完备的计划，有规定的阶段性活动，并且每一个活动都有相应的成果需要检验，整个开发进展是按照这个计划来进行的。

• In agile processes：

  • 敏捷过程，敏捷开发。计划是增量式的。

  • 在开发过程中经常遇到用户的需求变更，敏捷过程对响应客户需求的变化是比较容易的，计划驱动过程则难以应对。

  • web系统就是软件需求变化很快的一类系统，采用agile processes

  • 增量式，就是把整个系统划分成一块一块的，先开发前面的几块，需求变了后，再加上一个增量

• 实际应用：

  • 实际上，一个软件过程可能同时包含这两种方法。
  • 对于一个有一定规模的软件系统开发来讲。软件过程可能要包含这两种因素。
  • 软件过程没有绝对好坏，关键是这样一个软件过程对所开发的系统是否合适，是否最经济。

2.3 Software Processes Model 软件过程模型详述

2.3.1 概述

• 软件过程模型是对软件过程的抽象表达。它抽取了活动的特征，来反映这个活动的内容、成果、阶段、次序等。

• 三种典型模型：
  

• The waterfall model：

  • 是最早提出的一种软件过程模式，非常传统，至今仍被广泛被采用。

  • 它是一种 Plan-driven 计划驱动的模式，开发过程划分为明确的阶段。

• Incremental development：

  • 增量式开发，是软件的定义开发和验证活动交替进行的。
  • 可以是计划驱动的，也可以是敏捷开发方式的。
  • （广义）增量的含义有两种：
    • 一：就指敏捷开发（狭义）
    • 二：不同的开发版本，原型

• Reuse-oriented software engineering

  • 利用现成的组件，进行编码，构成新的系统。
  • 它也可以是Plan-driven，也可以是 agile 。

2.3.2 Waterfall model 瀑布模型

• 瀑布模型：
  

  • 五个阶段：需求定义、系统和软件设计、实现（编码）和单元测试、集成和系统测试、运行和维护。

    五个阶段有清晰的阶段划分。阶段之间有正向的和反向的箭头连接。

  • **正向箭头：**代表这个阶段的工作完成，经过评审以后可以进入下个阶段，像瀑布一样逐级而下。

  • **反向箭头：**代表这个阶段的工作存在的问题，要把反馈送回去，再重新进行工作，进行评审。

• 详细解释：
  

  • （1）Requirements analysis and definition：

    需求分析和定义，对应 software specification 这样的一个阶段活动。

  • （2）System and software design：

    对应着 系统结构的设计、算法的设计、数据结构的设计。

  • （3）Implementation and unit testing：

    实现和单元测试。实现理解为programming 或 coding；单元测试，一般都是由程序员来承担的，在编码的过程中，通常也要进行单元测试。

  • （4）Integration and system testing：

    经过单元测试，集成起来的子系统，叫做 integration testing

    把整个系统集成起来，完成的测试叫做 system testing。

    不同测试目标的测试方法 不一样。

  • （5）Operation and maintenance：

    系统投入运行并维护。

• 瀑布模型的缺陷：

  • 瀑布模型将整个项目，划分成清晰的缺乏柔性的几个阶段（inflexible partitioning）使得它在响应客户需求的变化时就变得困难。。**缺乏柔性划分：**在瀑布模型里，每个阶段的工作必须整体完成并评审通过后，才能进入下一阶段。而一旦进入后面的阶段，若发现了问题，就得返回重做，这样代价很大。但在软件开发过程中，需求更改是非常常见的情况。

• 瀑布模型适用：

  • **适用于：**需求清晰（well understood）、功能明确、变化有限 的系统。
  • **适用于：**大型系统（因为大型系统的需求很复杂，通常要做大量的工作，将它完整挖掘，精确描述；大型系统的整体设计不能频繁修改）。

2.3.3 Incremental development 增量式开发

• 增量式开发过程图： （Concurrent 并发）
  

• 过程详解：

  • 增量式开发模式可以不需要给出一个清晰的需求描述，而是从一个outline description开始（也就是说，我大致先知道需要做哪些功能）
  • 一旦有了一个大致的功能和性能要求，就可以通过specification，development，validation。构成一个软件的初始版本，也叫原型**（Initial version）** 。
  • 原型（Initial version）构造好后，交给用户来使用和评价，用户若觉得这个版本不合适，开发人员再进行修改，形成第二个版本。不断重复这些过程，就会形成很多的中间版本**（Intermediate versions），直到形成一个最终版本（Final version）**。

• 补充：

  • **用户参与：**用户是参与在开发过程中的。用户一直和开发团队进行交流，每开发出一个新的版本，用户要进行评价并产生反馈意见，然后由开发者来修订，产生不同的中间版本，最终演化成一个最终版本。
  • **别名：**演化式开发、原型开发。
  • **增量式含义：**每个增量，是在上一个版本的基础上，再进行的工作。

• benefits：

  • 对用户需求变化的适应性的代价会比较小
    • 瀑布模型，有一个清晰的阶段划分，每个阶段都需要有阶段性的成果，包括阶段性的文档用于评审。如果后期发生的变化，前面工作都需要重新来做，代价大。
    • 增量式开发，最后的版本是不断地修改而成，在做中间快速构造原型的过程中，几乎不产生文档，直到最后的版本出现才形成正式的文档。
  • 更容易获得用户的反馈
    • 瀑布模型，用户只在第一阶段，即需求分析阶段参与，后面都不参与。
    • 增量式开发，用户是一直参与其中的。每一个版本都会得到用户的及时反馈。
  • 更早的交付和部署
    • 瀑布模型，阶段固定，中间产物多，开发周期长。
    • 增量式开发，中间文档少，需求变化能得到快速响应，开发周期短。

• problems：

  • 过程不可见
    • 可见（visible）指的是：用户查看开发过程中的中间文档来获取信息。
    • 增量式开发，追求速度，不会产生大量中间文档，用户就难以系统地获取信息，就不可见。
  • 系统结构可能随增量变多而逐渐退化
    • 起初从outline description开始，意味着这个初始结构就可能存在缺陷（因为没有精确的需求定义），后面一版一版的修改，很可能会造成系统结构不断地退化。
    • 除非花钱花时间来重构改善这个软件，否则，经常性的这样的一个改变会导致这个结构的崩溃。（一样东西，若起初就有完整的设计，那么必将呈现一个好的结构；反之，若一开始就糙，再不断修改，就变得更糙，结构就一直存在缺陷）

• 瀑布模型和增量式开发对比：

  • 瀑布模型和增量式开发，两个优缺点几乎是互补的。
  • 增量式开发：
    • 用户全程参与，能得到用户的即时反馈，对于用户需求的变化，响应会比较好。
    • 开发快，交付早。中间过程不可见，系统结构可能会逐渐退化。
    • 适用于：中小型系统（生命周期较短，对结构和可维护性要求较低）
  • 瀑布模型：
    • 用户只参与第一阶段（需求定义），用户的需求发生变化，难以及时反映到开发过程中。
    • 开发慢，交付晚。中间过程可见，系统结构精确且稳定。
    • 适用于：大型系统（生命周期较长，对结构和可维护性要求较高）

2.3.4 Reuse-oriented SE 面向复用的软件工程

• 概念

  Based on systematic reuse where systems are integrated from existing components or COTS (Commercial-off-the-shelf) systems. （COTS：商用组件，可以购买来直接使用的）

• Process stages：

  • Component analysis
  • Requirements modification
  • System design with reuse
  • Development and integration

• 现状：

  **目前已是构造许多事物系统的标准方法。**是一种：**比较快速，而且能保证质量的，**一种软件系统开发模式。（因为现在开源软件、机构自研的组件、商业组件经过了大量积累）

• 完整过程图：
  
  （1）需求定义

  （2）组件分析：看那些组件可以满足我们系统构造的需要。

  （3）需求模拟：因为可复用的组件不可能完全贴合我们的需求，所以要做一些妥协。在不影响软件需求的本质功能和性能的前提下，将现有的组件做适当的修改。

  （4）复用地进行系统设计

  （5）开发和集成：用一些集成的代码把现有的组件集成起来，完成整个系统的实现。

  （6）系统验证：这种代码完成以后进行系统的确认。

• Types of software component 典型的软件组件类型（拿来复用的）：

  • Web service组件式开发，面向服务web系统的远程调用组件。
  • Collections of objects：对象的集合，这些对象被开发成一个包，并与组件框架(.net 或 J2EE)集成。
  • Stand-along：用于特定环境的一些商用独立的组件。

2.4 Process activities 过程活动详述

2.4.1 概述

• 真正的软件过程 是一些活动的交织：
  • Real software processes are inter-leaved sequences of technical, collaborative and managerial activities with the overall goal of specifying, designing, implementing and testing a software system.
  • 前面给出了三种典型的软件过程模型，而实际开发过程中，往往会根据软件类型和结构特点，将不同模型的一些元素带入自己的开发过程。
  • 真正的软件过程是技术、协作和管理活动的交错序列，其总体目标是指定、设计、实现和测试软件系统。
• 四个基本活动（所有软件过程都具备）：
  • The four basic process activities： specification, development, validation and evolution
  • 对于不同的软件过程，以不同的组织方式来呈现。瀑布模型中，以顺序的模式来组织的。增量式开发中，是交织在一起，交替进行的。

2.4.2 Software specification

• Definition：

  • The process of establishing what services are required, and the constraints on the system’s operation and development.（确定需要哪些服务，以及对系统的操作和开发的约束）。
  • 确定服务services：软件需求
  • 确地约束constrains：对于软件性能、开发过程、文档描述等等，各种各样的限制。

• Process：**
  

• The requirements engineering process
  

  • Feasibility Study
    • 产出：Feasibility report （可行性报告）
    • 进入：Requirements elicitation and analysis
  • Requirements elicitation and analysis
    • 产出：System models （系统模型）
    • 进入：Requirements specification
  • Requirements specification
    • 产出：User and system requirements（用户和系统需求）
    • 进入：Requirements specification（Feedback） 和 Requirements validation
  • Requirements validation
    • 产出：Requirements document （需求文档）
    • 进入：Requirements validation（Feedback）

• Requirements document：

  • 由system models，User and system requirements，Requirements validation 共同合成。

2.4.3 Software design and implementation

• Relationship between Software specification & software design :

  • Software specification: define what to do？
  • software design: define how to do？

• 软件设计和实现 (design & implementation)：

  • 就是我们所说的 development 这个阶段，即：开发阶段。
  • 是一个将系统的软件需求定义，转换成一个可执行的系统的过程。
  • 设计和实现的活动是密切相关的，可以相互穿插的（比如在增量式开发中就是交替进行的）。

• Software design：

  • Design a software structure that realizes the specification
  • 设计符合规格的软件结构

• Implementation：

  • Translate this structure into an executable program
  • 将该结构转换为可执行程序;

• A general model of the design process
  

  • 仍然是一个 activity model。分为三个层次，拿到inputs，进行design activities，得出outputs

  • 矩形框：代表输入源或者输出目标，圆角矩形：代表活动。

  • 中间的圆角矩形，就是我们设计的几个主要活动：

    • 体系结构设计（表示设计系统的整体的架构）
    • 接口设计（设计交互组件与组件之间的接口，对象与对象之间的接口）
    • 组件设计（指一个组件的细节设计，内部的实现算法、数据表示等）
    • 数据库设计（对于以数据为中心的一些系统来讲，数据描述是非常关键的，比如数据库系统里的实体关系模型）
      

  • Outputs的四个子部分合起来就变成了：requirements specification 需求规格说明.

2.4.4 Software validation

• 含义：

  • Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the system customer.
  • Verification and validation：验证 和 确认。
  • 保证一个系统，遵从自己的定义，并且满足客户需求。
  • specification 包含：Requirement specification，design specification，以及其他在软件过程中产生的相关定义，包括我们软件开发过程中的应该执行的相应的规范。

• Validation involves checking and review processes and system testing.

  • 涉及到：检验、评审、测试。

• checking and review （检验和评审）：

  • 查看开发过程中产生的文档、源代码。
  • 属于静态过程。

• testing（测试）：

  • 执行系统，用测试数据来发现系统存在的缺陷和错误。

  • 属于动态过程。

  • 软件测试，在 V&V 活动中，显然是最重要的。

• 软件测试详解：

  • 测试三大阶段：
    
    
  • 组件测试：一个组件内部的测试。
  • 系统测试：把所有的组件集成为一个完整的系统，对它的功能和性能进行测试。
  • 确认测试：由用户来测试系统是否能满足自己的实际需求需要，通过这关就可以交付软件。

• Testing phases in a plan-driven software process
  

• 在计划驱动的软件过程模式下的，测试阶段的，一张详细的示意图。

  上下两排都是活动，中间文档是我们的测试计划。

• **测试活动：在最下面一排，**分别对应了我们前面讲的三个阶段。其中 Sub-system integration test 还包含着这张图右边的 Module and unit code and test （即单元测试 unit test）

• **测试计划：在中间一排：**单元测试通常是程序员完成对自己编程的模块的测试，单元测试，跟我们系统的，详细设计，也就是模块内部的算法、数据结构的设计有关。

  Sub-system integration test plan：是根据 System design 和 Detail design来做出的。

  System integration test plan：是根据 system specification 和 System design 来做出的

  Acceptance test plan：是根据 Requirement specification 和 system specification来做出的

• **软件活动：在最上面一排，**实际上是把我们整个的软件活动又给分析一遍，把整个的系统的需求定义和设计定义分得更细致一点，并且对应着我们的测试计划，较早阶段就可以做出Acceptance test plan，而在系统的设计以后，可以做出System integration test plan 和Sub-system integration test plan。

• 这张图很重要，可以帮助理解，软件各阶段的活动和测试之间的关系。（比如可以看出：测试计划跟需求分析的定义，跟系统设计详细、算法设计都有很大的关系）

2.4.5 Software evolution

• 软件演化含义：

  • Software is inherently flexible and can change. （软件本质上就是灵活的和易变的）
  • 软件过程必须要能够适应事物的变化，改变软件系统，满足用户新的需求，这就是软件演化。

• 软件演化活动模型：
  

  • 定义系统需求：因为新的需求出现，我们要把这个新的需求加进去。
  • 获取现有系统：拿到新需求后，分析和评价现有的系统
  • 进行系统改变的相关定义
  • 修改现有的系统：满足新的需求。（包含着我们对系统局部的设计，或者增加一些设计，甚至是大量的一些修改，然后编码形成新的系统）同时新的系统形成也是需要进行确认的，所以所谓的修改这个系统其实包含了：变化的设计、编码以及测试。

• 软件演化可大可小：

  可能是修改一个bug，也可能是大的结构的调整，还有可能是整体代码的换新。