對日軟件外包(精)

第1章對日軟件外包對日軟件外包的發(fā)展全球應用軟件外包市場近幾年平均每年以 29%的速度增長，2005年整個市場規(guī)模將達到389億美元。目前全球的軟件產(chǎn)值中，三分之一需要通過對外發(fā)包來完成。軟件外包已經(jīng)成為世界軟件產(chǎn)業(yè)發(fā)展的一個重要趨勢。在這一趨勢下 ，《振興軟件產(chǎn)業(yè)行動綱要》提出，從2001年到2005年，中國軟件出口要從年出口7億美元提升到50億美元。按照預定的目標,2004年國內(nèi)軟件企業(yè)將要完成的出口額將達到35億美元。這對于中國軟件企業(yè)而言的確是個不小的數(shù)字。為了實現(xiàn)這一目標 ，有關人士指出，中國企業(yè)應積極拓展對歐美軟件外包業(yè)務，把軟件外包做強做大。但現(xiàn)在美國市場主要被印度壟斷，歐洲市場被愛爾蘭壟斷，中國企業(yè)的核心競爭力需要較長時間的積累，而對日軟件外包，我們則有優(yōu)勢。在對美軟件外包市場上，中國軟件企業(yè)與印度軟件企業(yè)的差距是明顯的，從英文水平到簽證難度，從法制制度的不同到對知識產(chǎn)權認識程度的差異，中國軟件企業(yè)要在對美軟件外包市場趕上印度企業(yè)還需加以時日。美國IT從業(yè)人員中印度和中國人員的比例是 3：1,中國軟件企業(yè)目前做的外包只占日本軟件外包的2%多一點。以英文為主導的軟件外包市場正在逐漸萎縮，并且在這個市場上我們和印度相比競爭優(yōu)勢不明顯。而對日軟件外包市場相對印度來說，中國軟件企業(yè)有地域優(yōu)勢和有限的語言優(yōu)勢，應當成為國內(nèi)軟件外包企業(yè)的發(fā)展導向。對日軟件外包的現(xiàn)狀對日外包市場潛力巨大，據(jù)IDC統(tǒng)計數(shù)據(jù),2005年日本IT外包市場規(guī)模為164億美元，而同年我國來自日本的軟件發(fā)包量約為5.6億美元，僅占日本IT外包市場的4%。IDC預測2008年日本IT外包市場將達到23,363億日元（約226億美元,2010年我國對日外包將近40億美元，占比上升為17.7%。由此可見我國對日軟件外包未來的市場潛力巨大。國內(nèi)現(xiàn)有的對日軟件外包企業(yè)，主要為面向日本資訊科技行業(yè)的客戶提供外包軟件開發(fā)服務，而該等客戶其本身又是為日本客戶或全球客戶提供軟件開發(fā)服務。也就是一種工程轉包性質的開發(fā)。以我現(xiàn)在所在公司為例，從事過制造業(yè)項目、CAD軟件工具、證券金融軟件、物流軟件等等。對日軟件外包的軟件開發(fā)特點由于外包客戶也是多為軟件公司或是大公司的軟件開發(fā)部分，而且由于是外包軟件開發(fā)，所以開發(fā)層次比較低，或者說不是一個完整意思上的軟件開發(fā)過程。根據(jù)個人在對日軟件開發(fā)公司工作多年的經(jīng)驗，總結以下幾點特點：技術含量低，從事低層次工作。通常，軟件開發(fā)過程都要經(jīng)歷商業(yè)建模、需求分析、系統(tǒng)分析和設計、實現(xiàn)、測試和部署等核心流程。然而，對日外包的開發(fā)流程被嚴格劃分開來的，外包客戶從事商業(yè)建模、需求分析、系統(tǒng)分析和設計等高層次的工作，然后將設計書發(fā)包到國內(nèi),而國內(nèi)公司僅僅只是嚴格依據(jù)客戶的設計書，將其代碼實現(xiàn)并通過單體測試就算完工。所以，國內(nèi)對日外包企業(yè)只是擔當了實現(xiàn)、測試兩個階段的任務。也有個別項目會擔當些簡單的設計任務。工期短工作量大由于國內(nèi)勞動力相對日本國內(nèi)廉價許多，許多日本IT企業(yè)將開發(fā)和測試環(huán)節(jié)移到中國國內(nèi)，根據(jù)客戶的功能設計書或詳細設計書，完成開發(fā)及測試。這樣即可以降低軟件開發(fā)成本，又不至于有太大的開發(fā)風險，因為設計是日本人自己完成的。但是，時常會發(fā)生因為客戶的設計不合理或不詳細或理解不同等等客觀原因 ，無法按照原來合同中規(guī)定的工數(shù)完成任務，所以常常要靠加班來爭取時間。品質要求咼誰都想花錢買到好東西，軟件外包也是一樣，日本公司也想花錢買到更好的客戶，具體體現(xiàn)就是提供優(yōu)質的代碼成果物。然而，由于軟件企業(yè)的流動性比較大，公司出于成本考慮，常會雇傭一些經(jīng)驗不足的實習人員直接投入項目開發(fā)中，導致品質較低,而為了彌補品質上問題，又需要用加班的方式來爭取大量時間提高質量。文檔要求高有些日本客戶公司，實施了CMM3或更高級別的控制標準,同樣也要求中國的外包公司按照其標準實施，當然這樣對于國內(nèi)公司自身管理能力也是一種提高。但是有些客戶公司過于注重文檔，而忽視了對于最更本的代碼的重視程度。第2章RUPRUP是Rational統(tǒng)一過程（RationalUnifiedProcess的簡稱，它是Rational公司（現(xiàn)歸屬IBM公司推出的一種軟件過程產(chǎn)品。從軟件過程模式角度看 ，RUP又是一種典型的軟件過程模式，它以迭代增量式、架構為中心、用例驅動的軟件開發(fā)方法、采用UML語言描述軟件開發(fā)過程為主要特征，其中以用例驅動乃是貫穿軟件開發(fā)始終的方法。2.1RUP的特點迭代式開發(fā)。在軟件開發(fā)的前期階段完全并準確的掌握用戶全部的需求幾乎是不可能的。實際上，經(jīng)常遇到，需求在整個軟件開發(fā)工程中會不斷改變，從而使得軟件項目難于管理而產(chǎn)生較大風險。而迭代的開發(fā)方式允許在每次迭代過程中需求有所變化，通過不斷細化來加深對問題的理解，最終實現(xiàn)完全滿足用戶需求的軟件。迭代式開發(fā)不僅可以降低項目的風險，而且使得軟件開發(fā)過程具備較強的控制性。管理需求。完善用戶需求是一個漸進的過程，開發(fā)人員在開發(fā)系統(tǒng)之初不可能完全詳細的說明一個系統(tǒng)的真正需求。RUP描述了如何提取、組織系統(tǒng)的功能和約束條件并將其文檔化，用例和腳本的使用以被證明是捕獲功能性需求的有效方法?；诮M件的體系結構。組件使重用成為可能，系統(tǒng)可以由組件組成?；讵毩⒌摹⒖商鎿Q的、模塊化組件的體系結構有助于管理復雜性，提高重用率。RUP描述了如何設計一個有彈性的、能適應變化的、易于理解的、有助于重用的軟件體系結構?？梢暬！UP和UML結合在一起，對軟件系統(tǒng)建立可視化模型幫助人們提供管理軟件復雜性的能力。RUP告訴我們?nèi)绾慰梢暬膶浖到y(tǒng)建模，獲取有關體系結構于組件的結構和行為信息。驗證軟件質量。在RUP中軟件質量評估不再是事后進行或單獨小組進行的分離活動，而是內(nèi)建于過程中的所有活動，這樣可以及早發(fā)現(xiàn)軟件中的缺陷?？刂栖浖兏?。迭代式開發(fā)中如果沒有嚴格的控制和協(xié)調(diào)，整個軟件開發(fā)過程很快就陷入混亂之中,RUP描述了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。 RUP通過軟件開發(fā)過程中的制品，隔離來自其他工作空間的變更，以此為每個開發(fā)人員建立安全的工作空間。2.2RUP的核心工作流RUP中有9個核心工作流,分為6個核心過程工作流（CoreProcessWorkflows和3個核心支持工作流（CoreSupportingWorkflows。盡管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用，在每一次迭代中以不同的重點和強度重復。商業(yè)建模（BusinessModeling描述了如何為新的目標組織開發(fā)一個構想，并基于這個構想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程，角色和責任。需求（Requirements描述系統(tǒng)應該做什么，并使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標，要對需要的功能和約束進行提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。分析和設計（Analysis&Design將需求轉化成未來系統(tǒng)的設計，為系統(tǒng)開發(fā)一個健壯的結構并調(diào)整設計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計活動以體系結構設計為中心，體系結構由若干結構視圖來表達，結構視圖是整個設計的抽象和簡化。實現(xiàn)（Implementation包括以層次化的子系統(tǒng)形式定義代碼的組織結構；以組件的形式（源文件、二進制文件、可執(zhí)行文件實現(xiàn)類和對象；將開發(fā)出的組件作為單元進行測試以及集成由單個開發(fā)者（或小組所產(chǎn)生的結果，使其成為可執(zhí)行的系統(tǒng)。測試（Test驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現(xiàn)，識別并確認缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法，意味著在整個項目中進行測試，從而盡可能早地發(fā)現(xiàn)缺陷，從根本上降低了修改缺陷的成本。部署（Deployment成功的生成版本并將軟件分發(fā)給最終用戶。描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關的活動，包括:軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。配置和變更管理（Configuration&ChangeManagement描繪了如何在多個成員組成的項目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產(chǎn)品修改原因、時間、人員保持審計記錄。項目管理（ProjectManagement平衡各種可能產(chǎn)生沖突的目標，管理風險，克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標包括：為項目的管理提供框架，為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實用的準則，為管理風險提供框架等。環(huán)境（Environment環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐步的指導手冊并介紹了如何在組織中實現(xiàn)過程。RUP裁剪步驟RUP是一個通用的過程模板，包含了很多開發(fā)指南、制品、開發(fā)過程所涉及到的角色說明，由于它非常龐大所以對具體的開發(fā)機構和項目，用RUP時還要做裁剪，也就是要對RUP進行配置。RUP就像一個元過程，通過對RUP進行裁剪可以得到很多不同的開發(fā)過程，這些軟件開發(fā)過程可以看作RUP的具體實例。RUP裁剪可以分為以下幾步：1確定本項目需要哪些工作流。RUP的9個核心工作流并不總是需要的，可以取舍。確定每個工作流需要哪些制品。確定4個階段之間如何演進。確定階段間演進要以風險控制為原則 ，決定每個階段要那些工作流，每個工作流執(zhí)行到什么程度，制品有那些，每個制品完成到什么程度。確定每個階段內(nèi)的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內(nèi)規(guī)劃工作流內(nèi)部結構。工作流涉及角色、活動及制品，他的復雜程度與項目規(guī)模即角色多少有關。最后規(guī)劃工作流的內(nèi)部結構，通常用活動圖的形式給出。第3章改進方案雖然，對日軟件外包工程往往不是一個完整的軟件開發(fā)過程，只是其中一部分或幾部分而已，但是并不妨礙RUP在對日外包項目中發(fā)揮強大的作用。上一章節(jié)中，分析了如何根絕具體項目特性對RUP過程進行裁剪，以適應不同的軟件項目。本章節(jié)將依據(jù)裁剪步驟，結合現(xiàn)在公司的項目特點，細化制定適當?shù)腞UP開發(fā)過程。.1確定工作流對日軟件外包，通常是根據(jù)客戶的功能需求書或詳細設計書，完成代碼實現(xiàn)和測試。所以只需要實現(xiàn)和測試兩個工作流。結合我公司現(xiàn)在從事項目的特點 ，簡單闡述一下各工作流。實現(xiàn)由于對日外包的特殊性，面對客戶基本都是日本的IT企業(yè),現(xiàn)階段都處于較低層次，也就是只負責代碼實現(xiàn)和測試，可能也會從事部分簡單設計。所以，根據(jù)客戶的設計書完成符合要求的代碼就是對日外包的主要工作任務。所以實現(xiàn)工作流也是最重要的工作流。而且，由于是根據(jù)日方的設計從事開發(fā)實現(xiàn)，所以除了實現(xiàn)本身的任務外，還有承前的工作要完成，比如:理解設計書的要求，開發(fā)環(huán)境搭建，判斷設計中可能存在的不合理性等。而這些問題都可能直接影響到最后是否能順利完成實現(xiàn)的工作任務。測試判斷開發(fā)的代碼是否能交付，也就是依靠測試用例了，我方只擔任單體測試部分的任務，并將全部通過測試的代碼和測試用例書作為成果物交付給日方。如果 ，由于單體測試內(nèi)容不全面，而在結合測試中發(fā)現(xiàn)的問題，將作為Bug報告，再由擔當者修正后提交。以上講的兩個工作流，是現(xiàn)在多數(shù)對日外包公司承擔的主要任務，當然也有部分公司可能承接的項目是個完整的軟件過程，涉及到9個工作流中的絕大多數(shù)，在此不作重點依次展開。其實各個項目，由自身特點可以制定出自己的RUP軟件過程。只要實用就是最好。3.2各工作流的職責和制品由于是委托開發(fā)，客戶為了有效控制開發(fā)過程和質量，往往是通過各種文檔來對項目進行管理和控制。對日外包開發(fā)中，文檔的分類比較繁多，規(guī)格要求也根據(jù)不同公司有不同的 要求。以下列舉幾種文檔，在整個開發(fā)過程中起俄作用：1.功能設計書用戶提出委托開發(fā)要求，中方根據(jù)功能設計書，了解所開發(fā)項目的所有需求，并估計工數(shù)和項目報價，如果對方客戶對報價沒有異議，就正常進入開發(fā)實施階段。開發(fā)小組成員開始一起研究功能設計，解決理解和實現(xiàn)技術上的所有問題，盡可能避免因設計書理解不足，導致項目失敗。2.詳細設計書結合實現(xiàn)技術的特點，通常，客戶是不提供詳細設計書，而是開發(fā)團隊根據(jù)功能設計書，完成詳細設計書，作為實現(xiàn)工作流的前期成果物，交付日方Review確認，只有通過Review后才能進入到正式的開發(fā)實現(xiàn)階段。代碼規(guī)約為加強代碼具有良好的可讀性， 需要通過在開發(fā)前期就作好代碼規(guī)范的教育工作，規(guī)范的代碼才能有效提交代碼的品質。4.開發(fā)環(huán)境構建步驟說明書外包開發(fā)通?？蛻羰菍⑼暾捻椖坎鸱殖啥鄠€相對獨立的模塊，分別發(fā)包給一個或多個外包開發(fā)公司開發(fā)，所以需要提供詳細完善的開發(fā)環(huán)境構建說明書，便于開發(fā)團隊盡快熟悉環(huán)境完成開發(fā)任務。5.代碼代碼程序當然是所有制品中最重要的，其質量直接影響到項目的成功與否。 由于是委托開發(fā)，全部都是根據(jù)客戶提供的功能設計書來完成代碼開發(fā)的，所以往往可能因為設計書理解不足，或設計書內(nèi)容存在錯誤等外部因素影響代碼的質量。而一旦存在疑問時，就應該及時通過QA方式向日方確認。最后在完成全部代碼實現(xiàn)后，需要和日方一起Review全部代碼?？傊椖砍蓴【腿Q于代碼的質量如何了。 6.代碼目錄結構說明書此文檔只是一個說明性的文檔，用說明各個代碼文件的目錄結構，編譯環(huán)境的設置等相關具體內(nèi)容。方便客戶拿到代碼文件后能盡快確認代碼的正確性。6測試用例書測試用例書也是整個開發(fā)過程中又一個關鍵，也是保證代碼質量的一種有效手段。通常分為正常系和異常系兩大類測試用例，判斷程序的正常執(zhí)行結果是否符合需求，是否具有一定的判錯能力等。與代碼一樣，測試用例書也是需要提交日方客戶Review確認后，再能進入測試階段的。8.測試數(shù)據(jù)測試過程用到的所有數(shù)據(jù)，可能因為測試數(shù)據(jù)的局限性導致有些 Bug沒有被發(fā)現(xiàn)，那就可以依據(jù)現(xiàn)有的測試數(shù)據(jù)內(nèi)容判斷測試是否全面而且有效了。9.測試結果書依據(jù)測試用例書，對最終的代碼程序進行測試，并全部確認無誤后，填寫測試結果書提交給日方客戶。10.輔助工具報告為了保證代碼的質量，通常還會使用一些自動化測試工具，對性能，漏洞，規(guī)范等方面進行測試，根據(jù)測試的結果報告，盡可能修正后，將最終的報告書也需要提交給日方客戶。 3.34個階段的劃分RUP將整個開發(fā)過程劃分成初始、細化、構造、交付四個階段。每個階段中都包含著多個工作流，只是工作的重點不同，同時還包含著復數(shù)個迭代過程。迭代次數(shù)和劃分時間也許無法事先預計，但是可以大致規(guī)劃，再根據(jù)具體情況，靈活變動修改的。以下將以四個階段為單位分別展開闡釋。1.初始初始階段主要完成的任務是：掌握功能設計書，熟悉開發(fā)環(huán)境，估算項目工數(shù)和規(guī)模。似乎初始階段的任務并不難，但是其估算結果的正確與否會影響到最后的實現(xiàn)情況。所以需要全面而準確的了解功能需求，才能避免過大的偏差。初始階段相對任務比較輕，一般一次迭代就能完成。在此迭代過程中也可以嘗試實現(xiàn)部分代碼，了解具體的項目難度，以便準確的估算。2.細化細化階段主要任務是：作成詳細設計書和測試用例書，并完成部分代碼的實現(xiàn)。詳細設計書和具體實現(xiàn)方法是有密切聯(lián)系的，所以應該在寫詳細設計書的同時編寫并測試通過部分代碼，以驗證設計的可行性。而現(xiàn)在多數(shù)項目中存在的問題是，大家并不能意識到迭代開發(fā)比如，詳細設計時，也會嘗試調(diào)查，的重要性，還不能掌握迭代開發(fā)的手段規(guī)避和控制風險。但是調(diào)查時候寫的代碼可能并不是最后要交付的代碼，可以認為那是一定程度上的資源浪費。所以應該加強開