今天看啥  ›  专栏  ›  知知带你每日一知

软件质量管理概述

知知带你每日一知  · 简书  ·  · 2020-10-15 07:50

今日分享:《软件质量管理指南》张瑾,软件质量管理体系综述、验证 P1~95

书中内容:

----------------------------------------------

软件质量管理体系概述


质量是指“产品具备满足明确或隐含需求能力的所有特性的总和”


软件质量管理体系的知识涵盖了软件工程、CMMI软件能力成熟度模型、PMP项目管理以及软件测试技术的理论。

软件工程:

主要介绍了各种生命周期模型,这是软件研发和质量管理的基础,也是CMMI软件能力成熟度模型和PMP项目管理理论中非重点介绍的内容;


PMP项目管理:

该理论适用于任何行业的项目管理工作,它详细介绍了制定项目估算、预算的方法,以及制定项目进度计划的各种技术,这些是CMMI软件能力成熟度模型和软件工程的重要补充;

CMMI1软件能力成熟度模型:

是当今最流行的一种对软件企业成熟度的评判标准,CMMI将软件的管理过程拆分为多个PA (过程域) ,并详细介绍了每个PA所需要完成的工作、流程以及流程中必备的产出物,它是软件质量管理中的核心部分。但CMMI软件能力成熟度模型着重于过程的定义,有些具体的操作方法和技术就必须参考PMP项目管理理论或软件测试理论的相关知识。


软件测试一直以来都被很多人误解为等同于软件质量管理,多样的软件测试技术正是CMMI软件能力成熟度模型VER (验证)的重要补充内容。


总的来说,软件工程中生命周期模型好比盖房子时打下的地基, CMMI软件能力成熟度模型就是房子的框架结构, PMP项目管理以及软件测试技术的理论就是填充房子的砖石,而盖好的这座房子就是软件质量管理体系。


软件质量管理是一套复杂的系统工程,软件质量的好坏就好比木桶盛水的多少,木桶所盛的水越多,软件产品的质量就越好。如图1—1所示,木桶所盛水的多少却是取决于木桶中最短的那块木板的高度。




那么软件质量管理系统是由哪些“木板”组成的呢?以CMMI和软件工程理论为依据,它们分别是:

讲述软件检查方式的验证管理(VER)

讲述软件预防手段的同行评审(Peer Review)

讲述软件信任机制的确认管理(VAL)

讲述软件审计体系的质量保证(PPQA)

作为软件管理基石的配置管理(CM),

讲述软件观洞察力的度量管理(MA)

讲述软件预警措施的风险管理(RSKM)

讲述软件统筹规划的项目集成管理(IPM),

讲述软件详细策划的项目计划(PP)

讲述软件监控手段的项目监控(PMC)

·讲述软件需求工程的需求开发(RD)和需求管Е (ReqM)

软件群体决策机制的决策分析(DAR)

讲述软件构建机制的产品集成(PI)

项目供应商管理(SAM)

项目的技术解决方案(TS)

讲述软件持续改进的组织过程的焦点(OPF)、

组织过程的定义(OPD)和组织培训 (OT)


软件质量复杂度的来源:

所谓“隔行如隔山” ,软件产品的业务逻辑集中体现了客户所从事工作的最佳实践,软件研发人员需要跨行业学习并理解相关的知识。

软件产品是一种主观的、无形的“逻辑”产品,在软件项目中"变化是永恒的,不变是短暂的"。

软件项目的需求60%以上都是隐形的需求,有时客户所提供的原始需求中简短的几个字就可以延伸成为一个规模不小的模块。

工业化是建立在“生产线”基础上的,但是软件行业“生产线”的概念却不明显,原因是软件行业是知识密集型的行业,人的大脑就是生产线上的设备,所以不能使用传统方式来对它进行规范,因此必须加强开发标准流程的定义和规范。

软件开发人员对文档的重视程度不够,通常认为只有写代码才是他们的本职工作。

软件开发人员对单元测试的重视程度不够,认为测试工作都是软件测试人员的事情。在当今主流的开发模型中对单元测试的要求越来越高,这正是先进软件质量理念“尽早测试”的集中体现。

软件研发人员往往会忽略了软件开发的真实目的。由客户投资来研发的软件其目的不是为了要这些代码,而是希望利用这些代码辅助实现其商业目的。


软件质量管理的检查方式:验证

验证的目的在于确保工作产品符合其指定的需求。


软件验证的过程可以抽象为以下3个部分:验证的准备工作、验证的执行工作、纠正措施。


所有验证准则都必须包含3个要素:输入、操作步骤和期望的输出。


书中提到验证的方法:

同行评审

单元测试

集成测试

性能测试(压力测试是检测在巨大的工作压力负荷下应用程序的运行情况。)

系统测试


软件测试人员在进行验证的过程中也要把握尺度,通常所遵循原则如下:

①软件各种测试方法的目的是为了发现存在的缺陷,但永远不能证明软件系统不存在缺陷。因为软件产品对于测试人员来说就是一个“黑盒子”,而软件的缺陷却已经在生产的过程中产生了。

②要想在有限的时间和资源下进行无穷尽的测试是不可能的,因此软件测试也要适可而止。

③测试要尽早介入,由于软件的复杂性和抽象性,在软件生命周期各个阶段都可能产生错误,所以不应把软件测试仅仅看做是软件开发的一个独立阶段的工作,而应当把它贯穿到软件开发的各个阶段中。

④帕雷托的80/20原则,80%的缺陷是因为20%的错误原因导致的。

⑤相同的测试用例反复使用是没有效果的,因为测试人员也会产生“审美疲劳”。


----------------------------------------------

读书感悟:

1,关于软件的验证,作者将同行评审纳入到此范畴,不是很认可这点。 软件测试就是软件测试,测试的对象是后面用户使用的产品,而同行评审的对象是什么? 是为了生产产品的过程文档,比如需求文档,架构文档,项目计划等等,是过程产物。

同行评审是保证输出正确的产物的手段,不是验证手段。


2,关于质量质量的木桶理论,在大型软件系统适用,但是进入互联网时代之后,里面的很多内容是不再适用,随着软件工具化的普遍应用,工具的升级等等,尤其是Devops模式的发展和流行,这些因素对最终质量的影响越来越小。


3,本书中的软件质量管理体系,涵盖软件工程、PMP,CMMI,软件测试等等,在体系化了解软件质量方面仍有很大借鉴意义。


------------------------------------------


以上内容属于书中和作者观点,请大家以辩证思维阅读,结合自己经验,多看,多思,选择性吸收。




原文地址:访问原文地址
快照地址: 访问文章快照