项目管理文档及过程检查清单QA
qa的职责
qa的职责导读：本文是关于qa的职责的文章，如果觉得很不错，欢迎点评和分享！【篇一：QA职责】1、制定和完善项目开发过程中的各项工作流程和规范。
2、监督项目过程按照既定的工作流程与规范执行。
3、对项目进行中产出的各项文档进行评估。
4、保证文档与工作进程的一致性。
5、与PM沟通，共同推动项目进行。
6、评估需求文档，规则文档，设计文档和测试用例。
7、评估需求分析过程所产出的各项设计文档，与工程师一共review这些文档。
8、监督在开发过程中，各小组按组内规范进行工作，有组间交互的任务需按组间交互规范去完成。
检查设计文档是否与程序源码一致，这些期间QA按工作流程规范监督各项工作任务的进行。
和PM 及时沟通共同推动项目的进行。
9、评估视觉设计的工作规范。
10、评估发布文档。
11、对新来的人员作流程和规范方面的培训。
【篇二：QA的工作职责】1、要清楚每天的出货计划与外来料，并严格按照抽样标准规定来检查待出货、外发加工的产品；2、将检查后的合格品盖上合格的印章，并摆放在相应的位置；3、不合格情况出现时，应立即通知相关人员确保产品忙改善，不可耽搁产品的出货，也要避免造成批量性的不良品；4、对品质不稳定的产品要进行跟踪、有问题时应及时汇报上级或其他人员，并找出解决方法，及时解决问题；5、协助主管对客户反馈、投诉进行处理，并确保仓库库存的不良品与良品得到有效处理；6、负责首件的签板确认，并保证无样板不生产、不合格不出货；7、统筹车间品质管理工作；8、认真填写各种报告，并对上级交待的工作负责。
【篇三：QA的职责】1、保障软件组织流程体系得到遵守；2、促使软件组织过程改进；3、指导项目实施流程；4、增加开发活动透明度；5、评审项目活动；6、审核工作产品；7、协助工作产品问题解决；8、度量数据采集分析，提供决策参考；9、进行缺陷预防；10、实现质量目标。
【篇四：QA职责】1、根据公司质量目标、质量方针，负责制定本部门的工作目标，按时向质量总监提交年、月度工作计划和总结。
QA项目管理过程检查表
序号 类型
检查项
1 CS 是否采用了合适的估算方法？
2 CS 是否规定的估算表进行估算？
3 CS 估算结果是否作为项目计划的依据？
4
CT
是否进行了有效的估算？估算结果是否可 靠？
5 PF 估算结果对项目计划是否有帮助？
检查结 论
检查记录
1、类型说明 CS：Consistency，Do right things!一致性，是否按公司的标准过程实施。 CT：Correctness，Do things right!正确性，实施的细节是否正确，表单填写是否正确。 PF：Performance，绩效性，过程实施是否有价值，对项目是否有帮助。
17 PF 组间协调的问题是否能有效解决？
18 PF 项目是否能按计划完成？
4、 项目变更控制
序号 类型
检查项
检查 论
1 CS 项目控制的阈值是否有定义？
2 CS 对项目出现的偏差/问题是否有记录并分析？
3 CS 对出现的偏差/问题是否有修改计划？
4 CS 规模、工作量、进度等是否进行重新估算？
5 CS 修改后的计划是否有经验评审及核准？
6 CS 对偏差/问题是否有采取纠正措施？
7 CT 纠正措施是否有纳入修改后的项目计划中？
项目是否能按计划完成？项目计划是否能得 8 PF 到保证？
5、 项目结案
序号 类型
检查项
1 CS 是否有取得客户的验收认可？ 2 CS 是否有按要求进行结案总结？ 3 CS 项目结案是否按要求经过核准？ 4 CS 是否有召开结案会议？ 5 CS 项目文档是否有归档，提交给质量保证部？
6 CS PM是否制定了项目管理计划？
7 CS PM是否制定了项目进度计划？
软件质量保证过程(SQA)
软件质量保证过程作为一种独产的审查活动贯通于整个软件开辟过程.质量控制人员类似于软件开辟过程中的过程警察,其主要职责是:检查开辟和管理活动是否与制定的过程策略、标准和流程一致；检查工作产品是否遵循模板规定的内容和格式。
此文档从软件开辟过程的各个阶段来描述软件质量保证过程。
项目计划过程的目的是计划并执行一系列必要的活动，以便在不超出项目预算和日程安排的前提下，将优质的产品交付给客户。
项目计划过程合用于公司的所有项目，但每一个项目可以根据各自的不同情况对该过程进行裁剪。
项目启动会议已经结束；在项目的生命周期中，根据项目的跟踪结果，需要对项目计划进行修改和完善。
项目启动报告；项目提案书；项目相关文档；组织财富库中以往类似的经验文档。
项目计划已通过评审、批准并确立。
评审后的项目计划文档包括：软件开辟质量计划；软件配置管理计划。
项目计划包含 3 个需要在项目中执行和管理的主要计划，如下：软件项目管理计划；软件项目质量管理计划；软件配置管理计划。
软件项目管理计划涉及项目中所有与项目管理相关的问题(从项目开始到结束)。
软件项目质量管理计划涉及与质量相关的需求，这些需要在产品中实现，并保证用于构筑产品的项目过程。
由于质量是产品创建的一部份，所以将软件项目管理计划和软件项目质量管理计划合成一个计划文档，称为软件开辟质量计划。
软件配置管理计划用于管理与配置管理相关的需求，这些需求与工作产品和可交付产品有关。
该计划的目的在于：为执行软件工程相关活动提供依据，并在整个开辟和维护过程中对软件项目进行管理。
将包含以下 3 点：可以使用不同的检查表来制定软件开辟质量计划和软件配置管理计划。
如下每一个计划都将包含以下 3 点：目标；执行方法；当前状态。
前两点不会时常变更，但第三点则被认为会在执行跟踪时被修改。
因此，前两点通常被直接放到计划中，而第三点则以链接的方法放到计划中。
(1)制订软件开辟质量计划软件开辟质量计划包括软件项目管理计划、软件项目质量管理计划。
CMMI QA检查单
验收检查单
1) 转产资料是否完整、正确 2）转产资料是否已顺利交接给供应链 3）是否有转产资料清单 4）转产评审记录检查
1）工程施工启动会议 2）工程施工计划 3）工程文件 4）勘测计划 5）工程勘测报告 7）施工方案 8）验货签收单 9）工程进度计划 10）工程问题记录表 11）工程初验报告 12）工程总结报告
配置管理检查单
2）质量检查结果是否有做记录 3）质量问题是否被处理并做记录，
质量保证检查单
41） ）是 是否 否编 做制 度质 量量 计报 划告
2）度量数据收集记录
3）是否做度量分析，度量分析的问题是否做处 理
度量分析检查单
1）是否按决策时机启动决策分析过程
2）是否召开决策分析会议
3) 编制决策分析报告
1）风险识别是否合理 2）是否进行风险评估 3）是否进行风险缓解 4）是否进行风险监控
项目监督与控制检查单 变更管理检查单 风险管理检查单
关键管控点
1）项目需求规格书是否进行评审 2）需求规格书是否能够涵盖客户所需的所有要 求 3）需求规格书功能参数是否符合相关规范及要 求（参考用户要求、国军标等） 4）是否建立需求跟踪矩阵 1）项目总体方案及各分方案是否进行评审 2）总体方案编制是否按需求规格书中的要求 3）各分方案设计是否明确， 能够顺利执行 4）方案评审后需发布
1）变更申请 2）变更评估 3）变更通知 4）变更实施 5）变更验证 6）变更发布
1）项目风险跟踪表 2）项目风险管理报告
研发过程检查（依项目策划
调整）
项目研制阶段
建议检查频度
内容
需求
每节点、里程碑检查，至少一次
1）项目需求规格说明书 2）需求评审
方案设计
项目管理方法-检查清单模板
项目管理方法-检查清单在项目执行期间，可以由项目管理团队作成检查清单或者模板(checklist/template)，也可以由项目管理室那样的支持项目管理的组织在项目审查和监督的成功案例和失败案例的基础上作成。
检查清单或者模板是组织的最佳实践，通过这些经验的积累可以提高项目管理的效率，有助于防止失败。
检查清单用于确认作业或工程是否存在遗漏。
模板作为产出物的雏形式样，具有WBS、网络图、需求变更书、进展报告书、合同标准文件等形式。
通过雏形的灵活运用，经验较浅的项目管理者可以明白必须做些什么，并能在其他项目中重复利用。
软件开发项目管理检查清单：天气晴雨表检查清单用于确认作业或工程是否存在遗漏，是反映项目管理是否存在问题的“天气晴雨表”。
下面是软件开发项目管理的一个检查清单，比本章中所言“软件开发项目管理过程中的祸根及其后果”更加详细。
通过这个清单，可以发现项目管理存在的问题，并采取措施加以改善。
需求式样晴雨表是否存在稳定的、完整的、书面的需求式样？是否已经就需求事项煞费苦心地与顾客进行了沟通和确认？是否存在需求式样尚未确定就以“暂定式样”开始作业而事后返工的情况？是否为了确认顾客的需求而对“需求式样书”进行了审查？是否根据顾客提供的产品式样书而直接进入了设计作业？是否在作业途中不断变更或追加需求式样？是否按照项目编号规则对每项需求赋予了惟一的编号？是否已经明确顾客方的项目推进体制以及最终决策者？是否摄于顾客的特权优位性而不经讨论地接受顾客的需求变更？是否在远远超越自身能力而根本无法完成的情况下不能清楚地说“不”？是否在作业已经进入测试阶段后还发现需求式样理解有误？是否以单一窗口接收顾客的需求，确保一窗口输入？项目组成员的作业是否基于最新需求信息，而不是已经失效的历史信息？项目计划晴雨表是否将估算视为一种特殊的技能，并将估算当作一个小项目？是否定期对项目计划实施重新估算并根据实际情况加以调整？是否对作业文档等成果物的“量”进行了估计？是否以适当的单位进行了作业量的估计？项目作业是否具有详细的日程表？日程表确定之后，如果和实际情况出入较大，是否进行了调整？是否接受了不切实际的开发日程，而其结果是，日程表仅仅成为一种形式？ “工作量”和“难易度”是否会因为担当者的不同而出现巨大变动？是否因为实际进展超前于计划而没有思考项目计划本身存在的精度问题？团队管理晴雨表是否存在明确的软件开发行动单位：团队？是否虽然叫作团队，但是并没有认识到协作而是专注于工作任务的分担？管理者是否仍然承担以前作为技术者所承担的具体开发作业任务？项目管理者是否仅仅根据自己的经验而将需求式样直接分派给“个人”？项目管理者是否总是认为项目没有什么值得注意的问题？团队成员是否知道项目作业内容的相互关系及其优先级？是否在项目启动之后仍然还有项目组成员感到无所事事？是否经常有特定的项目组成员总是加班到深夜？团队成员是否知道并遵守统一的作业规范？是否从作业流程上、从团队协作上追究过程序缺陷的真正原因？团队成员是否在相互察看成果物后产生提高自己的作业水平的意识？当问题难点解决之后，是否向项目组成员介绍解决该问题的思维和方法？项目组成员的出勤时间是否经常相差很大而不寻找原因？项目组成员在遇到技术难题时是否与项目组其他成员沟通并寻求支援？项目组成员在讨论问题时是否出现无条理的、非建设性的讨论？作业流程晴雨表是否存在专注于组织整体的开发作业和项目流程的人或者小组？是否存在项目开发作业的标准作业流程？是否存在记述顾客需求式样的文档标准？是否存在设计书的文档标准？是否不经过设计阶段而直接进入编码阶段？设计阶段是否实施了以设计为对象的审查？编码阶段是否实施了以代码为对象的审查？中途式样变更后，是否未经其影响范围的分析就直接分配给担当者？是否未经单体测试就直接开始综合测试？是否时至最后才发现此前隐藏的诸多问题？是否无视已经发现的问题而继续推进作业？是否多次重复出现以前相同的错误而没有吸取教训？是否没有专门的测试人员而在交付之前还是由开发者自己实施测试？对式样需求是否确立了适当的测试项目？测试是否几乎没有自动化手段？过程改善方面是否存在可以商量和咨询的人员？是否鼓励各开发小组写作事后分析报告，至少能就项目进程开会讨论？是否组织正式的活动，就软件开发与质量控制流程的相关问题相互切磋？项目配置晴雨表是否在发现潜在的缺陷时难以确定其对现有模型的影响范围？是否只有担当者知道而没有向所有成员公布缺陷的修正范围和修正方法？是否因为修改一个程序缺陷而引发多个新的缺陷？担当者是否能在任何时间对源程序做自由的变更？开发期间是否定期对制作过程中的文件和程序进行备份？是否确立了资源备份在非常时期的因应方式？需求式样书和设计书等正式文件是否存在“确认”手续？项目文档是否一直保持最初的状态，即使在式样变更后仍然没有变化？是否在项目后期难以想起中途式样变更的“理由”？对于程序缺陷和式样变更，是否能追踪其修改点？对于开发环境目录中的旧代码是否难以判断其能否删除？开发文档是否会出现链接到旧版本的情况？教育培训晴雨表是否描绘出现在的开发组织多年后的“风姿”？在组织上，是否对现在的人员实施技术性教育和培训？是否确立了员工教育培训的计划和目标？是否将技术学习视为个人任务而没有组织上的“方向”？项目开发人员所持有的软件开发文献的平均数量是否在1册以下？项目作业休息时间是否毫不涉及崭新技术方面的话题？项目组成员是否不知道软件工程的意思？是否不了解“凝聚度”、“结合度”等词汇的意思？是否难以说出5个以上的软件质量特性及其副特性？项目审查晴雨表参与者是否了解审查的整体流程？是否带着目的而非盲目地实施审查作业？是否仅仅局限于代码审查而不顾及其他？审查者是否只关注形式而非实质？是否明确审查对象物，针对“物”而非“人”？是否记录审查结果并追踪缺陷修正结果？是否将审查的反馈结果导入下一项目中？审查会议是否演化成为问题解决会议？其他是否采取了数据备份以及病毒防范等措施？对电子邮件的应对是否总是滞后？是否感到电子邮件的应对很繁琐？下面是余秋雨经典励志语录，欢迎阅读。
项目管理 项目资料整理清单
项目管理项目资料整理清单项目管理是指通过合理的组织、协调、控制和指导，以达到项目目标的一系列活动。
在项目管理过程中，项目资料整理清单是一个重要的工具，它能够帮助项目团队有效地管理和整理项目相关的文件和资料。
下面是一个标准格式的项目资料整理清单的示例：项目名称：XXX项目项目资料整理清单：1. 项目计划和进度管理资料：- 项目计划书：包括项目目标、范围、里程碑、资源分配等信息。
- 进度计划：详细列出项目的各个阶段和任务的开始时间、结束时间和持续时间。
- 项目进度报告：记录项目的实际进度和计划进度之间的差异，并提供解决方案。
2. 需求管理资料：- 需求文档：包括项目的功能需求、非功能需求和约束条件。
- 需求变更记录：记录需求的变更历史，包括变更原因、影响分析和批准人。
3. 风险管理资料：- 风险登记册：记录项目可能面临的各种风险、概率、影响和应对措施。
- 风险评估报告：对项目风险进行定性和定量评估，并提供相应的风险应对策略。
4. 质量管理资料：- 质量计划：包括项目的质量目标、质量标准和质量控制措施。
- 质量检查记录：记录项目的质量检查活动和结果，包括检查日期、检查内容和检查人员。
5. 采购管理资料：- 采购合同：包括供应商和项目之间的合同条款、价格和交付要求。
- 采购审计报告：对供应商履约情况进行审计，并提供相应的改进建议。
6. 沟通管理资料：- 会议纪要：记录项目会议的议题、讨论内容、决策和行动项。
- 沟通计划：明确项目沟通的目标、受众、内容、频率和沟通方式。
7. 变更管理资料：- 变更请求：记录项目的变更请求，包括变更内容、原因和影响分析。
- 变更批准记录：记录已批准的变更请求，包括批准人、日期和变更实施计划。
8. 项目交付物：- 项目交付物清单：列出项目交付物的名称、描述、负责人和交付日期。
- 交付物验收记录：记录项目交付物的验收结果和相关的问题和建议。
以上是项目资料整理清单的示例，具体的项目资料和数据可以根据实际情况进行编写和填充。
CMMI管理体系文档项目结项规程_QA检查记录单
无
周
无
3 源代码
4-软件源程序代码
4 测试 5 验收交付
《“项目名称”-测试大纲》 “项目名称”-测试用例设计》 《“项目名称”-测试报告》 “项目名称”-安装配置手册》 《“项目名称”操作手册》 《“项目名称”使用手册》 《“项目名称”专业版部署指南》
QA检查记录单
文件SVN库上路径
检查日期
/SVN内文件夹名字/06交付文 档/验收资料
2022/3/22
检查人
Hale Waihona Puke 备注周无/SVN内文件夹名字/06交付文 档/验收资料
2022/3/23
/SVN内文件夹名字/06交付文 档/验收资料
/SVN内文件夹名字/06交付文 档/验收资料
2022/3/24 2022/3/25
/SVN内文件夹名字/06交付文 档/验收资料
2022/3/26
周
无
周
无
周
1、项目名称：项目名称 SVN项目名称：SVN内文件夹名字 2、检查内容汇总
QA检查记录单
序号
检查内容
1 需求分析
2 设计
对应文档名称
《3-阶段性成果文档报审表（需求说 明书）》 《3-“项目名称”需求规格说明书》 《3-需求调研表-区域统一调度软件 《4-阶段性成果文档报审表（详细设 计与数据库设计）》 《4-“项目名称”软件开发详细设计 和数据库设计报告》
qa 项目qa岗位职责优秀4篇
qa 项目qa岗位职责优秀4篇在不断进步的时代，越来越多地方需要用到岗位职责，任何岗位职责都是一个责任、权力与义务的综合体，有多大的权力就应该承担多大的责任，有多大的权力和责任应该尽多大的义务，任何割裂开来的做法都会发生问题。
那么制定岗位职责真的很难吗？下面是作者给大家整理的4篇项目qa岗位职责，希望可以启发您对于qa的写作思路。
QA工作职责篇一工作职责：1.根据产品需求、负责搭建测试框架、编写测试计划、测试用例、测试脚本和测试数据；2.完成对产品的集成测试与系统测试，对产品的功能、性能及其他方面的测试负责；3.负责分析软件缺陷并提交缺陷报告；4.对测试实施过程中发现的软件问题进行跟踪分析和报告，推动测试中发现问题及时合理地解决任职要求：1.专科以上学历，计算机及相关专业毕业；2.具有1年以上测试经验，熟悉测试流程和规范，熟练掌握软件测试方法和一些常用测试工具，对软件测试工作有浓厚兴趣；3.有测试用例编写经验；4.较强的语言表达能力和文档撰写能力；5.熟悉手机客户端测试、WAP测试的优先。
QA工作职责篇二一、品质部主管岗位职责：1负责进料检验、过程检验和较终产品检验之指导和管理工作；2负责产品品质的记录、部门质量目标统计的管理；3负责协助采购对供货商的质量体系和产品质量进行评审；4负责不合格品的控制和管理；5负责对本部员工的检验技能培训并保存记录；6负责客户投诉、退货的验证和提出纠正与预防措施，并对其实施过程和效果进行跟踪和验证；7完成上级交待的其他工作。
二、品质部文员岗位职责：1、负责ISO及本部门文件的整理、归档及打印；2、负责每月品质报表及部门质量目标的统计；3、负责样品管理；4、服从上级主管的工作安排。
三、品质部领班岗位职责1、样品及承认书的检验，制程异常之处理跟进；2、检验员之相关培训及管理；3、相应报表之审核；4、MRB的统计；4、不能独立处理之异常及时上报；5、完成上级交待的其他工作。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试组长 测试组长
审计内容： 1、评审报告包含对需求评审的结果。 2、评审报告包含对项目特征集评审的结果。 3、评审报告包含对项目工作计划评审的结果。 4、评审报告包含对重要风险进行评审的结果。 5、评审报告包含了对测试计划、测试用例的评审结果。 6、评审报告包含了测试评估的风险清单。 7、评审报告已及时上传至配置管理库。 审计方式： 1、访谈评审参与人评审结果。 2、检查配置管理中评审报告的内容。
13、通过了公司的需求评审。
审计方式：
1、访谈PM、SA、测试需求一致性、功能完整性，并且与项目组各成员
达成一致。
2、检查配置管理存在用户需求分析报告，且为最新的。
必选
审计内容： 1、项目特征集覆盖所有需求。 2、特征集已区分优先级。 3、特征集已上传至配置管理中，且为最新的。 审计方式： 1、访谈设计人员是否了解项目的特征集。 2、检查配置管理库存在《项目特征集》，且为最新的。
系统分析员
必选
审计内容： 1、功能特征集覆盖全部需求。 2、功能特征集已划分优先级、风险。 3、能够指导开发、测试设计。 4、及时将最新的功能特征表上传至配置管理库。 审计方式： 1、访谈项目开发、测试对特征集的功能理解一致性。 2、检查配置管理库中存在最新的功能特征集表。
审计内容： 1、对于成本、进度估算、优先级、风险和开发流程是否合适与用户达 成一致意见。 2、项目开发计划明确了需求范围、交付件、进度、关键质量要求、外 界合作关系等。 3、补丁开发、问题解决类维护项目需要有任务分配表和计划。 4、通过了公司的项目开发计划评审。 5、及时将最新的项目开发计划上传至配置管理库。 审计方式： 1、访谈PM、开发、测试对项目开发计划理解的一致性。 2、检查配置管理库中存在最新的项目开发计划。
项目经理
项目成员
可选
必选
必选 可选 必选 可选
审计内容： 1、对项目立项阶段进行度量分析。 2、度量数据包含需求变更率、工作量、项目计划（里程碑计划）、项 目资源使用。 3、根据度量结果对偏差处采取改进措施、重估工作量并调整计划。 4、及时将度量分析报告上传至配置管理库。 审计方式： 1、访谈项目经理度量分析情况。 2、检查配置管理库中存在最新项目立项阶段的度量分析报告。
系统分析员 系统分析员
系统分析员
可选 必选
必选
审计内容： 1、完成了类结构关系层次的设计。 2、检查设计文档清晰描述组件与组件之间依赖关系。 3、组件与模块之间的接口有清晰明确的定义，接口具有可扩展性。 4、能够指导后续开发。 5、通过了公司设计评审。 6、及时将最新的类及组件结构层次说明上传至配置管理库。 审计方式： 1、访谈项目SA讲述应用层次划分情况。 2、检查配置管理库中存在最新的类及组件结构层次说明文档。
项目经理
审计内容： 1、项目计划包括任务、工作周期、分工以及需要达到的质量目标。 2、项目计划（里程碑计划）与实际一致，若不一致。 3、项目计划与实际不一致时及时调整与更新。 4、及时将项目计划（里程碑计划）上传至配置管理库。 审计方式： 1、访谈项目相关人员，是否了解项目的计划（关键时间点、个人任务 分工等）。 2、检查配置管理库存在项目计划（里程碑计划）。
项目经理
审计内容： 1、干系人通讯录中包含项目所有干系人。 2、各干系人的角色和责任识别正确。 3、及时将干系人通讯录上传至配置库。 审计方式： 1、访谈项目相关人员，对项目干系人的了解。 2、检查配置管理存在干系人通讯录，且为最新的。
项目经理 项目经理
审计内容： 1、每周都输出了周报。 2、周报中标识了进度状态、完成情况、工作量使用、风险和问题。 3、及时将工作周报上传至配置管理库。 审计方式： 1、访谈项目相关人员对项目的进度状态了解情况。 2、检查配置管理库存在工作周报，且为最新的。
审计内容： 1、周报更新了进度状态、风险和问题。 2、每周都输出周报。 3、及时将工作周报上传至配置管理库。 审计方式： 1、访谈项目干系人对项目当前状态的了解。 2、检查配置管理中存在每周的工作周报。
项目经理
必选
需求分析员 必选
需求分析员 需求分析员 需求分析员
可选 可选 可选
项目经理
必选
项目成员
请选择
功能特征表 项目开发计划
请选择 请选择
测试计划
请选择
测试用例
请选择
评审报告
评审检查单 评审通知 评审意见反馈表
工作周报
请选择
请选择 请选择 请选择
请选择
个人工作周报 度量分析报告
迭代过程
迭代项目计划 需求维护 迭代设计
迭代开发
பைடு நூலகம்
请选择 请选择
测试计划维护
测试案例维护 BUG清单
风险列表
迭代总结 评审报告 评审检查单 评审通知 评审意见反馈表 工作周报 个人工作周报
请选择
请选择 请选择 请选择 请选择
重要风险列表
评审报告 评审检查单 评审通知 评审意见反馈表 工作周报 个人工作周报
度量分析报告
系统设计
系统设计方案
请选择
请选择 请选择 请选择 请选择 请选择 请选择 请选择
请选择
系统架构设计说明 应用层次划分说明
请选择 请选择
领域模型设计说明
请选择
类及组件结构层次说明
请选择
请选择 请选择 请选择 请选择 请选择 请选择 请选择 请选择 请选择 请选择 请选择 请选择
请选择 请选择 请选择 请选择 请选择
个人工作周报 度量分析报告
请选择 请选择
：
项目当前阶段：
：
审计人员：
审计参考
审计项 负责人
审计 分类
审计内容： 1、与客户已经正式签订合同。 2、立项确认函中包含需求边界。 3、向上申请资源（包含开发、测试、实施、硬件资源）。 4、及时将立项确认函、资源申请及计划、项目计划书上传至配置管理 库。 审计方式： 1、查看配置库存在立项确认函、资源申请及计划、项目计划书文档。 2、访谈项目经理的项目立项、启动情况。
7、不存在一个需求项多处文档存在的情况。
8、需求项的表述颗粒度适宜于需求跟踪矩阵的建立。 9、每个需求项的表述简明独立，易于标识。
需求分析员
10、需求项的表述完整表明了需求实现的功能。
11、确定了项目的软件规模和边界条件，包括系统环境、运作前景、验
收标准以及希望软件中包括和不包括的内容；
12、需求能够指导后续的项目特征集划分、软件设计和测试设计。
请选择
请选择
请选择 请选择 请选择 请选择 请选择
请选择
请选择
项目例会
请选择
度量分析报告
项目实施
培训方案 培训计划 培训文档 用户操作手册 系统管理手册 系统安装手册 源代码 验收报告 交付清单及其所列文档 工作周报 个人工作周报 度量分析报告
项目总结
项目总结 个人总结 项目材料移交清单 经验教训 工作周报
项目经理
必选
审计内容： 1、系统设计方案实现系统子系统与功能模块的划分，明确子系统模块 之间的职责分配（如果只有一个子系统，这个活动可不做）。 2、系统设计方案实现子系统间通讯协议的设计。 3、系统设计方案实现系统的整体架构（应用架构、领域模型、类结构 层次模型）设计。 4、系统设计方案实现系统工具与开发规范的建立。 5、系统设计方案能够指导具体设计工作。 6、通过了公司的系统设计方案评审。 7、及时将系统设计方案上传至配置管理库。 审计方式： 1、访谈项目PM/SA讲述设计方案如何指导设计情况。 2、检查配置管理库中存在最新的系统设计方案。
项目经理
可选
审计内容： 1、对需求分析阶段进行度量分析。 2、度量数据包含需求变更率、工作量、项目计划（里程碑计划）、项 目资源使用。 3、根据度量结果对偏差处采取改进措施、重估工作量并调整计划。 4、及时将度量分析报告上传至配置管理库。 审计方式： 1、访谈项目经理度量分析情况。 2、检查配置管理库中存在最新需求分析阶段的度量分析报告。
系统分析员
审计内容： 1、对于成本、进度估算、优先级、风险和开发流程是否合适与用户达 成一致意见。 2、项目工作计划已上传至配置管理库，且为最新的。 审计方式： 1、访谈项目经理项目计划。 2、检查配置管理库中《项目工作计划》的内容。
项目经理 项目经理
项目经理
项目经理
必选
必选 可选 可选 可选
审计内容： 1、重要风险已在每周项目例会报告中有体现。 审计方式： 1、访谈项目经理当前阶段重要风险情况。 2、检查每周项目例会报告中的重要风险列表。 审计内容： 1、评审报告包含对需求评审的结果。 2、评审报告包含对项目特征集评审的结果。 3、评审报告包含对项目工作计划评审的结果。 4、评审报告包含对重要风险进行评审的结果。 4、评审报告已及时上传至配置管理库。 审计方式： 1、访谈评审参与人评审结果。 2、检查配置管理中评审报告的内容。
项目经理
必选
审计内容：
1、配置库内及时存放对应版本的需求分析报告。
2、确定了需求提供方认可的所有需求（功能和非功能），与用户对需
求达成一致意见，并且理解相同。
3、已经确定所有风险并且有针对每个风险的减轻风险策略。
4、需求分析确定了项目的支持环境。
5、不存在对某个需求描述的前后不一致。
6、不存在某几个需求项的表述相互矛盾。
项目经理/系 统分析员
项目经理
必选 必选
审计内容： 1、在开始测试计划之前先进行测试工作量估算。 2、使用统一的测试计划模版。 3、测试计划明确了测试目的。 4、测试计划明确了功能、性能、安全、兼容性、可用性测试范围。 5、测试计划明确了测试方法、策略。 6、测试计划明确了需要的资源。 7、测试计划明确了里程碑计划。 8、测试计划明确了需要达到的质量目标。 9、测试计划列出了风险清单。 10、能够指导测试设计、测试执行工作。 11、测试计划评审通过。 12、及时将测试计划上传至配置库。 审计方式： 1、访谈项目干系人对测试范围的了解。 2、访谈项目干系人对测试里程碑计划的了解。 3、访谈项目测试人员对自己各阶段测试任务的了解。 审计内容： 1、使用统一的测试用例模版。 2、测试用例本身的描述清晰，不存在二义性。 3、测试用例覆盖了所有的软件需求。 4、测试用例业务逻辑正确、测试用例与软件规格要求一致。 5、用例设计包含了正面、反面的用例。 6、测试用例已区分优先级。 7、及时提出存在的风险。 8、测试用例可以指导后续测试执行。 9、通过了项目组的测试用例评审。 10、及时将最新的测试用例上传至配置管理库。 审计方式： 1、访谈测试组长、测试人员、开发对测试功能检查点理解的一致性。 2、检查配置管理库中存在最新的测试用例。