《软件质量管理制度》.docx
《《软件质量管理制度》.docx》由会员分享，可在线阅读，更多相关《《软件质量管理制度》.docx（30页珍藏版）》请在冰豆网上搜索。
《软件质量管理制度》
《软件质量管理制度》
一、管理组织
本公司的软件质量保证活动统一由质量管-理-员进行管理、检查与汇报，公司相关部门经理及项目中的项目经理、程序经理、开发经理、测试经理、产品经理、测试经理、用户教育经理是质量保证活动中的第一责任人。
二、软件开发过程
本公司的软件开发过程分为以下8个阶段：
项目策划阶段、需求分析阶段、设计阶段、开发阶段、测试阶段、实施阶段、验收阶段、维护阶段，每个阶段的主要活动分别为：
业务启动和项目规划、需求分析、逻辑设计和物理设计、软件开发、软件测试、系统实施及用户培训、用户试用及验收、维护，里程碑分别为：
策划完成、需求明确、设计完成、开发完成、测试通过、系统上线、验收通过、合同结束。
每阶段结束后，必须对相应的里程碑进行检查，方式为评审或批准。
三、项目文档项目文档分为两种：
管理类文档与技术类文档，所有文档必须保存于知识库及相应的vss库中。
文档共有三种状态：
编制完成、审核通过、批准通过。
其中管理类文档只有编制和批准两种状态，技术类文档拥有所有三种状态。
所有文档必须明确说明当前文档版本号。
管理类文档包含以下类型：
计划、总结、报告、会议纪要、备忘录、申请等。
技术类文档包含：
设计文档、需求文档、测试设计文档、界面原型软件、使用手册、安装手册、技术白-皮-书、培训资料、源代码、软件产品等。
除vss库中的文档以外，放入知识库中的文档由部门助理统一放入，文档必须批准通过。
文档的编制、审核、批准可在文档中直接写明，也可使用单独的审批文档进行说明。
每个项目在不同阶段必须产生的文档如下，但不限于此：
1、项目开始前：
合同、技术方案、市场立项表。
以上文档存放于知识库。
2、项目策划阶段：
业务启动表（excel格式）、项目规划（word格式）、项目进度（project格式）等。
必须使用规定模板编写。
以上文档存放于知识库。
3、需求分析阶段：
需求模型（ea格式）、软件需求规格说明书（word格式）、单据报表格式（excel格式）、需求分析评审表（word格式）、需求分析计划（word格式和project两种格式）。
必须使用规定模板编写。
以上文档存放于知识库。
4、设计阶段
软件开发计划（project格式）、逻辑设计（ea格式）、物理设计（vs.格式）、设计评审表（word格式），必须使用规定模板编写。
物理设计存放于vss库，其它文档存放于知识库。
5、开发阶段
源代码、可安装的软件、安装手册、评审表（word格式）。
源代码、可安装的软件存放于vss库，其它文档存放于知识库。
6、测试阶段
测试用例设计、软件bug、测试计划（word格式和project两种格式）、测试报告（word格式）、开发的测试工具源代码及软件、测试通过的软件产品、软件评审表（word格式）。
开发的测试工具源代码及软件、测试通过的软件产品存放于vss库，其它文档存放于知识库。
软件bug存于td中。
7、实施阶段实施计划（word格式和project两种格式）、实施报告（word格式）、用户使用手册、用户培训资料、用户培训记录、软件问题反馈表（excel格式）、上线报告（书面、电子扫描件）等。
必须使用规定模板编写。
以上文档存放于知识库。
8、验收阶段
验收材料、验收报告（书面、电子扫描件）。
以上文档存放于知识库。
9、维护阶段
维护报告（word格式），以上文档存放于知识库。
四、检查和审查
本公司的项目关键检查点有以下8个，采取评审和批准的方式，由质量管-理-员进行跟踪。
1、策划完成里程碑
以总经理批准通过业务启动表为标志，质量管-理-员检查业务启动表、项目规划、项目风险控制计划、项目进度、技术方案文档是否进入知识库。
负责人为项目经理。
2、需求明确里程碑以软件需求评审通过为标志，评审通过后由配置管-理-员建立软件功能基线。
项目由用户代表、公司代表、同行、下游人员（程序经理、开发经理、测试经理、用户教育经理）进行评审，评审记录上必须有以上几类角色的人员进行签名。
质量管-理-员检查需求规格说明书、需求模型、需求评审表是否进入知识库。
负责人为产品经理。
3、设计完成里程碑
以逻辑设计和物理设计通过评审为标志，它包含两个部分：
逻辑设计与物理设计。
逻辑设计评审通过后由配置管-理-员建立指派基线1，物理设计评审通过后由配置管-理-员建立指派基线2。
逻辑设计评审参与人员必须包括：
公司代表、产品经理、开发经理、测试经理、同行。
物理设计评审参与人员必须包括：
公司代表、程序经理、测试经理、同行。
质量管-理-员检查逻辑设计、物理设计、设计评审表是否进入知识库或vss库。
逻辑设计负责人为程序经理、物理设计负责人为开发经理。
4、开发完成里程碑
以软件所有功能开发完成，并通过评审为标志，它的评审必须包括：
公司代表、产品经理、程序经理、测试经理。
质量管-理-员检查评审表是否进入知识库。
负责人为开发经理。
5、测试通过里程碑以软件评审通过作为标志，评审通过后将建立产品基线。
评审参与人员必须包括：
公司代表、产品经理、开发经理、实施经理、用户教育经理。
质量管-理-员检查测试报告、软件评审表是否进入知识库。
负责人为测试经理。
6、系统上线里程碑
以用户签署通过上线报告为标志，评审参与人员必须包括。
用户代表、公司代表、项目经理。
质量管-理-员检查上线报告、实施计划、培训材料等文档是否进入知识库。
如上线报告为纸质文档，则扫描后入库。
负责人为实施经理。
7、验收通过里程碑
以用户签署通过验收报告为准，评审参与人员必须包括。
用户代表、公司代表、项目经理。
质量管-理-员检查验收报告文档是否进入知识库，如上线报告为纸质文档，则扫描后入库。
负责人为项目经理。
8、合同结束里程碑
合同结束，项目跟踪完成。
负责人为软件业务部技术服务组长。
五、测试本公司的软件必须通过测试。
测试工作由开发部测试组负责，所有测试出来的bug必须统一存放，由测试组负责管理。
在测试活动进行前必须有测试计划，测试完成后必须编写测试报告。
测试报告由测试经理负责编写，测试组长批准。
六、配置管理
软件开发过程中的配置管理工作由配置管-理-员负责，配置管理工作详细要求依据《配置管理规范》进行。
七、媒体控制
在软件开发过程中产生的正式文档必须存入于知识库中或vss库中，由公司系统管-理-员负责每天进行物理备份。
在项目进行过程中的备份采用移动硬盘进行，已结项的项目使用刻录光盘存档备份。
八、质量记录
质量记录主要包括各种评审记录和审批记录，形式有评审表、签名文件、会议纪要、质量报告等。
所有的质量记录由质量管-理-员统一管理，纸质的保存在指定的文件柜中，电子的保存在知识库中。
质量记录的保存期限是3年。
九、风险和应急公司所有的项目必须有独立的风险控制计划，风险控制计划由项目经理负责编写并跟踪，风险控制计划由项目管理部门批准。
风险计划中必须包括风险列表、风险度、应急方案、缓解方案、责任人、风险状态。
风险度由风险发生可能性和风险造成的危害程度相乘得到。
十、质量报告
项目的质量管-理-员必须在每周五12：
00以前制作当前的项目质量报告，报告公司当前正在进行的项目的质量状态。
主要包括：
项目文档的审核情况、存放情况、完备情况;各里程碑的评审执行情况;各种计划的跟踪情况，责任人是否及时更新计划;各项规范的符合程度;等等。
质量报告属于项目状态报告的一部分，与其一同填写。
具体格式参见《项目状态报告》。
十一、质量会议
质量会议与公司的项目月例会合并召开，开会时必须提交质量报告。
参会人员必须包括软件业务部部门经理、产品组组长、实施组组长和开发部部门经理、开发组组长、技术支持组组长、测试组组长、各项目经理。
如遇特殊情况，质量管-理-员可临时针对某类问题发起会议，会议结束时必须有会议纪要并存档。
十二、工具及技术在进行质量保证活动中，主要使用两种工具软件：
知识管理系统和msvisualsourcesafe。
前者用来存放项目产生的各种文档，后者主要用于存放源码。
公司在所有正式场合中所使用的项目文档均以这两个系统中的数据为准。
在使用工具软件的过程中，各项目成员的权限统一由公司文档管-理-员进行分配。
十三、变更控制委员会
公司所有在建项目必须成立变更控制委员会，该委员会最小要包括以下人员：
用户代表、市场代表、软件业务代表、开发代表、项目经理，但不限于此。
一般情况下，产品经理、程序经理、开发经理、测试经理、实施经理、用户教育经理也可包括在该组织中。
对于维护性项目，变更控制委员会由营销中心主任、软件业务部经理、开发部经理组成。
第二篇：
软件质量保证管理1、v模型：
v模型是在rad模型的基础上演变而来的，由于开发过程构造成一个v字形而得名。
v模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
v模型具有面向客户、效率高、质量防范意识等特点。
左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动---审核过程，也就是静态的测试过程；右边是对左边结果的验证，是动态的过程，即对设计和分析的结果进行测试，以确认是否满足用户的需求。
v模型避免了瀑布模型所带来的误区-----软件测试是在代码完成之后进行的。
p30
2、什么是变更控制。
（p111）
软件开发过程中都会产生许多变更，如配置项，配置，基线，构建的版本，发布的版本的变更，对于这些变更，都要有一个控制机构，以保证所有的变更都是可控的，可跟踪的，可重现的。
这样的一类机构对变更的管理，就是变更控制。
3、软件可靠性概念。
（p176）
软件可靠性是指在给定时间内，特定环境下软件无错运行的概率，软件可靠性包含了以下三个要素：
规定的时间，规定的环境条件，规定的功能。
4、cmm（p195）
cmm：
能力成熟度模型，用来衡量组织软件过程成熟度和评价其软件过程能力。
能力成熟度是指一个特定过程被明确定义，管理，测量，控制并且是有效的程度。
分为五个等级：
初始级软件过程的特点是无序的，甚至是混乱的。
几乎没有什么过程是进过定义的。
可重复级关键过程区域集中关注软件项目所关心的，与建立基本项目管理控制有关的事情。
已定义级将软件生命周期的各个阶段严格的划分出来，从组织这个层次来保证过程质量该进
已管理级软件产品的质量目标被量化管理，它遵循了全面质量管理活动的科学程序，关键过程域的关注焦点是建立起对软件过程和正在构造的软件工作产品的定量了解。
优化级关键过程域包括那些为了实施连续不断的和可测的软件过程改进，组织和项目都必须解决的问题。
5、tqm的实施步骤（p265）
（1）建立质量小组，负责过程改进，流程完善，不断发现质量问题提出并实施解决方案。
（2）进行tqm思想的教育，通过教育，要让每个员工深刻认识到“满足顾客的需求是第一的”的思想，理解“什么是顾客需求”，如何让顾客满意等内容。
（3）了解市场，明确顾客需求，了解目前研发的软件产品的市场，包括竞争对手，客户群等，让员工明白什么是质量好的软件产品或软件服务，认真对待质量要求，开发出合格的产品。
（4）建立明确的质量基准和质量评估机制，以便和实际质量水平进行对比，识别质量的目标和工作的重点区域，采取相应措施。
（5）建立相对完善的奖励机制，在认可和给予奖励的过程中，应力求公正，真实，选择恰当的时间，恰当的场合，恰当的方式。
2、版本控制的目的。
是在于对软件开发过程中文件或目录的发展过程提供有效的追踪手段，保证在需要时找到旧的版本，避免文件的丢失，修改文件的丢失和相互覆盖，通过对版本库的访问控制避免XX访问和修改。
另外软件的控制是实现团队开发，提高效率的基础。
3、pdca包括4个部分：
计划、执行、检查、行动描述总结
（1）计划计划：
就是分析当前状况，发现问题，找出原因和主要原因，制定质量方针、质量
目标、质量计划书和管理原则。
管理原则有。
过程方法、管理的系统方法、持续改进
（2）执行：
执行时计划的履行和实现，主要按计划实施地去做，去落实具体对策，并实施过
程的监控，使活动按预期设想前进，最终达到计划设定的目标。
（3）检查。
是对执行后效果的评估。
检查是伴随着实施过程自始至终的，不断收集数据、信
息获取的过程，并通过数据分析、结果度量来完成检查。
行动。
重点在于检查完结果，要采取措施，即总结成功的经验，吸取失败的教训，实施标准化，以后依据标准执行。
4、阶段性开发模型：
增量模型和迭代模型
（1）增量模型描述软件产品的不同阶段是按产品所具有的功能进行划分的，先开发主要
功能或用户最需要的功能，然后随着时间的推进，不断增加新的辅助功能或次要功能，最终开发出一个功能完善的，稳定的产品。
（2）迭代模型描述软件产品的不同阶段是按产品深度或细化程度来划分，先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需要的全部功能。
然后随着时间推进，不断细化已具有的功能或完善已具有的功能，这个过程是一个迭代的过程
6、零缺陷质量管理的实施步骤：
（p268）
（1）建立推行零缺陷质量管理的组织事情的推行都需要组织的保证，通过建立组织，可以动员和组织全体职工积极的投入零缺陷管理，提高他们参与管理的自觉性也可以对每个人的合理化建议进行统计分析，不断进行经验交流，公司的最高管理者要亲自参加，表明决心，做出表率，要任命相应的领导人，建立相应的制度，要教育和训练员工
（2）确定零缺陷管理的目标，确定零缺陷小组在一定时期内所要达到的具体要求，包括确定目标项目，评价标准和目标值
（3）进行绩效评价，
（4）建立相应的提案机制
（5）建立表彰制度
sqa组织的责任是审计软件经理和软件工程组的质量活动中出现的偏差。
7、sqa计划（p283）
sqa在项目早期要根据项目计划制定与其相应的sqa计划，定义各阶段的检查点。
标识出检查审计的工作产品对象，以及在每个阶段sqa的输出产品。
具体实施步骤如下：
（1）了解项目的需求，明确项目sqa计划的要求和范围
（2）选择sqa任务
（3）估计sqa的工作量和资源
（4）安排sqa任务和日程
（5）形成sqa计划
（6）协商，评审sqa计划
（7）批准sqa计划
（8）执行sqa计划
sqa计划包含以下内容：
（1）目的，sqa计划的目的和范围
（2）参考文件，该sqa计划参考的文件列表（3）管理，组织，任务，责任（4）文档，列出所有的相关文档，如程序员手册，测试计划，配置管理计划等（5）标准定义，文档标准，逻辑结构标准，代码编写标准，注释标准等（6）评审/审核（7）配置管理，配置定义，配置控制，配置评审（8）问题报告和处理（9）工具，技术，方法（10）代码控制（11）事故/灾难控制，包括火灾，水灾，紧急情况等。
8、评审和审核的区别。
（p285）
评审：
过程进行时，sqa对过程的检查，sqa的角色在于确保当执行工程活动时，各项计划所规定的过程得到遵循，评审通常通过评委会的的方式进行，是对工作流程的评审
审核。
在软件工作产品生成时，sqa对工作产品进行的检查，sqa的角色在于确保开发工作产品中各项计划所规定的过程得到遵循，审核通常通过对工作产品的审查来执行。
侧重于产品本身。
sqa报告应遵循三条原则sqa和高级管理者之间应有的沟通渠道，sqa报告必须发布给软件工程组织但不必发布给项目管理人员，在可能的情况下向关心软件质量的人发布。
sqa度量是记录花费在sqa活动时间人力数据。
涉及以下三方面：
软件产品评估度量、软件产品质量度量、软件过程审核度量。
sqa的评估任务是软件开发前期对目标的软件和硬件资源进行评估，以确保其充分性和适合性。
9、白盒测试、黑盒测试（p390）
白盒测试将被测试程序看做一个盒子，测试者能够看到被测程序，可以分析被测程序的内部结构。
白盒测试可以用来对代码结构进行全面测试，常用的有语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，条件组合覆盖，路径覆盖，循环测试
黑盒测试常用来验证软件或模块功能是否得到实现，主要运用单元的性能和功能方面的测试除了测试其功能外，还需确保代码在结构上可靠，健全并能够有良好的响应。
黑盒测试主要运用于单元的功能和性能方面的测试。
功能测试包括用户界面测试各种操作的测试不同的数据输入逻辑思路，数据输出和存储的测试。
区别：
关键区别应该就是测试对象不一样，白盒测试主要针对的是程序代码逻辑，黑盒测试主要针对的是程序所展现给用户的功能，简单的说就是前者测试后台程序后者测试前台展示功能
10、测试的原则概括为10项：
（1）所有测试的标准都是建立在用户需求之上2软件测试必须基于“质量第一”的思想去开展各项工作3实现定义好产品的质量标准4软件项目一启动。
软件测试也就是开始5穷举测试是不可能的6第三方进行测试会更客观，更有效7软件测试计划是做好软件测试工作的前提8测试用例的设计出来的，不是写出来的9不可将测试用例置之度外，排除随意性10对发现错误较多的程序段，应进行更深入的测试
39、功能测试的概念。
是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否能正常使用、是否实现了产品规格说明书要求、是否能适当地接收输入数据而产生正确的输出结果等。
5、风险管理法：
sei（软件工程研究所）风险控制一般分5个步骤：
p80
（1）风险识别：
试图系统化的方法来确定威胁项目计划的因素。
识别方法包括：
风险检
测表、头脑风暴会议、流程图分析、与项目人员面谈。
（2）风险分析。
可以分为定性风险分析和定量风险分析。
定性风险分析是评估已经识别
风险的影响和可能性的过程。
定量风险分析是量化分析每一风险的概率及其对项目目标造成的后果，同时也要分析项目总体风险的程度。
（3）风险计划：
制定风险行动计划，应考虑以下部分：
责任、资源、时间、活动、应对
措施、结果、负责人。
（4）风险控制：
方法：
风险避免、风险弱化、风险承担、风险转移。
（5）风险跟踪：
监视风险的状况，检查风险的对策是否有效、跟踪机制是否在运行，不
断识别新的风险并制定对策。
6、评审的内容：
分为管理评审、技术评审、文档评审、过程评审（p217简答）
（1）管理评审是以实施质量方针和目标的质量体系的适应性和有效性为评论基准，对体系文
件的适应性和质量活动的有效性进行评价。
目标：
按规定的时间间隔对质量体系进行评审，确保持续的适宜性和有效性，以满足本标准要求和提供的质量方针和目标。
输入：
体系审核的结果。
输出：
《管理评审报表》
（2）技术评审是对产品以及各阶段的输出内容进行评估。
目的：
确保需求说明、设计说明书
与最初的说明书保持一致，并按照计划对软件进行了正确的开发。
输入：
需求文档、源代码、测试用例、评审检查单、其它文档。
输出：
技术评审报告
（3）文档评审分为格式评审和内容评审。
（4）过程评审是对软件开发过程的评审，其主要任务是通过对流程的监控，保证sqa组织
定义的软件过程在项目中得到了遵循，同时保证质量方针能得到更快更好的执行。
40.朱兰三部曲：
质量策划：
为建立有能力满足质量标准化的工作程序，质量策划是必要的
质量控制：
为了掌握何时采取必要措施纠正质量问题就必须实施质量控制
质量改进：
质量改进有助于发现更好的管理工作方式
40、从软件开发的各阶段论述如何提高软件产品的质量。
1、需求
我们知道人与人的交流总是会存在一些误会，同样一句话，心情不好与心情好的时候听起来的感觉可能会截然相反，正是因为人们之间存在着理解上的偏差，在描述需求的语言上就应该注意尽量避免歧义的产生。
如果对uml比较熟悉的话，需求分析可以利用uml工具进行，这样可以减少一些自然语言引起的歧义，但是uml可能与用户沟通起来有一些障碍，因为并不是所有的用户都了解uml各种图形的意思。
除了工具之外，我们可以从以下几个方面来保证需求描述的质量。
1、看句子和段落是否简短，一个很长的句子，看起来会非常困难，因此无法弄懂真正的需求，另外过长的句子和段落容易让人忽视一些需求，所以如果一个句子不能完全描述清楚需求，应该将其拆分成多个小句子。
2、句子是否有语法错误，还要注意标点符号，有时，标点符号点错了，就完全成了另外一个意思了。
3、是否存在模糊不清的需求，出现类似于可能，大概，或者等词汇表述的需求。
4、另外注意引用的术语和词汇是否前后一致。
5、是否存在一些形容词、比较性词语，比如。
容易的、快速的、方便的、有效的、许多、很少、简单、复杂、最新的，界面友好的，减少、扩大，不小于等等，需要将描述性词语进行量化，并且给出具体值或者范围，要不然不同的人根据不同的理解就会得出不同的结果，最终可能跟用户最初的要求有偏差，那“炒回锅肉”的事情就不可避免地会发生。
另外保证需求质量的一个很重要的因素就是需求是否细化，如果需求不细化也会很容易造成代码的返工，于是就出现了我们的程序员尽管总是加班加点却总是不能如期的完成任务的情景。
那么我们怎样才能判断需求细化的程度呢。
需求细化程度确实很难把握，什么样的需求可以算是比较细了，不用再进行细化了呢。
哪些需求又太粗了呢。
答案是需求是否可以写出相应的测试用例，如果写不出来，就说明需求还不是很细，还需要再进行细化。
2、设计
软件架构设计在软件产品开发周期中占有很重要的位置，我们开发出来的软件产品在开发伊始到产品发布会涉及到方方面面的角色，例如：
用户、项目管理人员、程序员、测试员、维护人员等等。
不同的角色对架构设计的要求也不相同。
例如用户关心的是需求，因此我们的设计对需求的覆盖率是多少。
对于程序员来说模块是否清晰，类的功能是否单一等等，对于测试人员来说系统的是系统的可测试性。
对于维护人员来讲系统的扩展性、可维护性如何。
一个高质量的软件架构，应该最大限度的考虑并满足不同角色的不同要求。
正
是因为有这些要求，我们在进行软件设计的时候，应该进行全面的考虑。
一般用来衡量软件设计质量的标准可以从以下几个方面来考虑：
1）、功能性。
包括完全性、正确性、安全性、兼容性、互用性。
完全性包括功能点覆盖率，重点功能点覆盖率，优先功能覆盖率。
正确性包括需求一致度。
安全性根据软件需求的不同有不同的安全性要求。
2）、效率。
包括产品运行的时间效率和利用的硬件资源两方面来考虑。
3）维护性。
包括架构的可改正性，可扩充性以及可测试性。
如果用户的一个很小的需求变更会引起架构设计很大的变化，那么这样的架构设计的可改正性和可扩充性就比较差。
4）可移植性。
包括硬件的独立性、软件独立性、可安装性、可重用性。
软件设计是否模块化、每个模块的可复用性如何都是应该考虑的因素。
5）可靠性。
包括缺陷数量、容错性、可用性。
6）使用性。
包括可理解性、易学习性、可操作性、易沟通性。
我们软件的最终目的是让用户来使用的，如果易用性不好，可操作性不好都会影响用户对软件的接纳程度。
因此在软件的可使用性也是非常重要的。
3、编码
代码质量的一个很重要的标准就是代码的可读性及规范性，可读性不一定是简单的代码，而是容易理解的代码，因为过于复杂的代码难以测试和维护，同时出错的几率也会更高。
如果一个方法内部的代码很长，而且使用了很多令人难以理解的数据集，这样就会带来代码维护的困难，因为很少有人能够有效地分析它们，因此也就是最容易出现缺陷和错误的地方。
类之间的耦合度会造成类与类之间的相互关联，当一个类发生改变时会使其他的类发生意想不到的变化，一般从导入类的个数判断类之间的耦合度，如果导入类的个数很多，每一个导入类发生变化都会影响到该类本身，另外如果该类的public方法太多也会导致类之间的高耦合性增加。
也许有的程序员会认为写出可读、规范的代码会影响工作进度。
的确，对于程序员个体短时间来说为代码写上注释是要花费些时间，但如今软件开发是多人协作
周期很长的过程，写过程序的人都知道，如果自己写了不规范的代码，随着自己所写的代码越来越多，到后来需要修改某个前期写的模块时都不知道自己当初是怎么想的了，读自己的代码也需要花很长时间才读懂。
况且如果随着人员的调动等其他原
升级会员 