二、软件过程及过程模型

二、软件过程及过程模型
1. 软件过程
（教材）一个为创建高质量软件所需要完成的活动、动作和任务的框架 。

（百度百科）一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。

通用活动

沟通：包含了与客户(和其他共利益者)之间大量的交流和协作，还包括需求获取以及其他相关活动。
策划：指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。
建模：包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求；设计可以实现需求。
构建：包括编码(手写或自动生成)和测试。
部署：软件(全部或者完成的部分)交付到用户，用户对其进行评测并给出反馈意见。
2. 软件过程模型
也称 软件开发模型 或 软件生存周期模型

是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。

对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

3. 通用过程模型

4. 过程流

5. 过程模型
写了再改模型
瀑布模型
增量过程模型
演化过程模型
原型开发模型
螺旋模型
并发模型
基于构件的开发
5.1 瀑布模型

瀑布模型的变体–V模型

瀑布模型的特点

阶段间具有顺序性和依赖性
推迟实现的观点
质量保证的观点
瀑布模型的优点

可强迫开发人员采用规范的方法（例如，结构化技术）。
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
严格地规定了每个阶段必须提交的文档。
瀑布模型的问题

难以应对需求变化：客户难以准确表达需求，软件团队很难准确理解需求。
过于理想：实际项目很少按照该模型给出的顺序进行；
风险太大：用户必须有耐心，等到系统开发完成才能见到软件；
阻塞状态：开发者常常被不必要地耽搁。
瀑布模型的适用场合

需求相当稳定，客户需求被全面的了解风险管理。
开发团队对于应用领域非常熟悉。
外部环境的不可控因素很少。
小型清晰的项目。
5.2 原型开发模型（快速原型）
原型开发模型的产生：

瀑布模型将软件生命周期划分成独立串行的几个阶段，前一个阶段没有完成便无法开始下一阶段的工作。

然而完整而准确的需求规格说明是很难得到的，因为：
在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求

随着开发工作的推进，用户可能会产生新的要求

开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境

原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。

一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发

原型开发的优点

快速开发出可以演示的系统，方便了客户沟通。

采用迭代技术能够使开发者逐步弄清客户的需求。

原型的使用策略：

废弃（throw away）策略
主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统

追加（add on）策略
主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统

原型模型— 适用情况

用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；

开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；

5.3 增量模型
增量模型以迭代的方式运用瀑布模型。

随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

 

增量模型的使用方法

软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估。

第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。

客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能。

重复上述过程，直到最终产品产生为止。

增量模型的优点

提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。

人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。

可规避技术风险：不确定的功能放在后面开发。

增量模型存在的问题

每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。

加入新增量时应简单、方便 ——软件的体系结构应当是开放的。

仍然无法处理需求发生变更的情况。

管理人员须有足够的技术能力来协调好各增量之间的关系。

难以确定所有版本共需的公用模块。

5.4 螺旋模型
Boehm于1988年提出，是一种演化过程模型，主要针对大型软件项目的开发。
风险驱动的软件开发模型

采用循环的方式，逐步加深系统定义和实现的深度，确定一系列里程碑，确保stakeholders都支持系统解决方案。

第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本，结合了原型的迭代性质和瀑布模型的可控性、系统性特点。

 

螺旋模型的优点

结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。

采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险。

确定一系列里程碑，确保各方都得到可行的系统解决方案。

始终保持可操作性，直到软件生命周期的结束。

风险驱动。

螺旋模型存在的问题

螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。

软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

5.5 专用过程模型
基于构件的开发 — 能够使软件复用

形式化方法模型 — 注重需求的数学规格说明

面向方面的软件开发 — 为定义、说明、设计和构建方面提供过程和方法

统一过程 — 一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合

基于构件的开发

是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段（集成）高效率、高质量地构造应用软件系统的过程。

 

优点：

充分利用软件复用，提高了软件开发的效率。

允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品。

缺点：

缺乏通用的构件组装结构标准，风险较大；

构件可重用性和系统高效性之间不易协调；

由于过分依赖于构件，构件质量影响着最终产品的质量。

5.6 形式化方法模型
从广义上讲，形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。
狭义的讲，形式化方法是运用形式化语言，进行形式化的规格描述、模型推理和验证的方法。
形式化方法原则上就是用数学与逻辑的方法描述和验证软件。
可以实现从描述到实现的自动转换。

优点

能够开发出无缺陷的软件
缺点

成本高、耗时

对开发人员的技术水平要求高