160_江浙某经济开发区终端安全管理系统信息系统项目质量管理

ONEPSOFT | 软考学习知识库

---

江浙地区某经济开发区的终端安全管理长期依赖人工巡检与事后处置，终端资产、安全策略、告警处置等数据分散在各企业网管与园区运维中心手中，项目周期紧、法定验收时点刚性、进度压缩明显，外部厂商交付质量不稳、集成验证反复返工，联调单位多、进度同步与责任界面复杂，终端底数不清、安全风险难以及时发现。为把终端安全管理数字化，该园区网信主管部门于 2023 年 7 月发起了经济开发区终端安全管理系统信息系统项目，经公开招标由我司承建，合同额 168.12 万元，建设周期 13 个月，我担任项目经理，对项目全过程管理负责。

项目建设目标是整合终端安全全流程数据，实现资产盘点在线化、策略下发自动化、告警处置闭环化。建设内容涵盖终端资产、策略管理、告警处置、安全审计、统计分析与报表五个模块，并与各企业网管及园区运维中心对接。技术方案上，后端服务以微服务方式拆分解耦，服务间调用纳入 Istio 服务网格统一治理并支持灰度发布，安全数据落库 GaussDB，热点数据经分布式缓存提速，前端采用 Vue3 组件体系，后端以 Java 17 与 Spring Boot 编写，应用部署在市政务云国产化环境，安全建设按等保三级标准同步实施。团队采用矩阵式组织，全队 24 人，其中需求分析 4 人、研发 11 人、测试 4 人、实施运维 3 人、数据治理 2 人，人员配置随模块规模动态调整，关键节点加派驻场支持。项目于 2024 年 8 月通过终验，上线后资金结算差错实现连续 12 个月零发生，用户满意度测评由 78 分提升至 94 分。

质量管理说到底，就是回答三个递进的问题：交付的东西凭什么说合格，做出来的过程怎么保证不跑偏，最终成果拿什么来证明。本项目周期紧、外部单位多、集成测试返工多，质量稍有闪失，安全策略下发错误、告警处置漏报，后果不堪设想。从实际体验看，质量管理的成败往往不取决于某一个环节做得多好，而取决于标准、过程、结果三道关口是否都立得住：标准立不住，后面全是糊涂账；过程管不住，问题会一路蔓延到交付；结果验不实，交付就没有说服力。13 个月的实践让我体会到，质量管理要守好三道关口：需求关把标准定住，开发关把过程管住，交付关把结果验住。下面围绕这三道关口，结合本项目的具体做法展开说明。

一、需求关：先把质量标准写清楚、把责任分到位

质量管理的第一道关口是需求关，回答 " 合格的标准是什么、谁对质量负责 "。项目启动后，我组织项目骨干，结合终端安全业务的合规要求，牵头编制了《质量管理计划》，把质量要求写成三条：功能上，资产盘点、策略下发、告警处置各环节必须完整可用；数据上，终端资产准确率不低于 99%、告警闭环率 100%；性能上，策略批量下发时响应不超过 5 秒。三条要求共同构成质量基线，任何交付都要对照基线核验。标准不是坐在办公室里拍脑袋定的，我们专门走访了园区两家代表性企业，把一线网管平时最头疼的终端漏管、告警误报等痛点逐条记下，再对照合规要求折算成可测的质量目标，基线因此既严又实。

标准写清楚只是第一步，责任分到位才落地。我们做了一张质量任务分解表，把质量责任落实到具体岗位：需求岗承接需求质量，开发岗承接实现质量，测试岗承接验收质量，实施岗承接上线质量，每张表上都注明检查节点与考核方式。针对第三方厂商交付质量参差的问题，我们提前把厂商交付物与验收标准写进协议，约定不合格不接收；针对周期紧的问题，我们把质量要求与进度计划同步排期，明确每个里程碑的质量验收点，从源头避免 " 赶进度丢质量 "。需求关守住了，后续工作才有标尺。

二、开发关：把质量要求嵌进开发联调，让过程不跑偏

质量管理的第二道关口是开发关，回答 " 怎么保证做出来的过程是合格的 "。我们建立了每周质量回顾与里程碑质量评审机制：周回顾看质量数据，评审把关键节点，问题在过程中暴露、在过程中解决，而不是攒到收尾。每个里程碑还设置了质量闸口，闸口项未清零前不允许进入下一阶段，从流程上卡住质量风险。以资产盘点模块为例，其开发过程中出现数据字段口径不一致的问题，我们在一周内的质量回顾中及时识别，当场统一口径并更新设计，问题没有蔓延到后续模块。

针对联调参与方多、责任界面不易划清的问题，我们用亲和图把各方的联调诉求按主题归并聚类，理出接口规范、数据格式、测试标准三类核心议题，据此制定了统一的联调规范，各单位的责任边界白纸黑字写清楚，并组织联合评审，联调过程中的扯皮明显减少。针对集成测试反复返工的问题，我们用直方图对缺陷来源做了分布统计：按缺陷类型统计发生频次，发现接口联调与安全策略配置两类缺陷占比最高，据此把测试资源优先投向这两类，并建立了缺陷复盘机制，每批缺陷修复合归后分析根因、预防复发，返工率明显下降。开发关的日常管理还靠制度兜底：关键模块强制代码评审与双人复核，质量问题逐条登记造册、闭环销号，团队逐渐形成了 " 先想质量、再做事情 " 的习惯。

三、交付关：把成果核验到底，让结果经得起追溯

质量管理的第三道关口是交付关，回答 " 交付的东西到底合不合格 "。我们设立了交付核验三道闸：开发自查、测试复核、独立确认，一道不过不进入下一道，问题在每道闸都被拦下来。三道闸不是走过场，每一道都有明确的核验标准与记录，上一道不通过，下一道绝不接手。针对终端资产台账的准确性，我们按终端类型与企业类别做分层抽样，逐条核对资产信息的完整性与准确性，抽到的差异当场定位原因、限期修正；针对告警处置闭环，我们用检查表按告警来源、处置时限、闭环状态三个维度逐项核对，闭环率始终保持在 100%。核验发现的问题我们按月归类分析，针对高频问题类型优化开发与测试流程，让问题在源头被减少，而不只是事后修正。

临近终验时，我们安排了一场交叉复核，由测试负责人与实施负责人分别核对方所负责模块的完成证据，复核发现的问题全部限期整改、销号存档，复核结论作为验收附件随卷归档。复核不是走过场，我们把每一个模块的复核记录都列出来逐条过，谁负责的模块有问题，当场明确责任与时限，复核结论也因此经得起事后追溯。交付关我们还注意把握质量与等级的关系：系统追求高质量而不是高等级，不过度设计、不堆砌功能，而是把核心安全流程做扎实、把数据做准确，让质量与成本、进度保持平衡。比如终端资产管理界面，我们没有为了 " 好看 " 堆砌大量图表，而是围绕网管最常用的资产台账与告警视图做精做细，界面简洁但实用，用户评价反而更高，这说明质量的核心是匹配需求而不是堆砌功能。项目最终一次通过验收，资金结算差错连续 12 个月零发生，用户满意度由 78 分提升到 94 分，各企业网管与园区运维中心对系统的认可度明显提升，网信主管部门认为这套质量管理做法值得在园区推广。

复盘整个项目，质量管理带给我的收获是：需求关定标准、开发关管过程、交付关验结果，三道关口环环相扣，任何一道失守，质量都会前功尽弃。这个体会我讲给项目组听时，大家都认同一点——质量不是验收前才想起来的事，而是从第一条需求、第一行代码就开始积累的事。这套把标准、过程、结果串成闭环的做法，后来被整理成公司在网络安全类项目的质量管理参考，供后续同类项目借鉴使用。