软件项目管理2-2【荐】.ppt

范围计划 核心三计划 范围计划 进度计划 成本计划 第2章 软件项目范围计划 项目计划活动的第一项计划活动就是估算：需要多长时间、需要多少工作量，以及需要多少人员。 项目管理过程中最重要也是最困难的方面之一是确定项目的范围，项目成果要素中很多是与范围相关的。 项目范围是指开发项目产品所包括的工作及产生这些产品所用的过程。这个过程规定了如何对项目范围进行定义、管理和控制。 2.1 关于软件需求 需求是一个软件项目的开端，也是项目建设的基石。有资料表明，软件项目中40％-60％的问题都是在需求分析阶段埋下的隐患。 软件开发中返工开销占开发总费用的40％，其中70％-80％的返工是由需求方面的错误所导致。 需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能，达到什么性能。 项目失败的原因分析 软件需求包括三个不同的层次：业务需求、用户需求、功能需求。最后确定软件规格，它们之间的规格如下图: 业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，它们在项目视图与范围文档中予以说明。 用户需求描述了用户通过使用本软件产品必须要完成的任务，一般是用户协助提供。 功能需求定义了开发人员必须实现的软件功能，使得用户通过使用次软件能完成他们的任务，从而满足了业务需求。 2.2 软件需求管理过程 需求管理过程是保证软件需求以一种形式描述一个产品应该具有的功能、性能等。 需求上出现问题很少是源于需求开发技术，更多的是软件人员对需求理解上的错误和忽略，源于需求工作的复杂性、细腻性以及任务的繁多。 有效的需求管理能获得多方面的好处，最大的好处是在开发后期和整个维护阶段的返工的工作量可以大大减少。Boehm发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个缺陷要多付出68倍的成本。近来很多研究表明这种缺陷导致成本放大因子可以高达200倍。 软件需求管理的过程 需求工程基本任务 2.2.1 需求获取 需求获取是通过与用户的交流，对现有系统的观测及对任务进行分析，从而开发、捕获和修订用户的需求。 需求获取的主要任务是和用户方的领导层、业务层人员的访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运作系统等等具体情况和客观的信息，建立良好的沟通渠道和方式。 需求获取需要执行的活动如下： ①了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围 ②对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。 ③需求分析人员对收集到的用户需求做进一步的分析和处理 ④需求分析人员将调研到的用户需求以适当的方式呈交给用户和开发方的相关人员。大家共同确认所提交的结果是否真实地反映了用户的意图。 2.2.2 需求分析 需求分析是为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多的捕获现实世界的语义 从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。 从系统开发的过程可知，系统需求分析时犯下的错误，会在接下来的阶段被成倍的放大，越是开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。 需求分析模型 需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型。如下图所示： 需求不明确是软件开发过程中经常遇到的问题，可以从以下几个方面处理需求不明问题： ①让用户参与开发 ②开发用户界面原型，以便用户确认需求 ③需求讨论会议 ④强化需求分析与评审 2.2.3 需求规格编写 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 软件需求规格说明的原则 从现实中分离功能，即描述要“做什么”而不是“怎样实现” 采用一定的规格说明语言 如果被开发软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中 规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩充 下面是一个可参考的软件需求规格模版： 1.导言 1.1目的 1.2背景 1.3缩写说明 1.4术语定义 1.5参考资料 1.6版本更新信息 2.系统概述 2.1系统定义 2.2应用环境 2.3假定和约束 3.需求规定 3.1对功能的规定 3.2对性能的规定 3.3输入输出的要求 3.4数据管理能力要求 3.5故障处理要求 3.6其他要求 4. 运行环境规定 4.