1.4 过程模型在线视频

大家好

我是北京理工大学

计算机学院 车海莺

今天我们来一起分享一下

软件工程里面的过程模型

过程模型这部分我们有

一些惯用过程模型

或者叫做传统过程模型

还有一些专用的过程模型

我们下面先看一下传统的过程模型

惯用过程模型

力求达到软件开发的结构和秩序

但是这样的诉求会产生一些问题

如果

惯用过程模型

力求达到软件开发的结构和秩序

那么对于富于变化的软件世界

和富于变化的业务

这一模型是否合适呢

如果我们抛弃了传统的过程模型

以及这些模型所规定的秩序

取而代之

以一些不够结构化的模型

非常灵活的模型

来进行软件开发

是否会使得我软件工作

无法达到协调和一致呢

这都是我们要真实的解决的问题

在传统的惯用过程模型当中

首先

我们不得不提的就是

瀑布模型

瀑布模型是最经典的过程模型

它由

沟通

策划

建模

构建

部署

这样五大块活动组成

在每个活动下面有

沟通下面包括项目启动和需求获取

在沟通之后的策划包括

项目估算

进度计划

项目跟踪

然后包括建模

建模里面包括分析建模和设计建模

在建模之后是构建

构建包括编码和测试

最后是部署

部署包括交付

后期的技术支持和维护

以及反馈

瀑布模型之所以称为瀑布模型

就是因为它整个的这个五大个活动

是顺序进行的

从沟通开始

到策划

到建模

到构建

到部署

中间没有更多的反馈和迭代的这样的过程

而是顺序的进行

这五大个软件工程的框架活动

第二个传统的过程模型是V模型

V模型开始于需求分析

然后是体系结构设计

然后是构建设计

然后是代码生成

从左边的V字的左上方

向

下方

顺序地进行了

需求模型

体系结构设计

构件设计和代码生成

然后从下方再向右上方

我们要进行单元测试

单元测试

是对应我们的代码生成和构件设计的内容

单元测试之后

我们进行集成测试

集成测试

我们要对照我们的构件设计

和体系结构设计来进行集成测试

最后进行系统测试

系统测试对照的标准是

体系结构设计

和需求模型

在系统测试

然后最后就是验收测试

V模型的特点是

当软件进行开发的时候

是从需求建模 体系结构设计

一直向下到构建设计

代码生成

然后当进行验证进行测试的时候呢

是从单元测试开始

单元测试的检验标准

是我们的代码生成

和构件设计的成果

然后是集成测试的检验标准

是构件设计和体系结构设计

然后系统测试的检验标准

我们要对照体系结构设计

和需求建模的成果

最后是用户的验收测试

这样一个V模型

第三个传统的过程模型是增量过程模型

增量过程模型

同样需要进行我们框架活动当中的五大类活动

沟通

策划

建模

构建

和部署

那么每一个软件的增量

它把一个大的软件开发任务划分为

许多个软件增量

每一个软件增量都要经过沟通

策划

建模

构建和部署

这样五个活动

之后产生第一个交付的软件增量

然后我们再开始第二个软件增量

同样经过沟通 策划 建模 构件和部署

这样每一个软件增量

都经过这样五个活动

产生我们每一个软件增量

这是增量过程模型

还有我们的演化模型

演化模型还叫原型模型

它同样起始于沟通

然后进行快速的策划出原型

然后通过建模

快速设计和构建我们的原型

在构建了原型之后

我们把原型部署并交付给客户进行反馈

针对客户反馈的情况

我们对原型进行下一轮的快速的策划

建模

设计

构建原型和部署交付

再一次的交给客户反馈

这样不断的循环反复

对我们的模型进行细化

这样就叫做演化模型

演化模型还有一种就是螺旋模型

螺旋模型是一种演进式的软件过程模型

它结合了圆形的迭代性质

和瀑布模型的可控性

和系统性的特点

具有快速开发

越来越完善的软件版本的潜力

螺旋模型是一种风险驱动型的过程模型生成器

对于软件集中的系统

它可以指导多个利益相关者的协同工作

螺旋模型有两个显著的特点

一个是采用循环的方式

逐步加深系统定义和实现的深度

同时降低风险

二是确定一系列的里程碑作为支撑点

不断的沿着螺旋模型的线路

不断的对系统进行进一步的增强 开发

螺旋模型确保利益相关者认可

是可行的

而且可以让各方都满意的

系统的

解决方案

演化模型还有是并行模型

并行模型就是对不同的软件的部分

或者不同的软件构建

或者不同的软件增量

它们各自沿着各自的顺序

进行沟通

策划

构建

部署等等

那么也就说在同一时刻

这张图显示的在同一时刻

有的软件增量处在正在开发的状态

有的软件增量处在等待变更的状态

有的软件增量可能在处在

正在评审的状态

那么不同的增量

它们是并行进行的

处在整个过程的不同的状态

或者是不同的阶段

它表示软件工程的活动

或者任务的某一个状态的

不同变迁

这个图显示的是

某个软件增量

或者是不同的软件增量

在同一时刻所处的不同状态的关系

除了传统的软件过程模型

我们还有一些专用的软件过程模型

专用的软件过程模型具有

传统过程模型的一些特点

但是往往应用面比较窄

而且专一

只适用于某些特定的软件工程方法

比如

基于构件的开发

它能够使软件得以复用

它适用于

基于构件的模型开发方法

还有形式化的方法

形式化的方法

通常注重对于需求的数学规格的描述

然后通过形式化演变

不断的生成我们的软件开发的成果

还有面向方面的软件开发

为定义

说明

设计和构建方面

提供了过程

和方法

还有一种叫做统一过程

它是一种用例驱动

以框架为中心

的迭代和增量

软件过程和统一的建模语言

UML

Unified Modeling Language

是紧密结合的

统一过程阶段

也是开始于我们的沟通阶段

沟通和策划是我们的起始阶段

策划和建模是我们的细化阶段

然后在建模之后我们进行构建

构建和部署

是我们的转换阶段

最终在部署之后我们交付

可生产的软件增量

这张图显示了统一过程阶段的各个阶段

它的横轴是时间

它的纵轴显示的是Work hour

也就是工作的小时

那么在一开始的起始阶段

需求分析的阶段

我们的需求分析阶段的各个任务

在不断的增加

然后把需求分析的任务

随着软件工程阶段的演进

软件需求分析的任务的工作量在不断的减少

然后再到需求分析

然后到设计

然后到Implementation实现

然后测试

最终是技术支持

那么在每一个这样的活动下面

我们的工作小时

也就是我们的任务量

都是图中灰色所显示的

在不断的增加

然后在不断的减少

从我们的起始阶段到我们的构建阶段

到最终的交付阶段

那么统一过程有一些工作产物

在起始阶段

统一过程的工作产物包括

版本文档

初始用例模型

初始项目表

还有初始的商业用例

初始的风险评估

项目计划

阶段和迭代等等

那么在细化阶段

有包括我们的用例模型

补充需求

包含非功能性需求

分析模型和软件架构的描述

细化阶段还有一些可执行的框架原型

和初步设计模型

和修正的风险清单

项目计划等等

在下一个阶段是构建阶段

构建阶段会有我们的设计模型

软件构建

集成软件增量

测试计划和步骤

测试用例

支持文档

用户手册 安装手册

和当前版本的描述等工作产物

最后是转换阶段

转换阶段的工作产物包括

交付的软件增量

和Beta测试报告

以及用户反馈报告

那我们的统一过程模型

是基于用例的

从用例出发

基于UML建模语言

进行的软件开发过程

另外我们需要了解的就是

个体软件过程

和团队软件过程

或者叫做个人软件过程模型

和团队软件过程模型

我们先看一下个人软件过程模型

个人软件过程强调对产品

以及产品质量的个人测量

那么它的测量单位是个人

那么以个人为单位进行软件过程测量的时候

它有

策划活动

策划活动将需求活动分离出来

估算项目的规模和所需的资源

并且进行缺陷评估

估计此项工作的缺陷数目

所有的度量都用工作表或者是模板来记录

最后识别开发任务

并建立项目进度计划

第二个

个人软件过程活动是高层设计

在高层设计中

我们要建立每个构件的外部规格说明

并完成构件设计

如果有不确定的需求

则构建原型系统

所有的问题都要记录和跟踪

高层设计要进行高层设计的评审

使用正式的验证方法来发现设计中的错误

对所有重要的任务和工作结果都进行度量

高层设计评审之后就要对设计的结果进行开发

细化和评审构件级的设计

完成编码

对编码进行审阅

评审

并进行编译和测试

对所有的重要任务和工作成果都进行度量

最后就是后验

根据收集到的度量和测量结果

这些度量和测量结果

需要进行大量的数据的统计分析

确定过程的有效性

度量和测量结果为提高过程的有效性

提供后期的指导

那么个体软件过程

通常会针对个人

对它进行测量

和后期的指导

那么与之相对应的团队软件过程

Team Software Process

是以团队为单位

对软件过程进行测量和指导

团队软件过程

建立自我管理的团队

来策划和跟踪其工作

确定目标

建立团队自己的过程和自己的计划

团队既可以是纯粹的软件开发队伍

也可以是集成的产品队伍

可以由3-20名工程师来组成

团队软件过程指示管理人员

和如何指导和激励其团队

并保持团队的最佳表现

使用CMM第5级的行为常规化

并依据此来约束员工

这样可以加速软件过程的改进

能力成熟度模型CMM

是一种度量软件过程有效性的一个模型

为高成熟度的软件组织提供了改进的指导

那么随着团队软件过程中

与使用能力成熟度模型

CMM进行评估

为软件的团队的进一步的改进

提供了一系列的指导意见

促进软件团队的不断的成熟

和提升

今天我们关于软件过程模型就分享到这里

谢谢大家