试论对日软件offshore开发的效率与质量的保证

1、试论对日软件offshore开发的效率与质量的保证论文导读：我国承接的软件offshore开发主要以日本的软件offshore开发为主。软件质量，试论对日软件offshore开发的效率与质量的保证。关键词：offshore开发，软件质量，离岸offshore开发因为我国临近日本，并且文化背景与日本很相近，在这些得天独厚的条件下，我国承接的软件offshore开发主要以日本的软件offshore开发为主，这就是对日软件offshore开发。目前，软件offshore开发在软件出口中占有很大的比重，尤其是日本对中国的软件offshore开发。论文发表，软件质量。据统计日本对中国的软件offshor

2、e开发比例占70%左右。日本很多大型企业在软件offshore开发业务中，输出到中国的软件offshore开发大大超过印度，平均占83%，有的企业到达95%。但是，在中日软件offshore开发中，存在着很多问题。主要的有以下几条：一、我国软件offshore开发产业目前处于低端地位软件offshore开发的产业特点符合中国目前产业升级和转型的需要，它无污染、低能耗、高附加值并可提供大量就业岗位。虽然这些年我国软件offshore开发看起来确实开展很快，但依然处在一个较低的层次。日本软件offshore开发的承接对象大多数是我国的中小企业。日本的发包工程，都是经过日本外乡的软件效劳商完成整体结

3、构设计后分拆出来的，我国大多数企业只是从事对日软件offshore开发效劳当中的编码、测试等低端效劳。这局部业务技术含量低，不可能形成有竞争力的技术积累。从事软件效劳的企业一般被认为是知识型员工为主的企业，完成工程需要很大智力投入。论文发表，软件质量。目前，IT工作投入的智力分两类，一类是提供一套完善的信息效劳系统，称之为系统解决方案，做的是软件行业的高端效劳；另一类是只做整体方案中的程序编码、测试及代码维护这局部，即按设计制作产品;局部，做的是软件行业的低端。软件offshore开发，尤其是对日软件offshore开发企业多为是后者。因此，业界有对软件offshore开发的技术人员称为白领工

4、人;或高级蓝领;的说法。二、本钱持续上升，金融危机和币制升值2006年下半年开始人民币缓慢升值，对日元汇率也出现了频繁变化，使得近两年对日软件的营业收入也变得难以控制。软件offshore开发低端业务接包的价格在行业内根本标准差不多，不会随着汇率的变化而浮动，人民币的升值使本来利润空间就比拟小的软件offshore开发更加雪上加霜。加上近期金融危机对日本经济的冲击，企业为了降低本钱，首先削减的是对生产起辅助作用的软件信，鼠系统开支，给中国的对日软件接包商带来了较大的影响。三、人才频繁流动2021年起执行的新?劳动法?对劳动密集型企业的弱势群体起到了有效的保护作用，对那些肆意榨取农民工血汗的制造

5、业雇主，有了强有力的约束。但是，对于原本比拟守法的软件offshore开发业经营者，却带来了负面影响。在软件企业中人工本钱是第一大支出，特别是单纯做offshore开发的企业，销售本钱很低，8090%都是人力资源本钱。人力资源的社会保障本钱也会随薪资而高，新?劳动法?对劳动者加大保护力度，除了提高原本已经较高的福利保障，还给员工的离职自由以更宽松的政策。稀缺性使有几年经验的员工频频跳槽，企业无奈只能放行，不少软件offshore开发企业的老板叹息：在劳动者面前我们才是弱势。;四、高端复合型人才短缺无论经营现状处于软件offshore开发的哪个层次，大家都已经意识到，只有尽量提升效劳offsho

6、re开发效劳的层次，从接受个别业务的offshore开发到参加对方的生产流程中，从低知识含量的offshore开发到高知识含量的offshore开发，才能真正得到高附加值、高利润的回报。但同时软件offshore开发经理人又都知道，中国offshore开发企业当前开展最大的困惑，是软件offshore开发的高端人才严重缺乏。缺少这样的人才很难提升软件offshore开发效劳层次，很难实现从低端offshore开发到高端offshore开发的跨越。对日高端软件人才是一种复合型人才，在企业中最起码的职位是软件工程经理。高端人才除具有良好外语能力和技术水平，还要求他们具有一定的管理能力和业务流程的理

7、解能力，这样的人才很难找。人才的培训总是滞后市场需求。近几年在政府、行业协会的推动下，对日软件工程师;培训大有泛滥之势。其实，虽经培训，但没有实际工作经验的新手，少至半年多那么一年，才能成为一个合格的白领工人;，离软件offshore开发所需的高端人才相距甚远。一个软件工程类毕业生，至少要在软件工程制作过程中磨练35年，这期间除了需要将学校扎实的根底知识，转变成软件开发的实际能力，还要到达相当日语水平最好到达一级日语能力后，通过派遣到日本当地企业工作，熟悉日本文化、思维方式、企业管理方法等，再经过参与假设干软件工程管理的摸爬滚打，才能成长为一名合格的软件工程经理。一个软件企业高端人才的多少，决

8、定了它能承接的工程技术含量的上下、规模的大小和数量的多少。行业内复合型人才短缺，缺少优秀的软件工程管理者，软件offshore开发的同质化;，使企业对人才的要求也几乎相同。高薪争聘有经验的软件offshore开发工程师，使得不少企业人员流动超过20%，非常不利于企业的成长，严重影响软件offshore开发层次的提升，这不是一个企业的问题，已是一个行业的普遍问题。关于以上问题，对于化解方法有以下的几点思考一、人才支持政策进一步宽松按照商务部等有关部门的规划目标，2021至2021年力争在国内建成一批产业聚集、并具有一定国际竞争力的效劳offshore开发基地；促进200家著名跨国公司将效劳off

9、shore开发业务转移到中国；培育2000家取得国际资质的大中型效劳offshore开发企业；培训120万承接效劳offshore开发所需实用人才；新增100万大学毕业生就业。到2021年，实现承接国际效劳offshore开发业务300亿美元，比2021年增长4倍多。为了保障规划目标的实现，最近，国家对效劳offshore开发进一步推出了税收优惠、资金支持、人才培训、特殊劳开工时等一系列支持政策，软件offshore开发产值未来5年内将会持续不断地快速增长。如果能给知识型企业在员工的企业社会保障支付方面有一定的灵活性，对削减这些高薪;企业本钱支出将是最有效的支持，同时员工收入并不会改变，不会触

10、发人才流失。二、学校企业紧密合作，提高人才培养的效率按人员的智力常规看，语言能力和管理能力强的人，往往技术能力比拟薄弱；反之，技术能力强的人，语言及沟通表达能力会弱一些。论文发表，软件质量。但对日软件高端人才，恰恰需要两方面都强的复合人才。论文发表，软件质量。对缩短复合人才的培养时间，高校教育与企业实践的互补有一定的作用。必须强化在校生软件专业的外语教育，包括根底外语和专业外语；必须和重要的外资企业挂钩，为学生提供实习基地，借此减少他们进入企业后的语言和技术培训时间，以最快的速度走上岗位，从一般的白领工人;中脱颖而出，迈入高端复合人才的队伍。在这方面，很多软件学院已做出了积极有效的探索。提升软

11、件offshore开发效劳的层次，扩大产业规模，将中国制造;变到中国智造;，如果不解决好人才的质量问题，一切就只能是我们的良好愿望。三、效劳offshore开发人民币结算今年4月，国家在上海市和广东省内四城市开展跨境贸易人民币结算试点。这项政策如能在对日软件offshore开发效劳企业中实现，当然是非常利好的消息。但真正实行起来恐怕不那么容易。以往对日软件offshore开发都是以日元结算的，每笔业务是以所需消耗的人日或人月数来计量的。如果用人民币定义每人月数的价格，作为发包方的日本客户是否会同意?目前也只有在中日双方合作非常紧密甚至有技术依赖关系的企业之间，可能将这个问题提上议事日程。但随着

12、人民币国际化程度的不断加大，软件offshore开发企业利用人民币结算将会越来越多，人民币结算政策将会改变软件offshore开发业的被动局面。这一政策在首先上海等地试水，上海软件接包商可以利用这一优势向总承包方向开展，软件offshore开发在国内也应按一、二、三线城市拉开梯次，人才流动的方向也就会随之拉开梯次。中国效劳offshore开发企业利用不同币种结算方式来保护自身利益将会变得更加灵活。四、培育良性产业链，扶持不同层次的软件offshore开发企业软件企业开展道路是多样化的，企业生存方式也各有所长。因此，软件offshore开发领域不管是重新洗牌、整合联盟、单纯效劳offshore开

13、发还是整体解决方案，永远会有上上下下分分合合与生生灭灭。中国是当前世界上唯一同时具有国内市场、区域市场和国际市场的软件接包地，软件offshore开发链条上也总是有高、中、低端业务之分工，这就需要我们既能培育出与世界顶级企业规模相媲美的大型企业，又要扶持好起步创业阶段的小企业。国家和各级地方政府只有根据本地区软件企业情况，给予不同程度的支持，才能更好地推动和开展我们具有中国特色的软件offshore开发;事业。据最新行业年度开展报告称，目前中国软件offshore开发企业达3600多家，存在形式和开展道路是多样化的。近几年软件offshore开发圈内常有有识之士提到行业的兼并和重新洗牌问题，以

14、便有效地整合行业优势资源，优化产品结构，推进品牌的国际化战略。其实一个行业也有其生态链条，做大做强固然好，但中小企业也是行业开展的生力军。培育良好的软件offshore开发产业链，是各级政府应该注重的工作。尤其第三类软件企业，因为不属国家政策的支持范围，生存压力很大。但它们是软件offshore开发产业链中必要的一环，开展offshore开发效劳的地方政府，应该给这局部接受国内大城市软件offshore开发业务的公司一定的扶持政策，使他们能够在软件offshore开发的产业链中，保持和不断提高与上游发包商的衔接实力，培育出本地真正意义上的软件offshore开发产业。只有宏观的策略是远远不够的

15、，要想提高对日软件offshore开发的效率并保证质量，还应提高开发人员的素质，下面浅论一下对开发人员的改善建议：一、加强语言功底开发人员对委托方提供的设计资料的理解程度直接影响着开发进度和质量。从过去的产品质量数据分析结果来看，对设计资料的理解错误是产生质量问题的主要原因。论文发表，软件质量。特别是对设计资料的理解错误，如果不从一开始就采取措施进行预防，对程序本身及其他程序的质量将可能产生较大的影响。针对这一点，系统开发部开展了以预防/消除设计资料理解错误;为主题的质量控制QC活动。随着活动开展的深入，质量控制逐渐取得了明显的成效。这一活动的首要任务就是学习语言。二、加强沟通对日软件offs

16、hore开发通常是不会offshore开发需求、分析和设计阶段的。这样造成接包方和发包方对需求、分析和设计在理解上的分歧，从而导致设计或编码的不断变更。需求和设计的不稳定是软件业的通病，是软件业最让人头疼的顽疾。有人说有一个软件领域的需求就非常稳定，可以在设计完成之后就不再变化，这就是离岸软件offshore开发。至少针对日软件offshore开发，在我看来这是大错特错的。公司在做HCHeart Core工程时，客户前后的设计说明书就变更了7个版本，仅需求理解就花费了20天时间，而开发和测试时间却不到10天。日本软件业的需求和设计文档相当标准，但这并不代表它们不会变更。因为大多数情况下，如果日

17、本某公司要制作一款软件会将其offshore开发首先给日本软件公司。而日本软件公司为了节约本钱，会将此工程中的局部模块或某个工程阶段转包给中国的对日软件offshore开发公司。总公司负责接包，然后再将工程发到下面分公司进行最终制造。可想而知这里面一共倒了多少次手了，有的时候甚至到某对日软件offshore开发公司手上的工程已经是三包四包了。工程小点还好说，如果是一个大工程，发包方要和接包方进行频繁的交流，大量的信息经由三四个节点的传输很难说不会变形。越是大工程需求越不稳定，这是大家都知道的。接包方很难一次性了解清楚所有的需求，何况再倒了几次手。论文发表，软件质量。加上设计书的错误或者语句有歧

18、义，接包方工程人员日语不好，最终编码人员对工程的理解和最初发包方的理解不会是完全吻合的。所以就出现了到了工程中后期的时候，已经做出一些成型的模块了，这时候发包方和接包方的交流就会越来越频繁，你问我答，我问你答，大家都竭力搞清楚某个东西到底是干什么用的，它到底是不是用户想要的，然后对设计书修了又补，这时就需要不断的修改程序。这时就需要开发人员加强沟通，相互探讨，共同完成。这里引申出了协同开发这点在现代的软件企业是很重要的一点。三、加强文档管理文档在软件工程中的重要性已经是尽人皆知，日本软件业极为重视文档和使用文档，他们把每个细枝末节都要以文档的形式记录，哪怕是一封邮件中的内容也要摘到文档中记录下

19、来。印度软件业的文档化和日本很相似，其软件业的文档也是相当完备的。日本软件业写文档有一个特点，就是特别偏爱Excel，他们90%以上的文档都是用Excel写的。至于为什么他们偏爱Excel是重说纷纭，我觉得其中最重要的一个原因是Excel可以分很多页，便于管理，而像Word等其他文本都不具备这个优势。日本软件业把Excel运用得出神入化，使用各种各样的宏、各种各样的绘图、各种复杂计算，只要他们想要，他们就能在Excel中做出来，对接包公司的大多数需求都是以Excel给出的。作为PMA，在工程管理中，需要整理很多文档，比方需求说明、DB设计书、工程模板等等。如果管理不善，会给工程开发带来严重的后

20、果。一般在获取客户的需求后，建立文件夹，把需求原件存起来。等翻译后，把对应的中文需求也保存起来，相关的附件、模板、DB设计书等放在一起。一切整理好后，在发给开发人员，这样便于他们理解。随着工程的跟进，在开发中客户可能修改需求和增加需求，这时PMA要及时把对应的需求给开发人员，以免做无用功或者遗漏需求。一般来说，任何offshore开发软件企业都会采用一些专门管理工具来管理相应的文档，比方我们用CVS来管理代码，用WIKI管理需求，这些都会在任务开发过程中及时更新。在配置管理的相关资料中，详细的阐述了什么是配置管理、配置管理的功能以及如何进行配置管理。四、严谨测试严谨测试这点在日本测试人员身上表达的淋漓尽致。公司在做java工程时，从3月24号交付，几乎天天修改测试交付修改测试交付，到目前为止，才完美交付了。虽然每个任务在交付前，已经根据需求做了测试，为什么存在那么多的bug，有的甚至是很明显的错误？由于受交货期的压力，开发者在参照设计资料时，细节局部的理解不够仔细。例如：画面数据的显示顺序、间隔、字体显示等；没有完全掌握设计思想的状况下即开始编码，对设计要求的理解容易发生偏差。这些漏洞就需要测试人