【现代软件工程】第三章

软件过程及过程模型

软件过程：一个为创建高质量软件所需要完成的活动、动作和任务的框架 。
软件过程模型：也称软件开发模型 或 软件生存周期模型，是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。

通用活动

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

普适性活动

软件项目跟踪和控制
风险管理
软件质量保证
技术评审
测量
软件配置管理
可复用管理
工作产品的准备和生产

过程流

线性过程流，迭代过程流，演化过程流，并行过程流

过程模型

传统过程模型（惯用过程模型）

1.写了再改模型
2.瀑布模型
3.增量过程模型
4.演化过程模型：原型开发模型，螺旋模型，并发模型

专用开发模型

基于构件的开发 面向方面的开发

写了再改模型

不需要太多其他准备或相关知识, 大家上来就写代码, 也许就能写出来, 写不出来就改, 也许能改好

瀑布模型

瀑布模型将软件生命周期划分为软件计划、需求分析、设计、实现、测试、运行和维护等阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。

所有过程模型的祖宗
项目从开始到结束按照一定的顺序执行
瀑布模型是文档驱动的，各个阶段有顺序也不交叉

V模型

瀑布模型的变体

(1)测试阶段划分得很清楚。
(2)每个开发阶段都有相应的测试对其进行验证。
(3)测试与开发是串行进行的而不是并行，也就是测试需要等开发完成后再开始。
(4)测试对象只有程序，而不包括需求等其他的说明书。

特点

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

适合的项目特征

需求明确固定
方案工作流程线性
类似项目短期项目

优点

强迫开发人员采取规范的方法（例如，结构化技术）
要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
严格的规定了每个阶段必须提交的文档
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。

存在的问题

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

适用场合

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

原型开发模型（快速原型）

原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。
一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型
被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发

优点

快速开发出可以演示的系统，方便了客户沟通。
采用迭代技术能够使开发者逐步弄清客户的需求。

缺点

用户有时误解了原型的角色，例如他们可能误解原形应该和真实系统一样可靠
缺少项目标准，进化原型法有点像编码修正
缺少控制，由于用户可能不断提出新要求，因而原型迭代的周期很难控制
额外的花费：研究结果表明构造一个原型可能需要10%额外花费
运行效率可能会受影响
原型法要求开发者与用户密切接触，有时这是不可能的。例如外包软件。

存在的问题

用户似乎看到的是软件的工作版本，其实反映软件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但开发速度可以很快。
开发者常常需要实现上的折衷，以使原型能够尽快工作。
快速原型开发往往是以牺牲质量为代价的

使用策略

在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：抛弃策略和附加策略。

废弃策略： 主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统
追加策略
主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统

适用情况

项目需求不明确：用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；
需求不确定，容易变化：开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；

哪些要进行原型化

人机界面
系统的功能或 算法原型

设计工具

原型制作并不一定要像传统代码一样进行设计编码，有很多原型工具，像 Axure、墨刀等，简单的拖拽就可以实现简单的界面和交互，同样可以达到确认需求的目的。

软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大

螺旋模型

是一种演化过程模型，主要针对大型软件项目的开发。
风险驱动的软件开发模型
1.采用循环的方式，逐步加深系统定义和实现的深度
2.确定一系列里程碑，确保stakeholders都支持系统解决方案
3.第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本
结合了原型的迭代性质和瀑布模型的可控性、系统性特点。

基本思想

使用原型及其他方法来尽量降低风险。
结合原型的迭代和 瀑布的系统性和可控性特点

优点

结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型。
采用循环的方式逐步加深系统定义和实现的深度，同时更好地理解、应对和降低风险
确定一系列里程碑，确保各方都得到可行的系统解决方案。
始终保持可操作性，直到软件生命周期的结束。
风险驱动。

存在的问题

螺旋模型依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。
软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。
增加了风险管理成本

并行模型

适合于不同的团队共同开发系统
可以表示为一系列框架活动、软件工程动作和任务以及相应的状态。
定义了一系列事件，这些事件将触发软件工程活动、动作或者任务状态的转换。

增量模型

增量模型以迭代的方式运用瀑布模型。
随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付。

增量式交付

使用方法

软件被作为一系列的增量来进行开发，每一个增量都提交一个可以操作的产品，可供用户评估。
第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。
客户使用上一个增量的提交物并进行评价，制定下一个增量计划，说明需要增加的特性和功能。
重复上述过程，直到最终产品产生为止。

优点

提高对用户需求的响应：用户看到可操作的早期版本后会提出一些建议和需求，可以在后续增量中调整。
人员分配灵活：如果找不到足够的开发人员，可采用增量模型，早期的增量由少量人员实现，如果客户反响较好，则在下一个增量中投入更多的人力。
可规避技术风险：不确定的功能放在后面开发。

存在的问题

每个附加的增量并入现有的软件时，必须不破坏原来已构造好的东西。
加入新增量时应简单、方便 ——软件的体系结构应当是开放的。
仍然无法处理需求发生变更的情况。
管理人员须有足够的技术能力来协调好各增量之间的关系。
难以确定所有版本共需的公用模块。

适合的项目特征

需求基本明确，可能发生变化
市场用户对于市场和用户把握需要逐步了解
系统改造，需要一步步实施，模块分批次交付

专用过程模型

基于构件的开发：能够使软件复用
形式化方法—注重需求的数学规格说明
面向方面的软件开发（AOSD)—为定义、说明、设计和构建方面提供过程和方法 (AOP,面向方面编程），将系统通用功能与业务逻辑分离，关注系统通用功能
统一过程（UP）—一种“用例驱动、以构架为中心的迭代和增量”，软件过程和统一建模语言(UML)紧密结合

基于构件的开发

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

优点：

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

缺点

缺乏通用的构件组装结构标准，风险较大；
构件可重用性和系统高效性之间不易协调；
由于过分依赖于构件，构件质量影响着最终产品的质量。

基于UML的统一建模过程——RUP

RUP包括初始、细化、构造和移交4个阶段，每个阶段又分若干次迭代，每次迭代都有一个核心工作流（包括5个活动：需求、分析、设计、实现、测试），如下图：

几种模型的比较