华中科技大学软件学院
THE SCHOOL OF SOFTWARE
ENGINEERING OF HUST
第 3 章 软件开发过程管理
2
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
3
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
软件过程
是指人们用于开发和维护软件及其相关产品的一系列活动、方
法、实践和革新。
软件开发过程管理
是指在软件开发过程中，除了先进技术和开发方法外，还有一
整套的管理技术。
软件过程改进
是针对软件生产过程中会对产品质量产生影响的问题而进行的，
它的直接结果是软件过程能力的提高。
现在常见的软件过程改进方法：ISO 9000，SW-CMM和由多
种能力模型演变而来的CMMI。
CMM和ISO9000
4
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
SW-CMM和CMMI
SW-CMM简介
为了保证软件产品的质量，1991年美国卡内基·梅隆大学软
件工程研究所（CMU/SEI）将软件过程成熟度框架进化为软件能
力成熟度模型（Capability Maturity Model For Software，简
称SW-CMM），并发布了最早的SW-CMM 版。
SW-CMM为软件企业的过程能力提供了一个阶梯式的进化框架，
阶梯共有五级。
5
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
SW-CMM和CMMI
1 初始级 2 可重复级
3 已定义级
4 已管理级5 优化级
无序、混乱的
软件过程。依
赖个别人的努
力和机遇。
建立基本的项
目管理过程。
相似项目，重
复以往成果。
文档化、标准
化和标准的软
件软件过程。
软件过程和产
品质量有详细
的度量标准。
持续的对过程
进行改进。
图 CMM分级标准
6
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
SW-CMM和CMMI
KPA及KP
除第一级外，SW-CMM的每一级都是按完全相同的结构组成
的。每一级包含了实现这一级目标的若干关键过程域（KPA），每
个KPA进一步包含若干关键实施活动（KP），无论哪个KPA，它
们的实施活动都统一按六个公共属性进行组织，即每一个KPA都包
含六类KP：
1. 目标
2. 实施保证
3. 实施能力
4. 执行活动
5. 度量分析
6. 实施验证
7
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
SW-CMM和CMMI
CMMI简介
由于不同领域能力成熟度模型存在不同的过程改进，重复的
培训、评估和改进活动以及活动不协调等一些问题。于是由美国
国防部出面，美国卡内基·梅隆大学软件工程研究所
（CMU/SEI）于2001年12月发布的CMMI 版本包括四个领域：
软件工程（SW）、系统工程（SE）、集成的产品和过程开发
（IPPD）、采购（SS）。
8
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
SW-CMM和CMMI
CMMI有两种不同的实施方法
连续式－－主要是衡量一个企业的项目能力
阶段式－－主要是衡量一个企业的成熟度
连续式与阶段式所包含的过程域是完全一致的。
两者的区别主要在于过程域的组织方式不同，
阶段式是用来描述组织整体上的成熟度，
而连续式关注的是组织单个过程域的能力。
如果组织注意力主要集中在某几个过程域上时，
则采用连续式比较合适
9
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
CMMI的五个台阶
完成级
管理级
定义级
量化管理级
优化级
每一个台阶都是上面一阶台阶的基石。要上高层台
阶必须首先踏上较低一层台阶。
10
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
与SW-CMM 的结构相比， CMMI 的模型结构显得更
加复杂与精细。 CMMI 从过程域所有的实践提炼出了
多个过程域所共有的实践，称为一般实践，将其目标
称为一般目标，其余特定于某个过程域的实践与目标
称为特定实践与特定目标。这样模型取得了相对
SW-CMM 更高的抽象度与适应范围。
目标（一般目标与特定目标）首次作为模型构成成分
出现，这表明CMMI 对过程活动的结果投入了更多的
关注。
11
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
ISO9000质量标准
ISO9000
所谓“ISO9000”不是指一般意义上的一个质量保证标准，而是
一族系列标准的统称。
作用
─ 强化品质管理，提高企业效益；增强客户信心，扩大市场份
额；
─ 获得了国际贸易“通行证”，消除了国际贸易壁垒；
─ 节省了第二方审核的精力和费用；
─ 在产品品质竞争中永远立于不败之地；
─ 有效地避免产品责任；
─ 有利于国际间的经济合作和技术交流。
12
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
三者之间的比较
选择SW-CMM还是CMMI的考虑
─实施企业的业务特点。
实施企业的业务特点： 如果企业的规模不是很大，业务又集中在
软件开发为主，那么还是软件CMM比较适用。如果企业的规模
比较大（开发人员100人以上），并且业务不仅仅集中在软件开发，
还包括硬件开发哪怕是硬件代理（采购）都可以考虑实施CMMI
。
13
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
实施企业对过程改进的熟悉程度： 如果企业已经实
施过ISO 9000，并且取得了较好的效果，那么可以考
虑实施CMMI。如果企业虽然没有实施过CMM，但是
对于过程改进一直比较关注，接受过不少相关培训，
甚至能够自发的进行一些过程改进，那么也可以考虑
实施CMMI。如果过去没有接触过类似的工作，那么
最好先从软件CMM 2级开始，首先建立持续过程改进
的思路。另外，软件CMM的要求也比CMMI要稍低一
些。可以适当降低实施的难度
14
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
─实施企业对过程改进的熟悉程度。
实施企业对过程改进的熟悉程度： 如果企业已经实施过ISO 9000，并且
取得了较好的效果，那么可以考虑实施CMMI。如果企业虽然没有实施
过CMM，但是对于过程改进一直比较关注，接受过不少相关培训，甚
至能够自发的进行一些过程改进，那么也可以考虑实施CMMI。如果过
去没有接触过类似的工作，那么最好先从软件CMM 2级开始，首先建
立持续过程改进的思路。另外，软件CMM的要求也比CMMI要稍低一
些。可以适当降低实施的难度
15
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
─实施企业对过程改进项目的预算。
实施企业对过程改进项目的预算： 不论怎样，几乎可以肯定地说，实施
CMMI的费用肯定要比实施CMM高出一些。而就模型本身来看，CMMI
的2级7个过程区域在内容上并不比软件CMM的2级6个关键过程区域多
多少。这样的话，我们完全可以“少花钱、多办事”，也就是说可以
采用CMM的实施和评估方法，但可以在过程改进的时候参考CMMI的
要求，这样就经济很多。
16
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
----实施企业是否可以使用阶段式的演进路线
： 如果企业只希望单方面的提高自己在项目管理、
工程活动、支持活动或者过程管理四个方面中的某些
方面的能力，那么就只能应用CMMI的连续表示方法。
如果实施企业可以接受成熟度级别的思路（目前看国
内大多数企业还是比较习惯于成熟度级别的），那么
就不一定必须选择CMMI了。
17
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
----------实施CMM与CMMI可以平滑的转换。
CMMI并不要求一家企业必须先做CMMI的2级然后再
向更高的成熟级别演进，评估的时候也没有这样的要
求。
另外， CMMI的评估都会根据被评估的成熟度级别，
检查所有不高于该级别的过程区域。换句话说，一个
企业在CMM正式评估中达到了2级的成熟度，将来改
为基于CMMI进行过程改进。在CMMI 3级的正式评估
时，CMMI 2级的内容同样要进行检查。如果我们能
够在做CMM 2级的时候就按照CMMI的要求实施，效
果没有任何的折扣，但对于实施企业来说，会节省很
多在培训和评估方面的“额外”费用。（此处的“额外”
费用是指CMMI收费比CMM高出的部分）
18
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
ISO9001与CMM的关系
─ISO9001和CMM既有区别又相互联系，两者不可简单地互相替 代。
─取得ISO9001认证并不意味着完全满足CMM某个等级的要求。
─取得CMM第2级(或第3级)不能笼统地认为可以满足ISO9001的要求。
19
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
案例1
W公司为了推行CMM，组建了独立的QA部门。尽管
在W公司的内部宣传材料上对QA的作用进行了大肆
的宣传，认为其对于CMM的推行和项目管理都具有
重要作用，但是实际上QA人员的资历都相对较浅，
对开发过程，技术和工具都缺乏必要的了解。只能够
照搬一些条文来要求开发人员，开发人员对此并不认
账，认为QA人员是没事找事。另外，QA这个岗位在
薪酬和升迁方面毫不吸引人
20
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
为了避免QA部门成为新手和项目组淘汰人员的集中
地，QA部门经理设法推行项目经理锻炼制度，让项
目经理到QA部门锻炼一段时间，然后继续担任项目
经理或者升迁。但是因为此项制度没有得到有效的支
持，项目经理在QA部门工作一段时间以后竟然没有
开发部门愿意接收，就更谈不上升迁了。QA部门在
W公司的威望江河日下。
21
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
QA人员对于质量保证和CMM的实施至关重要，如果
我们认可QA人员对于公司的价值，那就必须在人才
和待遇上向QA部门倾斜
22
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
H公司和Z公司都在研发相同类型的C产品。H公司在
推广CMM，采用了相对严格的过程规范，并且把相
对重要的部分外包给了印度的CMM5级公司。这些手
段Z公司都没有采用，但是Z公司却抢在了前面。
Z公司的“秘密武器”是一种形式化语言—SDL，Z公司
采用SDL作为设计工具，这样C产品的相当一部分代
码可以由SDL工具自动生成，而且在设计阶段就可以
进行仿真运行，这样就大大地提高了效率并减少了缺
陷。H公司虽然采用了相对严格的过程规范，但是因
为全部代码为手工编制，所以，无论是效率还是质量，
H公司都落后了
23
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
H公司显然忽视了先进技术可能为生产率带来的进步，
通过了CMM高级别的评估，只能说明被评估的组织
机构在过程控制上做得更加细致，但是并不能够保证
你的开发过程是高效的。某些沉迷于CMM的组织机
构忘记了先进的软件工程技术的重要性
24
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
25
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
软件生命周期
软件从需求确定、设计、开发、测试直至投入使用，并在使用中不
断地修改、增补和完善，直至被新的系统所替代而停止该软件的使用的
全过程。
可划分为以下子阶段
1.可行性研究
2.需求分析和定义
3.总体设计
4.详细设计
5.编码（实现）
6.软件测试、运行/维护
据此相继产生了瀑布模型、螺旋模型、进化模型、原型模型、增量
模型等。本节分别对这几种传统的软件开发生命周期模型予以介绍。
传统软件开发生命周期模型
26
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
瀑布模型
系统需求
软件需求
分析
设计
编码
测试
运行
瀑布模型总结
文档驱动的模型
阶段间具有顺序性和依
赖性
项目开发周期较长
实际项目很少按照该模
型给出的顺序进行
27
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
瀑布模型是最早出现的软件开发模型，在软件工程中
占有重要的地位，它提供了软件开发的基本框架。瀑
布模型的本质是一次通过，即每个活动只执行一次，
最后得到软件产品，也称为“线性顺序模型”或者“
传统生命周期”。其过程是从上一项活动接收该项活
动的工作对象作为输入，利用这一输入实施该项活动
应完成的内容给出该项活动的工作成果。
并作为输出传给下一项活动。同时评审该项活动的实
施，若确认，则继续下一项活动；否则返回前面，甚
至更前面的活动。瀑布模型有利于大型软件开发过程
中人员的组织及管理，
28
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
瀑布模型的优点：
（1）它提供了一个模版，这个模板使得分析，设计，
编码，测试和支持的方法可以在该模板下有一个共同
的指导标准。（2）虽然有不少缺陷但比在软件开发
中随意的状态要好的多。
29
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
缺点：
大部分情况下，实际的项目难以按照该模型给出的顺
序进行，而且这种模型的迭代是间接的，这很容易由
微小的变化而造成大的混乱。
顾客的需求难以表达真正的额外需要。
客户要等到开发周期的晚期才能看到程序运行的测试
版本，如果发生错误，有可能是灾难的。
采用这种线性模型，会经常在过程的开始和结束时碰
到等待其他成员完成其所依赖的任务才能进行下去。
30
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
原型模型
31
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
原型模型
Prototyping model特点
在需求定义之前，需要快速构建一个系统
根据构建系统的优缺点，用户给开发人员提出反馈意
见
根据反馈意见修改软件需求规格，以便系统可以更正
确地反映用户的需求
减少各种假设以及风险
32
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
33
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
原型的分类
① 废弃型：先构造一个功能简单而且质量要求不高
的模型系统，针对这个模型系统反复进行分析修改，
形成比较好的设计思想，据此设计出更加完整、准确、
一致、可靠的最终系统。系统构造完成后，原来的模
型系统就被废弃不用。
② 追加型或演化型：先构造一个功能简单而且质量要
求不高的模型系统，作为最终系统的核心，然后通过
不断地扩充修改，逐步追加新要求，最后发展成为最
终系统。
34
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
增量模型
当使用增量模型时，第1个增量往往是核心的产品，
即第1个增量实现了基本的需求，但很多补充的特
征还没有发布。客户对每一个增量的使用和评估
都作为下一个增量发布的新特征和功能，这个过
程在每一个增量发布后不断重复，直到产生了最
终的完善产品。增量模型强调每一个增量均发布
一个可操作的产品。采用增量模型的软件过程如
下图所示：
35
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
增量模型
图 增量模型
36
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
所示的增量模型表明，必须在开始实现各个构件之前就全部完成
需求分析、规格说明和概要设计的工作。由于在开始构建第一个
构件之前已经有了总体设计，因此风险较小
37
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
图 风险更大的增量模型
增量模型
38
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着
手拟定第一个构件的规格说明文档，完成后规格说明组将转向第
二个构件的规格说明，与此同时设计组开始设计第一个构件……
用这种方式开发软件，不同的构件将并行地构建，因此有可能加
快工程进度。但是，使用这种方法将冒构件无法集成到一起的风
险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。
39
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
渐增模型与快速原型 的相同之处是其迭代的特征，不同之处是渐增模型的每
一轮都得到一个用户可真正使用和操作的完整版本，而快速原型每一轮得到
的是在性能和功能上大大简化的版本。
优点:(1)渐增模型 对项目组的组成人员不是非常充裕的情况下十分有用。早期
对基本系统的开发需要的人员比较少，后续的各轮开发可以根据需要补充人
员。此外，这种增量式的开发，可以有效地防止技术风险。
(2)渐增模型每一轮都可以向用户发布一个高质量的可操作的版本。用户容
易接受并可以提出中肯的意见，不需要非常大的原始资金投入。
缺点：由于要求下一轮新增的功能能够无缝集成到上一轮系统中去，如果整
体结构设计不当，则有可能导致整个软件的结构变差。
增量模型
实例三
• 基于工作流的科技项目管理系统
项目信息发布 项目信息分类 项目信息集成
项目协同工作 项目过程支持 个性化设置
项目管理信息数据服务 项目监控与评价数据
服务
应用系统
集成服务 通讯服务 统一编码体系
项目组织管理 项目过程控制 项目数据分析
项目流程管理 项目知识管理 生命周期管理
工作流定义 消息组件 权限与安全 工作流 平台
动态工作流引擎 协同工作引擎 资源管理
29
40
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
优点
1) 由于能够在较短的时间内向用户提交一些有用的工
作产品，因此能够解决用户的一些急用功能。
2）由于每次只提交用户部分功能，用户有较充分的
时间学习和适应新的产品。
3）对系统的可维护性是一个极大的提高，因为整个
系统是由一个个构件集成在一起的，当需求变更时只
变更部分部件，而不必影响整个系统。
缺点
41
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
增量模型存在以下缺陷：
1） 由于各个构件是逐渐并入已有的软件体系结构中
的，所以加入构件必须不破坏已构造好的系统部分，
这需要软件具备开放式的体系结构。
2） 在开发过程中，需求的变化是不可避免的。增量
模型的灵活性可以使其适应这种变化的能力大大优于
瀑布模型和快速原型模型，但也很容易退化为边做边
改模型，从而使软件过程的控制失去整体性。
3）如果增量包之间存在相交的情况且未很好处理，
则必须做全盘系统分析，这种模型将功能细化后分别
开发的方法较适应于需求经常改变的软件开发过程。
42
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
增量模型
增量模型总结
融合了瀑布模型和原型的迭代特征。
每一个增量均发布一个可操作产品。
43
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
进化模型
建造/修改
原型
听取用户
意见
用户测试
运行原型
这个模型
可看作是重复执
行的多个瀑布模
型。
44
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
螺旋模型
原型1 原型2 原型3
可运行
原型
需求计划
生存期
计划
开
发
计 划
集
成
与
测
试
软件
需求
需求
确认
设计确认
与验证
软件
产品
设计
详细设计
风 险
分
析
风 险
分
析
风
险
分
析
验收
测试实现
集成
与
测试
单元
测试
编码
开发、验证
下一产品
实施工程
提交线
评审
累计
成本
风险分析
评价方案，识别
风险、消除风险
制订计划
决定目标
方案和限制
客户评估
45
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
构建原型是一种能使某些类型的风险降至最低的方法。为
了降低交付给用户的产品不能满足用户需要的风险，一种行之
有效的方法是在需求分析阶段快速地构建一个原型。在后续的
阶段中也可以通过构造适当的原型来降低某些技术风险。当然，
原型并不能“包治百病”，对于某些类型的风险，原型方法是
无能为力的。
螺旋模型的基本思想:使用原型及其他方法来尽量降低风
险。理解这种模型的一个简便方法，是把它看作在每个阶段之
前都增加了风险分析过程的快速原型模型。完整的螺旋模型如
图。
螺旋模型
46
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
图：简化的螺旋
模型
47
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
优点：对可选方案和约束条件的强调有利于已有软件的
重用，也有助于把软件质量作为软件开发的一个重要目标；
减少了过多测试（浪费资金）或测试不足（产品故障多）所
带来的风险；更重要的是，在螺旋模型中维护只是模型的另
一个周期，在维护和开发之间并没有本质区别。
主要优势:它是风险驱动的，但这也可能是其弱点。除非
软件开发人员具有丰富的风险评估经验和这方面的专门知识，
否则将出现真正的风险。当项目实际上正在走向灾难时，开
发人员可能还认为一切正常。
48
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
螺旋模型主要适用于内部开发的大规模软件项目。如果
进行风险分析的费用接近整个项目的经费预算，则风险分析
是不可行的。事实上，项目越大，风险也越大，因此，进行
风险分析的必要性也越大。此外，只有内部开发的项目，才
能在风险过大时方便地中止项目。
49
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
螺旋模型
螺旋模型总结
基于风险驱动的开发模型, 使用原型法或其它方法来
尽量降低风险。
适用于需求不明确的大规模软件项目
50
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
51
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
极限模型
极限模型简介
2001年，为了避免许多公司的软件团队陷入不断增长的过程
泥潭，一批业界专家一起概括出了一些敏捷开发过程的方法：
SCRUM，Crystal，特征驱动软件开发（Feature Driven
Development，简称FDD），自适应软件开发（Adaptive Software
Development，简称ASD），以及最重要的极限编程（eXtreme
Programming,简称XP）。
52
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
极限模型
极限编程将
开发阶段的4
个活动（分
析、设计、
编码和测试）
混合在一起，
在全过程中
采用迭代增
量开发、反
馈修正和反
复测试。
53
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
探索阶段
探索阶段的主要工作是开发初始的用户故事（User
Stories ）和体系结构骨架（architecture spike）。
用户故事描述了系统高层的需求，它是制订发布计
划的输入。
在探索阶段，试探找到系统中固定不变的部分（体
系结构骨架），并找出一种形象的比喻，这种比喻
描述了你打算如何构建系统，起到概念框架的作用。
探索阶段还应根据用户故事编制相应的测试用例，
供以后验收测试时使用。
54
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
计划阶段
计划阶段的任务是根据用户故事描述的需求、系统
体系结构骨架和系统比喻来制订迭代计划和发布计
划。
使用你最熟悉的形式为用户故事建模，这个模型描
述了用户故事的任务以及这些任务之间的关系。
通常图形方式（可以是草图）比文字描述更直观。
尽可能精确地估算工作量，这是制订计划的重要依
据。对于那些不能确切估算其工作量的难点部分，
要进一步作分析，直至能确定其工作量估算。
55
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
迭代到发布阶段
迭代到发布阶段根据迭代和发布计划，开发满足指
定用户故事需求的软件，并与前面已完成的软件版
本集成，得到软件的一个新版本。
根据在探索阶段编写的测试用例，进行验收测试。
一旦发现错误或者通过验收测试想进入下一轮迭代
时，就重复迭代开发的工作。
在这一阶段当客户提出新的用户故事，或者根据项
目的进展情况认为有必要时，可以回到计划阶段，
对迭代和发布计划做出修改或调整。
56
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
产品化阶段
产品化阶段的工作主要是确认迭代开发的软件已经
做好进入产品化的准备。
在此阶段可进行更多的测试，如系统测试、负载测
试、安装测试等。
另一个工作就是整理文档。虽然敏捷软件开发的价
值观中强调“可运行软件高于详尽的文档”，但是，
必要的文档仍是需要的。
57
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
可能要写的文档：
系统文档
系统文档的目的在于为系统提供一个总览，来帮助人
们理解它。主要包括：系统技术体系结构和业务体系
结构的总览、高层次的系统需求、关键设计决策的总
结、体系结构图以及重要的设计模型（如果有的话）
等。
操作文档
操作文档的内容包括：系统涉及的依赖关系，与其他
系统、数据库以及文件文互的特性，对备份流程的参
考引用，系统的联系人列表以及联系方法，系统的适
用性及可靠性需求的总结，系统预期负载情况概况，
以及排错指导原则。
58
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
支持文档
支持文档的内容包括：支持人员专用的培训教材，解
决问题时作为参考的用户文档，排错指导原则，解决
疑难问题时的上报流程，以及维护团队的联系列表。
用户文档
参考手册用于快速查询；用户指南用于指明系统的工
作方式；支持指南用于指导如何获取其他的帮助；培
训资料则主要用于培训。
59
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
维护阶段
维护阶段涵盖了计划阶段、迭代到发布阶段和产品
化阶段
通常这个阶段主要包括面向产品的活动，如系统的
运行和支持。
60
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
极限模型
XP开发模型核心思想：
交流（Communication）
简单（Simplicity ）
反馈（Feedback）
进取（Aggressiveness）
61
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
• 交流（Communication）
实践表明，项目失败的重要原因之一是交流不畅，
使得客户的需求不能准确地传递给开发人员，造成
开发人员不能充分理解需求；模型或设计的变动未
能及时告知相关人员，造成系统的不一致和集成的
困难
所有项目相关人员之间充分的有效的交流是软件开发
成功所必不可少的
XP方法提倡面对面的交流，这是一种有效的也是效率
最高的交流方式
62
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
• 简单（Simplicity）
指在确保得到客户满意的软件的前提下，做
最简洁的工作（简单的过程、模型、文档、
设计和实现）
在开发中不断优化设计，时刻保持代码简洁、
无冗余
体现了敏捷开发的“刚刚好(Just enough)”
思想，即开发中的活动及制品既不要太多也
不要太少，刚好即可
63
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
• 反馈（Feedback）
及时有效的反馈能确定开发工作是否正确，及时
发现开发工作的偏差并加以纠正。
强调各种形式的反馈，如非正式的评审（走查，
Walkthrough）、小发布等
64
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
• 进取
信任合作的同事，也相信自己
做能做到的最简单的事
只有在绝对需要的时候才创建文档
让业务人员制定业务决策，技术人员制定技术决策
用可能的最简单的工具，例如白板和纸，只有在复杂建模工具能提
供可能的最好价值时才去使用它们
相信程序员能制定设计决策，不需要给他们提供过多的细节
需要勇气来承认自己是会犯错误的，需要勇气来相信自己明天能克
服明天出现的问题。
65
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
XP方法的12个核心实践
1.完整的团队（Whole Team）
所有的小组成员应在同一个工作地点工作
成员中必须有一个现场用户（On-site User）由他
提出需求，确定开发优先级
通常还设一个“教练”（Coach）角色
教练指导XP方法的实施，以及与外部的沟通和协调
2.计划对策（Planning Game）
包括两类：发布计划和迭代（Iteration）计划
66
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
3. 系统比喻 （Metaphor）
系统比喻是待开发软件的一个每个成员都熟悉的形象化比
喻，相当于一个粗略的软件体系结构
4. 小发布（Small release）
经常、不断地发布可运行的、具有商业价值的小软件版本，
供现场用户评估或最终使用
5. 测试（testing）
XP方法提倡测试优先，即先写测试后编代码（testing then
coding）
6. 简单设计（Simple Design）
设计只考虑当前定义的功能而不考虑以后需求的变化
该设计是完成目前功能所需的最简洁的设计
67
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
7. 结对编程（Pair Programming）
一个程序员编程的同时，另一个程序员负责检查程序的正
确性和可读性
结对的伙伴可以动态调整
8. 设计改进（Design Improvement）
在不影响程序的外部可见行为的情况下，按高内聚低耦合
的原则对程序结构进行改进，保持代码简洁、无冗余
9. 持续集成（Continuous Integration）
10. 每完成一个模块的开发（包括该模块的单元测试）后，
立即将其组装到系统中，并进行集成测试，完成该集成测
试后才能进行下一次集成
68
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
10. 代码全体共享（Collective code Ownership）
团队中的任何人可以在任何时候修改系统任何位置上的
任何代码
团队的成员都可以参加模型的开发，又有系统比喻、结
对编程、编码标准、持续集成等实践，这些都为代码全
体共有提供了支持
11. 编码标准（Coding Standard）
12. XP方法强调制订一个统一的编码标准，包括命名、
注释、格式等编程风格
12. 可持续步调（Sustainable Pace）
每周40小时工作制
69
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
极限模型
优点
1) 采用简单计划策略，不需
要长期计划和复杂模型，
开发周期短；
2) 在全过程采用迭代增量开
发、反馈修正和反复测试
的方法，能够适应用户经
常变化的需求。
缺点
1) 目前主要在小规模项目上
应用并取得成功，但是否
适用于中等规模或大规模
软件产品，需慎重考虑；
2) 由于这个模型较新产品交
付后维护成本是否降低，
不能确定；
3) 对编码人员的经验要求高
70
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Rational统一过程
最佳实践
RUP充分体现了6条经过多年实践检验的软件开发经验：
1)迭代式开发：允许每次迭代过程中需求发生变化，加深
对问题的理解，易于满足需求的变化。
2)管理需求：描述了如何提取、组织系统的功能性需求和
约束条件并把它们文档化。
3)使用基于构件的体系结构：构件使软件重用称为可能。
RUP提供了使用现有的或新开发的构件定义体系结构的系统化方
法，降低开发复杂性，提高软件重用率。
Rational统一过程 （RUP）
71
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Rational统一过程
4)可视化建模：建模是为了理解事物而对事物做
出的一种抽象，是对事物的一种无歧义的书面描述。
可视化的图形形式更易于理解。
5)验证软件质量：RUP中软件质量评估贯穿于整个
开发过程中，由全体成员参与所有活动中。
6)控制软件变更: RUP描述了如何控制、跟踪和监
控修改，以确保迭代开发的成功。
72
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Rational统一过程 （RUP）
73
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
(1) 核心工作流
前6个为核心过程工作流程，后3个为核心支持工作
流程。
(2)工作阶段
划分为4个连续的阶段，每阶段都有明确的目标，
并且定义了用来评估是否达到这么目标的里程碑。每
个目标都是通过迭代实现。
(3)迭代式开发
采用迭代或渐增的方法开发软件。RUP重复一系
列组成软件生命周期的循环，每次循环经历一次完整
的生命周期且交付可运行版本。
74
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Rational统一过程 （RUP）
用例驱动
── Concise, simple, and understandable
以体系结构为中心
─ Effective basis for large-scale reuse
增量和迭代开发
─ 基于风险前驱的原则，渐进地展开分析、设计及其相关
活动，每个迭代都会提供一次验证和调整模型机会，推动
软件质量的提升。
75
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
一、问题陈述
有一个对外营业的会议中心，有各种不同规格的会议室，为用户提供以下服务：
1、用户可以按照会议人数、会议时间预订会议室。可以只预订１次，也可预订定期
召开的会议。
2、开会前允许修改会议时间、人数，重新选择会议室，甚至取消预订的会议。
3、确定会议预订后，会议中心负责会务管理：包括通过邮寄或电子邮件，通知开会
人员有关会议信息，制作代表证等。
4、系统根据会议室的使用情况（紧张与否），调整、更改会议室和会议时间，并调
整修改预订会议的时间。
会议管理系统会议管理系统
退出下页 末页
案 例 一
76
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
二、建立二、建立用例模型用例模型
1、识别角色
找出所有可能与系统发生交互行为的外部实体、对象、系统。
考虑系统的主要功能的使用者，就会想到用户和系统管理者，但如果直接将用户定
义为角色，系统的所有功能几乎都由用户使用。根据问题的描述，系统要求将会议和会
议的召开分开来。
从会议的角度看，允许用户定义、更改或删除一个会议。
从会议召开的角度看，允许用户为某个会议定义召开时间、参加人数、更改相应的
数据或删除已定义的会议召开。
因此，将用户识别为“会议管理者”和“会议申请者”两个角色。
本系统定义以下角色：
会议管理者（Meeting Administrator）
会议申请者（Meeting Instance Requester）
邮局（Post Office ）
会议人员管理（Attendee Management ）
系统维护者（System Maintainer ）
退出上页首页 下页 末页
77
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
在识别角色的基础上，列出与角色相关的用例，有的用例与多个角色相关，经过分
析，确定系统的用例（打 ）。
⑴ 与会议管理者相关的用例：
定义一个会议（Define Meeting ）
更改一个会议（Alter Meeting ）
删除一个会议（Remove Meeting ）
⑵ 与会议申请者相关的用例：
申请会议召开（Request Meeting Instance ）
更改申请（Chang Request ）
取消申请（Cancel Request ）
定义参加人员（Add Attendee ）
归还会议室（Release Room ）
22、用例识别、用例识别
退出上页首页 下页 末页
78
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
3、会议管理系统的Use case图
图1 会议管理系统的Use case图
归还会议室
申请会
议召开
更改申请
取消申请
定义参
加人员
会议召开申
请者
邮局
会议
人员
管理
设置预
定时限
会议室
维护
定义会议
更改会议
删除会议
系统维护者
会议管理员
退出上页首页 下页 末页
79
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
用例1、定义会议（Define Meeting ）
输入会议名称
确定会议规模
确定会议类型
其中会议规模是指参会人数范围。
用例２、更改会议（ Alter Meeting ）
改变会议名称
改变会议规模
改变会议召开频度
用例３、删除会议（ Remove Meeting ）
如果该会议没有召开申请
从会议列表中删除
如果该会议有召开申请
取消与之相关的会议召开信息
删除该会议
使用：
用例8 删除参加人员（ Remove Attendee ）
用例6 取消申请（Cancel Request）
44、对用例的进一步描述、对用例的进一步描述
用例4、申请会议召开（Request Meeting Instance)
确定召开时间（年、月、日）
确定参加人员
确定侯选会议室
发会议通知
使用：
用例11 发会议通知（Inform of Meeting）
用 例 13 选 择 参 加 组 （ Select Group
Attendee）
扩展：
① 如果召开时间在申请时限之外
用例12 申请拒绝(Request Rejection ）
② 如果还没定义参加人员
用例7 定义参加人员(Add Attendee )
用例5：更改申请（ Modify Request ）
更改召开时间
更改参加人员
更改取得会议室
发会议更改通知
使用：
用例13 选择参加组（Select Group Attendee）
用例11 发会议通知(Inform of Meeting)
扩展：
① 如果更改的时间不合法
用例12 申请拒绝（Request Rejection）
② 用例7 定义参加人员(Add Attendee )
退出上页首页 下页 末页
80
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
用例6：取消会议召开（Cancel Request）、
取消申请
归还会议室
发会议取消通知
使用：
用例8 归还会议室（Release Room）
用例14 发会议取消通知（Inform Rejection）
扩展：
① 如果会议已召开
用例12 申请拒绝（Request Rejection）
用例7：定义参加人员(Add Attendee )
输入参加人员的详细信息
定义参加组
用例9：会议维护（Meeting Room Maintenance）
加入一个会议室（用例15)
标记一个会议室不可用（用例16)
查询会议室预定情况（用例17)
用例10：设置预定时限制（ Set Reservation Tome
Limit）
设置时间限
用例11：发会议通知(Inform of Meeting)
从会议人员管理获得参加人员的投递地址
填写通知（会议召开时间、会议室号码）
发送通知
用例12：申请拒绝（Request Rejection）
作废当前的一切输入
中字止用户当前的操作
用例13：选择会议参加人员组(Select Group Attendee)
浏览会议组成员
选择参加组
用例14:会议取消通知（Inform of Cancellation)
从会议人员管理处获取参加人员地址
填写通知
发送通知
用例８：归还会议室（Release Room）
输入会议室号码
输入使用时间
删除参加人员
归还会议室
使用：
用例９会议室维护（Meeting Room Maintenance）
用例18 删除参加人员（Remove Attendee）
退出上页首页 下页 末页
81
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
用例15:增加会议室（Add Meeting Room）
输入会议室号码
输入会议室规模
输入会议室可使用状态（可使用、不可使用）
加入该会议室
用例16:设置会议室不可使用（Set Unusable Flag）
输入会议室号码
通知该会议室的预定者
标记该会议室的可所以状态为不可用
用例17:查询会议室的使用情况(Browse Meetingroom usage)
输入会议室号码
查询
本用例返回会议室的使用状态（已使用、空闲）和会议室的可否使用情况。
用例18：删除会议参加人员（Remove Attendee）
删除参加人员
删除参加组
图2描述了会议管理系统完整的用例模型。
退出上页首页 下页 末页
82
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST55、完整的会议管理系统的、完整的会议管理系统的Use caseUse case图图
图2 完整的会议管理系统Use case图
退出上页首页 下页 末页
83
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
除了用例模型外，其他模型都依赖于类模型，因此，类模型是ＯＯ方法的核心，类模型
从对象的角度描述系统的组成，描述类（对象）及相互间的关系。为了建立类模型，首先要
识别类，鉴于篇幅，这里就不再讨论类的识别过程。通过分析，识别以下类：
1、 Meeting类，标识一个会议（名称、类型、规模）。
2、 MeetingInstance类, Meeting类的子类，对会议时间、人数等进行描述。
3、 MeetingRoom类,描述会议室的有关信息。
4、 MeetingAdministration类，管理会议。
5、 Attendee类，描述参会人员（姓名、性别、地址、头衔等）。
6、 GroupAttende类，创建一个参加会议的组。
7、 Address类，描述邮寄地址E-mail地址。
8、 PostOffice类，负责发送邮寄通知。
9、 AttendeeManagement类，数据库管理。
10、ReservationCriteria类，定义会议室预定准则。
11、Information类，构造一条通知。
三、三、建立类模型建立类模型
退出上页首页 下页 末页
84
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
该类与会议召开不同，它标识了一个会议（图3），因此，其属性包括会议名称、类型、规
模（参加会议的人数）。其操作则有：增加会议、取消会议。一个会议往往有多个子会议（子
类）的召开，因此，必须描述Meeting类与其子类MeetingInstance类之间的关联，如图4所示。
22、、 MeetingInstanceMeetingInstance类类
MeetingInstance类是Meeting类的子类，描述会议的具体情况，会议的开始(Start Time)、
结束时间(End Time) ，参会的人数(AttendeeNumber) ，其操作有：添加参加人员AddAttendee()
、添加参加人员组AddGroupAttendee()，而AttachMeetingRoom()表示为该类分配一个会议室，
而Cancel()则表示取消该会议的召开。
Meeting
MeetingInstance
Start Time
EndTime
AttendeeNumber
AddAttendee()
AttachMeetingRoom()
AddGroupAttendee()
Cancel()
Meeting
Name
Type
Size
AddMeetingInstance()
CancelMeetingInstance()
图3 Meeting类图
图4 MeetingInstance类图
11、、 MeetingMeeting类类
退出上页首页 下页 末页
85
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
MeetingRoom
Capacity
BuildingCode
DoorCode
Status
AssignMeetingInstance ()
SetInvalidate()
Release()
MeetingInstance
Meeting
图5 MeetingRoom类图
该类描述了有关会议室的情况，因此MeetingRoom类的属性包括：会议室的规模Capacity，位置
BuildingCode、 DoorCode，使用状态Status（正在使用、已预定、空闲和不可用）等。
该类的操作有：AssignMeetingInstance() 将 MeetingRoom 分配给 MeetingInstance 对象,而SetInvalidate
()则表示当会议室出现故障时，将其状态设置为不可用。 Release()为归还会议室。
当会议被预定后，为了便于查询某个会议室预定给了哪个会议，应建立类MeetingRoom 与类
MeetingInstanc之间的双向关联，这里定义为1：1。
33、、MeetingRoomMeetingRoom类类
退出上页首页 下页 末页
86
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Attendee
Name
Sex
Postaddress
EmailAddress
Title
MeetingInstance
1 1..*
图6 Attendee类图
Attendee类描述参加会议人员的有关信息，如：姓名、性别、地址、E-mail地址、头衔等。
MeetingInstance类与Attendee类之间有一对多的关联 “1..*” 。
5、GroupAttendee类
MeetingInstance
GroupAttendee
MemberNumber
GroupName
AddAttendee()
DeleteAttendee()
1 0..* Attendee
1 1..*
图7 GroupAttendee类图
该类可创建一个参加会议的组，便于按照小组选择参加会议的人员。 MeetingInstance类
与GroupAttendee类之间有一对多的关联 “0..*”。
44、、AttendeeAttendee类类
退出上页首页 下页 末页
87
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
系统中有两种地址：电子邮件地址（ EmailAddress ）和邮寄地址（ PostAddress ），而且，
每个参加会议的人，可以有一个或者多个邮寄地址，有0个或多个E-mail地址。有关地址的属性，
在再内这里不再讨论。
负责发送邮寄通知。 PostOffice类分别与PostAddress、 EmailAddress和Information之间有
一对多的关联。
7、PostOffice类
1..*
Information EmailAddress
1..*
PostAddress
1..*
(from Use Case View)
DelieverInformation( )
图9 PostOffice类图
PostOffice
Address
PostAddress EmailAddress
Attendee
图8 Address类图
1..* 0..*
66、、AddressAddress类类
退出上页首页 下页 末页
88
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Information
Notice Topic
Receiver Title
Receiver name
Time
Event
Explanation
SendTime
Sendr
Signature
Create()
MeetingRoom
图10 Information类图
该类用于构造一条通知，由于在本系统中，通常有三种：会议召开通知，会议更改通知，
会议取消通知。如下例所示，通知的内容常包括标题、接受者、会议内容、会议时间及发通知
的时间等。
XXXX会议召开通知
XX先生：
定于2005年9月15日在樱都会议
中心召开XXXX会议。
XXXX会议筹备组
2005年8月20日
88、、InformationInformation类类
退出上页首页 下页 末页
89
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
GroupAttendee Attendee
AttendeeManagement
(from Use Case View)
AttendNumber()
GroupAttendeeNumber()
AddAttendee()
ChangeAttendee()
AddGroupAttendee()
DeleteGroupAttendee()
图11 AttendeeManagementt类图
该类使用数据库对参加会议的人员进行管理。分析阶段只确定该类与系统的接口，有关数
据库的设计在设计阶段解决。该类与GroupAttendee类及Attendee类的关联如图11所示。
1010、、 ReservationCriteriaReservationCriteria类类
该类定义了预定会议室的准则(如时间)，并建立会议实例（ MeetingInstanee 类）与该类
之间的联系。
ReservationCriteria
TimeCriteria
setCrieria()
GetCriteria()
MeetingInstanee
图12 ReservationCriteria类图
99、、 AttendeeManagementAttendeeManagement类类
退出上页首页 下页 末页
90
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
该类管理系统中由用户定义的所有会议，并提供给用户友好的用户界面。由于该类有
定义会议（DefineMeeting）、更改会议（AlterMeeting）、删除会议（ RemoveMeeting
）等操作，建立与Meeting类之间的关联关系。
MeetingName:string
MeetingAdministration
(from eetingPack)
MeetingNumber:int
DefineMeeting()
AlterMeeting()
RemoveMeeting()
Meeting
(from MeetingPack)
图13 MeetingAdministration类图
1111、、MeetingAdministrationMeetingAdministration类类
退出上页首页 下页 末页
91
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
Meeting
MeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
Information
MeetingRoom
1..*1..* 1..*
PostOffice
GroupAttendeeAttendeeManagement
Address
PostAddress EmailAddress
Attendee
1..*
0..*
1..*
0..*
1
1
0..*
0..*
0..*
1 11
图14 会议管理系统类图
会议管理系统类图
退出上页首页 下页 末页
92
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
四、建立系统包图
引入包图来对类进行管理，图15为本系统的包图。
系统由会议包(MeetingPack)、人员包(AttendeePack)和邮寄包(PostOfficePack)三类包组成。
图16、图17、图18分别描述了这三类包的构成。
PostOfficePack
图15 系统包图
MeetingPack AttendeePack
退出上页首页 下页 末页
93
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST1、会议包（ MeetingPack ）
2、人员包（ AttendeePack ） 3、邮寄包（ PostOfficePack ）
GroupAttendee
Address
PostAddress EmailAddress
Attendee
图17 人员包构成
0..*1..*
1..*
1
图18 邮寄包构成
Information
PostOffice
（from Use Case View）
1..*
0..*
MeetingMeetingName:stringMeetingAdministration
ReservationCriteria MeetingInstance
MeetingRoom
图16 会议包构成
1 1 1
包图
退出上页首页 下页 末页
94
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
静态模型关注的是系统各成分的组织结构，而动态模型则要描述系统各成分之间的交互
行为，即系统的动态特征。结合本系统，建立动态模型，包括交互图、合作图、活动图。
（一）对象交互模型
在面向对象的方法中，一切元素都与对象紧密相关，事件也不例外。因此，对象在其生
命期中不断地与其它对象交互。使用对象交互模型来描述用例图中的每个用例，从对象观点
来描述用例的动态交互过程。
在UML中，交互模型由两类图来描述：
顺序图（Sequence diagram）强调的是对象交互行为的时间“顺序”，直观描述了对象
的生存期，用消息传送来清晰地描述了在对象生存期中某一时刻的动态行为。只适宜描述简
单的对象交互情况。
合作图（Collaboration diagram）强调的是对象合作的交互行为关系，对象间由各种关联
连接，对象之间的合作情况（交互情况）使用消息流来表示，但消息没有发送时间和传送时
间的概念。适宜描述对象数目较多，交互情况教复杂的情况。
五、建立动态模型
退出上页首页 下页 末页
95
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
：Meeting
Administration
：Meeting
：Meeting
Administrattor
1:DefineMeeting(meeting)
[IsMeetingExisted=.T.] 3:Fail(MeetingExisted)
2:{new(meeting)}
图19 定义会议的顺序图
当用户向会议中心申请召开会议时，首先要定义一个会议。会议管理者发送DefineMeeting
消息给Meeting Administration对象,消息参数是有关会议的一个临时对象(meeting)，根据该临时
对象检查会议是否存在？若不存在，创建新会议：2:{new(meeting)}，若当条件表达式为真时：
[IsMeetingExisted=.T.]，表示会议已经被定义，不需要再定义。
1、用例：定义会议(Define Meeting)的顺序图
退出上页首页 下页 末页
96
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
当用户确定要取消某个会议时，首先检查会议是否定义，如果没有可以直接删除，否则要先
取消相关的会议。
如图20所示,首先系统用户对象MeetingAdministrator发出RemoveMeeting (MeetingName)消息
给对象MeetingAdministration，通过消息的参数检索要取消的会议对象，并向该对象发出取消会
议召开的消息。表达式“[IsOpen=.F.]”表示如果会议不处于召开状态，就取消它。表达式
“[IsAllMeetingInstancesCanceled=.T.]”表示该会议的所有会议召开都已经被取消，则会议
管理就发出取消会议召开的消息。否则返回取消失败（如会议正在召开）的消息。
2、用例：取消会议(Remove Meeting )的顺序图
图20 取消会议的顺序图
：Meeting
Administration
：Meeting
Instance
：Meeting
Administrator
1：RemoveMeeting (MeetingName)
[IsAllMeetingInstancesCanceled=.F.]
5:Fail(MeetingExisted)
2:CancelMeetingInstance()
：Meeting
[IsAllMeetingInstancesCanceled
=.T.]4:Fail(MeetingExisted)
[IsOpen=.F.]
3:Cancel()
退出上页首页 下页 末页
97
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
３、用例：撤消会议召开（Cancel Requestment）的顺序图
：Meeting
Administration ：Meeting
：Meeting
Instance
：Meeting
Room
：Post Office
1:CancelMeetingInstance(Instance) [IsOpen=.F.]
2:Cancel()
3:Release() 4:DelieverInformation (cancellation)
图21 撤消会议召开的顺序图
要撤消某个会议召开，发送Cancel 信息给MeetingInstance对象。该对象先要在Meeting对
象中注销自己，再归还已分配的会议室，并向参会人员发撤消会议的通知。
图21中会议管理对象发送给会议对象的消息CancelMeetingInstance(Instance)中的参数用
于检索会议召开。条件表达式[IsOpen=.F.]表示如会议召开未进行，则撤消会议召开。如果会
议已进行，则返回失败消息（图中未列出）。
退出上页首页 下页 末页
98
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
图22 撤消会议召开的顺序图
：Post Office
：Meeting
Administration ：Meeting
：Meeting
Instance
：Meeting
Room
1:AddMeetingInstance(instance)
2:{new}
6:AssignMeetingInstance ()
7:DelieverInformation (info)
5:AttachMeetingRoom(room)
4: AddGrooupAttendee (group)
3:AddAttendee (member) 如果时间合法，
就创建一个会议
召开对象。
４、用例：申请会议召开（Request Meeting Instance）的顺序图
用户申请一个会议召开时，应该指定会议召开的名称，召开的时间，及会议参加人员。
图22中instance、 member、group、 room、 info都是临时对象， instance记录了用户指定的会
议属性（时间、参加人数等）， member为一个参会代表，是Attendee group参会人员组的对
象；而room是满足要求的会议室。
４、用例：申请会议召开
退出上页首页 下页 末页
99
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
六、合作图与活动图
对于简单的对象交互情况，顺序图可以作很好的描述，可是，当交互对象数目增加，交
互情况复杂时，顺序图就很难描述清楚了，可用合作图来描述。
合作图描述了系统中所有对象之间的交互合作关系，注重对象之间的整体交互情况，交
互关系由消息流来表示。在Rose中，还可以将顺序图与合作图进行转换。本案例不再给出合
作图。
七、活动图七、活动图
活动图模型主要用于描述系统在问题域空间中的活动流程，活动图可以方便地描述系统中
的并发活动。由于本例中并没有复杂的并发活动，而且也也没有明显的基于核心的、具有复
杂状态和行为的对象，所以可以不必画出合作图和活动图。
六、合作图六、合作图
退出上页首页
100
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
微软产品开发周期模型
微软产品周期模型
产品规划阶段
测试阶段
产品开发阶段
发布阶段
M1…Mn
CC
ZBB
RTM/W
RC1…RCn
AlphaGolden Masters
Beta
Product Vision
Function Spec
QFEs
RTM/W QA
M n
M 0
101
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
MSF过程模型将里程碑分为两大类：主要里程碑（Major milestone）和
临时里程碑（Interim milestone）。
主要里程碑是在项目阶段和阶段之间设置的，用于审核前一阶段工作完成
情况的里程碑。如图 3‑4所示，MSF过程模型包含5个主要里程碑：
前景/范围得到认可
项目计划得到认可
开发完成
可发布版本准备就绪
发布完成
这5个主要里程碑适用于大多数IT项目。
临时里程碑用于将较大的工作阶段或工作任务划分为较小的、可管理的单
元，并对每个单元的完成情况进行审核。临时里程碑的设置是根据项目的
类型和具体情况而定的。项目组可根据项目的目标、范围和进展，在项目
过程中设置和使用临时里程碑。
102
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
103
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
104
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
质量与质量规划
软件质量
─ 是“所有描述计算机软件优秀程度的特性的组合”。
软件质量度量模型由三层组成
─ 第一层为质量特性
─ 第二层为质量子特性
─ 第三层称为度量
105
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
质量与质量规划
ISO／IEC9126 – 1991（GB／T16260 – 1996）标准标
准定义的6个质量特性
功能性
可靠性
易使用性
高效性
可维护性
可移植性
质量规划
─ 指识别哪些质量标准适用于软件项目，并确定如何满足这些标
准的要求
106
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
质量体系、质量手册和质量计划
质量体系
─ 指为保证产品、过程或服务质量，满足规定（或潜在）的
要求，由组织机构、职责、程序、活动、能力和资源等构成
的有机整体。
质量手册
─ 是描述企业质量体系的文件。
质量计划
─ 是质量管理（质量计划编制、质量保证和质量控制）的第
一过程域 。
107
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
质量体系、质量手册和质量计划
质量体系、质量手册
和质量计划之间的关系
质量体系好比一个国家的
法制机构，质量手册就如同宪
法，是质量体系的文档化的体
现。而为每个项目制定的质量
计划类似地方法规，它在符合
质量手册的前提下，根据自身
的要求与特殊性，通过适当的
裁减修正而来。
关系图
108
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
项目质量计划的内容
项目实施总体目标
─ 质量
─ 时间
─ 成本
三者是一个相互制约、相互影响的统一体，其中任一项目标变
化，都会引起另两个目标变化，并受其制约。
项目分类
─ 质量倾斜型体系
─ 工期倾斜型体系
─ 成本倾斜型体系
109
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
项目质量计划的内容
编写软件质量计划涉及的范围相当广，不论是项目
选型、软件开发各阶段，还是配置管理、岗位职责与团
队组织，又或是其他如项目制度的制定等等方面，都应
该是包含在项目质量计划中的内容。
110
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
质量目标
软件生命周期三大阶段（以传统的瀑布模型为例）
─ 软件定义
─ 软件开发
─ 软件使用与维护
111
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
阶段 需要监控的关键元素
问题定义 关于规模和目标的报告书
可行性研究 系统的高层逻辑模型：数据流图，成本/效益分析
需求分析 系统的逻辑模型：数据流图（MSC图），数据字
典（类清单、对象间关系），算法描述
总体设计 可能的解法：系统流程图，成本/效益分析
推荐的系统结构：层次图 ，结构图
详细设计 编码规格说明
综合测试 综合测试方案和结果
完整性一致的软件配置
维护 完整准确的维护记录
质量目标
各阶段的关键元素
112
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
项目质量计划的编写
质量计划
应说明项目管理小组如何具体执行它的质量策略。
目的
规划出哪些是需要被跟踪的质量工作，并建立文档，此文档可以
作为软件质量工作指南，帮助项目经理确保所有工作按计划完成。
编写准则
具体情况具体对待，没有统一定律。
113
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
按照质量计划实施有效的质量控制
质量计划确定后，按其建立的质量管理体系，各责任
单位必须按PDCA质量环的要求，实施有效的质量控制。
质量控制可分为两个阶段
─监测
─控制
质量控制应贯穿于项目的整个过程。
项目收尾的两个阶段
─项目评估
─项目终止
项目收尾阶段的质量控制是一个非常重要而又容易忽视的内容。
114
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
115
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
案例分析
HRMS系统
─ 即人力资源管理系统，是为某跨国企业的ISS部门而开发
的。
HRMS系统生存期模型选择过程
─ 针对本项目的开发特点，参考企业的生存期模型说明和软
件过程体系，决定采用迭代增量式模型。
116
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
案例分析
H
R
M
S
项
目
生
存
期
模
型
117
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
118
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章小结
讲述了软件开发过程管理需要掌握的部分知识。
介绍了ISO9000，CMM和CMMI三种常见的软件过程改进方法，并比
较了它们之间的异同，对于选取哪种方法给予了建议。
详细介绍了多种软件开发生命周期模型的特点、优缺点，对于软件开
发中的相当重要的项目选型工作提供了参照。
此外还介绍了质量计划的定义和详细的模版。(质量计划的制定对于软
件质量控制的重要性非同小可，它涉及的范围很广，需要制定的内容
相当多，部分内容读者可以在其它章节去详细了解。)
119
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
本章内容提要
CMM和ISO9000
传统软件开发生命周期模型
扩展软件开发生命周期模型
质量计划
案例分析
本章小结
复习思考题
120
THE SCHOOL OF SOFTWARE ENGINEERING OF HUST
复习思考题
1. CMM和CMMI的五个级别分别是什么？CMM和CMMI的关
系是什么？
2. 在软件企业中推行ISO9000的意义何在？
3. 传统的软件开发生命周期可以分为哪几个子阶段？
4. 原型模型可以细分为哪两种？它们的内容是什么？
5. 你觉得进化模型和螺旋模型有哪些相似之处吗？它们的核心思
想是什么？
6. 质量体系、质量手册和质量计划的联系何在？
7. 在需求分析阶段需要监控的关键元素是什么？
