没有合适的资源?快使用搜索试试~ 我知道了~
理论计算机科学电子笔记233(2009)73-87www.elsevier.com/locate/entcs软件维护成熟度模型(S3M):成熟度级别3和4的度量实践Alain April和阿兰·阿布兰E'coledeTechnologieSup'erieure,Montr'eal,CanadaEmail:alain.apriletsmtl.ca,alain.abranetsmtl.ca摘要软件维护的评估和持续改进是提高软件质量的关键因素。软件维护功能的支持,从稀缺的管理模式,将促进这些功能。本文概述了软件维护成熟度模型(S3M)的3级及更高级别的度量实践。关键词:软件维护,成熟度模型,过程改进,过程评估,产品评估1引言由于缺乏规划,软件维护仍然没有得到管理层的重视和支持,正如其危机管理风格经常说明的那样部分问题在于,维护通常被认为是昂贵和无效的。此外,几乎没有提出可在工业中立即应用一般来说,软件工程社区期望,如果维护过程得到改进,产品质量将得到提高。然而,研究人员倾向于开发孤立的、技术性很强的解决方案,这些解决方案在工业中的应用极具挑战性,尤其是在预算非常少、时间有限的小型维护团队中,这些解决方案用于改善维护活动。与此同时,一些运行最好的维护组织已经实施了一些软件维护最佳实践,尽管这些实践尚未得到认可,需要更好地描述,以便为向整个行业的技术转让做好准备。对于软件开发功能,已经存在许多成熟度模型用于评估开发过程和提出改进建议。对于软-1571-0661/© 2009 Elsevier B. V.根据CC BY-NC-ND许可证开放访问。doi:10.1016/j.entcs.2009.02.06274A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73软件维护功能,现有的评估模型的全面性要差得多本文基于第一个综合模型,考虑到维护过程的特定特征,软件维护成熟度模型该模型最近发表在《软件维护管理:评估和持续改进》[ 2 ]中本文概述了一些高级度量实践,这些实践被确定为更高级别的成熟度,例如3级及以上。该模型参考了ISO/IEC-12207、ISO/IEC-9126、CMMI和IEEE-1061等其他模型的元素。[3]中有一个模型的概述,明确描述了每个成熟度级别的性质和元素。最后,如果作者能提供一个案例研究,说明所提出的模型的应用及其使用结果,那将是有益的。本文的结构如下。第二部分介绍了软件维护的接口和关键过程。第3节介绍了软件维护的度量主题,使用信息源来识别成熟度级别3和更高级别的实践所需的第4节介绍了成熟度级别3及更高级别的高级度量实践最后,第5节提出了一个总结和说明。2软件维护的接口和关键过程理解维护活动的范围和软件维护人员日常工作的环境是很重要的在典型的软件维护组织环境中确实存在多个接口:• 软件维护的客户和用户(图1中标记为1);• 基础设施和运营部(标记为2);• 开发人员(标记为3);• 供应商(标记为4);• 前台维护和帮助台(标记为5)。考虑到这些接口需要日常服务,维护经理必须保持应用程序平稳运行,在出现生产问题时迅速做出反应以恢复服务,达到或超过商定的服务水平,保持用户群体的信心,即他们拥有一个在商定预算范围内行事的专业和称职的支持团队。[1]中强调了小型维护请求的性质和处理的关键特征,例如:• 修改请求或多或少是随机的,无法计算A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7375应用软件维护前期维护和帮助台客户和用户软件开发基础设施和运营供应商应用软件维护前期维护和帮助台客户和用户软件开发基础设施和运营供应商1请求状态发展项目服务水平协议,维修服务支持初始过渡4故障调用问题票 5 2问题解决沟通基础设施和运营前期维护和帮助台应用软件维护3供应商软件开发客户和用户1请求状态发展项目服务水平协议,维修服务支持初始过渡4故障调用问题票 5 2问题解决沟通基础设施和运营前期维护和帮助台应用软件维护3供应商软件开发客户和用户Fig. 1. 软件维护者上下文在年度预算规划过程中单独使用;• 调整请求通常在业务层面进行审查并分配优先级,其中大多数不需要高级管理层参与;• 使用队列管理而不是项目管理技术来管理维护工作量;• 每个小型维护请求的大小和复杂性使得它通常可以由一个或两个资源来处理;• 维护工作量是面向用户服务和面向应用程序• 优先顺序可以随时改变,更正请求可以优先于其他正在进行的工作;76A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73在S3M中,软件维护过程分为三类(图2),以提供与ISO 12207标准所用类似的表示,但重点是软件维护过程和活动:(i) 主要过程(软件维护操作过程);(ii) 支持过程(支持主要过程);(iii) 由信息系统(IS)或组织的其他部门(例如,培训、财务、人力资源、采购等)执行的组织过程。这个通用的软件维护过程模型有助于解释和表示各种关键的软件维护过程。软件维护组织使用的关键操作过程(也称为主要过程)在软件项目开发开始过渡进程。 这个过程并不局限于开发人员将系统移交给维护人员,而是确保软件项目受到控制,并使用结构化和协调的方法将软件移交给维护人员。在这个过程中,维护人员将关注这个新软件的可维护性,这意味着在系统开发生命周期中实施一个过程一旦软件成为维护者的责任,事件和服务请求管理流程处理所有日常问题,问题报告,修改请求和支持请求。这些都是必须有效管理的日常服务。此过程的第一步是评估请求是否要被处理、重新路由或拒绝(基于服务水平协议(SLA)以及请求的性质和大小)[5]。SLA和供应商协议流程涉及合同方面(例如托管、许可证、第三方)和SLA的管理。在以下服务类别之一中记录、优先化、分配和处理已接受的请求:1)运营支持过程(通常不需要对软件进行任何修改); 2)软件纠正过程;或3)软件演进过程。请注意,某些服务请求不会导致软件的任何修改。这些活动称为业务支助活动在模型中,它们包括:a)回答问题; b)提供信息和咨询; c)帮助客户更好地理解软件、交易或其文档。下一个主要过程涉及版本管理过程,它将项目转移到生产,以及监控和控制过程,确保操作环境没有被退化了维护人员始终监视操作系统及其环境的行为,以寻找退化的迹象。当发生异常情况时,他们将迅速警告其他支持组(操作员、技术支持、调度、网络和桌面支持),并判断是否发生了需要调查的服务降级实例。最后一个主要过程,恢复、迁移和淘汰,解决了提高可维护性的活动,将系统迁移到另一个环境的迁移活动,以及A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7377工程师O pOpp errraaatttionalnaalSuSu uu uuppppoorrr ttttttSeServviceeCCCCCE vE vE voo lo luuttiiovneesSeSer vicS塞塞塞塞斯岛CRooPRRPP公司简介定义它,作为一种方法,VVVerrriiifffiiicantcantcantiiioonn-VVValalalaliiidddatatatattiioo所以我们要C oMMMnafiiinnngtttuerrnancencencenanceationMaT rT rT rn aagiiinnngg我就像你一样andMeas uAnraelmysenistMeas uofr e mentM a inte na nc eT rT rSoaftnwsiatittirronntinntratinti nIEIsss uvsueneetaaandnddR eR eSe rR eqqqviuuueeessstttt tt tM aM aM aM aR ennnaaagqgeM a inte na nce Plan n ningCC在nov a t ion and d德普卢伊门PM oPrrod unitcotrionngSSu rvaneillilldaanncceecnM a inte na nce Tr a in inV eV erV essiornsi onM aR eR ensatagretmanneddnt p U g radess sa t a g r e t m aDMMMocuaiiimnttteetetetetetetetetenn anatttncncncioneP lp lp lP leten nnnnnin gngngn gn gO操作设备本地化支持SeServviceeCorrrree ctiveeSerServviceeE vE vo lo l utiveS e r vicce sPPPuuurrrccchah ah asssiiinggaaandndn dHHHuuummmaaannnRRReeesssourourcccasssses的ssc e s s es seoeRcooPRRPPC aC aC auuuusssaaallA nA nA naaaaalyyysssiiissssaaannndddP rP rP rooobbbb b bbblllemmmR eR eR essssooollluutrev ie w s andA u d its产品与服务曲阿立作为我们的一员S o f t w areRPerjouvdu ce nnatittoonnonSuM irvgerilllianc en重新开始E vE vE vE vS LS LS LoooAAAllluuutttaaaiiinnnvvvdddeSe rSe rSe rSe rSSSuuupppvv农业部P r o duc tionSur v eE vEool utiveeSerServvicc e工程师O pOpp errraaatttionalnaalSuSu uu uuppppoorrr ttttttSeServviceeCCCCCE vE vE voo lo luuttiiovneesSeSer vicrev ie w s andA u d its产品与服务曲阿立作为我们的一员S塞塞塞塞斯岛CRooPRRPP公司简介定义它,作为一种方法,VVVerrriiifffiiicantcantcantiiioonn-VVValalalaliiidddatatatattiioo所以我们要C oMMMnafiiinnngtttuerrnancencencenanceationMaT rT rT rn aagiiinnngg我就像你一样andMeas uAnraelmysenistMeas uofr e mentM a inte na nc eT rT rSoaftnwsiatittirronntinntratinti nIEIsss uvsueneetaaandnddR eR eSe rR eqqqviuuueeessstttt tt tM aM aM aM aR ennnaaagqgeM a inte na nce Plan n ningCC在nov a t ion and d德普卢伊门PM oPrrod unitcotrionngSSu rvaneillilldaanncceecnM a inte na nce Tr a in inV eV erV essiornsi onM aR eR ensatagretmanneddnt p U g radess sa t a g r e t m aDMMMocuaiiimnttteetetetetetetetetenn anatttncncncioneP lp lp lP leten nnnnnin gngngn gn gCorrrree ctiveeSerServviceeO操作设备本地化支持SeServviceeE vE vo lo l utiveS e r vicce sPPPuuurrrccchah ah asssiiinggaaandndn dHHHuuummmaaannnRRReeesssourourcccassssC aC aC auuuusssaaallA nA nA naaaaalyyysssiiissssaaannndddP rP rP rooobbbb b bbblllemmmR eR eR essssooollluutes的ssc e s s es seoeRcooPRRPPS LS LS LAAAaaannnndddSSSuuuppppppppplielielierrr农业部Ev o lu t ive Ser v ice sS o ftw a reR e juv e na tion Mig r a t ion重新开始Ev o lu t ive Ser v ice sP r o duc tionSur v e软件更新Ev en t andd Ser vice Req u es t妈妈S o ftw a reR e juv e na tion Mig r a t ion重新开始公司简介定义它,作为一种方法,作为你的孩子,M a inte na nc e在nov a t ion and d德普卢伊门特M a inte na nce Tr a in inin gPu r cha sing and Humm an R esour ces公司简介定义它,作为一种方法,作为你的孩子,M a inte na nc e在nov a t ion and d德普卢伊门特M a inte na nce Tr a in inin gPu r cha sing and Humm an R esour cesD E V E LOP E R S U SS U P P LIE R SIn fr a s tru c tur e和操作所以我们要公司简介rev ie w sand A u dits你好一个简单的方法是一个简单的方如果我是你,- V alid at io n产品与服务曲阿立作为我们的图二. 软件维护者的关键过程的分类一系列的进化工程Ev o lu tio n sVe r s io n妈妈联系我们Op e r a tio na l Su ppor t我的天啊公司简介SL A和Sup p p lier农业部M a inte na nce Plan n ningD o cum m en tatio n一系列的进化工程D E V ELOP E R SU S ER SOp e r a tio na l Su pp软件更新Ev en t andd妈妈维克·E爵士回复联系我们Ve r s io n妈妈我的天啊公司简介S o ftw areR重新开始米格·拉·托年轻人S U P PLIE R SSL A和Sup p p lier农业部Ev o lu tio nsIn fr a s tru c ture和操作D o cum m en tatio n所以我们要公司简介产品与服务曲阿立作为我们的一员如果我是你,rev ie w s andA u d its你好一个简单的方法是一个简单的方M a inte na nce Plan n ningP R I M a r y P r o c e sse sO PS.. S U U P P P P OR R T TO PS.. S U U P P P P OR R T TO r g an iiz a t. 我在LO r g a n iiz at. 我在LPr i m a r y 公司简介P r oces es es esP r o ces es es esP r o c e sse sP r o c e sse s78A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73系统退役时的退役活动当需要时,由操作过程使用的过程被称为是一种“支持性服务”。在大多数组织中,这些过程由开发人员和维护人员共享。此分类包括:(a)文件编制过程; b)软件配置管理功能和工具,通常与开发人员共享; c)过程和产品质量保证; d)验证和确认过程; e)审查和审计过程;最后,f)问题解决过程,通常与基础设施和运营部门共享。这些都是支持软件操作维护过程活动所需的关键过程。‘Organizational processes’ are typically offered by the IS organization and byother departments in the organization (e.g. the many maintenance planning per-spectives,虽然衡量和评估这些流程很重要,但更重要的是维护人员首先定义和优化运营流程。业务支助流程和组织流程遵循这些流程。3维护测量实践下一节概述了联合国人权事务高级专员办事处使用的信息来源。S3M用于度量软件维护过程、产品和服务。3.1维护过程测量-信息来源过程被定义为特定目的而执行的一系列步骤。据观察,软件的质量在很大程度上取决于用于设计和维护软件的开发过程的质量[22]。因此,维护经理的目标是帮助控制这样一个过程,测量在帮助他实现这一目标方面起着重要的作用。因为维护经理对软件的开发几乎没有控制权,所以他必须确定最早的一点,在这个点上,他可以了解正在构建的新软件的可维护性特征。在交付前和过渡期间启动测量是评估正在开发的产品质量及其在维护中是否准备就绪的关键策略。为了实现这个目标,可以决定实施一个维护度量程序,并将其与软件开发项目度量联系起来。例如,如果维护人员能够在新软件开发的早期设定一些可维护性目标,那么在开发期间和开发之后都可以测量其质量。在度量软件维护过程之前,必须考虑许多因素[23]。一个战略是确定该过程的关键活动。这些关键活动具有可以测量的特征,但是,在确定测量之前,必须定义软件维护过程。4月提出了软件维护测量先决条件A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7379维护过程维护过程AplicationBefore功能大小代码行环境特征维护请求数目努力计划人日其他投入工具行政服务AplicationBefore功能大小代码行环境特征维护请 求 数目努力计划人日其他投入工具行政服务AplicationAfterr功能大小代码行环境特征已完成的请求数类别职能规模代码行数人日AplicationAfterr功能大小代码行环境特征已完成的请求数类别职能规模代码行数人日图3.第三章。维护过程的选定特征示例[Des97]和Al-Shurougi [6]:1)定义维护工作类别; 2)实施请求管理流程;3)在活动账户数据图表中对维护工作分类(可计费/不可计费); 4)实施活动管理(时间表)软件,数据验证; 5)测量变更请求的大小。SEI [25]将过程度量活动描述为出现在成熟度级别2。这证实了在开始测量之前需要一个定义的过程。虽然SEI其他作者[17,9]确认了这一观点,并指出软件维护度量程序必须与开发人员的度量程序分开计划:因为度量需求是不同的,软件维护度量更侧重于问题解决和变更请求的管理成熟度较高的组织已经建立了维护度量程序。例如,Grady和Caswell [10]确定了以下关注点,软件维护测量程序专用维护过程维护过程80A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73我们应该如何计划一个软件产品族的维护阶段?产品什么时候稳定?软件产品的平均故障间隔时间(MTBF)真的是软件质量的一个应在哪个开发阶段进行工具和培训投资?文档如何提高可支持性?在一个给定规模的项目中,可以预期有多少缺陷发布前发现的缺陷和发布后发现的缺陷之间存在什么关系如果有的话,产品的大小和修复缺陷的平均时间之间的关系是什么?修复缺陷的平均时间是多少?需要多少测试才能确保fix是正确的?在维护过程中引入的缺陷百分比是多少在增强的时候?3.2维护产品-测量信息来源在软件工程文献[15]中,经常出现两种不同的可维护性观点。从外部的角度来看,可维护性试图衡量诊断、分析和将更改应用于特定应用软件所需的时间。从内部产品的角度来看,其思想是度量应用软件的属性,这些属性与修改应用软件所需的资源有关。 应用程序的可维护性没有单一的衡量标准IEEE 1061标准[11]也提供了度量的例子,但没有特别预先规定任何度量。通过采用可靠性是软件质量的一个重要特性的观点,IEEE 982.2指南[12]提出了一个度量字典。3.3维修服务-测量信息来源一些作者认为“软件维护比软件开发具有更多类似服务的其他信息系统/信息技术服务,如计算机业务,似乎也是如此。在文献中已经提出了软件维护服务的服务质量措施。它们分为两类:A) 服务协议(服务水平协议、服务合同和外包合同)B) 软件维护基准测试A) 服务水平协议(SLA)为了就服务水平达成一致,客户和维护组织必须就相关概念、术语A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7381以及将采取的措施。当服务水平协议完全在一个组织内执行时,就被称为内部协议。这类协议记录了关于许多维护服务的活动/结果和目标的共识SLA最初出现在20世纪50年代的大型计算机操作中心[16]。在20世纪70年代,他们逐步将其范围扩大到所有面向IS/IT服务的活动。然而,许多IS/IT组织目前仍然没有SLA [14]。最近出现了一些尝试,以确定示范做法和提出SLA成熟度模型。CobiT是IS/IT审计师使用的一组示例性实践:它识别并描述了必须实现的实践,以满足IS/IT审计师对SLA的要求。它还将“服务水平的定义和管理”确定为一项基本做法,并将衡量服务质量作为其主要目标。CobiT描述了协议的五个成熟度级别(不存在、临时、可重复、定义、管理/测量和优化)[8]。CobiT还描述了与软件维护直接相关的软件工程过程。SLA成熟度模型的其他建议可以在[19,13]中找到。在竞争激烈的环境中,SLA成为客户满意度的重要因素。一些出版物在软件维护环境中直接解决了这些问题[18,7,20,5,13,19,8]。SLA应阐明每项服务的期望/要求。在维护组织与其用户/客户之间关于软件维护服务的内部协议的背景下,报告了两种态度[5]:1) 一方面,客户希望专注于他的业务,并期望从他的IS/IT组织获得同质服务为客户提供这种同质服务的结果这种服务、这些系统或它们的基础设施的构成方式对客户来说不太重要,客户希望这种愿景在其SLA中得到体现。这就意味着,应当对整个服务(包括服务台和计算机操作)而不仅仅是个别/部分信息系统/信息技术组成部分(即服务器、网络、软件)说明基于成果的服务级协议2) 另一方面,软件维护人员只拥有客户所认为的服务的一部分。他们通常非常愿意为他们的服务提供基于结果的SLA。但是,这些产品在不属于其职责范围的基础设施(桌面、网络、平台)上运行,因为它们只与帮助台和计算机操作接口。要实现软件所有组件的集成度量,意味着所有相关团体的参与,并且IS/IT中的某个人必须拥有一个描述所有IS/IT服务的在[5]中,详细描述了内部SLA的案例研究。[5]也同意其他作者的观点,因为所有的IS/IT服务组织,82A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73必须在统一的SLA中记录对客户的支持,以满足客户的要求。统一的SLA包括所有参与支持最终用户的IS/IT组织的服务级别。B) 软件维护基准测试基准测试的一个流行定义最初是由David T.Xerox首席执行官Kearns:“标杆管理是一个持续的过程,衡量产品、服务和实践,与最强大的竞争对手或被公认为行业领导者的公司进行比较。”标杆管理的先决条件是对内部流程有清晰的理解。虽然测量程序不需要非常详细,但必须有数据。专门使用此方法进行维护的组织可以在练习结束时提供以下图表/测量的(i) 每人支持的功能点(内部开发)(ii) 每人支持的功能点(FP)(内部开发+软件包)(iii) 基于支持的功能点的(iv) 应用软件(目前正在生产)(v) 应用软件(目前正在生产)的年龄组(按功能分列的百分比)(vi) 支持的编程语言数量(vii) 支持的数据结构(顺序,索引,关系,其他)(viii) 编程类型的百分比(维护、改进、新应用程序)(ix) 支持(x) 支持(xi) 支持(xii) 人员稳定性百分比(更替率)(xiii) 就业时间(年)(xiv) 人力资源水平(占雇员总数的百分比)(xv) 薪金(xvi) 培训天数(每人每年培训天数)(xvii) 每1000个受支持FP的(xviii) 每1000个支持FP的用开放式数据库对活动进行基准测试现在是可行的,例如国际软件基准测试标准组(A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7383BSG(www.isbsg.org)。标杆管理需要知识渊博的拥护者提供持续的帮助在其他更成熟的行业中,组织通常会发布使用这种基准测试实践的富有洞察力的结果。4维护测量高级实践我们在第3节中介绍了用于识别该成熟度模型的高级度量实践的主要来源在成熟度级别,定义并实施了过程、产品和服务的3个度量:实施度量被认为是组织过程改进项目的一部分。软件维护措施还应与软件开发和操作措施放在一起。制度化软件维护流程的主要活动及服务已被识别为待计量的候选项目所维护的应用软件的质量属性记录测量目标(目标)和基线(当前值):这些目标与每个组织的业务目标和特定背景在明确界定衡量标准之后,需要确定其来源、数据收集活动和核查要求。维修人员接受有关测量及验证活动的培训。数据由维护人员根据需要在操作级别收集,然后合并到组织存储库中,在那里它们可以用于开发用于维护目的的测量模型随后是客户报告维护措施。 在这一级3 过程成熟度,软件维护客户应该对跨活动、服务和应用软件的IT度量的协调性有一个表1给出了一组8个高级度量实践,可以在成熟度级别3观察到。例如,实施规程Pro4.3.2就每一个目标而言,已设定具体目标,并收集所收集的数据,以监测该目标的进展情况。同样,已为每个应用程序定义了服务级别协议,并根据相应维护合同中指定的服务级别跟踪进度。这些高级测量实践的详细信息可参见第3节中确定的参考文献。在成熟度级别4(见表2),建立过程和产品的度量及其关键活动的过程的特征在于其量化方面,其设计目的是管理目标的实现。在这个成熟度级别上,过程和软件质量的影响在统计上得到了证明,并且已经到位的措施得到了优化。对性能、质量和应用软件的属性进行了回顾和分析。目标和基线的间隔是统计确定的。机械化分析84A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73实践描述ro4.3.1软件维护管理人员确定用于报告故障原因(过程、中间产品和生产软件)。Pro4.3.2所有维护的应用软件都有一组候选的质量和服务度量。ro4.3.3软件维护组织识别软件维护的过程和关键活动及其相关的质量措施。Pro4.3.4软件维护组织为每个选定的度量设置质量目标和性能目标ro4.3.5对软件维护测量结果进行统计分析的现有分析技术进行了识别和评估。ro4.3.6每一个软件维护过程、维护的应用软件和产品都有一个基线,用于分析、并随时间跟踪其进展情况。Pro4.3.7设计、实施和监测流程绩效模型Pro4.3.8设计、实施和监测软件性能模型。表1成熟度级别3的S3M软件允许定义额外的措施,以增加可维护性的所有四个子特性的覆盖范围客户感知到活动、服务和应用软件的内部编程标准的度量包括在编译器、汇编器、链接、操作系统加载程序、测试工具和文档工具中。预测故障的模型发展到用于决定是否可以将变更推广到生产。表2给出了一组四个高级度量实践,可以在成熟度级别4观察到。例如,实践Pro4.4.2“维护组织单位以定量方式测量其生产率”:对于每个应用软件,针对软件功能需求变更的每个请求收集分类数据,使用ISO认可的功能尺寸测量方法确定每个此类变更的尺寸,并使用相关的附加应用特性计算生产率。对维护请求在维护类别中的分布进行监控和分析,以便与过去的数据进行有意义的比较,并对维护估计模型进行调整,以便每一项先进措施的细节-A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7385实践描述o4.4.1估计的数据存储在数据库中以用于改进处理和计划未来的请求(请求的大小估计、关于所需工作的数据、关于生产率的数据缺陷)。Pro4.4.2维修组织单元以定量的方式衡量其生产率。o4.4.3软件可维护性的内部度量受到进一步定义、工具自动化和定量分析的影响。他们被简单地解释给所有利益相关者。ro4.4.4建立并保持对关键活动、选定措施和分析技术的使用方面的绩效差距的了解表2成熟度级别4的S3M在第3节中确定的参考文献中可以找到有关的实践。在成熟度级别5,用于管理软件维护需求和产品可靠性的模型通常用于使用过去事件/请求(大小,持续时间,时间,缺陷的关键性)的度量来评估资源或进度测量分析(关于维护过程和产品)的结果也用于监控过程及其关键子过程,以确保它们在统计过程控制下进行5总结本文介绍了软件维护度量信息源,已被用来识别过程和产品的测量实践中的S3M成熟度模型的软件维护。已经为成熟度级别3和4提供了两组高级度量实践。需要进一步的工作,以确定该模型如何帮助软件维护组织在他们的改进活动。例如,分析实证研究的结果,以便清楚地表明每种做法的拟议位置,这将是非常适当和有用的。例如,表1和表2的实践应该分析性地解释,以便更好地理解。这将确保维护专家建议的或文献中描述的关键实践可用于行业并产生预期的效益。还可以进行实证研究,以研究模型作为维护管理持续改进工具的效率。实证研究将有助于更好地了解软件维护功能的问题,并在所提出的模型的验证。86A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)73确认我们感谢为该项目做出贡献的行业成员,并特别感谢IBM GSA澳大利亚的LaxmanVasan和飞思卡尔美国的Caroline Milam。这项研究是在软件工程研究实验室进行的,E'coledeTech nologieSu'ere- U i v e r y y D r. 阿莲阿布兰 本报告中表达的意见仅代表作者个人。引用[1] Abran,A.,H. Nguyenkim,(1993年)。从基于需求的角度衡量维护过程,软件维护杂志:研究与实践,5,63-90。[2] April,A,Abran,A.软件维护管理:评估和持续改进,IEEE计算机协会,isbn:9780470147078,320p。[3] A. April,J. Hu J. Hayes,A.阿布兰河Dumke,[4] A. April,A. 阿布兰河 Dumke,[5] April,A.,J. Bouman,A. Abran,D. Al-Shurougi,(2001年)。服务水平协议中的软件维护:控制客户期望,FESMA,海德堡,德国,5月。[6] April,A.; Al-Shurougi,D.: 软件产品测量为供货商评价,软件度量会议论文集(FESMA-AEMES),西班牙马德里,2000年10月18-20日,Http://www.gelog.etsmtl.ca/publications/pdf/583.pdf[2008年2月10日]。[7] Bouman,J.,Trienekens,J.,Van der Zwan,M.(1999年)。服务水平协议的规范,在实践研究的基础上澄清概念,软件技术和工程实践会议录[8] IT治理研究所,(2007年)。CobiT,版本4.1。[9] Desharnais,J-M.,Par,F.,圣皮埃尔湾(1997年)。在软件维护中实现度量程序[10] 格雷迪河,Caswell,D.(1987年)。软件开发Englewood Cli Cles,NJ,Prentice-Hall.[11]电气与电子工程师学会。IEEE软件质量评估方法标准,标准1061-1998。电气和电子工程师协会:纽约,纽约,1998年; 35页。[12] 电气与电子工程师学会。IEEE Guide for the use of the IEEE Standard Dictionary of measures to producereliable software,Standard 982.2-1988:96p.[13] Kajko-Mattsson M.,Ahnlund,C.,Lundberg,E.(2004年)。CM3:服务水平协议,IEEE软件维护国际会议论文集(ICSM 2004)。芝加哥,IL,美国,432[14] Karten,N. 建立服务水平协议。Karten Associates.http://www.nkarten.com/slaservices.html[15] Lagu,B., April,A.(1996年)。ISO9126可维修性内部控制系统到工业研究工具的映射,1996年SES会议录,蒙特利尔,十月21-25,http://www.lrgl.uqam.ca/sponsored/ses96/paper/lague.html[16] McBride,D.(1990年)。服务级别协议:高效系统管理和应用程序优化之路,Hewlett-PackardProfessional。[17] McGarry,J.(1995年)。实用软件度量:客观程序洞察指南,国防部,1995年9月。[18] 米勒湾(1994年)。软件维护协议准备改变,系统管理杂志。A. April,A.Abran/Electronic Notes in Theoretical Computer Science 233(2009)7387[19] Niessink,F.,Clerk,V. van Vliet,H. IT服务能力成熟度模型,1.0候选版本1,软件工程研究中心:荷兰乌得勒支,2005年; 224页,http://www.itservicecmm.org/[20] Niessink,F.《软件维护的观点》,SIKS博士论文2000-1,荷兰信息与知识系统研究生院。[21] Pigoski,T. M.(1997年)。实用软件维护:管理软件投资的最佳实践。[22] Paulk,M.(1995年)。SEI的SW-CMM软件过程的演变1,1995年8月[23] P Pleeeger,S.L.,Bohner,S.(1990年)。维护度量的框架。软件维护会议论文集(佛罗里达州奥兰多),IEEE计算机协会出版社。[24] Pressman,R.S.软件工程:实践者的方法。McGraw-Hill,New York,NY,2001; 860p.[25] 能力成熟模型一体化为软件工程(CMMi),(2002年)的报告。版本1.1,CMU/SEI-2002-TR-028,ESC-TR-2002-028,软件工程研究所,卡内基梅隆大学。
下载后可阅读完整内容,剩余1页未读,立即下载
cpongm
- 粉丝: 4
- 资源: 2万+
上传资源 快速赚钱
- 我的内容管理 收起
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
会员权益专享
最新资源
- zigbee-cluster-library-specification
- JSBSim Reference Manual
- c++校园超市商品信息管理系统课程设计说明书(含源代码) (2).pdf
- 建筑供配电系统相关课件.pptx
- 企业管理规章制度及管理模式.doc
- vb打开摄像头.doc
- 云计算-可信计算中认证协议改进方案.pdf
- [详细完整版]单片机编程4.ppt
- c语言常用算法.pdf
- c++经典程序代码大全.pdf
- 单片机数字时钟资料.doc
- 11项目管理前沿1.0.pptx
- 基于ssm的“魅力”繁峙宣传网站的设计与实现论文.doc
- 智慧交通综合解决方案.pptx
- 建筑防潮设计-PowerPointPresentati.pptx
- SPC统计过程控制程序.pptx
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功