软件工程 第二章 过程模型

通用过程模型

通用过程框架:

• 框架活动:沟通,策划,建模,构建,部署
• 普适性活动:项目跟踪控制,风向管理,质量保证,配置管理,技术评审等

常见的过程流(process flow):

• 线性过程流(linear process flow)
• 迭代过程流(iterative process flow)
• 演化过程流(evolutionary process flow)
• 并行过程流(parallel process flow)

明确任务集:每个框架活动由一系列软件工程动作构成,每个软件工程动作由任务集来定义,任务集明确了将要完成的工作任务.

• 所需完成任务的列表
• 所需生产的工业产品列表
• 应用质量保证过滤的列表

过程模式:

• 描述了软件工程工作中遇到的过程相关的问题
• 明确了问题环境
• 给出了针对该问题的一种或集中可证明的解决方案
• [Amb98]一种在软件过程的背景下,同一描述问题解决方案的方法.

过程模式的类型:

• 步骤模式:定义了与过程框架活动有关的问题
• 任务模式:定义了与软件工程动作或工作任务模式相关的问题
• 阶段模式:定义了过程中发生的任务序列

惯用过程模型

惯用过程模型提倡有序的软件工程方法.

瀑布模型

瀑布模型(waterfall model),又称线性顺序模型(linear sequential model).

瀑布模型一般流程:沟通->策划->建模->构建->部署

瀑布模型是线性不可逆的,适用于需求明确的项目.

基于瀑布模型的改进模型:

• V模型
  

RAD(快速应用开发)模型是软件开发过程中的一个重要模型,由于其模型构图形似字母V,所以又称软件测试的V模型.

V模型大体可以划分为以下几个不同的阶段步骤:客户需求分析,软件需求分析,概要设计,详细设计,软件编码,单元测试,集成测试,系统测试,验收测试.

• W模型
  

W模型，由Evolutif公司提出,相对于V模型,W模型增加了软件开发各阶段中同步进行的验证和确认活动.

由两个V字型模型组成,分别代表测试与开发过程,明确表示出了测试与开发的并行关系.

测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求,设计等开发输出的文档同样要测试

(这里针对设计文档,一般可以划分为需求设计文档,概要设计文档,详细设计文档和代码文档)

也就是说,测试与开发是同步进行的。

从这个角度来说,一个完整合格的测试人员对软件各方面把握程度应该比开发人员更高,一个测试人员要能胜任软件研究任何一个岗位.

W模型有利于尽早地全面的发现问题. 例如,需求分析完成后,测试人员就应该参与到对需求文档的验证和确认活动中,以尽早地找出缺陷所在.

同时,对需求的测试也有利于及时了解项目难度和测试风险,及早制定应对措施,这将显著减少总体测试时间,加快项目进度.

增量模型

适用情景:初始的软件需求明确,但是整个开发过程不宜单纯适用线性模型,某个公司的核心产品.

增量模型的特点:

• 综合了线性过程流和并行过程流的特点
• 每一次增量都要提交一个可运行的程序
• 关注点分离

演化模型

演化模型进行原型开发:

• 抛弃型原型:使用一种快速的开发方法,不考虑细节,只考虑核心功能,一般开发的程序非常大型冗余,使用代码生产的方法.非常适用于用户需求的确认.
• 改进型原型:构建一些原型的系统,但是有部分是可以用的,可以在最初模型上加以改进最终使用,使用的语言与工具需要和最终一致,用于确认核心功能,可以在最终模型上进行复用.
• 界面原型:先设计若干个界面原型,根据场景列出所有的功能菜单,若某个功能菜单被确定选用,则进一步地根据场景对功能进行确定,使用visio或ppt.

演化模型使用情景:

• 客户提供了基本功能,但是并没有提供技术系统
• 用于快速开发一个模型

演化模型缺点:

• 很少好用,大部分很慢又巨大
• 一般作为被抛弃的模型

螺旋模型

螺旋模型特点:

• 采用循环的方式,每一次循环都进行风险分析
• 确定一系列里程碑,通过该方式实现进度控制
• 主要面向高风险的项目

并发模型:协同

• 在某一特定时间,可能存在任意模型状态

其他过程模型

• 基于构件(模块)的模型:这个过程模型能够使软件复用,是一个发展目标
• 形式化方法:强调需求的数学规范说明,一个变形是cleanroom(净室软件工程)
• 面向方面的软件开发(AOSD,AOP):为定义,说明,设计和构建方面提供方法和过程.
  横切关注点:如果某个关注点涉及系统多个方面的功能,特性和信息,那么称其为横切关注点.

AOP是OOP的延续,是软件开发中的一个热点,也是Spring框架中的一个重要内容,是函数式编程的一种衍生范型.

利用AOP可以对业务逻辑的各个部分进行隔离,从而使得业务逻辑各部分之间的耦合度降低,提高程序的可重用性,同时提高了开发的效率.

可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加某种特定功能的一种技术.

AOP实际是GoF设计模式的延续,设计模式孜孜不倦追求的是调用者和被调用者之间的解耦,提高代码的灵活性和可扩展性,AOP可以说也是这种目标的一种实现。

• 统一过程:一种"用例驱动,以架构为核心,迭代并且增量"的软件过程与统一建模语言的紧密结合.

统一过程(UP)

UP(统一过程,unified process):认识到与客户沟通以及从用户角度描述系统并保持该描述的一致性的重要性,强调软件体系结构的重要作用.建立了迭代的,增量的过程流.

UP模型的基础:

• 从分析角度看:基于场景,因而以用例为核心
• 从设计角度看:基于场景,因而以体系结构为核心.

UML(统一建模语言,unified modeling language):

UP的阶段:

• 起始阶段(inception phase):识别基本业务需求并用用例初步描述功能.
• 细化阶段(elaboration phase):扩展了初始阶段定义的用例,对项目计划进行修订.
• 构建阶段(constrction phase):软件增量所要求的的特征与功能基本实现.以及集成活动.
• 转换阶段(transition phase):包括通用构建活动的后期阶段以及通用部署活动的第一部分.在转换阶段结束后,软件增量成为可用的发布版本.
  beta测试:面对市场只有受邀用户得到测试,用于发现问题,会跟踪用户相关操作.
  alpha测试:用于公司内用户测试,开发人员指导用户测试软件来发现问题.
• 生产阶段(production phase):对持续使用的软件进行监控,提供运行环境的支持,提交并评估缺陷报告与变更请求.

有可能在构建,转换和生产阶段的同时,下一个软件增量的工作已经开始.

UP工作产品:

• 起始阶段:初始用例模型,愿景文档
• 细化阶段:分析模型边界,确定商业案例,风险评估,应用案例等;进一步细化软件内容,可能会添加非功能的细化,如类模型,行为模型等;在需求模型基础上进行体系结构的设计.
• 构建阶段:用例的具体功能实现以及相关文档,测试等内容.
• 生产阶段:对增量的发行与对系统的测试维护,对漏洞的修补.

个人软件过程(PSP)

团队软件过程(TSP)

• 建立自我管理团队来计划和跟踪他们的工作,确定目标,建立团队自己的过程和计划.
• 指示管理人员如何指导和激励其团队,以及如何帮助他们保持团队的最佳表现.
• 使得CMM从第五级的行为常规化并如同预期一样,加速软件过程改进.
• 为高成熟度的软件组织提供改进知识.
• 协助大学传授工业级软件知识.