风险分类体系表_第1页
风险分类体系表_第2页
风险分类体系表_第3页
风险分类体系表_第4页
风险分类体系表_第5页
已阅读5页,还剩19页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、风险分类体系表风险分类体系表,按照产品工程类、开发规程和方法类、规划约束类三个类不,采纳列举各类的不同来源和属性下的问题方法,关心在项目中更好的识不风险来源和治理风险。表A.1 产品工程类产品工程类来源属性问题需求支持性需求的相关方是否对需求活动提供了足够的支持?客户或用户能确保参与需求的猎取活动吗?no 能采取措施使其参与或采纳客户和用户代表替代的方法吗?客户或用户能为开发方提供现场观看的机会吗?no 能由用户或用户代表详细描述用户的实际工作流程吗?组织对需求人员进行市场调查活动给与资源和时刻方面的支持吗?客户理解需求分析人员的需求猎取和需求分析活动吗?no 能通过培训或进一步沟通取得他们的

2、理解吗?掌握性设计人员对需求的内容准确掌握了吗?设计人员对需求的内容能获得正确理解吗?no 能通过培训或与需求人员的沟通解决那个问题吗?设计人员对需求的内容全面掌握吗?no 能通过培训或与需求人员的沟通解决那个问题吗?稳定性随着开发的进行需求是否发生变化?需求是否稳定?no 在哪些方面(质量、功能、进度、集成、设计、测试)阻碍系统?外部接口是否会有变化?完整性需求是否有所遗漏或规定不够完整?是否有你明白应该在需求讲明书中写明,但却没有写的需求?yes 你能够将这些需求融入到系统中吗?客户是否有需求讲明书中没有包括的需求或期望?yes 是否有一种途径去获得这些需求?是否完整地定义了外部接口?清晰

3、性需求是否清晰或有必要的解释?你是否理解书面化的需求讲明书?no 不明确之处是否正在被中意地解决?yes 描述是否存在歧义或者缺少必要地解释? 有效性按照需求所开发出的产品能否真正满足客户的要求?是否存在没有讲明客户真正想要的需求?Yes 你如何解决这些问题?你和客户对需求的理解是否一致?yes 是否有一种方法确定上述问题?你如何样来确认需求?(原型、分析、模拟)可行性从分析的观点看需求是不可行的?是否有些需求在技术上难以实现?yes a:这些需求是什么?yes b:什么缘故这些需求实现是困难的?no 是否为这些需求做了可行的研究?Yes 你认为可行性研究中所做的假定是否可信? 先例需求所规定

4、的内容你往常从没做过或者你所在的公司从没有做过?需求是否代表当前技术进展的最高水平?(技术、方法、语言、硬件)no 对你来讲现有的需求是否存在新的内容?yes 在这些领域是否有足够的技能水平? no是否有打算去获得这些领域的必备技能?可衡量需求是否规定了一个更大、更复杂的产品,或者要求一个更大的团队来完成?是否关注系统的规模和复杂性?no 在这之前你是否做过同样规模和复杂性的项目?如此规模的项目是否需要一个比通常更大的团队来完成?功能在满足功能性需求方面是否存在一些隐含的问题?是否有规定的算法不能满足需求的情况发生?no 是否存在牵强符合需求的算法和设计?你是如何确定算法和设计的可行性的?(原

5、型、模型、分析、模拟)难度设计或实现是否存在困难?是否存在依据不切实际和乐观的假定而得出的设计?是否存在设计上有难度的需求或功能?no 你是否有所有需求的解决方案?yes这些需求是什么?什么缘故不易实现?设计接口是否详细定义同时操纵了内部接口(硬件和软件)?是否详细定义了内部接口?(软件和软件、软件和硬件)是否有一种方法用来定义内部接口?yes 关于内部接口的变化是否有一种操纵方法?硬件是否和软件一起并行开发?yes a.硬件讲明书是否发生变更?yes b.所有的软件接口都被定义了吗?yes c.是否有可用于测试软件的工程设计模型?性能是否有关于响应时刻或吞吐量方面的需求?在软件性能方面是否存

6、在问题?(吞吐量、调度异步实时事件、实时响应、恢复时限、响应时刻、数据库响应)是否做了性能分析?yes a.对性能的分析你有多大的把握? yes b.在设计和实现过程中是否有一个可用于跟踪性能的模型?可测试性测试产品是困难的或不可能的吗?软件是否容易测试?设计是否包括一些特性能够关心测试?测试人员是否参与了需求分析?硬件限制关于目标硬件是否存在一些限制?硬件设备是否限制了你满足软件需求的能力?(体系架构、内存容量、吞吐量、实时响应、响应时刻、恢复时限、数据库性能、功能、可靠性、可用性)非软件开发打算中非开发的软件是否存在问题?假如是复用或重构的软件你是否按照打算安排复用或重构非开发的软件?Ye

7、s 你是否预见到了什么问题?(文档、性能、功能、按时交付、客户化)假如使用了商业现货软件使用的商业现货软件是否存在问题?确定接口、规模或性能的文档不够充分性能欠佳需要大的共享内存和数据库容量与应用软件的接口存在问题没有全面的测试不能剔除所有的bug可维护性不强供货商响应速度缓慢关于集成商业现货软件的补充资料和修订版你是否预见到什么问题?可行性实现设计是否是困难的或不可能的?设计讲明书是否全面定义了执行产品的所有部分?选择的算法和设计容易去实现吗?测试在你验证关于设计的代码之前是否已开始了单元设计?列出的单元测试是否充分?是否有足够的时刻去执行你认为应该做的单元测试?假如有进度问题是否做了关于单

8、元测试的进度承诺?编码和单元测试编码/实现在编码和实现方面是否存在问题?用来写代码的设计讲明书是否足够详细?当编写代码时设计是否有变更?是否存在一些系统限制(内存、外部存储)给编写代码带来一定的困难?完成软件功能所使用的语言是否适合?在程序中是否使用了多种语言?yes 不同的编译器产生的代码接口是否兼容?开发计算机是否同目标用户计算机相同?no 开发计算机和目标用户计算机编译器是否存在差异?假如使用了硬件环境编写软件的硬件讲明书是否充分?当编写代码时硬件讲明书是否发生变更?环境集成和测试环境是否预备充分?是否有足够的硬件去做充分的集成和测试?验证需求的开发觉实际场景和测试数据是否存在问题?(特

9、定的数据通信、实时响应、异步事件处理、多用户接口)你能否用设备去验证性能?硬件和软件工具是否方便测试?yes 所有的测试是否充分?产品接口定义、设施预备是否充分?时刻是否充足?需要时目标用户的硬件是否可得到?接收标准是否与所有需求一致?yes 是否有一个正式的协议?外部接口是否被定义、文档化同时形成基线?是否存在难于测试的需求?所规定的产品集成是否充分?是否分配了足够的时刻用来产品集成和测试?假如是商业现货软件在验证分配给商业软件的需求时供货商的数据是否可同意?yes 在这方面合同清晰阐述了吗?集成测试系统系统集成过程中相互间的协调、接口定义、设备方面是否存在问题?规定了足够的系统集成了吗?在

10、系统集成和测试方面是否分配了足够的时刻?所有合同商差不多上集成团队的一部分吗?产品是否被集成到当前的系统中?Yes 与当前系统是否有一个并行接入的时刻段?no 你将如何保证集成后的产品能够正常的工作?系统集成是否在客户现场进行?可维护性维护系统是否是困难的?整体架构、设计、编码是否给维护带来困难?维护人员是否参与了早期的设计?为开发方以外的组织进行产品维护时提供的文档是否充分?可靠性满足可用性和可靠性方面的需求是否有难度?分配给软件的需求是否包括了可靠性方面的需求?分配给软件的需求是否包括了可用性方面的需求? yes 恢复时限方面是否有问题?工程特性安全性安全性需求是不可行和无法验证的吗?分配

11、给软件的需求是否包括安全性方面的需求?yes 在符合安全性需求的过程中你是否遇到了困难?验证满足需求中安全性方面的需求时是否存在困难?保密性处理保密性方面的需求是否比编程经验更重要?是否存在无先例的或代表当前最高技术水平的保密性需求?是否是单机多用户系统?是否实现了这种级不的保密性需求?讲明书设计、实现和测试系统所用的文档是充分的?用来设计系统的软件需求讲明书是否是充分的?设计和实现系统的硬件讲明书是否是充分的?外部接口需求是否专门好的被定义?测试讲明书是否是充分的去全面测试系统?假如是实现时期和部分实现时期用于实现该系统的设计讲明书是否足够清晰?(内部接口)表A.2 开发过程和方法类开发过程

12、和方法来源属性问题开发过程规范性对开发过程的实施是否专门难理解或专门难予以维护?是否使用一种以上的开发模型(如瀑布、增量)?yes 相互间协调是否存在问题?是否对所有的开发活动予以正式策划(需求分析、设计、编码、集成测试、安装、质量保证、配置治理)?yes a:该打算规定的过程是否清晰?yes b:开发人员是否熟悉此打算?适应性过程是否适合于开发模型(如瀑布、原型)?开发过程是否适应于产品?开发过程是否由一组相互一致的规程、方法和工具所支持?过程可控性软件开发过程是否得到强化实施、监督并用可度量的方法操纵?分布在不同现场的开发是否可协调?每位项目组成员都遵循开发过程吗?yes 如何保证的?能否

13、度量出开发过程满足不满足预定的生产率目标和质量目标?假如采纳分布式开发,还需考察:关于多场地的分布式开发,是否有足够的协调能力?可理解性项目组成员是否具有实施过程的经验?过程能否被所有成员所理解?项目组成员能否顺利实施开发过程?产品可控性是否具有某些机制用以操纵产品的变化?是否存在需求跟踪机制,可使需求从原始讲明一直跟踪到测试用例?是否运用某种跟踪机制,用以评价需求变化对分析的阻碍?是否存在正式的变更操纵流程?yes 它覆盖到已基线化的所有需求、设计、代码和文档的变更了吗?任意级不上的变化是否都向上追溯到了系统级不、向下追溯到了测试级不?系统加入新的需求时,是否进行了足够的分析?是否具有某种方

14、法对接口进行跟踪?开发系统容量是否具有足够的处理能力、内存容量和存储能力?是否为所有人员提供满足一定处理能力的开发环境?是否具备足够的跨时期(如代码、集成、测试)能力?适应性开发系统是否支持所有时期、所有活动和所有功能?开发系统是否支持进程的所有各个方面(需求分析、性能分析、设计、编码、测试、文档、配置治理、治理跟踪、需求跟踪)?可用性开发系统的应用是否方便?项目组成员一般认为开发系统是否便于使用?开发系统的信息是否完备?可理解性公司或项目组成员是否完全不熟悉该开发系统?项目组成员先前是否使用过某些工具和方法?可靠性系统是否遇到过软件缺陷、系统崩溃、安装备份不足的问题?是否考虑过系统可行性(如

15、编译、开发工具、硬件)?系统支持系统能否及时获得专家或供货商的支持?使用开发工具的人是否获得过培训?与运用某种系统的专家是否便于沟通?供货商对问题的反馈是否迅速?可交付性为了把开发系统交付给用户,对可同意的需求进行定义是否还未计入预算?提示:假如参加项目的人员对此不理解,或许从风险的观点看会漏掉一个问题。是否将开发系统交付给了用户?yes 对交付是否分配了足够的预算、进度和资源?治理过程制定打算打算及时制定了吗?,是否包含应急的打算?时刻进度是按照打算实施的吗?yes 大伙儿是否只是当成例行公事?当发生变化时,是否重新制定打算,并按照打算进行实施?因此项目组成员的工作中都包含打算吗?关于已知的

16、风险有应急的打算吗?yes 你是如何样确定何时进行应急打算?充分的提出长期存在的问题吗?组织机构清晰角色和报告之间的关系时刻进度的组织是有效的吗?大伙儿是否清晰他们自己及其他人在打算中的角色吗?大伙儿是否清晰每个人拥有的权利是什么吗?治理经验是经理在软件开发、软件治理、应用领域、开发过程和大型打算中的经验。是否有经验丰富的治理者(软件治理、软件开发、开发过程、应用领域、软件规模和复杂性等方面)? 打算接口和客户、承包商、高级或者同级经理的接口上下的治理沟通是否存在问题?和用户文档之间的问题是否及时得到解决?在和用户的治理会议中有适当的做打算人员吗(如技术经理、开发人员、分析人员)? 是否有治理

17、机制确保用户代表能够针对功能和操作方面代表客户的意见。是否有良好的机制用于呈现给客户和高级治理者。治理方法监控治理规则定义和开发过程的跟踪定期的报告每周状态报告吗?yes 每个人关于每周状态报告都得到回复了吗?从每人的每周状态报告中能够猎取适当的信息吗?对打算进行跟踪了吗?yes 治理层是否得到了清晰的进度图表?人员治理项目组成员合理的培训和使用。大伙儿在项目中获得了关于技能方面的培训吗?yes 这部分包含在打算进度中吗?人员是否被分配到于自己工作经验不相符的工作区域?项目组成员是否容易获得治理进度安排?所有成员是否了解关于打算的执行状态?大伙儿感受到保持打算的重要性了吗?在做治理决定之前,与

18、大伙儿讨论对他们工作的阻碍了吗?是否有适当的项目组成员(技术经理、开发人员、分析人员)与客户一起参与了项目的治理进度安排? 质量保证保证产品质量的资源过程软件质量保证在进度方面的作用充分吗?你定义了保证质量的机制了吗?yes a:所有的区域和过程都有质量保证过程吗?yes b:通常大伙儿在他们工作中运用这些流程吗?配置治理关于多点安装变更流程和版本操纵是否充分?你有足够的配置治理系统吗?配置治理人员充分吗?和安装系统的需求进行协调了吗?yes a:对安装的系统有足够的配置治理吗?yes b:配置治理系统和你的工作同步变更吗?你正在安装多样的站点吗?yes 配置治理系统支持多点安装吗?工作环境质

19、量意识是否缺乏质量工作的目标?所有人员是否都遵循质量操纵流程?能够获得关于质量方面的时刻进度吗?协调性是否缺乏团队精神?在解决冲突之间是否需要进行治理层干预?大伙儿是否通过定义好的功能边界进行协调工作?大伙儿是否朝着通用的目标而有效地进行工作?在某种情况下,治理干预是否需要协调其他人员一起进行工作?沟通性在同级人员和经理之间存在着任务和目标的薄弱意识,同时技术信息欠缺沟通吗?在项目组成员之间存在良好的沟通性吗(如项目经理、技术经理、开发人员、测试人员、配置治理员、QA)? 项目经理善于和项目组成员进行沟通吗?yes a:你能专门好的向你的项目经理寻求关心吗?yes b:项目组成员在没有完成手里

20、工作时能够提高风险吗?项目组成员关于阻碍他们工作的情况能够得到及时的通知吗?yes 是正式的依旧非正式的?士气是一种没有生产性、没有制造性的气氛吗?人们感受到自己做了额外的工作而没有得到承认吗?在开发过程中,如何保持项目组成员的高昂士气?no 产生士气低落的全然因素是什么?保留你所需要的人员方面有什么问题吗?表A.3 规划约束类规划约束类来源属性问题资源进度进度是否不合适或不稳定? 进度一直是稳定的吗进度合理吗? yes 可能的方法是否基于历史数据?采纳的方法在过去的实践中证明有效?是否存在进度打算中没有打算到的领域(QA活动、培训、维护课程和培训、关键设备、可交付的开发系统)?是否存在容易阻

21、碍进度的外部的依靠关系?人员人员是否缺乏经验和缺乏必备的知识和技能或人力不足?是否存在所需要的技术技能缺乏的领域(软件工程和需求分析方法、算法专家技术、设计和设计方法、程序语言、集成和测试方法、可靠性、可维护性、有用性、人员因素、配置治理、质量保证、目标环境、安全等级、商业软件、重用软件、执行系统、 数据库、要紧应用领域、性能分析、关键软件等)?是否有充分的人员供给打算?人员稳定吗?当你需要时你是否有权使用适当的人选?针对这种类型的系统是否实施了人员的安排?程序是否依靠少数几个关键人员?在选择合适人员时是否有问题?预算资金是否不充裕或不稳定?预算稳定吗?预确实是否基于合理的可能?yes 可能的方法是否基于历史数据?no 假如没有基于历史数据,这种方法是否曾经使用并有效?是否有部分特征或功能作为设计成本操纵的一部分而被删除?是否存在没有分配足够的预

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论