软件工程-过程模型

软件过程的概念

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

1.惯用过程模型

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

1.1 瀑布模型

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

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

为何瀑布模型有时候会失效？ 1.实际的项目不多遵照瀑布模型提出的顺序。虽然线性模型能够加入迭代，可是它是用间接的方式实现的，结果是，随着项目组工做的推动，变动可能形成混乱。 2.客户一般难以清楚的描述全部的需求。而瀑布模型却要求客户明确需求，这就很难适应在许多项目开始阶段必然存在的不肯定性。 3.客户必需要有耐心，由于只有在项目接近尾声的时候，他们才能获得可执行的程序。对于系统中存在的重大缺陷，若是在可执行程序评审以前没有发现，将可能形成惨重的损失。

他的优势就是适合那种需求已经肯定的状况，且工做采用线性的方式完成的时候，瀑布模型是一个颇有用的过程模型。

1.2 增量过程模型

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

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

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

1.3 演化过程模型

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

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

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

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

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

螺旋模型

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

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

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

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

1.4 并发模型

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

并发建模可用于全部类型的软件开发，它可以提供精确的项目当前状态图。

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

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

统一过程模型

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

细化阶段

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

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

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

生产阶段

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

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

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