全面质量管理在软件业的应用.docx
《全面质量管理在软件业的应用.docx》由会员分享，可在线阅读，更多相关《全面质量管理在软件业的应用.docx（26页珍藏版）》请在冰豆网上搜索。
全面质量管理在软件业的应用
全面质量管理在软件业的应用
早在20世纪60年代中期，人们就发现软件的生产出现了“问题”，主要表现在生产过程不规范，缺乏管理。
后来，人们在软件工程方法学中引入了工程的概念、原理、技术和方法，这种思想在一定程度上解决了软件生产过程中遇到的问题。
但是直至80年代还是没有提出一套管理软件开发的通用原则，软件管理不善的问题依旧在大范围内存在。
随着软件开发的深入、各种技术的不断创新以及软件产业的形成，人们越来越意识到软件过程管理的重要性，因此管理学的思想逐渐融入软件开发过程中，由美国软件工程研究所（SEI）提出的软件能力成熟度模型（简称SW-CMM）便是软件过程管理思想不断发展的集中体现。
CMM的管理思想背景
SW-CMM不仅是一个模型，一个工具，它更代表了一种管理哲学在软件工业中的应用。
SW-CMM的管理思想来源于已有60多年历史的产品质量管理。
1930年，WalterSheward率先提出了一整套基于统计学原理的质量控制方法，这些方法后来经过W.EwardsDeming和JosephJuran的发展和实践得到了广泛的应用。
PhilipCrosby在《质量是免费的》一书中率先提出将质量管理形成成熟度框架的概念，描述了进行质管实践的5个阶段，表达了质量管理的全部运作。
Deming、Juran以及Crosby等人的做法后来被称为全面质量管理（TQM）理论。
在IBM公司，WattsHumphrey和RonRadice将这种全面质量管理的思想应用于软件工程过程，收到了很大的成效。
SEI的软件能力成熟度模型就是在以Humphrey为主的软件专家实践经验的基础上发展而来的。
软件能力成熟度模型中融合了全面质量管理的思想，以5个不断进化的层次反映了软件过程定量控制中项目管理和项目工程的基本原则。
SW-CMM所依据的想法是只要不断地对软件企业的软件工程过程的基础结构和实践进行管理和改进，就可以克服软件生产中的困难，增强开发制造能力，从而能按时地、不超预算地制造出高质量的软件。
全面质量管理的含义和特点
含义全面质量管理（TotalQualityManagement，简称TQM）是一个组织以质量为中心，以全员参与为基础，目的在于通过让顾客满意和本组织所有成员及社会受益而达到长期成功的管理途径。
早期的质量管理仅限于质量检验，仅能对产品的质量实行事后把关，但质量并不是检验出来的，所以，质量检验并不能提高产品质量，只能剔除次品和废品。
1924年提出休哈特理论，质量控制从检验阶段发展到统计过程控制阶段。
休哈特认为，产品质量不是检验出来的，而是生产制造出来的，质量控制的重点应放在制造阶段，从而将质量控制从事后把关提前到制造阶段。
1961年费根堡姆提出全面质量管理理论（TQM），将质量控制扩展到产品寿命循环的全过程，强调全体员工都参与质量控制。
70年代，田口玄一博士提出田口质量理论，他认为，产品质量首先是设计出来的，其次才是制造出来的。
因此，质量控制的重点应放在设计阶段，从而将质量控制从制造阶段进一步提前到设计阶段。
特点全面质量管理即为全员、全过程、全方位的质量管理，力求全面提高经济效益。
包括以下基本特点:
（1）全员参加:
意味着质量控制由少数质量管理人员扩展到企业的所有人员。
（2）全过程:
将质量控制从质量检验和统计质量控制扩展到整个产品寿命周期。
（3）全面运用一切有效方法:
是指应用一切可以运用的方法，而不仅仅是数理统计法。
（4）全面控制质量因素:
意味着把影响质量的人、机器设备、材料、工艺、检测手段、环境等全部予以控制，以确保质量。
大多数经营管理者认为，全面质量管理的核心是强调一致性，克服随意性，消除差错，使顾客得到全面的满足，它强调为了取得真正的经济效益，管理必须始于识别顾客的质量要求，终于顾客对他手中的产品感到满意。
全面质量管理就是为了实现这一目标而指导人、机器、信息的协调活动。
因此，全面质量管理可以归纳为两大基本原则.
全面质量管理两大基本原则
首先是以满足顾客需求为导向，不断改善，最终达到顾客的全面满足；其次是以全员参与为基础，进行全过程的质量控制。
CMM对全面质量管理的体现
在软件业，软件质量得不到提高主要原因在于质量观念的缺乏，而将全面质量管理的思想运用于软件业，是提高软件产品质量、获取竞争优势的有效手段。
CMM不但对于指导过程改进是一项很好的工具，而且把全面质量管理概念应用到软件上，实现从需求管理到项目计划、项目控制、软件获取、质量保证、配置管理的软件过程全面质量管理。
CMM的思想是一切从顾客需求出发，从全组织层面上实施过程质量管理，正符合了TQM的基本原则。
因此，它的意义不仅仅是对软件开发的过程进程控制，最关键的它还是一种高效的管理方法，有助于企业最大程度的降低成本，提高质量和用户满意度。
CMM2
软件需求管理体现TQM的核心思想CMM的一个显著的特征是将软件需求作为一个活跃的实体贯穿于整个开发过程之中，实施有效的需求管理事实上渗透在CMM的不同层次（Level）和众多关键过程域之中。
软件需求是软件项目成功的关键，软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”。
美国质量管理协会（ASQC）将“质量”解释为“产品或服务内在特性和外部特性的总和，以此构成其满足给定需求的能力”，Crosby对于质量的定义也是“同需求保持统一”，从这个意义上说，只有满足用户需求的软件产品才谈得上有好的质量，反之，需求管理也正是从质量出发以确定需求。
CMM四级的“软件质量管理”过程域中也明确要求，组织、顾客和最终用户的软件质量需求及其优先级可以追踪到分配给软件的系统需求及软件质量目标。
因此，CMM的需求管理正是从全面质量管理的主导思想—“以满足顾客需求为导向”出发的，软件开发则应以需求工程作为核心过程（需求过程与其他过程的关系见图1）。
图1需求过程与其他过程的关系
需求工程无疑是当前软件工程中的关键问题，但又是软件工程中最复杂的过程之一。
完整的软件需求工程过程包括需求开发和需求管理两个部分，需求开发的一般过程分为需求获取、需求分析、编写需求规格说明书（SRS）、需求验证四个阶段，需求管理则主要包括需求基线的建立、需求变更控制以及需求跟踪等活动。
需求获取是通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；需求分析是为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述;由需求模型构件生成精确的形式化的描述，即需求规格说明书，它将作为用户和开发者之间的一致协议;需求分析的结果应该通过评审、测试等手段验证它的正确性、完整性和一致性，这就是需求验证。
贯穿于整个过程中，需求管理中最基本的任务则是明确需求，并使所有相关人员达成共识；建立需求跟踪能力联系链，确保所有用户需求被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求工程需要各类人员的参与，如领域专家、最终用户、系统投资人、需求分析员、系统开发人员等等，以不同的着眼点和不同的知识背景，获得对软件需求的全面理解。
需求工程最大的难度就体现在全方位需求的获取以及非功能性需求与功能性需求的错综复杂的联系上，当前对非功能性需求分析建模技术的缺乏大大增加了需求工程的复杂性，而非功能性需求往往又决定了对软件产品的质量要求。
因此，非功能性需求和质量特性的分析模型有待深层次的研究。
CMM3
软件产品工程体现TQM的过程控制从CMM三级开始,软件生命周期的各个阶段被严格地划分出来，其目的是保持软件工程活动和软件工作产品的一致性。
目前还有很多软件企业的软件开发工作仅限于编码，软件工程方法学中的各种方法和技术得不到真正的应用，因此单纯的软件工程技术并不能有效的解决“软件危机”，改善软件产品的质量;而单纯的测试也只是一种事后检测的方法。
只有通过软件过程管理，将需求、设计过程从编码中分离出来，才能对软件质量进行产品生命周期全过程、全方位的控制。
TQM的核心就在于防患于未然，做到事先控制，确信“下一道工序就是用户”，层层把好质量关，决不让不合格的半成品流入下道工序，一切为下道工序着想。
软件开发生命周期一般分为需求分析、概要设计、详细设计、编码、单元测试、集成测试、确认测试、系统测试几个阶段，常用的生命周期模型有瀑布模型、V模型、增量模型、演化模型和螺旋模型，实际的软件过程往往是几种模型的结合。
其中，V模型的运用越来越广泛，它强调了各个测试阶段与开发前期各阶段的对应，更明确表示了个各种工作产品间的关系，也易于用户在软件开发中的参与和评价（见图2）。
图2V模型
在软件的整个生命周期中，软件产品的质量首先取决于它的设计，因为质量、成本、效益的80%是在设计阶段就确定了的。
设计质量控制在TQM中也是非常重要的一个环节，事实证明:
产品投产后设计指标修改得越少，产品的质量水平也将越好。
要保证顾客对质量满意，就必须从产品开发研制阶段开始做起，需将用户对软件产品的质量要求转化成设计质量标准和开发过程中各个环节的技术要求。
因此，CMM要求每个阶段的软件工作产品必须文档化，并分别由上下游角色对其进行同行评审，置于严格的配置管理之下，以保证各角色在一致的基础上工作。
同行评审的目的则是在过程中及早地消除缺陷，减少后续阶段的返工，避免上一个阶段引入的缺陷遗留到下一个阶段，造成质量成本的成倍增加。
图3软件生命周期中的缺陷分布
从图3可以看出，缺陷是在开发过程的前期引入，但越到后期缺陷修复的成本越高，随着CMM级别的提高，缺陷的消除将从后期逐步转移到前期，遗留到用户手中的缺陷也相应减少，这必将大大缩短开发周期，降低不必要的成本。
因此，CMM的思想就是以过程为基础进行质量控制，把质量控制从事后检测转变为事前预防，能够尽量减少大的设计更改。
需求管理、全面质量管理以及TQM中常用的质量功能展开技术（QFD）也都是这种思想的反映。
CMM4
软件质量管理体现TQM的运行机制软件质量管理是CMM四级中一个独立的KPA，其目的是使项目的软件质量管理活动是有计划的、软件产品的质量目标是量化的和受到管理的。
它遵循了全面质量管理活动的科学程序—PDCA（Plan、Do、Check、Action），即四个阶段:
（1）计划:
即确定质量目标以及实现这个目标需要采取的措施。
制定质量计划是整个质量管理活动的基础。
国家标准对质量下的定义为:
质量是产品或服务满足明确或隐含需要能力的特征和特性的总和。
对于软件来说，软件质量则体现在质量特性上，ISO/IEC9126中规定了6个质量特性，即功能性、可靠性、易用性、效率、可维护性和可一致性，每个特性包含若干子特性。
设定质量目标就是要找到用户的质量需求与这些质量特性的相关性，并将其转化为开发过程中可度量的技术指标或能力指标，作为质量控制的依据。
上述的六大特性属于软件的外部属性，与用户满意度直接相关，可以根据组织的目标和项目的特点建立质量模型，并采用一定的方法，如QFD（QualityFunctionDeployment）、GQM（GoalQuestionMetrics）等确定量化的质量目标，但这在实际工作中往往是相当复杂和难以获得的。
因此，更常用的做法是以过程能力目标反映产品质量目标，一个典型的能力指标就是缺陷密度（即每单位规模工作产品中存在的缺陷数）和相应的阶段缺陷排错率，可以根据历史数据估计产品的规模和目标缺陷密度，从而对每个阶段发现的缺陷数量进行控制。
（2）实施：
即按预定计划、目标措施及其分工实际执行。
为了在过程中控制软件的质量，需采取相应的手段在预定的阶段点或里程碑上进行软件工作产品质量的测量，常用的方法有同行评审、原型评价、测试等。
这些方法主要从两方面对软件的质量进行度量，一是内部属性，即过程和活动自身可以度量的属性，例如工作产品的缺陷密度；二是外部属性，即与用户环境相关的属性，这些属性在过程中往往难以度量，只有通过在项目的早期引入用户测试来予以评价，而让用户参与开发过程，大大有利于产品质量的提高。
（3）检查：
即把实施的结果和计划的要求对比，检查计划的执行情况和实施的效果，是否达到预期的目标，并找出原因。
在对质量度量的结果进行分析时，往往会用到一些统计工具和方法，如检查表、直方图、控制图、Pareto图、散布图、因果图、运行图等。
这些工具可以帮助确定问题、评估现状、发现原因甚至形成下一步措施。
（4）处理：
即总结经验教训，将未解决的问题作为下一阶段制定计划的依据。
CMM要求对软件质量测量的结果分析后，应“采取合适的与软件质量计划相一致的措施，以便使得产品的质量测量结果与软件质量目标相符合”。
软件度量的方法体系
项目度量
项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。
规模度量
软件开发项目规模度量（sizemeasurement）是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。
规模度量是软件项目失败的重要原因之一。
一个好的规模度量模型可以解决这一问题。
有效的软件规模度量是成功项目的核心要素：
基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。
规模度量的要点在于：
由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。
软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。
软件规模的估算方法有很多种，如：
功能点分析（FPA：
functionpointsanalysis）、代码行（LOC：
linesofcode）、德尔菲法（Delphitechnique）、COCOMO模型、特征点（featurepoint）、对象点（objectpoint）、3-D功能点（3-Dfunctionpoints）、Bang度量（DeMarco'sbangmetric）、模糊逻辑（fuzzylogic）、标准构件法（standardcomponent）等，这些方法不断细化为更多具体的方法。
1.功能点分析法
（1）功能点分析法概述
功能点分析法（FPA：
functionpointanalysis）是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。
FPA法由IBM的工程师艾伦·艾尔布策（AllanAlbrech）于20世纪70年代提出，随后被国际功能点用户协会（IFPUG：
TheInternationalFunctionPointUsers'Group）提出的IFPUG方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：
“在外部式样确定的情况下可以度量系统的规模”，“可以对从用户角度把握的系统规模进行度量”。
功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。
经由ISO组织已经有多种功能点估算方法成为国际标准，如：
①加拿大人艾伦·艾布恩（AlainAbran）等人提出的全面功能点法（fullfunctionpoints）；②英国软件度量协会（UKSMA：
UnitedKingdomSoftwareMetricsAssociation）提出的IFPUG功能点法（IFPUGfunctionpoints）；③英国软件度量协会提出的MarkIIFPA功能点法（MarkIIfunctionpoints）；④荷兰功能点用户协会（NEFPUG：
NetherlandsFunctionPointUsersGroup）提出的NESMA功能点法，以及软件度量共同协会（COSMIC：
theCOmmonSoftwareMetricsConsortium）提出的COSMIC-FFP方法，这些方法都属于艾尔布策功能点方法的发展和细化。
（2）功能点分析法的基本计数
功能点分析的基本计数就是依据标准计算出的系统（或模块）中所含每一种元素的数目：
①外部输入数（EI：
externalinput）：
计算每个用户输入，它们向软件提供面向应用的数据。
输入应该与查询区分开来，分别计算。
②外部输出数（EO：
externaloutput）：
计算每个用户输出，它们向软件提供面向应用的信息。
这里，输出是指报表、屏幕、出错信息，等等。
一个报表中的单个数据项不单独计算。
③外部查询数（EQ：
externalquery）：
一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。
每一个不同的查询都要计算。
④内部逻辑文件（ILF：
internallogicalfile）：
计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。
⑤外部接口文件（EIF：
externalinterfacefile）：
计算所有机器可读的接口，如磁带或磁盘上的数据文件，利用这些接口可以将信息从一个系统传送到另一个系统。
（3）功能点分析的主要步骤
功能点分析可以按照如图5-6所示步骤进行：
图5-6功能点分析的主要步骤
（4）案例：
CSK株式会社的功能点分析案例
【CSK株式会社的CSFPA概述】
在实施CSFPA之前，CSK以Step数方法来估算开发规模。
但是在利用VB、C++、Java、SQL等语言的项目开发中，用Step数方法进行规模估算比较困难。
为了以定量化手段降低甚至消除估算错误，CSK在IFPUG（InternationalFunctionPointUsersGroup）的FP法的基础上加以改良开发出自身的CSFPA（CSKSimplifiedFunctionPointAnalysis）法，并在企业内加以实施。
CSK于1995年加入IFPUG组织，并于1998年开始正式开展活动。
CSFPA改良的两点是：
增加了度量要件定义等上游工程的简易测量功能；避免使用人为因素太强的调整系数。
CSFPA法适用体制在项目估算时的FP度量、项目完成时的FP度量、实际数据的收集、统计分析、工数模型化、质量指标化等方面具有CSK特有的方式，CSK在该方法的教育与培训、模型构筑、估算·质量计划的适用、结果评价·差异分析等方面取得了良好的绩效。
【CSFPA法的估算步骤】
CSFPA法与IFPUG法的估算步骤有所不同，二者的相似点以及不同点请参照图5-7。
图5-7CSFPA功能点估算步骤
【CSFPA法的推广运用】
为了普及和适用CSFPA，CSK在企业内设立由多名专任人员组成的事务局，推进方法的定义以及维护、管理、员工教育、度量支援、数据收集、统计分析、数据利用等。
下面对CSFPA的适用体制加以介绍。
项目估算时的FP度量。
在估算时度量软件规模，通过适用相应的工数模型测算预计工数，以此作为制定日程的根据。
CSFPA的工数模型以开发的全过程为对象，按照项目的开发范围进行估算，将式样、品质、技术的对应要件作为变动要素对此加以调整。
项目完成时的FP度量。
在项目完成阶段对FP数、使用环境、技术、工数以及质量信息等几十个项目加以记录，比较估算时的FP数并进行差异分析，以提升度量精度和模型有效性。
实际数据的收集。
将度量的实际数据剃除异常点后纳入数据库，并加以分析，然后向全企业公开。
这种标本数据已经超过400件。
由于FP度量过程中由于度量者的不同可能导致较大的误差，事务局还面向经验甚浅的度量者提供现场支持，验证度量结果的妥当性，提高度量的精度。
另外，还与其他企业所提供的数据进行比较验证，持续收集数据。
统计分析。
对于收集起来的数据，还需要考虑到项目特性的差异并加以分析。
作为分析的界限，CSK建立了包括约50种类型（可视化工具类开发、Web类开发、维护的主框架开发等）的数据库，并对各自包括工数在内的10种以上的项目和FP值实施相关分析。
工数模型化。
CSK将FP数和工数的关系称之为“工数模型”，现在已经拥有可适用的6种工数模型。
这些模型与实际数据的收集相配合，实施差异分析，持续提升估算精度。
质量指标化。
与工数模型一样，CSK将FP数和质量数据（缺陷、问题等）之间的相关关系作为质量模型加以提供。
通过定义经由质量模型获得的指标，并与现存的指标相结合，构筑综合性的质量指标。
【CSK推进FP法的经验总结】
度量方法的教育与渗透——启蒙。
要使用FP法进行度量，当然需要了解度量规则。
CSK在其“项目管理研修”这一体制中，对企业员工实施教育，讲解FP法的定位、概要、使用方法，进行度量演习，让企业员工掌握FP法。
模型构筑——提升估算精度的路径。
要使用各种模型提升估算的精度，需要度量项目特性以及仔细检查数据。
CSK通过现场调研和支援活动，积累起专业知识和技能，并对技术、式样、质量方面的特性信息加以整理，构筑适合CSK的估算模型，提高估算精度。
估算·质量计划的适用——制定适当而正确的计划。
构筑起来的模型在实际提案的时候作为估算的根据或者在产品的质量计划制定过程中适用。
在模型不断适用的情况下，这些模型的适用实例也就逐渐丰富起来。
结果评价·差异分析——取得反馈信息至更高水平的运用。
项目开发过程中，变更点管理以及计划与实绩的差异分析非常重要。
在这个过程中，需要获得适当的反馈信息，在把握复杂的项目状况的同时需要灵活应对这些变更和反馈。
CSK在这方面也在积极运作并在整个企业内展开。
【CSK功能点法今后的展开】
将FP作为商务活动中的共通尺度是CSK导入FP法的主要目的之一。
为了提高CSK与顾客之间将之作为共通尺度的认知度，CSK认为需要实施如下事项：
一是提高方法本身的认知度和信赖性；二是客观地验证度量数据的精度。
FP是度量软件规模的手段，在软件开发的商务活动、项目管理、资产管理等诸多场合中都是切实把握规模的依据，是以适当的价格提供高质量软件的基础，也是客观性表示CSK的生产性的重要因素。
CSK在通信、控制、嵌入式开发中正在试用COSMIC-FFP。
2.代码行
代码行（lineofcode）指所有的可执行的源代码行数，包括可交付的工作控制语言（JCL：
jobcontrollanguage）语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。
一代码行（1LOC）的价值和人月均代码行数可以体现一个软件组织的生产能力。
组织可以根据对历史项目的审计来核算组织的单行代码价值。
代码行LOC常用于源代码的规模估算，常使用的单位有：
SLOC（singlelineofcode）、KLOC（thousandlinesofcode）、LLOC（logicallineofcode）、PLOC（physicallineofcode）、NCLOC（non-commentedlineofcode）、DSI（deliveredsourceinstruction）。
3.德尔菲法
德尔菲法（Delphitechnique）是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管德尔菲技术可以减轻这种偏差，在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其他模型的输入时特别有用。
德尔菲法鼓励参加者就问题相互讨论。
德尔菲法的步骤是：
（1）协调人向各专家提供项目规格和估算表格；
（2）协调人召集小组会和各专家讨论与规模相关的因素；（3）各专家匿名填写迭代表格；（4）协调人整理出一个估算总结，以迭代表的形式返回给专家；（5）协调人召集小组会，讨论较大的估算差异；（6）专家复查估算总结并在迭代表上提交另一个匿名估算；（7）重复4～6，
升级会员 