《第22章 需求风险管理》由会员分享，可在线阅读，更多相关《第22章 需求风险管理（46页珍藏版）》请在金锄头文库上搜索。
1、第22章需求风险管理 2 所谓风险就是可能给项目的成功带来某些损失或威胁的情况 由于需求在软件项目中具有十分重要的地位 所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们 典型的需求风险包括 误解需求 用户的参与不恰当 项目范围和目标不确定或随意进行变更 对需求不断进行变更等 本章将对软件风险管理进行简要介绍 Wiegers1998b 本章后面还会提到需求工程活动中出现的许多风险因素 软件风险管理基本原理 除了与项目范围和需求有关的风险外 项目还面临着许多其他风险 对外部实体的依赖就是一种常见的风险来源 项目管理一直面临各种风险的挑战 评估不准确 管理人员拒绝开发人员的准确评估
2、 对项目状态不了解以及进行了人员调整等原因所引起的风险 技术风险威胁着高度复杂或很前沿的开发项目 知识的缺乏是风险的另一种来源 另外还有参与者对所用的技术或项目应用领域经验不足 经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废 风险管理的要素 风险管理 riskmanagement 就是使用某些工具和步骤把项目风险限制在一个可接受的范围内 风险管理提供了一种标准的方法 可以指出风险因素并将其编写成文档 评估这些风险的潜在威胁 并提出减少这些风险因素的战略 风险管理包括图所示的这些活动 风险评估 riskassessment 是一个对项目进行检查以确定潜在风险领域的过程 风险避免
3、 riskavoidance 是处理风险的一种方法 也就是尽量不要做冒险的事 编写项目风险文档 只是认识到项目所面临的风险是远远不够的 我们还必须以某种方式对风险进行管理 以便在整个项目开发过程中可以将风险问题和状态传达给项目的涉众 图展示了一个模板 用于对单个风险编写文档 制定风险管理计划 对于小型项目 可以把控制风险的计划包括在软件项目管理计划内 但对一个大型项目 则应该编写一个单独的风险管理计划 详细说明打算采用哪些方法来识别 评估 编档和跟踪风险 这一计划还应该包括风险管理活动的角色和职责 要建立起周期性进行风险监控的措施 注意 不要想当然地以为 在识别出了风险并采取了降低风险的相应活
4、动之后 风险就会处于您的控制之下 接下来还要实行风险管理活动 与需求相关的风险 下面介绍的这些风险因素 是按照需求工程的分支过程组织的 即需求获取 需求分析 编写需求规格说明 需求确认和需求管理过程 推荐的方法可以减小风险发生的可能性或风险发生后给项目造成的影响 与需求有关的风险 无足够用户参与用户需求的不断增加模棱两可的需求不必要的特性过于精简的规格说明忽略了用户分类不准确的计划 需求获取 产品前景和项目范围应该在项目早期 编写一份包括业务需求在内的前景和范围文档 并将它作为添加新需求和修改现有需求的指导 需求开发所需的时间将每个项目中需求开发所耗费的实际工作量记录下来 这样就可以判断出需求
5、开发是否充分 并可以改进未来项目的工作计划 需求规格说明的完整性和正确性为了确保需求是客户真正需要的 应该以用户任务为中心 应用用例技术来获取需求 创新产品的需求对某类产品中的第1个产品 不太容易把握市场对产品的反映 定义非功能需求由于我们一般都会强调产品的功能 所以很容易忽略产品的非功能性需求 需求获取 客户对产品需求意见一致确定那些主要的客户 并采用产品代言人的方法 保证有足够的客户代表的积极参与未加说明的需求客户经常会有一些隐含的期望要求 但并未以文档的方式说明出来 尽量识别客户可能做出的任何假设 把已有的产品作为需求基线来源将通过逆向工程发现的需求编写成文档 让客户评审这些需求 以确保
6、其正确性和相关性 根据需要提出解决方案分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图 需求分析 设定需求优先级要确保对每一个功能需求 特性或用例都设定了优先级 并安排在一个特定的系统版本或迭代中实现它们 技术上难以实现的特性采用项目状态跟踪来监控落后于实现计划的需求 并尽早采取纠正措施 不熟悉的技术 方法 语言 工具或硬件留出足够的时间用于从错误中学习经验 实验及制作原型 编写需求规格说明 需求理解开发人员和客户对需求的不同理解会导致彼此间的期望差距 并最终导致交付的产品无法满足客户的需要 尽管问题待确定但迫于时间压力而继续向前在软件需求规格说明中 将需要进一步研究的地方标上TBD
7、不失为一个好主意 具有二义性的术语对于不同的读者可能会有不同解释的业务术语或技术术语 应该创建一个术语表对这些术语进行定义 需求中包括了设计软件需求规格说明中所包含的设计对开发人员做出有效选择造成了不必要的限制 会妨碍他们发挥创造性设计出最佳方案 需求确认 未经确认的需求软件需求规格说明会令人望而生畏 在开发过程早期编写测试用例的想法就是基于这一点 审查熟练程度要对参与需求文档审查的所有团队成员进行培训 请组织内部有经验的审查人员或外界的咨询顾问来评述早先的审查 需求管理 变更需求将前景和范围文档作为批准需求变更的参照 可以减少范围蔓延 需求变更过程与需求变更的处理方式相关的风险包括 缺少已定
8、义的变更过程 采用无效的变更机制 以及不遵循制定的过程来做出变更 未实现的需求需求跟踪矩阵有助于在设计 构造或测试期间避免遗漏任何需求 扩大目范围如果最初的需求定义不够好 那么进一步定义需求就会扩大项目的范围 风险管理是我们的好帮手 周期性地进行风险跟踪可以使项目经理了解风险对项目的威胁 没有得到有效控制的风险应该上报高层管理人员 他们可能开始采取一些纠正措施 也可能不管风险 依旧按照原来的业务决策思路进行 即使不能控制项目可能遇到的所有风险 风险管理也能帮助我们看清形势 做出合理的决策 风险管理的措施 明确你当前项目面临的一些与需求有关的风险 不要把当前的问题当作风险 一定要是那些还未发生的
9、事情 将风险因素编写成文档 为每项风险推荐至少一种可能的降低风险的方法 风险管理的措施 召集代表开发 市场 客户和管理各方面的涉众召开风险 集体研讨 会议 尽力找出更多与需求有关的风险因素 估计每项风险发生的可能性及其影响 两者乘积就是风险危害值 通过按风险危害值降序排列找到最高的五项风险 为每项风险安排一个负责人负责实施降低风险的活动 第23章需求跟踪 需求跟踪提供了一个表明与合同或说明一致的方法 更进一步 需求跟踪可以改善产品质量 降低维护成本 而且很容易实现重用 需求跟踪链使你能跟踪一个需求使用期限的全过程 通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求 需求跟踪动机 CM
10、M的第三层次要求具备需求跟踪能力 需求跟踪的定义 IEEE 1994 开发过程的两个或多个产品之间能够建立关系的程度 尤其是那些具有前后关系或主从关系的产品 例如 某个给定组件的需求和设计的匹配程度 软件开发产品中每个元素能够建立其存在理由的程度 例如 数据流图中的每个元素定位它所满足需求的程度 跟踪关系 需求跟踪链 通用的跟踪模型 跟踪矩阵 用户需要与特性 跟踪矩阵 特性与用例 跟踪矩阵 特性与非功能性需求 在实现领域跟踪需求 从用例跟踪到用例实现 一 从用例实现跟踪到实现 二 从补充需求跟踪到实现 在测试领域跟踪需求 跟踪场景到测试用例 从用例到测试用例的跟踪矩阵 第24章需求管理工具 商
11、业需求管理工具 包括让用户从源文档中产生需求 定义属性值 操作和显示数据库内容 让需求以各式各样的形式表现出来 定义跟踪能力联系链 让需求同其他软件开发工具相连等功能 使用需求管理工具的益处 如何实现需求管理自动化 商业需求管理工具介绍 基于文档存储需求的限制 很难保持文档与现实的一致 不太容易做到为每一个需求保存增补的信息 很难在功能需求与相应的使用实例 设计 代码 测试和项目任务之间建立联系链 很难跟踪每个需求的状态 商业需求管理工具 以数据库为核心的产品以文档为核心的方法 一些商业需求管理工具 实现需求管理自动化 为需求管理工具定义项目需求 列出影响决策的10 15个因素 对上述步骤中列
12、出的因素打分 总计100分 获得有关可用的需求管理工具的最新信息 根据影响决策的因素对候选工具排序 根据给每个因素的加权值来计算每个候选工具的得分 从而确定最合适的产品 从候选工具的其他用户那里获得一些体会 从候选工具中前三名的开发商处得到评估拷贝 最好用一个实际的项目来评估工具 经过对排名 许可权费 开发商后续支持费 当前用户的输入 工作小组主观印象等的考虑之后做出决定 基于文档的存储需求的方法有许多局限性 例如 不容易保持文档的最新和同步 需要将变更人工通知给受影响的所有团队成员 不容易存储每一个需求的增补信息 属性 很难定义功能性需求和其他系统元素之间的联系链 很难跟踪需求状态 很难同时
13、管理多个分别用于不同产品版本或者相关产品的需求集 想要重用需求 分析人员必须将文本从初始的软件需求规格说明复制到每一个想要使用这一需求的系统或产品的软件需求规格说明中 如果有多人参与项目 要修改需求是很困难的 没有一个合适的地方可以方便地存储提议之后被否决的那些需求 以及已从基线中删除的需求 使用需求管理工具的益处 项目需求的收集工作做得很好 也应该使用自动化工具帮助您在开发过程中管理这些需求 随着时间的推移 团队成员对需求细节的记忆会逐渐变得模糊 这时使用需求管理工具的益处就得到了最大程度的体现 下面介绍这种工具可以帮助我们完成哪些任务 管理版本和变更项目应该定义需求基线 基线就是某一版本的
14、产品要实现的需求的集合 存储需求属性应该为每个需求记录一些描述性属性 要清楚地标出各种版本的产品要实现的需求基线 使用需求管理工具的益处 进行影响分析通过确定某一提议的变更可能影响哪些其他系统元素 这些联系链可以帮助分析这一变更对某一特定需求将产生的影响 跟踪需求状态将需求保存在数据库中就可以知道产品指定了多少离散的需求 访问控制需求管理工具可以定义单个用户或用户组的访问权限 并通过到数据库的Web接口与地域上分散的团队共享信息 与涉众沟通有些需求管理工具允许团队成员通过电子联系方式来讨论需求问题 重用需求将需求保存在数据库中 就可以方便地在多个项目或子系统中重用这些需求 需求管理工具的功能
15、大多数需求管理工具都与Word有某种程度的集成 一般情况下 是在Word菜单栏中添加了一个专门的工具菜单 这些工具的输出能力包括以用户指定的专门格式或表格格式报告生成需求文档的能力 产品有一个共同的趋势 就是尽量与应用程序开发所用的其他工具相集成 如图所示 选购需求管理产品时 要考虑它是否能与所用的其他工具交换数据 改变文化 如果我们努力要从商用需求管理工具中获得最大的投资回报 就应该考虑下面几个文化和过程问题 不要使用需求管理工具 甚至不要试用 直到书面创建了合适的软件需求规格说明 在项目早期的需求获取专题讨论会期间 不要试图直接用工具来捕获需求 将需求工具作为软件支持辅助工具 以方便不同地
16、理位置的项目涉众进行交流 仔细考虑要定义的各种需求类型 改变文化 为每一种需求类型定义一个拥有者 他对管理那一类型的数据库内容负有主要的职责 定义新的数据域或需求属性时 要使用业务术语 而不要使用IT术语 在需求稳定前不要定义跟踪链接 为了加快从基于文档的模式转向使用工具 要设置一个日期 不要期望在项目早期就冻结需求 而要养成习惯将某一特定版本的一组需求纳入基线 使需求管理工具服务于自己 项目需求加载到数据库 定义属性和跟踪链接 及时更新数据库内容 定义访问小组和他们的权限 以及培训用户 这些都需要付出劳动 管理层必须为这些操作分配所需的资源 确保在组织范围内确实将所选的产品用起来了 而不要让昂贵的工具束之高阁 我们明白工具不能克服过程的缺陷 就很可能会发现 商用需求管理工具可以提高我们对软件需求的控制能力 一旦我们使需求管理数据库服务于自己 那么就再也不想重新使用普通纸了
