软件质量保证过程(SQA)实施过程Word格式.docx
《软件质量保证过程(SQA)实施过程Word格式.docx》由会员分享，可在线阅读，更多相关《软件质量保证过程(SQA)实施过程Word格式.docx（14页珍藏版）》请在冰点文库上搜索。
因此，前两点通常被直接放到计划中，而第三点则以链接的方法放到计划中。
（1）制订软件开发质量计划
软件开发质量计划包括软件项目管理计划、软件项目质量管理计划。
①制订软件项目管理计划
软件项目管理计划的主要内容包括基础设施计划，进度计划（包括各种类型的估算）、风险管理计划、项目培训计划、执行计划、客户管理计划。
■基础设施计划
基础设施计划包括项目开始执行前必须到位的所有需求，它需要解决以下问题：
软件工程需求、基础设施需求、角色和职责、内外部接口、过程需求、知识和技能需求。
■进度计划
进度计划涉及制定合理可用的项目进度。
在制定项目进度时，需要进行下面的估算：
规模（Size）、工作量（effort）。
项目进度需要描述以下内容：
执行的活动、估算的人时、投入的人员、责任人和时间线、里程碑事件的标识。
■风险管理计划
风险管理包括：
标识风险事件（与管理相关的风险、与执行相关的风险，与客户相关的风险等）、评估风险并设定风险优先级、制订风险缓解和应急计划并跟踪该计划。
■项目培训计划
根据项目及人员结构制订项目培训计划，包括业务领域知识、技术、工具等方面的培训计划。
■执行计划
项目执行计划包含了与执行当前项目关系最大的生命周期模型。
该计划对组织级执行模型进行了裁剪。
项目生命周期模型通常包括：
项目执行的阶段、各阶段的输入和输出、可交付的产品、需要迭代（反复）的阶段。
②制订软件项目质量管理计划
制订软件项目质量管理计划包含如下主要内容：
■项目设定的质量标准；
■同级评审计划：
同级评审计划中描述了在不同的软件生命周期开发阶段，对不同的工作产品所采用的同级评审类型；
■测试计划：
测试计划包括对可执行文件/模块或整个系统将要进行的各种测试。
根据项目测试过程来制定测试计划；
■度量管理计划：
通过裁剪组织级的度量过程来制定项目度量管理计划。
■缺陷预防计划：
管理、开发和测试人员互相配合制订缺陷预防计划，防止已识别的缺陷再次发生；
■过程改进计划：
项目级过程改进的机会要记录到过程改进计划中。
这些机会主要来源于度量分析、缺陷预防分析和标识出的好的或可避免的实践。
（2）制订软件配置管理计划
软件配置管理计划主要包括以下内容：
■软件配置管理计划组织；
■角色和职责；
■开发/维护配置管理计划，包括可配置项的标识、命名约定、目录结构、访问控制、变更管理、基线库创建、放入/提取（Checkin/Checkout）机制、版本控制；
■产品配置管理，包括产品中部件的可跟踪性，产品的版本设定和发布、交付的配置管理（标识出要交付的产品构成）、需求配置管理（需求基线的确定、产品版本与划定基线的需求版本之间的关系）、配置审计。
验证：
同级评审人员和软件质量保证人员必须对项目计划进行评审，批准后项目才能付诸实施。
配置控制：
项目经理保管所有项目计划文档。
对所有项目计划文档都要进行配置管理。
项目结束后，所有的项目计划文档都要保存到组织财富库中，仍受配置控制。
QA检查清单：
QA检查清单包括：
该阶段要确保制定了软件开发质量计划和软件配置管理计划。
2.需求分析阶段
需求说明和需求管理过程的目的是为了保证开发组在开发期间对项目目标和生产出最后产品的目的有一个清晰的理解。
软件需求规格说明书将作为产品测试和验证是否适合需要的基础。
对于需求的变更，它可能在开发项目期间的任何时间点发生，需求的变更将要影响日程和承诺的变化，这些变化需要和客户所提出的要求相一致。
■计划已经被批准，并且项目整体的基础设施是可用的；
■软件的需求已经被需求收集小组捕获；
■对已经形成了基线的软件需求规格说明书有变更的请求时。
■软件的需求说明书；
■变更需求的请求。
■软件需求规格说明书已经经过评审并形成了基线；
■对已经形成基线的软件需求的变更进行了处理；
■形成基线的软件说明书已经经过客户批准；
■验收标准已经完成；
■所有评审的问题都已经解决。
■经过批准并形成基线的软件需求规格说明书；
■对受影响组件的重新估算文档；
■验收测试标准和测试计划。
这个过程主要处理以下两种活动：
需求说明和需求管理。
需求说明指的是需求过程中形成基线的主体，它是以后进一步的设计和测试的基础。
另外，在软件开发过程中，会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚的理解或认识，要对需求进行变更。
在对最初的需求说明书进行变更时，要用到需求管理过程。
（1）需求说明
需求说明过程主要包括以下任务：
■执行需求分析
■定义需求规格说明书
■定义验收标准
■评审说明书和验收标准。
①执行需求分析
分析收集到的需求和在提案中可用的需求。
这个任务要求需求说明书应该在完整性、一致性、清晰性和可测试性上达到比较合理的程序。
②定义需求说明书
基于对需求的分析编写软件需求规格说明书。
这个文档应清晰记录以下内容：
■目标和范围；
■功能需求；
■用户接口；
■输入输出；
■模块之间的接口；
■性能需求；
■特殊用户需求。
如果需求不清晰或模糊，就需要准备原型，通过评估原型来产生需求说明书。
③定义验收标准
基于对以前步骤收集的需求规格说明书，建立测试标准，验证的解决方案。
所有的需求应该可能制定测试标准。
这个测试标准将成为客户批准最终产品的依据，因此要求在制定客户标准时要经常紧密的与客户进行交流沟通。
④评审需求分析说明书和测试标准
因为是开发项目的基础,所以需求规格说明书和验收标准需要由项目组的同级人员进行评审。
（2）需求管理
需求管理过程包括以下6个任务：
■记录变更请求；
■分析受到影响的组件；
■估算需求变更成本；
■重新估算所有产品的交付日期和时间；
■评审受影响组件；
■获得客户的批准。
①记录变更请求；
形成基线的需求说明书的变更可能是由客户提出的，也可能是由于设计或编码阶段开发人员根据一些限制或优化而提出的。
所有需求变更必须经过客户的批准,并且必须是可行的。
任务需求变更可以由组织自己定义开始时间，并且所有需求变更需要记录到变更登记表中。
②分析受到影响的组件；
任何经过批准的变更需要在整个项目组范围内进行受影响组件分析。
③估算需求变更成本；
项目成本与需求变更有关。
任何规模的变更对于成本来讲都是一种损耗。
如果一个受影响组件是非常重要的，那么可行性需要重新进行成本估算。
④重新估算所有产品的交付日期和时间；
如果没有考虑有效的缓冲，成本的变化可能会影响整个项目的交付时间。
在交付时间内的任何实质的变更都需要再同用户商议决定。
⑤评审受影响组件；
在这个步骤中所有相关的受影响组件需要进行评审，项目负责人根执行此项任务。
⑥获得客户的批准。
这个过程的最后一项任务是获得客户的签字。
客户应该同意已经形成基线的软件需求说明书、验收标准和已记录的受影响组件的变更。
■项目经理要定期的检查需求规格说明书和项目需求管理的各个方面；
■软件质量保证人员要定期的对需求分析过程执行独立的评估。
■软件需求规格说明书需要严格的配置控制；
■所有的变更请求需要被管理和控制；
■用于跟踪的度量文档需要管理和控制。
质量保证检查清单包括：
■软件需求规格说明书；
■变更需求跟踪记录；
■验收测试标准与测试计划。
该阶段要确保客户提出的需求是可行的，确保客户了解自己提出的需求的含义，并且这个需求能够真正达到他们的目标，确保开发人员和客户对于需求没有误解或误会，确保按照需求实现的软件系统能够满足客户提出的需求。
3.设计阶段
本过程所关注的是把需求（用户需求说明书和软件需求规格说明书）转变成为如何实现这些需求的描述。
主要包括以下两个阶段：
■概要设计；
■详细设计。
软件设计过程主要包括以下活动：
■体系结构设计；
■运算方法设计；
■类/函数/数据结构设计；
■建立测试标准。
■产品需求已经形成了基线；
■需要设计解决方案；
■新的或修改的需求需要改变当前的设计。
■形成基线的需求（用户需求说明书和软件需求规格说明书）。
■设计文档已经评审并形成基线；
■测试标准、测试计划可行。
■概要设计文档；
■详细设计文档；
■测试计划；
■项目标准；
■选择的工具。
设计过程包括概要设计和详细设计两个阶段。
（1）概要设计
这个阶段包括以下的任务：
结构设计、逻辑设计、项目标准定义、系统/集成测试计划的创建，并要进行同级评审。
概要设计模板、系统/集成测试计划模板在本阶段将被使用。
①结构设计
在这个步骤中，完成软件解决方案的基础布局设计。
继软件布局设计之后，应用程序被分解成基础模块/组件，目的是为了实现在模块内的高聚合和模块之间的松耦合。
通常情况下，模块的划分是基于概要设计中的功能需求而定的。
②运算方法设计
在这个步骤中，完成软件系统解决方案与应用程序的转换逻辑设计。
设计模块接口和应用需求的主要逻辑。
在决定通用算法之前，通常需要一些模型。
③定义项目标准
在这个步骤中，所有的项目开发标准被定义。
详细设计/编码标准要同实际执行的一致。
制定标准时还要考虑标准将来的扩展性、灵活性和方便性。
④创建系统/集成测试计划
基于对概要设计的理解，系统和集成测试计划被制定出来。
验证最后生产的产品达到了设计要求，通常采用基于黑盒的功能或性能检查。
⑤评审设计
作为所有开发阶段基础的概要设计是非常重要的，因此需要进行同级评审，由能力强的高级软件工程师组成的同级评审小组，以确保完成了合适的软件解决方案设计。
（2）详细设计
这个阶段包括以下任务：
详细设计和准备单元测试计划。
在这个阶段，需要使用详细设计模板和单元测试计划模板。
①类/函数/数据结构设计
根据项目所采用的设计方法（软件结构化设计方法/面向对象设计方法）进行类、函数及数据结构的设计。
所有的用户界面、状态转换和相关的数据库详细描述在本阶段被建立。
②创建单元测试计划
测试计划应该包括要被测试的每一个模块的每一个元素，例如：
■与需求的完整一致性；
■与其它元素的一致性；
■在性能上的要求。
单元/功能测试采用完全透明的白盒/玻璃盒测试方法，对于测试者来讲，实际运行的代码是可见的。
③评审详细设计
详细设计阶段的输出是代码编写工作的基础，是非常重要的，因此需要在项目组中很好的进行评审。
评审小组负责评审和清除那些在详细设计中与采用的方法不一致的问题。
（3）选择有用工具
在详细设计完成之后，系统在解决方案已经非常清晰。
这时，项目组需要选择用来提高软件质量的工具。
这些工具要产生以下作用：
■提高质量；
■提高生产力；
■缩短开发周期。
■项目管理者分析概要设计满足需求的程序；
■项目管理者不定时的监督详细设计说明书的创建工作；
■项目管理者通过定期的分析在设计阶段收集的数据来验证设计过程执行的有效性；
■质量保证（QA）人员通过验证产生的工作产品和做独立的抽样检查来验证产品的有效性；
■质量保证（QA）人员通过分析项目的度量数据和对过程的走查来验证设计过程的效性。
■所有的概要设计文档、详细设计文档和系统/集成测试计划需要进行严格的配置控制；
■跟踪的度量数据需要进行管理和控制。
质量保证（QA）检查清单：
质量保证（QA）检查清单包括：
■测试计划（系统/集成/单元）；
■项目标准。
在概要设计阶段，要确保规格定义能够完全符合、支持和覆盖前面描述的系统需求；
可以采用建立需求跟踪文档和需求实现矩阵的方式，确保规格定义满足系统需求的性能、可维护性、灵活性的要求；
确保规格定义是可以测试的，并且建立了测试策略；
确保建立了可行的、包含评审活动的开发进度表；
确保建立了正式的变更控制流程。
在详细设计阶段，要确保建立了设计标准，并且按照该标准进行设计；
确保设计变更被正确跟踪、控制、文档化；
确保按照计划进行设计评审；
确保设计按照评审准则评审通过并被正式批准之前，没有开始正式编码。
4.编码阶段
编码过程的目的是为了实现详细设计中各个模块的功能，能够使用户要求的实际业务流程通过代码的方式被计算机识别并转化为计算机程序。
编码过程就是用具体的数据结构来定义对象的属性,用具体的语言来实现业务流程所表示的算法。
在对象设计阶段形成的对象类和关系最后被转换成特定的程序设计语言、数据库或者硬件的实现。
■设计文档已经形成基线；
■详细设计变更编写完毕并通过评审，并且代码需要变更时；
■对于维护项目，维护需求分析已经形成基线，可进行代码的变更；
■用于编码的测试标准已经制定。
■特定项目的编码规范；
■相关的软、硬件环境；
■维护分析文档；
■测试计划。
详细设计中所有模块的功能全部被实现，并通过自我代码审查，编译通过。
■已完成的、需要进行测试的代码；
■代码编写规范的更改建议。
编码过程是把详细设计中的各个模块功能转化为计算机可识别代码的过程，因此程序员在进行编码时，一定要仔细认真，切勿有半点疏忽。
编码过程通常情况下占整个项目开发时间的20%左右，为了代码达到高质量、高标准，代码编写过程一定要合理规范。
编码过程主要包括以下几项活动：
■制定编码计划；
■认真阅读开发规范；
■编码准备；
■专家指导，并填写疑问或问题表；
■理解详细设计书；
■编写代码；
■自我审查；
■提交代码；
■更改代码。
编码过程流程如下图所示。
（1）制定编码计划
在编码之前一周，项目经理要根据详细设计中的模块划分情况制定编码计划。
编码计划的主要内容如下。
①本次编码的目的
在制定编码计划时，必须要明确编码目的。
②编码人员组成
在编码之前，要确定本次编码的人员组成：
选择编码人员时要考虑以下几点：
责任心、技术能力、服从意识、努力程序、编码效率、编码质量。
③编码任务分配
在编码之前，一定要为每个编码人员划分好自己所负责的模块，并且要规定各个模块的编码开始，结束日期。
（2）认真阅读开发规范
为了实现编码的规范统一，需要制定编码规范。
有的项目，客户也会提供一些开发规范用来对本次编码进行约束。
编码人员在编写代码之前一定要理解并掌握相关编码规范的所有内容。
这样有助于以后编码工作的规范统一。
如果本次编码采用的是公司自己的开发规范，编码人员在阅读的过程中，如果发现编码规范有不足或不合理之处，可以编写开发规范建议书提交给项目经理，项目经理再和软件质量保证人员取得联系以决定是否要对目前的编码规范进行更改。
（3）编码准备
在进行编码之前还要进行一些相关的准备。
①软硬件环境配置：
包括编码工具、配置管理工具、数据库和一些必要的辅助工具。
②了解程序设计语言的特性，选择良好的程序设计风格：
程序设计风格是程序设计质量的一个重要方面，具有好的设计风格的程序更容易阅读和理解。
（4）理解详细设计书
由于项目模块功能的复杂性，即使再详细的设计也会有表达不够准确之处，因此在编写代码之前，一定要把每个模块的详细设计思路弄清楚。
如果编码人员在理解详细设计时有疑惑，一定要询问详细设计人员。
为了保证编码人员对详细设计的理解的正确性，采用以下方法：
①详细设计同级评审时，让编码人员参加；
②让编码人员对详细设计进行讲解；
③让编码人员根据自己的理解画出流程图，由详细设计者确认。
如果编码人员在理解详细设计书的过程中存在疑问,应填写详细设计疑问列表提交给项目经理或详细设计人员。
（5）专家指导
在编码之前或编码过程中，为了保证编码工作的顺利进行以及代码质量，项目经理要根据目前编码人员的技术能力或开发进度情况邀请本项目组内部或外部专家对编码人员进行指导。
指导的内容主要包括以下两方面的内容。
①对于本次编码有关的业务进行指导：
对编码人员进行业务上的指导，有助于编码人员对详细设计的理解。
②对技术进行指导：
通过对编码人员的技术指导，可以解答编码人员在技术上的一些疑问。
（6）编写代码
在很多的软件开发中，客户为了便于程序的可维护性，往往会对程序代码编写过程做出一些规定，如变量的命名规则、书写规范和公共处理等，所以这就要求编码人员要熟悉这些要求和规范，并严格的遵守这些规范，如果客户没有规定，就要按照公司的规定执行。
①画出程序的流程图
程序的流程图又称程序框图，用来描述软件设计，是历史最长、使用最广泛的方法。
在编码之前，一定要先画好程序的流程图，这对一个复杂的程序来说是非常必要的，这样做了以后，可以使你在编码阶段达到事半功倍的效果，而且对于代码的正确性和质量都是一个很好的保证。
②代码的模块化
模块化是把系统分割成能完成独立功能的模块代码，明确规定各个模块代码及其输入输出规格，使模块代码的接口不会产生混乱。
③程序的注解
程序的注解对于程序的阅读与理解起着重要的作用。
注解主要分两部分。
程序块头的注解，主要是模块功能的说明、输入输出变量的说明、算法的说明、程序员姓名和程序完成以及变更的日期列表。
这些主要是满足管理者的需要，管理者易于掌握哪些程序是由哪个编码人员负责的。
程序内部的注解，对程序中的一些难以理解的语句以上注释，以使阅读者容易理解设计者的意图，易于理解程序。
这样的程序具有很强的可读性和可维护性。
④数据类型/变量说明
■数据说明的次序应标准化，如按数据类型或者数据结构来确定数据说明的次序，次序的规则在数据字典中加以说明，以便在测试调试阶段和维护阶段可以方便的查找数据说明的情况；
■当对在同一个语句中的多个变量加以说明时，应按英文字母的顺序排列；
■在使用一个复杂的数据结构时，最好加注释语句；
■变量说明不要遗漏，变量的类型、长度、存储及其初始化要正确。
⑤语句构造
■不要为了节省空间把多个语句写在同一行；
■尽量避免复杂的条件；
■对于多分支语句，应该把出现可能性大的情况放在前面，把较少出现的分支放在后面，这样可以加快运算时间；
■避免大量使用循环嵌套语句和条件嵌套语句；
■利用括号使逻辑表达式或算术表达式的运算次序清晰直观；
■每个循环要有终止条件，不要出现死循环，也要避免不可能被执行的循环。
⑥程序效率
程序效率主要指处理工作时间和内存容量这两方面的利用率，在程序满足了正确性、可理解性、可测试性和可维护性的基础上，提高程序的效率也是非常必要的。
在编码过程中，一定要严格按照规定的开发规范进行编码，如果没有按照编码规范进行编码，再好的程序代码也不能被接受。
另外，在编写代码时，如果认为开发规范有不合理或有待补充之处，应该填写开发规范建议书提交给项目经理；
如果发现详细设计中有问题或对详细设计产生疑问，应该填写详细设计疑问列表并提交给项目经理。
（7）代码审查
在编码过程中，每个模块或程序的自我审查的关键环节是绝对不能缺少的。
无论多么好的编码人员编写的代码，都会或多或少的存在缺陷，从而影响程序的运行。
有的缺陷可以在很短的时间内暴露出来；
有的缺陷需要很长的时间才能显现出来。
因此在代码审查过程中，一定要仔细认真，不要遗漏某个条件。
编码人员切勿对自己编写的代码过于自信而不去自我审查。
在进行代码审查过程中，并不是盲目地进行审查。
而是要按照代码审查列表中的内容进行审查。
审查之后还要把自己审查的内容以及发现的问题记录到代码审查记录中。
代码审查记录不作为考核个人的依据。
通过代码审查记录，管理人员可以掌握每个编码人员的代码审查工作情况以及自我审查的质量效率。
如果是比较重要的代码（如重要的算法、复杂的SQL程序段、要求性能比较高的模块等）,可以让经验丰富的设计人员或编码人员来复查或进行同级评审。
（8）代码测试
为了进一步保证代码的正确性和合理性，编码人员还要对自己编写的代码进行测试。
代码测试的依据是详细设计过程中的单元测试计划书。
编码人员按照测试计划书中所提供的每个测试项目的测试用例进行测试。
本次测试只是编码人员对自己所编写的代码进行自我测试，测试主要采用白盒与黑盒结合的方法。
在代码测试过程中，应该填写代码测试记录。
（9）提交测试
编码人员对自己编写的代码审查完毕，并认为代码不会有任何问题，就可以把代码提交给相应的测试人员。
在提交代码时一定要注意自己所提交的代码是最新的版本。
（10）更改代码
更改代码的情况可以分为两种：
①在测试中发现代码有误或者逻辑不合理。
出现这种情况的主要原因可能有两种：
一是编码人员本身的错误而造成的缺陷；
二是在需求、设计阶段的错误没有被查出，被带到编码阶段而造成的缺陷。
②由于需求和设计的变更引起的代码变更。
在变更代码的过程中一定要注意对代码的版本管理。
■验证编码的规范性；
■验证是否进行了自我审查；
■验证代码的一致性和可跟踪性；
■通过测试验证代码的正确、合理性；
■验证每个编码人员的工作能力。
■通过相应的配置管理工具对不同版本的代码进行管理；
■对编码规范进行管理；
■对项目开发质量计划进
升级会员 