软件工程（小小总结）

软件工程的概念与发展

软件工程概念的提出与发展

一、软件危机

1、软件开发的速度
2、软件制品的质量
3、软件开发成本

二、软件工程

应用计算机科学理论和技术以及工程原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。

三、软件工程的发展

1、20世纪60一80年代初

开发模型、开发方法、支持工具

2、20世纪80年代末一今

软件复用技术、软件生产管理

一、软件开发的本质

1、软件开发的目标

1. 映射
2. 将问题域中的概念映射为运营平台层面上的概念

2、软件开发的本质

不同抽象层术语之间的“映射”，以及不同拍象层处理逻辑之间的“映射”。

• 如何实现这样的映射?

技术问题

• 如何管理这样的映射?

过程途径
问题建模

3、模型的概念

模型是一个抽象。模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述

4、模型的类别

1. 概念模型：描述软件是什么
2. 软件模型：实现概念模型的软件解决方案包括设计模型、实现模型和部署模型

eg:
在软件开发领域中，“描述了系统是什么”的系统模型被称为：概念模型
本体考查对模型及模型分类的理解和掌握
(1)概念模型：描述软件是什么
2)软件模型：实现概念模型的软件解决方案。包括设计模型、实现模型和部署模型

小结

1. 软件危机的出现，导致了软件工程的引入
2. 软件开发的本质，实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的较则。
3. 系统建模是指运用所掌握的知识，通过抽象，给出系统的一个结构。
4. 模型是一个抽象
5. 在软件开发领域，模型有两大类：概念模型 和软件模型。

二、需求获取

温伯格名言:“明白自己在做什么”
杰拉尔德·温伯格Gerald M Weinberg)是著名的软件和系统思想家，美国计算机名人堂代表人物。这个名人堂至今只有20名成员。为中国读者所熟悉的比尔·盖茨和迈克尔·戴尔等也是在他之后方才获得这一计算机界至高无上的殊荣

1、需求与需求获取

1）需求的定义

一个需求是有关一个“要予构造”的陈述，描述了待开发产品 系统功能能力、性能参数或其它性质。

2）需求的基本性质

1. 必要的
2. 无歧义的
3. 可测的
4. 可跟踪的
5. 可测量的

3）需求的分类

1. 功能需求，是整个需求的主体
2. 非功能需求：性能需求、外部接口需求、设计约束和质量属性需求

!能够区分哪些是功能需求，哪些是性能 需求

1. 功能需求
2. 性能需求
3. 接口需求
4. 设计约束

7类接口: 用户接口，硬件接口，软件接口，通信接口，内存约束，运行，地点需求

5. 质量属性

eg：
分析下列哪些是功能需来?

• 功能：系统产生月销售报表
• 功能：根据销售金额计算销售税
• 性能：系统应在3秒内计算出销售税
• 设计约束：系统必须使用JAVA语言编写
• 性能：系统至少支持1000个并发访问
• 接口：系统支持TCP IP协议

4）需求发现技术

1、自悟
2、交谈
3、观察
4、小组会
5、提炼

2、需求规约 (SRS)

1）需求规约的定义 ***

是一个软件/产品 /系统所有需求陈述的正式文档，它表达了一个软件/产品 /系统的概念模型

2）需求规约的基本性质

1、重要性和稳定性程度：对需求进行分级
2、可修改的
3、完整的：没有被遗漏的需求
4、一致的：不存在互斥的需求

3）需求规约的格式 ***

IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。
1、引言

目的、范围、定义、缩略语、参考文献、概述

2、总体描述

产品描述、产品功能、用户特性、约束、假设和依赖

3、特定需求：是文档的技术核心
4、附录
5、索引

4）需求规约的表达

表达需求的语言

1. 非形式化的需求规约
2. 半形式化的需求规约
3. 形式化的需求规约

5）需求规约的作用

1、需求规约是软件开发组织和用户之间一份是产品功能及其环境的体现事实上的技术合同书，
2、需求规约是一个管理控制点
3、对于产品 /系统的而设计，需求规约是一个正式的、受控的起始点
4、需求规约是创建产品验收计划和用户指南的基础

eg:

1、根据软件需求分类，下列选项中不属于设计约束的是C.质量属性
A. 并发操作B.握手协议C.质量属性D.硬件限制
2、什么是需求规约? 请简述需求规约的作用。
需求规约是一个软件/产品 /系统所有需求陈述的正式文档，它表达了一个软件 /产品 /系统的概念模型
需求规约的作用包括:
(1)需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。
(2) 需求规约是一个管理控制点。
(3) 对于产品/系统的而设计，需求规约是一个正式的、受控的起始点。
(4) 需求规约是创建产品验收计划和用户指南的基础

小结

1. 正确定义问题，是解决问题的基础
2. 需求获取是软件开发的基础
3. 需求的类型主要有功能性和非功能性需求两大类:非功能性需求包括:性能需求、接口需求、设计约束
4. 质量要求。
5. 需求规约将上述需求用标准文档表达出来
6. 需求规约的作用可以概括为4个方面

三、结构化方法

结构化方法作为一种“思想”工具，可以用于定义需求，建立待建系统的功能模型；可用于定义满足需求的结构，给出一种特定的软件解决方案

1、 结构化需求分析

1. DFD图
2. 数据字典
3. 决策树、判定表

请分析字处理程序的各种需求
“用户能有效地纠正文档中的拼写错误。–>业务需求
“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”–>用户需求
“找出拼写错误的词并高亮度显示: 显示提供替换词的对话框:实现整个文档范围的替换。"–>用户需求

需求分析面临的挑战

• 问题空间理解
• 人与人之间的通信，“有效沟通
• 需求的变化性

需求技术的基本特征

• 提供方便通信的机制
• 鼓励需求分析人员使用问题空间的术语思考问编写文档
• 提供定义系统边界的方法
• 提供支持抽象的基本机制
• 为需求分析人员提供多种可供选择的方案提供特定的技术，适应需求的变化

1)需求分析中的基本术语

1. 数据：客观事物的一种表示
2. 信息：具有特定语义的数据
3. 数据是信息的载体
4. 数据流:数据的流动
5. 加工：数据变换单元
6. 数据存储
7. 数据源和数据潭

四个数据要素

2）系统功能模型表示方法

1. 数据流图(DFD图）

一种表示数据变换的图形化工具

2. 数据流程图的元素

数据源 数据潭，数据流，数据加工，数据 存储

3）建模过程

1、自顶向下、逐步求精
2、建立系统环境图
3、0层图: 从0层图开始对流程图中的要素编号
4、1层图
…

数据流图的绘制过程

0层图

要对处理编号:1、2、3…

1层图

编号规则:1.1,1.2, 2.1,…

建模过程2-数据字典

1. 定义数据流程图中所有数据流和数据存储的数据结构
2. 顺序结构：+
3. 选择结构：|
4. 重复结构：{ }
5. 子界：m…n

建模过程3-加工的描述

(1)判定表

判断表(Decision Table)也称为决策表，是一个二维表，它说明了每一种条件组合所产生的结果

(2)判定树

判断树 (Decision Tree)也称为决策树，是用来描述在一组不同的条件下，决策的行动是根据不同条件及其取值来选择的处理过程。业务规则的描述通常可以使用判断树这一过程描述工具。

(3)结构化语言

若逻辑关系比较简单，可以用结构化自然语言来描述

如果应发工资低于4500，则无需缴税，否则需要交纳个人收入所得税:
IF立发工资<4500
无需缴税
ELSE
交纳个人收入所得税

4)应用中注意的问题

1、模型平衡问题

• DFD图与数据字典的一致
• 底层加工的处理逻辑描述，与数据字典一致

2、信息的复杂性控制问题

• 上层数据流可以打包
• 下层模块个数:7 ± 2
• 每个加工的数据流不能太多:增加层次

5)需求验证

1、验证:必要性、无歧义性、可测性、可跟踪性、可测量性

2、需求中发现的错误类型

• 不正确的事实:40%
• 遗漏: 31%
• 不一致，13%
• 歧义性: 5%
• 错放: 2%
• 其它:9%

发现错误的方法

• 审查:65%
• 单元测试: 10%
• 评估: 10%
• 集成: 5%

2、结构化设计

总体设计
详细设计

结构化设计的任务
1、定义满足需求所需要的结构
2、确定“怎么做”的问题
3、划分为:

• 总体设计: 以系统为对象
• 详细设计:以模块为对象

1）总体设计

1、总体设计的任务:

把系统的功能需求分配到一个特定的软件系统结构钟

2、引入了两个概念:

模块：软件中具有特定标识的独立成分.
模块调用：模块之间的一种使用关系

如何表达模块和模块调用

1、Yourdon提出的模块结构图
2、层次图
3、美国IBM公司提出的HIPO图
H: 层次图
IP0: 输入 处理 输出图

模块结构图

层次图

HIPO图

1、层次图+IPO图
2、每一个模块都有编号

1、总体设计的步骤

将DFD图映射为设计层面的模块及模块调用。
(1)将DFD图转换为初始的模块结构图
(2)基于“高内聚、低耦合”的软件设计原理通过模块化，将初始的模块结构图转化为最终的模块结构图

2、两种映射方法

(1) 变换设计

基于变换的数据流程图是一个线性的顺序结构，由输入、输出和变换中心三部分组成。

变换型数据流程图是一个线性的顺序结构由输入臂、输出臂和变换中心三部分组成。其中变换中心使系统数据发生本质的变化输入臂将物理输入变换成逻辑输入，而输出臂则将逻辑输出变换成物理输出

如果待分解的模块是一个数据凝聚的模块称该模块为以转换为中心的模块。可以把它分解为输入、处理、输出三大模块。

(2)事务设计

基于事务的数据流程图中有一个事务处理中心，它将输入分为许多相互平行的加工路径，然后根据输入的属性，选择某一加工路径。

如果模块为逻辑凝聚的模块，可以将它分解为一个检查业务类型的模块和一个调度模块，根据不同的业务类型，调度模块调用不同的下层模块

3、模块化及其启发式规则

(1) 模块
执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成:模块接口和模块体
(2)模块化的两个问题

• 如何将系统分解成软件模块

“分而治之”和“抽象
自顶向下，逐步求精
形成模块层次结构

• 如何设计模块

4、模块化

把一个待开发的软件分解成若干个简单的、具有高内聚低耦合的模块，这一过程称为模块化

(1) 模块耦合

耦合(coupling)是对两个模块之间相互依赖程度的一种度量。模块间的依赖程度越大，则其耦合程度也就越大;反之，模块间的依赖程度越小，则其耦合程度也就越小。

模块间耦合类型

• 内容耦合:一个模块直接修改或操作另一模块数据
• 公共耦合: 两个模块共同引用一个全局数据项
• 控制耦合:一个模块向另一模块传递控制信号
• 标记耦合:一个模块向两个模块传递一个公共参数
• 数据耦合: 模块之间通过参数来传递数据

(2) 模块内聚

是指一个模块内部个成分之间相互关联程度的度部。也就是说，内聚是对模块内各处理动作组合强度的一种度量。很显然，一个模块的内聚越大越好

内聚的类型

• 偶然内聚:模块的各成分没有任何关系
• 逻辑内聚:逻辑上相关的 处理放在一起
• 时间内聚:模块内的功能在同一时间完成
• 过程内聚:模块内的处理以特定的次序执行
• 通信内聚:操作同一数据集
• 顺序内聚:一个成分的输出作为另一成分的输 入
• 功能内聚:模块的所有成分完成单一的功能

(3)启发式规则

“高内聚、低耦合

1. 改进软件结构，提高软件独立性。模块分解
2. 模块规模适中
3. 力求深度、宽度、扇出、扇入适中。

• 深度:表示其控制的层数。
• 宽度: 同一层次上模块总数的最大值。
• 扇出:一个模块直接控制的下级模块的数目。
• 扇入: 有多少个上级模块直接调用它

4. 尽量使模块的作用域在其控制域内
5. 尽力降低模块接口的复杂度

• 模块的控制域:这个模块本身以及所有直接或间接从属它的模块的集合
• 模块的作用域:受该模块内一个判断所影响的所有模块的集合

6. 力求模块功能可以预测

2）详细设计

具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构。
详细设计的目标：将总体设计阶段产生的系统高层结构映射为以相关术语表达的低层结构，也是系统的最终结构

结构化程序设计方法

是一种基于结构的编程方法，即采用顺序结构、选择结构和重复结构进行编程，其中每一结构只允许一个入口和一个出口。
结构化程序设计的本质是：使程序的控制流程线性化，实现程序动态执行顺序符合静态书写的结构，提高程序的可读性

（1s) 顺序结构

（2）选择结构

（3）多分支结构

（4）循环结构

详细设计工具

(1) 程序流程图

程序流程图：程序流程图又称为程序框图它是历史最悠久使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。

(2)盒图(N-S图)

出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图
盒图

(3)PAD图

PAD是问题分析图(Problem AnalysisDiagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。下图给出PAD图的基本符号

(4)类程序设计语言PDL

PDL也称为伪码，它是用正文形式表示数据和处理过程的设计工具。
PDL具有严格的关键字外部语法，用于定义控制结构和数据结构:
一般说来PDL是一种“混杂”语言，它使用一种语言(通常是某种自然语言)的词汇，同时却使用另一种语言(某种结构化的程序设计语言) 的语法

设计规约

完整准确地描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制设计规约包括概要设计规约和详细设计规约。

(1)概要设计规约

1. 指明高层软件体系结构
2. 系统环境
3. 软件模块的结构
4. 模块描述
5. 文件结构和全局数据文件的逻辑结构
6. 测试需求

(2) 详细设计规约

详细设计规约主要作为软件设计人员与程序员之间交流的媒体。

1. 各处理过程的算法
2. 算法所涉及的全部数据结构的描述

小结

1. 本章详细介绍了结构化方法，包括结构化分析和结构化设计:
2. 结构化分析采用“自顶向下、逐步求精”的思想建立系统的概念模型-数据流图:
3. 结构化设计采用模块化的思想，建立了系统的模块层次结构(控制结构图) :
4. 模块设计的原则是高内聚、低耦合
5. 本章的重点是数据流图的绘制，

四、面向对象方法-UML（统一建模语言）

介绍

面向对象技术的发展中，一个重要的里程碑是UML。UML是一种可视化的语言，可用于规约系统制品、构造系统的制品、建立系统制品的文档，可以作为软件需求规约、设计和实现的工具。UML给出了方法学中不同抽象层次术语以及模型表达工具，或者说UML给出规约软件系统/产品的术语和表达格式。

UML在方法学中不同抽象层次

UML的8大术语

1. 类和对象
2. 接口
3. 协作
4. 用况
5. 主动类
6. 构件
7. 制品
8. 节点

描述关系的术语

1. 关联
2. 泛化
3. 实现
4. 依赖

知识结构

1. UML提供哪些术语，用于抽象表达客观世界中的各的事物

• UML提供哪些术语，用于抽象表达客观世界中的各式的事物之间的关系
• UML提供哪些术话，用于抽象表达客观世界中各种各样的模型
• 掌握各种术语
• 掌握表达模型的用况图、类图、顺序图、状态图

面向对象建模过程的步骤

1、需求获取
建立用况(use case)模型和用况场景
2、需求分析

建立活动图和状态图
类图(建立域模型)
顺序图(实现用况

3、编写需求规格说明书
4、需求验证

1、UML术语表

1. 表达客观事物的术语
2. 表达关系的术语
3. 表达组合关系的术语包

1）表达客观事物的术语

对象 (object )

对象 (object) 是系统中用来描述客观事物实体。一个对象由一组属性和对这组属性进行操作的一组方法组成

类(Class)

类(Class)是具有相同属性、操作、关系和语义的组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和服务两个主要部分

类的基本属性

(1) 可以有多个属性也可以没有属性。
(2) 可见性: public、protected、private
(3)多重性
(4)初始值
(5)性质串
(6)作用范围

类语义的进一步表达

1. 详细叙述类的职责
2. 通过类/操作的注解，详细注释类的定义
3. 通过类/操作的注解，详细注释各操作的前置条件和后置条件
4. 详述类的状态机（状态图）
5. 详述类的内部结构（活动图）
6. 类与其他类的协作 （协作图）

类的语义表达的详细程度取决于建模的意图

1. 为了与最终用户和领域专家沟通:较低的形式化手段
2. 为了支持正向和逆向工程: 采用较高的形式化手段
3. 为了对模型进行推理，证明其正确性: 采用很高的形式化手段

Rose

类在建模中的用途

1. 模型化问题域中的概念
2. 建立系统的职责分布模型
3. 模型化建模中使用的基本类型

类要满足的基本条件

一个结构良好的类，必须符合下列条件:

• 明确抽象了问题域或解域中某个有形事物或念
• 包含了一个小的、明确定义的职责集， 并能很好地实现
• 清晰地分离了抽象和实现

接口

接口的含义

接口是操作的一个集合，其中每个操作描述了类构件或子系统的一个服务

接口的表示

1. 采用具有分栏和关键字

的矩形符号来表示

2. 采用小圆圈和半圆圈来表示

使用中的问题

1. 如何描述接口的语义
2. 应用中应当注意的问题

应用中注意的问题

1. 接口智能被其它类目使用，其本身不能访问其它类目
2. 接口描述类的外部可见操作，通常是该类的一个特定有限行为
3. 接口不描述其中操作的实现，也没有属性和状态
4. 接口之间没有关联、泛化、实现和依赖

协作

协作是一个交互，涉及交互的三要素:交互各方、交互方式以及交互内容

用况 (use case) /用例

对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、i可观察的结果。

主动类

1. 至少具有一个进程或线程的类。能够启动系统的控制活动，并且其对象的行为通常与其它元素行为并发的
2. 表示方法:两条竖线
3. 用来模型化系统中的并发行为

构件/组件

1. 系统设计中的一种模块化都件,通过外部接口隐藏了它的内部实现
2. 具有相同接口的构件可以相互替代
3. 构件可以嵌套
4. 构件用于表达解空间中可独立标识的成分

制品 (Artifact)

1. 系统中包含物理信息的、可替代的物理部件
2. 部署制品:这类制品是构成一个可执行系统必要而充分的制品，例如: DLL、EXE文件
3. 工作产品制品:这类制品本质上是开发过程的产物，由源代码文件、数据文件等用来创建部署制品的事物构成
4. 执行制品:这类制品是作为一个正在运行的系统的结果而被创建的。一般存在于内存之中

节点

节点是在运行时存在的物理元素通常表示一种具有记忆能力和处理能力的计算机资源

2、表达关系的术语

1. 关联
2. 泛化
3. 细化
4. 依赖

1）关联(Association)

1. 关联反映了类和类之间的静态关系。关联在模型中，特别是在永久业务对象模型中是最基本的关系。
2. 关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。

导航：一个类推出另一个类(加个箭头)
组合是依赖另一个类的

关联的语义表达:

1. 关联名
2. 导航
3. 角色
4. 可见性( 权限)
5. 多重性:多重性(Multiplicity) 定义了与一个对象类相联系的对象 类出现一次，该对象 类可能出现的最小和最大的数目

关联的语义表达:

1. 限定符
2. 聚合:一个类是另一类的一部分 (空菱心箭头)
3. 组合:是聚合的一种特殊形式 (实菱心箭头)

3. 关联类

具有关联和类特性的模型元素

4. 约束

有序 （ordered）、无重复的(set)、有重复的 (bag)、有序集合（order set ）、列表（list）、只读 (read only)

2）泛化/继承

特殊类 (子类)的对象拥有其一般类(超类)的全部属性与服务，称作特殊类对一般类的继承 (inher itance) ，利用继承 (inher itance) ，子类可以继承父类的属性和方法。子类 / 父类也可分别叫做特殊类 /一般类、子类 /超类、派生类 / 基类等

3）细化/实现

1. 细化是类目之间的语义关系，其中一个类目规约了保证另一类目执行的契约
2. 用空心三角形的虚线表示

3. 在以下2个地方会使用实现关系:

接口与实现它们的类和构件之间:
用况与实现它们的协作之间

4）依赖

1. 依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务
2. 用有向虚线段表示

依赖-依赖的的分类:

(1) 定(Bind)
(2)导出(Derive)
(3) 允许 (Permit)
(4)实例 (Instantiate)

5）关系术语的使用

1. 结构关系
2. 继承关系
3. 精化关系
4. 依赖关系

3、表达组合信息的术语一包

包:是模型元素的一个分组，一个包本身可以被嵌套在其它包中，并且可以含有子包和其它类型的模型元素

1. 包的可见性符号
2. 包之间的关系
3. 访问 (use access)
4. 引入 (import)

2、UML的模型表达格式

1）类图

类图 (class diagram) 表达了(系统的静态结构信息，即系统是由哪些类组成的，这些类之间的关系是什么。
类图显示系统各个部分以及怎样将它们组装起来

构造类图的三个关键问题是:

1. 系统中有哪些需要关心的类?
2. 这些类是如何描述的?
3. 这些类之间的联系是什么?

2）用况图 (use case 图)

用况是对一个参与者 (actor ) 使用系统的一项功能时所进行的交互过程的一个文字描述序列
用况图是一种表达系统功能模型的图形化工具
include:包含，/扩展

用况图的6个模型元素:

1. 主题
2. 用况
3. 参与者: 系统用户、另一个系统时间
4. 关联、泛化、依赖
5. 用况是系统开发的起点
6. 大多数的系统功能都可以表示成用况

3）状态图

(一个对象的图)
状态机的图，强调了从一个状态到另一个状态的控制流

状态图 (state chart diagram) 使用状态、事件和转换来记录对象在其生命周期中所历经的状态序列

始态(实心圆加能头)
终态:(箭头加实心圆)

1. 对象的初始状态是图中任何事件都未对该对象起作用时的状态
2. 状态代表对象生命周期中的某一瞬间
3. 转换表明作为对事件的响应结果，对象将从一种状态转换到另一种状态并执行某个动作
4. 触发状态转换的事件在状态转换字符串中命名。双击一个状态转换，除事件签名以外，还可用字符串为其加注临界条件、动作表达式等标签

状态图中的 3 个术语:

1. 状态：一个实例所处的特定阶段、所具有的对外呈现以及所能提供的服务
2. 事件

• 信号事件
• 调用事件
• 时间事件
• 变化事件

引起状态变化的叫事件

3. 状态转移

4）顺序图

多个对象

顺序图(sequence diagram) 表示了对象之间传送消息的时间顺序，也就是对象之间的交互顺序。
这些交互是指在场景或用况的事件流中发生的。
每一个对象(类人用一条生命线来表示一一即用垂直线代表整个交互过程中对象的生命期。
生命线之间的箭头连线代表消息

顺序图中的基本元素包括:

1. 活动者，指用况中的活动者
2. 对象，指在用况中的内部对象。
3. 生命线: 在顺序图中的一个对象下面的竖线，用以显示这个对象的生命期。
4. 消息，指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息

消息的类型

(1)同步消息：返回消息，同步消息假定有一个返回消息司步消息用有实心的箭头表示:返回消息用虚线、箭头也不是实心来表示。
(2) 反身消息：消息的发送方和接收方是同一个对象。
(3) 异步消息：没有返回值的消息，用非实心箭头表示。
(4)定时消息：对消息附加时间约束条件，包括:发送时门接受时间、已用时间等。

控制操作子:

为了控制交互行为描述的复杂性，以便更清晰地表达顺序图中的复杂控制，UML给出了4中最常用的控制操作子

• 1)选择执行操作子(Operator for Optional Evecution)。该控制操作子记为“Opt”由两部分组成，一是监护条件,二是控制体。
• 2)条件执行操作子(Operator for Conditional Execution)该控制操作子记为“alt”，控制体通过水平线将其分成一些部分，每一部分表示一个条件分支，每个分支有一个监护条件
• 3)并发执行操作子(Operator for Parallel Execution该控制操作子记为“par”，该控制操作子的体通过水平线将其分为多个部分。每一部分表示一个并行计算。在大多数情况下,每一部分涉及不同的生命线。该控制操作子表明，当进入该控制操作子时，所有部分并发执行。
• 4)迭代操作子(Operator for lterative Execution)。该控制操作子记为“loop“

类(Class)是一组具有相同属性、操作、关系和语义的对象的描述
对象是类实例
类的构成成分:类名、属性、操作
类在建模中的主要用途:
(1)模型化问题域中的概念
(2)建立系统的职责分布模型
(3)模型化建模中使用的基本类型

小结

1. UML提供了跨越问题空间到“运行平台”之间的丰富的建模元素：提供了描述客观事物的8个术语和描述关系的4个术语
2. 提供了相应的模型表示工具:用况图、类图、状态图、顺序图
3. 为了表达概念模型和软件模型，UML提供了13种图形化工具

五、面向对象方法 RUP

RUP+UML = 面向对象方法

统一软件开发过程 (Rational UnifiedProcess: RUP) 是对象管理组织 (OMG) 所推荐的一个有关过程的标准。
RUP是基于UML的一种过程框架。比较完整地定义了将用户需求转换成产品所需要的活动集并提供了活动指南以及对产生相关文档的要求
RUP适应于大多数软件系统的开发，基于构件。

知识结构

过程模型:
1.需求获取模型
2.需求分析模型
3.软件设计模型
4.软件实现模型
5.软件测试模型

1、RUP的特点

以用况驱动的、以体系结构为中心的迭代、增量式开发。

(1)用况驱动

在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组织在一起，使各个阶段中都可以回溯到用户的实际需求。

(2)以体系结构为中心

• 系统体系结构:是对系统语义的概括描述对所有项目有关人员都是可以理解的
• 关注子系统、构件、接口、协作、关系和节点等重要模型元素，而忽略其它细节

(3)迭代与增量

• 迭代是重复的部分
• 增量是增加的部分

初始阶段的基本目标

• 获得与特定用况和平台无关的系统体系结构轮廓
• 为系统建立商业案例:
• 确定项目的边界
• 从业务角度指出该项目的价值
• 第一个重要的里程碑:生命周期目标(Lifecycle 0bjective) 里程碑

细化阶段

• 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素
• 第二个重要的里程碑:生命周期结构 (LifecyelArchitecture)里程碑

构造阶段

• 形成最终的系统体系结构基线
• 开发完整的系统
• 确保产品可以开始向客户交付
• 第三个重要的里程碑:初始功能nitial Operational) 里程碑

一个过程包括若千个任务，一个人任务包括若千个活动，一个活动有若千个术语

2、核心工作流

RUP中有9个核心工作流，分为6个核心过程工作流 (Core Process Workflows) 和3个核心支持工作流 (Core Supporting Workflows)
主要核心工作流：需求获取、分析、设计

1）需求获取

• RUP运用用况 (Use Gase) 技术来获取需求
• 需求获取的基本步骤:

列出候选的需求：特征列表
理解系统语境：领域模型或业务模型
捕获功能需求：用况模型
捕获非功能需求：补充需求或针对一些特定的用况

1. 列出候选的需求

搜取特征:是一个新的项 (ltem)及其简要描述

2. 理解系统语境

• 创建领域模型或业务模型
• 业务用况模型:业务参与者和业务用况
• 业务对象模型:三个术语: 工作人员业务实体、工作单元:用交互图和活动图来表达

3. 捕获功能需求:建立系统的用况模型

• 发现和描述参与者
• 发现并描述用况
• 确定用况的优先级
• 精化用况
• 构造用户界面模型
• 用况模型的结构化

2）需求分析

需求分析的目标:在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述

1.术语

(1) 分析类:

是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的
存在三种不同类型的类：实体类、边界类和控制类

（2)用况细化

• 用况细化是一个协作
• 针对一个用况，其行为可以用多个分析类之间的相互作用细化，并记为用况细化

（3） 分析包

• 分析包体现了“局部化”、“问题分离”等软件设计原理
• 分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包
• 体现“高内聚、低耦合“

2.分析模型的表达

• 分析模型是由“分析系统”来定义的
• 分析系统包含一组具有层次结构的包一个包
• 可以包含一些分析类和用况细化

3.分析的主要活动

活动1: 体系结构分析

• 标识分析包
• 处理分析包之间的共性
• 标识服务包
• 定义分析包的依赖
• 标识重要的实体类
• 标识分析包和重要实体类的公共特性需求

活动2: 用况分析

• 标识分析类
• 描述分析类之间的交互

活动3: 类的分析

• 标识责任
• 标识属性
• 标识关联和聚合
• 包的分析

活动4:包的分析

• 确保分析包尽可能与其它包相对独立
• 确保分析包实现了它的目标，即细化了某些领域类或用况
• 描述依赖

3.需求分析总结

• 三个术语:分析包、分析类、用况细化
• 四个步骤

• 体系结构分析
• 细化用况
• 对类分析
• 对包进行分析

• 一个成果:分析模型(分析系统)

一个是产品设计，一个是程序设计

3、软件设计

• 软件设计：定义满足需求规约所需要的软件结构
• RUP的设计目标：定义满足系统 产品分析模型所规约需求的软件结构。

1）相关术语

• 设计类
• 用况细化
• 设计子系统
• 接口

2）设计模型、部署模型及相关视角下的体系结构描述

(1) 设计模型:

• 设计子系统
• 设计类
• 用况细化
• 接口

(2) 部署模型:

是一个对象模型，描述了系统的物理分布，即如何把功能分布于各个节点上

（3）设计的主要活动

• 活动1：体系结构设计

标识节点和它们的网络配置
标识子系统和它们的接口
标识在体系结构方面有意义的设计类和它们的接口
标识一般性的设计机制

• 活动2：用况的设计

标识参与用况细化的设计类
标识参与用况细化的子系统和接口

• 活动3：类的设计

概括描述设计类
标识操作
标识属性
标识关联和聚合
标识泛化
描述方法

• 活动4：子系统设计 包的概念

维护子系统依赖
维护子系统所提供的接口
维护子系统内容

3）RUP设计小结

1.RUP 设计的特点

(1) 使用了一种公共的思想来思考设计，并使设计可视化
(2)给出了有关子系统、设计类和接口的需求
(3) 支持对底线工作的分解，时之称为一些可以由不同开发组尽可能同时处理的、可管理的部分

2.RUP的设计方法

(1)给出表达设计模型的基本成分的术语
(2)规约了设计模型的语法，指导模型的表达
(3)给出了创建设计模型的过程以及相应的指导

3.RUP的设计模型

(1)设计子系统和服务子系统，以及它们的依赖、接口和内容
(2)设计类，以及它们具有的操作、属性、关系及其实现需求
(3)用况细化
(4)设计模型视角下的体系结构描述

4、RUP的部署模型

(1)节点，它们的特征以及连接
(2)主动类到节点的初始映射

分析模型	设计模型
概念模型	软件模型
可应用于不同的设计	特定于一个实现
使用了三个衍生类: 边界、实体、控制	使用了多个行生类，依赖实现的语言
几乎不是形式化的	是比较形式化的
开发费用少	开发费用多
结构层次少	结构层次多
动态的，但很少关注定序方面	动态的，但更多关注定序方面
概括给出了系统设计	表明了系统设计
整个生命同期内不能修改、增加等	整个生命周期内应该予以维护
为构建系统定义一个结构，是基本输入	构件系统时，尽可能保留分析模形所定义的结构

5、设计阶段的活动

(1) 体系结构设计
(2)设计用况
(3)设计类
(4) 设计子系统

6、RUP设计对实现的影响

(1)设计子系统和服务子系统由实现子系统予以实现
(2)设计类由文件化构件予以实现
(3)在规划实现工作时，将要使用用况细化以产生一些“构造”
(4)在节点上部署构件、形成分布系统时，将使用部署模型和网络配置

4、RUP的实现与测试

编程的构建

1）RUP的实现目标

(1)基于设计类和子系统生成构件
(2)对构成进行单元测试
(3)进行集成和连接
(4)把可执行的构件映射到部署模型

2）RUP实现的主要活动

(1)实现体系结构
(2)集成系统
(3)实现子系统
(4)实现类
(5)完成单元测试

3）RUP的测试

包括:内部测试、中间测试和最终测试

4）RUP测试包括的主要活动

(1) 计划测试
(2)设计测试
(3)实现测试
(4)执行集成测试
(5)执行系统测试
(6)评价测试

小结

1. RUP是一种软件开发过程框架，基于面向对象符号体系给出了软件开发过程组织及实施的指导。
2. RUP框架的典型特征：以用况驱动的、以体系结构为中心的迭代、增量式开发
3. RUP与UML是一对“姐妹”，它们构成了种特定的软件开发方法学
4. 需求获取层的基本术语: 用况，参与者，关联，包含、扩展，泛化等
5. 系统分析层术语：分析类，用况细化，分析包以及描述关系的依赖、关联等
6. 系统设计层术语：设计子系统、设计类用况细化等

六、软件测试

错误是不可避免的，我们要做的就是发现它并改正它。
软件测试是保证软件过程质量和软件产品质量的基础。
软件测试是一种动态评估技术，通过执行程序发现其中的错误。

三种软件测试技术:

(1)基于程序路径的白盒测试技术
(2)基于需求规约的事务流测试技术
(3)等价类划分技术

1、软件测试目标与软件测试过程模型

1）软件测试的对象

软件 = 程序 + 文档
测试对象:各个阶段产生的源程序和文档。

2）软件测试的目的

测试的目的应该是通过软件测试尽可能多地发现并改正软件种存在的错误。

3）软件测试的定义

1. 软件测试(Software Testing)是按照特定规程发现软件错误的的过程。
2. 使用人工或自动手段，运行或测定某个系统的过程，其目的是检验它是否满足规定的需求，或清楚了解预期结果与实际结果之间的差异。

4）“测试”和“调试”的区别

1. 测试证明“失败”，调试证明“正确”
2. 测试以已知条件开始
3. 测试时有计划的
4. 测试是一个发现错误、改正错误、重新测试的 过程
5. 测试的执行是有规程的
6. 测试由独立的测试小组完成
7. 测试的执行和设计可由工具支持

5）测试过程模型

1、测试设计

• 环境模型
• 对象模型
• 错误模型

2、测试执行
3、测试结果比较

2、 软件测试技术

黑盒：功能测试(接口)
白盒：逻辑的测试(里面的数据都看得到)
***重要

1）路径测试技术

• 是一种白盒测试技术
• 依据的是程序的逻辑结构。
• 采用控制流程图来表达被测程序模型
• 通过合理地选择一组穿过程序的路径，以达到某种测量度量

a.控制流程图

是一种表示程序控制结构的图形化工具，其基本元素是过程块、节点、判定。

s1,s2…s4程序块
1,2,3,4:判定

路径:是由链组成的，包含一串指令或语句其长度由链的数目决定
对软件测试而言，限定路径为: 从程序的入口开始，在出口结束

b.测试策略

路径覆盖 (PX) :执行所有可能穿过程序控制流程的路径。 最强的测试度量
语句覆盖 (C1) : 至少执行程序中所有语句一次。最低的测试度量
分支覆盖(P2) :至少将程序中的每个分支执行一次
条件覆盖：与条件组合覆盖

条件覆盖: true和false 都执行
类似:完整功能，按钮事件和部分功能

语句:判断和语句都要执行
条件:真和假都要出现一遍
分支:所有的分支(语)都执行一遍
路径:所有的路径

几种测试覆盖存在以下基本关系:

语句覆盖≤分支覆盖≤条件组合覆盖≤路径覆盖

微码(英语:microode)，又称微指令，是在CISC结构下，运行一些功能复杂的指令时，所分解一系列相对简单的指令。相关的概念最早在1947年开始出现

c.路径选取与用例设计

最小的强制性测试需求是语句覆盖率。
路径选取的一般原则:
(1）选择最简单的、具有一定功能含义的入口 出口路径；
(2)在已选取的基础上，选择无循环的路径，选取短路径 简单路径:
(3)选取没有明显功能含义的路径，要研究该路径为什么

2）基于事务流的测试技术

是一种功能测试技术
属于黑盒测试技术

a.事务:

是指从系统用户的角度出发所见到的一个工作单元，有其“生”，有其“亡”

• 短信提醒
• 节日问候
• 数据更新

事务由一系列操作组成，用“事务流”表达事务流:是系统行为的一种表示方法，为功能测试建立了程序的动作模式事务流程图:表达系统的行为，多个事务流的执行

事务流程图

事务流程图中的相关概念

1、并生:事务处理产生一个新事务，由此这两个事务继续执行
2、丝分裂:事务处理产生两个新事务
3、汇集: 事务的不同活动可以汇集一处
4、吸收:一个事务可以被另一个事务吸食
5、结合: 两个事务结合后产生一个新事务

如何根据事务流程图设计测试用例

• 步骤1: 获得事务流程图
• 步骤2:浏览、复审
• 步骤3: 用例设计
• 步骤4:测试执行

3）等价类法

是根据程序的I/O特性，将程序的输入划分为有限个等价区段，使得从每个区段内抽取的代表性数据进行的测试等价于该区段内任何数据的测试。
对于每个输入条件存在着程序有效输入的 有效的等价类和对程序错误输入的无效等价类。

eg:
某实数X的取值范围假设为a<X<b，则所有[a+1，b-1]之间的实数构成了有效等价类，而任何[-∞，a]或[b，+∞]之间的实数构成了两个无效等价类。

1. 如果某个输入条件规定了输入数据的取值范围，则可以确立一个有效等价类和两个无效等价类
2. 如果某个输入条件规定了输入数据的个数，则可以确立一个有效等价类和两个无效等价类
3. 如果某个输入条件规定了输入数据的一组可能取的值每一个输入值就是一个有效等价类，一个无效等价类
4. 如果某个输入条件是一个布尔值，则可以划分一个有效等价类和一个无效等价类
5. 如果某个输入条件规定了必须符合的条件，则可以划分一个有效等价类和一个无效等价类
6. 若在已划分的某个等价类中各元素在程序中的处理方式不同，则应将此等价类进一步划分为更小的等价类

4）边值分析法

是一种根据I/O边界等价类上或紧靠边界的条件选择测试用例的更有效的方法。

eg：
给定三个点，判定能否构成三角形，可选取两边之和等于第三边的实例作为边值分析法的测试用例

5）因果图法

因一输入条件和果一输出结果，通过因果图将能说明转换成一张判定表，然后为每种输入条件的组合设计测试用例
着重检查输入条件的组合。

用因果图生成测试用例的步骤

步骤1: 找出模块的原因(输入条件或输入条件的等价类 和结果步骤2: 分析原因与结果之间的对应关系，画出因果图步骤3:在因果图上标识出一些特定的约束和限制条件
步骤4:把因果图转化为判定表
步骤5:把判定表的每一列作为依据，设计测试用例

3、软件测试步骤

软件测试是按照与系统开发相反的方向来进行的。依次为:

• 单元测试
• 集成测试
• 有效性测试
• 系统测试

1）单元测试

单元测试(Unit Testing)又称模块测试(ModuleTesting)，或模块分调，用于测试单个程序模块，确定模块的逻辑和功能是否正确。

单元测试采用白盒测试技术。

单元测试要考虑模块的4个特征:

(1) 模块接口
(2) 局部数据结构
(3)重要的执行路径
(4)错误执行路径

单元测试还需要开发驱动模块和承接模块

(1)驱动模块:调用被测试模块的模块
(2)承接模块:被测试模块调用的模块

2）集成测试

集成测试(Integration Testing)用来测试模块之间接口的正确性，也即模块之间的数据和控制传递。
集成测试是与单元测试平行进行的两种策略:

• 自顶向下的集成测试:需要设计承接模块
• 自底向上的集成测试:需求设计驱动模块

每加入新的模块，还要进行回归测试。

3）有效性测试

目标是发现软件实现的功能与需求规格说明书不一致的错误

采用黑盒测试技术
***重要

测试步骤	测试对象	测试方法	测试内容	特点
单元测试	模块	白盒测试	模块接口局部数据结构重要的执行路径错误执行路径	驱动模块承接模块
集成测试	模块的组装模块的接口	黑盒测试	模块的接口
有效测试	是否符合用户可见的文档	黑盒测试	软件实现的内容与需求说明书的一致性
系统测试	软硬件的协作系统的性能	黑盒测试

小结

**等价类

1. 软件测试是由规程地发现错误的过程；
2. 软件测试的过程模型: 测试设计、测试执行、测试结果比较；
3. 两种测试技术:白盒测试和黑盒测试；
4. 白盒测试：路径测试技术，四种覆盖:语句覆盖分支覆盖、条件覆盖、路径覆盖;
5. 黑盒测试技术：事务流测试、等价类测试、边界类测试、因果图

七、软件生存周期与管理

开发逻辑，是获取正确软件的关键!
软件生命周期是软件产品或系统的一系列相关活动的全周期。生命周期可以划分为若干阶段，每一阶段又包括若干活动和任务。为了更清晰地描述软件过程及其活动和任务，ISO发布了《ISO/IEC软件生存周期过程12207-1995》标准。

1、软件生存周期过程概述

1. 《ISO/IEC软件生存周期过程12207-1995》标准
2. 《ISO/IEC软件生存周期过程12207-2008》标准
3. 基本思路是:

1）《ISO/IEC软件生存周期过程12207-1995》标准

软件生存周期过程的分类:

1、基本过程
2、支持过程
3、组织过程

a.基本过程

(1) 指那些与软件生产直接相关的活动集
(2)包括5个过程

• 获取过程
• 供应过程
• 开发过程
• 运行过程
• 维护过程

开发过程包含的活动

• 过程实现

过程实现包含的任务

1. 选择合适的生存周期模型
2. 选择相应的标准、方法、工具和程序设计语言
3. 制定实施开发计划
4. 可以使用一些非交付的软件项。

• 系统需求分析

1. 建立系统需求规格说明
2. 对系统需求进行评估

• 有关获取方面需要的可追踪性
• 有关获取方面需要的一致性
• 可测试性
• 系统体系结构设计的可行性
• 运行与维护的可行性

• 系统体系结构设计

1. 建立系统的顶层体系结构
2. 对体系结构及每一项的需求进行评估

• 系统需求的可追踪性
• 与系统需求的一致性
• 所使用的设计标准和方法的适宜性
• 软件项满足其所分配的需求的可行性
• 运行与维护的可行性

• 软件需求分析

1. 建立软件需求规格说明
2. 对软件需求进行评估
3. 联合复审

• 软件体系结构设计

1. 把对软件项的需求转变为一种体系结构
2. 对该软件项的外部接口和各构件之间的接口进行顶层设计
3. 进行数据库的顶层设计
4. 编制用户文档的最初版本
5. 为软件集成定义初步的测试需求文档
6. 对软件项的体系结构、接口和数据库设计进行评估
7. 实施联合评审

• 软件详细设计
• 软件编码和测试
• 软件集成
• 软件合格性测试
• 系统集成
• 系统合格性测试
• 软件安装
• 软件验收支持

b.支持过程

1. 是指有关各方按他们的目标所从事的一系列支持活动集。支持活动有助于提高系统或软件产品的质量
2. 文档过程
3. 配置管理过程
4. 质量保证过程
5. 验证过程
6. 确认过程
7. 联合评审过程
8. 审计过程
9. 问题解决过程

配置管理过程

• 过程实现:编制配置管理计划
• 配置标识:为项目需要标识的并加以控制的软件项及其版本，制定一个方案
• 配置控制:标识并记录变更请求
• 配置状态统计: 编制管理记录和状态报告
• 配置评价
• 发布管理和交付

c.组织过程

1. 与软件生产组织有关的活动集。
2. 包括4个过程:

• 管理过程
• 基础设施过程
• 培训过程
• 改进过程

管理过程

1. 启动与范围定义
2. 规划
3. 测量
4. 执行与控制
5. 评审与评价
6. 结束处理

2）《ISO/IEC软件生存周期过程12207-2008》标准

2个过程类、7个过程组、43个过程,

2个过程类

1. “系统语境的过程“
2. “软件开发的过程“

***重要

7个过程组:

系统语境的过程类

(1) 协议过程组
(2)项目过程组
(3) 技术过程组
(4)组织上项目使能过程组

软件开发的过程类

(5)软件实现过程组
(6)软件支持过程组
(7) 软件复用过程组

2、过程描述

结构:过程一>活动一>任务

• 供应过程
• 软件实现过程
• 软件需求分析过程
• 软件体系结构设计过程
• 软件验证过程
• 软件确认过程

1)供应过程

1、意图:为获取方提供满足所协商需求的产品或服务
2、活动和任务

• 活动1:机遇标识
• 活动2:供应方投标
• 活动3:合同协商
• 活动4: 合同执行

3、结果

(1)标识了产品或服务的获取方
(2) 对获取方的要求作了必要的响应
(3)建立了获取方和供应方之间的协议
(4) 供应方开发了满足所协商需求的产品 服务
(5)按所协商的需求向获取方交付了相应的产品 服务
(6)按所协商的需求安装了产品

2)软件实现过程

1、意图

把已规约的行为、接口和实现约束转换为一些动作，创建称为“软件项”的软件产品和服务作为系统元素。

2、活动和任务

活动:软件实现策略

3、结果

(1)定义了实现策略
(2)标识了有关设计方面的实现技术约束
(3)实现了一个软件
(4)按提供协议，把该软件打包成一个软件并存储

3)软件需求分析过程

1、意图:建立系统软件部分的需求
2、活动和任务

任务1:建立软件需求和文档
任务2:评估软件需求，并建立相应的评估结果文档
任务3:按软件复审过程进行软件需求复审

3、结果

(1)需求已分配给系统的软件元素
(2)已分析软件需求的正确性和可测性
(3)已了解软件需求对运行环境的影响
(4)在软件需求和系统需求之间建立了一致性和可跟踪性
(5)已定义了实现软件需求的优先级别
(6)软件需求已得到批准并按需求进行了调整
(7)针对软件需求的更改对成本、进度和技术影响，已进行了相应的评估
(8)建立了软件需求的基线，并与有关部门进行了沟通

4)软件体系结构设计

1、意图

为软件的实现和按需求进行验证提供设计方案

2、活动和任务

软件体系结构设计

3、结果

• 开发一种软件体系结构设计，描述实现该软需求的软件项
• 设计每一软件项的内部接口和外部接口

5）软件验证过程

1、意图:证明软件产品是否满足了所规约的需求
2、活动和任务

• 过程实现
• 验证

3、结果

(1)开发并实现了验证策略
(2)标识了验证准则
(3)执行了所需要的验证活动
(4)标识并记录了缺点
(5) 给出了可用于客户和其它参与人员的验证活动的结果

6）软件确认过程

1、意图:证实所期望使用的软件产品是否满足需求
2、活动和任务

• 过程实现
• 确认

3、结果

• 开发并实现了确认策略
• 标识了所有需要的软件工作产品的确认准则
• 执行了所需要的确认活动
• 标识并记录了发现的问题
• 提供了证据证明:软件产品能够按照用户所期望的方式来使用
• 给出了可用于客户和其他参与人员的验证活动结 果

3、应用说明

是对标准“ISO/IEC系统与软件工程-软件生存周期过程12207-2008”的应用说明
1、系统和软件

• 软件是整个系统的组成部分
• 区分系统需求分析和软件需求分析

2、与《ISO IEC系统生存周期15288》的关系

• 当系统中包括非常重要的非软件因素时，要应用《ISO IEC系统生存周期15288》

3、组织层和项目层

项目可能由组织执行

4、过程之间的时序关系

• 没有明确过程、活动、任务之间的时间依赖的序列。
• 支持活动之间的迭代和再现

5、过程分解

把过程划分为一些小的“片段”

6、生存周期模型和阶段

• 用生存周期模型对系统成软件产品的生有模型化
• 模型由阶段组成

7、剪裁

针对特定的情况，修改生存周期过程

***重要(简答题)
(概念，优缺点，不同点)

4、软件生存周期模型

含义:是一个包含软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。
作用:不但为软件开发确定了一些抽象层，还确定了每一抽象层之间的基本关系

• 瀑布模型
• 增量模型
• 演化模型
• 螺旋模型
• 喷泉模型

1）瀑布模型

瀑布模型的原理

1. 自上而下具有相互衔接的固定顺序。
2. 每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。

瀑布模型的贡献

1. 在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么有一个规约。
2. 在系统构造之前有一个设计阶段，它鼓励规划系统结构
3. 每一阶段都有评审，允许获取方和用户的参与
4. 前一步作为下一步被认可的、文档化的基线

瀑布模型存在的问题

1. 要求客户能够完整、正确和清晰地表达他们的需求，并要求人员一开始就理解这一应用。
2. 由于需求的不确定性，使设计、编码和测试阶段都可能发生延期，并且当项目接近结束时，出现了大量的集成和测试工作
3. 在开始的阶段中，很难评估真正的进度状态，并且直到项目结束之前都不能演示系统的功能。
4. 在一个项目的早期阶段，过分地强调了基线和里程碑，并可能需要花费更多的时间用于建立一些用处不大的文档。

2）增量模型

1. 增量模型融合了瀑布模型的基本成分(重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”
2. 前提: 需求可结构化
3. 适用于“技术驱动”的软件产品开发。

原理

增量模型的优点

1. 第一个可交付版本所需的成本和时间较少
2. 由于很快发布第一个版本，可以减少用户需求的变更
3. 允许增量投资，即开始时只对一个或两个增量投资

增量模型的缺点

1. 如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定。
2. 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布。
3. 由于进度和配置的复杂性，可能会增大管理成本和超出组织的能力。

3）演化模型

1. 演化模型是一种全局的软件(或产品) 生存周期模型属于迭代开发方法
2. 演化模型主要针对事先不能完整定义需求的软件开发
3. 该模型可以表示为:第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计-> 实现->测试->集成)->反馈->··…

演化模型的优点

1. 任何功能一经开发就能进入测试以便验证是否符合产品需求。
2. 帮助导引出高质量的产品要求
3. 减少软件开发活动的盲目性

演化模型的不足

很容易弱化需求分析阶段的工作。

4）螺旋模型

1. 螺旋模型是在“瀑布模型”和演化模型的基础上，加入两者都忽略的风险分析所建立的一种软件开发模型
2. 螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应
3. 因此特别适用于庞大、复杂并具有高风险的系统

每一个螺旋都得考虑风险分析

原理图

工作过程

(1)制定计划:确定软件目标，选定实施方案，弄清项目开发的限制条件;
(2) 风险分析:分析评估所选方案，考虑如何识别和消除风险;
(3)实施工程:实施软件开发和验证
(4)客户评估:评价开发工作，提出修正建议，制定下一步计划。

下一步重复，螺旋上升

螺旋模型的特点

1. 螺旋模型很大程度上是一种“风险驱动”的方法体系。
2. 螺旋模型关注解决问题的基本步骤

5）喷泉模型

1. 喷泉模型是一种以用户需求为动力，以过象为驱动的模型，主要用于采用对象技术的软件开发项目。
2. 喷泉模型认为:软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。

喷泉模型原理图

喷泉模型主要用于支持面向对象技术的软件开发

5、过程规划与管理

1. 属于“组织上项目使能过程组
2. 包括四个环节

• 过程规划 §
• 过程检测 ©
• 过程执行(D)
• 过程调整 (A)

1）过程建立

1、选择软件生存周期模型
2、细化所选择的生存周期模型
3、为每一个活动或任务标识合适的实例数目4、确定活动的时序关系，并检查信息流
5、建立过程计划的文档

成果:项目的过程计划

2）过程监控

1. 软件生存周期过程的监控
2. 软件生存周期过程改变所产生的影响的评估
3. 改变的实施
4. 实现改变

表格总结

***重要

生命周期模型	特点
瀑布模型	自上而下具有相互衔接的固定顺序
增量模型	适用于“技术驱动”的软件产品开发
演化模型	主要针对事先不能完整定义需求的软件开发
螺旋模型	强调风险分析，是一种风险驱动的方法体系
喷泉模型	以用户需求为动力，以对象为驱动的模型

***重要
《ISO /IEC软件生存周期过程12207一1995》标准将过程分为三类：

过程类	包含过程
基本过程	获取过程；供应过程；开发过程；运行过程；维护过程
支持过程	文档过程；配置管理过程；质量保证过程；验证过程；确认过程；联合评审过程；审计过程；问题解决过程
组织过程	管理过程；基础设施过程；培训过程；改进过程

小结

1. 本章介绍了软件工程的过程规划技术以及过程监控
2. 软件工程需要做哪些工作，《ISO/IEC系统与软件工程-软件生存周期过程12207-1995 》和ISO/IEC系统与软件工程-软件生存周期过程12207-2008
3. 软件开发工作的组织: 软件生存周期模型软件项目的过程规划和监控。

八、集成化能力成熟度模型CMMI

仅当对软件过程予以有效管理时，才能实现有效的软件工程
本章关注的是软件过程的改善问题集成产品能力成熟度模型CMMI是针对系统/产品开发的能力成熟度模型，包含一些最佳实践，覆盖了产品从概念到交付和维护的整个生存周期

• CMMI的核心理念
• CMMI的模型部件
• 能力等级的划分及各等级的特征
• 成熟度等级的划分及各等级的特征
• 能力等级和成熟度等级的基本关系

1、背景和原理

1）CMMI的含义

Capability Matur ity Model Integration forDevelopment ，集成化能力成熟度模型是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。

2）CMMI的目的

其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件

过程改进

3）CMMI的构成 **重要

4）CMMI的应用

过程途径的基本假设: 系统或产品的质量高度受开发和维护中所使用的过程质量的影响
质量支撑点:

• 人员
• 规程和方法
• 工具和设备

2、CMMI的模型部件

• CMMI是一种过程改善框架
• 过程改善:是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果

CMMI的模型部件

• 由一些过程域组成，过程域有自己的确定专用目标和公共目标。（实心圆角矩形）

• 每个专用目标和公共目标的实现，分别依赖一些实践。（实心菱形）

• 每个专用实践有自己的子实践和确定的典型工作产品符号:实心椭圆，资料性部件。

• 每个过程域还有意图陈述、简介性注释以及相关过程域

专用目标:过程域特有的目标
公用目标:几个过程域都可能要用到的目标
目标实现需要依赖实践

1）过程域

1. 过程域：一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。
2. CMMI有22个过程域，分为四类
3. 见下表所示:

**重要(选择题)

过程域类名	包括的过程域
项目管理类	规划、监控、定量项目管理、集成项目管理、风险管理、提供方协议管理
工程类	需求开发、需求管理、技术解决方案、产品集成、确认、验证
支持类	配置管理、过程和产品质量保证、测量与分析原因分析与解决、决策分析与解决
过程管理类	组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署

2）专用目标

1. 一个过程域中都有一个或多个专用目标
2. 描述该过程域必须呈现的一些独有特征
3. 专用目标可用于帮助确定一个过程域是否得以满足

3）专用实践

1. 对于达到专用目标是重要的活动
2. 期望以专用实践所描述的活动，会导致达到一个过程域的专用目标。

4）共用目标和共用实践

1. 可用于多个过程域

5）典型工作产品

1. 专用实践所产生的输出样品

专用实践“依据项目，监视项目规划参数的实际值“

2. 典型工作产品是:重大偏差的记录

6）子实践

1. 子实践是对专用实践、共用实践的详细描述

专用实践：针对已标识的问题，采取纠正措施
子实践：针对已标识的问题，确定所需要的适当措施，并建立相应的文档

7）共用实践的精化

1. 为一个共用实践唯一地应用于一个过程域，提供了 相关的指导

8）意图描述

1. 用来描述过程域的意图

“组织过程定义”过程域的意图: 建立并维护一组可用的组织过程资产和工作环境标准

9）简介性解释

用来描述该过程域中所涉及的主要概念

在项目规划过程域中，规划从需求开始，定义产品和项目

10）相关过程域

1. 用来描述该过程域所引用的相关过程域
2. 反映了过程域之间的关系

3、CMMI的等级

两种类型的等级

1. 能力等级：是一种过程改善路径，该路径可使组织针对单一过程域不断改善该过程域
2. 成熟度等级：是一种过程改善路径，该路径可使组织针对–组过程域不断改善一组相关的过程域

1）能力等级

1、过程能力:

• 遵循一个过程可达到的预期结果的程度
• 表征组织对一个过程域的改善，是不断改善一个给定的过程域的一种手段

2、能力等级：

包含一个共性目标及其相关的共性实践，它们与一个过程域相关联，能够改进组织同那个过程域相关联的过程
**重要

能力等级	描述
能力等级0	未完成级:过程不完整
能力等级1	已执行级:实现了过程域的特定目标
能力等级2	已管理级:建立了基本的项目管理过程来跟踪费用进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
能力等级3	已定义级:按照组织的裁减指南从组织的标准过程中裁减出来的一个已管理(能力等级 2)过程
能力等级4	已量化管理级:使用统计和其他定量技巧控制的个已定义(能力等级 3) 过程。
能力等级5	已持续优化级:经过改进的一个量化管理过程

2）组织成熟度等级

1. 成熟度等级是指达到预先定义的一组过程域所有目标的一种过程改善等级。一个成熟度等级是由预先定义的一个过程域集及其相关的一些专用实践和共用实践组成的。
2. CMMI的阶段式表示模型定义了5个成熟度等级，在持续的过程改进上，每一等级都是构成下一阶段基础的一个层次，这些等级用从1到5的数字表示。
   | 成熟度等级 | 描述 |
   | — | — |
   | 成熟度等级1:初始级 | 过程是混乱的，应付式的。 |
   | 成熟度等级2:已管理 | 能确保过程按照预定方针得到计划和执行 |
   | 成熟度等级3:已定义 | 过程得到了很好地描述和理解，并应用标准、规程、工具及方法来表现。 |
   | 成熟度等级4:量化管理 | 组织和项目为质量和过程绩效建立了量化目标并将其用作管理过程的标准 |
   | 成熟度等级5:持续优化 | 点关注通过渐进性和革新性过程改边和技术改进来持续地改进过程的绩效 |

成熟度等级包含的过程域

成熟度等级与能力等级的关系

(1)为了达到成熟度2级，2级所包含的所有过程域必须达到能力等级2或更高级
(2)为了达到成熟度3级，2级、3级所包含的所有过程域必须达到能力等级3或更高级
(3)为了达到成熟度4级，2、3、4级所包含的所有过程域必须达到能力等级3或更高级

4、过程域举例

两个过程域:项目规划 (2级) 和需求开发过程 (3级）

1）项目规划

1、意图:建立并维护项目活动计划的定义
2、所要满足的专用目标、共用目标以及所要实施的实践:

专用目标与专用实践

共用目标和共用实践

共用目标	共用实践
GG2: 共用目标2
把过程制度化为一个已管理过程。
对达到共用目标1的专用实践实施了P-D-C-A。	GP2.1:建立组织策略
GP2.2:规划过程
GP2.3:提供资源GP2.4:指派责任GP2.5:培训人员GP2.6:管理配置
GP2.7:标识相关利益方的参与GP2.8:监控过程
GP2.9:客观地评估符合型
GP2.10: 高层管理视角评审状态

2）需求开发

1、意图
生成并分析客户需求、产品需求和产品部件需求
2、专用目标和专用实践

专用目标和专用实践

共用目标和共用实践

共用目标	共用实践
GG3：把过程制度化为一个已定义过程。	GP3.1:建立一个已定义过程
涉及需求开发过程的共用目标2的有关内容
GP3.2:收集改进信息

小结

1. 针对开发的CMM是一个有关产品和服务的过程改善的成熟度模型，继承了三个源模型:软件CMM、系统工程CMM、集成产品开发CMM；
2. CMMI模型基于过程途径思想，通过过程把软件质量的3个支撑点:受训人员、规程和方法、工具，以开发所期望的系统/产品；
3. CMMI提供了两种过程改善路径，一个称为能力等级，另一个称为成熟度等级 ;
4. 能力等级有6个等级:
5. 成熟度等级包括4个过程组、5个等级

注：本博客仅供学习和参考，内容较多，难免会有错误，请大家多多包涵哈🌸🌸
参考视频学习（软件工程->赵守香）

欢迎您在评论区留下您宝贵的建议
完结撒花啦~~~🌸🌸