软件工程导论复习

【软件工程导论】

软件 = 知识+程序+数据+文档

文档的概念和作用文档记录软件开发的活动和中间制品，记录软件的配置及变更，用于软件专业人员和用户的交流，用于软件开发、过程管理和运行阶段的维护。如:需求报告对所开发软 件的功能、性能、用户界面及运行环境等作出详细的说明，它是用户与开发人员双方 对软件需求取得共同理解基础上达成的协议，也是实施开发工作的基础。设计说明书 是概要设计阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入 输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基 础。详细设计说明书着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等

软件特点：逻辑实体、智力产品;制造即拷贝;无磨损和老化,不遵循“浴盆曲线”,但 存在退化问题。尚未摆脱手工方式;软件移植的需要;复杂（问题复杂性 / 程序结构复 杂性）软件开发的性质如成本、进度、质量等难以估计控制,维护困难，有可复用性

定义:将系统的、规范的、可量化的方法应用于软件的开发、运行和维护的过程及上述方法的研究

三要素：过程:管理部分;方法:完成软件工程项目的技术手段;工具自动或 半自动地支持软件的开发、维护和管理。

目标：在给定成本、进度的前提下，开发出满足用户或市场需要的高质量的软件产品

原则：抽象(自顶向下逐步求精)、信息隐藏（封装的接口）、模块化（相对独立/类）、局部化（相互关联/局部变量）、一致性（接口和规范）、完全性和可验证性(应易于检查、测试和评审)

**传统软件生命周期:**需求,设计,编码、测试,软件测试,运行、维护,退役

瀑布模型生命周期:1 可行性研究,2 需求分析,3 概要设计,4 详细设计,5 实现,6 集成测试,7 确认 测试,8 使用与维护,9 退役(软件定义:1-2 软件开发 3-7 维护 8-9)

各种模型的含义、优缺点、场景:

**瀑布模型:**假设软件需求在初期几乎可完全确定;主要思想:1.软件开发过程与软件生 命周期是一致的;2.相邻二阶段之间存在因果关系 3.每一阶段的结束点作为里程碑;4. 需对阶段性产品进行评审，如果评审不合格,需返工;优点:**1.**使用时间最长,应用面比较广泛;2.是其他一些开发模型的基础;3.思路简洁,明确,阶段间因果明确,紧密联系;4. 其可行性研究、需求、设计、编码、测试分离,有利于软件的体系结构设计,规范了软 件开发活动,有利于开发人员的组织管理;5.缓解软件危机缺点:1.必须确定软件需求后 才能进行后续开发工作,但多数场合给出全部需求是困难的;**2.到最后阶段才能得到可运行的软件版本不能适应用户需求的变 化 ;3.上游阶段的“过失”会为软件制品带 来“缺陷”并潜伏在制品中,会误导下游的开发活动,若未被发现运行时会造成“故障” , 寻找修复故障会比较困难场景:**对于规模较小、软件需求比较稳定的项目或子系统,能够显著提高软件开发的质量和效率;原型模型:**概念:**软件开发人员根据客户提出的软件(部分或全部)定义,快速地开发一个原型。原型向客户展示了待开发软件系统的全部 或部分功能和性能,在征求客户对原型意见的过程中,进一步修改、完善、确认软件系 统的需求并达到一致的理解;**优点1.**支持需求的动态变化;**2.**有助于获取用户需求,便于用户对需求的理解;**3.**尽早发现软件中的错误;**缺点:不支持风险分析.适用场景：开发 团队对所开发领域比较熟悉而且有快速的原型开发工具螺旋模型: 基本思想:1.将瀑布模型与原型模型进行有机结合;2.增加风险分析步骤。优点:**1.支持需求的动态变化;2. 有助于获取用户需求,便于用户对需求的理解;3.尽早发现软件中的错误;4.支持风险分 析,可降低或者尽早消除软件开发风险;5.适合于需求动态变化、开发风险较大的系统; **缺点:**由于确定的不确定性,软件开发初期无法进行软件体系结构设计,多次迭代会导 致软件体系结构变坏,为软件理解和维护带来困难;场景:在需求不明确的情况下,适合用螺旋模型进行开发,便于风险控制和需求变更;特别适合于大型复杂的系统.原型模型和螺旋模型既是迭代模型,又是进化模型。 喷泉模型:基本思想:1.软件复用与生命周期中多项开发活动集成2.主要支持面向对象的开发方法;优点 1软件系统可维护性较好 2各阶段相互重叠,表明了面向对象开发方法各阶段间的交叉和无缝过渡 3整个模型是一个迭代的过程,包括一个阶段内部的迭代和跨阶段的迭代 4模型具有增量开发特性,即能做到“分析一点,设计一点,实现一点,测试一点”,使相关功能随之加入到演化的系统中 5模型由对象驱动,对象是各阶段活动的主体,也是项目管理的基本内容 6该模型很自然地支持软部件的重用。

工具： 项目管理工具 AMSRealtime,MicrosoftProject,Viewpoint, Project ControlPanel ,Ittoolkit 软件开发工具：业务系统建模工具：RationalRose,ArgoUML,Visio,Real-TimeStudo(以 上也可以是对应的分析和设计工具）测试工具：CodeMedic(为标准 UNIX 调试器 gdb 提供图形界面，支持 C/C++、Java、汇编、FORTRAN、Modua-2 测试) BugCollectorPro （实现多用户数据库，支持软件团队追踪已报告的 bug、管理调试工作 流） JprobeThreadAnalyzer（支持线程测试问题：死锁、延迟） C++Test（C／C++ 单元测试）**原型建造工具（专用性）用户界面工具:**Macromedia Authorware,PowerDesigner/PowerBuilder,MotifCommonDesktopEnvironment

【第 2 章 UML 与 RUP 统一过程】(用例图(UC图),类图)

面向对象的软件开发方法 面向对象的软件开发方法通过提供对象,对象间消息传递等语言机制让分析人员在解空间中直接模拟问题空间中的对象及其行为,从而削减了语义断层,拉近了问题空间与解空间的距离,从而简化了软件工程师在二者之间架设“桥梁”的工作,并为软件 开发活动提供了直观,自然的语言支持和方法学指导。

面向对象 = {对象+类+继承+聚合+多态+消息} 基本要素

面向对象方法的优势:1.简化软件开发过程。面向对象方法不仅可以用来进行需求分析，还可以支持软件 的设计、实现和测试，构成了覆盖软件开发主要阶段的广谱软件开发方法学。 2.支持软件复用。在源代码级复用方面，面向对象方法通过继承机制和代理方法使得复用者不需要直接修改被复用的类；在设计级复用方面，近年来迅速发展的设计技术在软件界大显身手，贡献良多。 3.改善软件结构。面向对象方法通过对属性和操作的封装实现了软件工程倡导的信息隐藏原则。

用例图:用例图，从外部用户的角度描述系统功能，并指出参与者. 1.关联：参与者—执行用例。2.**包含(**include):一个用例 A 使用了另外一个用例 B。 A- ->B。边上 include。3.扩展(extend):A 扩展自 B。A- ->B。边上 extend

**结构视图:**（不同层面,系统的静态结构): 包图(描述系统的分解结构,表示包与包之间的关系);对象图(类图的一个实例,描述在某个状态下,或者某个时间段系统中活跃的对象及关系);类图(描述系统静态结构),①泛化与特化：表示类的继承关系。子类 父类。 ②关联：类之间有关联（对象组合）A 类用到了 B 类的信息 A->B。一对多的时候，边 上：1—*。双向关联没有箭头，单向关联有箭头，我们一般用单向。 ③聚合：强关联，整体与部分的关系。Engine Car。一对多：1-*。 ④组合：强聚合，整体的对象负责代表部分的对象的生命周期。Limb MonkeyKing ⑤依赖： ClassA的定义依赖于 ClassB的定义。例子： A 的构造函数的参数中有 ClassB。 A 中有个函数以 B 作为参数。A - ->B。

行为视图: (不同侧面系统的动态行为):交互图［描述对象之间通过消息传递进行的交互和协作,分为**顺序图(**对象之间消息发送的时间序), 通信图(对象间的动态协作关系,也可通过消息序号表示消息传递的时间序,不如顺序图直观)］, 状态图(描述类的对象的动态行为), 活动图［控制流（一个操作完成后对其后续操 作的触发）、信息流（刻画操作间的信息交换）］

构件视图：构件图(描述软件系统中各组成构件,构件的内部结构以及构件间依赖关系)

部署视图：部署图（描述软件系统中各类工件在物理运行环境中的分布情况）

【第六章 软件设计基本原则】(PDL伪代码格式)

内聚度：偶然性内聚、逻辑性内聚、时间性内聚（经典内聚）/程度低/->过程性内聚,通信性内聚/程度中/->信息内聚,功能性内聚/程度高/

耦合度:：1 非直接耦合->2 数据耦合与控制耦合->3 外部耦合->4 公共耦合->5 内容耦合。尽量使用 1/2，限制 3/4，杜绝 5。

选三种内聚度、三种耦合度各举一个例子说明。

功能内聚：一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割.(不建议举此例)信息内聚：完成多个功能各个功能都在同一数据结构上操作，每一项功能 有一个唯一的入口点。如课程管理系统上的查找课程、删除课程、修改课程都会使用 “课程”这个数据结构。通信内聚：一个模块各个功能部分都使用了相同的输入数据， 或产生了相同的输出数据。个人信息管理系统中：从文件中读取信息，打印功能和统计功能都会使用文件中的信息。逻辑内聚：这种模块把几种相关的功能组合在一起， 每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。 非直接耦合：两个模块之间没有直接关系，它们之间的练习完全时通过主模块的控制 和调用来实现的。main()函数调用 A B C 函数，其中 A 用到 B 的返回值。控制耦合： 通过传送开关、标志、名字等控制信息，明显的控制选择另一模块的功能。如 A 的返 回值为 0 时调用 C，A 的返回值为 1 时调用 B。公共耦合：一组模块都访问同一个公 共数据环境。如 A\B 都调用以局部变量 time,并且会对其修改。

如何降低耦合度：根据问题的特点，选择适当的耦合类型；降低模块接口的复杂性(传送信息的数量,耦合方式,传送信息的结构)；把模块的通信信息放在缓冲区中;

软件设计的原则：提高模块独立性；调整模块的大小；适当的模块深度、宽度、扇出 和扇入模块的作用范围应在控制范围之内简化模块的接口的复杂程度。

启发式设计策略：改造软件结构，降低耦合度，提高内聚度；减少扇出，追求高扇入； 使任一模块的作用域在其控制域内(作用域是指受模块内部判定影响的所有模块,控制域是指其所有的下属模块);降低模块接口复杂度和冗余度,提高协调性。 变换流：信息通常以“外部世界”所具有的形式进入系统，经过处理后，又以这种形式离开系统，呈现在结果界面上。事务流数据沿输入通道到达一个转换，该转换根据输入流的类型和特征在若干动作路径中选择一条来执行。

变换分析：复审基本系统模型；理解和精化数据流图；确定数据流图的类型；划分输入流、输出流的边界；执行二级分解；精化、改良软件结构。

【第八章、人机交互设计】

老人：图片字体大且清晰，描述简单，目录层级少，打开步骤少，操作简单，实用性 好，功能不复杂、只需要基本功能 小孩：色彩丰富。避免繁杂，大量图片和文字作为提示，风格轻松愉快，宽松简洁的 布局，高明度色彩，带拼音，可爱的卡通形象和字体设计，趣味和有故事性的背景

用户界面设计的基本原则①易理解性；②易操作性；③灵敏性；④一致性；⑤容错 性；⑥人性化。

用户界面设计模型的表示：①静态元素（无变化的文本、图标、图形、图像等）； ②动态元素（因运行状态而异自动呈现的不允许修改的文本、表格、图标、图形、图 像等）；③用户输入元素（可编辑文本、单选按钮、多选框、选择列表、可编辑的表 格）；④用户命令元素（按钮、菜单、超链接等）。

用户界面设计过程的主要活动: 1.用户分析、任务分析及建模。首先必须分析用户的特征，分析用户需要通过目标软件系统完成哪些工作任务，为完成这些任务人机之间需要进行哪些信息交互。2.概念设计。主要目标是确定屏幕中应该包含的主要内容，以及用户基于该屏幕可施行的主要操作。3.界面流设计。主要目标是确定屏幕之间的跳转关系，即一幅屏幕在何种情况下,或者在响应何种用户操作命令后将跳转至另一屏幕.两种原因：①单屏幕空间容量有限，不足以表现所有必要界面元素；②用户的界面操作可能导出新的屏幕，以便在新的屏幕上进行面向特定业务功能的界面交互。表示方式主要是 UML 交互图（顺序图）和类图。4.界面精化。主要任务是基于概念设计和界面流设计，给出目标软件产品界面的完整的、详细的设计。

【第九章、软件详细设计】主要活动①用例设计；②子系统设计；③构件设计；④类设计；⑤ 数据模型设计；⑥设计整合与验证。

【第十章、软件实现】

程序设计语言的演化：第一代：汇编；第二代：Fortran/Cobol/Basic，有成熟的 函数库；第三代：结构化语言 C/Pascal/Ada；面向对象语言 C++/Java；专用领域语 言 Lisp/Prolog；第四代：数据库查询语言 Sql。

1. 第三代语言的特点：支持结构化程序设计，具有较强的过程能力和数据结构能力。

2. 第四代特点：更高的抽象层次；只需要告诉计算机“做什么”，而不必告知“怎么做” 。

编程的规则：1.节俭化（代码尽量简洁）；2.模块化；3.简单化（命名一致性，数 据结构尽量简单） 4.结构化（缩进统一/函数代替重复出现的代码/代码单入口单出口） 5.文档化（文档自说明）6.格式化

编程风格:1.节俭化 2.模块化 3.简单化 4.结构化 5.文档化 6.格式化. 编程风格在很大程度上影响着程序的可读性、可测试性、可维护性。 结构化要做到按标准化的次序说明数据，按字母顺序说明对象名，使用容易理解的结 构化程序部件，根据背景排列程序各部分

调试策略：1.原始法（单步执行，printf）2.回溯法（沿着代码控制流往回找）3. 排除法

【第十一章】（设计题）

数据流图DFD与数据字典、实体—关系图、面向数据流设计方法（事务流/变换流）

【第十三章、软件维护】

·维护的分类(按原因划分):1.纠错性维护。为诊断和改正软件系统中潜藏的缺陷而进行的活动.2.适应性维护.为适应软件运行环境变化(如操作系统变更等)而修改软件的活动.3.完善性维护.是根据用户在软件使用过程中提出的一些新需求而实施的维护活动.4.预防性维护。是优化软件系统结构和可理解性，改善可维护性和可靠性。

·可维护性：软件的可维护性是指理解.改正.调整和改进软件的难易程度。是软件质量的重要属性，是指导软件工程活动的一条基本原则，也是软件工程追求的一个目标。

·影响可维护性的因素：开发方法有关：设计、编码和测试不规范，软件配置不全开发环境有关：①训练有素的软件团队；②维护团队是否熟悉经过多次维护的系统；③ 软件的可理解性，包括软件结构、描述软件制品的语言、文档及标准化程度等；④操作系统的标准化程度；⑤维护工具和环境；⑥生成测试用例的能力；⑦对于嵌入式系 统维护应有专门的调试工具。

·维护的技术手段：软件重构。包括：文档重构、重组（简化与结构化源代码）、逆 向工程、再工程。

【第十五章、软件度量与估算】

·测量（Measure）是按照统一的规则为现实世界的实体属性定值。软件工程的测量 是按照测量标准直接、客观地采集软件制品、过程或资源的特征、属性，并获得数据。 例如：测量程序的代码行数、操作符的种类、个数，程序中缺陷的个数等等。测量涉 及测量对象、选用的量纲、方法、工具、过程和数据结果。

·软件估算（Estimation）是根据经验、历史资料或模型，结合项目实际对软件 制 品、过程、资源进行预测。估算一般用于签订合同、制定工作计划、进行项目预算等。 这里涉及软件过程工作量的估算。

·软件度量（Metrics）软件产品、软件开发过程或资源简单属性的定量描述，（如 程序规模、操作数个数、占用内存）能用以解释软件所具有的一个给定属性对软件质 量影响的程度。

软件度量：规模度量、复杂性度量（McCabe基于图论；Halstead基于操作符与操作数）、质量度量、可靠性度量

·内部属性与外部属性：软件工程的软件制品、过程、资源都具有外部属性和内部属性。外部属性体现了软件制品、过程、资源与环境的关系。内部属性指软件制品\过程和资源本身的技术属性。 二者关系:外部属性在软件开发过程中很难测量和控制，但它是由软件的内部属性决定的。

	软件制品	过程	资源
内 部	程序语言；代码风格；模块化;复用性;耦合度与内聚度	项目管理过程；业务建模过程；需求过程；设计过程；构造过程；测试过程；部署过程；配置管理过程；工具与环境支持过程	人;软硬件环境; 经验
外 部	软件系统的可靠性;健壮性；效率;可用性;可维护性;可移植性	资源保障；可控制性；可观察性；稳定性	成本；时 间；合作 机制

▲软件规模的度量 (计算题)

（一）代码行度量（直接度量，依赖于程序设计语言）

含义：通过项目总代码行数去度量项目的规模属性。（书本原话：用代码行数（LOC）表示软件项目的规模是自然和直观的。可以用人工或工具直接测量。几乎所有软件开发组织都保存软件项目的代码行数记录，开发初期可以度量软 件规模，度量生产 率、每行代码的平均人力成本、文档和代码的比例关系、每千行代 码存在的软件缺陷个数等）

优点：简单直观，容易操作。

缺点：1.依赖于特定程序设计语言；2.可能对一些设计精巧的软件项目不利；3. 项目开发前期估算困难；4.适用于过程式程序设计语言，对非过程程序设计语言不太 适用；

（二）基于功能点度量（间接度量，不依赖于语言）

含义：根据事务信息处理程序的基本功能定义的，采用 5 个测量参数，涉及多种因 素的间接度量方式。（因而可以估算出软件项目的规模）

优点：1.与程序设计语言无关，适用于过程式和非过程式程序设计语言；2.度量可以用于软件开发的初期（因为初期即能确定系统的输入/输出）

缺点：1.涉及主观因素较多，如加权值；2.信息领域数据有时不容易采集；3.FP(功能点)的值没有直观物理意义。 两者联系：抽象度越高的语言，同样的功能点对应的码会越少。

▲软件复杂性的度量

(一)控制结构复杂性: 圈复杂度/巡回秩数 V(G) = e-n+2

V(G)的值不要大于10,否则模块内部结构就会变得复杂,给编码和测试带来困难

(二)体系结构的复杂性 1. 简单形态度量:弧与节点数之和 S=a+n; 弧与节点数之比 R=a/n;

比值R体现了体系结构的连接密度,R越大,耦合度越高.

▲软件质量度量

软件质量的定义：软件制品满足规约和隐含需求特征及特征总和的程度。特征包括：功能性，可靠性，有效性，可使用性，可维护性，可移植性。·2011：增加了安全性 和兼容性的两个特征，扩展了子特征的概念。 软件特征的变化反映了软件与时俱进的特点，为软件质量度量和通过技术手段提高 软件制品质量指明了方向

McCall 三层次度量模型：质量要素指标（Factor）、评价准则（Criteria）、属 性度量(Metric)。Factor 包括：运行性、修正性、适应性。评价准则 21 个。

所有的质量度量模型（McCall、ISO）是层次性模型，不同在于分的哪些层次,每一 层有哪些方面。

【第十六章、软件项目管理与过程改进】

目的：软件项目管理的目的是使项目能够按照预定的成本、 进度、质量顺利完成。

一般经验估算模型：基于代码行的模型 E=a(KLOC)b+c；基于功能点的模型 E=a+b*FP，不同模型采用不同参数

▲软件项目度量与估算

（一）采用代码行/功能点度量的工作量估算

E=(a+4m+b)/6: 采用上述估算方法可估算出 LOC/FP 的乐观值 a，悲观值 b，一般值 m。（表格 16.5 的几列数据要会算）

一般经验估算模型：基于代码行用 E=a(KLOC)^b+c,abc 查表；E 是人月工作量；基于功能点用 E=a+bFP。ab 查表。

（二）COCOMO 模型（Constructive Cost Model,构造性成本模型）

COCOMO 模型分为基本、中间、详细三个层次。

通信开销=un(n-1)/2

基本 COCOMO 模型：用于系统开发初期，估算系统开发工作量和所需要的时间。 E=a(L)^b; D=c(E)^d;abcd 查表；E 是人月工作量；D 是开发时间.N=E/D 是建议参加项目的人数。

中间 COCOMO 模型：用于详细设计阶段，估算各个子系统的工作量和开发时间。 E=a(L)^b*EAF;L 是代码行估算值，单位 kloc；ab 查表。EAF 是工作量调节因子，EAF= （15 个 Fi 连乘）

详细 COCOMO 模型：用于估算独立的软构件，如子系统内部的各个模块，软件的集成和测试。

（三）COCOMO Ⅱ

E=a(L)^b*EAF+ER。ER 表示复用构件、代码自动生成需要的工作量，单位人月。

（四）Putnam 模型

时间推前或延迟 k%对工作量的影响？

L=C*E^(1/3)*t^(4/3).L是代码行数；E 是工作量，单位人年，包括维护；t 是开 发时间；C 表示软件开发环境的常数，查表。

E=L^3/(C^3*t^4)。比如提前 10%的时间（t=0.9t）,算出工作量 E=1.524E。说明 要增加 52%的工作量。

Putnam 模型虽然揭示了软件项目的工作量、软件开发时间和程序代码长度三者之间的关系，但它没有反映软件制品、软件项目、软件开发人员和计算机软硬件资源等 属性。因此用该模型进行软件项目的成本估算是十分粗糙的。

▲软件项目计划—-工程进度安排

两个重要的图：网络图（找关键路径，非关键路径的点可调控）；甘特图（网络图=>甘特图）

Gantt 图优点：简单易用，容易修改，比 PERT 图更加直观方便。

Gantt 图缺点：不能显示各项活动之间的依赖关系

▲软件配置管理 (版本,基线)

配置管理的目的：目的是为了减少混乱，提高软件生产率。是对软件修改进行标识、组织和控制的技术，用来协 调和控制整个系统的过程。

基线技术：标志软件开发过程的各个里程碑，通过复审的软件配置项 (SCI,Software Configuration Item, SCI是配置管理的基本单位)是构成基线的重要内容,它标志开发过程中一 个阶段的结束。

基线的使用：1.某 SCI 成 为基线，就会被存入项目数 据库；2.要想改动 SCI，就要复制到私有工作区并在 项目数据库中锁住。3.在私有工作区完成修改并通过复审后，新SCI释放并送回项目 数据库,并解锁。

·常用基线：1.系统工程–系统规约；2.需求分析—软件需求规约；3.软件设计—设 计规约;4.编码—源代码；5.测试—测试计划、过程、数据；6.集成—可运行系统。

常用工具：版本控制 git；DSEE

DSEE：历史管理、配置管理、任务管理、监控管理。

SCI:（1）系统规约；（2）软件项目规划；（3）需求分析结果；a.软件需求规约； b.可执行的或“纸样”原型；（ 4）初步用户手册；（5）设计规约；a.数据设计描 述；b.总体结构设计描述；c.模块设计描述；d.界面设计描述；e.对象描述；（6） 源代码清单；（7）测试规约；a.测试计划和过程；b.测试用例和实验结果；（8）操 作和安装手册；（9）可执行程序；a.每个模块的可执行代码；b.链接到一起的代码； （10）数据库描述；a.数据模型和文件结构；b.初始化映像；（11）联机用户手册； （12）维护文档； a.软件问题报告；b.维护申请；c.预计变更的顺序；（13）软件工程的标准和过程。

配置管理的任务：标识配置项；版本管理。

配置项的状态有三种：“草稿”（Draft）、“正式发布”（Released）和“正在修 改”(Changing)。变迁：配置项刚建立时其状态为“草稿”。配置项通过评审（或审 批)后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程” 执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时， 其状态又变为“正式发布”，如此循环.

▲软件过程改进

能力成熟度模型CMM:Capability Maturity Model for Software,软件成熟度模型。CMM 是一个概念模型,模型框架和表示是刚性的，不能随意改变。但模型的解释和实现有一定弹性。CMM 源于大型软件开发实践，反映了软件过程评估和软件过程改进的需要，是一个有效的大型软件开发、维护过程模型。 CMM 的应用进一步规范、指导软 件开发组织的自身建设，使软件开发组织从混乱的、低效的不成熟状态，向有纪律的、 高效的成熟状态转变。

常用词汇: 组织,项目,软件过程,组织的标准软件过程,定义项目的软件过程,组织的软件过程资产

关键过程域 KPA：描述软件的过程属性，通过完成一组相互关联的活动，实现建立 过程能力至关重要的一组目标。（软件开发组织的软件过程能力是组织能够承接软件 项目的重要依据）

CMM 的能力成熟度共分 5 级：L1 初始级；L2 可重复级；L3 已定义级；L4 已管理级； L5 优化级。从 2 级开始，每级包括若干个 KPA。 ·CMM 评估阶梯：L1 初始级；L2（软件项目计划+软件项目跟踪与监督）；L3（综合 软件管理）；L4（定量的过程管理）；L5（过程变更管理）。

什么是 CMMI？CMMI 是若干过程模型的综合和改进，是支持多个工程学科和领域的,系统的,一致的过程改进框架，能够适应现代工程的特点和需要，能够提高过程的质量和工作效率。

CMMI 等级：L0 不完全级；L1 已执行级；L2 已管理级；L3 已定义级；L4 定量管理 级；L5 优化级。