l 对过程的一致理解;
l 员工对过程的有效应用。
b) 质量保证人员通过对过程执行进行持续的支持和监控,来推动项目组、支持部门对质量系统的正确理解和成功实施。 本文描述了在项目组整个生命周期中QA对项目组的支持活动,以强化QA的作用。

缩写
定义
NC
Non-Compliances
不符合项
PM
Project Manager
项目经理
SEPG
Software engineering process group
软件工程过程组
RCA
Root cause analysis
根本原因分析
QA
Quality Assurance
质量保证人员
CMO
Configure management operator
配置管理员
3 范围本指南对定义在《QA-2-01 过程和产品质量保证流程》中的QA角色和职责进行了详尽的阐述。
建议所有QA利用本指南为项目组提供支持,并通报项目组与业务部门的违规行为。
4 指南4.1 QA的角色和职责a) 根据项目需要,指导公司各部门、PM、项目组对组织级的规程、模板和表单进行必要地剪裁,裁剪需要经过文管中心的批准。
b) 参与评审项目计划(包括:软件开发计划、配置管理计划、风险管理计划、质量计划、沟通管理计划等),确保符合ISO9001/CMMI的要求
c) 参与评审软件产品,确保符合ISO9001/CMMI的要求。
d) 持续监控所有的项目活动是否与项目计划,以及PDSP中定义的软件过程一致。
e) 验证支持部门的所有承诺是否已经兑现,如果没有,则报告问题。
f) 把过程执行中的任何违规行为上报给QA经理和PM。
g) 确保所有经过评审、批准的文档均已置于项目文件夹和配置库。
h) 参加项目开工会议,阶段评估会议、阶段结束和项目关闭会议等。
i) 发现改进点并提交申请。
j) 对于新增的或经过修订的ISO9001/CMMI规程,要对项目组进行培训。
k) 培训项目组成员ISO9001/CMMI方面的知识。
l) 对项目数据进行收集、分析,并提供改进/预防活动的建议。
注释:在项目生命周期的任何阶段,如果有违规行为且QA认为其严重影响了项目质量,则QA可以立即建议停止项目活动,上报QA经理,并逐级上报到部门经理以采取进一步的行动。
4.2 项目任务启动a) 在项目启动、且PM已任命的情况下,QA经理将立即指派一名项目QA,会同PM、部门经理一起工作。
b) QA人员参与项目启动会。
c) 需要时,项目QA组织对项目组成员有关质量保证流程知识的培训。
d) 初步评估项目组成员的质量保证素质;
e) 必要时对项目组成员进行质量保证基础知识、相关制度流程培训。
f) QA检查开发立项申请是否已经发起,确保立项中的要求置于项目组建立的项目文件夹;
g) QA检查项目立项申请是否完成。通知PM建立临时项目文件夹,确保所有有效文档均已置于其中。
h) QA确保PM为项目准备了project工作任务列表和度量表。
4.3 存取项目文件a) 在整个项目工作期间,QA有读取项目文件夹的权限。
b) QA需要把新项目的详细信息加入到MIS/ERP的项目集合中。
4.4 估算在项目估算和重新估算的过程中,QA需要保证以下各项活动:
a) 简要介绍采用的估算技术。
b) 估算期间,简要介绍组织基线和可用于估算的数据。
c) 监控估算过程是否按照规程进行。
d) 确保记录估算依据。
4.5 项目计划4.5.1 《PDSP》文档a) 协助PM和项目组查阅以前类似项目的《PDSP》。
b) 确保《PDSP》中确准定义了生命周期,并且与模板一致。
c) 应该将所有对组织标准过程的剪裁情况记录在《PDSP》中。
d) 《PDSP》应该被评审、批准。
4.5.2 项目计划准备a) 协助PM查阅参考以前类似项目的《PDSP》、《软件开发计划》、《XXX Project项目计划》、《配置管理计划》等。
b) 协助PM结合组织基线设定项目质量目标。
4.5.3 风险管理计划a) 协助PM查阅参考以前类似项目的风险管理计划和《PDSP》。
b) 协助PM标识风险。
c) 确保风险规避和应急措施是合理的、可操作的,并得到落实。
4.5.4 配置管理计划a) 协助PM/CMO查阅其他类似项目的CMP。
b) 协助标识项目的配置项。
c) 协助PM确定项目的CCB。
d) 确保CMP得到评审,且跟踪评审发现的问题,直至结束。
4.5.5 项目Project计划文件的创建a) 协助PM和项目组利用MS Project工具,根据项目预测结果,采用《XXX Project项目计划》模板和WBS方法制定本项目组的任务进度计划。
4.5.6 参加项目计划的评审,并且核准该项目计划a) 评审活动应该按照评审流程进行。
b) 确保项目计划已经拟定完成,并且项目组完成了对该计划的内部评审。
c) 对于重点项目,评审小组应至少包含项目经理、部门经理。
d) 计划评审的输入包括:项目售前的问题记录、《PDSP》、《项目计划书》、Project计划等。
e) 填写评审表单,跟踪直至关闭所有评审问题。
f) 批准计划文件和project 计划,并且提交给部门经理签发。
g) 项目计划文件在部门经理签发之后,要确保被基线化。
h) QA会同CMO或其他项目组CMO一起进行基线审计,并跟踪基线审计发现的不符合项均已关闭。
4.5.7 项目开工会a) 确保及时召开项目开工会议,如果会议和项目实际开工日期相比延迟超过两天,QA要上报部门经理,并抄送给QA经理。
b) 参加会议,确认PM、项目组所有成员和支持组是否都出席了会议。
c) 确认项目开工会议Checklist的各项内容已经经过讨论且有会议纪要。
d) 确认项目组成员所需培训已经根据需求列入计划。
e) 确认各阶段所需的所有的工具、硬件、软件和其他资源均已列出。
f) 项目开工会议可以和项目周例会合并,但是在这种情况下,开工会议内容必须首先进行。
4.5.8 项目执行引导a) 确保项目阶段开工会召开。
b) 指导PM进行新老员工结合开展工作。
c) 与项目组成员进行例行沟通(参加例会、评审会议、阶段审计等),并验证任务是否按照当前项目计划的工作安排执行。
d) 验证生命周期各阶段的所有输入均已批准和签发。
e) 验证所有客户提供的资料受控,且已置于项目配置库中。
f) QA应该向PM报告任何过程偏离并筛选问题。
g) 提醒PM按照质量管理体系的流程,及时反馈进度偏差和例外事件。
h) 每月QA向QA经理和PM直接主管提交QA月报,并抄送PM。
4.5.9 项目工程引导a) 指导项目组如何实施需求分析方法(包括调查单、现场观摩、培训、访谈、原型等方法), 怎样写作需求规格说明书(包括客户需求规格说明书、系统需求规格说明书)。
b) 培训项目结构化或面向对象设计方法,直到项目进行软件总体结构设计、划分模块、设计模块接口等。
c) 指导项目组设计函数或类,例如函数或类的详细程度、复杂度等。
d) 指导项目组学习编程规范、代码评审检查单,以使得项目组避免编码中的常见问题。
e) 指导项目组如果制定测试计划、如何设计测试用例。
f) 指导项目组如何组织和监控测试活动,怎样做单元、集成和系统测试。
g) 向项目组推荐或建议适用于不同测试阶段的测试工具(包括Xunit、功能测试、性能测试,缺陷跟踪工具)。
4.6 生命周期4.6.1 需求
确保所需的工具和标准可用。
a) 参与需求分析活动,并评审SRS。
b) 确保《需求规格说明书》、系统测试计划文档评审的效果,并保留评审记录。
c) 确保评审活动遵循评审规程。
d) 协助项目组针对评审发现的缺陷进行原因分析并引导开展纠正活动。
e) 确保评审期间标识出的需求缺陷和系统测试计划缺陷已经关闭。
f) 依据项目计划,检查本阶段的培训需求是否已经完成。
g) 指导项目组准备需求跟踪矩阵。
h) 执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
i) 确认基线后的变更符合公司的变更流程。
j) 在阶段结束时,准备阶段结束工作并完成各项活动任务。
k) 确保阶段结束之前,更新、纠正和完善度量数据。
4.6.2 设计确保所需的工具与标准可用。
a) 确保《设计文档》和《测试计划》评审的效果,并保留评审记录。
b) 确保评审活动遵循评审规程。
c) 确保设计能够实现需求要求并满足编码需要。
d) 确保评审标识出的设计缺陷和集成测试计划缺陷已经关闭。
e) 协助项目组进行缺陷原因分析并引导开展纠正活动。
f) 执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
g) 确认基线后的变更符合公司的变更流程。
h) 在阶段结束时,准备阶段结束工作并完成各项活动任务。
i) 确保文档和需求跟踪矩阵的更新。
j) 确保阶段结束之前,更新、纠正和完善度量数据。
4.6.3 编码确保所需的工具与标准可用。
a) 确认开发代码符合编码规范。
b) 确保开发代码、单元测试计划评审的效果。
c) 确保新员工的代码经过老员工审查。
d) 确保评审和评审期间标识出的代码缺陷已经关闭。
e) 协助项目组进行缺陷原因分析并引导开展纠正活动。
f) 执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
g) 在阶段结束时,准备阶段结束工作并完成各项活动任务。
h) 确保文档和需求跟踪矩阵的更新。
i) 确保阶段结束之前,更新、纠正和完善度量数据。
4.6.4 单元测试a) 分析缺陷分布情况,协助项目经理找出测试重点。
b) 确保单元测试期间标识出的严重级测试缺陷已经关闭。
c) 协助项目组进行缺陷原因分析并引导开展纠正活动。
d) 执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
e) 在阶段结束时,准备阶段结束工作并完成各项活动任务。
f) 确保文档和需求跟踪矩阵的更新。
g) 确保阶段结束之前,更新、纠正和完善度量数据。
4.6.5 集成测试分析缺陷分布情况,协助项目经理找出测试重点。
确保集成与集成测试期间标识出的测试缺陷已经关闭。
协助项目组进行缺陷原因分析并引导开展纠正活动。
执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
在阶段结束时,准备阶段结束工作并完成各项活动任务。
确保文档和需求跟踪矩阵的更新。
确保阶段结束之前,更新、纠正和完善度量数据。
4.6.6 业务测试a) 分析缺陷分布情况,协助项目经理找出测试重点。
b) 确保系统测试期间标识出的测试缺陷已经关闭。
c) 协助项目组进行缺陷原因分析并引导开展纠正活动。
d) 执行交付审计、基线审计,确保交付审计、基线审计发现的问题均已关闭。
e) 在阶段结束时,准备阶段结束工作并完成各项活动任务。
f) 确保文档和需求跟踪矩阵的更新。
g) 确保业务测试结果经过客户主管的审核和批准。
4.6.7 发布/上线a) 在发布之前,QA与PM、CMO、测试组长共同按照发布/上线标准检验工作产品是否满足发布/上线要求。
b) 确保发布/上线报告已经发送给客户,并且客户做了正式验证、签核。
4.7 适用各个阶段的工作
Note: 注释:
第3.10节内容适用于项目整个生命周期的各个阶段。基于项目组特定的需求所做的适当剪裁可以在《PDSP》中进行定义。
4.7.1 通用a) 确保为项目组提供ISO9001/CMMI培训。
b) 确保所有文档均遵循了ISO9001/CMMI模板。
c) 维护和更新所有的质量记录。
d) 验证项目度量数据;
e) 周期性检查项目组是否按照配置管理规程对配置库进行了备份和恢复。
f) 遵循ISO9001/CMMI开展配置管理活动。
g) 确保项目组定期召开项目组会议。
h) 跟踪质量目标与达成情况,确保采取纠正/预防措施。
i) 确保所有软件工作产品经过评审、批准。
j) 确保更新并跟踪所有风险。
k) 每月向EPG组通报度量数据。
l) 分析项目进度,确保进度在预算控制范围内。
m) 分析项目功能、工作量分布,协助PM缓解项目瓶颈。
n) 执行内部审计计划。
o) 积极参与外部评估。
4.7.2 项目组周例会4.7.3 会前准备a) 验证项目度量数据、项目计划是否已更新。
b) 验证风险计划是否已更新。
c) 验证前一周评审和批准的所有软件产品均已基线化。
d) 验证对已基线化软件产品的任何更改都进行变更申请控制,并得到CCB批准。
4.7.4 会议过程中a) 按照周例会的Checklist展开讨论。
b) 讨论期间,需要检查上次会议的状态报告(例如,周例会纪要、项目状态报告、阶段结束报告等)。
c) 向项目组成员介绍度量分析细节,并且与质量目标进行比较。
d) 检查涉及支持部门的有关问题是否已经讨论并且记录在项目状态报告中。
e) 检查审计过程发现的不符合项是否已经按照计划关闭。
f) 如果支持部门出现了影响项目质量和进度的延迟,QA要上报QA经理,再由QA经理通报相关支持部门。
g) 状态报告在会议结束的同一天,由PM提交部门经理、抄送QA。
h) 检查状态报告中讨论的问题是否都已正确地表述,一旦发现与质量工作存在密切联系的事件,QA要上报部门经理、QA经理。
4.7.5 与客户交流a) PM应该通知给QA与客户进行讨论、交流的时间。
b) 确认项目计划中的客户沟通计划得到执行。
c) QA需要了解讨论的范围和议程,根据需要决定是否参加讨论会议。 如果QA出席讨论会议,必要时,QA将对客户或者项目组从质量角度提出的问题进行解释。
d) QA要确保项目组在生命周期的各个阶段所作的承诺没有发生变化,或者软件活动符合组织规程而且与项目定义的计划和《软件开发计划》一致。
e) 在会后,QA要检查会议纪要是否在会后三天之内创建并且发送给了客户。如果有延迟,QA将上报给部门经理和QA经理。
4.7.6 软件工作产品评审a) 验证正式的评审是否按照评审规程进行。
b) 当需要时,填写【不一致问题跟踪表】跟踪问题。
c) 验证评审发现的问题是否都进行跟踪并解决。
d) 验证评审后的工作产品是否进行基线化。
4.7.7 阶段结束会议根据《项目计划书》或《PDSP》计划确定是否需要进行阶段结束会议,如需要,是否按流程要求进行。
4.7.8 会前准备a) 验证软件产品已经基线化并且交付。
b) 验证度量数据已经全部更新和分析。
c) 需要的话(有些情况不需要进行重新估算),验证剩余生命周期的工作重新估算是否已经完成。
4.7.9 会议中a) 检查阶段结束报告是否已经准备并且在会议上被介绍。
b) 检查PM是否填写完成了checklist,并且在会后提交给部门经理、QA。
c) 检查本阶段的问题是否都有决议,以及下一阶段的工作安排是否明确。
d) 阶段结束报告在会议结束后的一天内,由PM提交部门经理、抄送QA。
4.7.10 月度评估会议a) 如果在前一个阶段结束会议之后一个月内按计划没有阶段结束会议,建议PM召集月度评估会议。如果现阶段计划在月度评估会议之后一周内结束,则不必召开阅读评估会议;
b) 会议之前,检查月度评估会议报告是否已经准备完毕并用来讨论。
c) 在会议中确保进行了阶段结束会议类似的评审,并且讨论了刚结束的一个月中经历的教训。
d) 在会议中,PM需要对照checklist确认各项内容完成情况。
e) 会后检查评估报告,定稿并提交给部门经理和QA经理。
4.7.11 不一致问题处理不一致问题首先在项目内部处理,并尽可能的解决。如果在项目内部不能解决问题,将问题提交部门经理裁决。对于等级为“严重”的问题,应在3个工作日内给出解决方案。
SQA在每一次的验证活动后,更新【不一致问题跟踪单】中对应问题的处理状态。在每月的《项目质量报告》报告给部门经理、QA经理、项目经理。
4.7.12 基线审计、交付审计a) 在软件产品基线化和提交给客户之前,QA负责对软件产品进行基线审计和交付审计,输出审计报告并且提交给PM、部门经理。如果在审计中发现NC,在报告中报告该NC。
b) 检查改进和预防措施计划是否合适并据此决定是否允许交付。
c) 如果延迟关闭NC,则上报QA经理。
4.7.13 项目组变化a) 如果项目组有成员释放,QA要检查PM是否已经安排项目组的其他人员接替该员工的工作。如果PM发生变化,部门经理需要安排工作移交。如果没有做好这些必要的安排,QA要上报QA经理,由QA经理上报总经理。
b) 如果项目QA发生变化,QA经理应该通知部门经理、PM,并且指定新的QA。QA工作交接时间为一周。即将离开的QA要在项目组周例会上向大家介绍新QA,此类介绍也应该记录到项目周状态报告中。
4.7.14 项目结束会议项目可以在成功完成承诺的交付件或者是由于技术和商业原因提前结束的情况下实施项目关闭。无论是那种情况,都应该召开由部门经理、PM、QA和项目组成员参加的项目结束会议。支持部门也应该参加结束会议。
4.7.15 会前准备a) 如果项目正常关闭,QA要检查所有的软件和工作产品均被客户接受。在提前结束的情况下,确保有部门经理提供的正式项目结束原因说明信息。
b) 确保与部门经理进行关闭项目的正式沟通。
c) 检查项目文件是否完整。
d) 检查度量文件是否更新。
e) 会议之前,检查项目结束会议报告是否已经准备就绪。
f) 一定要PM向项目组说明生产率、缺陷密度和项目的各种偏差,并且标识出项目的改进点。
g) 检查维护人员之外的项目组其他资源释放情况。
h) 检查所有的软件代码和其他软件产品是否已经归档。
i) 检查所有项目文件是否已经在公司归档。
j) 检查重用组件是否已经被适当标识并且提交SEPG归档、发布。
k) 检查需要放置到最佳实践库的内容是否已发放给了SEPG组归档、发布。
4.7.16 会后工作a) 检查PM是否把所有的项目关闭报告提交给部门经理和其他部门主管。
b) 更新MIS/ERP项目状态信息,更新为“结束”状态。
4.7.17 项目问题原因分析会议a) 建议由QA协调,部门经理或者管理部门主持开展“根本原因分析”活动,分析导致项目自身优缺点的根本原因。QA负责该过程按照组织规程进行,并且将发现的问题上报给管理部门。
b) RCA之后,QA要验证RCA报告已经置于过程资产库,以便将来参考。
在标识出每个最佳实践或教训总结的根本原因之后,必须提供一些能够提高系统能力或者能够使能力制度化的改进/预防措施,并由QA负责监督它的提交过程。