图书管理系统项目的风险分析.docx
《图书管理系统项目的风险分析.docx》由会员分享，可在线阅读，更多相关《图书管理系统项目的风险分析.docx（15页珍藏版）》请在冰点文库上搜索。
图书管理系统软件开发项目的风险分析
一、软件开发项目的风险背景
信息产业的发展是目前发展最快的行业之一，也是对社会影响最大的一个行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活，达到一个行业，小到一项服务。
我们不得不承认软件是二十一世纪最不可思议的产品。
伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险。
软件开发项目的成功与否会直接影响到公司的生存。
这对软件开发企业来讲应该是更大的难题。
一方面是业务需求更加复杂。
人们对软件质量和用途的期望大幅度提高，对业务系统的要求也越来越挑剔。
另一方面是开发成本不断缩减。
在此形势下，风险管理与控制已成为软件开发项目成败的关键。
软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点，其风险程度较高。
目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。
据有调查数据显示，有15-35%的软件项目中途被取消，剩下的项目不是超期就是超出预算或是无法达到预期目标。
另外，软件项目因风险控制和管理原因失败的约占90%,可见，软件风险控制与管理在目前的软件开发项目中的重要性。
、软件开发项目的风险来源及对项目成败的影响
软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。
软件项目风险经常会涉及许多方面，如：
缺乏用户的参与，缺少高级管理层的支持，含糊的要求,没有计划和管理等，总体概括下来应该由五大方面。
1、产品规模风险
项目的风险是与产品的规模成正比的。
与软件规模相关的常见风险因素有：
（1）估算产品规模的方法（包括：
代码行，文件数，功能点等）,
（2）产品规模估算的信任度，（3）产品规模与以前产品规模平均值的偏差，（4）产品的用户数，（5）复用的软件有多少，（6）产品的需求变更多少等。
一般规律，产品规模越大，以上的问题就越突出，尤其是估算产品规模的方法，复用软件的多少，需求变化。
2、需求风险
很多项目在确定需求时都面临着一些不确定性。
当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。
如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。
每一种情况对产品来讲都可能致命的。
与客户相关的风险因素有：
（1）对产品缺少清晰的认识，
（2）对产品需求缺少认同，（3）在做需求中客户参与不够，（4）没有优先需求，（5）由于不确定的需要导致新的市场，（6）不断变化需求，（7）缺少有效的需求变化管理过程，（8）对需求的变化缺少相关分析等。
3、相关性风险
许多风险都是因为项目的外部环境或因素的相关性产生的。
经常我们在控制外部的相关性上做的不够，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。
与外部环境相关的因素有：
（1）客户供应条目或信息，
（2）交互成员或交互团体依赖性，（3）内部或外部转包商的关系，（4）经验丰富人员的可得性，（5）项目的复用性。
项目经理圈子
4、技术风险
软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。
在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：
培训、聘请顾问以及为项目团队招聘合适的人才等。
主要有下面这些风险因素：
（1）缺乏培训，
（2）对方法、工具和技术理解的不够，（3）应用领域的经验不足，（4）新的技术和开发方法应用等。
5、管理风险
尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。
在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足——自己检查自己的错误，这是最难的。
然而，像这些问题可能会使项目的成功变得更加困难。
如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。
当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：
（1）计划和任务定义不够充分，
（2）实际项目状态，（3）项目所有者和决策者分不清，（4）不切实际的承诺，（5）员工之间的沟通等。
项目管理培训
6、安全风险项目管理者联盟
软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。
但一直以来，我们在软件这方面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。
软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。
而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们软件项目潜在的风险。
三、风险的分析、管理与控制
1.1“流程”因素分析
软件的开发流程般定义为：
需求分析一可行性分析一概要设计一结构化设计一详细设计一编码一软件测试一软件维护。
“流程”中软件项目的风险，主要体现存4个阶段：
软件需求阶段、软件设计阶段、软件实现阶段和软件维护阶段
•软件需求阶段
软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导，才能保证需求的完整，再以的形式形成《用户需求》这一重要的文档。
需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。
需求和需求分析的任何疏漏造成的损失，会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。
•软件设计阶段
设计的主要目的在于软件功能正确地反映了需求，需求的不完整和对需求分析的不完整或者错误，在设计阶段将被成倍地放大。
设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标；另一方面也是检验需求的致性和需求分析的完整性和正确性。
设计阶段的风险主要来自于系统分析人员O分析人员存设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担和维护成本的激增。
对用户来说系统的使用比例会有明显的折扣，甚至会造成软件寿命过短。
反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度上升,可靠性降低，给实现和测试阶段带来风险，系统的稳定性也会受到影响。
从另一个角度上看，用户需求和将来软件运行环境的变化都是必然的，目前软件设计的所渭的“通用性”是否就能很好的适应将来需求和运行环境的变化，都是需要认真折衷的，而这种折中也蕴涵着很大的风险。
设计阶段蕴涵的另一种风险来自于设计文档。
文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本级，甚至是发现的简单错误都无从更正。
•软件实现阶段
软件的实现从某种意义上讲是软件代码的生产。
源代码木身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。
源代码书的规范性，可读性是该阶段的主要风险来源。
规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。
•软件维护阶段
软件维护包含两个主要的维护阶段，一个是软件生产完毕到软件试运行阶段的维护，这个阶段是一种实环境的测试性维护，其主要目的是发现在测试环境中不能或末发现的问题；另一个阶段是当软件的运行不再能适应用户业务需求或是用户的运行环境（包括硬件平台、软件环境等）时进行的软件维护，具体可能是软件的版本升级或软件移植等。
1.2“技术”因素分析
存软件项目开发和建设的过程中，技术因素是一个非常重要的因素。
项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。
如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。
以上所说的各类风险都是项目成败的巨大隐患，它们对软件开发项目的成败有多大影响，我们可以利用风险分析工具，对以上各类风险进行分析，并加以控制和管理，将风险将到最低。
常用方法有风险条目检查表，它是利用一组提问来帮助项目风险管理者了解在项目和技术方面有哪些风险。
在风险条目检查表中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险，如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。
风险条目检查表可以不同的方式组织，通过假设分析、成本效益分析、风险剖面分析、判定树等，给出这些提问确定的回答，就可以帮助项目管理人员估算风险的影响。
另外，我们可以依据风险条目检查表，制作风险控制概图，让项目管理和实施人员能很直观的看到在项目开发个阶段的风险存在状况和各风险的大小，并采取相应措施。
从风险发生的概率来看，需求风险和管理风险对项目成败影响最大,当一个软件项目开发团队接手项目后，都是按照习惯性的方式来开发软件。
需求风险意识比较淡薄，软件需求分析阶段的完成的不够细致，忽略和很多软件开发必要的内容。
在整个软件开发过程中需求分析阶段的风险控制尤为重要，如果控制不好，对软件开发项目影响巨大，甚至是失败。
管理风险实际上是项目开发管理层，对项目开发的风险的意识反映。
国内的软件企业大多规模较小，企业年轻,开发经验不足，软件工程师较年轻，缺少开大型软件项目的经验，在管理方面缺少经验，特别是风险管理，更是缺乏。
下面是风险控制概图。
2、风险管理
风险管理应是贯穿软件项目开发始末的一项重要任务，其中包括风险识别、风险评估、风险计划、风险解决和风险监控。
它能让风险管理者主动“规避”风险，进行有效的风险管理。
风险管理模型有：
SEI风险管理模型、Riskit风险管理模型、SoftRisk风险管理模型、IEEE风险管理过程模型、CMMI风险管理模型、MSF风险管理模型等。
在项目管理中，建立风险管理策略，在项目的生命周期中不断控制风险是非常重要的，风险管理主要包括五个阶段：
（1）风险识别：
识别风险的方法常用的有现场观察法、座谈法、流程图法、财务报表法、相关部门配合法和环境分析法等。
（2）风险评估：
对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：
概率分布、外推法、多目标分析法等。
（3）计划进度：
按照评估后的风险结果，制定相应的风险管理进度表，为后续的风险管理提供参考。
（4）风险处理：
一般而言，风险处理有三种方法，①风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。
②风险自留，当风险量不大时可以余留风险。
③风险转移。
training,
（5）风险监控：
包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。
（1）建立有效的风险控制的组织机构项目管理者联盟文章
①设置风险管理岗位：
在软件开发项目管理过程中设置风险管理岗位，该岗位的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。
风险管理岗位的人数依据项目大小来决定，一般2—3人较为适合。
②双项目经理:
为项目开发项目设定两个项目经理岗位，一个负责技术岗位,另一个负责管理岗位。
目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出生的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足,这不利于项目风险管理和控制。
通过增加专门的管理经理岗位，可以弥补技术出生的项目经理的不足，提升软件开发项目的管理水平。
而且这样的经验也已得到了国外业界大多企业的认可。
（2）建立有效的风险控制管理过程
风险管理过程包括培训，风险识别、风险分析、风险计划、执行计划、跟踪计划等活动，有效的风险管理过程应是学习型的、持续的和不断改进的。
软件企业应建立自己的风险管理数据库作为风险管理的基础，并在实施中不断地更新和
7U口°
根据企业和项目的实际情况，进行科学的项目风险和控制，对项目的成功研发有着举足轻重的意义。
在项目开发的过程中，进行必要的项目风险分析，制定符合项目特点的风险评估和监督机制，特别是要定期对项目的风险状况进行评估和监管，发现意外风险或者是风险超出预期的一定要重点关照。
发现问题要立即上报，尽快解决。
并建立风险监管日志，实行“岗位负责制”，将软件开发项目的风险降到最低。
四：
项目中常见风险及预防措施
在项目的建设过程中，风险几乎无处不在。
如何有效地识别、控制和管理风险，对项目的成功起着至关重要的影响。
一个项目有可以预料的（包括已知的）风险和不可预料的风险，以下作者总结自己多年的软件项目工程经验，整理出软件项目经常遇到的15种可预料的（包括已知的）风险及其预防措施，期望能为项目经理制定项目风险计划和进行风险预防、控制等提供富有价值的参考。
（1）合同风险
签订的合同不科学、不严谨，项目边界和各方面责任界定不清等是影响项目成败的重大因素之一。
预防这种风险的办法是项目建设之初项目经理就需要全面准确地了解合同各条款的内容、尽早和合同各方就模糊或不明确的条款签订补充协议。
（2）需求变更风险
需求变更是软件项目经常发生的事情。
一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损（实际上项目建设方也面临巨大的风险）。
预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。
（3）沟通不良风险
项目组与项目各干系方沟通不良是影响项目顺利进展的一个非常重要的因素。
预防这种风险的办法是项目建设之初就和项目各干系方约定好沟通的渠道和方式、项目建设过程中多和项目各干系方交流和沟通、注意培养和锻炼自身的沟通技巧。
（4）缺乏领导支持风险
上层领导的支持是项目获得资源（包括人力资源、财力资源和物料资源等）的有效保障，也是项目遇到困难时项目组最强有力的“后台支撑”。
预防这种风险的办法是主动争取领导对项目的重视、确保和领导的沟通渠道畅通、经常向领导汇报工作进展。
（5）进度风险
有些项目对进度要求非常苛刻（进度要求不高的项目，我们同样要考虑该风险），项目进度的延迟意味着违约或市场机会的错失。
预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。
（6）质量风险
有些项目，用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。
预防这种风险的办法一般是经常和用户交流工作成果、品牌管理采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。
（7）系统性能风险
有些软件项目属于多用户并发的应用系统，系统对性能要求很高，这时项目组就需要关注项目的性能风险。
预防这种风险的办法一般是在进行项目开发之前先设计和搭建出系统的基础架构并进行性能测试，确保架构符合性能指标后再进行后续工作。
（8）工具风险
软件项目开发和实施过程，所必须用到的管理工具、开发工具、测试工具等是否能及时到位、到位的工具版本是否符合项目要求等，是项目组需要考虑的风险因素。
预防这种风险的办法一般是在项目的启动阶段就落实好各项工具的来源或可能的替代工具，在这些工具需要使用之前（一般需要提前一个月左右）跟踪并落实工具的到位事宜。
（9）技术风险
在软件项目开发和建设的过程中，战略管理技术因素是一个非常重要的因素。
项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。
如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。
预防这种风险的办法是选用项目所必须的技术、在技术应用之前，针对相关人员开展好技术培训工作。
（10）团队成员能力和素质风险
团队成员的能力（包括业务能力和技术能力）和素质，对项目的进展、项目的质量具有很大的影响，项目经理在项目的建设过程需要实时关注该因素。
预防这种风险的办法是在用人之前先选对人、开展有针对性的培训、将合适的人安排到合适的岗位上。
（11）团队成员协作风险
团队成员是否能齐心协力为项目的共同目标服务，生产管理是影响进度和质量的关键因素。
预防这种风险的办法是项目在建设之初项目经理就需要将项目目标、工作任务等和项目成员沟通清楚，采用公平、公正、公开的绩效考评制度，倡导团结互助的工作风尚等。
项目成员特别是核心成员的流动给项目造成的影响是非常可怕的人力资源。
人员的流动轻则影响项目进度，重则导致项目无法继续甚至被迫夭折。
预防这种风险的办法是尽可能将项目的核心工作分派给多人（而不要集中在个别人身上）、加强同类型人才的培养和储备。
（13）工作环境风险
工作环境（包括办公环境和人文环境）的好坏直接影响项目成员的工作情绪和工作效率。
预防这种风险的办法是在项目建设之前就选择和建设好适合项目特点财务管理和满足项目成员期望的办公环境、在项目的建设过程中不断培育和调整出和谐的人文环境。
（14）系统运行环境风险
目前，大部分项目系统集成和软件开发是分开进行的（甚至由不同公司承接）o因此，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具有相当大的影响。
预防这种风险的办法是和用户签定相关的协议、跟进系统集成部分的实施进度、及时提醒用户等。
（15）分包商风险
有些项目管理可能会涉及到将系统的部分功能分包出去，这时项目组就需要关注项目的分包商风险。
预防这种风险的办法一般是指定分包经理全程监控分包商活动、让分包商采用经认可的开发流程、督促分包商及时提交和汇报工作成果、及时审计分包商工作成果等。
世间万物总是发展变化的，风险亦可能随时出现和变化。
项目经理应该将“防患于未然”牢记于心并作为自己日常项目工作的“座右铭”。
项目经理不断培养和强化项目整个团队成员的风险意识，是确保项目顺利进展的最有效方法之一。
以上列举的这些风险，应该是软件项目建设中经常出现的主要风险，但由于项目本身的个性化特征，针对具体的项目，肯定会出现一些我们上面没有列举甚至是事先根本无法预期的风险，这就需要我们项目经理有敏锐的“嗅觉”去识别它们，从而更好地预防和控制它们。
排
序
输入
风险事件
可能性
影响
风险值
采取的措施
1
客户的
sow
需求不明确，增加需求，导致需求蔓延。
70%
50%
35%
请专业需求分析师和客户代表具体深入细节的交谈，多了解客户的想法，站在客户的角度上思考问题。
2
合同
进度要求紧，合同金额和日期有限。
30%
50%
15%
可以请一些实习的学生做辅助工作，一来降低成本，二来可以加快进度。
3
历史项
目信息
开发人员对测
试工作不重视
30%
40%
12%
1）强制性要求每段代码保留测试单元，由SQA检查。
4
WBS
对需求的开放
式系统标准没
有合适的测试
案例
20%
80%
16%
找专业的测试公司完成测试工作
5
历史项
目信息
开发人员的流动
15%
60%
9%
1）注意项目团队的沟通，及时了解开发人员的动态。
2）控制好项目过程中的文档
3）从其它的项目组解调人员
4）从外部招聘有过此类开发经验人员
6
系统设
计评审
没有足够的时间进行产品测试
50%
50%
25%
1）采取加班的方法
2）修改计划去掉一些任务
3）与客户商量延长一些时间
7
需求和
计划
采用新技术可能导致进度的延期
50%
30%
15%
1）培训开发人员
2）找专家作指导
3）采取边开发边学习的方法，
要求他们必须在规定的时间内掌握技术
风险分析表
图书管理系统软件开发项目风险分析表
风险：
1
风险信息表
标识者：
组内成员
优先级:
2
陈述：
编程语言的选择造成效率的不一致。
概率：
2
影响：
1
起因：
编程语言选择不一致
类别：
技术风险
分配给：
时间框架：
近期
语境：
1、由于编程语言不一致，导致合成有困难。
缓解策略：
1、实际编程前，统一编程语言。
应急计划及触发事件：
1、当发现编程语言选择不一致时，及时沟通协调达到一致。
风险:
2
风险信息表
标识者：
组内成员
优先级：
4
陈述：
使用的框架存在漏洞Bug,导致项目的失败。
概率：
1
影响：
4
起因：
使用的框架
存在漏洞Bug
类别：
技术风险
影响：
4
时间框架:
近期
时间框架:
近期
语境：
1、使用的框架本身有问题，不能支撑项目。
缓解策略：
1、测试人员及时发现问题，编程人员及时解决问题。
应急计划及触发事件：
1、当发现框架存在漏洞Bug,及时补救。
风险：
3
风险信息表
标识者：
组内成员
优先级：
4
陈述：
开发工具的不可靠性导致项目过程中的Bugo
概率：
1
影响:
4
起因：
开发工具不可靠
类别：
开发技术风险
分配给：
时间框架：
近期
语境：
1、开发工具不可靠导致问题。
缓解策略：
1、确定开发工具可靠。
应急计划和触发事件：
1、当开发工具不可靠导致项目过程中的Bug时，及时解决问题或者更换开发工具。
风险：
4
风险信息表
标识者：
组内成员
优先级:
4
陈述：
开发过程中由于版本变更控制不当导致版本混乱。
概率：
2
影响：
2
起因：
版本变更控制不当
类别：
技术风险
分配给：
时间框架：
近期
语境：
1、在开发过程中，。
缓解策略：
1、严格按照配置管理中的变更控制流程，做好跟踪与记录。
应急计划及触发事件：
1、当出现版本混乱时，及时统一新版本。
风险：
5
风险信息表
标识者：
组内成员
优先级：
4
陈述：
对于进度的估计不当，导致无法按期交付项目。
概率：
2
影响：
2
起因：
进度估计不当
类别：
管理风险
分配给：
时间框架：
近期
语境：
1、实际开发进度严重不符合进度估计，导致无法按期交付项目。
缓解策略：
1、开发前做好充足准备工作。
2、开发过程中不浪费时间。
应急计划及触发事件：
1、当无法按期交付项目时，与用户进行沟通，加快开发速度。
风险：
6
风险信息表
标识者：
组内成员
优先级：
5
陈述：
需求分析不到位，导致数据模型建好后无法使用
概率：
1
影响：
5
起因：
需求分析不到位
类别：
技术风险
分配给：
时间框架：
近期
语境：
1、在项目启动开始时，需求分析不到位。
缓解策略：
1、重新进行到位的需求分析。
应急计划和触发事件：
1、当数据模型建好后无法使用时，及时重新做需求分析。
风险：
7
风险信息表
标识者：
组内成员
优先级：
5
陈述：
火灾、洪涝、地震等自然灾害所造成的损失
概率：
1
影响：
5
起因：
自然灾害
类别：
自然风险
分配给：
时间框架：
远期
语境：
1、图书馆或者系统运行所需设备遭受自然灾害。
缓解策略：
1、做好转移工作，降低损失的程度。
应急计划及触发事件：
1、提前制定灾害时期计划，且工作人缘熟悉演练，关注有关部门发布的灾害预警。
2、当发生灾害时执行灾害时期计划。
风险：
8
风险信息表标识者：
组内成员
优先级：
8
陈述：
关键的人员在项目的关键时刻离开。
概率：
2
影响：
4
起因：
人员离职类别：
管理风险分配给：
时间框架：
近期
语境：
1、项目在成败一举时因人员离职遭受风险。
缓解策略：
1、加强人员考核，确定人员可靠性；
2、福利到位，防止人员被迫离职；
3、及时寻找替代人员。
应急计划及触发
升级会员 