软件项目进度计划估算探讨

    对软件项目做开发计划也许是最不靠谱的一件事了，由于需求的变动、开发人员的水平以及如人事变动等不可预测的情况，导致项目的延期成为了家常便饭。而现在的项目管理人员往往是凭经验来制作进度计划的，经验的确很重要，也是项目进度估算一个不可或缺的基础条件，但仅仅凭经验来做计划也会产生以下的一些问题：

创新互联建站于2013年创立，公司以成都网站制作、做网站、系统开发、网络推广、文化传媒、企业宣传、平面广告设计等为主要业务，适用行业近百种。服务企业客户上千，涉及国内多个省份客户。拥有多年网站建设开发经验。为企业提供专业的网站建设、创意设计、宣传推广等服务。 通过专业的设计、独特的风格，为不同客户提供各种风格的特色服务。

    1、对项目的理解不同，每个项目管理人员的开发经历与项目经历都是不同的，你有你的计划方法，我有我的计划方法，不同的人对同一项目做计划时可能对于人员的安排与项目的完成日期的分歧会很大。所以如果碰到中途换人的情况，那软件进度计划这个事就说不清楚了。

    2、漏掉必须完成的需求，如果项目管理人员每次都凭经验来对项目做计划，那么当项目规模变得很大时，势必会遗漏一些需求的细节，而这些致命的细节往往会在设计后期或开发后期才会知道，严重的可能导致整个软件架构重构。

    3、没有一套模型，项目管理人员仅凭经验来做计划是会缺少依据和可追溯性的，虽然对于每个任务时间的估算大部分情况是靠管理人员的经验与开发人员的承诺，但任务之间的顺序安排，任务之间的依赖关系，人员数量对项目开发效率的影响是需要一套方法来描述清楚的。而可追溯性则表现为为什么我要这么安排的层面上。

    为了解决上面的一些问题，我们需要引入一套模型（可以理解为一种思想）来完善我们的进度计划估算工作。这里，我以一个简单的B2C系统作背景，描述其中的一些主要模块，与大家一起探讨下如何为一个web软件项目的开发做计划。        

    首先，当然是要明确我们需要做什么，也就是确定需求。我们的需求及用例是这样的：

        用户操作

            注册：用户注册为网站会员。

            登录：用户登录网站，登录后能购买产品，查看相关用户资料。

            加入购物车：用户将产品加入购物车后可一起支付购买。

            购买（生成订单，支付）：付款及生成订单。

            查看/修改用户资料：通过用户资料页面查看/修改用户资料。

            查看购物车：看看准备买的东西。

            查看订单：看看已经买过的东西。

用户用例

    管理员操作

        产品

            操作产品（操作指增、删、改操作）：添加、修改、删除提供给用户购买的产品。

            操作产品所属厂商：添加、修改、删除产品所属的厂商。

            操作产品属性：添加、修改、删除产品的属性。

            操作产品类别：添加、修改、删除产品的类别。

        配件

            操作运送方式：添加、修改、删除提供的运送方式，如是顺丰还是UPS。

            操作国家地区：添加、修改、删除国家/区域，网站国家区域不同，收税也不同。

            操作语言：添加、修改、删除网站支持的语言，如中文和英文显示。

            操作税：设置税的类别，不同的产品可以附加不同的税费。

            操作系统设置，如设置商店名称等：网站的全局设置。

            操作货币：设置用户支付的币种。

        用户

            操作用户：添加、删除、修改用户资料。

            操作用户组：添加、删除、修改用户所属的用户组，不同用户组的用户在购买商品时享受的折扣不同。

        报表

            操作订单报表：添加、删除、修改、查询用户订单。

管理员用例

    通过用例，我们可以提炼出业务对象：

        1 用户

        2 用户组

        3 产品

            3.1 产品分类

            3.2 厂商

            3.3 产品属性

        4 订单

        5 配件

            5.1 国家

            5.2 语言

            5.3 物流

            5.4 税

            5.5 货币

            5.6 支付方式

    在确定业务对象后，我们需要知道每个对象的具体职责和用例的基本执行流程，可以用活动图来达到这个目的。

    活动图显示了核心用例购买商品的基本流程，从图中可以发现，要完成购买用例，我们必须先建立“产品对象”，“物流对象”，“支付方式对象”，“交易对象”，“订单对象”。“购物车对象”由于是可选步骤，所以可以单独建立。

    物流对象、交易对象、支付方式对象，是比较独立的对象，没有依赖。而要建立产品对象，购物车对象，订单对象都是有先决条件的。下面我们来依次分析这几个对象。分析的依据就是我们的用例图。我们可以利用表格来表达我们的分析结果：

    从上表可知对象间的相互关系。那么，在开发过程中，我们将从简单对象，也就是没有依赖项的对象开始设计，然后再来设计复杂对象。简单对象可以并行设计，也可依次设计，视具体人员决定。根据业务对象表，我们可推导出出版的关键路径图。如下图所示：

点击此处查看图

    上图初步的展示了开发步骤，在理想状态下，独立对象可以同步开发，依赖对象在前置对象开发完成后再开发。图中的虚线箭头表示隐性依赖，意思是在此期间并没有实际的任务在做，而只是表达一种依赖关系，表明在进行箭头后任务之前，必须完成箭头前的任务。但从图中我们也发现了，还没有计划安排开始时间及完成时间，每个任务的持续时间也没有计算出来。所以下面我们来开始估算每个任务的开发时间。

    对于任务时间的估算，有一种称为功能点的估算方法。下面来详细介绍下这个估算方法，请看下面的两个公式：

        未调整的功能点数 = a1 x Inp+ a2 x Out + a3 x Inq + a4 x Maf + a5 x Inf

        技术复杂性因子（TCF） = 软件技术因素对软件规模的综合影响程度(DI) x 0.01 + 0.65

        DI = ΣFi

        1<=i<=14

        F最小取值为0（对软件规模无影响）， 最大取值为5（对软件规模有很大影响）

        功能点数（FP） = 未调整的功能点数 x 技术复杂性因子

        Inp为输入项数，指用户向软件输入的项数，a1为它的系数。

        Out为输出项数，指软件向用户输出的项数，a2为它的系数

        Inq为查询数，指软件执行数据查询，如得到产品信息就是一个查询，a3为它的系数。

        Maf为文件数目，a4为它的系数。

        Inf为机器可读的接口数，如磁盘上数据文件的数量，a5为它的系数

        利用Albrecht & Gaffney 模型

        工作量 = -13.39 + 0.0545 x FP

        利用Maston, Barnett 和 Mellichamp模型

        工作量 = 585.7 + 15.12 x FP

        工作量单位为人/月

    从上面的公式可以看出，利用不同模型推算出来的工作量差别很大。实际上，没有一种模型能精确的推算出所有的软件项目工作量，多数只是根据若干应用领域中有限个项目的经验数据推导出来的。所以我们在计算时，完全无需照搬模型的算法，而是应该吸收模型所代表的思想。所以，下面我们试着用调整过的公式来计算下每个业务对象的功能点数以及工作量。

    在我们自己的计算中，打算去掉Maf与Inf这两个参数。所以，未调整的功能点数 = a1 x 填写表单数+ a2 x 数据操作数。对于简单对象，a1取值4，a2取值5。对于复杂对象，a1取值8，a2取值10。a在这里代表一个人完成任务所需要的小时数。其中，订单对象，产品对象为复杂对象，其它对象为简单对象，由于支付方式、运送方式是涉及到对外API实现，购物车是不存在填写表单与数据操作的，所以需要另算。在计算DI时，我们取平均F为1.5，代表技术因素对软件规模影响不大。则技术复杂因子=14*1.5*0.01+0.65=0.86。

    填写表单数对用户或管理员填写的表单进行统计，如用户注册需要填写一张表单，查询需要填写一张表单。管理员添加用户需要填写一张表单，修改用户也需要填写一张表单。

    详细统计请看下表：

    由此算出，除开购物车，支付方式，运送方式三个业务对象的开发，估计需要约416小时。按一天8小时计算，需52人/天，购物车的难度介于复杂对象与简单对象之间，可以取35。单个支付方式与运送方式，因为可能需要对外联调，所以难度可能相当于复杂对象，可以取50。所以如果该系统支持单个支付方式与运送方式，则全部业务对象估算需要416+35+50+50=551小时≈69人/天

    理论上，参与开发的人数越多，则软件开发速度越快。但事实上，随着项目规模的扩大，开发人员之间的通信开销也为之增大，所以个人生产率将会下降，以至于开发时间与从事开发工作的人数并不成反比关系。如果在项目过程中有老员工的离职与新员工的加入等情况，则更会加剧项目的延迟。

    假设有P名开发人员，则项目组成员间的通信路径的范围在P~P2/2之间，因为如果项目组每个成员都必须与其他成员沟通，那么通信路径是P(P-1)/2，而如果项目组每个成员只需与一个同事沟通的话，那么通信路径将是P-1。由此我们推导出项目总生产率的公式为

        Lsum = P(L-l(P-1)的r次方)

        L为单个成员理想生产率（不与任何其他成员通信时的生产率）

        l为每条通信路径导致生产率减少量

        r为对通信路径的度量，如每个成员都必须与其他所有成员通信，则r为1

    根据此公式计算，一般项目成员在3~5名的时候总生产率与成本将达到一个比较理想的状态。由于在这个例子中的业务对象较少（当然，在现实项目中，开发过程不仅仅只有业务对象，还有数据结构设计、模板设计、环境部署等一系列的工作，而这些工作可能还需要与不同小组的同事沟通协调），所以我们假定项目组成员有3人进行业务对象的开发。

    现在我们得到了总的工作量为69人/天，开发人数为3人，那么大概此项工作的全部时间为1个月。所以我们可以按1个月（22天）来安排工作了。根据工作量的估算，我们先为每个人安排工作，设员工为A, B和C则

        A负责: 产品类别/24.08， 产品厂商/28.38，产品属性/24.08，购物车/35，产品/56.76，语言/24.08 192.38

        B负责: 支付方式/50，运送方式/50，货币/24.08，国家/区域/48.16  172.24

        C负责: 用户/42.14，用户组/24.08，税/48.16，订单/72.24  186.62

        按每个员工的职责来重新绘制网络工程图，如下所示：

点击此处查看图

    至此，我们确定了工程的关键路径及具体每个任务的开始结束日期，而开发组成员的具体工作任务也分配好了。

    在实际的开发工程中，我们不仅要确认每个业务对象的具体任务，还有如数据对象的确认（从数据对象映射到数据结构），环境的配置，单元测试等一系列的工作，这些工作都可以用网络工程图的形式来确认相互的完成顺序与完成时间，并且网络工程图还可以等价转换为更加直观的甘特图来表示，从而对我们的项目的进度计划提供指导与依据。