关于改造项目规模估算的解决方案 _改造

我们一起来看看改造项目的特点和估算策略。
改造项目的特点：
一是改造项目在业务需求、程序代码、程序架构等方面有一定的继承性；
二是改造项目的内容一般包括新研、改造、沿用和删除等4部分；
三是改造项目的研发难度与原应用程序代码的架构、编程语言、编程规范、注释详细程度等因素密切相关。
改造项目估算的策略
一是分别确定改造项目的新研、改造、沿用和删除等4部分内容，确定其估算范围；
二是重点是对改造、删除的功能点进行估算，新研部分按新研项目估算，沿用部分不估算；
三是由于改造和沿用部分的边界容易存在交叉，且改造项目的影响因素较多，在使用功能点估算的基础上，可按项目开发团队人数、开发周期测算人月数，对结果进行交叉验算。
【关于改造项目规模估算的解决方案】小编：改造项目的功能规模估算，核心问题就是改造、删除的功能点如何估算？
关于删除部分的功能点计数：关于删除部分的功能点，小编觉得在一般项目中可以忽略。例如，一个模块的功能规模是200个功能点，根据新的改造需求，这部分内容全部删除，那么这部分的工作量按200计算肯定是不合理的。而且，现在的应用程序大多都是基于面向对象的语言进行开发，每个模块的代码都是独立存在，删除一些功能的时间和整个改造项目来比，是可忽略的。在特殊项目中可以视情况进行折算，例如，某个改造项目就是删除一部分功能。
小编：我们来重点分析下改造部分功能规模该如何估算？是按新开发项目来估算还是引入调整系数进行折算？应该引入调整系数，结合项目情况，确定调整系数的权重后，折算改造部分的功能点数。
小明观点：一是改造项目在业务需求、程序代码、程序架构等方面有一定的继承性，能够减少工作量的投入；二是改造项目相比于新研项目，在策划、需求、设计阶段的工作量投入要小，编码、测试、部署可以认为差不多，策划、需求、设计三部分的工作量一般占项目的比率为38.27%（详见下表）。综合考虑，改造部分可按0.7~1的比例系统进行调整；三是软件改造单位若是原先的研发单位，那么对软件架构和程序代码都有一定基础，在实际开发过程中效率相对较高。同时，用户在软件使用方面有一定的经验后，对软件功能有比较好的理解，能够提出更为准确的需求，对比新研项目有很大优势。

文章插图
小王：改造部分可以按新开发项目进行估算。理由如下：一是由于原应用程序代码的架构、编程语言、编程规范、注释详细程度等因素的影响，改造项目也有很多难点；二是在改造过程中，需求对原程序的代码和架构进行分析和理解，需要花费程序员的大量时间；三是改造项目，同样有策划、需求、设计的工作，只是相对于新软件而言，略微有所减少，可以忽略不计。
小明和小王的观点对比分析
小明和小王的观点都有道理，A同学引入0.7~1的调整系数，可以更佳灵活处理此类问题。B同学的观点适应于一部分改造项目，比如，改造单位不是原软件研发单位、软件需要跨操作系统平台改造、原项目没有完整的原代码、编程语言需要更换等等类似情况，改造的工作量与新研差不多。但所有改造部分按新开发估算，对甲方容易产生不公平。
小结：小编倾向于A同学的观点，引入0.7~1的调整系数，更佳灵活。
重点提醒：由于改造部分和沿用部分的边界容易存在交叉，且改造项目的影响因素较多，在使用功能点估算的基础上，可按项目开发团队人数、开发周期测算人月数，对结果进行交叉验算，综合测算得出较合理的功能规模。
总结：在实践估算工作中，建议引入0.7~1的调整因子，结合项目实际情况，甲乙双方协商确定系数权重，有利于解决改造类项目的功能规模估算。