软件质量工程的标准和模型
本文定义并描述ISO 9000和IEEE软件标准,以及SEI能力成熟度模型集成(CMMI)的开发、服务和获取评估模型。
软件工程协会(SEI Software Engineering Institute)将标准定义为 "制定并用于规定获取、开发或服务的一致方法的正式要求,"(SEI 2010)。标准通过对规则、要求、指南或特征的说明,为软件开发和其他活动定义了一种有规律的、一致的方法。标准旨在促进社区或组织的最佳利益,并应以科学、技术和实践经验的综合成果为基础。
在指定、开发、审查、审计、评估或测试一个系统、过程或产品时,标准被用作比较的基础。当一个组织和/或其人员将标准中所说的应该做的事情与该组织和/或其人员实际所做的事情相比较时,就符合了标准。当标准要求的内容与产品的实际特性、内容或状态相匹配时,产品就符合了标准。一个标准通常是由标准实践规定的,或者是由指定的标准机构(ISO、IEC、IEEE、OMG等)定义的。标准可以指定对项目或活动的要求,包括。
- 大小:例如,一个外部接口标准可能规定通信包的大小为32字节。
- 内容 :。例如,IEEE关于系统和软件工程配置管理的标准828(IEEE 2012)规定了配置管理计划应包括的内容
- 价值:例如外部接口标准可能会规定在该接口上传输的错误代码的价值。
- 质量:例如,建模和编码标准提供了生产高质量软件工作产品的工艺标准,ISO 9001:2015标准(ISO 2015)规定了有效实施质量管理体系(QMS)的要求。
在组织层面,标准使专业人员更容易在组织内的项目和产品团队之间流动,减少了培训所需的努力。通过使用标准,组织内不同小组开发的软件更加一致和统一,因此更容易集成和重复使用。事实上,每个人都知道并理解获取、开发和/或维护软件产品的标准方式,这就允许用统一的方法来审查产品和项目的状态。
在行业层面上,标准可以通过提供良好的实践机会来提高学科的专业性,这些实践是由软件行业有经验的从业者定义的。许多公司以ISO和IEEE标准为基准,作为改进自己的流程和实践的基础。标准还可以帮助将新的技术和方法引入软件行业。例如,来自对象管理小组(OMG 2015)的系统建模语言(SysML)标准帮助引入了一种一致的方法,可用于指定、分析、设计、验证和确认系统和系统中的面向对象的需求和设计。
应该注意的是,指南(guidelines)与标准不同。标准和指南通常都是由一些权威机构发布的。然而,标准定义了要求,而指南定义了建议的实践、建议、方法或程序,被认为是良好的实践,但不是强制性要求。
模型是对一个项目或过程从一个特定角度的抽象表述。一个模型表达了一个项目或过程的某些方面的基本内容,而没有给出不必要的细节。模型的目的是使有关人员能够思考、讨论和理解这些基本要素,而不被过多或复杂的细节所困扰。与标准不同,模型是沟通的工具,而不是强制性要求。用于开发的能力成熟度模型集成(CMMI)(SEI 2010)和生命周期模型(瀑布式、V型或螺旋式)是模型的例子。
ISO 9000
国际标准化组织(ISO)是一个由国家标准机构(ISO成员机构)组成的全球联盟"(ISO 2015)。ISO制定了9000系列标准,以定义质量管理和质量保证领域的良好做法。这些标准定义了质量管理系统的基本、第一层次。它们的实施并不能保证高质量。
在ISO 9000系列中,核心标准包括。
- ISO 9000:2015质量管理体系-基础和词汇
- ISO 9001:2015质量管理体系-要求
- ISO 9004:2009 为组织的持续成功而管理--质量管理方法
ISO还提供了一套辅助标准/指南,以帮助组织建立和改进其质量管理体系、流程或活动。这些支持性标准/指南的清单包含在ISO 9001:2015标准(ISO 2015)的附件B中。
ISO 9000系列标准基于七项质量管理原则,适用于任何组织,包括软件、制造和/或服务,包括。(ISO 2015; ISO 2015a)
- 以客户为中心
- 领导力
- 人员参与
- 过程方法
- 改进
- 基于证据的决策
- 关系管理
ISO 9001:2015标准定义了一套具体的质量管理体系要求,这些要求被注册机构用来审核和认证组织。ISO 9001:2015采用过程方法,其中包含了计划-执行-检查-行动(PDCA Plan-Do-Check-Act )循环和基于风险的思考。
一些行业对ISO 9000系列标准做出了特定的解释,或称附加条款。这样做是为了规范其行业对ISO 9001:2015的解释和/或增加行业特定的额外要求。这些特定行业的解释也有助于确保审核员接受培训并了解这些行业的具体需求。行业特定标准的例子包括。 - ISO/IEC 90003:2014 软件工程--ISO 9001:2008对计算机软件的应用指南,截至本书出版之日,尚未更新为ISO 9001:2015版本
- 用于航空、航天和国防的AS9100(以及针对可交付软件的AS9115)。
- 用于汽车行业的ISO/TS 16949
- 电信业的TL9000
- 医疗设备的ISO 13485和医疗设备软件的ISO 62304
- 石油、石化和天然气的ISO/TX 29001
- 核电的NQA 1
IEEE软件工程标准
IEEE计算机协会的软件和系统工程标准委员会制定并维护一套软件和系统工程标准。这套IEEE标准并不总是被逐字逐句地使用,但它们被广泛地用作基准、模板和行业良好实践的例子,各组织根据自己的具体要求进行调整。对于确定其软件流程的组织,这些标准可以提供指导,最大限度地减少时间和精力。这些标准也可以作为检查清单,帮助验证重要项目不被忽视。
ISO 9001:2015和CMMI模型为良好的软件质量工程实践集提供了路线图,而IEEE的软件和系统工程标准则提供了更详细的 "如何做 "的信息和指导。截至本出版物发布之日,IEEE软件和系统工程标准的当前列表包括以下与注册软件质量工程师(CSQE)知识体系主题密切相关的标准。请参阅IEEE软件和系统工程标准网站,了解这些和其他IEEE软件和系统工程标准的最新版本。
- 730-2014-软件质量保障流程
- 828-2012-系统和软件工程的配置管理
- 829-2008-软件和系统测试文件
- 982.1-2005-《软件可依赖性方面的标准衡量标准》。
- 1008-1987(2009年重申)--软件单元测试
- 1012-2012-系统和软件核查与验证
- 1016-2009-系统设计-软件设计说明
- 1028-2008-软件审查和审计
- 1044-2009-软件异常情况的标准分类
- 1061-1998(2009年重申)--软件质量度量方法学
- 1062-2015--软件采购的推荐做法
- 1220-2005(2011年重申)--系统工程过程的应用和管理
- 1228-1994(2010年重申)--软件安全计划
- 1320.1-1998 (2004年重申) - 功能建模语言-IDEF0的语法和语义
- 1320.2-1998(2004年重申)-概念建模语言-IDEF1X97(IDEFobject)的语法和语义
- 1490-2011-采用项目管理协会(PMI®)标准--《项目管理知识体系指南》(PMBOK®指南)--第四版
- 1517-2010-系统和软件生命周期过程-重用过程
- 1633-2008-软件可靠性的推荐实践
- 12207-2008-系统和软件工程-软件生命周期过程
- 14102-2010-采用ISO/IEC 14102:2008《信息技术--CASE工具的评估和选择指南
- 14471-2010-采用ISO/IEC TR 14471:2007《信息技术--软件工程--CASE工具采用指南》。
- 14764-2006-ISO/IEC软件工程国际标准-软件生命周期过程-维护
- 15026-n-采用ISO/IEC 15026-1《系统和软件工程-系统和软件保证》的标准
- 第1-2014部分。概念和词汇
- 第2-2011部分。保证案例
- 第3-2013部分。系统完整性等级
- 第4部分-2013年。生命周期中的保证
- 15288-2015-ISO/IEC/国际标准--系统和软件工程--系统寿命周期过程
- 15289-2015-ISO/IEC/国际标准--系统和软件工程--生命周期信息产品(文档)的内容
- 15939-2008-标准采用ISO/IEC 15939:2007-系统和软件工程-测量过程
- 16085-2006-ISO/IEC 16085:2006-软件工程-软件生命周期过程-风险管理
- 16326-2009-ISO/IEC/International Standard 系统和软件工程-生命周期过程-项目管理
20000-n-标准-采用ISO/IEC 20000-1:2011,信息技术-服务管理- 第1-2013部分。服务管理系统要求
- 第2-2013部分。服务管理系统的应用指南
- 24748-n-指南--采用ISO/IEC TR 24748系统和软件工程--生命周期管理
- 第1-2011部分。生命周期管理指南
- 第2-2012部分。ISO/IEC 15288(系统生命周期流程)应用指南
- 第3-2012部分。ISO/IEC 12207(软件生命周期流程)应用指南
- 24765-2010-系统和软件工程-词汇表
- 24774-2012-指南-采用ISO/IEC TR 24474:2010系统和软件工程--流程描述的生命周期管理指南
- 26702-2007-ISO/IEC系统工程-系统工程过程的应用和管理
- 29119-n-软件和系统工程-软件测试
- 第1-2013部分。概念和定义
- 第2-2013部分。测试过程
- 第3部分-2013。测试文件
- 第4-2015部分。测试技术
- 29148-2011-系统和软件工程-生命周期过程-需求工程
- 42010-2011-ISO/IEC系统和软件工程-架构描述
应该注意的是,除了ISO 9000系列标准外,还有许多ISO/IEC信息技术、软件工程、系统和软件工程标准通过ISO/IEC JTC 1/CS 7编写/正在编写。这些标准中的一些已经被IEEE采用,另一些可能在未来取代上面列出的现行IEEE标准。目前的ISO/IEC标准的清单可以在http://www.iso.org/iso/home/store/catalogue_tc/catalogue_tc_browse.htm?commid=45086 上找到)。
能力成熟度模型集成(CMMI
软件工程协会(SEI)推动软件工程从一种临时的、劳动密集型的活动演变为一门由技术管理和支持的学科。根据SEI的网站,SEI的主要工作领域包括。
- "软件工程管理实践。这项工作的重点是组织在获取、构建或增强软件系统时预测和控制质量、进度、成本、周期时间和生产力的能力。"
- "软件工程技术实践。这项工作的重点是软件工程师分析、预测和控制软件系统选定属性的能力。这一领域的工作涉及在获取、构建或增强软件系统时必须做出的关键选择和权衡"。
作为这项工作的一部分,SEI建立了CMMI模型(现在由CMMI协会支持),其目的是传达一套良好的实践,供追求企业范围内流程改进的组织使用。由此产生的CMMI框架允许生成多个CMMI模型,这取决于表现形式(阶段性或持续性)和学科。
能力成熟度模型集成(CMMI)用于开发(CMMI-DEV)(SEI 2010)。为组织提供良好实践的路线图,以改善他们的产品开发实践,从而生产出高质量的产品,满足客户、用户和其他利益相关者的需求。
服务的能力成熟度模型集成(CMMI)(CMMI-SVC)(SEI 2010a)。为有意为客户和用户提供高质量服务的组织提供良好实践路线图用于采购的能力成熟度模型集成(CMMI)(CMMI-ACQ)(SEI 2010b)。为组织提供良好实践的路线图,以改善其产品和服务获取实践,从而启动和管理高质量产品和服务的获取,满足客户、用户和其他利益相关者的需求。
在阶段性表述中,三个CMMI模型中的每一个都被细分为五个级别(或阶段),用来衡量组织的成熟度。每个模型都包括一个四级结构(2到5级)的良好实践,旨在提高产品和服务质量,以及项目绩效。在这三个CMMI模型的阶段性表示中,从2到5的每个级别都是由过程领域组成的。
每个CMMI过程领域都是用详细的要求、期望和信息组件来定义的,包括。
- 必要组件。
- 具体目标:每个过程领域都有一个或多个专门适用于该过程领域的目标,组织需要在该过程领域实现这些目标。
- 通用目标:该模型还包括一组通用目标,组织必须为每个过程领域实现这些目标。每个过程领域的描述都解释了这些通用目标以及它们如何适用于该过程领域。
- 预期的组成部分。
- 具体实践 : 每个具体的目标都有相关的实践,专门适用于该过程领域的该目标。组织应该实施模型中记录的具体实践,或可接受的替代实践,从而实现相关的具体目标。
- 一般性实践。每个通用目标都有适用于该通用目标的相关实践。组织应该实施模型中记录的通用实践,或可接受的替代实践,从而实现相关的通用目标。
- 信息化部分。
- 每个流程领域都有一个目的声明,定义了该流程领域的目的,以及介绍性说明,描述了该流程领域所涵盖的主要概念,还有一个相关流程领域的列表,并定义了具体的联系。
- 每个具体的实践都有子实践、相关的注释、例子和参考资料,它们提供了解释和实施具体实践的细节。
- 每个通用实践都有子实践,提供解释和实施通用实践的细节。每个通用实践都有一个关于该通用实践如何适用于所规定的流程领域的详细说明。
举例来说,CMMI的发展测量和分析过程领域的具体目标(SG)和具体实践(SP)是。(SEI 2010)
- SG 1:调整测量和分析活动
- SP 1.1: 建立测量目标
- SP 1.2:指定测量方法
- SP 1.3: 明确数据收集和存储程序
- SP 1.4: 明确分析程序
- SG 2: 提供测量结果
- SP 2.1: 收集测量数据
- SP 2.2: 分析测量数据
- SP 2.3: 存储数据和结果
- SP2.4:交流结果
所有三个CMMI模型都有相同的2级和3级通用目标(GG)及其相关的通用实践(GP)。(SEI 2010; SEI 2010a; SEI 2010b)
-
第2级。GG 2:将管理的流程制度化
- GP 2.1: 建立一个组织政策
- GP 2.2: 规划流程
- GP 2.3: 提供资源
- GP 2.4: 指派责任
- GP 2.5: 培训人员
- GP 2.6: 控制工作产品
- GP 2.7: 识别并让相关的利益相关者参与进来
- GP 2.8: 监测和控制过程
- GP 2.9: 客观地评估遵守情况
- GP 2.10: 与更高级别的管理层一起审查状态
-
第3级。GG3: 将确定的流程制度化
- GP 3.1: 建立一个明确的程序
- GP 3.2: 收集改进信息
在评估一个组织的成熟度水平时,阶段性表示中的过程领域是累积的。一个组织要达到2级成熟度,就必须。
通过实施所有相关的具体实践或可接受的替代实践,实现所有2级流程领域的所有具体目标。
通过实施所有相关的通用实践或可接受的替代实践,实现每个2级过程领域的所有2级通用目标。
为了向前迈进并达到3级成熟度,哪个组织将不得不。
通过实施每个二级流程领域的所有相关通用实践或可接受的替代实践,为每个通用目标增加实现所有三级通用目标的机会
通过实施所有相关的具体做法或可接受的替代做法,实现所有三级过程领域的所有具体目标。
通过实施每个3级过程领域的所有相关通用做法或可接受的替代做法,实现每个3级过程领域的所有2级和3级通用目标。
由于在分阶段表述中没有通用的4级或5级目标,为了向前迈进并达到4级成熟度,一个组织必须通过实施所有相关的具体实践或可接受的替代实践来实现所有4级流程领域的所有具体目标。为了向前迈进并达到5级成熟度,一个组织必须通过实施所有相关的具体实践或可接受的替代实践,来实现所有5级流程领域的所有具体目标。
到目前为止,我们只讨论了CMMI的阶段性表示。在连续表示法中,使用了相同的过程领域。然而,在连续表示法中,每个过程领域被独立地评估为能力水平,指定为0级到3级,并描述如下,而不是组织被评估为成熟度水平。
- 能力水平-0,不完整。流程能力的初始水平,表明该流程根本没有被执行,或其相关的一个或多个具体目标没有被实现。
- 能力水平-1,已执行。一个具有第1级的过程领域已经通过实施所有相关的具体实践或可接受的替代实践,实现了其所有的具体目标。
- 能力水平-2,管理。具有第2级的过程领域,除了实现第1级的所有具体目标外,还通过实施每个通用目标的所有相关通用做法或可接受的替代做法,实现了所有第2级通用目标。
- 能力3级,已定义。一个达到3级的过程领域,除了实现其1级的所有具体目标和2级的通用目标外,还通过实施每个通用目标的所有相关的通用做法或可接受的替代做法,实现了所有3级的通用目标。
实现高成熟度是通过同等的阶段性概念来实现的。一旦所有的2级和3级过程领域的分阶段表示达到了3级能力,4级高成熟度则通过组织过程绩效和量化项目管理过程领域达到3级能力来实现。一旦达到4级高成熟度,5级高成熟度将通过在因果分析和解决以及组织绩效管理方面达到3级能力而达到。
人员能力成熟度模型
除了三个CMMI模型之外,还有一个人员能力成熟度模型(P-CMM)(SEI 2009)。该模型提供了一个良好实践的路线图,以帮助组织解决其关键的人员问题,并改善管理和发展组织的员工队伍的过程。
上一篇: 老大哥的信息技术管理学习笔记(15):软件质量与软件维护
下一篇: 软件全面质量管理思想体系
推荐阅读
-
35 岁实现财务*,腾讯程序员手握2300万提前退休?-1000万房产、1000万腾讯股票、加上300万的现金,一共2300万的财产。有网友算了一笔账,假设1000万的房产用于自住,剩下1300万资产按照平均税后20-50万不等进行计算,大约花上26-60年左右的时间才能赚到这笔钱。也就是说,普通人可能奋斗一辈子,才能赚到这笔钱。在很多人还在为中年危机而惶惶不可终日的时候,有的人的35岁,就已经安全着陆,试问哪个打工人不羡慕?但问题是有这样财富积累必然有像样的实力做靠山。没有人可以不劳而获。 看到这里,肯定有人说,那么对于普通人来说,卷可能真就成了唯一的出路。但是卷也有轻松的卷,“偷懒”的卷法,对于程序员而言,刨除掉一时无法改掉的开会传统占用的大部分时间,如何把有限的时间和精力放在真正重要的架构设计、需求设计上,而不是重复的造*,编码、改bug、手动测试。因此在科技改变生活的今天,学会使用AI工具成为程序员们的必备技能。 以全栈式全自动的软件开发工具飞算SoFlu软件机器人为例,作为全球首款面向微服务架构设计和最佳实践的软件机器人,SoFlu软件机器人改变了原来手工编码的作业模式,通过可视化拖拽方式以及参数配置就能实现等同于编写复杂代码的业务逻辑,在设计业务逻辑时就完成了微服务应用开发,做到“业务即图,图即代码”,实现“软件开发,十倍提效”。 而作为飞算SoFlu软件机器人的一个重要组成部分,FuncGPT(慧函数)支持所有类型函数创建。通过自然语言描述Java函数需求,实时生成高质量、高可读性的Java函数代码。生成代码可直接复制到IDEA,或一键导入Java全自动开发工具函数库。 FuncGPT(慧函数)具有五大核心能力: ● 自然语言:通过自然语言即可生成函数,降低软件开发门槛。 ● 秒级函数开发:全自动秒级开发函数,秒级完成,效率千倍提升。 ● 一站式函数开发应用:函数生成即可直接应用,效率、安全有保障。 ● 质量可靠:生成的函数代码符合业界规范、具备良好的可读性,符合最优解。 ● 灵活生成:可以根据开发人员的具体需求生成并支持调整和修改。 以“将文件流转换为File对象”这个需求为例,以下是FuncGPT(慧函数)秒级生成的代码: / 类名:FileConverter // 函数名:convertStreamToFile // 函数功能:将文件流转换为File对象 // POM依赖包:无 import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.InputStream; public class FileConverter { /** * 将文件流转换为File对象 * @param inputStream 文件流 * @param filePath 文件路径 * @param fileName 文件名 * @return 转换后的File对象 * @throws IOException 如果发生I/O异常 */ public static File convertStreamToFile(InputStream inputStream, String filePath, String fileName) throws IOException { File file = new File(filePath + File.separator + fileName); // 创建File对象 try (FileOutputStream outputStream = new FileOutputStream(file)) { // 创建文件输出流 byte buffer = new byte[1024]; int bytesRead; while ((bytesRead = inputStream.read(buffer)) != -1) { // 从文件流读取数据并写入文件 outputStream.write(buffer, 0, bytesRead); } } return file; // 返回转换后的File对象 } } // 函数示例 // 将文件流转换为File对象示例 // 入参:inputStream,文件流 // 入参:filePath,文件路径 // 入参:fileName,文件名 // 出参:file,转换后的File对象 // 调用示例: // InputStream inputStream = new FileInputStream("example.txt"); // String filePath = "C:\\Users\\User\\Documents"; // String fileName = "example.txt"; // File file = FileConverter.convertStreamToFile(inputStream, filePath, fileName); // System.out.println(file.getAbsolutePath); // 输出结果:例如,将文件流转换为File对象后,文件的绝对路径为:C:\Users\User\Documents\example.txt // 则输出结果为:C:\Users\User\Documents\example.txt 通过分析,不难发现以上代码:
-
软件质量目标设定和指导的 4 个步骤
-
软件质量工程的标准和模型
-
如何促进 QC 小组软件工程质量管理的效率和质量提升
-
开发高质量软件的秘密:代码审查、单元测试和持续集成
-
软件工程 - 三次软件危机的表现和原因 - 第二次软件危机(80 年代至 90 年代)
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
什么是可用性测试?有效性(Effectiveness)-- 用户完成特定任务和实现特定目标的正确性和完整性程度;效率(Efficiency)-- 用户完成任务的正确性和完整性程度与所用资源(如时间)之比;满意度(Satisfaction)-- 用户在使用产品时的主观满意度和接受程度。 2.如何获得可用性? 可以参考以下原则:Gould、Boies 和 Lewis(1991 年)为以用户为中心的设计定义了 4 个重要原则: 早期以用户为中心:设计者应在设计过程的早期就努力了解用户的需求。 综合设计:设计的所有方面都应同步发展,而不是按顺序进行。使产品的内部设计始终与用户界面的需求保持一致。 早期和持续测试:当今唯一可行的软件测试方法是经验主义方法,即如果实际用户认为设计可行,该设计就是可行的。通过在整个开发过程中引入可用性测试,用户就有机会在产品推出之前对设计提出反馈意见。 迭代设计:大问题往往掩盖了小问题的存在。设计人员和开发人员应在整个测试过程中对设计进行迭代。 3...什么是可用性测试? 可用性测试是根据可用性标准对图形用户界面进行的系统评估。 可用性测试是衡量用户与系统(网站、软件应用程序、移动技术或任何用户操作设备)交互时的体验质量。4.如何进行可用性测试? l 实验室实验
-
软件工程可用性测试:改善软件、网站和产品用户体验的关键部分
-
纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享,主题为「敏捷需求挖掘和组织方法,交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验,完成了企业多个团队从传统模式到敏捷转型的落地和实施,积淀了很多的经验。 这次分享主要包含以下2个部分: 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis(以下简称EDBA) 用户影响地图,是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题,比如大家使用不同的业务语言、技术语言,造成角色间的沟通阻碍,还会导致一些问题,比如需求误解、需求传递错误等;这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间,研发人员必须要将这些需求实现交付,他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛点。研发人员往往只是拿到了解决方案,需要把它实现,但没有和业务侧一起去思考解决方案是否正确,能否真正的帮助客户解决问题。而用户影响地图通常是能够连接业务目标和产品功能的一种手段。 我们在每次迭代里加入的假设,也就是功能需求。首先把它先实现,再逐步去验证我们每一个小目标是否已经实现,再看下一个目标要是什么。那影响地图就是在这个过程中帮我们不断地去梳理目标和功能之间的关系。 我们在软件开发中可能存在的一些问题 针对这些问题,我们如何避免?先简单介绍做敏捷转型的常规思路: 先做团队级的敏捷,首先把产品、开发、测试人员,还有一些更后端的人员比如交互运维的同学放在一起,组成一个特训团队做交付。这个团队要包含交付过程中所涉及的所有角色。 接着业务敏捷要打通整个业务环节和研发侧的一个交付。上图中可以看到在敏捷中需求是分层管理的,第一层是业务需求,在这个层级是以用户目标和业务目标作为输入进行规划,同时需要去考虑客户的诉求。业务人员通过获取到的业务需求,进一步的和团队一起将其分解为产品需求。所以业务需求其实是我们真正去发布和运营的单元,它可以被独立发布到我们的生产环境上。我们的产品需求其实就是产品的具体功能,它是我们集成和测试的对象,也就是我们最终去部署到系统上的一个基本单元。产品需求再到了我们的开发团队,映射到迭代计划会上要把它分解为相应的技术任务,包括我们平时所说的比如一些前端的开发、后端的开发、测试都是相应的技术任务。所以业务敏捷要达到的目标是需要去持续顺畅高质量的交付业务价值。 将这几个点串起来,形成金字塔结构。最上层我们会把业务目标放在整个金字塔的塔尖。这个业务目标是通过用户的目标以及北极星指标确立的。确认业务目标后再去梳理相应的业务流程,最后生产。另外产品需求包含了操作流程和业务规则,具需求交付时间、工程时间以及我们的一些质量标准的要求。 谈到用户影响的地图,在敏捷江湖上其实有一个传说,大家都有一个说法叫做敏捷需求的“任督二脉”。用户影响地图其实就是任脉,在黑客马拉松上用过的用户故事地图其实叫督脉。所以说用户影响地图是在用户故事地图之前,先帮我们去梳理出我们要做哪些东西。当我们真正识别出我们要实现的业务活动之后,用户故事地图才去梳理我们整个的业务工作流,以及每个工作流节点下所要包含的具体功能和用户故事。所以说用户影响地图需要解决的问题,我们包括以下这些: 首先是范围蔓延,我们在整张地图上,功能和对应的业务目标是要去有一个映射的。这就避免了一些在我们比如有很多干系人参与的会议上,那大家都有不同想法些立场,会提出很多需求(正确以及错误的需求)。这个时候我们会依据目标去看这些需求是否真的是会影响我们的目标。 这里提到的错误需求,比如是利益相关的人提出的、客户认为产品应该有的、某个产品经理需求分析师认为可以有的....但是这些功能在用户影响地图中匹配不到对应目标的话,就需要降低优先级或弃掉。另外,通常我们去制定解决方案的时候,会考虑较完美的实现,导致解决方案括很多的功能。这个时候关键目标至关重要,会帮助我们梳理筛选、确定优先级。 看一下用户影响到地图概貌 总共分为一个三层的结构: 第一层why,你的业务目标哪个是最重要的,为什么?涉及到的角色有哪些? 第二层how ,怎样产生影响?影响用户角色什么样的行为? (不需要去列出所有的影响,基于业务目标) 第三层what,最关键的是在梳理需求时不需一次把所有细节想全,这通常团队中经常遇到的问题。 我们用这个例子来看一下 这是一个客服中心的影响地图,业务目标是 3个月内不增加客服人数的前提下能支持1.5倍的用户数。此业务目标设定是符合 smart 原则的,specific非常的具体,miserable 是可以衡量的,action reoriented是面向活动的, real list 也是很实际的。 量化的目标会指引我们接下来的行动,梳理一个业务目标,尽量去量化,比如 :我们通过打造一条什么样的流水线,能够提高整个部署的效率,时间是原来的 1/2 。这样才是一个能量化的有意义的目标。 回到这幅图, how 层级识别出来的内容,客服角色:想要对它施加的影响,把客户引导到论坛上,帮助客户更容易的跟踪问题,更快速的去定位问题。初级用户:方论坛上找到问题。高级用户:在论坛上回答问题。通过我们这些用户角色,进行活动,完成在不增加客户客服人数的前提下支持更多的用户数量。 最后一个层级,才是我们日常接触比较多的真正的功能的特性和需求,比如引导到客户到论坛上,其实这个产品就需要有一个常见问题的论坛的链接。这个层次需要我们团队进一步地在交付,在每个迭代之前做进一步的梳理,细化成相应的用户故事。 这个是云智慧团队中,自己做的影响地图的范例,可以看下整个的层级结构。序号表示优先级。 那我们用户影响地图可以总结为: