2004计算机软件工程考研串讲之四

作者名：不详　来源：网友提供 06年6月8日

10-1 顺序图
顺序图展现了一组对象和由这组对象收发的消息，用于按时间顺序对控制流建模。
对象表述为虚垂线顶端的矩形小框。
垂线是对象的生命线，说明对象的生命。
生命线之间的箭头表示消息。消息出现的次序自上而下。
消息箭头可以回到同一条生命线，指明自调用，即对象发给自己的消息。
移动电话系统的用例图
移动电话系统的顺序图
10-2 协作图
协作图展现了一组对象，这组对象之间的连接以及这组对象收发的消息。
它强调收发消息的对象结构组织，按组织结构对控制流建模。
协作图中的协作不是参与者与系统之间的交互，而是系统内部某一个用例中各个对象之间信息传递的方式。
消息上所附编号指明执行顺序。
移动电话系统的协作图
RUP的分析/设计工作流
分析和设计工作流的目的是研究欲采用的实现环境和系统构件的效用，定义软件的组织结构，把需求获取结果转化为实现规格。
为实现这种转化，必须理解需求，采用最佳实现策略将其翻译为系统设计。
为此，首先是建立健壮的软件体系结构，设计出易于理解、开发和演进的系统，然后调整这个设计，使之适应实现环境。
最后结果是产生一个对象模型，即设计模型。

定义一个初始的体系结构
建立一个初始的系统体系结构草图。定义
一组初始的重要体系结构元素。
一组初始分析机制。
系统的初始分层和组织。
在当前迭代过程中处理的用例实现。
从重要的构件用例中确定类。
确定类之间的交互作用，修改用例实现。
细化体系结构

建立从分析到设计的自然转移，并标识：
从分析元素中确定适当的设计元素。
从相关分析机制中确定适当的设计机制。
保持体系结构的一致性和完整性，确保：
将当前迭代中标识的新的设计元素与已有的设计元素集成在一起。
在设计中尽早地、最大限度地复用可获得的构件和设计元素。
描述系统运行的组织和实施体系结构。
组织实现模型以实现设计到实现无缝转移。

分析行为
将用例提供的行为描述转变为一系列可作为设计基础的元素。
在分析行为时，主要注重于如何能够提供要求的功能，较少关心系统的非功能需求。
设计构件
找出设计元素如何实现要求行为的细节，细化设计元素的定义。
根据新的设计元素来细化和更新用例实现。
当设计演进后，进行设计评审。

设计实时构件
在实时的或交互式的上下文中，使用封装制品作为主要的设计元素。
设计实时构件与设计构件有相似的活动，但增加了封装设计活动，定义系统的并发控制线程和它们之间的协议。
设计数据库
在设计中标识永久类并设计适当的数据库结构来存储永久类。
定义一种存储和检索永久数据的机制和策略，以满足系统的性能需求。

分析和设计工作流中的关键制品：
设计模型 由类的协作构成。这些类的协作可能集成为包或子系统。包是对类的逻辑分组，是为了减少系统的复杂性。
分析模型 是设计的抽象和泛化，它提供系统的功能描述，忽略了系统如何工作的细节。
软件体系结构文档 涵盖系统不同的体系结构视图。
实现工作流
实现工作流的目的是
建立代码的分层结构；
从构件（源文件、二进制文件、可执行文件或其他文件）角度来实现类和对象；
对开发出来的构件进行单元测试；
将个人和开发团队开发的结果集成到可执行系统中。
单元测试仅对单个构件进行。集成测试和系统测试在测试工作流中执行。

实现模型是在细化阶段通过不断迭代，不断使用更大规模的集成构造建立起来的。
对于每一次迭代，要求做到：
确定要实现哪一个子系统，以及在当前迭代中子系统的集成顺序。
对于每一个子系统，确定实现每个类的顺序，以及子系统集成的计划。
实现设计模型中的类和对象，包括编写源代码、改写已有构件、编译、链接和执行，及时反馈设计中可能的缺陷。

修改有缺陷的源代码，进行单元测试以验证这些变更。最后进行代码评审。
指定专人负责将所有新的和已变更的构件集成为一个新的实现子系统版本。在团队环境，集成将产生一系列构造，对每个构造由集成测试员进行集成测试。
将发布的子系统集成到系统。最终的构造即为系统。由系统测试员进行系统测试。

实现工作流的关键制品有：
实现子系统 构件和其他实现子系统的集成。它是将实现模型细分为更小的部分，并使其构造化。
构件 可以是一块程序代码，或是包含信息的文件。构件可以由其他构件聚合而成。
集成构造计划 定义构件和子系统的实现顺序，详细描述系统集成时要建立的构造。
实现与设计的关系紧密。在设计元素和实现元素之间有非常明显的跟踪链接。
创建良好设计的原则
设计原则1：分治
软件系统分解为子系统
分布式系统可以分解为客户机和服务器；
系统可以分解为一系列子系统；
子系统可以分解为一个或多个包；
包可以分解为类；
类可以分解为方法。

设计原则2：尽可能增加内聚
不同内聚类型：优先级从高到低排序
功能内聚：模块只执行单一计算并返回结果，没有副作用。如函数过程。
层内聚：相关服务放在一起，并有严格的层次结构，高层服务可访问低层服务，反之不可。如分层结构。
通信内聚：访问或操作同一数据的过程放在一个类中，这些过程可以互相通信。如某个类设计。

顺序内聚：存在一系列过程，其中一个过程向另一个过程提供输入，这些过程放在一起，形成顺序内聚。如消息序列。
过程内聚：几个一次调用的过程放在一起，但其中一个过程的输出不一定是另一个过程的输入，形成过程内聚。如调用结构。
时间内聚：程序执行过程中同一阶段内完成的操作放在一起，达到时间内聚。
实用程序内聚：逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用程序内聚。如可复用的过程或类。

设计原则3：尽可能降低耦合
模块间存在相互依赖关系即为耦合。不同耦合类型从高向低排列有：
内容耦合：一个构件在不被察觉的情况下修改另一个构件内部的数据，应始终避免。
公共耦合：一组构件使用了全局数据，就产生公共耦合。应通过封装降低公共耦合。
控制耦合：一个过程通过标志、开关或命令显式地控制另一个过程的动作，就产生控制耦合。降低的方法是采用多态操作。

标记耦合：在一个操作的参数表中将类作为参数，就产生标记耦合。降低标记耦合的方法可以传递简单变量或使用接口做参数。
数据耦合：在一个操作的参数表中用简单变量或简单的类（如string）作为参数，就产生数据耦合。应通过减少参数个数降低耦合。
例程调用耦合：一个例程（或类操作）调用另一个例程，就产生例程调用耦合。如果出现例程调用序列，降低的方法是编写一个例程将这个调用序列封装起来。

类型使用耦合：类将实例变量或本地变量声明为另一个类时，就产生类型（嵌套）使用耦合。降低该耦合的方法是将变量的类型声明为包含所需操作的最通用的类或接口。
包含/引入耦合：当一个构件引入（import）一个包时就产生引入耦合，当一个构件包含（include）另一个构件时，就产生包含耦合。
外部耦合：模块对外部系统，如操作系统、共享库或硬件有依赖关系时就产生外部耦合。可通过信息隐蔽减少这种依赖关系。

设计原则4：尽可能提高抽象层次
设计应隐藏或推迟考虑细节以降低复杂性。
类是包含过程抽象的数据抽象。
父类和接口可进一步提高抽象层次。
类中公有操作越少，抽象程度越高。
类中所有变量都是私有，抽象程度达到最高。
抽象可确保在设计时不必关心不必要的细节，能把握问题的本质并做出重要的决策。

设计原则5：尽可能提高可复用性

可以在算法、类、过程、框架和完整应用程序的级别上创建可复用性。
复用构件的机制包括过程调用和继承父类。

设计原则6：尽可能复用已有的设计和代码
复用已有的设计是对可复用性设计的补充。通过复用可从以往对可复用构件的投资中获益。

设计原则7：灵活性设计
积极预测将来可能在实现和功能上的变化，并为此采取相应措施。

在设计中引入灵活性的方法有：
降低耦合并提高内聚（易于提高替换能力）
建立抽象（创建有多态操作的接口和父类）
不要将代码写死（消除代码中的常数）
抛出异常（由操作的调用者处理异常）
使用并创建可复用的代码

设计原则8：预计过期
积极预测将来可能在技术和运行环境上的变化，并为此采取相应措施。

在设计中应遵循的预计过期的规则有：
避免使用早期发布的技术
避免使用针对特定环境的软件库
避免使用软件库中未编档的或很少使用的功能
避免使用小公司或可能不提供长期支持的公司提供的可复用构件或特殊硬件
使用众多厂商支持的标准语言和技术

设计原则9：可移植性设计

可移植性设计的主要目标是让软件在尽可能多的平台上运行。实现可移植性的规则有：
避免使用特定环境的专有功能
使用不依赖特定平台的程序设计语言
小心使用可能依赖某一平台的类库
了解其他语言可能依赖特殊硬件结构的功能和文本文件的差异

设计原则10：可测试性设计
设计时采取措施使得测试易于进行。

可测试性设计的最重要的方法是保证代码的所有功能都能脱离图形用户界面执行

设计原则11：防御性设计
为提高可靠性，应确保不引入任何缺陷，能够处理其他代码不适当使用构件引起的问题。
按契约设计是防御性设计技术，其核心思想：
被调用操作为正常执行必须满足的前置条件(precondition)：调用操作在调用一个操作时有责任确保该操作的前置条件成立。

被调用操作正常执行所得到的结果即为后置条件 (postcongdition)：要求被调用操作在返回前有责任保证这些后置条件成立。
被调用操作在执行时确保不会被修改的不变量(invariant)。
前置条件、后置条件和不变式都是布尔表达式，其计算结果为假，表示有错误发生。
可以使用断言机制。
在重要构件的边界（如层）应始终保留严格的断言检测。
设计模式
设计模式是面向对象软件设计经验的总结。
设计模式系统地命名、解释和评价了面向对象系统中的一个重要的和重复出现的设计。
设计模式使人们可以简单方便地复用成功的设计和体系结构。
设计模式描述了在特定场景下使用的解决一般设计问题的类和相互通信的对象。
设计模式的四个基本要素
模式名 用于描述模式的名字，说明模式的问题、解决方案和效果。
问题 说明在何种场合使用模式。要描述使用模式的先决条件和特定设计问题。
解决方案 描述设计的成分、它们之间的相互关系、各自的职责和合作方式。
效果 描述模式使用的效果，包括对时间和空间的衡量，以及对系统灵活性、可扩充性、可移植性的影响。
设计模式的特性
灵活性 设计模式应是精巧的解决方法。
一般化 设计模式不依赖于某一种特定的系统类型、程序设计语言或应用领域。
已验证 设计模式已在某些面向对象系统中实践并已通过测试。
简单性 设计模式通常较小，只有几个类。
可复用 可在设计层次（不是编码层次）应用于所有的系统。
面向对象 设计模式以面向对象的形式出现。
设计模式的类型
依据设计模式工作目的不同，模式可分为
创建型模式(Creational pattern)
结构型模式(Structural pattern)
行为型模式(Behavioral pattern)
创建型模式与对象的创建有关；
结构型模式处理类和对象的组合，将一组对象组合成一个大的结构，例如复杂的用户界面；
行为型模式描述类或对象的交互和职责分配，定义对象间的通信和复杂程序中的流控。
1、创建型模式
创建型模式描述怎样创建一个对象。它隐藏对象创建的具体细节，使用程序可不依赖具体的对象。因此当增加一个新对象时几乎不需要修改代码。
创建型类模式将对象的部分创建工作延迟到子类，创建型对象模式将它延迟到另一对象中。
这时，重点从定义固定的行为集合转向定义一个较小的基本行为集合，由这些行为可以组成许多更复杂的行为集合。

模式的特点
封装了系统中使用的类的具体信息；
隐藏了这些类的实例如何创建、如何放在一起的（机制）。
系统关于这些对象所知道的只有由抽象类定义的接口。
创建型类模式有Factory Method (工厂方法)。
创建型对象模式包括Abstract Factory (抽象工厂)、Builder (生成器)、Prototype (原型)、Singleton (单件)四种模式。
2、结构型模式
结构型模式处理类或对象的组合，即描述类和对象之间怎样组织起来形成大的结构，从而实现新的功能。
结构型类模式采用继承机制来组合类，如Adapter (适配器)模式；
结构型对象模式则描述了对象的组装方式，如Adapter (适配器)、Bridge (桥接)、Composite (复合)、Decorator (装饰)、Facade (外观)、Flyweight (享元)、Proxy (代理) 等七种模式。
3、行为型模式
行为模式涉及算法和对象之间职责的分配。行为模式不仅描述对象或类的模式，还描述它们之间的通信。
行为模式刻划了在运行时难以跟踪的复杂的控制流，但这类模式把人们的注意力从控制流转移到对象间的相互联系。
类行为模式使用继承机制在类间分派行为，如Template Method (模板方法)和Interpreter (解释器) 模式。

对象行为模式使用对象复合而不是继承，描述对象如何协同完成预定任务，如Chain of Responsibility (职责链)、Command (命令)、Iterator (遍历器)、Mediator (中介者)、Memento (备忘录)、Observer (观察者)、State (状态)、Strategy (策略)、Visitor (访问者) 等九种模式。
面向对象测试
面向对象系统的测试与传统的基于功能的系统的测试之间存在很大差别：
对象作为一个单独的构件一般比一个功能模块大。
由对象到子系统的集成通常是松散耦合的，没有一个明显的“顶层”。
如果对象被复用，测试者无权进入构件内部来分析其代码。

面向对象系统的测试可分为4个层次：
测试与对象相关联的单个操作 它们是一些函数或程序，传统的白盒测试和黑盒测试方法都可以使用。
测试单个对象类 黑盒测试的原理不变，但等价划分的概念要扩展以适合操作序列的情况。
测试对象簇（聚集） 严格的自顶向下或自底向上的集成不适合一组关联对象的情形。应使用基于场景的测试等其他方法。
对象类测试
测试面向对象系统 根据系统需求规格说明进行检验和有效性验证的过程可以像对其他范型的系统一样进行。

对象类，作为在语法上独立的构件，应当允许用在不同的应用中。每个类都应是可靠的，并且不需了解任何实现的细节就能复用。因此，对象类应尽可能孤立地进行测试。
设计操作的测试用例时需要注意：
首先定义测试对象的各操作的测试用例。
对于一个单独的操作，可通过该操作的前置条件选择测试用例，产生输出，让测试者能够判断后置条件是否能够得到满足。

各个操作的测试与传统对函数过程定义的测试基本相同。
然后再把测试用例组扩充，针对被测操作调用对象类中其他操作的情况，设计操作序列的测试用例组。
测试可以覆盖每个操作的整个输入域。但这不够，还必须测试这些操作的相互作用，才能认为测试是充分的。
各个操作间的相互作用包括类内通信和类间通信。

在设计对象类的规格说明测试时需要注意：
把对象类当做一个黑盒，确认类的实现是否遵照它的定义。对于“Stack”的测试应当确保 LIFO 原则得以实施。
对于多数的对象类，主要检验在类声明的 public 域中的那些操作。
对于子类，要检查继承父类的public 域和protected 域的那些操作。
检查所有public域，protected域及private 域中的操作以完全检查对象中定义的操作。

等价划分的思想也可用到对象类上。将使用对象相同属性的测试归入同一个等价划分集合中。这样可以建立对对象类属性进行初始化、访问、更新等的等价划分。
在设计对象类的行为测试时需要注意：
基于对象的状态模型进行测试时，首先要识别需要测试的状态的变迁序列，并定义事件序列来强制执行这些变迁。
原则上应当测试每一个状态变迁序列，当然这样做测试成本很高。
对象集成测试
当开发面向对象系统时，集成的层次并不明显。而当一组对象类通过组合行为提供一组服务时，则需将它们一起测试，这就是簇测试。
此时不存在自底向上和自顶向下的集成。

簇需要根据对象操作以及对象属性的关联来构成。
面向对象系统的集成测试有3种可用的方法：
用例或基于场景的测试 用例或场景描述了对系统的使用模式。测试可以根据场景描述和对象簇来制定。这种测试着眼于系统结构，首先测试几乎不使用服务器类的独立类，再测试那些使用了独立类的下一层次的（依赖）类。这样一层一层地持续下去，直到整个系统构造完成。

基于线程的测试 它把为响应某一系统输入或事件所需的一组对象类组装在一起。每一条线程将分别测试和组装。因为面向对象系统通常是事件驱动的，因此这是一个特别合适的测试形式。
对象交互测试 这个方法提出了集成测试的中间层概念。中间层给出叫做 “方法-消息”路径的对象交互序列。所谓“原子系统功能”就是指一些输入事件加上一条“方法 -消息”路径，终止于一个输出事件。
面向对象的确认测试
在确认测试或系统测试的层次上，不再考虑对象类间相互连接的细节。主要着眼于用户可见的动作和用户可识别的系统输出。
为了帮助确认测试的执行，测试者需要回到分析时的动态模型和描述系统行为的事件序列（脚本）进行测试。
可以利用黑盒测试的方法来驱动确认测试。测试检测软件中的故障并确定软件是否执行了预定要开发的功能。
面向对象测试用例的设计
测试过程包括了一组测试用例的开发，每一个测试用例要求能检验应用的一个特定的元素。还需要分析用各个测试用例执行测试的结果来收集有关软件的信息。
软件测试人员可以参考以下方法：
应当唯一标识每一个测试用例，并与被测试的类显式地建立关联。
陈述测试对象的一组特定状态。

对每一个测试建立一组测试步骤，要思考和确定的问题包括：
被测试对象的一组特定状态；
一组消息和操作；
考虑在对象测试时可能产生的一组异常；
一组外部条件；
辅助理解和实现测试时的补充信息。
传统的白盒测试方法可用在类定义的操作测试和类级别测试中，黑盒测试方法可用于多类测试。
第六章 软件工程过程
软件过程是软件生存周期中的一系列相关软件工程活动的集合，活动是任务的集合。任务是将输入变换为输出的操作。
活动的执行可以是顺序的，重复的，并行的、嵌套的。
每一个软件过程又是由一组工作任务、项目里程碑、软件工程产品和交付物以及质量保证点等组成。

基本过程
获取过程 是需方为了获得一个软件产品所进行的一系列活动。该过程从为获取该软件产品的需求定义开始，经过招标准备，合同准备和修改，对供方监督，直到验收完成。
供应过程 是供方为向需方提供软件产品所进行的一系列活动。该过程从理解软件需求开始，经过投标准备，签订合同，制定计划，实施计划及控制，进行评审和评价，直至完成交付。

开发过程 是软件开发者根据合同开发和交付软件的一系列活动。包括的活动有：过程实施准备，系统需求分析，系统结构设计，软件需求分析，软件体系结构设计，软件详细设计，程序编码和单元测试，软件集成，软件确认测试，系统集成，系统确认测试，软件安装，软件验收支持。
运行过程 软件开发完成后，软件从开发环境转移到用户的实际运行环境。在运行时对用户的要求提供帮助和咨询，对运行效果进

行评价。包括的活动有：实施过程准备，运行测试，系统向实际运行环境转移，系统运行，对用户运行的支持，系统运行评价，用户运行评价。
维护过程 维护人员提供维护软件产品的服务。包括的活动有：过程实施准备，问题分析和修改分析，修改实施，对维护进行评审／验收，移植，软件退役。
支持过程
文档过程 文档过程是一个记录由某一过程或活动所产生的信息的过程。它由以下活动组成：过程的实施准备，设计与开发，制作与发行，维护。
配置管理过程 该过程实施软件配置管理的活动。包括的主要活动有：过程实施准备，配置的确定，配置的控制，配置情况报告，配置的评价，发行管理和提交。

质量保证过程 这是一个为使软件过程和软件产品符合规定需求，并按预定计划按时完成提供适当保证的过程。包括的主要活动有：过程实施准备，软件产品的质量保证，软件过程的质量保证。
验证过程 确定系统或软件的需求是否完备和正确，以及每一阶段的软件产品是否达到前一阶段对它的要求和条件。包括的主要活动有：过程实施准备，验证，合同验证，过程验证，需求验证，设计验证，代码验证，集成验证，文档验证。

确认过程 确认需求和最终建立的系统或软件是否满足原计划的特定应用。包括的主要活动有：实施特定的测试并分析测试结果，确认软件产品的用途，测试软件产品的适用性。
审计过程 这一过程是要审计确定合作的另一方遵照需求、计划合同到什么程度的过程。包括的主要活动有：检验项目是否符合需求、计划、合同以及规格说明和标准。

联合评审过程 这是评价项目的某个活动或阶段的执行情况，以及产品是否合乎要求的过程。包括的主要活动有：过程实施准备，项目管理评审，技术评审。
问题解决过程 这是一个用于分析和排除在开发、运行、维护或其它过程中发现的问题和不一致的过程。
组织过程
管理过程 管理包括进度管理、成本管理、质量管理、人员管理、资源管理、标准化管理。管理的对象是进度、系统规模及工作量估算、经费、组织机构、人员、风险、质量、作业和环境配置等。包括的主要活动有：过程实施准备，制定计划，监控计划的实施，评审和评价计划的完成程度，涉及到有关过程的产品管理、项目管理和任务管理。

基础设施过程 该过程建立、维护各个过程所需的基础设施。基础设施包括硬件、软件、工具、技术、标准以及开发、运行、维护所需的各种基础设施。
改进过程 该过程建立、评估、度量、控制和改进软件生存周期的过程。主要活动是制定一组组织计划，评估相关过程，实施分析、改进过程。
培训过程 该过程为系统或软件产品提供人员培训。主要活动有制定所需人员用人

计划和培训计划， 开发培训资料， 实施培训活动等。

过程是针对确定的目的所实施的序列步骤，例如软件开发过程。（IEEE-STD-610）
过程是使用资源将输入转化为输出的活动的系统。（ISO 9000 : 2000）
过程是把输入转换为输出的一组彼此相关的活动。（ISO/IEC 12207）
软件过程的评估
对于不同的软件开发机构，在组织人员完成软件项目中所依据的管理策略有很大差别，因而软件项目所遵循的软件过程也有很大差别。我们用软件过程的成熟度加以区别。
所谓软件过程的成熟度是指一个软件过程被明确定义、管理、度量和控制的有效程度。
成熟度越高，说明软件过程能力改善的潜力越大。
软件过程成熟度的度量 (CMM)

CMM 定义软件过程成熟度为一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。它是指对过程计划或定义水平、过程实施水平、过程管理和控制水平、过程改善潜力等指标的综合评价。
软件能力成熟度等级则为软件开发组织在走向成熟的途中几个具有明确定义的表征软件能力成熟度的平台。
每一个成熟度等级为过程继续改进达到下一个等级提供一个基础。

各成熟度等级的特征
初始级
组织缺乏明文的管理办法，软件工作没有稳定的环境，制定了计划又不执行，反应式驱动工作开展。
紧急情况下已定的规程丢在一边，急于编码和测试。
个别项目的成功依赖于某个有经验的管理人员。

个别管理人员能顶住削减过程的压力，但他们离职则全然不同。
规定的过程无法克服由于缺乏有效管理带来的不稳定性。
现象往往表现为过程无一定之规，项目进度、预算、功能及产品质量无法保证，项目的实施不可预测。
可重复级
建立了为跟踪成本、进度和功能的基本项目管理过程。

基于以往项目经验，制定了过程实施规范，使类似的项目可再次成功。
能追踪成本、进度、功能，及时发现问题。
如有分包，其质量也能得到控制。
已定义级
制定了组织的标准过程文件，这是软件工程基础设施的重要组成部分。
建立了组织的软件工程过程组SEPG，负责软件过程活动。

制定和实施了人员培训大纲，保证人员能够胜任岗位知识和技能要求。
针对特定项目，可将标准软件过程进行剪裁。
项目成本、工期和功能已受控，质量可跟踪。
管理者了解所有项目对技术进步的要求。
已管理级
已为产品和过程建立了量化的目标。

对项目的过程活动，包括生产率和质量均作了度量。
利用过程数据库收集和分析过程的信息。
可量化评价项目过程和产品。
可有效地控制过程和产品的性能，使其限制在规定的范围内。
新应用领域的风险可知可控。
可预知产品的质量。
优化级

集中注意于过程的持续改进。
自知过程的薄弱环节，可预防缺陷的出现。
可通过对当前过程的分析，评价对新技术或将出现的变更作出评价。
重视探索创新活动，并将成功的创新推广。
出现的缺陷得到分析，找出原因，防止再次发生，教训为其它项目吸取。
软件过程能力
软件过程能力描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度。
软件过程性能则表征（开发组织或项目组）遵循其软件过程所得到的实际结果。
软件过程性能描述已得到的实际结果，而软件过程能力则描述最可能的预期结果。
为什么要提高过程能力？
对于顾客，较高的过程能力意味着：

开发组织能够更好地响应自己的要求
软件产品的成本更低
能更好地满足最终用户要求
对于开发组织，较高的过程能力表明：
软件产品开发和维护成本较低
开发周期较短
由于有效的项目风险分析和工作量投入估计，增强了达到成本和进度目标的能力
提高了满足量化设计和质量目标的能力
关键过程域 KPA （Key Process Area）
除去初始级以外，其它每一个成熟度等级都有若干个引导软件机构改进软件过程的要点，称为关键过程域。它们确定了实现一个成熟度级必需解决的问题，它们的实施对于达到该成熟度等级的目标起着保证作用。
CMM定义关键过程域为一个互相关联的若干软件实践活动和有关基础设施的集合。

每一个关键过程领域确定一组相应的活动，完成这些活动，就可认为已达到了改进过程能力的一组重要的目标。

关键实践
关键过程域包含为实现这些关键过程域所必需实施的关键实践，它们包含对关键过程域的实施起关键作用的方针、规程、措施、活动以及相关基础设施的建立。
关键实践一般只描述“做什么”，而不强制规定“如何做”。关键过程域的目标是通过其包含的关键实践的实施来达到的。
关键实践的实施全部按下面5个共同特征加以组织。

执行约定 — 描述一个机构在保证将过程建立起来并持续起作用方面所制定的方针和规定的高级管理人员对项目的支持。
执行能力 — 描述为了实施软件过程，项目或机构中必须存在的先决条件。执行能力一般包括资源、组织机构和培训。
执行活动 — 描述为了实现一个关键过程域必须由谁做什么，包括制定计划与规程、执行计划、跟踪执行情况，必要时采取纠正措施。

测量和分析 — 描述测量软件的过程和分析测量结果的要求需要，包括为确定所执行活动的状态及有效性而采用的测量和分析。
验证实施 — 描述保证遵照已建立的过程进行活动的措施，包括管理人员和软件质量保证部门所做的评审和审核。
CMM的内部结构
第七章 软件质量保证

由此可知，质量是产品、体系或过程的一组固有特性，反映的是满足顾客和其他相关方面要求的程度。
软件质量管理是对软件在质量方面指挥和控制组织的协调活动。通常包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
质量方针是由组织的最高管理者正式发布的该组织总的质量宗旨和方向。

质量目标是在质量方面所追求的目的。
质量策划是质量管理的一部分，致力于制定质量目标并规定必要的运行过程和相关资源以实现质量目标。
质量控制是质量管理的一部分，致力于满足质量要求。
质量保证是质量管理的一部分，致力于保障质量会得到满足的信任度。
质量改进是质量管理的一部分，致力于增强满足质量要求的能力。
软件质量模型
软件质量特性定义成分层模型。
最基本的叫做基本质量特性，它可以由一些子质量特性定义和度量。
二次特性在必要时又可由它的一些子质量特性定义和度量。
1976年 Boehm质量模型
1979年 McCall质量模型
1985年 ISO质量模型

ISO的软件质量评价模型
按照1991年 ISO发布的 ISO/IEC 9126 质量特性国际标准 ，软件质量度量模型由三层组成
软件质量特性
软件质量子特性
软件质量度量评价准则
高层和中层建立国际标准，低层可由各使用单位视实际情况制定。

可依赖性 dependability
对于某些高可靠性系统，质量特性“可依赖性”显得非常重要，它有四个主要方面：
可用性 (Availability)：系统在任何时间都能得到并能够执行有用服务的可能性。
可靠性 (Raliability)：系统在给定的时段内能提供希望的服务的可能性。
安全性或防护性 (Safety)：系统防止发生给人和环境造成伤害的失效的可能性。
安全性或保密性 (Security)：系统能够抵抗意外或蓄意的入侵的可能性。
可依赖性的层次
提高质量的方法 - 原型化方法
软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。它是各种特性的复杂组合。它随着应用的不同而不同，随着用户提出的质量要求不同而不同。
因此与用户的交流成为提高软件质量的关键。在系统开发中，与用户进行交流的基本技术是原型化方法。
系统原型是软件系统的初始版本，用于展示设计选择、发现问题和给出可能的解决方案。

软件原型支持需求工程的两项活动：
需求获取
需求有效性验证
其他用途：
用户培训
系统测试
主要分类：
进化式原型开发
抛弃式原型开发