EPIGS质量保证计划.docx
- 文档编号:10166560
- 上传时间:2023-02-09
- 格式:DOCX
- 页数:22
- 大小:41.47KB
EPIGS质量保证计划.docx
《EPIGS质量保证计划.docx》由会员分享,可在线阅读,更多相关《EPIGS质量保证计划.docx(22页珍藏版)》请在冰豆网上搜索。
EPIGS质量保证计划
EPIGS质量保证计划
SE_QA_PLAN_EPIGS
历史记录(History)
修改历史记录(Modification)
序号
日期
修改情况
版本号
签字
校阅历史记录(Revise)
序号
日期
校阅情况
签字
批准历史记录(Authorization)
序号
日期
批准情况
签字
公司软件质量保证计划
1.0范围(Scope)
此软件质量保证计划描述了在开发计算机软件和EPIGS的相关文档的开发中,公司软件质量保证(SQA)部门人员须遵守的软件质量过程。
这项计划适用于已开发的软件和对用户产品的全面开发所必要的支持软件。
负责执行该计划的人员即质量保证(QA)工程师。
工作中所有由EPIGS的工作陈述明确了的质量要求都在这个计划中作了阐述,并由QA人员执行。
此计划以立约人格式准备,此文档内容是根据公司为开发类似项目而执行SQA功能的上一次经验为基础的。
本计划提供了EPIGS中SQA工作量的依据,将每月评估一次直到系统测试完成,且只要项目结构或进度有重大变化也要进行评估。
1.1目的(goals)
SQA计划的目的是对EPIGS提供SQA过程的具体项目执行信息。
1.2与其他计划的关系(RelationshipstoOtherPlans)
此项SQA计划与EPIGS开发的其他管理计划相协调。
这些计划包括:
●需求管理的各项计划
●项目管理和开发计划
●风险管理计划
●项目软件配置管理计划
由于软件配置管理与SQA之间具有密切的相互作用,所以将对SCM计划和QA计划之间的一致性进行仔细检查。
2.0SQA过程框架(SQAProgramFramework)
SQA计划中的这个部分描述了关于公司中SQA过程的在EPIGS上的实施。
此部分中的有关SQA具体项目有:
●资源
●组织
●计划估算
●进度
●跟踪
●工具和方法
●度量
●培训
●特定审核
用户在SQA过程中是一个重要的参与者,将告知其有关评估的时间和地点。
项目程序质量经理通知来安排客户观察员在软件质量评估活动中的参与。
用户质量代表具有无须通知就可监控和审核QA活动的自由。
2.1SQA的程序与过程(SQAProgramandProcess)
为确保软件和相关产品符合合同要求,SQA程序和过程由必要的过程、方法和组织资源组成。
该项目在包括软件生命周期的需求分析、设计、编码、测试和安装以及检查等阶段中执行为QA事务,同时也考虑了在检验和操作过程中的维护活动。
Notes中的数据库产品后期测试数据库及项目跟踪与工作报告数据库是用来文档化在软件开发中所需的事件、产品、测试和媒体的状态与通过情况的。
SQA计划中要求由QA实施的所有评审结果都通过邮件群发的方式分发给软件经理、程序质量经理、项目经理以及被评估区域相应的负责人。
具体评审过程可参考Notes中的数据库产品后期测试数据库及项目跟踪与工作报告数据库。
2.1.1资源(Resources)
软件开发资源同QA部门资源一样,是在软件开发过程中用来完成质量活动的。
这些资源由计算机设备、软件工具和支持项目组成。
为了使QA人员监控和评估软件开发过程,他们必须掌握并有权使用用作软件需求分析和设计、需求可跟踪性、配置管理和自动测试的软件开发工具。
这些活动使用的工具或方法都在此计划中作了描述。
在开发过程中,QA人员将获得可以访问开发系统的所有信息/产品的帐号。
QA可用的计算机设备包括一部连入局域网的个人电脑。
这些资源可用于记录评估,需要时为管理和用户准备状态报告和陈述,也可用于在公司内部网上访问开发项目数据。
主要使用的软件工具有Word文字处理软件、Notes办公系统软件等从过程资源或公司网上可以获得的工具。
2.1.2SQA记录(SQARecords)
记录是由在此计划中文档化所有评估的QA维护的,这些记录提供了客观依据,并使得实施于整个软件开发中的操作具有可跟踪性。
是否满足所有质量需求的依据要根据此计划中所描述的频率,由在软件开发过程中所执行的评审来证明。
这些记录保存在Notes数据库中,并可用于用户评审。
记录要在EPIGS结束后在记录库中保存至少两年。
由QA执行并维护质量报告系统,并文档化状态、结果和软件开发的进展。
由系统产生的报告要以事件驱动方式通过Notes邮件群发方式分发给程序质量经理和QA经理。
这些以总结和可应用的形式产生的报告的内容包括以下信息:
●评估及其结果
●变更控制活动
●问题汇报
●测试进度及其结果
●偏差状态
2.1.3组织结构(OrganizationalStructure)
SQA与EPIGS软件开发组织中的活动的相关性见图2.1.3-1。
在整个机构中,项目经理对与项目管理有关的所有事件负有最终责任。
产品经理负责确保软件及相关产品符合合同要求。
他责成QA人员向项目经理提供软件质量活动的状态报告,确认问题区域,并建议必要的纠正行动。
构筑公司的质量组织,使过程质量功能有一条独立的命令链。
这条命令链完全独立于项目管理和其他负责软件开发的功能组。
由于任何其他功能组都没有直接管理质量组织活动的权力,所以允许QA人员拥有必要的组织自由来发出纠正动作、推荐和提供能够纠正或改进软件开发领域的方法、并确保完成纠正动作。
QA人员直接向EPIGS的产品经理做报告并且负责执行和维护软件质量过程。
图2.1.3-1
2.1.4SQA系统(SQASystem)
公司开发和执行了一套软件质量评估过程,使得用户对提交满足合同要求的软件产品具有信心。
这些过程涉及到作为QA评估的一部分并且是为EPIGS的独特需要而定制的检查表。
这些过程是由SQA的软件工程过程组来维护的。
2.1.5SQA对项目管理和计划的服从(SQACompliancetoSPMandPlans)
SQA过程的一个必要方面是确保软件活动和产品遵循项目管理并与软件计划一致。
2.2SQA计划、进度和跟踪(SQAPlanning,SchedulingandTracking)
2.2.1SQA计划(SQAPlanning)
2.1.3部分所描述的SQA组织负责执行项目的SQA计划。
项目质量经理评估此SQA计划并签署批准。
2.2.2估算(Estimates)
向项目经理和软件经理提供为EPIGS所作的SQA估算。
合适的话,对全体人员所需资金、设备及进度做SQA估算。
2.3SQA工具、技术、方法和测量(SQATools,Techniques,MethodsandMeasures)
QA使用的主要工具是Notes数据库管理方式。
QA能够更新不一致的评估记录并跟踪其状态直至结束。
项目允许由不同类别来报告各项内容并提醒QA提供需要后续报道的评估。
在QA评估软件过程后,根据是否一致分类指出过程的以下评估:
一致:
过程完整、正确,符合已制定的接收标准。
不一致:
过程不符合需求。
2.4培训(Training)
由具有以下普通资格的QA人员执行SQA任务:
●技术学位(计算机科学、工程或数学与项目相关专业科学)
●标准知识(SEI软件-CMM版本1.1等)
●内部的软件过程手册(如:
项目管理文档)知识。
对于那些执行EPIGS的QA活动的人员将提供以上所列的达到最低QA人员要求的培训。
QA参与评估关于EPIGS的软件工程工具和方法,这其中也需要培训。
保存这些培训课程的记录。
为EPIGS软件工程人员执行一个全面SQA定位会议,并且保存会议记录。
2.5审核(Audits)
公司的SQA需要一个SQA系统年度审核与一个软件项目的管理系统内部审核(MSIA)。
2.5.1审核SQA系统(AuditSQASystem)
SQA系统不仅适用于客户审核同样也适用于由软件过程组织进行的年度内审。
这项服务为SQA系统的持续过程改善指明了方向。
2.5.2审核软件项目(AuditSoftwareProject)
不断增加的软件工程记录文件服从年度评估以及QA和SPG的评估。
这些已经计划好的年度MSIA将SQA部门人员和SPG人员聚在一处重新关注EPIGS。
根据需要编写审核报告以及采取纠正动作。
3.0SQA评审(SQAEVALUATIONS)
在软件开发过程中执行的SQA活动用于评估软件、其相关文档及软件开发过程的。
由QA执行的活动与主要里程碑和/或为开发过程的每个阶段所计划的活动直接相关。
EPIGS的软件开发周期包括以下阶段:
●<需求分析>
●<概要设计>
●<详细设计>
●<编码与单元测试>
●<集成与测试>
●<系统测试>
标准开发活动有:
●方法及工具的选择
●执行分析
●软件需求分析
●软件概要设计
●软件详细设计
●编码及单元测试
●软件集成及测试
●系统集成及测试
●安装及检验
●维护及运作
运用计划中制定的质量评估标准,QA监控这些开发活动以保持与项目计划的一致性,评估已生产的软件产品,并参与软件开发的技术评估。
每个子系统可能处于不同的进度,因此必须独立运作由QA为每个子系统执行的活动。
3.1SQA任务/评审(SQATasks/Evaluations)
QA所要求的任务列入表3.1-1,附有关于活动的简短描述。
为了确保所有的软件文档符合用户的需求,QA将进行以下活动:
表3.1-1任务/评估
评估
对象
需求评估
确定任何问题需求
技术评估
用软件工程评估软件开发产品
单元测试
确保根据项目计划执行测试
集成测试
确保测试案例和根据项目计划对它们进行实施
SCM过程
确保活动执行与SCMP和SCM的指示一致
软件开发库(SDL)
确保软件产品的控制和维护与SCMP一致
纠正动作
确保报告、跟踪和解决了所有软件问题
代码评估
确保服从项目计划中的代码标准
3.2软件项目管理(SoftwareProjectManagement)
3.2.1软件计划(SoftwarePlanning)
QA与软件工程相协调并评估包含完整软件计划的项目计划;QA还要确保项目计划服从配置控制。
评估的执行要确保项目计划充分达到SOW的目的和意向以及项目计划是可行的。
部分评估涉及决定选择已经通过评估并用于执行任务的工具和设备。
3.2.2软件跟踪及监控(SoftwareTrackingandOversight)
QA确保EPIGS中软件活动、工作产品、工作量、成本、进度,关键计算机资源及IPT过程是根据项目计划来管理的。
3.2.2.1软件活动(SoftwareActivities)
EPIGS软件开发活动已列入3.0部分中。
QA确保软件机构执行软件活动并写出适当的过程评估表。
3.2.2.2软件工作产品(SoftwareWorkProducts)
EPIGS的软件工作产品已列入项目计划中。
QA确保软件机构生产软件工作产品并写出适当的产品评估表。
3.2.2.3软件工作量(SoftwareEffort)
EPIGS软件经理负责进行软件时间消耗跟踪和发生异常时采取纠正动作。
QA确保项目跟踪及监控的执行并写出软件跟踪及监督过程评估表。
3.2.2.4软件成本(SoftwareCost)
EPIGS软件经理负责进行软件费用消耗跟踪和发生异常时采取纠正动作。
QA确保项目跟踪及监督动作的执行并写出软件跟踪及监督过程评估表。
3.2.2.5软件进度(SoftwareSchedule)
EPIGS软件经理负责进行所用软件进度的跟踪和进度减退时采取纠正动作。
QA确保项目跟踪及监督动作的执行并写出软件跟踪及监督过程评估表。
3.2.2.6关键计算机资源(CriticalComputerResources)
EPIGS软件经理负责进行所用关键计算机资源的跟踪和资源流失时采取纠正动作。
QA确保项目跟踪及监督动作的执行并写出软件跟踪及监督过程评估表。
3.2.3风险管理(RiskManagement)
QA监控EPIGS的风险管理过程是否符合项目计划。
由软件工程所做的初始评估用来确认和评定基于特定项目目标、进度和成本的软件风险。
QA确保用报告已确认风险区域状态的软件管理指示器对项目计划中所列的风险区域进行监控。
在软件工程所产生的报告以外,QA确认在对软件开发过程和结果产品的审核及评估中发现的任何风险区域。
向项目管理者报告已确认风险的影响以便运用适当的控制和资源减小风险。
由QA来评估项目计划中所提到的风险区域软件管理指示器以确保它们周期性地更新以及一旦确认风险指示器则马上采取减小风险的措施。
3.2.4软件度量(SoftwareMetrics)
EPIGS收集的软件度量在项目的项目计划/设计中定义。
QA确保这些度量的完整、准确和及时。
同时也确保软件度量在管理此软件计划中的运用。
3.3需求(Requirements)
3.3.1软件需求分析(SoftwareRequirementsAnalysis)
QA评估执行软件需求分析的过程和收集需求的方法的有效性以使之在开发中可持续运用。
QA评估一项软件需求技术评估的准备情况并参与此评估。
由QA为软件需求分析所评估的软件产品和计划如下:
●针对每个子系统的初期软件需求说明
●项目计划
QA为系统/部分、主要项或关键项规范需求的软件需求跟踪而评估初期软件需求说明。
这些评估既确保了界面需求与界面元素规范的一致性又确保了初期软件需求规范间的一致性。
QA同时还确保软件功能、执行和界面需求的可测试性是得到验证了的。
3.3.2需求管理(RequirementsManagement)
在项目计划中的需求管理计划已为EPIGS的需求策略进行了定义。
QA保证为EPIGS确定需求经理。
当执行需求活动时,QA会每个月评估一次需求管理;继需求分析活动之后,QA会每两个月评估一次需求管理。
3.4设计(Design)
3.4.1软件体系设计(SoftwareArchitectureDesign)
QA为保持与项目计划一致而监控开发工作量;参与软件体系设计与测试计划的内部评估,并评估设计技术评估的就绪状况。
在软件结构设计过程中由QA评估的软件产品包括:
●每个子系统的初期软件设计文档
●初期软件测试计划
●最终软件需求说明
QA将针对每个子系统的软件需求的可跟踪性,以合适的设计技术与适当的细化程度来评估发展中的设计文档和初期软件设计文档。
为保证软件需求充分测试的全面性,与软件开发计划的一致性及测试计划的充分性需对初期软件计划进行评估。
QA将检查系统测试计划以防止软件测试计划与前者之间的不一致。
为保证对意见和技术更新的响应将对最终软件需求说明进行评估。
3.4.2软件详细设计(SoftwareDetailedDesign)
为了与项目计划保持一致,QA继续监控开发工作量、参与内部设计和测试描述评估,并评价最终设计技术评估的就绪状况。
QA为软件详细设计而评估的软件产品包括:
●非正式单元测试案例
●非正式集成测试案例
●针对每个功能软件水平的SDF
●每个子系统的发展中的软件设计文档
●每个子系统的初期界面设计文档
●初期软件测试过程
●最终软件测试计划
在软件详细设计过程中,QA对用详细设计信息更新的动态软件设计文档进行评估,并为了跟踪软件需求说明和初期设计文档而对界面设计进行评估。
QA还要确保合理设计技术的运用及文档间的一致性。
为跟踪软件测试计划、保证软件需求的全面测试范围以及与设计文档的保持一致性,需要评估初期软件测试过程、单元测试案例和集成测试案例。
为保证对意见和技术更新的响应的充分性,还需要对最终软件测试计划进行评估。
为了保证及时合理的估算、单元需求、设计考虑与规范以及确保进度及状态信息的准确性,保证对项目计划的服从,还需要评估软件开发文件样本/模板。
为了达到需求测试范围的完整性和充分性需要对SDF中的单元测试案例和集成测试案例进行评估。
3.5软件执行(SoftwareImplementation)
3.5.1代码和单元测试(CodeandUnitTest)
QA需根据表3.1-1评估代码样本来决定代码是否与项目计划一致。
在正式测试开始后QA将核对所有代码变更以确保处理了所有已核准的AR以及只包括了每个已核准项的变更。
除评估文档外,QA还要监控开发工作量以保持与项目计划的一致性。
在代码测试和单元测试过程中QA对软件产品的评估包括:
●源代码列表
●单元测试结果
●非正式集成测试过程
●最终软件设计文档
●最终界面设计文档
为了跟踪单元测试计划和单元测试案例QA还要评估单元测试过程和单元测试结果。
当一个单元测试成功后便将其加入开发基线。
为了跟踪测试计划和案例、保证软件需求测试范围的充分性及与设计文档保持一致性,需对信息集成测试过程和最新测试过程进行。
在此阶段为保证对意见和技术更新的响应的充分性,需要对最终软件设计文档和界面设计文档进行评估。
3.5.2技术评估(TechnicalReviews)
技术评估是软件开发的里程碑,为软件产品的评估与核准会进行软件开发产品的内部展示。
合适的情况下可邀请客户参与EPIGS的内部评估。
QA会对以下段落中详细说明的为每项评估而执行的计划和动作进行评价,以确认需求的所有产品已为进一步开发做好准备。
执行对系统设计的评估,来评价系统需求的优化、可跟踪性、相互关系、完整性及系统需求中的风险,系统需求包括实现系统/部分需求中相应的测试需求。
评估包括软件在内的总的系统需求。
执行对软件体系的评估,来评价软件需求的充分性。
在设计技术评估开始前,QA按更高水平的规范评估软件需求的可跟踪性;评估软件功能、性能、界面需求的可测试性,以及对EPIGS的合同需求的支持性。
来源于初期软件计划设计工作量和初期软件测试计划的初期软件设计文档和界面设计文档是运用主要子系统设计的最初技术评估来评估的。
QA确保设计技术的评估为每个子系统覆盖了软件需求、适当设计技术的运用和适当的详细程度。
基于这些评估,QA将评估项目的就绪状况,以进行软件详细设计,并通知项目经理新的发现。
连续的设计技术评估使每个子系统的详细设计在编码创建前生效。
在每项设计技术的基础上评估合适的最新设计和测试文档以确保由先前的分析和最初设计工作量来定位的功能适当地在最终设计中得到阐述。
设计技术评估的主要目的是为了确保每项最新软件和界面设计文档支持每个子系统的前期已核准文档并与其保持一致。
在设计技术评估中,为了跟踪软件需求说明和初期设计文档,QA需要评估最新设计和测试文档、合理设计技术的运用,以及文档间的一致性。
QA还要根据每份支持文档的目的来评估它们的完整性和准确性。
3.5.3非提交软件(Non-deliverableSoftware)
当项目计划中的非提交软件用于主要任务软件开发过程时,要对其进行确认,包括它的分析、设计、编码、控制和测试。
将此软件用于测试是很普通的。
这种软件并没有设计为子模块/系统。
必须对非提交软件执行预期目的的能力进行设定及验证。
SCM人员负责维护已开发的非提交软件并保护它们不受任何XX的变更。
QA确保已开发的非提交软件在项目软件库中得到确认及维护、确保对此软件的变更由SCCB文档化和评估、并确保只使用已核准的版本。
QA还须评估项目计划的SCM部分以确保此类软件的控制过程遵循为已开发的可提交软件建立的通用配置控制过程。
QA将验证用于开发操作软件或直接支持接受测试的已开发的非提交软件。
为了充分符合性能说明须对已开发的非提交软件的测试进行评估。
QA见证此软件的验证并文档化QA产品评估表的结果。
包括性能说明、测试过程及评估表的验证包将提交给项目库并用于客户评估。
3.6测试(Test)
3.6.1测试水平(LevelsofTest)
对合同中所提供的全部软件都要进行软件测试。
QA确保计算机软件测试和文档化与项目计划一致,并且所有的测试和数据都是完整的,正确的,可跟踪的,可重复的和可接受的。
通过这些活动方式,QA保证软件满足其技术和操作需求。
在接受测试开始之前,进行与项目计划相一致的非正式单元水平和集成测试。
对于每个单元,软件工程组负责一个SDF的全部条目,SDF中包括对每个特定的单元设计的功能/性能需求的描述,以及对进行的每项测试的目标、所涉及的测试步骤,测试结果,及每个测试的日期的描述。
对SDF的维护将包括对已设计的性能/功能需求的描述,以及对进行每项测试的目标,所涉及的测试步骤,测试结果,及每个测试进行的日期的描述。
QA同时监控单元和集成测试。
对单元和功能软件元素的非正规测试计划、过程及结果都要进行评估。
(见表3.1-1)
正规软件测试使用客户认可的软件测试计划和合同中确定的软件测试过程。
正规软件测试的结果在软件测试报告中文档化并提交给客户进行评估和认可。
所有的正规测试都可能由客户或经授权的代表见证。
为每个子系统进行的正规测试将与软件测试计划保持一致。
在正规测试中,观察员将遵照项目计划文档化所有出现的错误。
SCCB将对软件问题进行评估以决定重新测试的范围。
任何不需要重新测试的问题将注释作此决定的原因。
客户对软件和正规测试文档具有认可权。
3.6.1.1软件集成测试(SoftwareIntegrationTesting)
除评估文档外,QA还为与项目计划一致而监控开发工作量。
QA监控集成测试、参与附加代码的内部评估、并判定进行正规测试的就绪状况。
在软件集成与测试中QA对软件产品的评估包括以下几项:
●<源代码列表>
●<非正规集成测试过程和结果>
●<更新的SDF>
●<最终子系统软件测试过程>
评估更新的源代码对代码标准的服从性以及与更新的设计文档的一致性。
QA为追踪测试过程而评估SDF和集成测试的非正规测试结果。
在成功执行了所有的集成测试后,集成的各子系统准备接受正规测试。
为了追踪最新的软件测试计划、软件需求的充分测试范围、与设计文档的一致性、以及客户评估的适当合并,要对最终文档进行核查。
QA确保测试结果和需求确认的完整正确的报告得以维护。
子系统测试中QA对软件产品得评估包括以下几项:
●<源代码列表>
●<初期的软件测试报告>
●<更新的软件设计文档、界面设计文档>
QA见证子系统测试以保证它是用当前的代码控制版本的执行的;保证它的执行符合核准的测试计划和过程;保证它产生正确的结果;并保证它包括所有必要的重新测试。
在子系统测试的完成过程中,为了追踪子系统测试计划和测试结果,QA对初期的软件测试报告进行评估。
在这个评估的基础上,QA确定子系统是否满足它的特定需求。
为追踪软件需求规范和保持彼此的一致性,QA评估软件和界面设计文档的所有变更。
3.6.1.2系统集成测试(SystemIntegrationTesting)
继子系统测试之后,为了证明当子系统与联合配置项结合时子系统执行并达到合同需求的可能的最大范围,将进行作为非正规系统水平测试系列的硬件-软件集成测试。
全部系统测试将遵循HSIT(Hardware-SoftwareIntegrationTesting)。
QA将评估每个软件创建,这些软件创建是为系统水平测试、变更控制过程和代码的配置管理而开发的。
在HSIT中由QA评估的软件产品将包
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- EPIGS 质量保证 计划