全球研究计算机科学杂志》上
菜单石头:2229 - 371 x
石头:2229 - 371 x
拉库马g .1,Dr.K.Alagarsamy2
|
| 相关文章Pubmed,谷歌学者 |
访问更多的相关文章全球研究计算机科学杂志》上
软件评估模型应该支持软件项目的管理决策。软件成本估算是一个过程,预测开发一个软件系统所需的成本和精力。提出了许多估计模型在过去的20到30年。许多软件公司项目跟踪和分析性能通过测量成本估算精度。高估计误差经常被解释为可怜的估计能力。在软件成本估算的一个问题是如何评估评估模型。一个关键因素是其估计的准确性在选择一个成本估算模型。不幸的是,尽管大量的经验估算模型,这些模型的准确性并不令人满意。本文包括评论的性能评估模型和描述的几个成本估算方法。本文总结了几类软件成本估算模型和技术。
介绍 |
| 软件成本估算是大多数软件开发的一个重要组成部分。不幸的是,软件开发成本估算困难和不准确的。尽管许多的可用性评估方法和指导方针,仍然有需要改进。降低成本估计误差的一个方法是通过分析成本估算错误,例如,通过评估过程的识别,导致更准确的估计。自1950年代初以来,软件工程成本模型和估计技术是用于许多目的。 |
| 这些包括预算、风险分析、项目计划和控制和软件改进和投资分析。近年来,软件已成为最昂贵的计算机系统项目的组件。准确的软件成本估算是开发人员和客户的关键。[7]对软件成本估算的研究开始独立的公司和军事组织,构建大型软件系统。他们可以用于生成请求建议,合同谈判、调度、监控和控制。低估了成本可能导致管理批准拟议的系统,然后超过他们的预算,不发达的功能和质量差,未能按时完成。软件成本估算的目的是: |
| 。[2]定义所需的资源生产、检验和验证软件产品,管理这些活动。 |
| 软件质量保证 |
| c。[1]量化,只要是实用,这个估计固有的不确定性和风险。 |
| d。试验台的开发 |
| e。开发环境支持 |
| f。软件系统级测试支持,包括开发和仿真软件 |
| g。管理和支持成本 |
| h。独立的验证和确认(IV&V) |
| 我。其他的评论或支持的指控 |
| 准确的成本估算是很重要的,因为: |
| 。帮助分类和优先发展项目对整个商业计划。 |
| b。用于确定哪些资源承诺项目以及将使用这些资源。 |
| c。用于评估变更的影响和支持重新规划。 |
| d。[3]项目可以更容易管理和控制当资源更好地匹配实际的需求。 |
评估方法 |
| 所有的成本估算方法是基于某种形式的类比:历史类比,专家判断,模型,等等,这些方法在生成过程中所扮演的角色取决于估计,一个是在整个生命周期。 |
| 历史类比估算方法是基于使用软件大小、成本或从过去类似项目的工作。当术语在本文档中使用类比,比较了使用措施或数据记录完成软件项目。类比估计可以在高水平使用软件项目规模和/或总成本对个人工作分解结构(WBS)类别在发展的过程中主要的软件成本估算。一般来说,有必要调整大小或历史成本项目,很少有完美的类比。特别是高层类比。[10]类比模型是最简单的类型的估计模型。他们是用来估计成本通过比较与过去类似的项目或项目一个程序,从而避免问题专家判断的偏见。类比法的优点是,它是基于经验的。然而,方法是有限的,因为在大多数情况下,类似的项目不存在。8使用由类比估算的步骤,描述项目; Selecting the most similar completed projects whose characteristics have been stored in the historical data base’ Deriving the estimate for the proposed project from the most similar completed projects by analogy. |
| 该方法的主要优点是,估计是基于实际的项目特征数据;估计量的过去的经验和知识可以使用不容易量化;完成和项目之间的差异可以被识别并影响估计。 |
| 使用这种方法,我们必须确定如何最好地描述项目。变量的选择必须限制信息可用时,所需的预测。可能性包括应用程序域的类型,输入的数量,数量的不同的实体引用,屏幕的数量等等。 |
| 即使我们有项目特征,我们必须确定相似性和多少信心我们可以类比。太少的类比可能导致特立独行的项目使用;太多可能导致的稀释效果最接近的类比。最后,我们必须得到一个估计的新项目使用已知的努力值的类似的项目。可能性包括方法和加权意味着这将给更多的影响进一步类比。 |
| 专家判断:[5]的大多数研究工作进行的软件成本估算领域一直致力于算法模型。然而,绝大多数专家的判断是最常用的估计方法。从本意讲专家判断方法需要与一个或多个本地专家咨询了解开发环境或应用程序域估计所需的努力完成一个软件项目。 |
| 方法在很大程度上依赖于他们的知识的经验在类似的开发环境和历史数据库维护项目和论文的准确性过去的项目完成。这种方法的优点是,专家可以因素差异过去项目的项目经验和需求;专家可以在项目影响因素引起的新技术、体系结构、应用程序和语言参与未来的项目,也可以在特殊人员因素和交互特点,等等这些缺点包括,这种方法不能量化;很难文档使用的因素专家或专家组;专家可能有些偏颇,乐观和悲观,即使他们已经减少了群体共识;专家判断法总是赞美等其他成本估算方法计算方法。 |
| 德尔菲方法或宽带德尔菲法试图收集一组专家的意见,目的是产生一个精确的无偏估计。是一个结构化的技术专家判断和本质上是一个基于表单的技术涉及多步过程:专家发布了规范和评估形式的协调员。 |
| 。一组会议,讨论产品和估计问题。 |
| b。专家产生一个独立的评估。 |
| c。估计返回表明中值估计和专家的个人估计。 |
| d。另一组会议讨论的结果。 |
| 修改后的独立估计e。专家们准备。 |
| f。重复3 - 6步,直至达成共识的专家小组。 |
| 德尔福估计过程的优势: |
| 个性。12自由的社会压力,影响,和个人优势 |
| b。允许参与者之间共享信息和推理 |
| c。有利于独立思考,逐渐形成 |
| d。被调查者面板提供了广泛的分析视角问题和问题 |
| e。可以用来达到共识组织互相敌视 |
| 德尔福估计过程的缺点: |
| 。判断所选的组,并可能不能代表主流意见 |
| b。倾向于消除极端位置和力中间派的共识 |
| c。比名义群体更耗时的过程 |
| d。需要的书面交流技巧 |
| e。需要足够的时间和参与者的承诺(可能需要30到45天完成整个过程) |
| 计算方法:计算方法旨在提供一些数学方程来执行软件的评估。这些数学方程是基于研究和历史数据并使用输入如源行代码(SLOC),函数执行,和其他成本动因,如语言、设计方法、技能水平,风险评估,等。基于算法的方法很大程度上是研究和模型已经开发的有很多,比如COCOMO模型,普特南模型,和基于功能点的模型。一般方法的优点,它能够产生可重复的估计;很容易修改输入数据,提炼和自定义公式;它是有效的,能够支撑一个家庭的估计或敏感性分析;经验是客观地校准。一般的缺点是,它无法处理异常情况,如异常人员在任何软件成本估算练习,优秀的团队合作,和一个特殊的技能水平和任务之间的匹配;可怜的大小输入和不准确的成本动因评级将导致不准确的估计;一些经验和难以量化的因素。 |
| 自底向上的方法,每个组件的软件系统是分别估计结果聚合为整个系统产生一个估计。这种方法要求是一个初始的设计必须到位,表明系统分解成不同的组件。这种方法的优点是,它允许软件集团处理估计在传统方式和处理估计组件组的有感觉;它更稳定,因为估计各种组件中的错误有一个平衡的机会。缺点是,它可能忽略的许多系统级成本(集成、配置管理、质量保证等)与软件开发;它可能是不准确的,因为必要的信息可能不是在早期阶段; |
| 它往往是更耗时;它可能不是可行的时时间和人员是有限的。 |
| 自顶向下的方法是相反的自底向上的方法。整体系统成本估算来自全球性质,使用算法或non-algorithmic方法。总成本可以分解各个要素之间的关系。这种方法更适合在早期阶段成本估算。这种方法的优点是,它侧重于系统级活动,如集成、文档、配置管理、等,其中许多可能忽略了在其他的成本估算方法和它不会错过系统级功能;它需要最少的项目细节,通常是更快,更容易实现。缺点,它经常不确定困难的低级问题可能升级成本,有时往往忽视底层组件;它没有提供详细的依据证明决策或估计。 |
| COCOMO(建设性的成本模型)模型[4]成本和进度的估计模型最初发表在[Boehm 1981]。它成为最受欢迎的1980年代的参数成本估算模型。但COCOMO 81年以及1987年Ada更新经历了困难估计的成本开发新软件生命周期过程和功能。COCOMO II研究工作开始于1994年在南加州大学非顺序解决问题和快速开发过程模型、再造工程,重用驱动的方法,面向对象方法等。COCOMO II最初发表在1995年的软件工程的年报(Boehm et al . 1995年)。模型三个子模型,应用程序组成,早期设计和Post-Architecture,可以以多种方式组合在一起,从而应对当前和未来的软件实践市场。COCOMO模型的主要吸引力是他们完全可用内部方程和参数值。十几个商业COCOMO 81年实现。 |
| 模型在实践中已经被广泛接受。cocomo的代码大小年代在千LOC person-month (KLOC)和努力。基本COCOMO模型简单,易于使用。不考虑成本因素,它只能作为一个粗略的估计。 |
| COCOMO模型是一个回归模型。它是基于63年的分析选定的项目。主要的输入是KDSI。[11]的问题是:在系统生命周期的早期阶段,规模估计的不确定性的价值。所以,不能到达准确的成本估算;出于这个原因,调整是必要的。 |
软件评估 |
| 软件项目计划包括的估计成本、资源、产品规模、进度、人员配备水平,和关键里程碑。软件估算过程中讨论以下步骤开发软件估计。建立在生命周期的早期这一过程将导致更大的准确性和可信度估计和一个清晰的理解的因素,影响软件开发的成本。这个过程也为工程人员提供了方法来识别和监控成本和进度风险因素。描述的估算方法是基于使用: |
| 一个多个估计。 |
| b。从历史经验数据驱动的估计 |
| c。风险和不确定性对估计的影响 |
| d。[8]不同评估方法可以使用不同的数据。这将导致更好的覆盖评估知识库的过程。它可以帮助识别成本组件不能处理或被忽视的一个方法 |
| e。不同的观点和偏见可以考虑和协调。竞争合同报价,高业务优先级来降低成本,或一个小的市场窗口与紧迫的期限往往乐观的估计。建立生产计划由开发人员通常是更悲观的一面,以避免犯一个不能满足进度和预算。 |
| 评估方法的选择: |
| 从上面的比较,我们知道13没有一个方法一定比另一种更好或更糟,事实上,他们的优点和缺点通常互补。根据经验,建议结合模型和类比或专家判断评估方法是有用的可靠、准确的软件开发成本估算。 |
 |
| 使用评估方法: |
| 很常见,我们应用一些成本估算方法估算软件开发的成本。但是我们必须注意的是,它是非常重要的不断重新评估成本和比较目标与实际支出在每一个重要的里程碑。这使项目可见的状态,有助于识别必要的修正预算和进度就发生。在每一个估计和re-estimation点,迭代是一个重要的工具来提高评估质量。估计可以使用几个评估技术和检查他们的估计是否收敛。其他的优势后,不同的评估方法可能使用不同的数据。这将导致更好的覆盖评估知识库的过程。它可以帮助识别成本组件不能处理或被忽视的方法;不同的观点和偏见可以考虑和协调。竞争合同报价,高业务优先级来降低成本,或一个小的市场窗口与紧迫的期限往往乐观的估计。 A production schedule established by the developers is usually more on the pessimistic side to avoid committing to a schedule and budget one cannot meet. |
| 也是非常重要的,比较实际成本和时间估计即使只有一个或两个技巧。它还将提供必要的反馈,在未来提高评估质量。一般来说,成本估算的历史数据基础应该建立以备将来使用。 |
| 识别评估过程的目标是非常重要的,因为它将影响花在评估工作,其准确性,所使用的模型。紧张的时间表与高风险需要更精确的估计比松散定义的项目相对开放式的时间表。估计应该在数据估计所依据的质量和在各种目标。 |
结论 |
| 软件成本估算是简单的概念,但在现实困难和复杂。成功所需的难度和复杂性估计超过大多数软件项目经理的能力。因此,手动估计不能满足大型应用程序。本文介绍了一些软件估算技术的概述,提供目前几种流行的估计模型的概述。从本文的重要教训是,没有人应该优先于所有其他方法或模型。寻找可靠、准确和低成本估算方法必须继续下去。同时,需要更多的研究来改善维修项目成本估算的准确性。结论是,没有一种技术是最适合所有情况,,仔细比较几种方法的结果是最有可能产生现实的估计。 |
| 一些建议: |
| a。不依赖于单一的成本或进度估计。 |
| b。使用几个估计技术或成本模型,比较结果,并确定任何大的变化的原因。 |
| c。文档时所作的假设估计。 |
| d。监控项目——估计的准确性。 |
| e。有效的软件过程可以用来增加成本估算精度的方法。 |
| f。保持历史数据库 |
引用 |
|