浅谈软件质量管理.doc

浅谈软件质量管理[1]
随着信息技术的广泛应用，软件已成为大多数产品的重要组成部分，如何提高软件质量，使软件更好地服务于各种应用需要，已成为各行各业广泛关注的课题。本文介绍了软件质量概念和软件质量管理的内容。针对软件的特点，并提出了加强软件质量管理的必要性。
    一软件质量的定义
    软件质量：即国际化标准组织 9126中将软件质量定义为反映软件产品满足规定需求和潜在需求能力的特征和特征的总和。将软件质量定义所有描述计算机软件优秀程度的特性的组合也就是为了满足软件的各项精确定义的功能、性能要求合文档化的开发标准需要相应的给出或设计一些质量特性及其组合。要得到高质量的软件产品就必须使这些质量特性得到满足。目前对软件质量特性有多种提法但实际上是大同小异。 9126国际标准中定义的软件质量特性为以下六项：功能性可靠性易使用性效率可维护性可移植性。
    二影响软件质量的因素
    软件本身的特点和目前软件的开发模式的一些缺陷，使软件内部的质量问题有时不可能完全避免。
    1、软件本身的特点软件具有复杂性、一致性、可变性和不可见性。软件规模的增大，导致它的复杂程度大大增加，并且让整个开发工作变得难以控制和管理。如果说编写一个数十行到数百行的程序连初学者也不难完成，那么开发一个数万以至数百万行的软件，其复杂度将大大上升，即使是富有经验的程序员，也难免顾此失彼。例如，开发一个学生上机考试系统，需要根据实际情况考虑到不同专业、不同考试科目、不同层次的用户的使用，其复杂性是显而易见的。尤其糟糕的是，软件的可靠性往往随规模的增长而下降，质量保证也越来越困难。
    2，开发环节多根据传统的瀑布模型将软件的生存周期划分为：计划时期的问题定义和可行性研究；开发时期的需求分析、概要设计、详细设计、编码和测试；运行时期的维护。各个阶段之间具有顺序性和依赖性。在这里，顺序性有两重含义：第一，只有等前一阶段的工作完成以后，后一阶段的工作才能开始。第二，前一阶段的输出文档，就是后一阶段的输入文档。想在后阶段获得正确的结果，必须在前阶段有正确的输出。因此，如果在生存周期的某一阶段出现了问题，往往要追溯到在它之前的一些阶段，必要时还要修改前面已经完成的文档。
    3、选择支持工具目前软件开发工作大多是手工操作，借助工具自然可以提高效率，减少出错机会。但是，在软件的整个开发过程中，能够得到的开发工具或管理工具十分有限。、G语言、、 、、等都可以作为开发工具使用，在面临具体问题时，要根据各种语言自身的特点和开发人员的熟练程度，灵活机动地选择。
    4，测试的局限性目前在软件开发过程中质量保证的主要手段是测试。广泛采用的仍然是白盒测试和黑盒测试。而软件测试的局限性在于，虽然它能够帮助我们尽可能多地发现软件中隐藏的问题，但是，有一些错误仍然存在，因为测试本身也是有缺陷的，不是尽善尽美的。也就是说，我们通过测试，可以在一定程度上把错误减少到最低限度。
    三、软件质量管理方法
    由于软件是一种技术密集的、智力劳动的产品，一般软件具有实用性、抽象性、灵活性、复杂性、无磨损、不老化等特点，特定软件还具有高安全性、高可靠性、适应性强、实时性要求高等特点。软件的生产与硬件也不同，软件没有明显的制造过程，软件的开发至今仍不能自动化地进行而以人工开发方式为主。针对软件的特点，对软件的质量控制，更应该注重软件过程的控制，通过完善质量管理体系以适应软件质量管理要求和加强软件过程管理来实现。
浅谈软件质量管理[2]
1、软件质量管理体系软件及软件质量形成与硬件有明显的差别，因此软件质量管理要求与硬件质量管理要求也有所不同。基于目前产品主要承制单位按照9000标准要求建立质量管理体系的实际，为了提高质量管理体系对软件质量管理的适应性，确保软件开发质量，根据软件的特点，对于承担软件研制的承制单位，应在现有质量管理体系的基础上，补充完善软件质量管理要求，以确保软件质量满足要求。与此同时，根据软件质量形成的特点和软件作为产品管理的理念还没有得到普遍接受的实际，在质量管理体系建设中还要采取以下方法以强化软件的质量管理：
    （1）建立标准软件过程。标准软件过程是指承制方定义的基本软件过程，它描述基本的软件过程单元以及这些软件过程单元之间的关系，用它来引导建立项目软件过程。
    （2）纳入项目计划。软件应作为相应项目的配套产品纳入项目研制计划和产品配套表。
    （3）管理开发和验证环境。应确定、提供并维护软件开发和验证环境（工具、技术和方法），验证环境也应按质量管理标准有关监视和测量装置的控制要求进行控制。
    （4）控制采购软件。对采购的软件产品也应按照质量管理标准有关采购的要求进行控制。
    2、软件过程管理方法
    （1）软件给定需求控制给定需求，即“指定给软件的系统需求”，是系统需求的一部分，以文档形式给出。
    （2）软件质量策划对具体的软件项目，承制方应根据软件项目的特点，策划和实施与质量有关的活动，软件质量策划应与质量管理体系其他过程的要求相一致。
    （3）软件维护　根据合同的要求和策划的安排，对交付和安装后以及运行过程中的软件进行维护，维护活动结束应保持软件的一致性。
    （4）软件开发策划对软件的开发进行策划和控制，应根据承制方的标准软件过程，通过策划确定项目软件过程编制项目开发计划。
    （5）软件配置管理配置管理提供一个标识、控制和追踪每个软件项的正式版本的机制，以保证软件项目生成的产品在软件生命周期中的完整性。
    （6）软件开发控制　软件开发应在受控条伴下进行，按选定的开发文档标准编制文档。
    四加强软件质量管理的途径
    软件企业可以通过多种途径加强质量管理，提高软件产品的质量。
    1、重视质量管理　我们都知道，在工业生产中，即使有先进的设备与技术，管理不善的企业也不能获得良好的经济效益。对于软件生产，不能按时按质完成计划，其中管理混乱往往是一条重要原因。我国软件开发机构的管理相对比较薄弱，其中质量管理尤其显著，这与我们重技术、轻管理有关。为了做好软件质量管理工作，首先要从认识上转变过来，因为思想往往是行动的先导。
    2、开发小组的人员应该少而精　软件的质量依赖于参与开发工作人员的质量和数量。开发过程，提高软件产品质量。近年来，采用面向对象的开发技术、原型开发方法、三层结构、软件构件、软件复用、分布计算、等方法，取得了一定的效果。除此之外，还有一种净室开发技术，其基本思想在于“净化”软件开发过程，使得差错或缺陷不可能有机会混入开发过程。如果软件的需求可以用形式描述方法方便地表达出来，那么整个开发过程就会像公式推导那样严谨、无懈可击。
    总之提高软件质量势在必行，只有认识到软件质量的重要性，了解影响软件质量的因素，才能有的放矢，采用科学的管理技术和先进的技术方法，才可以确保软件的质量。
软件开发各阶段的质量控制[1]
提到软件开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉得人力资源不够，总是觉得我们没有太多的时间。等到代码终于开发完成了，测试进度却又非常令人担忧，每一个小都要花很长的时间去查找，改了某一个小错误却又引起了很多错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。
　　怎样摆脱这样的困境呢？为何软件开发项目管理这么困难呢？为何我们做的计划总是不能按时完成呢？为何软件开发不能像硬件开发那样可以控制呢？原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢？就像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。
　　软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证呢？有人想到了9000、，也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，和到中国来就变了味了，为什么变味儿了呢？其实我们只学到了该做什么，却不知道怎样去做，为什么要这样做？大家都知道做软件开发需要写需求规格说明书和设计文档，为什么要写，文档的重要性有多高？没有资深开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，对后面的编码和测试没有实际的指导作用，甚至起了“误导”作用，同样会引起大量返工，那么这些文档除了负担之外就没有其他用途了，要知道写这些文档是需要消耗项目组资源的（进度、成本…）。
　　很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方面的知识。
　　1、需求
　　我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对( )
比较熟悉的话，需求分析可以利用工具进行，这样可以减少一些自然语言引起的歧义，但是可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
软件开发各阶段的质量控制[2]
1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。4、另外注意引用的术语和词汇是否前后一致。5、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。
　　另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？哪些需求又太粗了呢？答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。
　　2、设计
　　软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少？对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何？一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
　　1）、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。
　　2）、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。
　　3）、维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。
　　4）、可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。
　　5）、可靠性：包括缺陷数量、容错性、可用性。
软件开发各阶段的质量控制[3]
6）、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。
　　3、编码
　　代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的方法太多也会导致类之间的高耦合性增加。
　　也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作
　　周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率（有些时候还影响维护人员的心情），反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。
　　代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。
软件项目质量管理三部曲
质量目标+质量控制+质量保证
    质量目标：提出软件质量的特性和明确的可测量的标准。它包含的动作有合理正确的解读需求，确定测试范围和测试内容，制定具体的测试准则。这部分内容一般由质量部门完成。
    我们后续做的软件测试工作，其实就是把执行的结果和预期设定的目标进行比对，符合的认为有质量的，不符号的则是错误的。
    质量控制：为了保证每个工作产品都能满足需求而进行的一系列的审查，评审和测试的工作。审查，评审主要针对需求的正确性，它属于设计质量的范畴；测试主要针对需求实现的功能，是一致性质量的范畴。
    我们可以把软件质量按照特征分为两类，设计质量和一致性质量。设计质量是设计者所规定的产品的特征，包括需求说明，产品规格说明和设计说明；一致性质量是具体实现的问题，也就是编码所实现功能。
    其实目前我们所做的主要工作就是质量控制阶段的测试部分，让它独立的去承担质量的风险，而我们所测试的基本都是一致性质量，对于设计质量很少涉及。那么我们应该怎么去测试设计质量，由什么职能的人员和部门去完成，都是需要思考的。
    质量保证：质量保证由评估质量控制活动有效性和完整性的一系列审核和报告所构成。其目的是为管理层提供了解产品质量所必须得测试数据，从而获得产品质量是否符合预定目标的信心。此数据也是为持续的过程改进提高了数据依据。它就是我们通常所说的测试总结和测试报告阶段，但包含的内容应该更丰富。
如何做好软件工程质量管理？[1]
在实际的项目质量管理中，质量管理总是围绕着质量保证( )过程和质量控制( )过程两方面。这两个过程相互作用，在实际应用中还可能会发生交叉。正如引言所述，关于软件的质量，很难下一个非常明确的定义。本文主要针对软件工程中的质量管理来进行讨论。
　　做软件“大餐”的工序
　　软件质量保证（ ，以下简称）的目的是验证在软件开发过程中是否遵循了合适的过程和标准。软件质量保证过程一般包含以下几项活动：
　　首先是建立组；其次是选择和确定活动，即选择组所要进行的质量保证活动，这些活动将作为计划的输入；然后是制定和维护计划，这个计划明确了活动与整个软件开发生命周期中各个阶段的关系；还有执行计划、对相关人员进行培训、选择与整个软件工程环境相适应的质量保证工具；最后是不断完善质量保证过程活动中存在的不足，改进项目的质量保证过程。
　　独立的组是衡量软件开发活动优劣与否的尺度之一。组的这一独立性，使其享有一项关键权利——“越级上报”。当组发现产品质量出现危机时，它有权向项目组的上级机构直接报告这一危机。这无疑对项目组起到相当的“威慑”作用，也可以看成是促使项目组重视软件开发质量的一种激励。这一形式使许多问题在组内得以解决，提高了软件开发的质量和效率。
　　选择和确定活动这一过程的目的是策划在整个项目开发过程中所需要进行的质量保证活动。质量保证活动应与整个项目的开发计划和配置管理计划相一致。一般把该活动分为以下五类：
　　1）评审软件产品、工具与设施
　　软件产品常被称为“无形”的产品。评审时难度更大。在此要注意的一点是：在评审时不能只对最终的软件代码进行评审，还要对软件开发计划、标准、过程、软件需求、软件设计、数据库、手册以及测试信息等进行评审。评估软件工具主要是为了保证项目组采用合适的技术和工具。评估项目设施的目的是保证项目组有充足设备和资源进行软件开发工作。这也为规划今后软件项目的设备购置、资源扩充、资源共享等提供依据。
　　2）活动审查的软件开发过程
    　活动审查的软件开发过程主要有：软件产品的评审过程、项目的计划和跟踪过程、软件需求分析过程、软件设计过程、软件实现和单元测试过程、集成和系统测试过程、项目交付过程、子承包商控制过程、配置管理过程。特别要强调的是，为保证软件质量，应赋予阻止交付某些不符合项目需求和标准产品的权利。
如何做好软件工程质量管理？[2]
3）参与技术和管理评审
　　参与技术和管理评审的目的是为了保证此类评审满足项目要求，便于监督问题的解决。
　　4）做报告
　　活动的一个重要内容就是报告对软件产品或软件过程评估的结果，并提出改进建议。应将其评估的结果文档化。
　　5）做度量
　　度量是记录花费在活动上时间、人力等数据。通过大量数据的积累、分析，可以使企业领导对质量管理的重要性有定量的认识，利于质量管理活动的进一步开展。
　　需要说明的是，并不是每个项目的质量保证过程都必须包含上述这些活动或仅限于这些活动，要根据项目的具体情况来定。
　　计划中必须明确定义在软件开发的各个阶段是如何进行质量保证活动的。它通常包含以下内容：质量目标；定义每个开发阶段的开始和结束边界；详细策划要进行的质量保证活动；明确质量活动的职责；组的职责和权限；组的资源需求，包括人员、工具和设施；定义由组执行的评估；定义由组负责组织的评审；组进行评审和检查时所参见的项目标准和过程；需由组产生的文档。
　　选择合适的工具并不是试图通过选择工具来保证软件产品的质量，而是用以支持的活动。选定工具时，首先需要明确质量保证目标。根据目标制定选择工具的需求并文档化，包括对平台、操作系统以及工具与软件工程平台接口的要求等。
　　如何使白壁“无瑕”
　　按工序去做也不一定能得到一盘完美的“大餐”，因为火侯等因素实在很难掌握。万一掌握不好怎么办？软件质量控制主要就是发现和消除软件产品的缺陷。对于高质量的软件来讲，最终产品应该尽可能达到零缺陷。而软件开发是一个以人为中心的活动，所以出现缺陷是不可避免的。因此，要想交付一个高质量的软件，消除缺陷的活动就变得很重要。缺陷消除是通过“评审”和“测试”这类质量控制活动来实现的。
　　缺陷在软件开发的任何阶段都可能会被引入。项目质量管理过程包含了许多可以识别缺陷、消除缺陷的过程。“识别缺陷”和“消除缺陷”本来是两个不同的过程，但在这里为了简便统一用“消除”来代表它们。潜在的缺陷越大，用来消除它所花的费用越高。因此成熟的软件开发过程在每一个可能会引入潜在缺陷的阶段完成之后都会开展质量控制活动。这些为了消除缺陷的活动包括：需求评审、设计评审、代码走查、单元测试、集成测试、系统测试以及验收测试等。
    质量控制的任务就是策划可行的质量管理活动，然后正确地执行和控制这些活动以保证绝大多数的缺陷可以在开发过程中被发现。
如何做好软件工程质量管理？[3]
正如前面提到的，在进行评审和测试时可检测到缺陷。评审是面向人的过程，测试是运行软件（或部分软件）以便发现缺陷。在一个项目里，评审和测试活动是预先策划好的（计划书中确定执行哪些质量控制活动和何时执行这些活动）。在执行过程中，根据已定义好的过程来执行这些活动。通过执行这些活动来识别缺陷，然后消除这些缺陷。例如，系统测试过程一般包括制定测试计划，测试计划中应列出在测试执行过程中所有的测试用例，评审测试计划，并且最终执行测试计划。

软件质量之路-软件质量框架[1]
软件质量的重要性是不言而喻的，但是当所有人都意识到它的重要性的时候，却很少有人能够清晰的描述出如何才能够提高软件质量。软件质量框架的目的就在于提出一个评价的原型，帮助我们分析一种方法和技术是否能够提高软件质量。本系列文章分日构建、测试驱动开发、建立核心框架、面向组件的大规模软件架构来进行深入分析。
    什么才是一个高质量的软件
    在讨论软件质量原型之前，我们先回答第一个问题。一个软件之所以被认定为质量优秀，并不是因为它获得了一个省级或部级奖，而是它的内在具备了这样一些特性：
    满足用户的需求。这是最重要的一点，一个软件如果不能够满足用户的需要，设计的再好，采用的技术再先进，也没有任何的意义。所以这一点非常的朴实，但却是软件质量的第一个评判标准。
    合理进度、成本、功能关系。软件开发中所有的管理都是围绕着这几个要素在做文章的，如何在特定的时间内，以特定的成本，开发出特定功能的软件。三者之间存在一种微妙的平衡。在 一书中，专门有一个章节讨论它们。一个高质量的软件的开发过程中，项目成员一定能够客观的对待这三个因素，并通过有效的计划、管理、控制，使得三者之间达成一种平衡，保证产出的最大化。
    具备扩展性和灵活性，能够适应一定程度的需求变化。当今的社会已经变成一种变化速度极快的设计了。变化就会对软件产生冲击，所以一个质量优秀的软件，应该能够在一定程度上适应这种变化，并保持软件的稳定。
    能够有效的处理例外的情况。写过软件的人都知道，实现主体功能的工作量其实不大，真正的工作量都在处理各种例外。所以，一个软件如果能够足够的强壮、足够的鲁棒，能够承受各种的非法情况的冲击，这个软件就是高质量的。
    保持成本和性能的平衡。性能往往来源于客户的非功能需求，是软件质量的一个重要的评价因素。但是性能问题在任何地方都存在，所以需要客观的看待它。例如，一段性能不错的代码可能可读性很差，这就需要进行平衡，如果这段代码的性能是整个软件的关键，那么取高性能而舍弃可读性，反之则取可读性而舍弃高性能。一个优秀的软件能够保持成本和性能之间的平衡。
    能够可持续的发展。很少有软件组织只开发一个软件的，所以，一个优秀的软件在开发完成后，可以形成知识沉淀，为软件组织的长期发展贡献力量。这是一个优秀的软件应该要能够做到的。
    软件质量框架的组成
    软件质量框架不是理论，而是优秀软件开发思想的一个应用，是对软件开发过程的有效管理实践。它以敏捷方法论为基础，并将先进的软件开发技术融入其中。您可能在之前听说过，学习过，尝试过各种软件技术，但是缺少一个统一整体的认识。所以，软件质量框架的目的是将您原先在脑海中就存在的思路进一步的整理，将一副完整的图像（ ）展现在你面前。软件质量框架偏重应用，所以不会涉及太多的理论，但是，它是基于理论的，所以，在需要理论支持的地方，我们会简单的描述理论，并给出必要的链接，供有兴趣的读者进一步阅读。
    软件质量框架并不复杂，它由几个部分组成，第一部分是前提，说明了软件框架的适用范围，以及适合的环境，和方法学一样，没有泛之四海皆准的方法学，所以软件质量框架也需要一个上下文环境。第二部分是价值观，价值观说明了软件质量框架中强调的价值，在软件框架的结构和实践中，都将充分的的表现出一开始我们定义的价值。第三部分是结构。结构定义了软件质量框架的组成部分，以及软件质量框架和开发过程之间的关系。第四部分是文章中着墨最多的部分，即优秀实践。优秀实践通过具体、实际的分析、举例，深入阐述了软件质量框架的价值观和结构。
    在本文剩下的篇幅中，将会对前三个部分进行阐述，并对软件质量开发的实践进行简单的描述。在剩余的篇章中，将会针对这些实践进行细致的分析。
    软件质量框架的前提
    平台前提：由于软件质量框架的实践将会涉及具体的技术和代码，所以我们首先为软件质量框架定义了平台。软件质量框架将会运行在2平台上，使用对象分析技术（并不一定是面向对象技术，我们可以采用以数据为中心的技术）。
    组织前提：执行软件质量框架需要投入，需要付出，软件质量框架最难的地方不是学习，而是执行。在一个组织中，需要评估应用软件质量框架需要多少的投入，对目前的开发过程有多大的助益。一般来说，组织的规模越大、其开发过程和产品越复杂，就越适合采用软件质量框架。
    方法学前提：在敏捷方法学中，对规则和秩序有两种不同的观点，一种是强调规则和秩序，以为代表，它对代码都有要求；另一种则不那么强调，以自适应软件开发为代表，它不要求程序员的具体行为。软件质量框架采用第一种观点，要求组织中存在严谨的规则和秩序。
    软件质量框架的价值观
    明确具体：对软件的管理必须是明确具体的。软件开发是工程、也是艺术，需要紧密的协作和沟通，任何一个含糊的指令都可能导致软件开发中出现错误，所以，在软件开发中，任何一个指令都应该是相对明确的。为什么说是相对呢？是和成本相对，指令越明确，成本就越高。例如，你可以把需求文档写的非常的具体，但是你需要付出制作和维护的代价。所以我们的明确性是一个考虑成本前提下的特性。
    明确具体要从综合上考量。怎么理解呢？例如，中的用户故事是非常不精确的，按道理说它是不明确，也是不具体的。但是在整个开发周期中，将会有迭代、测试、现场用户等多种手段使得用户故事明确具体起来，所以从整体上看，它并不违反我们的价值观。产品质量是一个系统工程，决不仅仅是部门的工作，这个道理适用于制造业，也适用于软件开发业。
    容错：软件开发是人的工作，人是无法避免错误的。所以，软件质量框架中允许犯错。因为不犯错是天方夜谭。你就算做了这方面的强制规定也无法避免它的出现，反而会引发其它的问题，例如隐瞒错误，或为了隐瞒错误而导致的额外成本。所以正确的态度是允许发生错误，并建立一套监测、管理、反馈、修改错误的体制。
    规范：在前提中，我们已经提到了，规范是软件质量框架的基本态度。所以，软件质量框架中强调规范，并使用规范来推动框架的运作。
    测试：软件质量框架非常强调测试，测试是保证质量的必由之路。测试要尽可能的多，尽可能的频繁、测试结果要尽可能快的反馈。这是软件质量框架对测试的基本态度。测试是综合性的，软件开发过程中的所有工件，都需要伴随着相应的测试工件。这是基于一个简单的理念，如果你不能够为你的工作制定一个完成的标准，你又该如何开展你的工作呢？
软件质量之路-软件质量框架[2]
软件质量框架的结构

    上图表现了软件质量框架的结构。处于结构核心的是技术架构和管理架构。软件质量框架既不是方法学，也不是一个软件，更像是两者的结合体。技术架构和管理架构的融合体现了这一特性。软件质量框架并不关心单个开发人员的效率，它关注的是开发团队整体的效率。因此，管理架构在框架中的意义在于它定义了一套软件管理的方法，能够对开发人员及其他们的工作进行管理。从这一点来看，它的作用和软件工程方法学是一样的。但是，在现实中我们发现软件组织在迈向软件过程的途中往往因为现实的困难而止步不前。其中一个主要的原因是在引入方法学的过程中生产效率降低了，而引起组织成员对变革的怀疑和不满。
    所以，除了管理架构之外，软件质量框架还提供了一个技术架构，其目的是明确的定义如何应用组织中涉及的软件技术，以及管理软件技术的方法。技术架构是具体的代码，相比起方法学来说，它更加的具体，更容易为开发人员所理解。而技术架构存在的目的，一方面是进行技术积累，另一方面也是为管理架构服务。
    技术架构和管理架构的下一层是支撑框架。支撑框架包括代码、组件、文档，目的是为技术架构和管理架构提供底层的支持。
    处于结构最顶层的是业务架构。这个部分对于任何一个软件组织来说都是不同的，因为不同的软件组织的业务不同。业务架构的目的是对业务进行建模和抽象，提取出可重用的部分，以提高软件组织的生产率。本文中不涉及该部分的内容。
    软件质量框架的优秀实践
    一个开发团队要提高效率，就需要思考目前的管理活动中有哪些要素是可以改进的：如何把一些事务性的操作变得自动化，从而节约人力；如何找到更好的方法，让开发过程更为合理，更注重软件的质量；如何在团队中传播优秀的思想，让团队成员不断的学习和进取，自发的改进过程。这些美好的愿望几乎是所有方法论和各种认证的共同心声，但要完全做到可就太难了。在我们的文章中，提出了一些优秀的实践，优秀实践均是来源于软件开发界中的一些新思路和新理论，它们能够为以上愿望的达成起到正面的作用。在组织中引入用这些实践决不是一个容易的过程，但它们确实非常的有效。不论是在成本控制上，还是在质量的改进上。
    每日创建：一个组织应当拥有一个有效的工作流程，这个工作流程能够指导软件开发的进行。这个流程应当是具体的、可操作的。随意的计划和从来不遵循的进度决不是一个有效的工作流程。日创建实践提出了一种对开发过程进行精细管理的方法，它是量化软件管理的基础。有了日创建，你会发现计划的制定和进度的监控是非常容易的一件事情。
    测试驱动开发：软件质量的根源来源于测试，测试做好了，软件质量就会好。这是毫无疑问的。问题的关键在于怎么做测试，才能保证测试的投入能够带来软件质量的有效提升。测试驱动开发正是为了解决这个问题而出现的。它不是一个完整的方法论，可以和任何一种开发流程进行融合。测试驱动开发不但能够改善测试效果，还能够改进软件的设计。
    建立核心框架：框架是一种具有高度重用性的软件，这个特性决定了它非常适合成为软件组织积累知识的一种有效手段。传统的知识积累的方法是文档，但是文档容易产生歧异，开发人员往往也不愿意去阅读和理解文档。框架提供的是一种综合的手段，包括文档、模型和代码。更容易理解，更重要的是，开发人员必须在日常的工作中使用框架，这使得他们对框架中的知识非常的熟悉，并根据工作的需要来改进框架。
    面向组件编程：有效的组织在于有效的分工。体力活动容易进行分工，脑力劳动则比较难，而软件开发似乎就更难了。所以，长久以来我们都习惯采用以功能块为单位的粗粒度划分方式。面向组件编程采用更加细密的划分方式，并以服务作为组件之间相互依赖的契约，不但定义了组件和组件之间的关系，也规定了组件开发者、组件使用者、组件测试者的权利和义务。从而能够进行软件开发工作的分配、管理、等工作。
    以上的几个优秀实践看起来似乎并没有多大的关系，他们的提出者也大都不同。但是有一点却是共同的，就是他们都能够对软件质量的改进起积极的作用。此外，他们为软件质量框架结构的实现提供了一个明确的实现方式。从软件结构的角度来看，日创建和测试驱动开发似乎偏向于管理架构，而建立核心框架和面向组件编程则偏向于技术架构。事实上，他们既包含了技术架构，也包含管理架构，彼此之间也有相互关联。例如，面向组件编程在合理划分组件之后，就需要一个有效的核心框架来集成组件，通过每个组件都需要采用测试驱动开发方法来保证质量，同时，日创建将会以组件为单位来进行每日的创建，从而为进度估算提供有效数据。
    随着软件设计技术的发展，新的实践将会出现，取代旧的实践。因此，以上的实践也会落伍，当可以肯定的是，以上的实践和具体的技术并没有直接的关系，更侧重于开发思想，因此他们的生命力会很长。而随着新技术的出现，他们更可能将新的技术融合如自身，呈现出一种崭新的形态。例如，未来的一种可能性是2.0和技术的普及，以上的几个实践从以代码为核心转变为以设计为核心，而另一种可能性是随着以为代表的技术的普及和J21.5中引入的元数据机制，面向组件编程将把作为组件的一种，而测试驱动开发也会加入测试的相关内容，在日创建中也会增加相应的处理的步骤。
软件项目管理：质量先行[1]
软件开发为何不能像硬件开发那样可控？软件质量之旅将带给我们一些启示。 
　　提到软件产品开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦地工作，加班加点，甚至通宵达旦。虽然项目经理一次又一次地修改了进度计划，而实际的开发情况却总是令人担忧，以至于每次向领导汇报工作的时候，总是觉得以前制定的计划没有很好完成，总是觉得人力资源不够，总是觉得没有太多的时间。等到代码终于开发完成了，测试进度同样非常令人担忧，每一个小都要花很长的时间去查找，改了某一个小错误却又引起了很多新的错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。 
　　怎样摆脱这样的困境？为何软件开发项目管理这么困难？为何我们做的计划总是不能按时完成？为何软件开发不能像硬件开发那样可以控制？ 
　　软件开发是完全依靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定、可变化的因素。那么我们怎样把握住这些变化因素呢？ 
　　软件项目管理——质量先行，如果我们能够控制软件生命周期每一个阶段的质量，就能很好地控制了软件开发的整个过程。 
　　软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，是将大脑里无形的思维变成可以解决实际问题的一组界面或者组件。在这样一个复杂的过程中，应该如何保证质量呢？有人想到了9000、，也有人提出反对意见，认为应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的本质。 
　　有人说，和到中国来怎么就变了味了？其实，我们只学到了怎样去做，但是不知道为什么要这样做。大家都知道在产品立项之前要写市场分析报告，但不了解为什么要写，市场分析报告的重要性有多高？不是资深开发人员很难理解其重要性，如果是简单地去写一篇形式上的文档，那么，除了负担之外就没有其它用途了。 
　　有些人又想到了测试，觉得是我们测试的力度不够，所以产品质量不过关。 
　　其实，软件开发的质量保证从最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式模型还是迭代式模型，都离不开需求、设计、编码、测试这几个阶段。在迭代式开发中，这几个阶段也是周期性出现的。 
　　怎样把