【《A公司某财税软件开发项目质量管理改进方案设计案例》6600字】

A公司某财税软件开发项目质量管理改进方案设计案例目录TOC\o"1-3"\h\u15590A公司某财税软件开发项目质量管理改进方案设计案例 1139051.1质量改进对策 175321.2A公司某财税软件需求阶段改进 2140111.2.1完善需求及UI的评审机制 2258201.2.2制定统一的UI设计规范 5313581.2.3增加需求的变更控制 6284061.2.4针对产品经理定期内部培训 7289701.3A公司某财税软件开发阶段改进 732431.3.1代码规范管理 8207341.3.2代码审核管理 820331.3.3规范自测制度 8158811.3.4针对开发人员定期内部培训 958491.4A公司某财税软件测试阶段改进 9141581.4.1组建专业测试团队 9165631.4.2加强测试用例的评审机制 11250631.4.3加强测试文档的管理 12质量改进对策根据第三及第四章节，本文通过对A公司某财税软件开发项目的现状考察发现了其存在较多质量管理问题，并对问题进行了深入分析，本章将以全面质量管理理念及PDCA方法论为指导，针对存在的问题及原因分析，提出一套适合于A公司某财税软件开发项目的质量管理改进方案。具体如下:（1）需求阶段改进在完成需求分析后，要做好需求确认评审工作，以便避免即将交付的需求产生逻辑漏洞；一旦需求变更，要做好相应的变更控制。确定质量方针、目标、明确责任人、评审计划等，再根据PDCA，对需求变更方面进行控制，确保需求质量；针对对技术不熟悉以及专业水平较弱的产品经理，定期组织内部培训，从“源头”进行改进。（2）开发阶段改进为了保证开发质量，避免由于开发工程师个人的背景及经历原因导致的代码个性化较重，从而造成的维护成本高的问题，公司内部需要制定代码规范管理制度，统一代码管理；同时为了确保每位开发工程师的代码质量，需要制定代码审核规范；为了避免不必要的后期缺陷及返工成本，加强开发工程师的自测管理；针对能力较弱的开发工程师，定期组织内部培训，尽快提升人员素质，确保开发质量。（3）测试阶段改进从A公司的组织架构可以看出，A公司缺乏专业的测试团队。而从第三章及第四章的内容也可以发现，A公司某财税软件开发项目的测试阶段由于缺乏专业的团队导致了测试不全面的问题。为了保证测试质量，需要组建专业的测试团队。同时测试用例作为整体测试阶段的重要依据，需要加强其在测试及验收阶段的评审机制，保证测试用例的全面性、可靠性。在测试文档方面，要加强文档的管理，保证变更及时性。A公司某财税软件需求阶段改进需求分析是该项目的根本，能否满足用户的实际需求，能否长远发展，直接关系到项目的成功与否。所以，通常情况下，需求部分是整个项目管理过程中的主要部分。如何保证需求分析的精准及全面是A公司某财税软件开发项目的关键问题。需求阶段的改进主要体现在三个方面：需求的评审及跟进、需求的变更流程以及人员的培训。完善需求及UI的评审机制根据第4章对A公司某财税软件开发项目分析可知，A公司某财税软件开发项目在需求分析的过程中，存在多种的问题，如需求分析不清、逻辑漏洞、变更频繁、设计图与原型图不符等，这些问题会导致项目缺乏计划性，导致成本增加、质量降低。基于此，要对输出到开发阶段的需求进行严谨地评审及跟进，并从源头上加强沟通，来杜绝掉需求变更频繁、逻辑漏洞、原型图不符等的情况。以此为依据，通过参考战略合作公司项目开发过程中的需求评审及跟进流程以及项目干系人之间的头脑风暴，对项目原需求分析与设计阶段的流程图进行改进，得到改进后的需求分析与设计阶段的流程图，如图5.1及图5.2所示。图5.1需求分析与设计阶段原流程图图5.2需求分析与设计阶段改进流程图在以上需求分析及设计流程中，主要针对需求收集方式及评审流程进行了改进。原需求收集阶段主要是由产品经理通过与客户沟通或与实施组长沟通，获得需求后自行整理，并转化为原型和文档。改进的需求收集是要遵循“三次握手”原则的，所谓“三次握手”原则，即是需求进行反复确认的过程，最终达到各方对需求全面精准掌握的目的。在此次收集需求的过程中，主要是由产品经理与客户进行面对面沟通，项目经理旁听，必要时需要有实施团队的组长的参与。这样就减少了对需求理解不到位或产生误解的可能性，通过这种方式来尽量减少需求的变更频率。而需求的评审也由原来的一次评审增加到三次。在原流程之中，需求与文档同时准备完成后进行评审，之后直接交付设计团队进行设计，产品经理自行验收后交付开发团队；在评审过程中如果出现问题，再次修改后也无需二次确认，可以直接交付设计团队。这样会造成需求可能不全面、逻辑不够完善及UI图可能由于验收不仔细造成的与原型产生偏差的情况。改进后的评审流程分为三轮，第一轮为原型初步完成时的评审，主要评审需求是否完善，由产品团队内部召开，以此来评判整体的逻辑是否顺畅。当第一轮评审结束后，产品经理开始撰写对应的需求文档，同时可将原型文件交付设计团队进行UI初版设计。需求文档完成后进行第二轮评审，此次评审的目的主要是对整体需求的细节是否到位、需求是否全面、逻辑是否畅通进行评审。根据原型图及需求文档的内容得到的最终版UI图会在产品组内部进行第三次评审，以确保UI图的风格统一性及与原型的一致性。制定统一的UI设计规范A公司某财税软件由于其用户需要长时间在软件上进行工作的处理，诸如录入凭证、冲销存货等，容易产生疲劳。因此软件的界面需要简洁，同时色彩度不能像其他官方网站一样采用明艳的色调，对舒适度要求较高。因此除了在5.2.1章节改进的需求评审的流程中保障设计图与原型图的一致性以外，还需要制定一套统一的UI设计规范来提高质量管理的效率。通过与设计部的主管进行沟通，结合公司内部其他项目的设计效果，制定统一规范方向：视觉与全局规则。视觉方向主要分为色彩、字体和图标，通过对主色、功能色、中性色的定义，规范整体项目的色彩范围；通过对字体的字号、行高以及不同场景下的字体颜色、粗细的定义，以及设定图标的角半径、比重、负空格，保证视觉的一致性。全局规则主要包括布局、按钮、边角、导航的设计规范，由于财税软件的表格内容较多，因此对其进行重点规范，保证界面的简洁。增加需求的变更控制虽然通过需求收集阶段的控制手段可以尽量减少需求后期变更的发生，但针对敏捷型项目来说，需求变更不可避免。而且，因为企业内部文化原因，一旦领导提出建议，项目组可回旋的余地极小。根据以往项目经验，一旦领导提出需求，最后基本都会增加到需求里，最终会造成需求的变更，进而造成项目可能的延期，为了避免延期的发生，进而收紧工期赶工，从而造成质量问题。所以对于本次项目建设，制定了需求变更流程对需求变更进行严格管控，如图5.3所示。图5.3需求变更控制流程图需求变更可以由项目经理、产品经理、需求开发人员、设计人员或者用户提出，发起方填写变更申请单，给出需求描述与变更理由。需求变更提出后，交予项目经理确认，由项目经理初步确定变更级别；对不可行的需求变更，由项目经理、技术部、业务部门、专家组与提出变更者协商，取消变更请求。如果变更可行，项目经理在《需求变更申请单》详细描述变更理由及变更的影响范围，并交由用户进行签字确认，确定最终变更需求，以防需求变更结果客户否认。需求一旦变更就意味着成本增加，所以必须通过高层确认，项目管理办公室(主要由公司高层组成)分析变更必要性和技术可行性并给出结论，批准变更提交或拒绝。变更批复后，需要将变更部分纳入需求文档、同步更新项目相关文档(包括设计文档、测试文档等)。如果变更可能导致项目进度延期，将同步调整项目计划。质量管理员监督变更实施过程并协助配置管理员对变更后的交付件进行版本控制。针对产品经理定期内部培训主要针对产品经理进行一些简单的技术知识培训以及专业技能和业务知识分享。本项目的产品基本上对于技术知识没有深入了解，甚至有些对于技术的一些基础理论也没有接触过，这种情况会导致没有技术经验的产品经理在进行需求分析设计的时候，和开发沟通会产生一定的难度。一旦在需求沟通过程中出现了需求的沟通偏差，会造成返工或影响到最终产品的质量。因此，对于一些完全没有技术背景的产品经理，要定期组织一些简单的培训课程或分享课程，同时推荐一些简单实用的技术类书籍，比如《写给产品经理的技术书》等。由于产品经理的能力参差不齐，为了保障需求输出的质量，可以定期开展产品经理的技能分享会，每周一次，进行分享。从而达到互相督促，互相进步，学以致用的目的。针对财税软件的业务特殊性，定期由财税专家对产品经理进行培训及分享，以此保证产品经理对于业务的熟知度，更好地理解客户需求，进行需求的设计。A公司某财税软件开发阶段改进软件开发的过程是质量保证的重点之一，加强研发过程中代码的规范性和可读性，加强代码编程的质量，提高开发效率。为实现此目标，A公司某财税软件开发项目的软件设计过程中，改进内容包括四项：明确和统一代码编写规范，提高代码的规范性和可维护性；进行代码的审核管理；规范自测制度；针对开发人员进行培训。代码规范管理由于A公司某财税软件在开发过程中涉及的编程语言主要为PHP，因此在项目的开发团队内部采用《PHP编码规范》，为了渗透编码标准，组织整体培训，确保开发人员对编码规范的掌握。定期对开发人员培训和宣导代码编写规范和注释规范，以确保开发团队统一的编码规范，加强代码规范性。在此过程中，要形成相应的管理办法对开发环节进行质量控制，对源码进行考核，建立健全的开发机制，降低开发人员个人素质对项目的影响。精细化设计中的功能，讨论和确定如何提高产品的质量，除了强调功能、性能的高要求外，还要从安全性、可靠性、稳定性、效率性、可维护性和易扩展性等方面提出对软件设计的质量要求，结合A公司某财税软件开发项目的特性，由于涉及到的客户票据量很大，隐私性较强，系统安全性和稳定性尤其重要，分别从接口安全性、资源分配、算法逻辑等方面提出设计要求。代码审核管理通过《PHP编码规范》只能解决代码规范一致性、提高代码可读性问题，为了提高软件服务性能和软件编码水平，需要成立专门的代码审核小组，负责对软件开发工程师提交的代码进行审核，剔除不合理或者不恰当的代码设计，提高代码的健壮性，只有审核通过的代码才会合并到测试分支进行提测；为了更好的实现代码审核小组的代码审核工作，将代码提交系统同OA进行关联，当代码进行提交后，可以实时通知代码审核小组的审核人员，让代码审核人员了解代码的实时变化，并可以直接对代码进行审核评论，从而进一步有效地控制代码质量。规范自测制度公司一直在倡导在软件开发过程中即对软件产品进行检查，尽早发现问题。对于软件开发工程师而言，自测是一种必要的流程。通过交付测试团队前的自测，有一些隐藏的缺陷将会被软件开发工程师发现。若是没有经过自测或者重视度不足，软件开发工程师将这些项目提交测试阶段后，会被负责该项目测试的软件测试工程师发现并将其打回。通过在自测的过程中增加PDCA小循环，增加对软件项目的自测执行情况的确认环节，则避免了软件项目被反复打回提交的尴尬现象。对问题的跟踪要不断重复循环，注重测试的反馈和跟踪，提高测试的执行，从而达到持续提升和改进产品质量的过程。严格要求软件开发工程师在完成对应的项目模块的开发工作后，需要对其所开发的项目模块进行完整的自测，从功能模块级别上确保项目的功能正确性，并且可以通过自测引导实现更简洁、高效的软件设计。只有经过检验的产品，才具有一定的质量保证，通过软件工程师的自测实现对项目质量的保证。针对开发人员定期内部培训通过第四章的问题分析已经可以发现，本项目的开发团队中存在能力较弱的团队成员，由于自身能力的原因会出现所负责的模块缺陷率较高的情况；同时也存在对于业务的熟知度较低的成员，为了帮助这两种类型的团队成员快速成长起来，避免后续的项目中重复出现由于人员问题导致的质量问题，可以在内部技术小组中组织定期“老员工”对“新员工”的专业技能培训。“老员工”温故知新的同时带动“新员工”一起成长，保证后续项目的产品质量。同时定期组织业务培训会，保障每位相关的开发成员对于业务的熟知度，进而保障产品质量。A公司某财税软件测试阶段改进组建专业测试团队软件测试是软件产品校验及软件质量管理中极为重要的过程之一，其作用是识别并及时纠正产品中的问题和缺陷，最终交付质量高、客户认可的软件产品。在A公司某财税软件开发项目的软件测试工作中，实施人员和产品人员“兼职”部分重要功能模块的测试，但由于专业度不足以支撑，因此并不能得到最终质量的保证。因此对于A公司某财税软件开发项目来说，首要任务是组建专业的测试团队，有专属的测试人员对产品进行测试和校验。测试团队包括客户测试团队和项目测试团队，除了项目中开发人员的自测，项目测试团队的INT测试，客户测试团队的UAT测试，同时项目中的产品经理、开发人员也要参与并配合测试工作的进行，以确保测试工作的高效性和全面性，测试工作角色及职责，详见表5.1。表5.1工作角色职责表组织结构角色职责项目测试组项目经理跟进测试进度，协调测试人员与其他相关人员的工作，确保测试顺利进行客户测试经理监控项目的测试进度和测试管理工作，确保测试顺利进行软件测试组项目组测试人员负责系统的整体测试工作；负责项目缺陷的汇总分析，并跟进修复情况；编写测试用例及最终测试报告客户测试人员负责系统的UAT测试；对系统已实现的内容与需求相比较，确保无偏差技术支持产品经理在测试人员测试前及测试中提供需求确认支持开发工程师在测试工作中提供技术方面的支持测试团队组建后，要针对不同阶段采取不同的测试策略。（1）集成测试在完成单元测试后，便进入集成测试阶段。在公司的其他项目中，都是采用非增量式集成的方式，也就是把测试对象一次性打包，进行整体测试。采用这种方式的优点在于时间短，并且能有效发现测试中的问题，导致测试过程中问题的数量会逐渐增多。不过，由于测试范围大，所以发现bug的几率也大。所以，在这个阶段经常会多种多样的问题，而且，存在定位bug不准的问题。定位bug不准也就不好修复bug，所以该方法导致集成测试质量较低，测试成本较大。本次项目采用螺旋式模型，迭代开发频繁，所以采用了增量式集成测试，逐步将已集成和未集成的模块进行打包测试，测试集成问题。QA组通过PDCA进行管理，通过以下两方面对集成测试过程进行改进:1）非增量式集成测试逐步扩大测试范围，可以准确定位bug、回归测试，提高测试质量;2）最大程度利用测试管理工具redmine，将其功能开发到极致，提升测试效率。（2）系统测试集成测试后，便进入系统测试阶段。系统测试相对而言就比较深入了，需要对需求有一定了解，所以，在项目建设的初期——需求分析与设计阶段，就需要核心测试人员介入到项目中，同时由于A公司某财税软件开发项目的财税专业性，需要对财税相关知识有所了解，后续如果需要，需要适当对测试人员进行专业性培训。等待测试人员对项目的功能需求、性能要求等掌握后，再由该测试人员组织系统测试工作，检验产品是否满