嵌入式软件开发作业流程.doc

嵌入式软件开发步骤
一、嵌入式软件开发步骤
1.1  嵌入式系统开发概述
     由嵌入式系统本身特征所影响，嵌入式系统开发和通用系统开发有很大区分。嵌入式系统开发关键分为系统总体开发、嵌入式硬件开发和嵌入式软件开发3大部分，其总体步骤图图1.1所表示。

图1.1  嵌入式系统开发步骤图
     在系统总体开发中，因为嵌入式系统和硬件依靠很紧密，往往一些需求只能经过特定硬件才能实现，所以需要进行处理器选型，以愈加好地满足产品需求。另外，对于有些硬件和软件全部能够实现功效，就需要在成本和性能上做出抉择。往往经过硬件实现会增加产品成品，但能大大提升产品性能和可靠性。
     再次，开发环境选择对于嵌入式系统开发也有很大影响。这里开发环境包含嵌入式操作系统选择和开发工具选择等。本书在4.1.5节对多种不一样嵌入式操作系统进行了比较，读者能够以此为依据进行相关选择。比如，对开发成本和进度限制较大产品能够选择嵌入式Linux，对实时性要求很高产品能够选择Vxworks等。
     因为本书关键讨论嵌入式软件应用开发，所以对硬件开发不做具体讲解，而关键讨论嵌入式软件开发步骤。
1.2  嵌入式软件开发概述
     嵌入式软件开发总体步骤为图4.15中“软件设计实现”部分所表示，它同通用计算机软件开发一样，分为需求分析、软件概要设计、软件具体设计、软件实现和软件测试。其中嵌入式软件需求分析和硬件需求分析合二为一，故没有分开画出。
因为在嵌入式软件开发工具很多，为了愈加好地帮助读者选择开发工具，下面首先对嵌入式软件开发过程中所使用工具做一简单归纳。
     嵌入式软件开发工具依据不一样开发过程而划分，比如在需求分析阶段，能够选择IBMRational 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调试方法

开发步骤框图：
阶段
步骤图
文档
项目
立项
阶段
任命项目经理
成立项目团体小组

项目提议书
可行性分析
市场信息反馈

签发项目任务书

可行性分析汇报
项目任务书

项目
总体
计划
产品定义
系统分析
各部需求分析
需求分析评审

确定里程碑
编制质量控制计划
编制项目计划书
风险控制计划

需求分析汇报
需求分析评审汇报
产品定义
产品技术规范
项目开发计划
风险控制计划
质量控制计划
系统分析文档
设计
阶段
系统分析评审
硬件设计步骤
软件设计步骤
结构设计及制作步骤图
软件V1.0
PCB V1.0
T1
工艺设计步骤
工艺说明
T1

评审，过程文件归档

产品技术总体设计方案（包含工艺）
系统分析评审汇报
软件设计过程文档
硬件设计过程文档
结构设计过程文档
工艺设计过程文档
软件V1.0
PCB V1.0
T1设计文档
工艺说明
分单元测试汇报
设
计
验
证
阶
段

T1

整机测试及评定
软硬件及工艺调整版本升级

FTA准备
修模
例试汇报及分析
装机汇报
少许装机
装机准备

装机汇报
例试分析汇报
整机测试评定汇报
软件FTA版本
硬件FTA版本

T2
FTA

修模
软硬件及工艺调整版本升级

CTA材料下单

例试、整机测试及评定
试产准备
小批量试产
FTA

T2设计文档
试产汇报
例试分析汇报
整机测试评定汇报
软件CTA版本
硬件CTA版本

T3
CTA

软硬件结构及工艺调整
版本升级

量产版本确定

例试、整机测试评定
试产准备
CTA准备
第二次试产
CTA

T3设计文档
试产汇报
例试分析汇报
整机测试评定汇报

量产
准备
阶段
生产工艺准备
全套文件归档
手工下单
封样

全套DVT汇报
工艺文件
量产
转移
量产转移

附录：1、结构设计及制作步骤图
2、软件设计步骤图
3、硬件设计步骤图

附录1. 结构设计及制作步骤图：
阶段
步骤图
表单
3D模型修改
结构
制订结构设计进度计划表
可行
评定
3D模型可行性评定

3D模型评定汇报
结构设计进度表

具体结构设计
结构
具体
设计

结构设计进展汇报

结构设计修改
结构设计内部评审

结构设计进度表

结构
设计
验证
评审

相关资料准备

结构设计外部评审
模具制作检讨
working sample验证
制作working sample

签署商务协议
开模
结构设计修改

结构设计内部评审统计
workingsample配色表
workingsample验收汇报
结构BOM
结构设计外部评审统计
模具制作检讨统计表
模具制作申请表
模含有品清单
模具制作注意事项表
工装夹具制作清单
物料进度按排需求表
配色方案表
模具制作进度表
参考文件：
《工业设计步骤》，《ID设计步骤》

附录2. 软件设计步骤图：
阶段
步骤图
表单
软件
需求
分析
软件开发计划和配置管理计划进度计划表
软件需求分析（包含技术风险评定）

软件测试计划

软件需求规格书
软件开发计划
软件开发风险控制计划
软件测试计划
软件
具体
设计
具体软件设计
内部设计评审

软件具体设计说明书
软件接口设计说明书
软件设计内部评审统计
软件
实现
测试

编码调试
编写测试用例
单元测试
软件集成/调试

评审后公布并归档
软件修订
软件系统测试
公布系统测试版本

单元源代码
单元调试汇报
单元测试用例
单元测试分析汇报
集成后软件及源代码
软件集成调试汇报
软件操作手册
系统测试软件
系统测试用软件文档
软件系统测试分析汇报
公布版本
参考文件：

附录3. 硬件设计步骤图：
阶段
步骤图
表单
硬件
需求
评定
硬件开发计划和配置管理计划进度计划表
硬件需求分析（包含技术风险评定）

硬件测试计划

硬件需求分析汇报
硬件开发计划
硬件测试计划
硬件
具体
设计
具体硬件设计

LCD认证步骤
关键器件采购
PCB毛坯图设计

内部设计评审

硬件具体设计说明书
硬件电路原理图
硬件BOM
硬件设计内部评审统计
硬件
实现
测试

软件
投板前审查
PCB布板步骤

打样、试产
硬件调试

硬件内部评审
PCB贴片

整机测试
评审后公布并归档
硬件修改

PCB数据
器件规格书
硬件子系统软件
装配图
硬件单元测试分析汇报
电装总结汇报
硬件系统测试版本
硬件系统测试分析汇报
硬件评审验证汇报
公布版本
参考文件：
1、 PCB布板步骤图
2、 LCD认证步骤图

PCB布板步骤图：
阶段
硬件
结构
其它各部
表单
布板
需求
设计
硬件电路原理图

PCB布板设计

结构尺寸要求

项目需求/产品定义

PCB
确定
投板前审查

PCB GERBER

PCB
投板
PCB投板

参考文件：

LCD认证步骤图：
阶段
硬件
结构
其它各部
表单
样品
提供
样品需求
SPEC
LCD供给商数据搜集和选择

供给商提供样品

尺寸

各部
确定
各部确定？
供给商供样

和供给商沟通

SPEC

各部提出修改要求
电性能SPEC

尺寸确定

软件确定

装机

是否经过？

否

是

封样

装机验证

参考文件：

软件开发规范

Software Development Specification

Version: V1.0
Date: -06-22

Prepared by

Document Revision History文档修订统计

VERSION版本
DATE
日期
DESCRIPTION
内容说明
INDIVIDUAL
修订人
1.0
-06-22
初稿

1 Introduction 介绍

一个成熟稳定组织或团体，能够降低风险，常常地成功地达成目标。成功含义是：按时、预算内【即符合成本要求】、符合质量要求。换言之，成熟稳定团体，能够避免以下问题：
Ø 组织方面出现问题
Ø 对需求缺乏管理
Ø 缺乏计划和控制
Ø 估算错误
同时，还要在以下多个方面做得比较出色：
Ø 人员调度和工作安排
Ø 工作量估量
Ø 预算管理
Ø 责权分配和平衡
Ø 实施和监控
Ø 沟通

本文档是软件开发规范，努力争取使团体打下一个良好基础，方便逐步成长为成熟稳定团体。团体需要一个逐步标准、规范开发过程，在这个过程中，团体得到锻炼，组员能力得到提升，风险得到控制。
关键内容是：
Ø 定义软件开发步骤；
Ø 定义软件开发文档格式；
Ø 定义包含角色；
Ø 定义包含信息；
Ø 描述开发步骤；

1.1 Purpose 目标

本文档目标是：
Ø 统一软件开发团体步骤、文档；
Ø 促进团体组员沟通，降低误解；
Ø 促进程序员书写易维护代码；
Ø 提升代码编写效率；
Ø 使每个组员成为一个高效程序员；

1.2 Scope 范围

本文档，包含：
Ø 项目管理步骤；
n 项目策划
n 项目追踪
n 配置管理
n 质量确保
n 同行评审
Ø 包含文档；
n 项目计划mpp
n 需求规格说明书SRS
n Delphi估算
n 项目状态汇报
n 配置库样式
n CheckList
n 评审表
n 变更申请表
Ø 开发工具规范；
n 数据库设计工具
n 功效设计工具
n IDE
n 配置工具

1.3 Definitions, 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.4 References 引用

《CMM2》
《CMM3》
1.5 Overview 文档组织

本文档关键分为四大部分：
Ø 概述；
描述了团体组织开发过程高层视图；

Ø TSP和PSP；
根据团体和个人描述步骤规范；

Ø 工具规范；
描述了开发工具具体规范；

Ø 文档；
包含文档格式；

2 The Overall Description 概述

本部分是开发团体开发过程高层描述。它描述了开发过程规范背景，用来和全部包含各方就基础过程达成共识。

2.1 Software Development Organizing 开发团体组织结构

说明： 表示企业行政部门 表示企业逻辑部门
实线表示参与产品实现组织和人员（不表示所属关系）
虚线表示工作汇报关系，如SQAE向SQA经理汇报。

2.2 Project Base Process 项目基础步骤

识别需求
提出处理方案
实施项目
结束项目
投入力量
可行性分析汇报
需求提议书
协议
项目目标
项目定义 制订计划 计划实施 项目终止
时间

基础步骤说明：
Ø 项目开启： 本阶段关键是进行可行性分析，定义项目，识别需求；
Ø 制订计划： 本阶段关键是计划策划，估算工作量，制订具体可实施计划；
Ø 计划实施： 本阶段关键是实施计划，完成计划中各项任务，汇报计划状态；
Ø 项目终止： 计划实施完成，总结项目；
2.3 CMM Base Process CMM基础过程

SCM
SQA
Work Area
BaseLine
SPP
SPTO
PR
Change & PR

基础过程说明：
Ø SCM： 软件配置管理，全部活动基础，一切制品必需放入配置库；
Ø SPP： 软件项目策划，估算工作量，制订具体计划【项目标制订计划阶段】；
Ø SPTO：项目追踪，汇报项目状态，评定并更新计划【项目标计划实施阶段】；
Ø PR： 同行评审，进入基线前提条件，降低风险，提升质量有效手段；
Ø SQA： 质量确保，预防风险有效手段；

2.3.1 SCM软件配置管理

配置管理关键处理：
Ø 版本
Ø 变更
确定配置项和基线
确定统计和汇报配置项状态策略
定义配置项
定义访问权限访问权限
确定配置管理工具
确定SCCB组员
确定配置库及其目录结构
项目开启
确定配置管理人员
Vss、SVN或VSTS
通常由：项目经理、技术经理、用户经理、质量确保人员、配置管理等项目标关键组员人员组成。
在配置项（基线）生成和基线变更时
配置库结构
权限表
基线表
确定基线变更过程

定义备份和病毒策略
按计划实施配置
管理活动
SCM计划制订和评审
统计和汇报基线状态
在配置项（基线）生成和基线变更时
最少在项目标每个里程碑结束时进行备份
1建立配置库
2对项目组指导和培训
3对配置项日常管理
4参与评审会议
5定时备份和病毒防护
6实施公布
7进行归档
8配置管理计划维护
配置管理情况总结
计划完成
总结配置项是否完整、基线改变情况统计、审核发觉问题情况统计、改善提议等，记入项目总结汇报
定义测试和公布归档方法
SCM计划
配置审核
状态汇报
审核汇报

2.3.2 SPP 计划策划

计划策划关键是工作量估算

从历史库中识别可用信息
项目开启
从企业数据中识别项目相同信息，如项目标总结汇报和其它数据或文挡
项目需求、协议和《软件项目任务书》等相关要求
选择项目生命周期

识别项目标特点

了解各个生命周期特点

确定适合项目生命周期模型
从对用户需求了解是否充足；人员介入项目标方法；产品交付方法；项目规模大小和风险高低；对项目系统架构了解是否充足等方面考虑

RUP
XP
RUP
XP
依据定义过程，识别必需完成任务和工作产品
分解时考虑活动事项要详尽，不要遗漏：教育或培训需要；参与评审文档；参与项目会议；确定、统计和显示多种和质量相关和和过程相关数据；传输时间
文档制品
如：计划、SRS等

规模估算
制订工作产品评审计划
估算表
估算结果

评审计划

识别项目需要使用工具和设施
风险评定
识别和其它组之间关系
确定项目标跟踪情况
确定项目标组织结构和职责
识别项目需要进行培训
制订时间进度表
在已知停工和节假日时间不安排工作；不考虑加班时间；考虑测试及评审中发觉问题返工需要时间；考虑用户需求稳定情况；考虑各项活动交接和信息传输时间；识别出风险对活动影响；在安排工作时应考虑整个项目标效率原因，在正常估算工期内增加20～40％余量，分配到项目标全部活动中――尤其是关键路径中活动中

工具指南

风险表

协同工作计划

项目跟踪计划

组织和角色定义

培训计划

时间进度表

编写项目开发计划书及其相关计划书
计划评审
计划管理和控制
SQA计划
SCM计划
SDP计划
Test计划
风险计划

2.3.3 SPTO项目追踪

软件项目开发计划
日常进度跟踪
定时汇报项目状态
周例会
里程碑总结
需要调整计划
修改和评审计划
纠正和预防
当出现：
规模、工作量、进度和关键计算机资源超出要求阈值；项目总原始计划不再可能达成；计划和实际任务安排显著不相符，起不到指导作用；对用户承诺不能实现时
并满足下列条件时：
造成计划改变原因是知道，并清楚计划怎么样改变；提议项目进度计划变动是可达成；提议项目进度计划已经得到了必需完成她人员许诺
在周例会上向项目组组员传达用户方面信息、交流项目近期进展情况、未完成工作、工作中存在问题、好经验和布署下两周工作，以使得计划和实际开发工作相符合
总结到现在为止项目开发总体情况、项目活动进展情况（通常经过甘特图来表现）、活动项进展（应尤其关注未完成活动项）、本阶段好经验和经典问题、过程改善提议、用户方面新要求，项目评审、培训实施情况、项目风险等其它方面存在问题，分析在进度、工作量和缺点等方面搜集数据并依据情况制订对应方法和调整时间进度表，保持项目正常、健康开发
个人工作周报
时间进度表
数据搜集
其它组跟踪
周汇报
分析和估计
里程碑汇报
项目总结
项目总结汇报

2.3.4 PR同行评审

评审准备
制订此次评审计划
评审跟踪
正式评审
评审人员进行预审，在指定时间内给出预审意见，反馈给评审组长和作者。
评审组长将缺点（或问题）及工作量汇总填入《评审汇报》。
要评审文档已经完成且文档符合标准模板要求，项目经理指定评审组长，发放工作产品及参考资料，必需时确定评审关键（参见评审指南）
工作产品评审计划
将汇报抄送相关人员
项目经理组织处理发觉缺点（或问题）
作者依据评审结果进行必需改善
验证人验证最终修正
评审经过产品作为基线要得到SCCB同意
评审通知表
个人评审表
评审汇报

2.3.5 SQA质量确保

软件项目开启
指定SQAE
制订质量确保计划并评审经过
进行审核
发觉不符合项
计划完成？
No
Yes
制订质量审核计划
具体审核时间安排最少在正式审核前2天发给项目经理或技术经理、SQA经理审核、得到项目或技术经理认可
问询相关人员，对项目组过程实施情况进行审核
检验文档和其它一切相关证据，验证项目组活动
总结审核情况
将汇报初稿和项目经理及相关人员进行讨论，落实问题责任人；
形成正式汇报后发送给高级管理者、SQA经理、项目经理、项目组员等相关人员
项目质量确保情况总结
SQA计划
SQA审核计划
CheckList
SQA审核汇报
SQA差异汇报

2.4 SDLC 生命周期选择

目前比较成熟稳定SDLC是：
Ø WaterFall
Ø RUP
Ø XP

其中：RUP和XP是迭代式开发过程，风险是可控。
Ø RUP优点是过程清楚、文档齐全，不过过于庞杂，比较适合大规模团体；
Ø XP优点是过程简练、推崇简单，不过不重视文档，难于交接，适合小规模团体。

对于中等规模团体来说，应该基于RUP和XP，进行裁剪，找到适合SDLC：
Ø SDLC关键是：迭代式和TDD
Ø 从全局看：
n Use-Case Driven用例驱动
n 基于Architecture
n 迭代和递增
Ø 从微观看：
n TDD测试驱动
n ReFactor重构
n Pair结对编程

2.5 Development Process 开发过程

需求
分析
概要
设计
具体
设计
编码
单元
测试
集成
测试
集成测试计划
系统测试计划
系统
测试
验收
测试
形成
文档
公布
维护
SRS
HLD
CODE
DD

策
划
软件配置管理
软件质量管理
评审管理

2.5.1 Development Phase 开发阶段

Ø 需求分析阶段
n 需求搜集
n 需求总结
Ø 总体设计阶段
n 总体架构
n 布署模型
Ø 概要设计阶段
n 模块划分
n 数据库设计
Ø 具体设计阶段
n 具体实现
Ø 编码阶段
n 测试用例
n Coding
n 单元测试
Ø 测试阶段
n 测试用例
n 测试
n 修正
Ø 公布阶段
n 安装测试
n 安装系统
n 维护

2.5.2 Phase Product 阶段制品

Ø 需求阶段
n SRS：需求规格说明书
Ø 总体设计阶段
n 总体设计说明书
Ø 概要设计阶段
n HLD：概要设计说明书
n DB：数据库设计
n DFD：数据流图
n UI：用户界面
Ø 具体设计阶段
n DD：具体设计说明书
Ø 编码阶段
n Test Case：测试用例
n Coding：源代码
n UT Test Result：单元测试汇报
Ø 测试阶段
n Test Task：测试任务书
n Test Case：测试用例
n Test Result：测试汇报
n Test Approvals：测试总结
Ø 公布阶段
n 公布申请书
Ø

Role Duty 角色职责

角色
责任
研发经理
【研发团体】
为软件项目提供足够资源.
确保SQA小组独立性.
处理SQA检验时发觉问题.
审批对外承诺。
定时审查SCM、SQA、项目计划和跟踪相关活动。
要求系统需求；将系统需求分配给硬件、软件和其它成份；要求硬件、软件和其它成份界面；
监控设计和开发以确保她们符合其规格说明；
代表企业下达任务书。
SA团体
负责网络工程计划制订及实施；
负责对用户技术支持和培训；
负责工程服务部内部人员素质和技术培训
负责系统集成工程标识、测试、验收及质量确保；
负责硬件、网络和系统软件产品最终交付；
负责组织自产软件储运、防护、交付和安装；
负责工程项目标配置管理
QA
研究制订测试规范和方案；
参与实施测试和质量确保过程；
对系统测试中发觉缺点进行验证；
负责组织软件项目任务书、开发计划、里程碑等管理评审；
负责企业配置管理；
项目经理
负责软件和硬件整个项目标协调、管理
进行需求分析，并进行文档编写
组织技术评审等活动
组织制订项目开发计划（SDP）、风险管理计划等计划
配合和协调SQA和SCM小组活动.
管理项目组，实施SQA方针和过程和SDP.
监督和跟踪SDP、项目估算
SA
负责硬件工程实施；
负责系统上线；
负责系统维护；

SCCB
授权建立软件基线和标识配置项/单元；
审查和审定对软件基线更改；
审定由软件基线库制造产品生成。
SCM
帮助软件项目经理制订SCM计划、维护SCM 计划；
制订并维护项目标识规范；按时归档配置项；
标识并管理置于配置管理过程之下软件工作产品集合；
进行软件项目标软件基线生成、管理和备份；
软件配置状态统计和审计，并向项目组、软件项目经理、高级管理者汇报相关活动情况；
将基线变更情况通知受影响组和