软件项目管理课程_9

《软件项目管理课程_9》由会员分享，可在线阅读，更多相关《软件项目管理课程_9（88页珍藏版）》请在金锄头文库上搜索。

1、软件项目管理,软件项目需求管理概述,1,软件项目任务分解,第8章 软件项目需求与变更管理,软件需求的变更控制,学习目标 掌握软件需求的概念 熟悉需求管理的方法与过程 掌握任务分解的方法与步骤 掌握需求确认、变更控制和需求跟踪的方法和过程,第8章 软件项目需求与变更管理,Hot Tip,软件需求定义 需求是来源于用户调查，即客户的需要。 需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿，分析出软件系统的功能、性能、数据等诸方面应该达到的目标，从而获得有关软件的需求规格定义的过程。,8 .1 软件项目需求管理概述,Hot Tip,软件需求定义 1用户需求 特点： （1）用户需求直接来源于

2、用户 （2）用户需求需要以文档的形式提供给用户审查 （3）可以把用户需求理解为用户对软件的合理请求 （4）用户需求主要是为用户方的管理层、用户方的技术代表、操作者以及开发方的高层技术人员撰写的,8 .1 软件项目需求管理概述,Hot Tip,2系统需求 （1）功能需求 全面性 一致性 可理解 可维护 可追踪等,8 .1 软件项目需求管理概述,（2）非功能性需求 性能需求、可靠性、可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准 关心系统的整体特性 （3）数据要求,Hot Tip,3需求规格说明书的写作规范 1）清晰 2）完整 3）一致 4）可测试,8 .1 软件项目需求管理

3、概述,需求的重要性,需求是业务的根源，需求工作的优劣对业务影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,8 .1 软件项目需求管理概述,需求是缺陷主要来源,错误定位费用分析,James Martin： 超过50%的缺陷由不完善的、不正确的、不准确的和/或不明确的需求所引起,James Martin： 80%以上的用于定位业务错误的费用是基于业务系统需求定义的错误,8 .1 软件项目需求管理概述,一个小故事,如何练就需求分析的火眼金晴？,5W + 1H + 8C 5W就是 Who、When、Where、What、Why Why是关键 1H就是 How 需求本身的流程 8C

4、指的是8个约束和限制，即8个Constraints： 包括性能Performance、成本Cost、时间Time、可靠性Reliability、安全性Security、合规性Compliance、技术性Technology、兼容性Compatibility DFX-Design for X 面向产品生命周期各环节的设计。DFC、DFS,明确的需求是项目的基础1,需求的生命周期： 需求产生（变化、内部、外部） 需求认识（现存、潜在、超前、前景分析） 需求表达： 1、让提出需求的人尽可能清楚地说明他们的需求； 2、对需求提出一系列问题：,明确的需求是项目的基础,明确的需求是项目的基础2,？提出需求

5、的人是如何描述需求的 ？需求真实吗，是真正需求还是表面现象 ？我们能满足这个需求吗，其他人能满足吗，是不是真的有解决方法 ？需求重要吗，值得去满足他吗 ？满足需求的关键问题在那里，会不会有新的需求产生，还要进一步满足其他需求吗，新的需求能取代目前这个需求吗 ？需求直接涉及什么人，他们认为这是一个必要的需求吗，满族足需求后对他们有什么影响，他们的反映会怎么样 ？需求对机构的影响是什么，对我的影响是什么,明确的需求是项目的基础,明确的需求是项目的基础3,3、作一些必要的研究工作，更好地理解需求 4、根据以上三步得出结论，尽可能清楚地描述这个需求 5、听听用户对你的阐述的反映，并作适当修改。 功能和

6、技术要求 1、把需求变成功能要求； 2、功能要求应描述项目最终交付产品的特征 3、技术要求根据功能要求产生 4、功能要求应用日常语言陈述清楚,明确的需求是项目的基础,定义需求时的问题1,含糊的需求： 1、不断变化的需求（人员变化、预算变化、技术变化、商业环境变化） 2、误解需求（我说不清楚我所需要的是什么，但我见到东西时就会知道感觉会随环境变化） 过早作出结论（截断需要表达过程需求分析需要耐心和自我控制） 与真正的用户讨论需求,定义需求时的问题,定义需求时的问题2,多种用户，多种需求（确定优先级，即需求层次） 曲解用户的需求 需求镀金 对用户的需求有选择的过滤 包办代替,定义需求时的问题,需求

7、和目标,基本需求: 项目实施范围、质量要求、 利润或成本目标、时间目标以及必须满 足的法规要求等 期望要求: 如一种新产品性能之外的外形、使用舒适,Hot Tip,需求管理 1需求管理复杂性分析 需求的描述问题 需求的完备程度问题 需求开发的工期问题 需求的细致程度问题 需求的变化问题,8 .1 软件项目需求管理概述,Hot Tip,需求管理 2需求管理的基本原则 需求管理必须与需求工程的其它活动紧密整合 需求必须是文档化的、正确的、最新的、可管理的、可理解的 只要需求变化了，需求变更的影响就必须被评估 需求必须分优先级 需求一定要分类管理,8 .1 软件项目需求管理概述,Hot Tip,3需

8、求管理的方法 确定需求变更控制过程 进行需求变更影响分析 建立需求基准版本和需求控制版本文档 维护需求变更的历史记录 跟踪每项需求的状态 衡量需求稳定性,8 .1 软件项目需求管理概述,Hot Tip,需求管理过程 1定义需求 2需求确认 3建立需求状态 4需求评审 评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。,8 .1 软件项目需求管理概述,Hot Tip,需求管理过程 5需求承诺 6需求跟踪 正向跟踪：以用户需求为切入点，检查需求规格说明书中的每个需求是否都能在后继工作产品中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工

9、作产品是否都能在需求规格说明书中找到出处。 7需求变更控制,8 .1 软件项目需求管理概述,需求分析在工程中的位置,三要点：需求确认、需求变更控制、需求跟踪,需求管理的三要点,需求管理的目的是在用户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。,需求工程贯穿开发全过程,Hot Tip,工作分解结构 项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也就是给项目的组织人员分派各自角色和任务的过程。 基于成果或功能的分解方法，以完成该项目应该交付的成果为导向，确定相关的任务、工作、活动和要素。 基于流程的分解方法，以完成该项

10、目所应经历的流程为导向，确定相关的任务、工作、活动和要素。,8 .2 软件项目任务分解,Hot Tip,工作分解结构 （1）图表形式 分解层次与结构,8 .2 软件项目任务分解,Hot Tip,工作包是完成一项具体工作所要求的一个特定的、可确定的、可交付以及独立的工作包，可为项目控制提供充分而合适的管理信息。 WBS编码设计,8 .2 软件项目任务分解,Hot Tip,（2）清单形式 需求分析计划 流程优化 编写需求说明书 编写需求规格词汇表 绘制业务流程 抽象业务类 建立数据模型 将需求分析图示加入规格文档 需求规格测试 需求规格确认,8 .2 软件项目任务分解,Hot Tip,任务分解过程

11、 1分解步骤 （1）确认并分解项目的主要组成要素。 （2）确定分解标准 （3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。 （4）确定项目交付成果。 （5）验证分解正确性，验证分解正确性后，建立一套编号系统。,8 .2 软件项目任务分解,Hot Tip,任务分解过程 2分解的标准:一般不能采用双重标准。选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱。 3分解结果的检验 核实分解的正确性： 更低层次的细目是否必要和充分？ 最底层要素是否有重复？ 每个细目都有明确的、完整的定义吗？ 是否每个细目可以进行适当的估算？谁能担负起完成这

12、个任务？,8 .2 软件项目任务分解,Hot Tip,4任务分解的注意事项 注意收集与项目相关的所有信息。 任务分解结果必须有利于责任分配。 最底层的工作包一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典。 避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量（40小时）。,8 .2 软件项目任务分解,Hot Tip,5责任分配及成本分解,8 .2 软件项目任务分解,Hot Tip,需求确认 需求确认是指开发方和用户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。,8 .3 软件需求的确认

13、、变更控制和跟踪,项目开发面临的实际问题,8 .3 软件需求的确认、变更控制和跟踪,需求确认,项目开发面临的实际问题,8 .3 软件需求的确认、变更控制和跟踪,需求确认,项目开发面临的实际问题,8 .3 软件需求的确认、变更控制和跟踪,需求确认,需求验证的目的和任务,需求确认的目的和任务 需求验证的目的就是要确保软件需求具有良好的特性（如完整性，正确性等）。 需求验证包含的活动 满足性（功能需求是否满足需要） 满意性（非功能需求是否满意）明确及含蓄的需求(失败)、(成功) 共识行（是否能共同理解）可行性（技术是否可行） 明晰性（信息是否存在含混性）,8 .3 软件需求的确认、变更控制和跟踪,需

14、求确认,需求确认的方法： 1、为需求进行正式评审 2、为需求写测试用例 3、用检查单识别常见问题 4、为需求设定优先级 5、最后：形成总体共识,8 .3 软件需求的确认、变更控制和跟踪,需求确认,1、为需求进行正式评审,1、为需求进行正式评审,8 .3 软件需求的确认、变更控制和跟踪,需求确认,需求评审做不好的后果：, 需求变更 需求不明确 需求不可测 需求不可实现 导致后续工作难于开展或经常出现变更 由于需求未能得到有效管理， 在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，项目延期。,8 .3 软件需求的确认、变更控制和跟踪,需求确认做不好

15、的后果,如何进行需求评审,1、为需求进行正式评审 如何进行需求评审 参与需求分析和评审的人员的管理 软件需求文档的管理 需求分析过程的管理 需求变更的管理,8 .3 软件需求的确认、变更控制和跟踪,例1：“产品应在不少于每秒的正常周期内提供状态信息。” 分析：这个需求是不完整的： 状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。,8 .3 软件需求的确认、变更控制和跟踪,例1需求

16、： 后台任务管理器因以误差上下不超过10秒的秒间隔，在用户界面的指定位置显示状态信息； 如果后台进程处理正常，那么应该显示任务已完成的百分数/比； 任务完成时，应显示相关的信息； 后台任务出错应该显示错误信息； 为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。,8 .3 软件需求的确认、变更控制和跟踪,例2：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换” 计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。,8 .3 软件需求的确认、变更控制和跟踪,例2需求： 用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。 现在就很清楚，不