软件工程-过程模型

软件过程的概念

软件过程是一个为创建高质量软件所需要完成的活动，动作和任务的框架。

1.惯用过程模型

惯用过程模型力求达到软件开发的结构和只需，其活动和任务都是按照过程的特定指引顺序进行的。

1.1 瀑布模型

瀑布模型又称为经典生命周期，它提出了一个系统的，顺序的软件开发方法，从用户需求规格说明开始，通过策划，建模，构建和部署的过程，最终提供完整的软件支持。

瀑布模型的一个变体称为V模型。V模型描述的质量保证动作同沟通，建模相关动作以及早期构建相关动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成了对问题及解决方案的详尽且技术性的描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一些列测试(质量保证动作)，这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。 实际上，经典生命周期模型和V模型没有本质区别，V模型提供了一种将验证和确认动作应用于早期软件工程工作中的直观方法。

为什么瀑布模型有时候会失效？ 1.实际的项目很少遵守瀑布模型提出的顺序。虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果是，随着项目组工作的推进，变更可能造成混乱。 2.客户通常难以清楚的描述所有的需求。而瀑布模型却要求客户明确需求，这就很难适应在许多项目开始阶段必然存在的不确定性。 3.客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能得到可执行的程序。对于系统中存在的重大缺陷，如果在可执行程序评审之前没有发现，将可能造成惨重的损失。

他的优点就是适合那种需求已经确定的情况，且工作采用线性的方式完成的时候，瀑布模型是一个很有用的过程模型。

1.2 增量过程模型

在许多情况下，初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。在这种条件下，需要选用一种以增量的形式生产软件产品的过程模型。

随着时间的推移，增量模型在每个阶段都运用线性序列。每个线性序列生产出软件的可交付增量。

运用增量模型的时候，第一个增量往往是核心产品。 也就是满足了基本的需求，但是许多附加的属性没有提供，客户使用该核心产品并进行仔细的评估，然后根据评估结果制定下一个增量计划。这份计划应说明需要对核心产品进行的修改，一遍更好的满足和客户的需求，，夜莺说明需要增加的特性和功能。每一个增量的交付都会重复这一课程，知道最红产品的产生。

1.3 演化过程模型

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

原型开发 已经定义了软件的一些基本任务，但是没有详细定义功能和特性需求。可以帮助软件开发人员和利益相关者更好的理解究竟需要做什么。 就是先设计一个原形，然后在原形系统不断调整以满足各种利益相关者需求的过程中，采用迭代技术，同时也使开发者逐步清楚用户的需求。

理想状态下，原型系统提供了定义软件需求的一种机制。当需要构建可执行的原型系统时，软件开发人员可以利用已有的程序片段或应用工具快速产生可执行的程序。

原型系统缺点： 1.利益相关者看到了软件的工作版本，却未察觉到整个软件是随意搭成的，也未察觉到为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。当开发者告诉客户整个系统需要重建以提高软件质量的时候，利益相关者会不愿意，并且要求对软件稍加修改使其变为一个可运行的产品。在绝大多数的情况下，软件开发管理层会做出妥协。 2.作为一名软件工程师，为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。他们经常会使用不合适的操作系统或程序设计语言，仅仅因为当时可用或他们对此较为熟悉。他们也经常会采用一种低效的算法，仅为了证明系统的能力。时间长了，软件开发人员可能会适应这些选择，而忽略了这些选择其实并不适合的理由，结果使并不完美的选择成了系统的组成部分。

尽管问题会发生，但原型开发对于软件工程来说仍是一个有效的范型。关键是要在游戏开始的时候指定规则，也就是说，所有利益相关者必须承认原型是为定义需求服务器的。然后丢弃原型，实际的软件系统时以质量第一为目标而开发的。

螺旋模型

螺旋模型将软件开发为一系列演进版本。在早期迭代中，软件可能是一个理论模型或是原型。在后来的迭代中，会产生一系列逐渐完整的系统版本。 螺旋模型被分割成一系列由软件工程团队定义的框架活动。

每个框架活动代表螺旋上的一个片段。随着演进过程开始，从圆心开始顺时针方向，软件团队执行螺旋上的一圈所表示的活动。在每次演进的时候，都要考虑风险。每个演进过程还要标记里程碑-沿着螺旋路径达到的工作产品和条件的结合体。 螺旋的第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本。

其他过程模型在软件交付后就结束了。螺旋模型则不同，它应用在计算机软件的整个生命周期。因此，螺旋上的第一圈可能表示“概念开发项目”，它起始于螺旋的中心，经过多次迭代，直到概念开发的结束。如果这个概念将被开发成为实际的产品，那么该过程将继续沿着螺旋向外伸展，成为“新产品开发项目”。新产品将沿着螺旋通过一系列的迭代不断的演进。最后，可以用一圈螺旋表示“产品提高项目”。本质上，当螺旋模型以这种方式进行下去的时候，它将永远保持可操作性，知道软件产品的生命周期结束。过程经常会处于休止状态，但当有变更时，过程总能够在合适的入口点启动。

螺旋模型是开发大型系统和软件的很实际的方法。由于软件随着过程的推进而变化，因此在每一个演进层次上，开发者和客户都可以更好的理解和应对风险。螺旋模型把原型作为降低风险的机制，更重要的是，开发人员可以产品眼睛的任何阶段使用原型方法。它保留了经典生命周期模型中系统逐步细化的方法，但是把它纳入一种迭代框架之中，这种迭代方式与真实世界更加吻合。螺旋模型要求在项目的所有阶段适中考虑技术风险，如果适当的应用该方法，就能够在风险变为难题之前将其化解。

1.4 并发模型

并发开发模型有时也叫做并发工程，它允许软件团队表述本章所描述的任何过程模型中的迭代元素和并发元素。 在某一特定时间，建模活动可能处于任何一种状态中.其他活动，动作或任务（如沟通或构建）可以用类似的方式表示。所有的软件工程活动同时存在并处于不同的状态。

并发建模可用于所有类型的软件开发，它能够提供精确的项目当前状态图。

并发建模可用于所有类型的软件开发，它能够提供精确的项目当前状态图。他不是软件工程活动，动作和任务局限在一个事件的序列，而是定义了一个过程网络。网络上每个活动，动作和任务与其他活动，动作和任务同时存在。过程网络中某一点产生的事件可以触发与每一个活动相关的状态的转换。

缺点：演化模型的初衷是采用迭代或者增量的方式开发高质量软件。可是，用演化模型也可以做到强调灵活性，可延展性和开发速度。软件团队及其经理所面临的挑战就是在这些严格的项目，产品参数与客户满意度之间找到一个合理的平衡点。

统一过程模型

UP(统一过程)起始阶段包括客户沟通和策划活动。通过与利益相关者协作定义软件的业务需求，提出系统的大致架构，并制定开发计划以保证项目开发具有地带和增量的特性。该阶段识别基本的业务需求，并初步用用例描述每一类用户所需要的主要特性和功能。此时的体系结构仅是主要子系统及其功能，特性的试探性概括。随后，体系结构将被细化和扩充成为一组模型，以描述系统的不同视图。擦花阶段将识别各种资源，评估主要风险，指定进度计划，并为其在软件增量开发的各个阶段中的应用建立基础。

细化阶段

包括沟通和通用过程模型的建模活动。细化阶段扩展了初始阶段定义的用例，并扩展了体系以包括软件的五种视图-用例模型，需求模型，设计模型，实现模型和部署模型。但是这个时候没有提供系统使用时所需的所有功能和特性。在细化的最终阶段将评审项目计划以确保项目的范围，风险和交付日期的合理性。该阶段通常要对项目计划进行修订。

构建阶段 构建阶段采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。为达到上述目的，要对在细化阶段开始的需求模型和设计模型加以完善，以反映出软件的最终版本。对每一个构建设计并实施单元测试。

转换阶段 包括通用构建活动的后期阶段以及通用部署活动的第一部分。软件被提交给最终用户尽心beta测试，用户反馈报告缺陷及必要的变更。另外，软件开发图那件创建系统发布所必须的支持信息。在转换阶段结束时，软件增量成为可用的发布版本。

生产阶段

与通用过程的部署活动一致。在该阶段，对持续使用的软件进行监控，提供运行环境的支持，提交并评估缺陷报告和变更请求。

有可能在构建，转换和生产阶段的同时，下一个软件增量的工作已经开始。这就意味着五个Up阶段并不是顺序进行，而是阶段性的并发进行。

注：本文内容均来自《软件工程 实践者的研究方法 第八版》，仅供自己学习