系统分析师学习笔记（九）

软件工程

IEEE对软件工程的定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。

软件工程由方法、工具和过程三个部分组成。

软件生命周期

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生命周期或生存周期。

1.软件生存周期过程

（1）基本过程。基本过程供各主要参与方在软件生存周期期间使用，主要参与方是发起或完成软件产品开发、运行或维护的组织。基本过程分为获取过程、供应过程、开发过程、运作过程和维护过程。
（2）支持过程。支持过程作为一个有机组成部分支持其他过程，以便取得软件项目的成功，并提高软件项目的质量。支持过程包括文档编制过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审核过程、问题解决过程和易用性过程，根据需要，支持过程可被其他过程应用和执行。
（3）组织过程。组织过程可被某个组织用来建立和实现由相关的生存周期过程和人员组成的基础结构并不断改进这种结构和过程。组织过程包括管理过程、基础设施过程、改进过程、人力资源过程、资产管理过程、重用大纲管理过程和领域工程过程。

2.软件生命周期各阶段的任务

（1）可行性研究和项目开发计划。通过分析用户提出的软件开发要求，确定软件项目的性质、目标和规模，得出可行性研究报告。如果可行性研究的结果是可行的，就要制订详细的项目开发计划。这两个活动通常被整合在一起进行，在实际工作中通常把它们归类到同一个阶段中。
（2）需求分析。需求分析工作是软件生命周期中重要的一步，也是决定性的一步。只有通过需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。
（3）概要设计。根据软件需求规格说明建立软件系统的总体结构和模块间的关系，定义各功能模块接口，设计全局数据库或数据结构，规定设计约束，制定组装测试计划。
（4）详细设计。将各模块要实现的功能用相应的设计工具详细描述出来。
（5）实现。写出正确的、易理解的和易维护的程序模块。程序员根据详细设计文档将详细设计转化为程序，完成单元测试。
（6）组装测试（集成测试）。将经过单元测试的模块逐步进行组装和测试。
（7）确认测试。测试系统是否达到了系统需求，按照规格说明书的规定，由用户（或在用户积极参与下）对系统进行验收。必要时，还可以再通过现场测试或并行运行等方法对系统进行进一步的测试。
（8）使用。将软件安装在用户确定的运行环境中，测试通过后移交用户使用。在软件的使用过程中，客户和维护人员必须认真收集发现的软件错误，定期或阶段性地撰写软件问题报告和软件修改报告。
（9）维护。通过各种必要的维护活动使系统持久地满足用户的需要。
（10）退役。终止对软件产品的支持，软件停止使用。

软件开发方法

形式化方法

1.形式化方法概述
形式化规格说明语言包括严格的语法定义和语义定义，以及一系列的数学推演规则。这些规则不仅说明了某些数学性质在软件规格说明中是否成立，也说明了软件实现与软件规格说明之间的满足关系。

近年来，形式化方法在以下两个方面的发展大大改善了其实用性：

（1）形式化方法与图形语言机制相结合。为图形语言机制赋予形式化的语法和语义，从而兼具了图形表示的直观、简洁，以及形式化方法的严谨、精确等优点。
（2）用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具支持形式化软件开发。CASE工具不仅可以简化描述工作，而且还可以利用自动证明技术，帮助开发人员验证软件的数学性质。

2.净室软件工程
净室软件工程（Cleanroom Software Engineering，CSE）是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构归约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。

CSE的理论基础是函数理论和抽样理论，所采用的技术手段主要有以下四个方面：

（1）统计过程控制下的增量式开发。
（2）基于函数的规范、设计。CSE按照函数理论定义了三种抽象层次，分别是行为视图、有限状态机视图和过程视图。规范从一个外部行为视图（称为黑盒）开始，然后被转化为一个状态机视图（称为状态盒），最后由一个过程视图（明盒）来实现。盒结构是基于对象的，并支持软件工程的关键原则，即信息隐藏、接口与实现分离。
（3）正确性验证。正确性验证是CSE的核心，正是由于采用了这一技术，软件质量才有了极大的提高。
（4）统计测试和软件认证。CSE在测试方面采用统计学的基本原理，即当总体太大时必须采取抽样的方法。首先，确定一个使用模型来代表系统所有可能使用的（一般是无限的）总体；然后，由使用模型产生测试用例。因为测试用例是总体的一个随机样本，所以可得到系统预期操作性能的有效的统计推导。

CSE的主要缺点体现在以下三个方面：

（1）对开发人员的要求比较高。CSE要求采用增量式开发、盒结构和统计测试方法，开发人员必须经过强化训练才能掌握。
（2）正确性验证的步骤比较困难，且比较耗时。
（3）开发小组不进行传统的模块测试，这是不现实的。程序员可能对编程语言和开发环境还不熟悉，而且编译器或操作系统的缺陷也可能导致未预期的错误。

逆向工程

软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。

1.相关概念
与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。

（1）重构（restructuring）。重构是指在同一抽象级别上转换系统描述形式。
（2）设计恢复（design recovery）。设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。
（3）再工程（re-engineering）。再工程是指在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。
（4）正向工程（forward engineering）。正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或重构现有系统，以改善其整体质量。

2.完备性
一般认为，凡是在软件生命周期内将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。逆向工程的完备性可以用在某一个抽象层次上提供信息的详细程度来描述。

逆向工程过程应该能够导出过程的设计模型（实现级，一种底层的抽象）、程序和数据结构信息（结构级，稍高层次的抽象）、对象模型、数据和控制流模型（功能级，相对高层的抽象）和UML状态图和部署图（领域级，高层抽象）。随着抽象层次增高，完备性就会降低。抽象层次越高，它与代码的距离就越远，通过逆向工程恢复的难度就越大。

软件开发模型

软件开发模型概述

1.瀑布模型
瀑布模型是一种严格定义方法，它将软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段，形如瀑布流水，最终得到软件产品。

瀑布模型是一个线性顺序模型，支持直线开发。它假设当线性序列完成之后就能交付一个完善的系统，并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划及需求调查和产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做什么，有利于项目管理。

在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

2.演化模型
演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上，根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本，重复这一过程，直到演化成最终的软件产品。

演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求，可以帮助导引出高质量的产品要求。其主要缺点是，如果不加控制地让用户接触开发中尚未稳定的功能，可能对开发人员及用户都会产生负面的影响。

3.螺旋模型
螺旋模型是瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件开发模型。在螺旋模型中，软件开发是一系列的增量发布。螺旋模型沿着螺线进行若干次迭代，每次迭代都包括制订计划、风险分析、实施工程和客户评估四个方面的工作。

4.喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。在喷泉模型中，各活动之间无明显边界，例如，分析和设计之间没有明显的边界。这种特性称为无间隙性。

5.变换模型
变换模型是基于形式化规格说明语言和程序变换的软件开发模型，它对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机能够接受的软件系统。

程序变换是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和改进阶段。

变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（例如，设计、编码和测试等）。但是，变换模型仍有较大局限，以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持。

6.智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在一起。该模型应用基于规则的系统，采用规约和推理机制，帮助开发人员完成开发工作，并使维护在系统规格说明一级进行。

7.V模型
V模型是在快速应用开发模型基础上演变而来，由于将整个开发过程构造成一个V字形而得名。V模型应用在软件测试方面，和瀑布模型有着一些共同的特征。V模型中的过程从左到右，描述了基本的开发过程和测试行为，其价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系。

快速应用开发

快速应用开发（Rapid Application Development，RAD）是一种比传统生命周期法快得多的开发方法，它强调极短的开发周期。

1.RAD的基本思想

（1）让用户更主动地参与到系统分析、设计和构造活动中来。
（2）将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分析师、设计人员和开发人员一起参与。
（3）通过一种迭代的构造方法，加速需求分析和设计阶段。
（4）让用户提前看到一个可工作的系统。

2.RAD的开发阶段
RAD的流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。

（1）业务建模。确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向及其处理等，可以使用数据流图来帮助建立业务模型。
（2）数据建模。为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其他数据对象的关系构成数据模型，可以使用E-R图来帮助建立数据模型。
（3）处理建模。将数据对象变换为要完成一个业务功能所需的信息流，创建处理以描述增加、修改、删除或获取某个数据对象，即细化数据流图中的加工。
（4）应用生成。利用第四代语言（4GL）写出处理程序，复用已有构件或创建新的可复用构件，利用环境提供的工具自动生成并构造出整个应用系统。
（5）测试与交付。因为RAD强调复用，许多构件已经是测试过的，这就减少了测试的时间。由于大量复用，所以一般只做总体测试，但新创建的构件还是要测试的。

3.RAD的特点
RAD采用基于构件的开发方法，复用已有的程序结构（如果可能的话）或使用构件，或者创建可复用的构件（如果需要的话）。在所有情况下，均可以使用CASE工具辅助进行软件构建。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到三个月的时间内完成，那么，它就是RAD的一个候选者。每个主要功能可由一个单独的RAD组来实现，最后再集成起来，形成一个整体。

RAD也具有以下局限性：

（1）并非所有应用都适合RAD。RAD对模块化要求比较高，如果有哪一项功能不能被模块化，那么RAD所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则RAD也有可能不能奏效。
（2）开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致RAD项目失败。
（3）RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统要与现有系统有较高的互操作性时，就不适合使用RAD。

统一过程

统一过程（Unified Process，UP）是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的，在为软件系统建模时，UP使用的是UML。与其他软件过程相比，UP具有三个显着的特点，即用例驱动、以架构为中心、迭代和增量。

1.RUP概述
RUP（Rational Unified Process）将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。RUP可以增强开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间。

RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和移交阶段。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。

基于RUP的软件过程是一个迭代过程。通过初始、细化、构建和移交四个阶段就是一个开发周期，每次经过这四个阶段就会产生一代软件。除非产品退役，否则通过重复同样的四个阶段，产品将演化为下一代产品，但每一次的侧重点都将放在不同的阶段上。

2.初始阶段
初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。初始阶段的实现过程如下：

（1）明确项目规模。建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的需求和约束，识别系统的关键用例。
（2）评估项目风险。软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的迭代式软件过程中，很多决策要受风险决定。要达到这个目的，开发人员需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略。
（3）制订项目计划。估计整个项目的总体成本、进度和人员配备。综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源。在这个过程中，要通过对一些概念的证实来证明可行性，可以采用可模拟需求的模型形式或用于探索高风险区的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶段和构建阶段。
（4）阶段技术评审。初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进度估算是否适中、估算根据是否可靠、需求是否正确、开发方和用户方对软件需求的理解是否达成一致、是否已经确定所有风险且有针对每个风险的规避策略等问题。

3.细化阶段
细化阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。细化阶段的实现过程如下：

（1）确定架构。确保架构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。通过处理架构方面重要的场景，建立一个已确定基线的架构，并验证其将在适当时间、以合理的成本支持系统需求。
（2）制订构建阶段计划。为构建阶段制订详细的过程计划并为其建立基线。
（3）建立支持环境。包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。
（4）选择构件。评估现有的构件库和潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。
（5）阶段技术评审。评审时，需要检验详细的系统目标和范围、架构的选择，以及主要风险的解决方案。

4.构建阶段
在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件作好准备。

5.移交阶段
当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品。

RUP由于太过于庞大和复杂，相对于轻量级的敏捷方法来说，显得死板和难以实施。RUP不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和很多额外的工作。

敏捷方法

敏捷方法强调，让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。

2.敏捷方法的特点
敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷方法中，软件项目的构建被切分成多个子项目，各个子项目成果都经过测试，具备集成和可运行的特征。

虽然敏捷方法发展得较快，但在实施的过程中，也暴露出来很多问题，一些敏捷方法的基本原则很难实施，主要体现在以下四个方面：

（1）客户参与往往依赖于客户参与的意愿和客户自身的代表性。
（2）团队成员的性格可能不适合激烈的投入，可能无法做到与其他成员之间的良好沟通。
（3）对系统的变更作出优先级排序可能是极端困难的。
（4）维护系统的简洁性往往需要额外的工作，但迫于时间表的压力，可能没有时间执行系统简化过程。

敏捷方法在几周或几个月的时间内完成相对较小的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增强，并且更加强调团队中的高度协作。相对而言，敏捷方法主要适用于以下场合：

（1）项目团队的人数不能太多，适合于规模较小的项目。
（2）项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较高的关键性、可靠性、安全性方面的要求，则可能不完全适合。
（3）高风险项目的实施。
（4）从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人员所作的决定得到认可、环境设施满足团队成员之间快速沟通的需要。

3.XP方法
敏捷方法中最着名的就是XP，XP是一种轻量、高效、低风险、柔性、可预测、科学且充满乐趣的软件开发方式，适用于小型或中型软件开发团队，并且客户的需求模糊或需求多变。与其他方法相比，其最大的不同如下：

（1）在更短的周期内，更早地提供具体、持续的反馈信息。
（2）迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展它。
（3）依赖于自动测试程序来监控开发进度，并及早地捕获缺陷。
（4）依赖于口头交流、测试和源程序进行沟通。
（5）倡导持续的演化式的设计。
（6）依赖于开发团队内部的紧密协作。
（7）尽可能达到程序员短期利益和项目长期利益的平衡。

XP由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。XP的核心是其总结的4大价值观，即沟通、简单、反馈和勇气。XP的5个原则是快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

在XP中，集成了12个最佳实践，分别是计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户和编码标准。

软件开发环境与工具

软件开发环境（Software Development Environment，SDE）是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。软件工具是指CASE工具，用以支持软件开发的相关过程、活动和任务；环境集成机制是指为工具集成和软件开发、维护及管理提供统一的支持。

软件开发环境

1.软件开发环境的分类
软件开发环境可按以下几种角度进行分类：

（1）按软件开发模型与开发方法分类，有支持瀑布模型、演化模型、螺旋模型和喷泉模型等不同模型，以及结构化方法、面向对象方法等不同方法的软件开发环境。
（2）按功能与结构特点分类，有单体型、协同型、分散型和并发型等多种类型的软件开发环境。
（3）按应用范围分类，有通用型和专用型软件开发环境。其中专用型软件开发环境与应用领域有关。
（4）按开发阶段分类，有前端开发环境（支持系统规划、分析、设计等阶段的活动）、后端开发环境（支持编程、测试等阶段的活动）、软件维护环境和逆向工程环境等。

2.集成机制
集成机制根据功能的不同，可划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。

（1）环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如，分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，例如，文档模板、系统配置、过程模型和可复用构件等。
（2）过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成是按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
（3）环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

3.集成计算机辅助软件工程
ICASE（Integrated Computer-Aided Software Engineering，集成计算机辅助软件工程的信息库不仅定义了面向对象的数据库管理系统，提供了数据-数据集成机制，还建立了可以被环境中所有工具访问的数据模型，提供了数据-工具集成机制，实现了配置管理功能。

软件开发工具

1.软件工具的分类
在软件生命周期中，要使用很多软件工具，从其功能上进行划分，可以分为软件开发工具、软件维护工具、软件管理和支持工具三类。

（1）软件开发工具。软件开发工具用来辅助开发人员进行软件开发活动，包括需求分析工具、设计工具、编码与排错工具等。
（2）软件维护工具。软件维护工具用来辅助维护人员对软件代码及其文档进行各种维护活动，包括版本管理工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等。
（3）软件管理和支持工具。软件管理和支持工具用来辅助管理人员和软件支持人员的管理活动和支持活动，以确保软件高质量的完成。包括项目管理工具、配置管理工具和软件评价工具等。

2.开发工具的选择
简单地说，开发工具的选择主要决定于两个因素，分别是所开发系统的最终用户和开发人员。最终用户需求是一切软件的来源和归宿，也是影响开发工具的决定性因素；开发人员的爱好、习惯和经验也影响着开发工具的选择。

3.快速开发工具
在RAD方法中，所包括的工具主要有数据库编程语言、界面生成器和报告生成器等。RAD工具主要使用可视化技术。可视化技术是一种通过集成细粒度可复用构件来构造软件的一种方法，其主要思想是用图形工具和可复用构件来交互地编制程序。

软件过程管理

软件产品的质量取决于软件过程，具有良好软件过程的组织能够开发出高质量的软件产品。

软件能力成熟度模型

软件能力成熟度模型（Capability Maturity Model，CMM）是一个概念模型，模型框架和表示是刚性的，不能随意改变，但模型的解释和实现有一定弹性。CMM提供了一个软件能力成熟度的框架，它将软件过程改进的步骤组织成五个成熟度等级，为软件过程不断改进奠定了一个循序渐进的基础。

1.CMM的等级

（1）初始级。初始级是未加定义的随意过程，软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。
（2）可重复级。可重复级是规则化和纪律化的过程，软件过程已建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
（3）已定义级。已定义级是标准的和一致的过程，用于管理的和工程的软件过程均已文档化、标准化，并形成了整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。
（4）已管理级。已管理级是可预测的过程，软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
（5）优化级。优化级是持续改进的过程，通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续性地对过程进行改进。

2.关键过程域
除初始级以外，CMM的每个级别的实现都定义成可操作的，每一级包含了实现这一级目标的若干关键过程域（Key Process Area，KPA）。每个KPA都是由关键实施活动（Key Practices，KP）所组成，它们的执行表明该KPA在一个组织内部得到实现。

3.能力成熟度模型集成
能力成熟度模型集成（Capability Maturity Model Integration，CMMI）融合了多种模型，形成了组织范围内过程改进的单一集成模型，其主要目的是消除不同模型之间的不一致和重复，降低基于模型进行改进的成本。

（1）阶段式模型。阶段式模型基本沿袭CMM模型框架，仍保持五个成熟等级，但关键过程域做了一些调整和扩充
（2）连续式模型。与阶段式模型相比，连续式模型没有与组织成熟度相关的几个阶段。连续式模型将24个过程域按照功能划分为过程管理、项目管理、工程和支持四个过程组。

软件过程评估

1.CMM模型
基于CMM的评估方法分为以下六个步骤：

（1）成立评估小组，小组由软件工程和管理工作经验丰富的专家组成，小组成员应接受过CMM基本概念和评估方法的专门培训。
（2）参评单位的代表认真填写成熟度问卷表，并回答有关问题。
（3）评估小组分析调查问卷。
（4）评估小组现场访问、召开座谈会、审核过程文档，判断KPA的实践活动是否达到预定目标，并将结论记入文档。
（5）整理调查结果，撰写调查报告，指明软件过程的强项和弱项。
（6）绘制KPA剖面图，显示是否达到KPA的目标，并向有关部门提交评估的结论性意见。

2.Trillum模型
Trillum模型的主要特点如下：

（1）模型的架构建立在路线图的基础上。
（2）模型不仅适用于软件，同时适用于硬件。
（3）模型强调以用户为关注的焦点。
（4）模型包括技术成熟度，主要面向通信产品。

3.Bootstrap 方法
Bootstrap引用了ISO 9000-3和ESA PSS-05等软件标准，设计了非常详细的过程质量属性结构，包括组织资源管理、测试方法和生命周期技术等17个属性，改进了CMM的问卷表和成熟度计算方法，使其可用于过程每一个质量属性，从而得到一个过程质量剖面。Bootstrap 可适用于各类软件组织，在欧洲有很大的影响。

4.ISO/IEC 15504标准
ISO/IEC 15504分为九个部分，分别是概念与介绍指南、过程与过程能力的参考模型、实施评估、评估实施指南、一个评估模型和指示指南、评估员资格认证指南、过程改进应用指南、判断供应商过程能力指南和词汇表，其中第一部分是资料，第二部分和第三部分是标准，其他部分都是参考性的。

在ISO/IEC 15504中，能力等级是针对每个过程的，它定义了6级过程性能，每一级都用主要的过程特征术语和用于性能测量的属性来进行描述。

（1）不完善的过程。在这个级别上通常不能成功地实现过程的目的。
（2）已实施的过程。通常能够达到过程的目标，但过程并未遵循严格的计划且未被跟踪。
（3）已计划与已跟踪的过程。过程在规定的时间和资源内交付出质量合格的工作产品，根据规程所展开的实施活动是有计划性的并且是可以被跟踪的。
（4）已建立的过程。通过采用一个基于好的软件工程原则所开发出的过程，整个过程被加以实施与管理。每位成员在实施过程时所采用的都是经过证实的被裁剪的标准，实施过程是一个文档化的过程。为建立过程所需的资源都已到位。
（5）可预测的过程。为了实现过程目标，已定义的过程在受控的范围内以一致的方式加以实施。关于实施的详细度量数据被加以收集与分析，从而导致对过程能力有一个定量的了解与掌握，而且具有为达到预期实施效果而加以改进的能力。对过程实施情况的管理是客观的，对工作产品的质量可以通过定量的方式加以了解。
（6）优化的过程。为了适应当前和未来业务方面的需要，对过程的实施应进行优化，而在达到所规定的业务目标的同时，过程也实现了可重复性。过程的优化包括对创新思想和新技术的引入与管理，根据已确定的目标抛弃或改进无效或低效的过程。

5.SJ/T 11234-2001标准
我国行业标准《软件过程能力评估模型（SJ/T 11234-2001）》针对软件组织对自身软件过程能力进行内部改进的需要，与CMMI连续表示形式基本相同。该模型有22个过程域，分为四大类，分别是过程管理类、项目管理类、工程化类和支持类。

SJ/T 11234-2001的每个过程能力划分为六个评估等级，分别是不完整级、已执行级、受管理级、已定义级、定量管理级和持续优化级。每个等级包含了通用目标、通用惯例、特定目标和特定惯例，它们组成一套衡量准则。不完整级是反映那些没有得到完整执行过程的状态，可能实现了部分特定目标，也可能什么目标都没有实现；处于已执行级的过程实现了全部特定的目标；受管理级、已定义级、定量管理级和持续优化级不仅实现了全部特定目标，而且依次实现了对应更高的通用目标。