一、软件质量特性

            商务印书馆四角号码新词典（1978年版）中质量的定义：（1）产品或工作好坏程度；（2）物体中所含物质的多少。本文取第一个定义。

            SW-CMM对质量的定义是：（1）一个系统、组件或过程符合特定需求的程度；（2）一个系统、组件或过程符合客户或用户的要求或期望的程度。

            1983年，ANSI/IEEE STD729给出了软件质量定义[92]：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，它包括：(1) 软件产品质量满足用户要求的程度；(2) 软件各种属性的组合程度；(3) 用户对软件产品的综合反映程度；(4) 软件在使用过程中满足用户要求的程度。

            按照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个子特性，如适合性、准确性、互用性、依从性、安全性、成熟性、容错性、可恢复性、可理解性、易学习性、操作性、时间特性、资源特性、可分析性、可变更性、稳定性、可测试性、适应性、可安装性、一致性和可替换性，但不作为标准。

            Figure 1-2 Class Diagram of Software Quality

            表1-1 用户要求与软件质量特性

            Table 1-1 The User Requirement and Software Quality Characteristic

            上述定义表明，软件质量依赖于软件的内部特性及其组合。为了对软件质量进行度量，首先必须对影响软件质量的要素进行度量，并建立实用的软件质量度量体系和模型。

            在进行软件质量设计时，必须考虑利弊，全面权衡，根据质量需求，适当合理地选择/设计质量特性，并进行评价。

            图1-2给出了上述软件质量特性构成关系的一个扼要说明。软件质量是建筑在用户要求基础上的，所以必须掌握好用户要求与开发过程中逐渐形成的质量特性之间的关系。一般反映到需求规格上的用户要求都属于与功能及性能有关的运行特性，或与修改、变更、及管理有关的维护特性。表1-1表示了这些用户要求与质量特性的关系。经过质量管理的软件开发过程也是逐步实现反映用户所要求的质量要求(quality requirement)的质量特性的过程。图1-3表示在如下的质量管理体系下与软件开发过程中实现质量管理的过程[75]。

            第一步是在费用与期限的制约下将需求规格与质量规格变换成设计书和程序的过程。在这个过程中将使用软件开发技术和开发工具把用户要求的质量特性表现在设计书和程序里。

            第二步是对设计书和程序等各工程开发成果进行评审的过程。评审（review）采用质量检查会也称质量论证会（walkthrough）、质量审查（inspection）等早期检查手段，一般在各工程作业结束后立即进行。参加者是一些和项目有关的技术人员。目的在于尽可能在早期工程（上游工程）阶段发现潜入的软件缺陷，将有缺陷的设计书和程序变换成无缺陷软件。在这一个过程中，如果发现设计书或程序中的缺陷就会导致再设计或再编码的返工作业。

            第三步是对最终开发成果进行测试，将第二步的无缺陷软件变换成既无缺陷又无差错的软件的过程。如果在测试中发现软件差错，和第二步一样也会导致再设计和再编码的返工作业。

            二、软件过程分类

            过程定义：韦氏词典将“过程”定义为“某物生产的操作体系……能导致结束或得到结果的一系列的活动、变革、或操作。”IEEE将“过程”定义为“为实现给定目标所执行的一系列的步骤（IEEE-STD-610）。”

            过程模型的主要作用：过程模型不仅详细规定了在每个阶段的所有任务和活动﹑任务活动之间的层次时序关系，还制定了在软件开发和演化中各个阶段的时序和约束条件，建立了从一个阶段进入下一个阶段的过渡准则。同时，它还确定了软件开发过程中所应遵守的“策略”或限制。过程模型还有利于软件开发中各类人员之间的有效通信和过程重用，支持过程演化，便于过程管理。

            软件过程：软件开发人员开发和维护软件及相关产品(如项目计划、设计文档、代码、测试用例和顾客手册)的一套行为、方法、实践和转化过程。

            理想的过程模型的标准：(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)。

            例题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 软件开发管理技术及其评价内容

            管理技术 评价内容

            *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是软件开发管理过程的活动图。

            （1）目标(target)：以用户要求和开发方针为依据，对质量需求准则、质量设计准则中的各质量特性设定质量目标。对各准则的重要程度可以设定“特别重要”、“重要”、“一般”3级。

            （2）计划(plan)：设定适用于被开发软件的评测检查项目，与此同时还要研讨实现质量目标的方法和手段。

            （3）执行(do)：在开发标准和质量评价准则的指导下，制作高质量的规格说明书。在接受质量检查之前要先做自我检查。

            （4）检查(check)：按计划阶段设定的质量评价准则进行评价，算出得分，用质量图的形式表示出来。对比评价结果的质量得分和质量目标，看软件是否合格。

            （5）改善(action)：对评价发现的问题进行改进，如果改进实现并达到了质量目标，接转入下一个工程阶段。

            三、软件过程管理国外发展情况

            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 1.1版本推出后，又推出了SW-CMM 2.0草案。目前，取消了单独的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倍。该公司所开发的产品在成熟度提升前每千条指令出错率约为0.31条，提升后仅为0.03条。

            国外主要软件质量/软件过程研究组织和机构：

            美国卡内基•梅隆大学软件工程研究所(Carnegie Mellon University/ Software Engineering Institution CMU/SEI) 成立于1984年，其长期目标是能够更好、更快和更便宜地预测美国国防部软件密集系统的获取、开发和维护。SEI认为软件学科的特点是可预测性：可预测的成本、可预测的进度、可预测的质量和可预测的功能。SEI的义务是使软件工程进化，使其从专门的、劳动密集的、个人英雄主义的活动中解脱出来。总之，SEI寻求的是依赖于软件的系统能按可预测的方式获取、开发和进化。Web站点www.sei.cmu.edu。

            软件工程实验室（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站点sel.gfsc.nasa.gov。

            软件技术支持中心(Software Technology Support Center, STSC)位于犹他州奥格登的Hill空军基地。成立STSC旨在帮助空军的组织机构标识、评价和采用改善产品质量、生产效率和可预测性的技术。采用术语技术(term technology)，从最广泛的意义上包括提高人类能力的过程、方法、技术和工具，STSC关注对 DoD任务有益的领域已证实的技术。STSC除了提供支持和咨询服务外，还出版CrossTalk  The Journal of Defense Software Engineering。Web站点www.stsc.hill.af.mil.org。

            软件生产率集团(Software Productivity Consortium, SPC) 是一个包括产业界、政府部门和学术界在内的非赢利的联合体。因为有90多个会员公司，SPC提供了改善系统和软件的质量、可靠性和上市时间性能所需要的技术和专门知识。SPC的技术计划适用于集成基于本质过程的集成化系统和软件开发活动。SPC提供了各种改善模型和方法的课程，包括软件CMM和CMMI、度量和软件工程技术、集成化系统和软件过程开发。  SPC提供了评估和咨询服务，还出版季刊时事通讯并发表其它与系统工程、软件工程、系统和软件集成以及过程改进有关的技术性文章。Web站点www.software.org。

            国际系统工程咨询委员会(International Council on Systems Engineering, INCOSE) 是国际性的非赢利组织，目的是为多学科系统产品的开发制定、发展和完善系统工程方法。INCOSE成立于1990年，目前已拥有3900多名系统工程专业人士。INCOSE是EIA/IS 731的主要开发者，并为  CMMI项目提供系统工程专家。Web站点www.incose.org。

            电子工业联盟（Electronic Industries Alliance, EIA）是电子与高技术协会和公司的联合体，承担着共享知识和影响的义务。EIA发表了许多标准和技术出版物来为公众利益服务，减少制造商和采购商之间的误会，促进产品的可交换性和改善，以及辅助采购商根据特定的需要快速选购并获得合适的产品。EIA过渡标准，系统工程能力和EIA/IS 731就是CMMI的三个源模型之一。Web站点www.eia.org。

            例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继续改进，目前最新的版本是UML2.0。UML的发明人G.Booch, J.Rumbaugh和I.Jacobson共同认为，提出一种统一的建模语言有以下3个理由：（1）他们各自提出的方法在演化中已经有相互结合的趋势；（2）走向统一将带来市场方面的好处；（3）有助于改进他们各自的学习方法，以获得更多的学习者并解决一些以往他们各自的方法不能很好解决的问题。该建模语言的作者们给出了一种推荐性的建模过程指导，即统一过程（Rational Unified Process，RUP）体现了适合于范围广泛的项目和组织的许多现代软件开发最佳实践。RUP是以用例为驱动、体系结构为中心、迭代和增量的过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流。

            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）配置管理的主要工作包括通过创建软件配置管理库、定义配置项(包括需求、分析设计模型、代码、文档、测试用例、测试数据等)以及建立和维护软件的基线；（2）变更请求管理的主要工作包括控制和记录配置项内容的变更，建立和维护一个系统并使其追踪和管理变更请求及问题报告。

            Rational的ClearCase和ClearQuest是相当成熟的配置管理和变更管理工具，它们已经连续四年被IDC评为业界最佳的配置管理工具。ClearCase的主要作用体现在三个方面：其一，帮助项目组利用版本对象库(VOB)完整地保存整个项目的开发历史，实现对软件资产的有效管理；其二,利用版本对象库(VOB)的安全机制，灵活地控制不同人员对不同配置项的检出和读取的权利，有效地保护企业的核心机密；第三，帮助团队实现并行开发，避免合并版本等工作阻碍其他开发工作，保证项目进度。

            ClearQuest的主要作用是加强开发团队与外界的沟通，用户、测试人员与市场销售人员可以直接通过Web提交变更请求,包括缺陷或功能扩充请求。

            可以毫不夸张地说，配置管理和变更管理是软件工程的基础。ClearCase和ClearQuest除了对CMM2级的“软件配置管理”KPA有帮助外，还可以对以下KPA提供帮助：“需求管理”、“软件项目跟踪与监督”、“软件质量保证”、“软件产品工程”以及“定量过程管理”。

            5. 测试工具

            “软件质量保证”是CMM2级中另一个重要的KPA，软件测试水平的高低直接影响软件产品质量的好坏与开发周期的长短。综观现阶段诸多软件开发组织在软件测试方面的状况，不难发现，多数组织存在以下问题：（1）没有进行单元测试，或单元测试不彻底；（2）由于需求不准确，导致测试缺乏计划；（3）测试工作大多依赖手工进行，没有有效的自动化测试工具，致使软件测试效率低下,测试周期较长，不能在软件开发的各个周期进行完整的测试；（4）缺乏有效的跟踪机制跟踪解决软件测试中发现的缺陷,致使有的问题得不到及时、恰当的解决。

            针对这些问题,Rational提供了一系列测试工具，帮助用户解决上述问题。这些工具包括用于单元测试的RQA(Rose Quality Architect)、Purify、Pure Coverage和Quantify 以及用于测试管理、回归测试和性能管理的Rational TeamTest。

            特别需要说明的是回归测试。目前，对大型软件系统来说，迭代式开发已经成为一种主流的开发模式，需要在开发的每个迭代周期内对软件功能进行确认,这就是回归测试。如果依靠人工测试的办法，这将是一个烦琐、耗时的过程。Rational TeamTest采用面向对象的记录技术，将对系统的功能测试动作记录在测试脚本中，当系统进入下一个迭代周期时，只需回放这个测试脚本，就可以自动地进行软件功能的确认，这种方法可以极大地提高软件测试的效率，保证软件功能测试的完整性。

            以上工具可以单独使用，解决个别问题，但是对于一个想在CMM实施中获得较高级别评估的软件组织来说，则需要尽可能广泛地进行有效的规划与部署,将这些工具有机地结合起来,满足企业在软件质量方面的较高要求。为此，Rational提供了一个完整的解决方案—TestStudio，它包括用于单元测试的PQC(Purify、Quantify、Pure Coverage)、提供全面功能测试和性能测试的TeamTest、进行差错跟踪的ClearQuest，以及一些对软件开发管理提供支持的基础工具,并将这些工具紧密地结合在一起。

            例7，填空题

            RUP是一种大多数软件项目软件开发组织都能适用的形式，它吸取了软件开发中的最佳实践（Best Practice），具有下面五个特性：（1）用例驱动（Use case driven）；（2）以架构为中心（Architecture centric）；（3）迭代式软件开发（Iterative）；（4）增量式软件开发（Incremental）；（5）可控式软件开发（Controlled）。

            从技术角度来讲RUP规定了6个过程成分：（1）业务建模（business modeling）；（2）需求分析（requirement  analyse）；（3）系统分析与设计（system analysis and design）；（4）实现（implementation）；（5）测试（testing）；（6）系统配置（system configuration）。

            RUP把软件项目开发过程划为4个阶段；（1）开端阶段（inception）；（2）精化阶段（elaboration）；（3）构建阶段（construction）；（4）过渡阶段（transition）。

            五、IDEAL模型

            1、IDEAL模型概念

            软件过程能力成熟度模型（Software Capability Maturity Model，SW-CMM）是美国卡内基•梅隆大学软件工程研究所SEI(Software Engineering Institution)从1986年开始研究并完成的，它侧重于对软件开发过程和开发方法论的考察。CMM包括5级：初始级(Initial)，2级：可重复级(Repeatable)，3级：已定义级(Defined)，4级：已管理级(Managed)，5级：优化级(Optimizing)。CMM则提供了一整套较为完善的软件研发项目管理的方法。美国先后在这上面投资了5亿多美元，做了很多实践工作来改进软件研发项目管理，而且其内容还在不断地改进，SW-CMM 1.1版本推出后，又推出了SW-CMM 2.0草案。目前，已取消了单独的CMM，正在开发CMMI，其模型包括CMMI-SW、CMMI-SE、CMMI-SE/SW、CMMI-SE/SW/IPPD。

            SEI又与HP公司合作，提出了实施SW-CMM的IDEAL模型。IDEAL模型是一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating(启动)、D代表Diagnosing(诊断)、E代表Establishing(建造)、A代表Acting(实施)、L代表Learning(学习)。图5-1是详细的IDEAL五阶段模型。其中：启动—获得改进的支持和责任；诊断—确定改进范围；建立—选择和计划特定的改进活动；实施—设计、指导、实现以及改进制度化；学习—确定基于IDEAL模型的改进活动。

            图5-2说明了IDEAL模型的两维结构，它处理过程改进中的两种不同操作级别：

            战略级：这些过程主要是高层领导的责任。

            战术级：这些过程主要由产品线经理和参与者执行。

            图5-3说明支持软件过程改进（Software Process Improvement, SPI）的因素。其中基础设施能够在需要时提供资源；对工作的方向、范围和进度提供建议;为SPI程序顺利前进排除障碍。其目的是维持SPI程序的可视性；方便和鼓励信息共享；抓住和保存经验教训并发展改进；提供支持网络。

            2、IDEAL模型各个阶段

            2.1启动阶段

            启动阶段要学习过程改进，约定启动资源并建立过程基础设施。最主要的是建立管理操作组（Management  steering  group, MSG）,软件工程过程组（Software Engineering  Process  Group, SEPG）。常常形成一个问题发现小组(Discovery Team)研究有关议题（Issues），并开发软件过程(Software Process Improvement, SPI)改进建议给高层管理者。

            启动阶段任务如下：1）开始；2）识别改进的商业需要和推动者；3）建立SPI提议；4）教育和建立支持；5）获得SPI提议的批准和启动资源；6）建立软件过程改进基础设施；7）评估SPI的情况（Climate）；8）确定SPI总的目标；9) 确定SPI程序的指导原则；10)正式启动。

            2.2 诊断阶段

            诊断阶段建立当前过程的成熟度，过程说明，度量等等，并启动行动计划的开发。

            诊断阶段任务如下：1）确定需要的基准（Baselines）；2）基准计划；3）指导（Conduct）基准；4）结果(Findings)展示；5）开发最终结果和建议报告；6）与组织就最终结果和建议报告进行沟通。

            2.3 建立阶段

            建立阶段建立目标和优先权，完成行动计划的开发。

            建立阶段任务如下：1）选择和得到战略规划过程的培训；2）评审组织愿景(Vision)；3）评审组织的商业计划；4）确定关键商业议题；5）评审过去的改进工作；6）说明改进的动机；7）确定当前和将来的改进工作；8）确定不同基础设施实体的角色和责任；9）确定改进活动和开发议题的优先级；10)协调在基准结论和建议内已有和计划的改进工作；11)将一般的SPI目标变成特定的可度量的目标；12）建立和更新SPI战略计划；13）建立审计、评审，并批准SPI战略计划，约定行动的资源。14）形成技术工作组（Technical  Working  Group, TWG）。

            2.4 行动阶段

            行动阶段研究和开发过程问题的解决方案，并扩展成功的过程改进到整个组织。

            行动阶段任务如下：1）完成TWG的具体计划；2）开发解决方案；3）试验有潜力的解决方案；4）选择解决方案提供商；5）确定长期的支持需要；6）开发首次（Rollout）实行的战略和计划的模板；7）整理改进（模板）并交给SEPG；8）解散TWG；9) 首次实行解决方案；10)转移到长期支持。

            2.5 学习阶段

            学习阶段准备再次通过IDEAL模型，应用学到的经验教训完善SPI过程。

            学习阶段任务如下：1）收集学到的经验教训；2）分析学到的经验教训；3）修改组织方法；4）评审保证人和约定；5）建立高级的目标；6）开发新的/修改的SPI提议；7）继续进行SPI。

            2.6 管理软件过程改进

            对改进过程提供监督并解决相应的问题。

            管理软件过程改进任务如下：1）设置软件过程改进的阶段(SPI)；2）组织SPI程序；3）计划SPI程序；4）SPI程序人员组织；5）监督SPI程序；6）指导SPI程序。

            在大多数情况下由三个部分组成了SPI的组织基础设施（见图5-4）：

            1.软件工程过程组（SEPG）；2.管理指导组（MSG）；3.技术工作组（TWG）。

            第一位并且最重要的是SEPG，有时叫作过程组。SEPG在SPI程序中为组织执行许多功能。SEPG可以：有利于在环境变化时对SPI程序提供持续的支持；建立和加强与保证人的关系；培育和持续个人的改进活动；保证在全组织内协调这些活动。

            由MSG任命SEPG。任命书作为管理层和SEPG的协议。提出任命书概括出SEPG的角色、责任和权威。任务是建立MSG；建立SEPG；开发SEPG（MSG）的任命书；向保证人演示改进活动；开发TWGs的任命书模板

            3、IDEAL模型与PDCA周期

            巴西电信公司（NEC do Brassil, NDB）在实施SPI时采用了PDCA周期[3]：其中P代表Plan(计划)、D代表Do(行动)、C代表Check(检查)、A代表Act(实施)。采用PDCA周期的理由是：（1）PDCA周期与客户驱动质量管理概念中建立的连续改进结构一致；（2）PDCA周期实践和术语已经在NDB中制度化了；（3）PDCA周期包括了绝大多数IDEAL的目标需求。

            基于IDEAL模型与PDCA周期的分析和剪裁，SPI可以结构化为如下阶段（表5-1）

            表5-1  SPI的PDCA周期

            信息和数据输入 信息和数据源应该用于改进过程，也能够用于SW-CMM评估过程或者客户驱动管理过程

            改进计划P 软件工程质量组（SEQT）和SEPG负责评审数据/信息，建立和记录告诉的行动计划已经在各个领域展开

            改进执行D SEQT和SEPG负责执行、跟踪和监督行动计划。该阶段，要将必要的信息送去评审

            验证和评审C 在涉及和综合领导（公司和关键域质量委员会）、SEQT及SEPG层次上进行评审

            实施A 实现系统变化和完成评审后的目标，为制度化和软件质量管理而标准化过程

            4、提高CMM的级别的ICASE模型

            ICASE是一个基本的系统开发过程改进模型，软件开发组织可以用来达到其希望提高CMM的级别的目的。其中I代表Investigation(调查)：即调查组织的系统开发过程的现有状态；C代表Construction建立：即在组织内部建立一种意识，使开发人员和管理人员进入改进系统开发过程的概念中；A代表Action行动：即在组织中对必须要求的过程改进行动建立一张清单；S代表Selection选择：即选择一个计划以达到要求的行动；E代表Execution执行：即提交执行的计划必须的资源。

            最后，当开始不断在CMM级别进行改进时，重复这一过程。

            5、CMM实施方法论的若干讨论

            中国哲学讲阴阳，讲和谐，讲平衡。讲和谐讲平衡不是不想前进，和谐就是有运动才能发出声响的东西。平衡更是非同小可，在运动中需要格外讲究。譬如滑冰，向前滑行了就必须寻找平衡，只讲前进不找平衡，一定跌倒。要不断前进就必须不断寻找平衡，平衡与和谐就是前进的主旋律。

            软件过程是关系错综复杂的各种活动的集合，各活动之间有时有严格的时序关系，有时是异步并行的，有时互为条件，有时互为反馈，因此实际的软件过程中的活动存在一种复杂的网状关系。软件开发是一个高度动态的过程，动态变化渗透到了软件过程的各个方面：需求说明、任务分配、调试、开发策略、工具集、支持环境等，这些变化的出现通常不可预料，造成的影响也无法确定。同时，软件过程是一个面向人的系统，而软件本身又是一种无形的产品，这就导致了工作进度难以控制，工作质量难以评估，使整个过程有极大的模糊性。我们认为SW-CMM的对策是：无规矩不成方圆（按部就班写文档）；不积跬步无以至千里（积小成多，量变到质变）；平衡与和谐（循序渐进，稳中求变，有序和创造相统一），似乎应该再加上适者生存（市场复杂多变，项目管理与战略管理相结合，知识管理）。我们认为对我国软件企业，技术和管理要一起抓，国外大学开设信息技术管理学院似乎较我国普遍采用的电子商务学院更有效和更实在。此外，CMM也不是全能的，我们从美国和印度的情况中发现它较适合用户定制的大型软件应用系统和软件出口，似乎不太适应以软件产品占领市场的软件公司，例如金山和北大方正。微软公司的哲理是追求高度灵活，企图把一种松散（有时称hacker）组织成的小组风格提升成正规的产品开发就是证明。因此，如何增强CMM灵活性也应该认真研究，这对目前中国软件企业也很重要。中国软件企业现在最欠缺的就是管理以及有创新思维的人才。是否能够像培养MBA那样，采取大量培养IT技术管理的将才，让这些将才在全球市场经济的竞争中自学成帅，以改变中国IT界“兵多将少没有帅”的局面？

            我们在研究中初步发现能力形成过程中有两点值得重视，现提出共同探讨：其一是学习方式的变化，早期以农业经济为主，人类知识总量也较少，学习主要是增加知识数量；随着人类知识总量的增加和工业化的发展，有效地发挥所学的知识作用就显得重要了，要学以致用；近年来，随着信息技术和互联网迅速发展，人类知识总量爆炸式地增加，为适应经济全球化的复杂多变环境，就要求掌握知识发展学习能力和基础素质，基础素质又反过来发展学习能力，信息时代必须重视终身学习、实时学习、高效学习再加上组织学习，要温故而创新。其二是通识能力的培养：就是要见多识广，这就必须要打通古今中外、科学和文化、科技和经济以及各行业的隔阂和藩篱，以达“海阔凭鱼跃，天高任鸟飞”的境界。

            例8，填空题

            SEI与惠普公司（Hewlett-Packard Corp.）合作，提出了实施SW-CMM的IDEAL模型。IDEAL模型是一个单位用于启动、规划和实现过程改善措施蓝图的模型，概括了建立一个成功的过程改善项目的必要步骤，其中I代表Initiating(启动)、D代表Diagnosing(诊断)、E代表Establishing(建造)、A代表Acting(实施)、L代表Learning(学习)。IDEAL模型要求的支持软件过程改进（Software Process Improvement, SPI）基础设施的四个目的是：（1）维持SPI程序的可视性（Maintain Visibility）;（2）方便和鼓励信息共享（Facilitate and Encourage Information Sharing）;（3）抓住和保存经验教训并发展改进（Capture and Retain Lessons Learned and Improvements Developed）;（4）提供支持网络（Provide a Support Network）。

            IDEAL模型启动阶段任务如下：1）开始；2）识别改进的商业需要和推动者；3）建立SPI提议；4）教育和建立支持；5）获得SPI提议的批准和启动资源；6）建立软件过程改进基础设施；7）评估SPI的情况（Climate）；8）确定SPI总的目标；9) 确定SPI程序的指导原则；10) 正式启动。