第二篇学时软件项目范围计划第三章分之精要.ppt

范围计划 核心三计划 范围计划 进度计划 成本计划 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、任务分解的方法 六、案例分析 软件需求 需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。 软件需求的层次 业务需求：反映了组织机构或客户对系统、产品高层次的目标要求； 用户需求：描述了用户通过使用本软件产品必须要完成的任务； 功能需求：定义了开发人员必须实现的软件功能，使用户通过使用本软件能完成他们的任务，从而满足业务需求。 软件需求规格：描述产品必须遵从的标准、规范和合约；外部界面的具体细节；非功能性需求；设计或实现的约束条件及质量属性。 软件需求的类型 功能需求:描述系统所应提供的功能和服务。 非功能需求: 领域需求:来源不是系统的用户,而是系统应 用的领域,反映了该领域的特点, 领域需求可能是功能需求,也可能 是非功能需求,其确定需要领域知 识。 需求管理的重要性 项目失败的原因分析 软件需求管理的过程 需求工程基本任务 需求获取 需求分析定义 需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述。 需求分析模型 需求规格 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 软件需求规格说明的原则 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的规格说明语言 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充 规格文档参考 引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证 需求验证 需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？ 最后的签字 需求总在变化 需求变更管理 确定需求变更控制过程 建立变更控制委员会(SCCB) 进行需求变更影响分析 跟踪所有受需求变更影响的工作产品 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性 需求变更管理 管理和控制需求基线的过程 需求变更控制系统 　一个正式的文档，说明如何控制需求变更 　　建立变更审批系统 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、任务分解的方法 六、案例分析 WBS (Work Breakdown Structure) 任务分解的过程 将一个项目分解为更多的工作细目或者子项目，使项目变得更小、更易管理、更易操作。 任务分解的结果 WBS（任务分解结构）。 WBS 面向可交付成果的。 Work packages（工作包） WBS的最低层次的可交付成果 WBS实例 PMI（项目管理协会）defines WBS 是面向可交付成果的对项目元素的分组，它组织并定义了整个项目范围，不在WBS中包括的工作就不是该项目的工作。 它是一个分级的树型结构，是对项目由粗到细的分解过程。工作结构每细分一个层次表示对项目元素更细致的描述。 PMI defines Work packages WBS的最低层次的可交付成果。 工作包应当由唯一主体负责。 这一交付成果可以分配给另外一位项目经理进行计划和执行,或者通过子项目的方式完成。 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务分解的过程 五、任务分解的方法 六、案例分析 类型 清单 图表 图表类型 清单类型 ?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????????? 在程序的头部增加修改纪录 本章要点 一、软件需求管理过程 二、任务分解定义 三、任务分解的类型 四、任务