本文通过中国郎中看病这个案例进而类比软件项目质量管理，对软件项目质量管理的论述和分析，并对改善软件质量的各个因素进行了讨论，最后对软件项目质量管理的现状进行分析，并对对其发展趋势进行展望。
通过对中国郎中看病的故事，我们给了软件项目质量管理一个通俗的解释和分析，分别用大儿子、二儿子以及三儿子类比软件项目管理过程中的各个角色和阶段。通过对软件质量的各种定义将“质量”这个词作了详尽分析，在以上所讨论的基础之上，我们解说了影响了软件项目质量管理的多个重要因素，并以多个图表图像的形式进行说明，形象生动。最后，笔者查找相关文献，谈了软件项目管理的现状和发展趋势，对于该课程的理解和体会，在文中最后做了较为详细的陈述。
缺陷降低软件质量，这是业界公认的事实，对于还未进入软件事业单位的我们来说，熟练掌握这些知识是百利而无一害的，在以后的的学习生活和研究中，一定不懈奋斗。
一、案例分析 1.1案例回顾
在中国古代，有一家三兄弟全是郎中。其中动人的高山是名医，人们问他：“你们兄弟三人谁的医术最高？” 他回答说：“我常用猛药给病危者医治，偶尔有些病危者被我救活，于是我的医术远近闻名并成了名医。我多情的机器猫通常在人们刚刚生病的时候马上就治愈他们，临近村庄的人说他是好郎中。我大哥不外出治病，他深知人们生病的原因，所以能够预防家里人生病，他的医术只有我们家里才知道。”
1.2案例类比分析
郎中三兄弟是三种治病方式的代言人，消除软件缺陷的三种方式：
老大治病的方式最高明，如果人们能够预防生病的话，那么没病就用不着看医生了。提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
即使一个人严守养生之道，身体状况良好，但总是会意外地得病的，得了病就要去看医生。 老二治病的方式就是医院的模式，病人越早看病，就越早治好，治病的代价就越低。
同理，在开发软件的时候，即使人们的技术水平很高，并且严格遵守规范，但是人非机器，总是会犯错误的，因此无法完全避免软件中的缺陷。
动人的高山治病的方式代价最高，只能是不得已而为之。可在现实之中，大多数软件企业采用动人的高山的方式来对付质量问题。典型现象是：在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。
1.3全面软件项目管理模型
结合老大老二的治病方式，我们提炼出以上软件质量管理模型图，项目中的所有人员几乎都参与了活动，只是介入的程度不同。质量的死对头是缺陷，缺陷是人们在软件开发过程中不喜欢和不愿看到的东西，但是又是难以避免的事情，缺陷越大，质量越低，提升软件质量的首要任务是减少软件缺陷。
二、软件质量 2.1软件质量定义 2.1.1词典定义① 典型的或本质的特征；
② 事物固有的或区别于其他事物的特征或本质；
③ 优良或出色的程度。
2.1.2 CMM定义① 一个系统、组件或过程符合特定需求的程度；
② 一个系统、组件或过程符合客户或用户的要求或期望的程度。
2.1.3百度词条定义
概括地说，软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地说，软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。
2.1.4通俗理解
古时候人们以为长得结实、饭量大就是健康，这显然是不科学的。现代人总是通过考察多方面的生理因素来判断是否健康，如测量身高、体重、心跳、血压、血液、体温等。如果上述因素都合格，那么表明这人是健康的。如果某个因素不合格，则表明此人在某个方面不健康，医生会对症下药。
通过类比，我们这样理解软件质量： 软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。
2.2影响软件质量的因素
2.3软件质量度量
2.4软件质量要素
从技术角度讲，对软件整体质量影响最大的那些质量属性才是质量要素；
从商业角度讲，客户最关心的、能成为卖点的质量属性才是质量要素。
对于一个特定的软件而言，我们首先判断什么是质量要素，才能给出提高质量的具体措施，而不是一股脑地想把所有的质量属性都做好，否则不仅做不好，还可能得不偿失。
如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。
商业目标决定质量目标。提高软件质量的最终目的是为了赢利，而不是创造完美无缺的产品。因此对于普通商业软件而言，并不是“质量越高越好”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
2.5软件质量度量的实施
2.5.1确定软件质量需求
（1）软件的功能需求的确定，存在一定的难度。而非功能需求的确定，则难度更大。这些困难包括：需求如何获取，需求冲突如何协调、需求的确认和变更的授权等。
（2）需求获取：首先，你要理解用户的需求，区分哪些是质量需求，
把这些需求记录下来，获得用户的确认。
（3）需求分析：拿到用户确认的需求后，你可以开始把用户的质量需求与我们设定的质量特性联系起来，一直区分到子特性。这种联系，就是把用户语言描述的需求，转变为计算机工程师语言的需求。建立了这种关联后，可以根据分类，分级，确定直接度量。
2.5.2确定直接度量
直接度量就是实际的软件质量测量活动，它的输入是软件或软件过程，输出是一个测量值。它通过执行一系列的任务，获得一个质量值。
在确定直接度量前，应该有如下准备：
（1）工具：有助于计算度量值的硬件/软件工具，如：缺陷跟踪工具；
（2）应用：描述度量结果的希望值、度量值的意义、作用和对度量结果数 据的使用方法；
（3）数据：获得度量结果所需的数据、程序、过程等度量对象；
（4）计算：度量程序、步骤和方法。
（5）费用：测试是要花钱（人力、物力、时间等）的。
2.5.3分析度量结果
对度量过程进行跟踪和分析，需要时，可能会对度量程序、度量工具、度量方法，甚至原始数据，做出补充和调整。
2.5.4确认质量度量
首先，要确认度量过程是否与事实相符，脱离现实真实的度量，与目标再相符的结果也是没有意义的。其次，是确认方法的有效性。
2.5.5其他度量
* 分析模型的度量（对分析模型的度量以测试系统的大小）
* 设计模型的度量（度量体系结构、数据和系统的复杂度）
* 源代码的度量（度量程序的长度、层次、开发量、时间等）
* 对测试的度量（度量测试的宽度、深度、错误的级别）
* 对维护的度量（度量软件的稳定性）
三、全面软件质量管理 3.1软件项目成功率调查
3.2全面软件质量管理具体步骤
3.2.1制定质量管理计划
质量管理计划是全面质量管理的行动纲领。
事先预防的思想，“缺陷越早发现越早修改越经济”的原则，缺陷纠正得越晚成本越大 ：自从 Deming 的全面质量管理（ TQM ）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。
产业界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和最终的缺陷）数量的 50 ％到 65 ％。根据 IBM 的研究表明，假定在分析阶段发现的错误其改正成本为 1 个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为 6.5 个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为 15 个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为 60 到 100 个货币单位。
3.2.2软件质量保证活动
为项目准备SQA 计划，参与开发项目的软件过程描述，评审各项软件工程活动，以验证其是否符合定义的软件过程，审核指定的软件工作产品，以验证其是否符合定义的软件过程中的相应部分，确保软件工作及工作产品中出现的偏差已文档化，并且按照文档化的
规程进行了处理，记录所有不符合的部分，并报告给高层管理者。
3.2.3软件评审
软件评审是软件过程中的“过滤器”，目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量，软件评审包括“正式技术评审”、“走查”、“审查”、“轮查”等。
* 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误；
* 验证评审中的软件是否满足其需求；
* 保证软件的表示符合预先定义的标准；
* 得到以统一的方式开发的软件；
* 使项目更易于管理。
正式技术评审流程
技术评审的好处有：
* 通过消除工作成果的缺陷而提高产品的质量；
* 技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就
越能降低开发成本；
* 开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，
更好地预防缺陷，一定程度上提高了开发生产率。
3.2.4质量保证，过程检查
* 过程检查计划的要点是确定主要检查项和检查时间（或频度）。
* 质量人员在执行过程检查的时候，如果发现问题，应该立即记录下来。过程问题也是缺陷，因此最好使用缺陷跟踪工具，有助于提高过程检查的效率。
* 质量人员首先设法在项目内部解决已经发现的质量问题，与项目成员们协商，给出解决措施。在项目内难以解决的质量问题，由上级领导给出解决措施。
3.2.5缺陷跟踪工具
* 如果没有缺陷跟踪工具的话，人们只好用纸张或文件去记录缺陷，不仅变更缺陷信息很麻烦，而且难以共享信息。缺陷跟踪工具就是帮助项目成员记录和跟踪缺陷用的，一般都有数据库支持，可以在局域网内运行。
* 由于缺陷跟踪工具仅仅是一种辅助性的工具，我们没有必要太在乎该软件的功能，只要用起来方便就行。
* 缺陷的主要属性：缺陷ID, 缺陷类型,缺陷状态,缺陷描述,相关文件,严重性,优先级,报告者,报告日期,接受者,解决方案（建议）,解决日期 。
* 缺陷跟踪工具的常见功能：查询缺陷,添加缺陷,修改缺陷,删除,缺陷分类图,缺陷趋势图, Email。
3.2.6 人员
* 谁对软件质量负责 ？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
* 谁对软件质量负最大的责任 ？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
* 质量人员的主要职责：
（1）负责制定质量计划（很重要但是工作量比较少）；
（2）负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；
（3）参与技术评审，约占个人工作量的30%；
（4）参与软件测试，约占个人工作量的30%；
（5）参与软件过程改进（面向整个机构），约占个人工作量的20%；
四、软件质量管理现状及发展趋势 4.1软件质量管理现状
在现实软件开发过程中,许多软件产品却时常陷入质量低下、甚至软件不符合用户需求的旋涡.究其根源,有以下几个方面:
（1）软件质量保证技术(审查、复审和测试)没有贯穿到整个软件开发全过程中去.
（2）在于这些软件产品对其质量内涵的把握,仅仅停留在减少软件运行错误、加强软件测试,避免软件缺陷的一般性层面,而对整个软件开发生命周期的全过程质量管理,缺乏总体架构.
（3）测试管理的一些误区也会导致严重的质量问题.没有按照测试原则进行尽早测试、连续测试与自动化测试.是测试本省变得的形式化.
（4）质量是全过程的,不仅是测试.质量管理者应该将质量控制与保证着眼于整个软件开发生存周期内.而事实上,质量管理者仅仅认为通过严格的测试就可以保证软件质量.
4.2软件项目质量管理的发展趋势
缺陷分析的提出是由于在质量管理中人们逐渐意识到的一个开发人员如果在某个方面出了问题导致软件缺陷的产生，那么今后的开发过程中他很可能在整个方面再次出问题，再次导致软件缺陷的产生。因此，对在软件开发过程中记录的软件缺陷进行分析不仅重要，而且必要。如果了解经常导致缺陷产生的活动，那么在今后开发中就可以着重防范这些活动，提高过程质量进而提高产品质量。
根本原因分析RCA和统计增长模型SGM是两种常用的软件缺陷分析方法。由于根本原因分析只有在得到了每个缺陷的所有细节之后才能进行有效的分析，因此它需要进行大量的活动才能完成。与之对比，统计增长模型提供了一个简单地方法来跟踪缺陷的走势，但是由于对缺陷的细节了解太少，它只能进行缺陷的跟踪却不能对缺陷的修复活动给出任何建议。
在这种情况下，正交缺陷ODC被提了出来。ODC是一种快速得到缺陷细节的方法，它通过定义和捕获缺陷属性使得对缺陷进行数学分析、建模成为可能。正将缺陷分类的数据分析提供了一个又价值的评估软件生命周期各个阶段、需求、设计、开发、测试以及维护以及产品和过程熟度的方法。
ODC是IBM华生研究中心在20实际90年代初提出的一个概念。最初基于ODC的分析方法主要用于在过程中把实际缺陷数据的反馈提供给开发人民和测试人员。此外，作为一种加强ODC的基本方案中已考虑进了面向对象编程这个因素。这些年来，ODC已经被实验性的用于60多个项目。现在IBM有超过4000名软件专业人员受其影响。如Motorola、Tandem和Nortel也已接受了这项技术。
五、学习《软件过程与CMM》课程感受
在现在这个信息发达的时代，软件质量的重要性也越来越重要，越来越被人们所认识。软件是产品、是装备、是工具，同时我也任务软件产品也是艺术，其质量决定这顾客的满意度。所以在软件开发过程中需要一个有力的工具来管理其开发过程，以使软件产品更加完美。
CMM（Capability Maturity Model for Software）是指“能力成熟度模型”，它的本质是软件管理工程的一个部分。它是对于软件组织在定义、实施、度量、控制和改善其软件工程的实践中各个发展阶段的描述。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。其目的是通过一个合理的体系模型来对软件组织开发能力进行合理有效的评估，帮助软件组织在模型实施的过程中提高软件过程管理能力，降低软件系统开发风险，在预定的项目周期和预算内开发出高质量的软件产品。它是学术界和工业界公认的有关工程和管理实践的最佳的软件过程。为评估软件组织的生产能力提供了标准，也为提高软件组织的生产过程指明了方向。
短短八周时间转瞬即逝，《软件过程与CMM》这门课程已进入尾声，作为一门选修课，我对该课程的热爱程度好不亚于任何必修课，这八周以来，该课程我从未出现过任何迟到早退缺堂的情况，对于这样的偏管理方面的课程，我是情有独钟的，看多了工科性质的专业课，在这门课程的洗礼下，感觉自身在专业的全局体味上有了较大的提升，学习软件工程，不仅仅是写代码编程，相反，这只是一个很小的部分，而更多上层或是设计方面的事情才是一个合格大学生所具备的本领。
我很喜欢会撒娇的季节的教学风格和教学理念，也很喜欢这门课程，只是感觉课时太少，以至于早早结束这门课程而留念不已。往后，我定会选修老师的其他课程，争取在会撒娇的季节的带领下学到更多的专业知识和职业素养。
这篇论文学生花了很长的时间来反复琢磨，一字一句都是经历了无数次心理斗争后的产物，每一个图形图表都是自己的独有创作，在上次的课堂课堂讨论过程中，我更是踊跃地上台担任PPT讲解负责人。在往后的学习过程中，学生一定更加努力，不负老师所望！
六、参考文献
[1] 清秀的楼房. 软件过程管理. 北京：清华大学出版社，2007,4-1
[2] wsdfj. 软件过程改进. 机械工业出版社，2003,4-1
[3] 忧郁的哑铃. 能力成熟度模型软件过程改进指南. 美国卡耐基梅隆大学软件工程研究所，电子工业出版社. 2003,4-1