软件开发的质量保证体系.docx
- 文档编号:5346462
- 上传时间:2022-12-15
- 格式:DOCX
- 页数:19
- 大小:25.03KB
软件开发的质量保证体系.docx
《软件开发的质量保证体系.docx》由会员分享,可在线阅读,更多相关《软件开发的质量保证体系.docx(19页珍藏版)》请在冰豆网上搜索。
软件开发的质量保证体系
软件开发质量保证体系
来自
1.使用范围
2.引用标准
3.定义
4.质量体系框架
4.1管理职责
4.2质量体系
4.3评审
4.4纠正措施
5.质量体系生存周期
5.1合同评审
5.2需方需求规格说明
5.3开发方案
5.4质量方案
5.5设计和实现
5.6测试和确认
5.7验收
5.8复制、交付和安装
5.9维护
软件开发质量保证体系
公司内部标准
本标准参照ISO9000-3?
质量管理和质量保证标准第三局部:
在软件开发、供给和维护中的使用指南?
。
1、使用范围
本标准作为本公司在软件工程开发、供给和维护时的质量要求,以保证产品的质量,防止不合格产品。
以下详细描述了软件开发各阶段的控制手段和要求。
要求质量保证贯穿各个阶段,始终保证严格实施。
2、引用标准
本标准制定考虑本公司的实际情况,因此本标准仅用于本公司内部控制产品质量。
使用本文档时,请尽量参照最新版本。
3、定义
产品:
以下指软件产品,即交付给用户的一整套计算机程序、规程及相关的文档和数据。
开发:
创作软件产品的所有活动。
供方:
指本公司。
需方:
指具体工程的需求方,即客户。
质量体系:
质量要素、各要素需要到达的目标以及在开发过程中必须采取的措施。
4、质量体系框架
4.1管理职责
4.1.1供方(及具体的工程开发组)负责以下职责
组织机构
本公司内部专门设立部门质量保证部门,由部门负责人及专门经过培训的人员组成。
具体工程开发组,设立质量保证组,或委托公司质量保证部门协助开展工作。
质量保证部门负责以下工作:
建立并维护公司内部的质量保证体系。
对可能导致产品不合格的问题予以识别,采取措施予以防止。
发现并记录产品的质量问题。
提出、采取或推荐问题解决方法。
验证解决方法的实施效果。
对不合格产品的处理、交付过程进展控制,确保最终问题得以纠正。
质量保证部门的评审活动应由与被评审工作无直接责任的人员组成。
制定质量方针和质量目标
确保工程组成员均理解质量方针并能坚持贯彻执行。
公司内部制定一般性的质量方针及对软件产品的质量目标,作为各工程组的参照,各工程组可根据具体客户期望及需求作出具体质量目标及质量承诺,具体质量目标及承诺,特别是超出公司目标的局部,提交给质量保证部门,以便提交给质量保证部门充分理解并协助实施。
?
质量方针和质量目标?
见附录
管理评审
质量保证部门负责人应每月对质量体系进展评审,主要是对内部质量审核结果的评定,以保证质量体系持续有效,保存评审记录。
4.1.2需方〔客户〕应负的职责
在工程中,应向需方〔客户〕提出具体要求,明确其需要承当的职责,以便相互配合,共同保证工程的顺利实施。
需方应明确指定工程相关负责人,应具有足够的权力处理以下问题:
向供方提出需求
答复供方提出的某些相关问题
认可供方的提案
与供方签订协议并能确保遵守签订的协议
规定验收准那么和规程
向供方提供必要的信息,提供有利的环境并解决工程中一些障碍。
4.1.3共同评审
双方定期地交流,并联合评审软件是否满足已经商定的需求规格说明书。
4.2质量体系
本质量体系贯穿整个开发周期,是为了在开发过程中保证质量,并非在开发完毕时才检查质量问题,所以重点强调防止问题地发生,问题发生后的纠正仅作为补充手段。
本公司将采取必要手段保证这一体系得以有效地贯彻实施。
质量体系文件
本公司的质量体系文件,包括质量要素、各要素需要到达的目标以及在开发过程中必须采取的措施。
质量体系文件见附录?
质量体系文件?
质量方案
具体工程开发组根据公司质量体系制订质量活动方案并形成?
质量保证方案?
,以保证开发组能正确理解质量体系并能遵照执行。
附录之?
质量保证方案指导?
作为各工程组制订方案的指导。
4.3审核
本公司内部建立全面的审核制度,以验证各具体工程中的质量活动是否符合方案要求,同时检查质量体系的有效性,以不断完善质量体系。
审核过程及采取的措施均要按书面方式进展。
审核结果形成报告,提交审核部门负责人。
对于审核时发现的问题,相关负责人应及时采取措施。
4.4纠正措施
纠正措施必须制定书面规程,应包括以下内容:
调查问题产生的直接原因,并制定防止同类事件发生所需的措施。
查询分析各类过程记录、让步记录、操作记录、质量记录、客户投诉等等,已查明潜在原因并消除
根据风险程度,采取预防措施
对纠正措施的有效实施加以控制
对纠正措施的记录
5.质量体系生存周期
要求各阶段必须有合格的产品〔包括文档〕,并以其作为下一阶段的工作根底。
对每一阶段的产品,必须组织评审,确保其质量,防止错误影响后续工作。
本标准适用于任何生存周期模型。
5.1合同评审
本公司应评审每一合同,以确保:
规定合同的范围和需求并写入文档
识别可能出现的风险
恰当的保护有关的专利信息
解决所有与招标不一致的需求
有能力满足需求
规定其他涉及工程的供货商的责任
统一双方对术语的理解
需方有能力履行合同职责
合同评审记录应妥善保管。
此外,应注意有关质量条款
验收准那么
在开发过程中对需求变更的处理
对验收后出现问题的处理
确定需方的责任,尤其是在需求规格说明、安装和验收时的作用
有需方提供的必要便利条件,如设施、工具和软件等
采用的标准和规程
5.2需方需求规格说明
在某一具体工程进展开发前,本公司应具有一套该工程的完整、准确、无歧义的功能需求,这些需求应包括需方的所有要求。
因为本公司在业务领域具有丰富的经历,可以大力配合客户识别并确定需求,需求在开发前得到需方确实认。
该需求应足以成为产品验收确认时的依据。
在制订需求规格说明时应注意:
双方制定专人负责
需求认可和更改的批准
防止误解,定义好术语,对需求的背景进展说明
记录和评审双方讨论的结果,以备将来查询某些需求确定原因。
5.3开发方案
在工程进展前制定开发方案,作为总体的筹划,指导整个工程有序的进展。
开发方案要求包括以下方面:
工程定义
工程资源组织管理
开发阶段
进度
确定质量保证方案、测试方案、集成方案等
随着工程的进展,开发方案要不断更新,在生命周期模型每一阶段开场之前,都要有该阶段的工作方案,并经过评审后实施。
以下较详细的说明开发方案中应具备的各方面。
A.开发阶段
开发方案应将工程目标转化为最终结果的过程、方法等清楚的描述出来,可以把工作分为几个阶段,比方按照生命周期法划分开发阶段。
开发阶段要确定以下项:
要执行的开发阶段
每一阶段所需的输入
必须用文档方式确定下来,每一项需求均有明确的定义,以保证完成情况可被检验。
每一阶段应产生的输出
验证阶段输出,必须满足以下几点:
满足相应的要求
有明确的验收准那么,作为验收评审的参考。
符合开发惯例和约定
每一阶段需要执行的验证步骤
必须有对每阶段输出的验证方案,并在适当的时间进展验证评审。
分析各阶段可能潜在的问题或需要解决的问题
B.工程管理
工程开发、实施等过程的时间进度安排
进度的控制方法及活动
确定组织机构及其职责、各工作组的资源及工作分配
不同工作组间的组织协调方法,并明确技术接口问题。
C.开发方法和工具
规定工程活动应共同遵循的方法及使用的工具,包括:
开发标准、惯例
开发工具及技术
5.4质量方案
质量方案作为开发方案的一局部。
质量方案随工程进展而更新,质量方案经正式评审,并得到所有与方案执行有关的组织的统一。
质量方案应包含或引用以下内容:
质量目标,尽可能以定量方式给出
定义每一阶段的输入、输出准那么
确定要进展的测试、验证和确认活动的类型和详细方案,包括时间、进度等。
确定具体质量活动的职责:
比方,评审和测试、更改控制、对缺陷的控制和纠正措施。
5.5设计和实现
设计和实现活动是将需求规格说明转化为软件产品的过程。
为保证软件产品的质量,这些活动必须在严格规定的方法下进展,不能依赖于事后的审查监视。
设计
设计阶段要满足各阶段的共同要求,此外,设计阶段还应考虑:
选用适合所开发产品类型的设计方法
总结吸取以往工程的经历教训
设计应考虑软件以后的测试、维护和使用
B.实现
规定编程规那么、编程语言、命名约定、编码和注释规那么等
要求在实现过程中严格遵守既定开发规那么
选用适宜的方法和工具实现产品
本公司内部制定?
开发标准?
,各工程组可参照制定适合特定工程的标准。
C.评审
为使需求规格说明得以满足和上述规那么方法得以实施,必须以评审的方式加以保证。
直到所有被发现的缺陷被消除,或确定缺陷的风险可被控制后,才能进入下一步的设计或实现工作。
各工程组引用公司标准或参照制定的开发标准应在取得本工程组广泛认可的情况下,提交给评审部门,作为评审参照依据。
评审纪录应保存,评审结果可能作为个人及工程组工作成绩评定的参考之一。
5.6测试和确认
要具有完整的测试方案,测试方案要经过评审,并以此为依据进展测试活动。
A.测试方案
包括单元测试方案、集成测试方案、系统测试方案、验收测试方案
制定测试用例、测试数据和预期结果
考虑要进展的测试类型,如:
功能测试、边界测试、性能测试、可用性测试等
描述测试环境、工具以及测试软件
软件产品是否完成的判断准那么
测试所需人员及其要求
B.测试活动
记录发现的问题,指出可能的受影响的其他局部的软件,通知相关负责人员。
确定受影响的其他局部软件,并对其进展重新测试。
评价测试是否适度和适当。
在验收和交付产品前,必须尽可能在类似使用环境中进展确认测试。
5.7验收
当软件产品已经完成,经过内部确认测试,准备好交付后,应要求需方根据合同中的规定原那么判断是否可以进展验收。
对于验收中发现问题的处理方法由双方商定并纳入文档。
具备验收条件后,应制定验收方案并逐步实施。
验收方案应包括:
时间进度
评估规程
软件/硬件环境
验收准那么
5.8复制、交付和安装
制定安装分发方案。
复制
制作好安装程序,复制好必要的拷贝。
准备好该交付的操作手册、用户指南等文档。
交付
交付前应对所交付产品的正确性及完整性进展检验。
安装
就以下方面双方明确商定各自的作用、责任和义务:
时间进度及安排,包括非工作时间及假日的人员安排及工作责任
提供出入便利条件,如通行证等
指定熟练人员的密切配合
提供必要的系统及设备
对每次安装确实认条件需明确规定
对每次安装认可的正式规程
5.9维护
对于软件产品在初次交付及安装后,本公司必须提供的维护应在合同中明确规定。
合同中应明确以下各项的维护期:
程序
数据
规格说明
维护工作一般包括:
问题的解决
接口的调整
功能扩大和性能改良
本公司针对以上维护工作制订完善的维护方案,并严格遵照执行。
具体维护方案见?
维护工作流程?
附录C质量体系文件
包括质量要素、各要素需要到达的目标以及在开发过程中必须采取的措施
质量要求要素定义如下:
正确性在预定环境下,软件满足设计规格说明及用户预期目标的程度。
它要求软件没有错误。
可靠性软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度。
效率为了完成预定功能,软件系统所需的计算机资源的多少。
完整性为了某一目的面保护数据,防止它受到偶然的,或有意的破坏、改动或遗失的能力。
可使用性对于一个软件系统,用户学习、使用软件及为程序准备输入和解释输出所需工作量的大小。
可维护性为满足用户新的要求,或当环境发生了变化,或运行中发现了新的错误时,对一个已投入运行的软件进展相应诊断和修改所需工作量的大小。
可测试性测试软件以确保其能够执行预定功能所需工作量的大小。
灵活性修改或改良一个已投入运行的软件所需工作量的大小。
复用性一个软件〔或软件的局部〕能再次用于其它应用〔该应用的功能与软件或软件部件的所完成功能有联系〕的程度。
在设计开发过程中,必须注意以下要求,以保证软件的质量到达目标。
正确性
软件的功能要满足用户的要求,在预定环境下能够完成预期的功能。
因此,必须明确的了解用户的需求。
在需求确定方面,应通过深刻的理解电信企业的运营系统及了解其开展趋势,建立模型并分析,广泛了解其他系统的特长,并总结以往的经历教训的根底上,确定出需求并通过与用户的交流最终确定。
在需求的表达方面,强调以全面、准确、细致、易于理解的方式表达,可能需要以多种形式,比方:
功能描述、数据描述、数据流图、系统说明等。
可维护性
遵从统一的标准,包括命名标准、界面标准、编程风格。
编码应具有良好的可读性,注释完整清晰。
防止复杂的逻辑判断条件,易读,易测试
编码应尽量简练,逻辑简单
保存异常信息与错误日志以便于调试与分析
降低模块之间的耦合度,增强模块内的内聚。
可用性
用户容易理解和使用该功能
响应时间快,操作方便,提高用户工作效率。
提示信息简洁准确
可靠性
具有异常捕获功能并提供异常处理与恢复功能
5、效率
尽量降低系统资源的开销
查询语句要充分考虑到索引
减少与数据库的不必要的交互
灵活性,易于扩展
充分考虑到各地的不同的环境,通过参数设置使其易于适应不同的要求。
完整性、平安性
保证相关的数据一致性
考虑数据的存取权限。
文档完善
按文档要求完成相关文档。
审查制度
对于每一阶段的文档及软件产品都应交付证质量保证部门,由审查小组按质量要求严格审查。
审查内容:
文档:
开发方案、用户需求规格说明、概要及详细设计文档、技术文档、用户手册等,详细要求见文档方案。
评审文档是否标准,表达清晰,有实用价值。
设计方案:
是否到达设计目标。
应用程序:
是否到达质量目标和符合设计目标。
审查流程:
工程组按方案准备好交付的产品及文档
交付质量保证部门,组织评审
完成评审,发现错误报告
发现错误的返工
复查返工问题是否已解决
有话要说 打印 保存 关闭
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 质量保证 体系