作者：杨天剑 关键词：质量管理

日本项目的一般特点

中国公司做的某些日本项目一般是整体项目中的一部分，在应用瀑布模型的开发中，通常是将下游工程承接下来，其特点是生命周期不完整，一般总体的项目经理在日方。中方的项目经理更多的是承担上传下达，翻译沟通，组织生产的任务。

日方通常会对项目进行紧密的管理。工程上，日方负责制定或者批准作业方法，各种规约，流程及手顺；提供范例，检查单，管理模板,评审PILOT产出，日方还会要求中方提交BUG记录，品质分析，质量报告等文档，甚至于变更程序的差分结果。管理上，日方还会代劳项目的估算，通过提供参考值的方法限定项目的规模。日方会紧密地跟踪项目的日程和品质状态，甚至插手人员体制的管理。技术上，日方会通过Ｑ&Ａ票或称悬案的方式对中方提出的技术问题进行解答 。

总 而言之，有些对日外包公司与客户之间的关系表面上看与一般软件公司和客户的关系类似，但是在工程上，有点类似母子公司，开发部门更是和日方同属一个项目 组，但是关于利润的分配和风险的分担上，还是有业务关系的不同公司。在技术上也有一定的差距。这就导致对日软件外包项目的不同之处，一般日方会比较注重工 程，中方则偏重语言和技术，管理则是由双方配合完成的。

代码评审

日本某些项目中的代码评审一般采用固化及改良的同行桌审的方式进行，有时称作DD。

之所以称为固化，是因为每个本程序都要在疏通之后，单元测试之前经过评审；之所以称为改良，是因为评审需要计划，并跟踪缺陷的解决，还要对缺陷进行统计记录及因果分析，而这一般是正式评审的特征。

评审的时候，需要依据仕样书，规约和PCL对代码进行校验，在质量要求高的项目中，同时需要将PCL上面的点标注在代码上面。评审发现的BUG，需要记录并跟踪和确认其修改情况，并记录在ＢＵＧ票中，个别质量要求低的项目可以将BUG标注在代码上面，但是要统计。

代码评审一般由专门的经验丰富的人员担当，通常会是TL（Team Lead）或者SE（software Engineer）。通常建议打印出来，但是只看打印的代码会非常困难，所以需要在编辑器中阅读代码。需要遍历多次代码，目标是不同的。

代码评审与其它的制品评审一样都是要求100%覆盖的。不存在可以不评审的裁剪。

所有缺陷都要记录，后面会对记录的主要方法有专门介绍。

测试后的检证

测试本身不能检查或者证明程序的一致和正确，需要进行文档化的处理。

检证指的是的在进行测试之后，将测试的输入输出数据或者截屏整理在一个文档中，每次运行的数据放在EXCEL的一个SHEET中 检查和验证测试结果与的正确，将CL（checklist）上面的点标注在检查正确的结果上面。未能检证的点需要说明理由，并主观判断其验证的点是否通过。

检证时一般要使用一些自动整理数据的工具，通常由在EXCEL中二次开发做成。检证的工作量很大，但是对于确保测试结果的确认和客观证据非常重要，检证的结果是纳品物（交付品）之一，有的项目要做为基线管理，其原因并不是直接影响产品，而是要交付给客户。

缺陷的记录

代码评审与测试中的缺陷，主要通过BUG票的形式来记录。通过记录的流程，其严谨程度可见一斑。下面详细介绍一种：

Ｂ票即ＢＵＧ票，是记录基础ＢＵＧ数据的表单，内容比较多，在质量要求高的项目中，所有的程序变更都需要填写。 Ｂ票是一般是纸质的，便于流转。

n  Ｂ票编号，程序ID，版本号：

由配置管理员分派并统一管理，在每个项目中编号是不重复的

n  发现者信息：

由发现者填写，发现者名字，发现手段（工程），发现日

n  ＢＵＧ现象：

由发现者填写，指的是测试是发现的不符合预期的现象，比如计算出的金额是５０００元，（与正确的结果不符合），评审中发现的ＢＵＧ，现象与原因一致

n  ＢＵＧ原因：

由作入者填写，指什么内容导致了错误的现象，如汇率值为１０

n  ＢＵＧ对策：

由程序作者填写，指如何修正程序以消除ＢＵＧ的现象，如汇率改为１００

n  担当者信息：

由程序作者填写，包括担当者名字，修正日期等

n  作入工程：

由作者填写，指的是产生ＢＵＧ的开发错误是哪个工程作入的，一般为选择

n  发生部位

由作者填写，一般为选择，指ＢＵＧ在开始处理，LOG输出，计算处理等部位

n  动机原因

由作入者填写，一般为选择，仕样错误，业务理解，语言知识，单纯错误等

n  确认者信息：

由确认者，通常是ＴＬ或者ＱＡ填写，包括名字，确认日期，签字等

n  应摘出工程

由确认者填写，一般为选择，指ＢＵＧ应该在什么质量工程中摘出

n  未摘出理由

由应摘出工程担当填写，一般为选择，如CASE不足，确认不够等

n  ＢＵＧ严重度

由确认者填写，ＢＵＧ的严重程度，一般为选择，如致命，严重，一般，轻微等

n  修改后的版本号

由配置员填写

可见，一张ＢＵＧ票要经过，配置管理员，发现者，作者，作入者，本来摘出工程担当，确认者等角色通过多次流转才能完成，ＢＵＧ票在完成后，会整理成ＢＵＧ一览，上面有所有内容，只是列表的形式。ＢＵＧ票要翻译成为日语并提交客户，ＢＵＧ票上面的内容作为品质分析的输入。

品质管理

项 目计划时要有品质方面的目标，分为：检查点密度的目标，ＢＵＧ率目标，以及测试覆盖率的目标。ＢＵＧ率的目标要进行横向和纵向的分配，所以在完成了 ＷＢＳ，估算和计划后，每本设计和程序就有了自己的品质目标。在测试时要跟踪测试点的消化情况和ＢＵＧ的摘出情况，形成品质管理图（见下图），在测试完了 后，要填写测试完了报告。在全部质量过程完成后，要做品质分析，以品质分析结果为输入，进行品质向上的ＡＣＴＩＯＮ。

测试完了报告

测试结束的时候要填写测试完了的报告，以单元测试为例，报告内容包括：

n  程序的ID

n  程序的估算规模和实际规模

n  程序的估算测试点数量的实际测试点数据

n  程序的覆盖率目标和实际覆盖率

n  程序的ＢＵＧ率目标和实际的ＢＵＧ率

n  未达标说明

n  客观质量判断

n  主观质量见解

品质分析

测试全部完成以后，要对所有的程序进行品质分析，内容通常包括：

n  总体质量目标的达成情况及未达标说明

n  程序别ＢＵＧ率分析

n  工程别ＢＵＧ分析

n  部位别ＢＵＧ分析

n  担当别ＢＵＧ分析

n  ＢＵＧ严重度解析

n  ＢＵＧ原因分析

n  ＡＣＴＩＯＮ　ＰＬＡＮ

品质向上

n  根据品质分析的结果，按照ACTION PLAN对项目中的质量进行再次检查

n  一般会是品质分析结果的直接体现，常用的方法为：

n  对所有问题多发的程序和处理进行普查

n  对BUG率超常的程序进行追加测试

n  对问题多发工程的产出再评审

n  对重点问题的原因有针对性的自查或者评审

n  责成LEADER对不符合要求的见解再分析

不厌其烦

日本项目中的QA一般会不厌其烦的对于项目中的问题进行苛刻的指摘，对于项目制品的质量也起着关键的作用。