【笔记】过程结构及过程模型

一、软件过程结构

  软件过程：一个为创建高质量软件说需要完成的活动、动作和任务的框架。
  软件过程定义了软件工程化中采用的方法，当软件工程还包含该过程中应用的技术——技术方法和自动化工具。

1.通用过程模型

  每个框架活动由一些列软件工程动作构成；每个软件工程动作由任务集来定义，这个任务集明确了将要完成的工作任务、将要产生的工作产品\所需要的质量保证点，以及用于表明过程状态的里程碑。

  软件过程还有一个很重要的方面即过程流，过程流描述了在执行顺序和执行时间上如何组织框架中的活动、动作和任务。

- **线性过程流**从沟通到部署顺序执行五个框架活动。- **迭代过程流**在执行下一个活动前重复执行之前的一个或多个活动。- **演化过程流**采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本。- **并行过程流**将一个或多个活动与其他活动并行执行。

—

2.明确任务集

  每一个软件工程动作（如需求获取以及与沟通活动相关的动作）都由若干个任务集构成，而每一个任务集都由软件工程工作任务、相关工作产品、质量保证点和项目里程碑组成。

---

3.过程模式

  过程描述描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案。过程模式提供了一个模版 —— 一种在软件过程的背景下统一描述问题解决方案的方法。通过模式组合，软件团队可以解决问题并定义最符合项目需求的开发过程。

  Ambler提出了下面的过程模式的描述模版：
  模式名称：模式名称应能清楚地表述该模式在软件过程中的含义。
  驱动力：模式的使用环境及主要问题，这些问题会显现在软件过程中并可能影响解决方案。
  类型：定义模式类型。Ambler提出了三种类型：

• 1.步骤模式——定义了与过程的框架活动相关的问题。步骤模式包括与步骤（框架活动）有关的许多任务模式。
• 2.任务模式——定义了与软件工程动作或是工作任务相关\关系软件工程实践成败的问题。
• 3.阶段模式——定义在过程中发生的框架活动序列，即使这些活动流本质上是迭代的。

  启动条件：描述的是模式应用的前提条件。
  问题：描述模式将要解决的具体问题。
  解决问题：描述如何成功实现模式。这部分主要讨论随着模式的启动，过程的初始状态（模式应用之前就已存在）是如何发生改变的。解决方案也描述了随着模式的成功执行，模式启动之前所获得的软件工程信息和项目信息是如何变换的。
  结果描述模式成功执行之后的结果。模式完成时需要明确：（1）必须完成哪些开发组织或是开发团队相关的活动？（2）过程的结束状态是什么？（3）产生了哪些软件工程信息或是项目信息？
  相关模式：以层次化或其他图的方式列举与该模式相关的其他过程模式。
  已知应用和实例：说明该模式可应用的具体实例。

  过程模式提供了一种有效的机制，用以解决任何与软件过程相关的问题。模式使得软件工程组织能够从高层抽象开始（阶段模式）建立层次化的过程描述。高层抽象描述又进一步细化为一系列步骤模式以描述框架活动，然后每一个步骤模式又进一步逐层细化为更详细的任务模式。过很模式一旦建立起来，就可以进行复用以定义各种过程变体，即软件开发团队可以将模式作为过程模型的构建模块，定制特定的过程模型。

---

二、过程模型

• 概念：过程模型为软件工程工作提供了特定的路线图，该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。

• 重要性：软件过程提高了软件工程的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。

• 步骤：过程模型为软件人员提供了开展软件工程工作需要遵循的步骤。

• 工作产品：工作产品是对过程所定义的活动和任务的格式化描述。

• 质量保证措施：表征软件过程有效性的最好指标还是所构建产品的质量、及时性和寿命。

---

1.惯用过程模型

  惯用过程模型力求达到软件开发的结构和秩序，其活动和任务都是按照过程的特定指引顺序进行的。
  它规定了一套过程元素——框架活动、软件工程动作、任务、工作产品、质量保证以及每个项目的变更控制机制。每个过程模型还定义了过程流（也称工作流）——即过程元素相互之间关联的方式。

瀑布模型

  当从沟通到部署都采用合理的线性工作流方式的时候，可以清楚地理解问题 需求。这种情况通常发生在需要对一个已经存在的系统进行明确定义的适应性调整或是增强的时候；也可能发生在很少数新的开发工作上，但是需求必须是准确定义和相对稳定的。
  瀑布模型又称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持。

  瀑布模型的一个变体成为**V模型**。V模型描述了质量保证动作同沟通、建模相关动作以及早期构建相关动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一系列测试（质量保证动作），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。

  瀑布模型的问题：>1. 实际的项目很少遵守瀑布模型提出的顺序。虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果随着项目组工作的推进，变更可能造成混乱。>2. 客户通常难以清楚地描述所有的需求。而瀑布模型却要求客户明确需求，这就很难适应在许多项目开始阶段必然存在的不确定性。>3. 客户必须要有耐心，因为只有在项目接近尾声的时候，他们才可能得到可执行的程序。对于系统中存在的重大缺陷，如果在可执行程序评审之前没有发现，将可能造成惨重损失。  目前，软件工作快速进展，经常面临永不停止的变更流，特性、功能和信息内容都会变更，瀑布模型往往并不适合这类工作。尽管如此，在需求已经确定的情况下，且工作采用线性的方式完成的时候，瀑布模型是一个很有用的过程模型。—

增量过程模型

  在许多情况下，初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品， 然后在后续版本中再进行细化和扩展功能。在这种条件下， 需要选用一种以增量的形式生产软件产品的过程模型。
  增量模型综合了线性过程流和并行过程流的特征。随着时间的推移，增量模型在每个阶段都运用线性序列。每个线性序列生产出软件的可交付增量。
  运用增量模型的时候，第一个增量往往是核心产品。也就是满足了基本的需求，但是许多附加的特性（一些是已知的，一些是未知的）没有提供，客户使用该核心产品并进行仔细的评估，然后根据评估结果制定下一个增量计划。这份计划应说明需要增加的特性和功能。每一个增量的教辅都会重复这一过程，直到最终产品的产生。

—

演化过程模型

  软件开发人员需要一种专门应对不断演变的软件产品的过程模型。演化模型是迭代的过程模型，这种模型使得软件开发人员能够逐步开发出更完整的软件版本。下面介绍两种常用的演化过程模型。

• 原型开发

  客户定义了软件的一些基本任务，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法效率、操作系统的适用性和人机交互的形式等情况并没有把握。在这些情况和类似情况下，采用原型开发范型是最好的解决办法。

  不论人们以什么方式运用它，当需求很模糊的矢耦，原型开发模型都能帮助软件开发人员和利益相关者更好地理解究竟需要做社么。  理想状况下，原型系统提供了定义软件需求的一种机制。当需要构建可执行的原型系统时，软件开发人员可以利用已有的程序片段或应用工具快速产生可执行的程序。  原型开发存在问题：>1. 利益相关者看到了软件的工作版本，却未察觉到软件是随意搭成的，也未察觉到为了尽快完成软件，开发者没有考虑到整体软件质量和长期的可维护性。当开发者告诉客户整个系统需要重建以提高软件质量的时候，利益相关者会不愿意，并且要求对软件稍加修改使其变为一个可运行的产品。在绝大多数的情况下，软件开发管理层会做出妥协。>2. 作为一名软件工程师，为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。他们经常会使用不合适的操作系统或程序设计语言，仅仅因为当时可用或他们对此较为熟悉。他们也经常会采用一种低效的算法，仅为了证明系统的能力。时间长了，软件开发人员可能会适应这些选择，而忽略了这些选择其实并不合适的理由，结果使并不完美的选择成了系统的组成部分。—- **螺旋模型**  **螺旋模型**是一种演进式软件过程模型。它结合了原型的迭代性质和瀑布模型的可控性和系统性特点。它具有快速开发越来越完善的软件版本的潜力。  螺旋模型是一种风险驱动型的过程模型生成器面对与软件集中的系统它可以知道多个利益相关者的协同工作。它有两个显著的特点：一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。二是去诶的那个一系列里程碑作为支撑点，确保利益相关者认可是可行的且令各满意的系统解决方案。  螺旋模型被分割成一系列由软件工程团队定义的框架活动。每个框架活动代表螺旋上的一个片段。随着演进过程开始，从圆心开始顺时针方向，软件团队执行螺旋上的一圈所表示的活动。在每次演进的时候，都要考虑风险。每个演进过程都要标记里程碑——沿着螺旋路径达到的工作产品和条件的结合体。

  其他过程模型在软件交付后就结束了。螺旋模型则不同，它应用在计算机软件的整个生命周期。本质上，当螺旋模型以这种方式进行下去的时候，它将永远保持可操作性，指导软件产品的生命周期结束。过程经常会处于休止状态，但每当有变更时，过程总能够在合适的入口点启动（如产品提高）。  螺旋模型是开发大型系统和软件的很实际的方法。由于软件随着过程的推进而变化，因此在每一个演进层次上，开发者和客户都可以更好地理解和应对风险。螺旋模型把原型作为降低风险的机制，更重要的是，开发者可以在产品演进的任何阶段使用原型方法。它保留了经典生命周期模型中系统逐步细化的方法，但是把他纳入一种迭代框架之中，这种迭代方式与真是世界更加温和。螺旋模型要求在项目的所有阶段始终考虑技术风险，如果适当地应用这种方法，就能够在风险变为难题之前将其化解。—

并发模型

  并发开发模型优势也叫做并发工程，它允许软件团队表述本文所描述的任何过程模型中的迭代元素和并发元素。
  并发建模定义了一系列事件，这些事件将触发软件工程活动、动作或者任务的状态转换。
  并发建模可用于所有类型的软件开发，它能够提供精确的项目当前状态图。它不是把软件工程活动、动作和任务局限在一个事件的序列，而是定义了一个过程网络。网络上每个活动、动作和任务与其他活动、动作和任务同时存在。过程网络中某一点产生的事件可以出发与每一个活动相关的状态的转换。

—

演化过程综述

  很多广为人们尊重的软件工程专家建议：软件过程强调灵活性、可扩展性和开发速度而不是高质量。
  演化模型的初中是采用迭代或者增量的方式开发高质量软件。可是，用演化模型也可以做到强调灵活性、可延展性和开发速度。软件团队及其经理所面临的挑战就是在这些严格的项目、产品参数与客户满意度之间找到一个合理的平衡点。

---

2.专用过程模型

  专用过程模型往往应用面较窄且较专一，值适用于某些特定的软件工程方法。

基于构件的开发

  商业现货软件构件由厂家作为产品供应，通过良好定义的接口提供特定的功能，这些构件能够集成到正在构建的软件中。基于构件的开发模型具有许多螺旋模型的特点。它本质上是演化模型，需要以迭代方式构建软件。不同之处在于，基于构件的开发模型采用预先打包的软件构件来开发应用系统。
  建模和构建活动开始于识别可选构件。这些构件有些设计成传统的软件模块，有些设计成面向对象的类或类包。若不考虑构件的开发技术，则基于构建开发模型由以下步骤组成：

1. 对于该问题的应用领域研究和评估可用的基于构件的产品。
2. 考虑构件集成的问题。
3. 设计软件架构以容纳这些构件。
4. 将构件集成到架构中。
5. 进行充分的测试以保证功能正常。

---

形式化方法模型

  形式化方法模型的主要活动是生成计算机软件形式化的数学规格说明。形式化方法使软件开发人员可以应用严格的数学符号来说明、开发和验证基于计算机的系统。这种方法的一个变形是净室软件工程。
  形式化方法提供了一种机制，使得在软件开发中可以避免一些问题，而这些问题在使用其他软件工程模型时是难以解决的。使用形式化方法时，歧义性问题、不完整问题、不一致问题等都能够更容易地被发现和改正——不是依靠特定评审，而是应用数学分析的方法。在设计阶段，形式化方法是程序验证的基础，使软件开发人员能够发现和改正一些诶常常被忽略的问题。

  形式化模型的问题：

• 目前，形式化模型开发非常耗时，成本也很高。
• 只有极少数程序员具有应用形式化方法的北京，因此需要大量的培训。
• 对于技术水品不高的客户，很难用这种模型进行沟通。

---

面向方面的软件开发

  局部的软件特性被做成构件（例如面向对象的类），容纳后在系统架构中使用。随着现代计算机系统变得更加复杂，某些关注点——客户需要的属性或者技术兴趣点——已经体现在整个架构设计中。
  如果某个关注点涉及系统的多个方面的功能、特性和信息，那么这些关注点通常被称为横切关注点。方面的需求定义那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发（AOSD）通常称为面向方面编程（AOP）或者面向方面构件工程（AOCE），它是相对较新的一种软件工程模型，为定义、说明、设计和构建方面提供过程和方法——是对横切关注点进行局部表示的一种机制超越了子程序和继承方法。
  面向方面的过程还不成熟。这种过程模型看似具备了演化模型和并发过程模型的共同特点。演化模型适合定义和构建方面；而并发开发的并行特点很重要，因为方面和构件的过程活动之间建立起一步的通信非常重要。

• 过程管理工具

  过程管理工具帮助软件组织或团队定义完整的软件过程模型（框架活动、动作、任务、质量保证检查点、里程碑和工作产品）。而且，该工具为软件工程师的技术工作提供路线图，为经理们跟踪和控制软件过程提供模版。代表性工具有GDPA、ALM Studio、ProVision BPMx。

---

3.统一过程

  在某种程度上，统一过程尝试着从传统的软件过程中挖掘最好的特征和性质，但是以敏捷软件开发中许多最好的原则来实现。统一过程认识到与客户沟通以及从用户的角度描述系统（即用例）并保持该描述的一致性的重要性。它强调软件体系结构的重要作用，并“帮助架构师专注于正确的目标，例如可理解性、对未来变更的可适应性以及复用”。它建立了迭代的、增量的过程流，提供了演进的特性，这对现代软件开发非常重要。

—

统一过程的阶段

  UP的起始阶段包括客户沟通和策划活动。通过与利益向挂着写作定义软件的业务需求，提出系统大致的结构，并制定开发计划以保证项目开发具有迭代的增量特性。该阶段识别基本的业务需求，并初步用用例描述每一类用户所需要的主要特性和功能。此时的体系结构仅是主要子系统及其功能、特性的试探性概括。随后，体系结构将被细化和扩充成为一组模型，以描述系统的不同视图。策划阶段将识别各种资源，评估主要风险，制定进度计划，并为其在软件增量开发的各个阶段中的应用建立基础。
  UP的细化阶段包括沟通和通用过程模型的建模活动。细化阶段扩展了初始阶段定义的用例，并扩展了体系结构以包括软件的五种视图——用例模型、需求模型、设计模型、实现模型和部署模型。在某些情况下，细化阶段建立了一个“可执行的体系结构基线”，这是建立可执行系统的第一步。体系结构基线证明了体系结构的可实现性，但没有提供系统使用时所需的所有功能和特性。另外，在细化的最终阶段将评审项目计划以确保项目的范围、风险和交付日期的合理性。该阶段通常要对项目计划进行修订。
  UP的构建阶段与通用软件过程中的构建活动相同。构建阶段采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。为达上述目的， 要对在细化阶段开始的需求模型和设计模型加以完善，以反映出软件增量的最终版本。软件增量所要求的必须具备的特性和功能在源代码中实现。随着构件的实现，对每一个构件设计并实施单元测试。另外，还实时了其他集成活动（构件组装和集成测试）。用例用于到处一族验收测试，以便在下一个UP阶段开始前执行。
  UP的转换阶段包括通用构建活动的后期阶段以及通用部署（交付和反馈）活动的第一部分。软件被提交给最终用户进行Beta测试，用户反馈报告缺陷及必要的变更。另外，软件开发团队创建系统发布所必须的支持信息（如用户手册、问题解决指南及安装步骤）。在转换阶段结束时，软件增量成为可用的发布版本。
  UP的生产阶段与通用过程的部署活动一致。在该阶段，对持续使用的软件进行监控，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求。
  有可能在构件、转换和生产阶段的同时，下一个软件增量的工作已经开始。这就意味着五个UP阶段并不是顺序进行，而是阶段性地并发进行。
  软件工程的工作流分布在所有UP阶段。在UP中，工作流类似于任务集。工作流识别了完成一个重要的软件工程活动的必要任务，以及在成功完成任务之后所产生的工作产品。并不是工作流所识别的每一个任务都在所有的系那个目中应用。软件开发团队应根据各自的需要适当调整过程（动作、任务、子任务及工作产品）。

---

产品和过程

  Margaret Davis对产品和过程的双重性的评述：

  我相信，我们对软件组成部分和开发过程的观测证明了软件具有过程和产品的二象性。如果仅仅将软件看作一个过程或是一个产品，那就应用都不能正确地理解软件，包括其背景、应用、意义和价值。
  所有的人类活动都可以看成是一个过程，我们每一个人都从这些活动中获得对自我价值的认识，这些活动所产生的结果可以被许多人反复地在不同情况下使用。也就是说，我们是从我们自己或是他人对我们产品的复用中得到满足的。
  因此，将复用目标融入软件开发，这不仅潜在地增加了软件专业人员从工作中获得的满足感，也增加了接受“产品和过程二象性”这一观点的紧迫性。对于一个可复用的部件，如果仅仅从产品或是仅仅从过程的角度考虑，都不利于软件开发，这种批那面的观点或者影响了人们对产品的应用环境和应用方法的认识，或者忽略了该产品还可以作为其他开发活动的输入这一事实。因此，片面地强调某一方面的观点会极大地降低软件复用的可能性，也会大大减少工作的成就感。