当前位置：文档库 › 常见B-S应用系统功能开发工作量评估参考

常见B-S应用系统功能开发工作量评估参考

[工作量评估参考]

B/S应用系统

常见功能模块工作量评估参考

广州市欧科地理信息技术服务有限公司

工作版本变更信息：（注意：以下为项目组人员填写部分。）

1文档目标 (4)

2工作量评估单位 (4)

3工作量评估准则（任务估算法） (4)

4工作量评估前提 (4)

5常见系统功能模块 (4)

6工作量评估分析（三层架构开发模式） (5)

6.1普通功能模块 (7)

6.1.1普通功能模块增加页面 (7)

6.1.2普通功能模块列表页面 (8)

6.1.3普通页面编辑/明细功能 (9)

6.2复杂系统功能模块 (10)

6.2.1复杂系统功能添加页面(认证系统) (10)

6.2.2复杂系统功能列表页面(认证系统) (15)

6.2.3复杂系统功能编辑/明细页面（认证系统） (15)

6.3组织结构树控件 (17)

6.4分析报表 (18)

6.5接口文件（WCF） (19)

6.6动态组装的列表数据 (19)

7工作量评估分析（开发平台） (20)

7.1常见功能模块开发工作量估算（客户资料管理） (21)

8工作量评估分析（https://www.wendangku.net/doc/3b14127186.html, + ENTITYFRAMEWORK） (22)

1文档目标

介绍自己在项目工作量评估的经验，并描述了常见系统功能模块的工作评估。为各位项目经理/系统架构师/系统开发人员等提供系统开发量评估的一个参考。

2工作量评估单位

工作量评估单位：人/天

工作点计算参考基准单位：UP(针对UI部分的元素使用)

DP（数据列）

TP(数据表)

CP(逻辑处理复杂点数,直接和时间进行关联)

3工作量评估准则（任务估算法）

系统工作量评估（任务估算法）是把软件项目系统功能采取逐层分解,将其细分到一定层次的模块功能。再分别估计完成每个功能模块需要的人员搭配比例及投入时间，每个人员的工作量之和就是该功能模块的工作量。最后将各个功能模块的工作量加起来就得出软件项目的总开发工作量。像传统的B/S应用系统，建议将系统的模块功能细分到3到5层之间，最好能具体到页面级别的模块功能。

设计各个岗位人员工作量可基于以下标准计算

（1）以程序员的工作量为标准；

（2）高级程序员的工作量为标准工作量的1.5倍；

（3）系统分析员的工作量为标准工作量的2倍；

（4）系统架构师的工作量为标准工作量的2倍；

（5）测试工程师的工作量为标准工作量；

（6）高级测试工程师的工作量为标准工作量的1.5倍；

（7）项目管理人员的工作量为标准工作量的2.5倍；

4工作量评估前提

文档介绍的工作量评估是在系统需求已经明晰，系统概要设计以基本完成。并且数据模型已经创建好的基础之上。

5常见系统功能模块

普通系统功能模块的增加/列表/编辑明晰页面。（用户增删除功能）

复杂的系统能模块的增加/列表/编辑明细页面。（订单数据增删除功能）

组织结构树控件

图表控件

接口文件（WCF）

动态组装的列表数据

6工作量评估分析（三层架构开发模式）

根据个人的工作经验。系统开发的工作量和系统采用的开发框剪是是密不可分的。系统的开发工作量主要是根据项目的功能需求和系统所采用的框架，并结合自己之前做类似项目的经验对系统的开发工作量进行评估。

对于软件开发，采用不同的开发框架/方式，由于系统实现的方式不同，开发过程中主要耗时间的地方也会有所不同，所以使用的评估方式是不一样的。以普通三层架构开发模式为例。系统开发的工作量（基于开发人员已经清楚系统需求并且数据库表已经设计并创建好）主要集中在UI页面和数据逻辑处理两个方面。工作量评估所涉及到的参考元素见下面的工作量评估关联图。

系统工作评估的流程如下：

1.0根据系统的功能需求，整理出系统功能模块。可以根据实际情况对功能模块进行细分。

例如一级模块、二级模块、三级模块等。

2.0根据功能模块，整理出其需要用到功能页面。

3.0根据系统功能页面，分别从页面的UI组装和逻辑代码处理两个层面进行工作量评估。

4.0系统功能页面的工作量评估，像普通的功能页面，主要是从页面中用到的页面元素进行

考虑。例如一个添加页面，其输入框有多少，需要进行JS校对数据合法性的元素有多少。假设一个普通页面元素的工作量单位为1UP，则下拉列表或者弹窗页面的工作量为2UP，用户自定义控件为2UP。对于有使用JS校对的页面元素，开发量加一UP.

对于页面个性化处理的复杂度则需要根据实际情况进行判断。例如一些交叉列表数据：

5.0系统逻辑处理。主要是考虑数据处理部分的工作量。根据数据处理所涉及到的字段和数

据表/视图/存储过程。为了评估逻辑处理的开发量，这里定义两个评估单位。DP：数据列、TP:数据表。其中数据列包括检索数据列和过滤列.对于一些个性化的逻辑处理，则根据具体的情况进行评估。

6.0数据库配置，主要是为列表页面提供数据支持。这部分开发量主要体现在视图用到的表

和数据列. 假设一个数据列的开发量为1DP,一个数据表的开发量1TP.

7.0模型配置部分的开发量通常比较小，可以忽略不计。

通常，像一个页面UI部分的工作量<=50UP,逻辑处理开发工作量<=30DP 和<=5TP。一天内能完成功能制作，调整和测试。

为了将UI的工作量和逻辑处理的开发工作量转为具体的人/天。我们整理一个粒度更小的单位。人/小时HP.

逻辑部分的开发工作量和HP之间的转换

6.1普通功能模块

6.1.1普通功能模块增加页面

普通数据增加页面，以客户管理为例子。整个页面只是简单的数据录入。其开发工作量主要是耗费在页面的输入框制作、页面数据校检。逻辑部分主要耗费的时间主要在于将输入框的数据转到数据存储模型，并调用保存方法。录入界面如图：

其中UI所涉及的普通控件为8个，多选的控件7个，自定义控件为2个（客户归属控件和区域选择控件），需要数据合法性校对的控件为3个。则UI的工作量为29UP。数据逻辑部分的处理主要是针对数据库表USER,操作的列包括20个列。

合计其总的开发工作量为

UI:29UP

逻辑处理：1TP + 20DP

所以这个页面在0,5—1天内能完成开发。

6.1.2普通功能模块列表页面

普通数据列表页面，以客户列表为例子。整个页面包括功能导航、搜索框、功能操作按钮、数据列表和分页控件。页面开发工作量主要是耗费在页面的输入框制作、页面列表呈现内容列组装。逻辑部分开发工作量主要在于搜索条件处理和数据读取操作。

系统UI部分的组装包括搜索框中一个自定义控件，列表中12个数据列，一个分页控件，5个操作按钮. 功能的逻辑处理主要包括三部分一个是删除功能，一个是数据组装事件，一个是分页事件。删除功能针对一个客户表的标识字段进行数据处理，涉及一个客户表和一个数据列处理。数据组装处理涉及一个客户数据视图、6个数据列和两列数据检索列的处理，其开发工作量为1TP + 6DP+2DP。数据配置，主要是数据列表视图的配置，它包括客户、团队和区域三个数据表。以及数据呈现所需要的12个数据列以及客户和团队两个数据表的标识列。最后统计整个页面的开发量如下：

UI开发工作量：2UP + (5UP +12UP) +2UP +5UP = 26UP

逻辑处理工作量：6DP +2DP+ 1TP

数据配置工作量：12DP +1TP

所以整个页面的开发工作量也在0.5—1天之间。

6.1.3普通页面编辑/明细功能

普通数据编辑/明细页面，以客户管理为例子。整个页面只是简单的数据录入。其开发工作量主要是耗费在页面的输入框制作、页面数据校检。逻辑部分的工作量主要包括一个初始化的数据绑定和一个保存事件的数据处理功能。录入界面如图：

其中UI所涉及的普通控件为8个，多选的控件7个，自定义控件为2个（客户归属控件和区域选择控件），需要数据合法性校对的控件为3个。则UI的工作量为29UP。数据逻辑部分主要包括数据绑定和数据保存。其中绑定的数据包含20个控件的数据绑定。数据保存也包括一个表/实体的20个列/属性的处理。工作量合计为1TP+40DP .所以这个页面在0,5—1天内能完成开发。

6.2复杂系统功能模块

复杂系统功能模块，这里主要是包含子从(1:N)关系的数据处理.例如常见的订单管理系统.一个订单中包含了多个销售明细项.本节文档主要以一个针对经销商提供认证管理的系统进行说明。其中经销商的认证消息包括用户基本资料和经销商相关的网店和实体店信息的认证。

6.2.1复杂系统功能添加页面(认证系统)

认证系统的添加页面主要由基本数据录入区域、网店和实体店录入区域组成。其中对于网店和实体店信息的添加是以新开窗体的形式进行录入。整体功能见下图：

认证系统通过新开的窗体的形式录入网店/实体店的信息。信息确定后，将网店/实体店的信息显示到添加页面中的实体店/网店信息列表。（其间对于网店/实体店的数据可以根据用户的使用习惯缓存到页面的VIEWSTATE或者页中某个隐藏标签）。用户填写好所有数据后，一次性将数据提交到服务器。服务器将对数据采用事务的处理形式，以保证数据的完整性。

整个页面的系统开发量主要包括UI部分的制作和逻辑数据的处理：

UI部分的功能主要包括4个普通的页面控件、一个多选列表控件、一个用户自定义控件（区域选择）、一个上传控件、两个列表区域控件和一个提交按钮。每个列表区域控件都对应新增和删除两个按钮。其中网店列表控件包括4列数据，实体店数据列表包括6列。对应的页面制作功能点为4UP+2UP+4UP+2UP+2*2UP+(5UP +4UP)+(5UP +6UP)+1UP=37UP。由于页面功能中涉及到两个页面之间的数据交互，这将增加页面处理的复杂度大概在5到10UP之间。最后得整个页面UI制作的工作量为27UP + 5UP + 5UP =47UP

整个系统逻辑部分的处理，包括实体店列表数据处理，网店数据处理，认证信息数据处理。实体店列表数据的处理涉及到一个实体店实数据表和三个数据列的处理。网店数据处理涉及6个数据列和一个网店表的处理.认证基本信息处理包括6个数据列和认认证资料表的的处理。整个页面的逻辑处理涉的工作量为3TP + （3+6+6）DP.

到目前为止整个页面设计的工作量为：UI制作37UP

逻辑处理:3TP +15DP.

在系统的逻辑处理中，我们忽略了一些工作量的计算。其中包括对网店数据和实体店数据的暂存处理，图片上传处理及认证系统数据存储复杂度的考考虑。认证数据存储的过程如下：

其中不但包括了事务的处理，在数据存储到数据库前还得进行预处理。实体店和网店信息必须调整其关联的认证标识再存储到数据库中。整个功能的逻辑复杂度估计得增加一天的开发工作量。

最后得到整个页面的开发工作量大概在2天左右。

6.2.2复杂系统功能列表页面(认证系统)

复杂系统功能列表页面的制作尽量避免涉及到数据子表中的数据。这样能大大降低开发的工作量。像上述的认证列表页面包括：3个搜索条件元素，两个按钮。一个列表区域，列表包括8个数据列和一个分页控件。UI制作工作量为3PU + 2PU +(5PU+ 8PU) + 2PU=20PU 系统逻辑处理的工作量包括：

列表数据处理：涉及一个认证表数据的查询，和两个过滤列的处理。

分页控件数据处理：涉及一个认证表数据的查询，和两个过滤列的处理。

逻辑处理总工作量：1TP +2DP + 1TP + 2DP = 2TP + 2DP

则系统开发总工作量为：15UP + 2TP + 2DP 整个页面的制作大概在0.5天左右。

6.2.3复杂系统功能编辑/明细页面（认证系统）

系统UI部分的工作量主要包括：

经销商的数据呈现，包括10个基本显示控件（LABLE）和一个图片控件。一个网店列表，包括三个数据列。一个实体店数据列表包括5个数据列。

整个UI的开发工作量为：10UP +2UP + 5UP+3UP +5UP+ 5UP =30UP

逻辑部分的工作量：

基础数据绑定：涉及一个实体数据（视图）的获取处理、一个过滤数据列（标识列）处理和11个用于呈现的数据列。其中视图的配置又涉及到三个数据表（区域表和认证基础信息和经销商信息表）以及11个数据列。

网店数据绑定：包括对网店表以及4个数据列（其中一个为数据列）的数据获取。

实体店数据绑定：包括对实体点列表以及6个数据列（其中一个为数据列）的数据获取。

认证信息停用处理：涉及到认证表和标识列和认证状态列的处理。

认证通过处理：涉及到认证表和标识列和认证状态列的处理。

认证不通过处理：涉及到认证表和标识列和认证状态列的处理。

总的开发工作量为：（1TP + 1DP +11DP +3TP+11DP）+ (4DP +1TP) + (6DP +1TP) +(2DP+1TP) + (2DP+1TP) +(2DP+1TP)=9TP + 39DP

整个页面的制作工作量在1到2天之间。

6.3组织结构树控件

组织结构树在UI处理部分的开发工作量比较小，主要就是对TREEVIEW的使用。其主要的开发量集中在系统数据的逻辑处理。

逻辑处理部分，如果目录树是一次性加载其所有目录节点，相对比较好处理。常见的加载流程，先加载顶层的目录树节点。然后递归地加载其所有的子目录节点数据。类似这种处理必须有相应的缓存机制。第一次加载目录树后，将目录树数据进行缓存。以后有涉及到目录数信息更新的，动态同步缓存中的目录树结构。

像这种只涉及一种维度的递归处理，和对应的混存处理。一般会交由高级开发人员制作，开发时间为1-2天，即开发工作量为1.5到3人/天

如果目录树采用动态更新的方法。目录树初始化时只是加载第一层的目录节点，当点击某一个目录节点时，动态加载目录下一级别子节点的相关数据并组装为其子目录节点。类似这种制作，又将增加相关的开发工作量。高级开发人员的开发时间估计为2天/人，即基本单位的3到4人/天

6.4分析报表

页面图表的开发工作量主要是在图表数据源的处理。目前图表的开发一般分两种形式。一种是通过第三方的报表平台进行开发和集成。其中主要的开发工作量是报表数据源的配置，报表的设计。一种是程序员自己编写获取数据源的代码，并将其绑定到一些图表控件中。例如某公司，根据资产的类型和年度资产投入分析，产生其走势图，如下图：

使用报表控件组装该图表，其处理流程如下：

1.0组装呈现数据。假设各类资产投入数据存储在一个资产登记信息表中。获取

呈现数据主要是分组统计SQL语句的组装。根据时间（年）和资产分类分组资产登记信息表的数据，并合计其登记金额。SQL语句可能大致如下：Select Year(AddTime) as 年份，Sum(金额)，分类 FROM 资产投入登记表 Group by 分类，Year(AddTime)

2.0图标数据的绑定。主要是根据分类绑定图标的分类数据。

通常类似的涉及到两个维度的分析数据统计，报表的制作通常交由高级程序员进行开发，需要的时间在2 到 3 天之间。即开发工作量为3到4人/天。

象一维的分析统计，高级程序员通常能在一天内完成。即2人/天左右。

如果使用报表平台对报表进行设计。主要是报表平台的使用和熟悉需要一个较长的时间。熟悉了报表工具的使用。基本上大部分的报表都能在1天内完成制作。

6.5接口文件（WCF）

接口文件的主要开发量是逻辑部分的处理，UI部分没有任何的工作量处理。

例如用户信息查询WebService接口。根据用户的姓名查找匹配的用户列表。逻辑处理部分，主要是涉及到一个用户表，用户表5个数据列表以及用户名属性过滤条件的处理。则其开发量为5DP +1DP + 1TP。半天内能完成。

6.6动态组装的列表数据

动态组装的数据列表，其主要的开发量是系统逻辑部分的处理。例如根据投诉统计页面，根据投诉分类和月份对投诉数据进行分析。见下图：

系统通过两个分析维度（时间和投诉分类）对投诉信息进行了统计。其处理流程如下：

1.0加载投诉分类数据

2.0加载时间分类数据（此处固定为12个月）

3.0加载分析合计数据，此处主要是合计数据的SQL语句组装。大致如下：

Select count(*),投诉分类，月份 from (select 投诉分类，

Month(AddTime) as 月份，投诉分类 from 投诉列表视图 )A group by

投诉分类，月份

4.0根据月份创建列表头部数据。

5.0逐行创建分类分析数据，并根据分类和时间的交集从合计数据中查找其

对应的统计数据。并组装其对应的单元格呈现。同时更新对应月份和分

类的合计数据。

6.0各类合计数据的组装。

类似这种列表，逻辑部分的组装相对复杂。根据经验，适合交给高级开发人员处理。通常需要2到3天的开发时间。即开发工作量为3-4人/天。

7工作量评估分析（开发平台）

由于系统平台实现了工厂批量生产处理，对应任意的系统同能，例如经销商数据列表呈现，经销商数据增加、经销商数据修改和经销商数据删除，可以通过配置工具动态生成。居于生成的页面功能，可能还会做些细化的工作，如字段选择依赖的过滤条件，简单线性流程的数据流转，删除时外键数据检查等，主要的工作量在于数据模型的建立和建表，复杂的业务逻辑可放在数据库的存储过程来处理。