软件项目管理背诵总结

将老师所发ppt的知识点整理，方便查阅与背诵。

1. 概述

1.1 什么是项目？

答：

1. 项目是为了创造一个唯一的产品或提供一个唯一的服务（目标性）而进行的临时性的努力；
2. 是以一套独特而相互联系的任务为前提，有效利用资源（资源约束性），在一定时间内满足一系列特定目标的多项相关工作的总称。

1.2 项目有那些特征？

答：

1. 目标性
2. 临时性
3. 独特性
4. 资源约束性
5. 不确定性

1.3 项目于日常工作有什么区别？

答：

1. 时限：项目是一次性的，日常运作是重复进行的
2. 追求：项目是以目标为导向的，日常运作是通过效率和有效性体现的
3. 组织：项目是通过与项目经理及其团队工作完成的，而日常运作是职能式的线性管理
4. 管理：项目存在大量的变更管理，而日常运作基本保持持续的连贯性的

1.4 如何衡量一个项目是否成功？

答：

1. 衡量项目是否成功，应该看该项目是否在工程允许范围内按照成本预算和进度计划，生产出客户满意的产品
2. 四要素
   1. 项目范围
   2. 成本
   3. 进度
   4. 客户满意度

1.5 软件项目还有什么特征？

答：

1. 抽象性
2. 复杂性
3. 经验在软件项目中起很大作用
4. 变更是软件项目中常见现象
5. 项目的独特性和临时性决定项目是渐进明细的
6. 目前，软件项目的开发较其他领域的项目缺少规范
7. 软件项目四要素
   1. 过程，结果，所需资源，委托人。

1.6 什么是项目管理？

答：

指在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望

1. 知识领域划分：项目范围，进度，成本，质量，人力资源，沟通，风险，变更管理
2. 项目干系人：指参与项目和受项目活动影响的人，包括项目发起人、项目组、 协助人员、客户、使用者、供应商，甚至是项目的反对者。

1.7 项目管理的内容可以从几个方面划分？

答：

1. 管理职能角度

2. 项目管理包括项目计划、组织、人事 安排、控制、协调等方面的内容

3. 项目获得的全过程角度

   1. 项目管理包括项目决策、项目规划与设计、项目的招投标、项目实施、项目终结与后评价等 方面的内容

4. 项目投入资源要素角度

   1. 项目管理包括项目资金财务 管理、项目人事劳动管理、项目材料设备管理、项目技术管理、项目信息管理、项目合同管理等方面的内容

5. 项目目标和约束角度

   1. 项目管理包括项目进度管理、 项目成本管理、项目质量管理等方面的内容

1.8 项目管理具有什么特征？

答：

1. 创造性
   1. 项目的一次性特点，决定了每实施一个项目都要具有创新性。
2. 项目管理是一项复杂的工作，具有较强的不确定性
   1. 项目一般由多个部分组成，工作跨越多个组织、多个学科、多个 行业，可供参考的经验很少甚至没有
3. 项目管理需要专门的组织和团队
   1. 项目管理通常要跨越部门的界限，在工作中将会遇到许多不同部 门的人员
4. 项目经理的作用非常重要
   1. 项目经理要在有限的资源和时间的约束下，运用系统的观点、科 学合理的方法对与项目相关的所有工作进行有效的管理，因此项 目经理对项目的成败起着非常重要的作用。

1.9 软件项目管理有什么特征？

答：

1. 软件是纯知识产品，其开发进度和质量很难估计和度量，生 产效率也难以预测和保障。需求在开始难以明确，与过早签 订合同是矛盾的
2. 周期长，复杂度高，变数多
3. 软件需要满足一群人的期望，其对项目的关注点不同，利益 也不同
4. 软件项目管理的目的是让软件项目能在控制之下，以预定成本，按质完成

1.10 项目管理的十个知识领域与五个标准化过程组是什么？

答：

十个知识领域：

1. 项目集成管理 (project integration management)
2. 项目范围管理 (project scope management)
3. 项目进度管理 (project schedule management)
4. 项目成本管理 (project cost management)
5. 项目质量管理 (project quality management)
6. 项目资源管理 (project resource management)
7. 项目沟通管理 (project communication management)
8. 项目风险管理 (project risk management)
9. 项目采购管理 (project procurement management)
10. 项目干系人管理 (project stakeholder management)

五个标准化过程：也称项目管理生命周期的5个阶段。

1. 启动过程组
2. 计划过程组
3. 控制过程组
4. 执行过程组
5. 收尾过程组

1.11软件过程是什么？

答:

1. 软件项目的开发过程主要有系统调研、需求分析、概要设计、详细 设计、编码、测试、实施与维护等.
2. 软件过程包括：流程、技术、产品、活动间关系、角色、工具等， 是软件开发过程的各个方面因素的有机结合

1.12 过程管理是什么？

答：

1. 从做过的项目中总结出的一些完善的过程，称为最佳实践
2. 软件过程管理就是对最佳实践进行有效积累，形成可重复的过程， 使最佳实践可以在机构内共享
3. 其目的是要让过程能够被共享、重用，并得到持续改进
4. 过程管理的内容包括过程定义和过程改进
   1. 过程定义：对最佳实践进行总结，形成一套稳定的可重复的软件过程
   2. 过程改进：根据实践中对过程的使用情况，进行优化

1.13 过程管理与项目管理有什么关系？

答：

1. 项目管理用于保证项目的成功
2. 孤傲从管理用于管理最佳实践
3. 这两者不是相互孤立的，而是有机地紧密地结合的
4. 过程管理的成果即软件过程可以在项目管理中辅助于项目管理工作。

1.14 什么是敏捷项目开发？

答：

1. 敏捷软件开发(agile software development) ：是一个灵活的开发方法，用于在一个动态的环境中向干系人快速交付产品
2. 主要特点是关注持续地交付价值，通过迭代和快速的用户反馈管理不确定性和应对变更
3. 4条价值观：
   1. 个体和交互胜过过程和工具 (individual and interaction over process and tool)
   2. 可以工作的软件胜过面面俱到的文档 (working software over comprehensive documentation)
   3. 客户合作胜过合同谈判 (customer collaboration over contract negotiation)
   4. 响应变化胜过遵循计划 (responding to change over following a plan)
4. 12个敏捷原则
   1. ① 最先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。 CFAIR
   2. ② 即使到了开发的后期，也欢迎改变需求。敏捷过程利用适应变化来为客户创造竞 争优势。
   3. ③ 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时 间间隔越短越好。
   4. ④ 在整个项目开发期间，业务人员和开发人员尽可能地在一起工作。
   5. ⑤ 围绕被激励起来的个体组成团队来构建项目，给他们提供所需的环境与支持，并且信任他们能够完成工作。
   6. ⑥ 在团队内部及团队之间，最有效果并且最有效率的传递信息的方式就是面对面的 交流。
   7. ⑦ 可以工作的软件是首要的进度度量标准。
   8. ⑧ 敏捷过程提倡平稳的开发。发起人、开发者和用户应该能够保持一个长期的、恒 定的开发速度。
   9. ⑨ 不断地关注优秀的技能和好的设计会增强敏捷的能力。
   10. ⑩ 简单——使未完成的工作最大化的艺术，是根本的。
   11. ⑪ 最好的架构、需求和设计出自于自组织的团队。
   12. ⑫ 每隔一定的时间，团队会在如何才能更有效地工作方面进行反省，然后相应地调 整自己的行为。

2. 项目初始

2.1 如何确立一个项目？

答：

1. 项目评估
2. 项目立项
3. 项目授权
4. 确定生存期模型

2.2 什么是项目评估？如何项目评估？

答：

1. 真正启动一个项目之前，需要对项目进行评估，主要从战略、操作性、计划、技术、社会可行性、市场可行性、经 济可行性等方面进行评估
2. 成本效益分析方法是评价项目经济效益的主要方法，它是将系统开发和运行所需要的成本与得到的效益进行比较，如果成本高于收益则表明项目亏损，如果成本小于效益则表明项目值得投资

2.3 请解释成本效益分析方法中名词。

答：

1. 现金流预测：是描述何时支出费用、何时有收益的过程

2. 净利润：是在项目的整个生命周期中总成本和总收入之差

3. 投资回报期：是达到收支平衡或者偿还初始投入所花费的时间

4. 投资回报率：（会计回报率）用于比较净收益率与需要的投入，常见的最简 单的公式是 投资回报率=(平均年利润/总投资)x 100%

5. 净现值：是一种项目评价技术，考虑了项目的收益率和要产生的现金流的时限，它是基于这样的观点：今天收到100元要比明年收到的100元更好

6. 内部回报率：指可以直接与利润比较的百分比回报。如果借贷的资本少于 10%，或者如果资本不投入到回报大于10%的其他地方，则具有10%的内部回报率的项目是值得做的

2.4 如何进行Make or Buy决策？

答：

对比因素	自制的理由	购买的理由
成本因素	自制成本低	购买成本低
技术能力	可以采用自制的技巧	不会自制
工作量管理	工作量可控	工作量小
战略价值	可以获得知识产权	购买更有益
风险与学习	学习新的技能	转移风险
资源条件	有可用的开发人员	有很好的供货商
项目重点	核心项目工作	项目可以将注意力放在其他工作上

2.5 项目的立项需要完成什么工作？

答：

1. 明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可。这个阶段称为立项阶段。
2. 立项是要解决做什么的问题，需要确定开发的项目，关注点是效益和利润。项目立项报告的核心内容是确定立项前期需要投入多少， 能否盈利，什么时候能够盈利，能否持久的盈利， 等等

2.6 合同项目立项的流程是怎么样的？

答：

合同项目立项是指企业与外部客户通过签订商业合同来启动的项目。整体流程分为三个主要阶段：

1. 甲方主导阶段：招标书定义 → 供方选择
2. 乙方响应阶段：项目分析 → 提交建议书
3. 双方合作阶段：合同签署 → 项目启动

项目启动准备：

• GAP期：合同签订后的缓冲准备期，用于团队组建和资源调配
• Kick off：召开项目启动会，标志项目正式开始
• Service Delivery：进入正式的服务交付阶段

2.7 内部项目立项的流程是怎么样的？

对比维度	合同项目	内部项目
约束机制	商业合同	内部协议
流程复杂度	复杂（招标、谈判、法务）	简化（重点在协调）
风险类型	商业风险、合规风险	管理风险、协调风险
管理重点	盈利性、合规性	协作性、效率性
签署过程	正式合同签署	内部协议确认

关键差异总结：

• 内部项目无需复杂的招投标流程
• 协议主要用于明确分工，而非商业保障
• 更注重部门间沟通协调和资源整合效率

2.8 什么是项目授权？要做什么？

答：

1. 对项目进行授权和初始化，以便确认相关的人知晓这个项目

2. 形式：文档化输出，主要是项目章程

2.9 什么是项目章程？

答：

1. 确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。
2. 项目章程类似项目的授权书，相当于对项目的正式授权，表明项目可以有效地开始了。项目章程授权项目，建立了项目经理的责任心 、发起人的主人翁意识及项目团队的团队意识。

2.10 项目经理有什么责任？

答：

1. 开发计划 项目经理的首要任务就是开发计划。完善合理的计划对于项目的成功至关重要。项目经理 要在对 所有的合同、需求等熟知、掌握的基础上，明确项目目标，并就该.目标与项目客户达成一致，同 时告知项目团队成员，然后为实现项目目标制订基本的实施计划（成本、进度、产品 质量）
2. 组织实施 项目经理组织实施项目主要体现在两个方面：第一，设计项目团队的组织结构图，对各职位的工 作内容进行描述，并安排合适的人选，组织项目开发；第二，对于大型项目，项目经理 应该决定 哪些任务由项目团队完成，哪些由承包商完成
3. 项目控制 在项目实施过程中，项目经理要时时监视项目的运行，根据项目实际进展情况调控项目， 必要的 时候，调整各项计划方案，积极预防，防止意外的发生；及时解决出现的问题，同时预测可能的 风险和问题，保证项目在预定的时间、资金、资源下顺利完成。
4. 项目组织的领导者，管理者，决策者，分析者，计划者，控制者，组织者，评价者，协调者

2.11 软件项目生存期模型有什么基本特征？

答：

1. 描述了开发的主要阶段
2. 定义了每一个阶段要完成的主要过程和活动
3. 规范了每一个阶段的输入和输出

2.12 有哪些常用的生存期模型？给出它们的简单介绍和特点

答：

模型名称	简单介绍	主要特点	适用范围
瀑布模型 (Waterfall)	按照需求分析、系统设计、编码、测试、维护的顺序逐步进行，每个阶段完成后才进入下一阶段	• 线性顺序执行，阶段间有明确里程碑 • 每个阶段都有详细文档输出 • 前一阶段完成后才能进入下一阶段 • 结构清晰，管理简单	• ✅优先选择：前期需求明确且稳定的项目 • 技术成熟、风险较低的项目 • 编码人员经验较少的团队 • 多个独立功能开发（功能内遵循瀑布）
V模型 (V-shaped)	瀑布模型的改进版，强调测试与开发阶段的对应关系，是改进型瀑布模型的典型代表	• 开发阶段与测试阶段一一对应 • 强调早期测试计划和验证 • 左臂开发过程，右臂测试过程 • 重视质量保证和缺陷预防	• 前期需求明确的高质量要求项目 • 安全关键型系统 • 对质量要求极高的系统 • 作为瀑布模型的改进选择
快速原型模型 (Rapid Prototyping)	通过快速构建系统原型帮助用户理解需求，在用户反馈基础上不断完善系统	• 快速构建可运行的原型 • 用户早期参与，频繁反馈 • 迭代式开发和改进 • 降低需求理解风险	• 🔧必须使用：用户无信息系统使用经验，需求分析人员技能不足 • 需求不明确或易变的项目 • 用户界面要求高的系统 • 可与增量、迭代综合使用
增量模型 (Incremental)	将软件分解为多个增量，每个增量都包含完整的开发周期，逐步交付可用的软件产品	• 分批次交付功能 • 每个增量都是完整的子系统 • 用户可以早期获得部分功能 • 降低项目整体风险	• 💰资金限制：资金和成本无法一次到位 • 📈需求不稳定：优先采用增量迭代模型 • 软件产品分多个版本发布 • ⚠️注意：全新系统需总体设计完成后开始
螺旋式模型 (Spiral)	结合瀑布和原型模型优点，通过风险驱动的迭代开发过程，每个迭代都包含风险分析	• 风险驱动的开发过程 • 四象限：确定目标、风险分析、开发测试、规划下轮 • 适应性强，可处理需求变化 • 强调风险管理	• 🔥高不确定性：不确定性因素很多，很多东西前面无法计划 • 高风险、大型复杂项目 • 创新性技术项目 • 需要有经验的开发团队
快速应用开发 (RAD)	强调快速开发和交付，通过并行开发、重用组件和用户参与来缩短开发周期	• 开发周期短（60-90天） • 大量使用现有组件和工具 • 用户深度参与开发过程 • 并行开发多个模块	• 时间紧迫的业务应用系统 • 有丰富组件库的项目 • 用户需求相对稳定的项目 • 需要快速交付价值的项目
渐近式阶段模型	通过多个阶段逐步接近最终目标，每个阶段都有明确的交付物和评估标准	• 阶段性目标明确 • 逐步逼近最终目标 • 每阶段都有里程碑检查 • 可根据评估结果调整方向	• 探索性项目，目标逐步明确 • 需要阶段性评估和调整的长期项目 • 研究开发类项目 • 目标不够明确的项目
敏捷型模型 (Agile)	强调个体和互动、工作软件、客户合作和响应变化，通过短迭代周期快速交付价值	• 短迭代周期（1-4周） • 持续交付可工作软件 • 客户深度参与和反馈 • 拥抱变化，快速响应 • 团队自组织和协作	• 需求变化频繁的创新项目 • 客户可频繁参与的项目 • ❌不建议：编码人员经验较少时 • 小到中型团队项目 • 可与原型模型综合使用

🔄 模型组合使用规则：

• 增量、迭代和原型可以综合使用
• 每一次增量或迭代都必须有明确的交付准则
• 对于全新系统的开发必须在总体设计完成后再开始增量或并行

👥 团队经验考虑：

• 编码人员经验较少：建议采用瀑布模型，避免敏捷或迭代等复杂模型
• 有经验团队：可选择螺旋、敏捷等复杂模型

🎯 并行开发策略：

• 多个独立功能开发：可在需求阶段分功能并行，但每个功能内都应遵循瀑布模型

3.项目范围计划——需求管理

3.1 什么是软件需求？

答：

1. 软件需求是指用户对软件的功能和性能的要求。
2. 软件需求三个层次
   • 业务需求：组织机构或客户对系统，产品高层次的目标要求，由管理人员或市场分析人员确定
   • 用户需求：用户通过使用本软件产品必须完成的任务，用户协助提供
   • 功能需求：开发人员必须实现的软件功能
3. 软件需求规格
   • 描述了软件系统应具有的外部行为，即系统展现给用户的行为和执行的操作

4. 需求类型:
   • 功能需求：系统必须执行的功能
   • 非功能需求：对实际使用环境所做的要求，如性能要求，可靠性 ，安全性
     • 非功能需求比功能需求要求更严格，更不易满足

3.2 什么是需求工程？有什么作用？

答：

1. 80年代中期，形成了软件工程的子领域——需求工程
2. 需求工程：指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。
3. 作用：保证软件需求以一种技术形式描述一个产品应具有的功能，性能和性质
4. 5个独立过程：获取，分析，规格，验证，变更

3.3 什么是需求获取？

答：

1. 需求获取是指通过与用户的交流，对现有系统的观察及对任务进行 分析，从而开发、捕获和修订用户的需求。
2. 主要任务：和用户方的领导层，业务层人员的访谈式沟通
3. 目的：从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构，业务流程，硬件环境，软件环境，现有运行系统等具体情况和客观的信息，建立起良好的沟通渠道和方式。

3.4 需求获取有哪些活动？

答：

1. 了解客户方的所有用户类型及潜在的类型，然后根据他们的要求来确定系统的整体目标和系统的工作范围。
2. 进行需求调查，对用户进行访谈和调研。
3. 需求分析人员对收集到的用户需求做进一步的分析和整理
4. 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求。

3.5 需求获取需要注意什么？

1. 识别真正的客户
2. 正确理解客户的需求
3. 具备较强的忍耐力和清晰的思维
4. 说服和教育客户
5. 需求获取阶段一般需要建立需求分析小组，进行充分交流，互相学习，同时要实地考察访谈，收集相关资料，进行语言交流，必要时可以采用图形、表格等工具。

3.6 什么是需求分析？

答：

1. 需求分析又称为需求建模

2. 需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义。

3. 应有足够的重视，并分配充足的时间和人力，要让有经验的系统分 析员负责，切忌让项目新手或程序员负责

4. 需求分析的结果是提供需求分析模型，它是产品的原型样本，使最 终产品更接近于解决需求，提高了用户对产品的满意度，从而使产 品成为真正优质合格的产品

3.7 需求分析有哪些活动？

答：

1. 以图形表示的方式描述系统的整体结构，包括系统的边界与接口。
2. 通过原型、页面流或其他方式向用户提供可视化的界面，用户可以对需求做出自己的评价。
3. 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系 、实体之间的状态转换等方面的内容。
4. 需求分析的基本策略是采用头脑风暴、专家评审、焦点会议组等方式 进行具体的流程细化、数据项的确认
5. 必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清 晰地向用户描述系统的业务流设计目标
6. 用户方可以通过审查业务流程报告、数据项表及操作开发方提供的原 型系统来提出反馈意见，并对可接受的报告、文档签字确认。
7. 在项目需求分析阶段，对问题的描述要足够细致
   • 应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准

3.8 什么是需求规格编写？

答：

1. 软件需求规格的编制是为了使用户和软件开发者双方对该软件的初 始规定有一个共同的理解，使之成为整个开发工作的基础
2. 需求分析完成的标志是提交一份完整的软件需求规格说明书 (SRS)
3. 需求规格说明书为客户和开发者之间建立一个约定，准确地陈述了要交付给客户什么。
   • 软件需求规格说明书的格式可以根据项目的具体情况采用不同的格式，没有统一的标准

3.9 什么是需求验证？

答：

1. 定义：需求规格提交后，开发人员需要与客户对需求分析的结果进行验证， 以需求规格说明书为输入。
2. 目的：以求需求规格中定义的需求必须正确、准确地反映用户的意图
3. 作用：验证需求的正确性及其质量能大大减少项目后期的返工现象

3.10 需求验证要保证什么性质？

答：

​ 正确性，一致性，完整性，可行性，必要性，可检验性，可跟踪性，最后的签字

3.11 为什么要有需求变更管理？

答：

1. 需求变更是软件项目一个突出的特点，也是软件项目最为普遍的一个特点
2. 需求变更是导致项目失败的主要原因之一。
3. 需求变更成本可以占项目总成本的40％

3.12 需求变更管理要完成什么工作？

答：

1. **建立需求基线。**需求基线是需求变更的依据。此后每次变更并 经过评审后，都要重新确定新的需求基线
2. **确定需求变更控制过程。**制定变更控制流程，并形成文档
3. 建立变更控制委员会 (SCCB)或相关职能的类似组织 。负责裁定接受哪些变更
4. **进行需求变更影响分析。**需求变更先申请然后评估
5. **跟踪所有受需求变更影响的工作产品。**软件计划、产品、活动 都要进行相应的变更，以和更新的需求保持一致
6. 跟踪每项需求的状态，衡量需求稳定性

3.13 请举例需求变更流程

答：

1. 根据变更输入，按照变更控制系统规定的审批程序执行，通过严格审查变更申请后，决定项目变更是否应得到批准或拒绝。

3.14 有哪些传统需求分析方法？

答：

1. 原型分析方法
2. 基于数据流的建模方法（结构化分析的主要方法）
3. 基于UML需求建模方法
4. 功能列表法

3.14注 什么是结构化的分析方法？

答：

结构化分析方法的定义（SA,Structured Analysis）

1. 20世纪70年发展起来的
2. 是一种自顶向下逐步求精的分析方法
3. 根据软件内部数据传递、变换的关系进行分析的
4. 结构化分析方法是很多其他方法的基础

3.14.1 原型分析方法

答：

1. 原型分析方法是通过不断评价原型来确定需求的方法
2. 在需求分析阶段，通过不断优化这个原型来最终确定项目需求
3. 实践中可以采用原型建模工具建模，如 Axure 等快速原型设计工 具
4. 与用户很容易交流。

3.14.2 数据流建模的方法

答：

1. 将现实世界描绘为数据在信息系统中的流动，以及在数据流动过程中数据向信息的转化
2. 数据流图 (DFD) 、数据字典 (DD) 、实体联系图 (ERD) 、 系统流程图等都是数据流分析技术
3. 数据流图DFD，是一种描述软件系统逻辑模型的图形符号，使用4 种基本元素来描述系统的行为，即过程、实体、数据流和数据存储

3.14.3 基于UML建模的方法

答：

1. 一种面向对象的分析方法。从用户角度看需求，将功能需求描述为 一些用例（use case）
   • 一个用例就是系统向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求。
   • 所有用例结合起来就构成了“用例模型”，描述系统的全部功能
2. 方法主要通过UML的用例视图、顺序视图、活动视图等表达需求模型
   • 一个系统往往可以从不同的角度进行观察，从一个角度观 察到的系统，就构成系统的一个视图（view）
3. 分析流程：
   • 识别出系统的Actor
   • 描述主要的Use case
   • 实现用例视图（Use case Diagram）
   • 实现顺序视图（Sequence Diagram）
   • 实现活动视图（Activity Diagram）
   • 状态视图（State Diagram）等

3.14.4 功能列表法

答：

1. 功能列表（feature list）方法是对项目的功能需求进行详细说明的一种方法。
2. 是基于功能特性及其层次关系来描述需求的方法。

需求类别（功能/性能）	名称/标识	描述
特性Feature A	A.1
	…
	A.n
特性Feature B	B.1
	…
	B.n
特性Feature C	C.1
	…

3.14.5 敏捷项目需求分析有哪几个关键要素？

答：

1. 产品待办事项列表
   • 细化产品待办事项列表
2. 用户故事

• 用户故事模板
• 评价用户故事
• 用户故事迭代优先级

3.14.5注0 敏捷项目需求分析的背景

答：

1. 需求不断变化、风险大或不确定性高的项目，其范围逐渐明确
2. 敏捷思维认为，对于需求可以“渐进明细”，以便应对变化.
3. 敏捷方法将需求列入未完项，不断构建和审查原型，并通过发布多个版本来明确需求。

3.14.5注1 什么是产品代办事项列表？

答：

1. 产品待办事项列表是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕它来进行。
2. 产品待办事项列表可以帮助我们对将要做的事情有一个整体的认识，以及可以知道我们现在的状态。
3. 通过产品待办事项列表梳理活动，即将被实现的产品待办事项会得到澄清，变得明确，粒度也拆得更小。

3.14.5注2 如何细化产品代办事项列表？

答：

1. 每个迭代中，获得细化的待办事项列表（产品待办事项列表 ➡Sprint订单）

   Sprint订单是指：

   • 从产品待办事项列表（Product Backlog）中选择出来的

   • 在当前Sprint迭代中需要完成的

   • 具体的、细化的任务清单

2. 细化的过程就是编写用户故事的过程，即每个迭代的需求是通过用户故事描述的。

3. 细化会议上，产品负责人有很多方法处理待办事项列表的细化准备 与会议，其中包括

   • 鼓励团队在开发人员、测试人员、业务分析人员和产品负责人三方面开展合作，一起讨论和撰写故事。
   • 把整个故事的概念呈现给团队。团队进行讨论，并根据需要将其细化为许多故事。
   • 与团队一起寻找各种方法探索和撰写故事，确保所有的故事都足够小，以便团队能源源不断地交付完成的工作

3.14.5注3 什么是用户故事模板？

答：

1. 用户故事按照一定的语法形式进行表示，不使用技术语言来描述， 只是以客户能够明白的、简短的形式表达。
2. 需求包括功能性需求和非功能性需求，用户故事可以描述功能性需求，也可以描述非功能需求。

3.14.5注6 如何评价一个用户故事？

答：

用户故事INVEST的特点

• I，independent，代表独立的

• N，negotiable，代表可协商的

• V，valuable，代表对用户或客户有价值的*

• E，estimable，代表可估计的

• S，small，代表小的

• T，testable，代表可测试的

3.14.5注7 用户故事有哪些优先级？

答：

迭代开发是基于用户故事优先级进行的，因此需要对用户故事的优 先级进行排序。用户故事的排序遵守一定的规则，如MoSCoW方法

• Must Have：必须做的/必须要有的；
• Should Have：应该做的/应该有的；
• Could Have：可以做的/可以有的
• Won’t Have：不要做的/不能有的

4. 项目范围计划——任务分解

4.1 什么是任务分解？

答：

1. 将一个项目分解为更多的工作 细目或者子项目，使项目变得更 小、更易管理、更易操作
2. 任务分 解结果：WBS（Work Breakdown Structure:任务分解结构）

4.2 什么是WBS？

答：

1. WBS是把所有项目工作逐层分解到较小的、便于管理的要素（可交付成果）。
   • WBS 的组成元素有助于项目干系人检查最终的产品
2. WBS是用来确定项目范围的，必须包括项目的所有工作。
   • WBS 是管理项目范围的基础，详细描述了项目所要完成的工作
3. 没有包含在WBS中的工作就不是项目范围内的工作，都不要做。如果要做，必须通过范围控制过程。
4. WBS的编制需要**“全员参与”，项目经理主要发挥“整合者”**的作用。
5. WBS的最底层组织部分是工作包（Work Package）。
   • WBS 的最低层元素是能够被评估的，可以安排进度的和被追踪的
6. 在WBS中可以单独列出一个**“项目管理”**分支，包括项目管理相关工作。

4.3 WBS有什么作用？

答：

1. 明确和准确说明项目范围
2. 工作分解结构定义项目边界，明确需要做的工作
3. 确定所需要的技术和人力资源，明确人员职责
4. 进行时间，成本和资源估算，提高估算的准确性
5. 确定工作内容和工作顺序，并根据实践情况进行调节和控制
6. 估计项目整体和全过程费用
7. 有助于防止需求蔓延

4.4 有几种WBS分解的形式？

1. 提纲式WBS也称为清单式WBS

   • 最常用，项目管理软件中常使用 适用于大型项目
   

2. 组织结构图式WBS也称为图表式WBS

   • 优点：直观结构清晰
   • 缺点：不易修改
   • 不适用：大型项目
   

4.5 工作分解有哪些层次？

答：

1. 项目群：叫大项目，也可以叫工程项目
2. 项目
3. 任务：完成项目必须进行的工作
4. 活动：完成任务需要做什么。
5. 工作包：活动的构成单元，它体现了活动是如何做的。
6. 工作单元：一般的WBS中，不需要分解到具体动作层。

4.6 如何理解工作包（work package）？

答：

1. 工作包（Work Package），是WBS中最底层的项目可交付成果，工作包可以再细分为具体动作。

2. 项目经理通常只负责到工作包的层次，负责该工作包的团队成员负责把工作包细分为实际工作。

3. 个工作包必须由一个人或者一个部门来负责，而不能由两个或两个以上的人或部门来负责。

4. 工作包单元的周期应该是最短周期/

5. 应明确本工作包与其他工作包之间的关系

   • 能够对工作包进行进度安排，成本估算，监视和控制

   • 要求: 逻辑上不可再分，<80h，易于估算，明确责任人

   • 一个人两周能干完的工作或将一个 人80小时能干完的工作称为一个工作包

4.7 WBS的编码有什么用？

答：

1. 为了简化信息交流过程，常利用编码技术对WBS进行信息转换。
2. 通常对每一层的每项任务需要按照来编号。

4.8 什么是WBS字典？

答：

1. WBS字典，是在制定WBS过程中生成，并与WBS配合使用的说明性文件
2. WBS具体工作要素的阐述通常收集在WBS字典(WBS dictionary) 中，同时也包括一些其他信息的阐述

4.9 有哪些任务分解的方法？

答：

1. 模板参照
   • 许多应用领域都有标准或半标准的wbs，它们可以当做模板参考使用
2. 类别方法
   • 许多项目有相同或相似周期和因此形成的相同或相似的工作细目要 求，可以采用类似项目的WBS作为参考
3. 自上而下
   • 自顶向下方法从一般到特殊的方向进行
   • 自顶向下方法需要有更多的逻辑和结构，它也是创建WBS的最好方法
   • 如果WBS开发人员对项目比较熟悉或者对项目大局有把握，可以使用自顶向下方法
4. 自下而上
   • 自底向上是从特殊向一般方向进行的。
   • 如果对于项目人员来说，这个项目是一个崭新的项目，可以采用自底向上方法开发WBS。

4.10 任务分解的基本步骤是怎么样的？

答：

1. 确定分解标准
   • 按照生存期阶段或产品组成分解
   • 不能同时使用两种标准进行分解
2. 确认并分解项目的组成要素。
3. 确定分解是否详细
4. 确定项目交付成果（可以编制WBS字典）
5. 验证分解的正确性（建立一套编号系统）
   • 必要和充分性检查
   • 完整和模糊性检查
   • 可计划和控制性检查（分配工期、预算、资源和责任人）

4.11 工作分解中需要注意哪些问题？

答：

1. 不要把工作分解结构变成物品清单
   • 分解出的工作包应是一项项的行动，而不能仅仅用名词来表达。
2. 不要考虑活动之间的先后顺序
   • 工作分解结构的目的是清楚地界定实现项目目标所需执行的具体活动，并不关心 究竟先做那个、后做那个。活动之间的先后顺序等到确定关键路径时再考虑。
3. 不要试图去做画蛇添足的事
   • 如果你以小时为单位来分解工作，而又无法把工作控制到这个程度，那你不妨将 工作分解到以天或周为单位就打住，否则，既浪费了时间，又办不成事情
4. 项目分解的原则
   • 在各层次上保持项目内容的完整性，不能遗漏工作单元。
   • 一个项目单元只能从属于某一个上层单元，不能交叉。
   • 项目单元应能区分不同的责任人和不同的工作内容。
   • 项目结构分解应能方便工期、成本、质量等的控制。
   • 详细程度适中。

4.12 什么是项目可交付结果与里程碑事件？

答：

1. 通过WBS分解出项目的工作任务后，还要进一步将每项任务的交付结果，即把项目的中间结果定义出来，目的是使项目组明白完成 WBS的任务后输出的产品是什么。
2. 在项目的一系列可交付结果中，可能会有一些事件的开始或结束对项目目标的有效实现至关重要，这些事件称之为里程碑事件
   • 里程碑事件必须是项目可交付结果完整的中间产品，对这一事件的描述必须精确，必须被所有项目参与人所准确理解
   • 里程碑事件的完成可度量

4.13 工作分解有哪些困难？该如何解决？

答：

1. 对于不是很大的项目很有效，而对于耗时长成本大的项目则分解成本太高。
2. 工作包的成本有时候难以确定的，新技术的应用会改变项目的进度和预算。
3. 在工作分解结构的技术层，各种活动直接相关性非常复杂，难以用图表表达。

为解决上述困难，可以为项目预留一部分资源（包括时间、进度、 资源）给不确定因素。

4.14 工作分解有哪些建议？

答：

1. 工作分解结构必须面向可交付成果的
2. 工作分解结构必须符合项目的范围
3. 工作分解结构的底层应该支持计划和控制
4. 工作分解结构中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与
5. 工作分解结构的指导，每个级别的工作分解结构把上一级的一个 元素分为4-7个新的元素，同一级的元素的大小应该相似
6. 工作分解结构并非是一成不变的

4.15 如何展开敏捷项目的任务分解？

答：

1. 在敏捷开发过程中，通过用户故事来将需求具体化成可以进行迭代开发的一个个现实的可见的开发任务。
2. 用户故事是站在用户的角度所描述的故事，是用户所能看懂的故事 ，是对需求的细化和切分
3. 敏捷项目的分解过程，就是将史诗故事（Epic）分解成用户故事。

• Epic–>Feature–>user Story–>Task

4. 敏捷分解检验,分解完成了用户故事之后，应该给出接收标准, 它可以作为用户测试用户故事的依据.
   • 这个接收标准一般写在故事卡片的后面，以确保这个用户故事是可理解的，而且可以方便团队讨论这个用户故事的业务价值。
5. 敏捷项目任务分解可以是对backlog列表进行细化的过程

5. 项目成本计划——成本估算

5.1 什么是成本估算？有什么作用？

答：

成本管理是确保项目在预算范围之内的管理过程，包括成本估算、成本预算、成本控制等过程。

1. 成本估算是对完成项目所需费用的估计和计划
   • 估算不是很准确，有误差
   • 项目经验数据非常重要
   • 不要太迷信某些数学模型
2. 重要性和意义

• 软件成本估算是成本管理的核心
• 成本估算贯穿于软件的生存期。
• 成本估算是项目计划中的一个重要组成部分要实行成本控制，首先要进行成本估算
• 软件成本估算，一直是软件工程和软件项目管理中最具挑战、最为重要的问题

5.2 成本分为哪几类？有哪些成本？

答：

1. 直接成本
   • 指与项目有直接关系的成本费用，是与项目直接对应的，包括人员的工资、材料费用、外包外购成本等，包括开发成本、管理成本、质量成本等。
   • 人的劳动的消耗所需要的代价是软件产品的主要成本，即开发成本 。
2. 间接成本
   • （如房租、水电、员工福利、税收等） 不能归属于一个具体的项目 ，是企业的运营成本，可以分摊到各个项目中

5.4 什么是软件项目规模？

答：

1. 软件项目规模即工作量
   • 是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务。
   • 是成本的主要因素，是成本估算的基础
2. 软件成本估算是预测开发一个软件系统所需要的总工作量的过程。
3. 软件项目成本，指软件开发过程中所花费的工作量及相应的代价。
   • LOC (Lines of Code) 代码行 源代码长度的测量
   • FP (Function Point) 功能点 用系统的功能数量来测量
   • 人月 ，人天 ，人年

5.5 有哪些影响软件项目成本的因素？

答：

1. 耗用资源的数量和价格
   • 中间产品和服务、市场人力资源、硬件、软件的价格也对成 本产生直接的影响。价格对项目预算的估计影响很大。
2. 项目工期
   • 项目的费用由直接费用和间接费用组成，一般工期和直接费用成反比，和间接费用成正比
   • 缩短工期需要更多的、技术水平更高的人员，直接成本费用就会增加。
3. 项目质量
   • 质量总成本由质量故障成本和质量保证成本组成。
   • 质量故障成本指为了排除产品质量原因所产生的故障， 保证产品重新恢复功能的费用。
   • 质量保证成本为了保证和提高产品质量而采取的技术 措施所消耗的费用。
4. 项目管理水平

• 高的管理水平可以提高预算的准确度，加强对项目预算的执行和监 管，对工期的控制严格限制在计划许可的范围之内，对设计方案和 项目计划更改造成的成本增加、减少和工期的变更，可以较为有效 地控制，减少风险的损失等。

---

5.6 成本估算的过程是怎么样的？给出成本估算的方法。

答：

1. 估算输入
   • 项目需求 ，工作分解结构WBS ，资源计划 ，资源单位价格，进度计划 ，历史信息
2. 估算处理
   • 代码行估算法、功能点估算法、用例点估算法、类比 (自顶向下) 估算法、自下而上估算法、参数估算法、专家估算法
3. 估算输出
   • 估算通常以货币单位表达，如元、法郎、美元等，这个估算便是成 本估算的结果；也可用人月、人天 或人小时这样的单位，这个估算结果便是项目规模估算的结果。有时用复合单位。
   • 成本估算是一个不断优化的过程。
   • 估算说明 ①工作范围的描述 ②说明估算的基础和依据

5.6.1 代码行估算法。

答：

1. 是一种面向规模的度量，从软件程序量的角度定义项目规模。

• 与具体的编程语言有关

• 分解足够详细

• 有一定的经验数据（类比和经验方法）

2. LOC(Lines of Code) 代码行，通常采用非注释的源代码行。

   • 可计算每千行代码(KLOC)的错误数，缺陷数，成本，文档页数。

3. 简单易行但代码行数依赖选择的硬件和软件，因此并不被认为是软件度量的最优方法。

5.6.2 功能点估算法（FP）

答：

1. 功能点分析中，系统分为5个组件：

   • 外部输入、外部输出、外部查询、外部接口文件（因为这些组件的每一个都处理文件 ，因此被称为事务）
   • 内部逻辑文件 （构成逻辑信息的存储地）

2. 它是一种按照统一方式测定软件功能的方法，最后的结果是一个数 。

   • 这个结果数可以用来估计代码行数，成本和工期。
   • 与实现的语言和技术没有关系。
   • 用系统的功能数量来测量其规模。
   • 通过评估、加权、量化得出功能点。

3. 功能点公式 FP =UFC*TCF

   • UFC：未调整功能点计数
   • TCF：技术复杂度因子

4. 功能点作为度量软件规模的方法已经被越来越广泛地接受

5.6.2.1 功能点估算中的系统组件（FP）

答

1. 外部输入（EI）

   • 外部输入是最终用户或其他程序用来增加、删除或改变程序数据的屏幕（screen）、表单 （form）、对话框（dialog）或控制信号 （control signal）等

2. 外部输出（EO）

   • 外部输出是程序生成供最终用户或其他程序使用的屏幕、报表（ report）、图表（graph） 或控制信号等。
   • 例如，报表和出错信息 等。

3. 外部查询（EQ）：

   • 外部査询是输入/输出组合，其中一个输入引出一个即时的简单输出。
   • 外部查询是一个输入引出一个即时的简单输出。没有处理过程。

4. 外部接口文件 （EIF）

   • 外部接口文件是受其他程序控制的文件，是用户可以识别的一组逻辑相关数据，这组数据只能被引用。
   • 数据完全存在于应用的外部，并且由另一个应用维护。外部接口文件是另外一个应用的内部逻辑文件。

5. 内部逻辑文件（ILF）

   • 内部逻辑文件是用户可确认的、在应用程序内部维护的、逻辑上相关联的最终用户数据或控制信息，如一个平面文件，或者关系数据库中的一个表。
   • 完全存在于应用的边界之内，并且通过外部输入维护，是逻辑主文件的数目。

5.6.2.2 给出功能点估算法的步骤

答：

1. 确定应用必须包含的功能

2. 对于于每一项功能，根据5项系统组件得到5类功能点数目

3. 在估算中对5类功能计数项中的每一类功能计数项按其复杂性的不同分为简单（低）、一般（中）和复杂（高）3个级别。确定复杂度权重因素，对功能点进行加权得到未调整的功能点数量，得到该产品的未调整功能点计数（UFC）

项目	简单（低）	一般（中）	复杂（高）
外部输入	×3	×4	×6
外部输出	×4	×5	×7
外部查询	×3	×4	×6
外部接口文件	×5	×7	×10
内部逻辑文件	×7	×10	×15

4. 计算项目中14个技术复杂度因子（TCF）。取值范围是0~5：TCF=0.65+0.01×∑Fi

5. 计算调整功能点：FP = 功能点总数UFC×调整系数TCF

5.6.3 简述用例点估算法的计算流程

答：

完整计算流程总结：

1. UAW = Σ(角色数量 × 角色权重)（1-3）
2. UUCW = Σ(用例数量 × 用例权重)
3. UUCP = UAW + UUCW
4. TCF = 0.6 + (0.01 × Σ(Ti × Wi))（0-5分）
5. EF = 1.4 + (-0.03 × Σ(Ei × Wi))（0-5分）
6. UCP = UUCP × TCF × EF
7. 工作量 = UCP × 生产率因子

---

1. 计算未调整的角色权值 (UAW)

• 公式： UAW = Σ(角色数量 × 对应权重)
• 角色权重分类：
  • 简单角色：权重 = 1（通过API交互）
  • 一般角色：权重 = 2（通过协议交互，如TCP/IP、FTP、HTTP等）
  • 复杂角色：权重 = 3（通过图形用户界面交互）

2. 计算未调整的用例权值 (UUCW)

   • 公式： UUCW = Σ(用例数量 × 对应权重)
   • 用例权重分类：
     • 简单用例：权重 = 5（≤3个事务）
     • 一般用例：权重 = 10（4-7个事务）
     • 复杂用例：权重 = 15（≥8个事务）

3. 计算未调整的用例点 (UUCP)

   • 公式：* UUCP = UAW + UUCW

4. 计算技术复杂度因子 (TCF) 和环境因子 (EF)

   • 技术复杂度因子 (TCF)

     • 公式： TCF = 0.6 + (0.01 × TFactor）

     • 其中：TFactor = Σ(Ti × Wi)

       • Ti：第i个技术因子的评分值（0-5分）
       • Wi：第i个技术因子的权重

     • 环境因子 (EF)

       • 公式： EF = 1.4 + (-0.03 × EFactor)

       • 其中：EFactor = Σ(Ei × Wi)

         • Ei：第i个环境因子的评分值（0-5分）

         • Wi：第i个环境因子的权重

5. 计算调整的用例点 (UCP)

   • 公式： UCP = UUCP × TCF × EF

6. 计算工作量 (Man-hours)

   • 公式： 工作量 = UCP × 生产率因子

• 生产率因子确定：

  • 项目简单：每用例点 = 20人时

  • 项目一般：每用例点 = 28人时

  • 项目复杂：每用例点 = 36人时

5.6.4 类比估算法

答：

1. 是一种自上而下的估算形式

2. 估算人员根据以往的完成类似项目所消耗的总成本（或工作量）， 来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中

3. 自上而下的估算，又称类比估算，通常在项目的初期或信息不足时进行，此时只确定了初步的工作分解结构，分解层次少，估算精度较差。

4. 类比估算中，需要评价不同项目间的相似程度。

   • 不加权的欧氏距离
   • 加权的欧氏距离

$$
distance(P_i, P_j) = \sqrt{\frac{\sum_{k=1}^{n} \delta(P_{ik}, P_{jk})}{n}}

\delta(P_{ik}, P_{jk}) = \begin{cases}
\left(\frac{|P_{ik} - P_{jk}|}{\max_k - \min_k}\right)^2, & k \text{是连续的} \
0, & k \text{是分散的且} P_{ik} = P_{jk} \
1, & k \text{是分散的且} P_{ik} \neq P_{jk}
\end{cases}
$$

5. 由于相似度计算比较麻烦，类比估算基本上采用主观推断 ，很少采用相似度计算方法。

5.6. 5 自下而上估算法

答：

1. 通常是在项目开始以后，或者WBS已经确定的项目，需要进行准确估算的时候釆用。

   • 优点：准确度较好

   • 缺点：需要花费一定的时间 ，估算本身也需要成本支持 ， 可能发生虚报现象

5.6.6 三点估算法

答：

1. 考虑项目的不确定性与风险
   • 3种估算值：最可能成本（CM）、最乐观成本（CO）、最悲观成本（CP）
   • 三角分布：预期成本CE=(CO+CM+CP)/3
   • 贝塔分布：预期成本CE=(CO+4CM+CP)/6

5.6.7 介绍下参数估算法

答：

1. 也称为算法模型或经验导出模型，是一种使用项目特性参数建立数学模型来估算成本的方法，是通过大量的项目数据进行数学分析导出的模型，是一种统计技术

2. 找到软件工作量的各种成本影响因子，并判定它对工作量所产生影响的程度是可加的、乘数的还是****指数的，以期得到最佳的模型算法表达形式

   • 当某个因子只影响系统的局部时，一般认为它是可加的
   • 当某个因子对整个系统具有全局性的影响时，则认为它是乘数的或指数的

3. 模型分类：

   • 基于回归分析的模型
     • 静态单变量模型
     • 动态多变量模型
   • 基于神经网络的模型

4. 使用条件

   • 具有良好的项目数据为基础
   • 存在成熟的项目估算模型

5. 特点

   • 比较简单,而且也比较准确
   • 如果模型选择不当或者数据不准,也会导致偏差

5.6.7.1 什么是静态单变量模型？

答：

静态单变量模型 的整体公式: E=a+b*S^C

• E:以人月表示的工作量

• a,b,c:经验导出的系数

• S:主要的输入参数(通常是LOC,FP等)

5.6.7.2 下COCOMO 81 模型

答：

1. COCOMO 81（Constructive Cost Model 1981）是Barry Boehm在1981年提出的软件成本估算模型，是最著名的软件工作量估算模型之一。

2. 模型等级:COCOMO 81有3个等级的模型，级别越高，模型的参数约束越多：

   • 基本COCOMO - 相关信息极少情况下使用
   • 中等COCOMO - 需求确定之后使用
   • 高级COCOMO - 设计完成后使用

3. 项目模式（类型）:COCOMO 81根据项目特征将软件项目分为三种模式：

   • 有机模式（Organic） - 小型项目，团队经验丰富，需求相对稳定

   • 嵌入式模式（Embedded） - 复杂的硬件/软件系统，严格约束条件

   • 半有机模式（Semidetached） - 介于有机和嵌入式之间的中等规模项目

4. 核心公式

$$PM=A\times S^E\times \prod _{i=1}^n(E{M}_i)$$

$$\text{Effort}=a\times {\text{KLOC}}^b\times F$$

$$\text{其中：}\begin{array}{rl}& \text{PM/Effort：项目工作量（人月）}\\ & \text{A/a：规模因子常数}\\ & \text{S/KLOC：软件规模（千行代码）}\\ & \text{E/b：规模指数}\\ & {\text{EM}}_i\text{：第}i\text{个工作量乘数因子}\\ & \text{F：调整因子}\end{array}$$

5. 参数取值：

   • 调整因子F的取值：取决于建模等级以及目标模式。由专家决定。基于数据库的项目要求

   • 参数值（a、b），取决于建模等级以及目标模式，通过历史数据统计得出，用于准确估算软件开发工作量。

5.6.8 下专家估算法

答：

1. 专家估算法是由一些被认为是该任务专家的人来进行的
2. 一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值，最后得出综合的估算值 ，因此引入Delphi专家估算法
   • 每位专家根据软件系统规格说明书进行估算**（保证专家不见面）**
   • 协调员整理专家估算，给出平均期望值（三角分布/贝塔分布）
   • 在此基础上各位专家进行再次估算
   • 以上过程可重复多次，直到专家评估值之差达到要

5.7 什么是项目成本预算？

答：

1. 成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去
2. 成本预算的目的是产生成本基线，作为度量项目成本性能的基础

5.8 什么是成本基线？

答：

1. 成本基线是每个时间阶段内的成本.
2. 是项目管理者度量或监控项目的依据。

6. 项目进度计划

6.1 什么是进度？进度计划为什么重要？

答：

1. 进度是对执行的活动和里程碑制定的工作计划日期表
2. 重要性：
   • 按时完成项目是项目经理最大的挑战
   • 时间是项目规划中灵活性最小的因素
   • 进度问题是项目冲突的主要原因

6.2 如何制定出进度计划？

答：

1. 根据WBS分解出主要的任务（活动）；
   • 任务是对WBS工作包的进一步细分。
2. 确立任务（活动）之间的关联关系；
3. 然后估计每个任务（活动）需要的资源、时间；
4. 最后编制出项目的进度计划。

6.3 任务之间的关系有哪几种？如何确定关系？

答：

1. 前置活动（任务）—〉后置活动（任务）

2. 确定任务（活动）之间关联关系的依据：

   • 硬逻辑关系 （强制性依赖关系）：客观的不可违背的
   • 软逻辑关系 ：人为的，主观的
   • 外部依赖关系：项目活动与非项目活动之间

6.4 进度管理有哪几种图示方法？

答：

1. 网络图 network diagramming
   • 节点法/单代号网络图 PDM （Precedence Diagramming Method）
   • 箭线法/双代号网络图 ADM （Arrow Diagramming Method）
2. 甘特图 Gantt
   • 棒状甘特图
   • 三角形甘特图
3. 里程碑图
4. 资源图
5. 燃尽图/燃起图

6.5 介绍进度管理几种图示方法。

答：

6.5.1 网络图

网络图是活动排序的一个输出，展示项目中各个活动以及活动之间的逻辑关系

1. PDM：

   

2. ADM

6.5.2 甘特图

显示基本的任务信息，可以查看任务的工期、开始时间和结束时间以及资源的信息。只有时标，没有活动的逻辑关系

6.5.3 里程碑图

6.5 4 资源图

6.5.5 燃尽图/燃起图

在项目完成之前，燃尽图是对待完成的工作的可视化表示，燃起图是对已完成的工作的可视化表示。

对比维度	燃尽图（Burn Down Chart）	燃起图（Burn Up Chart）
展示内容	仅展示从项目开始到终点的剩余工作量的减少	展示完成工作量以及项目总工作量的时间变化
图形特征	理想情况下是向下的曲线，随着剩余工作完成，烧尽至零	通过两条线（完成工作量线和总工作量线）展示进度与目标
目标明确性	目标相对隐含，主要关注剩余工作量	目标非常明确，总工作量线清晰显示项目目标
范围变化处理	不直接显示范围变化，如果增加任务，剩余工作量会突然增加，可能使读者难以理解原因	能够清晰表现项目范围变化，总工作量线会随着变更而调整
范围变更影响	范围发生变化时需要重新绘制图表	项目范围变化时，总工作量线会上升或下降，直观反映范围变动
工作量增加显示	不直接显示工作量的增加	通过总工作量线的变化直观显示工作量增减

6.6 介绍几种任务历时估计的方法

答：

1. 定额估算法：适合规模较小的项目。

   • T=Q/(R*S）T活动历时，Q任务规模，R人力数量，S工作效率

2. 经验导出模型

   • D=a*E^b,D:进度(以月单位) E:工作量(以人月单位) a:2-4之间 b:1/3左右

3. PERT(工程评估评审技术)

4. 专家判断法

5. 类比估计法

6. 基于承诺的进度估计

7. Jones的一阶估算准则

   • 基于估算项目功能点,从幂次表中选择合适的幂次将功能点升幂
   • ，一个商业软件的功能点FP=350，若一个平均水平的软件公司来承担，粗略的进度估算为 350^0.43=12月

8. 预留分析

9. 敏捷历时估算

6.6.1 PERT技术

答：于1958年，为适应大型工程的需要，并取得不错效果

1. 利用网络顺序图的逻辑关系和加权算法估算任务历时
2. 它是基于对某项任务的乐观，悲观以及最可能的概率时间估计

$$\begin{gathered} 贝塔分布方差近似值PERT历时=(O+4m+P)/6（贝塔分布） \\ 贝塔分布方差近似值：{\sigma }^2={\left(\frac{P-O}{6}\right)}^2 \end{gathered}$$

活动项	O,M,P	PERT估计值	δ	δ²
A	2,3,6	3.33	4/6	16/36
B	4,6,8	6	4/6	16/36
C	3,4,6	4.17	3/6	9/36
估计项目总历时	—	13.5	1.07	41/36

$$\begin{gathered} E=E_A+E_B+E_C \\ {\delta }^2={\delta }_A^2+{\delta }_B^2+{\delta }_C^2 \\ \delta =\sqrt{{\delta }_A^2+{\delta }_B^2+{\delta }_C^2} \end{gathered}$$

6.6.2 预留分析

答：

1. 在进行持续时间估算时，需考虑应急储备(有时称为“进度储备”), 以应对进度方面的不确定性。

2. 应急储备是包含在进度基准中的一段持续时间，用来应对已经接受 的已识别风险。应急储备可取活动持续时间估算值的**某一百分比( 如10%～15%)**或某一固定的时间段。

3. 预留的应急储备应该是将每一项任务的预留时间累加在一起放在关键路径末端，而不要增加每一项任务时间，即把应急储备从各个活动中剥离出来并汇总

6.6.3 敏捷历时估算

答：

1. 在敏捷项目中，团队的估算最多限于未来几周时间。
2. 敏捷历时估算可以分为：开发速度稳定前和开发速度稳定后两种

• 开发速度稳定前，可以采用决策技术，如举手表决。
• 开发速度稳定后：
  * 团队通过观察历史表现来更准确地规划下阶段的能力，可能需要4 ～8个迭代才能达到稳定的速度。

6.7 什么是任务进度计划编制？有什么基本方法？

答：

1. 进度计划编制是决定项目开始和结束日期的活动
   • 主要目的：是控制和节约项目的时间，保证项目在规定的时间内能够完成
   • 最终目标：建立一个现实的项目进度计划，为监控项目的进度进展提供一个基础。
2. 基本方法有
   • 关键路径法 CPM Critical Path Method 正推法/逆推法
   • 时间压缩法 应急法/平行作业法
   • 资源优化 资源平衡方法/资源平滑
   • 敏捷项目进度编排

6.7.1 如何使用关键路径法？

答：

1. 计算每一个活动的单一的、确定的最早和最迟开始和完成日期；

2. 计算网络图中最长的路径。以便确定项目完成时间估计。

6.7.1.1项目进度管理时间参数对照表

中文名称	英文名称	简称	定义/说明
最早开始时间	Early Start	ES	任务最早可以开始的时间
最晚开始时间	Late Start	LS	任务最晚必须开始的时间（不影响项目完成）
最早完成时间	Early Finish	EF	任务最早可以完成的时间
最晚完成时间	Late Finish	LF	任务最晚必须完成的时间（不影响项目完成）
超前	Lead	—	两个任务的逻辑关系所允许的提前后置任务的时间
滞后	Lag	—	两个任务的逻辑关系所允许的推迟后置任务的时间
浮动	Float	—	任务的机动性，在不影响项目完成情况下可推迟的时间量
自由浮动	Free Float	FF	在不影响后置任务最早开始时间，本任务可延迟的时间
总浮动	Total Float	TF	在不影响项目最早完成时间，本任务可延迟的时间

$$
FF = ES_{\text{后置任务}} - EF - \text{lag}\

TF = LS - ES \quad \text{或} \quad TF = LF - EF
$$

• 关键路径上的任务总浮动为0
• 自由浮动≤总浮动，任务的自由浮动永远不会超过其总浮动
• Lead/Lag主要用于调整任务间的逻辑关系时间依赖

6.7.2 介绍下时间压缩法

答：

1. 时间压缩法是在不改变项目范围的前提下缩短项目工期的方法，是一种数学分析方法
2. 分为：
   • 应急法——赶工（crash）
     • 时间成本平衡方法（进度压缩单位成本方）
     • 进度压缩因子方法
   • 平行作业法——快速跟进（Fast Tracking）

6.7.2.1 介绍下时间成本平衡方法（进度压缩单位成本方法)

答：

时间成本平衡方法是项目管理中通过增加成本来压缩项目进度的技术，核心是找到成本增加与时间节省之间的最优平衡点。

6.7.2.1.1基本假设

序号	假设条件
1	每个任务存在正常进度和可压缩进度、正常成本和可压缩成本
2	通过增加资源，每个任务的历时可以从正常进度压缩到可压缩进度
3	每个任务无法在低于可压缩进度内完成
4	有足够需要的资源可以利用
5	在"正常"与"可压缩"之间，进度压缩与成本增长成正比

$$\text{单位压缩成本}=\frac{\text{可压缩成本}-\text{正常成本}}{\text{正常进度}-\text{可压缩进度}}$$

参数类型	时间	成本
正常情况	正常进度（较长）	正常成本（较低）
压缩情况	可压缩进度（较短）	可压缩成本（较高）

决策原则

• 成本效益最大化：选择单位压缩成本最低的活动进行压缩

• 关键路径优先：只有关键路径上的活动压缩才能缩短项目总工期

• 资源约束考虑：在资源允许范围内进行压缩

6.7.2.2 简要介绍下进度压缩因子法

答：

1. 通过计算进度压缩因子来估算压缩进度后的工作量增加，实现时间与成本的量化权衡。

$$\begin{gathered} \text{进度压缩因子}=\frac{\text{压缩进度}}{\text{正常进度}} \\ \text{压缩后工作量}=\frac{\text{正常工作量}}{\text{进度压缩因子}} \end{gathered}$$

典型结果

• 进度缩短17% → 工作量增加21%
• 体现了进度压缩的非线性成本增长特性

安全限制

• 进度压缩因子 ≥ 0.75
• 最多压缩25%进度
• 超出此范围项目风险急剧增加

6.7.2.3 对比一下时间压缩方法中的应急法和平行作业

对比维度	应急法（赶工法）	平行作业法（快速跟进法）
基本原理	通过增加资源，以最小成本代价压缩进度工期	将正常情况下按顺序进行的活动改为至少部分并行开展
逻辑关系	不改变活动间的逻辑关系	可改变活动间的逻辑关系
实施方式	增加资源投入（人力、设备、资金等）	并行开展某些活动，使用提前量
适用条件	• 位于关键路径上的活动 • 通过增加资源就能缩短持续时间的活动	• 原本按顺序进行的活动或阶段 • 可以部分并行开展的工作
主要风险	• 可能导致风险或成本增加 • 并非总是切实可行	• 常导致返工 • 增加项目风险 • 增加质量风险
成本影响	直接增加资源成本，但以最小成本为目标	可能增加项目成本（返工、协调、质量问题）
协调复杂度	相对简单，主要是资源管理	增加相关活动间的协调工作
技术可行性	取决于活动特性，有些活动无法通过增加资源缩短	需要仔细分析活动依赖关系的可调整性
典型应用	增加加班时间、增加工作人员、使用更快设备	设计与采购并行、测试与开发重叠

选择建议

• 优先考虑应急法：当关键路径活动可通过增加资源缩短且成本可控时
• 谨慎使用平行作业法：当应急法不可行且能承受返工和质量风险时
• 组合使用：在复杂项目中可能需要两种方法配合使用

6.7.3 资源平滑方法。

资源平衡法是一种资源优化技术，通过调整活动的开始日期和完成日期，使计划使用的资源等于或少于可用资源，在资源需求与资源供给之间取得平衡。

主要目标	具体说明
形成平稳连续的资源需求	避免资源需求的剧烈波动
最有效利用资源	提高资源使用效率
最小化资源闲置时间	减少资源浪费
避免超出资源能力	防止资源过度分配

1. 适用场景

   • 需要进行资源平衡的情况：

     • 共享资源或关键资源只在特定时间可用

     • 资源数量有限

     • 资源被过度分配（同一资源在同一时段被分配至两个或多个活动）

2. 实施方法

   • 根据资源制约因素对开始日期和完成日期进行调整，通过调整任务时间来协调资源冲突。

3. 重要特点

   • 对项目的影响：

     • 资源平衡往往导致关键路径改变
     • 可在资源有约束的条件下制定可行的进度计划

   • 资源优化方法分类

     • 资源平衡：调整时间以匹配可用资源

     • 资源平滑：在不改变关键路径的前提下优化资源使用

   • 核心价值

     • 在项目编排中进行资源的优化配置，保证资源最优化、最有效，实现可执行的项目进度计划。
       | 并行开展某些活动，使用提前量 |
       | 适用条件 | • 位于关键路径上的活动
       • 通过增加资源就能缩短持续时间的活动 | • 原本按顺序进行的活动或阶段
       • 可以部分并行开展的工作 |
       | 主要风险 | • 可能导致风险或成本增加
       • 并非总是切实可行 | • 常导致返工
       • 增加项目风险
       • 增加质量风险 |
       | 成本影响 | 直接增加资源成本，但以最小成本为目标 | 可能增加项目成本（返工、协调、质量问题） |
       | 协调复杂度 | 相对简单，主要是资源管理 | 增加相关活动间的协调工作 |
       | 技术可行性 | 取决于活动特性，有些活动无法通过增加资源缩短 | 需要仔细分析活动依赖关系的可调整性 |
       | 典型应用 | 增加加班时间、增加工作人员、使用更快设备 | 设计与采购并行、测试与开发重叠 |

选择建议

• 优先考虑应急法：当关键路径活动可通过增加资源缩短且成本可控时
• 谨慎使用平行作业法：当应急法不可行且能承受返工和质量风险时
• 组合使用：在复杂项目中可能需要两种方法配合使用

6.7.3 资源平滑方法。

资源平衡法是一种资源优化技术，通过调整活动的开始日期和完成日期，使计划使用的资源等于或少于可用资源，在资源需求与资源供给之间取得平衡。

主要目标	具体说明
形成平稳连续的资源需求	避免资源需求的剧烈波动
最有效利用资源	提高资源使用效率
最小化资源闲置时间	减少资源浪费
避免超出资源能力	防止资源过度分配

1. 适用场景

   • 需要进行资源平衡的情况：

     • 共享资源或关键资源只在特定时间可用

     • 资源数量有限

     • 资源被过度分配（同一资源在同一时段被分配至两个或多个活动）

2. 实施方法

   • 根据资源制约因素对开始日期和完成日期进行调整，通过调整任务时间来协调资源冲突。

3. 重要特点

   • 对项目的影响：

     • 资源平衡往往导致关键路径改变
     • 可在资源有约束的条件下制定可行的进度计划

   • 资源优化方法分类

     • 资源平衡：调整时间以匹配可用资源

     • 资源平滑：在不改变关键路径的前提下优化资源使用

   • 核心价值

     • 在项目编排中进行资源的优化配置，保证资源最优化、最有效，实现可执行的项目进度计划。