第三章 计划和管理项目

1. 第三章计划和管理项目 中国科学技术大学 田野

2. Contents 3.1 跟踪项目进展 3.2 项目人员和组织 3.3 工作量和进度估计 3.4 风险管理 3.5 项目计划 3.6 过程建模与项目管理 3.7 信息系统的例子 3.8 实时系统的例子 3.9 本章的意义

3. Chapter 3 Objectives • 跟踪项目进展 • 项目的人员和组织 • 工作量和进度估算 • 风险管理 • 在项目管理中使用过程建模

4. 3.1 跟踪项目进展 • 软件开发中，必须回答 • 我们是否了解客户需求？ • 我们是否能够设计一个系统，解决客户的问题，或满足客户的需要。 • 开发这样一个系统需要多长时间？ • 开发这样一个系统需要花费多大成本？

5. 3.1 跟踪项目进展项目进度 • 通过以下方法描述项目开发生命周期 • 列举项目开发的各个阶段 • 将每个阶段分解为离散的任务或活动 • 描述这些活动之间的交互，并估算每项任务或活动将花费的时间

6. 3.1 跟踪项目进展项目进度 • 项目开发中，客户希望看到的可交付产品 • 文档； • 功能的演示； • 子系统的演示； • 精确性的演示； • 可靠性、安全性或性能的演示 • 确定生产这些可交付产品，必须进行哪些活动。某些事件被指定为里程碑。

7. 3.1 跟踪项目进展里程碑和活动 • 活动：项目的一部分，在一段时间内发生，包含四个参数 • 前驱：在活动开始以前必须发生的一个或多个事件 • 工期：完成一项活动所需要的时间 • 截止日期：一项活动必须完成的日期 • 终点：表示活动已结束，通常是一个里程碑或可交付产品 • 里程碑：某一特定时间，活动的完成

8. 3.1 跟踪项目进展项目进度（continued） • 把项目开发分为一连串的阶段，每一个阶段都由若干步骤组成

9. 3.1 跟踪项目进展项目进度（continued） • 建造一间房子的阶段、步骤和活动

10. 3.1 跟踪项目进展项目进度（continued）

11. 3.1 跟踪项目进展项目进度（continued） • 建房阶段的各个里程碑

12. 3.1 跟踪项目进展工作分解和活动图 • 为项目生成一个工作分解结构：把项目描述为若干离散部分构成的集合 • 活动图描述活动之间的依赖关系 • 节点：项目里程碑 • 连线：包含的活动

13. 3.1 跟踪项目进展工作分解和活动图（continued） • 建造房子的活动图 节点：项目里程碑 实线：活动 从申请许可（节点1.2 ）到勘测（节点1.1 ）之间有一条虚线，表明这些活动必须在挖掘开始之前完成

14. 3.1 跟踪项目进展估算完成时间 • 在活动图中添加完成每个活动的估算时间的信息，使活动图更有用

15. 3.1 跟踪项目进展估算建房的完成时间

16. 3.1 跟踪项目进展估算建房的完成时间（continued）

17. 3.1 跟踪项目进展关键路径法CPM • CPM：通过对每个活动工期的估算，告诉我们完成项目所需的最短时间 • 揭示按时完成这个项目的最关键的活动 • 对每个活动，估算真实时间或实际时间：完成该活动所需要的必需的时间量 • 可用时间：完成这个活动可用的时间量 • 时差或浮动时间：活动可用时间和真实时间之差活动开始的最早时间和在不延期的前提下可以开始的最晚时间之差 • “勘测”可以第1天，也可以第13天开始

18. 3.1 跟踪项目进展关键路径法CPM（continued） • 最长路径中每个节点的时差都为零，这条路径决定项目是否按进度完成 • 关键路径：每个节点时差都是零的路径（无时差路径） • 在一个项目进度中可能有多条关键路径

19. 建造房屋中每个活动的时差

20. 3.1 跟踪项目进展CPM条状图 • 包含活动的最早开始时间和最晚开始时间 • 星号表示关键路径 • 虚线和‘F’表示活动不在关键路径上，‘F’表示时差

21. 3.1 跟踪项目进展跟踪进展的工具 • 一个通信软件工作分解结构的例子

22. 3.1 跟踪项目进展跟踪进展的工具：甘特图 显示可以并行的活动 标有“今天”的垂线 三角形表示开始和结束，菱形表示出现偏移

23. 3.1 跟踪项目进展跟踪进展的工具：资源直方图 • 显示分配给项目的人员和每一开发阶段需要的人员之间的关系

24. 3.1 跟踪项目进展跟踪进展的工具：监控支出 • 监控项目支出的例子

25. 3.2 项目人员 • 需要人员参与的关键项目活动 • 需求分析 • 系统设计 • 程序设计 • 程序实现 • 测试 • 培训 • 维护 • 质量保证 • 将不同的责任分配给不同的几组人会很有好处 • 例如可以将开发人员和测试人员分开

26. 3.2 项目人员选择项目人员 • 必须决定每种角色需要哪种类型的人员，做同类工作的人至少在以下某一方面不同 • 完成工作的能力 • 对工作的兴趣 • 经验 • 类似产品 • 类似工具、语言和技术 • 类似开发环境 • 培训 • 与其他人交流的能力 • 与其他人共同承担责任的能力 • 管理技能

27. 3.2 项目人员选择项目人员 • 交流如何影响项目进度 • 受到交流程度的影响 • 单个开发人员交流其思想能力的影响 • 交流和理解中的障碍可能导致软件失败

28. 3.2 项目人员选择项目人员（continued） • 交流路径会随人员增多而快速增长 • 如果项目中有n名人员，则有可能需要交流的人员有n(n-1)/2 对

29. 3.2 项目人员让会议促进项目进展 • 项目中的交流很多通过会议进行。对会议的抱怨 • 会议目的不清楚 • 与会者无准备 • 主要人员缺席或迟到 • 谈话内容偏离主题 • 会议非讨论，而是争论 • 会议作出的决议永远得不到执行 • 确保一个会议卓有成效的方法 • 清楚地决定谁应该参加会议 • 有一个会议议程 • 应有人负责确保会议不偏离主题并解决冲突 • 应有人负责确保会议后每一项决议得到实施

30. 3.2 项目人员工作风格 • 外向型：直接告诉别人他的想法 • 内向型：形成意见前先征求别人的建议 • 感性的人：决定建立在对问题的感觉和情感反应上 • 理性的人：对事实进行分析以及谨慎考虑后作出决策

31. 3.2 项目人员工作风格（continued） • 水平轴：交流的风格 • 垂直轴：决策的风格

32. 3.2 项目人员工作风格（continued） • 工作风格决定交流方式 • 理解工作风格有助于 • 更灵活地与团队、客户和用户打交道 • 提供其他人会优先考虑的信息 • 工作风格还涉及针对给定任务进行的对人员的选择 • 感性的雇员设计工作 • 理性的雇员维护编程

33. 3.2 项目人员项目组织 • 项目组织取决于 • 团队成员的背景和工作风格 • 团队成员的数目 • 客户和管理人员的管理风格 • 例子： • 主程序员负责制：有一个人总体负责系统的设计和开发，主程序员应选择外向型的人，大多数小组成员不应是内向型人 • 忘我方法：每个人平等地负担责任，民主式的结构

34. 3.2 项目人员项目组织：主程序员负责制 • 团队其他成员向该主程序员汇报，经常交流，但是不必与其他成员交流

35. 3.2 项目人员项目组织（congtinued） • 项目组织结构的比较 主程序员负责制更有效 忘我方法更有效

36. 3.2 项目人员结构化 vs. 创造性 • Sally Phillip 教授的实验，将学生分为两组，用建筑用纸和胶水建一家旅馆 • 结构化的小组，小组成员具有清晰定义的责任 • 非结构化的小组，放任自流 • 结果总是类似的 • 结构化的小组总是能够按时完成一个普通但功能完备的旅馆 • 非结构化的小组具有难以置信的创造性，但是从来不能按时完成 • 好的项目管理意味着在结构化和创造性中找到一种平衡

37. 3.3 工作量估算 • 项目计划和管理的一个至关重要的方面是了解可能的成本 • 在项目生命周期的早期给出一个好的成本估算，可以帮助项目经理了解需要多少开发人员 • 成本的类型 • 设施：硬件、场地、办公设备、电话、…等等 • 软件：支持开发工作的软件和工具 • 工作量：需要多少人-日的工作量，是成本中的最大成分，不确定性最高

38. 3.3 工作量估算成本估算应在生命周期中反复进行 • 项目的不确定性影响成本和规模估算的精确性 随着我们对一个项目了解得越来越多，估算变得越来越精确。 精细的估算通常在大部分项目完成后才能出现，这样就太迟了

39. 3.3 工作量估算估算不精确的原因 • 用户频繁地变更请求 • 对任务的忽视 • 用户对需求缺乏理解 • 估算时缺乏充分分析 • 系统开发、技术服务、操作、数据管理以及开发中其它功能之间缺乏协调 • 缺乏适当的估算方法或指导原则

40. 3.3 工作量估算估算不精确的原因（continued） • 以下方面对估算产生重要影响 • 要开发的应用程序系统的复杂性 • 必须与现有的系统集成在一起 • 系统中程序的复杂性 • 系统的规模（功能或程序的数目） • 项目团队成员的能力 • 项目团队对应用程序、程序设计语言、以及硬件的经验 • 团队成员的能力 • 数据库管理系统 • 项目团队的人数 • 编程或文档标准的范围

41. 3.3 工作量估算估算方法的类型 • 专家判断 • 彻底的估算需要自顶向下或自底向上的彻底分析才能计算得出 • 请专家作3种预测，悲观预测（x），乐观预测（y），最可能的猜想（z）；通过公式(x +4y + z)/6计算 • Delphi技术：专家秘密地进行个人预测，计算平均值提交专家组；专家修正他的估算；重复进行直到没有专家修正为止

42. 3.3 工作量估算估算方法的类型：Wolverton模型 • 数字表示不同软件每一行代码的成本 • 影响难度的两个因素 • 是老问题（O）还是新问题（N） • 是容易的（E）或中等的（M）还是难的问题（H） • 矩阵中每个元素表示每行代码的成本 • 相应模块的代码行数乘以系数后相加

43. 3.3 工作量估算算法方法 • 表示工作量和因素之间关系的模型 • 算法方法：工作量方程E = (a + bSc)m(X) • S：系统规模；a,b,c：常量；X是从x1到xn的成本因素的向量；m：调整因子 • Walston和Felix的模型: E = 5.25 S 0.91 • Bailey 和Basili模型：E = 5.5 + 0.73 S1.16

44. 3.3 工作量估算算法方法 • 模型还包含一个生产率指标 • 29个因素可以影响生产率 • 如果增加了生产率，则为1 • 对生产率没有影响，则为0 • 降低了生产率，则为-1 • 用基本方程式对这29个因素加权来产生一个工作量估算

45. 3.3 工作量估算算法方法：Watson 和Felix模型生产率指标

46. 3.3 工作量估算算法方法：Bailey-Basili建模技术 • 通过最小化标准误差的方法建立了一个非常精确的估算公式E = 5.5 + 0.73S1.16 • 根据误差比率调整初始估计 • 如果R是实际工作量E，和估计工作量E’的比率，则工作量估计调整如下 • ERadj = R – 1 ，如果R > 1 = 1 – 1/R，如果R < 1 • 调整初始的工作量估计Eadj • Eadj = (1+ ERadj)E， if R > 1 = E/(1 + ERadj) ， if R < 1

47. 3.3 工作量估算算法方法：Bailey-Basili影响工作量的其它因素 对表中的每一项，根据项目经理的判断. 用0(不存在）到5 (非指重要)时项目进行评分

48. 3.3 工作量估算COCOMO 模型 • 20世纪70年代Boehm提出 • 20世纪90年代改进为COCOMO II • 更新的版本 • 包含复用的模型 • 基本模型 • E = bScm(X) • 其中 • bSc是初始的基于规模的估算 • m(X) 是成本驱动信息因子向量

49. 3.3 工作量估算COCOMO II：开发阶段 • 阶段1，构建原型 • 构建原型解决高风险的用户界面、系统交互问题 • 使用应用点来估算规模 • 阶段2，早期应用阶段 • 研究几种可选的体系结构和操作概念 • 使用功能点对规模进行测量 • 阶段3，后体系结构阶段 • 开发已经开始 • 使用代码行进行规模估算

50. COCOMO II的三个开发阶段