第8章_软件项目需求与变更管理

CasanovaCasanova第1/48页软件项目需求管理概述1软件项目任务分解2第8章软件项目需求与变更管理3软件需求的变更控制CasanovaCasanova第2页学习目标掌握软件需求的概念熟悉需求管理的方法与过程掌握任务分解的方法与步骤WBS了解需求变更的原因掌握需求变更控制的策略第7章项目招投标与合同管理CasanovaCasanova第3页HotTip一.软件需求定义需求是来源于用户调查，即客户的需要。需求分析是指软件分析人员通过研究用户在软件问题上的需求意愿，分析出软件系统的功能、性能、数据等诸方面应该达到的目标，从而获得有关软件的需求规格定义的过程。8.1软件项目需求管理概述CasanovaCasanova第4页HotTip一.软件需求定义1．用户需求特点：（1）用户需求直接来源于用户（2）用户需求需要以文档的形式提供给用户审查（3）可以把用户需求理解为用户对软件的合理请求（4）用户需求主要是为用户方的管理层、用户方的技术代表、操作者以及开发方的高层技术人员撰写的？p1238.1软件项目需求管理概述CasanovaCasanova第5页HotTip2．系统需求（1）功能需求全面性一致性可理解可维护可追踪等8.1软件项目需求管理概述（2）非功能性需求性能需求、可靠性、可用性需求、系统安全以及系统对开发过程、时间、资源等方面的约束和标准关心系统的整体特性（3）数据要求CasanovaCasanova业务需求用户需求系统需求功能需求质量属性其他非功能需求约束条件项目视图与范围文档使用实例文档软件需求规格说明用户能有效的纠正文档中的拼写错误找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。•找到并高亮度提示错词；•显示提供替换词的对话框以及实现整个文档范围的替换。需求组成CasanovaCasanova业务需求：组织机构/客户对软件的高层次目标用户需求：用户对软件的要求功能需求：软件做什么，如何做如小型超市商品查询:业务需求：保证及时进货；……用户需求:查询商品的价格，库存，销售及盈利功能需求：怎样查询/短信缺货提示，提供哪些信息CasanovaCasanova第8页HotTip3．需求规格说明书的写作规范1）清晰2）完整3）一致4）可测试8.1软件项目需求管理概述CasanovaCasanova需求管理活动CasanovaCasanova需求工程需求开发需求管理问题获取分析编写规格说明验证变更控制版本控制需求跟踪需求状态跟踪业务需求用户需求功能需求需求过程所涉及的工作CasanovaCasanova软件项目需求管理的重要性13%12%50%6%7%12%其它过少的用户输入不完整的需求需求变更技术缺乏人力缺乏影响软件项目成败的因素（1/3）CasanovaCasanova软件缺陷修复的成本CasanovaCasanova第13页HotTip二．需求管理1．需求管理复杂性分析需求的描述问题需求的完备程度问题需求开发的工期问题需求的细致程度问题需求的变化问题8.1软件项目需求管理概述CasanovaCasanova第14页HotTip二．需求管理2．需求管理的基本原则需求管理必须与需求工程的其它活动紧密整合需求必须是文档化的、正确的、最新的、可管理的、可理解的只要需求变化了，需求变更的影响就必须被评估需求必须分优先级需求一定要分类管理8.1软件项目需求管理概述CasanovaCasanova第15页HotTip3．需求管理的方法确定需求变更控制过程进行需求变更影响分析建立需求基准版本和需求控制版本文档维护需求变更的历史记录跟踪每项需求的状态衡量需求稳定性8.1软件项目需求管理概述CasanovaCasanova第16页HotTip三．需求管理过程1．定义需求2．需求确认3．建立需求状态4．需求评审评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。8.1软件项目需求管理概述CasanovaCasanova第17页HotTip三．需求管理过程5．需求承诺(签字生效）6．需求跟踪正向跟踪：以用户需求为切入点，检查《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。7．需求变更控制8.1软件项目需求管理概述CasanovaCasanovaCasanovaCasanova–确定需求变更控制过程–建立需求变更控制委员会–进行需求变更影响分析–建立需求基准版本和需求控制版本文档–维护需求变更的历史记录–跟踪每项需求的状态–跟踪所有受需求变更影响的工作产品–衡量需求稳定性（尽量避免、减少变化）需求变更管理活动：CasanovaCasanova第20/48页HotTip一．工作分解结构项目的分解结构就是将项目的产品或服务、组织、过程这3种不同的结构综合为项目分解结构的过程，也就是给项目的组织人员分派各自角色和任务的过程。基于成果/功能的分解方法，以完成该项目应该交付的成果为导向，确定相关的任务、工作、活动和要素基于流程的分解方法，以完成该项目所应经历的流程为导向，确定相关的任务、工作、活动和要素。8.2软件项目任务分解CasanovaCasanova8.2软件项目任务分解项目分解目的——明确项目所包含的各项工作；项目分解的结果就是WBS（任务分解结构）图项目分解意义——WBS（任务分解结构）图是实施项目、创造最终产品或服务所必须进行的全部活动的一张清单，也是进度计划、人员分配、预算计划的基础项目分解内容——项目分解就是先把复杂的项目逐步分解成一层一层的要素（工作），直到具体明确为止项目分解工具——项目分解的工具是工作分解结构ＷＢＳ原理，它是一个分级的树型结构，是一个对项目工作由粗到细的分解过程CasanovaCasanova软件项目分解WBS——WorkBreakdownStructure主要是将一个项目分解成易于管理的几个部分或几个细目，以便确保找出完成项目工作范围所需的所有工作要素它是一种在项目全范围内分解和定义各层次工作包的方法WBS——WorkBreakdownStructure结构层次越往下层则项目组成部分的定义越详细，WBS最后构成一份层次清晰，可以具体作为组织项目实施的工作依据WBS——WorkBreakdownStructure通常是一种面向“成果”的“树”，其最底层是细化后的“可交付成果”，该树组织确定了项目的整个范围。但WBS的形式并不限于“树”状，还有多种形式。CasanovaCasanova软件项目分解WBS分解类型基于可交付成果的划分上层一般为可交付成果为导向下层一般为可交付成果的工作内容基于工作过程的划分上层按照工作的流程分解下层按照工作的内容划分8.2软件项目任务分解CasanovaCasanova软件项目分解基于可交付成果的划分——WBS举例:信息网络工程信息网络工程结构化布线网络平台建设布线设计采购布线验收方案设计采购网络平台实施验收0级1级2级CasanovaCasanova软件项目分解基于工作过程的划分——WBS举例:网络系统工程网络系统培训设备准备设备采购设备验收交接网络系统设计布线设计平台设计工程实施布线实施网络集成软件开发软件需求确定系统设计编码测试0级1级2级CasanovaCasanova第26页HotTip一．工作分解结构（1）图表形式分解层次与结构8.2软件项目任务分解CasanovaCasanova软件项目分解项目工作分解结构表项目名称：项目负责人：单位名称：制表日期：工作分解结构任务编码任务名称主要活动描述负责人1000110012001x001x101x111x12项目负责人审核意见：签名：日期：CasanovaCasanova第28页HotTip工作包是完成一项具体工作所要求的一个特定的、可确定的、可交付以及独立的工作包，可为项目控制提供充分而合适的管理信息。（树叶）WBS编码设计（编号=》层次）8.2软件项目任务分解CasanovaCasanova用PROJECT生成的WBS例CasanovaCasanova第30页HotTip（2）清单形式①需求分析计划②流程优化③编写需求说明书•编写需求规格词汇表•绘制业务流程•抽象业务类•建立数据模型•将需求分析图示加入规格文档④需求规格测试⑤需求规格确认8.2软件项目任务分解CasanovaCasanova第31页HotTip一．任务分解过程1．分解步骤（1）确认并分解项目的主要组成要素。（2）确定分解标准（3）确认分解是否详细，分解结果是否可以作为费用和时间估计的标准，明确责任。（4）确定项目交付成果。（5）验证分解正确性，验证分解正确性后，建立一套编号系统。8.2软件项目任务分解CasanovaCasanova第32页HotTip一．任务分解过程2．分解的标准:一般不能采用双重标准。选择一种项目分解标准之后，在分解过程中应该统一使用此标准，避免因使用不同标准而导致的混乱。3．分解结果的检验核实分解的正确性：更低层次的细目是否必要和充分？最底层要素是否有重复？每个细目都有明确的、完整的定义吗？是否每个细目可以进行适当的估算？谁能担负起完成这个任务？8.2软件项目任务分解CasanovaCasanova第33页HotTip4．任务分解的注意事项注意收集与项目相关的所有信息。任务分解结果必须有利于责任分配。最底层的工作包一般要有全面、详细和明确的文字说明，并汇集编制成项目工作分解结构词典。避免不必要的过细，最好不要超过7层。按照软件项目的平均规模来说，推荐任务分解时至少分解到一周的工作量（40小时）。8.2软件项目任务分解CasanovaCasanova第34页HotTip5．责任分配及成本分解8.2软件项目任务分解WBS编号预算（￥/人天）责任者WBS编号预算责任者10.1张明3.30.15李立20.46李立3.40.1李立30.46张明、李立3.50.02张明3.10.04张明40.08万风3.20.15李立50.1张明CasanovaCasanovaWBS的要素WBS的每一个工作单元都是一个具体任务，它包括五个方面的要素：1．工作过程或内容：表明工作的性质或对工作的描述。2．人物的承担者：明确责任者，多人承担时应明确个人的职责分工。3．工作对象：工作对象不仅仅是物质的，也可能是非物质的。4．完成任务时间（工时）/工作量：估计完成任务所需时间。5．完成任务所需资源：执行任务所需空间，设备，人员，环境，资金等。CasanovaCasanova第36/48页HotTip一．需求变更原因分析1．范围没有圈定就开始细化2．没有良好的软件结构适应变化3．用户改变需求二．管理变更请求1．控制需求渐变的策略需求一定要与投入有显示的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。软件开发方和出资方都要明确这一条：需求变化，软件开发的投入也要变化。8.3软件需求的变更控制CasanovaCasanova第37页HotTip需求的变更要经过出资者的认可,这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。小的需求变更也要经过正规的需求管理流程，否则会积少成多。精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求细化了，它就不会变化了。8.3软件需求的变更控制CasanovaCasanova第38页HotTip2．变更控制过程（1）项目启动阶段的变更预防（2）项目实施阶段的变更控制（3）项目收尾阶段的总结控制8.3软件需求的变更控制CasanovaCasanova第39页HotTip三．需求变更处理流程8.3软件需求的变更控制CasanovaCasanova状态跟踪示例第40/48页