软件开发质量管理规范

软件开发质量管理规范篇一：软件开发规范-质量保障规范资料质量保证过程 版本： 修订记录 目 录 1 导言 . 2 目的 .2 范围 .2 术语定义 .2 2 3 4 主要角色和职责 2 入口准则 . 2 过程描述 . 3 参与制订项目计划、标准和规程. 3 制定质量保证计划 . 3 审计过程和产品 .3 不符合项上报渠道 . 3 记录 QA活动 . 4 与客户 QA一起审计 .4 对项目组培训 .4 制定组织级 QA计划 .4 5 6 7 8 9 出口准则 . 4 输出 . 4 工具和方法 5 裁剪指南 . 5 相关文档 . 5 1 导言目的 定义软件质量保证过程，为 QA工作提供指导。 范围 本文适用于公司所有软件开发项目的质量保证活动，同时适用于 SEPG的过程改进活动和质量保证相关的培训活动。本文档的读者包括软件质量管理部、 软件项目组、 软件过程改进组、 软件培训部。 术语定义 QA：Quality Assurance 质量保证。 2 主要角色和职责 3 入口准则在项目合同审核通过或项目开工证明审核通过，事业本部开始启动售中立项流程。 4 过程描述参与制订项目计划、标准和规程 在项目计划阶段，QA 协助项目经理制定项目计划：主要提供关于项目估算、标准使用、过程裁剪、生命周期模型选择等方面的咨询和指导。 制定质量保证计划 QA 依据已确定的项目计划和质量保证计划模板制定项目的质量保证计划。项目的质量保证计划包括以下内容： 1） QA的职责、资源（包括人员、工具、设施等） 。 2） 作为 QA审计基础的项目标准和规程。 3） QA在项目中要进行的审计活动和进度安排。 4） QA发现的不符合项的处理过程。 在质量保证计划编写完成后，应提交计划进行评审，参加评审的人员包括：项目经理、质量经理、架构师、项目开发人员、测试人员和质量工程师。 审计过程和产品 QA 依据质量保证计划和 QA检查单，对过程和产品进行审计。过程审计方式主要包括与项目经理及项目组成员进行访谈，观察过程执行等。产品审计应在产品成为基线前进行，审计的方式主要包括参与产品的技术评审，对产品进行确认等。 QA 在审计过程中，对发现的不符合项要和项目经理进行确认，并将不符合项记录在不符合项报告或缺陷管理工具中。 QA 定期（最长周期：周）或不定期（有严重不符合项时） ，将不符合项报告或将缺陷管理工具中的不符合项导出，报告给项目组。协助项目经理制定纠正措施，督促纠正措施的执行，并跟踪验证直到不符合项关闭。 不符合项上报渠道 当项目组不能、不愿或者到不符合计划关闭日期后的三天内还没有将不符合项解决时， QA 要将不符合项进行上报（如，计划关闭日期是号，到问题还没有解决，在就可以将问题上报，三天时间可以不包括周末） ，逐级上报的渠道为： 篇二：软件开发各阶段的质量管理软件开发各阶段的质量管理 提到软件开发，我们的脑海里总是浮现出这样的情景：开发组的每一位成员都在辛苦的工作，有的加班加点，甚至通宵达旦是常有的事，虽然项目经理修改了一次又一次的进度计划，而实际的开发情况却总是很令人担忧，以至于每次向领导汇报工作的时候总是觉得以前制定的计划没有很好的完成，总是觉得人力资源不够，总是觉得我们没有太多的时间。等到代码终于开发完成了，测试进度却又非常令人担忧，每一个小 BUG都要花很长的时间去查找，改了某一个小错误却又引起了很多错误，结果产品发布遥遥无期，而项目组里的每一位成员已经筋疲力尽。 怎样摆脱这样的困境呢？为何软件开发项目管理这么困难呢？为何我们做的计划总是不能按时完成呢？为何软件开发不能像硬件开发那样可以控制呢？原因在于软件开发完全靠人的大脑思维产生出产品，而每个人的大脑思维是不一样的，因此在软件开发过程中有太多不确定的、可以变化的因素，我们怎样把握住这些变化因素呢？就像我们题目所说的一样，软件开各阶段的成果质量管理，如果我们能够很好的控制软件生命周期每一个阶段的质量，也就很好的控制了整个软件开发的整个过程。 软件产品的质量是个很大的概念，因为软件产品完全是人们大脑思维的产物，就是将大脑里无形的看不见摸不着的思维变成一个可以看到的，可以解决实际问题的一组界面或者组件。这样的一个复杂的过程，质量应该如何保证呢？有人想到了 ISO9000、CMM，也有人很反对，说应该用敏捷开发。其实，不管用什么样的开发过程，关键是找到这些过程的真谛，有些人说，ISO 和 CMM到中国来就变了味了，为什么变味儿了呢？其实我们只学到了该做什么，却不知道怎样去做，为什么要这样做？大家都知道做软件开发需要写需求规格说明书和设计文档，为什么要写，文档的重要性有多高？没有资深开发和管理经验的人员可能很难理解其重要性，如果只是简单的形式上去写一篇这样的文档，对后面的编码和测试没有实际的指导作用，甚至起了“ 误导”作用，同样会引起大量返工，那么这些文档除了负担之外就没有其他用途了，要知道写这些文档是需要消耗项目组资源的（进度、成本.） 。 很多人又想到了测试，觉得是我们测试的力度不够，所以我们产品质量不过关，其实，软件开发的质量保证从开发最初就应该开始了，如果到了测试阶段才重视就已经晚了。软件产品开发过程，不管采用瀑布式还是迭代式，都离不开需求、设计、编码、测试这几个阶段，在迭代式开发中，这几个阶段也是周期性出现的。怎样把握好每个阶段的质量，确实不是一件容易的事，本期重点介绍一下需求、设计和编码阶段的成果质量，当然以后会共享一些过程质量方面的知识。 1、需求 我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。如果对 UML比较熟悉的话，需求分析可以利用 UML工具进行，这样可以减少一些自然语言引起的歧义，但是 UML可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解 UML各种图形的意思。除了工具之外，我们可以从以下几个方面来保证需求描述的质量。 1)、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。2)、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。 3)、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。 4)、另外注意引用的术语和词汇是否前后一致。 5)、是否存在一些形容词、比较性词语，比如：容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。 另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。那么我们怎样才能判断需求细化的程度呢？需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢？哪些需求又太粗了呢？答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。 2、设计 软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：用户、项目管理人员、程序员、测试员、维护人员等等。不同的角色对架构设计的要求也不相同。例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少？对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。对于维护人员来讲系统的扩展性、可维护性如何？一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。正是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。一般用来衡量软件设计质量的标准可以从以下几个方面来考虑： 1)、功能性：包括完全性、正确性、安全性、兼容性、互用性。完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。正确性包括需求一致度。安全性根据软件需求的不同有不同的安全性要求。 2)、效率：包括产品运行的时间效率和利用的硬件资源两方面来考虑。 3)、维护性：包括架构的可改正性，可扩充性以及可测试性。如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。 4)、可移植性：包括硬件的独立性、软件独立性、可安装性、可重用性。软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。 5)、可靠性：包括缺陷数量、容错性、可用性。 6)、使用性：包括可理解性、易学习性、可操作性、易沟通性。我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。因此在软件的可使用性也是非常重要的。3、编码 代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的 public方法太多也会导致类之间的高耦合性增加。 也许有的程序员会认为写出可读、规范的代码会影响工作进度。的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。况且如果随着人员的调动等其他原因，往往维护代码的程序员已不是当初写代码的人，很多情况就是读懂了一段糟糕的代码还比重新写出一段代码花费的时间还长，严重影响工作效率(有些时候还影响维护人员的心情)，反过来，如果大家都讲究把代码写成规范可读的，无疑对于整个组织来说提高总体工作效率是非常有用的。 代码质量另一个非常重要的衡量手段就是测试，通过统计测试代码所产生的缺陷情况，如严重等级分布、缺陷曲线的变化等可以从一个方面来简单地评估代码质量。 篇三：软件项目中的质量管理软件项目中的软件质量管理 摘 要软件项目的质量管理指的是保证项目满足其目标要求所需要的过程，它包括编制质量计划、质量控制、质量保证等过程。软件的质量是软件开发各个阶段质量的综合反映，每个环节都可能带来产品的质量问题，因此软件的质量管理贯穿了整个软件开发周期。软件项目的质量管理，不仅确保项目最终交付的产品满足质量要求，而且要保证项目实施过程中阶段性成果的质量，也就是保证软件需求说明、设计和代码的质量，包括各种项目文档的质量。 关键词质量管理，质量计划，质量控制，质量保证 Software quality in software project management AbstractQuality management in software project refers to the process to ensure the project meets its objectives and requirements , which includes the preparation of quality planning, quality control, quality assurance and other processes. Software quality at all stages of software development is a comprehensive reflection of the quality of each link may bring product quality problems, the quality of software management throughout the entire software development cycle. Quality management of software projects, not only to ensure the projects final delivery of products to meet the quality requirements, but also to ensure the quality of the process of the initial results of the implementation of the project is to ensure that the software requirements specification, design, and quality of the code, including the quality of project documentation. Keywords Quality management, quality planning, quality control, quality assurance 照；因而软件项目极易出现失败或失 1 前言 误。大量实践证明，软件工程项目的 随着越来越现代化的发展，提起成败，通常是因为管理问题（协同工如今的 IT项目，软件工程倍受人们关作的能力） ，而不是技术上的问题。注。而软件的质量更是众人关注的焦要想做一盘“完美”的软件大餐，质点，因为目前还没有一套完善的评估量管理的作用是不言而喻的。 标准。甚至有人提出，现在的软件开 发根本提不上是“工程”，因为它太 2 项目中质量管理的原则 稚嫩了，还没有一套成熟的标准来比 在软件项目实施中，由于进度和成本两大因素的影响，它的质量管理与产品开发有着很大的差别。因此，在项目实施中做好质量管理工作应该坚持自己的原则。想法落实到行动中 软件质量管理的重要性已经逐渐被国内的 IT企业认可，但是要落实到具体的项目实施工作中，并通过它提高软件质量，还有一段很长的路要走。因为几乎所有的软件公司都灌输着“进度高于一切”的思想，只要是为了赶进度和发布产品，所有影响进度的工作都可以忽略。因此，把想法落实到实际工作中是做好软件质量管理的第一原则。提高质量，尊重客户 可以说，目前很多公司都有“愚弄客户”的嫌疑，不管是有心的还是无意的。很多公司实施项目时只要能拿到“钱”就达到目的了，因此也就不在乎是否掩盖缺陷和敷衍客户。至于后果，那是以后的事情了。 在软件产业发达的今天，已经是客户的买方市场，客户永远会选择质量和服务都表现良好的产品来满足自己的需求。因此，我们应该尊重客户，把客户放在“上帝”的位置上，认证做好质量。 建立规范的质量保证体系 在没有开发规范的前提下，软件团队是不能开发出高质量软件的。因此软件团队一定要建立规范的质量保证体系，同时把规范体系逐步落实到工作中。如果急功近利，不但会做很多浪费人力和物力的无效工作，还会给客户留下不好的印象。 项目实施中的技术评审 很多软件项目由于性能等诸多原因最后导致失败，实际上都是由于设计阶段技术评审做的不够。一味地节省时间、关键工作仅由某几个人执行、整个项目的成败依赖于某些“个人英雄”等做法是十分错误的，重要的技术评审工作是不可以忽略的。 技术评审可以把一些软件缺陷消灭在代码开发之前，尤其是一些架构方面的缺陷。在项目实施中，为了节省时间应该优先对一些重要环节进行技术评审，这些环节主要有：项目计划、软件架构设计、数据库逻辑设计、系统概要设计等。如果时间和资源允许，可以考虑适当增加评审内容。 项目实施中的过程检查 项目经常延期是中国软件企业实施很多项目时候的特点，因此项目实施中的过程检查重点是“进度检查” 。在实际工作中，很多项目都是启动一段时间后就开始不停地加班，使整个团队处于疲惫状态，导致工作效率低下，最后把项目计划丢在一边。对于这种情况，比较好的做法是不断地检查项目计划与实际进度是否存在偏差，如果存在偏差则找出问题的根源，然后消除引起问题的因素，例如可以调整进度安排或者增加人力投入，这样就避免了问题不断放大。 版本检查在项目实施中也需要特别注意，因为版本混乱会带来很大麻烦，尤其进行测试的时候。此外，项目实施时候也应该注意文档检查，尤其是一些关键文档的质量，例如接口文档、用户手册等。 项目实施中的软件测试 项目实施相关的全部质量管理工作中，软件测试的工作量最大。由于很多项目在实施中非常不规范，因此软件测试一定要把好关。软件测试应该重点做好测试用例设计、功能测试、性能测试、缺陷管理等工作。 测试用例设计：虽然项目实施中没有太多时间来设计测试用例，但是这个环节是必不可少的。项目实施中设计测试用例应该根据进度安排，优先设计核心应用模块或核心业务相关的测试用例。设计测试用例的时候可以不设计的特别完善，基本目标是列出测试重点，对测试执行起良好地指导作用，这个时候的测试用例更像是“测试大纲” 。功能测试：软件首先应该从功能上满足用户需求，因此功能测试是质量管理工作中的重中之重。功能测试在产品试运行前一定要开展好，否则将会发生“让用户来执行测试”的情况，后果非常严重。 性能测试：性能测试是经常容易被忽略的测试。在实施项目过程中，应该充分考虑软件地性能，运行较慢的软件仍然不会为用户所接受。性能测试可以根据用户对软件的性能需求来开展，通常系统软件和银行、电信等特殊行业应用软件对性能要求较高，应该尽早进行，这样更易于早解决问题。 缺陷管理：缺陷跟踪与管理工作也经常被忽略，很多问题会被遗忘，直到客户再次发现。建议测试人员在项目实施中仍然采用一些工具进行缺陷管理与跟踪，保证任何缺陷都得到妥善的处理。 此外，对于一些项目，如果实在没有测试人员，可以考虑让开发人员互相进行测试，这样也可以发现很多缺陷。项目实施中的质量管理工作是非常复杂的，存在很多不可以控制的因素，例如没有质量人员、测试环境不具备等。因此，项目实施中的质量管理原则应该是“最大限度地去提高质量” 。只有这样，才能更好地利用现有资源尽可能地提高质量。 3 软件项目质量管理主要 存在的问题 缺乏软件质量意识 缺乏软件质量意识，信息化建设中软件质量问题未被完全重视。无形的软件产品较有形产品隐蔽，软件质量的检查要求一定的知识基础，对软件进行全面的检测、评估需要系统的方法和相关的标准以及评价体系，这样造成了软件质量意识的淡化。同时，在项目交付后，软件质量缺乏科学的量化指标。 追求项目进度 追求项目进度，从而忽视了软件质量和软件过程控制。较之国外长期的信息化的实施过程，我国信息化起步晚，底子薄，信息化过程积累的经验相对较少，尚未形成规范的标准和对应的体系，项目实施中不能形成有效的开发组织计划，文档控制和管理不规范，阶段性测试不深入等质量控制问题大量存在。 软件技术处于发展过程 软件技术处于发展过程，质量管理体系滞后。在开发过程中，对软件的发展高于软件质量的要求。软件开发是高智力的创造性活动，更强调过程的创新和合作。 缺乏有效质量控制体系 信息化过程的流动模式是：需求、调研、选型、招标、开发、测试、上线、维护。该模式的一个环节的质量问题是通过软件生产企业对产品的负责而受到一定的控制，但是大多数质量控制活动仅限软件测试，未对信息化过程的各个阶段质量进行控制。 4.软件项目质量管理方法论 项目质量管理的主要方法包括： 确定管理计划、定义合适的软件、确定软件需求、迭代开发、代码走样、软件评审、软件测试几个方面【2】 。确定软件管理计划 计算机软件是计算机得以运行的重要保证，它是计算机顺利运行的基础。在进行软件开发前。需要有一个软件质量保证计划，用于规划运行计算机软件的运行，设施的调适，并对可能出现的事情进行事先预防。软件质量管理的内容一般包括：计划实行目的；软件质量管理的相关理论分析和参考文献作保障；在软件质量管理时，组织的领导，以及组织实施任务的责任；软件质量管理的执行标准和约定，用以规范软件执行；计算机软件执行过程中，需要对软件进行详细的审计，以保证计算机软件的规范性；对于计算机软件的实施，要进行软件验证和确认评审，以确认软件能够有效的起效益，特别是对软件的各项功能进行调适，以确认其适应性；要正确运用各项工具、技术和方法，来规范计算机软件操作控制；要记录、收集计算机软件维护时的数据，收集第一手资料，为日后的做准备；要加强员工的风险管理培训意识，提高操作的可行性，保障计算机软件能够持续有效的运行，提高组织效率 。 定义合适的软件过程 软件过程是一个为建造高质量软件所需完成的任务的框架，即形成软件产品的一系列步骤，包括中间产品、资源、角色及过程中采取的方法、工具等范畴。在以计算机网络为基础的现代社会信息化背景下过程管理作为现代企业管理的先进思想和有效工具，随着外部环境与组织模式的变化而变化。因此作为一个好的软件项目过程，必须针对企业和项目的实际情况，确定软件项目运作流程，定义软件功能及相关性能明确各阶段的进入 条件和退出条件进行有效的过程控制与管理，在提高软件开发的效率和项目的成功率的基础上进一步保证所开发软件 的质量。 确定软件需求 对于任何软件项目而言，需求是 一个重要的环节，也是软件开发的基础。需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。往往用户需求明确变更少的项目的成功率就高，因此，需求分析的成败直接决定后期软件产品的成败。但是，在现实软件开发过程中，用户的需求总会由于各种不同的原因而不断发生变化。这就给软件项目过程实施带来不确定因素，导致项目组在开发阶段不停的返工，进而造成代码质量低下，测试拖期等一系列问题。因此在项目实施过程中，为了保证软件开发的顺利进行和最后交付的产品质量，应该对项目需求变更进行管理。 （1）需求应尽量明确。在项目开发过程中要尽早明确用户需求，有些内容一时无法确定则应该暂缓该部分的开发，尽量降低因需求变更而带来的风险。 （2）对需求变更进行管理。当需求分析完成后项目就进入开发阶段，用户可能会因为市场或策略的变化而提出需求变更的要求。此时，若是合理变更则有利于项目实施，但有时所作的变更可能会影响项目整体的设计和开发，造成项目进度的延期。对于这一情况，项目组应该积极与用户沟通，制订需求变更说明书，在双方都认可的情况下方可实施。 迭代开发 通过转向迭代开发，改变客户和开 发团队之间的交互模式，客户和开发团队都可以避免产生大量的分歧。在一个迭代开发的项目中，客户应该是构建应用团队中的不可缺少的一部 分。客户与开发团队的其他成员协同工作以确保最终交付的应用系统满足被需要的业务价值。客户的组织应该尽可能的保持与开发团队之间交互的兴趣，以确保开发团队可以理解他们应该构建什么和项目中具有什么样的风险和问题。代码走样 代码走查是一个开发人员与架构 师集中与讨论