關于對日軟件外包開發質量探討
論文關鍵詞：對日軟件外包；軟件質量；方法研究
論文摘 要：對日軟件外包是目前在國內發展迅速的一個行業，但是由于國界、地域、、習俗等差異，導致了對日軟件外包的質量得不到保證。通過研究和實踐，結合所學的知識，探討如何保證對日軟件外包的質量。
目前，軟件外包在軟件出口中占有很大的比重，尤其是日本對中國的軟件外包。據日本對中國的軟件外包比例占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).
【對日軟件外包開發質量探討】相關文章：
給排水專業ＣＡＤ軟件開發方法探討03-18
探索外包項目開發的管理12-10
對軟件項目管理的探討03-22
質量本錢探討02-27
質量成本探討03-21
有關收益質量的探討03-22
軟件的復用技術及開發方法03-29
中國旅游商品開發探討03-07
旅游度假區的開發模式探討11-23