# 项目

# 定义

• 是为创造独特的产品、服务或成果而进行的临时性工作（结果可以有形，可以无形）

量产的、日常、每天的不能算项目，因为不具备独特性

# 特点

# 1️⃣ 临时性 (一次性)

1. 有明确的起点和终点；
2. 不一定意味着持续时间短；
3. 大多数项目是为了得到持久的结果；
4. 项目团队也具有临时性。

# 2️⃣ 独特性

1. 创造独特的可交付成果（产品、服务、成果）；
2. 重复部件的存在并不改变整个项目工作的独特本质。

# 3️⃣ 渐进明细性 (逐步完善)

1. 分步、连续的积累，由粗略到详细深入；
2. 范围、目标、计划等都是渐进明细的。

# 4️⃣ 资源约束性

1. 资源有限，资源成本是项目成功实施的一个约束条件。

# 5️⃣ 目的性

1. 项目是面向目标的。
2. 三个主要目标：时间、成本、质量（如问四要素，加范围）
3. 要平衡不同干系人在不同时间对项目的不同看法

# 项目终止的几种情况

1. 当项目目标达成时 做完了
2. 当项目因不会或不能达到目标而中止时 做不完
3. 当项目需求不复存在时 不用再做了
4. 如果客户（顾客、发起人或项目倡导者）希望终止项目，项目也可能被终止 不让做了

# 项目与运营（日常运作）的关系

运营（日常运作）

是一种生产重复性结果的持续性工作

# 信息系统项目的特点

• 目标不明确
• 需求变化频繁
• 智力密集型
• 设计队伍庞大
• 设计人员高度专业化
• 涉及的承包商多
• 项目生命周期通常较短
• 通常采用大量的新技术
• 使用与维护的要求非常复杂
• 系统集成项目中需研制开发大量的软硬件系统

# 关于项目经理

项目经理

由执行组织委派，领导团队实现项目目标的个人。

• 责任：要满足三个需求

  • 任务需求
  • 团队需求
  • 个人需求（管事 + 管人）

• 能力：要具备三个能力

  • 知识能力
  • 实践能力
  • 个人能力（理论 + 实操 + 原生力）

如何做好一个项目经理：
真正理解项目经理的角色、重视项目团队的管理，惩罚分明、计划计划再计划、真正理解一把手工程，注重用户参与。
必须承担管理者和领导者的双重角色。

# 项目管理

# 定义

• 把各种知识、技能、手段和技术应用于项目活动之中，以达到项目的要求。

• 项目管理是通过应用和综合：启动、规划、实施、监控、收尾这些项目管理过程来进行的。

• 管理一个项目包括：识别要求；确定目标；平衡范围、进度、成本、质量等制约因素；管理干系人的期望等等

# 项目管理知识体系构成

• 项目管理知识体系
• 应用领域的知识、标准和规定
• 项目环境知识
  • 社会环境、政治环境、自然环境
• 通用的管理知识和技能
• 软技能或人际关系技能
  • 有效的沟通
  • 影响力
  • 领导力
  • 激励
  • 谈判和冲突管理
  • 问题解决

# 组织结构

# 职能型（集中式）

• 兼职项目经理（联络员）
• 协调路径（职员 A-> 职能经理 A-> 职能经理 B-> 职员 B）
• 职业路径清晰、横向联系薄弱

# 项目型

• 全职项目经理
• 协调路径（项目经理 A-> 职员 A、B、C）
• 项目经理控制度高
• 重复配置；无家可归

# 矩阵型

• 资源利用率高、有利于跨部门协调
• 多头领导；管理难度大；资源争夺；

# 弱矩阵

• 兼职项目经理（协调员，职权 < 职能经理）
• 协调路径（职员 A-> 职员 B、C）

# 平衡矩阵

• 全职项目经理（职权 = 职能经理）
• 协调路径（项目经理 -> 职员 B、C）

第一次出现全职的 “项目经理”
和 PMP 不一样，PMP 的全职 PM 出现在强矩阵型

# 强矩阵

• 全职项目经理（职权 > 职能经理）
• 协调路径（项目经理 A-> 职员 B、C）
• 出现 “项目经理的经理”

项目型里的项目团队成员才能全职工作
论文让介绍项目组织结构时，一律写项目型

# 项目管理办公室 PMO

# 定义

• 是对与项目相关的治理过程进行标准化，并促进资源、方法论、工具和技术共享的一个组织部门。

  • 是一个职能部门

• 根据需要，可以为一个项目、一个部门、一个企业设立 PMO。

  • 这三级 PMO 可以在一个组织内共存。

# PMO 的类型 支控指

支持型

支持，是顾问、项目资源库，对项目控制程度很低。

控制型

支持 + 要求服从，对项目控制程度中等。

指令型

直接管理和控制，对项目控制程度很高。

# PMO 在组织结构中的作用

默写警告

管理功能

管理 “共享资源”，识别和制定 “最佳实践” 和 “标准”

监督功能

通过 “项目审计”，监督对 “标准” 的遵守程度

指导培训功能

制定和管理政策、程序、模板，提供指导和培训

协调功能

协调 “跨项目” 的沟通

# 信息系统项目的生命周期

# 定义

项目生命周期 时间维度划分

项目从启动到收尾所经历的一系列阶段，阶段名称和数量视具体项目而定。

建筑项目 -- 可研、初步设计、详细设计、施工、移交；
软件项目 -- 需求分析、架构设计、编程、测试、部署；

项目通用生命周期 时间维度划分

4 个通用阶段：

• 启动项目；
• 组织与准备；
• 执行项目工作；
• 结束项目；

产品生命周期 时间维度划分

从项目开始到项目结束再到项目产品运行生命终止（退出市场）的全过程。

项目管理过程组 管理操作维度划分

5 个通用操作过程：

• 启动
• 规划
• 执行
• 监控
• 收尾

不论在哪个时间段里，都可以进行这 5 种操作

# 项目生命周期的特征

成本与人力投入

项目开始时 “缓慢增加”，在 “执行工作” 期间达到最高，项目快结束时 “迅速回落”

风险与不确定性、干系人的影响力、变更的数量

项目开始时最大，后续 “逐步降低”

变更的代价、风险的影响

项目开始时较小，后续 “显著增高”

# 项目阶段

• 不同类型的项目有不同的项目生命周期阶段划分，每个阶段都可以看作一个单独的项目或子项目。
• 阶段与阶段之间有 “顺序关系” 或 “交叠关系”（作为进度压缩的技术，被称为 “快速跟进”）
• 每个阶段可能会执行全部项目管理过程，阶段结束以可交付成果的转移或移交为标志
• 一个阶段的结束并非一定意味着下一阶段的开始，阶段结束点是重新评估项目活动、变更或终止项目的时点
  • 阶段关口、里程碑、阶段审查、阶段门、关键决策点、生死点、杀点

# 项目管理过程组

• 项目管理过程组：启动、规划、执行、监控、收尾
  • 在所有项目上都是一样的。
  • 五大过程组可以在每个项目阶段执行和重复执行
  • 也可以在整体项目层面执行和重复执行。
• “项目管理生命周期” 和 “项目生命周期” 有相同的起点和终点
• 五大过程组可以对应到 PDCA 戴明环
  • 规划对应 P
  • 执行对应 D
  • 监控对应 C 和 A。
• 启动过程组：制定项目章程、识别项目干系人；
• 收尾过程组：结束项目或阶段、结束采购。

# 过程间的相互联系与交互作用

• 过程组极少是孤立的或一次性事件，而是在整个项目期间相互重叠
• 在多阶段项目上，这些过程会在每个阶段内重复进行，直至符合阶段完成标准。
• 监控过程通常不能在时间段上独立存在，贯穿于其他所有过程中

# 信息系统项目典型生命周期模型

# 瀑布模型

• 一般将软件开发分为：
  • 可行性分析（计划）
  • 需求分析
  • 软件设计（概要设计、详细设计）
  • 编码（含单元测试）
  • 测试
  • 运行维护等几个阶段。
• 上一项活动的输出作为当前活动的输入，完成当前活动后，进行评审，通过则进行下一项，否则返回之前。
• 特点：
  • 也称生命周期法、预测型、计划驱动
  • 是结构化方法中最常用的开发模型
  • 本质是 “一次通过”
• 适用：
  • 需求明确或很少变更的项目；
  • 开发团队比较弱的情况；
  • 有厚实的行业实践基础；
  • 整批一次性交付有利于干系人。

# 螺旋模型

• 是一个演化软件过程模型，将瀑布型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统、风险大的项目。
• 整个开发过程是迭代和风险驱动的，通过将瀑布模型的多个阶段转化到多个迭代过程中 过程型迭代 ，以减少项目的风险
• 每一次迭代都包含了四个步骤：
  • 制订计划
  • 风险分析
  • 实施工程
  • 客户评估

# 迭代模型

• 在迭代式的过程中，每个阶段都包括不同比例的所有活动。
• 重复的循环，属于 “完善型迭代”。
• 适用于：
  • 不能完整定义产品的所有需求
  • 计划多期开发的
  • 在开发早期需求可能有所变化
  • 需要降低项目复杂性的
  • 部分交付有利于干系人的

# 增量模型

• 融合了瀑布模型的基本成分和原型实现的迭代特征。在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。
• 本质上是一种非整体开发模型。
  • 只有在最后一次迭代之后，可交付成果具有了必要和足够的能力，才能被视为完整的。
• 渐进地增加，属于 “功能型迭代”。

# 敏捷开发模型

• 是一种以人为核心、迭代、循序渐进的开发方法，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
• Scrum 是一种迭代式增量软件开发过程，通常用于敏捷软件开发（三个角色、三个物件、四个会议）
• 特点：
  • 较小增量
  • 快速迭代（2~4 周）
  • 变更驱动
  • 每次交付最有价值成果。
• 适用：小型或中型软件开发团队，并且客户的需求模糊或多变。

• 产品未完项（Product Backlog）或迭代未完项、产品代办事项

# 原型化模型

• 在很难一下子全面准确地提出用户需求的情况下，首先不要求一定要对系统做全面、详细的调查、分析，而是本着开发人员对用户需求的初步理解，先快速开发一个原型系统，然后通过反复修改来实现用户的最终需求。
• 分为：
  • 抛弃型原型
  • 进化型原型
• 特点：对用户的需求是动态响应、逐步纳入的，系统分析、设计与实现都是随着对一个工作模型的不断修改而同时完成的，相互之间并无明显界限，也没有明确分工。
• 适用：需求开始时定义不清、管理决策方法结构化程度不高的系统开发。

# 统一过程模型 RUP

• 是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由 UML 方法和工具支持，广泛应用于各类面向对象项目。

RUP 是由 Rational 公司开发并维护，和一系列软件开发工具紧密集成。
RUP 蕴含了大量优秀的实践方法，如：迭代式软件开发、需求管理、基于构件的构架应用、建立可视化的软件模型、软件质量验证、软件变更控制等。
在每个过程内部进行迭代

• 目标：在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。

# 喷泉模型

• 是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
  • 该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。
  • 各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。 对瀑布模型的改良
• 特点：迭代、无间隙、复用。
• 适用：面向对象的软件开发过程。

# V 模型

既是开发模型，也是测试模型
单元测试由开发做，是模块内的测试 ⇨ 测编码问题
集成测试由 QC 做，是模块间的测试 ⇨ 测详细设计
系统测试由 QC 做，把模块组成系统，做整体测试 ⇨ 测当时的概要设计
验收测试由客户做 ⇨ 测当时需求

• 测试活动的展开次序正好与开发的次序相反，动态测试的行为与开发行为相对应。
• 非常明确地表明了测试过程中存在的不同的级别，并且非常清晰地描述了这些测试阶段和开发阶段的对应关系。
• 特点：细化了瀑布模型中的测试部分、开发阶段清楚、便于控制开发的过程。
• 适用：需求明确、需求变更不频繁的情况。
  • 本质还是瀑布型，也有瀑布型的缺点

# 汇总