作者：肖敬龙
【摘 要】对日软件外包是目前在国内发展迅速的一个行业，但是由于国界、地域、语言、习俗等差异，导致了对日软件外包的质量得不到保证。通过研究和实践总结，结合所学的知识，探讨如何保证对日软件外包的质量。
【关键词】对日软件外包 软件质量 方法研究
目前，软件外包在软件出口中占有很大的比重，尤其是日本对中国的软件外包。据统计日本对中国的软件外包比例占70%左右。日本很多大型企业在软件外包业务中，输出到中国的软件外包大大超过印度，平均占83%，有的企业达到95%。但是，在中日软件外包中，存在的最大问题是质量问题。引起质量问题的原因很多，最主要的是：中日双方的企业文化、管理模式的差异，还有开发过程、沟通方式、开发标准和文档格式不统一等问题。
1 加强语言功底
开发人员对委托方提供的设计资料的理解程度直接影响着开发进度和质量。从过去的产品质量数据分析结果来看，对设计资料的理解错误是产生质量问题的主要原因。特别是对设计资料的理解错误，如果不从一开始就采取措施进行预防，对程序本身及其他程序的质量将可能产生较大的影响。针对这一点，系统开发部开展了以“预防/消除设计资料理解错误”为主题的质量控制（QC）活动。随着活动开展的深入，质量控制逐渐取得了明显的成效。这一活动的首要任务就是学习语言。
2 加强沟通
对日软件外包通常是不会外包需求、分析和设计阶段的。这样造成接包方和发包方对需求、分析和设计在理解上的分歧，从而导致设计或编码的不断变更。需求和设计的不稳定是软件业的通病，是软件业最让人头疼的顽疾。有人说有一个软件领域的需求就非常稳定，可以在设计完成之后就不再变化，这就是离岸软件外包。至少针对日软件外包，在我看来这是大错特错的。公司在做HC（HeartCore）项目时，客户前后的设计说明书就变更了7个版本，仅需求理解就花费了20天时间，而开发和测试时间却不到10天。日本软件业的需求和设计文档相当规范，但这并不代表它们不会变更。因为大多数情况下，如果日本某公司要制作一款软件会将其外包首先给日本软件公司。而日本软件公司为了节约成本，会将此项目中的部分模块或某个项目阶段转包给中国的对日软件外包公司。总公司负责接包，然后再将项目发到下面分公司进行最终制造。可想而知这里面一共倒了多少次手了，有的时候甚至到某对日软件外包公司手上的项目已经是三包四包了。项目小点还好说，如果是一个大项目，发包方要和接包方进行频繁的交流，大量的信息经由三四个节点的传输很难说不会变形。
越是大项目需求越不稳定，这是大家都知道的。接包方很难一次性了解清楚所有的需求，何况再倒了几次手。加上设计书的错误或者语句有歧义，接包方项目人员日语不好，最终编码人员对项目的理解和最初发包方的理解不会是完全吻合的。所以就出现了到了项目中后期的时候，已经做出一些成型的模块了，这时候发包方和接包方的交流就会越来越频繁，你问我答，我问你答，大家都极力搞清楚某个东西到底是干什么用的，它到底是不是用户想要的，然后对设计书修了又补，这时就需要不断的修改程序。这时就需要开发人员加强沟通，相互探讨，共同完成。这里引申出了协同开发——这点在现代的软件企业是很重要的一点。
3 加强文档管理
文档在软件项目中的重要性已经是尽人皆知，日本软件业极为重视文档和使用文档，他们把每个细枝末节都要以文档的形式记录，哪怕是一封邮件中的内容也要摘到文档中记录下来。印度软件业的文档化和日本很相似，其软件业的文档也是相当完备的。
日本软件业写文档有一个特点，就是特别偏爱Excel，他们90%以上的文档都是用Excel写的。至于为什么他们偏爱Excel是重说纷纭，我觉得其中最重要的一个原因是Excel可以分很多页，便于管理，而像Word等其他文本都不具备这个优势。日本软件业把Excel运用得出神入化，使用各种各样的宏、各种各样的绘图、各种复杂计算，只要他们想要，他们就能在Excel中做出来，对接包公司的大多数需求都是以Excel给出的。
作为PMA，在项目管理中，需要整理很多文档，比如需求说明、DB设计书、项目模板等等。如果管理不善，会给项目开发带来严重的后果。一般在获取客户的需求后，建立文件夹，把需求原件存起来。等翻译后，把对应的中文需求也保存起来，相关的附件、模板、DB设计书等放在一起。一切整理好后，在发给开发人员，这样便于他们理解。随着项目的跟进，在开发中客户可能修改需求和增加需求，这时PMA要及时把对应的需求给开发人员，以免做无用功或者遗漏需求。一般来说，任何外包软件企业都会采用一些专门管理工具来管理相应的文档，比如我们用CVS来管理代码，用WIKI管理需求，这些都会在任务开发过程中及时更新。在配置管理的相关资料中，详细的阐述了什么是配置管理、配置管理的功能以及如何进行配置管理。
4 严谨测试
严谨测试——这点在日本测试人员身上体现的淋漓尽致。公司在做java（nvmailpoint）项目时，从3月24号交付，几乎天天修改——测试——交付——修改——测试——交付，到目前为止，才完美交付了。
虽然每个任务在交付前，已经根据需求做了测试，为什么存在那么多的bug，有的甚至是很明显的错误？
由于受交货期的压力，开发者在参照设计资料时，细节部分的理解不够仔细。例如：画面数据的显示顺序、间隔、字体显示等；没有完全掌握设计思想的状况下即开始编码，对设计要求的理解容易发生偏差。这些漏洞就需要测试人员为开发人员补充。所以作为测试人员要做到以下几点：
（1）明确自己的责任——尽可能多的发现软件中的bug。
（2）尽可能早的测试，这样会尽早的发现软件中的错误，便于修改，以免造成后期更高的维护成本。
（3）测试前编写完整的测试用例，有计划、有目的的进行测试，尽可能用最少的测试用例，达到最高的测试效率。
（4）不断的执行回归测试。测试人员测试出bug后，等开发人员修改后，要执行回归测试，以免因此次的修改造成其他的Bug。
针对外包软件特殊的测试步骤：
（1）执行本地测试。
所谓的本地：其一是指在的开发环境下进行的测试；其二是指在本地配置的客户的环境下进行的测试。一般完成一个任务后，首先在本地的开发环境下测试，通过后，在虚拟的客户环境下进行测试。最终都通过测试后，做交付包，提交给客户。
（2）执行远程测试。
需要进行远程测试的主要原因——环境问题。虽然公司也安装了客户的环境，但是也不能说完全等同于客户的环境。由于其他原因，比如说编码方式、版本问题、环境差异将导致bug。
参考文献
［1］?张小松，王钰，曹跃.（美）Ron Patton（佩腾）. Software Testing（软件测试）（第2版）［M］.北京:机械工业出版社,2006，（4）.
［2］?林锐.软件配置管理——对软件成果的有效保护［M］.北京:电子工业出版社,2005,(3).
［3］?黄军，刘晓梅，熊勇.软件配置管理及其工具应用［M］.北京:人民邮电出版社,2002,(12).
［4］?My FAQ.高效软件开发团队的特征.网络文章.http://myfaq.com.cn/A200508/2005-08-07/184102.html,2005,(8).
［5］?朱少民.软件测试方法和技术(第1版)［M］.北京:清华大学出版社,2005,(7).
［6］?杨文宏，李新辉.（美）麦格雷戈（JohnD.McGregor）.面向对象的软件测试(第1版)［M］.北京:机械工业出版社,2002,(8).
期刊库（http://www.zgqkk.com），是一个专门从事期刊推广、投稿辅导的网站。
本站提供如何投稿辅导，寻求投稿辅导合作，快速投稿辅导，投稿辅导格式指导等解决方案：省级投稿辅导/国家级投稿辅导/核心期刊投稿辅导//职称投稿辅导。
【免责声明】本文仅代表作者本人观点，与投稿辅导_期刊发表_中国期刊库专业期刊网站无关。投稿辅导_期刊发表_中国期刊库专业期刊网站站对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考，并请自行承担全部责任。
646779424(普刊)
913775405(普刊)
867306987(核心)
271374912(核心)
