软件开发各阶段的质量管理有哪些呢?
软件产品的质量是个很大的概念,因为软件产品完全是人们大脑思维的产物,就是将大脑里无形的看不见摸不着的思维变成一个可以看到的,可以解决实际问题的一组界面或者组件。
这样的一个复杂的过程,质量应该如何保证呢?有人想到了ISO9000、CMM,也有人很反对,说应该用敏捷开发。
其实,不管用什么样的开发过程,关键是找到这些过程的真谛,有些人说,ISO和CMM到中国来就变了味了,为什么变味儿了呢?其实我们只学到了该做什么,却不知道怎样去做,为什么要这样做?大家都知道做软件开发需要写需求规格说明书和设计文档,为什么要写,文档的重要性有多高?没有资深开发和管理经验的人员可能很难理解其重要性,如果只是简单的形式上去写一篇这样的文档,对后面的编码和测试没有实际的指导作用,甚至起了“ 误导”作用,同样会引起大量返工,那么这些文档除了负担之外就没有其他用途了,要知道写这些文档是需要消耗项目组资源的(进度、成本...)。
很多人又想到了测试,觉得是我们测试的力度不够,所以我们产品质量不过关,其实,软件开发的质量保证从开发最初就应该开始了,如果到了测试阶段才重视就已经晚了。
软件产品开发过程,不管采用瀑布式还是迭代式,都离不开需求、设计、编码、测试这几个阶段,在迭代式开发中,这几个阶段也是周期性出现的。
怎样把握好每个阶段的质量,确实不是一件容易的事,本期重点介绍一下需求、设计和编码阶段的成果质量,当然以后会共享一些过程质量方面的知识。
1、需求 我们知道人与人的交流总是会存在一些误会,同样一句话,心情不好与心情好的时候听起来的感觉可能会截然相反,正是因为人们之间存在着理解上的偏差,在描述需求的语言上就应该注意尽量避免歧义的产生。
如果对UML比较熟悉的话,需求分析可以利用UML工具进行,这样可以减少一些自然语言引起的歧义,但是UML可能与用户沟通起来有一些障碍,因为并不是所有的用户都了解 UML各种图形的意思。
除了工具之外,我们可以从以下几个方面来保证需求描述的质量。
1、看句子和段落是否简短,一个很长的句子,看起来会非常困难,因此无法弄懂真正的需求,另外过长的句子和段落容易让人忽视一些需求,所以如果一个句子不能完全描述清楚需求,应该将其拆分成多个小句子。
2、句子是否有语法错误,还要注意标点符号,有时,标点符号点错了,就完全成了另外一个意思了。
3、是否存在模糊不清的需求,出现类似于可能,大概,或者等词汇表述的需求。
4、另外注意引用的术语和词汇是否前后一致。
5、是否存在一些形容词、比较性词语,比如:容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的,界面友好的,减少、扩大,不小于等等,需要将描述性词语进行量化,并且给出具体值或者范围,要不然不同的人根据不同的理解就会得出不同的结果,最终可能跟用户最初的要求有偏差,那“炒回锅肉”的事情就不可避免地会发生。
另外保证需求质量的一个很重要的因素就是需求是否细化,如果需求不细化也会很容易造成代码的返工,于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。
那么我们怎样才能判断需求细化的程度呢?需求细化程度确实很难把握,什么样的需求可以算是比较细了,不用再进行细化了呢?哪些需求又太粗了呢?答案是需求是否可以写出相应的测试用例,如果写不出来,就说明需求还不是很细,还需要再进行细化。
2、设计 软件架构设计在软件产品开发周期中占有很重要的位置,我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色,例如:用户、项目管理人员、程序员、测试员、维护人员等等。
不同的角色对架构设计的要求也不相同。
例如用户关心的是需求,因此我们的设计对需求的覆盖率是多少?对于程序员来说模块是否清晰,类的功能是否单一等等,对于测试人员来说系统的是系统的可测试性。
对于维护人员来讲系统的扩展性、可维护性如何?一个高质量的软件架构,应该最大限度的考虑并满足不同角色的不同要求。
正是因为有这些要求,我们在进行软件设计的时候,应该进行全面的考虑。
一般用来衡量软件设计质量的标准可以从以下几个方面来考虑: 1)、功能性:包括完全性、正确性、安全性、兼容性、互用性。
完全性包括功能点覆盖率,重点功能点覆盖率,优先功能覆盖率。
正确性包括需求一致度。
安全性根据软件需求的不同有不同的安全性要求。
来源于考试大 2)、效率:包括产品运行的时间效率和利用的硬件资源两方面来考虑。
3)、维护性:包括架构的可改正性,可扩充性以及可测试性。
如果用户的一个很小的需求变更会引起架构设计很大的变化,那么这样的架构设计的可改正性和可扩充性就比较差。
4)、可移植性:包括硬件的独立性、软件独立性、可安装性、可重用性。
软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。
5)、可靠性:包括缺陷数量、容错性、可用性。
6)、使用性:包括可理解性、易学习性、可操作性、易沟通性。
我们软件的最终目的是让用户来使用的,如果易...
软件开发质量管理层次如何初步划分?
1 、技术层次(数据、编程、文档) 2 、方法体系层次(措施、项目、过程) 3 、社会因素层次(质量环境、技术标准、业务标准、人员) 目前软件过程改进主要根据能力成熟度模型集成CMMI,其层次分为初始级、可重复级、已定义级、已管理级、优化级 编程质量管理层次可分为黑盒测试、灰盒测试、白盒测试、编译检查、编程规范、编程逻辑、编程优化。
系统分析、设计及实施 系统规格说明书应该达到的基本要求是:全面、系统、准确、详实、清晰地表达系统开发的目标、任务和系统功能。
系统说明书内容如下:1 引言,说明项目的名称、目标、功能、背景、引用资料,文中所用的专业术语等2 项目的概述,(项目的主要工作内容;现行系统的调查情况;新系统的逻辑模型)3 实施计划(工作任务的分解;进度和预算)
软件开发项目质量管理哪几个维度
以在开发项目上按照规范化软件的生产方式进行生产,在开发质量管理流程上采用ISO9000的标准进行。
每个项目除配备了项目开发所需角色外,还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施,下面针对这三种角色进行说明: 1、配置管理小组职责 配置管理小组是保证项目开发完毕的同时,内部文档和外部文档都同时完成。
内部文档的及时产生和规范,是保证项目开发各小组能够更好的接口和沟通的重要前提,从另一个方面讲,也是保证工程不被某个关键路径所阻塞而延滞的前提。
如上所述,配置管理小组还是保证质量保证小组得以发挥作用的基础。
配置管理小组的主要职责包括: 完善各个部门发送需要存档和进行版本控制的代码、文档(包括外来文件)和阶段性成果; 对代码、文档等进行单向出入的控制;对所有存档的文档进行版本控制; 提供文档规范,并传达到开发组中。
2、测试小组职责 测试小组作为质量控制的主要手段,负责软件的测试设计和执行工作。
如同软件开发一样,测试在执行之前,同样需要进行测试计划和测试策略的设计,通常情况下测试可以分为如下几种类型,如:正确性测试、功能性测试、性能测试、安全测试和系统测试等。
而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。
程序员在交给测试人员之前是进行过一定的单元测试,确保程序编译、运行正确。
测试人员根据详细设计的文档对软件要实现的功能进行一一测试,保证软件的执行正确的实现设计要求,在此也只证明了软件正确的反映了设计思想,但是否真正反映了用户的需求仍需要进一步的功能性测试。
测试人员只有根据软件需求规格说明书所提及的功能进行检测,才能确保项目组开发的软件产品满足用户需求。
在正确性测试完成之后,需要测试的是软件的性能,软件的性能在本项目中占有重要的地位,性能要求有可能改变软件的设计,为避免造成软件的后期返工,测试在性能上需要较大的侧重。
如果有必要的话,测试小组还需要做安全测试,以确保系统使用安全可靠。
3、质量保证小组职责 质量保证小组作为质量保证的实施小组,主要职责是保证软件透明开发的主要环节。
在项目开发的过程中几乎所有的部门都与质量保证小组有关。
质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告,提出差异原因和改进方法。
在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时,提请项目经理、项目负责人等必要的相关人员举行质量会议。
解决当前存在的和潜在的问题。
质量保证是建立在文档的复审基础之上,因而文档版本的控制,特别是软件配置管理,直接影响软件质量保证的影响力和力度。
质量保证小组的检测范围包括:系统分析人员是否正确的反映了用户的需求; 软件执行体是否正确的实现了分析人员的设计思想; 测试人员是否进行了较为彻底的和全面的测试;配置管理员是否对文档的规范化进行的比较彻底,版本控制是否有效。
软件技术(质量管理)
软件技术(质量管理)应该是软件方面质量有关的技术和管理。
软件质量的保证手段是过程管理以及软件测试。
开发过程的管理,就是按软件工程原理,对每个过程进行控制。
有多种模型,比较简单的是瀑布模型:软件生命周期分为:计划、需求、设计、实现、测试、维护等阶段。
每个阶段实施规定的管理,使得阶段质量得到保证。
软件开发组织一般组成:项目组长1名、设计工程师(可能分架构工程师、开发工程师或程序员)若干名、测试工程师(可能分测试工程师、测试员)若干名、QA(质量保证)1名、配置管理员1名。
测试(包括评审)是重要的质量保证手段,QA是过程管理的监督员。
配置是软件工作产品的库管员,只有测试通过的工作产品才能入库。
软件技术(质量管理)可能就是学习这方面的知识,将来的岗位:测试、QA、配置管理员。
国内软件质量管理发展情况是怎样的呢?
在国内软件业开始诞生和起步的时候,软件企业在质量管理方面比较落后,大部分的软件企业没有设置专门的测试组织和招聘专职的测试人员。
软件产品的质量完全依赖于程序设计和编写者的技术水平和工作效果。
这种依赖使得软件产品的质量水平低下。
虽然国内一些软件企业在2000年左右开始建立内部的测试小组,但仍然只起到了“事后检验”(即在已集成的版本上进行的一些基于用户操作层面上的测试和检验)的功能,大部分产品质量缺陷仍然无法及时和较全面的被发现和解决,更不用说“预防缺陷”。
即使这种具有“事后检验”功能的测试小组被建立,但由于没有必要的支持 ,以及人力资源投入严重不足,导致测试小组在软件质量上的贡献和业绩表现并不佳。
同时由于对产品质量的认识缺乏全面的理解,仅仅建立一个测试小组对产品质量的提升很有限。
随着中国WTO的发展步伐,国内涌现出了越来越多的软件企业,其中以外包企业为主,外包软件开发公司一般都需要取得一定的资质认证才能够接到来自国外的委托项目,其中以CMMI认证为主。
国内软件行业即将迎来一个新的发展时期――规范与规模化。
软件开发质量和风险如何定量监理呢?
软件质量是指与软件产品满足规定和隐含的需求的能力和有关的特征的全体,即所有描述计算机软件优秀程度的特性的组合。
应用软件的质量依赖于问题需求的描述、解决方案的建模设计、可执行程序的编码的产生以及为发现错误而运行软件的测试。
一个优秀的监理工程师应该能够使用定量的方法来评估软件开发过程中产生的分析及设计模型、源代码和测试用例(use case)的质量。
软件开发质量的定量监理 为了实现这种实时的质量评估,监理工程师们必须采用技术度量来客观地评估质量,而不能仅仅采用主观的方法进行评估。
在评估中,首先要明确的一点是,软件需求是度量软件质量的基础。
不符合需求的软件就不具备质量。
而在定量监理实践中,通常需要使用一种被称为尺度度量的方法,这种定量度量适用于一些能够直接度量的特性,比如,出错率定义为错误数/KLOC/单位时间等。
因而,对质量控制所应该建立的一些定量数据是: (1)明确性(无二义性)、完全性、正确性、可理解性、可验证性、内部和外部一致性、可完成性、简洁性、可追踪性、可修改性、精确性和可复用性的数据。
这些数据可以用来评价分析模型和相应的需求规约质量的特征。
公开的可能缺陷数与报告总缺陷数的对比则可以用来评价测试精确度和测试覆盖度,同时也可以预测项目发布时间。
(2)产品发布前清除的缺陷数在总缺陷数中所占的百分比,有助于评估产品的质量。
(3)按严重缺陷、子系统缺陷来划分,分类统计出平均修复时间,这样将有助于规划纠正缺陷的工作。
(4)利用测试的统计数据,估算可维护性、可靠性、可用性和原有故障总数等数据。
这些数据将有助于评估应用软件的稳定程度和可能产生的失败。
在上述定量数据的基础上,就可以开始进行估算。
1、基本的定量估算 基本定量估算示例: 设 F为用功能点描述的软件规模; D1为在开发过程(提交之前)中发现的所有缺陷数; D2为提交后发现的缺陷数; D为发现的总缺陷数。
因此, D=D1+D2 对于一个应用软件项目,则有如下计算方程式(可以从不同的角度估算软件的质量): 质量=D2/F; 缺陷注入率=D/F; 整体缺陷清除率=D1/D; 同样以上期中的CAD软件为例,根据上期计算所得结果,功能点F为366,而在开发过程中发现了15个错误,提交后又发现了4个错误,则: D1=15,D2=4 D=D1 +D2=15+4=19 质量(每功能点的缺陷数)=D2/F=4/366=0.0109 缺陷注入率=D/F=19/366=0.05191 整体缺陷清除率=D1/D=15/19=0.7895 有资料报告,美国的平均整体缺陷清除率目前只达到大约85%。
而像AT&T、IBM、摩托罗拉和惠普这样一些大公司的顶级项目,通过实施最佳实践,其缺陷清除率可以超过99%。
众所周知,清除软件缺陷的难易程度是不同的。
需求错误、规格说明、设计问题及错误修改是最难清除的。
表1给出了美国平均缺陷的情况: 表2反映的是CMM五个等级是如何影响软件质量的,其数据来源于美国空军1994年委托SPR(美国一家著名的调查公司)进行的一项研究。
从表中可以看出,CMM级别越高,缺陷清除率也越高。
在监理过程中,可以将这这些标准或指标结合起来使用,用以辨明可能存在的质量问题。