165_赣中某县域道路交通事故处理平台信息系统项目质量管理

ONEPSOFT | 软考学习知识库

---

赣中地区某县域的道路交通事故处理长期依赖人工受理与线下流转，接警登记、现场勘查、责任认定、理赔流转等环节分散在各交警中队手中，终端设备种类繁多、兼容性适配工作量被低估，算法识别在复杂光照与天气条件下准确率不稳定，并发访问峰值集中在办理高峰时段、性能压力大，事故处理周期长、群众等待久。为把道路交通事故处理业务数字化，该县公安交管部门于 2023 年 8 月发起了县域道路交通事故处理平台信息系统项目，经公开招标由我司承建，合同额 1180.32 万元，建设周期 12 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合事故处理全流程数据，实现接警登记在线化、责任认定辅助化、理赔流转协同化。建设内容包括接警登记、现场勘查、责任认定、理赔流转、统计分析与报表五个模块，并与各交警中队及保险机构对接。技术方案上，业务表单与流程依托低代码平台快速配置，微服务网关统一管理接口，业务数据存放于 OceanBase 数据库，消息通过 RocketMQ 异步推送，前端基于 Vue3 组件体系实现，后端以 Java 17 与 Spring Boot 编写，应用部署在县政务云信创环境，安全建设按等保三级实施。团队采用矩阵式组织，全队 24 人，需求、研发、测试、实施运维与数据治理各岗配齐，编制按模块规模与接口数量核定，联调高峰期另调集厂商力量集中攻坚。项目于 2024 年 8 月通过终验，上线后系统可用率稳定在 99.9% 以上，全年重大故障 0 起，资金结算差错实现连续 12 个月零发生。

12 个月里，我按质量管理的过程主线推进质量工作，把标准定在规划、把过程管在执行、把结果核在监控，下面分三个过程说明。

一、规划质量管理：把 " 合格 " 的定义定清楚

规划质量管理是确定质量目标与验收标准、并规划达成路径的过程，其作用在于让 " 合格 " 从一开始就有清晰的定义，避免事后扯皮。项目启动后，我组织项目骨干，结合交通事故处理的业务规范，牵头编制了《质量管理计划》，把质量要求写成三类可核验的标准：功能上，接警登记、现场勘查、责任认定各环节完整可用，接警受理成功率 100%、责任认定文书生成无差错；数据上，事故数据准确率不低于 99%、文书归档完整率 100%；性能上，办理高峰并发下响应时间不超过 3 秒。三类标准共同构成质量基线，任何交付都要对照基线核验，同时每条标准都对应到具体的采集方式与核验时点，功能标准在模块验收时核，数据标准在每周对账时核，性能标准在压测阶段核，标准因此不悬空。标准不是凭空定的，我们专门走访了两个业务量最大的中队，把一线民警对事故录入、文书生成的痛点逐条记下，再折算成可测的质量目标，基线因此既严又实。基线也不是挂在纸上的，我们把它拆成十几个可测指标，每两周采集一次数据与基线对比，指标偏离超过容忍范围的，责任人在质量例会上当场说明原因并给出纠偏时限，基线因此始终有约束力。同时我们把质量责任落到岗位：需求岗守需求质量，开发岗守实现质量，测试岗守验收质量，实施岗守上线质量，分工写进岗位说明书并纳入考核，责任从计划阶段就有人承接。

二、管理质量：把过程质量盯在每一天

管理质量是把质量标准融入开发、测试与评审活动、并持续推动过程改进的过程，其作用在于让质量要求落到每一天的执行里，而不是停在计划书上。我们建立了每周质量回顾与里程碑质量评审机制：周回顾看质量数据，评审把关键节点，问题在过程中暴露、在过程中解决，而不是攒到收尾。以现场勘查模块为例，其开发过程中出现过照片上传失败的偶发问题，我们在一周内的质量回顾中及时识别，定位到是部分老旧终端浏览器的兼容问题，当场补充了兼容处理，问题没有蔓延到后续模块。针对终端设备种类繁多、适配工作量被低估的问题，我们用散点图做了适配风险评估：以各终端型号为样本，横轴为适配工时，纵轴为遗留缺陷数，图形清楚显示部分老旧型号设备工时高、缺陷多，落在高风险区，据此把适配与测试资源优先投向这类设备，并逐台建立适配台账，适配进度的颗粒度从 " 批次 " 细化到 " 单台 "，每台设备的适配状态、遗留问题、负责人逐条登记，周例会上逐条过账，适配阶段的问题明显减少。

针对算法识别在复杂光照与天气条件下准确率不稳定的问题，我们用根本原因分析追根因：先问为什么识别准确率时高时低，再问为什么阴雨天气误报偏多，追到根子是夜间与阴雨场景的训练样本不足，据此补充了样本并调整了模型阈值，识别准确率由 87% 稳定到 94.6%。以责任认定的照片识别为例，晴天场景识别率一直不错，但阴雨天的车身照片经常识别失败，补充夜间与阴雨样本并调参后，识别结果稳定可用，民警现场操作因此省去了大量手工录入。针对高峰并发压力大的问题，过程管理还靠制度托底：关键模块强制代码评审与双人复核，质量问题逐条登记造册、闭环销号，测试用例覆盖不足的场景当场补齐，团队逐渐养成了 " 先想质量、再做事情 " 的习惯，12 个月里没有出现为赶进度而降标准的妥协，高峰时段的核心流程始终稳定运行。

三、控制质量：把交付结果核到最后一环

控制质量是检查交付成果是否满足既定标准、记录质量活动结果并推动纠正的过程，其作用在于为验收提供客观依据，把住交付前的最后一道关。我们设立了分级核验：开发自查、测试复核、独立评审，上一级不通过绝不流入下一级，问题在每一关都被拦下来。针对高峰并发性能压力，我们用逐项检查按峰值场景、性能目标、资源余量三个维度逐项核对压测数据，发现数据库连接池配置偏小，高并发下请求排队明显，据此调整了连接池参数并优化了缓存策略，压测全部达标，系统可用率稳定在 99.9% 以上。针对事故数据准确性问题，我们用统计抽样按事故类型与中队类别分层抽取样本，逐条核对数据的完整性与准确性，抽到的差异当场定位原因、限期修正；针对文书归档完整性问题，我们用检查表按文书要素、归档时限、流转完整性三个维度逐项核对，归档完整率始终保持在 100%。以责任认定文书为例，我们曾发现个别文书的电子签章时间与系统记录不一致，抽样核对后定位到是时钟同步问题，统一校准后完全一致，这类细节不核验到位，责任认定的时效统计就会失真。

收尾阶段，我们对照质量基线做了最终核验：接警受理成功率 100%，文书归档完整率 100%，关键业务响应时间压缩到 1.8 秒，资金结算差错连续 12 个月零发生，全年重大故障 0 起，各项指标全部达到或超过计划标准，项目一次通过验收，各交警中队与保险机构对系统的认可度明显提升，公安交管部门认为这套质量管理做法值得在系统内推广。核验不是只在收尾做，每个里程碑的核验记录都归档在案，验收时拿出的是一整条完整的数据链，各方因此对交付质量心服口服。复盘整个项目，我的体会是：质量不是验收前才想起来的事，而是从标准定下的那一刻就开始积累的事。规划阶段把标准定清楚，执行阶段把过程盯住，监控阶段把结果核实，三个过程环环相扣，缺了任何一环，质量都会失守。这套按过程主线推进的质量管理做法，后来被整理成公司在公安交管类项目的质量管理参考，供后续同类项目借鉴使用。质量管理的价值，正在于把无形的 " 靠谱 " 变成有形的标准与记录，让交付始终经得起检验。