软件项目管理第二篇：项目计划 （1）——范围计划

第二篇：项目计划 第四章：软件项目范围计划——需求管理

1.软件需求：

（1）定义：

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

（2）包括三个层次：

业务需求、用户需求、功能需求。最后确定软件需求规格。
软件项目系统的响应时间属于功能需求。

2.需求工程

包括需求开发（需求获取、需求分析、需求规格编写和需求验证）和需求管理。

• （1）需求获取

• （2）需求分析：
  传统需求分析方法

  1. 原型分析方法
  2. 基于数据流建模方法：是结构化分析的主要方法
     一种自顶向下逐步求精的分析方法，是根据数据流关系分析需求的。
     主要技术：DFD（数据流图）：、DD（数据字典）、ERD（实体联系图）、系统流程图。。。
     DD（数据字典）包括数据项、数据流、数据文件。
  3. 基于UML建模方法：
     UML需求视图：用例图、顺序图、活动图。
  4. 功能列表方法

  敏捷项目需求分析

  1. 产品待办事项列表
  2. 代办事项列表的细化
  3. 用户故事
     敏捷项目主要是采用用户故事描述需求。
     用户故事常常写在卡片上，然后将其部署在板上。
     它不使用技术语言来描述。
     -（3） 需求规格编写：需求分析完成的标志是提交一份完整的软件需求规格说明书（SRS）。

• （4）需求规格说明可以包括系统的运行环境。

• （5）需求验证：

• （6）需求变更：是软件项目的一个突出特点，可以导致软件项目的蔓延。

第二篇：项目计划 第四章：软件项目范围计划——任务分解

一、任务分解定义

是将一个项目分解为更多工作细目或者子项目，是项目变得更小、更易管理、更易操作，可以提高估算成本、时间和资源的准确性。

• 任务分解是对需求的进一步细化，是最后确定项目所有任务范围的过程。
• 任务分解的结果是WBS。

1.任务分解结构 WBS（Work Breakdown Structure）

• 是分级的树形结构

• 不包括在WBS中的工作就不是该项目的工作。

• 项目范围、项目工期、项目规模（成本）是支持项目成功的三大支柱。范围、规模越小，成功率越高，但是我们不能只做小项目，所以任务分解就很重要。
  

• WBS中每一个具体细目通常指定唯一的编码（code of account），这对有效地控制整个项目地系统非常重要。
  

• WBS提供了项目范围基线。

（1）工作包：上图中的1.1.1、1.1.2等就是工作包。

• 是WBS最低层次的可交付成果，是WBS的最小单位。项目完成时，应该完成这些交付成果。
• 但最低层次的任务，不一定是分配到个人完成的工作。
• 工作包可以通过子项目的形式完成，分配给另一位项目经理进行计划和执行，这时工作包可以进一步分解为子项目的WBS和相应的活动。
• 工作包应该由唯一主体负责，可以分配给另外一位项目经理通过子项目的方式完成。

（2）任务分解的形式

• ①提纲式WBS
• ②组织结构图式WBS

（3）WBS字典

（4）任务分解过程

（5）任务分解方法

• 模板参照法
• 类比方法
• 自顶向下法
  1. 采用演绎推理方法，是从一般到特殊方向进行的。
  2. 如果WBS开发人员对项目比较熟悉或者对项目大局有把握，则可以使用自顶向下方法。
• 自底向上发
  1. 是从特殊到一般方向进行的。
  2. 若对于项目人员来说，这个项目是一个崭新的项目，则可以采用自底向上方法开发WBS。

2.任务分解结果

（1）任务分解结果的检验

检验标准：

• 明确并识别出项目地各主要组成部分，即明确项目的主要交付成果。
• 确定每个可交付成果地详细程度是否已经达到了足以编制恰当地成本和历时估算。
  1. 最底层要素不能出现重复现象
• 确定可交付成果的组成元素
  1. 组成元素应当用切实的、可验证的结果来描述，以便于进行绩效测量。
  2. 切实、可验证的结果既可包括产品，又可包括服务。
• 核实分解的正确性：
  1. 最底层的要素是否是实现目标的充分必要条件。
  2. 每项定义是否清晰完整。
  3. 没想是否都能恰当地编制进度和预算。
• 与相关人员对WBS结果进行评审。
  1. 分层次少于7层。
  2. 最底层要素是否有清晰完整的定义。

（2）任务分解的重要性

• WBS提供了项目范围基线，是范围变更的重要输入。
• WBS防止遗漏工作、为项目估算提供依据。
• WBS明确完成项目所需的工作。
• WBS建立时间观念。
• WBS提供一种控制手段。
• WBS是范围基线的重要组成部分。
• WBS可以及时提示是否变更。

3.敏捷项目的任务分解

（1）用户故事的分解过程

• Epic：史诗故事，可以进一步分解为一些用户故事。
• 敏捷项目的分解过程，就是将大型故事分解成用户故事

（2）敏捷分解检验

（3）敏捷分解结果