下载文档原格式
软件质量包管过程之杨若古兰创作软件质量包管过程作为一种独产的审查活动贯穿于全部软件开发过程.质量控制人员类似于软件开发过程中的过程警察,其次要职责是:检查开发和管理活动是否与拟定的过程计谋、尺度和流程分歧；检查工作产品是否遵守模板规定的内容和格式.此文档从软件开发过程的各个阶段来描述软件质量包管过程.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.对不符合问题进行记录、跟踪直至解决。
卷内文件目录序文件文件名称编制单位页页备号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. 备注（复印件 /原件）。
软件开发项目检查记录日期：[填写日期]项目名称：[填写项目名称]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。
