對日軟件外包的軟件開發(fā)過程

1、.對日軟件外包的軟件開發(fā)過程第1章對日軟件外包1.1對日軟件外包的開展全球應用軟件外包市場近幾年平均每年以29%的速度增長，2005年整個市場規(guī)模將到達389億美元。目前全球的軟件產值中，三分之一需要通過對外發(fā)包來完成。軟件外包已經成為世界軟件產業(yè)開展的一個重要趨勢。在這一趨勢下，?振興軟件產業(yè)行動綱要?提出，從2001年到2005年，中國軟件出口要從年出口7億美元提升到50億美元。按照預定的目的，2004年國內軟件企業(yè)將要完成的出口額將到達35億美元。這對于中國軟件企業(yè)而言確實是個不小的數(shù)字。為了實現(xiàn)這一目的，有關人士指出，中國企業(yè)應積極拓展對歐美軟件外包業(yè)務，把軟件外包做強做大。但如今美國

2、市場主要被印度壟斷，歐洲市場被愛爾蘭壟斷，中國企業(yè)的核心競爭力需要較長時間的積累，而對日軟件外包，我們那么有優(yōu)勢。在對美軟件外包市場上，中國軟件企業(yè)與印度軟件企業(yè)的差距是明顯的，從英文程度到簽證難度，從法制制度的不同到對知識產權認識程度的差異，中國軟件企業(yè)要在對美軟件外包市場趕上印度企業(yè)還需加以時日。美國IT從業(yè)人員中印度和中國人員的比例是31，中國軟件企業(yè)目前做的外包只占日本軟件外包的2%多一點。以英文為主導的軟件外包市場正在逐漸萎縮，并且在這個市場上我們和印度相比競爭優(yōu)勢不明顯。而對日軟件外包市場相對印度來說，中國軟件企業(yè)有地域優(yōu)勢和有限的語言優(yōu)勢，應當成為國內軟件外包企業(yè)的開展導向。1.

3、2對日軟件外包的現(xiàn)狀對日外包市場潛力宏大，據IDC統(tǒng)計數(shù)據，2005年日本IT外包市場規(guī)模為164億美元，而同年我國來自日本的軟件發(fā)包量約為5.6億美元，僅占日本IT外包市場的3.4%。IDC預測2020年日本IT外包市場將到達23，363億日元約226億美元，2020年我國對日外包將近40億美元，占比上升為17.7%。由此可見我國對日軟件外包將來的市場潛力宏大。國內現(xiàn)有的對日軟件外包企業(yè)，主要為面向日本資訊科技行業(yè)的客戶提供外包軟件開發(fā)效勞，而該等客戶其本身又是為日本客戶或全球客戶提供軟件開發(fā)效勞。也就是一種工程轉包性質的開發(fā)。以我如今所在公司為例，從事過制造業(yè)工程、CAD軟件工具、證券金融

4、軟件、物流軟件等等。1.3對日軟件外包的軟件開發(fā)特點由于外包客戶也是多為軟件公司或是大公司的軟件開發(fā)部分，而且由于是外包軟件開發(fā)，所以開發(fā)層次比較低，或者說不是一個完好意思上的軟件開發(fā)過程。根據個人在對日軟件開發(fā)公司工作多年的經歷，總結以下幾點特點：1.技術含量低，從事低層次工作。通常，軟件開發(fā)過程都要經歷商業(yè)建模、需求分析、系統(tǒng)分析和設計、實現(xiàn)、測試和部署等核心流程。然而，對日外包的開發(fā)流程被嚴格劃分開來的，外包客戶從事商業(yè)建模、需求分析、系統(tǒng)分析和設計等高層次的工作，然后將設計書發(fā)包到國內，而國內公司僅僅只是嚴格根據客戶的設計書，將其代碼實現(xiàn)并通過單體測試就算完工。所以，國內對日外包企業(yè)只

5、是擔當了實現(xiàn)、測試兩個階段的任務。也有個別工程會擔當些簡單的設計任務。2.工期短工作量大由于國內勞動力相對日本國內廉價許多，許多日本IT企業(yè)將開發(fā)和測試環(huán)節(jié)移到中國國內，根據客戶的功能設計書或詳細設計書，完成開發(fā)及測試。這樣即可以降低軟件開發(fā)本錢，又不至于有太大的開發(fā)風險，因為設計是日本人自己完成的。但是，時常會發(fā)生因為客戶的設計不合理或不詳細或理解不同等等客觀原因，無法按照原來合同中規(guī)定的工數(shù)完成任務，所以常常要靠加班來爭取時間。3.品質要求高誰都想花錢買到好東西，軟件外包也是一樣，日本公司也想花錢買到更好的客戶，詳細表達就是提供優(yōu)質的代碼成果物。然而，由于軟件企業(yè)的流動性比較大，公司出于本

6、錢考慮，常會雇傭一些經歷缺乏的實習人員直接投入工程開發(fā)中，導致品質較低，而為了彌補品質上問題，又需要用加班的方式來爭取大量時間進步質量。4.文檔要求高有些日本客戶公司，施行了CMM3或更高級別的控制標準，同樣也要求中國的外包公司按照其標準施行，當然這樣對于國內公司自身管理才能也是一種進步。但是，有些客戶公司過于注重文檔，而無視了對于最更本的代碼的重視程度。第2章RUP RUP是Rational統(tǒng)一過程Rational Unified Process的簡稱，它是Rational公司現(xiàn)歸屬IBM公司推出的一種軟件過程產品。從軟件過程形式角度看，RUP又是一種典型的軟件過程形式，它以迭代增量式、架構

7、為中心、用例驅動的軟件開發(fā)方法、采用UML語言描繪軟件開發(fā)過程為主要特征，其中以用例驅動乃是貫穿軟件開發(fā)始終的方法。2.1 RUP的特點1.迭代式開發(fā)。在軟件開發(fā)的前期階段完全并準確的掌握用戶全部的需求幾乎是不可能的。實際上，經常遇到，需求在整個軟件開發(fā)工程中會不斷改變，從而使得軟件工程難于管理而產生較大風險。而迭代的開發(fā)方式允許在每次迭代過程中需求有所變化，通過不斷細化來加深對問題的理解，最終實現(xiàn)完全滿足用戶需求的軟件。迭代式開發(fā)不僅可以降低工程的風險，而且使得軟件開發(fā)過程具備較強的控制性。2.管理需求。完善用戶需求是一個漸進的過程，開發(fā)人員在開發(fā)系統(tǒng)之初不可能完全詳細的說明一個系統(tǒng)的真正需

8、求。RUP描繪了如何提取、組織系統(tǒng)的功能和約束條件并將其文檔化，用例和腳本的使用以被證明是捕獲功能性需求的有效方法。3.基于組件的體系構造。組件使重用成為可能，系統(tǒng)可以由組件組成?；讵毩⒌?、可交換的、模塊化組件的體系構造有助于管理復雜性，進步重用率。RUP描繪了如何設計一個有彈性的、能適應變化的、易于理解的、有助于重用的軟件體系構造。4.可視化建模。RUP和UML結合在一起，對軟件系統(tǒng)建立可視化模型幫助人們提供管理軟件復雜性的才能。RUP告訴我們如何可視化的對軟件系統(tǒng)建模，獲取有關體系構造于組件的構造和行為信息。5.驗證軟件質量。在RUP中軟件質量評估不再是事后進展或單獨小組進展的別離活動，

9、而是內建于過程中的所有活動，這樣可以及早發(fā)現(xiàn)軟件中的缺陷。6.控制軟件變更。迭代式開發(fā)中假設沒有嚴格的控制和協(xié)調，整個軟件開發(fā)過程很快就陷入混亂之中，RUP描繪了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。RUP通過軟件開發(fā)過程中的制品，隔離來自其他工作空間的變更，以此為每個開發(fā)人員建立平安的工作空間。2.2 RUP的核心工作流RUP中有9個核心工作流，分為6個核心過程工作流Core Process Workflows和3個核心支持工作流Core Supporting Workflows。盡管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段，但應注意迭代過程中的階段是完全不同的，這些

10、工作流在整個生命周期中一次又一次被訪問。9個核心工作流在工程中輪流被使用，在每一次迭代中以不同的重點和強度重復。1.商業(yè)建模Business Modeling描繪了如何為新的目的組織開發(fā)一個設想，并基于這個設想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程，角色和責任。2.需求Requirements描繪系統(tǒng)應該做什么，并使開發(fā)人員和用戶就這一描繪達成共識。為了到達該目的，要對需要的功能和約束進展提取、組織、文檔化；最重要的是理解系統(tǒng)所解決問題的定義和范圍。3.分析和設計Analysis&Design將需求轉化成將來系統(tǒng)的設計，為系統(tǒng)開發(fā)一個強健的構造并調整設計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化

11、其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計活動以體系構造設計為中心，體系構造由假設干構造視圖來表達，構造視圖是整個設計的抽象和簡化。4.實現(xiàn)Implementation包括以層次化的子系統(tǒng)形式定義代碼的組織構造；以組件的形式源文件、二進制文件、可執(zhí)行文件實現(xiàn)類和對象；將開發(fā)出的組件作為單元進展測試以及集成由單個開發(fā)者或小組所產生的結果，使其成為可執(zhí)行的系統(tǒng)。5.測試Test驗證對象間的交互作用，驗證軟件中所有組件的正確集成，檢驗所有的需求已被正確的實現(xiàn)，識別并確認缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法，意味著在整個工程中進展測試，從而盡可能早地發(fā)現(xiàn)缺陷，從根

12、本上降低了修改缺陷的本錢。6.部署Deployment成功的生成版本并將軟件分發(fā)給最終用戶。描繪了那些與確保軟件產品對最終用戶具有可用性相關的活動，包括：軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。7.配置和變更管理Configuration&Change Management描繪了如何在多個成員組成的工程中控制大量的產物。配置和變更管理工作流提供了準那么來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)立過程中的版本。描繪了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)立工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。8.工程管理Project Management平衡各種

13、可能產生沖突的目的，管理風險，抑制各種約束并成功交付使用戶滿意的產品。其目的包括：為工程的管理提供框架，為方案、人員裝備、執(zhí)行和監(jiān)控工程提供實用的準那么，為管理風險提供框架等。9.環(huán)境Environment環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。環(huán)境工作流集中于配置工程過程中所需要的活動，同樣也支持開發(fā)工程標準的活動，提供了逐步的指導手冊并介紹了如何在組織中實現(xiàn)過程。2.3 RUP裁剪步驟RUP是一個通用的過程模板，包含了很多開發(fā)指南、制品、開發(fā)過程所涉及到的角色說明，由于它非常龐大所以對詳細的開發(fā)機構和工程，用RUP時還要做裁剪，也就是要對RUP進展配置。RUP就像

14、一個元過程，通過對RUP進展裁剪可以得到很多不同的開發(fā)過程，這些軟件開發(fā)過程可以看作RUP的詳細實例。RUP裁剪可以分為以下幾步：1確定本工程需要哪些工作流。RUP的9個核心工作流并不總是需要的，可以取舍。2確定每個工作流需要哪些制品。3確定4個階段之間如何演進。確定階段間演進要以風險控制為原那么，決定每個階段要那些工作流，每個工作流執(zhí)行到什么程度，制品有那些，每個制品完成到什么程度。4確定每個階段內的迭代方案。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內容。5規(guī)劃工作流內部構造。工作流涉及角色、活動及制品，他的復雜程度與工程規(guī)模即角色多少有關。最后規(guī)劃工作流的內部構造，通常用活動圖的形式給出。第3

15、章改進方案雖然，對日軟件外包工程往往不是一個完好的軟件開發(fā)過程，只是其中一部分或幾部分而已，但是并不阻礙RUP在對日外包工程中發(fā)揮強大的作用。上一章節(jié)中，分析了如何根絕詳細工程特性，對RUP過程進展裁剪，以適應不同的軟件工程。本章節(jié)將根據裁剪步驟，結合如今公司的工程特點，細化制定適當?shù)腞UP開發(fā)過程。3.1確定工作流對日軟件外包，通常是根據客戶的功能需求書或詳細設計書，完成代碼實現(xiàn)和測試。所以只需要實現(xiàn)和測試兩個工作流。結合我公司如今從事工程的特點，簡單闡述一下各工作流。1.實現(xiàn)由于對日外包的特殊性，面對客戶根本都是日本的IT企業(yè)，現(xiàn)階段都處于較低層次，也就是只負責代碼實現(xiàn)和測試，可能也會從事

16、部分簡單設計。所以，根據客戶的設計書完成符合要求的代碼就是對日外包的主要工作任務。所以實現(xiàn)工作流也是最重要的工作流。而且，由于是根據日方的設計從事開發(fā)實現(xiàn)，所以除了實現(xiàn)本身的任務外，還有承前的工作要完成，比方：理解設計書的要求，開發(fā)環(huán)境搭建，判斷設計中可能存在的不合理性等。而這些問題都可能直接影響到最后是否能順利完成實現(xiàn)的工作任務。2.測試判斷開發(fā)的代碼是否能交付，也就是依靠測試用例了，我方只擔任單體測試部分的任務，并將全部通過測試的代碼和測試用例書作為成果物交付給日方。假設，由于單體測試內容不全面，而在結合測試中發(fā)現(xiàn)的問題，將作為Bug報告，再由擔當者修正后提交。以上講的兩個工作流，是如今多

17、數(shù)對日外包公司承擔的主要任務，當然也有部分公司可能承接的工程是個完好的軟件過程，涉及到9個工作流中的絕大多數(shù)，在此不作重點依次展開。其實各個工程，由自身特點可以制定出自己的RUP軟件過程。只要實用就是最好。3.2各工作流的職責和制品由于是委托開發(fā)，客戶為了有效控制開發(fā)過程和質量，往往是通過各種文檔來對工程進展管理和控制。對日外包開發(fā)中，文檔的分類比較繁多，規(guī)格要求也根據不同公司有不同的要求。以以下舉幾種文檔，在整個開發(fā)過程中起俄作用：1.功能設計書用戶提出委托開發(fā)要求，中方根據功能設計書，理解所開發(fā)工程的所有需求，并估計工數(shù)和工程報價，假設對方客戶對報價沒有異議，就正常進入開發(fā)施行階段。開發(fā)小

18、組成員開場一起研究功能設計，解決理解和實現(xiàn)技術上的所有問題，盡可能防止因設計書理解缺乏，而導致工程失敗。2.詳細設計書通常，客戶是不提供詳細設計書，而是開發(fā)團隊根據功能設計書，結合實現(xiàn)技術的特點，完成詳細設計書，作為實現(xiàn)工作流的前期成果物，交付日方Review確認，只有通過Review后才能進入到正式的開發(fā)實現(xiàn)階段。3.代碼規(guī)約為加強代碼具有良好的可讀性，需要通過在開發(fā)前期就作好代碼標準的教育工作，標準的代碼才能有效提交代碼的品質。4.開發(fā)環(huán)境構建步驟說明書外包開發(fā)通?？蛻羰菍⑼旰玫墓こ滩鸱殖啥鄠€相對獨立的模塊，分別發(fā)包給一個或多個外包開發(fā)公司開發(fā)，所以需要提供詳細完善的開發(fā)環(huán)境構建說明書，便

19、于開發(fā)團隊盡快熟悉環(huán)境完成開發(fā)任務。5.代碼代碼程序當然是所有制品中最重要的，其質量直接影響到工程的成功與否。由于是委托開發(fā)，全部都是根據客戶提供的功能設計書來完成代碼開發(fā)的，所以往往可能因為設計書理解缺乏，或設計書內容存在錯誤等外部因素影響代碼的質量。而一旦存在疑問時，就應該及時通過QA方式向日方確認。最后在完成全部代碼實現(xiàn)后，需要和日方一起Review全部代碼?？傊こ坛蓴【腿Q于代碼的質量如何了。6.代碼目錄構造說明書此文檔只是一個說明性的文檔，用說明各個代碼文件的目錄構造，編譯環(huán)境的設置等相關詳細內容。方便客戶拿到代碼文件后能盡快確認代碼的正確性。7.測試用例書測試用例書也是整個開發(fā)

20、過程中又一個關鍵，也是保證代碼質量的一種有效手段。通常分為正常系和異常系兩大類測試用例，判斷程序的正常執(zhí)行結果是否符合需求，是否具有一定的判錯才能等。與代碼一樣，測試用例書也是需要提交日方客戶Review確認后，再能進入測試階段的。8.測試數(shù)據測試過程用到的所有數(shù)據，可能因為測試數(shù)據的局限性導致有些Bug沒有被發(fā)現(xiàn)，那就可以根據現(xiàn)有的測試數(shù)據內容判斷測試是否全面而且有效了。9.測試結果書根據測試用例書，對最終的代碼程序進展測試，并全部確認無誤后，填寫測試結果書提交給日方客戶。10.輔助工具報告為了保證代碼的質量，通常還會使用一些自動化測試工具，對性能，破綻，標準等方面進展測試，根據測試的結果報

21、告，盡可能修正后，將最終的報告書也需要提交給日方客戶。3.3 4個階段的劃分RUP將整個開發(fā)過程劃分成初始、細化、構造、交付四個階段。每個階段中都包含著多個工作流，只是工作的重點不同，同時還包含著復數(shù)個迭代過程。迭代次數(shù)和劃分時間也許無法事先預計，但是可以大致規(guī)劃，再根據詳細情況，靈敏變動修改的。以下將以四個階段為單位分別展開闡釋。1.初始初始階段主要完成的任務是：掌握功能設計書，熟悉開發(fā)環(huán)境，估算工程工數(shù)和規(guī)模。似乎初始階段的任務并不難，但是其估算結果的正確與否會影響到最后的實現(xiàn)情況。所以需要全面而準確的理解功能需求，才能防止過大的偏向。初始階段相對任務比較輕，一般一次迭代就能完成。在此迭代過程中也可以嘗試實現(xiàn)部分代碼，理解詳細的工程難度，以便準確的估算。2.細化細化階段主要任務是：作成詳細設計書和測試用例書，并完成部分代碼的實現(xiàn)。詳細設計書和詳細實現(xiàn)方法是有親密聯(lián)絡的，所以應該在寫詳細設計書的同時編寫并測試通過部分代碼，以驗證設計的可行性。而如今多數(shù)工程中存在的問題是，大家并不能意識到迭代開發(fā)的重要性，還不能掌握迭代開發(fā)的手段躲避和控制風險。比方，詳細設計時，也會嘗試調查，但是調查時候寫的代碼可能并不是最后要交付的代碼，可以認為那是一定程度上的資源浪費。所以應該加強開發(fā)團隊在細化階段是，注重迭代開發(fā)，使得工程不斷完善。3.構造構造階段主要任務是：根據詳細設計書