软件需求与风险管理

软件需求与风险管理

软件工程师都是绝对的乐观主义者, 总是希望下一个项目进行顺利, 而忽略以前项目发生的问题, 事实却是许多潜在威胁阻碍项目按计划进行。

1. 基本概念 1) 风险

可能给项目的成功带来威胁或损失的情况 --> 成本费用, 进度安排, 技术方面, 产品质量, 团队工作效率

2) 风险管理

一种软件工业的最佳方法, 在风险给项目带来损失之前, 指明评估并对风险加以控制. 一旦发生风险, 只好通过项目事务(ongoing)状态跟踪和校正过程处理当前的问题.

3) 需求风险及其管理

需求说明在软件项目扮演一个核心角色, 精明的项目管理者会在初期就指明与需求相关的风险并积极控制它们.

[典型的需求风险]

- 需求误解( 同一个需求不同解释 ) - 不恰当用户参与

- 不确定或随意变更项目范围和目标以及持续变更需求

[避免方式]

- 不断与客户或者客户代表(市场人员)的合作控制需求风险

- 合作编写需求风险文档, 共同制订减轻风险的措施, 增强客户和开发人员之间的合作伙伴关系

2. 软件风险管理基础

风险管理事不断查看水平线上是否出现了冰山, 而不是以充足的信心认为船不会沉就以全速挺进.

风险管理的来源: 项目范围和需求相关, 转包承揽者和重用组件生产商, 技术风险(前沿开发), 知识缺乏风险

1) 风险管理的要素

--- 风险评价: 标识风险, 分析风险, 确定风险优先级 |

--- 风险管理 ------- 风险避免 |

--- 风险控制: 制订管理计划, 解决方案( 应急计划 ), 监控

2) 编写项目风险文档

软件风险条目跟踪模板

1. 序列号 <顺序号>

2. 确定日期

<编写风险条目列表日期>

3. 撤销日期

<撤销风险确定日期>

4. 描述

<以”条件—结果”的形式描述风险>

4.1 风险条目

<描述具体的风险>

5. 可能性

<风险成为问题事实的可能性>

5.1 风险条目 – 问题可能性

<一一对应描述风险成为问题的可能性>

6. 影响

<风险成为问题以后所造成的损失预计>

7. 危害值

<可能性 * 影响>

8. 降低风险计划

<一种或多种用来控制, 避免, 最小化以及降低风险的方法>

9. 负责人

<解决风险的责任承担者>

10. 截至日期

<完成降低风险措施的截至日期>

『说明』

. 不要试图精确量化风险

. 具体策略一方面是降低可能性, 另一方面是在风险成为事实以后减少可能带来的影响 . 长期或者复杂的风险可能需要具有多个阶段性成果的多步骤降低风险策略计划

3) 制订风险管理计划 [观点]

. 一张风险列表不等于一个风险管理计划 . 要坚持按照所采取得风险管理计划执行项目

. 项目进度安排上应该给风险管理留出足够时间确保项目并未浪费早期投资在风险计划上

. 工程项目的工作分类细目结构中包括降低风险的活动, 状态报告, 以及更新风险清单 . 周期性的进行监控和重点风险的评估

3. 与需求有关的风险

1) 需求获取

获取条目 说明

===============================================================

项目视图和产品范围 - 问题: 避免因为团队成员对于产品功能没有达成共识造成 的项目范围扩大

- 解决: 在项目早期制订项目视图与范围将业务需求涵盖在 内, 作为新的需求或者修改需求的指导 ----------------------------------------------------------------------------- 需求开发所需时间 - 问题: 仓促开始编码

- 解决: 1. 根据项目的规模和种类不同需要不同时间 2. 一般需求开发工作占15%

3. 记录参与的每个项目中实际需求开发的工作量, 进行评估是否所花时间适合并改进将来项目的工 作计划

-----------------------------------------------------------------------------

需求规格说明的完整性和 - 解决: 1. 针对客户使用\使用实例\根据情景编写\测试 准确性 用例\原型\等方式直观地向客户表达需求获 得反馈

2. 让客户代表对需求规格说明书和分析模型进行 正式的评审

----------------------------------------------------------------------------- 对革新产品的需求 - 问题: 忽略市场产品反馈信息 - 解决: 1. 强调市场调研 2. 建立原型

3. 运用客户核心小组

==> 获得革新产品任务的反馈信息

-----------------------------------------------------------------------------

明确非功能需求 - 问题: 忽略非功能需求

- 解决: 讯问客户有关产品性能, 使用性, 完整性, 可靠性 等质量特性, 编写非功能需求文件和验收标准(SRS) 作为可接受的标准

----------------------------------------------------------------------------- 客户赞同产品需求 - 问题: 不同客户对于产品具有不同意见 - 解决: 1. 找出主要客户

2. 采用产品代表方法确保客户代表积极参与, 确保 在决定权上有正确的人选

-----------------------------------------------------------------------------

未加说明的需求 - 问题: 客户提出隐含的期望要求, 并未进入SRS - 解决: 提出大量问题提示客户充分表达想法, 主意和应该 关注的一切

-----------------------------------------------------------------------------

把以后的产品作为基线 - 问题: 1. 被迫使用以后产品作为基线, 仅仅修正一些错误 和添加一些新特性.

2. 逆向工程得到的需求既不充分也不完整, 新系统 会具备旧系统的缺陷

- 解决: 1. 将逆向工程收集的需求编写文档, 让客户评审确 保正确性

-----------------------------------------------------------------------------

给出期望的解决办法 - 问题: 使用客户给出的解决方法造成业务处理低效, 或者 给开发人员带来压力导致作出很差的设计方案 - 解决: 提炼客户解决方案的本质核心二次开发

2) 需求分析

分析条目 说明

===============================================================

划分需求优先级 划分出每项需求, 特性或使用实例的优先级并安排特定的产 品版本或者实现步骤.

-----------------------------------------------------

评估每项新需求的优先级并与以后的工作主体现对比进行相 应决策

----------------------------------------------------------------------------- 带来技术困难的特性 评估每项需求的可行性进行决策 -----------------------------------------------------

对于落后计划的需求使用跟踪技术及早采取措施纠正 ----------------------------------------------------------------------------- 不熟悉的技术, 方法, 正视学习曲线

语言, 工具或硬件平台 ----------------------------------------------------- 明确高风险需求预留排错学习, 试验和测试原型的时间

3) 需求规格说明

说明条目 说明

===============================================================

需求理解 问题: 客户和开发人员对于需求的不同理解引起不同期望, 导致产品无法满足客户要求

解决: 1. 评审团体包括: 开发人员, 测试人员和客户 2. 分析人员引导客户得到更好的需求说明

3. 模型和原型从不同角度说明需求, 使得一些原本 模糊的需求清晰

-----------------------------------------------------------------------------

时间压力对于TBD的影响 问题: 未解决TBD将给结构设计与项目继续带来很大风险 解决: 明确TBD负责人以及解决的截至日期 -----------------------------------------------------------------------------

二义性术语 解决: 1. 建立术语和数据字典, 防止理解差异 2. 特别要搞清那些既有普通含义, 又有专业含义的 词语

3. SRS评审有助于帮助参与者对于关键术语, 概念达 成一致共识

-----------------------------------------------------------------------------

需求说明包括了设计 问题: SRS中的设计部分限制了开发人员并且妨碍他们设计 更好的方案

解决: 仔细评审需求说明以确保它的范围是在强调解决业务 问题需要做什么, 而不是怎么做

===============================================================

4) 需求验证

验证条目 说明

===============================================================

未经验证的需求 问题: 造成返工

解决: 1. 在项目计划中为保证质量的活动预留时间和资源 2. 积极配合客户代表获得参与评审的赞同(承诺), 尽早以可能低的成本通过非正式评审逐步到正式 评审找出存在问题

-----------------------------------------------------------------------------

审查自身的有效性 问题: 参审人员因为自身不懂得正确的评审技巧导致问题 解决: 对于内部团队进行培训, 并且聘请外部专家或者顾问 参与评审, 提高可靠性

===============================================================

5) 需求管理

管理条目 说明

===============================================================

需求变更 解决: 1. 利用项目视图和范围文档参照减少范围扩展 2. 用户的积极配合可以将需求变更减半

3. 对于易变更得需求使用多种设计方案实现, 并且注 重可修改性

----------------------------------------------------------------------------- 需求变更过程 问题: 1. 不明确的变更过程 2. 错误的变更决策 3. 不按计划作出变更

解决: 1. 在开发的各阶层建立需求变更管理的氛围

2. 提高决策能力(CCB), 分析变更影响, 使用相应的 工具.

-----------------------------------------------------------------------------

未实现的需求 解决: 使用需求跟踪能力矩阵有助于避免在设计, 结构建立 及测试期间遗漏需求, 和因为交流不充分导致多个开 发人员没有实现某些需求

-----------------------------------------------------------------------------

扩充项目范围 问题: 因为开始没有设计好需求, 导致项目周期性范围扩展, 或者未说明部分导致耗费更多工作量, 资源不足.

解决: 对于阶段式递增的生存期制订计划, 在早期版本中实 现核心功能, 在以后阶段逐步增加实现需求

===============================================================

===============================================================

5) 需求管理

管理条目 说明

===============================================================

需求变更 解决: 1. 利用项目视图和范围文档参照减少范围扩展 2. 用户的积极配合可以将需求变更减半

3. 对于易变更得需求使用多种设计方案实现, 并且注 重可修改性

----------------------------------------------------------------------------- 需求变更过程 问题: 1. 不明确的变更过程 2. 错误的变更决策 3. 不按计划作出变更

解决: 1. 在开发的各阶层建立需求变更管理的氛围

2. 提高决策能力(CCB), 分析变更影响, 使用相应的 工具.

-----------------------------------------------------------------------------

未实现的需求 解决: 使用需求跟踪能力矩阵有助于避免在设计, 结构建立 及测试期间遗漏需求, 和因为交流不充分导致多个开 发人员没有实现某些需求

-----------------------------------------------------------------------------

扩充项目范围 问题: 因为开始没有设计好需求, 导致项目周期性范围扩展, 或者未说明部分导致耗费更多工作量, 资源不足.

解决: 对于阶段式递增的生存期制订计划, 在早期版本中实 现核心功能, 在以后阶段逐步增加实现需求

===============================================================

本文来源：https://www.bwwdw.com/article/rb35.html