软件架构的风险消除策略

1.2 软件架构的风险消除策略

 

架构设计的依据是什么？当然是需求，但架构设计思想中最有价值的东西，莫过于用风险分析来驱动架构设计，为什么这是个有价值的策略呢？因为一个产品设计中要考虑的问题很多，但只有在发现风险与消除风险的过程中，发现和抓住高风险的部分，才可以针对潜在威胁有重点地提出设计解决方案，甚至改变我们的设计思想，从而设计出更加良好的产品。

一、用风险分析驱动架构设计

1，在项目不同阶段风险的特点

1）通过风险分析发现问题

设计的要义是发现问题并解决问题，通过分析所面临的重点问题，找到解决方案。没有解决问题的设计并不是好设计，而通过识别和分析风险，可以帮助我们发现问题。一般来说，项目的开发可以分为四个大的阶段，包括初始阶段、细化阶段（也称架构阶段）、构建阶段、交付阶段。在不同阶段的风险曲线大致如下图所示。

2）风险的特征是分阶段的

有效的风险管理包括通过利益相关方的合作和参与，并主动地进行风险标识。从一般的规律上可以看出：初始阶段由于对信息掌握得不充分，项目的风险是比较大的。细化阶段的风险管理应处理可能危及关键目标实现的问题，在架构验证时风险达到最高，这是因为中间会多次改变方案，很可能重新选择技术路线，直到风险大幅下降。当风险下降到拐点的时候，也就是大部分风险都在细化阶段得到了解决，就可以进入构建阶段了。最后，在交付阶段，由于迭代开发是逐次交付的，所以风险不会变大。这与瀑布开发到了交付阶段风险突然增大形成明显的区别。

3）不同阶段的关注点

从风险的特点来看，大多数情况下细化阶段和构建阶段对风险处理的关注点是不一样的。

l 在细化阶段：主要关注对产品总体质量产生影响的风险，这种风险一般都比较大、比较关键、而且处理困难。

l 在构建阶段：主要关注为了在预算范围内完成项目的大量相关具体工作的风险，这种风险大多数与后期由于需求变更与频繁修改，对进度造成不良影响相关。

    这两种风险的差异导致了设计工作特征上的不同。由于细化阶段是一种典型的探索性工作，也是风险最高的阶段，所以从人员配备上看，需要有一个小型的、强于探索的、高水平的、能够解决风险的团队。这也是为什么任何项目开发都需要一个高水平的架构团队的原因，架构师的水平不足本身就是风险。

 

2，细化阶段的关注点

系统架构是早期化解高风险的重要媒介，细化阶段的主要关注点是：对初始阶段建议采用的技术路线进行证明，并且在这个技术路线上充实一些必要的细节，以保证将来能够按质量要求交付出解决方案。

1）架构并不完全是概要设计

很多人认为架构设计就是概要设计，这是不正确的。概要设计还是停留在图纸上，而架构必须证明这个技术路线可行，并且能够证明大多数质量风险已经得到了解决。

从另一方面讲，架构设计也并不完全指的是整体解决方案，事实上即使在很细节的组件设计层面，仍然需要根据构建阶段的风险，仔细设计每一部分的体系结构，并且体现出良好的设计思想。换句话说，设计中处处有架构，这和概要设计仅仅在概要层面想问题是不同的。

2）细化阶段需要实现一些必要场景

如何才能证明技术路线可行？这就需要在细化阶段额外实现一些必要的场景，这就是架构原型的作用。如果在细化阶段大家认为这个技术方案是合理的，并且解决了项目中如果不解决就会对项目产生威胁的问题，那么团队就会对这个项目充满信心。在这个消除技术风险的工作中，我们能够得到一些有价值的额外信息，使项目剩余阶段估计和计划的可靠性也高很多。

3）细化阶段的进度特征

正是由于细化阶段是高风险的，所以进度斜率会远远小于构建阶段，如下图所示。

要注意，在细化阶段初期的一两次迭代中，风险总量会有所增加，这是由于在技术探索中会发现过去没有发现的问题。随着对技术风险的明确应对，风险在后期就开始下降。这中间会遇到多次返工，以及多个技术方案同时开发进行比对的情况，所以进度曲线比较缓慢，这可以理解。在风险曲线的拐点，也就是风险由急变缓的那一点，也就是细化阶段结束构建阶段开始的时候了。

 

为什么在细化阶段（或称架构阶段）主要的风险是质量风险呢？首先，产品的质量指标主要是由总体解决方案来决定的，架构是满足质量指标最关键的设计位置。另一方面，没有质量的产品永远不是好的产品。例如在验收的时候，产品的功能要求都达到了，但是客户认为产品可靠性、可恢复性、安全性、吞吐量、性能等方面没有达到要求，客户会怎么办？

二、质量风险对架构设计的影响

在细化阶段，我们需要关注的主要风险就是质量风险，并且希望通过合理的架构设计，使这些质量风险得以缓解。架构师在进行具体的架构设计之前，首先就需要花足够的精力来研究产品的质量要求，对质量的追求也往往会形成一些特殊的系统架构风格。

 

1，软件质量控制是一个系统

随着社现代社会运转的速度越来越快，人们对于自动化系统的依赖也越来越大，这就对软件质量提出了更苛刻的要求。但是，由于赶工缩短开发时间造成的质量问题不断出现，当工期和质量发生矛盾的时候，为了工期而放弃质量控制的案例比比皆是。

产品质量控制是一个系统，单点质量没什么意义，必须整体上每个控制点的质量都要好，这就需要付出巨大的努力。要注意到从系统的角度看质量是一个乘法，总体质量是每个单点质量乘在一起的，只要有一个点质量是是0，总的质量就是0。仅仅某一个部分质量好并不等于总体质量就很好，一个小小的bug引起了对整个体系质量的否定，关于质量的这个原理我们都要铭记于心。

质量的最高境界是什么呢？是尽善尽美，是“零缺陷”。这种境界似乎是不可达到的，但是我们不要忘了，软件是由人开发的，如果人们不能严于律己，堕落就会很快。软件企业应该根据自身实力和用户期望来设定质量目标，过低的质量将会毁坏企业声誉，而过高的质量目标有可能导致成本过高而拖累企业，这既需要平衡并且抓住重点。

 

2，质量属性决定了架构风格

在进行系统架构设计的时候，要注意到一种架构的风格，很大程度上与设计者如何满足质量要求的对策有关。需求的功能和非功能两方面都可能有质量要求，具体归纳如下。

1）与功能性有关的质量属性

和功能性有关的质量属性主要包括：

l 正确性ÿ