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

一、软件需求管理过程

核心三计划:

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

软件需求

需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。

软件需求的层次

304.软件项目管理--范围计划_第1张图片

项目失败的原因分析

304.软件项目管理--范围计划_第2张图片

软件需求管理的过程

304.软件项目管理--范围计划_第3张图片

需求获取

需求分析(功能数据行为模型,建模)

编写需求规格

需求验证

需求工程基本任务

304.软件项目管理--范围计划_第4张图片

需求获取

基线:通过评审的需求

需求分析定义

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

需求分析模型

304.软件项目管理--范围计划_第5张图片

需求规格

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

软件需求规格说明的原则

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

规格文档参考

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

需求验证

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

需求总在变化

需求变更管理

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

需求变更管理

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

需求变更控制系统 

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

建立变更审批系统

304.软件项目管理--范围计划_第6张图片

304.软件项目管理--范围计划_第7张图片

二、任务分解定义

WBS (Work Breakdown Structure)

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

任务分解的结果 WBS(任务分解结构)。

WBS 面向可交付成果的。

Work packages(工作包) WBS的最低层次的可交付成果

WBS实例

304.软件项目管理--范围计划_第8张图片

PMI defines WBS

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

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

PMI defines Work packages

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

工作包应当由唯一主体负责

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

三、任务分解的类型

类型

  • 清单
  • 图表

图表类型

304.软件项目管理--范围计划_第9张图片

清单类型

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

四、任务分解的方法

任务分解过程

304.软件项目管理--范围计划_第10张图片

分解方法

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

WBS模板举例

304.软件项目管理--范围计划_第11张图片

分解方法-自上而下

304.软件项目管理--范围计划_第12张图片

分解方法-自下而上

304.软件项目管理--范围计划_第13张图片

任务结构分解(WBS)步骤

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

确定分解标准

确定分解是否详细

确定项目交付成果

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

WBS编号系统

304.软件项目管理--范围计划_第14张图片

304.软件项目管理--范围计划_第15张图片

WBS与OBS(组织分解结构)

304.软件项目管理--范围计划_第16张图片

分解标准

  • 生存期
  • 功能组成

分解标准应统一

学生管理

  • 按照生命期分解

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

检验分解结果的标准

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

WBS字典内容

304.软件项目管理--范围计划_第17张图片

你可能感兴趣的:(304.软件项目管理--范围计划)