程序开发部程序开发及每日构造过程

  • 格式:pdf
  • 大小:181.67 KB
  • 文档页数:7

程序开发及每日构造过程
目录
1过程总述
1.1概述
1.2过程单元描述
1.3活动流程图
1.4人员职责
2活动详述
2.1进行编码工作
2.2代码静态审查
2.3单元测试
2.4集成测试
3过程裁剪
4度量
5规范
5.1确定编码的原则
5.2《C/C++编码规范》
6模板
7版本记录
1 程序开发及每日构造过程总述
输入
评审过的各模块《详细设计说明书》《项目计划书》
《产品需求规格说明书》编码质量准则(checklist )
就绪条件各模块《详细设计说明书》通过评审活动
1.确定编码原则并进行培训2.进行编码工作3.代码评审4.单元测试
完成条件代码完成单元测试代码进入配置管理基线
输出
评审通过的代码、单元测试用例和测试报告、代码检查记录
1.1 概述
程序开发及每日构造过程的目标是编写符合需求和设计的产品代码。

本阶段是实现产品的重要阶段,项目组开发人员应根据设计阶段输出的各个模块的详细设计方案进行编码,并完成单元测试,输出测试过的组件,提交应用集成部做集成测试。

原则上在全部详细设计正式评审通过后,开发人员就可以依据设计进行编码工作。

但在实际操作中,由于详细设计的模块很多,在部分模块完成详细设计并经过评审后即可启动这些模块的编码工作。

在整个开发过程中质量管理人员应着重检查编码的规范性和质量,并注意监控单元测试和集成测试过程。

配置管理人员应注意编码、文档的版本控制和稳定系统联调试时的的模块版本;
当需求发生变更时,为保持需求与设计、代码的一致性,项目组需要同时修改相关的概要设计文档、详细设计文档和代码。

项目组开发人员必须受到有关编码规范和开发方法的培训。

1.2 过程单元描述
1.3 活动流程图
整体开发过程活动的流程图如下:
每日构造的执行者是程序开发人员,流程图如下:
1.4人员职责
角色职责
部门总监负责进入程序开发及单元测试阶段的所有产品
的跟踪管理及相关技术和文档的评审工作;
负责人员的调配与管理
子部门经理对代码质量及过程进行监控,同时负责协调关
键技术的解决;
负责部门内资源的调配及管理
开发组长开发组人员任务的分配;
开发工作的流程控制:代码互查,单元测试过
程的控制
开发中关键技术问题的解决
对测试中的bug进行分析,并分配给开发人员
解决
开发工程师按详细设计说明书的要求进行代码编写;
根据组件特性进行单元测试用例编写;
进行单元测试;
组内人员的代码互查
系统设计师进行代码检查 / 抽查
集成工程师搭建每日集成环境;
进行组件的编译和构建,并交给测试部进行集
成测试;
进行组件的集成,并交给测试部进行系统测试测试工程师进行集成测试和系统测试。

2 活动详述
2.1 进行编码工作
在拿到详细设计文档和项目计划以及需求规格说明书后,子部门经理和开发组共同制定详细的开发计划,如开发计划和总体项目计划有冲突,则需经项目经理评审。

开始编码前,主设计师带领全体开发人员在质量经验库中查询同类项目编码相关问题,讨论应对策略,避免同类问题再次发生。

开发人员按照每个模块的《详细设计说明书》进行编码工作。

编码要符合项目确定的编码规范和原则。

开发人员首先应该自行检查代码是否符合编码规范;在每日构造活动之前,开发人员的代码需经过至少一个其他开发人员的检查,检查人员和检查记录需留下文档记录;同时项目经理和主设计师要负责检查开发人员完成的代码是否符合编码规范。

在编码时,如果发现《详细设计说明书》中的问题或者不完善的地方,开发人员应该把问题提交主设计师。

由主设计师负责安排修改设计文档。

并保证设计文档与开发代码的一致性。

2.2 代码静态审查
代码开发完成后,应该对代码进行审查。

代码静态审查的主要目的为:
所开发的代码功能是否与详细设计文档中描述的模块应该
完成的功能一致。

代码是否符合编码规范
代码是否正确无误,没有隐含的错误。

代码静态审查主要分为以下几个步骤:
1.选择合适模块
由于代码量很大,不可能全部代码都进行静态审查,因此需要根据工作量和进度,选择适量的合适的模块进行代码审查。

选择模块的原则如下:
模块的关键程度。

对于对整个系统比较关键(例如:对系
统功能、质量、性能非常关键,或者在结构上处于关键路
径)的模块,建议进行代码检查。

模块的复杂程度。

对于实现起来比较复杂的模块,建议进
行代码审查
历史情况。

对于以前实现过的类似模块发现的缺陷较多,
建议进行代码审查
研发人员的经验和水平。

对研发人员经验相对较少的人员
编写的模块,建议进行代码审查
一般建议选择的模块占总模块数量的20%左右。

项目经理和主设计师可以根据项目的进度和代码情况进行适当选择和调整。

2.系统设计师进行代码静态抽查
系统设计师对代码进行静态抽查,确认代码是否满足编码规范。

可以采用合适的代码检查工具(如LDRA等)进行检查。

系统设计师记录代码检查情况,并要求开发人员修改检查处的问题。

3.进行代码同行评审
对所选择的模块代码进行同行评审。

代码评审的方式可以采用交叉走查代码方式,对比较重要的代码应进行正规评审。

对代码进行同行评审的主要目的是确认代码是否正确无误以及验证代码是否与详细设计文档一致。

具体的评审工作可参见《同行评审过程》
开发人员修改评审中发现的问题。

评审通过后的代码应进入配置管理。

2.3 每日构造
开发人员每天必须提交代码到每日构造环境中进行构造和自动化单元测试,若出现问题,测试人员应及时修改,并恢复代码库中的代码到可以构造的版本。

2.4 单元测试
要求所有模块都必须进行单元测试。

开发人员修改单元测试中发现的问题
单元测试完成后要进行评审。

通过单元测试的模块代码必须检入到配置管理库中。

单元测试的具体要求参见《单元测试过程》
3 过程裁剪
对于有经验的项目,代码评审活动可以裁剪。

4 度量
开发阶段花费的工作量
代码的规模
代码同行评审的记录
修改评审意见所花费的工作量
单元测试的记录
修改单元测试问题的工作量
5 规范
5.1 确定编码的原则
1. 项目经理和主设计师根据公司编码规范确定自己项目的编码规范。

具体要求如下:
对于C/C++等语言,公司已制订标准的编码规范,项目直接
即可。

对于其它开发语言,项目组可以自行选择业界合适的编码规
范。

但必须经项目管理处审核通过。

2. 项目经理和主设计师根据通用编程规范,定制本项目实施的细则。

实施细则包括:标识符命名原则、开发目录结构、文件名命名、版本控制等制订实施细则后开发人员就可以在统一的环境下工作,保证开发后期集成Build能够顺利进行
5.2 《C/C++编码规范》
参见公司C++编码规范
5.3 《JAVA编码规范》
参见公司JAVA编码规范
6 模板
《代码评审记录表》
7 版本记录
修改原因修改位置修改人审核人版本号修改日

0.1
0.2
0.3
0.4
0.5。