软件项目管理第第4章软件需求课题.ppt

进行需求获取应注意的问题 识别真正的客户 正确理解客户的需求 具备较强的忍耐力和清晰的思维 说明和教育客户 控制需求渐变的策略 变更控制过程 需求变更处理流程 提出变更 变更评估 实施变更 需求变更管理原则 （1） 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。 （2） 制订简单、有效的变更控制流程，并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时，这个流程具有一定的普遍性，对以后的项目开发和其他项目都有借鉴作用。 （3） 成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。 （4） 需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。 （5） 需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。 （6） 妥善保存变更产生的相关文档。 需求变更应对之道 ?相互协作——很难想像遭到用户抵制的项目能够成功。在讨论需求时，开发人员与用户应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了在开发人员看来过分的要求，也应该仔细分析原因，积极提出可行的替代方案。 ?充分交流——需求变更管理的过程很大程度上就是用户与开发人员的交流过程。软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。 需求变更应对之道 ?安排专职人员负责需求变更管理——有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。 ?合同约束——需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。 需求变更应对之道 ? ?区别对待——随着开发进展，有些用户会不断提出一些在项目组看来确实无法实现或工作量比较大，对项目进度有重大影响的需求。遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求(虽然用户认为是细化需求，但实际上是增加了工作量的新需求)，会使项目不能按时完成。如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。同时，还要注意控制新需求提出的频率。 需求变更应对之道 ?选用适当的开发模型——采用建立原型的开发模型比较适合需求不明确的开发项目。开发人员先根据用户对需求的说明建立一个系统原型，再与用户沟通。一般用户看到一些实际的东西后，对需求会有更为详细的解释，开发人员可根据用户的说明进一步完善系统原型。这个过程重复几次后，系统原型逐渐向最终的用户需求靠拢，从根本上减少需求变更的出现。目前业界较为流行的叠代式开发方法对工期紧迫的项目的需求变更控制很有成效。 需求变更应对之道 ?用户参与需求评审——作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出许多有价值的意见。同时，这也是由用户对需求进行最后确认的机会，可以有效减少需求变更的发生。 案例分析 “School”项目的需求管理过程： 需求确认：原型法 需求变更： 变更控制系统 变更过程 Infosys公司常用的变更管理过程 （1）记录变更。 （2）分析变更对工作产品的影响。 （3）估计变更申请所需的工作量。 （4）重新估计交付时间表。 （5）执行累积的成本影响分析。 （6）如果影响超出一定限度，则与高级主管一起评审影响。 （7）客户不再提出变更申请。 （8）修改工作产品。 变更申请日记 护一个变更申请日记，以跟踪变更申请。 日志中的每条记录包含一个变更申请号、关于变更的简单描述、变更的影响、变更申请的状态以及关键日期。 在评估变更申请的影响时，必须执行影响分析。 影响分析涉及标识出需要进行变更的工作产品，并估算对每种产品的变更量；通过重新查看风险管理计划，重新评估项目风险；评估需求变更蕴涵的总的工作量和进度估计的变化。 客户对分析结果进行评审，并做出答复。 变更申请一般作为需求规格说明文档的附件。有时还要修改文档的有关部分以反映所做的变更。 监督已认可的变更申请并保证它们正确实现，这部分由配置管理过程处理。 变更的累积影响 需求变更的一种危险是：尽管每种变