软件质量属性设计

最近正好想写一篇质量属性如何设计的文章，看了温昱先生的书之后，很是兴奋，验证了我个人的一些想法，下面基于我实际经历的一个项目，结合对《软件架构设计》一书所讲，谈一下质量属性如何设计。

首先介绍一下项目背景，某大型电信解决方案提供商向全球电信运营商提供某软件系统，因不同的运营商需求有差别，需要投入大量的人力物力对某个特定的运营商进行客户化定制，成本较高，为了降低定制成本，该提供商将交付组织切分为负责通用版本的组织A和负责针对特定局点定制的交付组织B，且成立了一个项目专门提升该软件系统的可定制性，以实现这种分级交付，降低定制成本。

项目启动后，负责该项目的架构师凭借丰富的经验马上启动了架构设计，他从业界同类产品了解到，业界为了提升定制能力采用了元数据驱动的架构风格，于是马上开始了元数据驱动框架的设计，设计好之后召集开发人员和管理人员开了个沟通会，会中，该架构师被两个问题难住了：

1）有个定制开发人员问，如果基线版本升级了，能否保证定制版本做的修改能够被直接继承？在这个问题上，大家发生了激烈的争论，架构设计团队认为有些场景可以，有些场景不可以，而定制开发人员的理解跟架构设计团队的理解不一样，最终该问题被搁置下来，后续再论。

2）管理人员问，对定制能力目标，我们怎么测试和验证目标是否达成。这个问题比较毒，一下子把架构设计团队问傻了，没人答得上来，于是被骂了一顿。

问题在哪里？？看了《软件架构设计》的第9章“概念性架构设计”就能找到答案：“没有依据场景来做设计”。我认为的问题有：

1）没有从系统各Actor的角度，分析定制用例，导致重要定制场景遗漏，被问起的时候自然就捉襟见肘；

2）没有将定制能力目标分解到定制场景，导致对设计缺乏度量，不知道设计到底能不能满足定制能力目标要求，自然也回答不了“通用版本与定制版本的边界”这类的问题。

要怎么做呢？？看了《软件架构设计》的第9章“概念性架构设计”给出了方法：质量属性目标——质量属性场景——决策。我再结合自己的经验，对此方法进行一下细化，我认为应该遵从下面的步骤，才能确保定制目标的达成：

1）分析定制的Actor，比如定制开发人员，定制运维人员等；

2）针对各Actor，分析其定制用例，如开发人员增加一个业务、修改一个业务流程、增加一个业务实体字段等等；

3）针对每个用例，结合定制能力目标，分析该Actor的工作流程，通过这一步的分析，通用版本的边界（系统用例）能够大致识别出来。

4）再针对关键系统用例，进一步使用分析对象进行鲁棒分析；通过这一步，对元数据驱动框架的能力要求能明确下来；

5）然后在进一步对元数据驱动框架进行细化设计；

6）提取一个关键用例，基于设计方案进行验证，看看是否达到设计目标，如果达不到，需要再增加元数据驱动框架的场景覆盖广度或者覆盖厚度。

通过这样一个系统的方法和流程，我们才能保证做出符合业务目标的可定制性设计。其它类型的质量属性的设计方法和流程也是类似的。

其实那个负责可定制性设计的架构设计团队不管是业务经验还是技术能力，都是比较扎实的，关键是没有掌握一个比较科学的设计方法和流程。因此，广大程序员兄弟们在实践的同时，一定不能忘了提升理论素养，这样才有利于更早的打破天花板，获得更大的成功。