项目管理期中复习

第 1 章 概述

项目定义

项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。

项目和日常运作的相同点

• 都需要人来完成
• 都受到有限资源的限制
• 都需要计划、执行、控制

项目和日常运作的不同点

• 项目是一次性的，日常运作是重复进行的
• 项目以目标为导向，日常运作是通过效率和有效性体现的
• 项目通过项目经理及其团队工作完成，日常运作是职能式的线性管理
• 项目存在大量的变更管理，日常运作基本保持持续的连贯性

项目的特征

• 有明确目标
• 项目之间的活动有相关性
• 限定的周期
• 独特性
• 资源成本的约束性
• 不确定性

项目管理定义

项目管理是一系列的伴随着项目的进行而进行的，目的是为了确保项目能够达到期望结果的一系列管理行为。

过程管理

过程管理，就是对过程进行管理，目的是要让过程能够被共享、复用、并得到持续的改进。

项目管理知识体系（PMBOK）包括哪10个知识领域

• 项目集成管理

• 项目范围管理

• 项目时间管理

• 项目成本管理

• 项目质量管理

• 项目人力资源管理

• 项目沟通管理

• 项目风险管理

• 项目采购管理

• 项目干系人管理

项目管理的5个过程组及其关系

1. 启动过程组：主要是确定一个项目或一个阶段可以开始了，并要求着手实行；定义和授权项目或者项目的某个阶段。
2. 计划过程组：为完成项目所要达到的商业要求而进行的实际可行的工作计划的设计、维护，确保实现项目的既定商业目标。计划基准是后面跟踪和监控的基础。
3. 执行过程组：根据前面制定的基准计划，协调人力和其他资源，去执行项目管理计划或相关子计划。
4. 控制过程组：通过监控和检测过程确保项目达到目标，必要时采取一些修正措施。集成变更控制是一个重要的过程。
5. 收尾过程组：取得项目或阶段的正式认可并且有序地结束该项目或阶段。向客户提交相关产品，发布相关结束报告，并且更新组织过程资产并释放资源。

• 关系：各个过程组通过其结果进行连接，一个过程组的结果或输出是另一个过程组的输入。其中，计划过程组、执行过程组、控制过程组是核心管理过程组。

第 2 章 项目确立

成本效益评价指标

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

• 净利润：在项目的生命周期中总成本和总收入之差，需要考虑现金流的时限，项目周期的收益是否平稳

• 投资回报期：指达到收支平衡 / 偿还初始投入 所花费的时间

• 投资回报率 ROI：用于比较净收益率和需要的投入，常见公式 ROI =（平均年利润 ÷ 总投资）x 100%

• 净现值 NPV：考虑了项目的收益率和要产生的现金流的时限，计算公式 NPV = 第 t 年的 NPV / (1 + r)

• 内部回报率 IRR：指可以直接与利润比较的百分比回报

立项流程

• 立项是解决做什么的问题，需要确定开发的项目，关注点是效益和利润。
• 明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可。
• 项目立项报告的核心内容是确定立项前期需要投入多少，能否盈利，什么时候盈利，能否持久盈利
• 在立项阶段，产品负责人进行自造-购买决策，确定开发产品的哪些部分应当采购、外包或自主研发。

项目招投标过程

• 甲方招标书定义
• 乙方项目分析
• 招标和竞标
• 合同签署

乙方项目分析

• 需求分析
• 技术方案
• 项目规模估算
• 用户评估
• 可行性分析
• 项目风险分析
• 项目初步实施规划

项目章程

定义：项目章程是项目执行组织高层批准的一份以书面签署的确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。

项目经理

• 定义：由执行组织委派的领导团队实现项目目标的个人

• 能力：PMI 人才三角

  • 技术项目管理
  • 领导力
  • 战略和商务管理

立项期间的文档

• 甲方招标书
• 乙方投标书
• 项目合同

第 3 章 生存期模型

软件生存期模型特征

• 描述了开发的主要阶段
• 定义每一个阶段要完成的主要过程和活动
• 确定每一个阶段的输入和输出

预测型生存期模型

• 瀑布模型

  • 软件需求很明确的软件项目，即一般适用于功能明确、完成、无重大变化的软件系统的开发
  • 在项目开始前，项目的需求已经被很好的理解、也很明确，而且项目经理很熟悉为实现这一模型所需要的过程。
  • 解决方案在项目开始前也很明确。
  • 短期项目可采用瀑布模型。

• V 模型

  • 项目需求在项目开始前很明确
  • 解决方案在项目开始前也很明确
  • 项目对系统的安全很严格，如航天飞机控制系统、公司的财务系统等。

迭代型生存期模型 / 原型模型

• 项目的需求在项目开始前不明确
• 需要减少项目的不确定性的时候

增量型生存期模型

• 需求基本明确，可能发生变化
• 对于市场和用户把握需要逐步了解
• 系统改造需要一步一步实施

渐进式阶段模型

特点：

• 渐进式前进
• 阶段式提交

优点：

• 阶段式提交一个可运行的产品
• 关键的功能更早出现
• 早期预警问题，避免缺陷蔓延
• 阶段性完成可以降低估计失误

敏捷模型

特点：

• 敏捷组织提出的一个灵活开发方法
• 应对迅速变化需求的快速软件开发方法
• 是一种迭代、循序渐进的开发方法

敏捷宣言

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

极限编程方法的实施原则

• 快速反馈
• 假设简单
• 包容变化

混合型生存期模型

把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型（或混合模型）

第 4 章 需求管理

需求管理中的问题

• 需求的隐含错误

  只用 2 位来表示年份

• 用户不断增加需求，变更需求

• 不充分的需求规范

需求管理过程

• 需求获取
• 需求分析
• 需求规格编写
• 需求验证
• 需求变更

需求变更管理

• 确定需求变更控制过程
• 建立变更控制委员会
• 进行需求变更影响分析
• 跟踪所有收需求变更影响的工作产品
• 建立需求基准版本和需求控制版本文档
• 维护需求变更的历史记录
• 跟踪每项需求的状态
• 衡量需求稳定性

需求建模的基本方法

1. 原型方法：
   需求分析=>原型开发=>原型评价

2. 结构化分析法：
   是一种自顶向下逐步求精的分析方法，根据软件内部数据传递、变换的关系进行分析。
   技术包括数据流图，数据字典，系统流程图。

3. 面向对象的用例分析法
   基于面向对象的情景分析方法，从用户角度出发考虑功能需求，用例是系统向用户提供一个有价值的结果的某项功能。
   需求视图包括用例视图，顺序图，状态图，活动图。

4. 功能列表法

第 5 章 任务分解

任务分解过程和结果

任务分解过程：将一个项目分解为更多的工作项目或者子项目，使项目变得更小、更易管理、更易操作。

任务分解结果：WBS(Work Breakdown Structure) 是对项目由粗到细的分解过程，面向交付成果，组织并定义了整个项目范围。工作包(Work packages) 是 WBS 的最低层次的可交付成果，应当由唯一主体负责。

分解方法

• 类比
• 模板参照
• 自上而下
• 自下而上

任务分解的基本步骤

1. 确认并分解项目的组成要素（WBS 编号）
2. 确定分解标准
3. 确定分解是否详细
4. 确定项目交付成果（可以编制 WBS 字典）
5. 验证分解的正确性

分解标准

1. 按照生存周期阶段分解

   • 规划
   • 需求
   • 设计
   • 编码
   • 测试
   • 提交

2. 按照产品组成分解

   • 招生管理
   • 分班管理
   • 学生档案管理

WBS 字典

检验分解结果的标准

1. 最底层的要素是否是实现目标的充分必要条件
2. 最底层要素是否有重复
3. 每个要素是否清晰完整定义
4. 最底层要素是否有清晰的责任人
5. 是否可以进行成本估算和进度安排

第 6 章 成本计划

软件项目规模

软件项目规模即工作量，包括：软件规划、软件管理、需求、设计、编码、测试、维护等。

规模单位：

• LOC 源码长度
• FP 功能点
• 人月
• 人天
• 人年

软件项目成本

直接成本：和具体项目相关的成本，如参与项目的人员成本。

间接成本：可以分摊到各个具体项目中的成本，例如：培训、房租水电、员工福利、市场费。

成本估算方法

• 代码行估算法

  • 从程序量的角度定义规模，和具体语言相关，分解足够详细，有一定的经验数据。
  • 优点：代码是所有软件开发项目都有的产品，很容易计算行数。

  • 缺点：

    • 代码行没有公认的可接受的标准定义
    • 代码行数量依赖于所用的编程语言和个人的编程风格
    • 项目早期（需求不确定，设计不成熟，实现不确定），很难准确估算代码量
    • 强调编码的工作量，只是实现阶段的一部分

• 功能点估算法

  • 与实现的语言和技术没有关系，用系统的功能数量测量其规模，通过评估、加权、量化得出功能点。
  • FP = UFC * TCF