软件项目售后及质量保证措施方案

1.售后服务保障及承诺1.1.售后服务承诺对于系统售后方面我方作出以下承诺：.我方将严格遵守有关保密规定，不泄漏试验室的任何机密信息。.在技术服务期间，我方将对接触到的有关技术情报和技术资料等文件进行保密。.我方依据选购人要求将系统建设相关服务器、条码打印机、RFID管理设施等设施运送到指定的地点完成安装调试，安装过程中听从选购人的管理要求，不得破坏现场环境和设施。若因违反上述要求造成的一切损失，由应答人担当。.我方负责所供应软、硬件设施的现场安装、调试和开通，并保证设施的正常运行。我方负责支配具有相应操作资质的人员进行软硬件调试和开通等工作。相应的人员必要的资格证书需要在作业前将复印件交给选购人备案。安装调试所需工具设施物料由我方自备、自费运到选购人指定地点，完工后自费搬走。.设施及软硬件质保期内，选购人在使用过程中如消失任何对软硬件使用有疑问的状况，我方在接到选购人通报后1个工作日内赐予明确答复，2个工作日内到达现场解决问题，相关差旅、住宿费用自行担当。.我方在验收结束后免费供应一年半质保服务，质保内容包括软件BUG修复、平安漏洞修复、软件完善升级、运行状况巡检等；.质保期内，我方供应7*24小时的技术响应服务，对于选购人提出系统运维需求或系统软硬件消失问题/故障，我在接到选购人通知的24小时内进行应答和技术支持，在重大问题亟需当面解决时，我方接到选购人通知后12个小时内到达现场处理问题。.在项目实施阶段和保修期内，我方如对软、硬件设施有新的缺陷改进，应准时免费供应应选购人。产品缺陷问题（例如系统本身BUG和软件功能未达到预期要求系统我方负责终生免费维护。我方定期推送系统优化升级信息，选购人可依据需求选择是否升级。.质保期满后，每年运维服务费不高于合同额的12%。.我方承诺在人员支配方面批定专人，人员变动准时通知甲方。.我方承诺问题对接采纳邮件模式，供应企业邮箱：同时还供应热线电话：便利随时回答各种技术问题并在24小时内提出解决方案。.我方承诺在试运行期间，指定有阅历的技术人员在现场简单系统的运行和维护，若系统消失问题或故障，准时、免费进行故障处理和软件更新。1.2.服务体系公司专注于系统的研发和推广，客户遍布全国各地，为了更好的服务于客户，我公司成立了特地的售后服务机构，他们精通试验室业务，熟识软件实施和维护技术，擅长与用户的沟通和沟通，随时响应用户的求助。1.3.服务流程我公司关于售后的ISO9001程序文件规定了售后服务（系统预备、安装、调试、培训、维护）的质量掌握方法和要求。这个流程的建立有助于我方科学、高效地对每一个服务环节进行掌握，也便采用户对我方服务人员进行有力的监督。以下为我们的服务流程图：1.4.服务方式公司将向用户供应综合和特地的支持与服务，准时应对系统在使用过程中所遇到的各种意外状况和挑战，不断提高用户对系统的使用和日常维护水平，保障系统能始终在良好的状态下正常运行。1.4.1.电话、网络支持公司免费供应询问服务，解答用户在系统使用中遇到的问题，准时提出解决问题的建议和操作方法。公司设置了特地的技术支持热线电话和热线传真，并设立特地的服务邮箱和服务网站以及在线网络服务，用户在系统发生故障或有什么疑问时，可随时拨打热线电话和传真，或发送E-mail，由公司的工程师予以解答，帮助用户解决所消失的问题。电话支持服务实行首问负责制。1.4.2.远程维护公司供应远程维护方案，针对客户日常操作中遇到的问题可通过远程的方式，在用户监控下关心用户解决问题，进行在线故障排查。1.4.3.回访服务售后服务团队将执行每个季度针对客户使用状况进行回访，通过了解客户使用状况，对系统进行相应的升级改造。1.5.故障报告和预防我们的工程师在每一次技术支持或系统维护、修理时都会依据公司ISO9001文件的规定，填写相应的技术报告，分析问题产生的缘由和相应的预防和处理方法。我们会定期总结这些技术文件，并分发给用户，以利于用户准时预防和解决问题。同时，我们还会把从其它渠道得到的各种常见问题的预防和解决方法定期分发给用户。1.6.系统性能优化我们的技术支持工程师将从客户方技术维护人员处收集本系统运行状况。把纪录在册的资料进行汇总，我方将准时分析系统性能确定是否有性能优化的需要。对于用户提交的系统性能优化需求，或本公司分析确定有系统性能优化必要时，我方将制定系统性能优化方案提交给客户，由客户取决是否进行系统性能优化的实施。1.7.售后服务保障体系我公司为了更好的服务广阔用户，建立了完善的售后服务体系，并设有标准的服务工作流程，遵循“ISO质量保证体系”。1.8.客户投诉制度1、客户投诉受理内容用户若对公司技术支持人员的工作态度、响应时间和服务结果表示不满或存在争吵，可以向我方进行投诉，我方相关部门会快速调查，尽快反馈解决结果。2、客户投诉的受理方式客户通过E-MAIL或电话向我方投诉热线或信箱进行投诉，我方将尽快受理调查该投诉，并在第一时间反馈调查处理结果。2.质量保证措施方案2.1.项目质量掌握2.1.1.质量管理体系标准本项目实施应采纳先进的质量管理模式和科学的质量管理体系和流程，并依据项目自身特点选用合适的质量掌握规程。项目实施主要采纳ISO9001质量标准和软件成熟度模型（CMMI）两种掌握规程。针对本项目，公司将采纳GB/T19001-2000－ISO9001:2000质量体系标准，同时遵循SSE-CMM的平安实施标准，并在项目实施的过程中严格执行这些质量标准。系统的界面应满意GB/T25000.51-2022《软件工程软件产品质量要求与评价(SquaRE)商业现货(COTS)软件产品的质量要求和测试细则》中易用性条款中的要求（易学性、易操作性、易理解、吸引性、依从性）。2.1.2.质量掌握过程本项目中，由项目经理制订质量掌握方案，项目质量掌握组进行审核。审核方面包括：质量掌握措施是否足够、各个成员的质量责任是否明确合理，测试方法是否适用。2.1.3.质量评定方案为了加强项目质量管理和界定产品质量标准，本公司将制订适应于项目的检查验收规定和质量评定标准，确保工程质量。本项目中，实行两级检查、两级验收制度。一级检查、二级检查和一级验收由本公司实施小组组织完成；二级验收由用户组织实施。各级检查验收严格按项目实施中制订的相应的检查验收规定和质量评定标准执行。对实施和验收过程中消失的重大技术问题，将上报用户协调处理，对一般质量问题的处理应予以书面纪录。2.1.4.质量管理措施在项目实施过程中还将实行如下措施保障项目实施质量：1.产品到货后，对全部硬件设施应进行加电检测，同时对全部软件产品进行安装、产品授权验证。2.在项目实施前后对网络性能进行评估。3.在系统部署完成后要在实际环境中进行网络连通性测试、平安策略验证和应用系统测试。4.协作应用系统做好压力测试，依据压力测试结果调整系统配置。5.项目实施后进行肯定时间的试运行，在试运行期间要重点监控网络环境的运行状况、平安策略的验证和业务应用系统运行状况，若消失的问题要准时查找缘由并加以修正。在试点实施过程中验证方案的可行性和正确性。2.1.5.软件质量掌握软件质量保证过程包括对软件过程质量掌握和软件产品质量掌握。我公司在本系统项目组织中，由质量掌握组负责质量掌握和管理，采纳软件度量过程采集信息对软件过程和软件产品的质量进行管理。对软件过程质量的掌握通过度化并提取软件过程信息实现对软件过程的目标管理，量化的主要内容包括：产品质量、项目进度和资源占用。软件过程掌握一般采纳软件开发过程的节点掌握的方法。软件开发过程的节点掌握是提高软件开发的方案性和胜利阅历的可重复应用的重要支持手段。我公司在开发本系统的过程中，将充分采用该方法，确保本系统的高质、准时完成。在本系统的开发过程中，把涉及软件开发、应用的人员分为甲方、乙方，甲方代表各种层次的软件系统的用户，乙方代表软件开发商中各组织、各层次人员。软件系统的最终胜利基于甲乙双方对软件开发过程的共同掌握与管理，甲方侧重“需求”与“监督”职能，乙方侧重“供求”与“掌握”职能。甲乙双方实现职能的基础是软件开发过程的可视性，即从甲乙双方角度得到软件开发过程的可见性。如下图所示：图（a）表示一个对甲乙双方可见性极差的过程，甲方给出需求后，经过乙方的开发过程得到的是最终结果，甲方对软件开发过程没法参与。乙方中只有具体的开发人员了解局部的软件过程，高层管理人员没法得到开发过程中具体的过程状态信息，不能依据过程状态做出决策。图（b）表示一个对甲乙双方可见性较好的软件过程，在软件开发过程的特定阶段设置阶段掌握点（也称为里程碑甲乙双方依据阶段成果，从各自的角度提出过程改善与修改意见，掌握软件系统生产的质量、开发过程的效率及项目资源消费。2.2.项目管理机制2.2.1.项目汇报机制.《项目日报》：由项目经理或组长出具，汇报本日工作，明日工作方案及需要关注事宜；.《项目周报》：由项目经理或组长出具，汇报本周工作，下周工作方案及需要关注事宜；.《项目半月报》：由项目经理或组长出具，向甲方及高层汇报项目半月工作及下月方案，以及需要高层关注得事宜；.《周方案》：项目组内成员每周五向项目经理或组长提交《本周工作总结及下周工作方案》，项目经理或组长依据实际状况支配下周工作；.《月方案》：项目组内成员每月28日向项目经理或组长提交《本月工作总结、下月工作方案》，项目经理或组长依据实际状况支配下月方案；.项目例会：项目每周一及周五召开项目组例会总结上阶段问题，支配下阶段工作，会后生产《会议纪要》，发项目经理或组长及与会人员；.特别状况：如遇到会影响项目进度或产品质量以及设计资金方面得问题，需准时向直属领导汇报。2.2.2.项目沟通机制.项目接口：一般项目设立一个统一接外口人员，沟通问题由对外接口统一对接，特别项目可在项目经理或组长下设立一到两个技术人员作为对外接口，便利技术沟通；.问题沟通表：通常状况下项目对外沟通统一采纳《问题沟通表》的形式，技术人员将需要沟通问题发至项目经理或组特长，表内注明问题发起人，答复人，发起时间，答复时间，项目号，问题描述，问题反馈描述，附件等，由组长统一发出；.特别沟通：如遇到特别状况或特别问题，在领导授意的状况下，非接口人员可直接与外部人员沟通，沟通会需准时将信息反馈至项目组备份；.开会沟通：依据实际状况，项目经理或组长可依据项目需求支配会议，与甲方或其他合作方沟通，会议必需提前一周上报，以便总部协调支配；.沟通法律规范：全部技术邮件及传真未经上级领导批准，不得由接口以外的人员发出，全部接口人员发出的文件必需有备案，以供查询；2.2.3.项目过程管理人员管理.项目组全部成员听从项目经理或组长的支配，有任何问题直接向直属领导汇报；.按方案完成上级及项目组预订任务，如有延期准时上报；.每月进行员工绩效考核，考核结果直接与奖金和级别挂钩；.其他管理参照总公司管理机制；.项目内全部员工依据安排的任务包支配进行工作，问题及延期缘由归属，进行严格问责，予以相应的惩罚；.全部项目方面影响项目进度、预算、人员配置等方面的转变，必需以《项目通知单》的形式发出；文件管理.全部制定范围内的文档，必需在指定时间汇总至制定人员处。2.2.4.需求变更机制需求变更主要消失于项目的需求确定阶段，用户不能明确自己需要什么，或他们提出的需求只是依据当前的工作所需。随着开发工作的不断进展，系统开头呈现功能的雏形，用户对系统的了解也逐步深化。于是，他们可能会想到各种新的功能和特色，或对以前提出的要求进行改动。他们了解得越多，新的要求也就越多，需求变更因此不行避开地一次又一次消失。这时，假如开发团队缺少明确的需求变更掌握过程或采纳的变更掌握机制无效，抑或不按变更掌握流程来管理需求变更，那么很可能造成项目进度拖延、成本不足、人力紧缺，甚至导致整个项目失败。XX软件通过了国际CMMI4级认证，整理出了一整套切实可行的需求变更风险管控方式和需求变更流程。2.2.4.1.需求变更遵循原则建立需求基线，需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后(用户参与评审)，可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。制订简洁、有效的变更掌握流程，并形成文档。在建立了需求基线后提出的全部变更都必需遵循这个掌握流程进行掌握。成立项目变更掌握委员会，负责裁定接受哪些变更。CCB委员会由项目所涉及的多方人员共同组成，应当包括用户方和开发方的决策人员在内。需求变更肯定要先申请然后再评估，最终经过与变更大小相当级别的评审确认。需求变更后，受影响的软件方案、产品、活动都要进行相应的变更，以保持和更新的需求全都。妥当保存变更产生的相关文档。2.2.4.2.需求变更掌握为了有效削减需求变更，我方将在实施过程中，需求确认环节通过DEMO系统+需求文档与进行需求确认，DEMO系统中包含各个界面样式，每个界面内容细致到功能按钮，即需求确认环节可直观看到系统界面内容，从而尽可能削减开发过程中以及后期实施过程中的需求变更。而当需求变更消失时，我方原则如下：优先排序，分批实现每个需求的重要性是不同的。由于资源或技术条件的限制，会显得资源不足，因此不行能把全部的需求一次完成。把每个需求依据对效益的贡献打个分，排出个优先级来，优先级高的需求先实现，低优先级的需求支配到一下版式本实现。相互协作在争论需求时，开发人员与用户应当尽量实行相互理解、相互协作的态度，对能解决的问题尽量解决。即使用户提出了"过分"的要求，也会认真分析缘由，乐观提出可行的替代方案。合同约束需求变更给软件开发带来的影响有目共睹，所以在与用户签订合同时，建议增加一些相关条款，限定提出需求变更的时间，明确何种状况的变更可以接受、拒绝接受或部分接受，同时发生需求变更时必需执行变更掌握流程。用户参与需求评审作为需求的提出者，用户理所当然是最具权威的发言人之一。实际上，在需求评审过程中，用户往往能提出很多有价值的意见。同时，这也是由用户对需求进行最终确认的机会，可以有效削减需求变更的发生。2.2.4.3.需求变更流程节点责任人相关说明相关文档或纪录1收集需求变更客户方项1.1收集并整理各部门的新需求或需求变更内容，汇总写入【项目需求变更申请表】，并提交文档给项目负责人1.【项目需求变更申请表】2.【项目需求变更申请表】传真件1.2待项目负责人签字审核后，邮件此需求文档给项目组，并传真一份至项邮件：主送项目经理，抄送乙方项目总监、甲方项目邮件组邮件主题：“项目-需求变更申请-日期”2审核需求变更客户方项2.1接收项目经理提交的需求变更申请文档，对申请内容进行审核并签字确3审核需求变更XX软件项员3.1由乙方方项目经理发起会议，组织方项目小组针对需求变更内容进行争论、审核，并给出是否接受变更，估计完成日期等信息；邮件：主送客户方项目经理，抄送客户方项目负责人、方项目邮件组1.【项目需求变更申请表-反馈结果】2.【项目需求变更申请会议纪要】邮件主题：“项目-需求变更申请-评审结果-日期”4需求变更结果反馈反馈XX软件项4.1项目负责人对信息确认后，发出正式的【立项审批结果】、【项目经理任命函】；备注：项目邮件组由项目负责人组建；邮件：主送客户方项目经理，抄送客户方项目负责人、方项目邮件组1.【项目需求变更申请表-反馈结果】2.【新的补丁包、升级包或程序安装包】邮件主题：“项目-需求变更申请-反馈结果-日期”5评测需求变更评测客户方项5.1项目经理接收到项目经理发送过来的邮件后，组织内部人员进行测试，并更新需求结果状态；邮件：主送项目经理，抄送已方项目负责人、方项目邮件组1.【项目需求变更申请表-反馈结果-评测结果】邮件主题：“项目-需求变更申请-反馈结果-评测结果-日期”6需求变更验收验收双方项目负责人5.在需求变更解决后，由方项目负责人/项目经理组织针对此部分功能的验收确认工作；及其上级主管、TS部门经理、OMG1.【项目需求变更申请表-反馈结果-评测结果-验收】打印件，一式两份邮件主题：“项目-需求变更申请-反馈结果-评测结果-验收-日期”邮件及文档命名规章1需求变更申请项目-需求变更申请-日期2需求变更反馈项目-需求变更申请-反馈结果-日期3需求变更评测项目-需求变更申请-反馈结果-评测结果-日期4需求变更验收项目-需求变更申请-反馈结果-评测结果-验收-日期2.2.4.4.需求变更表功能需求变更申请单单据编号2022XXXX-001XX-项目名称-变更类型-年月变更类型报表分类报表名称报表用途使用部门/人报告模版变更原始纪录变更统计查询导出模版变更结果录入FTL变更交接单据变更项目经理意见签字：日期：项目负责人意见签字：日期：评审负责人评审成员变更评审对进度的影响对成本的影响对质量的影响变更风险预估技术评审结论可以变更请分别给出各变更内容的估计完成日期：OMG意见马上变更报表需求变更申请清单单据编号2022XXXX-001XX-项目名称-变更类型-年变更类型报表分类报表名称报表用途使用部门/人报告模版变更原始纪录变更统计查询导出模版变更结果录入FTL变更交接单据变更项目经理意见签字：日期：项目负责人意见签字：日期：评审负责人评审成员变更评审对进度的影响对成本的影响对质量的影响变更风险预估技术评审结论可以变更请分别给出各变更内容的估计完成日期：OMG意见马上变更2.2.5.缺陷管理2.2.5.1.缺陷管理流程2.2.5.2.缺陷管理内容描述流程任务流程责任角色输入输出操作说明1缺陷问题提出系统各使用人业务部门系统使用人员缺陷描述缺陷问题列表缺陷描述要求见“6、缺陷描述要求”2缺陷问题排发经理缺陷问题列表缺陷问题列表（处理优先级、处理人开发组长对缺陷问题进行分析、安>分析时，将询问类、理解错误类等问题处理掉，不留给开发人员；>对缺陷进行安排，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意>进行缺陷来源推断，进行对应的处理方案：1、代码开发问题：安排给开发人员进行处理；2、需求问题:与需求分析人员确认，需求分析人员给出解释，给出处理意见3、使用/理解有误问题：走回归测试流程3修改BUG开发人员缺陷问题列表（处意见等）BUG问题缘由分析、BUG解决方案、BUG开发代码开发人员依据缺陷问题列表信息，分析缺陷问题，编写缺陷问题缘由及具体的解决方案，修改BUG44测试4.1测试人员缺陷测试测试人员缺陷问题列表、修改的缺陷功能测试报告验证开发人员修改的BUG功能是否通过：通过后提交给缺陷提出人进行回归验证；不通过，则提交给开发组进步行缺陷问题分析及安排。4.2回归测试缺陷问题提出人缺陷问题列表、修改的缺陷功能、测试报告回归测试结果报告缺陷问题提出人，对使用理解有误问题以及测试人员验证缺陷通过的问题进行回归测试:通过后,回归通过则缺陷关不通过，则提交给开发组进步行缺陷问题分析及安排。5问题关闭测试人员回归测试结果报告缺陷问题列表（更新）缺陷提出人回归测试通过后，测试人员关闭完成处理的缺陷问题2.2.5.3.角色职责说明角色名角色职责开发组长及经理1、缺陷分析时，将询问类、理解错误类等问题处理掉；2、对缺陷进行安排，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意见3、依据缺陷来源进行缺陷安排；定期对缺陷库分析，找出常出错的模块，进行代码审查及提出优化、改进建议及方案开发人员分析Bug，写出问题缘由及解决方案，修改Bug缺陷问题提出人提出缺陷问题，回归验证需求分析人员1、解释需求，给出处理意见2、将缺陷库中的建议整理成需求文档。评审确定后列入需求版本开发方案测试人员验证Bug是否已被解决，对验证通过的缺陷进行关闭2.2.5.4.缺陷描述要求缺陷描述的要求为分类精确、叙述简洁、步骤清晰、有实例、易再现、简单问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查缺陷描述，看其是否描述清晰了缺陷，不好描述的把截图作为附件提交。具体要.单一：尽量一个报告只针对一个软件缺陷（在EXCEL表格中表显为一行报告形式应便利阅读.简洁：每个步骤的描述应尽可能简洁明白。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息；.再现：问题尽量要在自己机器上能复现方可入库（个别严峻问题复现不了也可入库，但需标明.有据可查：简单的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；亦可用HyperSnap之类的专用抓图工具；.用词精确：报告中不允许使用抽象词句：比如“有错误”之类；有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在缺陷报告中标识；缺陷描述示例：例一：功能点：用户管理中删除功能操作步骤：期望结果：实际结果：例二（模块或功能点也可在‘功能模块’字段中规定，则Bug描述中就不必写了）操作：1.打开新建向导；2.在“新建”中的“项例三（程序员知道期望结果的状况下）云南98土建操作：1.输入13-1702.F53.在F5中修改3240008的名称,处于编辑状态例四（建议、需求类）功能：预算页，子目排序后可恢复原挨次用途：用户误操作后可3.点击“下一步”期望结果：“项目名称”应<=80个字符，输入大一步”应有错误提示实际结果：进入“比重调整”界面4.到人材机,再回来实际结果：F5中变白板注：若3不处于编辑态切换则正常2.2.5.5.缺陷列表各属性及角色说明编号属性名角色说明1缺陷描述缺陷问题提出人通过EXCEL表格填写包括扫瞄器，IE分版本2菜单路径3操作步骤/过程5缺陷严峻级别6实际结果7缺陷提出人及联系方式8缺陷优先级开发组长9缺陷处理意见开发组长安排人/责任人/处理人开发组长指定安排人处理时间责任人估量，开发组长填写在BUG管理平台中填写缺陷状态不同阶段的人填写以BUG管理平台为准问题类型开发人员2.2.5.6.属性字典说明2.2.5.6.1.缺陷严峻级别类别名称说明备注1崩溃挂无法操作2重要的功能未实现或导致一个特性不能运行并且不行能有替代方案3次要的错误导致了一个特性不能运行但可有一个替代方案；4微小的错误是表面化或微小的（提示信息不太精确友好、错别字、UI布局或罕见故障等对功能几乎没有影响，产品及属性仍可使用；5建议建设性的意见或建议。2.2.5.6.2.缺陷优先级类别名称说明备注15阻挡相关开发人员的进一步开发活动，马上进行修复工作；阻挡与此亲密相关功能的进一步测试24必需修改，发版前必需修正33必需修改，不肯定立刻修改，但需确定在某个特定里程碑结束前须修正42假如时间允许应当修改51允许不修改2.2.5.6.3.缺陷处理意见类别名称说明备注1可修改可修改。表示Bug可以被修复或更正2重复重复。表示该Bug已经被其它测试人员找出来了（‘纯粹’重复或者开发认为缘由是相同的（但从测试来看，认为消失的地方有所不同、表现有所不同等）3延后延后。由于时间、进度、重要程度或者技术/需求等方面的缘由，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。（注：因‘Bug状态’字段中也有该值，依据各组各自使用状况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）4设计结构问题无法修改因设计结构问题无法修改。测试人员认为是Bug，不符合规律，也不符合用户的要求，但开发人员则认为是依据设计做的、只能如此处理，否则修改代价太大5不行复现不行复现。不能重现（如因Bug消失的环境重现不了了或以前消失的某个Bug自动消逝了（可能是在处理其他Bug的时候把这个Bug一并修复掉了）。（注：因TD本身亦带有‘是否复现(Reproducible)’字段，依据各组各自使用状况，可以用它来标识，或者不用它而在‘处理意见’字段中用该值标识出）2.2.5.6.4.问题类型类别名称说明备注1需求问题由于需求的问题引起的缺陷2架构问题由于构架的问题引起的缺陷3设计问题由于设计的问题引起的缺陷4代码问题由于编码的问题引起的缺陷5测试问题由于测试的问题引起的缺陷6环境问题7部署、版本问题2.3.文档管理机制建立完善的文档管理体系，包括文件命名法律规范、名目法律规范、文件传递规章在规定时间内向甲方提交项目建设需求调研、设计、开发、测试、实施各个阶段的方案、方案、报告、质量标准、项目进展状态及相关文档。项目结束后，我方依据本技术规格书的要求把项目相关文档全部移交给甲方。2.4.项目交付成果我方承诺自合同签订后15天内向甲方供应软件安装所必需的技术要求文件一份，具体内容包括但不限于项目实施方案、保密合同。我方在软件安装调试完毕后供应全套安装、调试、使用、升级所必需的纸质与电子档技术文件各3套，包括但不限于以下内容：1）软件安装实施文档（含需求分析、蓝图设计、概要设计、具体设计、测试报告、2）软件上线报告；3）软件配置文档说明书；4）用户手册及系统维护手册。技术文件字迹清晰，内容完整，甲方有权无偿复制上述文件。我方依据项目进程和要求向买方供应相应的交付物，包括但不限于以下内容：原厂授权（我方产品属于自主研发，拥有自主学问产权）。供应本次项目开发的软件全套源代码，允许第三方做二次开发。2.4.1.实施文档《现场工作日程支配方案》，在实施中的各阶段，对于所发生的需要在现场进行较训方案》等工作方案中未包含，则需要在工作开头前双方共同制订好《现场工作日程支配方案》，并严格据此执行，需要双方现场实施负责人签字生效。《现场工作周报》，在现场实施工作中，为了把阶段性的工作任务具体落实完成，需要合作双方每周一之前由公司实施工程师与用户组共同制定本周的工作方案，给出每个工作日上、下午的工作内容，以及双方的预备工作。方案制定完成后用户项目组向全部相关部门和领导发布，开头执行；实施中双方相互监督依据原方案开展工作；周五时双方负责人共同对本周方案执行状况进行总结，对原方案填写工作总结，具体描述各项方案的完成状况，未完成的部分应写明未完成缘由和责任归属，必要时双方协商一起进行加班处理，力争按时完成；对于不能按时完成的必需调整到下周方案中进行。《用户项目报告》，对于实施中各阶段较长时间不在用户现场进行的，或项目处于用户试运行、维护期的状况，为了使用户能够准时获知项目的进展状况和公司开发小组的工作状况，公司将在开发阶段每周向用户相关领导提交此报告，维护期内每月至少提交一次。《阶段评估报告》，实施中当某一阶段性目标实现后，公司将对该阶段双方联合开发组的工作状况进行总结，编写该报告并向工程领导小组提交，准时总结阅历教训，为下阶段工作打好基础。以下是对上面的实施过程中将产生的文件汇总说明：名称作用评审级别变更掌握调研《需求调研方案》《需求调研大纲》《项确定需求调研的预备工作、内容、方法方式及人员和日程支配双方现场实施负责人双方现场人《系统需求规格说明明确用户业务需求双方项目负双方项目负责人设计《系统概要设计方案》《数据库设计方案》《系统集成设计方案》《系统具体设计方案》描述整个系统软件的模块设计，具体设计，数据库设计，供开发编码使用双方项目负双方现场人软件开发《项目开发方案》软件开发的日程进度，分工，检查点设置，提交成果等方案双方现场实施负责人双方项目负责人软件测试《测试方案及方案》《系统联调测试方案》《测试问题卡》《测试总结报告》符合ISO9000质量保证体系规定的功能测试、同行间测试文档软件确定现场实施预备工双方现场实双方项目现场《项目实施方案》作、人员和日程支配、施负责人负责人培训方案、阶段目标等系统培训《培训方案》《培训方案》《培训考勤纪录》《培训总结》明确培训环境条件及方式，参与人员，课程课时等要求培训纪录，培训效果总结，是否达到目标双方现场实施负责人双方现场人系统安装《数据库安装名目》《系统安装、配置手《系统维护手册》《用户操作手册》现场安装、调试和提交软件的相关文档《软件功能清单》所提交软件全部模块结构划分，功能描述用户系统人员《软件交付书》软件已在现场安装、调试、培训完成，基本可以进入试运行证明用户系统负《软件问题及修改纪实施中发觉的软件问题和用户提出的具体修改意见，以及对其所作修改和确认纪录行《试运行方案》进行项目试运行验收《验收方案》《验收报告》《项目总结》《项目技术报告》《验收方案》《售后服务方案》《售后服务方案》开发过程项目总结，技术总结，数据库设计字典等验收相关文档工作《现场工作日程支配方案》需在现场进行较长时间的一般工作日程支配双方现场实施负责人双方现场人《用户项目报告》较长时间不在用户现场时向用户信息服务系统汇报项目进展和工作状《现场工作周报》现场工作周方案双方现场实施负责人双方现场人《阶段评估报告》某阶段性目标实现后进行总结，向工程领导小组提交，为下阶段打好基础2.4.2.培训文档我公司在培训前将给用户供应培训讲义和电子文档，经过用户审核认可后的培训讲义，我们才予以使用。现场培训包含的主要相关文档有《数据库安装名目》、《软件安装培训文档序号培训对象培训资料1系统管理员《数据库安装手册》《数据库说明手册》《系统安装、配置手册》《系统维护手册》《API示例及应用说明文档》2关键用户《用户操作手册》3最终用户《用户操作手册》4领导层《用户操作手册》2.4.3.培训光盘培训讲师在现场进行培训时可通过其他手段比如摄像机、录屏软件、刻录光盘将培训的整个过程纪录在案。即可解决远程培训过程中消失的断电、网速不稳定等现象。培训光盘用多媒体的形式把系统的使用方法呈现给用户。用户在使用过程中遇到不会操作的问题时可以随时到光盘的相应章节中观看系统操作录像，系统培训光盘也可用来对新来用户进行系统培训。2.5.项目风险掌握供应商对项目风险的严格把控和对项目胜利要素的有效采用直接打算了项目能否胜利。我公司具有多年行业阅历，能够对项目风险完善的前期猜测和过程把控，能够充分调动各种乐观因素促进项目进展。2.5.1.项目胜利的关键要素项目胜利关键要素单位自领导层的支持软产品和解决方案身组织结构的协作支持和维护服务业务流程和数据新产品的发布及升级单位自身的调整质量保证支持业务部门的参与产品技术的特长项目实施项目管理的特长高质量的硬件行业应用询问的阅历支持维护服务实施资源的支持性能调查对客户的引导及培训网络支持最佳的业务实践2.5.2.风险分析项目风险分析客户方开发方软件与硬件环境不匹配，导致无法安装系统与客户沟通不足，不能准时发觉问题并解决问题2.需求反复变更，导致开发工作反复2.需求调研不深化，不能构建完善的业务模型3领导重视程度不足，重要决策无人技术力气不充实，不能按时完成各项任务4.实际操作人员工作繁忙，无法协作项目实施工作4.解决方案可可行性差没有明确项目负责人，各项工作协调困难完成项目的责任感和使命感不足6前期供应业务数据不充分，导致开发人员对需求理解不深化2.5.3.风险掌握我公司依据多年从业阅历，总结了一套完整的风险掌握程序，从预防掌握、过程掌握和订正掌握三个方向入手，抓好项目的方案制定，准时汇报和收集项目进展信息，精确推断分析存在风险。1.通过制定具体的项目方案从项目的策划阶段进行预防掌握。2.通过准时收集和汇总项目进展信息，准时发觉项目项目中的潜在风险。3.通过精确推断风险趋势、深化分析风险产生缘由，准时消退风险隐患。2.5.4.项目平安掌握系统上线后为了保证稳定、平安运行，我公司将从网络平安、登录平安、权限管理、数据备份、环境平安、异地容灾共计六个方面保证项目的平安。序号类别措施1网络平安建立平安的网络环境，防止非法侵入内部网络。系统支持高峰时间段的正常访问，支持用户登录的优先级：对于领导层等特别用户，系统需要支持随时可以登录系统，2登录平安系统应保证使用的平安性，包括数据平安性与ID授权的平安性，拒绝非法用户进入系统和合法用户的越权操作，避开系统遭到恶意破坏，防止系统数据被窃取和篡改。此外还应通过软件方面的平安设置，避开合法用户对于数据的无意破坏。3权限管理系统需要支持每个用户有独立的用户名和密码，只有具有访问权限的用户才可以登录系统，系统支持对离职的用户进行失效操作。4数据备份系统需要支持对数据进行每日增量备份，周全备份，全年异地备份。在系统数据库消失问题，系统需要支持对备份的数据恢复至系统。为了降低历史数据对系统运行速度的影响，系统需要支持对N年之前的数据进行归档。5环境平安应有独立的并能防火、防盗、防水等措施的空间用于存放系统服务器。6异地容灾为了保证系统的平安，建立冗余系统或异地容灾，当一套系统故障，冗余系统会连续供应服务。2.6.后期运维建议我方供应的系统在不同的服务器环境下能分别配置生产系统、开发系统及测试系我方供应整体维护服务解决方案，包括系统备份、冗余以及故障恢复策略及方案。系统备份系统供应数据备份工具软件，支持可敏捷设置数据备份方式、备份频率及历史备份数据的保留周期。系统可设置当前数据库数据保留时间长度，保留期限之外的数据可自动转存。至历史数据库中，确保当前数据库保持适量大小，避开因数据量不断增加而影响系统响应性能。系统支持关系数据库分区功能，并能够自动进行分区。系统有数据查询和统计功能，且具有很好的运行性能。MySQL冗余数据方案互联网数据量很大的业务场景，往往数据库需要进行水平切分来降低单库数据量。水平切分会有一个patitionkey，通过patitionkey的查询能够直接定位到库，但是非patitionkey上的查询可能就需要扫描多个库了。此时常见的架构设计方案，是使用数据冗余这种反范式设计来满意分库后不同维度的查询需求。系统通过采纳服务同步双写的方式进行数据冗余，由服务层同步写冗余数据，这样数据全都性相对较高，不简单，服务层由单次写，变两次写。故障恢复策略在数据库运行过程中，可能会消失各种各样的故障，这些故障可分为以下三类：事务故障、系统故障和介质故障。系统依据故障类型的不同，实行不同的恢复策略。1、事务故障及其恢复事务故障表示由非预期的、不正常的程序结束所造成的故障。造成程序非正常结束的缘由包括输人数据错误、运算溢出、违反存储爱护、并行事务发生死锁等。发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消退该事务对数据库的影响，要采用日志文件中所记载的信息，强行回滚（RoLLBAcK）该事务，将数据库恢复到修改前的初始状态。为此，要检查日志文件中由这些事务所引起的发生变化的纪录，取消这些没有完成的事务所做的一切转变。这类恢复操作称为事务撤销（uNDo具体做法如下。（1）反向扫描日志文件，查找该事务的更新操作。（2）对该事务的更新操作执行反操作，即对已经插入的新纪录进行删除操作，对己删除的纪录进行插入操作，对修改的数据恢复旧值，用旧值代替新值。这样由后向前逐个扫描该事务已做的全部更新操作，并做同样处理，直到扫描到此事务的开头标记，事务故障恢复完毕为止。因此，一个事务是一个工作单位，也是一个恢复单位。一个事务越短，越便于对它进行UNDO操作。假如一个应用程序运行时间较长，则应当把该应用程序分成多个事务，用明确的coMMIT语句来结束各个事务。2、系统故障及其恢复系统故障是指系统在运行过程中，由于某种缘由，造成系统停止运转，致使全部正在运行的事务都以非正常方式终止，要求系统重新启动。引起系统故障的缘由可能有硬件错误（如CPu故障、操作系统）或DBMS代码错误、突然断电等。这时，内存中数据库缓冲区的内容全部丢失，虽然存储在外部存储设施上的数据库并未破坏，但其内容不行靠了。系统故障发生后，对数据库的影响有以下两种状况。一种状况是一些未完成事务对数据库的更新已写入数据库，这样在系统重新启动后，要强行撤销（uNDo）全部未完成的事务，清除这些事务对数据库所做的修改。这些末完成事务在日志文件中只有BEGINTRANsLATl0N标记，而无COMMIT标记。另一种状况是有些已提交的事务对数据库的更新结果还保留在缓冲区中，尚未写到磁盘上的物理数据库中，这也使数据库处于不全都状态，因此应将这些事务已提交的结果重新写入数据库。这类恢复操作称为事务的重做（REDo）。这种巳提交事务在日志文件中既有BGINTRANSCATION标记，也有COMMIT标记。因此，系统故障的恢复要完成两方面的工作，既要撤销全部末完成的事务，还要重做全部已提交的事务，这样才能将数据库真正恢复到全都的状态。具体做法如下。（1）正向扫描日志文件，查找尚未提交的事务，将其事务标识记人撤销队列。同时查找已经提交的事务，将其事务标识记入重做队