需求变更对软件开发的影响-read.pptVIP

第二讲 需求管理 3 定义软件开发过程的步骤 （1）确定软件模型 （2）确定活动 （3）确定活动间的关系 （4）文档化每个活动的其他有用信息 （5）文档化剪裁过程 （6）文档化改善过程 （7）获得过程的认可 （8）不断使用和改善过程 3.1 确定软件模型 编码修复模型 瀑布模型 增量模型 迭代模型 3.2 确定活动 3.3 确定活动间的关系 3.4 活动的有用信息文档化 3.5 剪裁过程文档化 3.6 改善过程文档化 3.7 过程获得认可并培训员工 3.8 不断使用和改善过程 六、需求管理 需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与工作成果的一致性，并控制需求的变更。 包括：需求确认 需求变更控制 需求跟踪 1、需求确认 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合同效果。 需求确认步骤： （1）非正式需求评审 项目经理先在项目内部组织人员进行非正式的需求评审，消除明显的错误和分歧。 （2）正式需求评审 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审需求文档，尽最大努力使需求文档能够正确无误地反映用户的意愿。 （3）获取需求承诺 通过正式评审后，开发方负责人（项目经理）和客户对需求文档做书面承诺，使之具有商业合同效果。 例如： 本需求文档建立在双方对需求的共同理解基础上，我同意后续的开发工作根据该需求文档开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白，需求的变更将导致双方重新协商成本、资源和进度等。 甲方负责人签字 乙方负责人签字 需求跟踪归纳如下： 1、建立和维护需求跟踪矩阵 正向跟踪 逆向跟踪 当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵 2、查找不一致 后续工作成果没有实现需求文档中的某些需求 后续工作成果实现了需求文档中不存在的需求 后续工作成果没有正确实现需求文档中的需求 3、消除不一致 将消除不一致记录到“需求跟踪报告” 消除不一致后，项目经理更新“需求跟踪矩阵” 某公司需求管理文档及模板介绍 讨论： 描述软件需求的三个层次。 描述软件非功能需求。 CMM2中分配需求含义是什么？ 需求管理包括哪些内容？ 结合实际谈为什么要进行需求管理？ 2、需求变更控制 什么是需求变更？ 初始需求 变更的需求 对问题的 初始理解 对问题的 新理解 时间 图8 需求的变更 需求变更原因分析 单纯的用户因素 市场形势变化 系统因素 工作环境和要求变化 需求开发的缺陷 ★ 需求分析、定义和评审不充分 ★ 与用户沟通不畅 需求变更对软件开发的影响 ⑴ 使变更前开发工作和成果失效 ⑵ 返工成为被迫采取的对策 ⑶ 工作量及资源投入的增加使开发成本提高 ⑷ 项目完成时间后延 需求变更失控可能导致的后果 ⑴ 未受控的需求 变更引起需求 和实现不一致 需求文档V1 系统实现 V1 系统实现 V2 需求变更 ⑵ 受控的需求 变更使需求和实现一致 图7 未受控及受控的需求变更 需求文档V1 需求文档V2 系统实现 V1 系统实现 V2 需求变更 降低需求变更风险的策略 ⑴ 与用户充分沟通 ★与用户共同明确确定的需求的意义 项目开发工作 项目开发组织 用户 * 产品后续开发工作的基础 * 产品维护工作的重要参考 * 对用户的承诺 * 关系到项目开发工作的投入、交付期和产品质量 * 关系到能否如期获得所需的产品 * 作为合同的附件，关系到双方的权益 * 是产品验收的依据 ★向用户说明需求不确切或频繁变更对开发工作的冲击 ★使用户理解过多变更最终对用户不利 ⑵ 与用户共同确定需求，作为合同附件， 签字生效 ⑶ 合同中含有对需求变更的条款 ⑷ 采用原型方法开发，或螺旋模型开发 ⑸ 项目计划中适当留有余地（时间进度、人力投入、 费用等） ⑹ 严格实施变更控制 需求变更控制要求 变更控制的策略 （1）所有需求变更必须遵循需求变更控制规程实施变更。 （2）需求变更提出后是否被接受，应由专门的组织―变 更控制委员会（CCB－Change Control Board）审查决定。 （3）不得以任何理由删除和修改需求变更的原始文件。 （4）应将已接受的需求变更通知到所有相关人员。 （5）已接受的需求变更应能追溯到批准的变更请求。 （6）对项目的需求赋予状态属性，以利于需求变更的控制。