【系统分析师】示范论文.论软件质量保证

2018年8月，公司为了打造国内通用的人力资源平台，立项了薪酬系统，我有幸参与了该系统的架构和开发管理工作，并担任项目经理一职。该系统面向小微企业，为其提供员工管理，考勤管理，社保和薪酬的计算，以及工资单的生成和发送等功能。本文就以此为例，论述质量保证各项工作在软件开发中的展开过程。在计划阶段，从代码规范，流程治理，责任划分，进度 等方面规划，为后续的工作制定了规则和时间表；审计阶段，责任人根据计划，针对团队开发流程，代码质量，变更等方面采取审计，以及对变更进行跟踪并记录；报告阶段就是对工作进行全面的总结，针对问题制定策略，然后反馈现有的工作中，以及来帮助团队成长。通过团队的8个月的努力，项目在2019年4月准时上线，并获得了业务部门的好评。

随着政府大力提倡”双创“，新产业领域登记的企业数量快速增长。在平台方面，越来越多的央企和地方政府搭建起了孵化平台和园区；在办公场地方面，市场涌现大量共享办公室，用来降低创业门槛；软件方面，员工需要管理，社保和薪酬需要计算，由此我司的项目应用而生。为了打造国内通用的人力资源平台，帮助提升企业的办公效能，解决人员招聘，福利管理，薪酬计算和支付，个税等问题，为国内小微企业提供一站式的人力资源管理系统。该系统功能包括：员工和组织管理，考勤管理，社保和公积金计算，薪酬和个税的计算，工资单的生成和发布，薪资的提交和审核，以及生成报盘文件等功能。我作为项目经理，负责团队的建设，参与制定技术规范，协调各角色的协作流程。经过团队10多人8个月的努力，项目于2019年4月上线。

系统能保质保量上线，质量保证不可缺少，所以开发过程中是尤为重视。根据项目实践，质量保证工作分为这么几部分：计划，审计，检查，跟踪，报告。计划阶段就是决定怎么做，谁来做，什么时间做等问题；审计则是对计划，报告，以及策略做评审，通过后才可以执行；检查就是对评审过的计划执行情况的Check；跟踪就是对一些变更或者问题进行跟踪防止遗漏；报告是我对前面工作的总结和回顾，提取经验，反馈的下次迭代的流程。对于具体某个工作，上述几个阶段是串行的，但对于不同的点阶段可能是交叉的。同时结合实际项目敏捷的开发方法，这几个阶段也采用迭代的思想，不断反馈，优化流程。

实际项目中，这些阶段间隔是模糊的，在不同知识域他们迭代的阶段是不同的。其中审计包括两部分，即计划的审计和报告的审计，工作中一般都是直接在计划讨论完成后直接进行评审，或者Review介绍后直接进行评审，同时对于检查和跟踪也是一个人来做。 所以这里就将质量保证分为三部分：计划，检查，总结。下面就结合项目实践从质量保证的三部分内容展开论述。

一.保证计划：这里的计划包括计划和对计划的评审，其中计划决定做什么，怎么做，谁来做，什么时间做。质量保证保证的是软件的质量，软件的质量包括代码质量，文档质量，以及影响软件质量的流程。代码质量方面，在开发前就协同架构部和组内的一些高级工程师指定了代码的编码规范和编码规则，比如：命名，流程控制，注释，异常处理以及数据库SQL脚本的编写方法。文档方面，通过引入CMMI的一些文档模板，解决日常开发工作中文档模板，技术性的文档采用wiki进行管理，开发是前后端分离的开发思路，采用可以共享的API工具来管理。相对于代码质量和文档质量，流程贯穿于所有阶段的，也是涉及各个角色，不同关注点就有不同的流程。项目中涉及到比较重要的流程是代码管理流程，该流程包括分支管理，前后端联调，模块集成，持续发版，发版的SQL加班管理等串联而成。如果说流程是一条河，做什么就是河流的宽度，怎么做，谁来做，什么时间做，就是这条河流随着时间维度中不同阶段由不同的人来执行操作，因为不同的侧重，负责人，时间节点和方法论都不同，这里不做赘述，下面详细描述。

二.过程检查：就是责任人根据计划来进行执行和对执行结果的检查，如果检查出来问题也需要进行评审。在文档管理方面，接口文档的正确和实时性很重要，如果采用传统的wiki进行管理，不仅仅是开发人员负担，同时在有变更的时候难免出现忘记和遗漏的情况，造成较大的沟通成本，后来采用了一个类似PostMan的互联网产品进行API管理，该产品可以很快进行模拟HTTP调用，同时可以将调用用例直接转换为文档，分享给别人，前端人员直接可以登录就可以访问，这样既保证了实时性，也保证了文档完整性，同时也减轻了写文档和构建驱动程序负担。代码方面，因为能力各有区别，编码风格也不尽相同，但是为了代码的可读性和后期的维护，代码质量必须保证。在计划阶段已经对编码风格，规范做了约束，实际项目中产品一味地强调进度和界面，后端人员难免会为了进度而牺牲质量。我采取的策略是代码审核，在提交时必须经过指定的高级来进行审核才可以提交，采用的工具是微软的TFS，审核人同提交人负同样的责任。代码检查保证了开发提交代码的质量为输出，但好的代码的前提完整需求，为了保证产品输入需求的完成性，在需求需求评审后1天左右进行需求检查会议，由前端，测试，项目经理 对模块负责人提问，能回答问题就认为通过，根据问题的情况，决定是否需要继续迭代检查。

三.结果总结：这个总结包括阶段性总结和过程中的总结，总结出的结论可能是问题，也可能是优点，对于优点需要继续保持，对于问题需要研究解决策略和方案，然后反馈到质量保证工作中，同时该问题点也会加入下次的迭代的质量保证的CheckList中来检查执行情况。项目中例行的会议就是SprintReview会议，项目采用敏捷开发方法，在每次Sprint上线后都会进行SprintReview会议，会议主要讨论本次Sprint遇到的问题，做的好地方，以及自己的建议和意见，每个人必须发言。同时有时产品，PMO也会参与，会议需要对每个人的发言进行记录，会议提倡只提出问题和解决方案，不研究方案优劣，以此来激发成员发言的主动性。问题一般设计到代码规范，需求问题，同产品的协作等问题，会议后我会根据具体问题情况，跟具体人来讨论了解，或者组织小会议专门讨论，决定问题是解决还是保留，更新到新的流程中去。

通过上述工作的开展，项目在2019年4月上线，试用阶段没出现过严重问题，BUG也能迅速修复，工作得到了业务部门和项目管理部的肯定。上线后经过对BUG分析，因为集成导致的BUG占用较大比例。原因是需求评审后又很快就进入开发阶段，因为缺少进行从较高的层面进行设计，以及对以前的逻辑的影响并没有反应到本次需求中,到最后模块间和新旧功能集成时出现返工。针对原因，决定采用以下措施：提前参与需求分析；迭代延长一周，这周进行需求Check和整体方案研究工作；需求检查时采用头脑风暴，及早发现本次需求涉及到的原逻辑，然后处理；前期进行接口设计，为后续的集成打好继承。经过本次Review，我明白了质量不仅仅只需要保证开发过程，同时也需要重视对该过程影响的因素，只有这样才能保证质量保证的价值。路漫漫，相信每个问题都是我们前进的台阶，也相信产品会有更好的前景。