Chapter2：Software Processes：SE_Notes《软件工程》笔记

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，也可能是大的结构的调整，还有可能是整体代码的换新。

2.5 Coping with change

2.5.1 概述

• change

  • Change is inevitable in all large software projects

    • 业务发生的变化会导致新的需求

    • 新的技术可能会出现给带来改善这个实现的新的可能性

    • 平台发生改变可能需要应用程序移植到新的平台

  • Change leads to rework

    • change是不可避免的，change会导致rework，那么rework也是不可避免的。
    • 我们要做的就是：如何经济地 rework。将rework的cost降到最低。

• How to reduce the cost of rework？ 可以从两方面考虑

  • change avoidance —— 我尽量避免change的出现
    • 在软件过程中包含一些活动，这些 activities 能在 rework 之前预见可能的 change 。
    • For example, a prototype system may be developed to show some key features of the system to customers.
    • 比如我们就可以在设计用户交互系统的时候。那么由于交互系统呢，有很多和用户之间的交互的界面。那么我们就可以用圆形的方式，给大家看一下，我这个界面就要设计成这个样子。用户满意了以后，再做这部分的时候，后面的变化可能就会少了很多，这就是所谓的避免变化。
  • change tolerance —— 我尽量容忍change带来的影响
    • 通常涉及到增量式开发的某种形式。
    • changes 可以以尚未开发的增量方式实现。

2.5.2 Prototype development —— change avoidance

1. what is prototype development?
   

   • 软件原型，是一个系统的初始版本，用来示范和演示出一些概念事物，希望能得出一些设计选项。
     • **Incremental development 中的 prototype：**没有形成 final version 的中间那些版本（包括 initial / intermediate versions）都称之为prototype。
     • **Prototype development 中的 prototype：**指的是，可以作为示范，可得到反馈意见的，可以帮助我们改善对软件的理解。
   • 这里的 prototype 可以被用于：
     • 需求工程过程，来帮助需求导出和确认
     • 设计过程，可以帮助开发用户界面。
     • 测试过程，可以采用背对背的测试方法（指：多种形式变化的测试）。

2. Benefits

   可使用性、贴近用户需求、设计质量、可维护性、降低开发代价。

   .

3. **how to develop? **

   • process of prototype development（flow chart）：
     
   • 建立原型目标、定义原型功能、开发原型（产生原型代码）、评价原型（是否达到预期目标）
   • 基于 快速构造原型的 语言和工具 而开发 based on rapid prototyping languages or tools
   • 不需要考虑很多完整的功能
     • Focus on：开发的软件中，不容易理解的部分
     • Focus on：功能性需求，而不是非功能性需求
     • 一般不进行Error checking and recovery

4. Throw-away prototypes 抛弃式原型

   • 开发一个 prototype 之后，若发现它对于一个 production system 并不是一个好的基础，那么我们会将这个 prototype 抛弃（discard）。
     • 【不满足非功能型需求】调整系统以满足非功能性需求可能是不可能的。
     • 【无文档】原型通常没有文档记录
     • 【会退化】原型结构通常通过快速变化而退化。
     • 【不符合质量标准】原型可能不符合正常的组织质量标准。
   • 对比 Incremental development中的prototype：增量式开发中的原型是一版一版的中间版本，这是不会抛弃的。这两个prototype是完全不一样的。

2.5.3 Incremental delivery —— change tolerance

1. what is Incremental delivery?

   • 完整系统，不是一次性地交付；开发和交付被分成若干个增量Increment，每个增量是完整系统要的功能的一部分。

   • 综合了瀑布模型和增量式开发的优势。

   • delivery 交付：就是把做出来的系统交给用户。

     • 在 Incremental development中，开发者是将软件增量开发（即：一版一版地开发，直到有 final version，最后只交付 final version 的整个系统就行了）。
     • 在Incremental delivery中，开发者是增量式地交付，把系统切分成多个部分，分很多次交付。

   • 需求会有不同的优先级（priority）需求越高，它所处的增量就越早。

   • 某个原型的开发一旦开始，它的需求就会被冻结（尽管这个需求对于后面的增量来说，可能还需要演化）这意思是，这个增量的开发会对后面的增量的开发有所帮助。当这个增量交付以后，用户的使用会产生反馈意见，这个增量就可以是后期增量开发的原型。

2. Incremental development vs. Incremental delivery
   

3. diagram of process

   • diagram：
     
   • 定义一个大致的需求（和 Incremental development类似，刚开始需求比较模糊）
   • 把需求划分成若干个增量
   • 设计系统的整体架构，即确定子系统（即：系统有哪些模块）
   • 根据优先级，开发系统的增量
   • 验证这个增量
   • 集成增量，将这个增量集成到前面已经开发的增量里面去
   • 再进行验证
   • 交付给用户
   • 若系统尚未完成，则继续开发增量；若完成了，则结束。

   这是一个迭代

4. advantages

   • 在应对软件变化方面是一个比较好的 process model

   • 每个增量在交付的时候就能给用户使用了，所以系统功能能得到一个不错的体现

   • 早期的增量可以作为原型帮助后面的增量导出需求

   • 整体项目失败的风险比较小

   • 最高优先级的系统功能（即最早期的增量）会接受彻底的测试。

5. disadvantages

   • 难以确定：能被系统的各个部分共同使用的功能。

     大多数系统都需要一些，能被系统的各个部分，共同使用的功能。但在增量式交付中，由于初期需求比较模糊，许多细节在增量实现之前都不清楚，所以初期很难识别出来这些共同功能

   • 软件的需求，在增量开发的过程中，才不断地清晰。这和“正常软件开发中需求应该一开始就明确”冲突了。

2.5.4 Boehm‘s spiral model

1. what is Boehm‘s spiral model ?
   

   • 和上面的增量式交付一样，综合了瀑布模型和增量式开发。但增量式交付比较新，而这个模型比较传统。
   • 表示成一个螺旋模型，而不是一系列带有回溯的活动。（回溯可以理解为：瀑布模型or增量式开发中的反向箭头）
   • 每一个环都代表螺旋模型中的一个阶段。
   • 阶段是不固定的，即：环是根据需求来确定的，而非固定的。
   • 整个过程中都包含了明确的风险评价。

2. Boehm’s spiral model of the software process
   

   • 整体为螺旋状的图，分为四个象限。 从第二象限起，顺时针绕一圈为一个环，每一环有4个阶段（每个象限（quadrant）为其中的1个阶段（phase））

   • 第一阶段，第二象限：是环的起点，左上角的描述为：对目标选项和限制进行决策。这个目标选项和限制指的是这一阶段活动的目标，以及它做哪些选择，选择的事物以及有哪些限制。

   • 第二阶段，第一象限：是对这阶段的活动做风险评价。右上角：识别出风险，并且作出决策。

   • 第三阶段，第四象限：是跟我们的软件通用活动相吻合的。开发验证下一级的产品，因为每一个还都代表着前一个环的下一级。

   • **第四阶段，第三象限：**计划下一阶段的活动。

   • 注意：

     • 第一象限有一条沿着径向的线。每个环的活动，沿着径向，产生了 prototype1，prototype 2，prototype 3。这带有 增量式开发 的特征。

     • 第四象限的径向线，内容又带有 瀑布模型 的阶段划分特征。

     • 刚才说：**每一个环的活动是不固定的，是根据需要做出决策的。这个就是我们每个环的第三象限plan next phase所做的事情。**如果一个环的本阶段目标没完成，那么他就在下一个阶段的活动在进行一次环，那么就产生的下一个的 prototype。

     • 这个模型的最重要的活动是：加入了risk analysis风险分析所以适合于比较大型的项目目，因为风险分析伴随着较高的成本代价。
       

3. usage

   • 能帮助人们理解，软件过程中的迭代，还有风险分析。
   • 此模型很少用于实际的软件开发，因为风险分析的成本较高。
     

2.5.5 The Rational Unified Process（RUP）

1. What is RUP ?

   • 是一种非常现代的通用过程，从UML里演化出来。

   • 综合了瀑布、增量式、复用 三种通用过程模型。
     

2. Phases in the Rational Unified Process

   • 四个阶段活动，每个阶段活动中的圆环代表迭代，也就是说 inception 可能有几个循环活动，代表可能会产生不同活动版本的活动产品。而整个过程又是一个 phase iteration，一个大的迭代活动。

   • 1个phase有4个activity。 In-phase阶段内部的activity需要迭代开发。Cross-phase阶段之间也需要迭代开发。
     
     

   • 下图是Rational公司官方给出的，可以反映出阶段内部的迭代以及整个过程的迭代特性。

     并且可以反映出，每个阶段的活动内容重点所在。

   • **纵向：**活动内容，不仅包含软件开发技术上的，还包含了管理部分的内容。

   • **横向：**四个阶段的活动。

   • **中间图像面积多少：**反映了这项活动，在这个阶段，重点的占比。
     

   • static workflows in RUP
     

3. RUP good practice
   

2.6 Chapter summary

1. 软件过程是生产软件系统所涉及的活动。软件过程模型是这些过程的抽象表示。

2. 通用过程模型描述软件过程的组织。这些通用模型的例子包括瀑布模型、增量开发和面向复用的开发。

3. 需求工程是一个软件规范开发的过程。

4. 设计和实现过程涉及到将需求规格说明书转换成可执行的软件系统。

5. 软件验证是检查系统是否符合其规范，是否满足系统用户的实际需要的过程。

6. 当你改变现有的软件系统以满足新的需求时，软件进化就发生了。软件必须进化以保持有用。◇流程应包括应对变化的活动。这可能涉及到原型阶段，这有助于避免在需求和设计上做出糟糕的决策。

7. 过程可以被组织起来进行迭代开发和交付，这样就可以在不破坏整个系统的情况下进行更改。

8. RUP是一个现代的通用过程模型，它被组织成四个阶段（inception, elaboration, construction and transition）但是将活动（requirements, analysis and design, etc）从这些阶段中分离出来。