软件质量保证过程(SQA)实施过程.docx
- 文档编号:86933
- 上传时间:2022-10-02
- 格式:DOCX
- 页数:14
- 大小:143.67KB
软件质量保证过程(SQA)实施过程.docx
《软件质量保证过程(SQA)实施过程.docx》由会员分享,可在线阅读,更多相关《软件质量保证过程(SQA)实施过程.docx(14页珍藏版)》请在冰豆网上搜索。
软件质量保证过程
软件质量保证过程作为一种独产的审查活动贯穿于整个软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其主要职责是:
检查开发和管理活动是否与制定的过程策略、标准和流程一致;检查工作产品是否遵循模板规定的内容和格式。
此文档从软件开发过程的各个阶段来描述软件质量保证过程。
1.计划阶段
目的和范围:
项目计划过程的目的是计划并执行一系列必要的活动,以便在不超出项目预算和日程安排的前提下,将优质的产品交付给客户。
项目计划过程适用于公司的所有项目,但每个项目可以根据各自的不同情况对该过程进行裁剪。
进入标准:
■项目启动会议已经结束;
■在项目的生命周期中,根据项目的跟踪结果,需要对项目计划进行修改和完善。
输入:
■项目启动报告;
■项目提案书;
■项目相关文档;
■组织财富库中以往类似的经验文档。
退出标准:
项目计划已通过评审、批准并确立。
输出:
评审后的项目计划文档包括:
■软件开发质量计划;
■软件配置管理计划。
过程描述:
项目计划包含3个需要在项目中执行和管理的主要计划,如下:
■软件项目管理计划;
■软件项目质量管理计划;
■软件配置管理计划。
软件项目管理计划涉及项目中所有与项目管理相关的问题(从项目开始到结束)o
软件项目质量管理计划涉及与质量相关的需求,这些需要在产品中实现,并保证用于构筑产品的项目过程。
由于质量是产品创建的一部分,所以将软件项目管理计划和软件项目质量管理计划合成一个计划文档,称为软件开发质量计划。
软件配置管理计划用于管理与配置管理相关的需求,这些需求与工作产品和可交付产品有关。
该计划的目的在于:
为执行软件工程相关活动提供依据,并在整个开发和维护过程中对软件项目进行管理。
可以使用不同的检查表来制定软件开发质量计划和软件配置管理计划。
如下每个计划都将包含以下3点:
■目标;
■执行方法;
■当前状态。
前两点不会经常变更,但第三点则被认为会在执行跟踪时被修改。
因此,前两点通常被直接放到计划中,而第三点则以链接的方法放到计划中。
(1)制订软件开发质量计划
软件开发质量计划包括软件项目管理计划、软件项目质量管理计划。
①制订软件项目管理计划
软件项目管理计划的主要内容包括基础设施计划,进度计划(包括各种类型的估算)、风险管理计划、项目培训计划、执行计划、客户管理计划。
■基础设施计划
基础设施计划包括项目开始执行前必须到位的所有需求,它需要解决以下问题:
软件工程需求、基础设施需求、角色和职责、内外部接口、过程需求、知识和技能需求。
■进度计划
进度计划涉及制定合理可用的项目进度。
在制定项目进度时,需要进行下面的估算:
规模(Size)、工作量(effort)。
项目进度需要描述以下内容:
执行的活动、估算的人时、投入的人员、责任人和时间线、里程碑事件的标识。
■风险管理计划
风险管理包括:
标识风险事件(与管理相关的风险、与执行相关的风险,与客户相关的风险等)、评估风险并设定风险优先级、制订风险缓解和应急计划并跟踪该计划。
■项目培训计划
根据项目及人员结构制订项目培训计划,包括业务领域知识、技术、工具等方面的培训计划。
■执行计划
项目执行计划包含了与执行当前项目关系最大的生命周期模型。
该计划对组织级执行模型进行了裁剪。
项目生命周期模型通常包括:
项目执行的阶段、各阶段的输入和输出、可交付的产品、需要迭代(反复)的阶段。
②制订软件项目质量管理计划
制订软件项目质量管理计划包含如下主要内容:
■项目设定的质量标准;
■同级评审计划:
同级评审计划中描述了在不同的软件生命周期开发阶段,对不同的工作产品所采用的同级评审类型;
■测试计划:
测试计划包括对可执行文件/模块或整个系统将要进行的各种测试。
根据项目测试过程来制定测试计划;
■度量管理计划:
通过裁剪组织级的度量过程来制定项目度量管理计划。
■缺陷预防计划:
管理、开发和测试人员互相配合制订缺陷预防计划,防止已识别的缺陷再次发生;
■过程改进计划:
项目级过程改进的机会要记录到过程改进计划中。
这些机会主要来源于度量分析、缺陷预防分析和标识出的好的或可避免的实践。
(2)制订软件配置管理计划
软件配置管理计划主要包括以下内容:
■软件配置管理计划组织;
■角色和职责;
■开发/维护配置管理计划,包括可配置项的标识、命名约定、目录结构、访问控制、变更管理、基线库创建、放入/提取(Checkin/Checkout)机制、版本控制;
■产品配置管理,包括产品中部件的可跟踪性,产品的版本设定和发布、交付的配置管理(标识出要交付的产品构成)、需求配置管理(需求基线的确定、产品版本与划定基线的需求版本之间的关系)、配置审计。
验证:
同级评审人员和软件质量保证人员必须对项目计划进行评审,批准后项目才能付诸实施。
配置控制:
项目经理保管所有项目计划文档。
对所有项目计划文档都要进行配置管理。
项目结束后,所有的项目计划文档都要保存到组织财富库中,仍受配置控制。
QA检查清单:
QA检查清单包括:
■软件开发质量计划;
■软件配置管理计划。
该阶段要确保制定了软件开发质量计划和软件配置管理计划。
2.需求分析阶段
目的和范围:
需求说明和需求管理过程的目的是为了保证开发组在开发期间对项目目标和生产出最后产品的目的有一个清晰的理解。
软件需求规格说明书将作为产品测试和验证是否适合需要的基础。
对于需求的变更,它可能在开发项目期间的任何时间点发生,需求的变更将要影响日程和承诺的变化,这些变化需要和客户所提出的要求相一致。
进入标准:
■计划已经被批准,并且项目整体的基础设施是可用的;
■软件的需求已经被需求收集小组捕获;
■对已经形成了基线的软件需求规格说明书有变更的请求时。
输入:
■软件的需求说明书;
■变更需求的请求。
退出标准:
■软件需求规格说明书已经经过评审并形成了基线;
■对已经形成基线的软件需求的变更进行了处理;
■形成基线的软件说明书已经经过客户批准;
■验收标准已经完成;
■所有评审的问题都已经解决。
输出:
■经过批准并形成基线的软件需求规格说明书;
■对受影响组件的重新估算文档;
■验收测试标准和测试计划。
过程描述:
这个过程主要处理以下两种活动:
需求说明和需求管理。
需求说明指的是需求过程中形成基线的主体,它是以后进一步的设计和测试的基础。
另外,在软件开发过程中,会经常遇到由于客户又有新需求或开发组自身对项目有了更清楚的理解或认识,要对需求进行变更。
在对最初的需求说明书进行变更时,要用到需求管理过程。
(1)需求说明
需求说明过程主要包括以下任务:
■执行需求分析
■定义需求规格说明书
■定义验收标准
■评审说明书和验收标准。
①执行需求分析
分析收集到的需求和在提案中可用的需求。
这个任务要求需求说明书应该在完整性、一致性、清晰性和可测试性上达到比较合理的程序。
②定义需求说明书
基于对需求的分析编写软件需求规格说明书。
这个文档应清晰记录以下内容:
■目标和范围;
■功能需求;
■用户接口;
■输入输出;
■模块之间的接口;
■性能需求;
■特殊用户需求。
如果需求不清晰或模糊,就需要准备原型,通过评估原型来产生需求说明书。
③定义验收标准
基于对以前步骤收集的需求规格说明书,建立测试标准,验证的解决方案。
所有的需求应该可能制定测试标准。
这个测试标准将成为客户批准最终产品的依据,因此要求在制定客户标准时要经常紧密的与客户进行交流沟通。
④评审需求分析说明书和测试标准
因为是开发项目的基础,所以需求规格说明书和验收标准需要由项目组的同级人员进行评审。
(2)需求管理
需求管理过程包括以下6个任务:
■记录变更请求;
■分析受到影响的组件;
■估算需求变更成本;
■重新估算所有产品的交付日期和时间;
■评审受影响组件;
■获得客户的批准。
①记录变更请求;
形成基线的需求说明书的变更可能是由客户提出的,也可能是由于设计或编码阶段开发人员根据一些限制或优化而提出的。
所有需求变更必须经过客户的批准,并且必须是可行的。
任务需求变更可以由组织自己定义开始时间,并且所有需求变更需要记录到变更登记表中。
②分析受到影响的组件;
任何经过批准的变更需要在整个项目组范围内进行受影响组件分析。
③估算需求变更成本;
项目成本与需求变更有关。
任何规模的变更对于成本来讲都是一种损耗。
如果一个受影响组件是非常重要的,那么可行性需要重新进行成本估算。
④重新估算所有产品的交付日期和时间;
如果没有考虑有效的缓冲,成本的变化可能会影响整个项目的交付时间。
在交付时间内的任何实质的变更都需要再同用户商议决定。
⑤评审受影响组件;
在这个步骤中所有相关的受影响组件需要进行评审,项目负责人根执行此项任务。
⑥获得客户的批准。
这个过程的最后一项任务是获得客户的签字。
客户应该同意已经形成基线的软件需求说明书、验收标准和已记录的受影响组件的变更。
验证:
■项目经理要定期的检查需求规格说明书和项目需求管理的各个方面;
■软件质量保证人员要定期的对需求分析过程执行独立的评估。
配置控制:
■软件需求规格说明书需要严格的配置控制;
■所有的变更请求需要被管理和控制;
■用于跟踪的度量文档需要管理和控制。
QA检查清单:
质量保证检查清单包括:
■软件需求规格说明书;
■变更需求跟踪记录;
■验收测试标准与测试计划。
该阶段要确保客户提出的需求是可行的,确保客户了解自己提出的需求的含义,并且这个需求能够真正达到他们的目标,确保开发人员和客户对于需求没有误解或误会,确保按照需求实现的软件系统能够满足客户提出的需求。
3.设计阶段
目的和范围:
本过程所关注的是把需求(用户需求说明书和软件需求规格说明书)转变成为如何实现这些需求的描述。
主要包括以下两个阶段:
■概要设计;
■详细设计。
软件设计过程主要包括以下活动:
■体系结构设计;
■运算方法设计;
■类/函数/数据结构设计;
■建立测试标准。
进入标准:
■产品需求已经形成了基线;
■需要设计解决方案;
■新的或修改的需求需要改变当前的设计。
输入:
■形成基线的需求(用户需求说明书和软件需求规格说明书)。
退出标准:
■设计文档已经评审并形成基线;
■测试标准、测试计划可行。
输出:
■概要设计文档;
■详细设计文档;
■测试计划;
■项目标准;
■选择的工具。
过程描述:
设计过程包括概要设计和详细设计两个阶段。
(1)概要设计
这个阶段包括以下的任务:
结构设计、逻辑设计、项目标准定义、系统/集成测试计划的创建,并要进行同级评审。
概要设计模板、系统/集成测试计划模板在本阶段将被使用。
①结构设计
在这个步骤中,完成软件解决方案的基础布局设计。
继软件布局设计之后,应用程序被分解成基础模块/组件,目的是为了实现在模块内的高聚合和模块之间的松耦合。
通常情况下,模块的划分是基于概要设计中的功能需求而定的。
②运算方法设计
在这个步骤中,完成软件系统解决方案与应用程序的转换逻辑设计。
设计模块接口和应用需求的主要逻辑。
在决定通用算法之前,通常需要一些模型。
③定义项目标准
在这个步骤中,所有的项目开发标准被定义。
详细设计/编码标准要同实际执行的一致。
制定标准时还要考虑标准将来的扩展性、灵活性和方便性。
④创建系统/集成测试计划
基于对概要设计的理解,系统和集成测试计划被制定出来。
验证最后生产的产品达到了设计要求,通常采用基于黑盒的功能或
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 质量保证 过程 SQA 实施