软考复习专题七---软件工程

专题七：软件工程专题

1、软件工程知识

1.1 概述

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。其目的是提高软件生产率、提高软件质量、减低软件成本。

软件工程是1968年在德国的NATO会议上提出的，希望用工程化的原则和方法来克服软件危机；而软件危机就是软件开发和维护过程中的各种问题，由于软件开发阶段缺乏好的方法的指导和好的工具的辅助，而且缺少有关的文档，使得大量的软件难以维护。

软件生命周期是指由软件定义、软件开发和软件维护等阶段组成的全过程，反映软件生存期内各种工作的组织以及各个阶段如何衔接。指一个软件系统从其提出、调查到分析、设计和有效使用，直至被淘汰或取代的整个期间。

软件生命周期法就是按软件生命周期的各个阶段划分任务，按一定的规则和步骤，有效地进行软件开发的方法。通常一个软件系统的生命周期可分为五个阶段：准备阶段、分析阶段、设计阶段、实施阶段、运行与维护阶段。下表归纳了软件生存周期各个阶段的任务、参与人员和产生文档。

阶段	任务	参与人员	产生文档
软件定义阶段——待开发软件要“做什么”
系统分析	确定待开发软件的总体要求和适用范围，以及与之有关的硬件、支撑软件的要求	用户、项目负责人、系统分析员	可合并项目计划书中
软件项目计划	确定待开发软件的目标，对其进行可行性分析，并对资源分配、进度安排等做出合理的计划	用户、项目负责人、系统分析员	可行性分析报告、项目计划书
需求分析	确定待开发软件的功能、性能、界面等要求，从而确定系统的逻辑模型	用户、项目负责人、系统分析员	需求规格说明书
软件开发阶段——待开发软件“怎么做”
软件设计	概要设计	模块分解，确定软件的结构，模块的功能和模块间的接口，以及全局数据结构的设计	系统分析员、高级程序员	设计说明书、数据说明书、模块开发卷宗
详细设计	设计每个模块的实现细节和局部数据结构的设计	高级程序员、程序员
编码	用某种程序语言为每个模块编写程序	高级程序员、程序员	程序清单
软件测试	发现软件中的错误，并加以纠正	高级程序员或系统分析员（另一部门或单位）	软件测试计划、软件测试用例说明，软件测试报告
软件维护阶段—开发后交付使用的软件的维护
软件维护	使软件适应外界环境的变化、实现功能的扩充和质量的改善而修改软件	维护人员	维护计划、维护报告

　　软件由计算机程序、数据及文档组成，同时与硬件、数据库、人、过程等共同构成计算机系统。软件工程包括三个要素：方法、工具和过程。
1.2 软件开发模型

1．瀑布模型（应用最广泛的模型）

2. 演化模型

增量模型：增量发布可运行产品，第一个增量通常是核心产品，包含基本需求

原型模型：从交流确定用户需求开始；设计原型；使用、评价原型；修改、完善原型

螺旋模型：增加了风险分析，从制定计划开始；风险分析；工程实施；客户评估。

3. 喷泉模型（体现迭代和无间隙特性）

支持面向对象开发，分析阶段：标志类和对象，定义类关系，建立对象关系模型和对象行为模型；设计阶段：对分析模型调整；编码阶段：实现通信完成功能。

分析模型和设计模型采用相同符号体系表示，开发各个活动无明显边界。

4. 基于构件的开发模型

利用预先包装的构件构造应用系统。

可行性分析的任务是从技术上、经济上、使用上、法律上分析需解决的问题是否存在可行的解。

　

U P由四个阶段的序列组成。每个阶段由主要里程碑所终止。

• 初始—生命周期目标；大部分工作是需求和分析。

• 细化—生命周期构架；重点是需求、分析和一些设计。

• 构造—初始运作功能；重点是设计和实现。

• 移交—产品发布。重点是实现和测试。

UP特点:

• 用例和风险驱动；

• 构架中心的；

• 迭代和增量的。

1.3 软件分析

需求分析

主要是确定待开发软件的功能、性能、数据、界面等要求。具体有以下几点：

Ø 确定软件系统的综合要求

Ø 分析软件系统的数据要求

Ø 导出系统的逻辑模型

Ø 修正项目开发计划

Ø 如有必要，可开发一个原型系统

需求分析的基本原则是能够表达和理解问题的信息域和功能域；以层次化的方式进行分解和不断细化；要给出系统的逻辑视图和物理视图；

描述软件需求的方法：

功能层次模型：一般来讲就是系统的功能图，模块分布图等描述整个系统的功能的分布和功能的层次结构；

数据流模型：就是以数据流为着眼点的分析方法得到的模型，主要通过数据在整个系统的流动情况来确定系统的主要功能主线和流程；

控制流模型：通过了解和界定系统中控制线，通过控制流的走向和控制的对象来确定系统的功能分布和控制与被控制的关系；

1.4 软件设计和开发

软件开发过程中的软件工程原则（8个）：

Ø 抽象；

Ø 自顶向下、逐层细化；

Ø 信息隐蔽和数据封装；

Ø 模块化；

Ø 局部化；

Ø 确定性；

Ø 一致性和标准化；

Ø 完备性和可验证性；

软件工程基本原理（7个）：

n 按软件生存周期分阶段指定计划并认真实施；

n 坚持进行阶段评审；

n 坚持严格的产品控制；

n 使用现代程序设计技术；

n 明确责任，使得工作结果能够得到清楚的审查；

n 用人少而精；

n 不断改进开发过程；

软件设计原则:
软件设计的原则对提高软件的设计质量有很大的帮助。

◆ 抽象

忽视一个主题中与当前目标无关的那些方面。过程抽象和数据抽象是常用的两种主要抽象手段。

◆ 模块化

将一个待开发的软件分解成若干个小的简单的部分——模块，每个模块可独立地开发、测试、最后组装成完整的软件。这是一种复杂问题的“分而治之”的原则。

模块：执行某一特定任务的数据结构和程序代码。一个模块有它的外部特征和内部特征。

◆ 信息隐蔽

开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理。信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。

◆ 模块独立

模块独立是指每个模块完成一个相对独立的子功能，并且与其他模块之间的联系简单。衡量模块独立程度的度量标准有两个：耦合和内聚。追求低耦合高内聚。

耦合是指模块之间联系的紧密程度。耦合度越高则模块的独立性越差。按耦合度从低到高依次有7种耦合方式。

Ø 非直接耦合（独立运行）

Ø 数据耦合（用参数表传递简单数据）

Ø 标记耦合（传递数据结构或者一部分）

Ø 控制耦合（传递的信息包括控制模块的信息）

Ø 外部耦合（模块与软件之外的环境有关）

Ø 公共耦合（多个模块引用同一全局的数据区）

Ø 内容耦合（访问内部数据，代码重叠或者多个入口）

内聚是指模块内部各元素之间联系的紧密程度内聚度越低模块的独立性越差。按内聚度从低到高依次有7种内聚种类。

Ø 偶然内聚（模块完成的多个任务，任务之间的关系松散）

Ø 逻辑内聚（模块完成逻辑相关的一组任务）

Ø 瞬时内聚（模块的所有任务必须在同一时间间隔内执行）

Ø 过程内聚（模块的处理元素相关而且按照特定的次序执行）

Ø 通信内聚（模块的所有元素集中在一个数据结构区域上）

Ø 顺序内聚（模块的处理元素相关，必须顺序执行）

Ø 功能内聚（模块完成单一的功能，各个部分协调工作，而且不可缺少）

模块分解原则：

Ø 满足信息隐蔽；

Ø 尽量内聚度高，模块间偶合度低；

Ø 模块大小在（50-100语句）；

Ø 模块调用深度不能过大；

Ø 模块的扇入（直接调用该模块）应尽量大，扇出（直接调用下级模块数）不宜过大；

Ø 设计单入口和单出口的模块；

Ø 模块的作用域应在控制域之内：

作用域：受模块内一个判定影响的所有的模块的集合；

控制域：该模块本身和被该模块直接或间接调用的所有的模块的集合；

Ø 模块的功能应是可以预测的，相同输入得到相同输出

软件编码：

根据详细设计说明书编写程序，为开发项目选择程序设计语言需要考虑的因素有应用领域、算法和计算的复杂性、软件运行环境、用户需求、数据结构和开发人员的水平。软件的设计质量与程序设计语言的技术性能无关，但在程序设计转向程序代码时，转化的质量受语言性能的影响。

COBOL商业领域；FORTRAN科学计算；PROLOG和LISP人工智能领域；SMALLTALK、C++、JAVA面向对象语言；C是开发系统的程序设计语言；

例题1：

软件设计中划分模块的一个准则是A 。两个模块之间的耦合方式中，B耦合的耦合度最高，C耦合的耦合度最低。一个模块内部的内聚种类中D内聚的内聚度最高，E内聚的内聚度最低。

A： ①低内聚低耦合 ②低内聚高耦合 ③高内聚低耦合 ④高内聚高耦合

B： ①数据 ②非直接 ③控制 ④内容
C： ①数据 ②非直接 ③控制 ④内容
D： ①偶然 ②逻辑
③功能 ④过程
E： ①偶然 ②逻辑 ③功能 ④过程
A3 B 4 C 2 D 3 E 1

例题2

关于程序模块优化的启发式规则有若干条，以下规则中不符合优化原则的是__B__。如果一个模块调用下层模块时传递一个数据结构，则这种耦合属于_C_。（软件工程）

(30)A．通过模块的合并和分解，降低模块的耦合度，提高模块的内聚性
B．提高上层模块的扇出，减少模块调用的层次
C．将模块的作用范围限制在模块的控制范围之内
D．降低模块之间接口的复杂性，避免“病态连接”
(31)A．简单耦合	B．直接耦合	C.标记耦合	D．控制耦合

1.5 软件测试及维护

对源程序最基本的质量要求是正确性和可靠性，此外还很注重易使用性、易维护性和易移植性。软件测试的工作量约占软件开发总工作量的40%以上，其目的是尽可能发现软件产品（主要是指程序）中的错误和缺陷。

软件测试是自底向上，逐步集成的过程，低一级测试为上一级测试准备条件；

测试的关键是测试用例的设计，其方法可分为两类。

1. 白盒测试：

白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用例测试数据运行被测程序时对程序逻辑的覆盖程度。

主要的覆盖标准：

I. 语句覆盖 最弱的覆盖

指选择足够的测试用例，使被测语句的每个语句至少执行一次。

II.判定覆盖

指选择足够的测试用例，使每个判定的所有可能结果至少出现一次。

III.条件覆盖

指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次。

IV. 判定/条件覆盖

指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次，并且每个判定中条件结果的所有可能结果也至少出现一次。

V. 条件组合覆盖最强的覆盖

指选择足够的测试用例，使每个判定中条件结果的所有可能组合至少出现一次。

VI. 路径覆盖

指选择足够的测试用例，使流程图中的每条路径至少经过一次。

2. 黑盒测试：

黑盒测试时根据规格说明所规定的功能来设计测试用例，它不考虑程序的内部结构和处理过程。常用的黑盒测试技术有：

Ø 等价类划分

Ø 边值划分

Ø 错误猜测

软件测试的主要步骤：单元测试、集成测试（对模块集成时测试）、确认测试。

确认（计划阶段）---》集成（概要设计阶段：需要模块划分）---》单元（详细设计阶段完成）

单元测试：

主要用来发现编码和详细设计中产生的错误，一般在编码阶段，采用白盒测试。

集成测试（也称组装测试）：

主要用来发现设计阶段产生的错误，是对各模块组装而成的程序进行测试，主要检查模块间的接口和通信，采用黑盒测试。

集成测试按集成方式又可分成非渐增式集成和渐增式集成，而渐增式集成又可分成自顶向下集成和自底向上集成。

确认测试：

检查软件的功能、性能和其他特征是否与用户需求一致，它以需求规格说明书为依据，采用黑盒测试

Alpha测试是在开发者的现场由客户来实施的，从用户角度和环境下进行；

Beta测试是在开发者不在现场下测试，由软件最终用户实施；

测试文件不只在测试阶段才考虑，它在软件开发的需求分析阶段就开始着手，因为测试文件与用户有着密切的关系。在设计阶段的一些设计方案也应在测试文件中得到反映，以利于设计的检验。测试文件对于测试阶段工作的指导与评价作用更是非常明显的。需要特别指出的是，在已开发的软件投入运行的维护阶段，常常还要进行再测试或回归测试，这时仍须用到测试文件。

使用各种测试方法的综合策略：

n 在任何情况下都必须使用边界值分析方法，用这种方法设计出测试用例发现程序错误的能力最强；

n 必要时用等价类划分方法补充一些测试用例；

n 用错误推测法再追加一些测试用例

n 对照程序逻辑，检查已有测试用例的逻辑覆盖程度

n 如果程序的功能说明中含有输入条件的组合情况，则选用因果图法

例题：

软件测试的目的是A 。通常B是在代码编写阶段可进行的测试，它是整个测试工作的基础。

逻辑覆盖标准主要用于C 。它主要包括条件覆盖、条件组合（多重条件）覆盖、判定覆盖、条件及判定覆盖、语句覆盖和路径覆盖等几种，其中除路径覆盖外最弱的覆盖标准是D
，最强的覆盖标准E 。

A：①表明软件的正确性 ②评价软件质量③尽可能发现软件中错误 ④判定软件是否合格
B：①系统测试 ②安装测试 ③验收测试
④单元测试

C：①黑盒测试方法 ②白盒测试方法 ③灰盒测试方法 ④软件验收方法

D、E：①条件覆盖 ②条件组合覆盖 ③判定覆盖 ④条件及判定覆盖 ⑤语句覆盖

A：③ B：④ C：②
D：⑤ E：②

软件维护阶段：

从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。根据引起软件维护的原因可分成改正性维护、适应性维护、完善性维护、预防性维护。

1.6 软件开发工具与环境（CASE）

用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具，通常也称为CASE（计算机辅助软件工程）工具。

软件开发工具：

整个软件开发过程要使用很多开发工具：分析工具、设计工具、编程工具、测试工具、维护工具等等。

软件开发环境：支持软件产品开发的软件系统，它由软件工具集和环境集成机制构成。

集成型软件开发环境由工具集和环境集成机制组成，这种环境应该具有开放性和可剪裁性；

工具集包括支持软件开发相关过程、活动、任务的软件工具；

环境集成机制为工具集成和软件开发、维护和管理提供统一的支持。核心是环境数据库。

把一组相关的工具集成在环境中，提供数据集成、控制集成和界面集成等机制。

Ø 数据集成机制：

提供统一的数据模式和数据接口规范，需要相互协同的工具通过这种统一的规范交换数据。数据集成可由共享文件、共享数据结构或共享信息库等不同的层次；

Ø 控制集成机制：

支持各工具或各开发活动之间的通信、切换、调度和协同工作，并且支持软件开发过程的描述、执行和转接；通常消息传送的方式实现控制的集成。

Ø 界面集成机制

使这些工具具有统一的界面风格，从而为软件开发、维护、管理等过程的各项活动提供连续的、一致的全方位支持。

1.7 软件开发方法

1. 结构化方法

由结构化分析,结构化设计,结构化程序设计组成.它是一种面向数据流的开发方法.

结构化方法指导思想: 自顶向下和逐层分解,他的基本原则是功能的分解与抽象.特别适合于解决数据处理领域的问题,但不适用于解决大规模和特别复杂的项目且难以适应需求变化.

Jackson方法.

它是一种面向数据结构的开发方法.

JSP方法: 是以数据结构为驱动,适用于小规模项目,当输入数据结构和输出数据结构没有对应关系的时候,难以使用该方法.

JSD方法: JSP的扩充,是一种完整的系统开发方法.它特别强调操作之间的时序性,以事件作为驱动,是一种基于进程的开发方法.适用时序性较强的系统.如数据处理系统和实时控制系统.

面向对象的开发方法.

主要是: 按照人类思维方法和认识世界的方法来分析和解决问题,主要有Booch方法,Coad方法和OMT方法.

4. 基于构件的软件开发

5. 敏捷软件开发

强调软件开发的灵活性，核心是价值观与原则，实践是其核心的体现。包括Scrum（项目管理的框架，适用于难以精确预测的其他项目），极限编程（涵盖范围更广，包括价值观、原则和一组实践方式；价值观：沟通、简单、反馈、勇气、尊重；实践：故事、估算、简单设计、重构、测试驱动开发、结对编程、持续集成、短小发布、代码共享、编码标准等），看板方法（从改善入手强调价值流的快速流动）。

1.8 结构化分析与设计

1. 结构化分析（SA）方法

面向数据流的需求分析方法，它适用于分析大型数据处理系统。结构化分析方法的基本思想是自顶向下逐层分解，这样做可以把一个大问题分解成若干个小问题，经过多次逐层分解，每个最底层的问题都是足够简单、容易解决的。

结构化方法的分析结果由数据流图DFD、数据词典和加工逻辑说明几个部分组成。其中，DFD的基本成分有数据流（data flow）、加工（process）、文件（file）和源/宿（source/sink）。分解要尽可能均匀，呈椭圆形最好。

n 画数据流图的基本步骤：

画系统输入输出： 顶层图只有一个加工且通常没有文件，0层图只有一张。

画系统内部： 按功能分解或按业务处理流程确定加工。

画加工内部， 重复直到每个加工都是基本加工为止。

分层数据流图的一致性：

n 数据流图的父图与子图要平衡, 即输入和输出的数据流一致；

n 保持数据守恒：一个加工的所有输出数据必须能从该加工的所有的输入流中获得；

n 局部的数据存储不画出来，只有当局部数据存储作为某些数据加工之间的数据接口才画出，这有利于信息隐蔽；

n 一个加工的数据流与输出流不应该同名；

分层数据流图的完整性：

n 数据流图中的每个加工至少有一个输入数据流和一个输出数据流；

n 在整套数据流图中，每个文件都必须既有读文件的数据流也有写文件的数据流；

n 画数据流的时候每个数据流和文件都必须命名（除流入和流出文件的数据流）；

n 分层DFD中每个基本加工都有一个加工规约

数据字典：由字典条目组成，条目分为：数据流、文件、数据项（组成数据流和文件的数据）、加工、源或宿。

加工条目：核心是加工逻辑，分为基本加工和非基本加工。只需要对基本加工写小说明，描述一个加工做什么，其输入输出之间的逻辑关系。描述加工逻辑的方法：结构化语言、判定表、判定树。

结构化设计方法

结构化设计（SD）方法是一种面向数据流的设计方法，它可以与SA方法衔接。

结构化设计采用结构图（SC）来描述程序的结构。其基本成分有模块、调用和输入/输出数据。

在需求分析阶段用SA方法产生了数据流图（DFD）。面向数据流的设计可以方便的将DFD转换成程序结构图。DFD从系统的输入数据流到系统的输出数据流的一连串连续变换形成一条信息流。DFD的信息流大体可分为两种类型：变换流（输入、变换、输出）和事务流（根据数据类型选择）。

存在两种分析，变换分析和事务分析。变换分析是从变换流型的DFD导出程序结构图，而事务分析则是从事务流型的DFD导出程序结构图。

SD方法的具体设计步骤为：

Ø 复查并精化数据流图

Ø 确定DFD的信息流类型

Ø 根据信息流类型分别将变换流或事务流转换成程序结构图

Ø 根据软件设计的原则对程序结构图作改进

结构化程序设计

结构化程序（SP）设计采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。

描述工具：

图形描述工具（程序流程图、盒图（NS图）和问题分析图（PAD））

语言描述工具（PDL（program designlanguage））

表格描述工具（判定表和判定树）。

1.9 面向数据结构的Jackson方法

以数据结构为设计基础，设计目标是得出对程序处理过程的描述，其设计过程是从描绘数据结构的Jackson图推导出描绘程序结构的Jackson图。这种方法最适合于详细设计阶段使用。

具体设计步骤为：

Ø 分析并确定输入和输出的数据的逻辑结构，并用Jackson图表示

Ø 找出输入数据结构与输出数据结构间有对应关系的数据单元

Ø 从描述数据结构的Jackson图导出描述程序结构的Jackson图

1.10 面向对象技术

1 面向对象的基本概念

面向对象（object-oriented，OO）方法是以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式；软件系统易于维护，体系结构易于理解、扩充；继承机制支持复用。

◆对象（Object）

对象是和有数据及可对这些数据施加的操作结合在一起所构成的独立单位的总称。一个对象通常可由对象名、属性和操作三部分组成。

◆实例（Instance）

实例是由某个特定类所描述的一个对象。

◆类（Class）

一组具有相同属性和相同操作的对象的集合。类是面向对象的程序设计语言提供的可再用软件成分。

◆方法（Method）

对象所能执行的操作称为方法。方法是类中定义的函数，描述对象执行操作的算法。

◆消息（Message）

消息是对象间通信手段。一个消息通常包括接受对象名、调用的操作名和适当的参数（如有必要）。

◆分布式对象Distributed Object

　　在发布实施角度上看，对象可分为三种：本地对象，远地对象，虚拟对象。

本地对象Local Object ：指分布在同一个系统中的对象，互称为本地对象

远地对象Remote Object ：指分布在不同系统中的对象（同一个群体系统）。

虚拟对象Virtual Object ：不同于本地和远地对象，虚拟对象不属于真实的对象，而是一个虚设的类型。真正的操作不在虚拟对象本身，只是远地对象在本地的映射。

本地和远地对象是相互的关系。而虚拟对象只是一种映射，用于关联本地和远地对象，起到分布和负载均衡的作用。

面向对象数据库技术：面向对象技术和数据库技术的有机的结合，它有着关系数据库没有的优点。

面向对象数据库(OODB) +关系数据库（RDB）→对象－关系数据库(ORDB)

u 面向对象技术弥补了前述关系模型的固有局限性。

u 对象数据模型有很强的描述复杂对象的能力，能包含更多的数据语义信息。

u 面向对象方法可很方便的表示嵌套对象，因而很容易表达层次数据，这点与RDB形成鲜明的对比，RDB强迫用户用多个关系的元组表达层次数据。

u 面向对象方法可方便的构造各种类型、而RDB不提供增加用户定义数据类型的手段。

主要特点：

◆封装性

封装性是一种信息隐蔽技术，它使系统分析员能够清晰地标明他们所提供的服务界面，用户和应用程序员则只看得见对象提供的操作功能（即封装面上的信息），看不到其中的数据或操作代码细节。

◆多态性

多态性是指同一个操作作用于不同的对象可以有不同的解释，产生不同的执行结果。

◆继承性

继承是指在某个类的层次关联中，不同的类共享属性和操作的一种机制。一个父类可以有多个子类。父类描述了这些子类的公共属性和操作，子类中还可以定义其自己的属性和操作。如果一个子类只有唯一的一个父类，称为单一继承。如果一个子类有多个父类，可以从多个父类中继承特性，称为多重继承。

2 面向对象的分析方法

面向对象的系统分析步骤：

u 获取需求：包括场景和用例（所有用例构成系统的完整功能需求），形成需求模型。

u 标识类和对象

u 定义类的层次和结构（一般-特殊结构和整体-部分结构）

u 建造对象-关系模型（静态结构）

u 建造对象-行为模型（动态行为，指出系统如何响应）

u 利用用例/场景来复审分析模型

3 面向对象设计方法

u 设计步骤：

u 系统设计

u 对象设计

u 消息设计

u 复审

面向对象的类设计相关原则：

1. 开闭原则（the Open Closed Principle OCP）

　　一个模块在扩展开放的而在更改封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法。

2. 替换原则 (the Liskov Substitution PrincipleLSP)

　　子类应当可以替换父类并出现在父类能够出现的任何地方。

3. 依赖倒转原则 (the Dependency InversionPrinciple DIP)

　　在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。

　　在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。

4. 接口分离原则（the Interface SegregationPrinciple ISP）

　　采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。

　　ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。

　　这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

4 面向对象的方法

PeterCoard和Edward Yourdon的OOA和OOD方法

OOA（面向对象分析）模型由5个层次和5个活动组成：

5个层次：主题层、对象类层、结构层、属性层、服务层

5个活动：标识对象类、标识结构、定义主题、定义属性、定义服务

在这种方法中定义两种对象类之间的结构：

分类结构——反映了一般与特殊的关系

组装结构——反映了对象之间整体与部分的关系

OOA中的5个层次和5个活动继续贯穿在OOD（面向对象设计）过程中。OOD模型由4个部分，即：

Ø 问题域

Ø 人机交互

Ø 任务管理

Ø 数据管理

Booth的OOD方法

Booth认为软件开发是一个螺旋上升的过程。在螺旋上升的每个周期中，有4个步骤：

Ø 标识类和对象

Ø 确定它们的含义

Ø 标识它们之间的关系

Ø 说明每一个类的界面和实现

OMT方法

OMT（对象建模技术）定义了3种模型：

Ø 对象模型

描述系统中对象的静态结构、对象之间的关系、对象的属性、对象的操作。它为动态模型和功能模型提供了基本的框架。用对象图表示。

Ø 动态模型：

描述与时间和操作顺序有关的系统特征——激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。用状态图表示。

Ø 功能模型：

描述与值的变换有关的系统特征——功能、映射、约束和函数依赖。用数据流图表示。

OMT方法有4个步骤

分析：这是OMT方法的第一步，其目的是建立可理解的现实世界模型。

系统设计：确定整个系统的体系结构，形成求解问题和建立解答的高层次策略。

对象设计：在分析的基础上，对象设计阶段建立基于分析模型的设计模型，考虑实现的细节。

实现：将对象设计阶段开发的对象类及其关系转换成特定的程序设计语言、数据库或硬件的实现。

5 UML

1. 基本概念

方法包括模型，模型用来描述内容，传达使用一个方法的结果，模型用建模语言表达，建模语言由记号和一组如何使用它的规则组成。

视图是从某个角度观察到的系统的特殊侧面，由若干个图组成，每幅图由若干模型元素组成。

2. 面向对象建模

用例建模：描述系统应该做什么，主要成分有用例、执行者、系统
静态建模：描述类及类之间的关系，展示了软件的静态结构
动态建模：描述动态行为，显示对象的动态交互
物理体系结构建模：描述系统硬件结构，代码模块的物理结构和依赖关系等

例题：

国家标准《计算机软件产品开发文件编制指南GB8567-88》中规定，在一项软件开发过程中，一般来说应该产生14种文件。

管理人员主要使用的有A 、B 、C 、开发进度月报、项目开发总结报告。

开发人员主要使用的有A 、B 、D 、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划和E 。

维护人员主要使用的有设计说明书、E和C 。

A~E：①软件需求说明书 ②项目开发计划 ③可行性研究报告

④模块开发卷宗 ⑤测试分析报告 ⑥操作手册

⑦用户手册

[分析]

对软件生命周期的每个阶段（如需求分析、软件设计、软件维护等）的相关知识应该仔细复习，对整个软件生命周期各阶段还应有个总体的认识和把握。

[答案]

A：② B：③ C：④ D：① E：⑤

同步辅导中的软件工程部分的题目很好，大家可以做一下，题目类型和软考类似；

1.11 软件项目管理

1. 软件项目管理概述

软件项目管理：

对于人员、产品、过程和项目进行管理，目的是有效利用各种资源使系统按计划和质量要求如期完成。

作为软件管理人员，应该站在高处来俯瞰整个项目。软件项目的管理工作可以分位四个方面：软件项目的计划、软件项目的组织、软件项目的领导和软件项目的控制.

软件项目的计划

包括定义项目的目标，以及达到目标的方法。涉及到项目实施的各个环节，带有全局的性质。计划应力求完备，要考虑到未知因素和不确定因素，考虑到可能的修改。计划应力求准确，尽可能提高所依据的数据的可靠程度。

主要工作：软件项目的估算、软件开发成本的估算和软件项目进度安排。

目标：提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应在软件项目开始时的一段时间内做出，并随项目进展更新。

2. 软件度量

软件度量对产品及开发产品的过程进行度量。外部属性（体现与环境和相关资源的关系）可以直接测量，而内部属性（产品本身属性）一般需要间接测量。

面向规模的度量：软件规模代码行，不够客观

面向功能的度量：考虑软件的功能性和实用性。功能点FP：基于软件信息域的特征（可直接测量）和软件复杂度计算的。

面向人的度量

程序复杂度度量：McCabe环形复杂度度量

对于强连通的有向图G，e为图中弧数，n是节点数，p是强连通分量的个数，则G的环数V(G) = e – n + p 当环数超过10时模块难分析。

软件可靠性度量：平均故障间隔时间= 平均故障时间+平均修复时间

软件可用性：平均故障时间/平均故障间隔时间*100%

3. 软件项目估算

估算方法：

基于已经完成的类似项目
基于分解技术，进行问题分解和过程分解
基于经验估算模型，如IBM, CoCoMo模型

代码行、功能点和工作量估算

IBM模型是基于代码行的静态单变量模型。

CoCoMo模型分为基本、中间和详细三级别。

软件可靠性估算：错误植入法、分别测试法、软件平均故障间隔时间估算

　　软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。现在已经使用的使用技术是时间和工作量的估算。估算是其他项目计划活动的基石，而项目计划又为软件工程过程提供工作方向，所以不能没有计划就着手开发。

估算本身带有风险，估算资源、成本和项目进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算的精确程度受到多方面的影响。

首先，项目的复杂性对于增加软件计划的不确定性影响很大，复杂性越高，估算的风险就越高。复杂性是相对度量的，他与项目参加人员的经验有关。

其次，项目的规模对于估算的精确性和功效的影响也比较大，因为随着软件规模的扩大，软件相同元素之间的相互依赖、相互影响也迅速增加，因而估算时进行问题分解也会变得更加困难。

还有项目的结构化程度也影响项目估算的风险，这里的结构性是指功能分解的简便性和处理信息的层次性，结构化程度提高，进行精确估算的能力就提高，相应风险将减少。

此外，历史信息的有效性也影响估算的风险，在对过去的项目进行这综合的软件度量之后，就可以借用来比较准确地进行估算。影响估算的因素远不止这些，如用户需求的频繁变更给估算带来非常大的影响。

估算的依据是软件的范围，包括功能，性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进行评价，并对其进行细化以便提供细节。由于成本和进度的估算都与功能有关，因此采用功能分解的办法。性能的考虑主要包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储和其他现有系统对软件的限制。

　　另外软件项目计划还要完成资源估算，包括人力资源、硬件资源和软件资源。在考虑各种软件开发资源时最重要的是人，必须考虑人员的技术水平、专业、人数以及在开发过程各阶段对各种人员的需要。硬件资源作为一种工具投入。软件资源包括各种帮助开发的软件工具，比如编程工具、管理工具、测试工具，还有操作系统和数据库等。

　　工作量估算是最普遍使用的技术。经过功能分解之后，可以估计出每一个项目任务的分解都需要花费若干人年，总计之后就知道软件项目总体工作量。下面就是一个示意性工作量估算表。

表格1 某软件系统工作量估算表（单位：人日）

任务	需求分析	设计	编码	测试	小计
用户定义	2	5	1	0.5	8.5
系统定义	2	5	1	0.5	8.5
广告预定	4	10	2	0.5	16.5
划版	5	20	10	0.5	35.5
制作和组版	3	5	3	1	12
总计	16	45	17	3	81

4. 软件进度管理

考虑软件交付用户使用的这一段开发时间的安排。进度安排的准确程度可能比成本估计的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。

考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不致被拖延。

在进行进度安排时要考虑的一个主要问题是任务的并行性问题。进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。

常用的进度安排方法有两种，即甘特图（Gantt Chart）法（能清晰地描述任务的开始,结束以及进展；无法反映各个任务之间的依赖关系,难以确定其关键所在）和项目计划评审技术(PERT图)：能准确的反映出各个任务之间的关系与找出关键路径.但无法反映任务的并行关系。

5. 风险管理

风险因素：性能、成本、支持、进度

风险标识（包括项目风险—对软件项目不良影响、技术风险—软件质量和交付时间、商业风险—生存能力）

风险预测（建立风险表）

风险评估（风险、概率、影响三元组）

风险管理与监控（风险避免、监控、计划）

6. 软件项目的组织

目的：尽早落实责任、减少交流接口、责权均衡

A 组织结构

开发组织形式由软件项目的特点和参加人员的素质决定。有三种组织结构模式：

　　1. 按课题组划分的模式：把开发人员按课题组成小组，小组成员自始至终承担课题的各项任务。该模式适用于规模不大的项目，并且要求小组成员在各方面有技术专长。

　　2. 按职能划分的模式：把开发项目的软件人员按任务的工作阶段划分为若干工作小组。要开发的软件在每个专业小组完成阶段加工后沿工序流水线向下传递。这种流水作业的方式使用于多项目并行的情况。

　　3. 矩阵形模型：这种模式是以上两种模式的复合。一方面按工作性质成立一些专门小组，另一方面每一个项目都有它的经理人员负责。每一个软件开发人员属于某一个专门小组，有参加某一个项目的工作。

该模式的优点有一方面参加专门组的成员可以在组内交流在各个项目中取得的经验，这更有利于发挥专业人员的作用；另一方面，各个项目有专门的人员负责，有利于软件项目的完成。这种模式比较适合于规模比较大的项目。

组织结构的最后一层是程序设计小组的组织形式。通常认为程序设计工作是按独立的方式进行的，程序人员独立地完成任务。但这并不意味着相互之间没有联系。小组内部人员的组织形式对对生产率有着十分重要的影响。

常见的小组组织形式有三种，这三种形式可以灵活使用。

　　1. 主程序员制小组：相当于组长负责制，小组的核心由一位主程序员，另外配备两到三位技术员、一位后援工程师组成。这种组织结构突出主程序员的领导，强调主程序员与其他技术人员的联系。

　　2. 民主制小组：在民主制小组中，遇到问题可以在组员之间平等地交换换意见，工作组目标的制定以及决定的作出都由全体人员参加。这种组织形式强调发挥每个成员的积极性，并要求每个成员发挥主动精神和协作精神。

　　3. 层次式小组：在层次式小组中，组内人员分位三级：组长（项目负责人）一人负责全组工作，他直接领导两到三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种结构比较适合于项目本身就是层次结构的课题。

B 人员配备

　　合理地配备人员是成功地完成软件项目的切实保证。所谓合理地配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段不同层次技术人员的参与情况是不一样的。下图是典型的软件开发人员参与情况曲线。

在人力配备问题上，由于配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。

　　

7. 软件质量管理（重点）

软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。

如下是McCall模型:

	质量因素	定义
产品运行	正确性	系统满足规格说明和用户目标的程序，即在预定环境下能正确的完成预期功能的程序
健壮性	在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程序
效率	为了完成预定的功能，系统需要的计算资源的多少
完整性（安全性）	对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程序
可用性	系统在完成预定应该完成的功能时令人满意的程度
产品修改	可测试性	软件容易测试的程度
可维修性	诊断和改正在运行现场发现的错误所需要的工作量的多少
灵活性（适应性）	修改或改进正在运行的系统需要的工作量的多少
产品转移	可再用性	在其他应用中该程序可以被再次使用的程度（或范围）
互运行性	把该系统和另一个系统结合起来需要的工作量的多少
可移植性	把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少

♦功用性（Functionality），即软件是否满足了客户功能要求；
♦可靠性（Reliability），即软件是否能够一直在一个稳定的状态上满足可用性；
♦可用性（Usability），即衡量用户能够使用软件需要多大的努力；
♦效率（Efficiency），即衡量软件正常运行需要耗费多少资源；
♦可维护性（Maintainability），即衡量对已经完成的软件进行调整需要多大的努力；
♦可移植性（Portability），即衡量软件是否能够方便地部署到不同的运行环境中。

高质量软件的特性：

u 满足用户的需求

u 合理进度、成本、功能关系。

u 具备扩展性和灵活性，能够适应一定程度的需求变化。

u 能够有效的处理例外的情况。

u 保持成本和性能的平衡。

u 能够可持续的发展，知识沉淀。

采用测试作为评价软件标准的做法是非常常见的。例如，sun公司就专门设计了测试软件，对各个实现J2EE规范的产品进行测试。使用测试作为规范的最大好处就是明确、具体。

使用测试代码建立目标，编写代码完成测试目标，再制定下一个目标，如此循环，构成了测试驱动开发的工作流程。

质量管理步骤:

软件质量保证：保证软件系统或软件产品最大限度的满足用户要求而进行的有计划、有组织的活动，其目的是产生高质量的软件。由管理层的审计和报告构成。

目前有多种软件质量模型来描述软件质量特性，如ISO/IEC9126软件质量模型、Mc Call软件质量模型等

8. 软件配置管理

软件配置管理（SCM——SoftwareConfiguration Management）是ISO9001和CMM Level2中的重要组成元素，它在软件产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理软件工程的方法，是软件开发和维护的基础。

主要活动有：版本控制、变更控制、配置审核和配置状态报告。

SCM是指通过技术及行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施和过程，它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理。SCM可以协调软件开发使得混乱减到最小，是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产效率。

SCM使软件产品变为受控的和可预见的，它控制这样几个问题：

1． 谁做的变更？

2． 软件有什么变更？

3． 什么时间做的变更？

4． 为何要变更？

通过实施SCM，可以达到可重用过程制度化，包括：满足组织的政策方针、计划和过程描述文档化、分配适当资源（包括资金，人员和工具）、确定责任和权限、培训相关人员、通过不同级别的管理方法和纠正活动检测状态。

置于SCM之下的工作产品包括发送给用户的软件产品（如软件需求文档，软件代码），用于内部使用的软件工作产品（如过程描述），和用于创建工作产品的工具等（如操作系统、数据库、开发工具）。

SCM还用于建立和维护软件工作产品基线。

基线：

由配置项及相关实体组成的，包括组成软件产品的相关版本、设计、代码、用户文档等。它是软件生命周期中各开发阶段末尾的特定点，即里程碑。

通过正式的技术评审而得到的软件配置的正式文本才能成为基线，它的作用是使各个阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。基线是配置项继续发展的一个固定基础。

实施SCM对软件开发者、测试者、项目经理、QA人员、客户都将会有好处：有助于规范团队各个角色的行为，同时又为各个角色之间的任务传递和交流提供无缝的接合；能帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。

SCM分为四大功能领域：配置标识、变更控制、配置状态统计、配置审核。

配置标识：

包括标识软件系统的结构，标识独立部件，并使它们是可访问的。目的是在整个生命周期中标识系统各部件并提供对软件及其软件产品的跟踪能力。

配置变更控制：

包括在软件生命周期中控制软件产品的发布和变更，目的是建立确保软件产品质量的机制。它回答：什么是受控的？受控产品怎样变更？谁控制变更？何时接受，恢复，验证变更？

配置状态统计：

包括记录和报告变更过程，目标是不间断记录所有基线项的状态和历史，并进行维护，它解决以下问题：系统已经做了什么变更？此问题将会对多少个文件产生影响？

配置审核：

将验证软件产品的构造是否符合需求、标准、或合同的要求，目的是根据SCM的过程和程序，验证所有的软件产品已经产生并有正确标识和描述，所有的变更需求都已解决。

SCM从应用层次上可以从低到高分为三级：版本控制、以开发者为中心、过程驱动。

版本控制：

主要应用于个人独立开发或小组开发，它可以控制任何文件的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信息，主要工具有我们目前用到的Visual SourceSafe及Intersolv PVCS。

以开发者为中心：

主要应用于部门级开发，它可用于软件维护、不断增加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能最大限度地利用人力资源，主要工具为RationalClearCase及MKS Source Integrity。

过程驱动：

主要使用于企业级开发，着重解决新的工具引入、IT审核、管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问题，实现真正规范的团队开发。

9. 软件过程改进

目前，CMM已经发展到CMMI（Capability Maturity Model Integration，能力成熟度模型集成）阶段。SEI开发了一系列涉及多个学科的CMM标准，包括系统工程、软件工程、软件获取、生产力实践及集成产品和过程开发，希望通过帮助组织提高人员、技术和过程的成熟度来改善组织整体软件生产能力。

然而，多个模型的同时使用限制和阻碍了组织过程改善的能力。于是，SEI中止了对CMMI源模型的更新，开始集中开发CMMI项目。

CMMI项目为工业界和政府部门提供了一个集成的产品集，主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。

SW-CMM主要应用在两大方面：能力评估和过程改善。

1. 能力评估

SW-CMM是基于政府评估软件承包商的软件能力发展而来的，有两种通用的评估方法用以评估组织软件过程的成熟度：软件过程评估和软件能力评价。

● 软件过程评估:

用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改善问题，为组织领导层提供报告以获得组织对软件过程改善的支持。

集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改善的支持。 CBA-IPI是一种软件过程评估方法。

● 软件能力评价:

用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。

集中关注识别在预算和进度要求范围内完成制造出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。

SCE是SEI开发的一种基于CMM面向软件能力评价的方法。

SW-CMM分为5个成熟度等级：初始级、可重复级、已定义级、可管理级和优化级。其中每个成熟度等级都是由一些关键过程域和关键实践组成。

CMM的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

企业实施CMM模型并评估的好处：

指导软件组织提高软件开发管理能力；

降低软件承包商和采购者的风险；评估软件承包商的软件开发管理能力；

帮助软件企业识别开发和维护软件的有效过程和关键实践，识别为达到CMM更高成熟等级所必须的关键实践；增加软件企业的国际竞争能力。

CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。

除了初始级别以外，CMM的每个成熟级别的实现都定义成可操作的，每一级包含了实现这一级目标的若干关键过程域（KPA），共有18个关键过程域（KPA）分布于2、3、4、5级当中，如下表所示。

成熟级	关键过程域（KPA）
5、优化级 (Optimizing)	缺陷预防（Defect Prevention）
技术变更管理（Technology Change Management）
过程变更管理（Process Change Management）
4、管理级 (Managed)	量化过程管理（Quantitative Process Management）
软件质量管理（Software Quality Management）
3、定义级 (Defined)	软件机构过程关注点（Organization Process Focus）
组织过程定义（Organization Process Definition）
培训计划（Training Program）
集成软件管理（Integrated Software Management）
软件产品工程（Software Product Engineering）
组间合作（Intergroup Coordination）
同行评审（Peer Reviews）
2、可重复级 (Repeatable)	需求管理（Requirement Management）
软件项目计划（Software Project Planning）
软件项目跟踪及监督（Software Project Tracking and Oversight）
软件质量保证（Software Quality Assurance）
软件配置管理（Software Configuration Management）
软件子合同管理（Software Subcontract Management）
初始级 (Initial)	无

每个KPA都是由关键实施活动（KP）所组成，它们的执行表明该KPA在一个组织内部得到实现。

2. 过程改善

一个持续的、全员参与的过程。SW-CMM建立了一组有效地描述成熟软件组织特征的准则。该准则清晰地描述了软件过程的关键元素，并包括软件工程和管理方面的优秀实践。

软件过程改进：

　　"软件危机"：软件质量达不到要求，软件项目无法按时完成和软件项目的花费超预算。在试图解决这个危机时，就引入了软件工程过程管理与软件工程过程改进的概念。

软件工程过程管理：

把整个软件的生命周期，从原始概念到产品维护，制订出-个明确合理的工程过程加以管理。过程管理不会压制专业人员的创造性。好的工程过程会保证软件项目不会陷入混乱状态，开发人员有充分的时间按计划进行创造。

　　如何进行软件过程管理与改进，卡内基梅隆大学的软件工程研究所SEI(Software Engineering Institute)提出了SW-CMM，它将软件过程的成熟度分为五级，描述了企业要达到每一个级别所必须要做的工作。企业通过使用这个模型，一级级地去提高它们的软件开发及生产能力。

CMM实施中应注意的问题 ：

1、 剪裁的问题

CMM是为承接政府(或军方)大型软件合同的软件企业为对象而制订出来的。中小型企业在采用CMM的时候， 必须按照企业本身的特点和需要去剪裁和解释它的条文。CMM就好比是一份包括各种等级的国宴的菜单。但如果你是中小型饭店或家庭,绝不能照搬国宴菜单，只能用作参考。正确的态度是把CMM作为一个参考模型，而不是一个必须完全照办的标准。

2、ISO9001与CMM的关系

国际标准化组织的质量管理标准ISO9000与CMM均可作为软件企业的过程改善框架. CMM仅仅适用于软件行业,而ISO9000的适应面更广,但绝不是说ISO9000不适合软件企业.实际上ISO9000:2000版标准和CMM遵循共同的管理思想,ISO9000:2000版标准已经彻底解决了94版的制造业痕迹较重,

就目前软件企业实施ISO9000失败的原因来看,主要是未考虑软件行业特点和企业公司特点,盲目照搬其它行业和公司的模式;领导的重视程度和推行力度不够.这些问题不解决,实施CMM同样会失败.

就内容来讲,ISO9001不覆盖CMM，CMM也不完全覆盖ISO9000。通过ISO9001认证的企业可达到CMM 2级或略高的程度，通过CMM3级的企业做补充，就可通过ISO 9001认证。ISO 9001近似于CMM 2.5级。

3、时间和效果的问题

　　(1)、CMM只是说明达到某一级别必须做的工作,并未按说明如何实施,所以需要企业结合自身的情况,对软件过程进行认真的策划,建立符合企业特点有效的管理体系。

(2) 、CMM费用远大于实施ISO9000的费用,因为CMM比ISO9000更复杂,要求也更详细。

　　(3)、实际一个管理过程的改进是一步步实现的