IT 项目管理

1. IT项目管理 首都经济贸易大学 信息学院 www.cueb.edu.cn

2. 2 3 第8章 软件项目需求与变更管理 1 软件项目需求管理概述 软件项目任务分解 软件需求的变更控制 第2页

3. 第7章 项目招投标与合同管理 • 学习目标 • 掌握软件需求的概念 • 熟悉需求管理的方法与过程 • 掌握任务分解的方法与步骤 • 了解需求变更的原因 • 掌握需求变更控制的策略 第3页

4. 8 .1 软件项目需求管理概述 • 软件需求定义 • 需求是来源于用户调查，即客户的需要。 • 需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿，分析出软件系统的功能、性能、数据等诸方面应该达到的目标，从而获得有关软件的需求规格定义的过程。 Hot Tip 第4页

5. 明确的需求是项目的基础 需求的生命周期： • 需求产生（变化、内部、外部） • 需求认识（现存、潜在、超前、前景分析） • 需求表达： 1、让提出需求的人尽可能清楚地说明他们的需求； 2、对需求提出一系列问题： 明确的需求是项目的基础1 第5页

6. 明确的需求是项目的基础 ？提出需求的人是如何描述需求的 ？需求真实吗，是真正需求还是表面现象 ？我们能满足这个需求吗，其他人能满足吗，是不是真的有解决方法 ？需求重要吗，值得去满足他吗 ？满足需求的关键问题在那里，会不会有新的需求产生，还要进一步满足其他需求吗，新的需求能取代目前这个需求吗 ？需求直接涉及什么人，他们认为这是一个必要的需求吗，满族足需求后对他们有什么影响，他们的反映会怎么样 ？需求对机构的影响是什么，对我的影响是什么 明确的需求是项目的基础2 第6页

7. 明确的需求是项目的基础 3、作一些必要的研究工作，更好地理解需求 4、根据以上三步得出结论，尽可能清楚地描述这个需求 5、听听用户对你的阐述的反映，并作适当修改。 • 功能和技术要求 1、把需求变成功能要求； 2、功能要求应描述项目最终交付产品的特征 3、技术要求根据功能要求产生 4、功能要求应用日常语言陈述清楚 明确的需求是项目的基础3 第7页

8. 定义需求时的问题 • 含糊的需求： 1、不断变化的需求（人员变化、预算变化、技术变化、商业环境变化） 2、误解需求（我说不清楚我所需要的是什么，但我见到东西时就会知道—感觉会随环境变化） • 过早作出结论（截断需要表达过程——需求分析需要耐心和自我控制） • 与真正的用户讨论需求 定义需求时的问题1 第8页

9. 定义需求时的问题 • 多种用户，多种需求（确定优先级，即需求层次） • 曲解用户的需求 • 需求镀金 • 对用户的需求有选择的过滤 • 包办代替 定义需求时的问题2 第9页

10. 需求和目标 基本需求: 项目实施范围、质量要求、 利润或成本目标、时间目标以及必须满 足的法规要求等 期望要求: 如一种新产品性能之外的外形、使用舒适 第10页

11. 8 .1 软件项目需求管理概述 • 软件需求定义 • 1．用户需求 • 特点： • （1）用户需求直接来源于用户 • （2）用户需求需要以文档的形式提供给用户审查 • （3）可以把用户需求理解为用户对软件的合理请求 • （4）用户需求主要是为用户方的管理层、用户方的技术代表、操作者以及开发方的高层技术人员撰写的 Hot Tip 第11页

12. 8 .1 软件项目需求管理概述 • 2．系统需求 • （1）功能需求 • 全面性 • 一致性 • 可理解 • 可维护 • 可追踪等 Hot Tip • （2）非功能性需求 • 性能需求、可靠性、可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准 • 关心系统的整体特性 （3）数据要求 第12页

13. 8 .1 软件项目需求管理概述 3．需求规格说明书的写作规范 1）清晰 2）完整 3）一致 4）可测试 Hot Tip 第13页

14. 8 .1 软件项目需求管理概述 • 需求管理 • 1．需求管理复杂性分析 • 需求的描述问题 • 需求的完备程度问题 • 需求开发的工期问题 • 需求的细致程度问题 • 需求的变化问题 Hot Tip 第14页

15. 8 .1 软件项目需求管理概述 • 需求管理 • 2．需求管理的基本原则 • 需求管理必须与需求工程的其它活动紧密整合 • 需求必须是文档化的、正确的、最新的、可管理的、可理解的 • 只要需求变化了，需求变更的影响就必须被评估 • 需求必须分优先级 • 需求一定要分类管理 Hot Tip 第15页

16. 8 .1 软件项目需求管理概述 • 3．需求管理的方法 • 确定需求变更控制过程 • 进行需求变更影响分析 • 建立需求基准版本和需求控制版本文档 • 维护需求变更的历史记录 • 跟踪每项需求的状态 • 衡量需求稳定性 Hot Tip 第16页

17. 8 .1 软件项目需求管理概述 • 需求管理过程 1．定义需求 2．需求确认 3．建立需求状态 4．需求评审 评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。 Hot Tip 第17页

18. 8 .1 软件项目需求管理概述 • 需求管理过程 5．需求承诺 6．需求跟踪 • 正向跟踪：以用户需求为切入点，检查《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。 • 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。 7．需求变更控制 Hot Tip 第18页

19. 8 .2 软件项目任务分解 • 工作分解结构 • 项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也就是给项目的组织人员分派各自角色和任务的过程。 • 基于成果或功能的分解方法，以完成该项目应该交付的成果为导向，确定相关的任务、工作、活动和要素。 • 基于流程的分解方法，以完成该项目所应经历的流程为导向，确定相关的任务、工作、活动和要素。 Hot Tip 第19页

20. 8 .2 软件项目任务分解 • 工作分解结构 （1）图表形式 • 分解层次与结构 Hot Tip 第20页

21. 8 .2 软件项目任务分解 工作包是完成一项具体工作所要求的一个特定的、可确定的、可交付以及独立的工作包，可为项目控制提供充分而合适的管理信息。 • WBS编码设计 Hot Tip 第21页

22. 8 .2 软件项目任务分解 （2）清单形式 • 需求分析计划 • 流程优化 • 编写需求说明书 • 编写需求规格词汇表 • 绘制业务流程 • 抽象业务类 • 建立数据模型 • 将需求分析图示加入规格文档 • 需求规格测试 • 需求规格确认 Hot Tip 第22页

23. 8 .2 软件项目任务分解 • 任务分解过程 1．分解步骤 • （1）确认并分解项目的主要组成要素。 • （2）确定分解标准 • （3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。 • （4）确定项目交付成果。 • （5）验证分解正确性，验证分解正确性后，建立一套编号系统。 Hot Tip 第23页

24. 8 .2 软件项目任务分解 • 任务分解过程 • 2．分解的标准:一般不能采用双重标准。选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱。 • 3．分解结果的检验 • 核实分解的正确性： • 更低层次的细目是否必要和充分？ • 最底层要素是否有重复？ • 每个细目都有明确的、完整的定义吗？ • 是否每个细目可以进行适当的估算？谁能担负起完成这个任务？ Hot Tip 第24页

25. 8 .2 软件项目任务分解 • 4．任务分解的注意事项 • 注意收集与项目相关的所有信息。 • 任务分解结果必须有利于责任分配。 • 最底层的工作包一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典。 • 避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量（40小时）。 Hot Tip 第25页

26. 8 .2 软件项目任务分解 5．责任分配及成本分解 Hot Tip 第26页

27. 8 .3 软件需求的变更控制 • 需求变更原因分析 • 1．范围没有圈定就开始细化 • 2．没有良好的软件结构适应变化 • 3．用户改变需求 • 管理变更请求 • 1．控制需求渐变的策略 • 需求一定要与投入有显示的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。所以，在项目的开始无论是软件开发方还是出资方都要明确这一条：需求变化，软件开发的投入也要变化。 Hot Tip 第27页

28. 8 .3 软件需求的变更控制 • 需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。 • 小的需求变更也要经过正规的需求管理流程，否则会积少成多。 • 精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求细化了，它就不会变化了。 Hot Tip 第28页

29. 8 .3 软件需求的变更控制 2．变更控制过程 （1）项目启动阶段的变更预防 （2）项目实施阶段的变更控制 （3）项目收尾阶段的总结控制 Hot Tip 第29页

30. 8 .3 软件需求的变更控制 需求变更处理流程 Hot Tip 第30页

31. 谢 谢！ Click to edit company slogan . Thank You !