GJB5000A 军用软件研制能力

中央军委装备发展部 · 军用软件能力认证

GJB5000A 军用软件研制能力成熟度模型

GJB 5000A-2008 — 军用软件能力成熟度模型

军工软件的"段位制"——从初始级（有就行）到优化级（自己进化）五级能力跃迁。
22个过程域 + 4大类别——覆盖软件工程/项目管理/支持/过程管理的全生命周期——不是"证书"是"能力评级"。

5级

成熟度等级

12-24

个月获评(三级)

22个

过程域(PA)

20-80

万元打包(三级)

OVERVIEW

GJB5000A：军用软件工程能力的"五级段位制"

它不是一张"合格证"——而是一套"能力标尺"——从1级到5级，每一级要求的企业管理体系完全不同

💻

什么是GJB5000A

GJB5000A-2008《军用软件研制能力成熟度模型》是中央军委装备发展部发布的国家军用标准——其原型是美国卡内基梅隆大学软件工程研究所(SEI)的CMMI-DEV。GJB5000A将软件研制能力分为5个成熟度等级（初始级/已管理级/已定义级/已定量管理级/优化级）——每级包含若干过程域(Process Area, PA)——共22个过程域覆盖项目管理/工程/支持/过程管理四大类别。它不是"通过/不通过"的二元结果——而是"你到了哪个等级"的能力评级。

🛡

与国家军标体系的关系

GJB5000A与GJB9001C（军工质量管理体系）的关系：①GJB9001C条款8.3明确要求"含嵌入式软件/武器系统软件的军品——软件开发过程应满足GJB5000A的要求"——也就是说GJB5000A是GJB9001C在软件维度上的"过程详细展开"——GJB9001C只提了"软件工程化"4个字——GJB5000A把"什么叫软件工程化"展开为22个过程域和数百个具体实践。②但两张证的审查逻辑不同——GJB9001C是体系认证（审核→发证→监督审核）——GJB5000A是能力评价（评价→给出等级→定期再评）——两者均有独立证书/评价结论——但适用场景不同。"

📜

GJB5000A三级的"行业分水岭"意义

软件供应商最常见的认证目标是三级（已定义级）——这是90%以上军品软件合同的准入门槛——也是区分"能写代码"和"有软件工程能力"的分水岭。一级≈没有过程——做什么全凭个人能力——没有任何军品软件顾客会接受一级供应商。二级（已管理级）≈项目管理基本受控——但工程过程仍停留在项目级——没有组织级标准过程——"好经验无法复制到下一个项目"。三级（已定义级）≈组织建立了标准软件过程——所有项目的过程都从标准过程剪裁而来——"组织能力的积累不依赖特定人员"——这才是军用软件顾客对供应商的最低期望水平。

🎯

谁必须做——"软件定义战争"时代的准入标配

进入军用软件供应商体系的企业——尤其是以下四类：①武器系统嵌入式软件（导弹飞行控制软件/雷达信号处理软件/火控解算软件——GJB5000A三级几乎是合同标配）②指挥信息系统软件（指挥自动化/态势显示/辅助决策——军用大数据量信息系统的软件复杂度和可靠性要求都远超普通商用软件）③仿真/训练系统软件（作战仿真/飞行模拟器/虚拟靶场——软件验证与确认(VV&A)是GJB5000A评价的核心检查项）④军用软件测评实验室（独立第三方软件测试——GJB5000A+军用软件测评实验室认可双重资质）。全国约1500+家企业已通过GJB5000A评价（其中约90%为三级）——大型军工集团总装厂的软件中心通常达到四级甚至五级。

5 LEVELS

GJB5000A 五级成熟度全景

从"个人英雄主义"到"组织自我进化"——五级之间不是"量的递增"而是"质的跃迁"

1
初始级过程混乱无序——项目成功全凭个别"英雄程序员"的个人能力——人走代码烂——无重复性可言
2
已管理级项目基本受控——有需求管理/项目策划/配置管理——但工程过程仍停留在项目级别
3
已定义级组织标准过程建立——所有项目从标准过程剪裁——过程资产可跨项目复用——军品软件合同的标配门槛
4
已定量管理级过程被量化——用统计方法控制关键子过程——"你的缺陷密度/进度偏差可以预测"——大型总装厂软件中心水平
5
优化级组织自我进化——量化反馈自动驱动过程改进——缺陷预防而非缺陷发现——全国能达五级的软件组织不足30家

GJB5000A的评价不要求"逐级爬"——你可以直接申请三级评价。但注意：GJB5000A三级要求满足二级+三级的全部18个过程域（二级7个+三级11个）——不能跳过二级的过程域只做三级——这是"累积式"的——不是"选了哪个级就只看哪个级"。绝大多数军品软件供应商直接定位于三级——因为二级在军品市场上几乎没有竞争力——"三级是军品软件的普通话——二级是方言——没人听得懂"。

22 PROCESS AREAS

GJB5000A 的22个过程域——从项目管理到组织创新

四大类别 × 五个等级 = 22个过程域——每个过程域包含若干"特定实践(SP)"和"通用实践(GP)"

等级2 · 已管理级 7个过程域 — "管住项目"

REQM · 需求管理

维护软件需求的双向追溯性——需求变更须受控——"需求→设计→代码→测试→需求"可追溯矩阵是评价必查项

PP · 项目策划

制定软件开发计划——规模/工作量/进度/风险的估算——"估算是计划的基础——不是拍脑袋"

PMC · 项目监控

跟踪项目进展——进度/工作量/缺陷/风险的实际vs计划偏差——"周报不是监控——周报里写了偏差但没人处理=不符合"

SAM · 供方协议管理

外包/分包软件开发的管理——"你的外包商的软件过程你也得管——不是签了合同就万事大吉"

MA · 测量与分析

定义度量指标并收集分析——代码规模/缺陷密度/进度偏差/工作量——"没有度量就没有管理——只有感觉"

PPQA · 过程与产品质量保证

独立于项目组检查过程是否被遵守、产品质量是否符合标准——"QA不是测试——QA看的是过程有没有被严格执行"

CM · 配置管理

版本控制/基线管理/变更控制——"你的代码库能不能追溯到每一次变更——谁/什么时间/改了什么/经谁批准——任何时点的代码必须可重现"

等级3 · 已定义级 11个过程域 — "组织能力可复用"

RD · 需求开发

从用户需求→软件需求→接口需求→功能/非功能需求——需求开发≠需求管理——RD是"把需求写对"——REQM是"需求变了能控住"

TS · 技术解决方案

设计方案选择/自行开发或购买决策/详细设计——"设计不止是画图——是从多个方案中评估选优的过程"

PI · 产品集成

组建集成/接口测试/集成环境——"软件不是写完就完了——集成策略/集成顺序/集成环境配置——全部受控"

Ver · 验证

同行评审/代码走查/单元测试——"验证问的是'我们正确地制造了产品吗'——验证=检查每一步是否正确——比测试早"

Val · 确认

需求确认/验收测试——"确认问的是'我们制造了正确的产品吗'——确认=最终产品满足用户需求——比验证晚但更关键"

OPF · 组织过程聚焦

建立组织标准软件过程(OSSP)——评估现有过程——识别改进机会——"OSSP是GJB5000A三级的灵魂——所有18个PA的评价员都会问——这个实践在OSSP中写在哪一节"

OPD · 组织过程定义

建立和维护组织过程资产库——含生命周期模型/过程剪裁指南/标准工作环境——"新项目启动第一件事不是写代码——而是从组织过程资产库剪裁项目过程"

OT · 组织培训

软件工程/项目管理/质量保证的培训体系——"组织培训≠入职培训——OT要求培训需求分析→培训策划→培训实施→效果评价——闭环"

IPM · 集成项目管理

从OSSP剪裁项目已定义过程(PDP)——协调相关方——建立项目工作环境——"IPM是三级和二级的最大区别——二级每个项目各管各的——三级所有项目从同一个OSSP长出来"

RSKM · 风险管理

风险识别→分析→缓解→跟踪——"二级只要求项目计划里写风险——三级要求有独立的风险管理过程——含风险参数/风险库/风险缓解计划——风险没有闭环=不符合"

DAR · 决策分析与决定

重要决策须用正式评估过程——多方案/多准则/权重评分——"选架构/选外购件/选算法——不是技术负责人在会上说选哪个就选哪个——要有记录在案的决策分析过程"——这是GJB5000A三级最具"军工特色"的PA

等级4-5 · 定量管理+优化级 4个过程域 — "数据驱动进化"

OPP · 组织过程性能

（四级）建立过程性能基线(PPM)——"你的缺陷密度基线是多少——你的生产率基线是多少——没有基线=无法判断'异常'"

QPM · 定量项目管理

（四级）用量化技术管理项目——"不是'这个月缺陷多了'——而是'缺陷密度超出3σ控制限——须启动原因分析'"

OID · 组织创新与部署

（五级）基于量化数据识别改进机会——试点→推广——"改进不是拍脑袋——是数据说哪里需要改进——改之前做试点——试点成功才推广"

CAR · 原因分析与决定

（五级）系统性地分析缺陷/问题的根因——不是"改了这一行代码"——而是"找到这个bug为什么在评审和测试中都没有被发现——改了过程比改了代码更重要"

GJB5000A三级 = 18个过程域（二级7个 + 三级11个）。每个过程域包含若干特定目标(SG)+特定实践(SP)和通用目标(GG)+通用实践(GP)——"特定实践"是本PA独特要求——"通用实践"是所有PA共通的（如"制定计划""提供资源""监控过程"）——通用实践是所有PA评价都要查的"底座项"。评价员会针对每个PA的所有实践逐条打分："充分实现(FI)/大部分实现(LI)/部分实现(PI)/未实现(NI)"——NI=直接不通过该PA——LI数量和分布决定总评等级。

GJB5000A vs GJB9001C vs CMMI

三张"军品软件"涉及的证——职能完全不同

GJB5000A管"软件过程能力"、GJB9001C管"军工质量体系"、CMMI管"国际通用软件能力"——三证可能全要

维度	GJB5000A	GJB9001C	CMMI-DEV
性质	能力评价（给等级1-5）	体系认证（通过/不通过）	能力评价（给等级1-5）
适用范围	仅软件——软件研制/测试/测评	所有军品——硬件+软件+服务	仅软件——国际通用
评价机构	装发部认可的军用软件评价机构（全国仅约10家）	装发部认可的认证机构（全国约20家）	SEI授权的主任评估师(Lead Appraiser)
核心方法	SCAMPI A级评价——文档审查+人员访谈+过程证据交叉验证	体系审核——抽样+现场+文件	SCAMPI评价——与GJB5000A方法同一体系
证书互认	军事采购专用——在国际/民用市场不具互认性	在民品市场可双标同审获得ISO 9001	国际通用——无GJB5000A的"军事属性"
常见等级	三级（已定义级）占90%	无等级概念——认证=通过	三级（已定义级）最普及
与另两个证关系	—	条款8.3要求含嵌入式软件的须参照GJB5000A	GJB5000A的"母本"——但GJB5000A增加了军工特殊要求
价格	三级：20-80万	8-30万	三级：约15-40万

"我们已经有CMMI三级证书了——还需要GJB5000A吗？"答案是：需要（如果你打算进入军品软件市场）。CMMI是国际通用证书——在政府采购/军品合同中不被认可——因为GJB5000A增加了军事软件专用要求（如软件开发中的保密接口/军事通信协议/武器安全完整性等级SIL等）。持有CMMI三级的企业在内容上距GJB5000A三级约有60-70%的重合度——但其余30-40%的"军事专属"内容（在GJB5000A中以专用实践的方式标注）须从头建立——不可直接复用CMMI证据。

WHO NEEDS IT

哪些企业在办GJB5000A

8个最高频的军用软件场景——从武器控制软件到测评实验室

🛰

武器系统嵌入式软件

导弹飞行控制/鱼雷制导/火炮火控——武器嵌入式软件——安全完整性等级SIL3/SIL4——强制三级以上

🛸

雷达/电子对抗软件

信号处理/目标识别/干扰策略——实时性要求极高——软件时序/中断响应须纳过程性能基线

📡

指挥信息系统(C4ISR)

态势综合/辅助决策/火力协同——大规模分布式软件——软件架构评估是GJB5000A评价的核心关注点

🚀

航空航天机载/星载软件

飞控/航电/星务管理——航天器软件不可维护——"一次性机会"——软件验证的充分性远超地面软件

📦

军用仿真与训练系统

作战仿真/飞行模拟/虚拟靶场——软件VV&A（校核验证与确认）是独立于开发的过程——须有独立的V&V团队

⚡

军用通信网络软件

数据链协议栈/军用网络管理——信息安全与通信保密——软件安全性分析须在需求阶段启动

🔧

军用软件测评实验室

独立第三方软件测试——GJB5000A+GJB2725A双重资质——测试过程的独立性/充分性是可评价的

🎓

军用软件保障/维护

现役武器系统软件升级维护——维护过程须纳入GJB5000A体系——"改1行代码和写1万行——变更控制流程完全相同"

REQUIREMENTS

申请GJB5000A评价的条件

与GJB9001C相近但有"软件专属"的额外条件——核心是"你有真实军品软件项目"

内资企业 + 法定代表人中国国籍

与GJB9001C一致——外资/外资控股企业不能申请GJB5000A——军事软件安全底线。且企业须持有有效的营业执照——经营范围须含软件相关业务。

具备至少1-2个真实的军品软件项目

GJB5000A评价以真实项目为评价对象——评价组会抽取1-3个代表性项目——深入审查软件需求文档/设计文档/代码/测试记录/配置管理库——不存在"虚拟项目"可蒙混过关——"写一个假项目的文档=评价组交叉比对发现无代码仓库/无真实测试数据=直接终止评价"。

软件过程体系运行至少12个月

比GJB9001C的6个月要求更长——因为软件过程须至少覆盖一个完整的项目生命周期（需求→设计→编码→测试→交付）——或至少两个在制项目全阶段覆盖——评价员要看到过程记录不是"突击补的"。

建立并实施组织标准软件过程(OSSP)

三级评价的绝对核心——组织须建立OSSP（不是项目级——是组织级标准过程）——含软件生命周期模型/过程剪裁指南/标准工作环境——且至少2个项目已从OSSP剪裁实施了项目已定义过程(PDP)——无OSSP=无法评价三级。

配备软件工程过程组(SEPG)

SEPG是GJB5000A体系建设和维护的核心团队——不是临时组建的——须长期存在——SEPG成员须具备软件工程+过程改进双重能力——"SEPG组长兼职写代码=资源配置不足=不符合OPF"。

配置管理+质量保证独立于项目组

CM（配置管理）和PPQA（质量保证）不能由项目经理兼任——须有独立的汇报线和预算——"写了CM计划但代码仓库没有分支策略/没有基线标签=不符合"——"QA检查单2年没有更新过=评价员直接判定PPQA过程域不通过"。

完成至少一次内部评价

须由经过培训的内部评价员(ATM)完成至少一次覆盖全部18个过程域的内部评价——内评发现的问题须有纠正措施——且纠正措施须有有效性验证——"内评走形式=评价组看了内评记录发现全部'通过'但实际项目质量数据很差=评价组不信任整个体系"。

关键岗位人员须通过GJB5000A培训

至少2-3名ATM（内部评价组成员）须经装发部认可的培训机构培训并取得证书——评价组长/SEPG负责人/ATM——这三个角色缺一不可——"无人经正规培训=评价组无法确认企业理解GJB5000A的真实水平——可能直接劝退"。

DOCUMENTS

GJB5000A三级评价核心材料清单

不是"材料清单审过去"——而是评价组在交叉比对中看"你的书面过程和你实际做的是否一致"

评价申请书（评价机构统一模板）

含企业基本信息、拟评价等级（二级/三级/四级/五级）、评价范围（组织单元/项目列表）

营业执照 + 法定代表人身份证明

确认内资身份——法定代表人中国国籍——经营范围含软件相关

组织标准软件过程(OSSP)文档集

GJB5000A三级核心。含：组织标准软件过程描述+软件生命周期模型说明+过程剪裁指南+标准工作环境定义+过程资产库结构

代表性项目的完整软件过程证据

GJB5000A独有。1-3个代表性项目的：需求规格说明(SRS)+需求追溯矩阵(RTM)+软件设计说明(SDD)+代码（版本库）+测试计划/测试用例/测试报告+配置管理记录+质量保证检查单——"从需求→设计→代码→测试→配置管理——全链条可追溯"

18个过程域的过程文件 + 证据

每个PA的过程描述+实施证据——如REQM的需求追溯矩阵/PP的项目估算记录/CM的配置管理计划+基线审计报告/MA的度量分析报告

内部评价(ATM Evaluation)报告

由内部ATM完成的完整内评报告——须覆盖全部18个PA——含发现/不符合项/纠正措施/有效性验证

组织培训记录 + 人员能力矩阵

含ATM证书/SEPG成员培训记录/软件工程师岗位能力评价——"不是凑人头——是每个角色的能力须有记录支撑"

组织过程资产库(PAL)内容清单

过程资产库中存储的标准模板/检查单/历史项目度量数据/经验教训——"PAL不能是'刚刚建的'——须有内容流通和使用的证据"

软件工程环境说明 + 工具链清单

需求管理工具/配置管理工具/测试管理工具/项目管理工具——"工具本身不会让过程改进——但工具的缺失会让所有PA的证据链断裂"

军品软件合同/任务书（至少1份）

证明企业实际从事军用软件研制——评价组须以真实合同为背景确认被评价项目的"军品属性"——无军品合同=无法开展评价

GJB5000A材料与GJB9001C材料最大的不同——"不是审查文件是否齐全——而是交叉比对文件之间是否逻辑一致"。GJB5000A评价的核心方法叫"三角验证(Triangulation)"——评价组同时看三种证据：①书面过程文件（你写了什么）②实施证据（你做了什么）③人员访谈（你怎么想的）。三者在逻辑上必须一致——"过程文件写了要做代码走查→代码仓库提交记录中找不到走查注释→开发人员在访谈中说'我们有时候做有时候不做'——三项交叉比对不一致=不符合——无论书面文件写得多完美"。这是GJB5000A评价与体系认证在方法论上的根本差异——"一致性"比"完整性"更重要。

PROCESS

GJB5000A三级评价完整流程

从体系建立到获评——比ISO认证更象"论文答辩"而非"考试"

差距分析+规划

对标GJB5000A三级18个PA——找出当前差距→制定改进计划
1-2个月

体系建立

建立OSSP+18个PA过程文件→工具链部署→ATM培训→试点项目
3-6个月

体系运行

至少2个项目从OSSP剪裁→积累≥12个月运行证据→内评
12+个月

正式评价

评价组文档审查→人员访谈→证据交叉比对→初步发现报告
5-10天（现场）

最终报告+等级发布

关闭不符合项→评价组出具最终评价报告→装发部备案→公布等级
1-3个月

GJB5000A评价的现场部分（5-10天）比任何ISO认证审核都长。评价组（通常4-7人——包含评价组长+ATM+领域专家）会做三件事：①文档审查——逐PA查阅过程文件和项目证据——每个PA通常耗时1-2小时——"发现不一致的记录=暂停该PA→扩大审查范围"②人员访谈——分别访谈项目经理/软件工程师/测试工程师/CM/QA/SEPG/高层管理者——"访谈不是一问一答——评价员会拿你5分钟前说的话和2小时前查的文档交叉比对——人在访谈中说我们每周做代码走查但代码仓库提交记录里找不到任何走查注释=矛盾项记录"③初步发现报告(PFR)——评价最后一天向被评组织报告——包括每个PA的通过/不通过情况和具体证据——"PFR不是最终结论——但通常最终结论不会与PFR有本质差异"。

COST & TIMELINE

评价周期与费用结构

GJB5000A三级是"最贵的软件资质之一"——但咨询价值远超认证价值

📅 时间线概览 12-24个月

差距分析+规划：1-2个月——对标22个PA逐条分析现况——确定改进重点和时间表
体系建立：3-6个月——建OSSP+18个PA过程文件+工具链+ATM培训+试点项目启动——这是咨询工作的核心交付
体系运行+积累证据：≥12个月——至少2个项目全生命周期运行——内评至少一次——"12个月是最低——大多数企业实际需要18-24个月"
正式评价（现场）：5-10天——4-7名评价员
最终报告+备案+等级发布：1-3个月——含不符合项整改和评价机构内部评审

💰 费用结构 20-80万

咨询费：15-40万元——GJB5000A咨询的核心是把22个PA"翻译"成组织自己的软件过程——建立OSSP→协助18个PA实施→指导ATM内评——这比ISO体系咨询复杂数倍——咨询师须兼具软件工程背景+GJB5000A评价经验
评价费：8-20万元——评价机构（装发部认可）按评价组人日收费——4-7人×5-10天+文档审查准备+报告编写
培训费：3-5万元——ATM培训+SEPG培训+试点项目培训——这是独立于咨询的服务
工具采购费：5-10万元——需求管理工具+配置管理工具+测试管理工具——基础版可用开源替代——但须满足军品安全要求
再评费：3年后再评≈初次评价费的60-80%

GJB5000A三级的"隐性成本"常常超过咨询费本身。最大的隐性成本是组织变革——从"英雄程序员单打独斗"到"每个人都在统一过程框架下工作"——项目中每人每周额外的过程记录和度量统计约增加10-20%的工时。第二隐性成本是工具链——如果企业之前靠Excel+SVN管理——引入商业工具(JIRA/DOORS/TestLink)的采购和迁移成本可能超过咨询费。第三隐性成本是时间——12-24个月内评价机构只看"从体系建立之后生成的证据"——体系建立之前的旧项目的文档不能作为证据——企业须选新项目或新阶段项目从头开始走全生命周期——这本身就影响项目排期。

TIPS

GJB5000A 评价的8条注意事项

软件过程评价的"暗礁"比体系认证更多——每一条都可能让你重做一年

⚠

评价机构必须是装发部认可的军用软件评价机构——全国仅约10家。不是任何一家能做CMMI的主任评估师都可以做GJB5000A——GJB5000A评价机构须经装发部审查并公布——全国仅约10家——选择时须核实机构是否在装发部网站公布的《军用软件评价机构名录》中——选错了=白做。

⚠

OSSP不是"写一本厚手册"而是"建立一个真正被使用的标准过程"——评价员关心的是"你用了吗"而不是"你写了吗"。很多组织把精力花在把OSSP写得很完美——但评价时发现项目中几乎找不到从OSSP"剪裁"的痕迹——项目的过程文件中没有引用OSSP的任何章节——"我们参考了OSSP但不是严格按照它做的"=口头承认不符合——"写你所做、做你所写"的三维一致性是GJB5000A评价的最高原则。

⚠

需求追溯矩阵(RTM)不能是后补的——RTM是GJB5000A评价中"最容易被查出来是形式文件"的证据。评价员会抽查3-5条需求——在RTM中→在设计中→在代码中→在测试用例中→在测试结果中——看"同一条需求在五个环节中的表达是否一致"——RTM中的需求编号与需求文档不一致/RTM中有需求标为"已测试"但测试用例中找不到/RTM中的追溯关系在设计文档中没有对应章节号——任意一项=REQM和Ver可能同时不通过——第三级评价中最普遍的致命伤。

⚠

"测量与分析(MA)"是三级的"沉默杀手"——数据太好看=数据不真实=视为不符合。评价员看的是"你收集的数据和你对这个数据的分析和改进"。如果看到的测量报告显示"缺陷密度始终稳定/进度偏差始终为0=一切完美"——这不是好——这是没有真实收数据或数据被人为筛选过——"真实数据一定有波动——没有波动的数据就是假数据"——这是评价组讨论PA通过与否时的默认共识。

⚠

"风险没有闭环"是RSKM不通过的最高频原因。RSKM要求风险识别→分析→缓解计划→跟踪→最终关闭——很多组织做到了前三步——但评价员问"这个风险最后怎么样了"——答不上来或只能说"没有发生"——"没有跟踪记录=RSKM不通过——风险被识别了但没被管理到最终关闭——说明风险管理是不完整的"。

⚠

评价等级有效期3年——但"以评促建"是GJB5000A的核心——不是评完就扔。3年后须重新评价——且自上一个等级通过后的3年内——企业须有持续运行和增量改进的证据——如果3年后重新评时——发现OSSP原封不动/度量数据与新项目无关/PAL中没有新的经验教训——评价组会认为"拿证后就把体系丢一边=名存实亡"。

⚠

"不适合公开的军事需求如何在RTM中体现"——这是军品软件独有的保密难题。军事需求（尤其是战术指标/算法参数）可能涉密——不能在公开文档中写明——解决方案：在RTM中标注"参见涉密需求文档<编号>"——评价组签保密承诺后查阅——组织的过程文件中须明确"涉密软件需求的处理流程"——包括如何纳入RTM、如何在不泄露涉密信息的前提下维持可追溯性。

⚠

"没有军品合同就不能评GJB5000A吗"——对中小企业这是一个现实的"鸡生蛋难题"。没有合同=找不到真实的军品项目作为评价对象——但很多合同要求在投标时就已有GJB5000A。破解策略：①寻找可接受"GJB5000A在评中"合同的军方/军工集团客户（需开具评价机构受理函）②以"内部研发具有军事应用前景的软件项目"作为评价对象（须获得评价机构认可）③先通过GJB9001C切入军品市场→在第一个合同执行过程中同时推进GJB5000A评价。"

FAQ

常见问题

8个最高频的咨询问题——从"三级难不难"到"GJB5000B什么时候来"

我们是10人小团队（编程能力强，但没有正规软件工程流程），能直接做三级吗？▼

理论上可以——但实操中10人以下团队做三级的"投入产出比"需要仔细评估。GJB5000A三级要求建立OSSP+18个PA过程——这些过程的建立和维护需要至少2-3名专职SEPG成员（含ATM）——对于10人团队来说——抽出20-30%的人员做过程工作——项目交付能力可能下降。但这不是"不能做"——小团队的优势是组织小、沟通成本低、过程灵活性高——如果团队领导有清晰的软件工程意识——"小团队的GJB5000A三级可以达到'麻雀虽小五脏俱全'的效果"——关键是在OSSP中定义与小团队规模适配的过程——而不是搬一个大企业的厚重过程。

已经通过CMMI三级了——还需要"从头来"GJB5000A吗？▼

60-70%的过程资产可以直接复用——但剩余30-40%的"军事专属"须新增。CMMI三级和GJB5000A三级在过程域结构上完全相同（22个PA对应关系是一一映射的）——你的OSSP、培训记录、度量数据、质量保证记录等大部分可以直接在GJB5000A评价中呈现。但GJB5000A在若干PA中增加了军事软件专用实践——如涉密需求的管理、军用通信协议接口的追溯、武器安全完整性等级的软件安全性分析——这些是CMMI不涉及的——须新增过程文件和实施证据。总体上——从CMMI三级到GJB5000A三级的增量工作约为40-50%——远少于从零开始建体系——且已有过程改进文化的团队在GJB5000A评价中通常表现更好。

GJB5000A和GJB9001C可以一起做吗？先后顺序有讲究吗？▼

可以并行——但建议"先GJB9001C→后GJB5000A"——因为GJB9001C是GJB5000A的"组织级底座"。GJB9001C建立了企业整体的质量管理框架——这个框架中的文件控制/内部审核/管理评审/纠正预防措施/CAPA等基础管理过程——在GJB5000A中是"默认已有"的——不需要在软件评价中重新建立。如果先做GJB9001C——企业在GJB5000A评价时——可以直接引用GJB9001C体系中的通用管理过程——将评价精力集中在22个软件工程专用的PA上——节省30%以上的工作量。但如果企业的主营业务就是软件——先做GJB5000A再做GJB9001C的逻辑也是通的——因为5000A建立的软件工程管理体系为9001C的8.3项提供了最扎实的证据。

GJB5000A评价中"不通过"了怎么办——有"补考"机制吗？▼

GJB5000A不象考试——没有"不及格就重考"的简单机制。如果评价发现某一个或几个PA被判定为不通过——评价组会在PFR（初步发现报告）中说明具体原因——企业须在限定时间内（通常1-3个月）完成整改——并向评价组提交整改证据——经评价组确认整改有效后——评价等级可以维持。但如果不通过的PA数量较多（如超过3-4个）或涉及核心PA（OPF/OPD/IPM）不通过——评价组可能判定"整体不满足三级要求"——这种情况下没有整改期——企业须重新启动整个评价流程——包括从头积累12个月运行证据——约等于重做一年后重新申请评价。

GJB5000B什么时候发布？现在做GJB5000A会不会马上过时？▼

GJB5000B已经在编制中——但过渡期至少有2-3年——现在做5000A完全不会白做。GJB5000B的"方向"已经比较明确：①从"22个过程域"转为类似于CMMI 2.0的"实践域(Practice Area)"结构——过程域数量可能减少到20个左右②强化安全性(Security)和安保(Safety)两个维度的软件要求——这是5000A相对薄弱的③增加敏捷/DevOps的兼容性——使标准能适应快速迭代的软件开发模式。但GJB5000B从发布到"合同强制要求5000B"——至少还有2-3年的过渡期——期间已持5000A证书的企业可以通过"升级评价"过渡到5000B——而不是从零重做——所以现在做GJB5000A三级——可以享受2-3年的证书有效期——届时"升B"的工作量远小于"从头做B"。

军用软件测评实验室需要GJB5000A吗？与GJB2725A是什么关系？▼

是的——军用软件测评实验室通常须同时满足GJB5000A和GJB2725A的要求。GJB2725A-2012《军用软件测评实验室测评过程和技术能力要求》——是军用软件测试实验室的专用标准——管的是"测试的技术能力"（如测试设计方法/测试环境/测试工具——类似于软件测试领域的ISO/IEC 17025）。GJB5000A管的是"测试的过程管理"——即Ver(验证)和Val(确认)两个PA的过程控制。两张证书的关系：GJB2725A≈测试技术能力合格（你能做测试），GJB5000A≈测试过程管理规范（你做得过程可控）。大型军品软件的第三方测评——合同中会同时要求两张证书——而不仅仅是其中之一。

GJB5000A三级和GJB9001C"软件工程化"要求到底是重合还是互补？▼

是"大框套小框"的关系——GJB9001C是框架、GJB5000A是具体展开。GJB9001C条款8.3（设计开发）中要求"含嵌入式软件的——软件开发过程应满足GJB5000A的要求"——这12个字在GJB9001C中是"A4纸的一行"——在GJB5000A中被展开为18个过程域、数百个实践、数千条证据。在GJB9001C审核中——审核员会问"你们的软件怎么管理的"——看了1-2个项目就结束。在GJB5000A评价中——评价组会把18个PA一个一个地审——每个PA投入1-2小时。所以——如果你只做GJB9001C——软件部分只要"过得去"——审核员通常不会深挖——但如果你同时有GJB5000A三级——GJB9001C的软件条款就自动"满分通过"了——这是两证并行的一个额外收益。

我们的军用软件是二次开发（基于外购基础平台定制），GJB5000A还适用吗？▼

适用——但评价范围须精确界定"哪些过程域在你组织的控制范围内"。如果是在外购平台基础上做定制开发——你的软件研制能力主要体现在需求开发(RD)、技术解决方案(TS)、产品集成(PI)、验证(Ver)、确认(Val)等与定制开发直接相关的过程域上——这些PA是你的重点。而供方协议管理(SAM)须覆盖外购平台的供应商管理——你须有证据表明——你对外购平台的功能/性能/接口/测试结果进行了验证——而不是"供应商说能实现我们就不管了"——"买了平台就靠供应商=SAM不符合"——因为GJB5000A要求对外包/外购的软件同样进行过程监督和产品质量审查——无论外包的技术复杂度多高。