• 18651623183
软件开发中软件架构的风险驱动模型是什么?你采用风险驱动了吗?
作者:admin /日期:2020-06-20 06:48

风险驱动模型可以指导开发者运用最小的架构技术集合去降低最紧迫的风险,以求事半功倍。这就带来了一连串的问题:“我的风险是什么?用于降低这些风险的最佳技术是什么?风险是否已经缓解,可以开始(或恢复)编码了吗?”概括起来,风险驱动模型可以归纳为三个步骤:

识别风险,并排定优先级;选择并运用一组技术;评估风险降低的程度。对于无足轻重的技术,无须浪费太多的时间;对于威胁项目的风险,则不能熟视无睹。只有将好钢用在刀刃上,才能构建成功的系统。这意味着只有当架构与设计技术受风险驱动时,才运用它们去消除风险。

以风险或特征为中心风险驱动模型的核心要素在于将风险放到极为显著的位置。只有将风险暴露出来,才会去考虑它带来的影响。大多数开发者已经认识到风险的重要性,但他们要考虑的东西实在太多,结果常常忽略了这些风险。一个团队如何由采用预先设计架构转向采用纯粹的特征驱动过程。整个团队关注于交付的特性,以至于推迟了对质量属性的关注,直到项目开发终止时,该系统已处于维护期。结论显示,团队对于系统特征的关注会使得开发者转移注意力,从而忽略了其他方面的内容,这其中就包括风险。早期的研究显示,即使是架构师在权衡设计因素时,对风险给予的足够重视也比人们预期的少。

合乎逻辑的理由若是你对风险的认知不同于其他人的认知,又该怎么办?风险识别、为风险排定优先级、选择技术及对风险缓解程度进行评估,这些活动的结果都是因人而异的。莫非风险驱动模型只是一种即兴发挥?非也。虽然不同开发者觉察到的风险各有不同,因而会挑选不同的技术,但是,风险驱动模型却具有一种有用的属性,即它可以产出可供评估的论据。一个论据示例采用如下形式:

将A、B、C识别为风险,其中B为首要风险。我们会花费时间运用X和Y技术,因为这两项技术有助于降低风险B。我们对由此产生的设计结果进行评审,并一致认为已充分降低了风险B,因此决定按照该设计进行编码。

这样,就可以根据相关背景(即觉察到的风险)提供一份计划(即要用到的技术),以便回答那个宽泛的问题:“到底应该做多少软件架构工作?”

其他开发者可能并不赞成你的评估结果,因此,他们可能提供另一份采用同样形式的论据,或许认为还应该考虑风险D。从工程学角度对风险和技术的讨论就将随之而来,因为你已经阐述了支撑你的观点与意见的理由,并且可供评估。很多开发者都自认为已经采用了风险驱动模型,或相似的模型。但有迹象表明许多开发者并未做到。迹象之一就是无法将他们所面对的风险及采用的对应技术罗列出来。

任何开发者都能答出这样的问题:“你正在实现哪些特性?”但对于“你的主要失败风险及对应的工程技术是什么”这类问题,许多开发者都会感到棘手,难以回答。如果确乎将风险摆在首位,要回答这类问题就轻而易举了。

技术选择应该多样化由于项目面临不同的风险,因此开发者就应运用不同的技术。一些项目会面临棘手的质量属性需求,因此需要做预先的计划式设计;而另一些项目只是对现有系统的微调,所以失败的风险也就微乎其微。某些开发团队是分布式的,因而需要为设计编写文档以利于分布团队的知识共享;而另一些团队则是同地协作,因此便可简化这种形式。

一旦开发者未能使架构活动与风险保持一致,他们就会对架构技术使用过度或不足,抑或兼而有之。通过仔细研究软件开发的整体过程,就可以知道为何会发生这样的事情。多数组织都会要求开发者遵循一种开发过程,其中包括某种文档模板,或设计活动列表。这些内容虽然有益且有效,但也可能在不经意间引导开发者误入歧途。

下面是一些设计规则的例子,它们的出发点是好的,但却可能使得开发者采取的行动与其项目风险不相匹配。

团队必须始终(或永不)为每个项目创建完整的文档。团队必须始终(或永不)绘制类图、分层图等。团队必须在架构上投入10%(或0%)的项目时间。尽管此类指导原则聊胜于无,但不同项目面临的风险也各不相同。倘若同一套设计图或技术总能作为解决一组不断变化的风险的最佳方法,则只能说这是一种不可思议的巧合罢了。

样本不符假设一家公司构建了一个三层架构的系统。第一层是用户界面,并向互联网公开。这一层中最大的风险可能是可用性与安全性。第二层和第三层分别实现了业务规则与持久化,它们都被部署在防火墙内,最大的风险可能在其吞吐量与可伸缩性方面。如果该公司采用了风险驱动模型,则前端与后端的开发者就会运用不同的架构与设计技术来处理他们面临的不同风险。然而事实相反,经常发生的事情是两个团队采用同一个

公司的标准化开发过程或模板,而且竟然提供同一份模块依赖图。问题就在于,他们所使用的技术与面临的风险之间没有任何联系。采用标准的过程或模板未必是坏事,不过它们却常常被滥用。随着时间推移,你或许能够归纳总结出公司项目遇到的诸多风险,进而摸索出一张适用技术的列表。关键之处就在于,技术与风险相互匹配。

风险驱动软件架构的三个步骤看似简单,实则纷繁复杂,一言难尽。风险与技术要同时把握好一个度,挑选一套适用的技术,适当的时候结束架构行为,必要的时候开始或恢复构建系统。

【恒安业务】网站建设、网站设计、服务器空间租售、网站维护、网站托管、网站优化、百度推广、自媒体营销、微信公众号
如有意向---联系我们
热门栏目
热门资讯
热门标签

网站建设 网站托管 成功案例 新闻动态 关于我们 联系我们 服务器空间 加盟合作 网站优化

备案号:苏ICP备13015331号 

公司地址:南京市鼓楼区广州路328号20楼2008室 咨询QQ:309664046 手机:18651623183 电话:025-87784618