某集团项目估计规程Word文档格式.docx
《某集团项目估计规程Word文档格式.docx》由会员分享，可在线阅读，更多相关《某集团项目估计规程Word文档格式.docx（20页珍藏版）》请在冰豆网上搜索。
角色
职责
项目经理
✧组织项目的估计活动。
需求分析阶段结束后进行初期估计、设计阶段结束后进行中期估计
✧确认估计的结果
✧在项目结项时将项目资源模型提交组织过程资产库
需求分析人员
✧实施软件项目的估计活动
开发人员
系统设计人员
测试人员
PPQA工程师
✧负责在本过程所涉及的质量保证工作
上级主管
✧评审估计的结果
4、使用的资源
公司项目度量库，不需要特殊工具软件
5、输入
1、工作范围说明书（SOW）。
2、用户需求说明书。
3、产品需求说明书
4、历史项目数据。
6、入口准则
1、用于初期估算的需求规格说明书或产品需求说明书已经形成。
7、流程图
图1估计活动流程图
8、活动
8.1估计规模
项目的规模可以用功能/子程序、类/模块、图形用户界面（GUI）组成部件、功能点（FP）、代码行（LOC）、接口数、文档页数、用例点（UCP）等来表示。
项目规模估计的方法可以使用宽带Delphi法、Pert法、类比法、功能点分析法（FPA），或者交错的使用不同的方法。
在使用类比法、功能点分析法时建议需求分析人员、项目经理和技术工程师三方面分别给出估算。
估算结果取三个估算结果的中值。
如果各方估算结果的偏差大于20%，则估算无效，需要重新估算。
偏差的计算公式如下：
偏差=max（（最大值-均值），（均值-最小值））/均值
估计过程可以采用自顶向下和由底向上结合的方式进行。
在项目早期采用自顶向下的方法估计项目的总规模；
需求分析阶段之后在需求比较明确的情况下采用由底向上的方法进行，先估计底层工作包对应的工作产品的规模，而后逐层往上汇总。
进行规模估计时，还需要考虑工作产品的复杂程度。
可以根据工作产品的复杂程度来估计一个难度系数。
此外，如果工作产品是可重用的，还需要对重用率进行估计。
所有估算假设、约束条件和接口都要得到清晰地定义。
知道了工作产品的规模和难度系数以及重用率，就可以用以下公式得到一个确定难度下的等价规模：
等价规模=规模*难度系数*（1-重用率）＋规模*重用率*重用率系数。
其中：
重用率=0～100%。
0表示没有重用，100%表示全部重用；
难度系数=0.5～1.5。
难度系数0.5为一般，1.5为最难；
重用率系数：
10%～30%。
8.2估计工作量
在完成规模的估计后，就可以开始进行工作量的估计。
工作量估算根据估算规模和生产率计算得出。
使用自顶向下估计。
在知道总规模后，就可以根据生产率导出总工作量。
然后就可以根据工作量的阶段分布比例（表1）来确定每个阶段的工作量。
Ø
估算总工作量
根据已估算出的规模数据，通过以下公式计算得出总工作量的值：
工作量=等价规模/（平均生产率*生产率系数）
公司如有历史平均生产率，应参照历史数据，该数据可从公司过程资产库中获取；
如无历史平均生产率，则建议参照业界标准或相似项目的历史数据（参见附录一）。
平均生产率是指平均每人天的代码行、功能点数。
它不仅仅指编码阶段，还包括需求、设计、编码、测试的整个过程，为软件全生命周期的平均生产率。
生产率系数是根据项目类型、复杂程度、人员经验和技术因素等确定的（参见附录一）。
估算阶段工作量
根据总工作量的估算结果，将总工作量分配到生命周期的各个阶段，生命周期的阶段划分应与项目选择的生命周期的定义保持一致，各阶段工作量的比例分配应参照公司历史项目阶段工作量分配比例的数据。
在没有公司历史数据的情况下，可以参考下表：
表1：
阶段性工作量百分比（行业推荐）
阶段
工作量百分比（行业）
百分比估计取值示例
需求分析与管理
15%–25%
20%
设计
15%–20%
15%
编码
20%–25%
测试（单元/集成/系统）
12%–20%
12%
初验、用户培训及试运行
7%–10%
8%
项目启动、结项
5%–10%
5%
项目管理
10%
质量保证
5%–7%
配置管理
2%–5%
记录估算结果
将工作量估算结果记录在《项目估计记录表》。
8.3估计进度
进度估算是根据工作量估算、资源和约束条件（该阶段投入的人员数量、人员知识和技能、合同工期要求）得出的。
根据阶段工作量和该阶段可能投入的人力资源确定阶段进度。
执行进度估计的顺序是，首先需要根据项目特点设置好工作包之间的依赖性，然后筹划关键任务的进度，最后安排次要任务的进度。
进度的安排过程中，需要注意以下事项：
每个工作包必须安排计划开始时间、计划结束时间、工期和执行人员；
项目进度表中，不能存在资源冲突；
如果项目合同对某些时间点有约定的话（初验时间、系统上线时间等），必须遵守合同的约定；
工作包之间的依赖性能够体现出来。
要求使用MSProject来制定软件项目的进度表。
在进度表中要标明关键路径和里程碑。
8.4审查和批准
估算要得到项目上层经理的评审和批准。
所有的估算纪录和结果都要纳入配置管理。
审查和批准应该采用同行评审的办法来完成。
同行评审应由下述人员参加：
进行估计的人员，PPQA，最好有一个来自同一个项目的未参加估计的软件工程师，有类似项目经验的软件工程师，项目上层经理等。
在审查完成并修复所有缺陷后，软件估计人员、项目经理、PPQA人员或上层经理应确认该估计，可以用签字或者邮件的方式。
审查和批准后的估计将作为项目监督和控制（PMC）输入的一部分。
8.5跟踪和报告估计
项目经理定期或在项目阶段总结时对项目的估计进行跟踪。
跟踪和报告的目的是随时间不断比较原来的估计与实际情况的差异，核对估计的准确性，并生成关于估计的历史文件。
8.6度量和改进估计
在项目结束后，项目经理要整理项目度量数据，分析项目实际数据和估计值的差异，并将原始记录纳入公司的过程资产库，供后续项目估计参考。
9、输出及需要的配置管理
输出产品
管理级别
项目估计记录表
记录类
注：
记录类配置项只进行读写控制；
一般受控配置项进行版本控制
10、出口准则
1、得出估计结果
2、估计结果得到相关人员认可
11、相关的文件
1、项目计划与监控规程
2、同行评审规程
12、附件
1、项目估计记录表
附录一、估计指南
一、估计的基本要求
下述列举了在估算一个项目时需要考虑的几个要点：
一、软件估计是一个持续过程，进行估计时必须遵循以下准则：
应该在项目需求与计划阶段即进行估计，并在项目的每一个重要的里程碑完成后，对各项估计的结果进行跟踪。
在项目的开发阶段如果发现实际值跟估计值发生较大偏离时，需要重新进行估计。
由于软件开发过程是一个逐步细化的过程，如果对于原有工作内容进行修改，需要进行重新估计（与细化下一阶段计划同时进行）。
应该由两个或者两个以上的本领域的资深人员分别进行独立的估计，并对各自估计的结果进行比较。
建议采用两种或两种以上的估计方法进行估计。
尽可能的使用历史数据，并在实际运作过程中，提出对历史数据进行修改的意见及该修改意见的客观依据。
所有的估算方法不能依赖于具体的某个人。
对大型项目的估算，要由多于一个人/团队来进行。
最终的估算输入要包含这些个人/团体的估算。
这种方法有助于取得完整的假设条件，从而得到一个最终的估算数值。
在定义工作的规模时，要咨询有经验的人员。
无论哪种方法，都要参考历史数据，这些数据存储在过程数据库中。
有必要对估算方法进行培训。
所有的估算都必须满足以下要求：
所有的假设条件必须要被清晰地表达、确证和批准。
必须维护每个阶段的估算。
下表描述了在一个项目中建议进行的各种估算：
估算阶段
项目开发生命周期阶段
预算估算
销售类项目：
在项目合同签订前；
产品研发类项目：
在项目立项完毕前
初期估算
需求说明书完成后
中期估算
设计阶段后
后期估算
在结项时
二、估计方法的选择
在下述各种情况下，建议使用FPA（功能点法）方法：
初期/预算估算
项目说明文档只对功能给出了大致的范围
功能可见性低
需要从头开始开发系统
估算人员有资深的经验（多于5年的项目管理经验）
在下述各种情况下，建议使用LOC（代码行）方法：
本方法适用于需求很清晰
有过往的项目可以参考的项目
适用于后期估算时，有历史项目可供参考时，也可应用于预算估算
在下述各种情况下，建议使用UCP（用例点）方法：
当项目会准备用例并且使用面向对象的方法时
在初期、中期和后期估算时
系统非常大
相关人员有OOAD、UML和UseCase准备经验
三、平均生产率
1、对于三层结构的应用软件，平均生产率大约是每人天0.9功能点
2、对于第四代语言，平均生产率大约是每人天0.9功能点
3、功能点与代码行之间的转换关系
代码行和功能点数之间的关系依赖于程度设计语言和设计质量。
下表给出了不同程序设计语言中，建造一个功能点所需的平均代码行数
程序设计语言
LOC/FP（平均值）
汇编语言
320
面向对象语言
30
C
128
第四代语言（4GLs）
20
Cobol
105
代码生成器
15
Fortran
电子表格
6
Pascal
90
图形语言（图标）
Ada
70
四、生产率系数
项目团队构成
生产率系数（VB/Oracle）
都是新人或有较少的经验
1.35
75%新人、25%有经验
1.38
75%有经验、25%新人
1.4
都是有经验的员工
1.5
附录二、项目估计示例（类比）
1、项目规模估计
项目名称
数字电视信息处理系统
项目令号
Z-GJ08015
项目负责人
黄明
估计人员
刘天、王可、许易
PPQA人员
彭民
批准者
董国平
估计日期
2008.3.15
第
（1）次估计
批准日期
2008．3．20
重估计的原因
估计量纲
功能点（FP）
历史项目名称
数字电视信息处理系统一期
估算项编号
需求点/功能模块
历史项目数据
新项目不同点
新项目估计规模
难度系数
重用率
重用率系数
总等价规模
SRF0101
查看全台运行情况
33
改进
60
0.5
50%
21
SRF0102
查看发射机运行状态
新增一个功能
25
0.8
30%
14.75
SRF0103
同步发射机故障
12
35%
14.05
SRF0104
同步调度令
相同
100%
3.6
SRF0105
查询调度令
8
2.4
SRF0106
同步运行图
16
12.16
SRF0107
查询运行图
5.2
SRF0201
制定排班规则
18
5.4
SRF0202
排班
SRF0203
换班
SRF0204
替班
SRF0205
查询排班记录
增加一个功能
4.8
合计
1、总等价规模=估计规模×
难度系数×
（1-重用率）+重用率×
2、难度系数取值范围：
0.5~1.5之间。
0.5为难度系数一般；
1.5为难度系数最难。
3、重用率取值范围：
0~100%。
0表示没有重用；
100表示全部重用。
4、重用率系数取值范围：
10%~30%。
表明重用部分所需要的工作量。
2、工作量估计
一、估算总工作量
规模估算值（需求点/功能模块）
96
生产率（需求点/功能模块/人天）
规模系数
总工作量（人天）
二、分配阶段工作量
项目阶段
阶段工作量分配比例（%）
工作量（人/天）
立项与启动
2%
1.8
需求与计划
27
25%
22.5
编码与测试
初验测试
培训与试运行
4.5
最终验收
3%
2.7
运行与维护
1、总工作量=规模估计值×
规模系数/生产率
2、生产率（行业数据）：
参见附录一中有关章节
附录三、宽带Delphi方法过程
活动1：
准备估计的内容。
准备估计的内容时，有两个要点：
（1）完备的识别被估计的内容。
（2）尽管Delphi方法既可以对颗粒度比较大的任务进行估计，也可以对颗粒度比较小的任务进行估计，但是还是要细分任务，其目的是为了提高估计的准确度与加快估计值收敛的速度。
如果让一个人去估计一幢大楼的使用面积和去估计一个房间的使用面积，估计的准确率显然差别很大。
由作者将被估计的内容细分为更小颗粒度的问题，这样更容易把握，估计时更容易快速收敛。
活动2：
成立估计小组。
估计小组有协调人、作者和3到6名估计专家组成。
协调人负责计划和协调软件估计活动，协调人在担任此角色时不能用自己的观点去引导专家，也不能因为自己的认识或偏见而对软件估计的结果进行歪曲。
协调人不能是作者，也不必作为专家。
专家的数量不宜太多，否则成本比较高。
专家必须具备2个条件：
（1）有业务与技术经验，熟悉被估计的内容；
（2）要有估计的经验，接受过估计方法的培训，并曾经在实践中评价过自己的估计准确率。
活动3：
召开启动会议。
协调人负责召开启动会议，在启动会议上主要进行以下工作：
（1）作者向专家介绍估计的内容、项目的各种假设和限制条件。
（2）专家对被估计的内容达成一致，并确认各种假设和限制条件。
专家与作者在本次会议上应对被估计的内容进行充分的讨论，以确保大家的理解是一致的，并通过这种讨论可能对被估计的内容进行完善。
专家对估计结果的度量单位达成一致。
比如估计软件的规模时，是用行还是千行作为计量单位，代码行是否包括注释行、空行、开发平台自动生成的语句等要达成一致。
对估计结束的准则达成一致。
结束的准则包括：
估计结果可接受的判断方法，即估计结果在多大的偏差范围内是认为是可接受的，此时称为估计结果收敛。
在连续几轮无法收敛后，估计应该结束；
对于不能收敛的估计内容如何确定估计结果。
结束准则也可以由协调人和作者在活动2中确定。
活动4：
专家独立估计。
在专家进行独立估计时，需要注意：
1、专家的估计活动不应受外界压力的影响，协调人或者作者不能给出估计结果的上下限或其他限定。
2、各专家之间没有讨论和咨询。
3、各专家采用的估计方法也不受限制。
各专家即可以根据自己的经验估计，也可以采用类比的方法进行估计。
4、如果专家认为被估计的内容中存在不明确的地方，应记录自己所做出的各种假设。
活动5：
汇总估计结果。
收集各专家的估计结果，制作本轮的估计结果表：
表1Delphi方法规模估算记录表（个人）
估算对象：
估算人：
估算日期：
估算单位：
代码行（LOC）
乐观值
可能值
悲观值
估算值
估算假设
估算约束
模块1（专家1）
1380
1420
1520
1430
模块2（专家1）
960
1020
1100
1023
模块1（专家2）
1690
1560
1558
模块2（专家2）
850
980
965
5
4977
差异率的计算方法以及接受的准则应该在活动2或者活动3时确定，比如可以采用如下的差异率计算公式及接受准则：
（1）差异率=max（最大值-平均值,平均值-最小值）/平均值；
（2）当差异率<
25%时接受平均值为最终估计结果。
需要注意的是对于颗粒度比较小的任务，可能对差异率比较敏感，比如一个程序的平均估计规模为10行，如果估计结果为13行、10行、7行，则差异率按上面的准则计算则为30%，大于了25%，估计结果不可以接受。
而如果一个程序的平均估计规模为100行，如果估计结果为103行、100行、97行的话，同样是3行的绝对偏差，该估计结果就是可以接受的。
所以对于颗粒度比较小的任务，可能需要区别定义接受准则。
活动6：
讨论不收敛项。
将本轮的匿名估计结果公布给各专家，讨论不收敛的估计项，在讨论时只对被估计的内容的理解进行讨论，不讨论每个人具体的估计结果，为了达成一致的理解，此时可能需要重新细化估计内容或确定估计假设。
活动7：
新一轮的估计
对于估计结果未被接受的估计项，执行活动4，如此不断反复，直至满足以下任何一项条件：
1、完成多轮估计（如4轮），该条件已经在结束准则中确定了。
2、所有的估计结果收敛于一个可以接受的范围；
3、所有专家拒绝对各自的估计结果进行修改。
活动8：
讨论未收敛的估计项
对于结束了多轮估计后，仍然未收敛的估计项，可以采用如下的方法确定最终估计结果：
1、按照少数服从多数的原则，忽略少数与其他估计结果差异很大的估计结果。
2、采用“掐头去尾求平均值”的方法。
即：
排除最大与最小值后，求剩余数值的平均值作为最终估计结果。
3、由各专家进行讨论，形成一个一致的意见。
活动9：
总结本次估计
估计小组对最后汇总的估计结果进行审核，并对结果达成一致。
估计小组可以对宽带Delphi方法进行思考，提出改进措施，以使将来的估计活动更加有效。
附录四、功能点（FPA）方法过程
计算未调整的功能点（UAFP）。
1、先标识出组成产品的五类元素
（1）外部输入（EI）
数据由外向内跨越边界的基本处理过程。
（2）外部输出（EO）
导出的数据由内向外跨越边界的基本处理过程。
数据发送给其他应用的报表或输出文件由一个或多个内部逻辑文件和外部接口文件所创建。
（3）外部查询（EQ）
包括输入和输出的基本处理过程。
输入和输出导致一个或多个内部逻辑文件和外部接口文件的数据检索。
该信息被发送出应用程序边界。
输入过程不会更新任何内部逻辑文件。
（4）内部逻辑文件（ILF）
在应用程序内部维护的逻辑相关数据或控制信息。
（5）外部接口文件（EIF）
由应用程序引用的逻辑相关数据或控制信息
数据完全驻留在应用程序外部，由其他应用程序所维护。
外部接口文件是其他应用程序的内部逻辑文件。
2、对标识出的每个元素确定其复杂度
（1）外部输入（EI）的复杂度确定
FTR’s：
用到内部逻辑文件和外部接口文件的数量
数据元素：
每个唯一的、用户可识别的字段
（2）外部输出（EO）和外部查询（EQ）的复杂度确定
（3）内部逻辑文件（ILF）和外部接口文件（EIF）的复杂度确定
RET’s：
记录类型个数，如：
部门记录算一种，员工记录算一种
3、计算未调整的功能点（UAFP）
将标识出的各元素按照复杂度分类统计，填入下表，得出系统未调整的功能点。
计算调整后的功能点（AFP）。
1、计算调整因子（VAF）
基于下述14个系统基本特性计算调整因子，评估这些系统特性对应用系统的影
升级会员 