- 转载自同学幕布，https://mubu.com/doc/explore/26583，幕布查看更佳
- 前言
- 软件项目管理概述
- 项目与软件项目
- 项目定义
- 项目是为了创造一个唯一的产品或提供一个唯一的服务而进行的临时性的努力。
- 项目特征
- 有明确的目标
- 项目之间的活动具有相关性
- 限定的周期
- 有独特性
- 资源成本的约束性
- 项目的不确定性
- 项目与日常运作的区别
- 项目是一次性的，日常运作是重复进行的，
- 项目是以目标为导向的，日常运作是通过效率和有效性体现的，
- 项目是通过项目经理及其团队工作完成的，而日常运作是职能式的线性管理；
- 项目存在大量的变更管理，而日常运作则基本保持连贯性的。
- 软件项目的特点
- 软件项目的组成要素
- 软件开发的过程
- 软件开发的结果
- 软件开发赖以生存的资源
- 软件项目的特定委托人
- 项目目标实现的制约因素
- 项目管理
- 项目管理背景
- 项目管理定义
- 项目管理是一系列的伴随着项目的进行而进行的、目的是为了确保项目能够达到期望的结果的一系列管理行为。
- 图示
- 开发项目管理
- 定义
- 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。
- 图示
- 项目管理知识体（ PMBOK ）
- 关于PMP
Project management Professional
- PMI在1984年提出项目管理认证计划(PMP)
- AT&T,Bell South,Bell Core,Bell Atlantic,Us West, Citibank,IBM,EDS ，ABB等参与，
- 是目前全球认可程度很高的项目管理专业认证
- 是项目管理资格重要的标志之一
- 详细信息参看：www.pmi.org
- PMBOK
- A guide to the Project management Body Of Knowledg
- 图示
- PMBOK的9个知识领域的关系
- 5个标准化过程组
- 软件开发项目管理的范围
- 项目管理的5要素
- 技术（Technical)
- 方法（Methodology）
- 团队建设（Team Building）
- 信息（Information）
- 沟通（Communication：80% jobs)
- 范围
- 战略上的范围
- 人员(People）
- 招聘，选择、业绩管理、培训、专业发展、组织和工作计划，团队精神、企业文化培养。
- 问题(Problem)
- 过程(Process)
- 技术上的范围
- 过程管理与软件项目管理的关系
- 不关注过程图示
- 关注过程图示
- 过程管理
- 过程管理，就是对过程进行管理，目的是要让过程能够被共享、复用，并得到持续的改进。
- 软件过程管理就是要注重循序渐进地积累，积累项目中的各个环节的实践经验和项目管理的实践经验，保证我们的生产力持续地发展。
- 过程管理和项目管理关系
- 图示
- 项目管理用于保证项目的成功，
- 过程管理用于管理最佳实践。
- 这两项管理不是相互孤立的，而是有机地紧密地结合的。
- 软件项目管理过程
- 图示
- 项目初始
- 项目计划
- 项目执行控制
- 项目结束
- 软件开发项目管理的核心
- 第一篇 项目初始
- 项目确立
- 项目立项
明确项目的目标、时间表、项目使用的资源和经费，而且得到执行该项目的项目经理和项目发起人的认可 .
- Make or Buy 决策
Make-or-Buy决策，确定待开发产品的哪些部分应当“采购”、“外包开发”或者“自主研发”。
- 决策实例
- 如果选择自己开发软件的策略，公司需要花费￥25,000，根据历史信息，维护这个软件每个月需要的费用是￥2,500。
- 如果选择购买软件公司产品的策略，需要￥17,000，同时软件公司为每个安装的软件进行维护的费用是每月￥2,700。
- 图示
- 合同项目
- 技术合同概念
- 技术合同是法人之间、法人和公民之间、公民之间以技术开发、技术转让、技术咨询和技术服务为内容，明确相互权利义务关系所达成的协议。
- 合同的生产期
- 甲方合同初始
- 合同准备
- 招标书定义(采购需求定义)
- 供方选择
- 合同文本准备
- 合同签署
- 合同管理
- 合同结束
- 乙方合同初始
- 内部项目
- 企业内部项目实施的核心是确定任务范围和相关各方进行有效地配合。这将通过相关各方之间的协议来调整。因此，在内部项目实施中，仅仅在合同签署过程中定义了一个协议签署过程。此处协议可视作为“合同”，但无特别的商业约束。其它方面可参考甲乙方的过程。
- 项目授权
- 项目章程
- 确认项目存在的文件，包括对项目的确认、对项目经理的授权和项目目标的概述等。
- 项目经理的角色
- 项目组织的领导者
- 项目组织的管理者
- 项目组织的决策者
- 项目组织的分析者
- 项目组织的计划者
- 项目组织的控制者
- 项目组织的组织者
- 项目组织的评价者
- 项目组织的协调者
- 项目经理的责任
- 生存期模型
- 生存期模型
- 软件开发的一种框架。
- 说明了软件的活动和进行软件开发的过程。
- 这个模型可以是以活动为中心，可以以产品为中心的。
- 生存期模型特征
- 描述了开发的主要阶段
- 定义了每一个阶段要完成的主要过程和活动
- 规范了每一个阶段的输入和输出
- 提供了一个框架，可以将必要的活动映射到该框架中。
- 常用的生存期模型
- 瀑布Waterfall
- 图示
- 适合的项目
- 在项目开始前,项目的需求很明确
- 在项目开始前,解决方案也很明确
- 类似的项目如：
- V模型V-shaped
- 图示
- 适合的项目
- 在项目开始前,项目的需求很明确
- 在项目开始前,解决方案也很明确
- 对系统的性能安全很严格的项目
- 类似的项目如：
- 原型Prototyping
- 图示
- 适合的项目
- 在项目开始前,项目的需求不明确
- 需要减少项目需求的不确定性
- 类似的项目如：
- 增量Incremental
- 图示
- 适合的项目
- 项目开始，明确了需求的大部分，但是需求可能会发生变化
- 对于市场和用户把握不是很准，需要逐步了解
- 对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的。
- 螺旋式Spiral
- 图示
- 过程
- 螺旋模型沿着螺线旋转，在四个象限上分别表达了四个方面的活动，即：
- 制定计划──确定软件目标，需求和选定实施方案，弄清项目开发的限制条件
- 风险分析──评估所选方案，考虑如何识别和消除风险
- 实施工程──实施软件开发，编码，测试等
- 客户评估──评价开发工作，提出修正建议，规划下期任务
- 适合的项目
- 风险是主要的制约因素
- 不确定因素和风险限制了项目进度
- 用户对自己的需求也不是很明确
- 需要对一些基本的概念进行验证
- 可能发生一些重大的变更
- 项目规模很大
- 项目中采用了新技术
- 快速应用开发RAD
- 图示
- 适合的项目
- 很小并且具有探索性质的项目
- 适合一个复杂度从小到大变化的项目，例如重整企业的信息系统
- 渐近式阶段
综合了增量模型和螺旋式模型的一个实用模型渐进式前进阶段式提交
- 图示
- 特点
- 阶段式提交一个可运行的产品
- 关键的功能更早出现
- 早期预警问题，避免软件缺陷不知不觉的增长
- 减少报告负担
- 阶段性完成可以降低估计失误
- 阶段性完成均衡了弹性与效率
- 适合的项目
- 可以适合任何规模的项目，主要是中型或大型项目
- 希望随时看到未来的项目
- 选择生存期的步骤
- 熟悉各种生存期模型
- 评审、分析项目的特性
- 选择适合项目的生存期模型
- 标识生存期模型与项目不一致地方,并进行裁减
- 第二篇 项目计划
核心三计划：范围计划、进度计划、成本计划
- 软件项目范围计划——需求管理
需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。
- 软件需求的层次
- 软件需求管理过程
- 需求工程基本任务
- 图示
- 需求获取
- 需求分析
- 需求分析定义
- 需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。
- 需求分析任务
- 借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题
- 需求分析模型
- 需求规格
- 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书
- 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。
- 需求规格说明的原则
- 从现实中分离功能，即描述要“做什么”而不是“怎样实现”
- 采用一定的规格说明语言
- 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
- 规格说明应该包括系统运行环境
- 规格说明应该是一个认识模型
- 规格说明应该容许不完备性并允许扩充
- 需求规格文档参考
- 引言
- 系统定义
- 应用环境
- 功能规格
- 性能需求
- 产品提交
- 实现约束
- 质量描述
- 其它
- 签字认证
- 需求验证
- 需求是正确的吗？
- 需求是一致的吗？
- 需求是完全的吗？
- 需求是实际可行的吗？
- 需求是必要的吗？
- 需求是可检验的吗？
- 需求是可跟踪的吗？
- 最后的签字
- 软件项目范围计划——任务分解
- 任务分解的定义
- 任务分解的过程
- 将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。
- 任务分解的结果
- WBS
- Work packages（工作包）
- 任务分解的类型
- 清单
- 实例
- 1. 变化计数器
- 1.1 比较两个版本的程序
- 1.1.1 预处理
- 1.1.2 文件比较
- 1.1.3 结果处理
- 1.2 找出修改后的程序中增加和删除的代码行
- 1.2.1 找出增加的代码行
- 1.2.2 找出删除的代码行
- 1.3 统计修改后的程序中增加和删除的代码行数
- 1.3.1 统计增加代码行数
- 1.3.2 统计删除代码行数
- 1.4 统计总的代码行数
- 1.5 设定标记以指示修改的次数
- 1.6 在程序的头部增加修改纪录
- 图表
- 任务分解的过程
- 任务分解的方法
- 任务分解的步骤
- 确认并分解项目的组成要素
- 确定分解标准
- 确定分解是否详细
- 检验分解结果的标准
- 最底层的要素是否是实现目标的充分必要条件
- 最底层要素是否有重复的
- 每个要素是否清晰完整定义
- 最底层要素是否有定义清晰的责任人,是否可以进行成本估算和进度安排
- 确定项目交付成果
- 验证分解的正确性(建立编号)
- 软件项目进度计划
- 进度管理的基本概念及过程
- 进度的定义
- 进度管理定义
- 进度管理的重要性
- 按时完成项目是项目经理最大的挑战之一
- 时间是项目规划中灵活性最小的因素
- 进度问题是项目冲突的主要原因，尤其在项目的后期
- 进度管理的过程
- 活动定义（Activitydefinition）
- 确定为完成项目的各个交付成果所必须进行的诸项具体活动
- 图示
- 活动排序（Activitysequencing）
- 项目各项活动之间存在相互联系与相互依赖关系,
- 根据这些关系进行适当的顺序安排
- 前置活动（任务）---〉后置活动（任务）
- 任务活动之间的关系
- 排序的依据
- 强制性依赖关系
- 强制性依赖关系也称为硬逻辑关系、这是活动固有的依赖关系，这种关系是活动之间本身存在的、无法改变的逻辑关系。例如，在建筑工程项目中，只有打好了地基，才能开始砌砖；在软件开发项目中，只有进行了需求分析，才能进行软件设计。也可以是相关合同强制规定的依赖关系，项目团队通常无法改变这种逻辑关系。
- 软逻辑关系
- 软逻辑关系是人为组织确定的一种先后关系例如，可以是项目管理团队确定的一种关系，基于项日团队的经验、偏好、习惯等，由项目团队自行选择的逻辑关系。在实际工作中，很多活动之间的关系是可以调整的。
- 例如，在信息系统集成项目中，是先进行网络布线后进行代码编写，还是先进行代码编写后进行网络布线，可以由项目管理团队根据人员安排情况进行确定；在软件开发项目中，是先进行数据库设计后进行软件模块设计，还是先进行软件模块设计后进行数据库设计，也可以由软件开发团队根据人员安排情况进行确定。
- 在进行活动排序时，要重点针对相互之间具有选择性逻辑关系的各种活动进行调整，以便缩短整个项目的工期。
- 外部依赖关系
- 外部依赖关系涉及到项目与非项目活动之间的关系，往往取决于项目外部的任何第三方的逻辑关系，例如，政府部门的批准、供货商的供货等。项目团队可以对外部依赖关系施加一定的影响，但通常无法掌控。例如，在一个典型的系统集成项目中，如果买方自己负责设备采购，系统测试活动就与设备采购活动之间具有外部依赖关系。因为如果设备采购不到位，系统测试就无法进行，而设备采购活动不由卖方决定。
- 活动资源估计(Activityresource estimating)
- 活动历时估计(Activityduration estimating)
- 制定进度计划（Scheduledevelopment）
- 进度控制（Schedule control）-项目跟踪
- 进度管理图示
- 网络图
- 网络图是活动排序的一个输出
- 展示项目中的各个活动以及活动之间的逻辑关系
- 网络图可以表达活动的历时
- 常用的网络图
- PDM (Precedence Diagramming Method ）
优先图法 ,节点法 (单代号)网络图
- 图例
- 详解
- 构成PDM网络图的基本特点是节点(Box)
- 节点(Box)表示活动(工序,工作)
- 用箭线表示各活动(工序,工作)之间的逻辑关系.
- 可以方便的表示活动之间的各种逻辑关系。
- 在软件项目中PDM比ADM更通用
- PDM (Precedence Diagramming Method )-优先图法图例
- ADM (Arrow Diagramming Method )
箭线法 (双代号)网络图
- 图例
- 解释
- ADM也称为AOA （activity-on-arrow）或者双代号项目网络图，
- 在ADM网络图中,箭线表示活动(工序\工作),
- 节点Node（圆圈:circle）表示前一道工序的结束,同时也表示后一道工序的开始.
- 只适合表示结束-开始的逻辑关系
- ADM图例-虚活动
- 甘特图
- 实例
- 显示基本的任务信息
- 可以查看任务的工期、开始时间和结束时间以及资源的信息。
- 只有时标，没有活动的逻辑关系
- 里程碑图
- 图示
- 里程碑显示项目进展中的重大工作完成
- 里程碑不同于活动
- 资源图
- 进度估算的基本方法
- 项目进度估算是估计任务的持续时间-历时估计
- 项目进度估算的基本方法
- 基于规模的进度估算
- 定额估算法
- 公式
- T=Q/(R*S)
- T:活动持续时间
- Q:活动的工作量
- R:人力或设备的数量
- S:产量定额,以单位时间完成的工作量表示
- 举例
- 方法比较的简单，容易计算。
- 适合项目的规模比较小，比如说小于10000LOC或者说小于6个月的项目
- 经验导出模型
- 公式
- 经验导出模型
- D:月进度
- E：人月工作量
- a=2—4
- b:1/3左右:依赖于项目的自然属性
- 建议掌握模型
- 图示
- 解释
- 组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）
- 嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。
- 半独立型（semidetached）： 介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。
- 举例
- 项目的规模E＝152ＰM， 采用基本COCOMO模型估算的进度
- D=2.5＊E ^ 0.35 =2.5*152 ^ 0.35＝14.5 M
- 其他模型举例
- 如果：E=65人月，并且a=3，b=1/3
- 则：D= 3 * 65 exp(1/3)=12月
- CPM
关键路径法估计（CPM： Critical Path Method ）
- 根据指定的网络顺序逻辑关系,进行单一的历时估算
- 当估算项目中某项单独的活动，时间比较确定的时候采用
- 图示
- PERT
工程评价技术（Program Evaluation and Review Technique)
- 用网络顺序图逻辑关系和加权历时估算来计算项目历时的技术。
- 当估算项目中某项单独的活动，存在很大的不确定性时采用。
- 公式
- 它是基于对某项任务的乐观，悲观以及最可能的概率时间估计
- 采用加权平均得到期望值E=（O+4m+P)/6，
- O是最小估算值:乐观(Optimistic)，
- P是最大估算值:悲观(Pessimistic)，
- M是最大可能估算(Most Likely)。
- 举例
- PERT/CPM区别
- PERT
- 计算历时采用的算法:加权平均（O+4m+P)/6
- 估计值不明确
- CPM
- 基于进度表的进度估算
- 可能的最短进度表
- 人员
- 人才库中前10%的最拔尖的人，
- 有几年应用编程语言和编程环境的工作经验，
- 开发人员掌握了应用领域的详细知识，
- 目标明确，努力工作，
- 分享成果，团队和谐
- 不存在人员调整
- 管理
- 理想的项目管理
- 开发人员可以专著于本职的工作
- 采用矩形员工模式
- 工具支持
- 有先进的软件开发工具
- 开发人员可以无限制的使用资源
- 工作环境理想，在集中的工作区域开发
- 交流工具畅通
- 方法
- 使用最时效的开发方法和开发工具
- 设计阶段开始的时候已经完全了解需求
- 需求不变更
- 压缩
- 图示
- 有效进度表
- 人员
- 人才库中前25%的最拔尖的人，
- 有1年应用编程语言和编程环境的工作经验，
- 目标有共同的看法，相互之间没有严重冲突，
- 采用有效的人员模式
- 人员调整少于 6%
- 其他
- 有效的编程工具
- 主动的风险管理
- 优良的物理环境
- 沟通工具方便
- 图示
- 普通进度表
- 人员
- 人才库中等以上的人
- 与编程语言和编程环境一般熟悉
- 开发人员对应用领域有一定的经验，但不丰富
- 团队不是很有凝聚力，但解决冲突时，有一定的经验
- 每年经历人员调整10-12%
- 其他
- 编程工具在一定程度上使用
- 风险管理不像理想那样得力
- 交流工具容易使用，
- 工作环境有些一般，不是很理想
- 进度压缩一般
- 图示
- 三种进度比较
- 可能的最短进度简直无法实现
- 有效进度代表了“最佳进度”
- 普通进度是为一般项目实用的
- 基于承诺的进度估计
- 从需求出发去安排进度
- 不进行中间的工作量（规模）估计
- 要求开发人员做出进度承诺，非进度估算
- 优点
- 有利于开发者对进度的关注
- 有利于开发者在接受承诺之后的士气高昂
- 缺点
- Jones的一阶估算准则
- 取得功能点的总和
- 从幂次表中选择合适的幂次将它升幂
- 幂次表
- 举例
- 如果，FP=350，平均水平的商业软件公司
- 则，粗略的进度= 350exp(0.43)=12月
- 其它策略
- 专家估算方法
- 类推估计
- 模拟估算
- 利用估算软件估算进度
- 利用企业的历史数据
- 编制进度计划
- 编制项目进度计划
- 确定项目的所有活动及其开始和结束时间
- 计划是三维的，考虑时间，费用和资源
- 监控项目实施的基础，它是项目管理的基准
- 编制项目核心(进度)计划步骤
- 进度编制
- 基本方法
- 关键路径法
CPM： Critical Path Method
- 关键路径的说明
没整理全，具体请看3.ppt 98-112
- 根据指定的网络图逻辑关系和单一的历时估算，计算每一个活动的单一的、确定的最早和最迟开始和完成日期。
- 计算浮动时间。
- 浮动时间
- 浮动时间是一个活动的机动性,它是一个活动在不影响其它活动或者项目完成的情况下可以延迟的时间量
- 自由与总浮动时间
- 总浮动（ Total Float）
- 自由浮动（Free Float）
- 计算网络图中最长的路径。
- 确定项目完成时间
- 例子
- 正推法
按照时间顺序计算最早开始时间和最早完成时间的方法,称为正推法
- 首先建立项目的开始时间
- 项目的开始时间是网络图中第一个活动的最早开始时间
- 从左到右，从上到下进行任务编排
- 当一个任务有多个前置时，选择其中最大的最早完成日期作为其后置任务的最早开始日期
- 公式
- ES+Duration=EF
- EF+Lag=ESs
- 图例
- 逆推法
按照逆时间顺序计算最晚开始时间和最晚结束时间的方法,称为逆推法.
- 首先建立项目的结束时间
- 项目的结束时间是网络图中最后一个活动的最晚结束时间
- 从右到左，从上到下进行计算
- 当一个前置任务有多个后置任务时，选择其中最小最晚开始日期作为其前置任务的最晚完成日期
- 公式
- LF-Duration=LS
- LS-Lag=LFp
- 图例
- 课堂练习
- 问题
- 作为项目经理，你需要给一个软件项目做计划安排，经过任务分解后得到任务A，B，C，D，E，F，G，假设各个任务之间没有滞后和超前，下图是这个项目的PDM网络图。通过历时估计已经估算出每个任务的工期，现已标识在PDM网络图上。假设项目的最早开工日期是第０天，请计算每个任务的最早开始时间，最晚开始时间，最早完成时间，最晚完成时间，同时确定关键路径，并计算关键路径的长度，计算任务F的自由浮动和总浮动.
-
- 答案
- 时间压缩法
时间压缩法是在不改变项目范围的前提下缩短项目工期的方法
- 应急法--赶工（Crash）
赶工也称为时间-成本平衡方法
- 在不改变活动的前提下，通过压缩某一个或者多个活动的时间来达到缩短整个项目工期的目的
- 在最小相关成本增加的条件下，压缩关键路经上的关键活动历时的方法
- 进度压缩
- 进度压缩的费用
- 进度压缩单位成本方法
- Charles Symons(1991)方法
- 进度压缩比普通进度短的时候，费用迅速上涨
- 公式
- 进度压缩因子=压缩进度/正常进度
- 压缩进度的工作量=正常工作量/进度压缩因子
- 例如：
- 初始进度估算是12月，初始工作量估算是78人月，
- 如果进度压缩到10月，进度压缩因子= 10/12=0.83，
- 则进度压缩后的工作量是：78/ 0.83=94人月
- 总结：进度缩短17%，增加21%的工作量
- 研究表明：进度压缩因子〉0.75，最多可以压缩25％
- 进度压缩单位成本方法
前提：活动的正常与压缩
- 项目活动的正常值
- 项目活动的压缩值
- 公式
- 进度压缩单位成本=（压缩成本-正常成本）/(正常进度-压缩进度)
- 举例
- 任务A:正常进度7周,成本5万；压缩到5周的成本是6.2万
- 进度压缩单位成本=(6.2-5)/(7-5)=6000元/周
- 如果压缩到6周的成本是：5.6万
- 时间压缩
- 平行作业法--快速跟进（Fast tracking:搭接）
是在改变活动间的逻辑关系，并行开展某些活动
- 关键链法
- 预备知识
- 管理预留
- 约束理论
- 所有现实系统都存在约束。
- 约束的存在表明系统存在改进的机会。
- 五大关键步骤
- 找出系统中的约束因素；
- 决定如何挖掘约束因素的潜力；
- 使系统中所有其他工作服从于第二步的决策；
- 提升约束因素的能力；
- 若该约束已经转化为非约束性因素，则回到第一步，否则回到第二步，要注意不要让思维惯性成为新的主要约束因素。
- 图示
- 资源调整
- 成本预算
- 计划优化调整
- 计划基线
- 软件项目成本计划
- 软件项目规模成本的概念
- 关于估算
- 估算不是很准确的，有误差的
- 经验（历史）数据非常重要
- 不要太迷信数学模型
- 软件项目规模
- 软件项目规模即工作量，是从软件项目范围中抽出的软件功能，然后确定每个软件功能所必须执行的一系列软件工程任务
- 包括：软件规划，软件管理，需求，设计，编码，测试，以及后期的维护等任务。
- 规模的单位
- LOC(Loc of Code)
- FP(Function Point)
- 人月
- 人天
- 人年
- 软件项目成本
- 完成软件规模相应付出的代价。
- 待开发的软件项目需要的资金。
- 人的劳动的消耗所需要的代价是软件产品的主要成本
- 成本的单位
- 软件的规模和成本的关系
- 规模是成本的主要因素，是成本估算的基础
- 有了规模就确定了成本
- 估算的过程
- 图示
- 估算输入
- 项目需求、WBS
- 历史项目度量
- 资源要求（资源编制计划）
- 资源消耗率:如人员成本:100元/小时
- 进度规划：项目总进度（一般是合同要求）
- 学习曲线
- 成本估算方法
- 直接成本
- 间接成本
- 不能具体到某个项目中的成本
- 可以分摊到各个具体项目中的成本，例如：
- 培训
- 房租水电
- 员工福利
- 市场费用
- 管理费
- 其他等等
- 估算结果
- 估算文件
- 资源，资源的数量，质量标准，估算成本等信息
- 单位：一般是货币单位
- BAC(Budget At completion)
- 估算说明
- 工作范围
- 估算的基础和依据
- 估算的假设
- 估算的误差变动等
- 估算说明
- 预测所需要的总工作量的过程。
- 是一种量化的结果
- 可以有一些误差
- 成本估算不同于项目定价
- 贯穿于软件的生存周期。
- 估算的方法
- 基本方法
- 代码行、功能点
- 代码行（LOC）
从软件程序量的角度定义项目规模。
- 要求功能分解足够详细的
- 有一定的经验数据（类比和经验方法）
- 与具体的编程语言有关
- 优点
- 代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数。
- 缺点
- 对代码行没有公认的可接受的标准定义
- 代码行数量依赖于所用的编程语言和个人的编程风格.
- 在项目早期,需求不稳定、设计不成熟、实现不确定的情况下很难准确地估算代码量.
- 代码行强调编码的工作量,只是项目实现阶段的一部分
- 功能点（FP: Function point）
用系统的功能数量来测量其规模与实现产品所使用的语言和技术没有关系的
- 两个评估
- 加权和量化
- 公式
- FP=UFC*TCF
- UFC：未调整功能点计数
- TCF：技术复杂度因子
- 计数复杂度因子
- 计数复杂度因子的取值范围
- 实例
- FP=UFC*TCF
- UFC=301
- TCF=0.65+0.01(14*3)=1.07
- FP=301*1.07=322
- 功能点与代码行的转换
- 类比 (自顶向下)估算法
- 类比的定义
- 估算人员根据以往的完成类似项目所消耗的总成本（或工作量），来推算将要开发的软件的总成本（或工作量），然后按比例将它分配到各个开发任务单元中
- 是一种自上而下的估算形式
- 类比的使用情况
- 有类似的历史项目数据
- 信息不足（要求不是非常精确)的时候
- 在合同期和市场招标时
- 类比的特点
- 简单易行,花费少
- 具有一定的局限性
- 准确性差,可能导致项目出现困难
- 自下而上估算法
- 自下而上的定义
- 利用任务分解结构图,对各个具体工作包进行详细的成本估算,然后将结果累加起来得出项目总成本。
- 自下而上的使用情况
- 项目开始以后，WBS的开发阶段
- 需要进行准确估算的时候
- 自下而上的特点
- 这种方法相对比较准确，它的准确度来源于每个任务的估算情况
- 非常费时,估算本身也需要成本支持
- 可能发生虚报现象
- 参数法估算法
- 参数估算法的定义
- 一种使用项目特性参数建立数据模型来估算成本的方法，是一种统计技术，如回归分析和学习曲线。
- 参数估算法的使用情况
- 存在成熟的项目估算模型
- 应该具有良好的数据库数据为基础
- 参数估算法的特点
- 比较简单,而且也比较准确
- 如果模型选择不当或者数据不准,也会导致偏差
- 经验导出成本模型
- 提供工作量(规模)的直接估计
- 通过过去项目数据,进行回归分析,得出的回归模型
- 整体公式
- E=A+B*SC
- E:以人月表示的工作量
- A,B,C:经验导出的系数
- S:主要的输入参数(通常是LOC,FP等)
- 面向LOC驱动的
- Walston-Felix(IBM)
- Balley-Basili
- .COCOMO
- Doty
- 面向FP驱动的
- Albrechtand Gaffney
- Matson,Barnett
- 建议掌握模型
- ＩＢＭ模型－（Walston-Felix）
1977年，IBM的Walston和Felix提出的估算公式
- E ＝ 5.2×L ^0.91 ，L是源代码行数(以KLOC计)，E是工作量（以PM计）
- D ＝ 4.1×L ^ 0.36，D是项目持续时间(以月计)
- S ＝ 0.54×E ^ 0.6，S是人员需要量(以人计)
- DOC ＝ 49×L ^ 1.01。DOC是文档数量(以页计)
- 举例
- 采用java 完成项目，366功能点，则
- L =366×46 = 16386行 =16.386KLOC
- E ＝ 5.2×L ^0.91 ＝ 5.2×16.386^ 0.91 ＝ 66人月
- DOC＝ 49×L ^1.01 ＝ 49×16.386^ 1.01 ＝ 826页
- COCOMO模型－(Boehm）
结构化成本模型 是世界上应用最广泛的参数型软件成本估计模型由Barry Boehm开发的
- COCOMO模型发展
- COCOMO 81
- 模型类别
- 基本COCOMO
静态单变量模型
- 公式
- E= a(KLOC)exp(b)
- E是所需的人力（人月），
- KLOC是交付的代码行
- a ， b是依赖于项目自然属性的参数：
- 基本COCOMO系数表
- 举例
- 一个33.3KLOC的软件开发项目，属于中等规模、半有机型的项目，采用基本COCOMO：
- a=3.0，b=1.12。
- E =3.0＊L ^1.12= 3.0＊33.3 ^1.12= 152 PM
- 中等COCOMO
基本模型基础上考虑影响因素，调整模型
- 公式
- E=a(KLOC)exp(b)*乘法因子
- a b是系数
- 乘法因子是根据成本驱动属性打分的结果，对公式的校正系数
- 中等COCOMO系数表
- 乘法因子
- 属性
- 图示
- 乘法因子计算
- 每个属性Fi的取值范围为： 很低、低、正常、高、很高、极高，共六级。正常情况下 Fi=1。
- 当每个Fi的值选定后，乘法因子的计算如下 乘法因子＝F1*F2*… Fi …* Fn
- 举例
- 一个33.3KLOC的软件开发项目，属于中等规模、半有机型的项目，采用中等COCOMO模型
- a=3.0，b=1.12。
- 乘法因子＝0.70*0.85*1……*1.15=1.09
- E = 3.0＊L ^1.12= 3.0＊33.3 ^1.12×１.０９＝１６６PM
- 高级COCOMO
中等COCOMO模型基础上考虑各个步骤的影响
- 将项目分解为一系列的子系统或者子模型
- 在一组子模型的基础上更加精确地调整一个模型的属性
- 图示
- 项目类型
- 有机:Organic
- 各类应用程序，例如数据处理、科学计算等
- 受硬件的约束比较小，程序的规模不是很大
- 嵌入式:Embedded
- 系统程序，例如实时处理、控制程序等
- 紧密联系的硬件、软件和操作的限制条件下运行，软件规模任意
- 半有机:Semidetached
- 各类实用程序，介于上述两种软件之间，例如编译器（程序）
- 规模和复杂度都属于中等或者更高
- 专家估算法
由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值,最后得出综合的估算值。
- 流程
- 组织者发给每位专家一份软件系统的规格说明和一张记录估算值的表格，请他们估算
- 专家详细研究软件规格说明后，对该软件提出3个规模的估算值
- 组织者对专家的表格中的答复进行整理
- 计算每位专家的Ei=(ai+4mi+bi)/6
- 综合结果后:E=E1+E2+…En/n（N:表示N 个专家）
- 再组织专家无记名填表格，比较估算差，并查找原因
- 如果各个专家的估算差异超出规定的范围（例如：15%），则需重复上述过程，最终可以获得一个多数专家共识的软件规模
- 举例
- 某多媒体信息查询系统—专家估算
- 专家1：1，8，9=〉（1+9+4* 8 ）/6=7（万元）
- 专家2： 4， 6 ， 8=〉（4+8+4*6）/6=6 （万元）
- 估算结果=（6+7）/2=6.5（万元）
- 综述
- 主要考虑三种模型
- 自下而上法费时费力,参数法比较简单
- 自下向上法与参数法的估计精度相似
- 类比法通常用来验证参数法和自下而上法的结果
- 各种方法不是孤立的,应该注意相互的结合使用
- 实用软件估算模型
- 是一种自下而上和参数法的结合模型,步骤如下:
- 对任务进行分解:1,2,…,i…
- 估算每个任务的成本Ei
- 直接估算成本Ei
- 先估算规模Qi，然后估算成本Ei= Qi *人力成本参数
- 唯一估计值：Qi=Avg
- PERT算法: Qi=(Max+4Avg+Min)/6
- 直接成本=E1+E2+……+Ei+……+ En
- 项目总估算成本
- 项目总估算成本= 直接成本+间接成本
- 直接成本
- 直接成本=规模*人力成本参数
- 直接成本组成
- 例如：人力成本参数=2万/人月，30人月规模的项目的直接成本是 60万
- 简易估算
- 开发（工作量）规模：Scale(Dev) (单位：人月)
- 管理、质量（工作量）规模：Scale(Mgn)=a* Scale(Dev)
- 直接成本＝ Scale(Dev) ＋ a*Scale(Dev)
- 间接成本
- 按照企业模型直接估算
- 简易算法
- 间接成本=直接成本*间接成本系数
- 间接成本= 规模*人力成本参数*间接成本系数
- 例如：间接成本系数=0.3
- 项目总报价
- 项目总报价=项目总估算成本+风险利润
- 风险利润=利润+风险基金+税
- 项目利润=估算成本*a%
- 风险基金=估算成本*b%
- 税=估算成本*c%(例如:c为5.5左右)
- 项目总报价=(a+b+c) %*项目总估算成本+项目总估算成本
- 成本预算
成本预算是将项目的总成本按照项目的进度分摊到各个工作单元中去。成本预算将总的成本安排到各个任务中
- 目的
- 分配项目成本预算包括三种情况
- 分配资源成本
- 给任务分配固定资源成本
- 当一个项目的资源需要固定数量的资金时，用户可以向任务分配固定资源成本。
- 例如：需要的硬件设备
- 给任务分配固定成本
- 有些任务是固定成本的类型的任务，也就是说，用户知道某项任务的成本不变，不管任务的工期有多长，或不管任务使用了那些资源。在这种情况下，用户向任务直接分配成本。
- 例如：培训任务
- 估算准确度
- 估算不准的原因
- 基础数据不足
- 缺乏经验的估算人员
- 签约前后不连贯
- 低劣的推测技术
- 估算对需求的敏感性
- 避免低劣估算
- 避免无准备的估算
- 留出估算的时间，并做好计划
- 使用以前的项目数据
- 使用开发人员提供的数据为基础估算
- 分类法估算
- 详细的较低层次上的估算
- 使用软件估算工具
- 使用几种不同估算技术，并比较它们的结果
- 估算的表达方式技巧
- 项目核心（进度）计划
- 编制项目核心(进度)计划步骤
- 进度编制
- 资源调整
- 成本预算
- 计划优化调整
- 计划优化调整
- 调整资源,解决资源冲突
- 调整进度,优化项目,缩短工期
- 调整项目成本预算,以便减少项目费用
- 调整资源,解决资源冲突
- 资源冲突(过度分配)主要有两种表现：
- 1、分配给一个资源的工时总量大于它的最大可用工时量。
- 2、同一种资源被分配给时间上重叠的几个任务或项目中。
- 解决资源冲突的方法
- 资源调配
- 推迟资源开始工作时间
- 替换资源
- 设置资源加班时间
- 调整资源日历
- 只使用资源的一部分工作时间
- 优化进度,缩短工期
项目中各任务的执行时间是否合理,有无冲突现象尽可能缩短项目工期
- 分解关键任务
- 注意：通过“分解关键任务”可以缩短任务工期，但有时候，受资源量的限制，有些任务是不能同步进行的，所以这时任务分拆也无助于缩短项目周期。
- 给任务增加资源
- 注意：
- 增加的资源数量不能大于资源的最大可用量。
- 增加资源必须是主导项目工期的关键路径上。
- 关键任务的缩短可能会变成非关键任务，因此，此时增加过多的资源是无法达到继续缩短总工期的目的的。
- 缩减关键任务的工期
- 注意：在任务已分配了资源的情况下，缩短任务工期意味着增加资源的工作量，可能导致资源的过度分配。
- 重叠关键任务
- 设置日历增加工作时间
- 可以通过改变资源的日历来调整工期，比如将资源原来的休息时间改变成工作时间来实现。这样通过增加资源的工作时间来缩短任务的工期。
- 通过分配加班工时来缩短关键任务
- 需要在关键任务上为资源设置加班时间，以缩短任务工期。
- 调整项目成本预算
- 降低预算成本的方法
- 降低资源的费率
- 减少任务的工时
- 减少加班
- 替换资源
- 减少任务的固定成本
- 删除任务
- 减少项目成本
- 降低资源的费率
- 降低资源的费率往往会打击工作人员的积极性，但可以通过降低其他资源的费率来实现，比如降低能源消耗、设备费用等。
- 减少任务的工时
- 适当的减少工时，可以降低任务的费用。但减少工时同时也影响项目的工期。
- 减少加班
- 加班需要支付加班费率，这通常要高于资源费率，所以减少加班可以有效的减少任务成本。
- 替换资源
- 用廉价的资源替换比较高价的资源，但有一个前提，那就是替换的资源同样能胜任这项任务。
- 减少任务的固定成本
- 删除任务
- 确认删除改任务对项目没有影响或影响在可控制范围内才可采用。
- 最后审查
- 计划基线
- 小结
- 软件项目质量计划
- 软件质量的基本概念
- 质量的多种定义
- 符合目的或者用途(Joseph Juran)
- 用户的感觉就是质量(A V Feigenbaum)
- 符合顾客在其合理价格下对产品的要求(Sud Ingle)
- 产品或者服务满足明确和隐含需要能力的性能特性的总体(BS4778)
- 质量定义
- 质量是满足要求的程度,包括符合规定的要求和满足顾客的需求.
- 软件质量
- 软件质量框架模型
- McCall质量模型
- 主观质量模型-ICEDT模型
- I：直观性
- C：一致性
- E：效率
- D：耐久性
- T：体贴
- 质量的重要性
质量管理是项目管理的最高统一（三大目标的统一）
- 图示
- 软件危机的主要矛盾
- 低质量的软件就像定时炸弹
- 低质量的产品，增加成本
- 质量是生命也是信誉
- 质量的形成
- 质量形成于产品或者服务的开发过程中，而不是事后的检查（测试）把关等。
- 质量管理理论的发展过程
- 软件质量管理的发展过程
- 决定质量的因素
- 其他
- 软件质量管理过程
- 图示
- 质量管理
- 软件质量管理过程
- 软件项目的质量计划
- 确定项目应达到的质量标准
- 决定如何满足质量标准的计划安排和方法
- 软件质量保证
- 通过评价项目整体绩效,建立对质量要求的信任
- 提供项目和产品可视化的管理报告
- 例如：《总体设计规格》质量审计
- Is it done right?
- 这个任务本身并不能提高产品的质量
- 一般由质量保证部门人员实施
- 项目绩效评价的作用
- 确保业主获知工程项目进展情况，满足业主检查工程项目进展情况的需求。
- 进一步确认项目组织对工程项目承诺的实现程度.
- 作为预测项目建设终结绩效的依据。
- 尽早发现项目实施的问题，以便提前采取措施。
- 作为考核工作成果，实施奖惩的依据。
- 质量保证的要点
- 对项目进行评价
- 推测能否达到质量指标
- 建立对项目的信心
- 质量保证活动-审计(Audit)
- 审计(Audit) 是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较
- 目的是确保真正的遵循了这一个过程，产生了合适的文档和精确反映实际项目的报告
- 可以预先规划的，也可以是临时决定的。
- 软件项目中常用的质量保证活动
- 软件质量控制
- 质量控制的要点
- 检查工作结果
- 按照标准跟踪检查
- 确定措施消灭质量问题
- 质量控制活动
- 技术评审
- 代码走查
- 测试
- 返工
- 控制图
- 控制图由正态分布演变而来。
- 正态分布可用两个参数即均值μ和标准差σ来决定。正态分布有一个结论对质量管理很有用，即无论均值μ和标准差σ取何值，产品质量特性值落在μ±3σ之间的概率为99.73%，落在μ±3σ之外的概率为100%-99.73%= 0.27%，而超过一侧，即大于μ+3σ 或小于μ-3σ的概率为0.27%/2=0.135%≈1‰,休哈特就根据这一事实提出了控制图。
- 由于上下的数值大小不合常规，再把分布图上下翻转180°，这样就得到一个单值控制图，称μ+3σ为上控制限，记为UCL，称μ为中心线，记为CL，称μ-3σ为下控制限，记为LCL,这三者统称为控制线。规定中心线用实线绘制，上下控制限用虚线绘制。
- 剩余5.ppt 37-39
- 趋势分析
- 趋势分析是指运用数字技巧，依据过去的成果预测将来的产品。趋势分析常用来监技术上的绩效：有多少错误和缺陷已被指出，有多少仍未纠正。如随着时间的推移，缺陷发生率呈上。升趋势。趋势图的主要优点是便于绘制，易于理解。
- 抽样统计
- 软件质量计划
- 质量计划
- 项目应达到的质量目标和所有特性的要求
- 确定项目中的质量活动和质量控制程序
- 项目不同阶段，职责，权限，交流方式以及资源分配
- 确定项目采用的控制手段,合适的验证手段和方法
- 确定和准备质量记录
- 质量计划方法
- 试验设计
- 试验设计是一种统计学方法，确定哪些因素可能会对特定变量产生影响。
- 基准对照
- 是一种寻找最佳实践的方法，是利用其他项目的实施情况作为当前项目性能衡量的标准。它通过审查项目的提交结果、项目管理过程、项目成功或者失败的原因等来衡量本项目的绩效。
- 质量成本分析
- 流程图方法
- 可以显示系统的各种成分是相互的关系，帮助我们预测在何处可能发生何种质量问题，并由此帮助开发处理他们的办法。
- 因果分析图
- 描述相关的各种原因和子原因如何产生潜在问题或影响，将影响质量问题的“人员、设备、参考资料、方法、环境”等各方面的原因进行细致的分解，方便地在质量计划中制定相应的预防措施。
- 图例
- 质量计划模板参照
- 项目概述
- 实施策略
- 项目组织
- 质量保证对象分析及选择
- 质量保证任务划分
- 实施计划
- 资源计划
- 记录的收集、维护与保存
- 质量体系
为实施质量管理所需的组织结构、程序、过程和资源。
- 质量体系与质量计划的区别
- 质量体系是企业长期遵循和需要重复实施的文件，具有较强的标准性质
- 质量计划是一次性实施的，项目结束，质量计划的有效性就结束。
- 软件项目团队计划
- 人力资源计划
- 人力资源计划基本概念
- 团队的定义
- 团队是一定数量的个体成员组织的集合
- 包括自己组织的人、供应商、分包商、客户等
- 为一个共同的目标工作，协调一致，愉快合作
- 最终开发出来高质量的产品
- 团队管理的特点
- 项目组织形式
- 组织结构特点
- 组织结构的主要类型
- 职能型
- 图示
- 职能型优点
- 可以充分发挥职能部门的资源集中优势
- 部门的专家可以同时为部门内不同项目使用
- 便于相互交流 , 相互支援
- 可以随时增派人员
- 可以将项目和本部门的职能工作融为一体
- 职能型缺点
- 项目和部门利益发生冲突，职能部门更重视本部门的目标,会忽视项目目标
- 资源平衡会出现问题
- 权利分割不利于各个职能部门的交流和团结协作
- 行政隶属关系使得项目经理没有充分的权利
- 项目型
- 图示
- 项目型优点
- 项目经理对项目可以负全责
- 项目目标单一，可以以项目为中心,有利于项目顺利进行
- 避免多重领导
- 组织结构简单，交流简单,快速
- 项目型缺点
- 资源不能共享
- 各个独立的项目处于相对封闭状态,不利于公司政策的贯彻
- 对项目组织的成员缺少一种事业上的连续性和安全感
- 项目组织之间处于分割状态,缺少信息交流
- 矩阵型
- 弱矩阵型图示
- 强矩阵型图示
- 矩阵型优点
- 专职的项目经理负责整个项目 , 以项目为中心,
- 公司的多个项目可以共享各个职能部门的资源
- 即利于项目目标的实现,又利于公司目标方针的贯彻
- 项目成员的顾虑减少了
- 矩阵型缺点
- 容易引起职能经理和项目经理权力的冲突
- 资源共享也能引起项目之间的冲突
- 项目成员有多头领导
- 人员管理计划
资源管理计划描述了项目团队的人员什么时候如何加入到团队中和离开团队。作为项目计划一部分，详细程度因项目而异。
- 选择合适的项目人员
- 项目经理
- 系统分析员
- 系统设计员
- 数据库管理员
- 支持工程师
- 程序员
- 质量保证工程师
- 业务专家（用户）
- 测试人员等等
- 项目沟通计划
- 沟通概念
- 项目沟通的过程
- 项目沟通的重要性
- 项目沟通的基本原则
- 沟通方式
- 项目沟通的方式
- 书面沟通和口头沟通
- 语言沟通和非语言沟通
- 正式沟通和非正式沟通
- 单向沟通和双向沟通
- 网络沟通
- 沟通渠道
- 沟通计划
- 项目沟通计划
- 沟通计划是确定谁需要信息，需要什么信息，何时需要信息，需要什么信息，何时需要，以及如何将信息分发给他们。
- 编制项目沟通计划
- 沟通需求分类
- 沟通内容
- 沟通方法
- 沟通职责
- 沟通进度
- 沟通计划维护
- 软件项目风险计划
- 风险基本概念
- 风险的定义
- 损失发生的不确定性；
- 对潜在的，未来可能发生损害的一种度量
- 项目风险的三要素
- 风险图示
- 风险类型
- 预测角度
- 已知风险——Known known
- 可预测风险 ——Known unknown
- 不可预测风险——unknown unknown
- 范围角度
- 风险的基本性质
- 风险的客观性
- 风险的不确定性
- 风险的不利性
- 风险的可变性
- 风险的相对性
- 风险同利益的对称性
- 风险管理的过程
- 风险管理的四个过程
- 图示
- 风险识别
风险识别是试图通过系统化地确定对项目计划的威胁，识别已知和可预测的风险。
- 图示
- 方法及工具
- 德尔菲方法
- 头脑风暴法
- 情景分析法
- 面谈法
- 风险条目检查表
- 检查表法是利用检查表作为风险识别的工具
- 检查表法是根据风险要素建立软件项目的风险条目列表
- 列表中列出所有与风险因素有关的提问
- 可以使管理者集中识别常见的类型中的已知和可预测的风险
- 有研究表明：IT项目常常存在一些共同的风险源
- 基于生存期的检查表
- 风险评估
确定风险发生概率的估计和评价，项目风险后果严重程度的估计和评价，项目风险影响范围的分析和评价，以及对于项目风险发生时间的估计和评价。
- 分析
- 风险发生的概率，确定发生的可能性（P）
- 风险后果，发生后对项目目标的影响（I）
- 风险值，风险的严重程度R=F(P,I)
- 确定优先次序
- 按风险的严重性排序
- 确定最需要关注的TOP 10风险
- 风险评估的方法
- 定性风险评估
定性评估风险概率及后果
- 风险概率
- 风险概率值
- 风险概率度量
- 高、中、低
- 极高、高、中、低、极低
- 不可能，不一定，可能和极可能
- 等等
- 风险后果（影响）
- 风险后果
- 风险后果度量
- 高、中、低
- 极高、高、中、低、极低
- 灾难，严重，轻微，可忽略
- 等等
- 风险概率及后果估计-矩阵图
- 定量风险评估
- 盈亏平衡分析
盈亏平衡分析是通过盈亏平衡点（BEP）分析项目成本与收益的平衡关系的一种方法。各种不确定因素（如投资、成本、销售量、产品价格、项目寿命期等）的变化会影响投资方案的经济效果，当这些因素的变化达到某一临界值时，就会影响方案的取舍。
- 盈亏平衡分析的目的
- 盈亏平衡分析的目的就是找出这种临界值，即盈亏平衡点(BEP)，判断投资方案对不确定因素变化的承受能力，为决策提供依据。
- 盈亏平衡点越低，说明项目盈利的可能性越大，亏损的可能性越小，因而项目有较大的抗经营风险能力。因为盈亏平衡分析是分析产量(销量)、成本与利润的关系，所以称量本利分析。 盈亏平衡点的表达形式有多种。它可以用实物产量、单位产品售价、单位产品可变成本以及年固定成本总量表示，也可以用生产能力利用率(盈亏平衡点率)等相对量表示。
- 模拟
- 蒙特卡洛模拟法又称统计试验法或随机模拟法，其原理是将项目目标变量（风险评价指标）和各个风险变量综合在一个数学模拟模型内，每个风险变量用一个概率分布来描述，然后利用计算机产生随机数（或伪随机数），并根据随机数在各个风险变量的概率分布中取值，算出目标变量值，经由量次运算即可得出目标变量的期望值、方差、概率分布等指标，绘造累计概率图，供决策者参考。
- 访谈
- 确定概率分布模型
- 领域专家访谈，信息采集
- 访谈技术用于量化对项目目标造成影响的风险的概率和后果。访谈可以邀请以前与本项目相类似的专家,这些专家运用它们的经验做出风险度量,其结果相当准确可靠,甚至有时比通过数学计算机与模拟分析的结果还要准确和可靠。
- 决策树分析
- 决策树分析是一种图表分析方法
- 提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率
- 提供选择一个最佳的方案的依据
- 决策树分析例子
- 试验一结果
- 实验二结果
- 课堂练习
- 利用决策树风险分析技术来分析如下两种情况的，以便决定你会选择哪种方案：（要求画出决策树）
- 方案１：随机投掷硬币两次，如果两次投掷的结果都是硬币正面朝上，你将获得１０元；投掷的结果背面每朝上一次你需要付出１.５元。
- 方案２：随机投掷硬币两次，你需要付出２元；如果两次投掷的结果都是硬币正面朝上，你将获得１０元。
- 课堂练习答案
- 量化风险条目检查表
- 风险规划
针对风险分析的结果，为提高实现项目目标的机会，降低风险的负面影响而制定风险应对策略和应对措施的过程，即制定一定的行动和策略来对付、减少、以至于消灭风险事件
- 风险规划的主要策略
- 回避风险
- 回避风险是对所有可能发生的风险尽可能的规避，采取主动放弃或者拒绝使用导致风险的方案
- 例如放弃采用新技术
- 注意事项
- 对风险有足够的认识
- 当其他风险策略不理想的时候，可以考虑
- 可能产生另外的风险
- 不是所有的情况都适用的
- 转移风险
- 转移风险是为了避免承担风险损失
- 有意识将损失或与损失有关的财务后果转嫁出去的方法
- 例如
- 损失控制
- 自留风险
- 由项目组织自己承担风险事故所致损失的措施。
- 自留风险的类型
- 主动自留风险和被动自留风险
- 全部自留风险和部分自留风险
- 实例
- 人员的频繁流动是一项风险，基于过去的历史和管理经验，频繁流动可能性的估计值为70%，开发时间增加15%，总成本增加12%，为了缓解这一风险，项目经理是采取的策略：
- 实例-采取的策略
- 与现有人员讨论人员流动的原因
- 项目启动时，做好会出现人员流动的准备，采取一些技术以确保人员的一旦离开后，项目仍然能继续
- 建立良好的项目组织和通信渠道，以使大家能够了解每个有关的开发活动的信息
- 指定文档标准并建立相应的机制，以保证文档能够及时建立
- 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作
- 风险控制
- 风险管理计划
- 风险应对计划（top 10清单）
- 岗位职责
- 时间
- 预算
- 追踪等等
- 软件项目合同计划
- 项目合同
- 项目采购
- 为了执行项目而从项目团队外部采购或者获取产品、服务或者结果的过程，称为采购
- 合同
- 具有法律效率的协议
- 双方自愿达成的协议：Offer,Acceptance
- 签订者具有相应的法律能力
- 有充分的签约理由
- 具有合法的目的
- 合同类型
- 成本补偿合同
- 成本加成本百分比
CPPC:Cost Plus percentage of cost
- 实例
- 预计成本=10万，%=15
- 如果实际成本增至20万
- 成本加固定费用
CPFF:Cost Plus Fixed Fee
- 实例
- 预计成本=10万，%=15
- 如果实际成本增至20万
- 成本加奖金
CPIF: Cost Plus Incentive Fee
- 实例
- 预计成本=10万，利润1万，奖励分配80/20
- 如果按照预计成本完成，则总价=11万
- 如果实际成本降至8万，则总价=8+1+2*20%=9.4万
- 固定价格合同
- 固定价格加奖励费
FPI:Fixed Price Plus Incentive Fee
- 目标价格：100万
- 最高价格：110万
- 卖方利润：10万
- 分享比例：70/30
- 例一：实际成本80万，则总价=80+10+20*30%=96万
- 例二：实际成本150万，则总价110万
- 固定总价
FFP:Firm Fixed Price
- 目标价格：100万
- 例一：实际成本80万，则总价=100万
- 例一：实际成本150万，则总价100万
- 单价合同
- 一个产品或者时间度量单位的价格 :
- 工程师单价:130美元/工时
- 产品单价:1000元/模块
- 合同类型与相应的风险
- 合同计划
- 合同计划
- 明确如何进行委托、委托什么项目、何时进行、费用如何等，其中，“资金”常常是一个约束条件。
- 选择需要的合同类型，同时，应该考虑市场条件，其他计划工作成果，例如供应商、承包商的情况，成本、工期、质量、人员等情况，采用的招标方式、合同形式等。
- 输出
- 软件外包
- 软件外包
- 软件项目外包其实质是软件开发过程从公司内部部分或全部延伸到公司外部的管理规范与管理技术。
- 软件外包基本步骤
- IBM软件外包的一些策略
- 软件配置管理计划
- 软件项目配置管理基本概念
- 配置管理
- 配置管理简述
- 记录软件产品的演化过程
- 确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置。
- 最终保证软件产品的完整性、一致性、追朔性、可控性
- 配置管理的作用
- 配置管理的主要功能
- 配置项
SCI :software configration item
- 软件配置项是项目需定义其受控于软件配置管理的款项。每个项目的配置项也许会不同。
- 软件配置项举例
- 系统规格说明书
- 软件需求规格说明书
- 设计规格说明书
- 源代码
- 测试规格说明书
- 配置项的版本
- 基线
- 基线定义
- 基线提供了软件生存期中各个开发阶段的一个特定点，
- 一个(些)配置项形成并通过审核，即形成基线
- 基线标志开发过程一个阶段的结束和里程碑
- 基线修改需要按照正式的程序执行
- 软件开发各个阶段基线图示
- SCCB
配置控制委员会(SCCB)：Software Configuration Control Board)
- 评估变更
- 批准变更申请
- 在生存期内规范变更申请流程
- 对变更进行反馈
- 与项目管理层沟通
- 配置管理过程
- 基本活动
- 配置管理的基本过程
- 配置项标识、跟踪
- 将软件项目中需要进行控制的部分拆分成SCI
- 配置项的拆分例子
- （某医疗网站）需求规格SCI
- 辅助功能.doc
- 性能.doc
- 产品目录.doc
- 医务管理.doc
- 医疗专业区.doc
- 首页.doc
- 建立唯一的标识
- 建立相互间的对应关系，进行系统的跟踪和版本控制，以确保项目过程中的产品与需求和规格的要求相一致，
- 配置项的标识
配置项被唯一的标识
- 配置项的跟踪
- 配置管理环境建立
- 软件配置管理库是用来存储所有基线配置项及相关文件的等内容的系统，是在软件产品的整个生存期中建立和维护软件产品完整性的主要手段。
- 基线变更管理
- 基线修改应受到控制，这种变化要经SCCB授权，按程序进行控制并记录基线修改的过程。
- 基线审核
- 配置状态统计
- 配置管理计划
- 配置管理计划过程
- 配置管理计划大纲
- 基线定义
- 版本控制
- 定义变更控制过程
- 变更委员会的管理
- 变更控制纪录
- 配置管理计划模板
- 引言
- 软件配置管理
- 软件配置管理组织
- 软件配置管理责任
- 与软件过程生命周期的关系
- 软件配置管理活动
- 软件配置管理活动
- 支持
- 配置管理计划工具
- 工具应具有的功能
- 版本管理
- 变更管理
- 问题追踪
- 建立管理
- 状态统计（查询和报告）
- 配置审核
- 访问控制和安全控制
- 常用配置管理的工具
- ClearCase&ClearQuest
- PVCS
- Harvest
- CVS
- VSS
- 配置管理建议
- 制定规则：实现版本管理
- 小企业，小项目
- 制定规则和（版本管理）工具：实现部分配置管理
- 中小企业，中小项目
- 制定规则和（配置管理）工具：实现配置管理-
- 大企业，大项目
- 异地开发模式
- 配备专门的配置管理人员
- 软件集成管理计划
- 项目集成管理
- 软件项目管理的最重要的四个要素
- 四要素的关系
- C=F(S,Q,T)
- S 与 C成一定正比关系
- Q 与 C成一定的正比关系
- T与C成一定的反比关系
- 基准计划
- 第三篇 项目执行控制
- 项目集成管理
- 项目执行控制过程
- 项目执行控制
- 项目控制的步骤
- 建立标准
- 采集项目信息,观察项目的性能
- 将项目的实际结果与计划进行比较
- 如果实际的项目同计划有误差时，采取必要的修正措施。
- 修正计划,通知有关人员和部门
- 整理不全，具体请看12.ppt 8-22
- 范围管理
- 项目范围控制
- 范围变更控制系统
- 范围控制注意点
- 防治不合理的范围扩张
- 蔓延（Scope Creeping）
- 镀金（Gold-plating）
- 时间\成本管理
- 跟踪项目进度
- 跟踪项目进度重要的是及时更新项目信息，这样及时反映项目的比较基准计划与实际运行状况的差异，以便于及时调整项目，达到项目跟踪的目的。
- 进度控制的建议
- 进度有张有弛，不做过分要求
- 注意关键路径，尤其存在多条关键路径的时候
- 确保检查点的定义是明确的
- 跟踪实际成本
- 计算任务的实际成本
- 每天更新实际成本
- 查看任务成本是否与预算相符
- 跟踪项目资源状况
- 资源完成的总实际工时
- 每天更新资源的实际工时
- 查看资源计划工时与实际工时之间的差异
- 性能分析的主要技术
- 图解控制法
用甘特图、累计费用曲线图和资源载荷图共同监控项目
- 进度---甘特图
- 成本—累计费用曲线图
- 累计费用（S）曲线是项目累计成本图，将项目各个阶段的费用进行累计，就得到了平滑的、递增的计划成本和实际成本的曲线
- 图示
- 人力物力资源—资源载荷图
- 图解控制法－图例1
- 图解控制法－图例2
- 挣值分析法（盈余分析法、已获取价值分析法）
Earned Value Analysis
- 挣值分析法原理
- 挣值分析法定义
- 对项目实施的进度、成本状态进行绩效评估的有效方法 -- 综合了范围、成本、进度的测量
- 是计算实际花在一个项目上的工作量，以及预计该项目所需成本和完成该项目的日期的一种方法
- 挣值分析模型
- 挣值分析输入
- BCWS
Budgeted cost of work scheduled
- ACWP
Actual cost of work performed
- BAC
Budget At Completion
- BCWP
Budgeted cost of work performed
- BCWP的计算
- 已获价值分析的难点是计算BCWP.
- 方法一：自下而上-很麻烦
- 方法二：公式计算方法
- 50/50规则
当一项工作开始时，假定已经获得一半的价值。
- 本规则可以克服对工作的进展情况主观的估计问题，以及自下而上详细估算工作量太大的缺点
- 最常用的规则
- 前提是任务分解的足够详细
- 例如：软件工作包《1周
- 0/100规则
当一项工作开始时，没有产生价值，直到结束获得全部的价值。
- 挣值（已获取价值）实例
- 经验加权法
- 挣值分析导出度量 - 1
- 进度差异:SV
Schedule Variance
- SV = BCWP - BCWS
- =0：按照进度进行
- <0：落后于进度
- >0：超前于进度
- 成本差异实例
- 进度差异实例
- 费用差异:CV
Cost Variance
- CV = BCWP - ACWP
- =0：按照预算进行
- >0：低于于预算
- <0：超出于预算
- 举例
- 项目原来预计2009.6.14完成1000元的工作，但是目前只完成了850元的工作，而为了这些工作花费了900元，则成本偏差和进度偏差各是多少？
- 挣值分析导出度量- 2
- 成本效能指数：CPI
Cost Performance Index
- CPI = BCWP / ACWP
- 费用的支出速度
- =1：按照预算进行
- >1：低于预算
- <1：超出预算
- 进度效能指标： SPI
Schedule Performance Index
- SPI = BCWP / BCWS
- 已完成工作百分比
- =1：按照进度进行
- >1：超前于进度
- <1：落后于进度
- 挣值分析导出度量- 3
- 工作完成的预测成本：EAC
Estimate At Completion
- EAC = BAC / CPI
- 其它借鉴公式
- EAC = BAC / ( CPI * SPI )
- EAC = ACWP + ( BAC - BCWP )
- EAC = ACWP + 剩余工作的新估计
- 工作完成的成本差异：VAC
Variance At Completion
- 项目完成的预测时间：SAC
Schedule At Completion
- 性能分析实例
- 项目性能分析实例研究
- 图示
- BCWS=96300
- BCWP=78650
- ACWP= 87100
- SV=-17650
- CV=-8450
- SPI= BCWP/ BCWS=81.7%
- CPI= BCWP/ ACWS=90.3%
- BAC=115000
- EAC=BAC/ CPI=127350
- 课堂练习题
- 例题
- 质量管理
- 图示
- 输入
- 方法
- 质量审计
审计(Audit) 是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较
- 目的是确保真正的遵循了这一个过程，产生了合适的文档和精确反映实际项目的报告
- 可以预先规划的，也可以是临时决定的。
- 项目执行过程审计
- 对项目的执行过程进行检查，确保所有活动遵循规程进行。
- 项目产品审计
- 对项目过程中的工作产品进行质量审查的过程
- 记录不符合项
- 编写产品审计报告
- 技术评审
- 目的是尽早发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。
- 技术评审例子
- 1、召开评审会议：一般应有3至5相关领域人员参加，会前每个参加者做好准备，评审会每次一般不超过2小时；
- 2、在评审会上，由开发小组对提交的评审对象进行讲解；
- 3、评审组可以对开发小组进行提问;提出建议和要求;也可以与开发小组展开讨论；
- 4、会议结束时必须做出以下决策之一：
- 接受该产品，不需做修改；
- 由于错误严重，拒绝接受；
- 暂时接受该产品,但需要对某一部分进行修改。开发小组还要将修改后的结果反馈至评审组。
- 5、评审报告与记录；所提出的问题都要进行记录，在评审会结束前产生一个评审问题表，另外必须完成评审报告。
- 代码评审/走查
- 代码评审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。
- 代码走查是在代码编写阶段，开发人员自己检查自己的代码
- 软件测试
- 测试是程序的执行过程，目的在于发现错误
- 一个好的测试用例在于能发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误的测试
- 返工
- 返工是将有缺陷的和不合格项改造为与需求和规格一致的行为
- 控制图
- 控制图法是一种图形的控制方法，它显示软件产品的质量随着时间变化的情况，在控制图法中标识出质量控制的偏差标准。
- 图示
- 趋势分析
- 趋势分析指运用数字技巧，依据过去的成果预测将来的产品。
- 图示
- 抽样统计
- 抽样统计是根据一定的分布概率抽取部分产品进行检查。它是以小批量的抽样为基准进行检验，以确定大量或批量产品质量的最常使用的方法。
- 输出
- 团队管理
- 人员选择
- 确定需要的人员类型
- 明确项目需要的人员技能
- 验证需要的技能
- 人员培训
- 人员激励
- 项目成员的激励的理论
- 马斯洛的需求层次理论
- 海兹伯格的激励理论
- 麦克勒格的 X－理论 和 Y －理论
- X－理论
- 不喜欢他们的工作并努力逃避工作
- 缺乏进取心，没有解决问题与创造的能力
- 喜欢经常被指导，避免承担责任，缺乏主动性
- 自我中心，对组织需求反应淡漠，反对变革
- 用马斯洛的底层需求（生理和安全）进行激励
- Y －理论
- 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
- 具有创造力，想象力，雄心和信心来实现组织目标
- 能够自我约束，自我导向与控制，渴望承担责任
- 用马斯洛的高层需求（自尊和自我实现）进行激励
- 超Ｙ理论
- 人们,各自有不同的情况:处理方法不同
- 组织形式和管理方法要与工作性质和人们的需要相适应,
- 组织机构和管理层次的划分、职工培训和工作分配、工作报酬和控制程度等, 不能千篇一律;
- 当一个目标达到后,应激起员工的胜任感,使他们为达到新的、更高的目标而努力。
- Ｚ理论
- 企业对员工实行长期或终身雇佣制度
- 注意员工培训
- 注意对人的经验和潜在能力进行诱导
- 企业决策采取集体研究和个人负责的方式
- 让职工多参与管理
- 期望理论
- 人们在下列情况下能够受到激励并且出大量成果
- 相信他们的努力很可能会产生成功的结果
- 他们也相信自己会因为成功得到相应的回报
- 团队建设
- 团队建设的基本方法
- 创建有确实存在感的项目队伍
- 建立奖励机制
- 建立良好人际关系
- 沟通管理
- 项目沟通的基本原则
- 项目沟通的方式
- 书面沟通和口头沟通
- 语言沟通和非语言沟通
- 正式沟通和非正式沟通
- 单向沟通和双向沟通
- 网络沟通
- 冲突解决
- 解决问题（Confrontation or problem-solving）
- 妥协（Compromise）
- 强迫方式（Forcing mode）
- 撤退(Withdrawal)
- 项目评审
项目评审是对项目的评价和审核的过程是项目执行控制的重要手段
- 评审内容
- 进度计划
- 质量计划
- 成本计划
- 风险计划
- 沟通计划
- 人力资源计划
- ….等等
- 项目评审
- 准备过程
- 评审目的
- 评审内容
- 文档或产品的名称
- 评审方式
- 评审依据的规范和标准
- 评审议程
- 评审负责人
- 评审进入条件和完成标志
- 评审参加人员的姓名、角色和责任
- 评审地点
- 评审时间安排
- 评审争议的解决方式
- 评审报告分发对象（包括人员、角色和职责）
- 评审类型
- 活动类别
- 商务评审
- 技术评审
- 管理评审
- 质量评审
- 产品评审等等
- 时间类别
- 评审过程
- 评审报告
- 评审结束后需要将评审的结果，以评审报告的形式进行发布
- 图示
- 评审报告的格式参考
- 风险管理
- 风险管理是一个连续的过程
- 风险管理是循环的过程
- 风险控制
- 实施和跟踪风险管理计划
- 确保针对风险策略正在合理使用
- 监视剩余的风险和识别新的风险
- 收集可用于将来的风险分析信息
- 图示
- 风险控制方法
- 建立项目风险监控体系
- 项目风险审核-Top 10风险列表控制
- Top 10风险列表控制是最有效的风险控制工具之一
- 定期(每周)审核Top 10风险列表
- Top 10风险列表样例
- 挣值分析
分析进度、成本等的风险
- 项目风险评价 -例如项目中期检查
- 合同管理
- 合同的生存期
- 甲方合同管理
- 乙方合同管理
- 合同执行跟踪管理过程
- 合同修改控制
- 违约事件处理过程
- 产品提交过程
- 产品维护过程
- 第四篇 项目结束
- 项目结束过程
- 合同结束
- 甲方合同结束-验收过程
- 甲方合同结束-合同终止过程
- 乙方合同结束
- 在合同终止过程中，乙方(供方)应该配合需方的工作，包括项目的验收、双方认可签字、总结项目的经验教训、获取合同的最后款项、开具相应的发票、获取需方的合同终止的通知、将合同相关文件归档的过程
- 项目结束
- 成功与失败的标准
- 可交付成果如何
- 是否实现目标
- 是否达到项目业主的期望
- 结束过程
- 制定执行结束计划
- 结束计划
- 项目计划的一部分
- 与客户一同评审项目结束计划
- 细化并实施项目结束计划
- 完成收尾工作
- 项目最后评审
- 是否实现项目目标
- 是否遵循项目进度
- 是否在预算成本内完成项目
- 项目进度过程中出现的突发问题以及解决措施是否合适，问题是否得到解决
- 对特殊成绩的讨论和认识
- 回顾客户和上层经理人员的评论
- 从该项目的实践中可以得到哪些经验和教训
- 项目总结
- 项目总结是一个把实际运行情况与项目计划不断比较以提炼经验教训的过程。
- 通过项目质量计划和总结，项目过程中的经验和教训将得到完整的记录和升华，成为“组织财富”
- 总结成功的经验和失败的教训
- 总结软件项目历程文件
- 项目管理过程总结
- 软件开发项目管理关系图
- NASA SEL提出的成功项目九件事
- 建立并遵循一套软件开发规划
- 授权项目人员
- 简化官僚体系
- 定义需求底线,管理需求变更
- 采取阶段性评估项目并及时修正项目规划
- 定期重新评估系统规模和进度
- 确定并管理阶段变化
- 培养团队精神
- 以少数资深人员开始进行项目
- NASA SEL提出的成功项目不应做的八件事
- 不要让团队成员以非系统化的方式工作
- 不要确定不合理的目标
- 不要做没有认可的变更
- 不要花哨的功能
- 不要人浮于事，特别是项目初期
- 不要假设阶段中期的时间延误可以在后头弥补过来
- 不要降低标准成本或缩短时间
- 不要假设有大量文件说明就保证成功
posted @
2019-12-13 11:00
Zander_Zhao
阅读(
2343)
评论()
编辑
收藏
举报
