嵌入式软件开发流程

嵌入式软件开发流程
一、嵌入式软件开发流程
1.1 嵌入式系统开发概述
由嵌入式系统本身的特性所影响，嵌入式系统开发与通用系统的开发有很大的区别。

嵌入式系统的开发主要分为系统总体开发、嵌入式硬件开发和嵌入式软件开发3大部分，其总体流程图如图1.1所示。

图1.1 嵌入式系统开发流程图
在系统总体开发中，由于嵌入式系统与硬件依赖非常紧密，往往某些需求只能通过特定的硬件才能实现，因此需要进行处理器选型，以更好地满足产品的需求。

另外，对于有些硬件和软件都可以实现的功能，就需要在成本和性能上做出抉择。

往往通过硬件实现会增加产品的成品，但能大大提高产品的性能和可靠性。

再次，开发环境的选择对于嵌入式系统的开发也有很大的影响。

这里的开发环境包括嵌入式操作系统的选择以及开发工具的选择等。

本书在4.1.5节对各种不同的嵌入式操作系统进行了比较，读者可以以此为依据进行相关的选择。

比如，对开发成本和进度限制较大的产品可以选择嵌入式Linux，对实时性要求非常高的产品可以选择Vxworks等。

由于本书主要讨论嵌入式软件的应用开发，因此对硬件开发不做详细讲解，而主要讨论嵌入式软件开发的流程。

1.2 嵌入式软件开发概述
嵌入式软件开发总体流程为图4.15中“软件设计实现”部分所示，它同通用计算机软件开发一样，分为需求分析、软件概要设计、软件详细设计、软件实现和软件测试。

其中嵌入式软件需求分析与硬件的需求分析合二为一，故没有分开画出。

由于在嵌入式软件开发的工具非常多，为了更好地帮助读者选择开发工具，下面首先对嵌入式软件开发过程中所使用的工具做一简单归纳。

嵌入式软件的开发工具根据不同的开发过程而划分，比如在需求分析阶段，可以选择IBM的Rational Rose等软件，而在程序开发阶段可以采用CodeWarrior（下面要介绍的ADS 的一个工具）等，在调试阶段所用的Multi-ICE等。

同时，不同的嵌入式操作系统往往会有配套的开发工具，比如Vxworks有集成开发环境Tornado，WindowsCE的集成开发环境WindowsCE Platform等。

此外，不同的处理器可能还有对应的开发工具，比如ARM的常用集成开发工具ADS、IAR和RealView等。

在这里，大多数软件都有比较高的使用费用，但也可以大大加快产品的开发进度，用户可以根据需求自行选择。

图4.16是嵌入式开发的不同阶段的常用软件。

图1.2 嵌入式开发不同阶段的常用软件
嵌入式系统的软件开发与通常软件开发的区别主要在于软件实现部分，其中又可以分为编译和调试两部分，下面分别对这两部分进行讲解。

1．交叉编译
嵌入式软件开发所采用的编译为交叉编译。

所谓交叉编译就是在一个平台上生成可以在另一个平台上执行的代码。

在第3章中已经提到，编译的最主要的工作就在将程序转化成运行该程序的CPU所能识别的机器代码，由于不同的体系结构有不同的指令系统。

因此，不同的CPU需要有相应的编译器，而交叉编译就如同翻译一样，把相同的程序代码翻译成不同CPU的对应可执行二进制文件。

要注意的是，编译器本身也是程序，也要在与之对应的某一个CPU平台上运行。

嵌入式系统交叉编译环境如图4.17所示。

图4.17 交叉编译环境
小知识与交叉编译相对应，平时常用的编译称为本地编译。

这里一般将进行交叉编译的主机称为宿主机，也就是普通的通用PC，而将程序实际的运行环境称为目标机，也就是嵌入式系统环境。

由于一般通用计算机拥有非常丰富的系统资源、使用方便的集成开发环境和调试工具等，而嵌入式系统的系统资源非常紧缺，无法在其上运行相关的编译工具，因此，嵌入式系统的开发需要借助宿主机（通用计算机）来编译出目标机的可执行代码。

由于编译的过程包括编译、链接等几个阶段，因此，嵌入式的交叉编译也包括交叉编译、交叉链接等过程，通常ARM的交叉编译器为arm-elf-gcc、arm-linux-gcc等，交叉链接器为arm-elf-ld、arm-linux-ld 等，交叉编译过程如图4.18所示。

图4.18 嵌入式交叉编译过程
2．交叉调试
嵌入式软件经过编译和链接后即进入调试阶段，调试是软件开发过程中必不可少的一个环节，嵌入式软件开发过程中的交叉调试与通用软件开发过程中的调试方式有很大的差别。

在常见软件开发中，调试器与被调试的程序往往运行在同一台计算机上，调试器是一个单独运行着的进程，它通过操作系统提供的调试接口来控制被调试的进程。

而在嵌入式软件开发中，调试时采用的是在宿主机和目标机之间进行的交叉调试，调试器仍然运行在宿主机的通用操作系统之上，但被调试的进程却是运行在基于特定硬件平台的嵌入式操作系统中，调试器和被调试进程通过串口或者网络进行通信，调试器可以控制、访问被调试进程，读取被调试进程的当前状态，并能够改变被调试进程的运行状态。

嵌入式系统的交叉调试有多种方法，主要可分为软件方式和硬件方式两种。

它们一般都具有如下一些典型特点。

•调试器和被调试进程运行在不同的机器上，调试器运行在PC机（宿主机），而被调试的进程则运行在各种专业调试板上（目标板）。

•调试器通过某种通信方式（串口、并口、网络、JTAG等）控制被调试进程。

•在目标机上一般会具备某种形式的调试代理，它负责与调试器共同配合完成对目标机上运行着的进程的调试。

这种调试代理可能是某些支持调试功能的硬件设备，也可能是某些专门的调试软件（如gdbserver）。

•目标机可能是某种形式的系统仿真器，通过在宿主机上运行目标机的仿真软件，整个调试过程可以在一台计算机上运行。

此时物理上虽然只有一台计算机，但逻辑上仍然存在着宿主机和目
标机的区别。

下面分别就软件调试桩方式和硬件片上调试两种方式进行详细介绍。

（1）软件方式。

软件调试主要是通过插入调试桩的方式来进行的。

调试桩方式进行调试是通过目标操作系统和调试器内分别加入某些功能模块，二者互通信息来进行调试。

该方式的典型调试器有gdb调试器。

gdb的交叉调试器分为GdbServer和GdbClient，其中的GdbServer就作为调试桩在安装在目标板上，GdbClient就是驻于本地的gdb调试器。

它们的调试原理图如图4.19所示。

图4.19 gdb远程调试原理图
gdb调试的工作流程。

•首先，建立调试器（本地gdb）与目标操作系统的通信连接，可通过串口、网卡、并口等多种方式。

•然后，在目标机上开启GdbServer进程，并监听对应端口。

•在宿主机上运行调试器gdb，这时，gdb就会自动寻找远端的通信进程，也就是GdbServer的所在进程。

•在宿主机上的gdb通过GdbServer请求对目标机上的程序发出控制命令。

这时，GdbServer将请求转化为程序的地址空间或目标平台的某些寄存器的访问，这对
于没有虚拟存储器的简单的嵌入式操作系统而言，是十分容易的。

•GdbServer把目标操作系统的所有异常处理转向通信模块，并告知宿主机上gdb当前有异常。

•宿主机上的gdb向用户显示被调试程序产生了哪一类异常。

这样就完成了调试的整个过程。

这个方案的实质是用软件接管目标机的全部异常处理及部分中断处理，并在其中插入调试端口通信模块，与主机的调试器进行交互。

但是它只能在目标机系统初始化完毕、调试通信端口初始化完成后才能起作用，因此，一般只能用于调试运行于目标操作系统之上的应用程序，而不宜用来调试目标操作系统的内核代码及启动代码。

而且，它必须改变目标操作系统，因此，也就多了一个不用于正式发布的调试版。

（2）硬件调试。

相对于软件调试而言，使用硬件调试器可以获得更强大的调试功能和更优秀的调试性能。

硬件调试器的基本原理是通过仿真硬件的执行过程，让开发者在调试时可以随时了解到
系统的当前执行情况。

目前嵌入式系统开发中最常用到的硬件调试器是ROMMonitor、ROMEmulator、In-CircuitEmulator和In-CircuitDebugger。

采用ROMMonitor方式进行交叉调试需要在宿主机上运行调试器，在宿主机上运行ROM 监视器（ROMMonitor）和被调试程序，宿主机通过调试器与目标机上的ROM监视器遵循远程调试协议建立通信连接。

ROM监视器可以是一段运行在目标机ROM上的可执行程序，也可以是一个专门的硬件调试设备，它负责监控目标机上被调试程序的运行情况，能够与宿主机端的调试器一同完成对应用程序的调试。

在使用这种调试方式时，被调试程序首先通过ROM监视器下载到目标机，然后在ROM 监视器的监控下完成调试。

优点：ROM监视器功能强大，能够完成设置断点、单步执行、查看寄存器、修改内存空间等各项调试功能。

确定：同软件调试一样，使用ROM监视器目标机和宿主机必须建立通信连接。

其原理图如图4.20所示。

图4.20 ROMMonitor调试方式
采用ROMEmulator方式进行交叉调试时需要使用ROM仿真器，并且它通常被插入到目标机上的ROM插槽中，专门用于仿真目标机上的ROM芯片。

在使用这种调试方式时，被调试程序首先下载到ROM仿真器中，因此等效于下载到目标机的ROM芯片上，然后在ROM仿真器中完成对目标程序的调试。

优点：避免了每次修改程序后都必须重新烧写到目标机的ROM中。

缺点：ROM仿真器本身比较昂贵，功能相对来讲又比较单一，只适应于某些特定场合。

其原理如图4.21所示。

图4.21 ROMEmulator调试方式
采用In-CircuitEmulator（ICE）方式进行交叉调试时需要使用在线仿真器，它是目前最为有效的嵌入式系统的调试手段。

它是仿照目标机上的CPU而专门设计的硬件，可以完全仿真处理器芯片的行为。

仿真器与目标板可以通过仿真头连接，与宿主机可以通过串口、并口、网线或USB口等连接方式。

由于仿真器自成体系，所以调试时既可以连接目标板，也可以不连接目标板。

在线仿真器提供了非常丰富的调试功能。

在使用在线仿真器进行调试的过程中，可以按
顺序单步执行，也可以倒退执行，还可以实时查看所有需要的数据，从而给调试过程带来了很多的便利。

嵌入式系统应用的一个显著特点是与现实世界中的硬件直接相关，并存在各种异变和事先未知的变化，从而给微处理器的指令执行带来各种不确定因素，这种不确定性在目前情况下只有通过在线仿真器才有可能发现。

优点：功能强大，软硬件都可做到完全实时在线调试。

缺点：价格昂贵。

其原理如图4.22所示。

图4.22 ICE调试方式
采用In-CircuitDebugger（ICD）方式进行交叉调试时需要使用在线调试器。

由于ICE
的价格非常昂贵，并且每种CPU都需要一种与之对应的ICE，使得开发成本非常高。

一个比较好的解决办法是让CPU直接在其内部实现调试功能，并通过在开发板上引出的调试端口发送调试命令和接收调试信息，完成调试过程。

如使用非常广泛的ARM处理器的JTAG 端口技术就是由此而诞生的。

JTAG是1985年指定的检测PCB和IC芯片的一个标准。

1990年被修改成为IEEE的一个标准，即IEEE1149.1。

JTAG标准所采用的主要技术为边界扫描技术，它的基本思想就是在靠近芯片的输入输出管脚上增加一个移位寄存器单元。

因为这些移位寄存器单元都分布在芯片的边界上（周围），所以被称为边界扫描寄存器（Boundary-Scan Register Cell）。

当芯片处于调试状态时候，这些边界扫描寄存器可以将芯片和外围的输入输出隔离开来。

通过这些边界扫描寄存器单元，可以实现对芯片输入输出信号的观察和控制。

对于芯片的输入管脚，可通过与之相连的边界扫描寄存器单元把信号（数据）加载到该管脚中去；对于芯片的输出管脚，可以通过与之相连的边界扫描寄存器单元“捕获”（CAPTURE）该管脚的输出信号。

这样，边界扫描寄存器提供了一个便捷的方式用于观测和控制所需要调试的芯片。

现在较为高档的微处理器都带有JTAG接口，包括ARM7、ARM9、StrongARM、DSP等，通过JTAG接口可以方便地对目标系统进行测试，同时，还可以实现Flash编程，这是非常受欢迎的。

优点：连接简单，成本低。

缺点：特性受制于芯片厂商。

其原理如图4.23所示。

图4.23 JTAG调试方式
软件开发规范
Software Development Specification
Version: V1.0
Date: 2010-06-22
Prepared by
Document Revision History文档修订记录
1Introduction 简介
一个成熟稳定的组织或者团队，能够减少风险，经常地成功地达成目标。

成功的含义是：按时、预算内【即符合成本要求】、符合质量要求。

换言之，成熟稳定的团队，能够避免以下问题：
➢组织方面出现问题
➢对需求缺乏管理
➢缺乏计划和控制
➢估算错误
同时，还要在以下几个方面做得比较出色：
➢人员调度与工作安排
➢工作量估计
➢预算管理
➢责权分配与平衡
➢执行与监控
➢沟通
本文档是软件开发规范，力求使团队打下一个良好的基础，以便逐步成长为成熟稳定的团队。

团队需要一个逐步标准、规范的开发过程，在这个过程中，团队得到锻炼，成员能力得到提高，风险得到控制。

主要内容是：
➢定义软件开发的流程；
➢定义软件开发的文档格式；
➢定义涉及的角色；
➢定义涉及的信息；
➢描述开发流程；
1.1Purpose 目标
本文档的目标是：
➢统一软件开发团队的流程、文档；
➢促进团队成员的沟通，减少误解；
➢促使程序员书写易维护的代码；
➢提高代码编写效率；
➢使每个成员成为一个高效的程序员；
1.2Scope 范围
本文档，包含：
➢项目管理的流程；
⏹项目策划
⏹项目追踪
⏹配置管理
⏹质量保证
⏹同行评审
➢涉及文档；
⏹项目计划mpp
⏹需求规格说明书SRS
⏹Delphi估算
⏹项目状态报告
⏹配置库样式
⏹CheckList
⏹评审表
⏹变更申请表
➢开发工具的规范；
⏹数据库设计工具
⏹功能设计工具
⏹IDE
⏹配置工具
1.3Definitions, Acronyms, and Abbreviations. 术语，缩略词
➢SPP 项目策划Software Project Planning
➢SPTO 项目追踪Software Project Tracking & Oversight
➢SCM 配置管理Software Configuration Management
➢SQA 质量保证Software Quality Assurance
➢PR 同行评审Peer Review
➢BaseLine 基线
➢SCCB 软件配置控制委员会Software Configuration Control Board ➢CR 变更请求Change Request
➢SDLC 软件开发生命周期Software Development Life Cycle
➢RUP 统一开发过程Rational Unified Process
➢XP 极限【敏捷方法】eXtreme Programming
➢TDD 测试驱动Test Driven Development
1.4References 引用
《CMM2》
《CMM3》
1.5Overview 文档组织
本文档主要分为四大部分：
➢概述；
描述了团队组织开发过程的高层视图；
➢TSP和PSP；
按照团队和个人描述流程规范；
➢工具规范；
描述了开发工具的详细规范；
➢文档；
涉及的文档格式；
2The Overall Description 概述
本部分是开发团队开发过程的高层描述。

它描述了开发过程规范的背景，用来和所有涉及各方就基本过程达成共识。

2.1Software Development Organizing 开发团队组织结构
表示公司的行政部门表示公
说明：
司的逻辑部门
实线表示参加产品实现的组织和人员（不表示所属关系）
虚线表示工作的汇报关系，如SQAE向SQA经理汇报。

2.2 Project Base Process 项目基本流程
基本流程说明：
➢ 项目启动： 本阶段主要是进行可行性分析，定义项目，识别需求；
➢ 制定计划： 本阶段主要是计划策划，估算工作量，制定具体的可执行的计划； ➢ 计划实施： 本阶段主要是实施计划，完成计划中的各项任务，报告计划状态； ➢ 项目终止： 计划执行完毕，总结项目；
2.3 CMM Base Process CMM 基本过程
基本过程说明：
➢ SCM ： 软件配置管理，所有活动的基础，一切制品必须放入配置库；
➢ SPP ： 软件项目策划，估算工作量，制定详细计划【项目的制定计划阶段】；
投入力量
项目定义 制定计划 计划实施 时间
➢SPTO：项目追踪，报告项目状态，评估并更新计划【项目的计划实施阶段】；➢PR：同行评审，进入基线的前提条件，降低风险，提高质量的有效手段；➢SQA：质量保证，预防风险的有效手段；
2.3.1SCM软件配置管理
配置管理主要解决：
➢版本
➢变更
2.3.2SPP 计划策划计划策划的核心是工作量估算
2.3.3SPTO项目追踪
2.3.4PR同行评审
2.3.5SQA质量保证
2.4 SDLC 生命周期选择
当前比较成熟稳定的SDLC 是：
➢WaterFall
➢RUP
➢XP
其中：RUP和XP是迭代式开发过程，风险是可控的。

➢RUP的优点是过程清晰、文档齐全，但是过于庞杂，比较适合大规模的团队；
➢XP的优点是过程简洁、推崇简单，但是不注重文档，难于交接，适合小规模团队。

对于中等规模的团队来说，应该基于RUP和XP，进行裁剪，找到适合的SDLC：
➢SDLC的核心是：迭代式和TDD
➢从全局看：
⏹Use-Case Driven用例驱动
⏹基于Architecture
⏹迭代和递增的
➢从微观看：
⏹TDD测试驱动
⏹ReFactor重构
⏹Pair结对编程
2.5Development Process 开发过程
2.5.1Development Phase 开发阶段
➢需求分析阶段
⏹需求收集
⏹需求总结
➢总体设计阶段
⏹总体架构
⏹部署模型
➢概要设计阶段
⏹模块划分
⏹数据库设计
➢详细设计阶段
⏹具体实现
➢编码阶段
⏹测试用例
⏹Coding
⏹单元测试
➢测试阶段
⏹测试用例
⏹测试
⏹修正
➢发布阶段
⏹安装测试
⏹安装系统
⏹维护
2.5.2Phase Product 阶段制品
➢需求阶段
⏹SRS：需求规格说明书
➢总体设计阶段
⏹总体设计说明书
➢概要设计阶段
⏹HLD：概要设计说明书
⏹DB：数据库设计
⏹DFD：数据流图
⏹UI：用户界面
➢详细设计阶段
⏹DD：详细设计说明书
➢编码阶段
⏹Test Case：测试用例
⏹Coding：源代码
⏹UT Test Result：单元测试报告➢测试阶段
⏹Test Task：测试任务书
⏹Test Case：测试用例
⏹Test Result：测试报告
⏹Test Approvals：测试总结
➢发布阶段
⏹发布申请书
➢
Role Duty 角色职责
2.6Constraints 限制
3Specific Requirements 详细描述本部分按照角色划分详细描述开发过程。

3.1Precondition 前提
3.1.1SCM配置库
➢目录结构
⏹开发库：开发工作区文档和代码
◆项目文档
●项目启动
●项目策划
●项目计划
●项目报告
◆开发文档
●需求
●设计
●测试
◆代码
●代码目录
◆参考资料
●客户资料等等
⏹基线库：评审通过后的文档
◆《文档同开发库》
⏹测试库：测试代码和测试发布包
◆文档
●计划
●用例
●测试报告
◆代码
●版本1
●版本2
◆参考资料
⏹产品库：测试通过后的文档和代码
◆项目交付制品
●项目总结
●验收报告
●。

◆项目产品
●版本1
●版本2
➢权限
⏹测试库：
◆测试人员可以读写
◆其它人员只能读，不能增加、修改和删除
◆
⏹基线库：只能增加，不能删除和修改
⏹产品库：只能增加，不能删除和修改
⏹开发库：
3.1.2Test Environment 测试环境
➢测试需要一个独立的环境
⏹DB独立
⏹FTP等资源独立
⏹Pass9等外部系统独立
➢最好是一个单独的局域网环境，完全和开发分开
⏹开发是172.18.0.0环境
⏹测试是192.168.0.0环境
➢每次测试，应当是一个完整的测试过程
⏹安装系统
◆DB
◆Web
◆AppServer
◆Client
◆其它
⏹配置系统
◆DB配置
◆AppServer配置
⏹系统初始化
◆清除所有历史数据
◆执行初始化脚本，插入初始数据
⏹测试系统
3.2Development Control Process 开发控制流程
3.2.1项目启动和策划阶段
本阶段的关键是定义项目、估算工作量和制定详细计划。

一个软件项目的正式启动从《软件项目任务书》的下达开始。

任务书中写明项目的基本信息及相关责任人和详细分工，规定项目必须提交的产品清单。

任务书由研发经理或者项目负责人起草，研发经理批准后下达给相关负责人。

项目任务书必须为打印纸质文档，由相关人员签字确认后，入配置管理库归档。

软件项目任务书主要作用是明确项目人员职责以及各组之间的协调确认。

估算工作量，从确认需求后开始。

由项目经理指定评估人员，先按照头脑风暴法估计各个子系统或者模块的难易程度，然后按照Delphi法估算各个部分的工作量。

项目经理和PMO成员，根据估算的工作量，制定项目计划。

SQA和SCM分别制定各自的计划。

SCM需要确定资源库的目录结构和权限结构。

项目经理召集PMO、SQA、SCM评审及审核项目计划、SQA计划、SQA审核计划、SCM 计划和测试计划。

对于发布后的一般性程序修改，不需要下达软件项目任务书。

对于关系重大，需要各组人员协调工作的重大修改，项目负责人可以以任务书的形式明确职责、协调关系。

测试负责人评估测试资源【人员及机器】，并决定测试人员是否介入项目的需求分析和设计阶段。

3.2.2需求分析、设计、编码阶段
本阶段的关键是评审和修订控制，关键评审需要需求、设计、编码、测试、项目管理、用户等的参与。

需求阶段，需求分析人员收集需求，根据SRS模版，作出需求规格说明书。

设计阶段，设计人员根据总体设计、概要设计、数据库设计和详细设计，作出设计文档。

编码阶段，编码人员根据详细设计，设计单元测试用例，编写代码，进行单元测试。

关键评审：SRS评审，设计评审，代码走查
3.2.3提交测试阶段
项目启动后，项目经理填写测试任务通知单，将测试任务下达给测试组。

概要设计评审完成后，由各子系统或者模块的负责人测算完成时间，在确定完成时间后（正式开始编码前）将测试任务通知单提交给项目测试负责人，项目测试负责人审核通过在通知单上签字后返回给子项目负责人。

开发及单元测试完成后，由开发人员将测试内容提交配置管理员入测试库后，将测试任务通知单提交给发布人员申请测试发布。

发布人员将测试库中本次测试的内容发布
到测试机后，在测试任务通知单上签字后，提交给测试人员开始测试。

测试完成后，测试人员在任务单上填写测试意见后，交测试负责人确认后，返还给开发人员。

如测试没有通过，开发人员修改测试内容，进入下一个测试流程。

如通过测试，开发人员将测试任务通知单提交给项目负责人，由项目负责人、SCCB签字确认后，提交配置管理员将测试内容入基线库。

过程关键：发布实施人员确保发布到测试机上的源程序在配置管理库中得到了有效的标识。

3.2.4生产发布、终测
程序通过测试入库以后，根据需要，由项目的负责人负责填写发布申请单。

发布申请单由项目测试负责人、配置管理员、SCCB、客户代表、研发经理签字确认后，由项目负责人提交给实施发布人员。

发布人员拿到签完字的发布申请后，才能从基线库中提取程序向生产机上发布。

如以上发布确认人员没有全部签字同意发布，必须由项目经理签字同意后发布。

程序发布到生产机上以后，进入终测【UAT】流程。

测试人员和用户代表要对生产机上的程序进行最后测试，确保生产机上的系统符合需求。

项目负责人负责同用户协调，项目负责人、测试人员和用户共同编写测试用例。

项目负责人将《终测意见书》提交三方签字，根据签字意见决定修订系统或者提交正式发布。

终测出现的问题修改按照基线变更流程进行。

实施人员只有拿到有三方签字的《终测意见书》后才能将系统正式公开发布。

系统正式发布三天之后一周之内，由实施人员负责到用户处取得有用户主要负责人签字的《系统运行报告》，项目负责人负责监督执行。

根据《系统运行报告》做相应的处理。

过程关键：发布到生产机上的程序都在基线库中得到了有效的标识。

3.2.5发布后问题反馈修改过程
系统发布之后，用户反馈的意见要形成问题清单或者变更申请单，记录需要修改的地方，提交给项目负责人。

项目负责人负责判断改动是否会影响需求或者设计，负责将任务分配给相关人员进行修改。

修改完成后，提交测试直至发布。

这个阶段的最重要的是保证所做的修改（文档、代码）都在配置管理库的基线库中得到体现。

即基线库中的文档和代码要进行同步更新，关键是发布人员严格根据发布申请单进行控制，并确保发布的代码都是从基线库中取出的。

没有经过流程直接要求发布的，发布人员必须予以拒绝。