1、软件工程知识
1.1概述
软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。其目的是提高软件生产率、提高软件质量、减低软件成本。
软件工程是1968年在德国的NATO会议上提出的，希望用工程化的原则和方法来克服软件危机；而软件危机就是软件开发和维护过程中的各种问题，由于软件开发阶段缺乏好的方法的指导和好的工具的辅助，而且缺少有关的文档，使得大量的软件难以维护。
软件生命周期是指由软件定义、软件开发和软件维护等阶段组成的全过程，反映软件生存期内各种工作得组织以及各个阶段如何衔接。下表归纳了软件生存周期各个阶段的任务、参与人员和产生文档。
常见的软件开发模型有瀑布模型、演化模型、螺旋模型和喷泉模型等。
|
阶段 |
任务 |
参与人员 |
产生文档 |
|
|
软件定义阶段——待开发软件要“做什么” |
||||
|
系统分析 |
确定待开发软件的总体要求和适用范围，以及与之有关的硬件、支撑软件的要求 |
用户、项目负责人、系统分析员 |
可合并项目计划书中 |
|
|
软件项目计划 |
确定待开发软件的目标，对其进行可行性分析，并对资源分配、进度安排等做出合理的计划 |
用户、项目负责人、系统分析员 |
可行性分析报告、项目计划书 |
|
|
需求分析 |
确定待开发软件的功能、性能、界面等要求，从而确定系统的逻辑模型 |
用户、项目负责人、系统分析员 |
需求规格说明书 |
|
|
软件开发阶段——待开发软件“怎么做” |
||||
|
软件设计 |
概要设计 |
模块分解，确定软件的结构，模块的功能和模块间的接口，以及全局数据结构的设计 |
系统分析员、高级程序员 |
设计说明书、数据说明书、模块开发卷宗 |
|
详细设计 |
设计每个模块的实现细节和局部数据结构的设计 |
高级程序员、程序员 |
||
|
编码 |
用某种程序语言为每个模块编写程序 |
高级程序员、程序员 |
程序清单 |
|
|
软件测试 |
发现软件中的错误，并加以纠正 |
高级程序员或系统分析员（另一部门或单位） |
软件测试计划、软件测试用例说明，软件测试报告 |
|
|
软件维护阶段—开发后交付使用的软件的维护 |
||||
|
软件维护 |
使软件适应外界环境的变化、实现功能的扩充和质量的改善而修改软件 |
维护人员 |
维护计划、维护报告 |
|
软件由计算机程序、数据及文档组成，同时与硬件、数据库人、过程等共同构成计算机系统。软件工程包括三个要素：方法、工具和过程。
主要的软件开发方法有以下几种方法：
生命周期法：命周期法认为：每一个软件系统都有一定的生命周期。软件的生命周期是指一个软件系统从其提出、调查到分析、设计和有效使用，直至被淘汰或取代的整个期间。软件生命周期法就是按软件生命周期的各个阶段划分任务，按一定的规则和步骤，有效地进行软件开发的方法。
通常一个软件系统的生命周期可分为五个阶段：准备阶段、分析阶段、设计阶段、实施阶段、运行与维护阶段
原型法：原型法是先根据用户的最主要要求，开发出能实现系统最基本功能的一个原型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。
原型法分4个阶段：确定用户需求；设计原型；使用、评价原型；修改、完善原型。
1.2软件分析
软件开发模型：瀑布模型；演化模型（原型法）；螺旋模型；喷泉模型（迭代和无间隙）；软件成本模型；可行性分析的任务是从技术上、经济上、使用上、法律上分析需解决的问题是否存在可行的解。
需求分析是软件生存周期中相当重要的一个阶段。需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体有以下几点：
Ø 确定软件系统的综合要求
Ø 分析软件系统的数据要求
Ø 导出系统的逻辑模型
Ø 修正项目开发计划
Ø 如有必要，可开发一个原型系统
需求分析的基本原则是能够表达和理解问题的信息域和功能域；以层次化的方式进行分解和不断细化；要给出系统的逻辑视图和物理视图；
描述软件需求的方法：
功能层次模型：一般来讲就是系统的功能图，模块分布图等描述整个系统的功能的分布和功能的层次结构；
数据流模型：就是以数据流为着眼点的分析方法得到的模型，主要通过数据在整个系统的流动情况来确定系统的主要功能主线和流程；
控制流模型：通过了解和界定系统中控制线，通过控制流的走向和控制的对象来确定系统的功能分布和控制与被控制的关系；
结构化分析（SA）方法是一种面向数据流的需求分析方法，它适用于分析大型数据处理系统。结构化分析方法的基本思想是自顶向下逐层分解，这样做可以把一个大问题分解成若干个小问题，经过多次逐层分解，每个最底层的问题都是足够简单、容易解决的，这个过程就是分解的过程。
结构化方法的分析结果由数据流图DFD、数据词典和加工逻辑说明几个部分组成。其中，DFD的基本成分有数据流（data flow）、加工（process）、文件（file）和源/宿（so rce/si k）。
画数据流图的基本步骤：自外向内、自顶向下、逐层细化、完善求精；
数据流图的父图与子图要平衡, 即输入和输出的数据流一致；
数据流图中的每个加工至少有一个输入数据流和一个输出数据流；
局部的数据存储不画出来，只有当局部数据存储作为某些数据加工之间的数据接口才画出，这有利于信息隐蔽；
画数据流的时候不画控制流，两者的区别就是控制流中没有数据；
一个加工的数据流与输出流不应该同名；
允许一个加工有多条数据流流向另一个加工，也允许一个加工有两个相同的输出流向两个不同的加工；
保持数据守恒：一个加工的所有输出数据必须能从该加工的所有的输入流中获得；
在整套数据流图中，每个文件都必须既有读文件的数据流也有写文件的数据流；
软件开发过程中的软件工程原则（8个）：
Ø 抽象；
Ø 自顶向下、逐层细化；
Ø 信息隐蔽和数据封装；
Ø 模块化；
Ø 局部化；
Ø 确定性；
Ø 一致性和标准化；
Ø 完备性和可验证性；
软件工程基本原理（7个）：
按软件生存周期分阶段指定计划并认真实施；
坚持进行阶段评审；
坚持严格的产品控制；
使用现代程序设计技术；
明确责任，使得工作结果能够得到清楚的审查；
用人少而精；
不断改进开发过程；
1.3软件设计
软件设计原则: 软件设计的原则对提高软件的设计质量有很大的帮助。
◆ 抽象
抽象是指忽视一个主题中与当前目标无关的那些方面，以便更充分地注意与当前目标有关的方面。过程抽象和数据抽象是常用的两种主要抽象手段。
◆ 模块化
模块化是指将一个待开发的软件分解成若干个小的简单的部分——模块，每个模块可独立地开发、测试、最后组装成完整的软件。这是一种复杂问题的“分而治之”的原则。
模块是指执行某一特定任务的数据结构和程序代码。一个模块有它的外部特征和内部特征。
◆ 信息隐蔽
信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，定义每一个模块时尽可能少地显露其内部的处理。信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。
◆ 模块独立
模块独立是指每个模块完成一个相对独立的子功能，并且与其他模块之间的联系简单。衡量模块独立程度的度量标准有两个：耦合和内聚。
耦合是指模块之间联系的紧密程度。耦合度越高则模块的独立性越差。按耦合度从低到高依次有7种耦合方式。
Ø 非直接耦合（独立运行）
Ø 数据耦合（用参数表传递简单数据）
Ø 标记耦合（传递数据结构或者一部分）
Ø 控制耦合（传递的信息包括控制模块的信息）
Ø 外部耦合（模块与软件之外的环境有关）
Ø 公共耦合（多个模块引用同一全局的数据区）
Ø 内容耦合（访问内部数据，代码重叠或者多个入口）
内聚是指模块内部各元素之间联系的紧密程度内聚度越低模块的独立性越差。按内聚度从低到高依次有7种内聚种类。
Ø 偶然内聚（模块完成的多个任务，任务之间的关系松散）
Ø 逻辑内聚（模块完成逻辑相关的一组任务）
Ø 瞬时内聚（模块的所有任务必须在同一时间间隔内执行）
Ø 过程内聚（模块的处理元素相关而且按照特定的次序执行）
Ø 通信内聚（模块的所有元素集中在一个数据结构区域上）
Ø 顺序内聚（模块的处理元素相关，必须顺序执行）
Ø 功能内聚（模块完成单一的功能，各个部分协调工作，而且不可缺少）
模块分解原则：
Ø 满足信息隐蔽；
Ø 尽量内聚度高，模块间偶合度低；
Ø 模块大小在（50-100语句）；
Ø 模块调用深度不能过大；
Ø 模块的扇入（直接调用该模块）应尽量大，扇出（直接调用下级模块数）不宜过大；
Ø 设计单入口和单出口的模块；
Ø 模块的作用域应在控制域之内：
作用域：受模块内一个判定影响的所有的模块的集合；
控制域：该模块本身和被该模块直接或间接调用的所有的模块的集合；
Ø 模块的功能应是可以预测的，相同输入得到相同输出
结构化设计方法
结构化设计（SD）方法是一种面向数据流的设计方法，它可以与SA方法衔接。
结构化设计采用结构图（SC）来描述程序的结构。其基本成分有模块、调用和输入/输出数据。
在需求分析阶段用SA方法产生了数据流图（DFD）。面向数据流的设计可以方便的将DFD转换成程序结构图。DFD从系统的输入数据流到系统的输出数据流的一连串连续变换形成一条信息流。DFD的信息流大体可分为两种类型：变换流和事务流。与之对应的也存在两种分析，变换分析和事务分析。变换分析是从变换流型的DFD导出程序结构图，而事务分析则是从事务流行型的DFD导出程序结构图。
SD方法的具体设计步骤为：
Ø 复查并精化数据流图
Ø 确定DFD的信息流类型
Ø 根据信息流类型分别将变换流或事务流转换成程序结构图
Ø 根据软件设计的原则对程序结构图作改进
结构化程序设计
结构化程序（SP）设计采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。
结构化程序设计的描述工具主要有图形描述工具、语言描述工具和表格描述工具。常用的图形描述工具有程序流程图、盒图（NS图）和问题分析图（PAD）。典型的语言描述工具是PDL（program desig la g age）。典型的表格描述工具是判定表和判定树。
面向数据结构的Jackso 方法也十分常用:
Jackso 方法是以数据结构为设计基础，设计目标是得出对程序处理过程的描述，其设计过程是从描绘数据结构的Jackso 图推导出描绘程序结构的Jackso 图。这种方法最适合于详细设计阶段使用。
Jackso 方法的具体设计步骤为：
Ø 分析并确定输入和输出的数据的逻辑结构，并用Jackso 图表示
Ø 找出输入数据结构与输出数据结构间有对应关系的数据单元
Ø 从描述数据结构的Jackso 图导出描述程序结构的Jackso 图
软件编码：
根据详细设计说明书编写程序，为开发项目选择程序设计语言需要考虑的因素有应用领域、算法和计算的复杂性、软件运行环境、用户需求、数据结构和开发人员的水平。软件的设计质量与程序设计语言的技术性能无关，但在程序设计转向程序代码时，转化的质量受语言性能的影响。
好的程序应该具有模块化结构，系统应该有较高的模块独立性。
从应用领域看，COBOL适合商业领域；FORTRAN适合科学计算；PROLOG和LISP适合人工智能领域；SMALLTALK、C++、JAVA是面向对象语言；C是开发系统的程序设计语言；
例题1：
软件设计中划分模块的一个准则是A 。两个模块之间的耦合方式中，B耦合的耦合度最高，C耦合的耦合度最低。一个模块内部的内聚种类中D内聚的内聚度最高，E内聚的内聚度最低。
A： ①低内聚低耦合 ②低内聚高耦合 ③高内聚低耦合 ④高内聚高耦合
B： ①数据 ②非直接 ③控制 ④内容
C： ①数据 ②非直接 ③控制 ④内容
D： ①偶然 ②逻辑 ③功能 ④过程
E： ①偶然 ②逻辑 ③功能 ④过
A 3 B 4 C 2 D 3 E 1
例题2
关于程序模块优化的启发式规则有若干条，以下规则中不符合优化原则的是__B__。如果一个模块调用下层模块时传递一个数据结构，则这种耦合属于_C_。（软件工程）
|
(30)A．通过模块的合并和分解，降低模块的耦合度，提高模块的内聚性 |
|||
|
B．提高上层模块的扇出，减少模块调用的层次 |
|||
|
C．将模块的作用范围限制在模块的控制范围之内 |
|||
|
D．降低模块之间接口的复杂性，避免“病态连接” |
|||
|
(31)A．简单耦合 |
B．直接耦合 |
C.标记耦合 |
D．控制耦合 |
1.4软件测试
对源程序最基本的质量要求是正确性和可靠性，此外还很注重软件的易使用性、易维护性和易移植性。软件测试的工作量约占软件开发总工作量的40%以上，其目的是尽可能多的发现软件产品（主要是指程序）中的错误和缺陷。
软件测试是自底向上，逐步集成的过程，低一级测试为上一级测试准备条件；
测试的关键是测试用例的设计，其方法可分为两类。
白盒测试：
白盒测试是根据程序的内部逻辑来设计测试用例，常用的技术是逻辑覆盖，即考察用例测试数据运行被测程序时对程序逻辑的覆盖程度。主要的覆盖标准有6种：
I. 语句覆盖
指选择足够的测试用例，使被测语句的每个语句至少执行一次。
II.判定覆盖
指选择足够的测试用例，使每个判定的所有可能结果至少出现一次。
III.条件覆盖
指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次。
IV. 判定/条件覆盖
指选择足够的测试用例，使判定中的每个条件的所有可能结果至少出现一次，并且每个判定中条件结果的所有可能组合也至少出现一次。
V. 条件组合覆盖
指选择足够的测试用例，使每个判定中条件结果的所有可能组合至少出现一次。
VI. 路径覆盖
指选择足够的测试用例，使流程图中的每条路径至少经过一次。
黑盒测试：
黑盒测试时根据规格说明所规定的功能来设计测试用例，它不考虑程序的内部结构和处理过程。常用的黑盒测试技术有：
Ø 等价类划分
Ø 边值划分
Ø 错误猜测
软件测试的主要步骤有单元测试、集成测试和确认测试。
单元测试：
主要用来发现编码和详细设计中产生的错误，一般在编码阶段，采用白盒测试。
集成测试（也称组装测试）：
主要用来发现设计阶段产生的错误，是对各模块组装而成的程序进行测试，主要检查模块间的接口和通信，采用黑盒测试。
集成测试按集成方式又可分成非渐增式集成和渐增式集成，而渐增式集成又可分成自顶向下集成和自底向上集成。
确认测试：
检查软件的功能、性能和其他特征是否与用户需求一致，它以需求规格说明书作测试为依据，采用黑盒测试
Alpha测试是在开发者的现场由客户来实施的，从用户角度和环境下进行；
Beta测试是在开发者不在现场下测试，由软件最终用户实施；
使用各种测试方法的综合策略：
在任何情况下都必须使用边界值分析方法，用这种方法设计出测试用例发现程序错误的能力最强；
必要时用等价类划分方法补充一些测试用例；
用错误推测法再追加一些测试用例
对照程序逻辑，检查已有测试用例的逻辑覆盖程度
如果程序的功能说明中含有输入条件的组合情况，则选用因果图法
例题：
软件测试的目的是A 。通常B是在代码编写阶段可进行的测试，它是整个测试工作的基础。
逻辑覆盖标准主要用于C 。它主要包括条件覆盖、条件组合（多重条件）覆盖、判定覆盖、条件及判定覆盖、语句覆盖和路径覆盖等几种，其中除路径覆盖外最弱的覆盖标准是D ，最强的覆盖标准E 。
A： ①表明软件的正确性 ②评价软件质量
③尽可能发现软件中错误 ④判定软件是否合格
B： ①系统测试 ②安装测试 ③验收测试 ④单元测试
C： ①黑盒测试方法 ②白盒测试方法 ③灰盒测试方法 ④软件验收方法
D、E： ①条件覆盖 ②条件组合覆盖 ③判定覆盖
④条件及判定覆盖 ⑤语句覆盖
A：③ B：④ C：② D：⑤ E：②
1.5软件开发工具与环境（CASE）
用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具，通常也称为CASE（计算机辅助软件工程）工具。
整个软件开发过程要使用很多开发工具，其中包括分析工具、设计工具、编程工具、测试工具、维护工具等等。
软件开发工具是指支持软件产品开发的软件系统，它由软件工具集和环境集成机智构成。工具集包括支持软件开发相关过程、活动、任务的软件工具；环境集成机智为工具集成和软件开发、维护和管理提供统一的支持。
软件开发环境是把一组相关的工具集成在环境中，提供数据集成、控制集成和界面集成等机制。其中：
Ø 数据集成机制：提供统一的数据模式和数据接口规范，需要相互协同的工具通过这种统一的规范交换数据。数据集成可由共享文件、共享数据结构或共享信息库等不同的层次；
Ø 控制集成机制：支持各工具或各开发活动之间的通信、切换、调度和协同工作，并且支持软件开发过程的描述、执行和转接；通常消息传送的方式实现控制的集成。
Ø 界面集成机制使这些工具具有统一的界面风格，从而为软件开发、维护、管理等过程的各项活动提供连续的、一致的全方位支持。
集成型软件开发环境由工具集和环境集成机制组成，这种环境应该具有开放性和可剪裁性；
环境集成机制的核心是环境数据库。
1.6软件维护和软件管理
软件开发项目管理基础知识（时间管理、成本管理、质量管理、人力资源管理、风险管理等）及其常用管理工具
软件维护阶段是指从软件交付使用到软件被淘汰为止的整个时期，它是在软件交付使用后，为了改正软件中隐藏的错误，或者为了使软件适应新的环境，或者为了扩充和完善软件的功能或性能而修改软件的过程。根据引起软件维护的原因，软件维护通常可分成改正性维护、适应性维护、完善性维护、预防性维护。
软件管理工作涉及到软件开发工作的方方面面，其直接对象包括人、财、物，简单地说，人就是指软件开发人员，财就是指项目经费，物就是指软件项目。也许还没有关于这方面的专门理论，但在工商管理领域已经有十分成熟的管理学理论，他山之石，可以攻玉，所以我们完全可以引进到软件项目方面的管理。
作为软件管理人员，应该站在高处来俯瞰整个项目，如果有不识庐山真面目的感觉就不太好了。有了俯瞰全局的意识这一前提，采用适当的管理技术，项目开展就容易罗。软件项目的管理工作可以分位四个方面：软件项目的计划、软件项目的组织、软件项目的领导和软件项目的控制.
1 软件项目的计划
软件开发项目的计划包括定义项目的目标，以及达到目标的方法。他涉及到项目实施的各个环节，带有全局的性质，是战略性的。计划应力求完备，要考虑到一些未知因素和不确定因素，考虑到可能的修改。计划应力求准确，尽可能提高所依据的数据的可靠程度。主要工作集中在软件项目的估算、软件开发成本的估算和软件项目进度安排。软件项目计划的目标是提供一个能使项目管理人员对资源、成本和进度做出合理估算的框架。这些估算应在软件项目开始时的一段有限时间内作出，并随着项目的进展进行更新。
2 软件项目的估算
软件项目管理过程开始于项目的计划，在做项目计划时，第一项活动是估算。现在已经使用的使用技术是时间和工作量的估算。因为估算是其他项目计划活动的基石，而且项目计划又未软件工程过程提供了工作方向，所以我们不能没有计划就着手开发，否则就会陷入盲目性。
估算本身带有风险，估算资源、成本和项目进度时需要经验、有用的历史信息、足够的定量数据和作定量度量的勇气。估算的精确程度受到多方面的影响。首先，项目的复杂性对于增加软件计划的不确定性影响很大，复杂性越高，估算的风险就越高。复杂性是相对度量的，他与项目参加人员的经验有关，比如如果让搞MIS的项目组去搞操作系统设计显然增加了复杂性。其次，项目的规模对于估算的精确性和功效的影响也比较大，因为随着软件规模的扩大，软件相同元素之间的相互依赖、相互影响也迅速增加，因而估算时进行问题分解也会变得更加困难。还有项目的结构化程度也影响项目估算的风险，这里的结构性是指功能分解的简便性和处理信息的层次性，结构化程度提高，进行精确估算的能力就提高，相应风险将减少。此外，历史信息的有效性也影响估算的风险，在对过去的项目进行这综合的软件度量之后，就可以借用来比较准确地进行估算。影响估算的因素远不止这些，比如用户需求的频繁变更给估算带来非常大的影响。
估算的依据是软件的范围，包括功能，性能、限制、接口和可靠性。在估算开始之前，应对软件的功能进行评价，并对其进行适当的细化以便提供更详细的细节。由于成本和进度的估算都与功能有关，因此常常采用功能分解的办法。性能的考虑主要包括处理和响应时间的需求。约束条件则标识外部硬件、可用存储和其他现有系统对软件的限制。
另外软件项目计划还要完成资源估算，包括人力资源、硬件资源和软件资源。在考虑各种软件开发资源时最重要的是人，必须考虑人员的技术水平、专业、人数以及在开发过程各阶段对各种人员的需要。硬件资源作为一种工具投入。软件资源包括各种帮助开发的软件工具，比如编程工具、管理工具、测试工具，还有操作系统和数据库等。
工作两估算是最普遍使用的技术。经过功能分解之后，可以估计出每一个项目任务的分解都需要花费若干人年，总计之后就知道软件项目总体工作量。下面就是一个示意性工作量估算表。
表格 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 |
软件开发成本的估算
软件开发成本主要是指软件开发过程所花费的工作量及其相应的代价。它不同于其他物理产品的成本，它主要包括人的劳动的消耗，人的劳动的消耗所需的代价就是软件产品的开发成本。
开发成本的估算方法有很多种，象简单的代码行技术，任务分解技术，自动估计成本技术，专家判定技术，还有参数方程法，标准值法，以及COCOMO模型法。其中COCOMO (Co str ctive Cost Model)模型法是一种精确、易于使用的成本估算方法，该模型按其详细程度分为三级：基本COCOMO模型、中间COCOMO模型和详细COCOMO模型
软件项目进度安排
软件项目的进度安排主要是考虑软件交付用户使用的这一段开发时间的安排。进度安排的准确程度可能比成本估计的准确程度更重要。软件产品可以靠重新定价或者靠大量的销售来弥补成本的增加，但进度安排的落空会导致市场机会的丧失或者用户不满意，而且也会导致成本的增加。因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法严密监视软件开发的进展情况，以使得软件开发的进度不致被拖延。
在进行进度安排时要考虑的一个主要问题是任务的并行性问题。当参加项目的人数不止一人是软件开发工作就会出现并行情况。因为并行任务是同时发生的所以进度计划表必须决定任务之间的从属关系，确定各个任务的先后次序和衔接，确定各个任务完成的持续时间。另外还应注意关键路径的任务，这样可以确定在进度安排中应保证的重点。常用的进度安排方法有两种，即甘特图（Ga tt Chart）法和工程网络法。
3.软件项目的组织
参加软件开发的人员如何组织起来，使他们发挥最大的工作效率，对成功地完成软件项目极为重要。
组织结构
开发组织采用什么形式由软件项目的特点决定，同时也与参加人员的素质有关。通常有三种组织结构模式：
1. 按课题组划分的模式：把开发人员按课题组成小组，小组成员自始至终承担课题的各项任务。该模式适用于规模不大的项目，并且要求小组成员在各方面有技术专长。
2. 按职能划分的模式：把开发项目的软件人员按任务的工作阶段划分为若干工作小组。要开发的软件在每个专业小组完成阶段加工后沿工序流水线向下传递。这种流水作业的方式使用于多项目并行的情况。
3. 矩阵形模型：这种模式是以上两种模式的复合。一方面按工作性质成立一些专门小组，另一方面每一个项目都有它的经理人员负责。每一个软件开发人员属于某一个专门小组，有参加某一个项目的工作。该模式的优点有一方面参加专门组的成员可以在组内交流在各个项目中取得的经验，这更有利于发挥专业人员的作用；另一方面，各个项目有专门的人员负责，有利于软件项目的完成。这种模式比较适合于规模比较大的项目。
组织结构的最后一层是程序设计小组的组织形式。通常认为程序设计工作是按独立的方式进行的，程序人员独立地完成任务。但这并不意味着相互之间没有联系。一般在人数比较少时组员之间的联系比较简单，但随着人数的增加，相互之间的联系变得负责起来。小组内部人员的组织形式对对生产率有着十分重要的影响。
常见的小组组织形式有三种，这三种形式可以灵活使用。
1. 主程序员制小组：相当于组长负责制，小组的核心由一位主程序员，另外配备两到三位技术员、一位后援工程师组成。这种组织结构突出主程序员的领导，强调主程序员与其他技术人员的联系。
2. *制小组：在*制小组中，遇到问题可以在组员之间平等地交换换意见，工作组目标的制定以及决定的作出都由全体人员参加。这种组织形式强调发挥每个成员的积极性，并要求每个成员发挥主动精神和协作精神。
3. 层次式小组：在层次式小组中，组内人员分位三级：组长（项目负责人）一人负责全组工作，他直接领导两到三名高级程序员，每位高级程序员通过基层小组，管理若干位程序员。这种结构比较适合于项目本身就是层次结构的课题。
人员配备
合理地配备人员是成功地完成软件项目的切实保证。所谓合理地配备人员应包括按不同阶段适时运用人员，恰当掌握用人标准。一般来说，软件项目不同阶段不同层次技术人员的参与情况是不一样的。下图是典型的软件开发人员参与情况曲线。
在人力配备问题上，由于配置不当，很容易造成人力资源的浪费，并延误工期。特别是采用恒定人员配备方案时在项目的开始和最后都会出现人力过剩，而在中期又会出现人力不足的情况。
4.软件项目的领导
5.软件项目的控制
对后面两个主题以后再讨论。其实本文所讨论的东西大多还没有涉及太多管理学方面的内容，但这方面确实有许多值得研究的东西，由于时间关系不能深入下去。姑且作为一个引子吧！
1.7面向对象技术
1.7.1面向对象的基本概念
面向对象（object-orie ted，OO）方法是以客观世界中的对象为中心，其分析和设计思想符合人们的思维方式，分析和设计的结果与客观世界的实际比较接近，容易被人们所接受。下面列举几个面向对象设计方法中的重要术语，它们构成面向对象的程序设计语言的核心。
◆对象（Object）
对象是和有数据及可对这些数据施加的操作结合在一起所构成的独立单位的总称。一个对象通常可由对象名、属性和操作三部分组成。
对象的划分判定标准：
1、 子对象之间独立性要高，即耦合度尽量达到最低，（理想的情况是达到组件化的程度）；
2、 子对象相对其他划分方法，更易于处理。所以对于复杂的大系统，一般都要经过多次的尝试，以尽量能找到较优的划分方案。对于比较简单的系统，E-R转换也能的到较为满意的划分。
◆实例（I sta ce）
实例是由某个特定类所描述的一个对象。
◆类（Class）
类是一组具有相同属性和相同操作的对象的集合。类是面向对象的程序设计语言提供的可再用软件成分。
◆方法（Method）
对象所能执行的操作称为方法。方法是类中定义的函数，描述对象执行操作的算法。
◆消息（Message）
消息是要求某个对象执行类中定义的某个操作的规格说明。一个消息通常包括接受对象名、调用的操作名和适当的参数（如有必要）。
主要特点：
◆封装性
封装性是一种信息隐蔽技术，它使系统分析员能够清晰地标明他们所提供的服务界面，用户和应用程序员则只看得见对象提供的操作功能（即封装面上的信息），看不到其中的数据或操作代码细节。
◆多态性
多态性是指同一个操作作用于不同的对象可以有不同的解释，产生不同的执行结果。
◆继承性
继承是指在某个类的层次关联中，不同的类共享属性和操作的一种机制。一个父类可以有多个子类。父类描述了这些子类的公共属性和操作，子类中还可以定义其自己的属性和操作。如果一个子类只有唯一的一个父类，这种继承称为单一继承。如果一个子类有多个父类，可以从多个父类中继承特性，这种继承称为多重继承。
◆分布式对象Distrib ted Object
在发布实施角度上看，对象可分为三种：本地对象，远地对象，虚拟对象。
本地对象Local Object ：指分布在同一个系统中的对象，互称为本地对象
远地对象Remote Object ：指分布在不同系统中的对象（同一个群体系统）。
虚拟对象Virt al Object ：不同于本地和远地对象，虚拟对象不属于真实的对象，而是一个虚设的类型。真正的操作不在虚拟对象本身，只是远地对象在本地的映射。
本地和远地对象是相互的关系。而虚拟对象只是一种映射，用于关联本地和远地对象，起到分布和负载均衡的作用。
面向对象数据库技术：是面向对象技术和数据库技术的有机的结合，它有着关系数据库没有的优点。
面向对象数据库(OODB) +关系数据库（RDB）→对象－关系数据库(ORDB)
面向对象的特征：类和继承性，对象及对象标识、封装性、信息/实现隐蔽、状态保持，消息，多态性，一般性。
面向对象技术的出现正是弥补了前述关系模型的固有局限性。
对象数据模型是有很强的描述复杂对象的能力，能包含更多的数据语义信息。
面向对象方法可很方便的表示嵌套对象，因而很容易表达层次数据，这点与RDB形成鲜明的对比，RDB强迫用户用多个关系的元组表达层次数据。
面向对象方法可方便的构造各种类型、而RDB不提供增加用户定义数据类型的手段。
1.7.2面向对象的分析方法
面向对象的系统分析设计，看起来其实也很简单，步骤大概如下：
（1）从项目开始，进行步骤（2）。
（2）对系统进行分析，如果它在一定的要求下可解决，则停止分析，进行设计；如果它在一定的要求下不可解决，则对它进行划分。
（3）步骤（2）如果有分析结果，则对其中每一个子对象，进行步骤（2）。
边界条件（也即上面提到的“一定要求”，对象划分的原则）：
子对象之间独立性要高，即耦合度尽量达到最低，（理想的情况是达到组件化的程度）；
子对象相对其他划分方法，更易于处理（如实现，维护等）。
当前常见的面向对象的方法很多，下面简单介绍三种:
Peter Coard和Edward Yo rdo 的OOA和OOD方法
OOA（面向对象分析）模型由5个层次和5个活动组成：
5个层次：主题层、对象类层、结构层、属性层、服务层
5个活动：标识对象类、标识结构、定义主题、定义属性、定义服务
在这种方法中定义两种对象类之间的结构：
分类结构——反映了一般与特殊的关系
组装结构——反映了对象之间整体与部分的关系
OOA中的5个层次和5个活动继续贯穿在OOD（面向对象设计）过程中。OOD模型由4个部分，即：
Ø 问题域
Ø 人机交互
Ø 任务管理
Ø 数据管理
Booth的OOD方法
Booth认为软件开发是一个螺旋上升的过程。在螺旋上升的每个周期中，有4个步骤：
Ø 标识类和对象
Ø 确定它们的含义
Ø 标识它们之间的关系
Ø 说明每一个类的界面和实现
OMT方法
OMT（对象建模技术）定义了3种模型：
Ø 对象模型
描述系统中对象的静态结构、对象之间的关系、对象的属性、对象的操作。它为动态模型和功能模型提供了基本的框架。用对象图表示。
Ø 动态模型：
描述与时间和操作顺序有关的系统特征——激发事件、事件序列、确定事件先后关系的状态以及事件和状态的组织。用状态图表示。
Ø 功能模型：
描述与值的变换有关的系统特征——功能、映射、约束和函数依赖。用数据流图表示。
OMT方法有4个步骤
分析：这是OMT方法的第一步，其目的是建立可理解的现实世界模型。
系统设计：确定整个系统的体系结构，形成求解问题和建立解答的高层次策略。
对象设计：在分析的基础上，对象设计阶段建立基于分析模型的设计模型，考虑实现的细节。
实现：将对象设计阶段开发的对象类及其关系转换成特定的程序设计语言、数据库或硬件的实现。
1.7.3面向对象设计方法
面向对象的类设计相关原则：
1. 开闭原则（the Ope Closed Pri ciple OCP）
一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象设计的方法，是软件工程设计方法的重要原则之一。
2. 替换原则 (the Liskov S bstit tio Pri ciple LSP)
子类应当可以替换父类并出现在父类能够出现的任何地方。这个原则是Liskov于1987年提出的设计原则。它同样可以从Bertra d Meyer 的DBC (Desig by Co tract) 的概念推出。
3. 依赖原则 (the Depe de cy I versio Pri ciple DIP)
在进行业务设计时，与特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。
为此，我们在进行业务设计时，应尽量在接口或抽象类中定义业务方法的原型，并通过具体的实现类（子类）来实现该业务方法，业务方法内容的修改将不会影响到运行时业务方法的调用。
4. 接口分离原则（the I terface Segregatio Pri ciple ISP）
采用多个与特定客户类有关的接口比采用一个通用的涵盖多个业务方法的接口要好。
ISP原则是另外一个支持诸如COM等组件化的使能技术。缺少ISP，组件、类的可用性和移植性将大打折扣。
这个原则的本质相当简单。如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。
例题：
国家标准《计算机软件产品开发文件编制指南GB8567-88》中规定，在一项软件开发过程中，一般来说应该产生14种文件，其中管理人员主要使用的有A 、B 、C 、开发进度月报、项目开发总结报告。开发人员主要使用的有A 、B 、D 、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、测试计划和E 。维护人员主要使用的有设计说明书、E和C 。
A~E：①软件需求说明书 ②项目开发计划 ③可行性研究报告
④模块开发卷宗 ⑤测试分析报告 ⑥操作手册
⑦用户手册
[分析]
本题综合考查了软件生命周期各个阶段的相关知识。
大家在复习软件工程这部分内容的时候，除了对软件生命周期的每个阶段（如需求分析、软件设计、软件维护等）的相关知识应该仔细复习以外，对整个软件生命周期各阶段还应有个总体的认识和把握。前面在知识要点中有比较表对各阶段的任务、参与人员和产生文档做出了归纳和总结，大家复习的时候可以好好参考一下。
[答案]
A：② B：③ C：④ D：① E：⑤
同步辅导中的软件工程部分的题目很好，大家可以做一下，题目类型和软考类似；
1.8软件质量（重点）
软件质量是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体。下面从管理的角度列出了影响软件质量的主要因素。
|
|
质量因素 |
定义 |
|
产品运行 |
正确性 |
系统满足规格说明和用户目标的程序，即在预定环境下能正确的完成预期功能的程序 |
|
健壮性 |
在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程序 |
|
|
效率 |
为了完成预定的功能，系统需要的计算资源的多少 |
|
|
完整性（安全性） |
对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程序 |
|
|
可用性 |
系统在完成预定应该完成的功能时令人满意的程度 |
|
|
风险 |
按预定的成本和进度将系统开发处理，并且为用户满意的概率 |
|
|
产品修改 |
可理解性 |
理解和使用该系统的容易程度 |
|
可维修性 |
诊断和改正在运行现场发现的错误所需要的工作量的多少 |
|
|
灵活性（适应性） |
修改或改进正在运行的系统需要的工作量的多少 |
|
|
可测试性 |
软件容易测试的程度 |
|
|
产品转移 |
可移植性 |
把程序从一种硬件配置和（或）软件系统环境转移到另一种配置和环境时，需要的工作量多少 |
|
可再用性 |
在其他应用中该程序可以被再次使用的程度（或范围） |
|
|
互运行性 |
把该系统和另一个系统结合起来需要的工作量的多少 |
高质量软件的特性：
满足用户的需求。这是最重要的一点，一个软件如果不能够满足用户的需要，设计的再好，采用的技术再先进，也没有任何的意义。所以这一点非常的朴实，但却是软件质量的第一个评判标准。
合理进度、成本、功能关系。软件开发中所有的管理都是围绕着这几个要素在做文章的，如何在特定的时间内，以特定的成本，开发出特定功能的软件。三者之间存在一种微妙的平衡。一个高质量的软件的开发过程中，项目成员一定能够客观的对待这三个因素，并通过有效的计划、管理、控制，使得三者之间达成一种平衡，保证产出的最大化。
具备扩展性和灵活性，能够适应一定程度的需求变化。当今的社会已经变成一种变化速度极快的设计了。变化就会对软件产生冲击，所以一个质量优秀的软件，应该能够在一定程度上适应这种变化，并保持软件的稳定。
能够有效的处理例外的情况。写过软件的人都知道，实现主体功能的工作量其实不大，真正的工作量都在处理各种例外。所以，一个软件如果能够足够的强壮、足够的鲁棒，能够承受各种的非法情况的冲击，这个软件就是高质量的。
保持成本和性能的平衡。性能往往来源于客户的非功能需求，是软件质量的一个重要的评价因素。但是性能问题在任何地方都存在，所以需要客观的看待它。例如，一段性能不错的代码可能可读性很差，这就需要进行平衡，如果这段代码的性能是整个软件的关键，那么取高性能而舍弃可读性，反之则取可读性而舍弃高性能。一个优秀的软件能够保持成本和性能之间的平衡。
能够可持续的发展。很少有软件组织只开发一个软件的，所以，一个优秀的软件在开发完成后，可以形成知识沉淀，为软件组织的长期发展贡献力量。这是一个优秀的软件应该要能够做到的。
采用测试作为评价软件标准的做法是非常常见的。例如，s 公司就专门设计了测试软件，对各个实现J2EE规范的产品进行测试。使用测试作为规范的最大好处就是明确、具体。
使用测试代码建立目标，编写代码完成测试目标，再制定下一个目标，如此循环，构成了测试驱动开发的工作流程。
1.8.1八项质量管理原则
为了成功地领导和运作一个组织，需要采用一种系统和透明的方式进行管理。针对所有相关方的需求，实施并保持持续改进其业绩的管理体系，使组织获得成功。组织为实现质量目标，应遵循以下八项质量管理原则。
原则1：以顾客为中心
组织依存于其顾客。因此，组织应理解顾客当前的和未来的需求，满足顾客要求并争取超越顾客期望。
1、 组织实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则2：领导作用
领导将本组织的宗旨、方向和内部环境统一起来，并创造使员工能够充分参与实现组织目标的环境。
1、 组织实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则3：全员参与
各级人员是组织之本。只有他们的充分参与，才能使他们的才干为组织带来最大的收益。
1、 织实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则4：过程方法
将相关的资源和活动作为过程进行管理，可以更高效地得到期望的结果。
过程方法的原则不仅适用于某些较简单的过程，也适用于由许多过程构成的过程网络。在应用于质量管理体系时，2000版ISO9000族标准建立了一个过程模式。此模式把管理职责、资源管理、产品实现、测量、分析与改进作为体系的四大主要过程，描述其相互关系，并以顾客要求为输入，提供给顾客的产品为输出，通过信息反馈来测定的顾客满意度，评价质量管理体系的业绩。
1、 实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则5：管理的系统方法
针对设定的目标，识别、理解并管理一个由相互关连的过程所组成的体系，有助于提高组织的有效性和效率。
ISO/DIS9000的3.3列出了建立和实施质量管理体系的十三个步骤：
1、 实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则6：持续改进
持续改进是组织的一个永恒的目标。
1、 实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则7：基于事实的决策方法
对数据和信息的逻辑分析或直觉判断是有效决策的基础。
以事实为依据做决策，可防止决策失误。在对信息和资料做科学分析时，统计技术是最重要的工具之一。统计技术可以用来测量、分析和说明产品和过程的变异性。统计技术可以为持续改进的决策提供依据。
1、 实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
原则8：互利的供方关系
通过互利的关系，增强组织及其供方创造价值的能力。
供方提供的产品将对组织向顾客提供满意的产品可能产生重要的影响，一次处理好与供方的关系，影响到组织能否持续稳定地提供顾客满意地产品。对供方不能只讲控制，不讲合作互利。特别对关键供方，更要建立互利关系。这对组织和供方双方都是有利的。
1、 实施本原则的主要利益
2、 组织实施本原则时一般要采取的主要措施
3、 本原则在标准中的体现
1.8.2十三个步骤:
软件质量保证是指为了保证软件系统或软件产品最大限度的满足用户要求而进行的有计划、有组织的活动，其目的是产生高质量的软件。目前有多种软件质量模型来描述软件质量特性，如ISO/IEC9126软件质量模型、Mc Call软件质量模型等
1.9软件配置管理
软件配置管理（SCM——Software Co fig ratio Ma ageme t）是ISO9001和CMM Level2中的重要组成元素，它在软件产品开发的生命周期中，提供了结构化的、有序化的、产品化的管理软件工程的方法，是软件开发和维护的基础。
SCM是指通过技术及行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施和过程，它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理。SCM可以协调软件开发使得混乱减到最小，是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产效率。
SCM使软件产品变为受控的和可预见的，它控制这样几个问题：
1． 谁做的变更？
2． 软件有什么变更？
3． 什么时间做的变更？
4． 为何要变更？
通过实施SCM，可以达到可重用过程制度化，包括：满足组织的政策方针、计划和过程描述文档化、分配适当资源（包括资金，人员和工具）、确定责任和权限、培训相关人员、通过不同级别的管理方法和纠正活动检测状态。
置于SCM之下的工作产品包括发送给用户的软件产品（如软件需求文档，软件代码），用于内部使用的软件工作产品（如过程描述），和用于创建工作产品的工具等（如操作系统、数据库、开发工具）。
SCM还用于建立和维护软件工作产品基线。基线是由配置项及相关实体组成的，包括组成软件产品的相关版本、设计、代码、用户文档等。它是软件生命周期中各开发阶段末尾的特定点，即里程碑。通过正式的技术评审而得到的软件配置的正式文本才能成为基线，它的作用是使各个阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，以便于检验和肯定阶段成果。基线是配置项继续发展的一个固定基础。
实施SCM不论是对软件开发者、测试者、项目经理、QA人员，还是客户都将会获得很多好处：有助于规范团队各个角色的行为，同时又为各个角色之间的任务传递和交流提供无缝的接合；能帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。
SCM分为四大功能领域：配置标识、变更控制、配置状态统计、配置审核。
配置标识：包括标识软件系统的结构，标识独立部件，并使它们是可访问的。配置标识的目的，是在整个生命周期中标识系统各部件并提供对软件及其软件产品的跟踪能力。
配置变更控制：包括在软件生命周期中控制软件产品的发布和变更，目的是建立确保软件产品质量的机制。它回答：什么是受控的？受控产品怎样变更？谁控制变更？何时接受，恢复，验证变更？
配置状态统计：包括记录和报告变更过程，目标是不间断记录所有基线项的状态和历史，并进行维护，它解决以下问题：系统已经做了什么变更？此问题将会对多少个文件产生影响？
配置审核：将验证软件产品的构造是否符合需求、标准、或合同的要求，目的是根据SCM的过程和程序，验证所有的软件产品已经产生并有正确标识和描述，所有的变更需求都已解决。
SCM从应用层次上可以从低到高分为三级：版本控制、以开发者为中心、过程驱动。
版本控制：主要应用于个人独立开发或小组开发，它可以控制任何文件的版本、实现分支和归并功能、进行文本比较、标记注释和版本报告信息，主要工具有我们目前用到的Vis al So rceSafe及I tersolv PVCS。
以开发者为中心：主要应用于部门级开发，它可用于软件维护、不断增加的开发任务、并行开发、QA及测试，它面向大型团队、利于交流、能最大限度地利用人力资源，主要工具为Ratio al ClearCase及MKS So rce I tegrity。
过程驱动：主要使用于企业级开发，着重解决新的工具引入、IT审核、管理报告、复杂的生命周期、应用工具包、集成解决方案、资料库等问题，实现真正规范的团队开发。
1.10软件过程改进
目前，CMM已经发展到CMMI（Capability Mat rity Model I tegratio ，能力成熟度模型集成）阶段。自20世纪80年代末以来，SEI开发了一系列涉及多个学科的CMM标准，包括系统工程、软件工程、软件获取、生产力实践及集成产品和过程开发，希望通过帮助组织提高人员、技术和过程的成熟度来改善组织整体软件生产能力。然而，多个模型的同时使用限制和阻碍了组织过程改善的能力。于是，SEI中止了对CMMI源模型的更新，开始集中开发CMMI项目。CMMI项目融合了SW-CMM v2.0 draft C、EIA/IS731、SECM以及IPD-CMM v0.98的内容，形成了组织范围内过程改善的单一集成模型。预计到2001年末，CMMI -SE/SW/IPPD/A ver1.1将正式发行。CMMI项目为工业界和*部门提供了一个集成的产品集，主要目的是消除不同模型之间的不一致和重复，降低基于模型改善的成本。未来的CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。
SW-CMM主要应用在两大方面：能力评估和过程改善。
1. 能力评估
SW-CMM是基于*评估软件承包商的软件能力发展而来的，有两种通用的评估方法用以评估组织软件过程的成熟度：软件过程评估和软件能力评价。
● 软件过程评估: 用于确定一个组织当前的软件工程过程状态及组织所面临的软件过程的优先改善问题，为组织领导层提供报告以获得组织对软件过程改善的支持。软件过程评估集中关注组织自身的软件过程，在一种合作的、开放的环境中进行。评估的成功取决于管理者和专业人员对组织软件过程改善的支持。CBA-IPI是一种软件过程评估方法，
● 软件能力评价: 用于识别合格的软件承包商或者监控软件承包商开发软件的过程状态。软件能力评价集中关注识别在预算和进度要求范围内完成制造出高质量的软件产品的软件合同及相关风险。评价在一种审核的环境中进行，重点在于揭示组织实际执行软件过程的文档化的审核记录。SCE是SEI开发的一种基于CMM面向软件能力评价的方法。
SW-CMM分为5个成熟度等级：初始级、可重复级、已定义级、可管理级和优化级。其中每个成熟度等级都是由一些关键过程域和关键实践组成。
CMM的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。企业实施CMM模型并评估可为企业带来如下好处：指导软件组织提高软件开发管理能力；降低软件承包商和采购者的风险；评估软件承包商的软件开发管理能力；帮助软件企业识别开发和维护软件的有效过程和关键实践；帮助软件企业识别为达到CMM更高成熟等级所必须的关键实践；增加软件企业的国际竞争能力。
CMM为企业的软件过程能力提供了一个阶梯式的进化框架，阶梯共有五级。第一级只是一个起点，任何准备按CMM体系进化的企业都自然处于这个起点上，并通过它向第二级迈进。除第一级外，每一级都设定了一组目标(Goals)，如果达到了这组目标，则表明达到了这个成熟级别，可以向下一级别迈进。
除了初始级别以外，CMM的每个成熟级别的实现都定义成可操作的，每一级包含了实现这一级目标的若干关键过程域（KPA），共有18个关键过程域（KPA）分布于2、3、4、5级当中，如下表所示。
|
成熟级 |
关键过程域（KPA） |
|
5、优化级 (Optimizi g) |
缺陷预防（Defect Preve tio ） |
|
技术变更管理（Tech ology Cha ge Ma ageme t） |
|
|
过程变更管理（Process Cha ge Ma ageme t） |
|
|
4、管理级 (Ma aged) |
量化过程管理（Q a titative Process Ma ageme t） |
|
软件质量管理（Software Q ality Ma ageme t） |
|
|
3、定义级 (Defi ed) |
软件机构过程关注点（Orga izatio Process Foc s） |
|
组织过程定义（Orga izatio Process Defi itio ） |
|
|
培训计划（Trai i g Program） |
|
|
集成软件管理（I tegrated Software Ma ageme t） |
|
|
软件产品工程（Software Prod ct E gi eeri g） |
|
|
组间合作（I tergro p Coordi atio ） |
|
|
同行评审（Peer Reviews） |
|
|
2、可重复级 (Repeatable) |
需求管理（Req ireme t Ma ageme t） |
|
软件项目计划（Software Project Pla i g） |
|
|
软件项目跟踪及监督（Software Project Tracki g a d Oversight） |
|
|
软件质量保证（Software Q ality Ass ra ce） |
|
|
软件配置管理（Software Co fig ratio Ma ageme t） |
|
|
软件子合同管理（Software S bco tract Ma ageme t） |
|
|
初始级 (I itial) |
无 |
每个KPA都是由关键实施活动（KP）所组成，它们的执行表明该KPA在一个组织内部得到实现。
2. 过程改善
软件过程改善是一个持续的、全员参与的过程。SW-CMM建立了一组有效地描述成熟软件组织特征的准则。该准则清晰地描述了软件过程的关键元素，并包括软件工程和管理方面的优秀实践。东软股份目前有选择地引用这些关键实践指导软件过程的开发和维护，以不断地改善组织软件过程，实现成本、进度、功能和产品质量等目标。
软件过程改进：
"软件危机"简单地说就是：软件质量达不到要求，软件项目无法按时完成和软件项目的花费超预算。这是一个世界性的问题。在试图解决这个危机时，就引入了软件工程过程管理与软件工程过程改进的概念。
软件工程过程管理就是要把整个软件的生命周期，从原始概念到产品维护，制订出-个明确合理的工程过程加以管理。过程管理不会压制专业人员的创造性。好的工程过程会保证软件项目不会陷入混乱状态，开发人员有充分的时间按计划进行创造。过程及其管理只不过是我们手中的一件工具，而且这件工具是我们为了自己而设计的。
一个企业软件工程过程的建立不会一开始就十全十美, 而且企业的内外部环境也是在不断地变化.所以软件的管理过程需要不断地改进。缺少了过程改进，再好的体系也会渐渐的变得过时和不适用，更没有可能使我们开发软件的能力逐步地成熟起来。所以不管是从提高内部的管理水平和赢得外部客户信任角度来讲，不断进行过程改进、向更高的成熟度迈进都是当今软件企业所必须要作的工作。
如何进行软件过程管理与改进，软件界的许多人提出了各种各样的方案。卡内基梅隆大学的软件工程研究所SEI(Software E gi eeri g I stit te)提出了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。一般而言，通过ISO 9001认证的企业可达到CMM 2级或略高的程度，通过CMM 3级的企业只要稍做补充，就可较容易地通过ISO 9001认证。粗略地说，ISO 9001近似于CMM 2.5级。
3、时间和效果的问题
目前整个中国的软件行业兴起一阵实施CMM的热潮,这对中国软件产业实在是一件好事,因为大家终于认识到软件开发过程管理的重要性.但针对以前ISO9000在其他行业及软件行业实施的经验教训,以下方面是软件界人士所必须关注的:
(1) 、CMM只是说明达到某一级别必须做的工作,并未按说明如何实施,所以需要企业结合自身的情况,对软件过程进行认真的策划,建立符合企业特点有效的管理体系。
(2) 、CMM费用远大于实施ISO9000的费用,是否所有企业都能够承担?实施后能否取得满意的效果?目前实施ISO9000取得非常满意效果的仅仅占一少部分;有一定效果的占一部份;剩下的为没什么效果,有的还束缚了企业的管理。CMM如果实施的没有效果,企业的投入不仅分文无归,而且会背上一个更大的包袱,因为CMM比ISO9000更复杂,要求也更详细。
(3) 、实际一个管理过程的改进是一步步实现的,但在中国很多企业(包括软件企业)实施ISO9000很多是快速完成,最短的三个月就可以完成,效果是可想而知的。国外的经验表明,企业实施CMM上升一级需要约16至24个月时间.中国的软件企业实施CMM时是否会重蹈ISO900O的覆辙?到那时受到更大伤害的只能是企业自己。