软件需求管理部分完整版 PPT课件

1 需求开发面临的特殊难题 需求开发 是针对一个新软件或系统开发项目的情况 这种项目有时也称为零起点项目 green fieldproject 大多数组织的主要精力集中于维护现存的遗留系统 或者为已有的商业产品构建新的版本 其他组织也很少是从零开始构建一个新系统 而是对商用现货产品进行集成 定制和扩充 以满足自己的需要 2 开始捕获信息 缺少精确的需求文档 那么维护人员就必须进行逆向工程 通过代码来理解系统 将此看作是软件考古学 softwarearchaeology 构建一个包含当前系统部分的需求表示可达到以下3个有用的目标 消除知识鸿沟 使将来的维护人员能更好地理解所做的变更 收集当前系统的一些信息 当前系统在以前缺乏良好的书面文档 提供一个指标 表明当前的系统测试集对系统功能的覆盖率 3 定义质量需求 软件的质量属性和性能目标是选择解决方案时所要考虑的用户需求的另一个方面 我们至少要研究下面几个属性 性能易使用性灵活性互操作性完整性 4 尽早地而且要经常地设定优先级 客户和开发人员协同工作 共同选定功能实现的顺序 这样增量开发才会取得成功 开发团队的目标是 将可用的功能和对质量的改进有规律地交到用户手中 因此 开发人员必须了解每次增量开发计划实现哪些功能 5 设定需求优先级 每一个受资源限制的软件项目都必须对要求的产品功能定义相对优先级 设定优先级有助于项目经理解决冲突 安排阶段性交付 并且做出必要的取舍 讨论设定需求优先级的重要性 提出一个简单的优先级划分方案 并介绍更严格的基于价值 成本和风险的优先级分析方案 6 需求和进度安排 注意 不要迫于压力而许下自己明知道不可能做到的诺言 这是避免最后两败俱伤的秘诀 7 需求管理 8 需求管理的原则和实践 需求管理包括在项目开发过程中维护需求约定的完整性 准确性以及保持需求约定是最新约定的所有活动 如图所示 9 10 软件需求管理 需求管理所要完成的任务需求管理模型管理变更需求风险管理需求跟踪需求管理工具 11 需求管理所要完成的任务 需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识 需求模型实际是最终产品的抽象化表现 用户需求的满足程度是衡量设计优劣的标准 优秀的需求分析应当非常精确细致地对用户需求作出描述 同时也应该最大程度地给予方案设计者充分发挥的余地 对开发项目进行任务划分 将整体开发任务细化为多个子模块 从而使这些子模块能够平行开发而无需太多的干预 需求管理在开发周期中是自始至终存在的 需求管理必须始终保持更新 需求管理同项目管理是密不可分的 12 需求管理的任务 明确需求并达成共识 建立关联 根据不同需求设计相应解决办法 进行系统优化 提出设计方案 监控和解决可能出现的问题以及需要做出的改变 控制不同开发任务的开展 对最终产品做出评测 监控可能出现的重复开发 提出项目实施时间表 确定最终用户界面 13 里程碑与项目管理 一项需求的满足就意味着一块里程碑的确立 里程碑构造机制的基本方法之一就是进程管理 需求管理在开发周期中是自始至终存在的 需求管理必须始终保持更新 它构成了技术管理的基础 需求管理同项目管理是密不可分的 14 需求管理模型 不同的需求组合起来 构成了一套完整的需求模型 需求管理的一项重要工作就是在整个项目的不同任务之间建立联系 需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动 需求管理的关键过程领域 需求管理的步骤 15 需求管理的主要活动 控制对需求基线的变动 保持项目计划与需求一致 控制单个需求和需求文档的版本情况 管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系 跟踪基线中需求的状态 16 需求开发与需求管理的分界 中程在线信息产业培训网 17 需求基线管理 为何需要 频繁的需求变更会破坏开发的节奏 使整个项目开发的进度陷入混乱和失控的状态 而且会变成一个 救火队 式的工作 整天都在处理突发事件 主要思想 将所有现在的 将来的需求进行优先级评估 然后分解成为不同的组 每次迭代都选择其中优先级最高的部分进行开发 然后在迭代完成之前 开发工作不响应变更 这些划入的需求项就是需求基线的组成部分 18 需求基线管理 操作思路 我们应该在分析的基础上 将需求整合成为用例或功能项 然后对其进行优先级 依赖性进行综合性评估优先级判断 业务人员确定业务决定 技术人员确定技术决策 满意度 不满意度 模型依赖性是指对于某些功能 在实现上有必须的依赖关系 即当某些功能没有实现时 另外的功能无法开始 这就需要对其进行调整 19 需求变更管理 需求变更是一定存在的 而需求变更管理并不是指逃避它 更不是说要避免它 它实际上是希望控制变更在基线内的需求不响应变更 为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应 了解需求变更的关键意图 新产生的工作量 从而良好地进行重新计划 以便能够有效地解决其对整个开发带来的麻烦 20 对待软件项目管理的组织必须确保做到以下几点 在提交提议的需求变更之前要对其进行仔细的评估 请合适的人员就需求变更做出周全合理的业务决策 将已批准的变更传达给受此影响的所有人员 项目以一致的方式将需求变更包含进来 采用一致的变更控制方法 就可以避免相关问题 避免开发工作的返工和浪费时间等情况的发生 21 变更控制委员会 变更控制委员会 有时也称为配置控制委员会 configurationcontrolboard CCB 已被证实是软件开发领域公认的最佳实践 McConnell1996 CCB是由人组成的团体 可以由一个小组担任 也可以由多个不同的小组担任 这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现 CCB也决定所报告的缺陷中哪些需要纠正 什么时候纠正 CCB可以评审和批准对项目中任何基线工作产品所做的变更 项目需求文档只是其中的一个样例 22 CCB的组成 CCB的成员应该能代表需要参与制定决策的所有小组 当然这些决策制定只能是在CCB的权力范围之内 可考虑从下面这些部门中选择CCB代表 项目或程序管理部门产品管理或需求分析部门开发部门测试或质量保证部门 市场或客户代表编写用户文档的部门技术支持或帮助部门配置管理部门 23 CCB规章 CCB规章描述了CCB的目的 权力范围 成员构成 运作规程和决策的制定过程等 Sorensen1999 CCB的权力范围规定了哪些决策由CCB决定 哪些决策则必须上报给高一级CCB或者由管理层来决定 1 制定决策决策制定过程的描述应该确定 CCB成员或主要角色的人数 这是制定决策的法定人数 所采用的决策规则是投票 少数服从多数 协商决定或其他方法 24 CCB规章 CCB主席是否可以否决CCB的集体决策 级别高的CCB或其他人是否必须认可CCB做出的决策 2 交流状态CCB做出决策之后 应该指派专人对变更数据库中的变更请求状态进行更新 3 重新协商原先的约定在接受一个重大的需求变更之前 为了适应这一变更 需要同管理部门和客户重新协商原先的约定 Humphrey1997 协商的内容可能包括 要求推迟产品交付时间 要求增派人手 或者要求推迟实现尚未实现的优先级较低的需求等 25 变更需要付出代价 影响分析 对软件实施大的功能增强 则需要进行影响分析 impactanalysis 但是 即使是小的变更请求 也可能潜伏着难以预料的复杂性 影响分析是需求管理的一个关键方面 Arnold和Bohner1996 通过对影响进行分析 可以准确地理解提议的变更所涉及到的问题 有助于项目团队就批准哪些提议做出周全合理的业务决策 影响分析 通过对所提议的变更进行检查 确定可能必须创建 修改或废弃哪些部分 并估计与实现这些变更相关的工作量 26 影响分析的过程 影响分析有3个方面 1 理解进行变更可能涉及的问题 变更常常会产生大量的连锁反应 产品包括的功能太多会降低其性能 甚至会到令人难以接受的地步 2 确定如果团队将提议的变更包括到产品中 可能必须对哪些文件 模型和文档进行修改 3 确定实现变更所需执行的任务 并估计完成这些任务所需的工作量 注意 跳过影响分析并不能改变任务的规模 只会使规模令人感到惊奇 而软件方面令人惊奇却很少是好消息 27 影响分析报告模板 图是一个推荐的报告模板 表示对每个需求变更造成的潜在影响的分析结果 如果采用标准模板 CCB成员就可以轻松地找到他们所需的信息 作出合理的决策 28 需求的变化是永恒的 因而 对于需求变更应该正确对待 尽量将其负面影响降低 需求变更可能来自解决方案提供商 客户或产品供应商等外部因素 也可能来源于项目组内部 变更都是有代价的 应该评估一下变更的代价及其对项目的影响 在需求变更发生之前尽量减少需求变更 以将需求变更带来的风险降低到最低 切忌在项目设计之前试图消除需求变更 29 需求变更的原因 因竞争 成本等因素 工期已经确定且极不合理 用户在需求期提不出需求 或用户的需求不明确 项目组对业务不熟悉 或者没有与用户密切结合 需求分析工作不细致 项目组没有很好地实施需求管理 30 需求变更的恶性循环 31 需求变更的因素 32 需求变更的代价 33 减少需求变更 34 需求变更的过程管理 认识到变更不可避免 为变更制订计划 确认需求基线 建立控制变更的唯一渠道 使用变更控制系统来捕获变更 分层次地管理变更 35 基于配置管理的需求管理 避免需求在未授权情况下变更 或在有潜在破坏性的情况下不受限制地随意变更 保护队需求文档的修正 方便对文档以前版本的检索或重建 支持系统以增量的方式改进基线 避免对文档的同时更新和冲突 36 基线管理 需求基线 requirementbaseline 是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合 基线 已经通过正式评审和批准的某规约或产品 它可以作为进一步开发的基础 并且只能通过正式的变化控制过程的改变 IEEE 基线是一个软件配置管理的概念 在软件工程的范围内 基线是软件开发中的里程碑 其标志是有一个或多个软件配置项的交付 且已经经过正式技术评审而获得认可 配置管理组或委员会 CCB 按照需求基线 对整个项目的进程进行控制和把握 37 需求状态的变化 38 需求管理过程 注意如果项目中无人负责执行需求管理活动 那么就不要指望需求管理能够运作 39 需求版本控制 版本控制是管理需求规格说明和其他项目文档必不可少的一个方面 需求文档的每一个版本都必须惟一地标识出来 为了尽量减少混乱 冲突和误传 应该指派一个人专门负责更新需求 并确保只要需求有所变更就相应地改变其版本标识号 最简单的版本控制机制是 根据标准约定 对每一个软件需求规格说明版本进行手工标识 还有一种更复杂的技术 可以把需求文档存储在版本控制工具中 版本控制最有用的方法是将需求存储在商业需求管理工具的数据库中 40 需求属性 应该考虑为每个需求指定如下一些属性 需求创建的日期 需求的当前版本号 创建需求的作者 负责确保该需求得到满足的人员 需求的拥有者或一组涉众列表 需求状态 需求的最初来源 创建需求的理由 需求涉及的子系统 需求涉及的产品版本号 使用的验证方法或验收测试的标准 需求实现的优先级 需求的稳定性 注意如果选择的需求属性太多 那么开发团队会望而生畏 结果是他们绝不可能提供所有需求的全部属性值 也无法有效地使用这些属性信息 41 跟踪需求状态 表列出了若干可能的需求状态 有些跟踪人员还添加了另外两个状态 已设计 Designed 和 已交付 Delivered 42 评估需求管理的工作量 如果跟踪在需求管理上投入了多少工作量 我们就可以评估工作量是太少 还是正合适 或者是太多 并且可以对当前过程和未来的计划做出相应的调整 将下面这些活动中所投入的工作量加起来 就可以算出需求管理的工作量 提交需求变更和提议新的需求 评估已提议的变更 包括进行影响分析 变更控制委员会的活动 更新需求文档或数据库 向受影响的小组或个人传达需求变更 跟踪并报告需求状态 收集需求的跟踪信息 43 需求风险管理 44 所谓风险就是可能给项目的成功带来某些损失或威胁的情况 由于需求在软件项目中具有十分重要的地位 所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们 典型的需求风险包括 误解需求 用户的参与不恰当 项目范围和目标不确定或随意进行变更 对需求不断进行变更等 45 软件风险管理基本原理 对外部实体的依赖就是一种常见的风险来源 项目管理一直面临各种风险的挑战 评估不准确 管理人员拒绝开发人员的准确评估 对项目状态不了解以及进行了人员调整等原因所引起的风险 技术风险威胁着高度复杂或很前沿的开发项目 知识的缺乏是风险的另一种来源 另外还有参与者对所用的技术或项目应用领域经验不足 经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废 46 风险管理的要素 风险管理 riskmanagement 就是使用某些工具和步骤把项目风险限制在一个可接受的范围内 风险管理提供了一种标准的方法 可以指出风险因素并将其编写成文档 评估这些风险的潜在威胁 并提出减少这些风险因素的战略 47 风险管理包括图所示的这些活动 风险评估 riskassessment 是一个对项目进行检查以确定潜在风险领域的过程 风险避免 riskavoidance 是处理风险的一种方法 也就是尽量不要做冒险的事 48 编写项目风险文档 图展示了一个模板 用于对单个风险编写文档 49 制定风险管理计划 对于小型项目 可以把控制风险的计划包括在软件项目管理计划内 但对一个大型项目 则应该编写一个单独的风险管理计划 详细说明打算采用哪些方法来识别 评估 编档和跟踪风险 这一计划还应该包括风险管理活动的角色和职责 要建立起周期性进行风险监控的措施 注意 不要想当然地以为 在识别出了风险并采取了降低风险的相应活动之后 风险就会处于您的控制之下 接下来还要实行风险管理活动 50 与需求有关的风险 无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划 51 风险管理是我们的好帮手 即使不能控制项目可能遇到的所有风险 风险管理也能帮助我们看清形势 做出合理的决策 52 风险管理的措施 明确你当前项目面临的一些与需求有关的风险 不要把当前的问题当作风险 一定要是那些还未发生的事情 将风险因素编写成文档 为每项风险推荐至少一种可能的降低风险的方法 53 风险管理的措施 召集代表开发 市场 客户和管理各方面的涉众召开风险 集体研讨 会议 54 需求跟踪 需求跟踪提供了一个表明与合同或说明一致的方法 更进一步 需求跟踪可以改善产品质量 降低维护成本 而且很容易实现重用 需求跟踪链使你能跟踪一个需求使用期限的全过程 通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求 55 需求跟踪的定义 IEEE 1994 开发过程的两个或多个产品之间能够建立关系的程度 尤其是那些具有前后关系或主从关系的产品 例如 某个给定组件的需求和设计的匹配程度 软件开发产