风险识别检查表

如果对于这
01客 户 f管理者与客户一同决策（如需求理解、测试标准、进度调 整、接口变更等）是否没有以及时的方式进行？ g与客户达成一致的机制（如合同规定的工作组、技术交换 会议等）是否无效？ h涉及达成一致的问题时，客户是否内讧？ a外部接口变化时，是否没有适当的通知、协调或正式变更 流程？ 02相 b是否没有恰当的转变计划？ 关定 b.a如果否，那么是否有订约人不支持转变计划？ 约人 c从相关定约人那里获得进度或接口数据是否存在问题？ c.a如果否，那么他们是否不正确？ a给子商的任务定义是否有含糊不清的地方？ b子商的报告和跟踪监控过程是否与项目要求的汇报不同？ 03子 c对子商的管理是否没有一个独立的部门进行？ 商 d在某个领域你是否非常依赖子商的专家技术？ e公司所了解的子商是否经常变动？ f从子商那里获得的进度和接口数据是否存在问题？ 04供 a是否依赖于供应商提供的关键部件（如编译器、硬件、 应商 COTS等）？
进一步的调 研，以评估 潜在的风险 。 03士 气 b项目是否存在导致士气低下的因素（如裁员、离职、公司 亏损、行业不景气、政治混乱等）？ 10资源限制 a进度是否不够稳定？ b进度是否不切实际？ b.a如果否，那么估计方法是否没有基于历史数据？ 01进 度 b.b如果否，那么估计方法在过去是否运用的不好？ c是否还有没列入计划中的事情（如分析和研究、QA、培训 、运行和维护等） d是否有外部依赖有可能影响进度？ a是否缺乏在所需技术技能领域（如软件工程与需求分析方 法、算法专门技术、设计方法、程序语言、集成和测试方 法、可靠性、可维护性、配置管理、质量保证、目标环境 、安全水平、重用软件、操作系统、数据库、应用领域、 性能分析等方面）的相关人员？
02人 员 b项目成员数量是否不够？ c项目成员是否够稳定？
d在你需要的时候是否不能获得合适人选？ e项目是否依赖于几个关键人员？ f获得项目成员是否存在问题？ a预算是否不够稳定？ 03预 b预算是否基于不切实际的估计？ 算 b.a如果否，那么估计方法是否没有基于历史数据？ b.b如果否，那么估计方法在过去是否运用的不好？ 04设 a开发设备是否不够？ 备 b集成环境是否不够？ 11合同 01合 a数据（COTS软件、开发的软件、没有开发的项目等）的专 同约 利是否存在问题？ 束 02合 a关于外部产品或服务的一路是否影响产品、预算或进度？ 同依 （这些依赖如相关定约人、主要合同方、转包商、供应商 赖 、客户完成的设备或软件等）
05工程特性 01可 a架构、设计或者代码是否造成维护困难？ 维护 b维护人员是否没有在设计早期加入进来？ 性 c产品文档是否不足以供外部组织进行维护？ 02可 a软件是否没有分配可靠性需求？ 靠性 a软件是否没有分配安全性需求？ 03安 a.a如果否，那么在满足安全性需求方面是否有困难？ 全性 b验证令人满意的安全性需求是否很困难？ c以前是否没有实现过这种水平的安全性要求？ 06开发过程 01适 a开发过程对于这个产品是否不合适？ 宜性 b开发过程是否没有一整套规程、方法和工具来支持？ a是否有人没有遵循开发过程？ 02过 b是否没有度量开发过程满足生产率和质量目标与否？ 程控 制 c如果存在分布开发场所，那么在分布开发场所中是否有协 调不充分的地方？ 03熟 悉程 a项目成员以前是否没有使用过这些工具和方法？ 度 07开发体系 01熟 悉程 a项目成员以前是否没有使用过这些工具和方法？ 度 02可 a开发体系是否没有考虑可靠性（如编译器、开发工具、硬 靠性 件等）？ 03系 a项目成员是否没有接受过使用开发工具的培训？ 统支 b在使用开发体系包括的系统方面是否没有可咨询的专家？ 持 c开发体系的供应商是否不能快速响应到的问题？ 08管理过程 a受管理的开发程序是否与计划不一致？ b当计划发生偏离时是否没有重新修订计划？ 01计 c是否有项目成员对自己的的工作没有计划？ 划 d针对已知风险是否没有对意外事故的处理进行计划安排？ e对于长期的问题是否没有充分的计划安排？ 02管 a项目的管理者是否没有经验（如软件管理、协助软件开发 理经 、在开发过程方面、在应用领域、程序规模或复杂性方面 验 的管理经验）？ a是否没有定期的项目状态报告？ 03跟 踪监 控 如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
a.a如果否，那么项目成员对项目状态报告是否没有反馈？ 03跟 踪监 b是否没有向公司层面汇报合适的项目信息？ 控 c是否没有对照计划跟踪项目进展？ c.a如果否，那么管理是否没有一幅清晰的画面描述进展情 况如何？ a项目成员是否没有活动在这个项目中所必需的技能培训？ a.a如果否，那么获得培训的安排是否没有计划？ b是否将经验与工作领域不匹配的人员分配到项目中？ c项目成员是否不容易管理？ 04人 员管 d项目成员是否没有意识到项目计划里自己的职责？ 理 e项目成员是否觉得遵循计划不是很重要？ f在受影响的工作进行决策前，管理者是否与成员一起商 议？ g与客户会见时，管理者是否安排合适的项目成员（如需求 负责人、技术负责人、开发负责人、测试负责人等）？ a软件质量保证功能是否没有充分的在该项目中开展？ 05质 b是否没有定义质量保证的机制？ 量保 证 b.a如果否，那么是否有些区域和阶段没有质量规程？ b.b如果否，项目成员工作时是否没有使用这些规程？ a是否没有适当的配置管理系统？ b配置管理功能是否提供的不充分？ 06配 c配置管理工具与需要安装在上面的系统是否不协调？ 置管 c.a如果否，那么配置管理系统是否与工作场所变更不同 理 步？ d配置管理工具是否安装在多个场所？ d.a如果是，那么配置管理系统是否没有提供给多个场所？ 07定 a在项目计划中是否没有制定定量管理的目标？ 量管 b数据分析时，所选的数据分析工具是否恰当？ 理 c项目是否采集不到合适的数据来供数据分析？ 09工作环境 a项目成员在职能边界处是否不合作？ 01合 b项目成员是否没有向共同目标有效的工作？ 作 c是否经常需要管理部门干涉来使大家一起工作？ a项目成员（如项目经理、技术负责人、开发人员、测试人 员、配置管理人员、质量保证人员等）之间是否没有良好 的沟通？ 02沟 b高级经理是否不善于与开发人员进行沟通？ 通 b.a如果否，那么你是否不能自由的向高级经理寻求帮助？ b.b如果否，那么项目成员是否不会及时向高层提出风险？ c项目成员是否不能及时获得影响他们工作的事件通知？ 03士 气 a留住你所需的项目成员是否存在问题？ 如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。 如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
如果对于这 些问题中的 任何一个的 回答是肯定 的，则需要 进一步的调 研，以评估 潜在的风险 。
Байду номын сангаас
12程序交互方 a客户正式批准（如文档、程序评审、正式评审）的周期是 否不及时？ b在得到客户正式批准前你是否继续下去？ c客户是否不理解系统的技术方面？ 01客 d客户是否不理解软件？ 户 e客户是否干涉开发过程和人员？
如果对于这 些问题中的 任何一个的 答案是肯定 的，则需要 进行进一步 的调研，以 评估潜在的 风险。
如果对于这 些问题中的 任何一个的 答案是肯定 的，则需要 进行进一步 的调研，以 评估潜在的 风险。
风险。
04性 能 b.a如果否，那么你是否对性能分析不很自信？ b.b如果否，那么在设计和执行中是否没有跟踪性能的模 型？ 05硬 a是否有需要满足的用户需求的硬件限制（如架构、存储容 件约 量、吞吐量、实时响应、响应时间、数据库性能、可靠性 束 、有效性等）？ 03实现 01可 a产品某部分在编码时是否没有完全被设计规格所定义？ 行性 b所选的算法和设计是否不容易实现？ a设计规格是否不够详细而导致不能编码？ b当编码时设计是否再更改？ c系统限制（如时间、内存、外部存储等限制）是否导致代 码难于编写？ d程序的语言是否不合适？ 02编 e程序中是否要使用多种语言？ 码执 行 e.a如果是，那么通过不同编译器产生的代码接口之间是否 不兼容？ f开发的计算机是否与目标的计算机不同？ f.a如果是，那么两者之间的编译器是否不同？ g硬件规格对于软件编码来说是否不适当？ h当编码过程时硬件规格是否变化？ 04集成和测试 a是否没有充足的硬件用来做适当的集成和测试？ b在开发实际场景及测试数据来证明需求时是否有问题（如 01环 实时响应、异步事件处理、多用户交互方面的问题）？ 境 c在你使用的设备中是否不能验证性能？ d软硬件使用仪器是否不容易测试？ d.a如果否，那么这些仪器对所有测试是否不够？ a当需要时目标硬件是否不可用？ b可接受的准则是否与需求不一致？ 02产 b.a如果否，那么是否没有一个正式的协定？ 品集 成 c外部接口是否没有被定义、文档化以及基线化？ d是否没有充分的产品集成说没？ e是否没有分配充足的时间进行产品集成和测试？ a是否没有充分的系统集成说明？ b是否没有分配充足的时间进行系统集成和测试？ 03系 c产品是否将要集成到一个现存的系统中？ 统集 c.a如果是，那么与现存系统是否没有一个并行过渡时期？ 成 c.a.a如果是，那么对产品在集成时能够正确运转是否不自 信？ d系统集成是否发生在客户方？ 如果对于上 述问题中大 多数的回答 是肯定的， 则软件集成 和测试环境 是薄弱的， 且风险很高 。 如果对于这 些问题中的 任何一个的 答案是肯定 的，则需要 进行进一步 的调研，以 评估潜在的 风险。
风险辨识预评价表
评审对象（项目名称） 序号 01需求 01稳 a需求是否不稳定？ 定性 b外部接口是否经常变化？ a需求规格中是否还有待确定的？ b是否还有你知道的必须在需求规格中的需求还没有列入？ 02完 b.a如果是，那么在系统中是否不能获得它们？ 整性 c是否客户还有未成文或者期待的需求？ c.a如果是，那么是否没有办法捕获它们？ d外部接口是否没有被完整的定义？ a是否不能完全理解所写的需求？ 03明 a.a如果是，那么含糊的地方是否不能满意的解决？ 确性 a.b如果否，那么是否有解释含糊或者其他问题？ a这些需求是否有客户不想要的需求？ 04正 b你和客户是否对需求理解不一致？ 确性 c是否没有过程来确定需求？ a是否有某些需求在技术上难于实现？ 05可 a.a如果是，那么这些需求是否都没有做可行性研究？ 行性 a.a.a如果否，那么你对所做的可行性研究是否不自信？ 02设计 a是否有指定算法不满足需求？ 01功 a.a如果否，是否有算法或设计没有满足需求的描述（即没 能性 有与需求对应的描述）？ b是否不确定算法和设计可行？ 02技 a设计是否有依赖于不切实际的或乐观的假定？ 术难 b是否有功能需求难于设计？ 点 b.a如果否，是否还有需求没有解决方案？ a是否有内部接口（如软件对软件或软件对硬件）没有很好 定义？ b是否没有一个定义内部接口的过程？ 03接 b.a如果否，那么是否没有针对内部接口的变更控制过程？ 口 c硬件开发是否与软件开发并行？ c.a如果是，那么硬件规格是否变化？ c.b如果是，那么是否还有对软件的接口没有定义？ c.c如果是，那么是否没有用来测试软件的工程设计模型？ a性能是否还有问题（例如吞吐量、进程异步实时事件、实 时响应、响应事件、数据库响应或访问方面等） 04性 b是否没有做性能分析？ 能 检查项 PM 是 否 影响评估 备注