软件质量和软件过程
一、软件质量特性
商务印书馆四角号码新词典（1978年版）中质量的定义：（1）产品或工作好坏程度；（2）物体中所含物质的多少。本文取第一个定义。
SW-CMM对质量的定义是：（1）一个系统、组件或过程符合特定需求的程度；（2）一个系统、组件或过程符合客户或用户的要求或期望的程度。
1983年，ANSI/IEEE STD729给出了软件质量定义[92]：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，它包括：(1) 软件产品质量满足用户要求的程度；(2) 软件各种属性的组合程度；(3) 用户对软件产品的综合反映程度；(4) 软件在使用过程中满足用户要求的程度。
图
图
ISO的软件质量度量模型的类图
按照ISO/TC97/SC7/WG3/1985-1-30/N382，软件质量度量模型由三层组成。高层称软件质量需求评价准则（SQRC），中层称软件质量设计评价准则（SQDC），低层称软件质量度量评价（SQMC）。ISO认为应对高层和中层建立国际标准，以便在国际范围内推广应用软件质量管理，而低层可由各使用单位自行制定。ISO高层由8个要素组成、中层由23个评价准则组成，它们之间的关系如图1-1所示。（图中的◆符号代表某项下面各子项是必须的，缺一不可。例如，效率项由存储效率和运行效率子项组成，两者缺一不可，这是统一建模语言（Unified Modeling Language, UML）的组合的表示方法）。
由于许多人纷纷提出意见，按1991年ISO发布的ISO/IEC9126质量特性国际标准，SQRC已降为6个。在这个标准中，三层次中第一层称为质量特性，第二层称为质量子特性，第三层称为度量。该标准定义了6个质量特性，即为功能性(functionality)、可靠性(reliability)、可使用性(usability)、效率(efficiency)、可维护性(maintainability)、可移植性(portability) 。并推荐21个子特性，如适合性、准确性、互用性、依从性、安全性、成熟性、容错性、可恢复性、可理解性、易学习性、操作性、时间特性、资源特性、可分析性、可变更性、稳定性、可测试性、适应性、可安装性、一致性和可替换性，但不作为标准。
图1-2 软件质量特性类图
Figure 1-2 Class Diagram of Software Quality
表1-1 用户要求与软件质量特性
Table 1-1 The User Requirement and Software Quality Characteristic
用户要求
要求质量的定义
质量特性
功能
·能否在有一定错误的情况下也不停止运行？
·软件故障发生的频率如何？
·故障期间的系统可以保存吗？
·使用方便吗?
完整性（integrity）
可靠性（reliability）
生存性（survivability）
可用性（usability）
性能
·需要多少资源？
·是否符合需求规格？
·能否回避异常状况？
·是否容易与其它系统连接？
效率性（efficiency）
正确性（correctness）
安全性（safety）
互操作性（inter-operability）
修改
变更
·发现软件差错后是否容易修改？
·功能扩充是否简单？
·能否容易地变更使用中的软件？
·移植到其它系统中是否正确运行？
·可否在其它系统里再利用？
可维护性（maintainability）
可扩充性（expandability）
灵活性（flexibility）
可移植性（portability）
再利用性（reusability）
管理
·检验性能是否简单？
·软件管理是否容易？
可检验性（verifiability）
可管理性（manageability）
上述定义表明，软件质量依赖于软件的内部特性及其组合。为了对软件质量进行度量，首先必须对影响软件质量的要素进行度量，并建立实用的软件质量度量体系和模型。
在进行软件质量设计时，必须考虑利弊，全面权衡，根据质量需求，适当合理地选择/设计质量特性，并进行评价。
图1-3 软件质量形成过程活动图
图1-2给出了上述软件质量特性构成关系的一个扼要说明。软件质量是建筑在用户要求基础上的，所以必须掌握好用户要求与开发过程中逐渐形成的质量特性之间的关系。一般反映到需求规格上的用户要求都属于与功能及性能有关的运行特性，或与修改、变更、及管理有关的维护特性。表1-1表示了这些用户要求与质量特性的关系。经过质量管理的软件开发过程也是逐步实现反映用户所要求的质量要求(quality requirement)的质量特性的过程。图1-3表示在如下的质量管理体系下与软件开发过程中实现质量管理的过程[75]。
第一步是在费用与期限的制约下将需求规格与质量规格变换成设计书和程序的过程。在这个过程中将使用软件开发技术和开发工具把用户要求的质量特性表现在设计书和程序里。
第二步是对设计书和程序等各工程开发成果进行评审的过程。评审（review）采用质量检查会也称质量论证会（walkthrough）、质量审查（inspection）等早期检查手段，一般在各工程作业结束后立即进行。参加者是一些和项目有关的技术人员。目的在于尽可能在早期工程（上游工程）阶段发现潜入的软件缺陷，将有缺陷的设计书和程序变换成无缺陷软件。在这一个过程中，如果发现设计书或程序中的缺陷就会导致再设计或再编码的返工作业。
第三步是对最终开发成果进行测试，将第二步的无缺陷软件变换成既无缺陷又无差错的软件的过程。如果在测试中发现软件差错，和第二步一样也会导致再设计和再编码的返工作业。
二、软件过程分类
过程定义：韦氏词典将“过程”定义为“某物生产的操作体系……能导致结束或得到结果的一系列的活动、变革、或操作。”IEEE将“过程”定义为“为实现给定目标所执行的一系列的步骤（IEEE-STD-610）。”
过程模型的主要作用：过程模型不仅详细规定了在每个阶段的所有任务和活动﹑任务活动之间的层次时序关系，还制定了在软件开发和演化中各个阶段的时序和约束条件，建立了从一个阶段进入下一个阶段的过渡准则。同时，它还确定了软件开发过程中所应遵守的“策略”或限制。过程模型还有利于软件开发中各类人员之间的有效通信和过程重用，支持过程演化，便于过程管理。
图2-1 理想的软件过程模型的标准类图
软件过程：软件开发人员开发和维护软件及相关产品(如项目计划、设计文档、代码、测试用例和顾客手册)的一套行为、方法、实践和转化过程。
图2-2 软件生存周期过程分类
图2-3 基本过程类图
图2-4 支持过程类图
理想的过程模型的标准：(1) 能表示所有活动的组织方式；(2) 能表示各活动的工作方式；(3) 能表示各活动的先后﹑并发﹑同步﹑制约等关系；(4) 能表示过程的动态特性；(5) 能随实际情况进行动态演化；(6) 易于被所有参与开发活动的人员理解；(7) 具有很强的灵活性，可以适应不同的软件项目；(8) 支持软件开发环境的建立；(9) 易于对开发过程进行控制和管理。本文用图2-1表示之（图中的◇符号代表某项由下面各子项组成，但各子项不是缺一不可的，由于各种原因有可能缺若干子项，这是UML的聚集的概念）。显然，若一个过程模型要完全符合这些标准几乎是不可能的，应根据实际需要选择几个最主要的标准即可。
1985年正式发布了一项国际标准，即ISO/IEC 12207信息技术----软件生存周期过程(见图2-2)，这是软件过程研究的一个重要成果。实践表明，软件过程需要不断地完善。首先，从非工程化的软件开发方式转变为工程化的软件开发方式，按照软件工程的系统方法进行软件的工程活动和管理活动，进而不断地完善各个软件过程，从而不断提高软件过程能力。随着这种能力的提高，一个软件组织完成软件产品时在预算、进度，特别是产品质量方面的风险就逐步降低。ISO/IEC 12207将软件生存周期的各个过程分成三类：基本生存周期过程(见图2-3)、支持生存周期过程(见图2-4)和组织生存周期过程(见图2-5)。
图2-5 组织过程类图
例题1、填出MaCall给出的11个质量要素特性的英文名称，并解释 部分。
1.正确性（correctness）。程序满足规格说明及完成用户目标的程度。
2.可靠性（reliability）。能够防止因为概念、设计和结构等方面的不完善造成的软件系统失效，具有挽回因操作不当造成软件系统失效的能力。
3.有效性（efficiency）。软件系统能最有效地利用计算机的时间资源和空间资源。
4.完整性（integrity）。控制未被授权人员访问程序和数据的程度。
5.可用性（usability）。学习使用软件的难易程度。
6.可维护性（maintainability）。软件产品交付用户使用后，能够对它进行修改，以便改正潜伏的错误，改进性能和其它的属性，使软件产品适应环境的变化等。
7.可测试性（testability）。测试程序使之具有预定功能所需的工作量。
8.灵活性（flexibility）。改变一个操作程序所需的工作量。
9.可移植性（portability）。软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。
10可重用性（reusebility）。概念或功能相对独立的一个或一组相关模块定义为一个软部件，软部件可以在多种场合应用的程度。
11.可互操作性（interoperability）。两个或多个系统交换信息并相互使用已交换信息的能力
例题2、PDCA循环用于软件开发管理
传统的质量管理思想和技术同样可以应用于软件项目管理，由于现在中国处于工业化社会和信息化社会并存的情况，传统的质量管理思想和技术更容易为人们所接受，技术上也比较成熟，是广大中国中小型软件企业最实用和现实的选择。
在一定的资源、时间和费用条件下完成符合需求规格的高质量软件，就必须采用适当的软件管理技术。管理技术包括管理实行前对开发规模、开发工时、开发费用的估算，以及以这个基本估算为依据所展开的各项管理技术。开发规模是对产品程序的大小的描述，用行数或语句数（step数）表示，分基本语句数（statement step数）和命令语句数（command step数）两种表示方式。开发工时是对软件工程技术人员工作时间的描述，用（人日）或（人月）等来表示。开发费用指开发所需要的各种费用，一般包括人工费（工时数×单价）、计算机机时费（计算机使用时间×单价）以及其它消耗。软件开发管理也称开发项目（project）管理。即将有关软件开发的各项活动统一称为“开发项目”，在一定的目标、计划、进度和预算指导下推行开发项目内容的实施。
软件开发管理的关键问题是如何在软件生存周期内对质量、时间、费用三要素进行量化，如何通过质量管理、工程管理和费用管理活动对这三要素进行分析和评价。
表2-2 软件开发管理技术及其评价内容
管理技术
评价内容
质量管理
·质量检查会（walkthrough）
·检查（inspection）
·质量管理工具
·测试辅助技术
·可靠性评价技术
·质量指标评价
·质量定量分析
·要求质量与产品质量评价
·软件错误原因调查
·开发方法论与工具评价
工程管理
·甘特图（grant chart）
·CPM/PERT
·里程碑图（milestone chart）
·进度预测仿真系统
·趋势图（trend chart）
·计划与实际比较
·掌握进度情况
·交付期管理
·工程延误对策
成本管理
（费用）
·SLM*
·SQAM*
·Doty Model
·COCOMO* Model
·开发规模，工时，成本预算与实际比较
·预算与实际成本比较
·修正基线生产经营效率
*SLM：软件生命周期管理(software life-cycle management)
SQAM： 软件质量评估和测量(software quality assessment and measurement)
COCOMO： 构造性成本模型(constructive cost model)
表2-2是一个将传统工业管理思想应用于软件开发管理的例子。为了有效地进行开发管理，一定的管理措施和标准化是很重要的。标准化（standardization）的目的是为了使软件开发作业工厂化，从依赖开发人员个人能力的手工业式生产转向软件工程学指导下的工业化生产。软件开发标准化分为作业本身标准化和管理活动标准化两大类。前者指在软件开发和维护的各个阶段设定的有关作业内容的标准（standard）；后者指在软件开发管理中为使质量管理、费用管理等各项管理业务都能有效的实施而设定的管理基线。
质量管理的目的在于保证开发成品的最终质量满足用户对质量的要求。为此，需要设定质量目标，质量保证基线，确立质量管理制度和措施。特别要重视当然质量（must-be quality），因为它是可靠性的重要保证因素。
工程管理的主要工作包括确立日程计划，规定各开发阶段（工程）的定义和成品，设定工程管理重点——“里程碑（milestone）”，制作工程作业网络图，掌握各工程进度，及时发现工程延误和提前并及时调整相关部署等等。在实际中，由于软件产品是非直观的，判断其生产过程中的准确进度常常是很困难的。通常的办法是事先将开发进度状况绘制成图表，在适当的时机设定软件工程管理点（里程碑）及相应的评价项目。当执行中进行到这些里程碑处时，对进度和相应项目进行检查和评价。
费用管理有两方面的工作，一是正确估计用于开发和维护的工时、人工费和计算机机时费等费用预算，一是按此预算管理生产过程中投入的费用。具体包括随时掌握预算与支出的相对状况，安排与调度人力，分析预算与实际的距离，制定标准单价，使费用内容具体化，分析损益收支情况，设定生产指标和改善生产效益等等。图2-6是软件开发管理过程的活动图。
图2-6 软件开发管理过程的活动图
图2-7列出了软件质量测量和质量保证系统在软件保证活动中的5个实施步骤：
（1）目标(target)：以用户要求和开发方针为依据，对质量需求准则、质量设计准则中的各质量特性设定质量目标。对各准则的重要程度可以设定“特别重要”、“重要”、“一般”3级。
（2）计划(plan)：设定适用于被开发软件的评测检查项目，与此同时还要研讨实现质量目标的方法和手段。
（3）执行(do)：在开发标准和质量评价准则的指导下，制作高质量的规格说明书。在接受质量检查之前要先做自我检查。
（4）检查(check)：按计划阶段设定的质量评价准则进行评价，算出得分，用质量图的形式表示出来。对比评价结果的质量得分和质量目标，看软件是否合格。
（5）改善(action)：对评价发现的问题进行改进，如果改进实现并达到了质量目标，接转入下一个工程阶段。
图2-7 软件质量测量与质量保证的活动图
三、软件过程管理国外发展情况
ISO9000是质量管理和质量评价系列标准，目标在于开发过程，ISO9000只决定过程的要求是什么，而不管如何实现。ISO9000标准针对软件部分的是ISO9001和ISO9000-3。其中ISO9001负责处理设计、开发、生产、安装和服务产品，ISO9000-3负责处理设计、开发、生产、安装和维护计算机软件。
开发详细的质量计划和程序控制配置管理、产品检验和合法性检查（测试）、不规范行为（软件缺陷）和修正措施（修复）。准备和接受软件开发计划证实，包括项目定义、产品目录清单、项目进度、产品说明书、如何组织项目的描述、风险和假设的讨论，以及控制策略。使用客户容易理解、测试时容易进行合法性检查的用语来表达说明书。开发控制软件设计随产品的生命周期中而变化的程序，开发和编制软件测试计划，开发检测软件是否满足客户要求的方法，实施软件合法性检查和验收测试，维护测试结果的记录，控制调查研究和解决软件缺陷的方式。证明产品在发布之前已经就绪，开发控制产品发布过程的程序，明确指出和规定应该收集何种质量信息，使用统计技术分析软件开发过程以及使用统计技术评估软件产品。
著名的软件过程能力成熟度模型（Software Capability Maturity Model，SW-CMM）是SEI从1986年开始研究并完成的，它侧重于对软件开发过程和开发方法论的考察。CMM包括5级：初始级(Initial)，2级：可重复级(Repeatable)，3级：已定义级(Defined)，4级：已管理级(Managed)，5级：优化级(Optimizing)。CMM还提供了一整套较为完善的软件研发项目管理的方法论。在CMM模型获得巨大成功的情况下，SEI又开发了一系列其它CMM模型，包括系统工程成熟度模型(Systems Engineering Capability Maturity Model 1994，SE-CMM)、软件人员成熟度模型(People Capability Maturity Model, 1995, P-CMM)、软件获取成熟度模型(Software Acquisition Capability Maturity Model，1996，SA-CMM)等。美国先后在这上面投资了5亿多美元，做了很多实践工作来改进软件研发项目管理，而且其内容还在不断地改进，SW-CMM 版本推出后，又推出了SW-CMM 草案。目前，取消了单独的CMM，开发出集成能力成熟度模型（Capability Maturity Model Integration，CMMI），其模型包括CMMI-SW、CMMI-SE、CMMI-SE/SW、CMMI-SE/SW/IPPD]，模型有连续表示（Staged Representation）和分级表示（Continuous Representation）两种。两种表示方法各有不同的使用对象，熟悉SE-CMM模型者用连续表示更容易，而熟悉SW-CMM模型者用分级表示更容易。
ISO9000产品质量体系认证和CMM体系认证在软件先进国家格外重视。印度软件企业普遍开展ISO9000质量体系认证，多数软件企业发展遵循ISO9001的标准，到目前为止已有100多家取得了ISO9001的认证；而且有越来越多的印度软件企业已经开始认识到采用CMM评估体系的重要性，而且重点已经开始转移。印度的软件企业是全球软件业进行CMM评估实践最早和最多的。据不完全统计，到2000年，全球有75家通过了CMM第4级和第5级认证，在世界9大软件出口国中，印度的软件出口规模和质量均在世界前列。
美国是世界软件生产大国，不论在技术创新和管理手段上都代表着软件发展的先进水平。据不完全统计，到2000年，全球已有近万家软件开发企业通过了CMM认证。其中绝大多数被认证的软件开发企业处于CMM第2级，有75家通过了CMM的第4级和第5级。达到后两个级别的软件企业在不断增加。美国企业所占比例约5%，十分重视标准化的日本企业所占比例约10%。在这些通过CMM认证的软件企业中，不乏成功者。例如，Raytheon公司现在有近400名软件开发人员，公司用近五年的时间，将其成熟度从第1级提高到第3级，已经收到明显的效果。为了提升到较高的级别，公司所花费的投资于五年来因成本降低所收到的效益之比为1:8，直接生产效率提高了大约14倍。该公司所开发的产品在成熟度提升前每千条指令出错率约为条，提升后仅为条。
国外主要软件质量/软件过程研究组织和机构：
美国卡内基·梅隆大学软件工程研究所(Carnegie Mellon University/ Software Engineering Institution CMU/SEI) 成立于1984年，其长期目标是能够更好、更快和更便宜地预测美国国防部软件密集系统的获取、开发和维护。SEI认为软件学科的特点是可预测性：可预测的成本、可预测的进度、可预测的质量和可预测的功能。SEI的义务是使软件工程进化，使其从专门的、劳动密集的、个人英雄主义的活动中解脱出来。总之，SEI寻求的是依赖于软件的系统能按可预测的方式获取、开发和进化。Web站点。
软件工程实验室（Software engineering laboratory, SEL）在美国国家宇航局所属的戈登空间飞行中心（National Aeronautics and Space Administration/ Goddard Space Flight Center，NASA/GSFC）支持下于1977年建立。的目的是研究开发应用软件有效的软件工程技术，主要由NASA/GSFC的系统开发部，马里兰大学计算机科学系（University of Maryland）和计算机科学公司飞行动力技术组（Computer Sciences Corporation, Flight Dynamics）三部分组成，进行了长期的软件工程实践，包括：（1）理解GSFC环境下的软件开发工程；（2）度量在这种过程下的方法论、工具和模型的效用（effect）; (3) 识别和应用成功的开发实践。Web站点。
软件技术支持中心(Software Technology Support Center, STSC)位于犹他州奥格登的Hill空军基地。成立STSC旨在帮助空军的组织机构标识、评价和采用改善产品质量、生产效率和可预测性的技术。采用术语技术(term technology)，从最广泛的意义上包括提高人类能力的过程、方法、技术和工具，STSC关注对 DoD任务有益的领域已证实的技术。STSC除了提供支持和咨询服务外，还出版CrossTalk The Journal of Defense Software Engineering。Web站点 。
软件生产率集团(Software Productivity Consortium, SPC) 是一个包括产业界、政府部门和学术界在内的非赢利的联合体。因为有90多个会员公司，SPC提供了改善系统和软件的质量、可靠性和上市时间性能所需要的技术和专门知识。SPC的技术计划适用于集成基于本质过程的集成化系统和软件开发活动。SPC提供了各种改善模型和方法的课程，包括软件CMM和CMMI、度量和软件工程技术、集成化系统和软件过程开发。 SPC提供了评估和咨询服务，还出版季刊时事通讯并发表其它与系统工程、软件工程、系统和软件集成以及过程改进有关的技术性文章。Web站点 。
国际系统工程咨询委员会(International Council on Systems Engineering, INCOSE) 是国际性的非赢利组织，目的是为多学科系统产品的开发制定、发展和完善系统工程方法。INCOSE成立于1990年，目前已拥有3900多名系统工程专业人士。INCOSE是EIA/IS 731的主要开发者，并为 CMMI项目提供系统工程专家。Web站点。
电子工业联盟（Electronic Industries Alliance, EIA）是电子与高技术协会和公司的联合体，承担着共享知识和影响的义务。EIA发表了许多标准和技术出版物来为公众利益服务，减少制造商和采购商之间的误会，促进产品的可交换性和改善，以及辅助采购商根据特定的需要快速选购并获得合适的产品。EIA过渡标准，系统工程能力和EIA/IS 731就是CMMI的三个源模型之一。Web站点。
例3．IBM OS/360总设计师布鲁克斯(Brooks)博士将软件中的难题分为本质问题两类和非本质问题，他还进一步指出了哪四个本质问题？并请简单说明之。
答：IBM OS/360总设计师布鲁克斯(Brooks)博士将软件中的难题分为两类：本质问题（essence，即由软件本质决定的固有的难题）和非本质问题（accidents，即目前遇到的，但并非软件产品固有的困难）。他指出了四个本质问题：即复杂性（complexity）、一致性(conformity)、可变性(changeability)和不可见性(invisibility)。他在文章中使用的“复杂性”的含义是“令人费解的、复杂难懂的”（complicated or intricate）。
复杂性：复杂性是软件的固有的属性。他认为如果将一套软件简化，则整个过程将是毫无用处的。数学和物理的简化技术之所以有用，只是因为那些系统的复杂性是非本质问题，而不是像在软件产品中那样，复杂性是本质问题。这种本质上的复杂性不仅影响软件产品本身，而且也会影响软件过程的管理。
一致性：他提出第一类一致性是软件必须和现有系统接口，从而使软件的复杂性达到了不必要的程度；第二类一致性是人们错误地认为软件是最容易调整的部分，使得软件的复杂性达到了不必要的程度。
可变性：系统的功能体现在它的软件中，通过修改软件，就可以收到改变系统功能的效果。他认为可变性是软件的本质属性，是一个不可克服的固有的复杂性问题。
不可见性：软件无法形象化表示的结果，不仅使软件难以理解，而且严重妨碍了软件专业人员之间的联系。
例4．SW-CMM的提出者Watts S. Humphrey指出了哪六个软件过程改进基本原理？并请简单说明之。
领导原理（HP1）：软件过程的主要改变始于高层领导。高层领导需要发起改变并提供持续的资源及优先级。
团队原理（HP2）：最终将涉及到每个人。软件工程是团队的努力，改进中任何人的缺席将失去好处，也可能阻碍进步。
计划原理（HP3）：有效地改变需要有当前过程的目标和知识。使用地图时你必须知道当前你在哪儿。
成熟度原理（HP4）：变化是持续的。软件过程改进不是暂时的，涉及到持续地学习和不断地强化。
效果原理（HP5）：没有明确地努力和定期地强化就不能保持软件过程改变的效果。
投资原理（HP6）：软件过程改变需要投资。需要计划，配备专职人员以及管理时间和资金投入。
例5，填空题
SW-CMM的五个成熟度等级是初始级(Initial Level)、可重复级(Repeatable Level)、已定义级(Defined Level)、已管理级(Managed Level)、优化级(Optimizing Level)。
SW-CMM的五个公共特征: (1)执行约定(Commitment to Perform)、(2)执行能力(Ability to Perform)、(3)执行的活动(Activities Performed)、(4)测量活动(Measurement and Analysis)、(5)验证实施(Verifying Implementation)。
SW-CMM的可重复级的六个关键过程域是：需求管理(Requirements Management)、软件项目策划(Software Project Planning)、软件项目跟踪与监控 (Software Project Tracking and Oversight) 、软件子合同管理 (Software Subcontract Management) 、软件质量保证(Software Quality Assurance) 、软件配置管理(Software Configuration Management)。
四、统一软件过程及其支持工具
统一建模语言（Unified Modeling Language, UML）于1996年由Rational公司正式创立(该公司已经被IBM 公司收购)。对象管理组织(OMG)于1997年11月采纳了它。此后，UML继续改进，目前最新的版本是。UML的发明人, 和共同认为，提出一种统一的建模语言有以下3个理由：（1）他们各自提出的方法在演化中已经有相互结合的趋势；（2）走向统一将带来市场方面的好处；（3）有助于改进他们各自的学习方法，以获得更多的学习者并解决一些以往他们各自的方法不能很好解决的问题。该建模语言的作者们给出了一种推荐性的建模过程指导，即统一过程（Rational Unified Process，RUP）体现了适合于范围广泛的项目和组织的许多现代软件开发最佳实践。RUP是以用例为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流。Web站点。
UML的定义有两个主要组成部分:语义和表示法。UML的语义用自然语言描述,表示法定义了UML的可视化标准表示符号，这决定了UML是一种可视化的建模语言。这些图形符号和文字用于建立应用级的模型，在语义上，模型是元模型的实例。此外UML的定义还给出了语法结构的精确规约。
UML是一种可视化的建模语言,对其各建模元素可进行详细说明，并能生成所建模型的文档。使用UML时，要从不同的角度观察系统，为此定义了一个概念"视图"。视图是对系统的模型在某方面的投影，注重于系统的某个方面。每个视图是图的协作，UML定义了9种图。用况视图由用况图组成，描述可被最终用户、分析人员和测试者看到的系统行为；设计视图包含类图、对象图、交互图、状态图和活动图，主要反映系统的功能需求；进程视图包含类图、对象图、交互图、状态图和活动图，主要描述形成系统并发与同步机制的线程和进程；实现视图包含构件图、交互图、状态图和活动图，反映用于装配与发布物理系统的构件和文件，主要针对系统发布的配置管理,可以用各种方法装配它们。部署视图包含部署图、交互图、状态图和活动图,主要描述对组成物理系统的部件的分布、交付和安装。根据实际需要，可以组合使用这些视图。
由视图可以定义模型，模型在语义上是闭合的,它从特定的角度(系统的规约或者设计)在一定抽象层次上描述目标系统。可以把视图组织成模型,开发人员可从各视角观察使用模型。
用以描述系统的模型可以是结构性的，强调系统的组织，也可以是行为性的,强调系统的动态方面。例如，RUP有9种模型,分别是业务模型、领域模型、用况模型(也称需求模型)、分析模型、设计模型、过程模型、部署模型、实现模型和测试模型，用于从不同的角度表示系统。
系统是一组反映不同侧面的子系统的集合，为了完成特定的目的要对这些子系统进行组织(在逻辑、功能和物理位置上是高内聚、低耦合的)。
子系统是一组元素的聚集，其中的元素还可以是子系统。它由一组模型从不同的角度进行描述。子系统本身几乎应是独立的，有自己应用的环境，相互间不重叠，它们之间用接口联系。
UML是一种建模语言，不是一种方法，它独立于过程。利于它建模时，可遵循任何类型的建模过程。该建模语言的作者们给出了一种推荐性的建模过程指导，即RUP。下面说明RUP如何支持UML的应用。
RUP是以用况为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段,每个阶段又分为若干次迭代,每次迭代都有一个核心工作流(包括5个活动)。
用况驱动旨在为到最终产品为止的每个阶段都可以回溯到用户的真正需求。以体系结构为中心是指关注体系结构模式的开发，以引导后续系统,保证系统的平滑演进。每一次迭代包括迭代计划、迭代评价和一些具体活动。下面对RUP的四个阶段要做的工作做一阐述。
1. 初始阶段
本阶段确定所设立的项目是否可行,具体要做如下工作:
（1）对需求有一个大概的了解，确定系统中的大多数角色和用况，但此时的用况是简要的。对给出的系统体系结构的概貌,细化到主要子系统即可。
（2）识别影响项目可行性的风险。
（3）考虑时间、经费、技术、项目规模和效益等因素。
（4）关注业务情况,制订出开发计划。
2. 细化阶段
（1）识别出剩余的大多数用况。对当前迭代的每个用况进行细化，分析用况的处理流程、状态细节以及可能发生的状态改变。细化流程时，可以使用程序框图和合作图，还可以使用活动图、类图分析用况。
（2）对风险的处理。
（a）需求风险：考虑项目的目标是否偏离了用户的需求。为解决需求风险要充分了解用户需求以及各需求的优先度，还应尽量列出所有的用况，至少列出重要的用况，并要建立领域的概念模型。
（b）技术风险：考察所选的技术方案是否可行。建立原型是解决技术风险的一种有效方法。
（c）技能风险：考虑实施项目的人员素质能否胜任项目的要求。
（d）政策风险：考虑政策性的因素对项目的影响。
（3）进行高层分析和设计，并作出结构性决策。
所产生的基线体系结构包括用况列表、领域概念模型和技术平台等。以后的阶段对细化阶段建立的体系结构不能进行过大的变动。
（4）为构造阶段制订计划。
细化阶段完成，意味着已经完成了如下的任务：用况完全细化并被用户接受；完成概念验证；完成类图；开发人员能给出项目估算(可分为精确、人月和无法估算)；基于用况考虑了所有风险(可分为高风险、可能的风险和不可能的风险)，并制订了相应的对策和计划；对用况标出优先级(可分为必须先实现、短期内实现和长期实现)。
3. 构造阶段
识别出剩余的用况。每一次迭代开发都针对用况进行分析、设计、编码(如类声明、属性声明、范围声明、函数原型声明和继承的声明等)、测试和集成过程，所得到产品满足项目需求的一个子集。由于细化阶段的软件设计已经完成，这样各项目组可以并发开发。
在代码完成后，要保证其符合标准和设计规则，并要进行质量检查。对于新出现的变化，要通过逆向工具把代码转换为模型，对模型进行修改，再重新产生代码，以保证软件与模型同步。
此阶段要建立类图、交互图和配置图；如一个类具有复杂的生命周期，可绘制状态图；如算法特别复杂，可绘制活动图。
4. 移交阶段
这一阶段完成最后的软件产品和最后的验收测试，并完成用户文档编制以及用户培训等工作。
总之：可以说，UML对系统模型的表达能力超出了以往任何一种面向对象的分析和设计方法。随之出现的问题是，它的复杂性也超出了以往任何一种方法。由于UML的复杂性,对它的掌握和使用确实不是一件轻松的事。
例6，填空题
UML规定了语言的四种公共机制：（1）说明(Specification);（2）装饰(Adornment);（3）通用划分(Common Division);（4）扩展机制(Extensibility)。
UML语言的体系结构建立在4层元模型结构之上，这4层模型分别为：（1）元—元模型 (meta-metamodel); （2）元模型(metamodel);（3）模型(model);（4）用户对象(user object)。
UML语言从4个抽象层次对UML语言的：（1）概念 (conception)、（2）模型元素(model element)、（3）结构(structure)、（4）机制(mechanism)等进行了全面的定义，并规定了相应的（5）表示法(notation)和（6）图形符号(graphic marker)。
瑞理软件工具对CMM实施的支持。一般来说,实施CMM需要以下主要工具:软件开发过程框架、需求管理工具、面向对象的分析设计工具、配置管理工具、变更管理工具和软件测试工具。
1. 软件开发过程框架
CMM是一种软件过程控制和评估框架，它列出了每个级别需要完成的目标以及判定条件，但并没有叙述如何实现这些目标。软件开发过程框架工具的目标就是为开发团队建立一个清晰的、可重复执行的流程，以帮助团队成员按时完成项目各阶段的工作。
Rational公司的RUP(Rational Unified Process)就是这样一个完整的软件开发过程框架,它包括3000个HTML文档、近一百万字的流程指南,其中文版本RUP-C已经在中国市场正式发布。
RUP对CMM实施的主要帮助体现在以下方面：（1）凝结了全球软件行业的最佳开发经验，以指南、模板和示例的形式为开发团队提供流程指导；（2）建立统一的软件开发标准,改善团队成员之间的沟通；（3）降低软件开发风险,增加软件开发的可预测性；（4） 赋予项目经理对进度和交付期限的控制能力。
2. 需求管理
需求是软件客户的要求,它决定了软件系统的工作内容,是整个开发活动的基本出发点和最终目标。在整个项目生命周期内,要想有效地协作,就需要对重要的需求信息提供访问权限,使跨功能团队的所有成员都能掌握必要的详细信息。需求管理的目的是在客户和相应的软件项目之间建立共同的理解,并最终形成估计、策划和跟踪整个软件生命周期内软件项目活动的基础。
需求管理是CMM2级(可重复级)的关键过程领域之一，其主要工作包括两点：其一,通过与利益相关者(Stakeholder)的交流来获取需求，并进行有效的组织和记录；其二，使客户和项目团队在系统变更需求上达成一致。
一个优秀的需求管理工具可以在保证有效管理需求的前提下提高需求管理工作流程的自动化程度，使需求管理可以真正在项目实施中得到有效的推行。Rational公司为需求管理提供了AnalystStudio需求工作包，它具有以下主要特点：（1）结合业界认可的RUP方法,提供完整的需求分析及管理流程；（2）以Web方式获取反馈,加强团队之间的有效沟通；（3）用追踪图直观展现需求变化带来的影响。
AnalystStudio除了可用于CMM2级的：“需求管理”外,还可以对以下KPA提供帮助：“软件项目规划”、“软件项目跟踪与监督”、“软件子合同管理”、“软件产品工程”、“组间协作”、“同级复审”和“定量过程管理”。
3. 面向对象的分析设计工具
在CMM3级的“软件产品工程”(Software Product Engineering)KPA中，对软件设计提出了明确的要求，要求软件设计遵循一定的设计语言、采用面向对象的方法、使设计结果可复用等。
为什么要采用面向对象的分析设计方法?主要原因有3点：（1）通过分析和设计，使开发者可以先关注问题的领域，再关心具体的设计和编程问题，从而有利于降低整个过程的复杂性，提高分析模型和设计模型的质量；（2）生成的分析模型和设计模型形成文档的主体，从根本上解决“先写代码、再补文档”的老问题，并能帮助团队规避因人员流动带来的不良影响；（3）分析模型和设计模型将成为团队内部以及团队之间有效沟通的桥梁,消除误解,进一步解决"系统集成难"的顽症,同时也可以促进团队之间的软件复用。
Rational Rose是Rational公司开发的可视化建模工具,它采用UML的表示方法，在同一个模型中实现业务建模、对象建模和数据建模，使所有参与项目的成员都可以在统一的语言环境中工作于同一个模型之上，有利于改善成员之间的沟通；其次，它支持多种语言的代码生成及双向工程，可实现代码和模型的互相转换，并且可以将遗留代码引入模型中；第三，它带有对设计元素进行测试的模块工具(Quality Architect)，可以尽早发现设计中的问题，真正实现“质量从头抓起”。
Rational Rose除了可帮助实施CMM3级的“软件产品工程”外,还可以对“组间协作”和“同级复审”KPA提供帮助。
4. 配置管理和变更管理
软件配置管理(SCM)是CMM2级中一个非常重要的KPA，它的目的是在软件项目的生命周期内建立并维护软件项目产品的完整性。在CMM标准中，明确规定了软件配置管理(SCM)以及变更请求管理(CRM)的相关工作，它包括以下两方面：（1）配置管理的主要工作包括通过创建软件配置管理库、定义配置项(包括需求、分析设计模型、代码、文档、测试用例、测试数据等)以及建立和维护软件
