完整笔记在语雀
https://www.yuque.com/huangzhanqi/nrt1l4/zoa0g0osnrmog0xd《软件工程》串讲讲义
应考指导
一、课程介绍
1、课程性质
《软件工程》是全国高等教育自学考试计算机及应用（独立本科段）的一门专业课。
软件工程是研究软件开发的一门课程，其主要内容包括：软件开发所需要的过程、活动和任务，以及这些活动和任务的组织、实施和管理。
2、指定教材
本课程指定教材为《软件工程》，全国高等教育自学考试指导委员会组编，王立福主编，机械工业出版社出版，2011年版。
新版教材与2000年版相比，无论是内容还是内容的组织，都有了很大的变化。整个知识体系、章节安排、内容选取都不一样，这是考生一定要注意的。新版教材的内容组织特点主要体现在：
基于对软件开发本质的认识，讲解软件工程的两大技术问题：一是开发逻辑，二是开发途径。
开发逻辑涉及软件生存周期过程、软件生存周期模型（有关过程、活动和任务的组织框架）以及项目软件生存周期的规划与监控。
开发途径涉及结构化方法和面向对象方法，以及支持软件评估所需要的软件测试技术等。
3、章节体系
本课程共有8章：
第1章：回答什么是软件开发的本质
第2章：软件需求与软件需求规约
第3章：结构化方法
第4章：面向对象方法-UML
第5章：面向对象方法-RUP
第6章：软件测试。
第7章：软件生存周期过程及管理
第8章：集成化能力成熟度模型CMMI
二、考情分析
1. 历年真题的分布情况
由于教材刚刚经过改版，新教材刚经过2011年10月、2012年01月两次考试。 通过对这两次真题的分析，各章所占分值的分布情况如下表所示：
| 年 份 章名、题型 | 2011-10 | 2012-01 |
| 一、绪论（单项、填空题） | 3分 | 3分 |
| 二、软件需求与软件需求规约 | 9 | 11 |
| 三、结构化方法（单、填、简答、综合） | 25分 | 25分 |
| 四、面向对象方法-UML（单、填、简答） | 11分 | 11分 |
| 五、面向对象方法-RUP（单、填、简答） | 12分 | 12分 |
| 六、软件测试（单、填、简答、综合） | 25分 | 23分 |
| 七、软件生存周期过程及管理（单、填、简） | 10分 | 10分 |
| 八、集成化能力成熟度模型CMMI | 5 | 5 |
从上面的统计数据可以看出：主要的分值分布在第3章和第6章，分别占到总分的25%左右。第1章和第8章的考核知识点相对较少。
2. 题型分析
本课程的考试题型分为：
（1） 单项选择题，共15小题，每小题2分，共30分
（2） 填空题，共20个空，每空1分，共20分
（3） 简答题，共6小题，每小题5分，共30分
（4） 综合应用题，共2题，每题10分，共20分
3. 复习方法
（1）以教学大纲为准绳。自学考试的原则是：考试范围既不超出大纲又不超出教材范围。所以考生一定根据教学大纲规定的考试内容和考核要求，认真学习教材，要全面、系统了解教材中的基本概念、基本知识。
（2）有的放矢。在学习的过程中，为了达到“事半功倍”，要学会“舍”。要用有限的时间去抓重点，对重点内容要进行深入细致的学习。
（3）注意学习方法，理论联系实际，注重理解
重视理论联系实际，训练并逐渐提高运用所学理论分析和解决实际案例的能力。考生应当注意在全面系统学习教材的基础上，尽可能多地了解和分析实际案例，以便更深刻地领会教材的内容，提高分析和解决实际问题的能力。
（4）合理安排时间，抓住学习重点
根据实际情况自己安排，利用平时空余时间观看网络课件，形成基本的了解。接下来认真地做一些练习题，不清楚的地方再回过头去看看书，并注意对不同的知识点进行比较，加深印象。
第一章 绪论
复习建议：
本章内容较少，主要是让大家了解软件工程的提出的背景-软件危机以及软件工程研究的内容。
考试题目类型主要是单项选择题、填空题，题量在3%~5%之间。
第一节 软件工程概念的提出与发展
1. 软件危机
（1） 速度：软件的发展水平远远滞后于硬件的发展水平，生产率低下，软件制造仍然是一种人工集约生产方式
（2） 质量：软件的质量低下，不能满足用户的需求、适应性差
（3） 成本：软件开发成本居高不下
软件开发的速度、软件制品的质量、软件开发成本是软件工程的三个核心问题。
2. 软件工程的发展
（1）20世纪60~80年代
瀑布模型；过程化语言；支持工具
（2）20世纪80年代~今
软件复用技术；软件生产管理；面向对象语言
（3）近几年
软件复用技术：构件技术、平台技术、需求工程技术、领域分析技术、应用集成技术等。
第二节 软件开发的本质
1. 软件
软件=程序+文档
2. 软件开发的本质：“映射”，即实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。
3. 系统建模
运用所掌握的知识，通过抽象，给出系统的一个结构。
4. 模型
模型是一个抽象。模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述。
5. 系统模型的类型
（1） 概念模型：描述软件是什么
（2） 软件模型：实现概念模型的软件解决方案。包括设计模型、实现模型和部署模型。
本章小结
1.软件危机的出现，导致了软件工程的引入。
2.软件开发的本质，实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。
3.系统建模是指运用所掌握的知识通过抽象给出系统的一个结构。
4.模型是一个抽象。
5.在软件开发领域，模型有两大类：概念模型和软件模型。
第二章 需求获取
复习建议：
正确定义问题，是解决问题的基础。
需求获取是软件开发的第一步，它的工作质量决定了整个软件开发工作的成败，因此本章的内容是考核的重点内容。
考核的题目类型主要有：单项选择题、填空题、简答题，分值在10%左右。
内容以基本概念、基本原理为主。
第一节 需求与需求获取
1. 需求的定义
一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能能力、性能参数或其它性质。
2. 需求的基本性质
（1） 必要的
（2） 无歧义的
（3） 可测的
（4） 可跟踪的
（5） 可测量的
3. 需求的分类 ★
（1） 功能需求，是整个需求的主体。
（2） 非功能需求：性能需求、外部接口需求、设计约束和质量属性需求。
能够区分哪些是功能需求，哪些是性能需求。
4. 接口需求的类别
（1） 用户接口
（2） 硬件接口
（3） 软件接口
（4） 通信接口
（5） 内存约束
（6） 运行
（7） 地点需求
5. 设计约束需求
（1） 法规政策
（2） 硬件限制
（3） 与其它应用的接口
（4） 并发操作
（5） 审计能力
（6） 控制功能
（7） 高级语言要求
（8） 握手协议
（9） 应用的关键程度
（10） 安全和保密
6. 质量属性
（1） 可靠性
（2） 存活性
（3） 可维护性
（4） 用户友好性
7. 需求发现的技术
（1） 自悟
（2） 交谈
（3） 观察
（4） 小组会
（5） 提炼
第二节 需求规约（SRS）
1. 需求规约的定义 ★
是一个软件/产品/系统所有需求陈述的正式文档，它表达了一个软件/产品/系统的概念模型。
2. 需求规约的基本性质 ★
（1） 重要性和稳定性程度：对需求进行分级
（2） 可修改的
（3） 完整的：没有被遗漏的需求
（4） 一致的：不存在互斥的需求
3. 需求规约的格式
IEEE标准830-1998(IEEE 1998)描述的需求规格说明书模板。
4. 需求规约（规格说明书）的表达
（1） 非形式化的需求规约
（2） 半形式化的需求规约
（3） 形式化的需求规约
5. 需求规约的作用 ★
（1） 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现
（2） 需求规约是一个管理控制点
（3） 对于产品/系统的而设计，需求规约是一个正式的、受控的起始点
（4） 需求规约是创建产品验收计划和用户指南的基础
第三章 结构化方法
复习建议：
自顶向下，逐步求精。
本章是整个课程的重点内容，其基本思想、基本原理和基本方法是软件工程理论体系中最经典的内容，考核题型涉及单项选择题、填空题、简答题、综合应用题所有题目类型，占分值25%左右。
建议考生在牢记基本概念、基本原理的基础上，对综合应用题多下工夫，多做练习。
第一节 结构化需求分析
1. 需求分析面临的挑战
（1） 问题空间理解
（2） 人与人之间的通信，“有效沟通”
（3） 需求的变化性
2. 结构化分析中的基本术语及表示方法
（1） 数据流
（2） 加工
（3） 数据存储
（4） 数据源和数据潭
3. 数据流图DFD图 ★
用于建立系统功能模型。
是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。
4. 建模过程（绘制流程图的过程）
自顶向下、功能分解
（1） 建立系统环境图
（2） 0层图：从0层图开始对流程图中的要素编号
（3） 1层图
（4） ……
【例题】绘制数据流程图（2008年10月真题）
41.某个学生成绩管理系统的部分功能如下：
（1）基本信息管理：教务管理人员输入或修改学期教学执行计划、学生名单和教师名单；
（2）学生选课：学生根据教学执行计划进行选课；
（3）分配任课教师：教务管理人员为符合开课条件的课程分配教师，并打印任课通知单给教师；
（4）成绩管理：每门课程的教师在考试评分结束后将考试成绩交给教务管理人员，教务管理人员输入、维护成绩，系统可生成成绩单（发给学生）、成绩统计分析表（发给教务管理人员）。
请根据要求画出该问题的分层数据流图（要求画出顶层和0层数据流图）。
【解析】
顶层图：只包含数据源/数据潭以及相关的数据流和一个处理。
顶层图
学期教学执行计划 学生名单 学生选课结果 教师信息
0层图
要注意的问题：
① 黑洞(black hole)，即只有输入而没有输出。
②只有输出而没有输入。
③灰洞(gray hole)，即输入不足以产生输出。灰洞是经常也是不易被察觉的错误。
④加工处理只用来表示数据的处理和变化，避免将计算机命令作为处理。
⑤数据流必须起于且/或止于处理，即每一个数据流必须有一个处理与之有关，数据流不能起于数据存贮且止于一个数据源/数据潭或另一个数据存贮；也不能起于某个实体且止于另一个数据源/数据潭或数据存贮。
5. 数据字典
定义数据流程图中所有数据流和数据存储的数据结构。
顺序结构：+
选择结构：|
重复结构：{ }
子界：m..n
6. 加工的描述 ★
（1） 判定表
判断表(Decision Table)也称为决策表，是一个二维表，它说明了每一种条件组合所产生的结果。
该表分为四个象限(quadrants)。
a) 左上限代表所有的条件
b) 左下限代表可能的结果
c) 右上限代表每一种条件的取值(用Y和N来表示)
d) 右下限用X表示所对应的条件组合所产生的结果
【例题】画出顾客购货的折扣政策的决策表。
销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予5％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予3％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。
【解析】
（2） 判定树
判断树 (Decision Tree)也称为决策树，是用来描述在一组不同的条件下，决策的行动是根据不同条件及其取值来选择的处理过程。业务规则的描述通常可以使用判断树这一过程描述工具。
【例题】画出顾客购货的折扣政策的决策树。
销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予5％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予3％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。
解析：
（3） 结构化语言
【例题】用结构化语言表达：顾客购货的折扣政策。
销售商在给顾客的折扣时，要考虑付款日期和交易额这两个因素。若付款日期在10天以内(含10天)，则当交易额超过￥10,000时，给予3％的折扣；当交易额在￥5,000到￥10,000之间(含￥5,000)时，给予2％的折扣；当交易额低于￥5,000时，没有折扣。若付款日期超过10天，则无论交易额多少，均不给任何折扣。
IF 付款日期在10日以上
折扣=0
ELSE
IF 交易额>=10000
折扣=3%
ELSE
IF交易额>=5000
折扣=2%
ELSE
折扣=0
7. 需求验证
（1） 验证每一个需求满足5个性质
（2） 验证需求规格说明书满足4个性质
第二节 结构化设计
分为总体设计和详细设计
1. 总体设计的任务
把系统的功能需求分配到一个特定的软件体系结构中。
2. 表达软件体系结构的工具
（1）模块结构图
（2）层次图
（3）HIPO图
3. 模块结构图 ★
结构图(Structure Chart)是对软件总体结构的一种图形描述，它显示了软件的层次结构、组织和通讯。也就是说，在结构图中，显示了软件是由哪些模块组成的，这些模块按照什么样的层次结构组织在一起以及模块之间通过什么接口联系在一起。
结构图也称之为控制结构图、模块结构图或系统结构图。
（1） 模块符号
（2） 模块调用关系
（3） 模块间的数据传递
（4） 模块间的控制信息传递
（5） 循环调用结构
（6） 选择调用结构
（7） 数据存储
4. 层次图
层次图中一个矩形框代表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方的矩形框所代表的模块）。
5. HIPO图
HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了使HIPO图具有可追踪性，在H图(即层次图)里除了顶层的方框之外，每个方框都加了编号。
H图+IPO图
6. 总体设计步骤
将DFD图映射为设计层面的模块及模块调用。
（1） 变换流(Transform Flow)。基于变换流的数据流程图是一个线性的顺序结构，由输入臂、输出臂和变换中心三部分组成。其中变换中心使系统数据发生本质的变化，输入臂将物理输入变换成逻辑输入，而输出臂则将逻辑输出变换成物理输出。
（2） 事务流(Transaction Flow)。事务流的数据流程图中有一个事务处理中心，它将输入分为许多相互平行的加工路径，然后根据输入的属性，选择某一加工路径。如下图所示。
业务中心完成以下任务：
Ø ⑴接收事务(即输入数据)；
Ø ⑵分析每个事务并确定它的类型；
Ø ⑶根据事务的类型选取一条活动通路。
【例题】控制结构图的绘制
根据数据计算的数据流图：
画出以转换为中心的控制结构图。
【解析】这是一个典型的以“转换为中心”结构的分解，可以转化为：
总结：任何处理都可以划分为两种转换类型之一：以转换为中心的分解和以业务为中心结构的分解。
【例题】产生固定资产资料数据流程图如下，做出以业务为中心的模块控制结构图。
【解析】
这是以业务为中心的处理，根据模板，可以转化为：
|
| ||||||||||||||||||
7. 模块
执行一个特殊任务的一个过程以及相关的数据结构。模块通常由两部分组成：模块接口和模块体。
8. 模块化
“分而治之”和“抽象”。
把一个待开发的软件分解成若干个简单的、具有高内聚低耦合的模块，这一过程称为模块化。
模块化是系统设计基本原理/原则之一。
9. 内聚(Cohesion)
是指一个模块内部个成分之间相互关联程度的度量。也就是说，凝聚是对模块内各处理动作组合强度的一种度量。很显然，一个模块的内聚越大越好。
（1）偶然凝聚 可维护性最差
（2）逻辑凝聚
（3） 时间凝聚
（4）过程内聚
（5）通信内聚
（6）顺序凝聚
（7）功能凝聚 可维护性最好
10. 模块耦合
耦合(coupling)是对两个模块之间联接程度的一种度量。模块间的依赖程度越大，则其耦合程度也就越大；反之，模块间的依赖程度越小，则其耦合程度也就越小。
很显然，为了使软件具有较好的可维护性和可修改性，模块间的关联程度即耦合程度应越小越好。因为耦合程度越小，表明模块间的独立程度越大，这样在修改一个模块时，对其它模块的影响程度就越小，从而使模块的修改工作局限于一个最小范围之内。
（1） 内容耦合
（2） 公共耦合
（3） 数据耦合
（4） 控制耦合
（5） 标记耦合
原则是：尽量用数据耦合，少用控制耦合，限制公共耦合的范围，避免使用内容耦合。
11. 启发式规则
高内聚、低耦合。
（1） 改进软件结构，提高软件独立性。模块分解
（2） 模块规模适中
（3） 力求深度、宽度、扇出、扇入适中。
深度：表示其控制的层数。
宽度：同一层次上模块总数的最大值。
扇出：一个模块直接控制的下级模块的数目。
扇入：有多少个上级模块直接调用它。
原则：顶层模块扇出比较大，中间层模块扇出较小，底层模块具有较大的扇入。
（4） 尽量使模块的作用域在其控制域内。
模块的控制域：这个模块本身以及所有直接或间接从属它的模块的集合。
模块的作用域：受该模块内一个判断所影响的所有模块的集合。
（5） 尽力降低模块接口的复杂度
（6） 力求模块功能可以预测
12. 详细设计
具体描述模块结构图中的每一模块，即给出实现模块功能的实施机制，包括一组例程和数据结构。
13. 结构化程序设计方法
一种基于结构的编程方法，即采用顺序结构、选择结构和重复结构进行编程，其中每一结构只允许一个入口和一个出口。
三种基本的控制结构：
(a) 顺序结构，先执行A再执行B；
(b) IF-THEN-ELSE型选择(分支)结构；
(c)DO-WHILE型循环结构
14. 详细设计工具
（1） 程序流程图
程序流程图：程序流程图又称为程序框图，它是历史最悠久使用最广泛的描述过程设计的方法，然而它也是用得最混乱的一种方法。
（2） 盒图（N-S图）
出于要有一种不允许违背结构程序设计精神的图形工具的考虑，Nassi和Shneiderman提出了盒图，又称为N-S图。
(a) 顺序；(b) IF-THEN-ELSE型分支；(c) CASE型多分支；
(d) 循环；(e) 调用子程序A
（3） PAD图
PAD是问题分析图(Problem Analysis Diagram)的英文缩写，自1973年由日本日立公司发明以后，已得到一定程度的推广。它用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。下图给出PAD图的基本符号。
（4） 类程序设计语言PDL
PDL也称为伪码，它是用正文形式表示数据和处理过程的设计工具。
PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；另一方面，PDL表示实际操作和条件的内部语法通常又是灵活自由的，以便可以适应各种工程项目的需要。因此，一般说来PDL是一种“混杂”语言，它使用一种语言（通常是某种自然语言）的词汇，同时却使用另一种语言（某种结构化的程序设计语言）的语法。
可以作为注释工具直接插在源程序中间。
15. 设计规约
完整准确地描述满足需求规约所要求的所有功能模块，以及伴随功能模块而出现的非功能机制。
设计规约包括概要设计规约和详细设计规约。
（1） 概要设计规约
指明高层软件体系结构。
Ø 系统环境
Ø 软件模块的结构
Ø 模块描述
Ø 文件结构和全局数据文件的逻辑结构
Ø 测试需求
（2） 详细设计规约
Ø 各处理过程的算法
Ø 算法所涉及的全部数据结构的描述
【例题】根据下列变换型的数据流图，设计出初始软件结构图。
题40图
【答案】
【解析】这是一个典型的变换型数据流程图，将其转换为模块控制图时，第一层可以分解为三个模块：输入模块、变换模块、输出模块。每一模块还可以继续分解。
第四章 面向对象方法UML
复习建议：
以不变应万变。
统一建模语言（Unified Modeling Language，UML）
UML是目前流行的建模语言，特别是在网站开发中广泛应用。
UML涉及很多的图，每一种图都有不同的图形符号、作用，在什么情况下用何种图来描述是本章的重点内容。
考核题目类型包括单项选择题、填空题、简答题，分值在10%~15%之间。需要考生掌握各种UML图的作用。
面向对象建模过程的步骤：
（1） 需求获取
a) 建立用况（use case）模型和用况场景
（2） 需求分析
a) 建立活动图和状态图
b) 类图（建立域模型）
c) 顺序图（实现用况）
（3） 编写需求规格说明书
（4） 需求验证
第一节 UML术语表
1. 对象（object）
对象（object）是系统中用来描述客观事物的一个实体。一个对象由一组属性和对这组属性进行操作的一组方法组成。
对象只描述客观事物本质的与系统目标有关的特征。
对象之间通过消息通信，一个对象通过向另一个对象发送消息激活某一个功能。
2. 类
类（Class）是具有相同属性、操作、关系和语义的一组对象的集合，它为属于该类的全部对象提供了同一的抽象描述，其内部包括属性和服务两个主要部分。
类有超类（Superclass）和子类（Subclass）之分。
（相对而言）对象与类的关系犹如程序设计语言中变量和类型的关系。对象是类的实例（Instance）。
类在类图上使用包含三个部分的矩形来描述，如下图4-1所示。最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的操作（或者说"方法"）。
图4-1：类图中的示例类对象
3. 属性
对象或类的属性（attributes）描述了对象的具体特征。属性有属性名和属性值（或称属性状态）。
每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。
UML规定类的属性的语法为：
可见性 属性名 ： 类型 = 缺省值 {性质串}
可见性：public（+） 、protected（#）、private（-）、包内的（~）
4. 类的操作
通常也被称为功能，但是它们被约束在类的内部，只能作用到该类的对象上。操作名、返回类型和参数表组成操作界面。
UML规定操作的语法为:
可见性 操作名 （参数表） : 返回类型 {性质串}
例如：+取客户地址（客户名:字符串）：字符串
5. 接口
接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务。
（1） 采用具有分栏和关键字<interface>的矩形符号来表示
（2） 采用小圆圈和半圆圈来表示
6. 协作
协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容。
7. 用况（use case）/用况
对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果。
8. 主动类
至少具有一个进程或线程的类。能够启动系统的控制活动，并且其对象的行为通常与其它元素行为并发的。
表示方法：两条竖线。
9. 构件
系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。
10. 制品
系统中包含物理信息的、可替代的物理部件。
11. 节点
节点是在运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。
12. 关联（Association）
关联反映了类和类之间的静态关系。关联在模型中，特别是在永久业务对象模型中是最基本的关系。
链（link）是对象之间具有特定语义关系的抽象。
（1） 关联名
（2） 导航
（3） 角色
（4） 可见性
（5） 多重性：多重性（Multiplicity）定义了与一个对象/类相联系的对象/类出现一次，该对象/类可能出现的最小和最大的数目。
（6） 限定符
（7） 聚合：一个类是另一类的一部分。
（8） 组合：是聚合的一种特殊形式
（9） 关联类
（10）约束
13. 泛化/继承
继承：特殊类（子类）的对象拥有其一般类（超类）的全部属性与服务，称作特殊类对一般类的继承（Inheritance） 。利用继承（inheritance），子类可以继承父类的属性和方法。子类／父类也可分别叫做特殊类／一般类、子类／超类、派生类／基类等。
继承反映了类之间的一种联系或结构:一般-特殊结构，也称分类结构（Classification Structure），是由一组具有继承关系的类所组成的结构。仅由一些单继承关系的类形成的结构又称作层次结构（Hierarchy Structure）；由一些存在多继承关系的类形成的结构又称作网格结构（Lattice Structure）。
14. 多态性（Polymorphism）
是指一般类中定义的属性或服务被特殊类继承之后，可以具有不同的数据类型或表现出不同的行为。这使得同一属性或服务名在一般类及其各个特殊类中具有不同的语义。
多态是指用同一界面形式表示不同对象类中的不同实现的能力。
多态性的实现基于两个基本原理：封装和泛化。
多态性实现的方法：
（1）泛化
（2）定义一个抽象类——接口类
15. 细化
细化是类目之间的语义关系，其中一个类目规约了保证另一类目执行的契约。
用空心三角形的虚线表示。
16. 依赖
依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。
用有向虚线段表示。
17. 包
包是模型元素的一个分组，一个包本身可以被嵌套在其它包中，并且可以含有子包和其它类型的模型元素。
第二节 UML的模型表达格式
图形化工具。
图的类别：
（一）结构图
（1）对象结构建模—类图和对象图
（2）应用结构建模—包图、构件图、部署图、组合结构图
（二）行为图
对象交互建模—顺序图、协作图（通信图、交互综述图、定时图）、状态图（状态机）
对象行为建模—用况图、活动图
- 类图
任何系统都需要从两方面进行描述：结构信息和行为信息。系统的组成表达了系统各组成要素之间的联系，称为结构；这些组成要素的执行逻辑称为行为。在面向对象方法中，系统的结构信息是通过类图（class diagram）来描述的；而系统行为信息则通过用况图、交互图（包括顺序图和协作图）和状态图来描述的。也就是说，前者说明了系统的组成部分是什么，而后者则说明了系统做什么。
类图（class diagram）表达了系统的静态结构信息，即系统是由哪些类组成的，这些类之间的关系是什么。
类图显示系统各个部分以及怎样将它们组装起来;但却不能模拟组装后系统的工作情况。
构造类图的三个关键问题是：
（1） 系统中有哪些需要关心的类？
（2） 这些类是如何描述的？
（3） 这些类之间的联系是什么？
创建一个系统的类图，要涉及4方面的工作：
（1） 模型化待建系统中的概念，形成类图中基本元素
（2）模型化待建系统中的各种关系，形成该系统的初始关系。
（3）模型化系统中的协作，给出该系统的最终类图。
（4）模型化逻辑数据库模式
2. 用况图（use case 图）
用况是对一个参与者（actor）使用系统的一项功能时所进行的交互过程的一个文字描述序列。
用况是系统、子系统或类 与 外部的参与者（actor）交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。
用况图（Use Case Diagram）是指反映活动者，系统边界所封闭的用况，及活动者与用况之间，用况与用况之间关系的一种图。
6个模型元素：
（1） 主题
（2） 用况
（3） 参与者：
Ø 系统用户: 是最常见的一种角色。是直接使用系统的人。
Ø 另一个系统：如DSS可作为MIS的一个活动者。补货系统可作为定单处理系统的活动者。
Ø 时间：当经过一定时间触发系统中的某个事件时，时间就成了角色。例如定期的某些业务处理工作。
（4） 关联
（5） 泛化
（6） 依赖
3. 状态图
对象或者类的整体行为的某些规则所能适应的对象或类的状况、情况、条件、形式或生存周期。仅当对象的行为规则不同时，才称对象处于不同的状态。
在由对象的全部属性的属性值集合所构成的笛卡儿乘积中的每一个等价集合（即，使对象的服务呈现相同行为规则的属性值的集合）称之为对象的一种状态。
例如，对象发票（invoice）可以根据其付款的情况分为三个状态：未付款（unpaid）、部分付款（partly paid）以及付清款（fully paid）。
状态图（state chart diagram）使用状态、事件和转换来记录对象在其生命周期中所历经的状态序列。
① 对象的初始状态是图中任何事件都未对该对象起作用时的状态。
② 状态代表对象生命周期中的某一瞬间。
③ 转换表明作为对事件的响应结果，对象将从一种状态转换到另一种状态并执行某个动作。
④ 触发状态转换的事件在状态转换字符串中命名。双击一个状态转换，除事件签名以外，还可用字符串为其加注临界条件、动作表达式等标签。
- 顺序图
顺序图（sequence diagram）表示了对象之间传送消息的时间顺序，也就是对象之间的交互顺序，这些交互是指在场景或用况的事件流中发生的。每一个对象（类）用一条生命线来表示——即用垂直线代表整个交互过程中对象的生命期。生命线之间的箭头连线代表消息。
顺序图中的基本元素包括：
① 活动者，指用况中的活动者。
② 对象，指在用况中的内部对象。
③ 生命线：在顺序图中的一个对象下面的竖线，用以显示这个对象的生命期。时间从上到下流过。生命线实际上显示了消息的顺序，在生命线之上的消息比在它之下的消息先发生。在生命线中的棒形方框表示的是活动生命线，用以强调一个对象只有在一个场景的部分中处于活动状态。
④ 消息，指场景内由事件流定义的内部事件成为在对象和活动者或其他对象之间的消息。
• 同步消息——返回消息。同步消息假定有一个返回消息。同步消息用有实心的箭头表示；返回消息用虚线、箭头也不是实心来表示。
• 反身消息——消息的发送方和接收方是同一个对象。
• 异步消息——没有返回值的消息。用非实心箭头表示。
• 定时消息——对消息附加时间约束条件，包括：发送时间、接收时间、已用时间等。
第五章 面向对象方法-RUP
复习建议：
RUP（Rational Unified Process，统一软件开发过程）。
掌握RUP在解决下列三个问题的基本方法。
（1） 表达基本信息的术语
（2） 用于组织基本信息的表达格式
（3） 在不同抽象层之间进行“映射”的过程指导。
本章考核题目类型包括单项选择题、填空题、简答题，分值在10%~15%之间。
重点要掌握基本概念、基本原理。
1．迭代式开发
在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上，我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险，而且每个迭代过程都可以执行版本结束，可以鼓舞开发人员。
2．管理需求
确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化，用况和脚本的使用已被证明是捕获功能性需求的有效方法。
3．体系结构
组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于降低管理复杂性，提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
4．可视化建模
RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模，获取有关体系结构于组件的结构和行为信息。
5．验证软件质量
在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
6．控制软件变更
迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
第一节 RUP的特点
以用况驱动的、以体系结构为中心的迭代、增量式开发。
1. 用况驱动
（1） 用况是能够向用户提供有价值结果的系统中的一种功能
（2） 用况获取的是功能需求
在系统的生存周期中，以用况作为基础，驱动系统有关人员对所要建立系统的功能需求进行交流，驱动系统分析、设计、实现和测试等活动，包括制定计划、分配任务、监控执行和进行测试等，并将它们有机地组织在一起，使各个阶段中都可以回溯到用户的实际需求。
2. 以体系结构为中心
系统体系结构：是对系统语义的概括描述，对所有项目有关人员都是可以理解的。
3. 迭代与增量
（1） 迭代是重复的部分
（2） 增量是增加的部分
一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。
图5-1 RUP迭代模型
二维开发模型：
RUP软件开发生命周期是一个二维的软件开发模型。横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期(Cycle）、阶段（Phase）、迭代（Iteration）和里程碑(Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。如图1：
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
图5-2：RUP二维开发模型
（1） 初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。初始阶段结束时是第一个重要的里程碑：生命周期目标（Lifecycle Objective）里程碑。生命周期目标里程碑评价项目基本的生存能力。
（2） 细化阶段
细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构作出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑：生命周期结构（Lifecycle Architecture）里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
（3）构造阶段
在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。
（4）交付阶段
交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑：产品发布（Product Release）里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。
第二节 核心工作流
RUP中有9个核心工作流，分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。
（1）商业建模
商业建模（Business Modeling）工作流描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用况模型和商业对象模型中定义组织的过程，角色和责任。
（2）需求
需求（Requirement）工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织、文档化；最重要的是理解系统所解决问题的定义和范围。
（3）分析和设计
分析和设计（Analysis & Design）工作流将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。设计模型是源代码的抽象，由设计类和一些描述组成。设计类被组织成具有良好接口的设计包（Package）和设计子系统（Subsystem），而描述则体现了类的对象如何协同工作实现用况的功能。设计活动以体系结构设计为中心，体系结构由若干结构视图来表达，结构视图是整个设计的抽象和简化，该视图中省略了一些细节，使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承载媒介，而且在系统的开发中能提高被创建模型的质量。
（4）实现
实现（Implementation）工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式（源文件、二进制文件、可执行文件）实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。
（5）测试
测试（Test）工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。RUP提出了迭代的方法，意味着在整个项目中进行测试，从而尽可能早地发现缺陷，从根本上降低了修改缺陷的成本。测试类似于三维模型，分别从可靠性、功能性和系统性能来进行。
（6）部署
部署（Deployment）工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动，包括：软件打包、生成软件本身以外的产品、安装软件、为用户提供帮助。在有些情况下，还可能包括计划和进行beta测试版、移植现有的软件和数据以及正式验收。
（7）配置和变更管理
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置和变更管理工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同时也阐述了对产品修改原因、时间、人员保持审计记录。
（8）项目管理
软件项目管理（Project Management）平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。其目标包括：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。
（9）环境
环境（Environment）工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。环境工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
图5-3 RUP核心概念
1. 需求获取
RUP运用用况（Use Case）技术来获取需求。
（1） 列出候选的需求：特征列表
（2） 理解系统语境：领域模型或业务模型
（3） 捕获功能需求：用况模型
（4） 捕获非功能需求：补充需求或针对一些特定的用况
特征：是一个新的项（Item）及其简要描述。
领域模型：类图
(1) 业务对象
(2) 实在对象
(3) 事件
业务对象模型：交互图、活动图
（1） 工作人员
（2） 业务实体
（3） 工作单元
创建系统用况模型的活动和任务：
（1） 发现并描述参与者
（2） 发现并描述用况
（3） 确定用况的优先级
（4） 精化用况
（5） 构造用户界面原型
（6） 用况模型的结构化
2. 需求分析
在系统用况模型的基础上，创建系统分析模型以及在该分析模型视角下的体系结构描述。
分析类：是类的一种衍型，很少有操作和特征标记，而用责任来定义其行为，并且其属性和关系也是概念性的。
存在三种不同类型的类：实体类、边界类和控制类。
（1）实体类
实体类描述要保存到持久存储体中的信息。如：数据库、各种形式的数据文件中的信息。包括：
活动者类。活动者类代表出现在用况模型中的活动者。活动者是现实世界中与系统交互的人和/或机构。例如，订单处理系统中客户是一个活动者类。
业务类描述业务的地点、物品、概念和事件。例如订单处理系统中的订单、商品等都是业务类。
（2）边界类
也称界面类（UI类），是组成系统用户界面的屏幕显示、菜单和报表。例如，订单处理系统中客户登录系统的界面、显示和编辑订单的屏幕等都属于UI类。
边界类位于系统与外界的交界处。如：窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。
（3）控制类
控制类是主要负责其它类工作的类。如：主程序类、主窗体类。
分析包:
分析包体现了“局部化”、“问题分离”等软件设计原理。
分析包把一些变化限制到一个业务过程、一个参与者的行为或一组紧密相关的用况，形成一些不同的分析包。
服务包和共享包。
用况细化：
（2）分析模型的表达
（3）分析的主要活动
活动1：体系结构分析
活动2：用况分析
3. 设计层
定义满足需求规约所需要的软件结构。
RUP的设计目标：定义满足系统/产品分析模型所规约需求的软件结构。
4个术语：
（1） 设计类
（2） 用况细化
（3） 设计子系统
（4） 接口
两个角度：
（1） 系统设计模型
（2） 表达物理分布的系统部署模型
4. 设计层的术语
（1） 设计类：是对系统实现中一个类或类似构造的一个无缝抽象。
了解设计类的主要特征：操作、属性、关系、方法、实现需求、是否为主动类。
（2） 用况细化：描述一个特定用况是如何予以细化的。
（3） 设计子系统
（4） 接口
5. 设计模型、部署模型、体系结构描述
（1） 设计模型
（2） 部署模型
（3） 体系结构描述
6. 设计的主要活动
活动1：体系结构设计
（1） 标识节点和它们的网络配置
（2） 标识子系统和它们的接口
（3） 标识在体系结构方面有意义的设计类和它们的接口
（4） 标识一般性的设计机制
活动2：用况的设计
（1） 标识参与用况细化的设计类
（2） 标识参与用况细化的子系统和接口
活动3：类的设计
（1） 概括描述设计类
（2） 标识操作
（3） 标识属性
（4） 标识关联和聚合
（5） 标识泛化
（6） 描述方法
（7） 描述状态
活动4：子系统设计
（1） 维护子系统依赖
（2） 维护子系统所提供的接口
（3） 维护子系统内容
7. RUP的实现
RUP实现的目标：
（1）基于设计类和子系统生成构件
（2）对构成进行单元测试
（3）进行集成和连接
（4）把可执行的构件映射到部署模型
RUP实现的主要活动：
（1） 实现体系结构
（2） 集成系统
（3） 实现子系统
（4） 实现类
（5） 完成单元测试
8. RUP的测试
包括：内部测试、中间测试和最终测试。
RUP测试包括的主要活动：
（1） 计划测试
（2） 设计测试
（3） 实现测试
（4） 执行集成测试
（5） 执行系统测试
（6） 评价测试
第六章 软件测试
复习建议
错误是不可避免的，我们要做的就是发现它，并改正它。
软件测试是保证软件过程质量和软件产品质量的基础。因此软件测试也是本课程的重点内容，题目类型涉及单项选择题、填空题、简答题、综合应用题全部题型，分值在25%左右。
本章既有基本概念，也有综合应用，要求考生多做练习。
第一节 软件测试目标与软件测试过程模型
1. 软件测试的对象
软件=程序+文档
测试对象：各个阶段产生的源程序和文档。
2. 软件测试的目的
基于不同的立场，对软件测试的目的存在着两种完全对立的观点。
（1） 一种观点是通过测试暴露出软件中所包含的故障和缺陷(从用户的角度)；
（2） 另一种是希望测试成为表明软件产品中不存在错误的过程，验证该软件中已正确地实现了用户的要求，因此，它们倾向于选取导致程序失败概率最小的测试实例和数据。
显然，第二种观点对完善和提高软件质量和可靠性毫无价值，因此测试的目的应该是通过软件测试尽可能多地发现并改正软件种存在的错误。
3. 软件测试的定义
Glenford J. Myers把这一观点归纳为：
⑴测试是程序执行的过程，其目的在于发现错误。
⑵一个好的测试实例在于发现至今未发现的错误。
⑶一个成功的测试是发现了至今未发现的错误的测试。
因此,软件测试(Software Testing)是从引起和发现错误的目的出发执行某一程序的过程。
4. 错误的类型
（1） 功能错误：处理功能说明不完整或不确切，致使编程时对功能有误解而产生的错误。
（2） 系统错误：与外部接口错误、子程序调用错误、参数使用错误等。
（3） 过程错误：算术运算错误和逻辑运算错误
（4） 数据错误：数据结构、实体、属性错误。
（5） 编程错误：语法错误、程序逻辑错误、编程书写错误等。
5. 软件测试过程模型
（1）测试设计
（2）测试执行
（3）测试结果比较
第二节 软件测试技术
测试法分为黑盒法和白盒法。
1. 黑盒（Black-box Testing）法：黑盒法又称为功能测试法，它是根据程序功能的分析，推演出由函数定义域中有代表性的元素组成测试集，这些数据应包括对程序是有效的和无效的输入，极端的、正常的和特殊的数据元素。因此，黑盒测试法是从外界来检查模块或程序的功能，也即根据模块的输入和输出，得出所得结果得差异。这种测试无须知道模块的内部逻辑，而是给定一输入，检查是否会得到所期望的输出。功能测试法又具体分为等价类法，边值分析法，因果图法和错误猜测法等。
2. 白盒法（White-box Testing）：白盒法也称之为结构测试或逻辑覆盖法。它是根据对软件内部逻辑结构的分析，选取测试数据集（即测试用例：Testing Case），而测试数据集对程序逻辑的覆盖程度决定了测试完全性的程度。常用的几个覆盖标准有：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖。
【例题▪填空题】黑盒法又称为＿＿＿＿＿＿＿法，黑盒测试法是从外界来检查模块或程序的功能，也即根据模块的输入和输出，得出所得结果得差异。
【答案】功能测试
3. 路径测试技术（白盒测试） ★
依据的是程序的逻辑结构。
（1） 控制流程图
基本元素：过程块、节点、判定。
链、路径的概念。
注意：控制流程图和程序流程图的差别。
（2） 测试策略
a) 路径覆盖：执行所有可能穿过程序控制流程的路径。 最强的测试度量。
b) 语句覆盖：至少执行程序中所有语句一次。最低的测试度量。
c) 分支覆盖：至少将程序中的每个分支执行一次。
d) 条件覆盖与条件组合覆盖
语句覆盖≤分支覆盖≤条件组合覆盖≤路径覆盖
（3） 路径选取与用例设计
最小的强制性测试需求是语句覆盖率。
【例题】根据下列程序流程图，设计不超过2组的测试用例，使之满足语句覆盖，要求给出每组测试数据的执行路径、输入值、输出值及两个判定（3）和（5）的判定结果。
【解析】此类题目属于综合应用题（每题10分），考核知识点为路径测试技术。
在本题中，要求设计测试用例，满足语句覆盖，即所有语句都必须执行一遍。
A、B、C的值决定了程序执行的顺序
| A、B、C的值 | 执行顺序 | 结果 |
| 3,6,10 | 1,2,3,4,5,7,8 | 7 |
| 25,1,10 | 1,2,3,5,6,7,8 | 11 |
4. 路径选取的一般原则
（1） 选择最简单的、具有一定功能含义的入口/出口路径
（2） 在已选取的基础上，选择无循环的路径，选取短路径、简单路径
（3） 选取没有明显功能含义的路径，要研究该路径为什么存在
5. 基于事务流的测试技术
（1） 事务与事务流程图
事务的含义
事务流
（2） 事务流测试的步骤
a) 获得事务流程图
b) 浏览、复审
c) 用例设计
d) 测试执行
6. 等价类法
是根据程序的I/O特性，将程序的输入划分为有限个等价区段，使得从每个区段内抽取的代表性数据进行的测试等价于该区段内任何数据的测试。对于每个输入条件存在着程序有效输入的有效等价类和对程序错误输入的无效等价类。例如，某实数X的取值范围假设为a＜X＜b，则所有[a+1，b-1]之间的实数构成了有效等价类，而任何[-∞，a]或[b，+∞]之间的实数构成了两个无效等价类。
7. 边值分析法
是一种根据I/O边界等价类上或紧靠边界的条件，选择测试用例的更有效的方法。例如，给定三个点，判定能否构成三角形，可选取两边之和等于第三边的实例作为边值分析法的测试用例。
【例题】有一个学生选课系统：程序的输入条件为：每个学生可以选修1至3门课程，试用黑盒测试法完成测试。
(1)按等价类划分法，设计测试用例(要求列出设计过程)；
(2)按边界值分析法，设计测试用例。
【解析】
（1）等价类法：
课程门数<1
课程门数>3
课程门数1~3
（2）边界值分析法
课程门数=1
课程门数=3
8. 因果图法
是通过从用自然语言书写的功能说明表中找出因—输入条件和果—输出结果，通过因果图将功能说明转换成一张判定表，然后为每种输出条件的组合设计测试用例。
错误推测法是根据测试人员的经验和直觉推测程序种可能存在的各种错误。
第三节 软件测试步骤
软件测试是按照与系统开发相反的方向来进行的。依次为：单元测试(模块测试)、集成测试、有效性测试和系统测试。
1． 单元测试
单元测试（Unit Testing）又称模块测试（Module Testing），或模块分调，用于测试单个程序模块，确定模块的逻辑和功能是否正确。
单元测试采用白盒测试技术。
（1） 模块接口
（2） 局部数据结构
（3） 重要的执行路径
（4） 错误执行路径
驱动模块和承接模块。
2．集成测试
集成测试(Integration Testing)用来测试模块之间接口的正确性，也即模块之间的数据和控制传递。集成测试是与单元测试平行进行的。
集成测试采用黑盒测试技术。
（1） 自顶向下的集成测试：需要设计承接模块
（2） 自底向上的集成测试：需求设计驱动模块
3．有效性测试
目的：发现软件实现的功能与需求规格说明书不一致的错误。
方法：采用黑盒测试技术
第七章 软件生存周期过程与管理
复习建议
开发逻辑，是获取正确软件的关键！
围绕生命周期的阶段划分，掌握每一阶段的任务、内容、工作方法、工作成果。
题目类型包括单项选择题、填空题、简答题，分值在10%左右。
第一节 软件生存周期过程概述
1. 软件生存周期(SDLC，软件生命周期)
是软件的产生直到报废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟，软件生命周期设计方法的指导意义正在逐步减少。
一般来说，软件生存周包括计划、开发、运行三个时期，每一时期又可分为若干更小的阶段。计划时期的主要任务是分析用户要求，分析新系统的主要目标以及开发该系统的可行性。开发时期要完成设计和实现两大任务具体。具体分为需求分析、概要设计、详细设计、编码、测试。其中编码和测试是软件开发期的最后两个阶段。运行时期是软件生存周期的最后一个时期，软件人员在这一时期的工作，主要是做好软件维护。
2. 基本过程
指那些与软件生产直接相关的活动集。
（1） 获取过程
（2） 供应过程
（3） 开发过程
（4） 运行过程
（5） 维护过程
3. 开发过程
软件开发者所从事的一系列活动和任务。将一组需求转换为一个软件产品或系统。
（1） 过程实现
（2） 系统需求分析
（3） 系统体系结构设计
（4） 软件需求分析
（5） 软件体系结构设计
（6） 软件详细设计
（7） 软件编码和测试
（8） 软件集成
（9） 软件合格性测试
（10） 系统集成
（11） 系统合格性测试
（12） 软件安装
（13） 软件验收支持
4. 过程实现
（1） 选择合适的生存周期模型
（2） 选择相应的标准、方法、工具和程序设计语言
（3） 制定实施开发计划
（4） 可以使用一些非交付的软件项。
5. 系统需求分析
（1） 建立系统需求规格说明
（2） 对系统需求进行评估
a) 有关获取方面需要的可追踪性
b) 有关获取方面需要的一致性
c) 可测试性
d) 系统体系结构设计的可行性
e) 运行与维护的可行性
6. 系统体系结构设计
（1） 建立系统的顶层体系结构
（2） 对体系结构及每一项的需求进行评估
a) 系统需求的可追踪性
b) 与系统需求的一致性
c) 所使用的设计标准和方法的适宜性
d) 软件项满足其所分配的需求的可行性
e) 运行与维护的可行性
7. 软件需求分析
（1） 建立软件需求规格说明
a) 功能与能力的规格说明
b) 该软件项的外部接口
c) 合格性需求
d) 有关安全的规格说明
e) 有关保密的规格说明
f) 人因工程的规格说明
g) 数据定义和数据库需求
h) 用户文档
i) 用户操作与执行需求
j) 用户维护需求
（2） 对软件需求进行评估
a) 对系统需求和系统设计的可追溯性
b) 与系统需求的外部一致性
c) 内部一致性
d) 可测试性
e) 软件设计的可行性
f) 运行和维护的可行性
（3） 联合复审
8. 软件体系结构设计
（1） 把对软件项的需求转变为一种体系结构
（2） 对该软件项的外部接口和各构件之间的接口进行顶层设计
（3） 进行数据库的顶层设计
（4） 编制用户文档的最初版本
（5） 为软件集成定义初步的测试需求文档
（6） 对软件项的体系结构、接口和数据库设计进行评估
（7） 实施联合评审
9. 支持过程
是指有关各方按他们的目标所从事的一系列支持活动集。支持活动有助于提高系统或软件产品的质量。
（1） 文档过程
（2） 配置管理过程
（3） 质量保证过程
（4） 验证过程
（5） 确认过程
（6） 联合评审过程
（7） 审计过程
（8） 问题解决过程
10. 支持过程—配置管理过程
应用管理上、技术上的规程来支持整个软件生存周期的过程。
（1） 过程实现：编制配置管理计划
（2） 配置标识
（3） 配置控制：标识并记录变更请求
（4） 配置状态统计：编制管理记录和状态报告
（5） 配置评价
（6） 发布管理和交付
11. 组织过程
与软件生产组织有关的活动集。
（1） 管理过程
（2） 基础设施过程
（3） 培训过程
（4） 改进过程
12. 组织过程—管理过程
（1） 启动与范围定义
（2） 规划
（3） 测量
（4） 执行与控制
（5） 评审与评价
（6） 结束处理
13. ISO/IEC系统与软件工程-软件生存周期过程12207-2008
2个过程类、7个过程组、43个过程。
“系统语境的过程”和“软件开发的过程”。
（1） 协议过程组
（2） 项目过程组
（3） 技术过程组
（4） 组织上项目使能过程组
（5） 软件实现过程组
（6） 软件支持过程组
（7） 软件复用过程组
第二节 过程描述
1. 过程描述
过程→活动→任务
2. 供应过程
活动1：机遇标识
活动2：供应方投标
任务1：需求评审
任务2：做出有关投标或接受合同的决定
任务3：准备一份提案
活动3：合同协商
任务1：与获取方就提供的软件产品或服务，协商合同条文
任务2：请求对合同的修改，作为变更控制机制的一个成分。
活动4：合同执行
任务1：进行获取需求评审
任务2：定义或选择一个适合项目范围、粒度和复杂性的生存周期模型。
任务3：
……
3. 软件实现过程
活动：软件实现策略
任务1：开发人员选择合适的生存周期模型
任务2：实施人员
任务3：实施人员选择合适的标准、方法、工具和编程语言
任务4：开发进行该过程活动的计划
任务5：对不用交付的软件项的处理。
4. 软件需求分析过程
5. 软件体系结构设计
6. 软件验证过程
7. 软件确认过程
第三节 应用说明
是对标准“ISO/IEC系统与软件工程-软件生存周期过程12207-2008”的应用说明。
1. 系统和软件
软件是整个系统的组成部分。
区分系统需求分析和软件需求分析。
2. 与《ISO/IEC系统生存周期15288》的关系
当系统中包括非常重要的非软件因素时，要应用《ISO/IEC系统生存周期15288》。
3. 组织层和项目层
项目可能由组织执行
4. 过程之间的时序关系
没有明确过程、活动、任务之间的时间依赖的序列。
支持活动之间的迭代和再现。
5. 过程分解
把过程划分为一些小的“片段”
6. 生存周期模型和阶段
7. 剪裁
第四节 软件生存周期模型 ★
1. 瀑布模型
系统需求
软件需求
需求分析
设计
编码
测试
运行
自上而下具有相互衔接的固定顺序。
每一阶段的输入，即工作对象以及本阶段的工作成果，作为输出传送到下一阶段。
瀑布模型的贡献：
（1） 在决定系统怎样做之前存在一个需求阶段，它鼓励对系统做什么有一个规约。
（2） 在系统构造之前有一个设计阶段，它鼓励规划系统结构
（3） 每一阶段都有评审，允许获取方和用户的参与
（4） 前一步作为下一步被认可的、文档化的基线
瀑布模型存在的问题：
（1） 要求客户能够完整、正确和清晰地表达他们的需求，并要求开发人员一开始就理解这一应用。
（2） 由于需求的不确定性，使设计、编码和测试阶段都可能发生延期，并且当项目接近结束时，出现了大量的集成和测试工作。
（3） 在开始的阶段中，很难评估真正的进度状态，并且直到项目结束之前都不能演示系统的功能。
（4） 在一个项目的早期阶段，过分地强调了基线和里程碑处的文档，并可能需要花费更多的时间用于建立一些用处不大的文档。
2. 增量模型
增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。
增量模型适用于“技术驱动”的软件产品开发。
优点：
采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布部分功能给客户，对客户起到镇静剂的作用。此外，增量能够有计划地管理技术风险。
缺点：
增量模型存在以下缺陷：
1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
3. 演化模型
演化模型是一种全局的软件（或产品）生存周期模型。属于迭代开发方法。
该模型可以表示为：第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->……
即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。
演化模型主要针对事先不能完整定义需求的软件开发。用户可以给出待开发系统的核心需求，并且当看到核心需求实现后，能够有效地提出反馈，以支持系统的最终设计和实现。软件开发人员根据用户的需求，首先开发核心系统。当该核心系统投入运行后，用户试用之，完成他们的工作，并提出精化系统、增强系统能力的需求。软件开发人员根据用户的反馈，实施开发的迭代过程。第一迭代过程均由需求、设计、编码、测试、集成等阶段组成，为整个系统增加一个可定义的、可管理的子集。 在开发模式上采取分批循环开发的办法，每循环开发一部分的功能，它们成为这个产品的原型的新增功能。于是，设计就不断地演化出新的系统。 实际上，这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组，以便分批循环开发。这种分组并不是绝对随意性的，而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。有经验指出，每个开发循环以六周到八周为适当的长度。
演化模型的优点：
（1）任何功能一经开发就能进入测试以便验证是否符合产品需求。
（2）帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而作出修改。
（3）风险管理可以在早期就获得项目进程数据，可据此对后续的开发循环作出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。
（4）大大有助于早期建立产品开发的配置管理，产品构建（build ），自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。
（5）开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。
（6）如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。
（7）心理上，开发人员早日见到产品的雏型，是一种鼓舞。
（8）使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。
（9）可使销售工作有可能提前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
演化模型的缺点：
（1）如果所有的产品需求在一开始并不完全弄清楚的话，会给总体设计带来困难及削弱产品设计的完整性，并因而影响产品性能的优化及产品的可维护性。
（2）如果缺乏严格的过程管理的话，这个生命周期模型很可能退化为一种原始的无计划的“试－错－改”模式。
（3）心理上，可能产生一种影响尽最大努力的想法，认为虽然不能完成全部功能，但还是造出了一个有部分功能的产品。
（4）如果不加控制地让用户接触开发中尚未测试稳定的功能，可能对开发人员及用户都产生负面的影响。
4. 螺旋模型
螺旋模型（Spiral Model）采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。使用它，项目经理在早期就能够为客户实证某些概念。该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如下图所示:：
软件过程
螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。
图7- 螺旋模型
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。在实践中，螺旋法技术和流程变得更为简单。迭代方法体系更倾向于按照开发/设计人员的方式工作，而不是项目经理的方式。螺旋模型中存在众多变量，并且在将来会有更大幅度的增长，该方法体系正良好运作着。
5. 喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。
图7- 喷泉模型
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
第五节 过程规划与管理
过程规划（P）
过程检测（C）
过程执行（D）
过程调整（A）
1. 过程建立
（1） 选择软件生存周期模型
（2） 细化所选择的生存周期模型
（3） 为每一个活动或任务标识合适的实例数目
（4） 确定活动的时序关系，并检查信息流
成果：项目的过程计划
2. 过程监控
（1） 过程的监控
（2） 过程改变所产生的影响的评估
（3） 改变的实施
（4） 实现改变
第八章 集成化能力成熟度模型（CMMI）
复习建议：
软件过程的改善问题。
本章内容围绕CMMI的构成和等级，介绍能力等级和成熟度等级，主要以概念和原理为主，考核题型为单项选择题和填空题，分值在5%左右。
第一节 背景和原理
1. CMMI的含义
全称是Capability Maturity Model Integration， 即软件能力成熟度模型集成，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。
2. CMMI主要关注点
成本效益、明确重点、过程集中和灵活性四个方面。
CMMI核心理念：过程管理
3. CMMI核心理念：过程管理
CMMI是一套融合多学科的、可扩充的产品集合， 其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。 CMMI的本质是软件管理工程的一个部分。软件过程改善是当前软件管理工程的核心问题， 50多年来计算机的发展使人们认识到要高效率、高质量和低成本地开发软件，必须改善软件生产过程。基於模型的过程改进是指用采用能力模型来指导组织的过程改进，使之过程能力稳定的进行改善，该组织也能变得更加成熟。
CMM的成功促使其他学科也相继开发类似的过程改进模型，例如系统工程、需求工程、人力资源、集成产品开发、软件采购等等，从CMM衍生出了一些改善模型，比如：SW－CMM，SE-CMM、IPD-CMM等。不过，在同一个组织中多个过程改进模型的存在可能会引起冲突和混淆。CMMI就是为了解决怎麼保持这些模式之间的协调。
4. CMMI的构成
（1） 软件能力成熟模型（SW－CMM）
（2） 软件工程能力模型SECM
（3） 集成产品开发能力成熟度模型IPD-CMM
第二节 CMMI的模型部件
每一个CMMI模型都有的基本模块叫做“过程域”。一个过程域并不对如何执行一个有效的过程（例如进入标准和离开标准、参加者任务、资源）做出描述，而是要对那些使用了有效过程的人做了什么（实践）以及他们为什么做这些事（目标）做出描述。
CMMI是一种过程改善框架。
1. 过程改善（Process Improvement）
是指人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果。
2. CMMI的模型部件
（1） 由一些过程域组成，过程域有自己的确定专用目标和公共目标。
（2） 每个专用目标和公共目标的实现，分别依赖一些实践。
（3） 每个专用实践有自己的子实践和确定的典型工作产品，符号： ，资料性部件。
（4） 每个过程域还有意图陈述、简介性注释以及相关过程域。
3. 过程域
一个业务域中一束相关的实践，当它们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件。
CMMI有22个过程域，分为四类。
| 过程域类名 | 包括的过程域 |
| 项目管理类 | 规划、监控、定量项目管理、集成项目管理、风险管理、提供方协议管理 |
| 工程类 | 需求开发、需求管理、技术解决方案、产品集成、确认、验证 |
| 支持类 | 配置管理、过程和产品质量保证、测量与分析、原因分析与解决、决策分析与解决 |
| 过程管理类 | 组织过程定义、组织过程性能、组织过程培训、组织过程关注、组织创新与部署 |
（1） 意图陈述
（2） 简介性注释
（3）相关过程域
4. 专用目标与专用实践
描述该过程域必须呈现的一些独有特征。
5. 共用目标与共用实践
可用于多个过程。
6. 典型工作产品
7. 子实践
第三节 CMMI的等级
能力等级和成熟度等级。
1. 过程能力
遵循一个过程可达到的预期结果的程度。
表征组织对一个过程域的改善，是不断改善一个给定的过程域的一种手段。
2. 能力等级
能力等级包含一个共性目标及其相关的共性实践，它们与一个过程域相关联，能够改进组织同那个过程域相关联的过程。
能力等级0： 未完成级。过程不完整 – 一个过程或者没有得到执行或者只是得到部分执行。过程域的一个或者多个特定目标没有被实现，而且该等级不存在共性目标，因为没有理由将一个仅仅是部分完成的过程制度化。
能力等级1：已执行的过程 – 实现了过程域的特定目标。它支持产生输出成果所需的工作。
能力等级 2： 已管理的过程 – 一个能够支持该过程的基础设施已经到位的已执行（能力等级1）的过程。它的计划和执行按照政策来进行；雇佣了拥有充足资源以生成受控的输出的有熟练技能的人；相关的利益相关者参与了进来；它受到了监控和检查；还要接受有没有遵守过程描述的评价。能力等级2所表现出的工艺有助于确保现有的实践在困难时期仍能够保持。
能力等级3： 已定义过程 – 按照组织的裁减指南从组织的标准过程中裁减出来的一个已管理（能力等级 2）过程，它向组织的过程资产提供工作成果、量度和其他的过程改进信息。
能力等级4： 量化管理过程 – 使用统计和其他定量技巧控制的一个已定义（能力等级 3）过程。质量和过程绩效的量化目标得以设立并被当作管理过程的标准。质量和过程绩效在统计意义上得到理解，并在过程的生命周期中受到管理。
能力等级5： 持续优化过程 – 经过改进的一个量化管理过程，这种改进的基础是对过程内在的共性变异原因的理解。持续优化过程的中心在于通过渐进式的和创新式的改进持续地改进过程绩效的范围。
【例题▪填空题】能力等级的含义是通过达到专用目标和公共目标及其相关的＿＿＿来反映的。
【答案】实践
3. 组织成熟度等级
成熟度等级是一个经过定义的渐进的过程改进集合。每个成熟度等级都巩固了组织在计划、执行以及成功地完成项目方面的一些重要能力。
CMMI的阶段式表示模型定义了5个成熟度等级，在持续的过程改进上，每一等级都是构成下一阶段基础的一个层次，这些等级用从1到5的数字表示。
（1） 成熟度等级1：初始级
过程是混乱的，应付式的。组织没有提供一个稳定的环境来支持过程。成功由组织中个人的能力和拼搏精神决定，而不是建立在经过检验的过程之上。尽管过程是这样的混乱，在成熟度等级1中的组织仍可能生产出可用的产品和服务；但是，他们经常会超出预算并且无法按期完成。
（2） 成熟度等级2：已管理
组织的项目已能确保过程按照预定方针得到计划和执行；项目雇佣了掌握着足够资源来产生受控输出的技能熟练的员工；相关的利益相关者参与了进来；受到了监控和检查；而且还被评价是否符合它们的过程描述。
（3） 成熟度等级3: 已定义
过程得到了很好地描述和理解，并应用标准、规程、工具及方法来表现。作为成熟度等级3基础的组织标准过程集已经被建立并且不断被改进。这些标准过程被用来在组织范围内建立一致性。项目通过按照剪裁指南剪裁组织的标准过程集来建立他们的已定义过程。
（4） 成熟度等级4: 量化管理
组织和项目为质量和过程绩效建立了量化目标并将其用作管理过程的标准。量化目标以顾客、最终用户、组织和过程实施者的需要为基础。质量和过程绩效在统计意义上得到理解，并在过程的生命周期中受到管理。
（5） 成熟度等级5: 持续优化
重点关注通过渐进性和革新性过程改进和技术改进来持续地改进过程的绩效。组织的量化过程改进目标已获建立，并被不断地修订以反映企业目标的改变，该目标还被用作管理过程改进的标准。人们按照量化过程改进目标量度和评价已部署的过程改进的效果。已定义过程和组织的标准过程集都是可量度的改进活动的对象。
成熟度等级包含的过程域
| 成熟度等级 | 过程域 | 类属 |
| 2 | 配置管理 测量与分析 项目监控 项目规划 过程和产品质量保证 需求管理 提供方协议管理 | 同学们把所属类别填上 |
| 3 | 决策分析与解决 集成项目管理 组织过程定义 组织过程关注 …… | |
| 4 | 组织过程性能 定量项目管理 | 过程管理类 项目管理类 |
| 5 | 原因分析与解决 组织创新与部署 | 支持类 过程管理类 |
第四节 过程域举例
两个过程域：项目规划（2级）和需求开发过程（3级）。
1. 项目规划-意图
建立并维护项目活动计划的定义。
项目计划和项目规划的区别。
2. 项目规划-专用目标和专用实践
3个专用目标：
（1） SG1：建立估算
（2） SG2：开发项目计划
（3） SG3：获得对该计划的承诺
14个专用实践：
（1） SP1.1 估算项目规模
（2） SP1.2 建立工作产品和任务属性的估算
（3） SP1.3 定义项目生存期
（4） SP1.4 确定工作量和成本的估算
（5） SP2.1 建立预算和进度
（6） SP2.2 标识项目风险
（7） SP2.3 规划数据管理
（8） SP2.4 规划项目资源
（9） SP2.5 规划需要的知识和技能
（10）SP2.6 规划利益攸关方的参与
（11）SP2.7 建立项目计划
（12）SP3.1 评审该项目的计划
（13）SP3.2 调和工作和资源等级，使之一致
（14）SP3.3 获得计划承诺
3. SP1.1 估算项目规模
WBS工作分解结构。
把一个大型项目划分为一些活动和产品。
4. 项目规划-共用目标和共用实践
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：高层管理视角评审状态
5. 需求开发-意图
生成并分析客户需求、产品需求和产品部件需求。
6. 需求开发-专用目标和专用实践
SG1：开发客户需求
SP1.1：引出要求
SP1.2：开发客户需求
SG2：开发产品需求
SP2.1：建立产品和产品构件的需求
SP2.2：分配产品构件需求
SP2.3：标识接口需求
SG3：分析并验证需求
SP3.1：建立操作概念和场景
SP3.2：建立所需功能的定义
SP3.3：分析需求
SP3.4：分析需求，以达到权衡
SP3.5：确认需求
7. 需求开发-共用目标和共用实践
开发过程域必须达到共用目标3。
GG3把过程制度化为一个已定义过程。
GP3.1：建立一个已定义过程
GP2.1：建立组织策略
GP2.2：规划过程
GP2.3：提供资源
GP2.4：指派责任
GP2.5：培训人员
GP2.6：管理配置
GP2.7：标识相关利益方的参与
GP2.8：监控过程
GP2.9：客观地评估符合性
GP2.10：以高层管理视角评审状态
GP3.2：收集改进信息
结尾
以上为本次串讲的内容，如果同学们在听课过程中有不清楚的问题，可以登录华夏大地教育的答疑室，进行提问交流，以便更好的掌握课程内容。
祝同学们考试顺利通过。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
