CMMI过程性能模型

CMMI过程性能模型（精选7篇）

CMMI过程性能模型 第1篇

关键词：软件质量管理,过程性能基线,过程性能模型

1 引言

随着软件产业的飞速发展, 软件的核心竞争力主要集中体现在质量、成本和交付工期上, 而质量是最显著影响其它两方面的因素。对软件企业来说, 质量不再只是争夺市场的一个有利因素, 而变成了公司在竞争中成功的必要条件。然而, 随着软件规模和复杂度的增加, 软件开发过程越来越难以控制, 导致开发过程中的产品质量和过程质量处于失控状态。

过去存在着一些片面的观点, 认为先进的工具和方法可以神奇地解决软件开发中的质量问题。目前的现实并不尽如人意。有的企业由于缺乏对开发过程的控制, 往往很难平衡客户和公司在质量、成本和交付工期的要求, 成功的项目比例很小。

面对如前所述的现状, 软件质量管理一定要面向预测式管理。一个软件产品的质量主要是由它的开发、采购和维护过程决定的, 为了改进软件产品的质量进而提高竞争力, 就要把焦点放在能够稳定地开发优质产品所需的过程上[1], 通过过程数据预测和控制结果。

过程性能模型重点强调过程和产品度量对结果的重要性, 分析和建立过程和产品度量与结果的关系。其通过过程性能基线控制过程的关键因子, 分析过程的性能偏差, 进而预测并控制最终结果。由此可以看出, 过程性能模型是解决上述问题的有效方法, 本文将关注基于过程性能模型的软件质量管理过程。

本文首先归纳了软件质量和软件质量管理的研究现状, 并指出了现有软件质量管理过程所存在的问题;随后引入了过程性能基线和过程性能模型, 提出了基于过程性能模型的软件质量管理过程模型, 阐述了过程性能基线和模型在质量计划、质量活动、质量度量和分析、质量预测和控制、质量评价和改进等五个质量管理子过程中的应用;最后在研究的基础上, 构建了软件质量管理系统的体系结构, 包括组织过程资产库, 过程支持和软件质量管理三个子系统。

2 软件质量及管理

当前业界已将交付软件的缺陷密度作为软件产品的质量的衡量关键标准。即, 已交付软件中每个单位规模的缺陷数, 简称为交付缺陷密度。因此, 软件质量管理通常围绕缺陷而展开, 软件项目的目标是使交付的软件存在尽可能少的缺陷[2]。

质量管理的任务是计划恰当的质量活动, 然后正确执行和控制这些活动, 以便可以在软件开发过程中 (即在软件交付以前) 检测到大多数缺陷[2]。

质量管理包括确定软件的质量目标, 制定实现这些目标的计划, 并监控和调整软件计划、软件工作产品、活动和质量目标, 以满足客户和最终用户对高质量产品的需求和愿望。

质量管理基于机构、客户和最终用户的需求建立软件产品的质量目标。为实现这些目标, 机构制定相应的策略和计划, 项目则为实现这些质量目标对其定义的软件过程进行具体调整[3]。

在软件质量管理过程和方法上, 传统的包括:全面质量管理 (Total Quality Management, TQM) 是一套能控制质量、提高质量的方法;在PMBOK[4]中, 软件项目的质量管理是指保证项目满足其目标要求所需要的过程, 包括质量计划、质量保证和质量控制三个过程域;著名的“Juran三部曲”[5]--TQM的理论基础和基本方法的主要基石--包含质量计划、质量控制和质量改进三个步骤, 突出了对过程改进的支持。最有成效的要属六西格玛质量管理方法, 其理念是通过排除和预防缺陷来提高客户满意度, 进而提高企业的收益率, 包括过程性能度量集、多种改进框架和分析工具, 尤以DMAIC框架 (定义-度量-分析-改进-控制) 最常用[6]。将六西格玛与CMMI实施相结合将是更有效的过程改进途径。

在软件质量管理工具方面, Ishikawa提出了质量控制的七种基本统计工具[7], 包括因果图[8]、Pareto图、直方图、控制图、散布图、运行图、检查单。目前也有许多有关预测模型的论著, 如:Rayleigh模型。

现有的软件质量管理过程和方法提供了质量管理的高层指导, 主要关注于实施步骤以及最终结果, 质量管理工具也着力于解决质量管理中的具体的某“点”的质量问题和控制, 但在如何通过过程控制其结果, 业界正在寻求有效的途径, 是亟待解决的问题。例如:如何制定低风险且切实可行的质量计划、如何在开发过程不同的影响因素下确保项目质量目标得以实现等。这些正是本文致力于研究的主题。

3 基于过程性能模型的软件质量管理过程

过程性能模型是解决通过过程控制其结果的有效方法, 具体定义如下。

过程性能基线 (Process Performance Baseline, PPB) 是对遵循过程所达到的实际结果的文档化刻画, 用于比较实际过程性能和预期过程性能的基准[9]。

过程性能模型 (Process Performance Model, PPM) 是对过程属性和过程工作产品之间关系的描述, 基于历史过程性能数据而建立, 并使用项目中收集的过程度量和产品度量进行校准, 最终用于预测遵循过程将能达到的结果[9]。

过程性能基线可用于组织内任何独立的项目, 通过分析所收集的度量, 建立结果的分布和极差, 其刻画了所选过程的预期性能[10]。过程性能模型基于其他过程和产品的度量来估算或者预测某一过程性能的度量, 刻画了过去的和当前的过程性能, 对过程将来的性能进行预测。过程性能基线控制子过程的能力;过程性能模型预测过程的中间目标和最终目标, 通过过程控制结果, 在子过程结束时进行调整和预测, 确保最终目标的实现。

基于六西格玛质量管理的方法及其DMAIC框架 (定义-度量-分析-改进-控制) , 以及过程管理的四个核心职责 (定义过程、度量过程、控制过程、改进过程) , 并结合过程性能基线和模型的原理, 本文提出了一种基于过程性能模型的软件质量管理过程模型, 该模型在质量管理过程中增加了过程性能基线和模型的指导、统计管理以及预测和控制, 提供了软件开发过程中进行质量控制和持续改进的框架, 如图1所示。模型主要包括:质量计划、质量活动、质量度量和分析、质量预测和控制、质量评价和改进。接下来将详细阐述过程性能基线和模型在上述五个质量管理子过程中的应用。

3.1 质量计划

要生产出高质量的产品, 首先必须制定质量计划。质量计划作为基于过程性能模型的软件质量管理过程模型的一个核心环节, 简言之, 就是怎样以及何时将质量活动和质量材料应用到一个项目中。质量计划中必须明确定义在软件开发的各个阶段应如何进行质量活动。制定质量计划的前提是项目已完成任务计划、进度计划和规模估算, 故在制定质量计划之前必须进行入口准则的验证。

基于过程性能模型的软件质量管理过程要充分发挥过程性能基线和模型在质量计划制定时的指导作用。团队软件过程 (Team Software Process, TSP) 质量计划是一个最佳范例, 本节将介绍如何使用过程性能基线和模型指导质量计划的制定。

3.1.1 TSP质量计划

团队软件过程 (TSP) 制定的质量计划包括以下几个方面[11]:系统无缺陷比率、各阶段排除缺陷密度、质检过失比、阶段收益、过程收益、缺陷引入率和缺陷排除率, 可划分为过程质量度量和产品质量度量两大类。

为了提高客户满意度, 首要解决的就是降低交付缺陷密度, 即验收测试过程中发现的缺陷密度。团队在制定质量计划时, 首先估算可能会引入的缺陷数, 其中估算每个过程阶段所引入的缺陷数的方法有许多种, TSP质量计划使用的是缺陷引入率;然后就是估算排除的缺陷数, 这里TSP质量计划使用了阶段收益。一旦团队按阶段估算了引入和排除的缺陷, 那么结合项目的规模估算与任务和进度计划, 就可以估算出每个阶段将会排除的缺陷密度, 然后检查所估算的交付缺陷密度是否满足项目的质量目标, 进而通过局部调整以完成质量计划。

3.1.2 使用过程性能基线和模型指导质量计划制定

在使用缺陷引入率和阶段收益估算缺陷的引入与排除时, 传统的做法是“拍脑袋”或者基于业界数据, 有经验的组织会基于历史数据, 但是实际实施表明:上述情况中绝大多数的估算都是徒劳的。原因如下:一是因为对阶段缺陷引入率和阶段收益的估计值没有准确地反映缺陷引入与排除过程的能力, 不应只是单个值, 而应该是一个区间, 包括均值和上下限;二是因为没有对缺陷引入与排除的过程进行计划, 尤其是某些关键度量, 例如评审速度、测试覆盖度、人员技能、经验等级、检查单条目数等, 从而无法通过缺陷引入与排除的过程控制过程的执行结果 (缺陷引入率和阶段收益) , 使得项目质量目标的实现变得不可预测和控制。

为解决上述问题, 这里使用过程性能基线和模型从四个环节提供支持:

(1) 建立项目的质量目标, 制定交付缺陷密度的计划值。

(2) 基于组织的历史数据, 建立阶段缺陷引入率和阶段收益的过程性能基线, 参照过程性能基线计划阶段缺陷引入率和阶段收益, 以“上限, 均值, 下限”的三元组形式。

(3) 基于组织的历史数据, 构建缺陷引入过程和缺陷排除过程内部的过程性能模型, 建立子过程结果 (也即中间目标) 与子过程因子 (包括可控的和不可控的) 之间的关系, 以及子过程可控因子的过程性能基线, 参考所建立的过程性能基线和模型制定子过程的质量计划。同时在质量预测和控制时, 需要对这些子过程进行统计管理。例如设计评审, 代码评审, 单元测试。

(4) 在分别计划好项目的质量目标、缺陷引入和排除过程的中间目标、缺陷引入和排除过程因子之后, 使用统计方法 (例如蒙特卡洛模拟) 对项目质量目标达成情况进行预测[12], 通过置信度与置信区间评估目标达成情况的风险, 必要时调整计划。

若软件组织处于起步阶段, 没有足够的历史数据, 质量计划的制定可参考TSP质量准则[13]。

3.2 质量活动

质量活动作为软件开发过程中的一项必要且非常重要的活动, 负责排除开发过程中所引入的缺陷。其作为软件质量管理过程中不可缺少的环节, 通常分为两大类:评审和测试。评审不但可以识别存在于可执行系统中的缺陷, 而且可用于文档。评审有许多种类型, 其中主要的类型有审查、走查和个人评审。审查和走查是同行评审[14]。测试则旨在发现尽可能多的缺陷。测试有七种类型, 分别是单元测试、集成测试、外部功能测试、回归测试、系统测试、验收测试以及安装测试[15]。常用的有单元测试、集成测试以及系统测试等项。

以TSP为例, 其任务计划中所涉及的质量活动按执行的先后顺序排列有需求审查、高层测试审查、详细设计评审、详细设计审查、代码评审、编译、代码审查、单元测试、集成测试、系统测试、验收测试。

项目的质量经理根据进度计划, 按期组织任务计划中所安排的质量活动, 基于既定的质量计划, 具体由质量保证人员按计划实施。

3.3 质量度量和分析

在质量活动实施的过程中, 软件质量保证人员应收集质量度量的实际数据, 包括基本度量和派生度量。以软件审查为例, 基本度量包括规模、评审准备时间、评审会时间、参与审查人数以及所发现的不同类型的缺陷数;派生度量包括总的审查时间、准备速度、审查速度、总的审查速度、缺陷密度、每小时发现缺陷数、评审准备时间与评审会时间之比、审查有效性。个体软件过程 (Personal Software Process, PSP) [14]提供了非常有价值的度量和分析。

与此同时, 质量人员可对收集的质量度量数据进行一些初步的探索性分析, 为进一步的质量预测和控制打下基础。数据分析的切入点可以为缺陷的引入、排除以及泄漏, 与评审有关的准备速度、评审速度、缺陷密度、审查有效性等, 以及与测试有关的测试用例密度、测试覆盖度、测试用例有效性等。数据分析的方法包括如下:

(1) 推测, 支持工具有Pareto图、运行图、直方图、箱线图、多变异图等;

(2) 提出原因的假设, 支持工具有因果图和关系图等;

(3) 证实或排除原因, 这主要是由能提供假设检验、方差分析和多元分析等方法的高级分析工具所支持。

3.4 质量预测和控制

为了有效地跟踪并控制质量活动的实施, 实现质量计划中对各质量活动所设定的预期目标, 进而确保项目质量目标的达成, 基于过程性能模型的软件质量管理过程模型所包含的另一个核心环节就是质量预测和控制, 主要涉及到统计管理子过程性能和预测项目质量目标达成两方面。具体而言就是使用过程性能基线和模型对质量计划中标注的关键子过程实施统计管理, 在每一个子过程结束时使用过程性能模型预测项目质量目标达成的置信度, 必要时对质量计划进行调整。

3.4.1 统计管理子过程性能

统计管理的过程[9] (Statistically Managed Process) 即使用基于统计的方法进行管理的过程, 其中, 对该过程进行了分析, 过程偏差的特殊原因得以识别, 过程性能也被控制在已定义的范围内。对子过程实施统计管理, 可以使子过程的性能得到很好的控制, 从而确保实现子过程的预期质量目标。适于统计管理的度量必须是可控的, 对子过程来说是关键的, 可以为人员属性、环境因子、技术因子、工具或硬件条件、过程因子、客户以及供应商等利益相关者, 例如人员经验等级、人员可用性、同行评审相关度量、测试覆盖度、编程语言等[16]。

根据对相关材料的研究, 本文归纳并提炼出了一个统计管理子过程性能的流程, 大体将统计管理子过程划分为过程稳定性评估和过程能力评估两部分, 如图2所示。

(1) 过程稳定性评估

过程稳定性评估[17]需要用到统计过程控制方法 (Statistical Process Control, SPC) 。SPC主要用来测量一个过程的稳定性并识别过程的各个执行情况是否超出所预期的变化范围和控制界限。控制图是实现统计过程控制强有力的工具, 常用的为Xm R图和U图。通常情况下, 适于统计管理的度量其取值都是服从正态分布的, 对于不服从正态分布的情况, 可以使用箱线图。

对于不稳定的过程 (子过程中出现了性能偏差) , 需要识别偏差的特殊原因, 集中分析并采取矫正措施排除特殊原因。检测不稳定性除了Western Electric提出的4种有效测试[17]外, 还可参考Minitab等统计软件中提供的其他测试规则。必要时可采用分组的方法。

(2) 过程能力评估

在子过程执行即将结束时, 需要分析子过程的能力, 进行过程能力评估。过程能力[17]评估的前提是过程是稳定的或统计受控的。有能力的过程首先是稳定的, 且其能力的上下限必须在规格界限之内。过程能力可以通过过程能力指数C p和Cpk来衡量, 使用控制图或直方图进行图形化展示。

过程能力指数Cp是我们描述过程能力的最重要指标, 但由于Cp的计算与过程输出的均值μ无关, 它是假定过程输出的均值与规格中值M重合时的过程能力。因此, Cp指数只是反映了过程的潜在能力。为此引入了过程能力指数Cpk, 其被称为实际过程能力指数[18]。

合理考虑Cp和Cpk两个指数, 对整个过程的状况就有了较为全面的了解。不应单独使用这两个之中的一个。

当C p和C p k都较小且二者差别不大时, 说明过程的主要问题是σ太大, 改进过程应首先着眼于降低过程的波动。

若Cp较大, 而Cpk很小, 二者差别较大, 说明过程的主要问题是μ偏离M太多, 改进过程应首先着眼于移动μ值, 使之更接近M。

如果Cp本身不够好, Cpk更小, 二者差别较大时, 说明过程的μ和σ都有问题, 通常改进过程应首先移动μ值, 使之更接近M, 然后设法降低过程的波动, 减小σ。

需要特别强调的是, Cp和Cpk是由处于统计受控状态下的过程波动的大小和均值偏离决定的。因此首先要判断过程是否处于统计受控状态。

3.4.2 预测项目质量目标达成

在每一个子过程结束时, 应使用子过程中间目标与项目质量目标之间的过程性能模型预测项目质量目标达成的置信度。当达到项目预期质量目标所面临的风险超出可以接受的范围时, 本文结合过程稳定性和过程能力评估的结果以及进度计划给出相关决策如表1所示:

3.5 质量评价和改进

项目到达结项阶段时, 软件质量管理也进入了最后一个环节:质量评价和改进。基于过程性能模型的软件质量管理过程中的质量评价和改进除了进行传统的质量总结报告之外, 还包括基于正交缺陷分类[19] (Orthogonal Defect Classification, ODC) 的Pareto缺陷类型分析、过程性能基线和过程性能模型的分析评价。

质量总结报告提供了项目质量目标达成情况, 质量活动的过程度量和结果度量实际数据, 以及缺陷的引入排除情况汇总等。

考虑到ODC的缺陷类型与特定的软件开发阶段相联系, 将Pareto缺陷类型分析与ODC结合起来, 有利于识别最普遍的缺陷类型。而且通过Pareto分析找出缺陷数最多的缺陷类型, 然后找出与该缺陷类型相关的开发阶段, 从而对该阶段采取相应的改进措施。

质量评价和改进环节最重要的一步就是要对整个质量管理过程中所使用的过程性能基线和过程性能模型进行分析和评价, 包括过程性能基线是否需要更新、过程性能模型的评价以及过程性能模型是否需要更新等。

3.5.1 过程性能基线更新决策

过程性能基线的建立过程是增量或迭代的, 在获得新项目的实际度量数据后, 要评估数据质量, 然后将数据纳入已有基线的分析, 确定是建立一个新基线还是使用已有基线。

判断将新的项目数据纳入已有过程性能基线是否合适的一个方法是:执行假设检验来判断新数据与已有基线是否存在显著的统计差异。如果存在显著的统计差异, 我们需要使用新的项目数据建立新基线;如果假设检验的结果表明没有显著差异, 则继续使用已有基线。

此外, 在综合考虑项目和项目组之间的内在区别及组织业务变更的基础上, 应定期评审组织过程性能基线集, 以确定是否需要建立新的基线, 或者是否需要合并、修订或放弃已有基线。组织过程性能基线需要合并、修订或放弃的情况如下:

(1) 当子过程改变时;

(2) 当组织的结果改变时 (例如, 由于过程偏移) ;

(3) 当组织的需要改变时。

3.5.2 过程性能模型评价与更新决策

基于过程性能模型的软件质量管理过程是否能真正奏效, 过程性能模型自身的好坏至关重要, 其是否能有效且准确地对目标进行预测和控制、其可理解程度及其可用性等都需要进行严格的评价。

通过对可靠性增长模型、质量管理模型等模型的评价标准进行调研[20], 本文归纳了四条过程性能模型的评价标准, 如下所示:

(1) 预测有效性。预测结果与实际结果偏差大不大, 直接关系到模型的好坏。

(2) 及时性。模型能够越早地发现问题或提高的征兆, 就有越多的时间提前进行计划。

(3) 开发过程的覆盖程度。开发过程的所有阶段的模型覆盖度是很重要的。每个开发阶段必须得到管理, 并且应当实施适当的措施。往往需要建立模型集。

(4) 简单性。数据采集简单并且代价不高;概念简单, 用户不需要很多的数学基础就能理解。

过程性能模型的更新包括对模型的校准 (Calibration) 和修订 (Revision) 。

量化管理项目时, 从统计管理选择的子过程中获取关键属性度量, 通过使用所获得的这些实际性能数据, 校准有关过程的过程性能模型, 判断项目是否能够实现其目标, 包括中期和最终目标 (此时这些目标在项目生命周期的后面阶段才可以度量) 。

需要修订过程性能模型的情况总结如下:

(1) 当子过程改变时;

(2) 当组织的结果改变时;

(3) 当组织的需要改变时。

4 质量管理系统体系结构

在对基于过程性能模型的软件质量管理过程的研究的基础上, 研发了质量管理系统, 其体系结构如图3所示。该系统建立了组织过程资产库, 并提供两大功能:过程支持和软件质量管理。

4.1 组织过程资产库

一个组织应该拥有自己的过程资产库, 包括组织的标准过程集、度量库、过程性能基线库以及过程性能模型库, 分别为过程、度量、PPB和PPM建立了相应的数据字典。其中, 标准过程集支持过程定义和裁剪, 度量库包括过程度量和产品度量, 过程性能基线库以“上限、均值、下限”的方式存储, 过程性能模型库中涵盖基本的统计预测模型和高级预测模型。

4.2 过程支持

过程支持提供了从软件度量到过程性能基线直至过程性能模型的建立与维护功能。随着度量数据的不断积累, 过程性能基线的控制限在建立的过程中需要不断地修订。开发过程性能模型也是一个迭代的过程, 不断的选择一个或多个适当的统计建模方法, 并用过去的性能数据对模型进行评估, 直到得到适当的模型预测值。

过程性能基线建立的统计方法为控制图理论, 支持过程性能模型建立的统计方法包括回归、方差分析、虚拟变量回归、卡方检验、逻辑斯蒂回归, 以及蒙特卡洛模拟, 贝叶斯信念网络 (Bayesian Belief Networks, BBN) 。

4.3 软件质量管理

(1) 质量计划模块支持入口准则验证、质量计划概要、项目质量目标的建立、各阶段质量活动其质量目标的建立、各阶段质量活动的属性及其度量的详细计划、项目质量目标达成情况预测及结果报告。

(2) 质量活动模块支持评审过程、测试过程的实施。前者包括评审计划、评审会、缺陷修复、评审总结, 后者包含测试用例管理、测试报告、缺陷管理。

(3) 质量度量和分析模块负责从过程中进行质量度量数据 (特别是缺陷数据) 的收集、分析、评价并生成质量状态报告, 质量数据分析包括按阶段和项目划分的缺陷引入和排除情况分析等。

(4) 质量预测和控制支持统计管理子过程性能和目标达成情况预测, 为质量活动反馈偏差原因和建议的矫正措施, 必要时提供质量计划调整的相关决策。

(5) 质量评价和改进模块基于项目质量目标实际达成情况和软件开发过程中的质量数据, 生成质量总结报告, 并支持基于ODC的Pareto缺陷类型分析, 重点提供过程性能基线和过程性能模型更新的决策和相关评价。

5 结语

CMMI差距分析过程与实施 第2篇

差距分析是CMMI实施准备阶段的一项主要工作。关于差距分析的意义, 可引用CMMI奠基人瓦茨汉弗莱 (Watts Humphrey) 的一句话:如果你不清楚自己在什么位置, 那么就算有地图也帮不了你。差距分析的主要意义包括: (1) 验证组织现有的体系文件, 识别差距, 依据标准评审体系文件的符合性, 按照CMMI模型识别组织软件过程的强项、弱项; (2) 依据识别的差距进行过程体系定义, 建立和完善体系文件框架及组织职能; (3) 为制定过程改进行动计划提供依据。

2 差距分析的内容

差距分析以CMMI模型为依据, 综合检查、评估组织现有体系文件及其实施情况, 发现其中的差距, 其主要内容 (如图1) 包括:

(1) 文件评审。文件评审包括组织和项目文档, 如组织方针、过程、指南和以前其他项目实施记录, 步骤分别是: (1) 按照模型/标准验证组织文档; (2) 按照模型/标准验证项目文档。

(2) 识别组织的强项和弱项。一个有效的改变过程需要对当前状态的理解, 通过实施状态评审, 访谈组织不同职能角色的人员, 包括高级管理者、项目经理、工程过程组、质量保证组、开发人员、测试人员、培训组、采购组、配置管理组等, 以了解组织目前的项目实施情况及差距, 并识别和报告组织过程的强项和弱项。

(3) 制定过程改进行动计划。根据差距分析的结果, 制定过程改进行动计划, 包括体系文件完善计划、项目实施计划和内部评审计划等。在整个计划编写和实施中, 推荐运用IDEAL模型方法。

3 文件评审

3.1 文件评审的目的

差距分析时的文件评审, 是在CMMI模型建立实施之前进行的, 因此只能基于组织当前的过程体系所建立的文件体系来进行评审。一般地, 组织在建立和实施CMMI前均已建立了一套软件过程规范。但是根据我们多年的咨询、评估经验, 此时组织所拥有的软件过程规范普遍存在两个问题:

(1) 软件过程不够完整系统。参考CMMI模型的要求, 一部分过程是缺乏的, 比如, 缺乏项目级和组织级的数据收集、存储、分析、报告规程, 还有一部分过程是不完善的, 如配置管理规程中制定了版本控制规范, 但缺少对配置项变更控制流程的规定。

(2) 项目实施与公司现有体系文件的规程要求偏离较大。也就是俗称的“两张皮”现象, 要么是认为软件开发无章可循, 不制定或较少制定过程规范导致无序开发的过程能力低下, 要么就是组织制定了很多过程规范, 但很少能合适地指导软件开发过程, 导致过程规范变为僵化的教条而不被认可或者执行流于形式。

因此, 差距分析时的文件评审的目的, 就是结合组织现有环境情况, 依据CMMI模型要求, 评审组织现有相关管理体系文件 (包括记录) 针对评估准则的适宜性和充分性。

3.2 文件评审的活动

文件评审的活动可分为两个步骤: (1) 按照模型/标准验证组织体系文档; (2) 按照模型/标准验证项目实施文档。

在差距分析阶段的文件评审期间, 可考虑按文件的分层体系来开展评审活动:组织级体系文件与项目级实施文件。

(1) 组织级体系文件的评审。组织的体系文件结构主要由以下几个部分组成:质量手册 (方针、目标) , 过程/规程, 规范/指南/模板/记录表格/工具。

在进行组织级体系文件的评审过程中, 结合组织的产品服务的实际情况, 通过对组织级体系文件的评审, 可以了解组织过程体系活动/过程的相互作用与描述是否清晰、充分, 同时为差距分析的评估人员提供了对组织过程环境的认识, 有利于评估组进一步明确后续访谈活动中需要提出什么样有针对性的问题。

(2) 项目级实施文档的评审。对项目级实施文档的评审会贯穿整个差距分析的过程。在差距分析中一般会要求被评审方找出2-3个有代表性的项目实施记录来进行分析。因为项目级实施文档会比较多, 在有限时间内不可能进行全面评审, 那么在评审项目级实施文档时就要注意如下策略: (1) 以过程为主线, 关注项目级实施文档与组织级体系文件、访谈所收集到的信息的关联性; (2) 关注项目级实施文档与CMMI模型实践的对应关系; (3) 关注组织业务目标, 同时综合考虑组织资源能力、管理基础和发展阶段情况, 有重点地收集项目实施证据。一般情况下, 可重点关注的过程有:配置管理、项目策划、项目监控、项目交付验收、测试管理、需求开发、需求管理等。

文件评审活动完成后, 应根据对收集证据的分析形成组织体系文件分析报告。

4 识别组织的强项和弱项

4.1 评估策划

差距分析小组进行差距分析计划的制定, 差距分析的策划主要考虑以下方面内容: (1) 差距分析的目的; (2) 差距分析的范围; (3) 差距分析的进度、资源; (4) 制定差距分析的检查表; (5) 制定差距分析计划。

4.2 识别组织的强项和弱项

(1) 组织强项、弱项的定义。强项:反映软件集成成熟度模型中某个模型实践得到显著示范性实施。

弱项:反映软件集成成熟度模型中一个或多个模型实践无效或未执行。

(2) 识别组织的强项和弱项。评估小组分析通过了解组织体系文件、实施文档以及现场访谈的信息证据, 进行各个过程域的文档化的强项和弱项陈述, 识别组织的强项和弱项, 并编制差距分析报告与组织管理层及EPG人员沟通评估发现, 最后报告评估结果。

4.3 建立组织过程定义框架

在完成各个过程域的文档化的强项和弱项陈述, 识别组织的强项和弱项, 在形成差距分析报告的同时, 可编制《CMMI过程改进体系文件完善计划》。

5 制定过程改进计划

通过以上的差距分析过程, 参与评估诊断的双方基本明确组织在什么样的位置, 同时可以开始着手确定要到哪里去 (过程改进的目标和路线图) , 并且将过程改进作为一个正式的项目进行运作。评估组和组织EPG根据差距分析识别的结果组织策划过程改进活动, 以一个CMMI3的过程改进项目为例, 策划并形成以下《过程改进计划案例》。

6 过程改进计划案例

6.1 CMMI3项目概述

(1) 项目介绍。 (1) 项目名称:×××公司SPI项目; (2) 项目目的; (3) 项目背景。

(2) 范围。 (1) CMMI模型范围:实施CMMI3级的18个KPA; (2) 应用范围:×××公司所有软件工程项目。

6.2 SPI (过程改进) 项目过程定义

(1) 生命周期模型:采用迭代的IDEAL过程改进模型, 如下图所示。第1轮→第2轮→第3轮→.每一轮都遵循一个IDEAL模型; (2) SPI (过程改进) 组织结构; (3) 角色与职责; (4) SPI (过程改进) 任务进度 (过程改进的具体行动计划, 包括:改进的活动/步骤、活动责任人、进度安排、是否里程碑点等) ; (5) SPI (过程改进项目沟通; (6) SPI (过程改进) 培训计划。

摘要：差距分析过程是CMMI实施准备阶段的一项主要工作。通过采用快速诊断方法的差距分析, 对组织的软件过程进行综合评估, 了解组织现有软件过程的状况, 为识别过程改进机会提供帮助。根据实践积累, 对CMMI差距分析的过程和实施的经验进行了分析总结。

关键词：CMMI,差距分析,软件过程改进

参考文献

[1]北京SPIN.软件过程改进实践[M].北京:电子工业出版社, 2004.

CMMI和敏捷开发过程的分析研究 第3篇

1 CMMI和敏捷开发简述

CMMI和敏捷开发是两种完全不同的软件开发模式, 它们的概念不同, 管理方法和技巧不同, 开发流程不同, 开发过程不同, 管理特点不同, 它们之间有着本质的区别。敏捷与CMMI都非常注重质量, 差别在于CMMI开发模式是一种重量形式的开发, 敏捷是一种轻量模式的开发。CMMI强调的是以数学统计为基础的技术方式, 而敏捷强调的更多的是具体的、使用的工程技术方式。另外敏捷与CMMI有着共同的目标, 即用最短的时间, 投入最少的资金, 开发出满足客户需求的最好的软件;同时他们都是目前应用比较广泛软件开发模式, 均具有最佳的实践经验。CMMI软件开发管理模式的有很强的包容性, 它强调重量级的项目过程管理控制, 而敏捷是轻量级开发, 强调具体、实用开发技术。相比较而言他们在各自的开发领域都有比较好的积极作用的发挥, 但是敏捷开发中轻量级的管理过程开发效率相对比较高。敏捷开发与CMMI都注重团队与组织, 只是敏捷开发更加注重人的主观能动性。

2 敏捷与CMMI项目管理比较

敏捷开发项目管理更注重软件开发实施的模式, 强调团队中个人的能力的发挥。它对软件开发中技术和控制管理不是太看重。从这方面来看它与CMMI项目管理过程有着较大的区别。CMMI软件开发过程管理模式是根据预先制定的计划, 按照计划中的每一个步骤进行的管理与开发。如果在开发的过程中项目发生变更, 需要重新对项目进行估计, 重新作出项目计划, 所以此管理模式容易受客户需求变更的影响, 效率比较低。CMMI项目管理过程对客户和供应商的可视性不高。在开发过程中计划驱动方法、软件交付实践少, 风险控制滞后。

敏捷开发的项目管理过程是一个不断变化的过程, 它使用迭代、增量的步骤进行开发管理。敏捷开发的方式实现没有对项目进行仔细的分析, 项目研发初期他们不注重对项目的了解, 而是在开发的过程中对项目进行慢慢的了解的过程, 敏捷只为项目中的一个迭代做开发规划, 不会针对整个项目做整体规划, 所以它的具有较高的灵活性, 能够在客户变更需求时, 第一时间做出反应。另外, 它对整个项目一个比较粗略的规划, 然后对每一次迭代做详细的规划, 根据迭代规划做研发工作。相互信任和给予权力是敏捷开发的主要管理方式。这种管理模式使合同变更变得简单, 客户和开发人合作关系, 关系密切, 每次迭代的完成, 都有可交付的软件生成, 能够利用第一代迭代软件识别软件早期风险, 从而及时更正。

敏捷来发不仅能及时、有效的解决软件研发中存在的问题, 减少软件开发风险, 而且能够在最短的实践内完成项目的交付, 提高研发效率。因为它每次迭代都可以产生可以运行的软件, 所以能够实现快捷交付。开发的过程中国根据项目风险级别, 采取最优先行开发的原则进行开发。增强项目的变更管理, 减少大量的重型计划工作, 简化繁琐的管理过程, 提高研发的效率。有效的改善项目的沟通, 使客户能够有效的参与到研发中, 减少项目管理中错误的假设。敏捷开发能够最大限度的额提高研发效率, 减少工作中不必要的文档和工作量, 提高客户满意度, 达到短期内生产生效, 完成交付的任务。还能有效的改善员工的满意度, 增强团队精神, 使每位员工都能够规划和管理自己的工作, 提高员工工作的积极性, 使项目更加适应市场变化。

CMMI和敏捷开发各有优势, 只是侧重带你不同, 前者侧重管理过程的规划和质量控制的技术, 后者侧重具体、使用的软件按工程技术, 它们在各自的应用范围内都是最佳的管理模式。在未来的发展中, CMMI和敏捷开发可能会走向融合, 敏捷可以帮助CMMI高级别更容易实现短期的转变。从另外一方面看敏捷开发是使用CMMI第4, 5级别来改进如何发展产品的完美例子, 二者具有很强的互补性。

3 结语

总之, 软件的开发并不是只有一个或者两个模式, 软件企业可以选用一个比较适合自身且发展的而研发模式实施管理, 也可以多个结合运用。CMMI与敏捷开发虽然有很多的不同, 但是也不是两个完全对立的管理模式, 他们有着共同的研发目标, 致力于软件研发的高质量、高效率以及高效益, 同样追求客户的满意度。所以, 在一定的环境下, 二者完全可以相互补充、共同促进, 共同达到市场需求标准, 推动软件研发的发展。

参考文献

[1]徐俊, 彭章纲.敏捷开发过程与CMMI实施融合研究[J].现代计算机 (下半月版) , 2011 (24) :122-123.

[2]王易, 童杰, 宋鹏飞.基于CMM/CMMI和敏捷软件过程改进的研究[J].科技资讯, 2009 (14) :196-197.

[3]杨根兴.软件过程的改进与敏捷方法[J].软件产业与工程, 2010 (6) :287-288.

CMMI过程性能模型 第4篇

在计算机软件工程方面,质量常常被视为系统内部部件或系统过程中满足的以下两个要求:(1)明确的需求。(2)客户或用户对系统的需要或期望的程度。更为重要的是,软件产品的质量往往是软件工程的核心所在[1]。可是,目前在软件工程中还没有形成完整且统一的软件质量的概念,而目前比较权威的观点则认为质量满足有以下四种条件:首先,软件质量需要集合计算机系统稳定和卓越程度的所有属性;其次,软件质量需要集合软件产品中满足明确需求程度的属性;第三,软件质量需要集合软件产品的明确或隐含的需求能力的特性或者特征;最后,软件质量需要满足在质量定义中客户明确指出的需求[2]。

综上所述,软件质量需满足以下三个特性:(1)软件需求成为度量软件质量的基础。(2)软件质量是一种难以定量度量的属性。(3)软件质量需要同时保证客户的明确需求和隐含需求。

2 软件的质量管理(Software quality management)

而软件的质量管理则包括执行确定的质量政策、目标与职责过程相关的活动,进而使待完成的项目满足一开始制定的需求。随着各行各业中信息技术越来越广泛的使用,软件质量受到了越来越多的关注和重视。因此,软件质量的好坏与否已经越来越成为公司能否生存的核心竞争力之一。而这种决定企业生存的竞争力除了体现在多样的产品类型和先进的产品功能上外,更多的竞争力则体现在产品是否具有可靠且稳定的质量保证上。随着目前信息科技在社会日常需求上的发展,软件被应用的领域在进一步被细化。随之而来的则是进一步复杂的设计程度,以及不断被要求缩短的软件研发周期。只有软件具有的质量和服务在制定之处就以利润最大化和质量最优化为市场导向,才能将软件具有的市场价值最大化[3]。

而目前有很多能够影响软件质量的因素。首先影响软件质量的管理学因素主要有软件执行的正确性,软件的健壮性,软件运行的效率,软件的安全性和可用性,软件运行的风险,软件执行的可理解性,软件本身的可维护性和适应性,以及软件的可移植性和可再用性等因素。而软件的复杂性这个属性则决定了必须由相应固定的标准来保证软件质量,从而形成了完整统一的软件质量保证体系。

3 软件的质量保证(Software quality assurance)

软件质量保证(Software Quality Assurance,SQA)也往往具有不同的定义。目前比较权威的定义是:软件质量保证是软件质量评估和度量的一个功能单位,其包括过程和产品的保证。它的基本任务是确保软件项目履行的过程中对产品和过程的承诺。在整个软件的开发过程中,软件质量保证应该一直贯穿其中,且在该过程中软件不会被耗损,这是与硬件系统最大的不同。因此,在软件交付使用之后,该软件的可用性不会随着时间的流逝而改变,具有相当的稳定性[4]。

针对软件质量保证的软件质量管理体系是标准化组织经过长期的研究和实践逐步演化和制定的一整套适用于软件管理的理论体系。它的目的是对质量管理过程进行规范,使得软件质量管理有据可依。目前在国际社会中有两种被广泛采用的软件质量管理体系分别是ISO9000和CMM/CMMI。前者是集合了国际标准化组织的现代管理学理念的精华部分,并合并了ISO9001、ISO9002和ISO9003三种标准,进一步将PDCA戴明环闭环管理模式引入其中,同时把持续改进的思想引进并贯穿于整个软件质量管理标准,从而建立一种可持续改进的结构。后者ISO9001:2000则为各种机构和组织提供了软件质量管理的另一种切实可行的方案,并以体系化模式来管理软件组织的质量,该体系把“以顾客为中心”和“持续改进”的理念彻底贯彻到标准中,以拥有持续满意的顾客为目的,从而使软件质量和软件服务更好地满足顾客的期望值。

4 基于CMMI的软件质量保证(On software qualityassurance of CMMI)

软件能力成熟度模型集成(Capability Maturity Model Integration,CMMI)是软件能力成熟度模型(Capability Maturity Model for Software,CMM)模型的最新版本。CMMI可以描述组织软件过程的能力,其核心是将软件开发过程花,并对软件开发和维护进行监控和研究,使其满足标准化,科学化的要求,帮助企业实现更好的商业目的。在实际的执行过程中CMMI将能力成熟度划分为五个等级,分别是:初始级、已管理级、已定义级、量化管理级和优化级。这个五个等级中的每一个级别都将构成下一个级别的基础。CMMI被公认为是软件产品进入国际市场的通行证,它为改进软件组织的过程提供了一种单一的集成化框架,消除了模型之间的差异性,减少了各类模型的重复劳动,增加了软件的透明度和理解,从而建立了一个自动的并可扩展的框架,并从总体上改进软件组织的质量和运行效率。因此,有效实施地CMMI可以有效地提升软件开发项目的成功率,进一步降低软件开发风险和成本,并提高产品的质量,使得企业的竞争力在根本上得到提升。在目前看来,有两点原因促使企业实施CMMI,其一是为适应市场需求,特别是提升企业在投标活动中通过CMMI门槛的概率;第二个方面出于有效管理的目的,通过CMMI的顺利实施来对组织内部的管理进行改进,从而有效提升组织的工作效率。迄今为止,CMMI主要被应用在软件能力评估和持续过程改进这两大方面。

在实际的操作过程中,开发人员的素质和团队管理能力则往往更多地决定了软件质量,而在大型软件开发的项目中,主要体团队的总体能力又体现在软件开发人员的能力上。而软件开发过程中的控制力和自我改善能力又决定了软件的成熟度,其对软件的实际开发质量起到了至关重要的作用。因此,只有不断的加强软件开发成员团队素质的管理,才能更好地建立有效且稳定的软件开发过程,进而达到对软件开发质量的控制,以更好地保证软件的开发质量。

以上的描述主要从理论上阐述了基于CMMI的软件质量保证的概念与理论,为了更好地诠释基于CMMI的软件质量保证,本文将进一步从工程实际出发描述软件质量保证的实际操作。

5 基于CMMI的软件质量保证的实际工程操作(Thepractice of software quality assurance of CMMI)

在软件开发项目立项后,需要首先任命一名该项目的测试负责人。该测试负责人需要具体负责项目测试的相关文档,测试进度,测试质量,测试过程的管控。进而在软件测试开始前,团队的开发人员需要首先熟悉产品需求规格说明书,产品开发计划和产品详细设计等准备工作。

在熟悉产品需求规格书方面,测试人员应该参与产品需求规格说明书的审核,产品需求规格说明书完成后,需求人员应以邮件方式及时发送给测试人员,避免在产品开发完成提交测试时才告知测试人员。当开发过程和测试过程中发现需求定义有问题的,开发人员和测试人员都只能向需求人员提出问题,当需求出现疑义时,必须由需求人员与客户沟通确认,并更新需求规格说明书。在产品开发计划方面,在确定开发人员提交测试版本的时间时需要开发负责人签字确认,开发人员在提交测试版本同时给出测试说明,测试说明包括本测试版本已知重要问题,未完成功能(如果存在),测试建议等。在产品详细设计方面,对于软件项目的需求,开发人员提交测试版本时同时提交该需求的产品详细设计,内容包含开发人员为实现需求,所做的改动,新增的功能,删除的功能等说明。同时其他项目的产品详细设计内容,见软件开发流程中产品详细设计的相关说明。在整个准备过程中,开发人员、测试人员和需求分析人员需要保持充分积极的沟通,以保证所设计出的软件能够体现客户的真正需要。

在软件的设计过程中,需要详尽地将整个软件设计过程分成若干可执行的阶段,确定好每阶段的时间节点和完成需求,保证每一个阶段的充分可执行性。在完成软件设计后,测试团队需要根据最初的设计制定完备的测试需求并搭建测试平台,编写测试计划,完成测试用例审核和测试人员评估,最后在测试的完成阶段做好详尽的测试报告以备客户查询。

总之,软件的设计与测试的实际操作是一个严丝合缝并环环相扣的过程。

6 结论(Conclusion)

基于CMMI的软件测试是一个庞大且详细的框架体系,其对软件质量的保证和企业市场的扩大有着非常重要的促进作用。而基于CMMI的软件测试需要整个设计和测试团队的密切配合和积极沟通,其实际操作具有相当大的探讨空间。

摘要：软件质量保证是当今软件行业一个值得关注的重要问题。软件的质量则直接关系到用户的生命和财产安全。而在实际的工程应用中,软件质量的优劣与软件工程过程的合理与否有着密切的关系。本文从理论和实践两个角度详细阐述了基于CMMI的软件质量保证过程,从而实现了基于CMMI的软件质量保证的定量和全面的质量管理。

CMMI过程性能模型 第5篇

软件过程管理是指在软件开发过程中除了先进技术和开发方法外，还有一整套的管理方法。它侧重的是软件组织在软件开发的过程中对需求管理、计划安排、合同管理、项目跟踪、资源分配和质量要求等的管理方式，也就是对软件开发、维护全过程规范化、透明化、标准化的管理。目前，普遍采用的软件过程管理方法是由SEI提出的CM-MI(Capability Maturity Model Integration)，即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进。该模型提供了一种渐进式的软件过程改进途径，体现了软件工程和软件管理的最佳实践，为软件开发单位提供了逐步达到成熟的规范化过程的框架。CMMI分为5个等级，共22个过程区域(PA)，每个等级都被分解为过程域，特定目标和特定实践，通用目标、通用实践和共同特性;每个等级都由几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特定目标和通用目标，通过相应的特定实践和通用实践来实现这些目标。当一个过程域的所有特定实践和通用实践都按要求得到实施，就能实现该过程域的目标。

2 有效实施软件过程管理的策略

在CMMI模型中，主要以过程域(PA)为主题，阐述了对各PA的要求，描述了PA要达到的目标以及为实现目标而必须实践的过程;模型还描述了实践后要达到的效果，但并没有描述应该如何去做，尽管模型中也给出了少量的实例说明。然而，照搬照抄CMMI模型并不能帮助企业达到期望的成熟度，必须将CMMI模型转换成与公司业务目标相适应的体系规范。因此，本文从以下7个方面确定了实施CMMI模型的策略：

2.1 明确软件公司的发展愿景

在知识经济时代，企业发展更加依赖于技术进步和技术创新，谁抢占了技术的制高点，谁就抢占了市场的制高点。要以市场武装技术，以技术占领市场，走上市场和技术交替推动的持续发展之路。另外，还要建立可量化的业务目标并分阶段具体实施。有了愿景以及近期可以实施的业务目标，就可以对实施CMMI进行规划。通过实施CMMI模型对公司内部软件开发过程进行管理。

2.2 建立实施CMMI的组织机构

为了真正落实和加强软件开发过程的控制与管理，需要建立起软件开发质量保证的组织机构，明确与软件开发相关联的各级人员(小组/部门)的职责、权限和沟通方式，确保软件过程管理的有效性。这样才能使CMMI工作持续地开展下去，达到不断提高产品质量的目的(如图1)。

在整个组织框架内，实施负责人确立一个长期的过程改进目标，并带领大家为此目标而努力，是过程改进的动力和鼓动者。SEPG(软件过程改进小组)是过程改进的核心，承担整个过程改进的组织、策划和实施推广工作，他们通常是由公司内部各方面的资深专家组成。项目人员通常来自各职能部门，因此要处理好SEPG、项目和部门之间的关系。在这个团队中，职能部门经理的地位非常重要。图2给出了每个项目组的构成。

项目经理负责管理组内所有工作，以及与其他组之间的协调;变更控制委员会(CCB)的目的是确保每个基线变更都经过所有相关方的考虑，每个变更在实施前都经过批准。CCB是对每个变更进行评审，做出批准、不批准或推迟实施以获得更多信息的一个实体。它至少要包括从事开发、文档编写、测试、保证、维护和发布等方面工作的的人员。

2.3 确定软件项目开发过程

软件开发中心从业务部门收到软件需求计划之后，任命一名项目经理负责。项目经理根据软件需求计划，撰写软件开发计划书草稿，软件开发计划书定义了软件开发团队职责范围、人员数量和结构需求、阶段性里程碑的设置和产出、风险的识别和规避办法、人员的培训计划、软件开发过程的定义等。软件开发计划书完成后，召开软件项目开发启动会议，邀请人力资源部、培训部、过程改进组。在会上，项目经理根据软件开发计划向人力资源部代表提出各阶段的人力资源计划需求，向培训部提出相关培训需求，同时与过程改进组讨论、裁剪软件开发过程。

软件启动会议召开后，项目经理根据相关与会部门代表商议的结果修改软件开发计划书并形成正式版本。同时，配置管理员对该文档形成基线并收进配置管理库。之后，软件项目将按照软件开发计划书进行。每月末，质量监察员将依据项目软件开发计划书对项目进展和质量进行评审并责令项目经理限时整改。

每周五，项目经理通过周报形式向业务部门代表和开发中心高级经理汇报项目的进展情况。周报的内容包括：本周完成工作的情况、遇到的问题和是否解决、下周计划完成的工作和预计可能遇到的问题。周报作为正式的沟通渠道让相关领导和部门实时监控项目的进展和风险。

当项目完成并获得业务部门的认可之后，项目经理将根据软件开发计划书召集项目团队成员、人力资源部代表、过程改进组代表召开项目总结大会。在会上，项目经理和团队成员就该项目遇到的困难和解决方法进行总结分析，并形成项目总结报告。该报告由软件过程改进组收入软件开发经验共享库以供所有开发人员分享经验。同时，会议召开后，项目组将解散，所有成员将归还人力资源部重新分配。

2.4 制定软件过程管理体系规范，确保过程可以固化

按照CMMI的软件过程改进标准制定管理策略和技术文档，制定适合软件开发的过程管理体系规范，是CMMI实施中一项非常重要的工作，它将软件开发所运用的方法和流程加以固化，并同时进行改进，以达到相应的CMMI能力成熟度级别要求。统一适用的管理体系规范使各项目组执行的方法和流程进一步规范。

软件文档分为过程管理文档和工作产品文档两大类。过程管理类文档描述了每个过程的目的、开展的活动、遵循的步骤和规则、人员的职责和应当输出的工作产品等;工作产品类文档给出了每个过程输出的工作产品的内容和形式模板。表1给出了几个关键过程域的过程管理文档和工作产品文档。

2.5 选择项目试点，确保体系规范的适应性

选择需求规范覆盖至少为公司主营业务的一部分项目，将制定好的过程文档和模板，在试点项目中进行试运行，消除不符合要求的地方，对过程进一步改进。面向项目组进行培训，根据项目组整体的过程成熟度有针对性地开展，就过程中存在的问题开展辅导，此阶段的培训和辅导主要是由质量经理担任。在实施过程中，首先重点关注成熟度较低的PA实施，并制定切实可行的办法进行整改;其次要关注每一个PA的难点实施，要做到各个击破，将实施工作做到位。对实施过程中遇到的问题要及时加以解决，问题长期得不到解决会对项目组的实施热情造成伤害。还要定期开展评估工作，了解目前的进展以及存在的差距，树立过程改进的信心。

2.6 适时认证和推广，树立过程改进信心

在初步达到相应的成熟度级别后，就可以开展相关的CMMI认证工作，具体可与一些有资质的公司联系。与此同时还要对过程管理体系规范进行推广，制订切实可行的推广计划，使项目组对投入到管理、文档上的工作量要有预估，在时间效率上达到平衡。在实施过程中，各部门在观念、利益上存在冲突，会给实施工作带来较大的阻力，因此需要有力的领导来总控，确保CMMI实施工作顺利进行。最后还要加强对问题的跟踪力度，对推广过程中出现的问题要加以分析并快速解决。

2.7 不断深化，使过程改进工作持续推进

当过程管理体系规范在公司得到全面推广后，并不代表过程改进工作结束了，只是表明企业目前已取得了阶段性成果，还需要不断深化，总结经验。要将过程改进工作持续推进，还要做好以下工作：一是建立收集过程改进意见通道;二是对过程管理体系规范进行定期修订，确保对项目有较强的适应性;三是用工具完成对开发流程的支撑;最后要大力推进质量文化建设，使过程改进工作深入人心，落到实处。

软件过程管理体系制定出来后，一定要先全员培训，经试点后再推广。

3 结语

CMMI过程性能模型 第6篇

1 CMMI概述

CMMI ( Capability Maturity Model Integration) 即能力成熟度模型集成。是继CMM发布以后,美国卡内基—梅隆大学软件工程研究所于2000 年8 月11 日发布的综合模型,2001年12 月颁布CMMI 1. 1 版本,2006 年又推出了CMMI 1. 2版本。

CMMI相对CMM而言,是把各种能力成熟度模型集成到一个框架中去,其源模型包含如下三个: 一是CMM 2. 0版本( C稿) ; 二是电子行业协会临时标准( EIA/IS) 731;三是集成产品开发能力成熟度模型( IPD - CMM) v0. 98。通过这个框架建立一种从集成产品与过程发展的角度出发、包含健全的系统开发原则的过程改进和对软件采购方法的改革。CMMI共有五个等级,分别标志着软件企业能力成熟度的五个层次。

( 1) 初始级: 没有经过CMMI的指导,并用以执行开发过程改进的企业,其产品开发过程被视为初始级。其软件开发过程混乱、无序,对过程几乎没有定义,成功取决于个人努力; 管理是反应式的。

( 2) 已管理级: 建立了开发项目的基本管理过程,并定义其明确目标,用以项目经费和进度等的跟踪管理。其在软件开发的过程中执行了适当的监控措施,能重复早先类似应用项目取得的成功经验论文格式。

( 3) 已定义级: 已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。企业可以从其运作过的历史项目之中,提取出一套行之有效的项目开发规范,所有项目均可使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的。

( 4) 量化管理级: 已经能通过采取一系列量化的指标作为对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理过程有一个做出结论的客观依据,管理能够在定量的范围内预测性能。

( 5) 优化管理级: 企业已经具备通过执行一定的过程规范,可通过预防缺陷、技术创新和改进过程等多种方式对软件过程不断地进行改进,并且通过过程的量化反馈和先进的新思想、新技术不断改善企业软件过程能力。企业的软件过程能力可描述为持续改进的。[1]

2 CMMI模型的结构框架及模型范围

SEI于2010 年10 月28 日发布了CMMI模型的新版本CMMIfor Development V 1. 3,自2011 年11 月30 日起新的评估都要采用V 1. 3 模型,评估有效期为3 年。新版本V1. 3 模型取消了软件工程、硬件工程、系统工程等工程学科的单独描述,对成熟度4 级和5 级的过程域做了详细描述,并将原有的组织创新和部署( OPD) 改为组织绩效管理。在CM、PI、PP、PPQA、RD、REQM、RSKM、TS和VER增加敏捷方法的描述。并在OPD增加SP 1. 7 建立团队的规则和指南,在IPM增加SP 1. 6 建立团队。

CMMI模型的全部描述就是以过程域作为基本构件而展开的,针对不同的过程域分别规定了应达到什么目标( Goals) 和为了达到这些目标应该做些什么 “实践” ( Practice) ,但是模型中并不规定这些实践由谁做,如何做等。每个等级都被分解为若干关键过程域,特殊目标和特殊实践,通用目标、通用实践和共同特性。[1]

3 CMMI在中小企业中的实施背景及范围

3. 1 公司实施CMMI 3 背景简介

该公司主要承担信息、通信、自动化等领域的软件开发与研制,与国内外多家知名企业建立了联合设计伙伴关系。

目前该公司存在的主要问题有: 岗位职责不明确; 部分工作流程不清晰; 设计过程、输出等不规范。

目标: 持续改进过程能力,提高项目开发及管理水平,提升员工的工程化研发能力。

3. 2 CMMI 3 组织实施范围

本次CMMI实施涉及公司产品部、研发中心、质量管理部和相关管理部门,约150 人。主要覆盖其开发产品领域。

首先确定模型的过程机构和人员,其中项目和人员范围如图1 所示。

发起人: 确定CMMI实施目标和过程改进目标,提供必要的资源,参与项目的重大决策,关注CMMI实施过程中的问题; 从最上层开始推动SPI;

中层经理: 负责职能范围内的资源保障,过程的贯彻执行以及工作审查;

EPG ( 过程改进) : 负责CMMI ML3 体系的建立和完善工作,推进CMMI的实施;

QA ( 质量保证) : 对项目的各个过程提供客观的评价,并跟踪问题的解决;

培训组织人员: 根据组织目标,组织开展培训工作;

采购外包: 负责各项目的软硬件采购,项目外包工作;

项目经理: 负责按照合同及公司体系文件要求,管理项目,负责项目的验收工作;

需求人员: 负责需求的调研、分析及定义,根据需求并管理需求的变更;

设计人员: 负责产品的设计工作,并提供集成方案;

开发人员:负责产品开发和产品集成工作;

测试人员: 负责产品的测试工作;

配置管理: 负责项目及组织过程及组织过程资产的配置管理工作。

考虑其功能不同,各角色的实施过程域分配如下表所示。

4 CMMI 3 在中小企业中的实施过程

达到CMMI ML2 级需实施的过程域如下: CMMI ML2 级的过程域: 需求管理、项目策划、项目监督和控制、测量和分析、供方协定管理、过程和产品质量保证、配置管理7 个过程域;

CMMI ML3 级中的过程域: 需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、集成项目管理、组织培训、风险管理、决策分析与决定11 个过程域。其中,供方协定管理过程域是唯一一个可以裁剪的过程域,根据公司情况,如果不满足实施供方协定管理过程域的条件,公司对其进行裁剪。

公司于2013 年1 月启动开始引入CMMI标准改进其技术水平和管理过程,实施流程分为四个阶段:

第一阶段: 策划阶段。此阶段为整个CMMI实施做准备,主要工作为差距分析,CMMI基础培训,并根据差距分析结果制订详细的过程改进行动计划。

第二阶段: 体系建立阶段。此阶段的主要工作是: ①针对各个PA开展培训,详细解释标准要求,介绍最佳实践,并指导如何结合公司实际情况实施。②指导文件编写,评审文件。采用培训、研讨、文件编写、评审交叉进行的方式。

结合企业过程现状进行CMMI过程域培训,通过举例、案例分析等方式,让企业的EPG掌握过程文件定义技巧,结合企业实际情况有针对性的定义组织的研发过程,并确定过程产出物( 如需求报告) 。

第三阶段: 体系实施阶段。包括实施指导、实施持续支持、实施状态评审等工作。此阶段主要是指导如何在公司内实施CMMI,定期评审实施情况,并解决发现问题。

选择代表公司核心业务的项目或者典型项目进行试点,通过试点来完善过程文件,从而为企业全面推广过程文件打下基础。

第四阶段: 评估阶段。此阶段的主要工作有准备性检查( 即预评估) 、预评估问题解决,以及最终评估。验证组织推广的结果,识别企业尚存缺陷并制定再次改善方案,准备充分,以便企业能够更好地进行正式SCAMPI评估。

SCAM正式评估由SEI授权的主任评估师领导,采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement) 评估方法,对企业的能力成熟度进行正式的评估,颁发证书,通过SEI网站向全球发布企业信息。

通过建立过程改进体系后,确认推进实施CMMI 3后的过程改进方案:

第一,加强需求开发和管理工作; 第二,组织工程资产库的建立和维护; 第三,建立公司的度量管理体系; 第四,整合管理工具,建立信息数据共享机制。

5 结论和经验

CMMI是一种管理流程的标准化,是由产品开发、维护的最佳实践组成,涵盖产品构思、交付和维护的整个生存周期的活动。通过对中小软件企业的调查研究,中小企业CMMI的实施可参照上述过程,很多过程活动在小组织内根本无法开展,这部分内容要根据企业自身实际情况进行裁剪。

根据上述实施案例可以看出,CMMI实施过程中首先企业高层领导要给予必要的支持; 其次明确项目范围和人员的过程域; 需要明确培训目标及培训人员。

这里强调一点,企业必须根据自身的实际制定可行的方案,不深入研究就照搬其他企业的模式是很难起到提高软件产品质量水平的真正目的的。

参考文献

[1]沈剑沧,郑雪原,鲍培明.软件过程改进框架[J].计算机工程与设计,2007,28(22):5341.

CMMI过程性能模型 第7篇

在教学管理实践中认识到:同软件开发过程类似,教学实践过程中也存在很多“bug”(缺陷),并且教学过程中的“bug”更难以发现和控制,这些bug严重影响着教学质量的提高。只有逐渐形成教学过程的持续改进机制,实现教学过程的定量管理,尽可能地减少或者完全排除教学过程中的“bug”,才能实现教学质量的持续提高。为此,可以参照软件企业普遍采用的集成化能力成熟模型(capability maturity model integration,CMMI),在教学管理中引入过程管理的思想,通过构建本科教学过程持续改进机制,达到促使高校教学能力持续改进和教学质量持续提高的目标。

1 CMMI应用于本科教学过程管理的可行性分析

1.1 CMMI的概念

CMMI是美国卡内基-梅隆大学软件工程研究所组织开发的软件过程模型,它是提高软件开发过程的质量和效率的管理体系,融合了ISO9000等标准体系的核心思想,用以促进软件机构软件质量的提高。CMMI可以用初始级、已管理级、已定义级、定量管理级和优化级等五个不断进化的成熟度级别来表达[2]。在CMMI中,每一个等级都是下一个等级的基础,各个级别由不同的过程域组成,每个过程域由关键实践体现,通过实现这些关键实践活动来达到过程域所要求的目标。

如果一个软件机构实现了某个级别的所有目标,就表示该软件机构的软件能力达到了该级别,软件机构通过软件能力成熟度级别的提升实现其软件能力的持续改进。CMMI适合于广泛的知识工程领域。

1.2 本科教学过程管理与软件过程管理的共性比较

本科教学过程是一个依据教学规律不断重复、螺旋上升的过程。本科教学过程管理与软件企业的软件开发过程管理具有许多共同点:

(1)教学过程和软件开发过程都是一种可持续改进的“生产”过程,二者具有高度的相似性。教学活动和软件开发活动都属于抽象的高度脑力劳动,它们都是利用一定的经验,按照特定的计划目标,通过创造性的劳动,“生产”出符合特殊需要的“产品”的过程。

(2)教学活动和软件生产活动都可以划分成一系列的子过程,从而可以采用过程管理的思想提高“产品质量”。如,软件过程有:需求管理、流程设计管理、开发管理、测试管理等主要过程;教学过程则有:教学计划和教学大纲制定、教学设计与备课、课堂讲授、成绩考核、教学评价、教学成果推广等过程。

(3)从知识管理的角度来看,教学过程管理和软件过程管理具有极大的相似性。首先,二者都是通过知识的获取、利用、传播和创造来实现知识的流通共享,都是高智力的劳动过程,其“产品”都是人类智慧的结晶。其次,教学过程和软件开发过程都具有较高的抽象性,其管理过程透明性较差,执行程度和执行结果不容易做到标准化,相关数据不易测量,因而难以通过传统的管理方法对其实现量化管理和控制。

(4)从过程的组织实施来看,高校的人才培养能力和软件企业的生产能力都是以全体机构成员的整体素质为基础、可以通过加强人员管理来提高的。在早期的软件生产过程中,软件产品的质量主要靠软件开发人员的个人能力和素质来保证。随着软件规模的快速增长,软件质量难以控制产生“软件危机”。在试图解决这个危机时引入了软件过程管理与过程改进的概念。同样,高校的人才培养因其培养周期长、过程复杂,人才培养过程质量难以把握,从而导致教学质量难以控制的问题。在当前的教学管理模式下,教学质量的高低主要取决于教师个人的能力和态度,教学质量无法进行准确的控制。因此,我们尝试将软件过程管理和软件过程持续改进的思想引入到教学过程管理中,建立教学过程管理的CMMI对教学过程进行动态跟踪与管理。

1.3 在教学过程管理中应用CMMI的可行性

CMMI是提高软件开发过程质量和效率的管理体系,其本质是一种新兴的管理思想和方法,其精髓是过程标准化和持续过程改进。CMMI既融合了阶段性管理思想,又增加了管理过程的连续性,其管理方法更适合组织内部的过程能力改进,通过CMMI可以实现管理的透明性。CMMI所倡导的过程管理、质量意识、持续改进、基准管理、以人为本、规范化制度化、团队精神都是目前我国高校教学过程管理所缺少而又亟需具备的。

另外,CMMI虽然是针对软件机构的过程改进模型,结构比较抽象,但是其易于在软件工程以外的领域实施,对于高校教学过程管理具有较好的适用性[3]。因此,高等院校引入CMMI思想对本科教学过程进行管理,从而建立本科教学过程的持续改进机制是可行的。

2 本科教学过程CMMI

2.1 本科教学过程CMMI的级别划分

将CMMI思想引入到本科教学过程管理中,建立本科教学过程CMMI,如图1所示。

该模型将本科教学过程能力划分为5个成熟度级别:

(1)初始级。教学过程是无序的,教学进度、教学质量不可预测,通常只靠教师的个人水平去把握,一般不具备稳定的教学环境,也难以注重整体教学效果,管理人员或用人单位只能看到对学生的要求和结果。

(2)可重复级。管理制度化,制定了基本的教学管理政策以及为贯彻执行政策而制定的措施,基于以往教学过程中的经验来计划与管理新的教学,教学过程已制度化,有纪律,可重复,有一定的质量保证措施,并设置检查点进行阶段控制。

(3)标准级。教学管理过程,包括教学工作和管理工作,均实现标准化、文档化管理;制定了完整的教学过程管理文件体系,通过执行这些教学管理文件,规范化和程序化教师的教学过程;建立了完善的专家评审制度和教学及教学管理人员培训提高制度;教学内部结构清晰,便于管理人员参与管理。

(4)定量管理级。建立了人才培养质量量化目标;建立过程管理数据库,将教学过程中的过程数据存入数据库;可以根据收集的过程数据对教学过程进行客观的度量,预见教学过程中的问题,定量地、有目标地做出决定,用人单位也能定量地理解学生的能力。

(5)优化级。优化级的重点是对教学过程不断优化,主动找出教学过程的弱点与长处,改革和创新教育教学理论与方法,并且建立一套预防机制以达到预防缺陷的目标。

一个符合CMMI某一级别的教学过程,则认为其质量达到了某一水平。CMMI的升级,表明教学过程的持续改进,可以实现教学质量的提高;反之,若要持续提高教学质量,必须提升CMMI的级别,亦即必须建立教学过程的持续改进机制。因此,持续改进机制是提高教学质量的充分必要条件。

2.2 本科教学过程CMMI的关键教学过程域定义

在本科教学过程CMMI中,每一个成熟级别都包含若干个关键教学过程域,规定了该级别所要实现的目标。关键教学过程域由一系列关键教学实践活动组成,合理划分关键教学过程域,对关键教学活动进行量化和透明管理,及时发现教学过程中存在的“bug”,采取应对和改进措施,从而持续地改进教学能力,提高教学质量。

根据本科教学过程的基本规律,将本科教学过程管理CMMI划分为15个关键过程域,如表1所示。

根据实现的目标不同,每个关键教学过程域分别属于本科教学过程CMMI中的不同级别。其中,重复级包含4个关键过程域,标准级包含7个关键过程域,定量管理级包含2个关键过程域,优化级包含2个关键过程域。

3 本科教学过程持续改进机制

3.1 在教学过程管理实践中引入CMMI思想

哈尔滨理工大学软件学院是黑龙江省教育厅首批成立的两所省级示范性软件学院之一,现拥有软件工程和集成电路设计与集成系统两个软件类本科专业。由于学院成立时间短,专业设置新,学院的教学能力相对薄弱。在经过几年基本建设之后,学院把工作重点放到改进教学管理、提高教学质量上来。在充分调查研究的基础上,学院在教学过程管理中引入CMMI思想,以此作为推进教学改革、提高教学质量的有效途径。

经过几年的探索和实践,我院已经建立起比较完备的教学管理制度,并且制定了相关的本科教学过程管理文件,按照本科教学过程CMMI的级别划分标准,我院的教学能力处于CMMI的第3级(标准级)。为了实现教学能力成熟度的提升,不断提高教学质量,学院探索建立了本科教学过程的持续改进机制,通过科学合理的教学过程实施规范和教学过程综合管理平台,实现对教学过程的持续改进和教学质量的快速提高,取得了初步成效。

3.2 制定科学合理的教学过程实施规范

在引入CMMI管理思想之前,我院已经建立了比较完备的教学管理制度,并制定了一部分教学规范文件。在此基础上,学院按照本科教学过程CMMI划分的关键过程域,重新制定了一系列教学实践活动的过程规范,用以指导和管理教师的实践教学活动,进而实现对本科教学过程的持续改进。

首先按照CMMI第3级中的关键过程域,将本科教学过程划分成教学计划、教学设计、教师备课、课堂讲授、作业考核、评价反思、学生管理等关键过程,并对各个关键过程建立完整的过程规范,即标准文档。教学过程规范体系,如表2所示。

3.3 构建教学过程综合管理平台,对教学过程实施定量管理

按照本科教学过程管理CMMI第4级要求,教学过程管理可以实行定量管理和定量评价。我院在实现本科教学过程CMMI第3级的要求以后,已经建立起完备的教学过程规范体系,制定了一系列的教学执行标准,在此基础上对教学过程实施定量管理和定量评价,从而使我院的教学能力提升到CMMI第4级,实现了教学能力的持续改进和教学质量的持续提高。

教学过程定量管理和定量评价的关键在于对教学过程中各种数据进行收集、整理、分析,及时发现教学过程中存在的问题,反馈给相关教师和管理人员,及时提出改进措施,周而复始,逐步提高学院的教育教学能力,实现教学质量的持续改进和提高。面对大量统计数据,传统的人工管理方式显然不能适合教学过程定量管理的需要,为此我们创建了教学过程网上综合管理平台,通过计算机网络数据库实施教学过程的动态管理。教学过程网上综合管理平台的结构,如图2所示。

4 实施教学过程的定量管理和定量评价,实现教学质量的持续改进和提高

在完备的教学过程规范体系和教学过程网上综合管理平台的基础,可以实现教学过程的定量管理和定量评价,从而实现教学的持续改进和教学质量的快速提高。下面以教师教学过程管理和学生学习过程管理为例,介绍教学过程定量管理和定量评价的执行流程。

4.1 教师教学过程的定量管理

教师严格按照教学过程规范,制定课程教学计划和进度安排,认真备课、撰写教案、制作课件,并在上课前将备课信息提交到教学过程综合管理平台;课堂上教师认真按照教学计划组织课堂教学,创造性地开展教学活动;课后教师提交教学计划跟踪表,及时总结一周的教学情况,对于遇到的问题及时采取改进措施。另外,教师每周登陆教学管理平台,查阅学生课堂反馈情况,并在下一次上课时,给出合理的解释。每个月最后一天,教师应该对自己一个月来的教学工作进行总结,并将数据提交。每个月,教师参加系里组织的教学质量保证联席会议,接受反馈,参与讨论。整个教学过程,从备课、上课到课后批阅作业等环节,都接受质量保证的监控。教学过程定量管理的执行流程,如图3所示。

4.2 学生课堂反馈的定量评价

在整个教学过程中,学生既是接受教育的客体,同时又是评价教学过程的客体。在教学过程中,学生的课堂反馈信息,对于教师发现教学过程中的问题、改进教学方法、提高教学质量具有十分重要的参考意义。通过教学过程网上综合管理平台,学生可以方便地对于课堂教学情况进行反馈。每天上完课后,学生登录网络管理平台,就一天的课堂学习情况及教师的课堂讲授情况提交反馈信息。为了收集到真实、可靠、翔实的反馈信息,课堂反馈调查表的设计应该科学合理,调查选项既要覆盖全部教学评价内容,又要便于学生评价。为此,设计学生课堂反馈表。教师每周应该填写课堂反馈答复表,对于学生反馈的问题,及时给与答复。学生学习管理的执行流程,如图4所示。

5 结论

传统的教学督导与教学评价制度达不到持续提高教学质量的目的,只有建立教学过程的持续改进机制,才能实现教学质量的持续提高。实践证明,哈尔滨理工大学软件学院将CMMI思想引入到本科教学过程管理中,建立了完整的教学过程规范体系和教学过程网上综合管理平台,对教学过程实行定量和透明化管理,从而建立起本科教学过程的持续改进机制,学院的教学能力成熟度由本科教学过程CMMI的3级提升到第4级,实现了教学过程能力的持续改进,学院的教学质量得到了明显的提高。

参考文献

[1]徐晓娟,刘琦,华小洋.教师课堂教学评价主体及运行机制探讨[J].高等工程教育研究,2008(5):139-141.

[2]刘文红,吴欣,张敏.基于CMMI的软件质量保证[J].现代电子技术,2012,35(6):53-56.