| 3.5 质量特征计划 为帮助设计者们进行设计，我们准备编写一本设计指南的书，内容包括设计中的一些有代表性的类型、模式和技术。 类型是最简单的基本结构，通常被用来定义体系结构。常见的类型的例子包括客户-服务器结构，管道与过滤结构，分层结构等等。在早期的结构选择上，按照组织体系进行选择是一种有代表性的类型。 模式是一种能够重复使用的微观结构。它通常根据其产生、结构、行为的特征进行分类。例如适配器就是一个协调型的模式。 设计技术是其它有益于设计的相关信息，它能避免一个低水平的设计。例如，数据编码的使用，用于安全性的密码保护，为使操作简便而使用应用程序接口方法(API)，等等。 在体系结构/设计中选择合适的类型、模式和技术，对能否实现设计目标具有很大的关系。例如，一个分层体系结构将有助于实现易更改性，但是降低了操作性能。设计指南一书将作为这种设计知识的仓库而为设计者提供服务。 在结构和设计阶段可以参考设计指南。我们设想设计指南具有一个简单的使用界面并发布在互联网络上，使设计者们能通过特殊的搜索工具根据其期望特征选择相关的类型、模式和技术，从而建立一个关注质量特征的体系结构。设计指南将为设计者们提供详细的入口信息，使他们能根据这些入口的适用性作出正确的选择。 3.6 过程改进 在项目开发的生命周期行为中，应该尽量使用上面提及的那些新技术。通过这些新技术，可以增强现有过程能力和过程资产(模版、指导方针、检验方法)，实现产品质量焦点一体化。 项目开发的生命周期主要包括几个阶段(或如下图所示)：  —在需求阶段明确地列出所有需要关注的特征， —在产品设计期间关注各项特征， —从产品质量角度出发对可交付产品进行检验， —确定测试案例并进行测试，检查并核实特征是否满足。 对指定的特征进行测量、跟踪和分析。 例如，需要改进的过程资产用步骤序列的形式表示如下： —暂时不考虑计划 —需求手册模板 —设计(HLD,LLD)模板 —预演指导方针 —检验指导方针 —帐目检查表 —测试计划文档/测试案例文档 —发布检查表 —用户满意度调查程序及其提问单 来自发展组织内部的软件质量工程师、过程工程师以及软件质量改进的支持者们都致力于改进过程的创新工作，他们在总结以往经验的基础上为改进过程设立了基线。当OPG(组织过程组)提出一个POR(过程时机报告)时，意味着开始进行过程改进。一旦对所有过程都实施了改进，我们将计划召开Educom(教育/交流)会议来对组织内部进行沟通。 3.7 评价标准 产品质量的评价标准可以被分为两大类，即：内在的评价标准和外在的评价标准。内在的评价标准与产品自身相关，而外在的评价标准与开发者为满足产品目标所付出的努力相关。下表列出了部分与产品自身相关的内在评价标准：
如果内在的评价标准之间存在各种关联，那么采用该标准并不能明确地区分各个特征目标。因此，在通常情况下，我们建议采用外在的评价标准对产品质量特征进行评价。 3.7.1 改进性 任何一个改进性规范的目的都将为适应变化所需付出的努力程度分为低/中/高三类。在下表中，对低/中/高三种努力程度的含义给出了一种可能的解释。该表相对于某个特定项目是十分准确的。
在体系结构或设计阶段的最后，可以分析得出产品质量的外在的评价标准，如下所示： 1）已满足改进目标的百分比 2）不能满足的改进目标个数(低努力程度) 3）不能满足的改进目标个数(中努力程度) 4）不能满足的改进目标个数(高努力程度) 可以采用SAAM方法[4]对体系结构或设计进行分析，以获得上面这些评价标准。 3.7.2 操作性 下面的评价标准可以用来跟踪操作性目标。 1）实现的操作性目标的百分比：在设计阶段，依照操作性规范对项目的每一个入口的设计都进行分析。在测试阶段，通过测试案例来验证产品是否达到操作性规范的要求。 实现的操作性目标的百分比 = （已实现的操作性目标的个数/操作性规范中要实现的目标的总个数）*100% 2）在设计/测试阶段结束后，可以通过图表来反应操作性规范中每个目标计划值与实际值之间的差异。 例如：屏幕刷新率 1—5秒 1sec 5sec 1sec 5sec  3.7.3 可用性 接下来讲述的评价标准是与产品的可用性相关的，在SUMI方法中，对初始阶段的任何原型的改进或在完成之后对产品的评价都需要使用可用性评价标准。该标准使用一些0—70范围内的数值进行评价。 1）综合 该评价标准反应用户对于可用性的理解的综合观点 2）效率 该评价标准反应用户对于该软件能否通过一种有效的方式来完成工作任务的看法。 3）影响 该评价标准反应软件对用户产生的心理影响。即用户使用该软件而产生的精神压力和身体压力。 4）作用 该评价标准反应用户对软件能产生的作用大小的认可程度。 5）控制 该评价标准反应用户在使用软件的过程中的舒适程度。如果用户可以比较容易的使用软件实现他所希望实现的目标，那么该软件具有良好的控制性。 6）容易掌握 该评价标准反应用户是否能够轻松地掌握软件的使用方法并开始使用。 3.7.4 有效性 该评价标准与the five 9的系统有效性小组所提出的标准相同。 1）nines的个数 2）无效性原因的排列图 4. 基本的指导 SMAP2000小组在需求分析阶段就指定产品的质量特征作为设计的目标。他们把产品的操作性、可用性、可改进性作为产品的重要特征。项目小组在这些活动上大约花费了17个工作日(估计值)，但可以使项目从以下几个方面受益。 1）改善了图形用户界面设计，并增加了有用的设计观点。 2）有助于从用户那里获取他们对软件的操作性能期望并在可解决的范围内识别约束条件(例如带宽)。 3）通过改进的观点帮助项目小组对当前产品的试用版本进行思考，帮助他们获得改进的最新理解。它使产品的结构观发生了转变，从“能适应当前SMAP-2G的执行”转变为“一个应用程序的网络管理平台”。 4）特征规范可以应用于综合集成和现场实验，还可以用来解释工具的操作行为。 5）它能满足过程改进体系结构的需要。 6）对这些特征的研究使设计人员能更好地理解部分的功能需求。 特征规范文档可以在http://libra.miel.mot.com/~3gtoolscm/ 3G_smap.html获得。 当前，正在对项目设计进行操作性分析，计划采用SAAM方法针对改进性进行设计分析。 在MIEL中的其它产品计划(如SinglecellWiLL，VOIP)也已经开始采用这种方法进行分析。 5. 实施步骤 我们可以对产品质量特征或设计目标进行明确地识别，并制订一个规范，以此作为出发点。在实施过程中要注重建立过程资产，比如反应不同风险承担者对软件产品质量所持观点的提问单，描述与质量特征相关的一般性概念的骨架图，已开发的用于获取产品操作性和可用性规范的模板。在每次实施过程中我们也至少参与一个项目，对产品质量特征和设计目标规范进行实践，以便为其他类似项目进行同一个实施过程时所借鉴。 最近，在组织范围内成立了产品质量支持小组，小组成员来自工作台(商业部门)。他们在产品质量改进计划中的任务如下： —在产品质量改进计划(PQIP)中充当消费者咨询委员会(CAB)的角色，为用户提供咨询 —参与计划/策略/过程的改进，并提出明确意见 —对产品质量改进计划(PQIP)的可交付产品进行检查并提出反馈意见 —在各自的Ops中扮演支持者的角色： —确定急需改进产品质量的侯选项目 —在规范、设计、分析、测试、验证期间，通过相应专家的参与，确保在项目中对产品质量的关注 —促进产品质量技术的广泛应用并在Ops中进行实践 与当前角色相对应的职责如下表所示：
6. 结论 产品质量改进计划通过关注操作性、可用性、有效性、改进性等质量特征，促使组织开发出更好的产品。改进过程通过一系列额外的活动来满足产品质量特征，使不同的风险承担者(包括用户、系统工程人员、系统专家和销售人员、软件工程人员、产品改进人员等等)在整个产品开发周期内关注产品质量。而且，本文所讨论的产品质量改进活动和技术也有助于巩固CMM模型的软件质量管理关键过程域。 组织应为实施产品质量改进计划提供支持，它有助于提高用户对产品和解决方案的满意度，从而使得用户继续使用该产品成为可能。该计划也涉及到少数的关键技术实践(如设计分析)，从而增强MIEL的整体过程成熟度。 7. 参考书目 [1]"Attribute-based architecture development", Krishnan Rangarajan, Kashinath Kakarla, Deepti Arora, Proceedings APSES-98, pp 381-387. [2]"Architecture"Attributes"for"SMAP2000",http://libra.miel.mot.com/~3gtoolscm/ 3G_smap.html [3]"Software Metrics for Product Assessment", Richard Bache, Gualtiero Bazzana, Mcgraw-Hill Book Company, 1994. [4]"Scenario-Based Analysis of software Architecture", Kazman, R., Abowd, G., Bass, L., and Clements, P., IEEE Software, 13(6):47-56, 1996. [5] http://www.usability.serco.com [6]"Experiences with Architecture attribute analysis", Lakshmi and Suresh Kumar Chintada, submitted for APSES99. [7]"Looking beyond customer satisfaction", Jyoti, submitted for APSES99. [8]"Information Needs in analysis of Telecommunication software - a case study", Vesa Hirvisalo, Esko Nuutila. [9]"Problems in practice of performance engineering", Mark H. Klein, CMU/SEI-95-TR-020, ESC-TR-95-020, Feb 1996. [10]"Testing for Non-functional attributes", Santhosh C.K and Krishnan Rangarajan, submitted for APSES99. [11] http://5nines.mot.com/ [12]"Usability analysis with SUMI method", Krishnan Rangarajan, Jacob Jacob, S.C Nirmala, P.Rajshekar Swamy, submitted for APSES99. |