|
项目估算通常不会考虑在应用系统生命周期内的维护任务的估算问题。但是对软件进行维护的费用往往又会超过其他应用开发的费用。软件维护通常定义为在提交之后对软件所做的修改，比如纠正错误，提高软件性能或者其他属性，以及根据改变后的环境对产品进行升级等。实际经验表明，IT系统的生命周期通常比预料的要长。常用的做法是将维护所需的费用计算在系统生命周期之内，而对费用的总量不加以控制，并且也不区分各种费用之间的区别。结果往往是如同一个在超级市场购物的顾客结账时惊讶地发现，购物篮（我们可以将其比作软件维护的需求）中一些本来很便宜的货物算在一起居然是一个很大的数目。但遗憾的是，软件维护中的任何需求又都不能从“购物篮”中丢出去（如同在超市购物时不能够舍弃某些生活必需品一样）。项目管理者联盟 需要强调的是，IFPUG（International Function Point User Group，国际功能点用户群组）定义认为，软件维护并不会改变一个应用系统的功能。如果维护中改变了系统的功能，则该应用系统就应该被一个升级版本所代替。 项目管理者联盟 1.1 UKSMA和NESMA标准项目管理者联盟 软件维护测量中所用到的标准除了ISO 14764标准中的“软件工程——软件维护”部分之外，UKSMA（United Kingdom Software Metrics Association，英国软件测量协会）和ISBSG（International Software Benchmarking Standards Group，国际软件基准测试小组）在2001年7月联合发布了UKSMA质量测量标准系列中的“测量软件维护和支持”0.5版草稿[UKS]，该标准可以从http://www.uksma.co.uk下载。 bbs.mypm.net 该标准指出了软件维护、支持与操作之间的区别（见表1）。 项目管理者联盟  项目管理者联盟
该标准的目的是定义一些度量，从这些度量中可以派生出23种度量单位，比如：
生产率：功能点/人年；
1、小规模升级的部门比率：（每个部门）为小规模升级而付出的维护和支持比率；
2、小规模升级比率：小规模升级的部门比率除以小规模升级的维护和支持工作量的总和，以百分比表示。 项目管理者联盟 2001年，NESMA（Netherlands Software Metrieken Gebruikers Associatie）发布了软件升级功能点分析手册1.0版本（NES），其中（考虑特殊影响因素而）使用所谓的测试功能点（TFP）和升级功能点（EFP）来计算包括测试（E）在内的总的升级工作量，如下：
E=(EFP*小时/EFP)+(TFP*小时/TFP) 项目管理培训 1.2升级项目管理者联盟 维护是一个应用系统升级的必要组成部分。ISBSG在2002年6月发布的[ISB]资料库7中，40.7%（791个项目中的322个，参见23页）属于升级项目。在第32和34页展示了有关IFPUG 4.0 [IFP4.0]功能点数量的详细细节，如下：项目管理者联盟  项目管理者联盟
 项目管理者联盟
同时还需要记住的是，根据IFPRUG 4.1规则定义，软件维护并不改变系统在功能点上的规模，如果改动了系统规模则不属于维护，而是属于软件升级。项目管理者联盟 1.3软件维护的度量pmp.mypm.net 仍然可以根据类似于超市购物的思想对软件维护的工作量估计进行度量。目的是要找出度量标准和原始数字，以便于确定在什么时候用于软件维护的工作量会超过开发一个新的系统的工作量。通常情况下，人们不会象对其他的产品或者货物那样考虑软件的时间寿命，因而也就认为对软件的维护和再次开发做一个预防计划是不必要的。项目管理者联盟 在一些从事度量研究的团体中有一种广泛共识就是软件生产率尤其依赖于软件规模，并且同时还受到其他一些参数的影响。软件维护的工作量同样也是如此。Cocomo-M模型[BOE]和SLIM都只使用一个与维护工作量有关的参数，而PRICE-S, SEER-SEM和Capers Jones的估算工具Checkpoint却使用好几个这样的参数。与维护相关的参数在Abran et al.所发布的2002 [ABR-S]中进行了总结，如下：项目管理者联盟 1、应用系统的类型
2、程序设计语言
3、软件寿命
4、现存文档的质量
5、进行完整系统测试的必要性
6、资源可用性方面的约束
7、功能复杂度
8、技术复杂度
9、可重用程度talent.mypm.net 这一领域的研究主要从两个组织中进行，其中一个组织考虑了涉及功能修改的15个软件维护的项目，另一个组织考虑了19个软件维护项目。结果表明在软件规模与维护工作量之间的确存在一种明确而又微弱的关联。回归分析表明其他一些因素同样也会影响软件维护的工作量，并且表现出一种2次指数关系（R2 =0.85和0.87）。在基于web开发环境的组织中，软件维护任务的平均规模是军用开发组织的四倍，而维护任务的工作量却只是其两倍。因此，在基于web开发环境的组织中每一项维护任务的平均工作量（大约115人工作时）只是军用软件开发环境中的一半（大约221人工作时）。项目管理者联盟 Abran 和Robillard [ABR-R]在1996年报告了大约21个带有大量功能升级的管理信息系统（MIS）的软件维护项目。这些项目的平均工作量为2200人工作时或者332人工作日。从这里可以发现规模与工作量之间的一种统计关系（R2 =0.81）。数据来自于一个软件开发组织，该组织以能够及时地在费用预算内提交功能和质量都满足要求的一流项目产品而闻名。该组织在1990年初就已经达到了CMM3的成熟度等级，并且有明确证据表明实现了等级5上的定量管理KPI（关键执行指示器）。项目管理者联盟 Abran 和 Nguyenkim [ABR-N]在1993年对一个具有完备数据和工作量记录的组织进行了专门研究。所涉及的软件项目大都是一些较小的维护任务，一般只需要一个人即可完成。每项任务的平均工作量是37小时，其中工作量最小的是27小时，最大的是52小时。项目管理者联盟 Horst Zuse [ZUS]收集了如下一些可以用来对维护任务进行估算的度量标准：bbs.mypm.net 1、提交后所发现的错误数量。一般情况下，测量在提交后的六个月之内进行。
2、改动或者改动需求的数量。
3、错误搜索和纠正的工作量。
4、每个功能点所记录的错误数量。
5、到错误发生时的运行时间。
6、软件成熟度指数，即SMI。SMI可以定义为实际发布的模块/功能点数量（R）与以前发布的版本中改动、添加和删除的模块/功能点数量（P）之差，然后再用这个差值除以实际发布的模块/功能点数量：SMI = (R – P) / R项目管理者联盟 列表中还可以加上下面一条：项目管理者联盟 在所安装的每个功能点上进行维护所花费的工作时数量。如果这个数量非常高，就应该考虑重新构件和开发软件系统。项目管理者联盟 通过以上各条我们可以得出结论：对软件维护工作量和错误报告进行计算应该考虑有错误的模块，并且需要提交与升级的模块/功能点有关的信息。这样的从相关数据中收集的度量和结果对于组织未来的软件维护任务估算才是有用的信息。blog.mypm.net
|
