【IT项目管理】第二章项目管理范围期末复习

定义项目范围

为实现项目目标应该完成的任务及必要的工作

范围管理

制定范围管理计划

收集需求（完整性、正确性、可行性、必要性、划分优先级、无二义性、可验证性）

定义范围

创建工作分解结构

验证范围

控制范围

建立项目优先级

受限、加强、接受

创建工作分解结构

将项目可交付成果细分为更小的部分

类比法：查看类似项目的WBS

自上而下法：从最大的项目开始

自下而上法：从具体的任务开始

思维导图法：以非线性、分支的格式编写任务，然后创建WBS结构

分解方法

确定项目的主要交付物

确定当前级的所有工作细目

确定该细目的构成要素

检验工作分解是否正确

WBS完成的六个标准

状态/完成是可计量的、

明确定义了开始/结束事件、

可交付的、

时间/费用容易估计、

活动工期在可接受期限内、

工作安排是独立的

将WBS与组织相结合

项目责任矩阵（RM）

A负责人，P参与者，R要求审查，I要求输入，S要求签字

进行WBS编码

数字缩进编列

生命周期模型

预测型（进度和成本可预测）

适应型（基于组件，迭代性和增量性逐渐增加）

瀑布模型

制定计划、需求分析、软件设计、程序编写、软件测试和运行维护（自上而下，相互衔接，固定次序）

新项目不适合这个模型，用户直到项目结束才能看到质量如何，不允许或者限制变更，降低管理费用

适合：项目需求明确，版本维护、移植，质量需求高于其他需求，技术力量较弱缺乏经验，容易理解但很复杂的项目（公司的财务系统、库存管理系统、短期项目）

V型模型

强调测试过程，在开发过程中进行

左边：需求分析、概要设计（面向用户）、详细设计、编码（组织内部）

右边：单元测试、集成测试、系统测试、验收测试

比瀑布模型成功机会高，没有反应实际的开发过程，每个阶段都有可交付成果，按照顺序，一个阶段的输出是另一个阶段的输入，对应过程并行考虑，不灵活，成本高昂，花费时间长

适合：需求明确，技术和工具众所周知，性能安全要求高（航天飞机，财务系统，对一个产品增加很少的功能以完善产品）

螺旋模型

瀑布模型＋快速原型，在瀑布模型的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制

每个阶段更细划分，灵活设计，用户可以更早看到产品，和用户合作，投资不用一次投入，采用最低成本来开发对将来项目有用的一部分，风险很多（主要制约因素），注意风险控制，成本高不适合小型项目，时间管理困难，难以定义里程碑，过于依赖风险分析人员

适合：项目很大，采用了新技术，可能发生重大变更（新的项目，而且技术比较新）

增量模型

瀑布模型＋原型实现

更快的开发，减少需求变更，循序渐进，减少成本，需要大量文档，需要更多客户参与，集成问题

适合：需求明确但可能变化，对市场和用户把握不准，规模较大，功能较复杂，开发周期较长，跨职能的团队

原型法

增量模型的另一种形式

缺少标准、控制，额外花费，要与用户亲密接触，不适合外包软件

需求不明确，快速构建，用户给开发人员反馈意见（GUI等显示界面，第一次开发的产品）

快速应用开发模型：在不牺牲质量的情况下快速生产系统。

迭代模型

需求工作流程、分析设计工作流程、实施工作流程和测试工作流程

降低了在一个增量上的开支风险，降低了无法按照既定进度进入市场的风险，加快了开发进度，适应需求的变化，优先实现风险最高的功能而不是最有价值的功能（成本风险）

适合：高风险，人员对应用领域熟悉，早期需求会变化，面向对象或统一建模语言，使用CASE工具，具有高素质的项目管理者和软件研发团队

极限编程（XP敏捷软件开发方法学）

更强调可适应性

有效的沟通，简单的可行方案，有效的反馈，勇于放弃和重构

局限于小规模项目

适合：规模小，进度紧，需求变化大，质量要求严

Scrum（冲刺，敏捷软件开发方法学）

轻量级迭代、递增、演进式

三大角色：产品负责人，流程管理员，开发团队

渐进式阶段模型

增量模型＋螺旋模型，渐进式前进，阶段式提交

阶段式提交一个可运行的产品，关键功能更早出现，减少报告负担，可以应用80/20原则

适合：中型或大型项目、随时看到项目的未来，减少不确定性

数据挖掘行业标准流程

商业理解

数据理解

数据准备

建模

评估

部署

敏捷软件开发宣言

个体和互动高于流程和工具

工作的软件高于详尽的文档

客户合作高于合同谈判

响应变化高于遵循计划

用户故事

主题（在线购物）

特性（商城浏览、购物车）

史诗故事（搜索商品）

用户故事（通过品牌搜索）：Who、What、Why

任务

好的用户故事的特征

独立的

可协商的

有价值的

可估算的

小型的

可测试的