以下是小编为大家准备的项目管理的质量保证计划，本文共6篇，希望对大家有帮助。
篇1：项目管理的质量保证计划
项目管理的保证
项目管理的主要目标是保证项目在规定时间内高质量的完成项目，项目管理包括了项目组开发各阶段的人员结构的配置，质量控制的实施方略，内部文档和产品文档的组织编写等各项工作。
开发项目按照规范化软件的生产方式进行生产，在生产流程上采用ISO9000的标准进行。项目开发参与的角色有项目经理，项目负责人，领域专家，系统分析员，程序员，测试组，技术支持部，质量监督组，文档组。下面就各个角色一一说明其主要职责。
项目经理
主要负责该项目开发商在开发和维护的过程中同客户的商务接洽和开发配合方面的事物，包括：项目合同的签定;提交开发计划给客户;组织客户与分析人员进行需求确定; 组织客户阶段性验收; 协调客户提供测试环境; 监督项目进度与质量; 提供开发人员所需的各种人力物力资源; 负责项目开发过程中客户、开发项目组、质量监督部，文档组等相关部门的联络与沟通。
项目的开发采用项目负责人责任制。项目的开发由项目负责人全权负责，负责的范围包括： 项目开发计划的制定; 开发方法的确定; 技术规范的编制; 项目各阶段的人员配给与人员之间的配合; 各阶段文档的生成和版本编号。
领域专家
主要责任是协同系统分析员认清领域边界，确定领域内容。领域专家可以由客户抽调技术骨干担任，也可以由开发商聘请担任。领域专家在开发过程中主要参与的阶段是系统需求分析，在明确了系统将来要完成的主要任务之后，领域专家的职责转向系统用户界面的确定上。开发出的系统能被客户接受的两个重要指标一个是系统正确性，即系统是否正确的完成了用户希望它完成的任务;第二就是系统操作的便捷性。便捷主要受到使用系统的客户的操作习惯的制约。领域专家往往是多年从事该项工作的人员，他们的使用习惯会对系统的易用性非常有帮助。领域专家参与的开发阶段受到开发方式的影响。
系统分析员
系统分析员是系统开发方法的贯彻者和系统实现的指导者。分析人员主要参与开发阶段的需求分析和系统设计两个阶段(这两个阶段并不是截然分开的，由开发方式的不同，可能会贯穿整个开发工期)。
首先系统分析员和领域专家一起对领域进行分析，确定领域边界和领域内容。在完成这项任务后，系统分析员应当提交《系统需求报告》。《系统需求报告》由领域专家确认之后交给质量监督组进行复审，复审完毕由文档组进行文档规范化，进行存档和版本编号，与此同时，规范化的《系统需求报告》由项目经理转交给客户进行复审(项目经理对《系统需求报告》的内容格式等有审查的义务)。
客户复审完毕之后通过项目负责人转交给系统分析员进行更新修正，并对版本进行升级。之后再经质量监督组和文档组等环节进行流转，直到该报告无须进行再流转为止。 接下来系统分析员的一项主要任务是对领域进行分析和映射，构造系统构架，即进行体系结构的设计。
参与的系统分析员在不止一个时，首先由分析员委员会进行体系结构设计，当体系结构基本确定之后，定义分组和分组之间的接口，特别对将来需要密切接口的部分要进行详细定义，包括彼此间的“通讯协议”，时间及方式等等。完成该项工作后必须产生《体系结构设计说明》。《体系结构设计说明》生成后由项目负责人提交给质量监督组进行复审，复审通过之后，由文档组进行格式化和版本编号并存档。《体系结构设计说明》的完整流转过程在开发商内部，客户并不介入。
程序员
为了有效的利用领域专家的资源，在体系结构设计的同时，可以由系统分析员的指导之下，由程序员进行界面原形的开发。界面原形由领域专家进行评审。评审通过后由客户进行复审。界面原形跳过质量监督由文档组进行格式化和存档。质量监督有了解和监督界面原形变化的责任。程序员参与系统详细设计，主要负责系统的实现工作，并对测试组提供相应的测试资源。由于详细设计的详细程度不易把握，有程序员参与的情况下，系统分析人员与程序员的交流会有助于系统开发进度。在项目代码生产的后期，程序员要进行相应的白盒测试。之后，可执行体提交到测试组进行测试。《系统详细设计说明》由分析员和程序员共同完成。通过项目负责人转交质量监督组进行复审，复审通过后，由文档组进行格式化和版本编号，并存档。
测试组
主要进行软件的测试工作。上面提到程序员在交给测试人员之前是进行过一定的白盒测试的。测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行体正确的实现设计要求，在此也只证明了软件正确的反映了设计思想，但是否真正反映了用户的需求仍需要进一步的测试。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。
同样，测试在不同的阶段需要不同的“输入”与“输出”。在正确性测试阶段，不需要太详细的测试计划和测试策略的设计。而在性能测试时，需要分析人员提出测试策略和测试用例，质量监督组同样会提出他们认为必要的测试策略和测试用例，后者提出的测试策略和测试用例被认为是对前者的抽样调查。无论是前者还是后者提出的测试策略和测试用例，都由测试组组织实施。
质量监督组
保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量监督组有关。质量监督组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。在项目进度被延滞或质量监督组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量监督是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量监督的影响力和力度。文档组则是保证软件质量监督的得以实施的重要保证。
质量监督组的监督范围包括： 系统分析人员是否正确的反映了用户的需求; 软件执行体是否正确的实现了分析人员的设计思想; 测试人员是否进行了较为彻底的和全面的测试; 文档组是否对文档的规范化进行的比较彻底，版本控制是否有效;
文档组
是保证项目开发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述，文档组还是保证质量监督组得以发挥作用的基础。
文档组的主要职责包括： 完善各个部门发送需要存档和进行版本控制的文档; 对文档进行单向出入的控制; 对所有存档的文档进行版本控制; 书写文档规范，并传达到开发组中; 书写部分外部文档。
技术支持部
技术支持部的存在是保证软件在用户使用的过程中，为用户提供最及时的技术服务，也为项目开发人员抽身进行新版本软件开发保证。技术支持部的人员能够作到对软件的使用人员进行软件的安装、配置、正确使用进行培训。能够解决由于软件的不当使用产生的各种问题。技术支持部的人员也有对软件系统分析监督的作用。技术支持人员是软件开发过程中的虚拟用户，也就是说在软件未正式提交用户之前，技术支持人员充当用户的角色。
合作伙伴提供的保证
软件的开发我们选用微软公司的Windows平台和Visual Studio为主要开发工具。 我公司是微软(Microsoft)在中国最大的技术方案提供商，在软件开发方面能够直接从微软公司获得最快最全面的技术支持。另一方面，公司能最快速的获得微软最新的企业解决方案的培训和咨询。同时我公司还是微软出版社中国唯一总代理，公司拥有微软最全面的书面资讯。
项目进度的保证
项目进度是项目进行是否顺利的最直观表现。显然在项目开始之前，项目开发计划是必须的。如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，从而制定较为合理的项目开发计划。本公司已经开发过铁道部的结算系统，开发中的子项目多达六个，历时十五个月，目前多数项目已经开发完毕，有些系统已经投入运营五个月，项目金额数千万元。在这样的项目中，从管理者到开发人员到测试人员都积累了较为丰富的经验，特别是项目开发计划的制定，和项目进度的控制。
项目计划以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调整。也利于项目质量的监督。
里程碑就是对项目在开发过程中完成的较大成果的定义，比如需求分析完毕、代码生产完毕、正确性测试完毕，都被定义为一个里程碑，每一个里程碑都需要对完成的界定方式进行定义。比如需求分析完毕为一里程碑，这一里程碑完成的定义是：《系统需求说明》必须经过客户的确认，并在文档组进行了相应的归档工作。当然把完成需求分析作为里程碑不一定恰当，因为系统开发往往伴随着需求的不断变化和新需求的不断产生。如此又引出新的问题，即如何定义恰当的里程碑，如何界定里程碑的完成。里程碑将项目分成若干个较小的段，通过保证每一个段的顺利完成，来保证整个项目顺利完成，同时通过每个段的完成质量，可以测度整个项目质量。同时里程碑保证各个阶段的产品的依赖关系尽可能的小，并以完备的文档作为里程碑完成的重要标志之一。在里程碑和完备文档的控制之下，项目已完成的阶段是受到保护的，在任何时间，人员变动，甚至是开发商的变动，都不至于造成特别重大的损失，通过完备的文档，原有的成果能够被延续进行开发。
项目开发方法对项目质量的保证
项目的开发方法对项目的质量和按时完成也有较大的影响。
面向对象的开发方法有利于对问题领域的深入理解，也有利于将问题空间向解空间映射从而得到更加理想和完整的系统模型。同时面向对象的开发方法和实现方法也有利于系统错误被局限在较小的范围内，不会出现骨牌效应。面向对象的开发方法也有不利的方面。开发人员对它的熟悉程度不如传统的结构化的开发方法。对面向对象中新出现的名词需要重新在开发队伍中进行定义，以便在开发的过程中彼此交流时表达的更加准确，从而减少开发队伍之间的通讯量。通讯量的降低意味着效率的提高，减少了占用开发时间讨论一个彼此立场根本一致的“问题”的时间。软件构架定义了该领域中特定对象必然 的发生方式，这种发生方式以构架中抽象类之间定义的关系被固化在构件中，开发人员在开发应用系统时不必再为定义这种相互作用方式而书写代码，这为将来系统的维护奠定了坚实的基础，也为将来新版本软件的透明升级并保持兼容性和正确性提供了有利保证。通过面向对象的继承特性，可以在不伤害原有系统的情况下，任意替换功能模块，从而以效率更高的模块代替原有模块，从另一角度讲，也实现了软件模块的配置功能。要实现真正的软件模块的即插即用，还需要利用面向对象的另一优势--组件。
面向对象使得面向对象的类或对象可以以与语言无关的二进制方式被存储和调用。这就是COM技术。显然软件构架实现的基础是COM组件。由于COM是二进制的方式被存储，因而它可以被任何语言编写的软件所调用。组件与系统分离，只是在发生系统调用时才被调入内存执行，这就保证了系统更高层次的即插即用。
鉴于如此多的好处，采用面向对象的技术进行该项目的开发是值得的，
对于上面提到的面向对象的不利因素采用如下方法进行克服：第一，在系统开发之前，首先定义技术术语，然后定义领域术语，这样保证了开发过程中开发人员用同种“语言”进行交流，避免了文不对题的讨论或争论。第二，指定技术规范。在殊途同归的情况下，我们只允许那些在技术规范之内的技术来实现。技术规范定义了若干种对象技术，这些技术规范在整个开发小组中进行统一认识方面的学习。
开发策略是针对不同开发技术和问题领域而作出的策略性的考虑。显然开发策略与所用的开发方法、实现技术以及问题领域的特征密切相关。一般来讲，鉴于面向对象的“无缝”特性，采用原形法比较恰当，而开发过程则采用螺旋式开发方法。螺旋式开发方法提高了人员的利用率，使得软件开发的局部阶段相互重叠，在整体上形成多道流水线重叠并行。显然这又缩短了开发的总周期。
项目开发各阶段的质量保证
需求分析
需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。同时，想在某个时间点上宣布需求分析已经完毕，不再需要进行进一步的需求分析，这也是不现实的。经验告诉我们，往往在测试过程中会发现，用户真正想要的并非您脑海中的设想，另一方面用户往往知道自己肯定不需要什么，而无法明确告知他们需要的是什么。面对这些事实，我们无法期望改变用户;比如提高用户同分析人员的“沟通”能力，让他们说出的话更能被分析人员理解。唯一的做法是采用一定的方式方法，诱导用户尽可能早地将需求表达出来，表达得完整。
在某个项目中我们的做法有两个方面：一是请领域专家参与到系统开发的早期阶段;二是开发系统原形，原形包括功能性的原形和用户界面性的原形，也可以是二者混合的原形，用这些原形确认用户的需求。让领域专家参与开发的早期阶段，是保证分析人员有充足的时间和领域专家进行充分的交流和确认。在这个阶段，原形可能在提交到用户之前，首先被领域专家确认，这样保证了原形被认可的程度和认可过程耗费的时间尽可能的短，从而在提高效率的同时保证了质量。
在开发方内部还有三项保证措施： 系统分析委员会保证系统分析集思广益; 质量监督组对分析工作的监督; 技术支持人员参与需求调研。
分析委员会的意义在于任何分析人员在提交其所分析部分的分析说明书前，必须通过委员会的共同审议，委员会的成员根据各自的分析经验和自身所分析的部分对他人的分析报告提出质疑。如此审议过后保证了各部分间相互关联的部分被明确定义，避免了由于“疏忽”造成系统在后期进行整合时出现较严重的系统鸿沟或系统重叠。
质量监督组在项目的任何阶段都要提出监督计划。按照监督计划分配相应的资源来保证某阶段的开发质量。分析阶段的监督计划会在分析任务之前被项目经理，项目负责人、系统分析员以及技术支持所了解。为保证分析工作高质量进行，同时分析工作又不被过分打扰，质量监督组则主要针对《系统分析报告》进行复审，只在认为确实有必要的情况下才召开质量复审会议。质量复审会议的主要参与者是项目经理、项目负责人、分析人员和质量监督组组长。会议的主要议题是提出质量质疑，给出改进建议即可。具体是否存在质量问题，是否需要改进，不在会议中进行讨论。以此保证了会议参与的人数较少，会议的时间尽可能的短。
通过技术支持的职责可以发现，技术支持参与分析调研有利于对分析工作的监督，在获得用户需求的口头表达之后，能帮助技术支持更好地扮演开发阶段 “用户”的角色。技术支持具有相当的计算机技术背景，在接下来的开发过程中就能较好的起到监督的作用，也为将来维护和为用户提供更好的服务奠定基础。
系统设计
优良的体系结构应当具备可扩展性和可配置性，这两方面因素的实现是通过Windows DNA的应用完成的，正如建议书中所述，在此不再赘述。
实现
实现也就是代码的生产过程。从设计的结构图中可以看出，生产的类别有类的生产，组件的生产，构件的生产，应用系统的整合，以及各种测试用例的生产。为了能够提高生产的质量，我们将生产的程序人员按职能分成两组，测试用例的生产和测试用例生产，也就是说如果某个程序员生产了某个组件，则其测试用例不能再由该程序员来生产，但他可以生产其他组件的测试用例。这样交叉生产更容易发现组件的存在的问题。测试人员按照测试用例来测试组件的各项指标提出测试报告。
随生产的不断深入，组件的生产日趋减少，构件的生产的量开始逐步增加，生产构件的过程又是对组件的考验过程。因此描述组件实现的文档是非常重要的，它将有可能成为阻碍进一步生产的瓶颈。文档组在生产过程中的重要工作是对各类部件的文档进行丰富和规范，同时进行版本的控制。文档的完备与否，在开发的后期，对项目进度有至关重要的影响。文档是共享前期开发成果的唯一手段。根据上一节描述的应用系统体系结构来看，整个开发环节丝丝相扣，每一步都受到上一步的制约。
为了控制系统开发过程中的往复，不至于产生重大过失和往复的泛滥。文档组和质量监督组协同完成软件开发的配置管理。
软件配置管理的目的在于控制软件开发过程中的“变化”，这种变化可能是外部引起的，如需求的变化。也可能是来自于内部的变化，如早期设计的某个部件不够完备，需要修改等。为了控制这些变化，把变化引起的波动尽可能的控制在有限的范围内。
配置项是指需要进行控制的任何文档单元，它可能是需求说明报告，也可能是需求说明报告的某个点。在本项目中需要控制的内部配置项包括需求报告，设计报告，组件代码，组件接口文档，构件及构件相关文档;外部配置项包括项目计划书，使用手册，系统安装说明和系统配置说明等。
从图中可以看出在文档没有被提交出开发组以前，文档可以在开发组内部“任意”地被修改，但一旦文档被提交，则相关的部门就会被调动，来维护文档的质量。因此为了保证工作效率，开发组提交文档之前必须慎重，以免引起不必要的工作量的增加。从另一角度来看，开发部受到严密的监督，从而保证了开发的各个环节对于开发的全过程保持透明，避免了因为个人的原因造成整个开发的瘫痪或受阻。项目经理通过质监报告可以了项目开发的进度和质量情况，为调整开发计划提供有利的依据。
显然开发部的内部流程在配置管理的过程中受到的监管是非常有限的。配置管理所能起的作用完全是建立在文档之上。当项目进度非常紧张时，开发部可能书写文档的时间会非常少，在此情况之下质量监督组和文档组就肩负将开发部提供的文档进行丰富和完善的工作，从而减少开发部书写文档的时间，当然这是增加质量监督组与开发部的口头交流为代价的。
测试
测试组的工作被分成若干阶段，不同阶段的划分是以保证软件质量的不同指标为目标的。
测试的软件指标分别包括： 软件的正确性：正确性测试主要是测试软件的功能是否被正确的实现。 测试的方式主要是按照功能的要求按照给定的输入，看是否有给定的输出。在非标称输入时，输出是否异常等。一方面测试软件的功能是否实现，同时是否实现的完整。
性能指标：该项目对性能的要求非同一般的软件项目。性能测试往往包含了压力测试、攻击性测试等测试，软件所能承受的极限是多少，一般来将软件的极限应当高出用户要求的性能，各种指标也应当为用户所了解。
易用性：软件的使用界面在设计实现的时候应当设法使之与功能的实现相脱离。脱离的原因在于易用性是通过友好的界面实现的。然而让开发人员以使用者的角度来确定软件是否易用是件非常困难的事情，在确定使用界面时往往需要多次的反复修改，甚至只能在软件的最后交付之前或用户使用一段时间之后才被提出来。鉴于这种特点，软件在开发的不同阶段都作了相应的保证措施，比如在软件需求界定的时候请领域专家参与，在软件设计阶段，让功能的实现尽可能地包含在软件的组件之中，也就是没有界面要求的底层实现。界面的实现仅仅依赖于一个数据接口，界面仅仅负责将用户输入的数据送到指定的数据块中，用于显示的数据也在指定的数据块中提取，只要保证数据块被互斥的访问就可以了。有了这样的设计结构，软件的易用性也就相当容易保证了。当测试中发现易用性的问题时，软件不会伤到筋骨，皮毛的修改总是非常容易的。
测试人员的角色也是逐步的由开发向用户方向转移。
测试存在两个非常重要的问题，一是保证测试的结果真正是反映了软件的质量。一般来讲，如果测试测出的错误数是收敛的情况，基本认为测试本身应当是比较全面的和足够深入的。二是测试结果的反馈。测试报告是测试结果的正式书面反馈形式。测试报需要经过质量监督组的复审，并进行统计，再形成质量监督报告的一部分，提交到项目经理和项目开发组组长处。同时，测试组产生的测试报告和测试统计报告也要进行归档，以便跟踪软件的质量进展。这也是软件进行版本编号的一个重要依据。
文档维护
文档维护主要是文档组的工作。文档从用途上分主要分为内部文档和外部文档。
内部文档包括： 项目开发计划; 需求分析; 体系结构设计说明; 详细设计说明; 构件索引; 构件成分说明; 构件接口及调用说明;组件索引; 组件接口及调用说明; 类索引; 类属性及方法说明; 测试报告; 测试统计报告; 质量监督报告; 源代码; 文档分类版本索引;软件安装打包文件。
外部文档主要包括： 软件安装手册; 软件操作手册; 在线帮助; 系统性能指标报告; 系统操作索引。
文档的重要性在前面的章节中已经多次提到。如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个“度”的问题。在本项目的开发中，文档组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下“填空”的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。
文档组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量监督组经过复审之后转交给文档组，有些则会直接从文档的出处到达文档组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。
系统维护保证
对于该项目，软件维护主要由公司的技术支持部来完成。技术支持在本公司的角色在第一章中已经有所描述。在这里需要重申的是，在本公司，技术支持的任务一方面是保证对项目客户的跟踪服务，另一方面是把该项目的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中，因此要求技术支持人员在项目开始的时候就介入其中，并在开发的过程中不断跟踪项目，特别是开发中同客户的交流，他们必须参加。不仅如此，软件的代码编写，他们也需要有所了解，并对非核心代码能够进行一定的修改，最起码能够准确定位错误，以便提请公司以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由技术支持部来解决。
技术支持部的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在技术支持部会有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。
篇2：项目合同管理计划
项目合同管理计划模板
项目合同管理计划
1.编制依据：
2.签证管理一般规定 2.1对发包人签证
2.1.1在合同中没有约定的情形下，签证事件发生后3d内向发包人提交签证资料，当改签证事件持续进行时，应阶段性向发包人提交后续签证资料。签证单的格式参照示范文本。
2.1.2签证事件发生后，经办人员必须精心撰写签证事实，签证事实应经得住发包人的推敲。
2.1.3签证申请中涉及的干扰事件、签证内容、签证值计算以及相应的证据要充分齐全。
2.1.4所有的签证资料必须及时收集、整理、归档，确保在规定时间内提交给发包人。
2.1.5对报送的签证资料做好应答对策，并预防对方的反索赔签证。 2.1.6用词简洁准确，调理清楚，逻辑性强，签证值的计算要符合合同约定，合同中未约定选用的计算方法是必须采用常规的方法。 2.1.7通过对几种计算方法的对比分析，选择最有利的计算方法计算签证值。
2.2签证单的要素
2.2.1简洁的说明针对什么事件提出签证的要求。
2.2.2阐明发生签证事件的有效依据，包括法律法规、合同条款、指令、变更罕见、各类确认函等
2.2.3描述签证事件发生的进过及其对总承包方的影响，以及总承包方要求签认的相关事宜，包括工程量、工期、费用等。
2.3流程
2.3.1签证事实发生后，现场经办人收集资料，撰写签证单 2.3.2技术性的签证（含设计变更）交项目技术负责人审核，经济性签证（含材料类的签证）交项目预算员审核。
2.3.3签证必须由项目总工程师和合约经理进一步复核，项目经理审批后报送
2.3.4特殊情况下的签证须经企业总经济师审批
3对分包人签证 3.1一般规定
3.1.1对分包人的签证应遵循以合同为依据、现场发生为事实。“实事求是、量入而签”的原则
3.1.2对分包人的签证不得完全参照或等同于发包人的签证工程量，应以分包人实际发生的工程量为准，特殊签证除外
3.1.3总承包项目经理部任何人员不得超越权限在签证中签订合同外的`施工单价或总价。合同没有约定单机的由分包人提出报价，总承包项目经理部审核后报企业审批
3.1.4签证不得违反分包人投标承诺及合同的有关约
定
3.1.5对于内容不清楚、不齐全的签证单或计算单，总承包项目经理部合约人员不得予以审核
3.1.6分包人的签证单应内容齐全，并经其签字盖章后方可提交给总承包项目经理部，进入审核核价程序。
3.2分包人提交的签证等应注明以下内容 3.2.1工程指令签发时间及编号；
3.2.2签证事实发生、完成时间及签证单提交的日期；
3.2.3签证的依据（工程指令、变更或任务书等函件作为附件）； 3.2.4签证事实及完成情况简述； 3.2.5涉及的工程量和金额。
3.3审核依据
3.3.1工程指令、施工任务书及现场签证等书面函件； 3.3.2工程特点及现场实际施工情况；
3.3.3分包人的合同、承诺书、补充协议、企业核定的单价确认函； 3.3.4工程图纸； 3.3.5其他。
3.4总承包度对分包人签证单的审核流程、期限及其他
3.4.1总承包项目经理部应要求分包人在签证事件完成后2d内提交签证资料（签证单、工程指令等证据资料）一式二份，供总承包项目经理部现场工程师审查。
3.4.2总承包项目经理部现场工程师在接到分包人提交的签证资料后，2d内完成审定（若现场工程师发现签证内容逾期提交可以直接认定该签证单作废）；总承包项目经理部主管生产副经理及合约人员审核期限分别不能超过2d及3d。
篇3：项目成本管理计划怎么写
项目成本管理计划怎么写
1.目的和范围
为了使本项目成本管理规范化、程序化，切实为业主把好资金使用关，用好资金，根据我公司对造价管理的管理标准并结合本项目的特点制定本计划。本计划适用于本项目管理服务各阶段的成本管理，并根据工程实际进展状况作出及时调整。
2.职责
2.3.项目经理
2.3.1.项目经理对项目管理各阶段的成本管理负全面责任。
2.3.2.负责与业主沟通,细化合同关于成本管理工作的内容和范围,明确项目管理部、业主、造价咨询单位、监理单位造价管理的职责分工、工作流程和审批权限。建立项目成本管理制度。
2.3.3.负责审批项目部出手的有关工程成本管理方面的重要文件、凭证等。
2.4.项目合同造价管理组
2.4.1.负责编制成本管理工作计划，成本管理工作制度和项目成本管理工作流程。
2.4.2.负责编制项目投资估算、项目投资目标分解、年度资金使用计划。进行成本分析和投资风险因素分析，制定控制措施。
2.4.3.审核初步设计概算，进行设计阶段成本控制。
2.4.4.审核造价咨询单位提供的工作计划和工程量清单等成本管理成果文件。
2.4.5.协助业主组织或参与招标、采购阶段的询价、比选和商务谈判，进行招标、采购阶段的成本控制。
2.4.6.负责施工阶段工程变更、工程进度款支付、索赔费用的控制和管理。
2.4.7.负责组织和审核工程结算。
3.阶段性项目成本管理计划
3.1土地审批阶段
针对获得土地使用权方面搜集相关信息，对于土地获得所需要的相关文件涉及到的费用建立价格信息台账，做到每笔费用有据可依。
3.2建设工程的立项阶段
1)充分利用各种社会资源简化项目立项程序，加快项目立项进度，从而降低因工程延期造成项目成本的增加。
2)确保项目立项审批所需文件的质量，尽量防止文件的第二次修改，降低过程成本，为项目后期工作打好良好的基础。
3.3设计阶段
3.3.1设计阶段的目标及内容
1)通过设计招标（含方案竞赛），协助业主选择高水平的设计单位和项目设计队伍，在规定的设计进度和投资限额内，完成符合业主和合同要求的高质量的工程设计。根据有关统计资料表明,计费用一般只相当于建设工程全部寿命费用的1%以下,但是这少于1%的费用对施工项目造价的影响度达到75%以上,由此，可见设计阶段的成本管理对整个项目资金使用合理性有重要作用，对设计阶段的成本管理显得尤为重要。
2)在保证项目投资管理目标即批复的初步设计概算的`前提下，限度地满足建设单位的要求，把有限的资金用到最需要的实体项目上。
3)编制设计阶段管理工作计划，协助建设单位编制设计任务书、组织评选设计方案，招标选择设计单位。
4)编写设计阶段技术、经济分析报告，经项目经理批准后提交业主。
3.3.2方案设计的成本管理
方案阶段项目部协助业主作好多方案技术经济比较,提高投资估算精度，作好投资估算。采用设计招标形式选择最合理的设计方案，促使设计单位采用先进技术，降低工程成本。
3.3.3初步设计的成本管理
1)项目设计任务书和初步设计方案应在充分考虑业主定位和投资目标的基础上，项目部工程技术人员和造价工程师必须密切配合，进一步进行技术和经济分析比较，协助业主选择相对经济、合理、适用的设计方案。
2)项目部编写设计阶段技术、经济分析报告，经项目经理批准后提交业主。
3.3.4施工图设计的成本管理
1)要求设计人员按照批准的总概算控制总体工程设计，各专业在保证达到设计任务书各项要求的前提下，按分配的投资额控制各自的设计，在满足设计任务书和相关标准的前提下，采用合理的工艺技术，材料设备和合理的结构形式，使其设计造价接近投资限额或更少。
2)审核工程设计概算。初步设计概算一般采用对比分析法、查询法和详细审查法等方式进行审查，项目部应结合设计图纸审查进行设计概算审查。主要审查内容包括：
设计概算的编制依据、编制方法、编制深度；
设计概算的项目、规模、建设标准、配套工程投资；
分析采用的定额水平与合理性；
调查分析人工、材料、资源供应等基础价格的合理性，施工方法和施工机械设备是否符合施工规划的要求，取费标准是否合理；
工程设备规格、数量与配置是否符合工艺设计要求，价格是否真实；
单价分析的组成与计算程序、方法是否符合现行规定；
概算项目的编制内容、编制水平、静态投资、分年投资；
技术经济指标水平；
检查经济效益分析；
3)编制技术经济审核报告，经项目经理批准提交业主和设计单位。对不合理技术方案和设计概算，要求设计单位修改设计图纸，调整设计概算。
3.4招投标阶段
根据招标采购工作计划对拟采用招标方式招标的项目，项目部应审核招标代理机构或造价咨询机构提供的工程量清单，审核结果提交业主和招标代理机构或造价咨询机构。招标代理机构或造价咨询机构对偏差部分进行修正后，方可进行招标。
3.4.1招标阶段成本管理的目标
通过招标的方式，在工程、货物、服务的采购中选择性价比较高的供应单位，做好在招标阶段的成本管理。
3.4.2设计招标的成本管理
严格按照业主的要求，同时兼顾对项目总投资的控制。在设计招标阶段协助业主选择设计方案及的设计单位，以确保设计进度、质量、成本得到有效控制，不影响整体工程的进度。
3.4.3施工招标的成本管理
准确把握设计图纸,通过对建设项目的具体情况分析和投标单位的资格预审,编制招标文件,确定工程标底；通过评标、定标,选择中标单位,并确定承包合同价。合理地确定工程标底是施工招标阶段工程成本控制的一种重要方法,工程标底的确定往往因设计图不全,材料的变更,或因市场价的不断变化,难于有一个准确的数值。
3.4.4监理招标的成本管理
通过招标选定有资质的工程监理单位，明确监理单位在工程中的工作范围。
3.4.5主要材料设备招标的成本管理
根据招标采购计划对直接采购的项目，项目部应组织招标代理机构或造价咨询单位、项目管理部、监理单位进行询价，编写询价报告。严格控制材料等可变价格。对工程造价影响大，价格和质量较难把握的主要材料和大型设备应单独招标。主要材料和大型设备的供应控制主要是价格和质量方面，应深入市场调查，然后定下主要材料和大型设备的技术指标及其质量，价格档次，由投标单位按要求自行报价，形成投标价格，签定合同时就形成了固定单价合同，防止施工单位以次充好，对其供应的材料应严格检查。
3.5施工阶段
3.5.1施工阶段成本管理的目标
1)使项目要求的质量、工期、费用所进行的全过程、全方位的规划、组织、控制与协调。
2)缩短工期、提高质量和降低造价。
3.5.2投资人或项目管理者在工程施工阶段对项目的管理是为使项目要求的质量、工期、费用所进行的全过程、全方位的规划、组织、控制与协调。
根据项目合同和项目约定的工程进度款申请和审批程序进行工程计量和工程款支付审批。
根据合同和项目约定的工程变更费用申请和审批程序，审批工程变更费用和支付申请。
工程投资控制。项目部应建立工程进度款支付和工程变更费用及其它费用支付台帐，并定期进行分析比较，编制项目造价分析报告，经项目经理批准后提交业主。
费用索赔管理。项目部应根据合同和项目约定的索赔报审程序，与项目部工程技术管理人员配合，进行索赔处理和审批。
3.5.3在组织措施上，督促承包商在保证质量和进度的前提下尽可能采取先进技术，以降低工程成本，制定先进的、经济合理的施工方案，以达到缩短工期、提高质量和降低成本的目的。
3.5.4加强材料、设备的采购和管理。材料费是构成工程施工过程中成本的主要内容，一般材料费占工程总成本的60％～70％。
3.6竣工验收阶段
3.6.1竣工验收阶段的成本管理目标
1)避免承包商在结算过程中，虚报工程量和高套定额基价等以获取高额利润的行为。
2)审核竣工内容是否符合合同要求、验收是否合格,审核结算方法、计价方法、优惠条款是否符合合同;按竣工图审核工程量,在审核中,应根据竣工图、设计变更、现场签证等,按照国家规定的工程量计算规则逐项核对;严格执行计价依据与计价方法;严格审查设计变更签证;检查取费标准，是否按照国家及北京市相关计取。
3.6.1从项目的的各个环节人手，找出控制要点，突出重点管理，实施建设过程严格监控，这样以来，就可以将建设工程总造价控制在预计或理想的范围内。
3.6.2工程项目或工作单元竣工后，项目部应按合同和项目约定的工程竣工结算程序，及时组织施工单位、监理单位进行工程结算，审查施工单位报送并经监理单位审核的竣工结算报表，进行竣工结算。
3.6.3协助业主与承包单位进行工程结算谈判。
3.6.4协助业主报送审计部门进行工程审计。
4.项目部投资控制总结及资料归档
4.1项目竣工结算完成后，项目部应组织投资控制分析总结，按照项目分解结构，编制项目各时间段投资分析对照表，包括目标值、调整值、实际结算值的对照及该工程分类指标分析、含钢量、砼含量指标等。经项目部校核，项目经理批准后报公司造价部经理审定后归档保存，同时也作为公司造价数据库内容由造价部保存。
4.2项目投资控制总结是项目工作总结的组成部分，应按要求在竣工结算完成后一个月内完成。
4.3记录
项目成本管理形成的记录按作业文件《项目管理资料管理规定》的要求收集、保存、归档。
5.项目成本管理的全局统筹计划
5.1以策划阶段、设计阶段为重点的建设全过程造价控制。
5.2主动控制。工程项目造价控制,不仅要反映投资决策,反映设计、发包和施工,被动地控制工程造价,更要能动的影响投资决策,影响设计、发包和施工,主动地控制工程造价。
5.3技术与经济相结合。将技术与经济有机结合,通过技术比较、经济分析和效果评价,正确处理技术先进与经济两者之间的对立统一关系,力求做到在技术先进条件下经济合理,在经济合理基础上技术先进,把控制工程成本的观念渗透到各项设计和施工技术措施之中。
5.4工程监理。从组织和管理的角度采取科学的措施确保建设项目工程成本目标、工期目标和质量目标合理地实现,为业主求得投入产出。实践证明,工程监理是控制工程成本的有效途径。
5.5合同管理。
篇4：加强科技计划项目管理规定
加强科技计划项目管理规定
一、目的意义
为促进我市医疗卫生领域科技创新、提高科研水平、加强指导性科技计划项目管理，营造积极健康的科研氛围，树立正确的科研导向，依照国家和省、市科技计划项目管理有关规定，特制定本暂行规定
二、基本原则
1、政府引导的原则
为引导、支持、鼓励医疗卫生领域科技人员加强科技创新与成果推广应用，市科技局设立了指导性科技计划项目。指导性科技计划项目作为一般性科技计划项目（有应用研究与开发经费支助的项目）的一项补充，采取市科技局立项管理，项目承担单位自筹经费保障实施的原则。
2、科技创新的原则
指导性科技计划（医疗卫生领域）项目选题必须围绕市经济和社会发展、科技进步战略，符合相应行业操作与管理规范，有利于推动医疗卫生领域的科技创新，提升医疗水平。项目研究内容应具有新颖性与创新性，研究成果具有指导临床或应用临床的作用。优先支持技术先进、应用前景广、社会或经济效益显著的研究或应用项目。
3、资源整合的原则
鼓励市属及县（区）医疗卫生单位与高等院校、科研院所、医药企业开展联合研究，发挥高等院校、科研院所的人才和技术资源优势。优先支持围绕“公益、共性、关键”技术进行产学研合作开发和集成创新的项目，以及技术创新人才培养项目。
三、项目申报与立项程序
指导性科技计划（医疗卫生领域）项目的申报立项程序一般包括：市科技局发布申报通知；各医疗卫生单位组织医卫人员申报项目；申报单位组织内部评审并推荐（县、区医疗卫生机构申报的项目由县、区科技行政主管部门负责统一推荐）；市科技局审核及受理申报材料；市科技局批准立项下文；双方签订项目合同书。共六个基本程序。
申报单位要严格把关，对所申报项目的目的意义、研究内容、研究方法和技术路线等内容要组织本单位学术委员会的专家进行集中评审，并在报送材料时提交推荐汇总表和评审推荐意见，作为立项参考依据。
四、项目申报要求
1、申报单位要求
申报单位应具有独立法人资格，为辖区内的医疗卫生单位，包括：市属、县（区）医疗卫生机构，驻昌高校、部队附属医院，企事业单位职工医院，民营医院等单位。申报单位应具有保障项目实施的基本条件，包括：较强的科研能力，良好的基础设施和管理能力，自筹、配套相应的科研经费能落实到位等条件。
2、项目组负责人要求
项目组第一负责人必须具备中级以上职称或硕士以上学历，有较高的业务水平和组织协调能力，并具有开拓进取、勇于创新的科学意识。
项目组负责人，已申报并立项了当年的一个科技计划项目，原则上不允许再申报当年的指导性科技计划项目；对于承担了我市科技计划项目，正在实施或实施完成但未鉴定或验收的项目负责人的新申报项目，不予受理。
3、项目研究内容要求
指导性科技计划（医疗卫生领域）项目的选题要围绕我市人口与健康急需解决的.医疗技术难题、重大疾病预防控制和市卫生系统“三名工程”建设的要求。项目研究内容具体、技术路线清晰、预期成果先进、应用前景广阔、社会效益显著，有助于提高医疗卫生行业科研实力和创新能力。经检索查新，显示国内有技术要点完全相同研究文献报道，研究结论已经明确了的研究项目，原则上不予受理（虽有技术要点完全相同研究文献报道，但在不同对象或扩大范围内推广应用，改进临床操作技术的项目除外）。
申报书中对技术指标、经济指标、社会效益的描述需要明确具体，即要有定性的阐述，也需要有定量的参数。
4、申报材料要求
申报材料应包括：《市指导性科技计划项目申报（合同）书》、《科技查新报告》和相关附件证明材料。使用A4纸打印，左侧装订，一式6份。经所在单位评估审核后，按归口渠道和规定时间报市科技局，同时报送申报项目的汇总表和推荐意见。项目申报（合同）书可到科技信息网下载。
5、申报时间要求
指导性科技计划（医疗卫生领域）项目实行集中申报，每年两批次。第一批申报时间为3月1日-5月31日，第二批申报时间为8月1日-10月31日。
五、项目的实施管理
立项通知下达后，项目承担单位与市科技局签订项目合同书。项目承担单位应将项目纳入本部门和本单位的科技工作计划，配套相应的研究经费、提供实验设备、研究场所等方面的保障，经常性督促检查项目执行，协助市科技局进行项目实施的日常管理，确保项目按计划和合同要求完成。
项目执行期以计划下达之日为始，原则上不超过3年，研究内容与项目组人员不得随意变更。各项目组须在项目实施期内，于每年12月31日前，向本单位科教科提交《市指导性科技计划项目年度执行情况报告》。再由各医疗卫生单位科教科统一收集后，报送市科技局。
项目负责人原则上不得变更；因项目主要研究人员的人事变动和科研内容作重大调整等情况，经本单位科教科同意后，填写《市指导性科技计划项目研究人员变更申请表》，加盖单位公章，报市科技局审核批准；因计划外因素，致使项目研究需延期、调整、中止的，经本单位科教科同意后，提出书面申请，加盖单位公章，报市科技局审核批准；在项目合同规定时间内，无故不完成研究任务的，市科技局可以采取通报批评，并视情况中止、撤消项目合同、取消项目负责人三年内申报科技计划的资格；项目承担单位不提供科研保障，致使项目研究无法开展，合同任务不能按时完成的，市科技局将调减该单位今后科研项目立项数量。
六、项目的鉴定、验收
项目承担单位在完成项目研究任务后，应向市科技局业务处室申请项目鉴定或验收，并提交鉴定或验收材料。经业务处室审核材料后，报鉴定或验收责任处室，由鉴定或验收责任处室组织专家进行会议鉴定或会议验收。鉴定或验收的相关材料与表格可到科技信息网下载。
验收材料包括：工作总结报告、技术研究报告、项目合同书、年度执行情况报告、《市指导性科技计划项目验收证书》草本、相关附件（如：著作、论文、临床数据等）。
为提高工作效率，项目承担单位可向市科技局提出申请，在同一时间段内，由市科技局组织专家对同一承担单位的多个归类项目进行集中验收。
鉴定材料包括：科技成果鉴定申请表、项目合同书、工作总结报告、技术研究报告、查新报告、相关附件（专利申请书或证书、发表的论文、用户使用情况报告、经济社会效益分析报告、行业主管部门证书或批件等）。具体参照科技计划项目成果鉴定流程。
市科技局根据专家组鉴定或验收意见，提出“通过鉴定或验收”或“需要复议”或“不通过鉴定或验收”的结论建议，并以鉴定或验收证书的形式下达给项目承担单位。
七、其他
其他未尽事宜，请参照《市科技计划项目管理办法（试行）》和《市科技计划项目验收管理办法（试行）》执行。
篇5：IT项目管理的质量计划
-03-05 17:18作者：zhengzhong出处：天极网责任编辑：郑重
质量计划需要回答的是如果通过各种质量相关活动来保证项目达到预期的质量目标。质量计划中的重要输入是质量目标，而质量目标来源于用户需求和商业目标，项目质量计划根据质量目标制定，包括质量保证计划和质量跟踪控制计划。
质量属性包括了正确、可用等功能性属性，也包括了性能，安全，易用，可维护等非功能性属性。各质量属性间本身也存 在正负相互作用力，提高某个质量属性会导致其它质量属性受影响，也会使项目进度成本等其它要素受到影响。项目进度成本有限，不可能满足所有的质量要求，因 此必须系统的确定各质量属性满足的优先级，满足的度。这里面有QFD系统的方法，也可以参考KANO模型真正找到我们投入不多的时间和成本就能大幅增加客户满足度的易用性需求。 因此质量目标应该包含两方面的内容，一方面是功能性的质量目标，主要以产品的无故障运行时间和产品的现场故障密度 来定义。另一方面则是非功能性的质量目标，应该根据非功能性需求中对应的质量属性来定义。只有明确的定义了质量目标才能够去计划和安排质量相关的活动。质 量成本分为COQ好质量成本和COPQ坏质量成本，质量是设计出来的而不是检验出来的，有了质量成本指标可以很好的衡量项目总体的生产率和效率，衡量项目进行中的质量水平。 为了提高和保证软件质量，在项目执行过程中会采取一系列的质量活动，比如评审，培训，测试，代码走查等。这些活动的安排时间点和安排工作量应该和项目质量目标一致。当为了预防质量问题投入的好质量成本小于返工等引起的坏质量成本的时候，都是值得安排的质量活动，质量活动的价值就在于提前发现质量问题，或者通过前期的培训减少质量问题的发生。因此对各活动安排的参考意见为:
需求和总体设计类文档一般要求评审，防止前期的缺陷泄露。另外一个重要的原则就是你认为当前任务执行人无法很好的保证产出物的质量的时候都需要进行评审。我们一再强调评审不是解决成员责任心的问题，评审最重要的作用是要发现潜在的'问题，并挖掘遗漏。
对于测试首先需要确定测试的方法论，如果测试方法论没有很好的和生命周期模型配合，则会出现测试和开发工作脱节并 出现较大干扰。因此测试方法论对功能性质量保证会产生很多的影响，确定了测试方法论后再考虑测试的一些计划和策略，这里面包括了对功能性需求和非功能需求 的测试计划和策略。测试是整个产品的最后一道防线，但仍然需要注意到软件质量不是测试出来的，而是设计和开发出来的，测试发现太多的问题只能说明整个团队技能水平不足，我们的过程和规范不成熟，测试是驱动项目和组织去改进质量水平。
项目进行中各阶段工作产品的质量水平可能由项目成员的责任心态度引起，也可能由于项目成员本身的技能水平引起。而 恰好我们的评审都在评审这两方面的问题，当然评审不会起到很关键的效果。对于责任心和态度问题要加强团队建设和项目规则制定，而对于技能的问题则需要前期 在人力资源计划中对项目成员的技能进行评估，发现技能缺陷后要及时组织培训。项目的培训投入是最有益的质量成本投入，将对整个项目的长远期都产生积极的影响。
对于质量计划应该包括的内容为:
1.项目的质量目标(包括功能性属性和非功能性属性的质量要求)
2.各质量属性相互约束分析,满足的优先级和成本效益分析(KANO,QFD)
3.潜在的质量问题和应对分析(评审，培训，代码走查)
4.各阶段的质量目标分解(QFD)
5.项目的质量控制策略(评审安排，覆盖率，培训，测试安排)
6.非功能性质量需求对软件生命周期各阶段的影响，对测试的影响
7.质量属性满足的优先级和成本效益分析
8.质量保证计划
篇6：科学技术计划项目管理论文
科学技术计划项目管理论文
一、科技项目管理系统研究的内容
通过该系统地研究和实施，能及时、快捷地提供各类统计数据，通过对这些数据和资料进行分析和定期总结，完成科技项目的投入和产出、科技项目领域和行业分布情况等信息的研究报告，直接为相关政策法规和管理制度的出台提供决策支持。
二、科技项目管理系统总体设计
科技计划项目管理系统是在充分利用已有的数据资源、应用资源、硬件资源的基础上，形成一个设计科学、合理优化的集中业务中心数据库；建成全局统一的业务信息系统应用支撑平台，在其基础上，建成全局统一的住房和城乡建设部科学技术计划项目管理的业务应用系统；建成一个全面灵活的综合查询统计分析系统；建成一个通用的数据应用支撑平台及一个与其他已有系统的数据互通、信息共享所需的标准外部接口支撑平台。
三、科技项目管理系统功能研究
1、科技项目管理系统包括项目实施过程中的人员、文件、过程等方面的管理
1）文件管理主要指发布相关住房和城乡建设部项目的管理办法、通知和管理条例，申报企业、省级管理员、分类管理员、专家等能够对文件进行浏览、查询及下载。
2）通讯管理主要指系统中各角色之间可以进行站内信发送、手机短信发送及邮件往来，流程处理中重要操作步骤的提醒，建立各管理角色和企业之间的联系。
3）立项管理立项管理主要指项目立项时期的管理，包括两个工作流程，分别是立项申报的工作流及名称修改的`工作流。专家在认为项目的名称宽泛或不合适的情况下，可以建议申报单位进行名称的修改。
4）中期管理主要是对跨年项目提交中期汇报的报告，并由负责该项目的管理者进行审核，监督企业申报的项目进展情况。在项目实施过程可能出现的情况进行相关变更，变更包括三部分内容：研究单位和合作单位的变更、项目的延期申请以及其他情况所需要的变更。企业提出申请中期变更申请后，由各级管理者进行审核。
5）验收管理验收管理主要包括验收申请和验收证书、成果登记。
6）专家管理专家管理主要包括对专家的用户名、密码、姓名、证件号码、手机号和工作单位等基本信息管理及设置，并对专家的工作过程进行相应的管理。
7）用户管理主要是对项目承担单位进行管理，管理内容包括注册企业、注册企业的审核、注册单位的管理、各级管理者的管理，包括各级管理员身份内容的添加、列表的展示、密码重置、启用、禁用和删除等功能。
8）项目统计项目统计主要指对项目管理过程中涉及项目以及管理者的数据进行相应的统计。有立项统计、中期汇报统计、验收统计等。在统计功能的研究过程中能根据项目类别，项目的所属管理机构，所属年份，等三个维度进行不同的统计，并根据所处的列表生成图表和导出Excel文件。
2、科技项目管理应用支撑平台研究
科技项目管理应用支撑平台应满足的基本功能要求主要包括如下两个方面。一方面，应用支撑平台位于整个系统的中间层，各类系统终端和公众用户不再与业务处理系统的服务端直接相联，而必须经过应用支撑平台服务端的认证与授权才能进入业务系统服务端。建立以数据交换为核心的体系，支持不同处理业务、不同软硬平台、不同结构数据的捕获、分类、整合、管理、传送等交互操作的协同工作机制。另一方面，应用支撑平台具有不同业务信息共享和不同工作流程相配合的功能，能够将应用系统的基础结构改造、完善成为一个开放的系统，从而有效地整合已有的应用系统，并为接纳新的应用系统清除障碍。对于新的应用系统，直接在应用支撑平台上进行开发，同时，无需限制新应用系统的操作规则，无需限制新应用系统的数据库类型和结构，无需为实现数据互通而为新应用系统编写接口。应用支撑平台可以识别、抽取、输出多种文件格式的数据。通过预设业务规则，应用支撑平台可依据系统条件或相关数据库状态自动启动数据处理操作。应用支撑平台包含了统计分析、数据交换、日志管理等功能。
四、结语
科技计划管理系统的研究和实施是对科技项目全生命周期管理过程的规范化和标准化，也是对项目管理过程中纸质文档的电子化的一个过程。系统的研究和实施将是对科技项目管理所涉及的项目申报、立项评审、中期管理和验收等环节的全流程信息化管理，加大了管理的透明度，保证了专家评审的公平公正性，提高项目管理水平。系统的研究和实施也将使科技项目管理部门在科学决策中有一定的量化的数据作支撑，为解决管理部门对科技项目管控、学科领域专家搜索、人员科研状况分析问题提供辅助决策支持。是用信息化的手段对政府工作体制改革的一种创新，也是信息化规范行政体制管理的一种有效手段。
★项目计划
文档为doc格式
