01软件项目估算过程
- 格式：doc
- 大小：140.00 KB
- 文档页数：7
下载文档原格式
合集下载
软件规模估计方法
圈复杂度计算
圈复杂度是衡量代码结构复杂性的一个指标，通 过计算代码中的独立路径数量来评估。
3
调整代码行数
根据圈复杂度对代码行数进行调整，以更准确地 估计软件规模。
基于特征的代码行数估计法
识别代码特征
01
这种方法通过识别源代码中的特定特征来估计软件规模。
特征选择与权重分配
02
选择与软件规模相关的特征，并为每个特征分配适当的权重。
感谢您的观看
快速、简单，适用于初步估计。
缺点
主观性强，精度难以保证。
历史项目类比法
优点
相对客观，可减少主观偏差。
缺点
要求有丰富的历史数据，且项目间必须具有可比性。
参数模型法
优点
精度较高，适用于大量项目的规模估 计。
缺点
需要大量历史数据，模型建立和维护 成本较高。
05 成本驱动估计法
COCOMO模型
COCOMO模型是一种基于工程任务量的估计模型， 通过分析软件的功能和复杂性来估算软件规模。
估计方法的标准化与验证
方法标准化
制定统一的软件规模估计方法标 准，确保不同组织或团队之间的 估计结果具有可比性。
方法验证
通过实际项目验证软件规模估计 方法的准确性和可靠性，不断优 化和改进方法。
基准测试
建立基准测试库，用于评估不同 软件规模估计方法的性能和准确 性，为实际项目提供参考依据。
人工智能在软件规模估计中的应用
缺点
对软件内部结构了解要求较高，需要具备专 业知识和经验。
外部功能点计数法
定义
外部功能点计数法是根据软件外部接 口和用户交互进行功能点计数的估算 方法。
适用场景
适用于软件外部接口和用户交互较为 明确的软件项目。
圈复杂度是衡量代码结构复杂性的一个指标，通 过计算代码中的独立路径数量来评估。
3
调整代码行数
根据圈复杂度对代码行数进行调整，以更准确地 估计软件规模。
基于特征的代码行数估计法
识别代码特征
01
这种方法通过识别源代码中的特定特征来估计软件规模。
特征选择与权重分配
02
选择与软件规模相关的特征，并为每个特征分配适当的权重。
感谢您的观看
快速、简单，适用于初步估计。
缺点
主观性强，精度难以保证。
历史项目类比法
优点
相对客观，可减少主观偏差。
缺点
要求有丰富的历史数据，且项目间必须具有可比性。
参数模型法
优点
精度较高，适用于大量项目的规模估 计。
缺点
需要大量历史数据，模型建立和维护 成本较高。
05 成本驱动估计法
COCOMO模型
COCOMO模型是一种基于工程任务量的估计模型， 通过分析软件的功能和复杂性来估算软件规模。
估计方法的标准化与验证
方法标准化
制定统一的软件规模估计方法标 准，确保不同组织或团队之间的 估计结果具有可比性。
方法验证
通过实际项目验证软件规模估计 方法的准确性和可靠性，不断优 化和改进方法。
基准测试
建立基准测试库，用于评估不同 软件规模估计方法的性能和准确 性，为实际项目提供参考依据。
人工智能在软件规模估计中的应用
缺点
对软件内部结构了解要求较高，需要具备专 业知识和经验。
外部功能点计数法
定义
外部功能点计数法是根据软件外部接 口和用户交互进行功能点计数的估算 方法。
适用场景
适用于软件外部接口和用户交互较为 明确的软件项目。
软件开发报价(含软件开发项目工作量及报价模板)的计算方法
软件开发报价(含软件开发项目工作量及报价模板)的计算方法软件开发的价格估算与工作量、商务成本、国家税收以及企业利润等因素有关。
为了方便计算，可以使用以下公式进行计算：软件开发价格 = 开发工作量 ×开发费用/人·月。
1.1 开发工作量软件开发工作量与估算工作量经验值、风险系数和复用系数等因素有关。
具体计算公式为：软件开发工作量 = 估算工作量经验值 ×风险系数 ×复用系数。
1.1.1 估算工作量经验值（以 A 来表示）过去，有人提出使用源代码行或功能点来计算软件开发工作量，但这些方法都存在一定的困难。
目前，国际上仍按照经验的方式进行计算，而国内各软件企业也采用这种方式进行工作量估算。
为了更好地规范估算方法，建议按照国家标准“GB/T 8566-2001 软件生存周期过程”中规定的软件开发过程活动来计算工作量。
工作量的计算按照一个开发工作人员在一个月内（日历中的月，包括国家规定的节假日）能够完成的工作量为单位，通常称为“人·月”。
需要特别提醒的是，软件开发过程中不仅包括软件开发，还包括各种软件测试活动。
1.1.2 风险系数（以σ 来表示）估算工作量经验值也存在较大的风险，造成软件危机的因素很多，这也是一个方面的因素。
特别是当软件企业对该信息工程项目的业务领域不熟悉或不太熟悉，而且用户又无法或不能完整明白地表达他们的真实需求，就会导致软件企业需要不断地完善需求获取、修改设计等各项工作。
因此，风险系数应该满足以下条件：1 ≤ 风险系数≤ 1.5.我们了解到，超过估算工作量经验值的一半已经是不可接受的，因此我们将“1.5”设定为极限值。
当然，这既要看企业的能力，也要看用户能接受的程度。
1.1.3 复用系数（以τ 来表示）估算工作量经验值是软件企业承担一般项目时使用的，但如果软件企业已经采用“基于构件的开发方法”，并建立了能够复用的构件库（核心资产库），或者已有一些软件产品仅需进行二次开发，从而使软件开发工作量减少。
功能点估算法
功能点(Funciton Point FP)估算法功能点估算法是软件项目管理众多知识中比较有技术含量的一个。
在软件项目管理中项目计划制定的优劣直接关系到项目的成败，项目计划中对项目范围的估算又尤为重要。
如果项目负责人对项目的规模没有一个比较客观的认识，没有对工作量、所需资源、完工时间等因素进行估算，那么项目计划也就没有存在的意义。
功能点估算法的特点项目范围的估算在CMMI的“MA”度量分析管理和“PP”项目计划中均有涉及。
对软件项目范围的估算有很多种方法，常见的是LOC代码行和FP功能点法。
它们之间的区别和关系如下：•功能点估算法常用在项目开始或项目需求基本明确时使用，这时进行估算其结果的准确性比较高。
假如这个时候使用LOC代码行估算法，则误差会比较大。
•使用功能点估算法无需懂得软件使用何种开发技术。
LOC代码行估算法则与软件开发技术密切相关。
•功能点估算法是以用户为角度进行估算，LOC代码行估算法则是以技术为角度进行估算。
•通过一些行业标准或企业自身度量的分析，功能点估算法是可以转换为LOC代码行的。
在项目刚开始的时候进行功能点估算可以对项目的范围进行预测。
在项目开发的过程中由于需求的变更和细化可能会导致项目范围的蔓延，计算出来的结果会与当初估计的不同。
因此，在项目结束时还需要对项目的范围情况重新进行估算，这个时候估算的结果才能最准确反映项目的规模。
功能点分析的步骤本文将以国际标准IFPUG（International Function Point Users Group）组织提供的功能点估算法V4.1.1为基础进行讲解。
如下图所示，首先大家应该了解功能点估算法的使用步骤。
图1 功能点估算法的步骤具体步骤包括：1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。
软件开发成本估算
例如：完成某个任务的人员投入和时间需求，则其工作量为60.5人月。
开发阶段
投入人员情况
时间（月）
工作量（人月）
需求分析
系统分析员2人
2
2*2*2.5=10
系统设计
系统分析员1人
2
1*2*2.5=5
高级程序员2人
2
2*2*1.5=6
编码
高级程序员2人
1
2*1*1.5=3
程序员4人
1
4*1*1=4
测试
服务费
3.3.1 验收测试费 软件项目验收是一个运行环境复杂、技术难度较高、评价体系抽象的过程。该项目验收除经过专家评审外，还应进行相应验收测试，只有两者结合才能为信息化项目验收和鉴定提供定性、定量的科学依据，才能做出较为客观准确的验收和鉴定结论。
1
功能确认测试
2
项目对象：省、市级信息化建设项目包括电子政务建设项目验收，各种渠道申报的与软件相关的科技项目的验收和科技成果鉴定项目。
在招标活动中，公证处对全过程进行现场公证并对采购合同进行公证，公证费按照国家规定标准计算。
3.各项费用取费依据
注： 1.按表1计费不足1000元的，按1000元收费。 2.按表2计费不足200元的，按200元收费。 3.技术咨询按耗用工时（日）计费，为完成委托任务发生的差旅、交通费由委托方另行支付。 4.招标代理收费和公证服务收费按差额定率累进法计算。 5.如某招标代理业务中标金额为600万元，计算招标代理费如下： 100万元*1.0% = 1万元 （300-100）万元*0.8% = 1.6万元 （500-300）万元*0.7% = 1.4万元 （600-500）万元*0.55% = 0.55万元 则合计收费：1 + 1.6 + 1.4 + 0.55 = 4.55万元
软件项目策划PPT课件
选择调研方法
根据调研目标选择合适的调研 方法，如问卷调查、访谈、观
察等。
实施调研
按照调研方法收集数据和信息 ，并进行整理和分析。
编写调研报告
将调研结果以报告形式呈现， 包括市场现状、竞争态势、用
户需求等。
产品定位
分析市场环境
了解行业趋势、市场规 模、竞争格局等。
确定目标用户
明确产品的目标用户群 体及其特征。
项目背景
该企业试图通过实施ERP系统提升管理水平，但最终未能 成功。
失败案例剖析及教训汲取
失败原因
对ERP系统的实施难度和复杂性认识不足，缺乏足够 的资源投入和专业的实施团队；同时，企业内部对变 革的抵触情绪也是导致失败的原因之一。
教训汲取
在实施大型软件系统时，必须充分评估项目的难度和 复杂性，投入足够的资源和专业的实施团队；同时， 积极引导和推动企业内部变革也是非常重要的。
软件项目的分类与发展趋势
分类
根据应用领域不同，软件项目可分为系统软件、应用软件、 嵌入式软件等；根据开发模式不同，可分为瀑布模型、迭代 模型、敏捷开发等。
发展趋势
未来软件项目将更加注重用户体验和个性化需求，采用更加 先进的开发技术和工具，同时更加注重软件质量和安全性。 此外，人工智能、大数据等技术的发展也将对软件项目产生 深远影响。
启示意义
在软件项目策划中，应注重技术创新和应用创新，通过引入先进 技术和创新服务模式，提升产品的竞争力和用户体验。
案例二
某大型软件企业推出的云端协作平台
项目背景
该企业针对团队协作需求，推出一款云端协作平台，提供高效、便 捷的团队协作服务。
创新案例展示及启示意义探讨
创新点
采用云计算技术，实现团队协作数据的实时 同步和共享；同时，提供丰富的协作工具和 应用场景支持，满足不同团队的个性化需求 。
如何对软件开发项目开展造价评估
如何对软件开发项目开展造价评估摘要：目前，国内的很多软件开发项目存在着工程延期、投资超支等情况，难以按期竣工并投入使用。
此外，做为建设方也很难拥有雄厚的专业技术实力对即将开发的软件有一个客观、真实的认识。
针对上述情况，国内的专业第三方咨询机构有能力为建设方提供软件开发项目的造价评估服务，在建设方对项目作投资决策时为其提供参考。
本文将介绍当今主流的造价评估理论和方法，结合笔者在税务领域的实践经验，向大家介绍如何开展造价评估工作。
关键词：软件开发；造价评估；咨询；功能点how to make the cost assessment for software development projectabstract:in china,many software development projects have project extension,investment overruns,etc.the present state affairs cause the project cannot complete on schedule.furthermore,major owners cannot hold professional technology capacity about the development of software.therefore,the third party consulting institution provides the cost assessment of software development project,which helps the owners with investment decision.this article presents the popular cost assessment theories and methods,and then introduces how to make the cost assessment with the author experience.keywords:software development;cost assessment;consulting;function point1造价评估概述由于软件本身的复杂性、估算工具的缺乏以及一些人为错误，可能导致软件项目的投资估算往往和实际情况相差甚远。
软件过程体系结构图
DAR 决策分析与决议\DAR-2-01 决策分析与决议流程 OPM \组织过程绩效\组织过程绩效流程 PP 项目策划\PP-2-01项目计划流程 PMC 项目跟踪与监控\PMC-2-01 项目跟踪与监控流程 MA 度量与分析\MA-2-01 度量与分析流程
OPM 组织过程管理\组织过程管理流程 CAR 原因分析与解决过程\原因分析与解决过程流程
CMMI5
组织革新与部署 原因分析与解决过程
简写 RM
PP PMC SSM MC PPQA CM RD
TS PI
VE\VA OPF OPD
OT
IPM RSKM DAR OPP
QPM OID CAR
CMMI软件过程体系结构图
文件编号：COM-3-03 版本：B 仅供内部使用
对应的公司流程
RE 需求工程\RE-2-02 需求管理流程 PP 项目策划\PP-2-01项目计划流程 PP 项目策划\PP-2-02 项目估算流程 PMC 项目跟踪与监控\PMC-2-01 项目跟踪与监控流程 无外包业务，因此删免； MA 度量与分析\MA-2-01 度量与分析流程 QA 过程和产品质量保证\QA-2-01 过程和产品质量保证流程 CM 配置管理\CM-2-02 配置管理流程 RE 需求工程\RE-2-01 需求开发流程 TS 设计编码与集成\TS-2-01 设计流程 TS 设计编码与集成\TS-2-02 编码流程 TS 设计编码与集成\TS-2-03 产品集成流程 Review 评审\PR-2-01 评审流程 Test 测试\TEST-2-01 测试流程 OPM 组织过程管理流程 OPM 组织过程管理流程 OT 组织培训\TP-2-01 公司员工培训流程 OT 组织培训\TP-2-02 项目组员工培训流程 PP 项目策划\PP-2-01项目计划流程 PMC 项目跟踪与监控\PMC-2-01 项目跟踪与监控流程 RSKM 风险管理\风险管理流程
OPM 组织过程管理\组织过程管理流程 CAR 原因分析与解决过程\原因分析与解决过程流程
CMMI5
组织革新与部署 原因分析与解决过程
简写 RM
PP PMC SSM MC PPQA CM RD
TS PI
VE\VA OPF OPD
OT
IPM RSKM DAR OPP
QPM OID CAR
CMMI软件过程体系结构图
文件编号：COM-3-03 版本：B 仅供内部使用
对应的公司流程
RE 需求工程\RE-2-02 需求管理流程 PP 项目策划\PP-2-01项目计划流程 PP 项目策划\PP-2-02 项目估算流程 PMC 项目跟踪与监控\PMC-2-01 项目跟踪与监控流程 无外包业务，因此删免； MA 度量与分析\MA-2-01 度量与分析流程 QA 过程和产品质量保证\QA-2-01 过程和产品质量保证流程 CM 配置管理\CM-2-02 配置管理流程 RE 需求工程\RE-2-01 需求开发流程 TS 设计编码与集成\TS-2-01 设计流程 TS 设计编码与集成\TS-2-02 编码流程 TS 设计编码与集成\TS-2-03 产品集成流程 Review 评审\PR-2-01 评审流程 Test 测试\TEST-2-01 测试流程 OPM 组织过程管理流程 OPM 组织过程管理流程 OT 组织培训\TP-2-01 公司员工培训流程 OT 组织培训\TP-2-02 项目组员工培训流程 PP 项目策划\PP-2-01项目计划流程 PMC 项目跟踪与监控\PMC-2-01 项目跟踪与监控流程 RSKM 风险管理\风险管理流程
项目管理第1章软件项目的估算
4 作为LOC和FP估算的实例，考察一个
为CAD应用而开发的软件包。
• 在这个实例中，使用LOC做为估算 0011 0010 1010 1101 0001 0100 1011 变量。
• 根据系统规格说明, 软件范围的初步
412 叙述如下
“软件将从操作员那里接收2维或3维几 何数据。 操作员通过用户界面与 CAD 系统交互并控制它，这种用户界面将 0011 0010 1010 1101 0001 0100 1011 表现出很好的人机接口设计特性。所 有的几何数据和其它支持信息保存在 一个CAD数据库内。要开发一些设计
1 各种人员的需要。
2 • 计划人员首先估算范围并选择为完 成开发工作所需要的技能。还要在 4 组织和专业两方面做出安排。
• 对于一些规模较小的项目（1个人年 或者更少），只要向专家做些咨询， 0011 0010 1010 1101 0001 0100 1011
也许一个人就可以完成所有的软件 工程步骤。
1 所需要的代码行数并不相同；
42 ·这种方法不适用于非过程语言。
2.1.2 功能点技术
0•01功1 00能10 1点010技110术1 00依01 0据100对101软1 件信息域特性和软件 复杂性的评估结果，估算软件规模。这种 方法用功能点（FP）为单位，度量软件的 规模。
1 • 1．信息域特性 功能点技术定义了信息域的5个特性，分别 2 是输入项数（Inp）、输出项数（Out）、 查询数（Inq），主文件数（Maf）和外部 4 接口数（Inf）。
（1）宿主机（Host）─ 软件开发时 使用的计算机及外围设备；
1 （2）目标机（Target）─ 运行已开发
成功软件的计算机及外围设备；
2 （3）其它硬件设备 ─ 专用软件开发
为CAD应用而开发的软件包。
• 在这个实例中，使用LOC做为估算 0011 0010 1010 1101 0001 0100 1011 变量。
• 根据系统规格说明, 软件范围的初步
412 叙述如下
“软件将从操作员那里接收2维或3维几 何数据。 操作员通过用户界面与 CAD 系统交互并控制它，这种用户界面将 0011 0010 1010 1101 0001 0100 1011 表现出很好的人机接口设计特性。所 有的几何数据和其它支持信息保存在 一个CAD数据库内。要开发一些设计
1 各种人员的需要。
2 • 计划人员首先估算范围并选择为完 成开发工作所需要的技能。还要在 4 组织和专业两方面做出安排。
• 对于一些规模较小的项目（1个人年 或者更少），只要向专家做些咨询， 0011 0010 1010 1101 0001 0100 1011
也许一个人就可以完成所有的软件 工程步骤。
1 所需要的代码行数并不相同；
42 ·这种方法不适用于非过程语言。
2.1.2 功能点技术
0•01功1 00能10 1点010技110术1 00依01 0据100对101软1 件信息域特性和软件 复杂性的评估结果，估算软件规模。这种 方法用功能点（FP）为单位，度量软件的 规模。
1 • 1．信息域特性 功能点技术定义了信息域的5个特性，分别 2 是输入项数（Inp）、输出项数（Out）、 查询数（Inq），主文件数（Maf）和外部 4 接口数（Inf）。
（1）宿主机（Host）─ 软件开发时 使用的计算机及外围设备；
1 （2）目标机（Target）─ 运行已开发
成功软件的计算机及外围设备；
2 （3）其它硬件设备 ─ 专用软件开发
01三点估算法
成的概率大致为 （38） 。
（37） A．20
B．21
C．22
D．23
（38） A．8.9%
B．15.9% C．22.2% D．28.6%
试题分析：期望工期=（8+420+38）/ 6=21
标准差=（38-8）/ 6=5
26天与21天之间为1个标准差（而非±1个标准差），16天到26天之
间为±1个标准差，根据正态分布规律，故16天到26天之间完成的概
工期是按时完工概率的50%，所以如果要18天完成，需要增 加2218=4天。 参考答案：A
2017年5月信息系统项目管理师真题：
● 项目经理在做软件项目成本估算时，先考虑了最不利的情况
，估算出项目成本为120人日，又考虑了最有利的情况下项目
成本为60人日，最后考虑一般情况下的项目成本可能为75人
日，该项目最终的成本预算应为 （58） 人日。
【问题3】（4分） 请给出关键路径和项目总工期。
（58）A．100
B．90
C．80
D．75
试题分析 期望工期=（最乐观时间+4最可能时间+最悲观时间）/ 6 =（120+475+60）/6=80 参考答案：C
2013年11月系统集成项目管理工程师真题： ●A line manager provides you with three estimates for his activity in your PERT network. His estimates are 2 weeks optimistically, 4 weeks most likely, and 12 weeks pessimistically. which would appear on the chart （74） 。 （74）A．4 weeks B．5 weeks
软件成本估算方法及应用
E-mail: jos@ Tel/Fax: +86-10-62562563
软件成本估算方法及应用
∗
பைடு நூலகம்
李明树 1,2+, 何 梅 1,3, 杨 达 1,3, 舒风笛 1, 王 青 1
1 2 3
(中国科学院 软件研究所 互联网软件技术实验室,北京 (中国科学院 研究生院 ,北京 100049)
ISSN 1000-9825, CODEN RUXUEW Journal of Software, Vol.18, No.4, April 2007, pp.775−795 DOI: 10.1360/jos180775 © 2007 by Journal of Software. All rights reserved.
776
Journal of Software 软件学报 Vol.18, No.4, April 2007
随着软件系统规模的不断扩大和复杂程度的日益加大,从 20 世纪 60 年代末期开始,出现了以大量软件项 目进度延期、预算超支和质量缺陷为典型特征的软件危机,至今仍频繁发生.根据 Standish 组织在 1995 年公布 的 CHAOS 报告显示,在来自 350 个组织的 8 000 个项目中,只有 16.2%是 “成功的(succeeded)”,即能在预算和限 期内完成 ;31.1%是 “失败的 (failed)”, 即未能完成或者取消 ; 其余 52.7% 被称为 “被质疑的 (challenged)”, 虽然完成 但平均预算超支 89%[1].2004 年,该组织的统计项目数累计达到 50 000 多个,结果显示,成功项目的比例提升到 29%,而被质疑的项目比例仍有 53%[2](如图 1 所示).虽然有些研究认为,CHAOS 报告中关于预算超支 89%的数 据被夸大了 , 实际情况应该平均在 30%~40%[3]. 但有一点却能够取得共识 :人们经常对软件成本估算不足 . 它与 需求不稳定并列,是造成软件项目失控最普遍的两个原因[4].
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目录
1.目的1
2.X围2
3.估算过程2
3.1规模和工作量估算2
3.1.1 单元复杂度定义3
3.1.2 项目的单元分解3
3.1.3 规模和工作量估算3
3.1.4 项目整体开发工作量估计3
3.2进度估算4
3.3风险的估算4
3.4关键计算机资源估算5
3.5项目成本及报价参见〈项目估算表〉6
3.5.1人力成本6
3.5.2非人力成本6
3.5.3项目成本6
3.5.4项目报价6
4.估算方法6
5.项目估算评审7
6.参考资料7
1.目的
软件估算的目的是通过对软件项目管理和开发工作量的估算, 确认项目开发
的成本, 开发周期以作为项目投标、立项的依据. 对项目的估算通常还包括对软件大小(Size) 、软件项目风险和关键计算机资源的估算等.
对软件的估算很难以精确或准确来衡量, 相反以其合理性来评估. 项目的估算通常和市场价格、商务目标、项目经验和开发成员的工作弹性相关并是上述方面的综合反映.
2.X围
软件项目的估算不是一次估算过程. 通常会对项目估算多次. 例如在商务过程中, 通过估算进行报价和投标; 在项目计划过程中, 通过估算以确定项目开发计划;
在里程碑评审和变更过程, 通过估算和总结调整项目计划.
3.估算过程
3.1规模和工作量估算
在估算过程中，根据项目的类型、技术、语言和其他属性，尽可能地参照以往项目的数据，基于以往项目的历史数据，对指定项目的程序单元进行划分和确认。
如果没有可供参照的历史数据，使用Delphi等方法进行估算。
3.1.1单元复杂度定义
软件项目经理根据以下表格并结合项目的历史数据，确定本项目的单元复杂度标准。
（下表列出了制定复杂度标准时参考的因素，具体到各项目，需要软件项目经理
3.1.2项目的单元分解
•软件项目经理组织相关人员参照定义的标准进行系统分解，以确认系统的程序单元以及程序单元的复杂度。
3.1.3规模和工作量估算
在确认完成简单、中等和复杂后，软件项目经理可以参照历史数据或用Delphi 法对工作量或规模进行估算，并把结果登记到程序单元估算表中。
（在用Delphi法估算时，各类估算值的X围应在单元复杂度标准定义的X围内）如下表：
3.1.4项目整体开发工作量估计
软件项目经理组织相关人员估计项目开发过程中各开发阶段的相对工作量和总工作量（可参照以前项目的历史数据，否则需要用用Delphi法估算）。
工作量分配比例应依据以往项目经验和项目实际情况进行调整并在项目开发过程中跟踪和在项目结束时进行总结.
前六个阶段的工作量主要指完成实际的开发任务所需的工作量；质量保证工作量包括实施检查、填写各种工作记录等活动；配置管理工作量包括配置管理的库管理活动、状态报告、填写各种记录等活动；项目管理指软件项目经理的管理活动如任务跟踪、组织交流等；评审包括各种技术评审、计划评审和里程碑评审等；培训包括项目管理和项目技术等方面培训。
3.2进度估算
项目进度估算应基于以往相似项目的时间进度进行估计。
具体步骤为:
1.创建一个MS Project 2000 文件。
2.设置项目工作日历。
3.到甘特图视图，基于程序单元估算表，列出项目所有的任务/活动。
4.定义任务依赖性。
5.设置所有的约束，包括：
a.确定的里程碑日期；
b.关键资源获取日期（人力资源/硬件/软件）。
6.到资源页面，输入对所有相关项目相关组来说，可获得的资源。
7.到甘特图视图，分配任务资源。
8.设置任务周期，周期基于以下考虑：
a.基于系统大小和工作量估计。
b.根据指定资源的工作效率，调整任务周期。
c.在工作周期中，不要包括假期。
d.在里程碑周期内，根据活动和时间分割，设置合理的周期。
e.为不可预知的问题，预留15% 的余量
9.重复步骤3, 4, 5, 6, 7, 8, 直到任务，资源和周期合理分配。
3.3风险的估算
1 识别风险项（可利用风险项检查指南）和对风险进行分析
2 确定风险优先级
根据上述列表“最主要的 5 个”风险项，根据风险大小确定优先级。
3 建立风险排序表和制定相应的措施进行预防
为高
3.4关键计算机资源估算
对计算机资源的估算可和工作量、进度估算并行进行。
估计程序如下：•估计系统的大小，包括数据类型和存储在数据库中数据记录的数量，同时访问系统的用户数量，网络传输的数据量。
•计算存储在数据库中的数据大小，每分钟执行的请求和复杂度。
•定义系统中使用的协议，计算网络的带宽。
•计算数据库服务器的性能和其他服务器的性能，定义操作系统和数据库系统。
•定义应用服务器和其他附件
•计算桌面计算机的性能，定义开发工具。
•定义硬件服务器，桌面计算机和开发计算机。
•基于以上估计步骤，填写计算机资源估算表(参见《项目估算表》)。
需要特别指出的是, 关键计算机资源的估算是指项目必须满足的针对计算机资源的要求. 例如, 软件的规模不能超过500MB, 系统响应时间不能低于2秒/页, 等. 对于关键计算机资源的要求应于计算机资源估算表中记录.
3.5项目成本及报价参见〈项目估算表〉
3.5.1人力成本
项目的人力成本是指由于各种人员的参与而计入的成本. 可根据对总工作量的估算乘以相应的小时成本得出:
人力成本= ∑(工作量x 小时成本)
3.5.2非人力成本
非人力成本主要包括和项目相关的成本, 如软件, 硬件, 出差及办公费用等.
3.5.3项目成本
项目成本是人力成本和非人力成本的总和:
项目成本= 人力成本+ 非人力成本
3.5.4项目报价
项目报价则是以项目成本为基础加上合理的利润. 需要指出的是项目的报价通常受客户的承受力、市场价格以及项目竞争者报价制约, 应予综合考虑.
4.估算方法
针对项目的需要, 在不同阶段可采取不同的估算方法. 如单人估算和多人Delphi 估算法等. 通常建议采用由3-5 人组成估算小组, 每人单独估算并填写《Delphi估算表》, 经讨论后汇总的Delphi 估算法.
Delphi 估算法是工业界广泛采用的基于个人经验汇总的估算方法. 其基本方法为:
1.软件项目经理选择具有相关经验的估算人员3-5人组成估算小组, 并确认组
长.
2.软件项目经理准备和估算相关的材料.
3.软件项目经理召开会议, 确认待估算的条目(Item), 并分发給估算小组成
员.
4.估算小组成员进行个人独立估算, 并填写Delphi个人估算表.
5.估算小组长汇总个人估算于Delphi估算总结
6.估算小组长召开会议组织讨论和汇总, 对于估算偏差大于30%的条目经讨论
后由小组成员重新估算.
7.估算小组长汇总最终估算并报软件项目经理
8.软件项目经理记录并归档于项目估算表
估算小组分工和责任如下所示: (深色阴影代表主要负责人)
5.项目估算评审
估算的评审通常和其他的过程评审一同进行, 也可单独进行. 如估算的评审可作为投标评估、合同评审、计划评审、里程碑评审的一个组成部分. 评审过程应参照〈〈评审过程〉〉.
6.参考资料。