软件质量保证开发计划评审检查表
软件开发计划检查表 模板
2、是否预算了项目的工作量并划分给小组成员？
九、配置管理
1、是否制定了配置管理计划表？
检查人/日期：批准人/日期：
5、是否考虑软件复用？
五、组织结构
1、是否确定项目小组成员，并将其划分成多个Team?
2、是否明确各个小组成员的职责？
六、风险管理
1、是否预测了与项目有关的主要风险？
2、是否采取跟踪、监测措施以减小风险或避免风险的产生？
七、相关性
1、是否考虑了项目的外部相关活动？
2、是否考虑了项目的内部相关活动？
八、资源预算
三、产品清单
1、是否明确提交给客户的产品清单（产品名称、提交时间、客户接受方式、责任人、验收标准）？
2、是否明确提交给项目监按钮部门的产品清单（产品名称、提交时间、提交方式、责任人）？
四、技术管理
1、是否明确开发环境（软件、硬件环境）？
2、是否明确开发工具？
3、是否明确开发方法？
4、是否采用新技术？
软件
项目名称：项目编号：
检查项目
检查内容
检查结果
得分
一、质量目标
1、是否符合质量体系的要求？
2、如果不符合技量体系的要求，是否按要求编制《质量计划》？
二、阶段划分
1、是否Байду номын сангаас确划分各阶段？
2、各阶段的输入、输出标准是否明确？
3、是否明确各阶段提交物？
4、是否明确各阶段质量目标？
5、是否明确提出各阶段检查点？
产品开发各阶段质量控制评审流程
生产与测试文件
试生产准备评审表
试生产准备评审
MFG进行试产前评审，判定是否具备试产条件
MFG
试生产
生产部委托OEM或ODM或客户工厂进行试生产
MFG
《试生产总结报告》
《DFM Check List》
《维修报告》
《试生产ISSUE LIST》
生产部与设计师、QA现场进行监控、
提供技术支持，提出报告
结果跟踪确认
结果跟踪、验证
持续改进
总结、分析，PDCA
评价报告
DQA按Qualify标准评价，识别问题和风险
DQA
《项目质量管理表》
ISSUE 提出
依据检测、评价报告结果提出ISSUE。
项目组
《ISSUE LIST》
ISSUE 管理
ISSUE LIST建立与维护、管理。
PM
《ISSUE LIST》
原因分析
改进计划
项目组分析问题制定改进方案。
项目组
《ISSUE LIST》；《ICN》；《部品改进通知单》
DQA
《部品认定报告》
SP过程检查
各部门按《项目阶段定义与目标》进行检查
项目组
Check List
SP评审会
PM组织SP评审会
PM
会议记录
SP Stage
judgement
DQA在SP评审会上进行EP Stage judgement
DQA
SP judgement 报告
第五阶段：
验证生产
试生产准备
物料准备；生产文件准备；
改进计划沟通、安排
OQC
DQA进行OQC，
PM安排外部测试（FTA、CTA、客户评价…）
软件质量保证过程(SQA)
软件质量包管过程之杨若古兰创作软件质量包管过程作为一种独产的审查活动贯穿于全部软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其次要职责是:检查开发和管理活动是否与拟定的过程计谋、尺度和流程分歧；检查工作产品是否遵守模板规定的内容和格式.此文档从软件开发过程的各个阶段来描述软件质量包管过程.1.计划阶段目的和范围：项目计划过程的目的是计划并履行一系列须要的活动，以便在不超出项目预算和日程安插的前提下，将优良的产品交付给客户.项目计划过程适用于公司的所有项目，但每个项目可以根据各自的分歧情况对该过程进行裁剪.进入尺度：⏹项目启动会议曾经结束；⏹在项目的生命周期中，根据项目的跟踪结果，须要对项目计划进行点窜和完美.输入：⏹项目启动陈述；⏹项目提案书；⏹项目相干文档；⏹组织财富库中以往类似的经验文档.退出尺度：项目计划已通过评审、批准并确立.输出：评审后的项目计划文档包含：⏹软件开发质量计划；⏹软件配置管理计划.过程描述：项目计划包含3个须要在项目中履行和管理的次要计划，如下：⏹软件项目管理计划；⏹软件项目质量管理计划；⏹软件配置管理计划.软件项目管理计划涉及项目中所有与项目管理相干的成绩（从项目开始到结束）.软件项目质量管理计划涉及与质量相干的需求，这些须要在产品中实现，并包管用于构筑产品的项目过程.因为质量是产品创建的一部分，所以将软件项目管理计划和软件项目质量管理计划合成一个计划文档，称为软件开发质量计划.软件配置管理计划用于管理与配置管理相干的需求，这些需求与工作产品和可交付产品有关.该计划的目的在于：为履行软件工程相干活动提供根据，并在全部开发和保护过程中对软件项目进行管理.可以使用分歧的检查表来拟定软件开发质量计划和软件配置管理计划.如下每个计划都将包含以下3点：⏹目标；⏹履行方法；⏹当前形态.前两点不会经常变动，但第三点则被认为会在履行跟踪时被点窜.是以，前两点通常被直接放到计划中，而第三点则以链接的方法放到计划中.（1）拟定软件开发质量计划软件开发质量计划包含软件项目管理计划、软件项目质量管理计划.①拟定软件项目管理计划软件项目管理计划的次要内容包含基础设施计划，进度计划（包含各品种型的估算）、风险管理计划、项目培训计划、履行计划、客户管理计划.⏹基础设施计划基础设施计划包含项目开始履行前必须到位的所有需求，它须要解决以下成绩：软件工程需求、基础设施需求、角色和职责、内内部接口、过程需求、常识和技能需求.⏹进度计划进度计划涉及拟定合理可用的项目进度.在拟定项目进度时，须要进行上面的估算：规模（Size）、工作量（effort）.项目进度须要描述以下内容：履行的活动、估算的人时、投入的人员、义务人和时间线、里程碑事件的标识.⏹风险管理计划风险管理包含：标识风险事件（与管理相干的风险、与履行相干的风险，与客户相干的风险等）、评估风险并设定风险优先级、拟定风险缓解和应急计划并跟踪该计划.⏹项目培训计划根据项目及人员结构拟定项目培训计划，包含营业领域常识、技术、工具等方面的培训计划.⏹履行计划项目履行计划包含了与履行当前项目关系最大的生命周期模型.该计划对组织级履行模型进行了裁剪.项目生命周期模型通常包含：项目履行的阶段、各阶段的输入和输出、可交付的产品、须要迭代（反复）的阶段.②拟定软件项目质量管理计划拟定软件项目质量管理计划包含如下次要内容：⏹项目设定的质量尺度；⏹同级评审计划：同级评审计划中描述了在分歧的软件生命周期开发阶段，对分歧的工作产品所采取的同级评审类型；⏹测试计划：测试计划包含对可履行文件/模块或全部零碎将要进行的各种测试.根据项目测试过程来拟定测试计划；⏹度量管理计划：通过裁剪组织级的度量过程来拟定项目度量管理计划.⏹缺陷预防计划：管理、开发和测试人员互相配合拟定缺陷预防计划，防止已识此外缺陷再次发生；⏹过程改进计划：项目级过程改进的机会要记录到过程改进计划中.这些机会次要来源于度量分析、缺陷预防分析和标识出的好的或可防止的实践.（2）拟定软件配置管理计划软件配置管理计划次要包含以下内容：⏹软件配置管理计划组织；⏹角色和职责；⏹开发/保护配置管理计划，包含可配置项的标识、命名商定、目录结构、访问控制、变动管理、基线库创建、放入/提取（Check in/Check out）机制、版本控制；⏹产品配置管理，包含产品中部件的可跟踪性，产品的版本设定和发布、交付的配置管理（标识出要交付的产品构成）、需求配置管理（需求基线的确定、产品版本与划定基线的需求版本之间的关系）、配置审计.验证：同级评审人员和软件质量包管人员必须对项目计划进行评审，批准后项目才干付诸实施.配置控制：项目经理保管所有项目计划文档.对所有项目计划文档都要进行配置管理.项目结束后，所有的项目计划文档都要保管到组织财富库中，仍受配置控制.QA检查清单：QA检查清单包含：⏹软件开发质量计划；⏹软件配置管理计划.该阶段要确保拟定了软件开发质量计划和软件配置管理计划.2.需求分析阶段目的和范围：需求说明和需求管理过程的目的是为了包管开发组在开发期间对项目目标和生产出最初产品的目的有一个清晰的理解.软件需求规格说明书将作为产品测试和验证是否适合须要的基础.对于需求的变动，它可能在开发项目期间的任何时间点发生，需求的变动将要影响日程和承诺的变更，这些变更须要和客户所提出的请求相分歧.进入尺度：⏹计划曾经被批准，而且项目全体的基础设施是可用的；⏹软件的需求曾经被需求收集小组捕获；⏹对曾经构成了基线的软件需求规格说明书有变动的请求时.输入：⏹软件的需求说明书；⏹变动需求的请求.退出尺度：⏹软件需求规格说明书曾经经过评审并构成了基线；⏹对曾经构成基线的软件需求的变动进行了处理；⏹构成基线的软件说明书曾经经过客户批准；⏹验收尺度曾经完成；⏹所有评审的成绩都曾经解决.输出：⏹经过批准并构成基线的软件需求规格说明书；⏹对受影响组件的从头估算文档；⏹验收测试尺度和测试计划.过程描述：这个过程次要处理以下两种活动：需求说明和需求管理.需求说明指的是需求过程中构成基线的主体，它是当前进一步的设计和测试的基础.另外，在软件开发过程中，会经常碰到因为客户又有新需求或开发组本身对项目有了更清楚的理解或认识，要对需求进行变动.在对最初的需求说明书进行变动时，要用到需求管理过程.（1）需求说明需求说明过程次要包含以下任务：⏹履行需求分析⏹定义需求规格说明书⏹定义验收尺度⏹评审说明书和验收尺度.①履行需求分析分析收集到的需求和在提案中可用的需求.这个任务请求需求说明书应当在完好性、分歧性、清晰性和可测试性上达到比较合理的程序.②定义需求说明书基于对需求的分析编写软件需求规格说明书.这个文档应清晰记录以下内容：⏹目标和范围；⏹功能需求；⏹用户接口；⏹输入输出；⏹模块之间的接口；⏹功能需求；⏹特殊用户需求.如果需求不清晰或模糊，就须要筹办原型，通过评估原型来发生需求说明书.③定义验收尺度基于对之前步调收集的需求规格说明书，建立测试尺度，验证的解决方案.所有的需求应当可能拟定测试尺度.这个测试尺度将成为客户批准终极产品的根据，是以请求在拟定客户尺度时要经常紧密的与客户进行交流沟通.④评审需求分析说明书和测试尺度因为是开发项目的基础，所以需求规格说明书和验收尺度须要由项目组的同级人员进行评审.（2）需求管理需求管理过程包含以下6个任务：⏹记录变动请求；⏹分析受到影响的组件；⏹估算需求变动成本；⏹从头估算所有产品的交付日期和时间；⏹评审受影响组件；⏹获得客户的批准.①记录变动请求；构成基线的需求说明书的变动可能是由客户提出的，也可能是因为设计或编码阶段开发人员根据一些限制或优化而提出的.所有需求变动必须经过客户的批准，而且必须是可行的.任务需求变动可以由组织本人定义开始时间，而且所有需求变动须要记录到变动登记表中.②分析受到影响的组件；任何经过批准的变动须要在全部项目组范围内进行受影响组件分析.③估算需求变动成本；项目成本与需求变动有关.任何规模的变动对于成本来讲都是一种损耗.如果一个受影响组件是非常次要的，那么可行性须要从头进行成本估算.④从头估算所有产品的交付日期和时间；如果没有考虑无效的缓冲，成本的变更可能会影响全部项目的交付时间.在交付时间内的任何实质的变动都须要再同用户商经过议定定.⑤评审受影响组件；在这个步调中所有相干的受影响组件须要进行评审，项目负责人根履行此项任务.⑥获得客户的批准.这个过程的最初一项任务是获得客户的签字.客户应当同意曾经构成基线的软件需求说明书、验收尺度和已记录的受影响组件的变动.验证：项目经理要定期的检查需求规格说明书和项目需求管理的各个方面；⏹软件质量包管人员要定期的对需求分析过程履行独立的评估.配置控制：⏹软件需求规格说明书须要严酷的配置控制；⏹所有的变动请求须要被管理和控制；⏹用于跟踪的度量文档须要管理和控制.QA检查清单：质量包管检查清单包含：⏹软件需求规格说明书；⏹变动需求跟踪记录；⏹验收测试尺度与测试计划.该阶段要确保客户提出的需求是可行的，确保客户了解本人提出的需求的含义，而且这个需求能够真正达到他们的目标，确保开发人员和客户对于需求没有曲解或曲解，确保按照需求实现的软件零碎能够满足客户提出的需求.3.设计阶段目的和范围：本过程所关注的是把需求（用户需求说明书和软件需求规格说明书）转酿成为如何实现这些需求的描述.次要包含以下两个阶段：⏹概要设计；⏹具体设计.软件设计过程次要包含以下活动：⏹体系结构设计；⏹运算方法设计；⏹类/函数/数据结构设计；⏹建立测试尺度.进入尺度：⏹产品需求曾经构成了基线；⏹须要设计解决方案；⏹新的或点窜的需求须要改变当前的设计.输入：⏹构成基线的需求（用户需求说明书和软件需求规格说明书）.退出尺度：⏹设计文档曾经评审并构成基线；⏹测试尺度、测试计划可行.输出：⏹概要设计文档；⏹具体设计文档；⏹测试计划；⏹项目尺度；⏹选择的工具.过程描述：设计过程包含概要设计和具体设计两个阶段.（1）概要设计这个阶段包含以下的任务：结构设计、逻辑设计、项目尺度定义、零碎/集成测试计划的创建，并要进行同级评审.概要设计模板、零碎/集成测试计划模板在本阶段将被使用.①结构设计在这个步调中，完成软件解决方案的基础规划设计.继软件规划设计以后，利用程序被分解成基础模块/组件，目的是为了实此刻模块内的高聚合和模块之间的松耦合.通常情况下，模块的划分是基于概要设计中的功能需求而定的.②运算方法设计在这个步调中，完成软件零碎解决方案与利用程序的转换逻辑设计.设计模块接口和利用需求的次要逻辑.在决定通用算法之前，通常须要一些模型.③定义项目尺度在这个步调中，所有的项目开发尺度被定义.具体设计/编码尺度要同实际履行的分歧.拟定尺度时还要考虑尺度将来的扩展性、灵活性和方便性.④创建零碎/集成测试计划基于对概要设计的理解，零碎和集成测试计划被拟定出来.验证最初生产的产品达到了设计请求，通常采取基于黑盒的功能或功能检查.⑤评审设计作为所有开发阶段基础的概要设计是非常次要的，是以须要进行同级评审，由能力强的高级软件工程师构成的同级评审小组，以确保完成了合适的软件解决方案设计.（2）具体设计这个阶段包含以下任务：具体设计和筹办单元测试计划.在这个阶段，须要使器具体设计模板和单元测试计划模板.①类/函数/数据结构设计根据项目所采取的设计方法（软件结构化设计方法/面向对象设计方法）进行类、函数及数据结构的设计.所有的用户界面、形态转换和相干的数据库具体描述在本阶段被建立.②创建单元测试计划测试计划应当包含要被测试的每一个模块的每一个元素，例如：⏹与需求的完好分歧性；⏹与其它元素的分歧性；⏹在功能上的请求.单元/功能测试采取完好透明的白盒/玻璃盒测试方法，对于测试者来讲，实际运转的代码是可见的.③评审具体设计具体设计阶段的输出是代码编写工作的基础，是非常次要的，是以须要在项目组中很好的进行评审.评审小组负责评审和清除那些在具体设计中与采取的方法纷歧致的成绩.（3）选择有效工具在具体设计完成以后，零碎在解决方案曾经非常清晰.这时候，项目组须要选择用来提高软件质量的工具.这些工具要发生以下感化：⏹提高质量；⏹提高生产力；⏹缩短开发周期.验证：⏹项目管理者分析概要设计满足需求的程序；⏹项目管理者不定时的监督具体设计说明书的创建工作；⏹项目管理者通过定期的分析在设计阶段收集的数据来验证设计过程履行的无效性；⏹质量包管（QA）人员通过验证发生的工作产品和做独立的抽样检查来验证产品的无效性；⏹质量包管（QA）人员通过分析项目的度量数据和对过程的走查来验证设计过程的效性.配置控制：⏹所有的概要设计文档、具体设计文档和零碎/集成测试计划须要进行严酷的配置控制；⏹跟踪的度量数据须要进行管理和控制.质量包管（QA）检查清单：质量包管（QA）检查清单包含：⏹概要设计文档；⏹具体设计文档；⏹测试计划（零碎/集成/单元）；⏹项目尺度.在概要设计阶段，要确保规格定义能够完好符合、撑持和覆盖前面描述的零碎需求；可以采取建立需求跟踪文档和需求实现矩阵的方式，确保规格定义满足零碎需求的功能、可保护性、灵活性的请求；确保规格定义是可以测试的，而且建立了测试计谋；确保建立了可行的、包含评审活动的开发进度表；确保建立了正式的变动控制流程.在具体设计阶段，要确保建立了设计尺度，而且按照该尺度进行设计；确保设计变动被精确跟踪、控制、文档化；确保按照计划进行设计评审；确保设计按照评审原则评审通过并被正式批准之前，没有开始正式编码.4.编码阶段目的和范围：编码过程的目的是为了实现具体设计中各个模块的功能，能够使用户请求的实际营业流程通过代码的方式被计算机识别并转化为计算机程序.编码过程就是器具体的数据结构来定义对象的属性，器具体的说话来实现营业流程所暗示的算法.在对象设计阶段构成的对象类和关系最初被转换成特定的程序设计说话、数据库或者硬件的实现.进入尺度：⏹设计文档曾经构成基线；⏹具体设计变动编写终了并通过评审，而且代码须要变动时；⏹对于保护项目，保护需求分析曾经构成基线，可进行代码的变动；⏹用于编码的测试尺度曾经拟定.输入：⏹具体设计文档；⏹特定项目的编码规范；⏹相干的软、硬件环境；⏹保护分析文档；⏹测试计划.退出尺度：具体设计中所有模块的功能全部被实现，并通过自我代码审查，编译通过.输出：⏹已完成的、须要进行测试的代码；⏹代码编写规范的更改建议.过程描述：编码过程是把具体设计中的各个模块功能转化为计算机可识别代码的过程，是以程序员在进行编码时，必定要细心认真，切勿有半点疏忽.编码过程通常情况下占全部项目开发时间的20%摆布，为了代码达到高质量、高尺度，代码编写过程必定要合理规范.编码过程次要包含以下几项活动：⏹拟定编码计划；⏹认真浏览开发规范；⏹编码筹办；⏹专家指点，并填写疑问或成绩表；⏹理解具体设计书；⏹编写代码；⏹自我审查；⏹提交代码；⏹更改代码.编码过程流程如下图所示.（1）拟定编码计划在编码之前一周，项目经理要根据具体设计中的模块划分情况拟定编码计划.编码计划的次要内容如下.①本次编码的目的在拟定编码计划时，必必要明确编码目的.②编码人员构成在编码之前，要确定本次编码的人员构成：选择编码人员时要考虑以下几点：义务心、技术能力、服从认识、努力程序、编码效力、编码质量.③编码任务分配在编码之前，必定要为每个编码人员划分好本人所负责的模块，而且要规定各个模块的编码开始，结束日期.（2）认真浏览开发规范为了实现编码的规范统一，须要拟定编码规范.有的项目，客户也会提供一些开发规范用来对本次编码进行束缚.编码人员在编写代码之前必定要理解并把握相干编码规范的所有内容.如许有助于当前编码工作的规范统一.如果本次编码采取的是公司本人的开发规范，编码人员在浏览的过程中，如果发现编码规范出缺乏或分歧理的地方，可以编写开发规范建议书提交给项目经理，项目经理再和软件质量包管人员取得联系以决定是否要对目前的编码规范进行更改.（3）编码筹办在进行编码之前还要进行一些相干的筹办.①软硬件环境配置：包含编码工具、配置管理工具、数据库和一些须要的辅助工具.②了解程序设计说话的特性，选择良好的程序设计风格：程序设计风格是程序设计质量的一个次要方面，具有好的设计风格的程序更容易浏览和理解.（4）理解具体设计书因为项目模块功能的复杂性，即使再具体的设计也会有表达不敷精确的地方，是以在编写代码之前，必定要把每个模块的具体设计思路弄清楚.如果编码人员在理解具体设计时有困惑，必定要扣问具体设计人员.为了包管编码人员对具体设计的理解的精确性，采取以下方法：①具体设计同级评审时，让编码人员介入；②让编码人员对具体设计进行讲解；③让编码人员根据本人的理解画出流程图，由具体设计者确认.如果编码人员在理解具体设计书的过程中存在疑问，应填写具体设计疑问列表提交给项目经理或具体设计人员.（5）专家指点在编码之前或编码过程中，为了包管编码工作的顺利进行和代码质量，项目经理要根据目前编码人员的技术能力或开发进度情况约请本项目组内部或内部专家对编码人员进行指点.指点的内容次要包含以下两方面的内容.①对于本次编码有关的营业进行指点：对编码人员进行营业上的指点，有助于编码人员对具体设计的理解.②对技术进行指点：通过对编码人员的技术指点，可以解答编码人员在技术上的一些疑问.（6）编写代码在很多的软件开发中，客户为了便于程序的可保护性，常常会对程序代码编写过程做出一些规定，如变量的命名规则、书写规范和公共处理等，所以这就请求编码人员要熟悉这些请求和规范，并严酷的恪守这些规范，如果客户没有规定，就要按照公司的规定履行.①画出程序的流程图程序的流程图又称程序框图，用来描述软件设计，是历史最长、使用最广泛的方法.在编码之前，必定要先画好程序的流程图，这对一个复杂的程序来说是非常须要的，如许做了当前，可以使你在编码阶段达到事半功倍的后果，而且对于代码的精确性和质量都是一个很好的包管.②代码的模块化模块化是把零碎分割成能完成独立功能的模块代码，明确规定各个模块代码及其输入输出规格，使模块代码的接口不会发生混乱.③程序的注解程序的注解对于程序的浏览与理解起侧次要的感化.注解次要分两部分.程序块头的注解，主如果模块功能的说明、输入输出变量的说明、算法的说明、程序员姓名和程序完成和变动的日期列表.这些主如果满足管理者的须要，管理者易于把握哪些程序是由哪个编码人员负责的.程序内部的注解，对程序中的一些难以理解的语句以上正文，以使浏览者容易理解设计者的意图，易于理解程序.如许的程序具有很强的可读性和可保护性.④数据类型/变量说明数据说明的次序应尺度化，如按数据类型或者数据结构来确定数据说明的次序，次序的规则在数据字典中加以说明，以便在测试调试阶段和保护阶段可以方便的查找数据说明的情况；⏹当对在同一个语句中的多个变量加以说明时，应按英文字母的顺序排列；⏹在使用一个复杂的数据结构时，最好加正文语句；⏹变量说明不要漏掉，变量的类型、长度、存储及其初始化要精确.⑤语句构造⏹不要为了节省空间把多个语句写在同一行；⏹尽量防止复杂的条件；⏹对于多分支语句，应当把出现可能性大的情况放在前面，把较少出现的分支放在后面，如许可以加快运算时间；⏹防止大量使用轮回嵌套语句和条件嵌套语句；⏹利用括号使逻辑表达式或算术表达式的运算次序清晰直观；⏹每个轮回要有终止条件，不要出现死轮回，也要防止不成能被履行的轮回.⑥程序效力程序效力次要指处理工作时间和内存容量这两方面的利用率，在程序满足了精确性、可理解性、可测试性和可保护性的基础上，提高程序的效力也是非常须要的.在编码过程中，必定要严酷按照规定的开发规范进行编码，。
软件项目检查表
软件项目检查表
项目概述
该软件项目检查表旨在帮助团队对软件项目进行全面的检查和
评估，以确保项目的顺利进行和高质量的交付。
本检查表包括多个
方面，包括项目计划、需求分析、设计、开发、测试和部署等环节。
项目计划
- 项目是否有明确的目标和可行的计划？
- 是否有详细的项目计划及时间表？
- 是否有项目经理负责监督和管理项目进度？
需求分析
- 是否完整、准确地收集和记录了项目的需求？
- 是否对需求进行了合理的分类和优先级排序？
- 是否与相关利益相关者沟通确认了需求？
设计
- 是否进行了系统的架构设计和模块设计？
- 是否充分考虑了扩展性和可维护性等因素？
- 是否进行了界面设计和交互设计？
开发
- 是否按照设计文档进行开发工作？
- 是否按照编码规范完成代码编写？
- 是否进行了代码评审和单元测试？
测试
- 是否制定了详细的测试计划和测试用例？
- 是否进行了功能测试、性能测试和安全测试等多个方面的测试？
- 是否及时修复了测试中发现的缺陷和问题？
部署
- 是否制定了可靠的部署计划？
- 是否进行了部署前的完整测试和验证？
- 是否提供了必要的文档和培训？
运维支持
- 是否确保了系统的可靠性和稳定性？
- 是否建立了监控和报警机制？
- 是否保障了系统的安全性和数据的完整性？
以上是软件项目检查表的主要内容，通过对每个方面的检查和评估，能够有效提升软件项目的质量和成功交付的概率。
请针对具体项目的不同需求和情况，适当调整和完善该检查表。
软件质量管理计划模板
XXXX项目质量保证计划***科技（北京）有限公司版本历史目录目录 (3)1.介绍 (4)1.1目的 (4)1.2术语 (4)1.3参考资料 (4)2.管理 (4)2.1职责 (4)3任务 (5)3.1过程与产品质量检查计划 (5)3.2 参与技术评审的计划 (6)3.3 审计流程 (7)4.输出产物 (7)1.介绍1.1目的本质量保证计划制定(某项目)项目质量保证工作相关的一些措施和规定，作为质量保证工作的整体指导方向，是质量保证人员展开质量活动的依据，也是检查项目质量的基础。
本质量保证计划的目的是保证所发布的(某产品)能够满足《需求规格说明书》中规定的各项需求。
1.2术语1.3参考资料《**-项目计划》2.管理2.1职责3任务3.1过程与产品质量检查计划提示：质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果，并估计检查时间和人员。
注意：对某些过程域的检查应当是周期性的而不是一次性的，例如配置管理、需求管理等。
3.2 参与技术评审的计划提示：（1）技术评审计划一般由研发经理或者项目的技术负责人制定。
（2）质量保证员应当参与并监督重要工作成果如需求、设计、代码的技术评审。
质量保证员根据技术评审计划，制定“参与技术评审”的计划。
（3）工作成果的技术评审有两种形式：正式技术评审（FTR）和非正式技术评审（ITR）。
FTR需要举行评审会议，参加评审会议的人数相对比较多。
ITR形式比较灵活，一般在同伴之间开展或以邮件等的方式进行评审。
3.3 审计流程提示：此处定义针对软件工作产品的审计过程。
下面是审计过程示例：1.确定当前要审计的软件工作产品。
2.确定与当前审计有关的标准。
3.使用《QA产品审计报告》中的检查表实施工作产品审计。
4.使用《QA过程审计报告》中的检查表实施工作过程审计。
5.制定和发布《软件质量保证报告》6.对不能在项目组内部解决的不符合问题报告给高层经理。
7.对不符合问题进行记录、跟踪直至解决。
软件设计与开发评审检查表
是否执行输入、输出、接口和结果的错误检查？
是否对所有错误情况都发出故意义的信息？
对特殊情况返回的代码是否和已规定的全局定义的返回代码相匹配？
是否考虑到意外事件？
易测性
是否可以对每个单元进行测试、演示、分析或检查来说明它们是满足需求的？
该套系统是否能用增量型的方法来集成和测试？
可追溯性
是否各部分的设计都能追溯到需求说明书的需求？
是否所有的设计决策都能追溯到本来拟定的权衡因素?
所继承设计的已知风险是否已拟定和分析？
具体设计检查表
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
检查项
Y/TBD/N/NA
清楚性
所有单元或过程的目的是否都已文档化？
一致性
数据元素的命名和使用在整个单元和单元接口之间是否一致？
所有接口的设计是否互相一致并且和更高级别文档一致？
对的性
是否解决所有条件 （大于、等于、小于零、switch/case）？ 是否存在解决“case not found”的条件？
是否对的地规定了分支（逻辑没有颠倒）？
数据使用
是否所有声明的数据都被实际使用到？
Y: 是 TBD: 不拟定 N: 不是 NA:不合用
备注
检查项
Y/TBD/N/NA
清楚性
系统的目的是否已定义？
是否对关键术语和缩略语进行定义和描述？
所使用的术语是否和用户/客户使用的一致？
需求的描述是否清楚, 不模糊？
是否有对整套系统进行功能概述？
是否已具体说明了软件环境 (共存的软件) 和硬件环境 (特定的配置)？
软件项目验收文档目录
卷内文件目录序文件文件名称编制单位页页备号1 编号工程管理文件次数注1.1 合同相关文件1.1.1 政府采购合同书及补充协议书政采中心、通信中心1.1.2 政府采购中标通知书政采中心1-1 1 复印件1.1.3 廉政合同通信中心1.2 承建单位资质文件1.3 施工组织设计及报审表1.4 开工申请1.4.1 工程情况说明1.4.2 项目经理任命书1.4.3 项目组成员及联络名单1.4.4 项目用章授权1.4.5 开工报告1.5 开工令1.6 工程实施方案及报审表1.7 技术交底文件1.8 监理联系单1.9 监理通知单1.10 监理通知回复单2 工程质量控制文件2.1 需求调研2.2.1 需求调研计划/提纲及报审表2.2.1 需求调研记录及确认2.2.2 需求规格说明书2.2 软件开发计划及报审表2.3 质量保证计划及报审表2.4 配置管理计划及报审表2.5 代码编写规范及报审表2.6 代码审查记录及报审表2.7 模块开发卷宗及报审表2.8 软件测试（单元、集成、系统）2.8.1 软件测试计划/方案2.8.2 缺陷修改记录2.8.3 软件功能/性能测试报告2.9 软件部署方案及报审表2.10 用户手册2.11 维护手册2.12 产品验收相关文件2.12.1 设备/材料报审表及报验清单2.12.2 原厂清单、合格证、质检报告2.12.3 软件产品相关授权文件2.12.4 产品安装、调试记录2.12.5 产品功能/ 性能检查表2.13 接口设计说明书2.13.1 统一登录、统一权限接口规范2.13.2 短信平台接口规范2.14 系统运行管理办法2.15 部省联调测试2.15.1 联调测试方案及报审2.15.2 联调测试报告2.16 试运行相关文件2.16.1 试运行方案及报审2.16.2 试运行记录2.16.3 试运行报告2.17 培训相关文件2.17.1 培训方案及报审2.17.2 培训签到及培训记录2.18 自检报告2.19 验收方案及报审3 工程进度控制文件3.1 工程总进度计划报审3.2 进度计划横道图3.3 月进度考核4 施工原始记录4.1 施工周报4.2 施工月报4.3 施工照片1. 文件编号规则 TJFX ·1-001 （表示统计分析文件第一部分第 001 文件）；2. 编制单位根据实际填写；3. 页次为本部分起止页码（例1-15 ）；4. 页数为本部分页数（例 15 页）；5. 备注（复印件 /原件）。
质量保证计划
对实施过程中的数据和信息进行 记录和报告，以便对质量保证计 划的实施效果进行分析和评估。
监控与评估阶段
监控实施效果
通过定期检查、审核等方式，监控质量保证计划的实 施效果，确保其符合预期目标。
评估改进机会
根据实施效果和反馈信息，评估质量保证计划的改进 机会，持续优化计划内容。
调整控制措施
根据评估结果，调整控制措施，以更好地满足产品质 量要求和提高生产效率。
03
质量保证计划的工具与技 术
质量检查表
总结词
质量检查表是一种用于记录和检查产品或服务质量的工具。
详细描述
质量检查表是一种标准化、结构化的表格，用于记录产品或服务的质量特性、要求和检查结果。它通 常包括检查项目、检查方法、检查结果等内容，有助于确保产品或服务的质量符合规定要求。
流程图
总结词
流程图是一种用于描述过程或操作流程的图形化表示工具。
统计过程控制
总结词
统计过程控制是一种基于数据的控制和管理 过程的方法。
详细描述
统计过程控制使用统计技术来分析和控制生 产或服务过程，确保过程的稳定性和一致性 。通过收集和分析数据，统计过程控制可以 识别过程的异常波动，采取相应的措施进行 调整和控制，提高产品质量和生产效率。
抽样技术
总结词
抽样技术是一种从总体中选取部分样本进行检验的方法。
01
原材料问题
原材料质量不稳定或不符合标准， 导致产品性能下降。
设备故障
设备维护不当或故障，影响产品质 量和生产效率。
03
02
生产工艺问题
生产过程中工艺控制不严格，导致 产品不符合规格要求。
人员操作失误
操作人员技能不足或疏忽，导致产 品不符合要求。
软件开发项目检查记录
软件开发项目检查记录日期：[填写日期]项目名称：[填写项目名称]1. 项目背景在软件开发过程中，进行定期的项目检查是确保项目质量和进度的关键一环。
本次软件开发项目检查记录旨在对项目进展情况进行全面梳理和评估。
2. 项目概况本项目为[填写项目名称]，旨在开发[填写项目目标]。
项目启动于[填写启动日期]，预计完成日期为[填写完成日期]。
3. 检查内容及结果3.1 进度评估项目进度是保障项目按时完成的重要指标之一。
根据本次检查，项目进度评估如下：- 需求收集阶段：已完成，达到预期目标。
- 概要设计阶段：完成进度为70%，与计划相符。
- 详细设计阶段：已完成，达到预期目标。
- 编码与单元测试阶段：完成进度为50%，稍有偏低。
- 综合测试阶段：尚未开始。
针对进度偏低的编码与单元测试阶段，需加强团队协作，提高效率，以确保后续阶段按计划进行。
3.2 质量评估项目的质量是保障软件可信度和可用性的重要保证。
根据本次检查，项目质量评估如下：- 需求规格说明书：规范明确，无明显缺陷。
- 概要设计文档：设计思路清晰，符合要求。
- 详细设计文档：设计文档完整，细节准确。
- 编码规范：编码规范符合标准，代码结构清晰。
- 单元测试：单元测试用例覆盖全面，测试结果符合预期。
在保证项目进度的前提下，建议项目团队继续加强对软件质量的控制和评估，特别是在编码与单元测试阶段加大工作量和质量监控力度。
3.3 风险评估项目进行中不可避免地存在着各种风险和不确定性因素。
根据本次检查，项目风险评估如下：- 人员流失风险：目前项目团队成员稳定，风险较低。
- 需求变更风险：需求稳定性良好，变更请求控制在可接受范围。
- 技术难题风险：目前无明显技术难题，项目进展顺利。
项目团队需要继续关注项目的风险因素，及时采取相应的风险应对措施，以确保项目的顺利进行和最终交付。
4. 下一步计划综合以上的检查结果，制定下一步的项目计划如下：- 完成编码与单元测试阶段，提高进度并保证代码质量。
软件过程检查表
1.过程检查要素表2.过程打分2.1.过程打分原则：1)过程打分占整个项目得分的30％，以30分为满分，最低分不低于9分。
2)不同的项目可以从标准软件过程中剪裁得到项目定义过程，因此各项目包含的软件过程是不同的，为了使软件过程数目不同的项目，仍以合理的方式进行过程打分，需对剪裁后的软件过程数目进行换算，从而不因剪裁而失分。
3)SQA人员对经剪裁的软件过程的检查内容和实施情况进行剪裁。
4)项目级的软件过程剪裁必须得到高级经理，质量管理部经理和项目SQA人员的检查和认可；检查内容和实施情况剪裁必须得到项目经理和受审计人员的认可。
5)软件过程检查打分的依据是“过程检查表”。
2.2.打分步骤：1)依据标准过程定义项目过程，得出项目过程数N。
2)每个项目过程的得分M＝30 / N。
3)采用“过程检查表”，对各个过程进行检查和打分。
4)定义“过程检查表”中的实际检查内容项个数为X，每项标准得分10分，因此每个“过程检查表”的最高得分A = 10X。
5)实际检查时，对“实施情况”一栏中每个条款进行打勾“”,因此实际每项得分Bj=（打勾条款数/ 该项实际检查总条款数）×10。
6)每个过程的实际得分Bi=∑1x Bj。
7)每个过程的换算得分B=Bi /A ×M。
8)若某个过程发生多次z，则该过程得分B=(∑1zB)/z 。
9)项目的过程得分C=∑1NB 。
10)为确保项目组的基本得分不低于9分，因此各过程打分不得低于9/N分，低于此分，以9/N分计算。
2.3.例子：某项目计划进行5个阶段的审计：计划过程，需求过程，设计过程，测试过程，计划跟踪和监督过程，其中计划跟踪和监督过程执行两次，其他各一次则每阶段得分M=30/5=6;第一次计划跟踪和监督过程检查项共15项，实际由于变更未发生检查了13项, 标准分为A=13×10＝130，实际检查得分Bi=123则该阶段得分B1=123/130 * 6=第二次计划跟踪和监督过程，实际检查了15项，标准分为15×10＝150；实际检查得分140。
软件开发质量保证计划 检查 跟踪 保证报告全套
软件开发质量保证计划、检查、跟踪、保证报告过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”而“差的过程”将产生“差的产品”。
人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心产品质量。
提高产品质量有三种基本方法：◆质量保证。
质量保证人员通过有计划地检查“工作过程以及工作成果”是否符合既定的规范，来监控和改进“过程质量”与“产品质量”。
◆技术评审。
请同行专家、技术人员对工作成果进行评审，尽早发现工作成果中的缺陷。
◆测试。
通过运行测试用例来找出软件中的缺陷。
例如单元测试、集成测试、系统测试、验收测试等。
质量保证既关心过程质量又关心产品质量。
如果“工作过程以及工作成果”不符合既定的规范，那么产品的质量肯定有问题。
基于这样的推理，质量保证人员即使不是技术专家，他也能够客观地检查和监控产品的质量。
这是质量保证方法富有成效的一面。
但是“工作过程以及工作成果”符合既定的规范却并不意味着产品的质量一定合格，因为仅靠规范无法识别出产品中可能存在的大量缺陷。
这是质量保证方法的不足之处。
所以单独的“质量保证”其实并不能“保证质量”。
技术评审与测试关注的是产品质量而不是过程质量，两者的技术强度比质量保证要高得多。
技术评审和测试能弥补质量保证的不足，三者是相辅相成的质量管理方法。
我们在实践中不能将质量保证、技术评审和测试混为一谈，也不能把三者孤立起来执行。
让质量保证人员参加并监督重要的技术评审和测试工作，这是很好的方法。
把三者有机地结合起来，可提高工作效率，降低成本。
质量保证小组（Quality Assurance Group, QAG）有如下特点：◆质量保证小组在行政上独立于任何项目。
这种独立性有助于质量保证小组客观地检查和监控“过程以及产品的质量”。
◆质量保证小组有一定的权利，可以对质量不合格的工作成果做出处理。
这种权利使得质量保证小组的工作不会被轻视，并有助于加强全员的质量意识。
软件设计评审检查表
Y: 是 TBD:不确定 N: 不是 NA:不适用
检查项
Y/TBD/N/NA
完整性
该测试计划是否详细说明测试的大体方法和策略？
该测试计划是否详细说明所有测试活动的顺序？
该测试计划是否描述了将使用的软硬件系统环境?
该测试计划是否描述了测试活动中断和恢复的条件/情形？
该测试计划是否为所有测试定义了成功标准？
是否详细说明了参数的度量单位、取值范围、正确度和精度？
共享数据区域及其存取规定的映射是否一致？
可维护性
单元是否具有高内聚度和低耦合度（例如：对该单元的更改不会在该单元有任何无法预料的影响并对其它单元的影响很小）？
性能
是否该单元的所有约束例（如过程时间和规模）都被详细说明？
可靠性
初始化是否使用到缺省值，缺省值是否正确？
包括了数据流、控制流和接口的单元设计是否已清晰的说明？
完整性
是否已定义和初始化所有的变量、指针和常量？
是否已描述单元的全部功能？
是否已详细说明用来实现该单元的关键算法（例如：用自然语言或PDL）?
是否已列出该单元的调用？
依从性
该文档是否遵循了该项目已文档化的标准？
是否采用了所要求的方法和工具来进行单元设计？
该测试计划是否充分地描述了被测试的功能？
该测试计划是否明确地描述了不被测试的功能？
该测试计划是否充分地描述了测试基线？
对于阶段交付，该测试计划是否有在每一阶段建立测试基线给下一阶段使用？
该测试计划是否定义了足够和正确的衰退测试？
依从性
该测试计划是否依从了与开发有关的所有说明书、标准和文档？
一致性
是否已定义了测试顺序来匹配更高级别的文档所指定的集成顺序？
IATF16949-2016版内审检查表(new)
IATF16949内审检查表一、IATF16949的应用范围二、过程方法的使用三、IATF16949：2016的目标第二节组织环境（4）一、理解组织及其环境(4.1）二、理解相关方的需求和期望（4.2）三、组织环境(4）—经营计划四、确定质量管理体系的范围（4。
3）五、质量管理体系及其过程(4。
4）六、质量管理体系及其过程（4.4）—过程效率管理第三节领导作用（5) 一、领导作用和承诺（5。
1）二、以顾客关注为焦点(5.2）三、方针（5。
2）四、角色、职责和权限（5。
3）第四节策划（6）一、应对风险和机遇的措施（6。
1)二、质量目标及其实现的策划（6。
2）三、变更的策划（6。
3）第五节支持（7）一、资源管理总则(7。
1.1）二、人员(7。
1。
2)三、基础设施（7。
1。
3)四、过程运行环境（7。
1。
4）五、监视和测量资源总则（7.1.5。
1）六、测量系统分析（7。
1.5。
1。
1）七、校准/验证记录（7.1.5。
2.1)八、内部实验室要求（7。
1.5。
3.1）九、外部实验室要求（7.1。
5。
3.2)十、组织的知识(7。
1.6）十一、能力（7.2）十二、意识（7.3)十三、员工激励与授权（7.3。
2）十四、沟通(7。
4）第六节、形成文件的信息（7。
5)二、质量管理体系文件（7.5.1。
1）三、创建与更新(7.5.2)四、形成文件的信息的控制（7。
5.3）五、记录保存，工程规范（7。
5.3。
2。
1,7。
5.3..2.2）第七节、运行（8) 一、运行策划和控制（8.1）二、顾客沟通（8。
2.1）三、产品和服务要求的确定（8.2。
2)四、产品和服务要求的评审（8。
2.3）五、产品和服务要求的更改（8。
2.4）第八节、设计和开发（8。
3）一、总则，设计和开发策划（8.3。
1,8.3。
2）二、产品设计输入（8。
3.3。
1）三、制造过程设计输入(8。
3.3。
2)四、特殊特性（8.3。
3。
3）五、设计和开发控制（8.3.4)六、设计和开发控制(8.3。
设计和开发策划内审检查表模板
编号
检查内容
1
设计和开发的目的
确保后续的产品和服务的提供
2
设计和开发过程要求
应建立、实施和保持适当的设计和开发过程
3
产品和制造过程的设计和开发，应着重于错误预防，而不是探测
4
应对设计和开发过程形成文件
5
应对产品的设计和开发进行控制。说明：控制的目的是确保设计和开发依据策划的方式进行，并在必要的时候进行策划更新
18
使用多方论证方法的方面
19
设计和开发的策划输出应及时更新。说明：这些更新是依据设计和开发的进展、客户的需求和期望的变化、产品要求及标准的更变、资源需求的要求等而进行的
20
设计和开发策划应确定的内容
设计和开发阶段。说明：可以根据产品的特点、过程复杂程度、组织的水平、历史经验、和顾客的要求等因素来划分设计和开发阶段
13
顾客和使用者参与设计和开发过程的需求
14
对后续产品和服务提供的要求
15
顾客和其他相关方期望的设计和开发过程的控制水平
16
证实已经满足设计和开发要求所需的成文信息
17
设计和开发策划要求
应确保设计和开发策划涵盖组织内部所有受影响的利益相关者及其（适当的）供应链。说明：采购、供应商和维护功能也许会作为利益相关方被包括
21
设计和开发的评审活动。说明：明确活动的方式、时机、参与人员等
22设Leabharlann 和开发的验证活动23设计和开发的确认活动。说明：设计和开发的评审、验证和确认具有各自明确的目的，根据产品和组织的具体情况，可以单独或一起进行并记录
24
设计和开发的职责
25
GJB9001C-2017内审检查表
c) 避免和减少不利影响；
d) 实现改进。
6.1.2公司根据风险分析结果，策划应对这些风险和机遇的措施，包括规避风险，为寻求机遇承担风险，消除风险源，改变风险的可能性和后果，分担风险，或通过明智决策延缓风险。实施新实践，推出新产品，开辟新市场，赢得新客户，建立合作伙伴关系，利用新技术以及能够解决组织或其顾客需求的其他机会。明确如何在质量管理体系过程中整合并实施这些措施；评价这些措施的有效性。
应对风险和机遇的措施应与其对于产品和服务符合性的潜在影响相适应。
6.2 质量目标及其实现的策划
6.2.1公司策划并制定了质量目标，并在相关职能、层次和过程进行分解。质量目标策划，变更和实施中应与质量方针保持一致；可测量；考虑到适用的要求；与提供合格产品和服务以及增强顾客满意相关，予以监视；予以沟通；适时更新。
c) 确保质量管理体系要求融入与组织的业务过程；
d) 促进管理者在体系策划、运行中使用过程方法和基于风险的思维；
e) 识别公司质量管理体系所需的资源及其更新需要并配备这些资源；
f) 在公司内进行沟通，确保全员理解有效的质量管理和符合质量管理体系要求的重要性，积极主动参与和配合，通过考核、培训、分享知识、奖励制度，促使、指导和支持员工努力提高其素质，提高质量管理体系的有效性和管理绩效；
表1 外部相关方及要求与期望
相关方
要求与期望
法律法规及监管机关
符合法律法规要求
顾客、最终用户或受益人
提供的技术方案或研发的产品符合最初提出的要求
银行
有能力支付银行的款项
外部供应商
价格合理，结算及时，有规范的流程或手续
第三方认证服务机构
满足GJB9001C体系要求，持续改进质量管理体系
评审检查表
评审检查表
目录
1.项目计划检查表 (3)
2.需求规格阐明书检查表 (4)
3.概要设计阐明书检查表 (5)
4.具体设计阐明书检查表 (6)
5.编码检查表 (7)
6.测试用例检查表 (10)
7.产品验收和公布检查表 (11)
1.项目计划检查表
2.需求规格阐明书检查表
3.概要设计阐明书检查表
4.具体设计阐明书检查表
5.编码检查表
通过结合编码检查表和代码检查单，能够比较清晰地拟定代码问题的位置。
5.1.代码检查表
5.2.代码检查内容
备注：
1)激活：本列标注Y 的为激活的项目，表明这些项目必须被明确地自查（其它问题处在“顺
便被检查”的状态），在运行编码检查的时候，前期几乎全部项都要在激活状态；后期稳定后，保持8~10 个（或遵从目前规范）激活的检查项。
为了醒目，能够像此表这样将目前的激活项用亮黄色表达。
其中10~40 是编码错误，50~100 是设计错误。
3)检查项：全部检查项均为普通疑问句，当发现回答为“否”时，即存在一种缺点。
6.测试用例检查表
7.产品验收和公布检查表。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
评审的组织
以上资料是否提前2天发给参加评审的人员
（√）
是否指定评审会议主持人
（√）
评审的参与人
产品经理（PM）
（√）
系统分析员（SA）
（√）
测试经理（TM）
（√）
开发经理（DM）
（√）
配置管理员
（√）
SQA
（√）
项目外部相关组代表
（√）
评审的过程
项目描述
（√）
人员职责
（√）
项目估计
（√）
开发计划
（√）
是否有软件项目的工作量和成本估计
（√）
是否有关键计算机资源估计
（√）
开发计划
是否有项目资源描述，包括人员配备、职责与权限、人员及其技术职位、设备与支持工具等
（√）
是否明确定义项目开发主要阶段和每个阶段的输入、输出的软件工作产品及验证准则
（√）
是否有进度表
（√）
是否明确标识里程碑和评审点
（√）
是否说明项目开发中的使用的主要的开发工具和技术方法
时间：2014-05-06
请在（）内标注相关检查结果
√：检查通过
х：检查不通过需修改
其他标记：请注明原因
需要项目组外的人员和部门协助配合的，是否已经达成共识
（√）
进度表是否得到高层经理、项目经理和开发人员、测试人员的认同
（√）
开发目标和范围是否和需求一致
（√）
风险分析
（√）
评审结论
评审结论是否明确
（√）
评审遗留问题是否落实
（√）
评审报告
评审报告是否成文
（√）
评审报告是否发给参加评审的人员
（√）
项目SQA人员签名：张廷
（√）
是否说明本项目中使用到的规程、惯例、标准和约定
（√）
是否对项目组对外支持的工作量做出估计或者在进度中加以考虑
（√）
配置计划
是否有配置计划（具体见配置计划检查表）
（√）
测试计划
是否有测试计划（具体见测试计划检查表）
（√）
风险分析
是否有风险评估，包括标识风险，安排优先级和明确负责人、防范措施、截止日期
软件质量保证（SQA）软件开发计划评审检查表
项目名称
水专项数据中心
评审时间
2014-05-06
评审主持人
张廷
评审方式【√】会议【】邮件 Nhomakorabea文件齐备性
开发计划
（）
文件内容完整性
项目描述
是否明确阐述项目开发目标、范围描述
（√）
人员职责
是否明确说明项目人员职责
（√）
项目估计
是否有软件工作产品的规模及其可能的变化估计