软件项目策划与管理知识点汇总
categories: [计算机通识,软件项目策划与管理]
thumbnail: /images/fe/rjxmchhgl.jpg
toc: true
软件项目策划与管知识点汇总
第一章：序言
关于软件
软件的特征
- 软件是一种逻辑元素而不是物理元素
- 软件是开发出来的而不是用传统的方法制造出来的
- 软件不会被用坏
软件的分类： - 系统软件（操作系统）
- 实时软件（高炉控制软件）
- 商务软件
- 工程与科学计算软件
- 嵌入式软件（安卓）
- 个人计算机软件
- web软件
- 人工智能软件
- 。。。
软件危机：指在计算机软件的开发和维护过程中所遇到的一系列严重问题
软件危机的表现
- 成本高
- 软件质量得不到保证
- 进度难以控制
- 维护非常困难
产生软件危机的原因以及如何解决软件危机
- 逻辑产品不同于物理产品，
- 复杂性高
- 规模大
- 影响软件生产率和质量的因素比较复杂：人员的能力与水平、团队合作
- 缺乏有效、系统原理、原则、方法和工具的指导和辅助
解决：既要有技术措施（方法和工具）支持软件开发，又要有必要的组织管理措施
什么是项目（重点）
为创造某种独特产品或服务所做的一次性有计划的活动。
项目的要素与特征（重点）
一个项目无论大小、特点如何，一般包括下列要素：
(1)具体的结果（产品或结果）。
(2)明确的开始与结束日期（项目工作开始日期和它的结束日期）。
(3)既定的预算（包括人员、资金、设备、设施和资料总额等）。
项目的基本特征表现在：
- 它有一个明确的目标。每一个项目都是一个特定的项目产品，是为一个明确的目标而成立的。
- 由一系列互相关联的任务构成。
- 所有的项目都具有有限的资源。比如时间、人力和成本等。
- 项目是具有一次性、独特性的活动。它有明确的开始和结束时间，具有临时性
项目的5个阶段（重点）
- 启动
- 计划
- 控制
- 执行
- 结束
什么是项目管理（重点）
项目管理是在项目活动中应用知识、技能、工具和技术来满足项目需求的过程，它通过初始化，计划，执行，控制和结束等活动来完成。
PMI对项目管理的定义：项目管理就是为了满足甚至超越项目干系人对项目的需求和期望，将理论知识、技能、工具和技巧应用到项目的活动中去，以满足或超过项目干系人的需求和期望。
项目管理是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内完成项目的各项工作。
软件项目生命周期（重点）
- 开始阶段
- 中间阶段
- 最后阶段
软件项目的特征
- 不可见
- 灵活
- 复杂性
软件项目常见问题
产品相关的问题：
- 需求镀金：项目具有比实际需求多得多的性能
- 功能蔓延：项目平均会有25％的需求变更
- 开发人员的镀金：开发人员着迷于新技术
- 又拉又推的交易：经理在批准项目顺延时又加入了新的功能
- 研究导向的开发
过程相关的问题
- 缺乏计划
- 过于乐观的计划
- 在压力下放弃计划
- 缺乏足够的风险管理
- 承包人导致的失败
- 在模糊的项目前期，浪费时间
- 前期活动不符合要求
- 设计低劣
- 缺少质量保证措施
- 缺少管理控制
- 太早和过于频繁的集成
- 项目估算时遗漏必要的任务
- 追赶计划
- 鲁莽编码
技术相关的问题
- 银弹综合征：过于相信以前没有采用的技术
- 过高估计新技术和方法带来的节省量
- 项目中间时切换工具
- 缺少自动的源代码控制手段
人员相关的问题
- 挫伤积极性
- 人员素质低
- 对有问题的员工失控
- 英雄主义
- 项目开发后期加入人员：火上加油
- 办公环境差
- 开发人员与客户之间发生摩擦
- 不现实的预期
- 缺乏有效的上层支持
- 缺乏各种角色的互相协作
- 缺乏用户的介入
- 政治高于物质
- 充满想象
第二章 软件项目计划总揽
项目计划的作用
- 指导计划的实施
- 记载项目计划的前提假设
- 记载根据选择的方案作出的决策
- 促进项目人员之间的沟通
- 确定项目管理的内容、范围和时间
- 作为度量（实际执行效果与计划作比较）和控制项目进程的基准
项目计划的内容
- 什么：工作的具体内容，一定时期内的工作重点
- 怎样：如何完成这些工作和任务
- 谁：确定具体人员和部门
- 何时：各项工作需要多少时间
- 多少：各项工作需要多少费用
- 哪里：各项工作进行的环境
项目计划的特性
动态性要求：项目计划要有弹性
职能性：从总体出发，涉及各相关部门
相关性：子计划的相互影响
系统性：子计划的合理性
目标性：目标是灵魂
经济性：技术经济分析
软件项目计划的步骤
使用的是步进式模型：
- 选择项目
- 确定项目的范围和目的
- 确定项目结构
- 分析项目特征
- 确定项目产品与活动
- 估计每个活动的工作量
- 确定活动的风险
- 分配资源
- 检查和公布计划
- 执行计划
- 更细层次上的计划
1. 选择项目（可行性分析）
一般需要回答下列问题：
2. 确定项目的范围和目的
- 确定目标和这些目标的衡量方法
- 选择项目的责任人（负责人）
- 确定项目的所有干系人（技术人员，甲方，政府部门等等和项目有关系的人）和兴趣（关注点）
- 根据项目的干系人的要求分析修改目标
- 建立各方沟通渠道
3. 确定项目的结构
- 建立项目和策略计划
- 建立标准和过程
- 建立项目团队组织
4.分析项目特征
- 分析项目是目标驱动还是产品驱动
- 分析项目的其他特征（针对的行业）
- 确定项目的高层次的风险（主要风险）
- 考虑用户实现方面的需求
- 选择通用的生命周期方法
- 检查估计资源
5. 确定项目的产品与活动
-
确定产品的类型：技术产品（如代码）、管理产品（计划说明书）
-
确定产品的层次性：产品由一些子产品构成，子产品由一些更小的子产品构成
-
画出产品的分解结构：PBS
一个通用的产品模型：
-
写出一般性的生产流程：产品流程图（PFD）
-
确定产品实例
-
定义理想的活动网络：从一个产品产生另一个产品，需要一个或多个活动完成转换。为了确定这些活动，需要一个活动网，以标识活动执行的顺序。
这是一个活动网络图（CPN）
（图中每一个活动有一个持续时间，可以根据这个图找出一个关键活动，就是耗时最长的活动路径） -
考虑阶段和检查点，修改理想的活动网络
在实际项目中，一般将项目分解为阶段，并设置检查点。检查点，即里程碑
6. 估计活动的工作量
- 自底向上的估计
- 对计划进行修改以生成可控的活动
7.确定活动的风险
- 识别和量化风险
- 制定风险降低方法和紧急处理手段（关键人员生病，使用兼职人员）
- 在考虑风险的基础上调整计划和估计（计划中加入培训活动，或悲观估计）
8. 分配资源
- 确定和分配资源
- 在考虑资源约束条件下，修改计划（某些人员承担多个任务，就要考虑任务的优先级）
9. 检查和公布计划
- 检查项目计划的质量（活动需小组质量检查，前面活动因质量问题需重做）
- 计划书面化和上报批准
10. 执行计划
11. 更细层次上的计划
产品分解结构的描述
- 产品的名称及标识
- 产品的功能
- 产品的来源
- 产品的派生物
- 产品的形式（用文档或图形表示）
- 产品的分解结构
- 相关的标准（如文档的模板）
- 适用的质量标准（如文档的评价标准）
软件项目的经济性评价（重点）
如何估计经济型
- 自底向上
将任务分解为片段
估计每一个片段
将片段加起来
- 自顶向下
从管理者对成本的额度期望出发
确定在成本约束条件下能够交付的产品
提供管理者多种选择
成本
- 开发成本
- 安装成本
- 运行成本
可能的IT成本
- 采购成本
- 启动成本
- 与项目有关的成本
- 运行成本
项目经济型评估
- 净收益：项目生命周期内，总收入与总成本的差额
2. 投资回收期：投资项目所需要的时间（简单来说就是回本的时间）
- 回收时间越长，项目的风险越大，或者说项目收益不那么具有吸引力。
- 如果项目的收益比较大，收益就远远大于支出，它就可以在较短时间内回收项目投资，短的回收期通常意味着项目具有更好的收益，所以也可以通过项目的回收期来判断一个项目是否可行。
投资回收期短的不一定净收益高
- 投资回报率或收益率（ROI）
平均年收益 = 净收益 / 年份
- 净现值NPV
一个投资项目的净现值等于一个项目整个生命周期内（时间）预期未来每年净现金流的现值之和减去项目初始投资支出(本金)
判断一个项目是否可行，就要看它的净现值是不是大于零，净现值大于零，意味着项目能够取得收益，它的净收益是正的，也就是说项目的净收益大于净支出，这个项目应该入选，反之不然。
NPV计算公式：
- NPV：净现值度i－贴现率
- NCFt：第t年的营业现金净流量
- n：项目寿命周期
- i ：预期收益率
举个例子：
B公司正考虑一项新的软件开发投资项目，该项目初始投资为40000元，每年的税后现金流如下所示。假设该公司要求的收益率为13%。
所得净现值为负数，证明此方案不可行。
但是NPV也存在问题，当收益率不同时，NPV结果也会随着被影响
5. 内部收益率（IRR）
内部收益率就是当NPV为0时的收益率的值，就是上面那个公式知道NPV为0，反推i的值
所以可以很容易得出结论，从项目的角度来说：内部收益率越高越好，但是从公司的角度出发，内部收益率越低越好
可以用内部收益率是否大于期望的标准收益率或者基本收益率（行业投资平均收益率）来判断这个项目是否能够入选。
总结：净现值、内部收益率和回收期，这三个指标通常是用来决定一个项目取舍的主要经济效益指标
第三章 招投标活动
招标的工作内容和步骤（重点）
- 成立招标工作小组；
- 编制招标文件;
- 发布招标公告；
- 进行投标单位资格审查；
- 组织现场踏勘和招标答疑；
- 接受投标文件；
- 组织评标
- 确定中标单位；
- 发出中标通知书
- 签订承发包合同
评标过程（重点）
- 专家库抽取各方面的的专家
- 专家人数：5，7，9…，甲方人数1/3以下
- 确定地点（保密）
- 监督部门到场
- 专家评标（根据一定的标准）
- 专家写出评价意见，推荐中标人
- 由业主或招标代理写出评价报告
- 评标方法：主要有打分法和合理低价中标法
第四章 需求工程
需求工程的定义与内容（重点）
- 把所有与需求直接相关的活动通称为需求工程。
- 需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。
- 需求工程的结构图：
需求开发
通过调查与分析，获取用户需求并定义产品需求。
- 需求调查：通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
- 需求分析：对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
- 需求定义：根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作
需求管理
在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更
- 需求确认：开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果
- 需求跟踪：通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
- 需求变更：依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
需求开发主要困难（重点）
- 知识技能问题
- 态度问题
- 合作关系（需求分析员与用户，开发方与用户）
- 用户说不清楚需求
- 双方误解需求
- 开发人员写不好需求文档
- 用户经常变更需求
如何开展需求调查
准备调查
- 首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。
- 其次，需求分析员应当确定需求调查的方式
与用户交谈，向用户提问题。向用户群体发调查问卷。
参观用户的工作流程，观察用户的操作。
与同行、专家交谈，听取他们的意见。
分析已经存在的同类软件产品，提取需求。
从行业标准、规则中提取需求。 从Internet上搜查相关资料。
- 最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户
执行调查
- 准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息 。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系
-
前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
-
后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。
-
两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
撰写《用户需求说明书》
如何开展需求分析
需求分析的概念：在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图
- 问答分析方法
- 建模分析法
- 做出决策
如何定义产品需求
- 细化并分析用户需求
- 撰写产品需求规格说明书
- 进行需求确认
需求管理（确认、跟踪、变更控制）
需求确认
需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作**：“需求评审”和“需求承诺”**。
需求评审面临的困难（重点）
- 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。
- 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易
- 开评审会议时经常会“跑题”，导致评审效率很低
- 评审会议时经常会发生争议，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情
- 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”
需求跟踪
- 需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。
- 需求跟踪有两种方式：
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。 - 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
需求变更控制
需求发生变更的起因主要有：
- 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
- 市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。
第五章 软件开发过程
软件开发过程的概念和组成
过程的概念：针对一个给定目的地一系列操作步骤
软件开发过程的概念**：按照项目的进度、成本和质量限制，开发和维护满足用户需求的软件所必需的一组有序的软件开发活动集合**
软件开发过程的组成：
- 软件开发活动
- 软件开发活动之间的关系
为什么需要软件开发过程
- 明确了软件开发的过程和步骤，促进工程化软件开发
- 便于制定软件项目计划
- 为软件开发提供了可视性，便于对软件开发过程进行管理和控制
- 便于细化和安排任务，使得每个人员明确各自的工作
软件开发活动的概念及类型，活动之间关系及活动描述（重点）
概念：为开发软件项目而执行的一项具有明确任务的具体工作
类型：
- 技术活动
对软件项目实施开发，产生软件产品
例如，需求分析，概要设计，编码，单元测试等等 - 管理活动
对软件项目中的人、产品和过程等实施管理的活动
例如，制订软件项目计划，软件配置等等
软件开发活动间的关系：软件开发活动之间的次序反映了活动之间的依赖关系
- 逻辑
一个软件开发活动输出是另一个软件开发活动的输入
例如，需求分析和软件设计之间 - 时间
一个软件开发活动需等到另一个软件开发活动完成之后才能执行
如何定义软件开发活动及常见的软件开发活动（重点）
- 名称
- 任务
- 输入: 开始所必需满足的条件
- 输出: 完成时所必须满足的条件以及结果
- 实施: 做什么，怎么做(详细的步骤)，或者如何从输入产生输出
例子：
常见的软件开发活动：
技术活动
- 需求分析
- 概要设计
- 详细设计
- 编码
- 集成测试
- 撰写出版物
- 用户确认测试
- 软件发布
管理活动
- 制定初步软件开发计划
- 制定详细软件开发计划
- 制定软件配置管理计划
- 制定软件质量保证计划
- 项目跟踪和监督
- 配置管理
- 用户培训
软件开发过程模型（重点）
什么是软件开发过程模型：
- 软件开发模型是软件开发全过程、软件开发活动以及它们之间关系的的结构框架
- 指导软件开发，以及软件开发过程的定义
常用的软件开发过程模型（重点）：
- 瀑布模型
- 原型模型
- 增量模型
- 迭代模型
- 螺旋模型
过程模型选择的影响因素
技术选择将影响
- 开发人员的训练要求
- 人员招聘
- 开发环境－硬件和软件
- 系统维护安排
分析项目的特征
- 目标驱动还是产品驱动
- 面向数据还面向控制
- 通用的还是专用的
- 是否涉及需要专用工具支持的专门技术
- 是否需要特殊的安全性要求
- 对软硬件有何要求
影响因素：
- 识别项目中的高风险
- 产品的不确定性。
系统需求理解的准确性，用户开始时有可能对系统该是什么样都无法确定。在某些环境中，精确而有效的需求描述可能迅速变得过时 - 过程的不确定性。
在项目开始时要选择项目方法或过程模型或新的工具，任何对原先采用的开发方法的变换都将引进不确定性。 - 资源的不确定性。
项目过程中资源可能发生变化
瀑布模型（重点）
特点：
- 所有过程模型的鼻祖
- 强调阶段的划分及其顺序性
- 强调各阶段工作及其文档的完备性
- 每个阶段结束之前，从技术和管理两个角度进行严格的审查
- 是一种严格线性的、按阶段顺序的、逐步细化的开发模式
适合场景：
- 所有功能、性能等要求能一次理解和描述时；一个定义很好的系统进行维护或移植到新平台上时
- 所有的系统功能一次交付时；必须同时淘汰全部老系统时
- 容易理解但很复杂的项目；特别关注质量，对时间，成本不太关注的项目
- 当开发队伍的技术力量比较薄弱或经验缺乏时
风险与缺点：
- 获得完善的需求规约是非常困难的；
- 难以适应快速变化需求；
- 系统太大时,难以一次做完；
- 反馈信息慢；
- 极可能引起开发后期的大量返工，如返工到需求、设计等早期活动；
瀑布模型变种——V模型（强调验证过程）
瀑布模型的变种—生鱼片模型（各阶段有重叠）
传统的瀑布模型强调阶段之间的最小重叠，而生鱼片模型强调大幅度的重叠，即在需求分析之前就可以进行架构设计和部分的详细设计
优点：加快进度
缺点：过程跟踪和控制带来问题
螺旋模型
缺点：
比较复杂，需要责任心，专业和管理方面的知识
应用场所：
开发风险较大的软件项目
原型模型（重点）
特点
- 有效适应用户需求的变化
- 不知循环多少次，进度难以控制
适合场所
- 需求动态变化、难以确定的软件系统
原型的好处
- 从实践中学习（learning by doing）
- 改善的通信
- 改善的用户参与
- 使部分已知的需求清晰化
- 展示描述的一致性和完整性
- 可能减少文档
- 减少维护成本
- 特征约束（利用工具构造原型可将某些特性落到实处，非写在纸上那样容易失误）
- 体验结果
原型的缺点：
- 用户有时误解原型的角色，如他们可能误解原型应和真实系统一样可靠
- 缺少项目标准时，进化原型法有点像编码修正
- 缺少控制，由于用户不断提出新要求，原型法的叠代周期难以控制
- 额外的花费：研究表明构造一个原型可能需要10％的额外费用
- 运行效率受影响
- 与用户亲密沟通有时做不到，如软件外包
阶段交付模型
持续地在确定阶段向用户展示软件
和渐进原型不同，在阶段交付的时候，你明确知道下一步要完成什么工作。
特点：不会在项目结束的时候一下交付全部软件，而是在整个项目中持续不断交付阶段成果
优点：项目结束交付全部成果前，分阶段将有用的功能交付给用户
缺点：如果管理层和技术层面上缺乏仔细的规划，工作就无法进行
增量模型
基本过程：
开发一个产品的版本，展示给用户，根据反馈改善产品
特点：
- 并行开发
- 管理复杂
- 结合渐进原型和阶段交付模型的过程模型
如果计划满足用户绝大多数需求，增量模型与渐进原型差不多，如果计划满足用户少量的需求，增量模型与阶段交付原型差不多
渐进原型强调，系统看得见的样子，再回来堵漏洞，增量模型强调系统的核心和底层系统的功能
增量模型优点：
- 从早期的增量的反馈来改进后面的阶段
- 由于阶段设计与其实现之间跨度较短，减少需求变更的可能性
- 用户早期能得到效益
- 有些早期交付可改进现金流
- 较小型的子项目更于控制和管理
- 对于不需要的或不使用的需求是不重要的，或出现在下一增量任务中
- 如果突然出现更多的紧急任务，项目可临时放弃
- 增加开发人员的成就感，能短时间、定时看到自己的劳动成果
不足之处：
- 后面的增量可能要求修改早期的增量
迭代模型
特点
- 通过逐步迭代，建立软件系统
- 面向对象技术
适合场所 - 需求没有/难以完整定义的软件
Scrum
- 一个快捷轻便的过程
- 一个迭代式增量软件开发过程
- 一个适应和经验型的系统管理
- 现存软件工程实践的包装
- 一个提高软件生产效率,改善沟通和合作的方法
SCRUM方法的开发过程
- 计划和体系结构设计（确定性过程）
- Sprint（经验性过程）
- 交付和巩固（确定性过程）
第六章 软件工作量度量
软件度量、测量、估算的概念
软件度量(Metrics)：是指对软件产品、软件开发过程或者资源的简单属性的定量描述
软件测量(Measure)：是对软件产品、软件开发过程和资源复杂属性的定量描述，用于事后或实时状态，如软件可靠性
估算(Estimation)：软件产品、软件开发过程和资源复杂属性的定量描述，用于事前, 如软件开发成本
- 产品：软件开发过程中所生成的各种文档和程序
- 过程：与软件开发有关的各种活动，如软件设计等
- 资源：软件开发过程中所需支持，如人员、费用等
为什么需要软件度量
任何工程化的工作都需要度量
- 软件工程也不例外，准确了解工程的实施情况
项目实施之前 - 辅助制定软件项目的计划
- 估算成本和工作量，以便制定计划
项目实施过程中 - 提供软件开发的可视性
- 跟踪和控制软件项目的开发
- 评估软件开发质量，进行质量控制
- 加强风险管理
项目实施之后 - 对项目的实施情况进行评估
- 为后续项目的积累经验数据
软件度量的内容
三个方面
- 产品：各种文档和程序
- 过程：各种软件开发活动
- 资源：各种资源如人员、费用等
二个层次
- 内部属性
- 外部属性
软件度量方法（重点）
面向规模的度量
对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量的度量
优点
- 简单易行，自然直观
缺点 - 依赖于程序设计语言的表达能力和功能
- 软件开发初期很难估算出最终软件的代码行数
- 对精巧的软件项目不合适
- 只适合于过程式程序设计语言
面向功能的度量
面向功能的软件度量是对软件和软件开发过程的间接度量。
面向功能度量主要考虑程序的“功能性”和“实用性”，而不是对LOC计数。
该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点FP。
计算功能点，使用如下的关系式：
FP ＝ 总计数×( 0.65+ 0.01×SUM ( Fi ) )
Fi（i＝1…14）是复杂性校正值，它们应通过逐一回答下一页的提问来确定。
Fi的取值0…5：
0 没有影响
1 偶然的
2 适中的
3 普通的
4 重要的
5 极重要的
SUM（Fi）是求和函数。
CT的计算方法
- 用户输入数×加权因子(简单=3,平均=4,复杂=6)
- 用户输出数×加权因子(简单=4,平均=5,复杂=7)
- 用户查询数×加权因子(简单=3,平均=4,复杂=6)
- 文件数×加权因子(简单=7,平均=10,复杂=15)
- 外部界面数×加权因子(简单=5,平均=7,复杂=10)
- 系统是否需要可靠的备份和恢复？
- 是否需要数据通信？
- 是否有分布处理的功能？
- 是否性能成为关键？
- 系统是否运行在既存的高度实用化的操作环境中？
- 系统是否需要联机数据项？
- 联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。
- 主文件是否联机更新？
- 输入、输出、文件、查询是否复杂？
- 内部处理过程是否复杂？
- 程序代码是否可复用？
- 设计中是否包括了转移和安装？
- 系统是否设计成可以重复安装在不同机构中
- 系统是否设计成易修改和易使用？
一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：
- 生产率 ＝ FP／PM（人月）
- 质量 ＝ 错误数／FP
- 成本 ＝ 元／FP
- 文档 ＝ 文档页数／FP.
优点
- 与程序设计语言无关, 在开发前就可以估算出软件项目的规模(事前)
不足 - 没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统；
- 功能点计算主要靠经验公式，主观因素比较多
- 数据不好采集
软件估算（重点）
估算内容
- 规模
- 工作量
- 进度
- 关键计算机资源
- 成本
现在已使用的实用技术是时间和工作量估算。估算资源、成本和进度时需要经验、有用的历史信息、足够的定量数据。估算本身带有风险。
软件项目成本和工作量估算极为重要
- 计算机系统中软件成本占总成本的比例很大
- 用户和项目管理人员对软件成本和工作量估算都很重视
软件估算的影响因素
- 历史信息的可用性
要考虑不同的环境，编程语言、软件工具、标准和人员经验 - 项目规模
直接计算实际成本或时间是不可能的。编写同样程序，不同的人所需时间是有显著不同。
通常工作量表示为源代码的数量（source line of code,SLOC）或千行代码量（KLOC） - 项目复杂性
相同的KLOC的两个程序，不同的人所需时间是有显著不同。不能简单的应用SLOC或KLOC，需根据复杂行进行修正 - 结构不确定性，即需求被确定的程度，功能被分解的容易程度等
成本与工作量的估算
- 承诺估计
- 参照和依据已完成项目的历史数据（对比法）
- 自上而下（将大项目分解为小项目，工作分解结构）
- 自下而上的估计：适合后期阶段的估计
- 将项目按照软件生命周期分解
- 根据经验估算公式
- 请专家估计（Delphi技术）
- 帕金森法：先估计人数量，后判断
- 赢的价格：以比较低的合同价来估计
标准Deiphi技术
① 组织者发给每位专家一份软件系统规格说明书和一张记录估算值的表格，请他们进行估算。
② 专家详细研究软件规格说明书的内容，对该软件提出三个规模的估算值，即： ai（最小） mi（可能） bi（最大），无记名地填写表格， 在填表的过程中，专家互相不进行讨论但可以向组织者提问。
③ 组织者对专家们填在表格中的答复进行整理： a. 计算各位专家估算的期望值 Ei; b. 对专家的估算结果分类摘要。专家对此估算值另做一次估算。
④ 在综合专家估算结果的基础上，组织专家再次无记名地填写表格。 比较两次估算的结果。若差异很大，则要通过查询找出差异的原因。
⑤ 上述过程可重复多次。最终可获得一个得到多数专家共识的软件规模（源代码行数）。在此过程中不得进行小组讨论。
基于代码行工作量估算
软件项目规模影响软件项目成本和工作量
估算出FP或者LOC期望值e = (a + 4m + b)/6
a：乐观值
b：可能值
c：悲观值
扩展：
- 根据PM = FP(LOC)/ E 计算出工作量 （工作量 = （规模 = 代码行） / 生产率）
- 根据C = S/FP(LOC) 计算出成本 （总成本 = 工作量 x 单人工资）
PM：工作量
C：总成本
S：每个人每个月成本
例子：
需求分析及设计工作量：41/6+33=39.83 人日
设计检查工作量：1+1+1=3 人日
测试工作量：4+4+4=12 人日
编码工作量：900+900+900=2700 行，假设工程师每天编码效率为270 行，则为 10 人日集成及安装：6 人日
总工作量 E 为 39.83+3+12+10+6=70.83 人日
如果公司平均每日工资为 300 元，则总成本：300×70.83=21249 元
功能点分析
步骤1：估算 5 类型功能点数量
- 外部输入类型：更新系统内部文件的输入活动
- 外部输出类型：输出给用户的信息或数据
- 内部逻辑文件：系统所用的固定文件
- 外部接口文件：与其他系统交换信息
- 外部查询类型：在线输入获得立即结果，不更新内部文件
步骤2：权衡加权因子
功能点复杂度加权因子：
- 用户输入数×加权因子(简单=3,平均=4,复杂=6)
- 用户输出数×加权因子(简单=4,平均=5,复杂=7)
- 用户查询数×加权因子(简单=3,平均=4,复杂=6)
- 文件数×加权因子(简单=7,平均=10,复杂=15)
- 外部界面数×加权因子(简单=5,平均=7,复杂=10)
估算计数=（乐观值+4*可能值+悲观值）/6，功能点计数=估算计数×加权因子
步骤3：确定复杂度校正因子（共 14 个，值为 0-5）即下列公式的Fi
- 系统是否需要可靠的备份和恢复？
- 是否需要数据通信？
- 是否有分布处理的功能？
- 是否性能成为关键？
- 系统是否运行在既存的高度实用化的操作环境中？
- 系统是否需要联机数据项？
- 联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。
- 主文件是否联机更新？
- 输入、输出、文件、查询是否复杂？
- 内部处理过程是否复杂？
- 程序代码是否可复用？
- 设计中是否包括了转移和安装？
- 系统是否设计成可以重复安装在不同机构中
- 系统是否设计成易修改和易使用？
步骤4：计算功能点，使用如下经验关系式：
FP =总计数×( 0.65＋0.01×SUM ( Fi ) )
步骤5：计算工作量和成本
工作量 = FP（功能点数）/ 生产率（点/人日）
成本 = 工作量 * 人均工资
例子：
基础功能点
复杂因子：
FP =总计数×( 0.65＋0.01×SUM ( Fi ) )=114×(0.65+52×0.01)=133
设公司人均效率 2 个功能点/天，日工资 300 元。
工作量 E：133/2=68.5 人日
成本：68.5×300=20550 元
软件估算的经验模型
IBM模型
IBM模型是静态单变量模型。
-
L 是源代码行数(KLOC)
-
E 是工作量(PM,人月)
-
D 是项目持续时间(月)
-
S 是人员需要量(人)
-
DOC 是文档数量(页)
-
在此模型中，一般指一条机器指令为一行源代码
-
一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。
-
对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。
-
转换系数＝机器指令条数／非机器语言执行步数。如：Fortran的转换系数为4~6
CoCoMo模型
CoCoMo模型的层次 － 支持不同的阶段
- 基本COCoMo模型
系统开发的初期，估算整个系统的工作量(包括维护)和软件开发和维护所需的时间 - 中间COCoMo模型
估算各个子系统的工作量和开发时间 - 详细COCoMo模型
估算独立的软构件，如各个子系统的各个模块的工作量和开发时间
基本CoCoMo模型：
E = a * (kLOC)^b;E是工作量(人月) ，a和b是经验常数
D = c * E^d;D是开发时间(月) ，c和d是经验常数
参与开发的人数：E/D
成本 = E * 每日工资 * 一个月工作多少天
例子：
已知代码行数：目标代码行33.2kLOC
- E = 3.0*(33.2)1.12 =152 PM
- D = 2.5*(152)0.35 = 14.5 (月)
- 参加项目人数N = E/D = 152/14.5 = 11(人)
特点：不稳定
中间CoCoMo模型
E = a * (kLOC)^b * EAF
E表示工作量(人月)，EAF表示工作量调节因子，a,b为经验常数
EAF的取值(范围)
- 很低、低、正常、高、很高、极高
- Boehm建议取值范围[0.70-1.66]
其中，工作量因子：
一个规模为10KDSI的商用微机远程通信的嵌入型软件，使用中间COCOMO模型进行成本估算
成本 = 工作量（人月） * 每日工资 * 工作天数
估算技巧
- 分解估算（过程分解和模块分解）
和的误差大于误差的和 - 给出估计一个范围（如最好情况下）或一个可信赖程度（如90%的把握）。
期望值=（乐观值+4*一般值+悲观值）/ 6 - 避免无准备的估算
不要随便说出一个 - 估算留出估算的时间，并做好计划
- 使用以前项目的数据
- 估算师和开发人员共同估算
- 走查估算
- 分类法估算
- 不要忽略普通任务
- 使用软件估算工具
- 使用几种不同估算方法，并比较它们的结果
- 项目进行中改变估算规则
第七章 软件项目计划
什么是软件项目计划（重点）
软件项目计划是对软件项目实施所涉及的活动、人员的安排、任务的划分、开发进度、资源的分配和使用等方面作出的预先规划
- 活动和任务
- 资源及其安排
- 进度计划
为什么需要软件项目计划（重点）
- 有序、可控制地对软件项目进行管理
- 确保活动在正确的时间有正确的资源可用
- 避免不同的活动在相同的时间竞争相同的资源
- 为每个员工分配任务
- 实际的进度有标准进行衡量
- 产生成本的消耗计划
- 根据项目的实际，调整项目计划
- 生产高质量的软件产品
- 确保员工的士气高昂，员工保持高生产率
- 及时交付软件产品，降低软件开发成本
- 成功地进入市场
- 客户满意度
- 及时发布产品新版本
制定软件项目计划应该考虑的因素
软件项目计划制定的方式
自顶向下
- 由一个或者一部分人单独完成
- 目的是服务于高层领导和用户，而不是项目组
- 主要依据项目进度的要求和约束，针对项目中的重大活动(如需求分析、软件设计等)而制定的一个粗略的软件项目计划
- 只能作为目标进度表，不能作为实施进度表
自底向上
- 计划由计划制订者负责，所有项目组成员参与制定
- 一般供项目组，用于实际项目的实施
- 要求项目组成员事先了解和认可
- 详细定义了计划中的所有活动(不仅仅是哪些重大活动)，明确了活动的参与者、持续时间以及活动之间的关系
软件开发活动
什么是软件开发活动？
- 为开发软件项目而执行的一项具有明确任务的具体工作
- 例如，需求分析，执行单元测试，制定软件项目开发计划等
软件开发过程中存在许多相互关联的软件开发活动
- 明确的任务
- 非孤立，和其他活动存在关联
按任务性质，软件开发活动可分为二种形式
- 技术活动
对软件项目实施开发，产生软件产品
例如，需求分析，概要设计，编码，单元测试等等 - 管理活动
对软件项目中的人、产品和过程等实施管理的活动
例如，制订软件项目计划，软件配置等等
技术活动
- 需求分析
- 概要设计
- 详细设计
- 编码
- 集成测试
- 撰写出版物
- 用户确认测试
- 软件发布
管理活动
- 制定初步软件开发计划
- 制定详细软件开发计划
- 制定软件配置管理计划
- 制定软件质量保证计划
- 项目跟踪和监督
- 配置管理
- 用户培训
如何定义软件开发活动?
- 名称
- 任务
- 输入: 开始所必需满足的条件
- 输出: 完成时所必须满足的条件以及结果
- 实施: 做什么，怎么做(详细的步骤)，或者如何从输入产生输出
软件活动例子: 单元测试
- 任务
对软件基本单元模块进行测试，判断是否有错
- 输入
有一个已完成、被文档化和批准的软件单元测试计划 供测试的软件单元模块代码
- 实施
遵循单元测试计划，运行了所有的测试用例 撰写了单元测试报告
- 输出
单元测试报告
软件开发活动之间的关系
软件开发活动之间的次序反映了活动之间的依赖关系
- 逻辑
一个软件开发活动输出是另一个软件开发活动的输入
例如，需求分析和软件设计之间 - 时间
一个软件开发活动需等到另一个软件开发活动完成之后才能执行
例如，集成测试和确认测试
活动之间有哪些关系？
- 结束到开始
- 开始到开始
- 结束到结束
- 开始到结束
结束到开始：
开始到开始：
结束到结束：
WBS的构造方法（重点）
- 识别出项目中（包括技术活动、管理活动）中的主要交付物
- 资产管理系统中的交付物有哪些？
- 主要交付物总是根据项目实际是如何组织来定义的
项目生命周期的各阶段可以作为第一层次，并将项目交付物作为第二层次
每个分支的组织方法可以不一样
例子：每天起床的WBS
如何验证WBS的正确性和完整性：
- 判断对这一层次是否能够对成本和日期进行评估，如果不能，继续分解，否则该分支分解结束
- 识别交付物的组成部分。组成部分必须是实际的、可验证的部件
- 验证分解的正确性。
是否被分解的条目对子项目是否充分必要，如果不是，则需要增、删、合或修改
是否每一条目被清晰定义
是否每一条目能够被合理地计划，成本规划，被分配给合适的组织或团队、个人
输出
WBS最底下的一层，称为工作包（work package）
示例：
CPM的构造方法与原则
CPM的一些构造规则（重点）
- 项目网络只有一个起点
- 项目网络只有一个终点
- 连接有持续时间
- 节点无持续时间
- 时间从左到右
- 节点顺序编号
- 网络能不包含回路
（错）
-
网络不能包含悬点
（错） -
前继：某活动的紧前活动
CPM构造方法
估算活动周期
- 细分活动
活动的粒度越小，估算的准确度就会越高 - 借鉴历史数据
积累历史数据 - 使用估算模型
例如，CoCoMo模型 - 考虑缓冲时间
缓冲时间保证项目按照计划有足够的时间来完成活动 - 缓冲时间
意外事件的缓冲
意外事件可能会发生(如全企业的培训)
例如，需求分析计划从8.1开始共需20个工作日，应该8.29日完成，但中间公司要开展2天的全员培训，因此8.31结束
节假日时间的缓冲
例如，编码计划从9.31开始，工作量为10个工作日，因为国庆放假1周，因此，应该计划在10.21日完成 - 不要在计划中考虑加班时间，加班是不可避免得，但是考虑了加班，可能会发生更多的加班
- 综合考虑其他因素
考虑节假日
以工作日(而不是星期)规定活动周期
考虑参与活动团队的教育、培训、经验和技能水平
考虑教育和培训需要 考虑评审所化的时间
考虑传播时间
考虑团队中成员的其他工作
考虑硬件、工具和人员的效率
考虑活动的迭代和重复
活动之间有一定的缓冲……
工作量的分布：
活动中加入时间（重点）
关键路径法主要关注的两个目标：
- 尽快完成整个项目
- 识别哪些一旦延期将对整个项目周期产生影响的活动
对每个活动赋予持续时间后，可采用前向路径（forward pass）计算项目和各活动最早结束时间；采用反向路径（backward pass），计算项目和各活动最晚结束时间。
CPM中节点的表示（重点）
- 事件代号(Event number)
- 最早日期(Earliest date)
最早开始和最早结束 - 最晚日期(Latest date)
最晚开始和最晚结束 - 缓冲时间(Slack)
最晚结束时间-最早结束时间
最晚开始时间-最早开始时间
例子
先从前往后填写最早时间：
第一步：
第二步：
第三步：
第四步：
第五步：
第六步：
再从后往前填最晚时间：
第七步：
第八步：
第九步：
第十步：
第十一步：
第十二步：
前后向路径计算完成后的活动表：
关键路径（重点）
时间的最早结束时间和最晚结束时间的差，成为缓冲时间。它表示一个事件推迟多少时间可以不影响项目的结束。Slack为0的事件为关键事件，将关键事件连接起来的最长路径为关键路径
为什么要考虑关键路径：
- 关键路径上活动的进度直接影响到整个项目的进度
- 必须保证关键路径上的资源和活动顺利进行
- 如果关键路径上活动的进度受到影响，那么整个项目的进度肯定会受到影响
- 要缩短项目的开发周期，必须加快关键路径上活动的开发进度
上述案例中的关键路径：
活动的缓冲时间（重点）
给个活动的缓冲时间是相关的。如果某个活动用了缓冲时间，后续的活动可能就没有缓冲时间。
空闲缓冲(free float):当前活动的最早结束时间和后继活动最早开始时间之差为空闲缓冲时间。它不影响其它活动。当前活动延期多长时间而不影响后继活动的最早开始时间，强调的是会不会影响后继活动的最早开始时间。
干预缓冲(interfering float)：活动的空闲缓冲时间与总缓冲时间之差。它反应空闲缓冲被使用后，活动还能被延时多少时间而不影响整个项目的结束时间。
缩短项目时间（重点）
- 减少关键活动的周期
- 整个项目活动的重组
过于乐观的软件项目计划
出现的原因：
- 赶时间
- 为了迎合客户的不切实际的进度要求
- 估算不准确
- 需求变更(增加)
- 开发人员没有充分参与和承诺
产生乐观估计的根源：
- 为了赶在某些特定时间前展示或出售产品，如计算机交易会
- 管理人员和客户拒绝接受仅给出范围的估算，而是按照他们认为的最佳“估算”来制定进度计划
- 项目管理人员和开发人员为了享受挑战的乐趣或压力下工作的刺激，故意缩短进度
- 项目管理人员认为较紧的进度计划能够使员工勤奋工作
- 原先估计是合理的，但在项目进行过程中又加进了许多新特性，从而变成过于乐观的进度
过于乐观计划的后果：
- 计划的质量：错误的假设必将导致无效的项目规划
- 抛弃计划：当面临进度压力时，大多数开发组织抛弃原有计划，而走入盲目开发歧途
- 如果试图在关键阶段节省时间，必将在后续阶段加倍补偿
- 分散管理者的注意力：管理者将精力放在不断调整计划上
- 客户关系：项目一拖再拖，客户将失去耐心
- 仓促收尾
要排错只能将系统拆分后进行，一个小的变动要花很长时间
开发人员清楚知道系统中存在一些应做修改却未做的地方
测试人员发现错误的速度大于软件开发人员的速度
排除已发现的错误的同时，产生大量新的错误 由于软件变化频繁，难以保证用户文档的同步更新
目估算多次调整，软价交付日期一拖再拖
第八章 资源分配
资源分配的目的
- 活动进度
产生每个活动计划新的开始日期和结束日期 - 资源进度
产生每个资源要求的日期以及要求的调度等级 - 成本进度
产生资源使用过程中的计划的累计花费
资源的特性：
- 资源是执行项目过程中所需的人员或任何事物
- 有些资源是项目整个过程中都需要的，有些则在某些活动中需要，前者管理起来反而比后者简单
资源的分类（重点）
- 人力资源：项目团队成员（项目经理，需求分析员，系统分析员，设计人员，程序员，质量管理员，其它人员）
- 设备资源：包括服务器以及其它计算和办公室设备（打印机、传真机、打印纸、数据采集器等）；员工需要的桌椅
- 物料资源：设计硬件时才需要
- 场地资源：如果要容纳更多的人，就要考虑
- 服务资源：比如网络带宽，其它的支持软件
- 时间：每一项目中都要有的资源
- 金钱：必不可少的支持项目进行的资源，可购买其它资源
确定资源需求
某个项目的优先网络：
根据需要确定一定需求水平的各种资源，如：何种类型的员工及数量，设备的类型和数量等
资源需求列表：
平衡资源与资源调度（重点）
我们将上述例子画成甘特图：
绿色的部分代表缓冲区
根据上图，画出某一个资源的资源需求直方图：
纵轴——资源的数量
横轴——项目的阶段
（图中第一阶段没有画出）
红线代表可用的资源数量
画的方法：画一条平行于纵轴的线，将线从左向右移动，这一过程中某一时间点和这条线相交的活动的数量就是资源需求量的根据
资源的平衡方法
通过将活动延期或将活动分解成几部分，使资源图变得均匀。
蓝线代表：资源可用性
还是一上面那个题为例：
在上面项目中，现阶段的资源直方图在阶段2和阶段4期间要求4名，如何平衡直方图使得只使用3名分析/设计人员就能满足要求。
由于只有3名分析/设计人员，将不得不延迟模块D的详细说明直到完成模块B的详细说明之后才开始，这样以来整个项目将延迟5天。如果希望项目在100天内完成，将重新设计活动图。在原来的活动图中，需要检查完所有的详细说明模块才能进行设计活动，这是个瓶颈。因而可先检查详细设计模块A、B、D后，就开始设计工作，详细设计模块C的检查另外进行
修订后的优先网络图(假设有4名分析员)
修订后的Gantt图及资源图(4人分析/设计)
活动优先权的设定（重点）
- 找到最佳的资源平衡图要耗时间且困难
- 资源分配给一个活动后，其它活动便不能再分配
- 多个活动需要同一资源时需要对资源进行排序
设置活动的优先权
- 有助于资源能以比较合理的方式分配给竞争的活动
- 先分配资源给关键路径，后分配给可能影响其它活动的活动
总缓冲期优先权
- 活动按总缓冲期排序，最小总缓冲期的活动具有最高的优先权
- 活动总是按总缓冲期的升序分配资源
- 随着项目的进展，如果有活动被拖延，总缓冲期将减少；重新计算总缓冲期，重排优先权列表
上述的例子：
有序表优先权：
可以同时进行的活动，按一组简单的准则来排序－Burman列表
- 最短关键活动
- 关键活动
- 最短非关键活动
- 有最少缓冲的非关键活动
- 非关键活动
考虑资源的特性
-
目的：分配任务合理，满足项目进度要求
-
在大型建筑领域，人力一般被看成平等的，各人的技能和效率可不考虑。
-
资源的可获得行(availability)：需要知道特定的人员在需要时是否可以获得
-
关键性(criticality)：将有经验的人员分配给关键路径上的活动
-
风险（risk）：标识项目中最大风险的活动；将有经验的人员分配到最高的风险活动
-
培训(training)：有充足的缓冲时间来培训初级员工开发非关键活动的技能
-
团队组建（team building）
第九章 软件项目监控
软件项目监控示意图：
什么是软件项目监控
在项目实施过程中，随时掌握项目的实际开发情况，使得当项目实施与计划相背离，或者出现问题和风险时，能够采取有效的措施
软件项目监控的基础
- 软件开发计划
活动和关系
进度计划
资源和人员计划
成本计划，……
- 软件项目实际实施过程
实施了的实际进度
实施面临的问题
为什么需要对软件项目进行监控
软件项目实施相对于计划的不确定性、动态性和实施过程中问题多样性和不可预知性及其带来的风险
- 不现实的截至日期
- 对工作量和资源数量估算不足
- 客户需求的动态变化
- 交流不畅而导致的项目延期
- 计划没有考虑风险
- 事先无法预知的技术问题
- 事先无法预知的人力困难
软件项目监控的内容（重点）
- 项目风险
- 项目进展
- 开发活动进展（实际的与计划的差别）
- 开发活动问题
- 项目展望
- 成本监控
软件项目风险
软件项目在实施过程中存在各种问题和风险
- 技术风险，例如某项需求尚未找到合适的技术解决途径，或者原先所制定的技术解决途径发现不合适
- 进度风险，例如某项活动原先计划1个月时间完成，但是现在3个月过去了仅仅完成任务的一半
- 成本风险，由于没有控制支出，实际成本已经远远超过原先计划的成本预算，并且仍然不断增长
- 人员风险，项目组成员临时跳槽或者调派，人员缺乏
- 工具和设备风险，所需的工具和设备不能按时提供，或者得不到，….
在项目监控过程中，识别风险以便管理风险
- 通过了解项目的实际实施情况，发现风险
- 详细描述风险
- 将各个风险组织以风险清单形式提交讨论
项目风险清单的内容
- 风险描述
- 负责人
- 风险处理的开始时间，可能会发生变更，保留历史
- 目标结束时间，可能会发生变更，保留历史
- 风险标识
风险报告－交通灯法：
询问项目成员完成计划的可能性
识别评价项目中某项活动的关键元素
将关键元素分解为子元素
对每一元素 - 符合计划要求：绿灯
- 目前已经拖后，但可以恢复：黄灯
- 已经拖后，恢复很难：红灯
例子：
项目进展
在项目实施过程中，项目的实际进度可能会与计划的进度产生偏差
- 工作量估算的不准确
- 用户需求的变更
- 交流的不畅
- 人员的变更
- 受到其他不可预知情况的干扰
- …
在项目监控过程中，洞悉项目的实际进展
- 了解项目的实际进展情况
- 项目计划
- 将实际进展与计划进行比较，了解偏差，以便采取措施
开发活动进展
在项目监控过程中，洞悉开发活动实际进展
- 详细、具体了解各项活动的实际情况
- 开发活动的计划
- 将实际进展与计划进行比较，了解偏差，以便采取措施
开发活动进展球形图(3/3)
开发活动问题
项目开发活动过程中，可能会遇到许多问题
- 具体项目的特殊情况
- 计划的不全面性
- 规程的不完备性
- 交流的不充分性
项目展望
展望项目在未来合适的时间段的情况
- 下一个主要里程碑
- 公开发布日期
- 产品交付日期
软件项目监控的目标和方式
软件项目监控的目标
通过监控对软件项目的实施提供可视性：
- 知道项目的实际执行和实施情况
- 知道项目实施过程中(可能)出现了哪些问题
- 知道如何采取措施防止问题的出现，或者出现时该采取什么办法减少它给软件项目实施带来的影响和损失
软件项目监控的方式
- 成立项目监控小组PTT(Project Tracing Team)
由项目组成员(小项目)或者负责人(大项目)组成
- 指定项目监控负责人
负责协调项目进度的监控工作
- 定期召开项目监控会议，获取项目实施的详细情况和面临的问题
最好定期每周一次
了解项目实施情况
汇报问题：口头报告或书面报告
成本监控（重点考核）
成本监控的意义：
- 成本本身是项目的重要元素
- 成本监控能够展示已经花费了多少劳力
简单的监控方法－累计消耗图：
缺点：不能说明项目的进展情况
累计消耗图＋项目时间信息：
挣值管理
挣值管理方法目前已成为项目管理和控制中的主流方法，或者说是一个非常重要的管理方法。
- 实际上是建立在工期和成本联合控制方法上的一套技术
- 它是基于工作分解、估算及预算，根据项目的进度计划确定项目的工期、进展情况以及成本预算，对成本预算进行分配，监控项目的绩效进展。
挣值管理的优点：
- 准确地描述项目的状况
- 准确及时地确定趋势
- 准确及时地识别困难
- 为过程改进提供基础
BCWS（PV）：项目预算成本
活动或项目预算成本（计划预算成本），简称BCWS。也称PV(计划成本)，即根据批准认可的进度计划和预算到某一时点应当完成的工作所需要投入的资金。这个值对衡量项目进度和费用都是一个基准，一般来说，PV在项目实施过程中应保持不变，除非预算、计划或者合同有变更。表示应做多少工作？
BCWP（EV）：挣值（已完成部分的预算成本）
就是挣得的价值，即活动或项目完成以后的工作预算成本，也称EV(挣值Earned Value) ，即根据批准认可的预算，到某一时间点已经完成的工作应当投入的资金。表示做了多少工作？
ACWP（AC）:项目实际成本
项目的实际成本常常用ACWP来表示，也称AC(实际成本) ，即到某一时间点已完成的工作实际花费或消耗的成本。
项目的预算成本、挣值和项目的实际成本都是随着时间而不断变化的，一直到项目结束为止。通常这三个曲线的变化特征像一个S曲线。
例子：
举例：某土方工程总挖方量为
4000立方米，计划用10天完成，每天400立方米，预算单价为45元/立方米，该挖方工程预算总费用为180000元。
开工后第7天早晨刚上班时业主项目管理人员前去测量，取得了两个数据：已完成挖方2000立方米，支付给承包单位的工程进度款累计已达120000元。
1、计算BCWP（实际完成工作的预算成本）
BCWP =45元/立方米 ×2000立方米=90000元
从这里可以看出，实际完成工作预算成本（BCWP）与项目进度没有直接关心，并不关系项目实际进度到了什么程度，只关系实际完成的工作量
2、计算BCWS（计划工作预算成本）
开工后第6天结束时，承包单位应得到的工程进度款累计额为BCWS=108000元。
3、计算ACWP（完成工作的实际成本）
本案例的ACWP很明显，直接给出了，ACWP=120000
CV：成本偏差
CV=BCWP–ACWP
成本偏差也就是挣值与实际成本两者之差。
如果挣值大于实际成本，那么成本偏差是正的，它反映成本绩效比较好，反之，如果成本偏差是负数，代表的是成本的超支，就是成本项目的绩效有问题。
- 大于0 成本节约状态
- 小于0 成本超支状态
SV：进度偏差（Schedule Variance）
SV=BCWP-BCWS
SV，即进度偏差。进度偏差仍然用挣值做一个基本标准，用挣值减去当前活动或项目的预算成本，就是BCWP减去BCWS。
进度本来应该是时间单位，但是在挣值管理方法里边，工期偏差可用货币进行描述（？）。
- 大于0 进度超前状态
- 小于0 进度滞后状态
成本绩效指数（CPI）
挣值与实际成本之比
进度绩效指数（SPI）
挣值与计划成本之比
挣值跟踪图
BAC：完工预算成本
BAC也就是在活动或项目期末的时候总的计划成本是多少，即完工时的预算成本。
EAC：预计完工成本
EDC：预计完工日期
项目的预计完工工期(EDC)
＝原项目计划的工期(OD)/SPI
完工偏差VAC、VDC、ETC和预计的完工成本
完工成本偏差(VAC)=BAC-EAC
完工的进度偏差（VDC）＝原工期(OD)－估计新工期(EDC)
预计完工成本偏差（ETC）=EAC-ACWP
完工进度比例＝BCWP/BAC
完工资金比例＝ACWP/BAC
某软件项目计划工期为4年，预算总成本为800万元。在项目的实施过程中，通过对成本的核算和有关成本与进度的记录得知，在开工后第二年年末的实际情况是：开工后二年末实际成本发生额为200万元，所完成工作的计划预算成本额为100万元。与项目预算成本比较可知：当工期过半时，项目的计划成本发生额应该为400万元。试分析项目的成本执行情况和计划完工情况。
由已知条件可知：PV=400万元 AC=200万元 EV=100万元
CV=EV-AC=100-200=-100 成本超支100万元
SV=EV-PV=100-400=-300 进度落后300万元
SPI=EV/PV=100/400=25%
二年只完成了只完成了总任务在1/4.
CPI=EV/AC=100/200=50%
完成同样的工作量实际发生成本是预算成本的2倍。
EAC=BAC/CPI=400/0.5=800万元(当前)
预计整个项目完成时的EAC=800/0.5=1600万
该项目延期，并且超支了
软件配置管理
软件配置管理（Software Configuration Management, SCM）是指通过执行版本控制、变更控制等规程，以及使用合适的配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
配置管理与任何一位项目成员都有关系，因为每个人都会产生工作成果。配置管理是否有成效取决于三个要素：人、规范、工具
变更控制
变更控制的目的是防止配置项被随意修改而导致混乱。
- 为了提高效率，对于处于“草稿状态”的配置项，不必进行变更控制，因为它们本来就是草稿，本来就是要被不断地修改的。
- 当配置项状态为“正式发布”，或者该配置项已经成为某个基线的一部分（即被“冻结”）时，如果要修改配置项的话，那么按照变更控制规则执行。
步骤：
第十章 软件项目风险管理
什么是软件风险（重点）
使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件
例如，人员的临时流失，计划过于乐观，设计的低劣
软件风险的分类
- 项目风险：威胁到项目计划
如：进度、人力、资源、客户及需求等问题 - 技术风险：威胁到软件的质量及交付时间
如：设计、实现、接口、验证和维护等问题 - 商业风险：威胁到软件的生存能力
- 环境风险：威胁到软件的合法性
与相关法规相冲突，能否通过管理部门的鉴定 - 政治风险：会不会造成政治方面困扰
五大商业风险
- 市场风险
开发了个没有人真正需要的优秀软件 - 策略风险
开发的产品不再符合公司的整体商业策略 - 销售风险
建造了一个销售部门不知道如何去卖的产品 - 管理风险
由于重点的转移或团队人员的变动而失去了高级管理层的支持 - 预算风险
没有得到预算或人力上的保证
什么是软件风险管理
- 对影响软件项目、过程或产品的风险进行评估和控制的实践过程。
- 在风险影响软件项目成功实施前，对它进行识别和处理，并预防和消除风险的发生
- 识别风险(会有哪些风险？)
- 预防和消除风险(最好别让风险发生)
- 制定风险发生后的处理措施(万一发生该怎么办？)
风险管理的组成
为什么需要软件风险管理（重点）
- 软件风险是软件与生俱来的；
- 软件风险随着系统复杂程度的增加而增加；
- 软件风险阻碍人们实现目标
- 软件项目风险管理可以降低软件项目风险造成的危害和损失
风险评估
- 风险识别：识别风险，形成风险列表
- 风险分析：判定每一个风险出现的概率、产生的影响及其重要性
- 风险优先级：按照每个风险的重要性排出一个风险优先级
多维度风险识别方法（重点）
目标维：成本、进度、质量、安全
要求有相对的成本、项目目标、成本目标、进度目标、质量目标、安全目标，根据目标的维度分析可能存在的风险，像成本超支风险、进度拖延的风险、质量不合格的风险、安全隐患的风险。
时间维：不同阶段、需求分析、设计、编码/测试、集成
项目的进展维度，在项目进展的不同阶段，对可能存在的风险进行分析。
因素维：技术、非技术
可以按照技术风险、非技术风险进行风险识别。分析技术类的风险是人为风险还是管理的风险？从多个角度、多个维度进行风险识别，可以有效地把可能存在的风险找出来，为有效项目风险管理提供良好的基础。
软件风险的具体类别
- 计划编制
- 组织和管理
- 开发环境
- 最终用户
- 客户
- 承包商
- 需求
- 产品外部环境
- 人员
- 设计和实现
- 过程
风险分析
定性风险分析方法和步骤
- 在定性分析中通常采用概率这个术语。
- 风险的概率是指某一个风险发生的可能性。
- 使用定性术语可以将风险的概率及其后果描述为极高、高、中、低、极低五档。风险后果是指风险发生对项目目标产生的影响。后者指的是一个结果，前者指的是一种可能性。
- 风险的这两个维度适用于具体风险事件，而不适用于项目整体。
- 使用风险概率和风险后果来分析风险，可以帮助我们甄别出哪些风险需要强有力的控制与管理。
运算规则
风险发生可能性： VH H M L VL
损失严重性： VH H M L VL
风险运算规则：
LL=VL
MM=M
HH=VH
MH=H
ML=L
定性风险分析方法评估风险发生的概率
主观性较强，采用方法
- 熟悉系统、有经验的人参与评估
- 多人独立评估，综合折中
- 采用分类：非常可能(0.8-1.0), 很可能(0.6-0.8)，或许(0.4－0.6)，不太可能(0.2-0.4)，不可能(0-0.2)
定量风险分析方法
定量风险分析过程的目标是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。这一过程使用的技术手段和决策分析包括：
- 测定达成某一特定项目目标的概率，概率越大，目标达成的可能性越大；
- 量化项目的风险暴露额，决定可能需要的成本大小和进度计划应急准备金的大小、数量；
- 通过量化各风险对项目风险的相应影响，甄别出最需要关注的风险；
- 找出理想的和可实现的成本、进度计划及工作范围目标。
定量风险分析方法概率分布
通过量化分析，量化各风险对项目总风险的影响，找出哪些是需要关注的风险。按照轻重对风险进行排序，找出理想的对策。
量化风险分析涉及到一些概率论的基本知识，这就需要了解概率的分布特征。概率的分布主要有四种：
- 离散分布和连续分布
- 均匀分布
- 正态分布
- β分布
概率变量:风险损失的期望值、标准差或方差
应用PERT技术确定活动的概率（重点）
最可能时间：期望任务在正常情况下所花的时间(m)
乐观的时间：期望任务完成的最短时间（a）
悲观的时间：考虑所有可能情况下的最坏可能时间（b）
期望时间（均值）：te
例子：
解答：
（1）求出σ： σ = （36-6）/ 6 = 5
（2） 由 σ可知 21+5=26 21-5=16， 因此16—26天落在1 σ分布内。
（3） 由1 σ的概率P为68.26可得答案为 B. 68.26%
注意：必须记住三个数字是 1σ 68.26%
2σ 95.46%
3σ 99.7%
PERT活动时间的估计
PERT网络：
计算活动和事件标准偏差：
风险优先级（重点）
- 统计表明，项目80%成本用于解决20%的问题
- 风险管理重点关注20％重要的部分
- 根据风险的危险度确定风险的重要性，忽略其他的部分
评估风险发生造成的损失：
可以基于**“进度”，“成本”或者“工作量”**来进行估算
风险危险度 = 风险概率 × 风险损失
根据上述计算优先级：
风险控制
风险管理计划
针对每一个重要的风险，制定一个处理该风险的计划
- 风险由谁引起
- 表现形式是什么
- 可能什么时候发生
- 为什么发生
- 如何避免或者消除它的发生
- 发生后的处理措施
风险化解（重点）
- 避免风险：推迟小谢的离开时间
- 转移风险：将风险从系统的一部分转移到另一部分，让客户来做
- 风险减轻：消除发生风险的根源，加薪
- 发布风险：不会突然和惊讶
- 接受和控制风险：接受并提供处理计划，安排小王接替小谢的工作
- 记录风险：为将来项目风险管理提供历史数据
根据不同条件，不同的环境或者不同的问题可以选择不同的对策
概率高低以及后果损失大小，组成了一个四维空间。
①概率发生率高，后果损失较小；
②概率发生率比较低，后果损失小；
③概率发生率高，后果损失大；
④概率发生率比较低，后果损失大。
风险监控
检查风险的化解程度及其变化(概率、损失)
风险监控的方式
- 监控和跟踪重要的(前10个)风险，记录风险危险度的变化以及风险化解的进展
- 中间审查，在每个里程碑后进行小规模的走查
- 任命风险官员(适合于大项目)，警告项目风险，防止项目经理和开发人员忽略计划中的风险管理