跳转到内容

软体品质管理

本页使用了标题或全文手工转换
维基百科，自由的百科全书

软体品质管理（Software quality management，缩写SQM）是一种管理流程，目标在发展与管控软体的品质，确保产出的成品可以满足使用者的需求。软体品质管理人员在产品正式发行之前对其进行品质测试，并且执行一系列称之为软体周期的步骤，为了在软体发布前预先发现并修正错误。他们（软体品质管理人员）的工作不仅是确保软体产品为消费者期待的型态，且经由正确的开发流程来保护他们的软体产品，并对流程中的每一位成员提倡品质文化，避免欺骗行为的发生。

定义

软体品质管理（SQM）的目标为管理软体开发过程中与开发完成后的软体品质，一个优质的产品必须符合品质的要求条件，并且满足使用者的需求。品质文化是指在一个组织环境中，品质被视为每个人的责任义务。

  • 软体品质要求条件：[1][2]
    • 确认的目标与架构的范围。
    • 监督专案的执行查核。
    • 差异的协调与调整。
    • 预防重复性的活动。
    • 执行历程的书面纪录。

描述

Ian Sommerville[3]著作的软体工程书籍中使用了伞状概念的软体品质管理，该概念包含以下软体品质层级：

  • 软体品质保证（SQA）层级，组织的品质指南包含：
    • 在软体开发生命周期中的标准、法规与程序以生产、确认、测试与确认上线运作；
    • 整合最佳实务知识库；
    • 选择现成的软体来套用以上程序。
  • 软体品质计画（SQP）层级：一个软体品质管理的阶段，每个专案皆需要撰写，用以表示软体开发专案周期内，专案的承诺与遵从的标准、规范、程序与工具。此外，SQP也包含了要实现的品质目标、风险预估、与风险管理。SQP来源衍生自
    • SQA元件的被采纳使用或客制化以专案需求为主；
    • 新流程、标准与工具补充了被注记在专案的特别项目或从组织外部导入的缺失与不合用的SQA元件。任何软体品质保证（SQA）中的软体品质计画（SQP）偏失，都需要经由专案经理证明，并经由公司管理阶层确认。
  • 软体品质控制（SQC）层级：确保软体开发过程中，皆有遵循SQA与SQP规范。软体品质控制的作业包含：
    • 指导如何制作与开发物件（成果），例如事先定义的工程文件与标准范本；
    • 指导如何进行标准流程，例如品质检阅；
    • 执行线上品质检阅、以验证、评估、与确认开发物件（成果）；
    • 验证与评估用以改善使用的方法、流程以及被采用的软体工具。

软体品质管理（SQM）规则

  • 确保软体产品达到品质可接受度；
  • 提倡全公司层级的“品质文化”概念为全体员工的责任；
  • 减少学习曲线与帮助团队成员改变组织内部职位的连续性；
  • 在开发过程中启动流程错误回避与错误预防。

许多人交替使用SQM（软体品质管理）与SQA（软体品质保证）概念

  • 软件质量管理 (SQM) 必须有效地为质量保证活动部署资源，以反映实现的产品质量，其更广泛定义，包含可重用性和可维护性[4]。

品质保证和标准

  • 标准(standard)是达到有效品质管理的关键，可以是国际、全 国、组织或专案的标准。
  • 产品标准(product standard)定义所有元件需呈现(exhibit)的特 性(characteristics)，如程式语言风格(programming style)。
  • 流程标准(process standard)定义软体流程扮演角色(how the software process should be enacted)。

软体品质管理（SQM）与软体生命周期（software lifecycle）

软体品质管理能够以不同的方式实现，取决于组织与实际专案的类型，[5] 但是应该都包含在整个软体开发周期范围，

意味：

  • 收集需求与定义IT专案的范畴，如果需求是可测试的，则著重于检验。最后产生测试策略。
  • 设计解决方法，著重于计画测试步骤，例如可执行哪些类型的测试、如何在测试环境下执行、与测试资料取得，最后产生测试计画或是测试排程。
  • 建置解决方案，透过建立测试案例、测试情境、执行项目以及登记缺陷、修正状况、与重复性测试的报告之程序。
  • 变更管理，透过确认如何计划变更能够影响解决方案建立的品质以及测试计画的最终变更，最后产出测试计画、测试案例与测试情境。
  • 结束计画，透过实际测试的重点集中在复杂的检验，以建立解决方案的整体品质，包含了系统整合测试、使用者验收测试与运行验收测试，最后产生系统建议上线时间。[6]
  • 为实现项目目标或目的而进行的活动逻辑序列[7]。
    • (1)启动：定义输出和关键成功因素；
    • (2)规划：将项目缩小为可管理范围/任务；
    • (3)执行：项目计划执行；
    • (4)监测：实际项目活动以基线为基准；
    • (5)关闭或退出：最终完成项目。
  • 对软体专案开发进行有效管理的作业，品质管理系扮演了一个软体专案开发过程中扮演了关键性角色（Reel, 1999 ; Karl, 2008）。
  1. 确保软体产品达到所需的品质层次(required level of quality)。
  2. 包括定义适当的品质标准和程序(procedures)，并确保遵循这些标准和程序。
  3. 专注于发展品质文化(quality culture)，品质被视为每个人的责任。

软体品质管理（SQM）风险管理[8]

1. 什么是风险？

风险是一个问题“……它可能在未来发生并产生不想要的后果”（SPILLNER 等人，2008 年）。 风险可以表示为损坏量和损坏概率的乘积（SPILLNER & LINZ 2005）。


2. 风险和软件

软件系统的故障会给企业带来沉重的风险。一个例子发生在 2009 年，当时软件错误使德国最大的移动电信提供商 T-mobile (http://www.spiegel.de/netzwelt/tech/0,1518,620388,00) 的整个移动电话网络瘫痪。 html - 27/4/2010）。当与安全相关的软件出现故障时，例如飞机的软件，甚至可能危及人的生命。 NEUMANN (1995) 提供了一个令人印象深刻的列表，说明信息技术系统中的故障如何导致严重事故和人员伤亡。因此，软件必须具有足够的质量以防止此类事件。


根据 PINKSTER 等人的说法。 (2006)，所有与软件测试项目相关的风险都可以分为两类，即项目风险和产品风险。 PINKSTER 等人。将项目风险定义为与测试过程管理相关的风险。它们进一步区分了与时间和预算相关的业务相关项目风险与 ICT 相关项目风险，例如不稳定的测试环境。根据这些作者的说法，软件测试人员主要关注第二类风险，也可以分为“业务”和“ICT”相关的产品风险。为了更好地了解这些风险类别，


3. 根据 PINKSTER 等人的说法。 (2006)，软件测试背景下的结构化风险管理过程包括以下步骤：

- 风险识别

- 风险分类与评估

- 风险分配和选择

- 风险监控


4. 风险识别与分类

BACH (1999a) 推荐了两种风险识别方法（BACH 使用术语“风险分析”）： 由内向外分析和由外向内分析：由内向外分析从产品及其组件开始。 BACH 建议针对每个组件提出以下三个问题：

- “漏洞：这个组件有什么弱点或可能的故障？”

- “威胁：可能存在哪些输入或情况可能会利用漏洞并触发该组件的故障？”

- “受害者：谁或什么会受到潜在故障的影响，会有多糟糕？”


这种分析方法试图回答哪些风险与软件产品的不同部分相关的问题。它可以涉及技术细节，因此需要技术洞察力。因此，应该与软件开发商合作完成。

BACH 提出的由外而内的分析则相反：预先创建潜在风险列表，然后将其与产品的不同部分联系起来。例如，风险列表可以以质量标准为导向，因为问题被问及基于质量标准的要求不满足会发生什么情况。也可以有一个通用的风险列表，例如：

- 软件的哪些部分是新的？

- 软件的哪些部分非常复杂？


由外而内的分析还导致下一步，即风险分类。 与 BACH 的第二种方法类似，PINKSTER 等人。 建议根据 ISO 9126 的质量属性对第一步中已经识别的产品风险进行分类。 作者通过将其应用于控制自动柜员机的软件使这一点更加清晰：

将产品风险与自动柜员机 (ATM) 的质量属性联系起来的示例


围绕质量属性对可能的风险进行分组可以帮助作为风险识别过程一部分的测试涉众，以确保风险列表是完整的。 之后，可以开发针对每个质量属性的第一个测试安排（PINKSTER 等人，2006 年）。


5. 风险评估

识别风险后，必须对其进行评估，以确定测试优先级。可以以定性方式评估风险，例如使用“MoSCoW”原则，这意味著每个产品风险都被分配到以下类别：必须测试、应该测试、可以测试、不会测试（PINKSTER 等人）。在这些类的帮助下，可以在测试过程中建立相互之间的优先级。使用上述的损坏量×损坏概率公式，也可以对风险进行量化评估。处理数学公式意味著必须为这两个因素提供定量值，以实现可用于设置测试过程优先级的结果。在大多数情况下，量化将使用指标和尺度（例如“1”代表低，“2”代表中等，“3”代表高）而不是货币价值。


6. 量化损坏量（REDMILL 2004）

由于每个系统都有许多利益相关者，因此每个利益相关者的故障后果或损害程度可能不同。例如，银行可能会运行一个银行账户系统，该系统显示客户被拒绝访问其账户的故障：从银行运营商和维护的角度来看，这种故障的成本，即损失金额，可能很低人员。但如果这样的失败在媒体上发表，可能会导致声誉损失，这可能会导致商誉下降、市场份额和营销成本下降，以重新获得公司以前的市场地位。从业务的角度来看，这样的失败继承了巨大的损失。还可以从软件开发人员的角度来估计可能的损失量：一定数量的失败可能会导致失去在同一组织内赢得另一个项目的机会。因此，在估计软件故障的后果时，必须预先定义从哪个角度考虑它们。


此外，必须从适当的来源获取有关故障可能导致的损坏量的信息。适当的来源是例如定义系统目标的人，例如高级经理或系统战略家。

资讯技术（IT）相关方法

软体品质管理与专案管理各项主题有密不可分的关联，开发与资讯技术（IT）的作业方式如下：

透过RUP与V-Model来实现软体品质管理
  • 专案管理的PRINCE2（专案中可控制的环境）方法 [9] 定义：
  • 元件“专案环境品质”，描述了需要双重检查的必要性与建立产品的目标控制项目，相关展示了四个元件：品质管理系统、品质控制功能、品质规划与品质控制。
  • “品质检阅技巧”专注于确认建立的产品是否符合定义的品质标准。
  • 专案管理 PMBOK（专案管理知识体系，第四版 [10]）方法论，定义了专案品质管理的知识领域与以下程序：
  • 3.4.12 规划品质，
  • 3.5.2. 施行品质保证，
  • 3.6.7. 施行品质控制
  • 统一软件开发过程（RUP） 开发方法定义了测试规范，为所有阶段以构思阶段为开始，以移交阶段做为结束。
  • 微软解决方案开发框架（MSF）开发方法定义了测试员的规则与稳定阶段，著重于测试解决方案。[11]
  • 敏捷软件开发（Agile software development）不需要精确定义测试者的规则或者机制，涉及软体品质管理。敏捷法只定义持续整合与测试驱动开发。虽然，最后出现了敏捷测试。
  • 能力成熟度模型集成（CMMI） 操作法定义中，有关于PPQA（程序与产品品质保证）的程序领域，相关纪载于CMMI第二阶。
  • 信息及相关技术控制目标（COBIT）操作法定义中，被定义为P08品质管理。
  • 信息技术基础架构库（ITIL）操作法定义中，被定义为发行持续性改善。
  • V模型（V－Model）模组–定义了软体开发周期与测试程序。
  • ISO 9000－一系列标准具有关于品质管理系统的标准以及设计来协助企业组织确保相关生产合乎客户的需求与其他相关利益者，以满足与产品相关的法定和法规要求。

协会和组织

  • ISTQB, 国际软体测试认证委员会（International Software Testing Qualifications Board，简称ISTQB）是在比利时合法注册的非营利软体测试质量认证组织。它管理软件测试人员的认证过程。 已有超过200.000份ISTQB®证书（日期：2012年3月）。[12]
  • ASQ （页面存档备份，存于互联网档案馆），美国品质协会是一个基于知识的全球质量专业人士社区，近80,000名成员致力于在工作场所和社区中推广和推进优质工具，原则和做法。

参见

参考文件

本条目部分或全部内容出自以GFDL授权发布的《自由线上电脑词典》（FOLDOC）。

  1. ^ 郭忠义. 軟體品質管理 (PDF). [12-11-2021]. （原始内容存档 (PDF)于2021-12-11）. 
  2. ^ Bishop, D., & Reeves, K. How to build a quality management climate in a small to medium enterprise. An action research project.. Lean Six Sigma. 2021 [2021-12-16]. （原始内容存档于2021-12-16）. 
  3. ^ Ian Sommerville (2004), Software Engineering, 7th ed., chapter 27
  4. ^ Alexander Poth; Ali Sunyaev. Effective Quality Management: Value- and Risk-Based Software Quality Management. IEEE Software. 2014-11, 31 (6): 79–85. doi:10.1109/MS.2013.138. 
  5. ^ Kelemen, Z. D. (2013). Process Based Unification for Multi-Model Software Process Improvement （页面存档备份，存于互联网档案馆） Eindhoven: Technische Universiteit Eindhoven. ISBN 978-90-386-3313-8
  6. ^ Software Quality Management. [2017-10-30]. （原始内容存档于2006-06-04）. 
  7. ^ Wong, Whee Yen; Wen Yu, Su; Too, Chian Wen. A Systematic Approach to Software Quality Assurance: The Relationship of Project Activities within Project Life Cycle and System Development Life Cycle. 2018 IEEE Conference on Systems, Process and Control (ICSPC) (Melaka, Malaysia: IEEE). 2018-12: 123–128 [2021-12-16]. ISBN 978-1-5386-6327-1. doi:10.1109/SPC.2018.8703978. （原始内容存档于2021-12-16）. 
  8. ^ Sickinger, Jan. Risk management in software quality assurance. https://www.grin.com/document/178001. [2022-01-06]. ISBN 978-3-640-99994-1. （原始内容存档于2022-01-06） （德语）.  缺少或|title=为空 (帮助)
  9. ^ OGC (Office of Government Commerce) (2009). Managing Successful Projects with PRINCE2 (2009 ed.). TSO (The Stationery Office). ISBN 978-0-11-331059-3
  10. ^ A Guide to the Project Management Body of Knowledge, Fourth Edition, PMI, USA, 2008
  11. ^ Microsoft Solution Framework - Chapter 18 Stabilization phase, Published: April 27, 2005 [1] （页面存档备份，存于互联网档案馆）
  12. ^ ISTQB. [2017-10-30]. （原始内容存档于2010-02-10）. 
检索自“https://zh.wikipedia.org/w/index.php?title=軟體品質管理&oldid=70481428”