- 相關(guān)推薦
關(guān)于對日軟件外包開發(fā)質(zhì)量探討
論文關(guān)鍵詞：對日軟件外包；軟件質(zhì)量；方法研究
論文摘 要：對日軟件外包是目前在國內(nèi)發(fā)展迅速的一個行業(yè)，但是由于國界、地域、、習(xí)俗等差異，導(dǎo)致了對日軟件外包的質(zhì)量得不到保證。通過研究和實踐，結(jié)合所學(xué)的知識，探討如何保證對日軟件外包的質(zhì)量。
目前，軟件外包在軟件出口中占有很大的比重，尤其是日本對中國的軟件外包。據(jù)日本對中國的軟件外包比例占70%左右。日本很多大型企業(yè)在軟件外包業(yè)務(wù)中，輸出到中國的軟件外包大大超過印度，平均占83%，有的企業(yè)達到95%。但是，在中日軟件外包中，存在的最大問題是質(zhì)量問題。引起質(zhì)量問題的原因很多，最主要的是：中日雙方的企業(yè)、模式的差異，還有開發(fā)過程、溝通方式、開發(fā)標準和文檔格式不統(tǒng)一等問題。
1 加強語言功底
開發(fā)人員對委托方提供的設(shè)計資料的理解程度直接影響著開發(fā)進度和質(zhì)量。從過去的產(chǎn)品質(zhì)量數(shù)據(jù)分析結(jié)果來看，對設(shè)計資料的理解錯誤是產(chǎn)生質(zhì)量問題的主要原因。特別是對設(shè)計資料的理解錯誤，如果不從一開始就采取措施進行，對程序本身及其他程序的質(zhì)量將可能產(chǎn)生較大的影響。針對這一點，系統(tǒng)開發(fā)部開展了以“預(yù)防/消除設(shè)計資料理解錯誤”為主題的質(zhì)量控制（QC）活動。隨著活動開展的深入，質(zhì)量控制逐漸取得了明顯的成效。這一活動的首要任務(wù)就是學(xué)習(xí)語言。
2 加強溝通
對日軟件外包通常是不會外包需求、分析和設(shè)計階段的。這樣造成接包方和發(fā)包方對需求、分析和設(shè)計在理解上的分歧，從而導(dǎo)致設(shè)計或編碼的不斷變更。需求和設(shè)計的不穩(wěn)定是軟件業(yè)的通病，是軟件業(yè)最讓人頭疼的頑疾。有人說有一個軟件領(lǐng)域的需求就非常穩(wěn)定，可以在設(shè)計完成之后就不再變化，這就是離岸軟件外包。至少針對日軟件外包，在我看來這是大錯特錯的。公司在做HC（HeartCore）項目時，客戶前后的設(shè)計說明書就變更了7個版本，僅需求理解就花費了20天時間，而開發(fā)和測試時間卻不到10天。日本軟件業(yè)的需求和設(shè)計文檔相當規(guī)范，但這并不代表它們不會變更。因為大多數(shù)情況下，如果日本某公司要制作一款軟件會將其外包首先給日本軟件公司。而日本軟件公司為了節(jié)約，會將此項目中的部分模塊或某個項目階段轉(zhuǎn)包給中國的對日軟件外包公司。總公司負責(zé)接包，然后再將項目發(fā)到下面分公司進行最終制造。可想而知這里面一共倒了多少次手了，有的時候甚至到某對日軟件外包公司手上的項目已經(jīng)是三包四包了。項目小點還好說，如果是一個大項目，發(fā)包方要和接包方進行頻繁的交流，大量的信息經(jīng)由三四個節(jié)點的傳輸很難說不會變形。
越是大項目需求越不穩(wěn)定，這是大家都知道的。接包方很難一次性了解清楚所有的需求，何況再倒了幾次手。加上設(shè)計書的錯誤或者語句有歧義，接包方項目人員日語不好，最終編碼人員對項目的理解和最初發(fā)包方的理解不會是完全吻合的。所以就出現(xiàn)了到了項目中后期的時候，已經(jīng)做出一些成型的模塊了，這時候發(fā)包方和接包方的交流就會越來越頻繁，你問我答，我問你答，大家都極力搞清楚某個東西到底是干什么用的，它到底是不是用戶想要的，然后對設(shè)計書修了又補，這時就需要不斷的修改程序。這時就需要開發(fā)人員加強溝通，相互探討，共同完成。這里引申出了協(xié)同開發(fā)——這點在現(xiàn)代的軟件企業(yè)是很重要的一點。
3 加強文檔管理
文檔在軟件項目中的重要性已經(jīng)是盡人皆知，日本軟件業(yè)極為重視文檔和使用文檔，他們把每個細枝末節(jié)都要以文檔的形式記錄，哪怕是一封郵件中的內(nèi)容也要摘到文檔中記錄下來。印度軟件業(yè)的文檔化和日本很相似，其軟件業(yè)的文檔也是相當完備的。
日本軟件業(yè)寫文檔有一個特點，就是特別偏愛Excel，他們90%以上的文檔都是用Excel寫的。至于為什么他們偏愛Excel是重說紛紜，我覺得其中最重要的一個原因是Excel可以分很多頁，便于管理，而像Word等其他文本都不具備這個優(yōu)勢。日本軟件業(yè)把Excel運用得出神入化，使用各種各樣的宏、各種各樣的繪圖、各種復(fù)雜計算，只要他們想要，他們就能在Excel中做出來，對接包公司的大多數(shù)需求都是以Excel給出的。
作為PMA，在項目中，需要整理很多文檔，比如需求說明、DB設(shè)計書、項目模板等等。如果管理不善，會給項目開發(fā)帶來嚴重的后果。一般在獲取客戶的需求后，建立文件夾，把需求原件存起來。等后，把對應(yīng)的中文需求也保存起來，相關(guān)的附件、模板、DB設(shè)計書等放在一起。一切整理好后，在發(fā)給開發(fā)人員，這樣便于他們理解。隨著項目的跟進，在開發(fā)中客戶可能修改需求和增加需求，這時PMA要及時把對應(yīng)的需求給開發(fā)人員，以免做無用功或者遺漏需求。一般來說，任何外包軟件企業(yè)都會采用一些專門管理工具來管理相應(yīng)的文檔，比如我們用CVS來管理代碼，用WIKI管理需求，這些都會在任務(wù)開發(fā)過程中及時更新。在配置管理的相關(guān)資料中，詳細的闡述了什么是配置管理、配置管理的功能以及如何進行配置管理。
4 嚴謹測試
嚴謹測試——這點在日本測試人員身上體現(xiàn)的淋漓盡致。公司在做java（nvmailpoint）項目時，從3月24號交付，幾乎天天修改——測試——交付——修改——測試——交付，到目前為止，才完美交付了。
雖然每個任務(wù)在交付前，已經(jīng)根據(jù)需求做了測試，為什么存在那么多的bug，有的甚至是很明顯的錯誤？
由于受交貨期的壓力，開發(fā)者在參照設(shè)計資料時，細節(jié)部分的理解不夠仔細。例如：畫面數(shù)據(jù)的顯示順序、間隔、字體顯示等；沒有完全掌握設(shè)計思想的狀況下即開始編碼，對設(shè)計要求的理解容易發(fā)生偏差。這些漏洞就需要測試人員為開發(fā)人員補充。所以作為測試人員要做到以下幾點：
（1）明確自己的責(zé)任——盡可能多的發(fā)現(xiàn)軟件中的bug。
（2）盡可能早的測試，這樣會盡早的發(fā)現(xiàn)軟件中的錯誤，便于修改，以免造成后期更高的維護。
（3）測試前編寫完整的測試用例，有計劃、有目的的進行測試，盡可能用最少的測試用例，達到最高的測試效率。
（4）不斷的執(zhí)行回歸測試。測試人員測試出bug后，等開發(fā)人員修改后，要執(zhí)行回歸測試，以免因此次的修改造成其他的Bug。
針對外包軟件特殊的測試步驟：
（1）執(zhí)行本地測試。
所謂的本地：其一是指在的開發(fā)下進行的測試；其二是指在本地配置的客戶的環(huán)境下進行的測試。一般完成一個任務(wù)后，首先在本地的開發(fā)環(huán)境下測試，通過后，在虛擬的客戶環(huán)境下進行測試。最終都通過測試后，做交付包，提交給客戶。
（2）執(zhí)行遠程測試。
需要進行遠程測試的主要原因——環(huán)境問題。雖然公司也安裝了客戶的環(huán)境，但是也不能說完全等同于客戶的環(huán)境。由于其他原因，比如說編碼方式、版本問題、環(huán)境差異將導(dǎo)致bug。
參考文獻
［1］?張小松，王鈺，曹躍.（美）Ron Patton（佩騰）. Software Testing（軟件測試）（第2版）［M］.北京:出版社,2006，（4）.
［2］?林銳.軟件配置管理——對軟件成果的有效保護［M］.北京:工業(yè)出版社,2005,(3).
［3］?黃軍，劉曉梅，熊勇.軟件配置管理及其工具應(yīng)用［M］.北京:人民郵電出版社,2002,(12).
［4］?My FAQ.高效軟件開發(fā)團隊的特征.網(wǎng)絡(luò)文章.http://myfaq.com.cn/A200508/2005-08-07/184102.html,2005,(8).
［5］?朱少民.軟件測試方法和技術(shù)(第1版)［M］.北京:清華大學(xué)出版社,2005,(7).
［6］?楊文宏，李新輝.（美）麥格雷戈（JohnD.McGregor）.面向?qū)ο蟮能浖䴗y試(第1版)［M］.北京:機械工業(yè)出版社,2002,(8).
【對日軟件外包開發(fā)質(zhì)量探討】相關(guān)文章：
寧波佛教旅游資源開發(fā)探討05-30
游戲軟件開發(fā)VC++05-13
醫(yī)院檔案開發(fā)利用常見問題處理方式的探討05-15
探討工程質(zhì)量通病發(fā)生的原因和預(yù)防措施03-22
軟件開發(fā)風(fēng)險及控制措施（通用6篇）05-12
淺談軟件開發(fā)項目的成本控制論文04-18
城市GPS控制網(wǎng)施測質(zhì)量控制措施探討05-28
控制稅收征管成本的探討06-01