软件质量保证配置管理计划评审检查表
审查表(完整)
b)针对产品确定过程、文件和资源的需求；
c)产品所要求的验证、确认、监视、测量、检验和试验活动，以及产品接收准则；
d)为实现过程及其产品满足要求提供证据所需的记录（见4.2.4）。
策划的输出形式应适合于组织的运作方式。
注1：对应用于特定产品、项目或合同的质量管理体系的过程（包括产品实现过程）和资源做出规定的文件可称之为质量计划。
4.检查质量手册对标准应用的说明、引用和含有标准、程序文件，支持性文件清单。
5.检查质量手册对使用的文件结构的描述。
6.检查质量手册对过程及其相互作用的描述。
4.2.3文件控制
质量管理体系所要求的文件应予以控制。记录是一种特殊类型的文件，应依据4.2.4的要求进行控制。
应编制形成文件的程序，以规定以下方面所需的控制：
a)确保质量管理体系所需的过程得到建立、实施和保持；
b)向最高管理者报告质量管理体系的业绩和任何改进的需求；
c)确保在整个组织内提高满足顾客和法规要求的意识。
注：管理者代表的职责可包括就质量管理体系有关事宜与外部方进行联络。
1.检查管理者代表任命。询问管理者代表如何开展自己的工作。
2.询问管代如何建立并保持质量管理体系、如何评价质量管理体系的有效性、业绩。
4.2.2质量手册
组织应编制和保持质量手册，质量手册包括：
a)质量管理体系的范围，包括任何删减的细节和正当的理由（见1.2）；
b)为质量管理体系编制的形成文件的程序或对其引用；
c)质量管理体系过程之间的相互作用的表述。
1.检查质量手册的裁减描述。
2.检查质量手册覆盖的产品范围。
3.检查质量手册描述的体系覆盖范围是否能覆盖标准的所有要求。
软件质量保证过程(SQA)
软件质量包管过程之杨若古兰创作软件质量包管过程作为一种独产的审查活动贯穿于全部软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其次要职责是:检查开发和管理活动是否与拟定的过程计谋、尺度和流程分歧；检查工作产品是否遵守模板规定的内容和格式.此文档从软件开发过程的各个阶段来描述软件质量包管过程.1.计划阶段目的和范围：项目计划过程的目的是计划并履行一系列须要的活动，以便在不超出项目预算和日程安插的前提下，将优良的产品交付给客户.项目计划过程适用于公司的所有项目，但每个项目可以根据各自的分歧情况对该过程进行裁剪.进入尺度：⏹项目启动会议曾经结束；⏹在项目的生命周期中，根据项目的跟踪结果，须要对项目计划进行点窜和完美.输入：⏹项目启动陈述；⏹项目提案书；⏹项目相干文档；⏹组织财富库中以往类似的经验文档.退出尺度：项目计划已通过评审、批准并确立.输出：评审后的项目计划文档包含：⏹软件开发质量计划；⏹软件配置管理计划.过程描述：项目计划包含3个须要在项目中履行和管理的次要计划，如下：⏹软件项目管理计划；⏹软件项目质量管理计划；⏹软件配置管理计划.软件项目管理计划涉及项目中所有与项目管理相干的成绩（从项目开始到结束）.软件项目质量管理计划涉及与质量相干的需求，这些须要在产品中实现，并包管用于构筑产品的项目过程.因为质量是产品创建的一部分，所以将软件项目管理计划和软件项目质量管理计划合成一个计划文档，称为软件开发质量计划.软件配置管理计划用于管理与配置管理相干的需求，这些需求与工作产品和可交付产品有关.该计划的目的在于：为履行软件工程相干活动提供根据，并在全部开发和保护过程中对软件项目进行管理.可以使用分歧的检查表来拟定软件开发质量计划和软件配置管理计划.如下每个计划都将包含以下3点：⏹目标；⏹履行方法；⏹当前形态.前两点不会经常变动，但第三点则被认为会在履行跟踪时被点窜.是以，前两点通常被直接放到计划中，而第三点则以链接的方法放到计划中.（1）拟定软件开发质量计划软件开发质量计划包含软件项目管理计划、软件项目质量管理计划.①拟定软件项目管理计划软件项目管理计划的次要内容包含基础设施计划，进度计划（包含各品种型的估算）、风险管理计划、项目培训计划、履行计划、客户管理计划.⏹基础设施计划基础设施计划包含项目开始履行前必须到位的所有需求，它须要解决以下成绩：软件工程需求、基础设施需求、角色和职责、内内部接口、过程需求、常识和技能需求.⏹进度计划进度计划涉及拟定合理可用的项目进度.在拟定项目进度时，须要进行上面的估算：规模（Size）、工作量（effort）.项目进度须要描述以下内容：履行的活动、估算的人时、投入的人员、义务人和时间线、里程碑事件的标识.⏹风险管理计划风险管理包含：标识风险事件（与管理相干的风险、与履行相干的风险，与客户相干的风险等）、评估风险并设定风险优先级、拟定风险缓解和应急计划并跟踪该计划.⏹项目培训计划根据项目及人员结构拟定项目培训计划，包含营业领域常识、技术、工具等方面的培训计划.⏹履行计划项目履行计划包含了与履行当前项目关系最大的生命周期模型.该计划对组织级履行模型进行了裁剪.项目生命周期模型通常包含：项目履行的阶段、各阶段的输入和输出、可交付的产品、须要迭代（反复）的阶段.②拟定软件项目质量管理计划拟定软件项目质量管理计划包含如下次要内容：⏹项目设定的质量尺度；⏹同级评审计划：同级评审计划中描述了在分歧的软件生命周期开发阶段，对分歧的工作产品所采取的同级评审类型；⏹测试计划：测试计划包含对可履行文件/模块或全部零碎将要进行的各种测试.根据项目测试过程来拟定测试计划；⏹度量管理计划：通过裁剪组织级的度量过程来拟定项目度量管理计划.⏹缺陷预防计划：管理、开发和测试人员互相配合拟定缺陷预防计划，防止已识此外缺陷再次发生；⏹过程改进计划：项目级过程改进的机会要记录到过程改进计划中.这些机会次要来源于度量分析、缺陷预防分析和标识出的好的或可防止的实践.（2）拟定软件配置管理计划软件配置管理计划次要包含以下内容：⏹软件配置管理计划组织；⏹角色和职责；⏹开发/保护配置管理计划，包含可配置项的标识、命名商定、目录结构、访问控制、变动管理、基线库创建、放入/提取（Check in/Check out）机制、版本控制；⏹产品配置管理，包含产品中部件的可跟踪性，产品的版本设定和发布、交付的配置管理（标识出要交付的产品构成）、需求配置管理（需求基线的确定、产品版本与划定基线的需求版本之间的关系）、配置审计.验证：同级评审人员和软件质量包管人员必须对项目计划进行评审，批准后项目才干付诸实施.配置控制：项目经理保管所有项目计划文档.对所有项目计划文档都要进行配置管理.项目结束后，所有的项目计划文档都要保管到组织财富库中，仍受配置控制.QA检查清单：QA检查清单包含：⏹软件开发质量计划；⏹软件配置管理计划.该阶段要确保拟定了软件开发质量计划和软件配置管理计划.2.需求分析阶段目的和范围：需求说明和需求管理过程的目的是为了包管开发组在开发期间对项目目标和生产出最初产品的目的有一个清晰的理解.软件需求规格说明书将作为产品测试和验证是否适合须要的基础.对于需求的变动，它可能在开发项目期间的任何时间点发生，需求的变动将要影响日程和承诺的变更，这些变更须要和客户所提出的请求相分歧.进入尺度：⏹计划曾经被批准，而且项目全体的基础设施是可用的；⏹软件的需求曾经被需求收集小组捕获；⏹对曾经构成了基线的软件需求规格说明书有变动的请求时.输入：⏹软件的需求说明书；⏹变动需求的请求.退出尺度：⏹软件需求规格说明书曾经经过评审并构成了基线；⏹对曾经构成基线的软件需求的变动进行了处理；⏹构成基线的软件说明书曾经经过客户批准；⏹验收尺度曾经完成；⏹所有评审的成绩都曾经解决.输出：⏹经过批准并构成基线的软件需求规格说明书；⏹对受影响组件的从头估算文档；⏹验收测试尺度和测试计划.过程描述：这个过程次要处理以下两种活动：需求说明和需求管理.需求说明指的是需求过程中构成基线的主体，它是当前进一步的设计和测试的基础.另外，在软件开发过程中，会经常碰到因为客户又有新需求或开发组本身对项目有了更清楚的理解或认识，要对需求进行变动.在对最初的需求说明书进行变动时，要用到需求管理过程.（1）需求说明需求说明过程次要包含以下任务：⏹履行需求分析⏹定义需求规格说明书⏹定义验收尺度⏹评审说明书和验收尺度.①履行需求分析分析收集到的需求和在提案中可用的需求.这个任务请求需求说明书应当在完好性、分歧性、清晰性和可测试性上达到比较合理的程序.②定义需求说明书基于对需求的分析编写软件需求规格说明书.这个文档应清晰记录以下内容：⏹目标和范围；⏹功能需求；⏹用户接口；⏹输入输出；⏹模块之间的接口；⏹功能需求；⏹特殊用户需求.如果需求不清晰或模糊，就须要筹办原型，通过评估原型来发生需求说明书.③定义验收尺度基于对之前步调收集的需求规格说明书，建立测试尺度，验证的解决方案.所有的需求应当可能拟定测试尺度.这个测试尺度将成为客户批准终极产品的根据，是以请求在拟定客户尺度时要经常紧密的与客户进行交流沟通.④评审需求分析说明书和测试尺度因为是开发项目的基础，所以需求规格说明书和验收尺度须要由项目组的同级人员进行评审.（2）需求管理需求管理过程包含以下6个任务：⏹记录变动请求；⏹分析受到影响的组件；⏹估算需求变动成本；⏹从头估算所有产品的交付日期和时间；⏹评审受影响组件；⏹获得客户的批准.①记录变动请求；构成基线的需求说明书的变动可能是由客户提出的，也可能是因为设计或编码阶段开发人员根据一些限制或优化而提出的.所有需求变动必须经过客户的批准，而且必须是可行的.任务需求变动可以由组织本人定义开始时间，而且所有需求变动须要记录到变动登记表中.②分析受到影响的组件；任何经过批准的变动须要在全部项目组范围内进行受影响组件分析.③估算需求变动成本；项目成本与需求变动有关.任何规模的变动对于成本来讲都是一种损耗.如果一个受影响组件是非常次要的，那么可行性须要从头进行成本估算.④从头估算所有产品的交付日期和时间；如果没有考虑无效的缓冲，成本的变更可能会影响全部项目的交付时间.在交付时间内的任何实质的变动都须要再同用户商经过议定定.⑤评审受影响组件；在这个步调中所有相干的受影响组件须要进行评审，项目负责人根履行此项任务.⑥获得客户的批准.这个过程的最初一项任务是获得客户的签字.客户应当同意曾经构成基线的软件需求说明书、验收尺度和已记录的受影响组件的变动.验证：项目经理要定期的检查需求规格说明书和项目需求管理的各个方面；⏹软件质量包管人员要定期的对需求分析过程履行独立的评估.配置控制：⏹软件需求规格说明书须要严酷的配置控制；⏹所有的变动请求须要被管理和控制；⏹用于跟踪的度量文档须要管理和控制.QA检查清单：质量包管检查清单包含：⏹软件需求规格说明书；⏹变动需求跟踪记录；⏹验收测试尺度与测试计划.该阶段要确保客户提出的需求是可行的，确保客户了解本人提出的需求的含义，而且这个需求能够真正达到他们的目标，确保开发人员和客户对于需求没有曲解或曲解，确保按照需求实现的软件零碎能够满足客户提出的需求.3.设计阶段目的和范围：本过程所关注的是把需求（用户需求说明书和软件需求规格说明书）转酿成为如何实现这些需求的描述.次要包含以下两个阶段：⏹概要设计；⏹具体设计.软件设计过程次要包含以下活动：⏹体系结构设计；⏹运算方法设计；⏹类/函数/数据结构设计；⏹建立测试尺度.进入尺度：⏹产品需求曾经构成了基线；⏹须要设计解决方案；⏹新的或点窜的需求须要改变当前的设计.输入：⏹构成基线的需求（用户需求说明书和软件需求规格说明书）.退出尺度：⏹设计文档曾经评审并构成基线；⏹测试尺度、测试计划可行.输出：⏹概要设计文档；⏹具体设计文档；⏹测试计划；⏹项目尺度；⏹选择的工具.过程描述：设计过程包含概要设计和具体设计两个阶段.（1）概要设计这个阶段包含以下的任务：结构设计、逻辑设计、项目尺度定义、零碎/集成测试计划的创建，并要进行同级评审.概要设计模板、零碎/集成测试计划模板在本阶段将被使用.①结构设计在这个步调中，完成软件解决方案的基础规划设计.继软件规划设计以后，利用程序被分解成基础模块/组件，目的是为了实此刻模块内的高聚合和模块之间的松耦合.通常情况下，模块的划分是基于概要设计中的功能需求而定的.②运算方法设计在这个步调中，完成软件零碎解决方案与利用程序的转换逻辑设计.设计模块接口和利用需求的次要逻辑.在决定通用算法之前，通常须要一些模型.③定义项目尺度在这个步调中，所有的项目开发尺度被定义.具体设计/编码尺度要同实际履行的分歧.拟定尺度时还要考虑尺度将来的扩展性、灵活性和方便性.④创建零碎/集成测试计划基于对概要设计的理解，零碎和集成测试计划被拟定出来.验证最初生产的产品达到了设计请求，通常采取基于黑盒的功能或功能检查.⑤评审设计作为所有开发阶段基础的概要设计是非常次要的，是以须要进行同级评审，由能力强的高级软件工程师构成的同级评审小组，以确保完成了合适的软件解决方案设计.（2）具体设计这个阶段包含以下任务：具体设计和筹办单元测试计划.在这个阶段，须要使器具体设计模板和单元测试计划模板.①类/函数/数据结构设计根据项目所采取的设计方法（软件结构化设计方法/面向对象设计方法）进行类、函数及数据结构的设计.所有的用户界面、形态转换和相干的数据库具体描述在本阶段被建立.②创建单元测试计划测试计划应当包含要被测试的每一个模块的每一个元素，例如：⏹与需求的完好分歧性；⏹与其它元素的分歧性；⏹在功能上的请求.单元/功能测试采取完好透明的白盒/玻璃盒测试方法，对于测试者来讲，实际运转的代码是可见的.③评审具体设计具体设计阶段的输出是代码编写工作的基础，是非常次要的，是以须要在项目组中很好的进行评审.评审小组负责评审和清除那些在具体设计中与采取的方法纷歧致的成绩.（3）选择有效工具在具体设计完成以后，零碎在解决方案曾经非常清晰.这时候，项目组须要选择用来提高软件质量的工具.这些工具要发生以下感化：⏹提高质量；⏹提高生产力；⏹缩短开发周期.验证：⏹项目管理者分析概要设计满足需求的程序；⏹项目管理者不定时的监督具体设计说明书的创建工作；⏹项目管理者通过定期的分析在设计阶段收集的数据来验证设计过程履行的无效性；⏹质量包管（QA）人员通过验证发生的工作产品和做独立的抽样检查来验证产品的无效性；⏹质量包管（QA）人员通过分析项目的度量数据和对过程的走查来验证设计过程的效性.配置控制：⏹所有的概要设计文档、具体设计文档和零碎/集成测试计划须要进行严酷的配置控制；⏹跟踪的度量数据须要进行管理和控制.质量包管（QA）检查清单：质量包管（QA）检查清单包含：⏹概要设计文档；⏹具体设计文档；⏹测试计划（零碎/集成/单元）；⏹项目尺度.在概要设计阶段，要确保规格定义能够完好符合、撑持和覆盖前面描述的零碎需求；可以采取建立需求跟踪文档和需求实现矩阵的方式，确保规格定义满足零碎需求的功能、可保护性、灵活性的请求；确保规格定义是可以测试的，而且建立了测试计谋；确保建立了可行的、包含评审活动的开发进度表；确保建立了正式的变动控制流程.在具体设计阶段，要确保建立了设计尺度，而且按照该尺度进行设计；确保设计变动被精确跟踪、控制、文档化；确保按照计划进行设计评审；确保设计按照评审原则评审通过并被正式批准之前，没有开始正式编码.4.编码阶段目的和范围：编码过程的目的是为了实现具体设计中各个模块的功能，能够使用户请求的实际营业流程通过代码的方式被计算机识别并转化为计算机程序.编码过程就是器具体的数据结构来定义对象的属性，器具体的说话来实现营业流程所暗示的算法.在对象设计阶段构成的对象类和关系最初被转换成特定的程序设计说话、数据库或者硬件的实现.进入尺度：⏹设计文档曾经构成基线；⏹具体设计变动编写终了并通过评审，而且代码须要变动时；⏹对于保护项目，保护需求分析曾经构成基线，可进行代码的变动；⏹用于编码的测试尺度曾经拟定.输入：⏹具体设计文档；⏹特定项目的编码规范；⏹相干的软、硬件环境；⏹保护分析文档；⏹测试计划.退出尺度：具体设计中所有模块的功能全部被实现，并通过自我代码审查，编译通过.输出：⏹已完成的、须要进行测试的代码；⏹代码编写规范的更改建议.过程描述：编码过程是把具体设计中的各个模块功能转化为计算机可识别代码的过程，是以程序员在进行编码时，必定要细心认真，切勿有半点疏忽.编码过程通常情况下占全部项目开发时间的20%摆布，为了代码达到高质量、高尺度，代码编写过程必定要合理规范.编码过程次要包含以下几项活动：⏹拟定编码计划；⏹认真浏览开发规范；⏹编码筹办；⏹专家指点，并填写疑问或成绩表；⏹理解具体设计书；⏹编写代码；⏹自我审查；⏹提交代码；⏹更改代码.编码过程流程如下图所示.（1）拟定编码计划在编码之前一周，项目经理要根据具体设计中的模块划分情况拟定编码计划.编码计划的次要内容如下.①本次编码的目的在拟定编码计划时，必必要明确编码目的.②编码人员构成在编码之前，要确定本次编码的人员构成：选择编码人员时要考虑以下几点：义务心、技术能力、服从认识、努力程序、编码效力、编码质量.③编码任务分配在编码之前，必定要为每个编码人员划分好本人所负责的模块，而且要规定各个模块的编码开始，结束日期.（2）认真浏览开发规范为了实现编码的规范统一，须要拟定编码规范.有的项目，客户也会提供一些开发规范用来对本次编码进行束缚.编码人员在编写代码之前必定要理解并把握相干编码规范的所有内容.如许有助于当前编码工作的规范统一.如果本次编码采取的是公司本人的开发规范，编码人员在浏览的过程中，如果发现编码规范出缺乏或分歧理的地方，可以编写开发规范建议书提交给项目经理，项目经理再和软件质量包管人员取得联系以决定是否要对目前的编码规范进行更改.（3）编码筹办在进行编码之前还要进行一些相干的筹办.①软硬件环境配置：包含编码工具、配置管理工具、数据库和一些须要的辅助工具.②了解程序设计说话的特性，选择良好的程序设计风格：程序设计风格是程序设计质量的一个次要方面，具有好的设计风格的程序更容易浏览和理解.（4）理解具体设计书因为项目模块功能的复杂性，即使再具体的设计也会有表达不敷精确的地方，是以在编写代码之前，必定要把每个模块的具体设计思路弄清楚.如果编码人员在理解具体设计时有困惑，必定要扣问具体设计人员.为了包管编码人员对具体设计的理解的精确性，采取以下方法：①具体设计同级评审时，让编码人员介入；②让编码人员对具体设计进行讲解；③让编码人员根据本人的理解画出流程图，由具体设计者确认.如果编码人员在理解具体设计书的过程中存在疑问，应填写具体设计疑问列表提交给项目经理或具体设计人员.（5）专家指点在编码之前或编码过程中，为了包管编码工作的顺利进行和代码质量，项目经理要根据目前编码人员的技术能力或开发进度情况约请本项目组内部或内部专家对编码人员进行指点.指点的内容次要包含以下两方面的内容.①对于本次编码有关的营业进行指点：对编码人员进行营业上的指点，有助于编码人员对具体设计的理解.②对技术进行指点：通过对编码人员的技术指点，可以解答编码人员在技术上的一些疑问.（6）编写代码在很多的软件开发中，客户为了便于程序的可保护性，常常会对程序代码编写过程做出一些规定，如变量的命名规则、书写规范和公共处理等，所以这就请求编码人员要熟悉这些请求和规范，并严酷的恪守这些规范，如果客户没有规定，就要按照公司的规定履行.①画出程序的流程图程序的流程图又称程序框图，用来描述软件设计，是历史最长、使用最广泛的方法.在编码之前，必定要先画好程序的流程图，这对一个复杂的程序来说是非常须要的，如许做了当前，可以使你在编码阶段达到事半功倍的后果，而且对于代码的精确性和质量都是一个很好的包管.②代码的模块化模块化是把零碎分割成能完成独立功能的模块代码，明确规定各个模块代码及其输入输出规格，使模块代码的接口不会发生混乱.③程序的注解程序的注解对于程序的浏览与理解起侧次要的感化.注解次要分两部分.程序块头的注解，主如果模块功能的说明、输入输出变量的说明、算法的说明、程序员姓名和程序完成和变动的日期列表.这些主如果满足管理者的须要，管理者易于把握哪些程序是由哪个编码人员负责的.程序内部的注解，对程序中的一些难以理解的语句以上正文，以使浏览者容易理解设计者的意图，易于理解程序.如许的程序具有很强的可读性和可保护性.④数据类型/变量说明数据说明的次序应尺度化，如按数据类型或者数据结构来确定数据说明的次序，次序的规则在数据字典中加以说明，以便在测试调试阶段和保护阶段可以方便的查找数据说明的情况；⏹当对在同一个语句中的多个变量加以说明时，应按英文字母的顺序排列；⏹在使用一个复杂的数据结构时，最好加正文语句；⏹变量说明不要漏掉，变量的类型、长度、存储及其初始化要精确.⑤语句构造⏹不要为了节省空间把多个语句写在同一行；⏹尽量防止复杂的条件；⏹对于多分支语句，应当把出现可能性大的情况放在前面，把较少出现的分支放在后面，如许可以加快运算时间；⏹防止大量使用轮回嵌套语句和条件嵌套语句；⏹利用括号使逻辑表达式或算术表达式的运算次序清晰直观；⏹每个轮回要有终止条件，不要出现死轮回，也要防止不成能被履行的轮回.⑥程序效力程序效力次要指处理工作时间和内存容量这两方面的利用率，在程序满足了精确性、可理解性、可测试性和可保护性的基础上，提高程序的效力也是非常须要的.在编码过程中，必定要严酷按照规定的开发规范进行编码，。
配置管理计划(CMT-cm-plan-v1.0)
文档密级：普通文档状态：[ ] 草案 [√]正式发布 [ ]正在修订变更履历目录1配置管理的目的 (3)2人员及职责 (3)3项目软硬件资源 (4)3.1配置管理软硬件资源 (4)3.2其它工具说明 (5)4定义配置项 (5)4.1配置库的结构 (5)4.2权限说明 (7)4.3配置项标识说明 (7)5基线识别 (8)6配置库备份计划 (8)7版本发布计划 (9)8配置报告计划 (10)9配置审计计划 (10)10项目变更管理计划 (10)1配置管理的目的在2012集约化平台开发项目开发的过程中，建立和维护工作产品的完整性和一致性，建立项目组可开展工作的平台，标识研发过程达到的状态。
2人员及职责3项目软硬件资源3.1配置管理软硬件资源3.2其它工具说明无4定义配置项4.1配置库的结构4.2权限说明1)2)3)4.3配置项标识说明配置项标识的规则为：项目名称-过程域名-配置项名称-版本。
从上面的规则可知，配置项标识四个主段位：1)第一主段位——[ProName]：用于描述配置项所属的项目，本项目的项目简称为：CMT.2)第二主段位——[PA]：用于描述配置项所在的过程域——分为PP、IPM、PPQA、SAM、MA、PMC、RSKM、RD、REQM、CM、TS、Ver、Val、PI、OPF、OPD、OT、DAR。
3)第三主段位——[TYPE]：用于描述配置项的文件名称，例如：Plan、CMWeeklyRpt、Audit、Recorde、Report等，即为文档的英文名称。
4)第四主段位——[Version]:用于描述配置项的版本，以和同类文件相区别，各类周报采用yymmdd，其他文件均采用版本号。
5)其中对于：●处于“草稿”状态的配置项的版本号格式为：0. YZ。
（YZ数字范围为01—99）●处于“审核”状态的配置项的版本号格式为：0. Y0。
（Y数字范围为1—9）●处于“发布”状态的配置项的版本号格式为：X.Y。
软件质量管理计划模板word文档良心出品
xxxx项目质量保证计划[V ]草稿[]正式发布[]正在修改***科技（北京）有限公司版本历史目录 .............................1.介绍 ..........................1.1目的...................1.2术语...................1.3参考资料...............2.管理..........................2.1职责................... 3任务............................3.1过程与产品质量检查计划3.2参与技术评审的计划..3.3审计流程...............4.输出产物....................... 目录56771.介绍1.1目的本质量保证计划制定（某项目）项目质量保证工作相关的一些措施和规定，作为质量保证工作的整体指导方向，是质量保证人员展开质量活动的依据，也是检查项目质量的基础。
本质量保证计划的目的是保证所发布的（某产品）能够满足《需求规格说明书》中规定的各项需求。
1.2术语1.3参考资料«**-项目计划》2.管理2.1职责3任务3.1过程与产品质量检查计划提示：质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果, 并估计检查时间和人员。
注意：对某些过程域的检查应当是周期性的而不是一次性的，例如配置管理、需求管理等。
3.2参与技术评审的计划提示:（1）技术评审计划一般由研发经理或者项目的技术负责人制定。
（2）质量保证员应当参与并监督重要工作成果如需求、设计、代码的技术评审。
质量保证员根据技术评审计划，制定“参与技术评审”的计划。
（3）工作成果的技术评审有两种形式：正式技术评审（FTR）和非正式技术评审（ITR）。
FTR需要举行评审会议，参加评审会议的人数相对比较多。
ITR形式比较灵活,般在同伴之间开展或以邮件等的方式进行评审。
ISO9001-2015内审检查表(含检查记录)
£09001:2015版内审检查表（完整记录）V V V V V管理体系的有效性进行沟通，包括与组织内外部沟通，以达到相互了解、相互信任、实 现全员参与的目的。
具体可采取： a ） 沟通什么； b ） 何时沟通； c ） 与谁沟通； d ） 如何沟通；e ） 由谁负责。
7.5.1 总则组织的质量管理体系应包括：a ） 标准要求的形成文件的信息（含程序文件、操作规程、管理制度、记录等）b ） 组织确定的为确保质量管理体系有效性所需的形成文件的信息。
质量管理体系形成文件的信息的多少与详略程度应考虑： a ） 本组织的规模，以及活动、过程、产品和服务的类型； b ） 过程的复杂程度及其相互作用；c ） 人员的能力。
7.5.2创建和更新在创建和更新形成文件的信息时，组织应确保适当的： a ） 标识和说明（例如：标题、日期、作者、索引编号等）；b）格式（例如：语言、软件版本、图示）和媒介（例如：纸质、电子格式）c）评审和批准，以确保适宜性和充分性。
7.5.3形成文件的信息的控制7.5.3.1 应控制质量管理体系和本标准所要求的形成文件的信息，以确保：8.3产品和服务的设计和开发1、设计开发的策划有哪些？2、设计开发的输入信息有哪些？8.3.1 总则3、设计开发是怎么进行控制的？组织应建立、实施和保持设计和开发过程，以便确保后续的产品和服务的提供。
4、设计开发输出有哪些内容？8.3.2 设计和开发策划5、设计开发更改了哪些内容，更改后又是怎么控制的？在确定设计和开发的各个阶段及其控制时，组织应考虑：a) 设计和开发活动的性质、持续时间和复杂程度；b) 所需的过程阶段，包括适用的设计和开发评审；c) 所要求的设计和开发验证和确认活动；d) 设计和开发过程涉及的职责和权限；e) 产品和服务的设计和开发所需的内部和外部资源；f) 设计和开发过程参与人员之间接口的控制需求；g) 顾客和使用者参与设计和开发过程的需求；h) 后续的开发的产品和服务提供的要求；i) 顾客和其他相关方期望的设计和开发过程得控制水平；j) 证实已满足设计和开发要求所需的文件化信息。
质量管理体系检查表(生产车间)
13
环标
包装、标签、储运/回收与废物处置
《固体废弃物管理规范》
查看：产品包装材料是否可回收利用？处置的办法及查看现场如何存放？
生产现场的各类搬运和储存是否会影响产品的性能？对环境产生的污染是否采取相应的措施？
按生产流程查生产设备的配置和完好情况？工作环境是否符合规定要求？
查看：关键过程（配料）、特殊过程（成型、施釉、印花、烧成）等，是否形成了作业指导书？
查看生产过程的参数控制记录和各现场监控仪参数是否符合技术文件的规定要求；当天的记录是否及时？确认其实施的符合性和有效性？
6
Q:6.3
E:
环标
“3C”:
4.4
询问：当设备、原料变化和质量波动明显时是否进行了再确认？
8
Q:
“3C”:
9.0
标识和可追溯性
《标识和可追溯性控制程序》
询问：在产品实现的全过程中如何标识和识别产品？并查看现场实际标识情况及记录。
(包括报表的标识、纸箱的标识、合格品存放处的标识、是否唯一和已受控并有记录等情况。)
查阅：强制性产品认证标志的使用是否按要求执行？
各生产现场是否合理配置消防设施？并抽查其有效情况下？
查看：当顾客财产出现问题时，是否按规定予以记录并向顾客报告？
11
Q:
环标
产品防护
《产品防护控制程序》
询问及现场观察：在生产和服务过程中其产品是如何进行搬运、包装、贮存和保护的？
查看：现场作业的实际情况，是否达到产品防护的要求？
12
Q:8.3
J:5.3
环标
软件配置管理计划模板
XXXX软件项目配置管理计划XXXX企业有限公司____年___月___日文档信息修改记录目录软件项目配置管理计划 (2)1 引言 (2)1.1 编写目的 (2)1.2 术语定义 (2)1.3 参考资料 (2)2 计划内容 (2)2.1 人员及职责 (2)2.2 软硬件环境计划 (4)2.2.1 项目计划环境 (4)2.2.2 需求分析和设计环境 (4)2.2.3 开发环境 (4)2.2.4 测试环境 (4)2.2.5 配置管理环境 (4)2.3 配置项计划 (4)2.4 配置库计划 (6)2.5 权限计划 (7)2.6 基线计划 (8)2.7 发布计划 (8)2.8 配置库备份计划 (9)软件项目配置管理计划1 引言1.1 编写目的本文档目的在于对本公司项目进行软件配置管理，提高软件质量，降低软件开发成本。
本计划制定了本公司如何进行配置管理活动、活动的计划安排、指派的职责和所要求的资源。
对本公司项目实施软件配置管理活动时，需要参照本计划。
1.2 术语定义1、软件配置管理（SCM）：软件配置管理是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性，控制这些特性的变更，记录和报告变更的过程和状态，并验证它们与需求是否一致。
2、配置项（CI）：配置项可包括以下几方面：项目(或活动)文档、源代码、可执行代码、度量数据、变更请求(CR)。
项目(或活动)文档即项目(或活动)相关的规范、指南中定义的各个任务的输出和输入；源代码和可执行代码是特殊的文档；度量数据指度量分析定义表中定义的度量以及对应的实际数据。
3、基线（BaseLine）: 用来标识一组配置项的特定版本的集合的标记，以记录工作成果的历史状态，或通过不同的版本组合定义不同特性的工作成果。
1.3 参考资料2 计划内容2.1 人员及职责1、根据《软件项目计划书》中的角色分配，确定CM，CCB（变更控制委员会）成员；2.2 软硬件环境计划2.2.1 项目计划环境软件：MS Office Word、MS Office Excel、MS Office Project2.2.2 需求分析和设计环境软件：MS Office Word、MS Office Visio、Sybase PowerDesigner、Rational Rose2.2.3 开发环境软件：Windows Visual Studio .Net、MyEclipse、JDK、Apache-Tomcat、Apache、Oracle 10g、SQL Server 2003、WebLogic、SQL Server 2005、Websphere2.2.4 测试环境软件：Load Runner2.2.5 配置管理环境1、软件：TortoiseSVN2.3 配置项计划配置管理员标识配置项，标识符的参考格式为：项目编号-配置项类型-配置项序号-配置项版本配置项名称。
软件质量管理计划模板
XXXX项目质量保证计划***科技（北京）有限公司版本历史目录目录 (3)1.介绍 (4)1.1目的 (4)1.2术语 (4)1.3参考资料 (4)2.管理 (4)2.1职责 (4)3任务 (5)3.1过程与产品质量检查计划 (5)3.2 参与技术评审的计划 (6)3.3 审计流程 (7)4.输出产物 (7)1.介绍1.1目的本质量保证计划制定(某项目)项目质量保证工作相关的一些措施和规定，作为质量保证工作的整体指导方向，是质量保证人员展开质量活动的依据，也是检查项目质量的基础。
本质量保证计划的目的是保证所发布的(某产品)能够满足《需求规格说明书》中规定的各项需求。
1.2术语1.3参考资料《**-项目计划》2.管理2.1职责3任务3.1过程与产品质量检查计划提示：质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果，并估计检查时间和人员。
注意：对某些过程域的检查应当是周期性的而不是一次性的，例如配置管理、需求管理等。
3.2 参与技术评审的计划提示：（1）技术评审计划一般由研发经理或者项目的技术负责人制定。
（2）质量保证员应当参与并监督重要工作成果如需求、设计、代码的技术评审。
质量保证员根据技术评审计划，制定“参与技术评审”的计划。
（3）工作成果的技术评审有两种形式：正式技术评审（FTR）和非正式技术评审（ITR）。
FTR需要举行评审会议，参加评审会议的人数相对比较多。
ITR形式比较灵活，一般在同伴之间开展或以邮件等的方式进行评审。
3.3 审计流程提示：此处定义针对软件工作产品的审计过程。
下面是审计过程示例：1.确定当前要审计的软件工作产品。
2.确定与当前审计有关的标准。
3.使用《QA产品审计报告》中的检查表实施工作产品审计。
4.使用《QA过程审计报告》中的检查表实施工作过程审计。
5.制定和发布《软件质量保证报告》6.对不能在项目组内部解决的不符合问题报告给高层经理。
7.对不符合问题进行记录、跟踪直至解决。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
目标
（）
适用范围
（）
职责与权限
（）
配置项标识
（）
配置管理工具
（）
配置项组织结构
（）
备份制度
（）
版本发放
（）
变更控制
（）
监督与监控
（）
评审结论
评审结论是否明确
（）
评审遗留问题是否落实
（）
评审报告
评审报告是否成文
（）
评审报告是否发给参加评审的人员
（）
项目SQA人员签名：
请在（）内标注相关检查结果
（）
对配置项（包括源码）修改时填写注释
（）
源代码阶段性设置Lable
（）
监督与控制机制是否明确
（）
评审的组织
以上资料是否提前2天发给参加评审的人员
（）
是否指定评审会议主持人
（）
评审的参与人
配置管理计划中涉及的SCCB成员
（）
配置管理计划中定义的配置管理员
（）
其他相关项目负责人
（）
SQA
（）
评审的过程
软件质量保证（SQA）配置管理计划评审检查表
项目名称
评审时间
评审主持人
评审方式
【】会议【】邮件
文件齐备性
配置管理计划
（）
文件内容完整性
配置管理计划
目标
（）
适用范围
（）
职责与权限
（）
SCCB名单
（）
配置管理负责人是否明确
（）
项目组成员得权限是否明确
（）
配置项标识
开发计划
（）
开发策划书
（）
配置管理计划
（）
√：检查通过
х： 检查不通过需修改
其他标记：请注明原因
质量策划
（）
需求文档
（）
设计文档
（）
测试计划用户手册
报告
（）
培训记录
（）
每日/周工作记录
（）
评审报告
（）
源代码
（）
开发工具与版本
（）
配置管理工具的定义
（）
配置项组织结构
（）
备份制度是否明确
（）
版本发放
版本发放原则（谁做，如何做）
（）
版本标识原则
（）
变更控制
明确的提交流程
（）
明确的修改流程