XXX公司_项目估算指南
CMMI5-项目经理访谈
项目经理访谈1．向评估小组ATM介绍自己？2．综述负责项目的特点、进度和完成情况？3．是否了解组织的商业目标和过程性能目标？是由谁制定的？中恒博瑞战略规划、组织级《组织过程能力》；高层领导和EPG依据历史相关数据制定组织过程性能目标。
4．是否了解组织过程性能基线PPB和模型PPM？谁负责制定、维护和发布？基线是《中恒博瑞PPB和PPM分析细则》、模型是《中恒博瑞PPB预测模型》；EPG负责组织过程性能基线和模型的相关工作，EPG对项目经理进行过相关培训。
5．制定《量化项目管理计划》是否使用了PPB和PPM？是否接受过PPB和PPM的培训？接受过相关培训，量化项目管理计划使用了模型对新项目进行模拟，依据历史数据，可以模拟出项目周期、工作量、成本和缺陷率等数据。
使用这些数据可以总体的和阶段性的对项目进行管理和预防偏差。
6．项目的量化目标是什么？是如何制定出来的？《量化项目管理计划》中有量化目标，是依据组织的过程性能目标演化出的项目目标，总成本控制在多少。
验收质量控制在多少。
页脚内容17．量化项目管理如何对项目的里程碑进行监控？量化项目管理中，主要通过里程碑报告和量化项目管理计划的偏差进行阶段性监控，通常对进度、工作量和质量进行监控。
8．项目在何时进行根本原因分析（CAR）？当项目的进度、成本、质量超出阈值（20%）时，都需要做根本原因分析。
参见各项目的《里程碑报告》9．进行根本原因分析，有哪些干系人一起参与进行分析？项目经理、项目QA、项目阶段人员、EPG、部门经理。
10．根本原因分析过程中，使用了哪些技术？使用MINITAB的控制图对数据的稳定性进行分析，使用鱼骨图进行根本原因分析，使用帕累托原则对根本原因进行优先级分析。
11．项目结项，如何为组织提供项目数据？通过《项目度量分析报告》和《项目结项总结报告》将项目数据提供给EPG进行分析。
12．制定组织过程基线和模型需要使用哪些工具和技术？制作基线需要准确、完整的历史数据和MINITAB工具，运行模型需要CRYSTALBALL工具，进行蒙特卡洛模拟。
PP_项目估算指南_规模(多种)&工作量
目录1 目的 (2)2 范围 (2)3 术语和定义 (2)4 正文内容 (3)4.1 Delphi法 (3)4.2 类比法 (3)4.3 PERT估计法 (4)4.4 功能点估计法(FPA) (5)4.4.1 功能点法定义 (5)4.4.2 功能点法适用范围及应用 (5)4.4.3 常用术语定义 (5)4.4.4 基本估算流程 (6)4.4.5 快速方法计算功能点 (8)4.4.6 不同系统的功能点计算方法 (8)4.5 运算法 (9)4.6 专家判断法 (10)4.7 关键路径法（CPM） (10)4.8 估算系数 (10)4.8.1 开发工具系数 (10)4.8.2 规模系数 (10)4.8.3 生产力系数 (11)4.8.4 成本系数 (11)5 相关联文件 (11)6 表单和模板 (12)项目估算指南1目的本文档的目的是为项目估计提供指南；并对业界比较认可的项目估计方法进行了简单介绍，作为项目估计的参考资料。
2范围适用于组织中的所有软件项目。
3术语和定义1.SLOCa.源行代码（Source lines of code）一个SLOC就是指一个非空行的注释行或者人工编写代码行，包括可执行语句、数据定义、类定义，数据类型声明、宏定义、等价声明、输入/输出格式声明等，由工具自动产生的类、代码行，如果此代码行可由人工进行修改，并能保存修改的结果，也可计算在内，否则不计算在内。
b.SLOC经常用于估算将被要求开发的一个程序规模的总量，也可估算生产出来的软件的费用。
2.1SLOC价值和人月均代码行数a.体现一个软件生产组织的生产能力。
组织可以根据对历史项目的审计来核算组织的单行代码价值。
b.例如，以公司某项目为例，统计发现每一万行C语言源代码形成的源文件（.c和.h文件）约为280K。
某项目的源文件大小为10.3M，则可估计该项目源代码大约为38万行，该项目累计投入工作量为240人月，每人月费用为12760元（包括人均工资、福利、办公费用公摊等），则该项目中1SLOC的价值为：（240×12760）/380000＝8元/SLOC该项目的人月均代码行数为：380000/240=1583SLOC/人月3.PERT：计划评审技术（Program Evaluation an Review Technique) 是50年代末美国海军部开发北极星潜艇系统时为协调3000多个承包商和研究机构而开发的，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。
工程投资估算方案模板范文
工程投资估算方案模板范文一、项目概况项目名称：XXX工程投资估算建设地点：XXX建设单位：XXX公司项目负责人：XXX联系方式：XXX项目简介：本项目是XXX工程的投资估算方案，旨在全面评估项目的投资规模及投资分布，为项目的后续建设提供可靠的经济基础和决策依据。
二、前期准备工作1. 项目信息收集：搜集项目相关的规划、设计、招投标文件、现场勘察报告等信息。
2. 调研分析：进行项目周边环境、市场需求、竞争情况等方面的调研分析。
3. 定性分析：根据收集到的数据进行定性分析，确定项目的基本建设方案和目标。
4. 技术准备：准备投资估算所需的技术工具和软件，保证估算的准确性和可靠性。
三、投资估算方法1. 评价方法：采用成本法、收入法、市场比较法等方法综合评估投资规模。
2. 数据采集：结合项目规划文件和设计方案，确定项目所需的主要材料、设备、人工等成本。
3. 成本计算：根据采集到的数据，进行成本核算，包括建筑工程、设备采购、材料费用、施工人工、管理费用等方面的成本。
4. 收入评估：根据项目预期产出，采用收入法对项目进行收益预测。
5. 市场比较法：根据类似项目的市场价格和投资经验，对项目进行市场比较，确定投资规模的合理性。
四、投资估算内容1. 建筑工程投资：包括土建工程、装修装饰等方面的投资估算。
2. 设备采购投资：确定项目所需设备的采购成本。
3. 材料费用：计算项目所需的建筑材料、装饰材料等费用。
4. 人工成本：确定项目的施工人工成本，包括施工人员工资、社会保险费等。
5. 管理费用：对项目的管理费用进行评估。
6. 其他费用：包括税费、意外费用等方面的费用估算。
五、投资估算报告1. 编制形式：依据投资估算内容，编制成标准的投资估算报告。
2. 报告内容：包括项目概况、前期准备工作、投资估算方法、投资估算内容、风险评估、预测分析等方面的内容。
3. 审批流程：报告编制完成后，由项目负责人审查确认后，上报公司领导审核审批。
软件估算指南
软件估算指南本估算指南采用IFPUG（国际功能点用户组）制定的FPA（功能点分析）计算规则制定的。
为什么要采用本估算办法？⏹本公司以前采用的需求点经验估算法简单直接，容易操作，但存在工作量估算主观性较强、详细分析不足以及难以量化分析等缺陷。
⏹FPA（功能点分析）是目前国际通用的一种软件估算方法，目前已比较成熟，适合于研发和增强型项目的估算。
FPA方法FPA的一个特点是：与其它软件估算方法不同，对同一软件系统，不同的人采用FPA计算法计算所得的结果基本上是相同的。
FPA是一种将软件系统细分为小的组成部分，从而更易于理解和分析的办法。
功能点是软件度量的基本单位，就象度量时间所用的“小时”和度量长度所用的“公里”一样。
它并不等同于我们常说的“需求点”。
基本元素FPA将软件系统分为五个基本元素，其中包括三个为事务型元素和两个数据型元素。
事务型元素：EI 外部输入EO 外部输出EQ 外部查询数据型元素ILF 内部逻辑文件EIF 外部接口文件通过对以上五个基本元素的计算，结合功能复杂度可以初步得出一个系统的功能点数，即UFP（未调整的功能点数）在此基础上再结合系统的技术和运行特点，作为V AF（调整因子）算出AFP（调整后的功能点数）。
维护型项目的估算当一个软件项目主要是进行改错和性能调整时，FPA并不是一个非常好的估算方法。
改错时很多工作量主要用在理解及查找问题。
这时候很多工作是由一或两个人独立完成的。
个人的技巧水平将成为度量这种类型工作的主要因素。
而性能调整可能与功能没有任何关系。
估算方法估算步骤估算分两步进行：Step1：估算系统规模的UFP（未调整的功能点数）Step2：确定V AF（调整因子）Step3：估算AFP（调整后的功能点数）Step2：在规模的基础上根据软件生产率计算出所需的Effort（工作量，以人/天为单位）估算系统规模的UFP首先，对需求点进行分类，可分为两类：新增、修改。
然后根据具体类别加以统计，对涉及的EI、EO、EQ、ILF、EIF分别计数，两类的区别在于对修改类只能计算修改所影响的部分，不能将不变的部分也计算在内。
房地产估价报告书(实用5篇)
房地产估价报告书第1篇一、委估项目XXX公司所属房产抵押贷款估价项目二、委托方名称：XXX公司地址：XXX三、估价方名称：XXX房地产评估咨询有限公司地址：XXX证书号：XXX 资质等级：XXX法定**人：XXX四、估价对象概况估价对象位于XXX，其合法产权人为XXX公司，建筑面积共*方米。
其中主楼一幢，1-5层，混合结构，建筑面积为，*均层高米，建成于2003年，于2007年底重新改造装修，外观九五成新，房屋所有权证号码为XXX。
副楼一幢，1-3层，混合结构，建筑面积为，*均层高米，建成于2003年，外观九成新，房屋所有权证号码为XXX。
五、估价目的为确定房产抵押贷款额度提供参考依据而评估房产抵押价值。
六、估价时点2014年8月15日七、价值定义采用公开市场价值标准八、估价原则本次评估在遵循公正、公*、公开、客观、科学原则的前提下，还应依据如下原则：1. 合法原则，以估价对象的合法使用、合法处分为前提。
2. 最高最佳使用原则，以估价对象最高最佳使用为前提。
3. 替代原则，要求估价结果不得明显偏离类似房地产在同等条件下的正常价格。
4. 估价时点原则，要求估价结果应是估价时点的客观合理价格。
九、估价依据1. 委托方提供的资料(1)委托书;(2)委托方企业营业执照复印件;(3)房屋所有权证复印件。
2. 国家标准GB/T50291-1999《房地产估价规范》。
3. 国家和地方的有关法律、法规和有关规定。
4. 估价机构和估价人员掌握和收集的\'有关资料。
十、估价方法估价对象为商业房产，同一供求圈内的整体成交案例极少，无法适用市场比较法;同时由于其具有明显的收益性，因此适宜选用收益法进行评估。
十一、估价结果估价人员根据估价目的，遵循估价原则，按照估价程序，采用科学的方法，在认真分析现有资料的基础上，经过周密、细致的测算，确定该估价对象在评估基准日的抵押价值为***贰仟贰佰陆拾伍万叁仟肆佰元整(￥万元)。
项目概算申请书范本
项目概算申请书范本尊敬的XX公司领导：您好！我代表项目团队，向您提交关于“XXX项目”的概算申请书。
首先，感谢您在百忙之中抽出时间审阅我们的申请。
以下是我们对项目的详细介绍和概算申请。
一、项目背景及目标随着我国经济的持续快速发展，对XXX行业的需求日益增长。
为了满足市场需求，提高我公司在行业内的竞争力，我们计划实施“XXX项目”。
该项目旨在提升产品质量和生产效率，降低成本，实现可持续发展。
二、项目内容与实施方案1. 项目内容：项目主要包括以下几个方面：（1）设备购置：购置先进的生产设备，提高生产效率和产品质量。
（2）技术研发：加强技术研发，开发具有竞争力的新产品。
（3）生产线改造：优化生产线布局，提高生产流程的合理性。
（4）信息化建设：建立完善的信息化管理系统，提高管理效率。
2. 实施方案：（1）设备购置：根据产品需求和技术要求，选择合适的设备，进行购置。
（2）技术研发：组织专业团队进行技术研发，与高校和科研机构合作，共享资源。
（3）生产线改造：对现有生产线进行合理布局和改造，提高生产效率。
（4）信息化建设：采购成熟的信息化管理软件，进行系统部署和培训。
三、项目投资估算根据项目内容和实施方案，我们对项目投资进行了初步估算。
项目总投资约为XX万元，具体投资构成如下：1. 设备购置费用：XX万元2. 技术研发费用：XX万元3. 生产线改造费用：XX万元4. 信息化建设费用：XX万元5. 其他费用：XX万元四、项目效益预测1. 经济效益：项目实施后，预计年产量将提高XX%，产品质量将达到行业领先水平，从而提高产品销售价格，增加公司收入。
同时，项目将降低生产成本，提高利润率。
2. 社会效益：项目实施后将提供更多的就业岗位，为社会创造更多的价值。
同时，项目的实施将推动行业发展，提升我国在国际市场的竞争力。
五、资金需求及还款计划1. 资金需求：项目总投资约为XX万元，其中自有资金为XX万元，贷款金额为XX万元。
软件项目估算指南(CMMI5)
项目估算指南Version 1.1文档名称：CMMI5-项目估算指南-V1.1.doc修订历史记录目录1 目的 (4)2 围 (4)3 术语、缩写词 (4)4 估算过程 (4)4.1简要说明 (4)4.2流程图 (5)4.2.1自顶向下的方法 (5)4.2.2自底向上的方法 (6)4.3估算规程 (6)4.4裁剪指南 (7)5 估算方法 (7)5.1UCP估算算法 (7)5.1.1估算UUCP (8)5.1.2估算TCF调整因子 (8)5.1.3估算EF调整因子 (9)5.1.4估算UCP (10)5.1.5估算工作量 (10)5.1.6估算进度 (10)5.1.7估算成本 (11)6 附录 (11)6.1生产率数据来源 (11)6.2进度估算数据来源 (11)项目估算指南1目的本文用于估算软件项目的规模、进度、工作量、成本，以指导项目作出合理的估算。
2围本文件包括软件项目估算的各个方面，包括规模、进度、工作量、成本，并包括其在项目的中的分布估算。
本文件适用于公司所有项目。
3术语、缩写词UCP Use Case Point，用例点4估算过程4.1简要说明准确的估算是最大可能加快开发速度的基础，没有准确的进度估算，再有效的进度计划也无从谈起。
不切实际的估算、不正确的期望是带来项目问题的主要原因。
估算是一个不断改进的过程，只有当详细地理解了每个功能，你才有可能准确估算出软件开发的进度和成本。
因此，能够提前做出的决策越多，估算的精确度就越高。
准确的估算可以更好的控制项目的规模、进度、成本。
工作量和进度估算通常在提交建议书及制定项目计划时进行，在项目实施过程中，也可能要对工作量和进度重新估计。
对于软件规模的估算主要有三种方法：代码行，功能点，用例点。
本公司现在主要使用用例点方法。
对于工作量的估计，主要有两种方法：⏹自顶向下的方法（Top-down approach），用一个简单的方程从估计的规模求出估计的总工作量，各阶段的工作量可以根据它们占总工作量的百分比而得到。
关于项目预算的请示
关于项目预算的请示致 xxx 部门/团队/领导的项目预算请示函日期：[日期]尊敬的 [部门/团队/领导姓名]：首先，我代表 [公司/机构名称] 项目组，向您致以诚挚的问候。
我特此函达，以请示关于项目预算的事宜，并希望得到您的指导和批准。
一、项目背景和目标我们的项目致力于 [项目的目标和愿景]，旨在 [项目的具体目标和重要性]。
通过该项目，我们希望 [项目预期的成果和效益]。
为了确保项目成功实施，我们认为制定合理、科学的项目预算是至关重要的。
二、预算编制原则在编制项目预算时，我们遵循以下原则：1. 确保项目目标的实现：项目预算应能够满足项目的各项需求，确保项目能够按时、按质、按量地完成。
2. 合理性和可行性：预算编制应合理、可行，考虑到项目所需资源的估计和实际可得性，充分综合分析各项因素，保证预算的可行性。
3. 控制成本和效益最大化：我们将注重控制项目成本，通过优化资源配置和管理，追求效益最大化，提高项目的整体经济效益。
三、项目预算构成根据我们对项目需求的初步估算和分析，整体项目预算分为以下几个方面：1. 人力资源费用：包括项目人员的薪资、福利、培训和招募成本等。
2. 物力资源费用：涵盖项目所需设备、办公用品、材料及其他资源的采购与维护成本。
3. 外部支出费用：涉及到项目外部合作、咨询、培训、广告宣传等相关费用。
4. 运营费用：包括项目运营所需的日常开支，如办公场地租金、水电费、通信费等。
5. 其他费用：此部分费用为项目具体实施中可能出现的额外费用，如突发事件应对费用、变更管理费用等。
四、项目预算金额及说明根据我们的初步估算，项目预算总额为 [金额]，具体分配如下：1. 人力资源费用：[金额]，由于项目需要[详细说明人力资源需求]。
2. 物力资源费用：[金额]，具体包括 [详细说明物力资源需求]。
3. 外部支出费用：[金额]，主要用于 [详细说明外部支出内容和目的]。
4. 运营费用：[金额]，主要用于 [详细说明运营费用项目]。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
XXX公司软件过程体系项目估算指南编制人：***审核人：***批准人：***CMMI管理部目录项目估算指南 (1)1概述 (3)1.1目的 (3)1.2适用范围 (4)1.3术语及定义 (4)1.4方针 (4)2项目估算流程 (4)3明确项目范围 (5)4定义项目生命周期模型 (11)4.1瀑布模型/改进的瀑布模型 (11)4.2螺旋模型 (13)4.3增量和迭代模型 (14)4.4原型法 (15)4.5建议 (16)5工作分解和任务估算 (16)6估算值确定 (18)6.1通过PPM确定总工作量和规模 (18)6.2通过PPB确定各阶段工作量 (18)6.3估算次数 (18)6.4专家领域估算 (19)7成本估计 (20)8裁剪说明 (20)1概述1.1目的项目估算主要通过组织性能基线和组织性能模型估算项目的规模、工作量和周期等参数，为制定项目计划做好基础。
1.2适用范围本文档适合公司所有项目。
1.3术语及定义WBS：工作分解结构。
Delphi法：一种方法。
该方法主要用于一些预测和预测的场合，广泛用来进行预测、决策分析和编制规划工作。
大项目：(工作量>1300人天)且(项目周期>10个月)中项目：(工作量=220至 1300人天)且(项目周期=5 至 10个月)小项目：（工作量<220人天）或 (项目周期<4个月)PPB: 组织性能基线。
PPM：组织性能模型。
1.4方针在项目策划阶段通过PPB和PPM提高估算精度，保证在项目监督管理上有据可依。
现阶段保证在项目工作量估算与实际工作量估算差值控制在10%左右。
2项目估算流程3明确项目范围明确项目的范围，可以用项目的WBS来表示。
但应该注意以下几点：1.WBS分解颗粒度要适合，对于近期的任务颗粒度要小于5天，长期的任务颗粒度要小于10天。
2.WBS的分解是逐步细化的过程。
3.一般先以产品为线索进行WBS分解，然后以活动为主线进行分解。
4.WBS中只是对任务拆分，不分配资源，WBS不是进度表。
5.在做WBS工作分解时，小项目WBS要分解到第2层，中项目WBS要分解到第3层、大项目WBS要分解到第4-5层。
同时根据用户需求，分解产品的功能，制定产品的WBS，根据项目的不同类型，进行工作分解和任务时可参考以下模板：图1 用于项目估计WBS示意图集成实施类项目范围参考下图内容：图2图3集成实施类WBS分解模板软件开发类项目范围参考下图内容：图4软件开发类WBS分解模板维护类项目范围参考下图内容：图5维护类WBS分解模板4定义项目生命周期模型参考公司定义的项目生命周期模型，选择估算项目的生命周期模型。
4.1瀑布模型/改进的瀑布模型虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型。
瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行，每一个阶段都可以定义明确的产出物和验证准则。
瀑布模型在每一个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下一个阶段。
由于需要对每一个阶段进行验证，瀑布模型要求每一个阶段都有明确的文档产出，对于严格的瀑布模型每一个阶段都不应该重叠，而应该是在评审通过，相关的产出物都已经基线后才能够进入到下一个阶段。
瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够提前的被发现和解决。
采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性。
但对于前期需求不明确，而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况，这也是必须要考虑的问题。
很多人往往会以进度约束而不选择瀑布模型，这往往是一个错误的观点。
导致这种情况的一个关键因素往往是概念需求阶段人力不足。
因此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太大的差别。
反而是很多项目对于迭代或敏捷模型用不好，为了赶进度在前期需求不明确，没有经过一个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度。
架构设计是软件开发中一个重要的关注点。
因此在RUP中也提及到软件开发要以架构为核心。
因此在架构设计完成后系统会被分为相关的子系统和功能模块。
每个功能模块间的接口都可以定义清楚。
在这种情况下，当模块B的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才开始编码，因此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路。
这是瀑布模型的一种最重要的改进思路，也可以说这是一种增量开发的模型。
当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候，这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作。
这种方式的最大问题就是没有一个完全总体的设计，架构设计人员无法在洞悉了所有需求后从系统的可扩展性，复用等方面总体规划。
在项目管理中有一种压缩进度的方法叫赶工，因此瀑布模型的另外改进处就在适当的重叠各个阶段过程，达到资源的有效利用。
比如我们通过讨论，会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来。
4.2螺旋模型首先螺旋模型是遵从瀑布模型的。
即需求->架构->设计->开发->测试的路线。
螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的。
通过将瀑布模型的多个阶段转化到多个迭代过程中，以减少项目的风险。
螺旋模型的每一次迭代都包含了以下六个步骤1.决定目标，替代方案和约束。
2.识别和解决项目的风险。
3.评估技术方案和替代解决方案。
4.开发本次迭代的交付物和验证迭代产出的正确性。
5.计划下一次迭代。
6.提交下一次迭代的步骤和方案。
螺旋模型实现了随着项目成本投入不断增加，风险逐渐减小。
以帮我我们加强项目的管理和跟踪，在每次迭代结束后都需要对产出物进行评估和验证，当发现无法继续进行下去时可以及早的终止项目。
螺旋模型复杂的地方在于尽责，专心和知识渊博的管理。
因为对于每一次迭代我们要制定出清晰的目标，分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情。
螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段。
如第二次迭代重点是需求，第三次迭代是总体设计和后续设计开发计划等。
因此这是和RUP 提倡的迭代模型是有区别的，RUP的每一次迭代都会包含需求，设计，开发和测试等各个阶段的活动。
RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作。
4.3增量和迭代模型增量迭代是RUP统一过程常采用的软件开发生命周期模型。
增量和迭代有区别但两者又经常一起使用。
所以这里要先解释下增量和迭代的概念。
假设现在要开发A，B，C，D四个大的业务功能，每个功能都需要开发两周的时间。
则对于增量方法而言可以将四个功能分为两次增量来完成，第一个增量完成A，B功能，第二次增量完成C，D功能;而对于迭代开发来将则是分两次迭代来开发，第一次迭代完成A，B，C，D四个基本业务功能但不含复杂的业务逻辑，而第二个功能再逐渐细化补充完整相关的业务逻辑。
在第一个月过去后采用增量开始时候A，B全部开发完成而C，D还一点都没有动;而采用迭代开发的时候A，B，C，D四个的基础功能都已经完成。
RUP强调的每次迭代都包含了需求，设计和开发，测试等各个过程，而且每次迭代完成后都是一个可以交付的原型。
迭代不是并行，在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程。
迭代周期的长度跟项目的周期和规模有很大的关系。
小型项目可以一周一次迭代，而对于大型项目则可以2-4周一次迭代。
如果项目没有一个很好的架构师，很难规划出每次迭代的内容和要到达的目标，验证相关的交付和产出。
因此迭代模型虽然能够很好的满足与用户的交付，需求的变化，但确是一个很难真正用好的模型。
就对风险的消除上，增量和迭代模型都能够很好的控制前期的风险并解决。
但迭代模型在这方面更有优势。
迭代模型更多的可以从总体方面去系统的思考问题，从最早就可以给出相对完善的框架或原型，后期的每次迭代都是针对上次迭代的逐步精化。
业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量。
同时每个增量也可以是独立发布的小版本。
由于系统的总体设计往往对一个系统的架构和可扩展性有重大的影响，因此我们推荐的增量最好是在架构设计完成后再开始进行增量，这样可以更好的保证系统的健壮性和可扩展性。
4.4原型法原型一般都不是单独采用的一种生命周期模型，往往会结合瀑布和增量迭代等方法一起使用。
对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型。
对于迭代开发来讲，每一个迭代周期的产出都可以看做是下个阶段要精化的原型。
而对于瀑布模型开发来讲，我们在需求阶段也可以进行界面和操作建模，形成DEMO后和用户做进一部的需求沟通和确认。
当你的用户没有信息系统的使用经验，你的系统分析员也没有过多的需求分析和挖掘经验的时候，需求分析和调研过程则更需要是一个启发式的过程。
而原型则是这种很好的启发式方法，可以快速的挖掘用户需求并达成需求理解上的一致。
否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西。
原型可以分为抛弃型的和不抛弃型的。
如果原型仅仅是需求阶段方面和用户沟通画的DEMO，则这种原型一般都建议抛弃掉。
而对于迭代开发来将，每次迭代的产出都是可以独立运行和包含基础功能的系统，是后续细化的基础，这类原型一般都不建议抛弃，后期的设计开发也要基于该原型逐渐的进行完善。
4.5建议1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型。
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型。
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型4.在需求不稳定情况下尽量采用增量迭代模型5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型7.对于全新系统的开发必须在总体设计完成后再开始增量或并行。
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型。
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则。
5工作分解和任务估算WBS是项目管理的重要基础，制定正确的WBS是项目经理管理项目的核心课题。
WBS是把项目工作内容的分解，在此基础之上再进行资源的分配、进度计划并估计项目的工作量和成本，参照《项目进度表》模板输出。