304.软件项目管理--范围计划

1、软件需求管理过程

核心三计划:

范围计划\进度计划\成本计划(成本基准，进度基准)

软件需求

需求是指用户对软件的功能和性能的要求，就是用户但愿软件能作什么事情，完成什么样的功能，达到什么性能。

软件需求的层次

项目失败的缘由分析

软件需求管理的过程

需求获取

需求分析（功能数据行为模型，建模）

编写需求规格

需求验证

需求工程基本任务

需求获取

基线：经过评审的需求

需求分析定义

需求分析是为最终用户所看到的系统创建一个概念模型，是对需求的抽象描述。

需求分析模型

需求规格

• 需求分析工做完成的一个基本标志是造成了一份完整的、规范的需求规格说明书
• 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工做的基础。

软件需求规格说明的原则

• 从现实中分离功能，即描述要“作什么”而不是“怎样实现”
• 采用必定的规格说明语言
• 若是被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中
• 规格说明应该包括系统运行环境
• 规格说明应该是一个认识模型
• 规格说明应该允许不完备性并容许扩充

规格文档参考

1. 引言
2. 系统定义
3. 应用环境
4. 功能规格
5. 性能需求
6. 产品提交
7. 实现约束
8. 质量描述
9. 其它
10. 签字认证

需求验证

• 需求是正确的吗？
• 需求是一致的吗？
• 需求是彻底的吗？
• 需求是实际可行的吗？
• 需求是必要的吗？
• 需求是可检验的吗？
• 需求是可跟踪的吗？
• 最后的签字

需求总在变化

需求变动管理

1. 肯定需求变动控制过程
2. 创建变动控制委员会(SCCB)
3. 进行需求变动影响分析
4. 跟踪全部受需求变动影响的工做产品
5. 创建需求基准版本和需求控制版本文档
6. 维护需求变动的历史记录
7. 跟踪每项需求的状态
8. 衡量需求稳定性

需求变动管理

管理和控制需求基线的过程

需求变动控制系统　

一个正式的文档，说明如何控制需求变动　　

创建变动审批系统

2、任务分解定义

WBS (Work Breakdown Structure)

任务分解的过程 将一个项目分解为更多的工做细目或者子项目，使项目变得更小、更易管理、更易操做。

任务分解的结果 WBS（任务分解结构）。

WBS 面向可交付成果的。

Work packages（工做包） WBS的最低层次的可交付成果

WBS实例

PMI defines WBS

是面向可交付成果的对项目元素的分组,它组织并定义了整个项目范围.不在WBS中包括的工做就不是该项目的工做

它是一个分级的树型结构，是对项目由粗到细的分解过程。工做结构每细分一个层次表示对项目元素更细致的描述

PMI defines Work packages

WBS的最低层次的可交付成果

工做包应当由惟一主体负责

这一交付成果能够分配给另一位项目经理进行计划和执行,或者经过子项目的方式完成

3、任务分解的类型

类型

• 清单
• 图表

图表类型

清单类型

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          在程序的头部增长修改纪录

4、任务分解的方法

任务分解过程

分解方法

• 类比：参照相似项目的WBS
• 模版：经过一个通用模板，对其进行增删
• 自上而下
• 自下而上

WBS模板举例

分解方法-自上而下

分解方法-自下而上

任务结构分解(WBS)步骤

确认并分解项目的组成要素

肯定分解标准

肯定分解是否详细

肯定项目交付成果

验证分解的正确性(创建编号)

WBS编号系统

WBS与OBS（组织分解结构）

分解标准

• 生存期
• 功能组成

分解标准应统一

学生管理

• 按照生命期分解

• • 规划需求设计编码测试提交
• 按照产品组成分解
  • 1.1        招生管理
  • 1.2         分班管理
  • 1.3         学生档案管理
  • 1.4         学生成绩管理
• 不能同时使用两种标准进行分解
  • 招生管理  分班管理  学生档案管理 学生成绩管理 规划 需求 设计 编码 测试 提交

检验分解结果的标准

• WBS分解的规模和数量因项目而异、因项目经理而异
  
• 收集与项目相关的全部信息
• 参看一下相似的项目的WBS,与相关人员讨论
• 能够参照模板最低层是可控的和可管理的，可是避免没必要要的过细，最好不要超过7层，
• 软件项目推荐分解到40小时的任务
• 注：80/8规则
• 每一个Work package必须有一个提交物
• 定义任务完成的标准
• 每一个WBS必须有利于责任分配
• 能够准备WBS的字典
• 最后与相关人员进行评审

WBS字典内容