2. 进度安排
软件开发项目的进度安排有两 种方式： （1）系统最终交付日期已经 确定，软件开发部门必须在规 定期限内完成； （2）系统最终交付日期只确 定了大致的年限，最後交付日 期由软件开发部门确定。
进度安排落空，会导致市场机 会的丧失，使用户不满意，而 且也会导致成本的增加。 因此，在考虑进度安排时，要 把工作量与花费时间联系起来， 合理分配工作量, 利用进度安排 的有效分析方法严密监控软件 开发的进展情况，使软件开发 进度不致拖延。
软件项目计划—Observations on Estimating
估算需要：
经验 experience 了解以前有用的信息 access to good historical information 当仅存定性数据时进行定量测量的勇气 the courage to commit to quantitative predictions when qualitative information is all that exists.
那只猴子能用C编程， 非常快，代码紧凑高 效，所以值那么多钱。
$5000
哦，那是一只C++ 猴；它会面向对象的 编程，会用Visual C++， 还懂得一点Java，是非 常有用的
$10000
我们也不知 道它究竟能 做什么，不 过它是做项 目管理出身 的
$50000
Unit 3 软件项目计划
70年代中期
风险评估
风险识别—提出一个潜在破坏项目进度的风险 列表。 风险分析—评估每一个风险出现的可能性及其 影响，判定风险的级别。 风险优先级—按风险影响大小排出一个风险优 先级，这个风险列表将作为风险控制的基础。
风险控制
风险管理计划—制定一个应对每个重要风险的 方案，同时确保每一个单独的风险管理计划之 间以及与整体项目计划之间相一致。 风险化解—每个重要风险所对应计划的执行。 风险监控—对解决风险的过程进行监控，还可 以包括识别新的风险并将其反馈到正在进行的 风险管理进程中。
由于风险管理需要一定的成本，因此需要 确定风险的优先级，以便明确风险管理要 专注的重点。
定量
按风暴暴露量排序，确定风险优先级
定性
安排风险管理计划的进度
将风险管理计划和标准项目管理过程结合， 确保计划的执行 把风险管理计划的任务安排到项目进度表 中
Risk Resolution
避免风险 将风险从系统的一部分转移到另一部分 购买关于风险的信息 消除产生风险的根源 接受风险 发布风险 控制风险 记住风险
Risk Management Review
风险管理要素 Risk Management Principles 风险识别 Risk Identification 风险分析 Risk Analysis 风险的优先级 Risk Prioritization 风险管理计划 Risk Management planning 风险化解 Risk Resolution 风险监视 Risk Monitoring
亚里斯多德：
记住：应该满足于事物的本性所能 容许的精确度，当只能近似于真理 时，不要去寻求绝对的准确„„
软件项目计划—Project Planning Objectives
提供一个框架，使得管理者能够对资源、 成本及进度进行合理的估算。
一个限定的时间框架内 “最好的情况” 及“最坏的情况”
RE=不希望的损失的概率*损失的程度
RE= risk likelihood * risk impact
损失和概率的评估方法
由最熟悉系统的人评估每个风险的发生概 率，然后保留一份风险评估审核文件。 使用Delphi法：从一组专家中得到一致的意 见，来预测未来的发展。 少数服从多数法
Risk Prioritization
Risk Identification
如果你不问关于风险的问题， 你就可能是正在问所遇到麻烦的 问题
— Tom Gilb
确定可能对项目造成影响的风险，并且把 每一风险的特性编制成文档。 风险识别不是一次性活动，必须在整个项 目过程中经常进行 风险识别的工具和办法：
风险检查列表 调查问卷 interviewing Delphi 头脑风暴法 Brainstorming
风险
功能蔓延 需求镀金或开发人员镀金
化解方法
基于客户，控制功能集，针对变更的设计 修正需求，时间锁定，阶段交付，基于进度表
质量不定
计划过于乐观 设计欠佳 银弹综合症 研发导向的开发 人员薄弱 签约商失败 研发人员与客户的摩擦
给QA留出时间，注重质量保证基础
采用多估算实践，基于进度表，增量开发 清晰设计活动，足够设计时间，进行设计检查 建立软件度量计划，建立软件工具库 不要试图进行研究的同时使开发速度最快 招募，培训，团队建设 检查参考资料，分析承包能力，管理承包商 将客户纳入项目组中
Meiler Page-Jones：
我拜访了很多商业公司，我也观察了 很多数据处理的管理者，我常常恐惧地看 到这些管理者徒劳地与恶梦般的项目斗争 着，在根本不可能的最后期限下苦苦挣扎， 或是在交付了使其用户极为不满的系统之 后，又继续花费大量的时间去维护该系统。
管理的范围
有效的项目管理集中于三个P 上：
70%的项目是由于管理不善引起的， 而并不是因为技术实力不够
管理是影响软件研发项目全局 的因素，而技术因素只影响局 部。
90年代中期
美国软件工程实施现状的调查：
10%的项目能够在预定的费用和 进度下交付。
软件项目管理 成为软件项目开发中
最重要的核心问题之一。
什么是软件项目管理？
软件项目管理是为了使软件项目能够按照 预定的成本、进度、质量顺利完成，而对 成本、人员、进度、质量、风险等进行分 析和管理的活动。 软件项目管理的对象是软件工程项目，他 所涉及的范围覆盖了整个软件工程过程。
通过一个信息发现的过程实现的
软件项目计划—Software Scope
软件项目计划的第一个活动是软件范围的 确定。 软件范围描述了功能、性能、约束条件、 接口及可靠性。
软件项目计划—Software Scope
范围是通过回答下列问题来定义的：
背景：待建造的软件如何适应于大型的系统、产 品或商业的背景，在该背景下要加什么约束？ 信息目标：软件要产生什么样的客户可见的数据 对象输出，需要什么样的数据对象输入？ 功能和性能：软件执行什么样的功能使得输入数 据才能变换成为输出数据？需要满足什么特殊的 性能特征吗？
Overall Risk
风险因素
性能风险—产品能够满足需求且符合于其 使用目的的不确定的程度。 成本风险—项目预算能够被维持的不确定 的程度。 支持风险—软件易于纠错、适应及增强的 不确定的程度。 进度风险—项目进度能够被维持且产品能 按时交付的不确定的程度。
风险暴露量(Risk Exposure)
几种可考虑的选择
将估算拖延到项目的最后 基于已经完成的类似项目 使用简单的分解技术 使用经验模型
最常见的进度计划风险
功能无限蔓延 需求镀金或开发人员镀金 质量不定 计划过于乐观 设计欠佳 银弹综合症 研发导向的开发 人员薄弱 签约商失败 研发人员与客户的摩擦
People
项目参与者 项目负责人 软件项目组 协调和通讯
Problem
软件范围 问题分解
Process
合并问题和过程 过程分解
软件项目管理
软件项目计划 风险管理 进度安排
1. 软件项目计划
软件项目计划 Software Project Planning
对估算的观察 Observations on Estimating 项目计划目标 Project Planning Objectives 软件范围 Software Scope 资源 Resources 软件项目估算 Software Project Estimation 分解技术 Decomposition 经验估算模型 Empirical Estimation Models 自行开发或购买的决策 The Make/Buy Decision
软件项目计划—Resources
资源说明四特征
资源描述 可用性说明 需要该资源的时间 被使用的持续时间
软件项目计划—Resources
软件成本及工作量估算永远不会是一门精 确的科学。 可以从神秘的技巧向一系列系统化的步骤 转化
软件项目计划—Software Project Estimation
软件项目计划—Resources
主要资源 人员 极大地降低开 发成本，时间
可复用构件
硬件/软件工具
提供支持开发 工作的基础
软件项目计划—Resources
人力资源
描述组织的职位及专业技能等
可复用软件资源
可直接使用的构件 具有完全经验的构件 具有部分经验的构件 新构件
环境资源
硬件及软件
Risk Monitoring
检查每个风险的化解程度，并确定随着它 们的消失而带来的新的风险。
不断的识别新的风险 不断识别新的风险 不断的分析风险的产生概率 不断的整理风险表 不断的规避优先级别最高的风险
Same Example
监控因素
项目组成员对于项目压力的一般态度 项目组的凝聚力 项目组成员彼此之间的关系 与报和利益相关的潜在问题 在公司内和公司外工作的可能性 文档
Risk Analysis
重要的是量化不确定程度及与每个风险相 关的损失的程度。
Probability
Very low, low, medium, high and very high
Impact
Negligible, marginal, critical and catastrophic