常见的软件开发风险和应对措施软件开发安全保证措施 _风险

我们在软件开发过程中会遇到不同的变更，代码的更新，新功能的写入，架构的调整，系统的扩容。每天有大量的需求，代码，Bug需要处理，其实我们做的每个对系统产生影响的动作背后都存在风险。那么我们如何评估和管理这些风险呢，任何一位项目的管理者或者领导者都需要了解下面提到的方法论。
对风险进行定义大家知道在做任何一次变更的时候都存在风险，比如一次新功能模块的发布会影响到几个老的功能模块，那么作为管理者如何评估这个上线的新功能的风险呢。这里介绍几种方法。
第一，直觉，这个说起来有点好笑，其实就是凭借经验丰富的程序员，架构师（老司机）的感觉去评估这次变更存在的风险。这种方式长期存在各个互联网/软件企业之中的，基本都是靠老人来带着大家踩坑。这种方式虽然多见，但是缺点很明显，就是依赖个人能力，而且具有随机性，一旦个人判断失误就真的坑了。
第二，交通灯法。还是刚才新功能的例子，我们可以把新功能影响到的老功能模块列出来，针对每个功能模块受到的影响进行“红，黄，绿”灯评价。绿灯=低风险，黄灯=中风险，红灯=高风险。然后通过团队以及专家评审的方式来判断这次新功能的上线的风险有多大。这个的好处是，减少了人为感知的风险，让风险具体化了，而且引入了团队评审的方式，让结果更加客观。
第三，故障模式及影响分析法（Failure mode and effects analysis, FMEA）。这种方式会把一个功能模块切分成几个组成部分，然后针对每个组成部分的三个维度进行打分。这三个维度分别是：故障发生的可能性，故障发生的严重性，故障检测能力水平。可以针对这三个维度进行打分，分数从1-9分不等，分数越高说明风险越高。通常我们会按照高中低三个级别来划分分值，例如：高风险：9分，中风险：3分，低风险：1分。小伙伴们可以根据自己的团体来具体设置分值不同。举个例子来说，我们有一个登录服务，有可能出现“给用户设置错误权限”的风险。因为这个权限设置都是系统管理员来设置的，那么故障发生的可能性是比较低的，我们给其打分为1分（低风险）。一旦这个权限设置错误会导致，用户看到不属于自己的信息，这个故障发生的严重性是很高的，我们给其打分了9分（高风险）。这个故障我们可以通过后台脚本的方式去针对每个用户的权限进行核对，所以故障检测能力的水平属于中等，就给3分（中风险）。如此这样我们可以把三个维度的分数相乘就是1*9*3=27 。如果这个登录功能还包含其他的组件，就以此类推评估每个组件的风险分数然后相加就是这个功能的风险分数了。如果我们希望降低发生故障的风险，就根据这个三个维度采取对应的防范措施。例如：后台定时监测用户权限，如果发现第一时间让用户和权限做隔离，并且通知客户部门给客户做解释，把风险降到最低点。如果这么做了我们就将故障发生的严重性的风险分值将下来了，从原来的9分降到3分，那么总分就是1*3*3=9分。是不是把风险控制到可控的范围内了呢。这里可以根据每个团队设计一个风险的表格把风险都记录下来。

常见的软件开发风险和应对措施 软件开发安全保证措施

猜你喜欢

常见的软件开发风险和应对措施软件开发安全保证措施