SRE06-需求管理.pptVIP

* * SRE07 -需求管理 一 有效的需求变更控制实践 1 需求变更概述 经验的问题 需求变更的出现主要是因为在项目早期，用户往往不能确切地定义自己需要什么。用户常常以为自己清楚，但实际上他们提出的需求只是依据当前的工作所需，而采用的新设备、新技术通常会改变他们的工作方式；或者要开发的系统对用户来说也是个未知数，他们以前没有过相关的使用经验。 需求变更概述 意识的问题： 随着开发工作的不断进展，系统开始展现功能的雏形，用户对系统的了解也逐步深入。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不可避免地一次又一次出现。 需求变更概述 管理的问题 如果开发团队缺少明确的需求变更控制过程或采用的变更控制机制无效，抑或不按变更控制流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。当然，即使按照需求变更控制流程进行管理，由于受进度、成本等因素的制约，软件质量还是会受到不同程度的影响。但实施严格的软件需求管理会最大限度地控制需求变更给软件质量造成的负面影响，这也正是我们进行需求变更管理的目的所在。  2 需求变更管理的最大问题 知道需要做需求变更管理 不知道如何更有效的执行变更控制操作 受CMMI误导，强调文档，走向维护变更数据之路 形成“重记录、轻控制”的不良现象 掌握变更管理的核心要旨： 需求变更控制一般要经过“变更申请、变更评估、决策、实施、验证”这五大步骤。 3 解决问题 变更申请 需求方 开发方 忽略 选择变更方式 SCCB评估 项目经理自行决定 根据评估结果 拒绝 接受本次修改 下个版本再修改 修改合同相关信息 修改相关需求 修改相应的项目计划 需求变更管理实例 解决问题 经验一：相互协作 很难想像遭到用户抵制的项目能够成功。 在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。 即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。 解决问题 经验二：充分交流 需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。 “希尔顿酒店案例”，不能停工的原因，地价影响之谜 解决问题 经验三：安排专职人员负责需求变更管理 有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 解决问题 经验四：合同约束 需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。 诸如“诸如，需求发布后，变更本着双方友好协商的原则，确定协商流程” 解决问题 经验五：区别对待的原则 学会识别变更的类型、层次 目标层变更 功能层变更 操作层变更 随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大、对项目进度有重大影响的需求。 遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。 如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 解决问题 经验六：选用适当的开发模型 采用建立原型的开发模型比较适合需求不明确的开发项目。 开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。 一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。 这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。 目前业界较为流行的迭代式开发方法对工期紧迫的项目的需求变更控制很有成效。 解决问题 经验六：加强前期的用户参与力度 诸如，用户参与需求评审 。作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。 4 需求变更管理：核心思想 变更管理是目标是控制变更，而非避免变更 控制变更的目标是减少变更的影响，而达成这一目标需要由所有团队协作 需求团队的贡献在于“尽早标识变更”，设计团队的贡献在于“尽可能以弹性的设计来减少变更的影响” 建立统