软件开发都有哪些风险（软件开发都有哪些风险隐患）
今天给各位分享软件开发都有哪些风险的知识，其中也会对软件开发都有哪些风险隐患进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
做软件开发的弊端都有哪些？
个软件项目从开始到结束，由于资源、人员、管理、方法学等等各方面的因素，往往不可避免的会存在一些问题，如需求不明确、项目管理失败、沟通问题等等。
不能很好的理解用户的需求，缺少与用户之间的沟通。
错误的预估项目的大小和难易度。
没有计划就匆匆开始编码。
没有在项目初期就开始做测试，一直拖到项目后期才做，或者根本不做什么测试。
选择时下最cool的技术还是已经被团队使用比较成熟的技术，往往不能做出很正确的选择。
不采用任何软件过程或者方法学。
没有一个真正的项目经理，让开发人员无计划的主导项目。
拖延计划，把进度压力留在后期。
不做版本控制，混乱的代码库和开发环境。
在项目过程中随意的更换开发工具和环境。
客户的任何需求都答应下来，需求会永无止境，记得学会说“不”。
只有一个大的计划，没有把计划分割成一个个更小的任务，要知道，大的计划如果不分割成任务很难落实和具体实施。
对开发团队的管理不足。
在项目后期增加人员来加快开发速度，很多时候往往适得其反。
开发人员不做单元测试。
一旦项目中遇到问题，就把压力抛给开发人员。
不关注软件实际的运营环境和硬件条件。
没有命名规范和代码规范。
到处都用全局变量。
遇到问题的时候往往不请教别人，而是一个人闷头搞，到最后还是不得以还是通过别人来解决
没有写代码注释的习惯。
对输入输出的数据不做验证。
不做压力测试，到实际环境中往往就会出现更多的跟环境和性能相关的问题。
项目内部沟通不畅，每个成员只是埋头做自己的事情。
没有很好的bug管理规范和系统，往往用word、email、excel等文本方式来跟踪bug，将会导致整个项目的bug管理陷入混沌。
软件项目管理及风险分析
关于软件项目管理及风险分析
摘要： 软件项H的有效管理，对项目的成败具有至关重要的作用。软件项目的风险体现存些方血，如何回避这些风险，存本文中进行了探讨，最后指出建立合理的管理流程，对软件项目的管理来说，是非常重要的。
关键词： 软件项目：管流程;风险分析
软件项目管理的提出是在2O世纪70年代中期的美国，当时美国国防部专研究了软件开发不能按时提交，预算超支和质量达到用户要求的原因，结果发现70%的项目是因为管理不善引起的，而非技术原因。于是软件开发者开始逐渐重视起软件开发中的各项管理。到了20世纪90年代中期，软件研发项日管理不善的问题仍然存在。据美国软件工程实施现状的调查，软件研发的情况仍然很难预测，大约只有10%的项目能够在预定的费用和进度下交付。
究竟怎么样才能做好软件项目的管理及风险分析，保证项目顺利实施呢?这是个比较复杂的问题，下面就软件项目的特点，缩合大家的经验总结，谈一点看法。
1、软件项目管理风险分析
软件项目管是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对人员、产品、过程和项目进行分析和管理的活动。目的是为了让软件项目尤其是大型项目的整个软件生命周期(从分析、设计、编码、测试、到维护全过程)都能在管理者的控制之下，以预定成本按期，按质的完成软件交付用户使用。
怎样进行有效的项目管理呢?首先我们来分析下影响软件项目的质量因素。
软件项目，尤其是大型项目有二项非常重要的因素，会影响整个项目的进度与质量，它们分别是：“人”、“流程” 与“技术”。
“人”是项目中最难预料与掌控的一项要素，人可分成两部份，一是客户，二是开发团队。
“技术”是指软件项目所使用的开发半台，主要指开发环境及开发语言。是最容易掌握的部份。
“流程”是指软件开发流程或是项目流程，定义流程的目的是要掌控所有的情况。项目的最大敌人是时间及预算，这两者都是有限的，如何在有限预算内准时完成项目，可说是一项艺术。
1.1“人”因素分析
“人”是指客户和开发团队，其中开发团队的因素对项目影响很大，对于这方面影响因素主要分析如下：
人员技能未达到要求
在项目开始之初，我们假设项目成员都能够达到组织级的要求，但往往并不是每个成员都能够达到要求。而且项目中每个成员的生产率差异可能很大，也给项目进度安排造成影响。所以在项目始之初，应该对项目成员的技能进行一次总体的评估，对于大家都欠缺的技能，应该安排统一的培训，后续需要对培训的效果进行跟踪;对于个别人员技能欠缺的，应该单独预留自我学习时间或通过以师带徒的方式进行培养，使其技能能够尽快达到要求：对于项目新员的工作和任务，应该加强评审和检查，保证输出不出现大的偏差而导致后续大量的返工。对于这方影响因素主要分析如下：
项目成员责任心不强
态度决定一切，细节决定成败。对于项目过程中的各项任务，经常出现由于项目成员责任心不强敷衍了事，导致产出的工件质量较差，引起大量返工的情况。在这种情况下，项目更应该加强项目规范的建设，项目经理应加强同这些成员的单独沟通，加强项目的团队建设和集体荣誉感。让项目成员感觉到做的系统是他们自己的产品，而不是公司的项目，项目经理的项目。
项目沟通问题
在软件项目中，保证项目各种角色和成员中的高效沟通是很重要的，如何建立起快捷顺畅的沟通渠道，采用最佳的沟通方式来解决问题，必须在项目中经常强调。如果一周的项目任务花存实际做事情上有2天，而花在沟通上却占用了3天，这时必须及时分析和总结原因。沟通最重要的`就是要在最短的时间里面，采用各种方法或工具，使交流双方或多方达成一致。
项目人员流失
项目人员特别是项目关键成员在项目进行过程中的流失，对项目影响很大，对于这种情况，应该在项目开始之初，就作为专门的风险进行跟踪，并考虑具体的应对措施。
1.2“流程”因素分析
软件的开发流程般定义为：
需求分析一可行性分析一概要设计一结构化设计一详细设计一编码一软件测试一软件维护。
“流程”中软件项目的风险，主要体现存4个阶段：软件需求阶段、软件设计阶段、软件实现阶段和软件维护阶段
软件需求阶段
软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导，才能保证需求的完整，再以的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失，会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。
软件设计阶段
设计的主要目的在于软件功能正确地反映了需求，需求的不完整和对需求分析的不完整或者错误，在设计阶段将被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标;另一方面也是检验需求的致性和需求分析的完整性和正确性。
设计阶段的风险主要来自于系统分析人员。分析人员存设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担和维护成本的激增。对用户来说系统的使用比例会有明显的折扣，甚至会造成软件寿命过短。反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度上升，可靠性降低，给实现和测试阶段带来风险，系统的稳定性也会受到影响。从另一个角度上看，用户需求和将来软件运行环境的变化都是必然的，目前软件设计的所渭的“通用性”是否就能很好的适应将来需求和运行环境的变化，都是需要认真折衷的，而这种折中也蕴涵着很大的风险。
设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本级，甚至是发现的简单错误都无从更正。
软件开发面临哪些法律风险
1\软件公司最多只能对设计的软件的本身享有所有权,而且这种情况还是要在合同约定该软件归软件公司所有的情况下才能实现.并且因为该软件在运行过程中获得的部分数据不是汽车公司的数据，而是网点自身在业务经营过程中的消费方面的数据。如果软件公司在未经汽车公司以及4S店的允许擅自查看\复制\传播\买卖等,可能涉及关于侵犯商业秘密的行为,很可能受刑法制裁.
2\直接读取他人软件的数据库是否侵权应当看是否拥有使用权或者所有权,还要看你读取的目的是什么,即使拥有使用权,如果你读取了并且复制传播有可能使他人获得该软件的核心内容或者直接制作以该内容为核心的新软件,则肯定侵犯了软件公司的知识产权.
3\如果盗窃\传播\买卖客户关系的数据,就可能涉及关于侵犯商业秘密的行为,很可能受刑法制裁,如果只是使用数据不谨慎,导致被他人利用该数据,例如你复制数据回家进行工作,但在路上遗失,而你又没有积极采取措施补救,就可能承担民事法律责任.
对补充问题的回答:对于"现在开发小系统的是个人，属于汽车公司的员工"涉及到该小系统软件的所有权问题,如果是汽车公司委托该员工开发的,并且没有约定该小系统权利归该员工,则汽车公司获得该小系统的知识产权.同理,对于汽车公司和软件公司之间的那套软件的问题也适用以上规则.另外,如果该小系统的运行利用了该大系统的核心技术或主要数据程序或者小系统的运行必须依附该大系统才能得以实现等,那小系统的开发并不一定构成新的知识产权.
如果你的意思是想问,小系统直接读取软件公司设计软件的数据库，是不是有侵权行为？我的意见是,如果小系统和软件公司设计软件的所有权均归汽车公司,则不构成侵权,因为两个软件的所有权人为同一公司.如果小系统属于汽车公司,软件公司对其设计的软件有所有权,仅赋予了汽车公司使用权,则小系统的读取行为侵犯了软件公司的该软件权利,如果小系统按约定属于该员工,而大系统(软件公司开发软件的简称)属于软件公司,则该员工的行为就有可能侵犯软件公司的权利.不知道这是不是你要问的.
对补充问题二的意见:"如果大系统不运行，小系统也可以单独运行，只是部分数据要手工输入了。那么小软件有完整的知识产权么？"是的,从你说的前提来看,只要不涉及本案以外的知识产权问题,则你应该可以拥有该软件的知识产权,至于是否是完整的,还需看你和汽车公司的约定,如汽车公司与你约定,汽车公司拥有使用权,且该使用权是独占性质的,则你不能将该使用权转让或者授权给汽车公司和你以外的人使用.
对于问题三的意见:首先是保证"如果"的情况是客观事实,其次是看小系统读取的是客户关系数据还是大系统本身的数据,如果是前者,无论软件公司是否同意,一般都属于合法使用,但如果是后者,就要看软件公司是否授权你使用,如果没有授权,那基本就是侵犯了软件公司的权利,但是否会追究你的侵权责任存在主观因素,这就不好确定了.另外,如果是必须由大系统运行才能得到的结果数据,别的软件不能得到该数据,一般情况下,如果你拥有大系统的使用权,你就可以合法使用该数据,如果没有使用权就存在侵权行为,是否追究还是看软件公司的主观意志.
如何做好敏捷软件开发中的风险管理
敏捷软件开发风险管理的思路是：首先分析敏捷软件开发的特点，然后结合风险管理过程进行管理。敏捷软件开发通过其执行结构规避和减轻了常见的软件开发风险，但这也引进了开发过程的不确定，因此也蕴含了大量的风险。
敏捷软件开发的风险分类
软件开发可分为开发人员、过程、产品和技术四个维度，它们互相联系和统一，共同决定了软件开发的速度和效率。
（1）人员风险。人员风险有沟通不畅，缺乏协作，人员变动，素质低下，矛盾和冲突，缺乏激励，士气低下，对业务不理解，缺乏优秀人才，缺乏客户介入等。
（2）技术风险。技术风险有伪敏捷，架构体系不稳定，设计不佳，缺乏技能，高估新技术等。
（3）产品风险。产品风险有功能不符，需求镀金，功能蔓延，质量低下，工期延误，成本超支，客户满意度低，低产品价值，低投资回报等。
（4）过程风险。过程风险有缺乏计划，迭代掌握不佳，评估和规划不合理，缺乏风险管理，缺乏质量保证措施等。
敏捷软件开发的风险处理
在敏捷软件开发过程中从人、过程、产品和技术四个纬度进行的风险处理过程。
（1） 人员风险
敏捷软件开发通过频繁沟通、每日站立会议、反馈等方式解决了沟通不畅，缺乏协作的问题；通过领导、结对编程、代码集体所有权等方式促进团队协作，提高技能素质，应对人员变动，降低矛盾和冲突；通过频繁的产品发布提高人员成就感和士气；通过现场开发，降低缺乏客户介入的风险。
（2） 技术风险
敏捷软件开发通过迭代、测试套件、重构等方式适应变化和演进，避免了传统的开发方法在一开始就进行架构及设计，从而导致架构体系不稳定和设计不佳的风险。对于敏捷技能险，可以通过引入敏捷教练、结对编程、学习环的方式加以应对。
而对于非敏捷软件开发所特有的普适性技术风险，可以通过组织和加强内部技术人员的培训和培养，引进能解决项目关键问题的优秀人才，防止优秀人才的流失等方式进行规避。
（3） 产品风险
敏捷软件开发通过迭代、反馈、客户参与的方式解决了构建错误产品、功能蔓延、需求镀金、质量低下、客户满意度低等风险。可以通过综合考虑功能价值和风险，按照高风险高价值→低风险高价值→低风险低价值→高风险低价值的顺序开发产品功能，渐次降低产品的价值风险；通过对净现值、内部收益率、回收期、贴现回收期等经济指标的综合分析，规避项目的投资回报风险。
（4）过程风险。敏捷软件开发通过产品→发布规划→迭代规划→任务逐渐瞄准的形式，极大地消除了各种不确定风险。
对于软件开发过程的进度风险，可以通过设置功能缓冲区和进度缓冲区，从功能和进度两个方面保护项目免受不确定性的冲击；也可以从以下三个方面对进度风险进行定量分析。
①N=S/V(N：估算的项目总迭代数，S：项目的总故事点数，V：速率，是基于历史数据计算的每一次迭代所能完成的故事点数)。
②用正态分布N(μ,σ的平方)，得到每一次迭代的平均故事点数X和标准差σ，计算μ=(S/N-X)/σ，并得出项目按时完成的概率。
③综合正态分布，PERT分布，三角分布进行蒙特卡罗模拟，得出模拟的结果并绘制累计完成的概率分布。
软件开发都有哪些风险的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件开发都有哪些风险隐患、软件开发都有哪些风险的信息别忘了在本站进行查找喔。
