医患诚信系统——软件项目的风险

【医患诚信系统】

软件项目的风险

小组成员：1759103李思佳、1759106黄宇星、1759107陶彦婷[组长]、1759112刘亚玲、1759135王怡飞

目录

一、  文档目的

二、  风险

2.1  人员风险

2.2  流程风险

2.3  技术风险

2.4  环境风险

2.5  需求风险

2.6  产品风险

2.7  设计和实现风险

 

 

一、    文档目的

软件在其生命周期内的各个环节都具备不肯定性和复杂性，存在必定的风险。随着现代化科技技术的发展，各领域的须要日益增多，如何变被动为主动，对软件项目的风险进行识别，掌控软件项目的风险具备十分重要的现实意义。

软件项目风险控制应贯穿于整个软件开发过程，重视风险、学会正确处理风险，合理规避风险，调整应变成本，可将风险发生的可能性减少到最低，也能将风险发生带来的损失尽量降至最低。

此文档着重介绍了软件开发过程当中所涉及到的人员、流程、技术、环境、需求、产品以及设计和实现等方面所面临的风险以及它们的规避方法。

二、    风险

2.1  人员风险

风险	解决方案
咱们组有五我的，其中编程能力较好的有两人，因此软件开发的主要代码由他们二人负责编写，任务较重、压较大、完成时间难以掌握。	尽量将项目的核心工做分派给多人，培养和增强各成员的代码编写能力。
某些成员须要更多的时间适应还不熟悉的软件工具和环境。	全部成员都要尽快熟悉的软件工具和环境，基础好的成员多帮助基础较差的成员，你们共同进步，分担压力。
若是项目组成员之间发生冲突可能会致使沟通不顺畅、设计欠佳、接口出现错误和额外的重复工做。	发生矛盾时要及时讨论并解决问题，成员间要互相理解、理性分析，确保项目顺利进展。
缺少适当的激励措施，成员可能会由于长时间的工做（如：修改代码错误）而情绪低下致使效率下降。	创建必定的鼓励措施，分阶段制订几个小目标。目标完成后对完成目标的主要人员进行必定的物质奖励。
熟悉各类操做较慢的成员完成工做的时间以及任务比重，可能会影响项目组其余成员的积极性。	根据各成员较为擅长的项目决定项目分工，合理组织项目组成员，使他们有效地分工协做、共同完成项目建设。
文档编写与软件开发双方若沟通不良会影响项目顺利进展。	项目组成员应明确沟通方式和沟通渠道，确保沟通畅通，信息及时互通。
因为技术人员不足或技术人员水平或人员沟通等等缘由致使代码编写的完成时间难以掌握。	招募项目所需的技术人员，从而优化和提升代码质量，缩短完成周期，使项目完成时间可控。

 

2.2  流程风险

风险	解决方案
开发过程当中每一个人负责板块不一样，编程风格不一样,致使沟通不足,质量欠佳,甚至需从新开发	使用迭代开发，将开发过程分为多个阶段，将每一个阶段的开发任务分给不一样的组员，该开发阶段中，开发人员专一开发，在模块开发完成后未分到开发任务的组员进行测试和功能报告的撰写保证虽然每一个人负责的板块不一样但对他人写的模块都有所了解
撰写进程报告占用开发人员的时间比预期的多

 

2.3  技术风险

风险	后果	解决方案
不理解三层架构，经验不足过分使用某些技术（如xml,web webservice）、业务规则和逻辑混在一块儿。	（１）按照２层经验去设计三层架构，一个很差的经验致使整个系统瘫痪 （２）过分使用xml,web service致使性能严重不佳   （３）一个页面写５,6千行代码，没法维护，缺少可伸缩性	将结构简化，同时借鉴同行经验，取其精华改进，明确需求和所需功能，防止算法逻辑混乱。
对主机没有作好提早规划，急于上线	运行一段时间后系统资源不足，必须从新规划	对于主机提早作好全局规划，预留维护空间。
业务（数据）架构不合理（查询、插入操做放在一块儿）	查询、插入须要不一样的优化方式	将查询和插入操做分为两个模块来实现。
测试不全面	用户成了试验田	在正式上线前进行严谨的软件测试，寻找用户参与测试，使得软件更成熟。
陈旧的开发过程，没有每日集成，未及时与客户确认功能实现	上线临近出现一大堆没法解决的问题	采用W型开发，需求开发测试同步进行，增长容错率，及时解决问题。
未作好集中压力测试	并发时系统崩溃	作好压力测试，防止系统奔溃，必要时进行服务器扩容。
没有好的架构，缺少好的开发规范	程序bug重多，代码很难维护，代码水平依赖程序员水平。 解决方案：规范代码格式，书写编程日志，在适合的框架下编写代码，减小工做量。	规范代码格式，书写编程日志，在适合的框架下编写代码，减小工做量。
缺少数据库规划	噩梦般的熬夜调优、维护	创建数据库前作好规划，规范数据库格式。
脱离现状的设计	知足不了客户要求	采用W型开发，需求开发测试同步进行，逐步知足客户的需求，减小没必要要的资源浪费。
没有真正理解java多线程、对象、继承、垃圾回收机制等等；没有真正理解JDBC、没有真正理解Ｊ２ＥＥ、sevelet、JSP、MVC	形成可靠性、可维护性、可伸缩性、性能问题。	提高自身实力，寻找精通的人才加入。
操做性、友好性很差	很难使用、业务员抱怨成堆、实施异常困难	很难使用、业务员抱怨成堆、实施异常困难 解决方案：作好用户体验报告，及时更新改善操做性友好性问题，进行屡次调试，多轮测试。

 

2.4  环境风险

 

风险	解决方案
工做环境（包括办公环境和人文环境）	工做环境（包括办公环境和人文环境）的好坏直接影响项目成员的工做情绪和工做效率。 预防这种风险的办法是在项目建设以前就选择和建设好适合项目特色财务管理和知足项目成员指望的办公环境、在项目的建设过程当中不断培育和调整出和谐的人文环境。
系统运行环境风险	目前，大部分项目系统集成和软件开发是分开进行的（甚至由不一样公司承接）。所以，软件系统赖以运行的硬件环境和网络环境的建设进度对软件系统是否能顺利实施具备至关大的影响。 预防这种风险的办法是和用户签订相关的协议、跟进系统集成部分的实施进度、及时提醒用户等。

 

2.5  需求风险

   产品开发过程当中，因为产品需求自己的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变动等缘由，可能使需求分析偏离实际需求而最终致使产品开发的失败，这种可能性称为需求风险。软件开发项目风险是指在软件生命周期中所遇到的全部的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。需求分析是软件开发过程当中最初始、最基础的工做，也是最重要的工做之一，其成败将直接并最终决定软件开发的成败，而且呈倍增效应。需求分析的关键是使隐含的需求明确，使变动的需求可控，采用座谈会、需求调查表、需求启发、角色扮演等方法可使需求明确化；采用面向对象的方法及UML工具、领域专家的全程参与、需求分级、二次开发接口等方法可使需求变动处于可控范围内。实践证实，这些都是控制需求风险的有效方法。

风险	解决方案
没有足够用户参与	对系统用户及用户的替代源等相关涉众进行准确的分析；采用问卷调查等简单的需求获取方式或对于参与用户提供必定的奖励政策。
需求已经成为项目基准，但需求还在继续变化	对于合理的用户需求能够将新需求放到后续版本中；对于不可理的用户需求，须要开发人员保持业务领域的专业性。
模棱两可的市场需求	经过多用户或了解用户背景的方式来分析用户的深层目的，明确隐藏在背后的需求
没必要要的特性	对于没必要要的特性要摒弃
过于精简的规格说明	同时使用模型语言和天然语言两种表达方式，同时保证信息传递的准确行和文档的可读性。
被忽略的用户分类	召开屡次头脑风暴或集体会议明确全部的用户分类。
不许确的产品开发计划	召开屡次集体会议明确全部的产品开发计划书。

 

2.6  产品风险

 

风险	解决方案
开发额外的不须要的功能(镀金),延长了计划进度	使用迭代开发，将开发过程分为多个阶段，每一个阶段开始以前联系用户，让用户参与需求分析，结合用户的想法进行修改，删除用户认为无用的功能
要求与其余系统或不受本项目组控制的系统相连,致使没法预料的设计、实现和测试工做	在作系统的整体设计方案时，先把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题，肯定相关设备的技术参数和配置要求。
在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题
开发一种全新的模块将比预期花费更长的时间	在项目开发早期，创建系统的架构，对系统所须要应用的技术作深度探索。让小组里编程能力较强的组员优先解决关键技术难题，编程能力较差的组员负责较基础的功能编写，必要时刻利用网络解决问题

 

2.7  设计和实现风险

 

风险	解决方案
设计质量低下,致使重复设计	使用迭代开发，将开发过程分为多个阶段，每一个阶段完成以后联系用户，让用户参与测试，结合用户的使用感想进行阶段性修改， 将每一个阶段的开发任务分给不一样的组员，该开发阶段中，开发人员专一开发，未分到开发任务的组员进行测试和报告的撰写，同时对代码进行监督，若代码质量低则及时反馈， 保证每一个人负责的板块不一样但对他人写的模块都有所了解
代码和库的质量低下,致使须要进行额外的测试,修正错误,或从新制做
分别开发的模块没法有效集成,须要从新设计或制做
一些必要的功能没法使用现有的代码和库来实现,开发人员必须使用新的库或者自行开发新的功能	在项目开发早期，创建系统的架构，对系统所须要应用的技术作深度探索。让小组里编程能力较强的组员优先解决关键技术难题，编程能力较差的组员负责较基础的功能编写，必要时刻利用网络解决问题，若实在没法解决则求助老师