基于CMMI的软件过程度量

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

摘要:CMMI为软件产品及软件过程提供了一套定量的表示和分析,即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点,介绍了基于CMMI的多层架构软件产品的度量模型,并着重讨论了基于CMMI的软件过程度量,总结了软件过程度量的工作方法和思路,提出了解决国内软件度量的一般性方法,为软件过程改进提供了可行的方法和实践。

关键词:CMMI;软件度量;软件过程能力;度量项;门限值

0引言

软件度量的目的是为项目管理提供项目的执行情况的充分可见性,并使项目管理者了解项目实际进展与项目计划之间的偏差,以便采取纠正行动,保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法;软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量;软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。

软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。

1三层架构软件产品度量

1.1质量要素

软件质量可分解成六个要素,这六个要素是软件的基本特征。功能性:软件所实现的功能满足用户需求的程度;可靠性:在规定的时间和条件下,软件所能维持其性能水平的程度;易用性:对于一个软件,用户学习、操作、准备输入和理解输出时所做努力的程度;效率:在指定的条件下,软件实现某种功能使用计算机资源(包括时间)的有效程度;可维修性:为了满足用户需求、环境改变或发生软件错误时,对软件进行相应修改所需的努力程度;可移植性:软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。

1.2评价准则

评价准则包括:精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。

1.3度量元

根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段,制定针对每一个阶段的度量元。

2基于CMMI软件过程度量

从软件企业的观点出发,软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure),为项目管理者提供有关项目的各种重要信息,也是进行软件评估活动的基础。

Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图:

图1软件度量过程体系结构

下面我们就上面的体系结构进行分析。

制定度量过程的计划包括两个方面的活动,一是确认范围,二是定义程序步骤。确认范围:明确度量需求的大小,以限定一个适合于企业本身需求的度量过程。因为在整个度量过程中是需要花费人力物力等有限资源的,不切实际的大而全或不足以反映实际结果的需求都会影响度量过程的可靠性以及企业的发展能力。定义程序步骤:在确认了范围后,定义操作及度量过程的步骤,同时成文立案。主要工作包括定义完整、一致、可操作的度量;定义数据采集方法以及如何进行数据记录与保存;定义可以对度量数据进行分析的相关技术,以使用户能根据度量数据得到实质性的结果。

过程的实施包括两方面的活动,一个是数据的采集,一个是数据的分析。数据的采集:根据已定义的度量操作进行数据的采集、记录及存储;此外,数据还应经过适当的校验以确认有效性。在进行该项活动时应具有一定的针对性,应注意到不同的项目或活动所需要的实际数据量是有差别的,对活动状态的跟踪是非常重要的。数据的分析:包括分析数据及准备报告、提交报告,并进行评审以确保报告足够准确。这些程序步骤可能需要反复,因为报告可能没有为使用者提供有益的帮助或使用者对报告中的内容不理解,在这两种情况下,都应回馈并重启度量过程以再进行数据分析。

过程的改善仅包含一个方面的活动,即优化过程。优化过程:用于动态地改善过程并确保提供一个结构化的方式综合且处理多个涉及过程改进的问题。除此以外,该活动要对度量过程本身进行评估,报告的使用者会对数据的有效性进行反馈。这些反馈可能来自其他的活动,但一般都会溶入到新一轮度量过程的生命周期中,对度量过程进行新的确认及定义。

在实现项目中,项目启动之后,项目度量工作就正式展开。项目经理在项目计划阶段要针对项目的特点制订相应的度量计划,制定度量数据收集和量化分析与控制的策略。在项目实施的过程中,项目相关成员按照预先设定的周期收集各项度量数据,填写相关软件度量记录表。度量负责人根据项目度量表采用适当的方法比较和分析项目级的度量数据,得出度量分析报告。在必要时采取纠正措施,如修正项目计划、进行相关培训等。项目结束时,度量负责人及相关人员对度量规程及有关文件、度量采集的数据、分析结果及报告进行验证后,将其放入相应度量数据库。

确定度量项要根据实际软件项目情况。如果我们比较关注项目进度、工作量和质量,可以将项目进度偏差不超过25%,项目工作量偏差不超过20%,项目的缺陷修复率不低于90%这三项指标作为度量目标。

2.1需求度量

需求的稳定度在极大程度上影响项目的规模、工作量和进度。不稳定的需求将带来负面影响,例如软件产品质量下降、项目成本增高、项目进度延迟等。跟踪分析需求的稳定性能够体现项目成员管理和控制软件需求的能力。目前国内软件项目对需求的分析和控制比较薄弱,开发人员付出了加倍的努力,用户满意度仍不理想。因此有必要对项目需求进行有效的度量和管理。

需求度量项主要包括:原始需求总数、本阶段新增需求的数目、本阶段删除需求的数目、本阶段修改需求

的数目、本阶段需求变更数目、本阶段需求总数目、项目结束时变更的需求总数、项目结束时需求总数、需求变更比例、需求实现率等。

需求变更可能直接导致规模的增长、进度的延迟、成本的增加以及返工。项目成员应周期性地度量需求变更(包括新增、修改和删除需求)和需求总数的变化,控制需求变更并采取相应行动。图2表现了需求的稳定度,两条折线分别表示监控过程需求总数的变化以及需求变更数目的变化。假设需求基线化评审发生在第3次项目监控时,该图显示,需求评审之后,第4次的需求总数以及第4、5、6次需求变更数都有明显增长,在第7次以后需求趋于稳定。说明在需求基线化评审结束之后相当一段时间需求仍然不稳定。产生的原因可能有以下几种:(1)需

本文原文求调研不充分、误解、歧义、不完整、不正确等;(2)客户需求变化频繁。解决措施:在进行需求调研时充分挖掘客户的需求,进行需求确认。对于频繁变更的需求,项目成员可能要采取诸如重新分配资源及重新估算规模、工作量和进度等措施。

图2需求变化趋势图

2.2规模度量

规模是项目的基本度量项,是决定软件项目成本的最基本因素,是估算工作量和进度、计算生产率、缺陷密度及其它项目评估指标的基础。对规模的有效估算、跟踪和控制,一方面使得项目得以按照预定计划顺利开展,另—方面也也保证机构盈利目标的实现。

监控实际规模与估算规模的偏差。如果需要,重新估算工作量和进度。

在里程碑处(如需求阶段、设计阶段)以及大的需求变更发生时,或进行项目情况汇总时,项目经理需要分析规模变化率并监控产品有效规模的偏差。

如果规模变化率在上下控制限范围内,则度量结果是可以接受的。

如果规模变化率超出上下控制限范围,则分析原因并采取相应措施。

度量项主要包括:项目估计规模、项目实际规模、规模变化率、项目估计成本、项目实际成本、可复用的代码行等。可以根据实际情况取舍。

2.3进度度量

保证软件项目的进度是控制项目成本,赢得用户满意的关键。软件项目容易在进度上发生问题,对项目的进度进行定量的高透明度的管理,可以尽早发现进度的延误,迅速做出相应的调整。具体度量项包括:项目估计进度、项目实际进度、进度偏差、里程碑计划总天数、里程碑实际总天数、里程碑差异天数、项目计划总天数、项目实际总天数、项目总的差异天数。如果进度偏差超出控制界限,则分析原因,采取措施,跟踪进度,直至进度得到控制。

相关文档
最新文档