對日軟件外包(精)

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