系统质量属性
根据GB/T 16260.1 定义，从管理角度对软件系统质量进行度量，可将影响软件质量的主要因素划分为6种维度特性包括：功能性、可靠性、易用性、效率、维护性、可移植性
开发期质量属性
开发期质量属性包括：易理解性、可拓展性、可重用性、可测试性、可移植性
运行期质量属性
运行期质量属性包括：性能、安全性、可伸缩性、互操作性、可靠性、鲁棒性
质量属性场景描述
质量属性场景是一种面向特定质量属性的需求，由6部分组成：刺激源、刺激、环境、制品、响应、响应度量
- 刺激源：这是某个个生成刺激的实体。
- 刺激：该刺激是当刺激到达系统时需要考虑的条件
- 环境：该刺激在某些条件内发生。当激励发生时，系统可能处于过载、运行或者其他情况。
- 制品：某个制品被激励。这可能是整个系统，也可能是系统的一部分。
- 响应：该响应是在激励到达后所采取的行动。
- 响应度量：当响应发生时，应当能够以某种方式对其进行度量，以对需求进行测试。
面向架构评估的质量属性
性能
是指系统的响应能力，及要经过多长时间才能对某个事件做出响应，或者在某段事件内系统所能处理的事件的个数。经常用单位时间内处理事务的数量或系统完成某个事物处理所需的时间来对性能进行定量标识。性能测试经常要使用基准测试程序。
性能质量属性场景
- 刺激源：用户请求、其他系统触发等
- 刺激：事件（定期、随机、偶然事件）
- 制品：系统
- 环境：正常模式、超载模式
- 响应：处理刺激、改变系统状态
- 响应度量指标：处理时间所花时间、单位时间内处理事件的数目、处理的错误率/丢失率
提升性能的策略
可靠性
可靠性是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特征，通常用来衡量在规定的条件和时间内，软件完成规定功能的能力。通常用平均失效等待时间MTTF 和平均失效间隔时间 MTBF 来衡量。在失效率为常数和修复时间很短的情况下，MTTF 和 MTBF 几乎相等。可靠性分为两个方面：
软件/硬件可靠性对比
软件可靠性定量描述
- 平均失效前时间（MTTF）：Mean Time To Faliure：从t=0 时到故障发生时系统的持续运行时间的期望值，不包括老化失效。
- 平均恢复前时间 （MTTR）Mean Time To Restoration：从出现故障到修复成功的一段时间
- 平均故障间隔时间（MTBF）Mean Time Between Failures：失效或维护中所需的平均时间，包括故障时间以及检测和维护设备的时间；MTBF = MTTF+ MTTR
影响软件可靠性的因素
软件可靠性建模
可靠性建模的步骤包括：模型假设、性能度量、参数估计方法、数据要求
- 模型假设。模型是实际情况的简化或规范化，总要包含若干假设，例如测试的选取代表实际运行剖面，不同软件失效独立发生等。
- 性能度量。软件可靠性模型的输出量就是性能度量，如失效强度、残留缺陷数等。在软件可靠性模型中性能度量通常以数学表达式给出。
- 参数估计方法。某些可靠性度量的实际值无法直接获得，例如残留缺陷数，这时需要通过一定的方法估计参数的值，从而间接确定可靠性度量的值。估计是通过收集到的失效数据进行统计分析，利用一定的推导过程归纳出模型的参数；预测则是使用软件产品自身的属性和开发过程来确定模型的参数，这种方法可以在开始执行程序前完成。
- 数据要求：一个软件可靠性模型要求一定的输入数据，即软件可靠性数据。不同类型的软件可靠性模型可能要求不同类型的软件可靠性数据。
软件的可靠性模型分类
| 选取软件输入域中的某些样本“点”运行程序，根据这些样本点在“实际”使用环境的使用概率的测试运行时的成功/失效率，推断软件的使用可靠性。 | |
软件可靠性管理
软件可靠性管理分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、实施阶段
软件可靠性设计
- 容错设计
- 恢复快设计：恢复快方法是一种动态的故障屏蔽技术，采用向后恢复策略。
- N版本程序设计:N版本程序设计是一种静态的故障屏蔽技术，采用向前恢复的策略。（订单、对账、清算工作）
- 防卫式程序设计：通过在程序中包含错误检查代码和错误恢复代码，使得一旦发生错误，程序就能撤销错误状态，恢复到一个已知的正确状态中去
- 冗余设计：改善软件可靠性的一个重要技术是冗余设计。在硬件系统中，在主程序运行的系统之外备用额外的元件或系统，如果出现一个元件故障或系统故障，则立即更换冗余的元件或切换到冗余的系统，则该硬件仍可以继续维持运行。在软件系统中，冗余技术的运用有所区别。如果采用相同两套软件系统互为备份，其意义不大，因为在相同的环境中，一套软件出现故障的地方，另外一套也一定会出现故障。软件冗余设计技术实现的原理是在一套完整的软件系统之外，设计一种不同路径、不同算法或不同实现方法的模块或系统作为备份，在出现故障时可以使用冗余的部分进行替换，从而维持软件系统的正常运行。
- 检错技术
- 采用检错技术要着重考虑几个要素：检测对象、检测延迟、实现方式和处理方式
- 检测对象：包含两个层次的含义，即检测点和检测内容。在设计时应考虑把检测点放在容易出错的地方和出错对软件系统影响较大的地方；检测内容选取那些有代表性的、易于判断的指标。
- 检测延时：从软件发生故障到被自检出来是有一定延时的，这段延时的长短对故障的处理是非常重要的。因此，在软件检错设计时要充分考虑到检测延时。如果延时长到影响故障的及时报警，则需要更换检测对象或检测方式
- 实现方式：最直接的一种实现方式是判断返回结果，如果返回结果超出正常范围，则进行异常处理。计算运行时间也是一种常用的技术，如果某个模块或函数运行超过预期的时间可以判断出现故障。另外，还有置状态标志位等多种方法，自检的实现方式要根据实际情况来选用。
- 处理方式：大多数检错采用：查出故障-停止软件系统运行-报警的处理方式，但也有采用不停止或部分停止软件系统运行的情况，这一般由故障是否需要实时处理来决定。
- 降低复杂度设计
- 系统配置技术
- 系统配置技术主要包括双机热备、双机互备、双机双工、服务集群技术
- 双机热备：双机热备即是目前通常所说的active/standby方式，服务器数据包括数据库数据同时往两台或多台服务器写，或者使用一个共享的存储设备。当 active服务器出现故障的时候，通过软件诊测(一般是通过心跳诊断)将standby机器激活，保证应用在短时间内完全恢复正常使用。
- 双机互备：在双机热备的基础上，两个相对独立的应用在两台机器同时运行，但彼此均设为备机，当某一台服务器出现故障时，另一台服务器可以在短时间内将故障服务器的应用接管过来，从而保证了应用的持续性。这种方式实际上是双机热备的一种应用。它避免了两个应用使用四台服务器分别实现双机热备。
- 双机双工：两台或多台服务器均为活动，同时运行相同的应用，保证整体的性能，也实现了负载均衡和互为备份。需要利用磁盘柜存储技术(最好采用san)。对于数据库服务而言，它同时需要数据库软件的支持，是比较复杂的。而WEB服务器或应用服务器就比较简单了。
- 服务器集群技术：集群技术是指一组相互独立的服务器在网络中组合成为单一的系统工作，并以单一系统的模式加以管理。此单一系统为客户工作站提供高可靠性的服务。大多数情况下，集群中所有的计算机拥有一个共同的名称，集群内任一系统上运行的服务可被所有的网络客户所使用。
可靠性测试
可靠性评价过程
可靠性的评价过程包括：选择可靠性模型、收集可靠性数据、可靠性评估和预测
可用性
可用性是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
可用性质量属性
- 刺激源：故障（来自系统内部或外部）
- 刺激：系统出错，系统崩溃（反复出错），给出结果不及时，给出错误结果
- 制品：计算或存储或网络
- 环境：正常状态，降级模式
- 响应：错误报告，回传厂家；通知管理员或其它系统；关闭系统，系统在维修期间不可用
- 响应度量指标：故障时间百分比，平均故障修复时间，平均无故障时间
提升可用性的策略
安全性
是指系统在合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性可根据系统可能受到的安全威胁类型来分类。安全性又可分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程。完整性保证信息的完整和准确，防止信息被非法修改；不可否认性是指信息交换的双方不能否认其在交换过程中发送信息或接收信息的行为；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
安全性质量属性场景
- 刺激源：正确识别、非正确识别；授权、未授权
- 刺激：试图显示数据，改变/删除数据，访问系统服务
- 环境：在线或离线、联网或断网
- 制品：系统服务、系统中的数据
- 响应：对用户身份进行认证；隐藏用户的身份；阻止或允许访问数据或服务；
- 响应度量：用成功的概率表示；检测到攻击的可能性；确定攻击或访问、修改数据或服务的个人的可能性
提升安全性的策略
可修改性
可修改性是指能够快速地以较高的性价比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价来衡量可修改性。可修改性分为4个方面
- 可维护性：这主要体现在问题的修复上，在错误发生后“修复”软件系统。可维护性好的软件架构往往能做局部性的修改并能使对其他构件的负面影响最小化。
- 可拓展性：这一点关注的是使用新特性来拓展软件系统，以及使用改进版本方式替换构件并删除不需要或不必要的特性和构件。为了实现可拓展性，软件系统需要松散耦合的构件。其目标是实现一种架构，能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的架构中也是必要的。
- 结构重组：这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构建移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
- 可移植性：可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植性，需要按照硬件、软件无关的方式组织软件系统。可移植性是系统能够在不同计算环境下运行的能力，这些环境可能是硬件、软件，也可能是两者的结合。如果移植到新的系统需要做适当更改，则该可移植性就是一种特殊的可修改性。
可修改性质量属性场景
- 刺激源：最终用户、开发人员、系统管理员
- 刺激：希望增加、删除、修改、改变功能、质量属性、容量等
- 环境：系统设计时、编译时、构建时、运行时
- 制品：系统用户界面、平台、环境或与目标系统交互的系统
- 响应：查找架构中需要修改的位置，进行修改且不会影响其他功能，对所做的修改进行测试，部署所做的修改
- 响应度量：根据所影响元素的数量度量的成本、努力、资金；该修改对其他功能或质量属性所造成影响的程度
提升可修改性的策略
提升可修改性的策略有：局部化修改、防止连锁反应、延迟绑定时间
功能性
是系统完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
可变性
是指架构经扩充或变更而成为新架构的能力。这种新架构应该符合预先定义的规则，在某些方面不同于原有的架构。当要将某个架构作为一系列相关产品的基础时，可变性是很重要的。
互操作性
作为系统组成部分的软件不是独立存在的，通常与其他系统或自身环境相互作用。为了支持互操作性，软件架构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件架构。
扫一扫
1526
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
