Files
telecom-rd-project-template/.agents/skills/telecom-rd-standards/references/source-documents/03-overall-rd-standard.md
T
2026-07-28 22:30:20 +08:00

216 lines
21 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 中国电信软件研发规范总体规范(修订版)
> 脱敏整理版:已移除编制人员、联系人和联系方式,并合并无意义硬换行。技术条款、章节和示例以原始 DOCX 为争议核验依据。
附件3
中国电信软件研发规范总 体 规 范 (修订版)
中国电信集团有限公司
## 2023 年 12 月
i
> 编制人员信息已移除。
版本变更历史
## 1 文档说明
### 1.1 编制说明
为进一步提升全集团的软件研发水平,实现软件分级分类管理,编制中国电信软件研发规范体系, 用于指导和规范全集团的软件研发过程, 提升软件质量。下图为中国电信软件研发规范体系结构:
软件研发总体规范用于规定软件研发过程的总体要求,包括总体原则、项目角色设置 、交付成果 、开发过程及安全等等, 同时作为各分册的索引。
软件需求管理规范制定研发过程中需求开发和管理的要求,包括需求的调研、分析 、编写 、评审 、变更 、验收等阶段的规范要求。软件编码规范对软件开发过程进行有效的编码规范管理,使得最终的软件产品具有良好的风格和统一的结构, 提高代码可读性和可维护性, 减少代码缺陷。代码管理规范制定代码仓库设置 、开发模式 、代码提交 、操作规范及代码版本管理等要求。制品管理规范制定制品全生命周期管理 、制品版本 、制品第三方组件管理、制品溯源管理等方面的要求。流水线管理规范制定流水线配置、流水线步骤、流水线触发类型等方面的要求。测试管理规范制定测试流程、测试文档、缺陷管理、验收标准等方面的要求。部署管理规范制定软件产品部署到生产环境时的要求,包括部署准备、部署审批流程 、部署任务设置及部署执行等方面。安全规范制定代码安全管理 、质量管理 、评估方法等方面的要求。
### 1.2 文档结构
本规范由文档说明、总体要求、软件研发阶段及交付成果、项目组织和角色、软件开发过程 、附件等部分构成, 各章节的主要内容如下:第 1 章文档说明,对规范的编制、文档结构、使用范围、起草单位、解释权、版权和本规范用到的术语进行说明。第 2 章总体要求, 对规范的编制原则进行说明。第 3 章软件研发工作流、角色和交付成果,对研发过程涉及的各个工作流(阶段), 涉及的角色及职责, 以及每个工作流应交付的成果进行描述。第 4 章软件开发过程,对软件研发的模式,涉及的工作流,包括配置和变更、需求 、设计 、实现 、测试 、发布和部署等进行说明。第 5 章软件安全要求, 规范中国电信软件安全研发流程。第 6 章为相关附件, 包括质量指标及解释, 各类交付件模板。
### 1.3 适用范围
本规范适用于指导中国电信软件研发工作。
### 1.4 起草单位
本规范的起草单位是中国电信集团公司。
### 1.5 解释权
本规范解释权属于中国电信集团公司。
### 1.6 版权
本规范的版权属于中国电信集团公司。
### 1.7 名词解释
## 2 总体要求
### 2.1 总体原则
1. 体系化原则:构建一个全面的软件研发规范体系,覆盖软件研发流程的需求、分析和设计 、实现 、测试 、部署发布以及配置管理等工作流。2. 分级规范原则: 中国电信软件研发处于发展阶段,各项目团队处于不同的能力水平,各类项目的要求也不尽相同,需要基于研发能力分级进行研发过程的管控,定义适合不同级别研发能力的规范要求,适应不同研发能力的团队,不同类型项目的需求, 同时为各项目团队提升研发水平给出明确指引。软件研发能力分为C0-C4, 其中 C0 为业界最佳实践建议, 不做强制要求,其它 C1-C4 级别逐级增强 。定义如下:
软件研发能力的适用项目要求:C4 级, 适用于研发链项目 、战略级项目 、核心能力级重大攻关项目;C3 级, 适用于国家项目 、核心能力级重点研究项目;C2 级, 适用于专业能力级项目 、省级重点项目;C1 级, 适用于创新探索级项目和其他未评级项目。软件研发总体规范 、需求管理分册 、代码管理分册 、制品管理分册 、流水线管理分册 、测试管理分册和部署管理分册均按上述能力级别提出分级要求。3. 可检查可度量原则: 围绕研发效能提升制定规范要求, 明确需要采集的度量数据 。 中国电信研发云平台作为研发规范的实施支撑平台,按照分级分类实施原则, 逐步实现规范检查和度量指标获取的完全自动化。4. 安全保密原则: 严格落实集团安全保密要求,软件研发过程相关的文档和代码等均属于电信内部资料, 不得通过暴露在互联网的媒体、平台 、工具等进行存储 、处理和传输。
## 3 研发工作流 、 角色和交付成果
### 3.1 软件研发工作流
软件研发过程主要包括以下几个工作流: 需求 、分析和设计 、实现 、测试、发布和部署 、配置和变更管理。
### 3.2 项目角色设置
研发项目角色设置及相关职责说明:
### 3.3 交付成果
各工作流需要相应交付的成果如下表:
## 4 软件开发过程
软件开发过程中的主要工作内容及相互之间的关系的示意图如下:
本规范按照上述软件研发工作内容进行组织。涉及企业数据的使用和研发,参照《中国电信〔2022〕121 号 关于进一步推进数据共享和知数用数相关工作的通知》相关规定执行。
### 4.1 软件开发模式
为更快暴露项目的风险,应对需求的变化,建议采用迭代式开发模式(C2),推荐 2-4 周为一次迭代(C0) 。每个迭代需要建立功能、需求和测试用例之间的双向追踪关系,迭代结束应建立基线,并按照代码管理和制品管理的要求对代码和组件进行版本打标 。(C1)
### 4.2 配置和变更管理
配置管理通过执行版本控制、变更控制等规程, 以及使用合适的配置管理软件,来保证所有配置项的完整性和可跟踪性,从而保证软件项目生成的产品在软件生命周期中的完整性和一致性。(1) 标识变化;(2) 控制变化;(3)保证变化被适当地实现;
4 向可能有兴趣的人员报告变化。
需要纳入配置管理的内容:(1) 属于产品组成部分的工作成果, 例如源代码 、需求文档 、设计文档、测试用例等; (C1)(2)在管理过程中产生的文档例如各种计划 、 监控报告等 。(C2)项目所有配置项必须存储在电信内部服务器上,不得使用外部公共云存储等服务 。(C1)项目需要在需求 、迭代 、测试用例 、代码版本 、制品版本和产品版本之间建立双向追踪关系 。(C2)源代码管理详细要求见《中国电信软件研发规范-代码管理分册》;需求变更控制详细要求见《中国电信软件研发规范-需求管理分册》;缺陷管理详细要求见《中国电信软件研发规范-总体规范》的 5.5.7 节。
#### 4.2.1 版本管理
源代码、制品和产品的发行版本必须维护可回溯性 。制品的版本号应与对应源代码的版本号保持一致。详细要求见《中国电信软件研发规范-代码管理分册》和《中国电信软件研发规范-制品管理分册》 。(C1)
### 4.3 需求
需求阶段的主要目的通过建立客户需求和软件开发过程一致的协调,让客户和软件开发小组共同理解系统业务,并在功能和非功能各方面达成共同理解和一致意见。需求管理规范用于需求的调研、分析、编写、评审、变更、验收等阶段的规范要求。项目应制定需求的管理和变更流程。在经过需求评审完成需求定义后,需要建立基线, 管理和控制需求项的变更, 使需求项的变更受控 、可追溯 。(C1)
项目应对需求状态进行跟踪, 以维持需求与项目开发计划、后续各项工作成果之间的双向追溯性 。(C1)需求是项目开展其它活动的基础。需求管理的交付件是软件分析设计和测试的主要依据之一。详细要求见《中国电信软件研发规范-需求管理分册》。
### 4.4 分析设计
软件分析和设计是把需求转化为软件系统的重要环节,软件设计的优劣在根本上决定了软件系统的质量。软件系统的技术选型须符合《中国电信软件开发统一技术栈要求(试行版)》(中国电信科创〔2023〕 1 号), 新项目采用《中国电信软件开发组件清单》 内统一组件, 存量项目按文件要求实施。软件设计通常可以分为概要设计和详细设计。概要设计的目的是说明对程序系统的设计考虑,包括程序系统的基本处理流程、总体结构、模块划分、功能分配、接口设计、运行设计、安全设计、数据结构设计和出错处理设计等, 为程序的详细设计提供基础。详细设计的目的是说明一个软件系统各个层次中的每个程序(每个模块或子程序) 和数据库系统的设计考虑, 为程序员编码提供依据。项目需要提供概要设计文档(C1) 和详细设计文档(C2) 。 内容如上所述,可参考附件模板 。设计说明书的内容需要跟系统同步更新(C1) 。
### 4.5 实现
#### 4.5.1 编码要求
编码工作需在云电脑内进行, 所有代码不出研发云 。(C1)编码需要关注代码风格,保证代码的简洁 、可读性和可靠性(C1) 。各种语言编码规范要求详细见《中国电信软件研发规范-编码规范分册》。系统/模块间的接口调用参照 OpenAPIhttps://www.openapis.org/ 的相关要求(C4) 。编码规范和安全规范的要求分为三个级别: 强制 、推荐和参考。
n 【强制】: 必须遵守的规范 。违反此类规范会给项目带来安全或性能风险, 产生相关漏洞 。亦或造成产品质量 、可维护性等方面的问题。n 【推荐】: 建议遵守的规范 。在强制级别的基础上结合最佳实践, 考虑到易理解 、易掌握,给开发编码更大的空间,如果没有更好的显著理由,建议遵守。n 【参考】: 可选择遵守的规范 。此类规范通常为解决某问题的一种最佳实践, 可能受具体场景的变化影响,不排除有更好的改良版。编码需要遵循代码安全性要求(C1), 详细见《中国电信软件研发规范-安全分册》。代码需要进行单元测试,并且测试覆盖率需根据语言及项目类型的不同达到一定的要求(C1) 。详细要求见《中国电信软件研发规范-测试分册》。各种不同编程语言的命名规范按照各个编码分册的要求,如果涉及到使用域名对代码进行组织的, 例如 java 的 package 名称,使用 cn.chinatelecom .<分公司/专业公司缩写>.<自定义名称>,分公司/专业公司缩写见《附件 13-组件域名管理规则》。
#### 4.5.2 代码质量扫描要求
代码质量扫描在软件开发过程中为代码提供质量管控,对源代码进行静态扫描, 检测代码中存在的质量 BUG 、安全缺陷 、语言风格等质量问题并提供修复建议,分析代码的重复率、复杂度与单元测试覆盖率,帮助项目团队从开发阶段了解代码风险和存在的质量问题, 从而进行持续改进。代码质量扫描根据检测结果中问题的类型和严重程度,获取阻断级问题数量、严重级问题数量、可靠性评级、安全性评级、可维护性评级、重复率、行覆盖率和分支覆盖率等代码质量度量指标,作为项目质量评估的重要数据来源。具体的扫描规则和指标解释参见附件《代码质量扫描规则与指标解释》。软件开发期间, 项目团队在提交代码评审时, 需进行代码质量扫描, 以获取代码的质量度量指标 。(C2)
#### 4.5.3 代码安全扫描要求
源代码安全分析技术通过对软件的源代码静态的语义分析、结构分析、数据流分析、控制流分析、缓冲区及配置分析等技术手段来发现其中潜在的风险,可识别在开发期间软件源代码的安全漏洞和质量问题并提供修复指导,可有效帮助开发人员消除代码中的缺陷, 为软件的信息安全保驾护航。在软件开发期间、软件上线发布前应进行源代码安全扫描, 并达到相应软件开发能力的分级要求,确保软件系统上线前尽可能减少代码缺陷,降低信息安全风险, 实现前置安全防护的目标 。(C1)安全扫描基本要求(C1) ,详细见《中国电信软件研发规范-安全分册》。代码安全扫描结果评估与定级(C2) ,详细见《中国电信软件研发规范-安全分册》。代码安全扫描缺陷处理、缺陷审计、代码安全基线(C3),详细见《中国电信软件研发规范-安全分册》。
#### 4.5.4 代码管理要求
代码管理规定软件项目版本管理的对象、存储目录、分支、权限 、维护等内容,使软件项目版本管理流程化并规范化,确保在系统开发和实施过程中项目的完整性和一致性 。 代码管理须满足《中国电信代码安全管理实施指引(试行)》相关要求。项目的源代码必须纳入代码版本控制系统进行管理 。(C1)项目需要制定代码分支管理过程,使用基于 Git 的代码版本管理工具 。(C1)对于发布版本,需要在主分支上打上版本标签,版本命名符合规范要求。(C1)详细要求见《中国电信软件研发规范-代码管理分册》。
#### 4.5.5 软件制品管理
制品管理从制品版本 、基线 、制品库分类分级管理 、制品晋级 、制品清理、制品下载等过程阐述了具体的操作,使得对制品的管理更加标准化、具体化。包括制品名称命名规范, 制品版本命名规范, 制品清理策略等。
研发过程中使用的第三方制品必须从统一制品仓库获取。第三方制品的引入和使用须符合《中国电信软件开发统一技术栈要求(试行版)》(中国电信科创〔2023〕
## 1 号) 。(C1
项目在开发功能时需要查看统一制品库是否有满足需求的自主研发组件,优先考虑复用已有组件 。(C0)详细要求见《中国电信软件研发规范-制品管理分册》。
#### 4.5.6 流水线管理
流水线管理的目标是规范项目组对流水线的使用。项目组应根据自身项目等级, 遵照该管理办法正确使用流水线以及合理配置流水线的各项信息。流水线的内容如下图所示:
项目根据项目类型等因素选择适合的流水线内容。详细要求见《中国电信软件研发规范-流水线管理分册》。
#### 4.5.7 缺陷管理
软件开发过程中需要对缺陷进行分级管理(C1) 。根据缺陷对系统的影响,分为四级: 致命 、严重 、一般和轻微。项目需要制定缺陷管理流程,包括争议处理,设置缺陷处理优先级,对缺陷进行闭环管理(C1) 。每个迭代需要记录缺陷的标题 、类型 、等级 、优先级 、处理人 、测试人员、测试环境 、状态 、修复时间等信息。详细要求见《中国电信软件研发管理规范-测试管理分册》的第 6 节。
### 4.6 测试
软件测试类型主要包括单元测试、集成测试 、系统测试和验收测试 。其中单元测试由开发人员进行, 其他类型测试活动由项目的测试人员执行。测试活动的输入包括经过评审后的项目总体计划(不包含在本规范中),《软件需求规格说明书》和《概要设计说明书》。测试过程包含以下几个活动:(1)测试方案编写:项目测试负责人根据项目总体计划,编写《测试方案》,安排测试进度, 分配测试人员等;(2)测试需求分析: 测试工程师理解项目具体需求, 并参与项目需求评审;(3) 用例编写: 测试工程师根据《软件需求规格说明书》 、《概要设计说明书》编写《集成测试用例》 、《系统测试用例》 、《性能测试用例》;(4) 测试实施: 根据测试用例进行测试, 记录结果并编写测试报告。测试计划和测试用例必须经过评审, 评审通过后由项目经理批准确认。测试规范为软件测试工作提供详细的指引,指导测试工程师完成测试阶段工作 。详细要求见《中国电信软件研发规范-测试管理分册》。
### 4.7 发布和部署
产品部署的目的是用来为确保最终用户可以正常使用软件项目、产品而进行的活动。产品部署环节是指将产品,包括配置文件、用户手册、帮助文档等进行收集 、打包 、安装 、配置 、发布 、 回滚的过程。部署管理明确研发项目部署到生产环境时,在研发平台侧的相关流程和要求,包括在进行部署之前需要完成的准备工作,部署审批流程,部署任务设置及部署执行等方面。
研发项目在生产平台侧部署的相关流程和要求,按照对应生产平台的相关规定执行。
### 4.8 评审
软件研发阶段的评审是由一组有资格的人员对软件设计和开发的输出进行评价,以判断确定研发过程的输出能否实现软件产品预先定义的规格,同时通过评审标识出与规格和标准的偏差, 识别潜在问题和风险。评审的方式主要有以下三种:l 预评审: 至少提前 3 个工作日申请评审, 同时将评审材料发给评审参加人员预审,评审人员在会审前反馈问题,填写评审反馈表。有效的预评审应有不少于 50%的评审成员反馈预评审结果。l 会议评审:通过组织正式评审会议,对阶段工作成果或交付物进行评审,评审参加人员发现、讨论、确认问题和缺陷。会议评审会输出评审记录、评审缺陷汇总, 相关材料应所有评审人员签字确认。l 离线评审:通过邮件或平台工具组织,将评审材料分发给评审参加人员,评审人员采用离线的方式审查材料,在要求的时限内提交评审结果,输出评审记录 、评审缺陷汇总。研发过程中里程碑交付成果的评审要求如下:
评审通过标准:l 通过: 不需要对产品进一步的确认 。未发现导致产品背离需求的缺陷,只有少量细微的缺陷需要作者修正。l 有条件通过:有少量的重要缺陷,但是修改这些缺陷不会对工作产品的主要结构造成实质性的影响。修正后的工作产品需要经评审专家确认后,即通过评审。l 不通过:有较多的重要缺陷,或者修改缺陷会对工作产品的主要结构造成实质性的影响。由责任人修改后,评审组织者需要重新组织评审活动;由评审组织者决定, 是否对被评审对象的全部进行评审。
## 5 软件安全要求
安全性是软件产品的一个关键需求。在软件开发的各个阶段都应当考虑安全性, 并且为关键的应用程序和敏感信息的应用程序提供更高级别的安全性。软件开发安全规范规范中国电信软件安全研发流程,提升研发人员安全编码意识和安全威胁防范能力,指导开发人员在保证系统安全性的情况下完成系统开发,从而有助于在编码阶段减少安全漏洞的产生,在部署阶段可以规避常见的安全问题, 提升整体软件或系统的安全防护能力。详细要求见《中国电信软件研发规范-安全分册》。
## 6 附件
### 6.1 《客户访谈记录表》模板
附件1 -客户访谈记录模板.xlsx
### 6.2 《需求追踪表》模板
附件2-需求追踪表模板.xlsx
### 6.3 《需求追踪表 (变更) 》模板
附件3-需求追踪表(变更)模板.xlsx
### 6.4 《单个模块需求文档》模板
附件4-单个模块需求文档模板.xlsx
### 6.5 《软件需求规格说明书》模板
附件5-软件需求规格说明书模板.doc
### 6.6 《概要设计说明书》模板
附件6-概要设计说明书模板.doc
### 6.7 《详细设计说明书》模板
附件7-详细设计说明书模板.doc
### 6.8 《测试方案》模板
附件8-测试方案模版.docx
### 6.9 《测试用例》模板
附件9-测试用例模板.xlsx
6.10《缺陷追踪表》模板
附件1 0-缺陷追踪表模板.xlsx
6.11《测试报告》模板
附件1 1 -测试报告模板.doc
6.12《代码质量扫描规则与指标解释》
附件12-代码质量 扫描规则与指标解释
6.13《组件域名管理规则》