嵌入式软件开发流程

嵌入式软件开发流程一、嵌入式软件开发流程1.1

嵌入式系统开发概述

由嵌入式系统本身的特性所影响，嵌入式系统开发与通用系统的开发有很大的区别。嵌入式系统的开发主要分为系统总体开发、嵌入式硬件开发和嵌入式软件开发3大局部，其总体流程图如图1.1所示。

图1.1

嵌入式系统开发流程图

在系统总体开发中，由于嵌入式系统与硬件依赖非常紧密，往往某些需求只能通过特定的硬件才能实现，因此需要进行处理器选型，以更好地满足产品的需求。另外，对于有些硬件和软件都可以实现的功能，就需要在本钱和性能上做出抉择。往往通过硬件实现会增加产品的成品，但能大大提高产品的性能和可靠性。

再次，开发环境的选择对于嵌入式系统的开发也有很大的影响。这里的开发环境包括嵌入式操作系统的选择以及开发工具的选择等。本书在节对各种不同的嵌入式操作系统进行了比拟，读者可以以此为依据进行相关的选择。比方，对开发本钱和进度限制较大的产品可以选择嵌入式Linux，对实时性要求非常高的产品可以选择Vxworks等。

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

1.2

嵌入式软件开发概述

嵌入式软件开发总体流程为图4.15中“软件设计实现〞局部所示，它同通用计算机软件开发一样，分为需求分析、软件概要设计、软件详细设计、软件实现和软件测试。其中嵌入式软件需求分析与硬件的需求分析合二为一，故没有分开画出。

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

嵌入式软件的开发工具根据不同的开发过程而划分，比方在需求分析阶段，可以选择IBM的RationalRose等软件，而在程序开发阶段可以采用CodeWarrior〔下面要介绍的ADS的一个工具〕等，在调试阶段所用的Multi-ICE等。同时，不同的嵌入式操作系统往往会有配套的开发工具，比方Vxworks有集成开发环境Tornado，WindowsCE的集成开发环境WindowsCEPlatform等。此外，不同的处理器可能还有对应的开发工具，比方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-ScanRegisterCell〕。

当芯片处于调试状态时候，这些边界扫描存放器可以将芯片和外围的输入输出隔离开来。通过这些边界扫描存放器单元，可以实现对芯片输入输出信号的观察和控制。对于芯片的输入管脚，可通过与之相连的边界扫描存放器单元把信号〔数据〕加载到该管脚中去；对于芯片的输出管脚，可以通过与之相连的边界扫描存放器单元“捕获〞〔CAPTURE〕该管脚的输出信号。这样，边界扫描存放器提供了一个便捷的方式用于观测和控制所需要调试的芯片。

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

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

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

其原理如图4.23所示。图4.23

JTAG调试方式开发流程框图：阶段流程图文档工程立项阶段任命工程经理成立工程团队小组工程建议书可行性分析市场信息反应任命工程经理成立工程团队小组工程建议书可行性分析市场信息反应签发工程任务书签发工程任务书可行性分析报告工程任务书工程总体规划产品定义系统分析各部需求分析需求分析评审产品定义系统分析各部需求分析需求分析评审确定里程碑编制质量控制方案编制工程方案书风险控制方案确定里程碑编制质量控制方案编制工程方案书风险控制方案需求分析报告需求分析评审报告产品定义产品技术标准工程开发方案风险控制方案质量控制方案系统分析文档设计阶段系统分析评审硬件设计流程软件设计流程结构设计及制作流程图软件V1.0PCBV1.0T1工艺设计流程工艺说明T1系统分析评审硬件设计流程软件设计流程结构设计及制作流程图软件V1.0PCBV1.0T1工艺设计流程工艺说明T1评审，过程文件归档评审，过程文件归档产品技术总体设计方案〔包括工艺〕系统分析评审报告软件设计过程文档硬件设计过程文档结构设计过程文档工艺设计过程文档软件V1.0PCBV1.0T1设计文档工艺说明分单元测试报告设计验证阶段T1整机测试及评估软硬件及工艺调整版本升级FTA准备修模例试报告及分析装机报告少量装机装机准备整机测试及评估软硬件及工艺调整版本升级FTA准备修模例试报告及分析装机报告少量装机装机准备装机报告例试分析报告整机测试评估报告软件FTA版本硬件FTA版本T2FTA修模软硬件及工艺调整版本升级CTA材料下单例试、整机测试及评估试产准备小批量试产FTA修模软硬件及工艺调整版本升级CTA材料下单例试、整机测试及评估试产准备小批量试产FTAT2设计文档试产报告例试分析报告整机测试评估报告软件CTA版本硬件CTA版本T3CTA软硬件结构及工艺调整版本升级量产版本确定例试、整机测试评估试产准备CTA准备第二次试产CTA软硬件结构及工艺调整版本升级量产版本确定例试、整机测试评估试产准备CTA准备第二次试产CTAT3设计文档试产报告例试分析报告整机测试评估报告量产准备阶段生产工艺准备全套文件归档手工下单封样生产工艺准备全套文件归档手工下单封样全套DVT报告工艺文件量产转移量产转移量产转移附录：1、结构设计及制作流程图2、软件设计流程图3、硬件设计流程图附录1.结构设计及制作流程图：阶段流程图表单3D模型修改结构3D模型修改制定结构设计进度方案表可行制定结构设计进度方案表评估3D3D模型可行性评估3D模型评估报告结构设计进度表详细结构设计结构详细结构设计详细设计结构设计进展汇报结构设计进展汇报结构设计修改结构设计内部评审结构设计修改结构设计内部评审结构设计进度表结构设计验证评审相关资料准备相关资料准备结构设计外部评审模具制作检讨workingsample验证制作workingsample结构设计外部评审模具制作检讨workingsample验证制作workingsample签订商务合同开模结构设计修改签订商务合同开模结构设计修改结构设计内部评审记录workingsample配色表workingsample验收报告结构BOM结构设计外部评审记录模具制作检讨记录表模具制作申请表模具备品清单模具制作考前须知表工装夹具制作清单物料进度按排需求表配色方案表模具制作进度表参考文件：《工业设计流程》，《ID设计流程》附录2.软件设计流程图：阶段流程图表单软件需求分析软件开发方案和配置管理方案进度方案表软件需求分析〔包括技术风险评估〕软件开发方案和配置管理方案进度方案表软件需求分析〔包括技术风险评估〕软件测试方案软件测试方案软件需求规格书软件开发方案软件开发风险控制方案软件测试方案软件详细设计详细软件设计内部设计评审详细软件设计内部设计评审软件详细设计说明书软件接口设计说明书软件设计内部评审记录软件实现测试编码调试编写测试用例单元测试软件集成/调试编码调试编写测试用例单元测试软件集成/调试评审后发布并归档软件修订软件系统测试发布系统测试版本评审后发布并归档软件修订软件系统测试发布系统测试版本单元源代码单元调试报告单元测试用例单元测试分析报告集成后的软件及源代码软件集成调试报告软件操作手册系统测试软件系统测试用软件文档软件系统测试分析报告发布版本参考文件：附录3.硬件设计流程图：阶段流程图表单硬件需求评估硬件开发方案和配置管理方案进度方案表硬件需求分析〔包括技术风险评估〕硬件开发方案和配置管理方案进度方案表硬件需求分析〔包括技术风险评估〕硬件测试方案硬件测试方案硬件需求分析报告硬件开发方案硬件测试方案硬件详细设计详细硬件设计详细硬件设计LCD认证流程关键器件采购PCB毛坯图设计内部设计评审LCD认证流程关键器件采购PCB毛坯图设计内部设计评审硬件详细设计说明书硬件电路原理图硬件BOM硬件设计内部评审记录硬件实现测试软件投板前审查PCB布板流程软件投板前审查PCB布板流程打样、试产硬件调试 打样、试产硬件调试硬件内部评审PCB贴片硬件内部评审PCB贴片整机测试评审后发布并归档硬件修改整机测试评审后发布并归档硬件修改PCB数据器件规格书硬件子系统软件装配图硬件单元测试分析报告电装总结报告硬件系统测试版本硬件系统测试分析报告硬件评审验证报告发布版本参考文件：PCB布板流程图LCD认证流程图PCB布板流程图：阶段硬件结构其他各部表单布板需求设计硬件电路原理图硬件电路原理图PCB布板设计PCB布板设计结构尺寸要求结构尺寸要求工程需求工程需求/产品定义PCB确认投板前审查PCBGERBER投板前审查PCBGERBERPCB投板PCBPCB投板参考文件：LCD认证流程图：阶段硬件结构其他各部表单样品提供样品需求SPECLCD供给商数据收集和选择供给商提供样品样品需求SPECLCD供给商数据收集和选择供给商提供样品尺寸尺寸各部确认各部确认？供给商供样与供给商沟通SPEC各部提出修改要求电性能SPEC各部确认？供给商供样与供给商沟通SPEC各部提出修改要求电性能SPEC尺寸确认尺寸确认软件确认软件确认装机是否通过？是否通过？否是封样装机验证封样装机验证参考文件：软件开发标准SoftwareDevelopmentSpecificationVersion:V1.0Date:20PreparedbyDocumentRevisionHistory文档修订记录VERSION版本DATE日期DESCRIPTION内容说明INDIVIDUAL修订人1.020初稿Introduction简介一个成熟稳定的组织或者团队，能够减少风险，经常地成功地达成目标。成功的含义是：按时、预算内【即符合本钱要求】、符合质量要求。换言之，成熟稳定的团队，能够防止以下问题：组织方面出现问题对需求缺乏管理缺乏方案和控制估算错误同时，还要在以下几个方面做得比拟出色：人员调度与工作安排工作量估计预算管理责权分配与平衡执行与监控沟通本文档是软件开发标准，力求使团队打下一个良好的根底，以便逐步成长为成熟稳定的团队。团队需要一个逐步标准、标准的开发过程，在这个过程中，团队得到锻炼，成员能力得到提高，风险得到控制。主要内容是：定义软件开发的流程；定义软件开发的文档格式；定义涉及的角色；定义涉及的信息；描述开发流程；Purpose目标本文档的目标是：统一软件开发团队的流程、文档；促进团队成员的沟通，减少误解；促使程序员书写易维护的代码；提高代码编写效率；使每个成员成为一个高效的程序员；Scope范围本文档，包含：工程管理的流程；工程筹划工程追踪配置管理质量保证同行评审涉及文档；工程方案mpp需求规格说明书SRSDelphi估算工程状态报告配置库样式CheckList评审表变更申请表开发工具的标准；数据库设计工具功能设计工具IDE配置工具Definitions,Acronyms,andAbbreviations.术语，缩略词SPP 工程筹划SoftwareProjectPlanningSPTO 工程追踪SoftwareProjectTracking&OversightSCM 配置管理SoftwareConfigurationManagementSQA 质量保证SoftwareQualityAssurancePR 同行评审PeerReviewBaseLine 基线SCCB 软件配置控制委员会SoftwareConfigurationControlBoardCR 变更请求ChangeRequestSDLC 软件开发生命周期SoftwareDevelopmentLifeCycleRUP 统一开发过程RationalUnifiedProcessXP 极限【敏捷方法】eXtremeProgrammingTDD 测试驱动TestDrivenDevelopmentReferences引用《CMM2》《CMM3》Overview文档组织本文档主要分为四大局部：概述；描述了团队组织开发过程的高层视图；TSP和PSP；按照团队和个人描述流程标准；工具标准；描述了开发工具的详细标准；文档；涉及的文档格式；TheOverallDescription概述本局部是开发团队开发过程的高层描述。它描述了开发过程标准的背景，用来和所有涉及各方就根本过程达成共识。SoftwareDevelopmentOrganizing开发团队组织结构说明：表示公司的行政部门表示公司的逻辑部门实线表示参加产品实现的组织和人员〔不表示所属关系〕虚线表示工作的汇报关系，如SQAE向SQA经理汇报。ProjectBaseProcess工程根本流程识别需求识别需求提出解决方案执行工程结束工程投入力量可行性分析报告需求建议书合同工程目标工程定义制定方案方案实施工程终止时间根本流程说明：工程启动：本阶段主要是进行可行性分析，定义工程，识别需求；制定方案：本阶段主要是方案筹划，估算工作量，制定具体的可执行的方案；方案实施：本阶段主要是实施方案，完成方案中的各项任务，报告方案状态；工程终止：方案执行完毕，总结工程；CMMBaseProcessCMM根本过程SCMSCMSQAWorkAreaBaseLineSPPSPTOPRChange&PR根本过程说明：SCM：软件配置管理，所有活动的根底，一切制品必须放入配置库；SPP：软件工程筹划，估算工作量，制定详细方案【工程的制定方案阶段】；SPTO：工程追踪，报告工程状态，评估并更新方案【工程的方案实施阶段】；PR：同行评审，进入基线的前提条件，降低风险，提高质量的有效手段；SQA：质量保证，预防风险的有效手段；SCM软件配置管理配置管理主要解决：版本变更确定配置项和基线确定配置项和基线确定记录和报告配置项状态策略定义配置项定义访问权限访问权限确定配置管理工具确定SCCB成员确定配置库及其目录结构工程启动确定配置管理人员Vss、SVN或VSTS一般由：工程经理、技术经理、客户经理、质量保证人员、配置管理等工程的核心成员人员组成。在配置项〔基线〕生成和基线变更时配置库结构权限表基线表确定基线变更过程定义备份与病毒策略定义备份与病毒策略按方案执行配置管理活动SCM方案制定和评审记录和报告基线的状态在配置项〔基线〕生成和基线变更时至少在工程的每个里程碑结束时进行备份1建立配置库2对工程组指导和培训3对配置项的日常管理4参加评审会议5定期备份和病毒防护6实施发布7进行归档8配置管理方案的维护配置管理情况总结方案完成总结配置项是否完整、基线的变化情况统计、审核发现问题情况统计、改良建议等，记入工程总结报告定义测试和发布归档方式SCM方案配置审核状态报告审核报告SPP方案筹划方案筹划的核心是工作量估算从历史库中识别可用的信息从历史库中识别可用的信息工程启动从公司的数据中识别工程相似的信息，如工程的总结报告和其它的数据或文挡工程需求、合同以及《软件工程任务书》等相关要求选择工程生命周期识别工程的特点了解各个生命周期的特点确定适合工程生命周期模型从对用户需求的理解是否充分；人员介入工程的方式；产品的交付方式；工程规模大小和风险上下；对工程系统架构的理解是否充分等方面考虑RUPXPRUPXP依据定义的过程，识别必须完成的任务和工作产品分解时考虑的活动事项要详尽，不要漏掉：教育或培训的需要；参与评审文档；参与工程会议；确定、记录和显示各种与质量相关和与过程相关的数据；传播时间文档制品如：方案、SRS等规模估算制定工作产品的评审方案估算表估算结果评审方案识别工程需要使用的工具和设施识别工程需要使用的工具和设施风险评估识别与其他组之间的关系确定工程的跟踪情况确定工程的组织结构和职责识别工程需要进行的培训制定时间进度表在的停工和节假日时间不安排工作；不考虑加班时间；考虑测试及评审中发现问题的返工需要的时间；考虑客户需求的稳定情况；考虑各项活动的交接和信息的传递时间；识别出的风险对活动的影响；在安排工作时应考虑整个工程的效率因素，在正常估算的工期内增加20～40％的余量，分配到工程的所有活动中――特别是关键路径中的活动中工具指南风险表协同工作方案工程跟踪方案组织和角色定义培训方案时间进度表编写工程开发方案书及其相关方案书编写工程开发方案书及其相关方案书方案评审方案管理和控制SQA方案SCM方案SDP方案Test方案风险方案SPTO工程追踪软件工程开发方案软件工程开发方案日常进度跟踪定期报告工程状态周例会里程碑总结需要调整方案修改和评审方案纠正和预防当出现：规模、工作量、进度和关键计算机资源超出规定的阈值；工程总的原始方案不再可能到达；方案和实际的任务安排明显不相符，起不到指导作用；对客户的承诺不能实现时并满足以下条件时：导致方案变化的原因是知道的，并清楚方案怎么样改变；提议的工程进度方案变动是可到达的；提议的工程进度方案已经得到了必须完成他的人员的许诺在周例会上向工程组的成员传达客户方面的信息、交流工程近期进展情况、未完成的工作、工作中存在的问题、好的经验以及部署下两周的工作，以使得方案和实际的开发工作相符合总结到目前为止工程开发总体状况、工程活动进展情况〔一般通过甘特图来表达〕、活动项进展〔应特别关注未完成活动项〕、本阶段好的经验和典型问题、过程改良建议、客户方面新要求，工程评审、培训执行情况、工程风险等其它方面存在的问题，分析在进度、工作量和缺陷等方面收集的数据并根据情况制定相应的措施和调整时间进度表，保持工程正常、健康开发个人工作周报时间进度表数据收集其它组跟踪周报告分析和预测里程碑报告工程总结工程总结报告PR同行评审评审准备评审准备制定本次评审方案评审跟踪正式评审评审人员进行预审，在指定的时间内给出预审意见，反应给评审组长和作者。评审组长将缺陷〔或问题〕及工作量汇总填入《评审报告》。要评审的文档已经完成且文档符合标准模板要求，工程经理指定评审组长，发放工作产品及参考资料，必要时确定评审重点〔参见评审指南〕工作产品评审方案将报告抄送相关人员工程经理组织解决发现的缺陷〔或问题〕作者根据评审结果进行必要的改良验证人验证最终修正评审通过的产品作为基线的要得到SCCB批准评审通知表个人评审表评审报告SQA质量保证软件工程启动软件工程启动指定SQAE制定质量保证方案并评审通过进行审核发现不符合项方案完成？NoYes制定质量审核方案详细的审核时间安排至少在正式审核前2天发给工程经理或技术经理、SQA经理审核、得到工程或技术经理认可询问相关人员，对工程组的过程执行情况进行审核检查文档和其他一切相关的证据，验证工程组的活动总结审核情况将报告初稿与工程经理及有关人员进行讨论，落实问题负责人；形成正式报告后发送给高级管理者、SQA经理、工程经理、工程成员等相关人员工程质量保证情况总结SQA方案SQA审核方案CheckListSQA审核报告SQA差异报告SDLC生命周期选择当前比拟成熟稳定的SDLC是：WaterFallRUPXP其中：RUP和XP是迭代式开发过程，风险是可控的。RUP的优点是过程清晰、文档齐全，但是过于庞杂，比拟适合大规模的团队；XP的优点是过程简洁、推崇简单，但是不注重文档，难于交接，适合小规模团队。对于中等规模的团队来说，应该基于RUP和XP，进行裁剪，找到适合的SDLC：SDLC的核心是：迭代式和TDD从全局看：Use-CaseDriven用例驱动基于Architecture迭代和递增的从微观看：TDD测试驱动ReFactor重构Pair结对编程DevelopmentProcess开发过程需求需求分析概要设计详细设计编码单元测试集成测试集成测试方案系统测试方案系统测试验收测试形成文档发布维护SRSHLDCODEDD策划软件配置管理软件质量管理评审管理DevelopmentPhase开发阶段需求分析阶段需求收集需求总结总体设计阶段总体架构部署模型概要设计阶段模块划分数据库设计详细设计阶段具体实现编码阶段测试用例Coding单元测试测试阶段测试用例测试修正发布阶段安装测试安装系统维护PhaseProduct阶段制品需求阶段SRS：需求规格说明书总体设计阶段总体设计说明书概要设计阶段HLD：概要设计说明书DB：数据库设计DFD：数据流图UI：用户界面详细设计阶段DD：详细设计说明书编码阶段TestCase：测试用例Coding：源代码UTTestResult：单元测试报告测试阶段TestTask：测试任务书TestCase：测试用例TestResult：测试报告TestApprovals：测试总结发布阶段发布申请书RoleDuty角色职责角色责任研发经理【研发团队】为软件工程提供足够的资源.保证SQA小组的独立性.解决SQA检查时发现的问题.审批对外的承诺。定期审查SCM、SQA、工程方案和跟踪的相关活动。规定系统需求；将系统需求分配给硬件、软件和其他成分；规定硬件、软件和其他成分的界面；监控设计和开发以保证他们符合其规格说明；代表公司下达任务书。SA团队负责网络工程方案的制定及实施；负责对客户的技术支持与培训；负责工程效劳部内部人员素质与技术培训负责系统集成工程标识、测试、验收及质量保证；负责硬件、网络和系统软件产品的最后交付；负责组织自产软件储运、防护、交付和安装；负责工程工程的配置管理QA研究制定测试标准和方案；参加实施测试和质量保证过程；对系统测试中发现的缺陷进行验证；负责组织软件工程任务书、开发方案、里程碑等管理评审；负责公司的配置管理；工程经理负责软件和硬件整个工程的协调、管理进行需求分析，并进行文档的编写组织技术评审等活动组织制定工程开发方案〔SDP〕、风险管理方案等方案配合与协调SQA和SCM小组的活动.管理工程组，执行SQA方针和过程以及SDP.监督和跟踪SDP、工程估算SA负责硬件工程的实施；负责系统的上线；负责系统的维护；SCCB授权建立软件基线和标识配置项/单元；审查和审定对软件基线的更改；审定由软件基线库制造的产品的生成。SCM协助软件工程经理制定SCM方案、维护SCM方案；制定并维护工程标识标准；按时归档配置项；标识并管理置于配置管理过程之下的软件工作产品集合；进行软件工程的软件基线生成、管理和备份；软件配置状态的统计和审计，并向工程组、软件工程经理、高级管理者汇报有关活动情况；将基线的变更情况通知受影响的组和个人；保存并管理各项评审记录、与工程相关的技术文档、标准和规程。SQC依据测试方案模板制定测试方案.执行测试方案进行测试并记录测试发现的缺陷提供测试报告.SQA主要是筹划软件质量保证活动、检验软件产品或活动对可用的标准、需求和规那么的遵守程度、组织处理工程内部不能解决的不一致问题；定期报告检查情况，发现偏差组织制定纠正、预防措施并监督更正；参与制定SQA方案，实施SQA活动，并向SQA经理、软件工程经理工程组、高级管理者汇报有关的情况。DBA负责DB的创立和维护；为DE提供一个稳定的环境；DE按软件开发方案进行开发，并记录相关数据；遵守公司质量管理体系的要求.Deployer根据发布申请，提取代码，发布系统和SA、DBA一起配置环境重构和重建系统Constraints限制SpecificRequirements详细描述本局部按照角色划分详细描述开发过程。Precondition前提SCM配置库目录结构开发库：开发工作区文档和代码工程文档工程启动工程筹划工程方案工程报告开发文档需求设计测试代码代码目录参考资料客户资料等等基线库：评审通过后的文档《文档同开发库》测试库：测试代码和测试发布包文档方案用例测试报告代码版本1版本2参考资料产品库：测试通过后的文档和代码工程交付制品工程总结验收报告。。。工程产品版本1版本2权限测试库：测试人员可以读写其它人员只能读，不能增加、修改和删除基线库：只能增加，不能删除和修改产品库：只能增加，不能删除和修改开发库：TestEnvironment测试环境测试需要一个独立的环境DB独立FTP等资源独立Pass9等外部系统独立最好是一个单独的局域网环境，完全和开发分开开发是环境测试是环境每次测试，应当是一个完整的测试过程安装系统DBWebAppServerClient其它配置系统DB配置AppServer配置系统初始化去除所有历史数据执行初始化脚本，插入初始数据测试系统DevelopmentControlProcess开发控制流程工程启动和筹划阶段本阶段的关键是定义工程、估算工作量和制定详细方案。一个软件工程的正式启动从《软件工程任务书》的下达开始。任务书中写明工程的根本信息及相关责任人和详细分工，规定工程必须提交的产品清单。任务书由研发经理或者工程负责人起草，研发经理批准后下达给相关负责人。工程任务书必须为打印纸质文档，由相关人员签字确认后，入配置管理库归档。软件工程任务书主要作用是明确工程人员职责以及各组之间的协调确认。估算工作量，从确认需求后开始。由工程经理指定评估人员，先按照头脑风暴法估计各个子系统或者模块的难易程度，然后按照Delphi法估算各个局部的工作量。工程经理和PMO成员，根据估算的工作量，制定工程方案。SQA和SCM分别制定各自的方案。SCM需要确定资源库的目录结构和权限结构。工程经理召集PMO、SQA、SCM评审及审核工程方案、SQA方案、SQA审核方案、SCM方案和测试方案。对于发布后的一般性程序修改，不需要下达软件工程任务书。对于关系重大，需要各组人员协调工作的重大修改，工程负责人可以以任务书的形式明确职责、协调关系。测试负责人评估测试资源【人员及机器】，并决定测试人员是否介入工程的需求分析和设计阶段。需求分析、设计、编码阶段本阶段的关键是评审和修订控制，关键评审需要需求、设计、编码、测试、工程管理、用户等的参与。需求阶段，需求分析人员收集需求，根据SRS模版，作出需求规格说明书。设计阶段，设计人员根据总体设计、概要设计、数据库设计和详细设计，作出设计文档。编码阶段，编码人员根据详细设计，设计单元测试用例，编写代码，进行单元测试。关键评审：SRS评审，设计评审，代码走查提交测试阶段工程启动后，工程经理填写测试任务通知单，将测试任务下达给测试组。概要设计评审完成后，由各子系统或者模块的负责人测算完成时间，在确定完成时间后〔正式开始编码前〕将测试任务通知单提交给工程测试负责人，工程测试负责人审核通过在通知单上签字后返回给子工程负责人。开发及单元测试完成后，由开发人员将测试内容提交配置管理员入测试库后，将测试任务通知单提交给发布人员申请测试发布。发布人员将测试库中本次测试的内容发布到测试机后，在测试任务通知单上签字后，提交给测试人员开始测试。测试完成后，测试人员在任务单上填写测试意见后，交测试负责人确认后，返还给开发人员。如测试没有通过，开发人员修改测试内容，进入下一个测试流程。如通过测试，开发人员将测试任务通知单提交给工程负责人，由工程负责人、SCCB签字确认后，提交配置管理员将测试内容入基线库。过程关键：发布实施人员确保发布到测试机上的源程序在配置管理库中得到了有效的标识。生产发布、终测程序通过测试入库以后，根据需要，由工程的负责人负责填写发布申请单。发布申请单由工程测试负责人、配置管理员、SCCB、客户代表、研发经理签字确认后，由工程负责人提交给实施发布人员。发布人员拿到签完字的发布申请后，才能从基线库中提取程序向生产机上发布。如以上发布确认人员没有全部签字同意发布，必须由工程经理签字同意后发布。程序发布到生产机上以后，进入终测【UAT】流程。测试人员和用户代表要对生产机上的程序进行最后测试，确保生产机上的系统符合需求。工程负责人负责同用户协调，工程负责人、测试人员和用户共同编写测试用例。工程负责人将《终测意见书》提交三方签字，根据签字意见决定修订系统或者提交正式发布。终测出现的问题修改按照基线变更流程进行。实施人员只有拿到有三方签字的《终测意见书》后才能将系统正式公开发布。系统正式发布三天之后一周之内，由实施人员负责到用户处取得有用户主要负责人签字的《系统运行报告》，工程负责人负责监督执行。根据《系统运行报告》做相应的处理。过程关键：发布到生产机上的程序都在基线库中得到了有效的标识。发布后问题反应修改正程系统发布之后，用户反应的意见要形成问题清单或者变更申请单，记录需要修改的地方，提交给工程负责人。工程负责人负责判断改动是否会影响需求或者设计，负责将任务分配给相关人员进行修改。修改完成后，提交测试直至发布。这个阶段的最重要的是保证所做的修改〔文档、代码〕都在配置管理库的基线库中得到表达。即基线库中的文档和代码要进行同步更新，关键是发布人员严格根据发布申请单进行控制，并确保发布的代码都是从基线库中取出的。没有经过流程直接要求发布的，发布人员必须予以拒绝。TSP团队软件过程会议组织会议前，确定会议主持人和记录员向参与会议人员发送会议资料参与会议人员阅读会议资料确定会议主题、日期时间和地点注意：留出阅读资料的时间确定会议议程准备会议用品【如投影仪等】重要会议，需要签到会议开始前，申明会议纪律发言时间限制发言顺序除主持人外，不得打断别人记录员记录会议纪要会议后，发送会议总结沟通问题原那么目标明确明确反应反复沟通请求－答复当有疑问时，发出请求明确求助对象，指定第一对象和辅助对象第一对象接收到请求后，不能及时答复的应当转发给自己认为适宜的答复人，并告知求助人求助方式【高－低】：当面，，