軟件開發，標準化流水線式開發的實施構想

軟件開發，標準化流水線式開發的實施構想

?????? 近日看到一篇博文，討論標準化流水線開發模式的話題，但是這篇博文僅僅提出這個問題，未見回應。

?????? 這其實是一個很大的問題，我從事軟件開發這么多年，仍然未見到國內有任何一家公司真正做到，這個問題也是我一直到思考的。一直以來我也嘗試推行這種模式，但是仍然未見起色，從中我不僅學習到一些經驗，但是也深知其困難。通過這篇博文來跟到家分享下我的經驗。

????????? 一個問題、什么是標準化和流水線開發模式，為什么要實施？

?????? 可能大家對標準化和流水線開發模式還不大清楚，我們先來細細闡述一下。標準化和流水線開發模式就是使得軟件模塊標準化，軟件開發流程像生產車間流水線作業一樣，所有的軟件工程師只需要根據軟件設計規格書去模塊庫選擇適當的模塊（即原材料），然后編寫程序進行拼裝、測試、發布即可。

?????? 無可厚非，這種開發模式，效率是極高的，而且對程序員水平要求也是極低，這樣不僅僅可以提高軟件系統的效率，而且也可以大大的降低人力成本，完全實現軟件大批量式生產和開發，因此實施這種模式對一個公司來說確實很迫切。

????????? 又一個問題、國內軟件公司為什么遲遲未能成功實施這種開發模式呢？

?????? 首先需要說明的一點，大家切不要以為國內的公司不想實施，其實做夢都在想，但是為什么沒能成功實施呢？我認為有以下幾點；

?????? 國內大部分公司的目標和需求都不明確。大家可以發現國內的公司有一個最大的特點就是產品種類多，其實這個也不算什么，最要命的就是，種類多還行業多。比如說有些公司既有煤礦安全監控的產品，又有電子消費方面的產品，甚至還有ERP方面的產品。其實細細觀察，這些公司的產品卻沒有一個是已經具備一定規模的，可以想象，這些公司在這些相應的行業中的積累似乎足夠淺，提煉這個行業的軟件模塊基本不可能，或者就是模塊根本達不到通用的標準。因此大家常常會發現，公司的大部分工程師是在修改原由的模塊來滿足各類客戶的需求，這樣久而久之使得軟件模塊已經很難統一，維護異常困難，人疲馬乏，還怎么實現標準化和流水化呢！其實總結一句就是，定制產品就是使得公司無法成功實施標準化和流水化開發模式的原因，可能這樣說來說去又回到“雞”和“蛋”的問題，大家細細琢磨吧！

?????? 國內公司的管理層和程序員還太年輕。在這么多的公司當中，大家其實可能發現，國內的公司都是青春期的公司，一些工作一兩年的就是什么系統工程師，工作兩三年的就當個項目經理甚至部門經理，可以想象，在中國這種環境下，這樣的職位晉升從此斷送這些人的技術前景和積累。從此這些人就開始不斷的根市場打交道，學會市場卻忽略了技術的學習和積累，如此長久下去，最終、公司的高層雖都具備市場的眼光，但卻斷送了工程技術的創造力，其慢慢就無法把握工程的基層開發流程，更不用去談什么標準化和流水線作業了。這就是為什么有些公司發展數十載，再也發展和壯大不下去的原因——因為他們已經陷入了人才怪圈的循環，此后就會發現人才流動頻繁，人才周期縮短等現象。

?????? 國內公司缺乏項目總結和軟件重構的意識和投入。國內很多公司都是靠定制項目生存的，有些項目來的很緊急，需要迅速開發出來。大家都知道，這種快速的開發完全時間建立在成熟的技術至上，由于時間緊急，發布可運行的軟件是最為緊迫的，大家工作的目的就是趕時間、趕工程、趕“發布”，然而如此往復，不僅人困馬乏，而且我們時常發現，軟件發布后，一旦獲得用戶認可，那么這個項目就算是完成了，然后項目組進行簡單的項目總結之后就將項目組成員遣散到其他項目中去，也不對系統進行重新分析和模塊進行重夠構、甚至不做任何歸檔。這樣、在這個項目的中獲取的經驗就完全屬于項目組成員的個人經驗，而非公司技術積累，一旦某個程序員離職，那么在項目中積累的一些經驗（軟件模塊）就隨之不復。IT行業，在國內來說，至少是一個高流動性的行業，因此對于國內IT企業來說，技術積累也是異常的困難。其實就我看來，一家人才流動性比較高的企業，其10年的行業技術積累還不如一些稍微穩定的公司6年的積累。

????????? 那么我們應該如何實施軟件標準化和流水線開發模式？

??????? 在我的軟件開發生涯當中，我時時刻刻在思考如何將實施軟件標準化和流水線開發模式。我先后從事過應用開發、基礎設備驅動開發、內核開發，每個開發過程我都試圖尋找其中的開發模式，盡量作到標準化和流水線作業，以提高開發效率。這些年雖然未的到一個成熟的方案，但也獲得一些經驗，那我們來分享下吧；

????????? 第一、? 開發過程盡量做到標準化，將文檔作為開發過程的里程碑。

???????? 在一些急行軍式的項目開發過程中，很多時候都會將文檔忽略，或則就是只有少量的文檔。軟件開發過程也沒有，需求分析、架構設計、詳細設計等過程，只是項目一上來就開發編寫代碼。這樣項目小還好說，如果項目比較大的話，那么到開發的后期就將無法控制了。記得前些年，我開發一套財務系統，當時是第一次作為項目負責人，時間比較緊，因此拿到項目需求之后，就立馬組織人員進行簡單分析、模塊劃分之后就開發編寫代碼，1.5月之后，我們順利地將軟件開發出來了，測試之后就部署到服務器上，之后我們就沒有再過問這個系統。一天我的BOSS，突然給我電話，說財務系統導致虧損18萬，當時我就驚呆（并不是因為金額，而是頭腦中無一點頭緒），之后就立刻組織人員對代碼進行復查，當我再次那到這些代碼的時候，似乎這些代碼已經很陌生了，因為沒有文檔，程序里一些復雜的算法已經忘光了，無根無據，只能從頭到未反復演算算法過程，那段痛苦的時間，每每提起都讓人毛骨悚然。之后，在任何項目中開發中，我都盡量將開發過程標準化，以此避免這種類似的事情發生。

?????????軟件標準化和流水線開發模式的目的是要進行大規模大批量軟件產品開發，在這種前提下，如果軟件開發過程不夠標準、文檔不夠齊備，那么公司就需要投入多倍的技術支持來彌補這些缺損、解決這種“無根無據”的問題。因此軟件標準化和流水線開發模式先要將軟件開發過程標準化、將（重要）文檔作為開發的里程碑。

????????? 第二、? 將軟件模塊更抽象、更細化，層次劃分更合理。

???????? 在軟件構架的時候，將軟件進行層次劃分，模塊細化十分重要。以前看過一本書《設計模式》，一句話總結這本書的內容就是“層次劃分、模塊抽象和細化、高內聚低偶合”。就標準化和流水線開發模式而言，這更是重要的，也是實施的前提。

??????? 前些年在開發一些管理系統的時候，每次看到我的一位老師（重慶市著名的數據設計專家——王家偉）發給我數據邏輯模型的時候，總是會發現這個模型有些地方總會和上一次的模型的某些地方相同的，比方說用戶管理模塊。這樣、我以前編寫的模塊代碼就能完全復用，節省了這部分的開發時間。當時我就在想，如果每個模塊都能抽象、細化成經典的模塊，那么在下次開發的過程中我們就能直接引用，那該多節省時間啊，新的項目真正需要開發也就是業務層了。

??????? 第一次開發管理系統的時候，我一直對MVC模式無法駕馭，雖然口談論足，但是未得其然。第一個項目之后，我又參加了另外一個稍微大一點的項目，跟著一個資深的工程師開發，當他給我項目設計書的時候，提出了四層級別的MVC模式，Model、DAL、BLL、Web四層開發模式。這引起我對ＭＶＣ模式的深思，隨著項目經驗增多，我慢慢才體會到，MVC模式是一個經典的模式，本身并沒有什么，它的目的就是告訴你，在軟件設計的時候要對軟件進行分層，降低系統的模塊和層次之間的偶合度，在后期面的開發過程中，最多時候我還設計了８層ＭＶＣ開發模式。

?????? 后來我慢慢發現，一個好的經典的模塊應用，一個恰當的系統層次模型往往會使得的整個項目開發周期大大縮短、穩定性大大增高。因此、我認為、標準化和流水線開發模式，如果離開了標準（經典）的模塊和合理的層次結構，那么也就是“口談論足，未得其然”罷了！

?????? 第三、? 將項目總結和模塊標準化、軟件重構、模塊抽取納入到開發周期中。

???????就像上面的敘述一樣，很多公司為了趕項目，往往忽略了后期的項目總結、軟件（模塊）重構等方面的工作。

?????? 有些項目開發經驗的程序員就會發現，客戶的需求總是變化的，以前項目中的一些相似模塊總是需要有些改動才能適用新項目的需求。

???????確實如此，我也總是遇到，但是后面我改變方法了，每次項目結束之后，我都會對項目總的一些經典的模塊進行分析、重構、最終抽取出來建立自己的模塊庫，下次用的時候，就可以直接采用，或則稍做少量的修改就能符合新的需求。這種方法我已經獲得一定的見效，并且屢試不爽！

?????? 前不久，我經歷過一個項目，需要開發一個波形圖繪制的模塊，大家都知道這個模塊并不復雜，很多人只需花費一個上午就可以完成。也不差、很快我就開發完成了，并成功應用到系統當中去了。但是，著并不算什么，為了讓這個模塊更加健壯和適應后期的需求，我仔細分析了，后面我發現，這種波形圖模塊，少不了坐標選項、少不了波形回查（重現）、少不了波形圖走勢記錄等功能，因此我以經典的模型圖類派生了三個子類，形成波形圖較為經典的模塊。這個模塊在后期也得到了很好的應用和驗證，節省了很多不必要的時間。

?????? 標準化和流水線開發模式總是要將軟件需求預先預料，以適應更加廣闊的需求，那么項目總結和模塊標準化、軟件重構、模塊抽取就是軟件開發中的“未雨綢繆”，因此建議將其納入到開發周期。

????? 第四、? 建立公司的模塊庫，制定軟件開發流水作業模型，并建立培訓單位。

????? 最后一個話題，有了上面的開發過程標準化、模塊抽象、模塊重構和抽取，如果我們都這樣做到了。那么就公司而言，就必須做好技術積累的相應措施了！

????? 有了模塊，公司就必須建立模塊庫，并進行分類管理，如GUI庫、控制協議庫、業務邏輯庫等。如果公司10年如一日的堅持模塊庫的建立，如果以平均1000個程序員的規模計算，那么整個庫將涵括1萬個經典子模塊庫，這些模塊就是軟件的構件，也是軟件標準化和流水線作業的原才料和基礎，就相當制造業工廠生產線的螺絲。

????? 模塊庫一旦形成，就必須建立軟件開發流水線作業模型，其實也就是新的適合公司的軟件開發流程。如下過程如何；

{《需求分析》—《模型設計》—《架構設計》—《模塊復用設計》—《詳細設計》—《編碼》—《測試》—《發布》—《項目總結、新模塊重構和抽取》—《模塊庫歸檔》}

????? 如果模塊庫和流水線模型建成，那么建立培訓機制就更顯重要，對于新員工來說，讓他們了解項目開發過程當中能夠使用的資源比什么都重要，這樣可以避免做無用功。

至此一個簡單的標準化和流水作業實施方案已經趨于完成，最后介紹一下測試。

????????? 測試也需要標準化，建立標準化、自動化、壓力測試部門。

?????? 很多公司都不太注重測試，很多公司即使有了測試，也有些行同虛設，不得其要點。在標準化和流水線開發模型當中，測試顯得更加重要，其實大家都可以發現，在真個項目周期中測試所占用的時間都是真個周期的40%，無可厚非，如果不能精簡這部分的時間消耗，那么標準化和流水線實施的意義也就大大折扣。

?????? 就想我以前的一篇文章中介紹的一樣，其實試分析一下，現在公司的大多數項目都是基于行業應用的，行業應用的產品通常都有自己的參數指標，例如工控產品需要過竟EMC檢測等。

???????另外公司也可以形成自己的普通軟件的測試標準，比如說，接口測試必須自動化測試1000次以上不失敗等。對于很多軟件而言，通過壓力測試也是必須的，例如高性能服務器必須通過5000連接同時傳輸7天的壓力測試等。

?????? 就此種種、建議大部分有勢力的公司在實施標準化和流水線作業模型的過程中，建立標準化、自動化、壓力測試部門，這些部門主要用于制定標準測試方案、流程和編寫自動化測試軟件。

?????? 以上就是我的一些想法，似有不足，請大家評論。最后要說一句，印度的大部分外包軟件公司都成功實施了這種標準化和流水化的開發模式，其開發規模和效率確實遠高于我國。

Internet 服務總線

?

作者：Donald F. Ferguson、Dennis Pilarinos、John Shewchuk

?

摘要：Web應用程序是非常常見的應用程序模型，它們將變得越來越普遍。幾乎所有大中型企業的應用程序都提供Web用戶界面。在本文中，我們將使用術語“企業”表示大中型企業、軟件供應商和集成商。桌面和客戶端/服務器應用程序越來越多地使用瀏覽器作為UI引擎，并通過Web協議調用數據和服務。

軟件、應用程序模型以及Web本身都在進行革命性變革。這場變革對計算機世界的影響與客戶端/服務器模型或Web的出現相差無幾。Web將從連接用戶與站點提供的應用程序的工具發展為具有以下特征的模型：

l? 應用程序“在Web中”執行。

l? 最終用戶開發自己的應用程序訪問Web，將其轉變為用于訪問Web服務的最終用戶開發的工作空間。

本文重點介紹變革中的一小部分內容。其他文章將擴展此愿景。

很多技術和趨勢都為上述革命性變革提供了動力。比如：多核處理器；虛擬化；聯合很多設備的應用程序方案，如手機和平板電腦；面向服務的架構(SOA)和Web服務；Web 2.0；軟件即服務(Software as a Service，SaaS)。

我們將討論某些趨勢的影響，但我們主要側重于SOA、Web 2.0和軟件即服務(SaaS)。這些概念及其關系尚未得到廣泛了解。通常，這些技術似乎相互矛盾。本文介紹使這些概念成為一個統一體的高級參考架構的元素。

上文所述的很多技術趨勢都得到了廣泛的認可和關注。本文討論爭議較大的第三個趨勢：無處不在的編程功能。很多高等學校和大學畢業生開始參加工作時都有基本的編程技巧，很多學生已經開發了簡單的PHP或Visual Basic應用程序并且構建了網站。專業人員的主要工作職責可能不包括編程，但是很多情況下，如果編程能夠使他們效率更高，專業人員也會簡單的進行編程。他們可能還會開發一些簡單的應用程序，因為這樣比較“酷”。對于這個概念，我們將使用最終用戶編程這個術語。

最終用戶編程是機會開發的極端情況，它發生在企業中的各個部分以及業務范圍(LOB)中。LOB和團隊通常構建簡單的“快捷而粗劣的”SharePoint或PHP應用程序，這些應用程序可以通過擴展已封裝的應用程序或企業范圍核心應用程序解決直接業務問題。

機會開發和系統開發形成了對照。系統開發是模型驅動的，總是需要進行需求收集、用例和股東會談，包括質量和保證的應用程序開發生命周期等等。系統開發是企業開發團隊（“CIO團隊”）的主要模型。很多封裝的應用程序開發人員（獨立軟件供應商或ISV）和系統集成商(SI)也提出系統解決方案。

在機會開發和系統開發的企業之間有一個拉力。如果最終用戶編程變得很普遍，則這個拉力將會增大。最終用戶將不滿足于等待系統開發團隊開發或修改解決方案。我們介紹的參考架構提供了一個協調機會開發和系統開發的方法。

我們將使用一個方案來演示參考架構。形成和支撐該架構的核心元素是Internet 服務總線(ISB)。參考架構包含很多元素，但是，本文僅提供ISB的詳細信息。其他文章將介紹其他元素。

?

?

目錄

方案以及機會開發和系統開發
軟件和服務，以及Internet 服務總線
結束語
參考資料
關于作者

?

方案以及機開發會和系統開發

Dave 經常出差，他首先要使用酒店和航空公司。在出差的城市中，他使用當地的汽車服務，并且預訂餐館。與朋友、家人和同事的協作也是非常重要的。Dave使用各旅行提供商的網站制訂和更改旅行計劃。

Dave的旅行管理涉及很多通過網站與旅行提供商進行的手動交互任務。他必須手動協調跨站點的任務，并且必須手動在字段之間剪切和粘貼數據。而且要符合一定的先后順序邏輯，例如，必須先預訂餐館和汽車服務才能到達餐館。Dave的行為就像一個復雜的應用程序或企業應用程序集成(EAI)解決方案。手動工作非常單調乏味而且容易出錯。Dave有基本的編程技巧，因此他決定編寫一個小mashup。此mashup通過客戶端網頁腳本或簡單的HTML剪輯使用旅行提供商的網站（圖1(a)）。此mashup使Dave的生活變得更加輕松，并且使Dave的工作效率更高，因為他在管理旅行方面花費的時間更好，而將更多的時間花費在他的工作上。此mashup也非常酷，給他的朋友留下了很深刻的印象。

Mary和Ludwig喜歡這個應用程序，他們從Dave那里獲得了代碼。他們想擁有不同的UI，但希望共享代碼。因此，他們將UI與網站訪問分離、編寫腳本并通過實現簡單的模型視圖控制器版本進行緩存，從而改進了這個應用程序（圖1(b)）。改進后的程序還可以通過其他設備（如PDA或手機）進行訪問以重用代碼（圖1(c)）。最后，他們決定將模型層移動到部門Web服務器并實現一個簡單的Web應用程序。這樣便使多個人能夠訪問信息，以獲得幫助。

朋友有機會構建一個復雜的應用程序，這是一個簡單的偽EAI解決方案。隨著能夠編程的專業人員的參與，這些專門的即時應用程序將變得越來越普遍。不僅僅有“酷的因素”，而且應用程序也將簡化單調乏味的任務。專業人員還可能為解決短期的業務問題（如約定）構建“即時”應用程序。當用戶通過訪問現有數據庫和核心企業應用程序執行業務任務時，這些應用程序類似于電子表格的角色。

機會情境應用程序（situational application）將對企業系統應用程序交付產生深遠的影響。首先它將影響企業應用程序的開發。情境應用程序可能“依賴”核心企業應用程序，或采用意想不到的方法使用核心系統。這將使IT組織將某些“模型層”移動到企業服務器，以提高性能和完整性。

本質上，情境應用程序定義了驅動系統企業應用程序變革的用例。情境應用程序可以替換用于記錄用例的簡單實體模型，并且可以驅使正式的建模。

很多壓力使大量情境應用程序移動到企業服務器。可能有一些合作伙伴需要使用要求企業安全的應用程序。某些應用程序可能是重要業務決策的一部分，比如貸款審批。管理和遵從性將要求記錄數據訪問和輸入，并且保存這些應用程序各個版本的代碼。將情境應用程序移動到數據中心具有深遠意義。除了核心業務解決方案之外，數據中心還需要支持上百或上千個經常更改的應用程序。數據中心需要管理幾十個供大量用戶訪問的高負載核心應用程序服務器，以及上千個小型團隊使用專用應用程序偶爾訪問的虛擬服務器。

很多情況下，系統解決方案也使用機會應用程序。Dave認為如果IT使用他的應用程序，這將非常酷。

總之，機會應用程序推動系統解決方案的發展，系統解決方案推動機會應用程序的完善（例如代表性狀態傳輸（Representational State Transfer，REST）-> Web服務）。這些動��還推動軟件即服務的發展，更確切的說是軟件和服務。軟件和服務提供了一個平臺，可以將系統解決方案和機會應用程序的開發和交付結合在一起。

?

企業服務總線

考慮當Dave正在從紐約旅行到達拉斯時，如果航空公司取消了Dave從達拉斯到舊金山的航班將會發生的情況。Dave將不能到達舊金山，他需要在中轉機場所在的城市停留一整夜。因此有必要更改酒店、餐館以及汽車服務預訂。Dave在下飛機時可以使用他的mashup簡化這些更改。如果在飛行時能夠自動重新預訂，那最好不過了（“更酷了”）。航空公司和航班監視站提供航班時間表的更新服務。理想情況下，Dave的應用程序將始終動態執行。應用程序將監視這些更新，并使用簡單邏輯響應事件，更改路線和計劃。

簡單的最終用戶應用程序未必總是修復路線，但大多數修復非常簡單。Dave只需手動處理復雜的情況，還可以批準飛行過程中他的應用程序自動進行的更改。

修復路線的常規應用程序方案是企業中常見的問題類型。例如，類似的問題也可能發生在購買定單和報銷單審批方面。下面這個方案就是復合應用程序的一個示例，它實現直接處理(STP)模式（參見參考資料）。企業執行系統方法來解決這些問題。圖2概述了如果航空公司、酒店、餐館、城市汽車以及其他系統位于企業防火墻中時，復合應用程序可能的樣式。運行時間相對較長的編排過程預訂航班管理系統發出的事件。該過程來回發送消息，并調用現有應用程序取消預訂、查詢空閑資源以及進行新的預訂。由于企業種類的不同，現有應用程序具有各種消息格式（C、COBOL等等）以及通信協議（例如，WebSphere MQ、SAP RFC）。

?

圖2：企業業務過程（單擊圖片查看大圖）

圖2所示的修復過程設計非常脆弱。例如，如果添加了另一個航空公司應用程序，則必須更改業務過程。還可以將業務過程與現有應用程序的特定消息格式和語言聯系在一起。添加一個常規機制用于記錄與某些條件匹配的消息（例如，如果旅行者是管理人員，則記錄所有消息）是非常困難的。這種脆弱性導致企業應用程序架構發展為企業服務總線(ESB)。

圖3概述了企業服務總線。應用程序適配器將現有格式和協議轉換為標準的Web服務。這樣便將任何內容與任何內容連接的NxN協議/格式映射問題轉變成了N->1映射的問題，即將所有內容都轉換為標準。ESB提供了處理服務之間消息流的其他功能。示例包括消息轉換、記錄和路由。

?

圖3：企業服務總線（單擊圖片查看大圖）

如果Dave公司的企業開發和業務部門決定，實現其旅行應用程序的重要性足以為其提供資金支持，那么這個企業團隊可以實現類似于圖3的應用程序。開發此系統解決方案有以下幾個問題：

1. ? ? ? ? 無法保證企業會對復合應用程序提供資金支持。可能還有其他更迫切的業務問題。

2. ? ? ? ? 系統開發涉及用例、某些形式的過程建模、會見股東等。這些都需要時間。

3. ? ? ? ? 航空公司、酒店以及其他應用程序都在企業之外。企業會非常慎重地考慮建立業務到業務的連接。即使業務合作伙伴實現了Web服務，企業也需要建立Web服務與合作伙伴交互的授權規則和審核。企業將需要支持用戶身份管理、聯合身份驗證以及資料供應，因為不僅管理員工在企業內部的身份，還要管理其在多個航空公司以及酒店中的身份。

4. ? ? ? ? 針對各個員工的喜好定制解決方案是非常復雜的。員工無法進行“DIY”定制。應用程序位于中央企業服務器上。IT專業人員定義和修改業務過程，而不是Dave。

如果Dave能夠實現一個簡單的個人版本的系統解決方案，這的確非常酷。如果我們概括ESB并將其視為一種為系統企業開發進行了優化的服務總線，那么我們同樣可以設想一種為機會開發進行了優化的服務總線。這就是Interne服務總線（ISB）。ISB更像是一個無處不在的分子。ISB將設備彼此鏈接、將設備鏈接到本地服務器、將網站鏈接到網站、將ESB鏈接到ESB，而且它本身就是一個ESB。ISB是一個用于“DIY”復合應用程序和業務過程的平臺。ISB還是一個軟件即服務(SaaS)的示例。

?

Internet服務總線

圖4概述了Internet服務總線的概念。（ISB的一個早期示例為BizTalk Services；請參見參考資料。）ISB提供商類似于PHP網站托管公司。它們都提供在動態的應用程序平臺。PHP Web托管站點主要提供用于開發動態網站和與數據庫交互的Web服務的平臺。相比之下，ISB提供的平臺用于創建和部署集成其他站點提供的服務的復合應用程序。ISB、PHP Web托管公司以及服務型存儲（如Amazon的S3）都是支持基礎結構軟件即服務的應用程序的示例。這與Salesforce.com不同，它在一開始就封裝為軟件即服務的應用程序。

核心ISB概念構建在統一資源標識符(URI)空間上。Dave的團隊處理了應用程序注冊問題，“擁有”了URI：http://ISB.net/DaveAndTeam。此根目錄下的URI表示應用程序集成點，它類似于Java Messaging Service中的目的地、面向消息的中間件中的隊列，或者發布/訂閱系統中的主題。團隊通過將策略和功能與URI相關聯開發了一個ISB應用程序。此復合應用程序是一組URI、策略和功能。ISB提供了身份和訪問功能，用于控制哪些消息可以由誰發送給URI。身份和訪問功能就是將策略與URI關聯的示例。

例如，Dave可以選擇保留公共網站上某個顯示其旅行預訂的wiki頁面。Dave會希望控制對此wiki頁面的訪問。在他的個人網站上建立和維護身份驗證和授權數據庫是非常單調乏味的。如果Dave在多個網站上都有頁面和數據，則這個問題會變得更復雜，例如：

l? 驅動PHP站點的個人數據庫

l? 使用http://www.twiki.org/構建的一系列協作門戶

l? 存在于某個個人空間站點，如Windows Live Spaces (http://home.services.spaces.live.com/)。

?

圖4：Internet服務總線（單擊圖片查看大圖）

Dave的朋友Don可以注冊ISB的身份組件并且創建一個用戶ID don@foo.bar。Dave可以使用該身份組件的Web UI指定Don可以訪問Dave的哪個ISB URI。Dave還可以定義組并授予組訪問權限。Don登錄到ISB之后便可以訪問URI。ISB簡化了Dave的安全管理，因為他可以維護一個中央數據庫，然后授予“ISB”訪問其wiki以及其他資源的權限。ISB通過對其前面的ISB URI進行訪問控制保護實際資源。ISB的優勢在于，Dave擁有一個空間，可以定義和維護Web上所有與其“服務”有關的身份、組、資源以及訪問策略。

我們剛剛已經討論了通過網頁的顯式用戶操作。另一種比較常見的方法是讓參與復合應用程序的端點上應用程序使用Web服務API訪問ISB。

身份組件還將支持WS-Security的Security Token Service (STS)功能以及與其他STS的聯合。這樣便允許Dave管理未向ISB注冊的身份的訪問。如果foo.bar是一個Dave信任并且實現了STS的公司，則Dave可以為經過foo.bar身份驗證的身份定義訪問策略。

一段時間之后，ISB將提供可以連接到URI的其他策略和實現。示例可能包括WS-Reliable Messaging或隱式消息記錄。此概念類似于服務質量策略與面向消息的中間件的關聯。

ISB構建于身份和訪問功能之上，為應用程序（甚至包括位于防火墻之后的應用程序）提供“安全普遍的連接性”。這包括對廣泛的連接性模式和協議的支持。示例包括面向REST的HTTP、WS-*以及很多企業應用程序中的事件驅動模式。確切的說，ISB的連接性組件還提供了三個核心功能：

l? 中繼，使ISB和防火墻之后的應用程序之間能夠通信。有很多技術可實現該功能（Biztalk Labs，請參見參考資料）。中繼功能不再需要為簡單方案建立系統跨企業連接。

l? 協議，提供一組用于交換消息的公共協議，如WS-*或REST。ISB還提供使用不同協議自動連接端點的協議映射。例如，可以將RSS feed連接到WS-*消息連接，而不必修改任何應用程序。

l? 功能，支持將簡單的類似于ESB的功能與URL關聯。示例可能包括多播、WS-Eventing、持久消息等。

連接層在基礎結構技術級別上運行。它避免了由于不同的“plumbing”（例如，REST與WS-*）而引起的復雜性，從而簡化了解決方案開發。必須在該級別實現的基礎結構集成的項目會導致大量成本和風險。ISB解決了這些問題。

連接層不感知應用程序級別元素和消息格式。構建復合應用程序要求適應連接的服務所實現的各種消息格式。ISB功能的一個示例就是將HTTP GET中的參數轉換為XML消息中的元素。ISB提供一個簡單的工作流程（服務編排），該流程提供對應用程序級別映射的支持（圖5）。

?

圖5：ISB消息處理（單擊圖片查看大圖）

ISB為簡單的功能提供了一組模板“活動”。工作流程是一個由實例化的活動模板組成的圖形。假設航空公司通過RSS feed發出了航班狀態，并且Dave的部分應用程序希望收到WS-Eventing通知以便更新。連接層支持將RSS與WS-*集成。仍然有必要將消息負載從RSS格式轉換為Dave的應用程序所期望的XML事件格式。通常，ISB將提供一個可配置的、可重復使用的活動模板，用于將RSS轉換為XML映射。

另一個常見的活動模板是基于選擇的路由。Dave的應用程序可能發出一個取消汽車預訂的消息（ID=1234）。如果一個城市汽車服務的預訂代碼以“LE-”開頭并且另一個以“OL”開頭，則Dave的應用程序可以將取消事件發送到一個ISB URI。然后，選擇器處理該消息并將其路由到相應的端點。

組合這些活動以便處理更復雜的消息是非常有用的，這將是ISB的一個共同功能。作為示例，圖6顯示了Dave定義的用于接收取消汽車預訂消息的URL上的活動：

1. ? ? ? ? 使用WS-*接收XML格式的取消消息。

2. ? ? ? ? 提取預訂ID元素并在表中查找前綴。

3. ? ? ? ? 將消息轉換為城市汽車服務的期望格式，即

a) ? ? ? 用于某個提供商的HTML電子郵件

b) ? ? ? 用于另一個提供商的HTTP POST。

?

圖6：ISB消息處理（單擊圖片查看大圖）

構建消息處理功能非常簡單。很多常見應用程序方案都是模式和模板的簡單實例。ISB提供商將提供一個簡單的基于Web的應用程序開發工具，該工具允許開發人員通過Web表單選擇活動模板并設置配置參數。對于路由，Web表單將允許開發人員指定路由表中路由的消息字段和值。一段時間之后，ISB將提供更強大的工具，如BizTalk中的消息處理工具。

消息處理（路由、轉換等等）的功能非常強大，足夠供很多應用程序方案使用。但是，對于其他應用程序來說，需要進行簡單的順序和流程控制。考慮當Dave進退兩難時在達拉斯預訂酒店的任務。該過程的簡單描述如下：

?

1. ? ? ? ? 向酒店鏈AAA發送預訂請求

2. ? ? ? ? 接收響應。

3. ? ? ? ? 如果成功，則退出

4. ? ? ? ? 向酒店鏈BBB發送預訂請求

5. ? ? ? ? 如果成功

?

工作流程活動借助控制流（while、if ... then …等等）的活動模板擴展消息處理。ISB將不斷增加對簡單工作流程的支持，以擴展基本消息處理。

工作流程似乎是比較復雜的概念，系統企業工作流程解決方案功能強大，但比較復雜。但大多數專用應用程序、機會應用程序的工作流程都非常簡單。結構并不比簡單的PowerPoint圖表復雜。存在很小的一組“剪貼畫”用于連接和圖形，開發人員在圖形上設置屬性以表達活動的行為。

大多數工作流程傾向于使用嵌入的列表結構。這樣便可以使用簡單的工具構建工作流程。簡單的XSD可以提供定義嵌入列表的工作流程XML文檔的結構。虛擬工具允許開發人員指定活動及其實現，或者對外部服務的連接。很多開發人員都熟悉此模型，原因是Web UI框架通常提供類似的頁面流和轉換的概念（例如，Struts）。

系統工作流程解決方案通常比較復雜，因為它們都是任務關鍵型解決方案，支持許多人使用的應用程序。過程建模和引擎必須能夠表示過程的所有功能，并且能處理復雜的錯誤條件、審批等等。相比之下，對于大多數專用機會解決方案，很少人使用此工作流程，因此該團隊不斷修補它以便進行改進。

?

服務級別目標

在ISB上部署應用程序的企業希望定義服務級別協議(SLA)，用于指定響應時間、吞吐量、可用性等等。SLA將確定ISB提供商收取的費用。為任意應用程序實現SLA這一常規問題常讓人感到棘手。但是，ISB的任務更加簡單，因為它不部署任意用戶代碼。為策略、發布/訂閱、工作流程活動等實例化和配置的預定義模板限制了應用程序。這簡化了實現SLA、可預測成本以及完整性的過程。

?

機會應用程序的軟件和服務的參考架構

圖7展示了一個高級概覽，將本文所述的內容結合在一起。首先，Internet服務總線是無處不在的，它連接所有系統和服務器。將存在很多復合應用程序，這些應用程序中的一些元素在“ESB”上，另一些在ISB上。多組織復合應用程序是一個非常明顯的示例，它可以動態將元素部署到ISB上。另一種可能是在短時間內存在一個組織復合應用程序。例如，企業使用復合應用程序管理內部會議。與獲取、安裝、配置和支持硬件和軟件以“靜態”運行應用程序相比，重新使用預先配置且“動態”安裝的軟件平臺效率更高。

?

?

圖7：生態系統和業務模型（單擊圖片查看大圖）

如果企業在多個會議中重新使用專用應用程序，則系統解決方案可能來自于機會解決方案。機會解決方案為系統解決方案提供了一組具體的用例。它還可以提供一些指標，用于確定應用程序的哪些方面經常使用。

第三方將增值服務連接到ISB。第一種類型的服務將是基礎結構服務，如更強大的工作流程引擎或支持XML查詢的數據庫。開發人員可以將服務連接到其應用程序中的URI，以在其解決方案中包含這些服務。這些基礎結構服務說明了第三方如何通過提供高級基礎結構作為服務加入生態系統。

第二種類型的服務將是可重復使用的業務服務，例如，用于維護產品信息和目錄的預建服務。另一個示例可能是安排集會的會議室。這個示例說明了第三方如何通過添加應用程序“構建塊”服務加入生態系統。ISB復合應用程序可以將復合應用程序中的URI連接到構建塊服務，以便使用構建塊。

最后，系統集成商和解決方案提供商將提供可配置的、可擴展的解決方案，即模板。第三方可能提供支持很多會議/大會管理功能的可配置的解決方案。封裝的應用程序供應商可以支持“試用”。潛在客戶只需“動態”實例化某個版本即可，無需發布需要安裝應用程序和先決條件的CD。

社區是Web 2.0的一個重要方面。實際上，它是最重要的方面。基礎結構服務、基本應用程序構建塊以及解決方案模板也將通過與提供和共享代碼的ISB關聯的社區出現。社區還提供論壇，以支持自助服務并建立“軟件即服務”供應商的名譽。

軟件+服務

整個“軟件即服務”是一個神話。所有有意義的SaaS解決方案最終包含一些內部（on-premise）軟件，即它是混合的。實例化解決方案的某些元素將位于總線（例如，工作流程）中，一些元素位于連接到總線的服務中（如XML內容管理系統），一些元素將在內部“安裝”。幾乎所有使用ISB和SaaS的方案實際上都是內部（on premise）和外部（off-premise）軟件的混合。

還有一個例子，請考慮Dave用來在其應用程序中存儲路線的數據存儲提供商。始終使用遠程訪問來讀取/更新路線容易出現問題。存儲提供商將可能提供內部（on-premise）和on-PC軟件包，該軟件包已通過緩存、復制、版本控制等等優化了數據存儲。用一個術語表示混合模型就是“軟件+服務”。

?

結束語

幾種趨勢集合在一起從根本上改變了Web應用程序模型。目前，Web主要用于幫助人們連接到文檔和應用程序。最基本的改變是將Internet和Web作為執行應用程序的平臺這一思路。具有基本編程技巧的專業人員編寫個人應用程序，通過該程序可以更加有效地利用Web。他們將與沒有什么計算機知識的朋友和同事共享這些應用程序。隨之出現了社區，它通過社區提供了傳播個人解決方案“meme”的另一種方法。

不可避免的是，個人應用程序的元素將“走向全世界”。只要原因將是“虛擬”PC的廣泛使用，“虛擬”PC可以根據用戶和附近的設備進行組裝。虛擬PC不是在酒店房間中使用筆記本，而是通過旅行者的手機和TV、Internet連接以及房間中的鍵盤組裝而成。也有可能組裝虛擬機(VM)，��只包含執行特定方案所需的軟件。

VM還提供：

l? 應用程序隔離

l? 實現類似于用戶管理個人計算機的方式的概念模型，進行最終用戶管理。

l? 向外擴展基于多核處理器的自然剝離。

l? 會聚這些趨勢的企業的優勢包括：

l? 大大提高員工效率和士氣。工作不再單調，業務價值任務更加突出，可能還比較有趣。

l? 提高了靈活性和敏感度，因為應用程序開發和修改可能發生在幾小時而不是幾個月之內。

支持這些改變的主要技術就是Internet服務總線。SOA、Web服務和mashup都能夠快速進行復合應用程序開發，這些應用程序集成、定制和擴展了基本的應用程序構建塊。在Web中支持這些復合應用程序是下一個重要飛躍，也是Web 2.0的核心方面。實現這個前提的關鍵元素在于Internet服務總線。除了支持靈活的應用程序開發之外，ISB還支持軟件提供商的生態系統。ISB的功能支持“編程”專業人員的加入，尤其支持自下至上通過社區開發長期應用程序。計算領域的統一理論是軟件和服務，而ISB是此新應用程序模型的基礎。

?

參考資料

l? Biztalk Adapter http://(zh-cn,2.microsoft.com/zh-cn/library/aa744368.aspx

l? Biztalk Labs http://labs.biztalk.net

l? 企業應用程序集成(EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration

l? 企業服務總線http://en.wikipedia.org/wiki/Enterprise_service_bus

l? Mashup http://en.wikipedia.org/wiki/Mashup_(web應用程序混合)

l? 模型視圖控制器http://en.wikipedia.org/wiki/Model_view_controller

l? OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/

l? SAP RFC http://en.wikipedia.org/wiki/ABAP

l? 直接處理http://en.wikipedia.org/wiki/Straight_Through_Processing

l? Struts http://struts.apache.org/

l? 用例http://en.wikipedia.org/wiki/Use_cases

l? WS-Eventing http://www.w3.org/Submission/WS-Eventing/

l? WS-Security Security Token Service http://sts.labs.live.com/

l? Zorro的ISB博客http://zorroisb.spaces.live.com

?

關于作者

Donald Ferguson博士是Microsoft CTO辦公室負責平臺與策略的高級研究員（Technical Fellow）。Don主要從事業務上發展和改革信息技術的角色。加入Microsoft之前，Don曾經是IBM Fellow和IBM軟件集團(SWG)的首席架構師，他主持SWG Architecture Board，主要研究產品集成、跨產品計劃以及新出現的技術，包括Web服務、模式、Web 2.0以及業務驅動開發。Don的主要愛好是Kenpo空手道。他在2005年12月贏得了黑帶。

Dennis Pilarinos是Microsoft的互聯系統分部的高級技術主管。您可以從他的博客www.dennispi.com上詳細了解有關他的工作。

John Shewchuk領導Microsoft互聯系統分部(CSD)的技術戰略團隊。在CSD中，John已經開發了Microsoft的應用程序平臺，包含在應用程序消息技術（如Windows Communication Foundation）、Web服務互操作規范（如WS-Security）以及身份和訪問技術（如InfoCard）方面的工作。John協同成立了Indigo團隊并且已經成為跨行業互操作方面的主要驅動力。John與Indigo團隊的其他人員一起領導了Web服務架構和規范的開發，并管理與廣泛行業合作伙伴的技術協商。

嵌入式通用行業應用平臺的靈魂和搭建

快速原型開發模式在實際開發過程中的應用

【摘要】本文以作者的實踐開發經驗為主線，從理論和實際的角度探討快速原型開發模式在實踐開發中的應用，并從軟件開發的各個角度、各個時期剖析快速開發模式的優缺點和應該注意的問題。

【關鍵字】軟件工程、開發模式、快速開發、軟件開發、原型模式

? ??快速原型開發模式的基本思想是在系統開發的初期，在對用戶需求初步了解的基礎之上，以快速的方法先構造一個可以工作的系統原型。將這個原型提供給用戶使用，聽取他們的意見。然后修正原型，補充新的數據、數據結構和應用模型，形成新的原型。經過幾次迭代以后，可以達到用戶與開發者之間的完美溝通，消除各種誤解，形成明確的系統定義以及用戶界面要求。

了解快速原型開發模式后，下面結合我開發過學分制收費管理系統項目經驗來談一下我是如何在實際開發過程中實施快速原型開發模式。

【項目背景】

隨著國家教育事業的發展，很多高校紛紛引進學分制教學體制模式。我所在的學校為跟上時代的步伐，經市教委批準，從2008-2009學年試行學分制改革，2009-2010正式運行。以傳統的教學模式相比學分制教學模式有很多明顯的優勢，學生的自由度也得到了很大的提高。然而一種新的教學模式要取代傳統的教學模式，勢必會存在很多麻煩和問題。其中學分制教學模式下的收費方式與傳統的收費方式就存在很大的差異，任然沿用傳統的收費方式已經無法滿足學分制改革的要求，因此為推動學分制改革，制定一套符合學分制教學要求的收費管理系統勢在必行。有幸這個項目由我們團隊負責開發。

然而事情遠沒有想象那么簡單，學分制改革是學校的大事情，需要財務處、教務處、學工部等行政部門的支持和各二級學院的配合。學分制收費更是與各個部門、學院和學生兮兮相關。試分析可以發現：待制定的學分制收費管理系統必須做到把財務處的各項收費標準信息、教務處的學生選課信息和學工部的助學貸款、緩繳學費、參軍等學生信息緊密的糅合起來，并計算出學生預繳費用。由于涉及到的部門比較多，各部門領導又并不具備專業的軟件知識，提出的需求并不明確或則是根本無法系統化。如果采用瀑布模式或則是演變模式進行開發，顯然會存在著很大的風險，介于此、經項目組研討決定采用快速原型開發模式進行項目開發。

【具體實施】

㈠????? 開發工具選擇

?經項目研討后我們決定選擇.NET平臺采用ASP.NET+AJAX+SQL SERVER2000技術進行開發。主要原因是.NET平臺具有一下優勢：

⑴、技術領先??

? .Net技術于2001年由微軟公司推出，與Java構成當前最主流的開發平臺，.Net對XML、Web Service、AJAX提供很好的支持，而且，提供了更為便捷的開發、調試、部署環境，同時，與微軟的BizTalk、Office、SQL Server2000等系統可以無縫銜接。??

??⑵、安全性??

? .Net是構建于操作系統之上的虛擬平臺，提供了更為強健的安全系統。在系統當中，提供集成Windows驗證、基于角色的權限管理機制、SSL傳輸加密、MD5數據加密等多種安全手段，以提高系統的安全性。??

?⑶、穩定性??

? 作為24*7運行的系統，除了提供良好的性能之外，系統的穩定性也非常重要，系統采用如下方法提高系統性能及穩定性：??

? ??①Web服務器采用Windows 2003+IIS6?? ??

?? ?②模板系統：更新不頻繁的數據使用模板系統生成靜態頁面，減少數據庫壓力??

?? ?③站點緩沖：頻繁更新的數據，使用緩沖以提高訪問速度，減少數據庫壓力??

? ??④系統日志：再好的設計都會有bug，系統日志記錄程序運行過程中產生的異常，以方便調試系統，發現潛在的bug ??

??⑷、擴展性??

? 采集4層結構，分為數據訪問層、業務邏輯層、業務外觀層、表現層，各層之間嚴格遵守"高內聚、低耦合"原則，使系統具備較好的擴展性。??

? 數據訪問層：完成基本的CRUD（Create/Read/Update/Delete）操作。??

? 業務邏輯層：完成各種業務規則和邏輯的實現，調用數據訪問層完成CRUD操作。??

? 業務外觀層：為表示層提供統一的訪問接口，分離界面和具體的業務功能。??

? 表示層：分為B/S和C/S兩中表現形式（暫時只實現了B/S一種模式）。??

? 多層分布式設計，當業務和訪問量增大時，可以在中間層部署更多的應用服務器，前端部署更多的Web服務器，提高對客戶端的響應，而所有的變化對客戶端是透明的。

?㈡ 項目組成員以及分工

我們項目組由一個項目負責人、一個測試工程師、一個文檔管理員、三個編碼員（其中一個軟件設計師和兩個程序員）。具體分工如下表：

成員	任務		輸出文檔
項目負責人		需求采集①、控制進度、協調用戶關系	學分制收費研究報告
測試工程師		集成測試、總體測試	測試報告
文檔管理員		編寫用戶手冊、編寫操作手冊、軟件服務制定	用戶手冊、操作手冊 軟件服務說明書
編碼員		軟件設計師：需求分析、數據庫設計、軟件架構、核心代碼編寫、配合集成測試和總體設計、任務劃分、編碼質量控制	需求分析報告、系統設計書、詳細設計、軟件規范說明書
		其他兩個編碼員：單元代碼的編碼、單元測試
?	?	?	?

很榮幸我擔任的是軟件設計師的職務，在此感謝項目組對我的信任。另外在項目研討的時候，根據項目開發時間緊迫、需求不好把握、需不斷的構造軟件原型等特點，我們打破常規，將原本屬于編碼員完成的集成測試任務全部劃分給了測試工程師，測試工程師也只需將每次測試結果當做一種需求的方式返回給我們，我們再根據返回的需求微調程序，微調后的程序就基本上能滿足要求。但這樣做有個很大的前提就是測試工程師要對需求相當成熟。

①項目負責人通過與各部門領導溝通和軟件演示的方式來采集用戶需求。???????????????????????????????

㈢工作流程以時間安排

??????? 項目負責人通過與各部門領導的溝通和實際調查，初步確定了軟件需求，并提交學分制收費研究報告，同時把軟件的核心功能定位于“計算學生的預繳費用，并將這些數據提供給財務收費系統（以.XLS文件導入、導出）”。隨后經各部門領導協商，定于4.20日正式提交軟件，如果軟件能滿足要求則立即投入使用。時間很緊迫，為保證第二次原型開發具有充足的時間，經項目組討論決定制定了以下的工作安排。

項目名稱：學分制收費管理系統????? ?任務安排表

任務代碼 / 名稱	交付的文檔	人員	計劃
			開始	結束	工期(天)
學分制收費管理系統	?	?	2009.2.9	2009.4.19	69
?T1 確定初步需求	學分制收費研究報告	項目負責人	2009.2.14	2009.2.28	14
?T2 項目研討會	?	項目組成員	2009.2.28	2009.3.1	1
?T3系統設計	需求分析、系統設計、詳細設計、系統規范說明	軟件設計師	2009.3.2	2009.3.9	7
?T4第一次原型構建	?	編碼員	2009.2.9	2009.2.16	7
?T5集成測試	測試報告	測試工程師	2009.3.16	2009.3.17	1
?T6程序微調	?	編碼員	2009.3.17	2009.3.18	1
?T7軟件演示	需求分析報告	項目負責人	2009.4.18	2009.4.19	1
?T8項目研討會	?	項目組全體成員	2009.3.19	2009.3.20	1
?T9需求調整	?	軟件設計師	2009.3.20	2009.3.21	1
T10第二次原型構建	?	編碼員	2009.3.21	2009.4.4	14
T11集成測試	測試報告	測試工程師	2009.4.4	2009.4.5	1
?T12程序微調	?	編碼員	2009.4.5	2009.4.6	1
?T13第二次演示	需求分析報告	項目負責人	2009.4.6	2009.4.7	1
?T14項目研討	?	項目組全體成員	2009.4.8	2009.4.9	1
?T15軟件完善	?	編碼員	2009.4.9	2009.4.14	5
?T16集成測試	測試報告	測試工程師	2009.4.14	2009.4.15	1
?T17程序微調	?	編碼員	2009.4.15	2009.4.16	1
?T18總體測試	測試報告	測試工程師	2009.4.16	2009.4.18	2
?T19測試微調	?	編碼員	2009.4.18	2009.4.19	1
?T20文檔整理	用戶手冊、操作手冊、軟件服務說明書	文檔員	2009.3.22	2009.4.12	21
?T21軟件提交	?	項目負責人	2009.4.19	2009.4.20	1

在具體的實施的工程當中，我們依照任務安排表嚴格執行，經過兩個多月的開發，學分制收費管理系統終于完成，并在第二次軟件演示的時候得到了各部門領導的一致好評。

【存在的不足】

雖然開發的系統得到了各部門領導的好評，但在整個開發工程當中仍然存在很多不足。我總結了主要有以下幾點：

①某些關鍵的細節^⊕在最開始就被忽略，這導致了后期為彌補這個細節花費了大量的時間，同時影響了隊員的信心。

②程序員經驗不足，對需求的理解能力稍差，有時候開發出來的某些復雜的模塊根本不能滿足要求，這無形中增加了需求溝通和程序修改的時間。

③對捕捉程度不夠清晰，有時候需求過大，需要的開發時間較長，很難在預定時間內完成，只得加班加點。但有時需求較少，需要的開發時間較少，預先安排的時間有空余。這種情況使得程序員作息正常的作息時間被打亂，雖然開發進度能被很好的把握，但其實開發效率并不高。

?④第一次原型開發初期，由于時間比較緊，對編碼質量沒有進行很好的控制，這導致后期的開發當中常常出現一些莫名其妙的錯誤（比如某個模塊運行時間過長）。

⊕數據表中的某一個字段不清楚到底該如何處理時將其忽略。

? 【后期總結】

雖然在開發的過程當中存在一些不足，但我仍然學到了很多東西，同時也第一次正真的體驗了快速原型開發模式在實踐當中的應用，這次的經驗在我今后的工作當中也都將產生深遠的影響。在項目結束時，關于快速原型開發模式在實踐當中的應用，我總結以下幾點值得參考性的意見。

①在選擇項目組成員時，應該本著“少而精”的原則。

②在軟件開發之前，必須提出核心需求，進而確定軟件的核心功能。

③在軟件開發之前，對開發需時進行認真評估，制定一張符合實際的任務安排表，保證隊員正常作息時間。

④在軟件開發的過程當中，應嚴格控制原型的構建次數（建議只構建三次），一般在第一次軟件演示后就應該基本確定用戶需求，第二次軟件演示的時就應該基本滿足用戶需求，第三次軟件演示后再通過一些細節方面的修改就可以交付。

⑤對于某些暫時模糊的關鍵性細節應予以認真記錄和分析，影響力大、需及時解決的細節必須及時解決，暫時不忙解決的應將涉及到這個細節的所有功能模塊放在下一次原型構造時才進行開發與解決。

⑥如果開發時間很緊迫，測試工程師應跟蹤測試，確保測試與開發同步。

公用對象請求代理（調度）程序體系結構(CORBA)

UML軟件設計基礎(UML圖詳解)

UML軟件設計基礎(UML圖詳解)

作為一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。(1) UML語義　描述基于UML的精確元模型定義。元模型為UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。(2) UML表示法　定義UML符號的表示法,為開發者或開發工具使用這些圖形符號和文本語法為系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。標準建模語言UML的重要內容可以由下列五類圖(共9種圖形)來定義:·第一類是用例圖,從用戶角度描述系統功能,并指出各功能的操作者。·第二類是靜態圖(Static diagram),包括類圖、對象圖和包圖。其中類圖描述系統中類的靜態結構。不僅定義系統中的類,表示類之間的聯系如關聯、依賴、聚合等,也包括類的內部結構(類的屬性和操作)。類圖描述的是一種靜態關系,在系統的整個生命周期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期,因此對象圖只能在系統某一時間段存在。包由包或類組成,表示包與包之間的關系。包圖用于描述系統的分層結構。·第三類是行為圖(Behavior diagram),描述系統的動態模型和組成對象間的交互關系。其中狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件。通常,狀態圖是對類圖的補充。在實用上并不需要為所有的類畫狀態圖,僅為那些有多個狀態其行為受外界環境的影響并且發生改變的類畫狀態圖。而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系,有利于識別并行活動。·第四類是交互圖(Interactive diagram),描述對象間的交互關系。其中順序圖顯示對象之間的動態合作關系,它強調對象之間消息發送的順序,同時顯示對象之間的交互;合作圖描述對象間的協作關系,合作圖跟順序圖相似,顯示對象間的動態合作關系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關系。如果強調時間和順序,則使用順序圖;如果強調上下級關系,則選擇合作圖。這兩種圖合稱為交互圖。·第五類是實現圖( Implementation diagram )。其中構件圖描述代碼部件的物理結構及各部件之間的依賴關系。一個部件可能是一個資源代碼部件、一個二進制部件或一個可執行部件。它包含邏輯類或實現類的有關信息。部件圖有助于分析和理解部件之間的相互影響程度。

     配置圖定義系統中軟硬件的物理體系結構。它可以顯示實際的計算機和設備(用節點表示)以及它們之間的連接關系,也可顯示連接的類型及部件之間的依賴性。在節點內部,放置可執行部件和對象以顯示節點跟可執行軟件單元的對應關系。

從應用的角度看,當采用面向對象技術設計系統時,首先是描述需求;其次根據需求建立系統的靜態模型,以構造系統的結構;第三步是描述系統的行為。其中在第一步與第二步中所建立的模型都是靜態的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形,是標準建模語言UML的靜態建模機制。其中第三步中所建立的模型或者可以執行,或者表示執行時的時序狀態或交互關系。它包括狀態圖、活動圖、順序圖和合作圖等四個圖形,是標準建模語言 UML的動態建模機制。因此,標準建模語言UML的主要內容也可以歸納為靜態建模機制和動態建模機制兩大類。

1、UML 類圖UML類圖模型類型表明了模型元素，如類，對象，界面等，之間的靜態關系。UML 類圖對類進行了定義。對這些類，對應的操作（方法）和屬性可以用成員關系進行分配。類與類之間的關系也在UML 類圖中進行了表達。這種關聯是二元關系，是在類與類之間直接發生的。在這里，用菱形標志表示的插入的關聯被用于表示多重關系。如果這一關聯就是一個類，則可以使用關聯的供給屬性。關聯的多重性可以被輸入到關聯連接的多重性（Src）和多重性（Trg）屬性中。在UML語言中, 集成和復合表示特殊的關聯。它們經過關聯之間的連接入口而標明，并由關聯之間連接的尾部的一個小白色(集成) 或黑色(復合) 菱形標志表示。關于這一點的范例，可參見圖5.2.1.1-1類圖—關聯。

?

圖5.2.1.1?1 UML 類圖 – 關聯

?

??? 類與類之間的繼承性關系被表示為一般關系，由三角形標志來表示。分配到優先類的屬性和操作將會被傳遞到下一級次的類中。關于這一點的范例，可參見圖5.2.1.1-2: UML 類圖—繼承性關系。

圖5.2.1.1-2:UML 類圖 – 繼承性關系

?

??? 在UML 類圖中另外的模型元素有程序包，用于組合模型元素；注釋，用于說明一些模型中的補充信息；對象，用于說明類的實例；以及界面。每個界面描述的是一個類的界面(支持連接)。通過對界面的調用 (調用連接), 其他的類也可以使用這個被界面支持的類。

?

2、UML類描述圖

???? UML類描述圖模型類型是標準UML圖的一個補充。它對類進行了更加精確的說明。UML類描述圖的建模選項UML 類圖選項的一個子集，舉例說明，所有UML 類描述圖的建模選項在UML 類圖中葉都具有。屬性，操作，注釋，對象，和界面的類都可以在UML 類描述圖中得到分配。這種分配也可以在UML 類圖中進行，但是一旦UML類圖圖形過載，就需要提供UML類描述圖獨立的建模方法。在這種情況下，UML類描述圖必須被定義為UML類圖中類的分配。總的來說有關聯，但在UML類圖中非必須的屬性，操作，注釋，對象以及界面，就可以被移植到UML類描述圖中來。

?

? 3、UML使用案例圖

?????? UML使用案例圖對應用案例(使用案例) 和使用者，即，它所包括的受到使用案例影響的對象，進行了說明。使用者就是指使用應用系統來完成任務的用戶。UML使用案例圖從用戶的角度對系統的內部行為進行了說明。在ARIS體系中，使用者是作為人類對象類型來實現的。

?

??? 使用者與使用案例之間的聯接是一種通信關系。這表明了使用者執行完成使用案例的關系。使用案例之間的聯系由一種概括關系所決定，這種關聯用一個三角形點來表示。所需要的語義可以被分配到這種關系的舊版屬性里去。UML 標準建議在擴展和使用中使用舊版。比如說，在異常條件下，擴展說明了一個使用案例擴展了另一個使用案例的應用范圍的這種擴大了的關系。使用說明了一種使用的關系。舉例說明，一個使用案例使用了另一個使用案例的應用案例說明，使得它可以被重新利用。圖5.2.3-1 表現了UML使用案例圖的一個樣本模型。另外，程序包和注釋對象類型在UML使用案例圖中也是可得到的。

Figure5.2.3?1 UML使用案例圖

?

4、? UML 活動圖

?????? UML 活動圖把整個過程按活動順序進行了說明。在UML語言中，活動一般指的就是對象。因此，活動圖被分配為到類，操作，或是使用案例，并且對相關的內部過程進行了說明。

??? 因為活動圖被認為是一種自動狀態的特殊形式，一個活動圖過程從一個初態開始，并以一個末態結束。活動表示了一種有內部動作和一個或更多輸出轉換的狀態。這種轉換是用活動之間的產生聯接關系來表示的。一個活動與其他活動之間的關系可以是簡單的，也可以是多層的輸入與輸出關系：

?

?????? 1.???? 多重出站關系可以被表示為條件。在這里要使用到決策符號（菱形）。用決策符號對一個條件建立模型是可選擇的；或者，用戶也可以只對幾個出站聯系建立模型。我們建議用戶保持激活前驅站關系的連接角色屬性，并把它表示在圖中。

?

?????? 2.???? 分割/同步符號（豎直或水平劃線）可以用來同時激活幾個相繼的活動，或是當某一活動的前期活動轉換完成后再將其激活。

??? 活動可以被認為是特殊的對象狀態并創造一些特殊的對象狀態。對象的狀態可以用對象狀態對象類型來說明，這種類型以與活動的關系的形式含有已經輸出和已經輸入聯接（劃線箭頭）。

?

??????? UML 用所謂“泳道”來說明執行活動的組織職責。泳道就是以一欄列出所有組織單元所負責的活動。為了這一目的，ARIS UML 活動圖預先定義了一個兩欄的圖表。對活動所負責的組織單元（無論是一個內部人員，方位，人員類型，或是組織單元，或是工作組）在頂上一欄，在底下一欄里則是它所負責的活動，決策，分割/同步，對象狀態和注釋符號。

?

圖5.2.4-1:UML 活動圖表現了一個 UML 活動圖及其相關組成部分。

圖5.2.4-1:UML 活動圖

5? UML 狀態圖

??? 與UML 活動圖一樣，UML 狀態圖也對自動狀態和相似情況進行了說明。然而，狀態圖的焦點更多的集中在對象的狀態上面。它說明了一個對象在它的存在過程中所要承擔的狀態的順序。不僅如此，它也包含了與此狀態相關的一些動作。這些動作或者是進入狀態（進入/）的先決條件，或者在這種狀態中執行完成（執行/），或者是在離開這一狀態時執行（退出/）。

?

???? ARIS UML 狀態圖提供了一些狀態符號。狀態轉換，也叫轉換，以直接聯接（與…關聯）的方式與狀態之間建立了關聯。同UML 活動圖一樣，一個狀態圖必須以一個初態作為開始，以一個末態作為結束。圖5.2.5-1: UML 狀態圖?表示了一個UML 狀態圖。

?

圖5.2.5-1:UML 狀態圖

?

6? UML 協作圖

??? 對象之間以信息交換形式表現的交互作用在UML協作圖0中得到了說明。對象，也叫實例，是類中較為具體的樣本。信息交換的模型是通過一個與聯接有關的交互作用來建立的。與聯接有關的交互作用的精確含義是通過以下概念的出現建立的：條件，信息號，操作，和參數等屬性。這些屬性的功能如下所示：

?

條件:條件即一種特殊的信息，這種信息在當前信息能夠被發送之前必須被發送出去。這種信息以及其信息號是以列表的形式給出的。如果不存在這種先決性的信息，條件就是不必要的了。每一個條件與它的信息號之間是以一條斜杠(?/“)被分隔開的。

????信息號: 信息號是在圖表中標識一體哦信息的唯一號碼。信息是以升序排列的。如果一個操作正在處理接收到的信息，同時它也送出了幾條信息，舊的號碼就會以一個單獨的“子號碼”作為補充。(例如：一個操作接受到了信息3.4，并以號碼3.4.1 和3.4.2送出了兩條信息)。信息號與操作之間以冒號（“：”）分隔。

??? 操作：表示所給出的即將被執行的對象的類的操作。

??? 參數：?參數對被調用的操作參數列表進行說明。參數列表被表示在括弧中。

?

例：1.3, 2.1 / 3.2.1：計算凈值(總量，比率)????
??? 在這里，信息1.3 and 2.1 是條件，信息號就是 3.2.1這個數字，所要進行的操作就是計算凈值，并且這一操作還含有總量和比率這兩個參數。

?

圖5.2.6-1:UML 協作圖

?

7? UML 成分圖

?????? UML 能夠對與以圖表格式出現的實現過程有關的方面進行說明，如代碼結構(成分)與系統運行時間結構（配置）。在ARIS體系中， UML 成分圖就是為了實現這一目的而設計的。

??? 成分是在編譯或連接的時候，或是在系統操作的時候組成單元的項目。例如，可執行文件。成分之間第一種類型的聯系表現的是成分的物理結構。一個成分也可以包含另外一個成分，這在它們之間的包含關系中得到了體現。成分之間的第二種類型的聯系就是所謂的關系。一個成分通過界面對另一個成分進行調用，用一個小圓圈表示。提供界面的成分與支持關系連接（單劃線），使用界面的成分與之通過一種調用關系進行連接（長箭頭）。

??? 當系統運行時也仍然可以進行成分配置（配置）。為了實現這一目的，對成分進行了分組，并分配到各個程序包（也叫節點）中。這種分配是通過成分與其程序包之間的包含關系完成的。以圖解的方式把成分放入程序包對象的方法也是非常可取的。

?

圖 5.2.7?1 UML 成分圖示例

表現了一個UML成分圖的實際例子。

圖5.2.7?1 UML 成分圖示例

（篇01）企業如何軟件商業化？

企業如何軟件商業化？

【記2010-02-15 清晨 晨跑回】

????? 偶看了多篇商業化的文章，前輩們的思路確實令人佩服！晨跑完，突有想法，覺得有必要談談自己心中的軟件商業化——企業該如何軟件產品商業化？

????? 正如Beacher_Ma所言，作為一個軟件設計師，我同樣經歷過野生派階段—— 學院派階段——商業派階段三個階段的變遷，如今正為周立功公司服務。周立功公司雖然不算純粹的軟件公司，但也有不少的軟件產品和軟件項目。規范之言雖不敢說，但是卻也有可以商業化的軟件、也有可商業化的平臺。

????? 在我看來，軟件企業的主要投資方向有兩種，一種是軟件定制項目——稱為服務型軟件，一種是戰列型軟件——稱為產品型軟件。服務型軟件掙錢快，周期短，生命力并不旺盛。當您接到一個定制項目的時候，該如何進行商業化呢？如下來談談服務型軟件如何商業化?

????? 1、風險評估、認準了才下手

?????? 服務型軟件即定制項目的需求都是千變萬化的，存在很大的風險。如果一個定制項目破產，企業的前期投入將付出東流！這無疑將帶來很到的損失。當一個服務型軟件投入的新技術占整體技術的10%以上，那么這個定制項目將存在風險，利率在大也無須過分留戀。

????? 2、合理的成本預算，實現利率最多化

????? 一些大型的軟件公司認為其實最不掙錢的就是定制項目，為什么呢？因為客戶一旦還沒付清定制項目費用，我方仍然會出于保持合作或其他關系來瞞住客戶的需求，往往這部分的預算未能列入其中，其實依據個人經驗，這部分的投資至少要占整體投資的30%。如果忽略了這部分的預算，那么整個定制項目將無利率可圖。

????? 3、多用通用模塊、提高開發效率

????? 很多軟件公司都意識到定制項目的錢很難掙，周期雖然短，但成本很高。似乎提高效率是唯一的辦法，如何提高效率呢？模塊的軟件思想已經盛行很多年了，但是很多公司卻未能做到，包括我服務的公司。每一個定制項目總是從頭再來，這樣的效率豈不是很低，現在的軟件應該需要站在巨人的肩膀上去構造，巨人的肩膀就是公司的技術沉淀，如果軟件公司不早些抽出通用模塊，必將抵不過市場的競爭。如果公司不多用通用模塊，效率將無法提高。

????? 4、制定服務，延續行業關系

????? 很多公司可能認為，定制項目做完了，收了錢，就不管了。其實這樣做大錯特錯，關系在這個社會是何等的重要啊，軟件定制項目如何來維護客戶端關系呢？只有定制服務，不斷提供升級。其中還能掙到不少的服務費用。曾經有個老師跟我說過了，只要那家公司用過我的軟件，那么他們這一輩子都跟我有扯不清的關系。

??????5、專業需求捕捉，做到行業通用化

??????我一直很欣賞用友軟件公司，他們公司的用友財務軟件做的堪稱中國財務軟件之最。其實用友軟件的前身不過就是一個定制項目，然而這個定制項目確闖入了財務行業，形成規范。很多公司都在做財務軟件，但是為什么沒有成功呢？好好檢討吧，如果你扎住點點需求就瞞住了，如果你做完一個項目就不再去研究這個行業了，那么用友公司將踢你出局。需求捕捉不僅是因為項目需要才進行的，??它也不應該因為項目結束就結束。

?

???? 服務型軟件的公司務必做到上述幾點，小生不自量力！現在就寫到這里了，待續。

（篇02）企業如何軟件商業化？

企業如何軟件商業化？

【2010-02-16 16:27:41 夢醒之時】

?????? 昨天已經更大家談了談服務型軟件如何商業化，似乎欲語未盡。想了想，對于企業如何軟件商業化這個問題只談服務型軟件好像不和情理，畢竟產品型軟件才是市場的主導、企業的命脈。如下談談企業如何實現產品型軟件商業化？

??????對于一個企業而言，都在尋找自己企業賴以生存的產品型軟件。企業沒有產品，sales去賣什么呢？企業的利率又將在那呢？很多企業都發現定制項目不是一個長遠之計，通過定制項目獲取的利率往往只能維持周轉。

????? 用友軟件應該都熟悉吧！飛秋軟件熟悉吧！ QQ 騰訊熟悉吧！這些都很成功，用友公司、新媒傳音、騰訊公司就是憑借這幾款軟件立足于中國軟件之林，并創造為國家巨大的利率。那么他們是如何將自己的產品做的如此成功呢？我認為無非有如下幾點，詳細如下；

????? 1、定位行業、捕捉需求，從小做大

????? 定位行業是什么意識呢？意識就是當一個公司悄悄進入一個行業的時候（或者是因為每個定制項目進入了某個行業），必須進行一個定位（否者隨時將失去一個很好的機會）。行業市場調查過后，如果該行業的軟件趨于飽和就無須留戀，除非你有更好的創意更雄厚的資金。還有一種情況就是該行業很不穩定，牽涉太多太大，它的將來把握在政府手上，這種行業也無須留戀，例如煤礦安全軟件，因為這種軟件需要實時的跟蹤政府制定的政策。那么那種行業應該進軍呢？答案就是成熟或能預測其成熟的行業。

??????如果行業已經定位，捕捉需求尤為重要，很多不成功的需求專家們（自稱），總喜歡將需求做的大做的沒邊，殊不知步驟大了難免出現出現漏洞，或者就是捕捉的需求不切實際。我認為需求捕捉住最好從小做起，先捕捉定制項目的需求，這種需求難度稍微小一點，畢竟有指定的客戶可以咨詢。既然行業已經穩定或則能預測穩定，說明定制項目的需求捕捉后，進步一步的話就能實現通用化了。如果沒有定制項目的需求，那么可以先參照同行的軟件，取其精華，并根據市場調查結果添枝添葉，需求統一后可以請行業專家評審，通過后方可實施。因此這兩步切勿急躁，否則貽害無窮。

????? 2、細分軟件結構、務必理清行業流程

????? 有時候分析軟件的時候，總覺得亂糟糟的。雖然實現的功能很多，但是流程未必清晰。對于行業而言，所需要的功能不許準確，流程一定需要清晰。沒必要的東西就無須放在上面，可能有事后出于美觀的目的，要知道一樣東西看久了未必好看。如果行業工作者使用你開發的軟件之前還有仔細看看幾百頁甚至上千頁的使用手冊，試問還有幾個用戶會賣你的軟件。試問Google 、baidu這樣的搜索引擎為什么看起來那么清爽呢，為什么他們的輸入框設置那么長呢？它們的目的就是要告訴大家，我們是專注搜素引擎，框長告訴大家，您可以輸入更長的關鍵字。試問使用Google、baidu的時候，您還需要使用用戶手冊嗎？

??????3、嚴格控制軟件質量和周期，合理預算

????? 正如服務型軟件一樣，產品型軟件同樣需要控制開發周期，合理預算。如果預算超出了軟件的附加值，那么還有投資的必要嗎？有時候很多公司表面上看似達到什么CMM5，但是其實它們開發出來的軟件質量并不高，主要的原因就是徒有其名!為什么國人總是感嘆國外的軟件做的怎么怎么的好！他們同樣采用 CMM！

?????? 產品型軟件最終總是要進入市場的，它的質量代表的一家公司，一個品牌。如果質量不高那么公司將受到致命的傷害。神舟電腦為什么會落入到現在這種地步，聯想電腦為什么能位居世界第二呢？可想而吧。

??????4、花兩倍的時間測試，提高用戶體驗

????? 問題太大，待今后專門用一章來詳細介紹。

????? 時已至此17:35:35，產品型軟件商業化已經接近尾聲，小生不自量力，忘前輩們見諒。如何進行軟件測試、如何提高用戶體驗，待續！

我眼中的商業軟件開發

2009-11-21 00:38

????? 接到肖哥的邀請，有點突然，呵呵。跟同學們競爭似乎不公平，咱就算蹭個熱鬧，不圖名次。

????? 如果說學習編程就算接觸軟件開發的話，那么從接觸軟件開發到現在也有十來年了。從編程圖個樂，到享受編譯快感，再到混口飯吃，現在是產品就是我兒子，中間經歷了野生派、學院派和商用派幾大派系轉換，想來也挺有意思的，可以把自己的感受匯總起來跟同學們分享一下。

????? 那么，商業軟件開發和非商業軟件開發有什么差異呢？我們先說說商業軟件的特質：

????? 一、商業軟件意味著一種責任
????? 現在圈里炒的火熱的幾大派系之爭，就包括商業軟件和自由軟件之爭。自由軟件多好啊，源碼給你，你可以自己按需修改然后自己構建。最大的好處是，你可以不用花錢就能得到無數行代碼！而商業軟件呢？改個屁大點功能，增加芝麻綠豆似的按鈕，甚至換個自己的Logo，都得出血，關鍵是，你不知道它內部是怎么運作的！……于是人們都覺得自由軟件好，真好，什么都免費給你。其實這同時，責任也給你了，而這是一般用戶扛不起的責任（這個一般用戶幾乎是百分之百）。不要告訴我誰誰誰定制了某個自由軟件給自己用，因為那是沒有普適價值的。Windows源碼泄露這么多年了，我實際了解的效果是有一個開發人員從代碼堆里刨出了軟鍵盤的代碼，嵌進了一個觸摸屏程序中。
????? 商業軟件收費了，賣出了軟件，承擔了責任，一個個軟件機構為了社會中商業系統的的運作奔波在各個公司之間，解決他們遇到的一堆一堆的問題，這就是責任。自由軟件現在也在轉變盈利模式，軟件免費，收服務費，這也是責任，這就是軟件商業化了。

????? 二、商業軟件意味著效率和效果
????? 效率和效果是商業的生命。同樣，商業軟件也必須講求效率和效果。效果，意味著解決問題的品質。效率，意味著還有時間限制。

????? 有上面兩條做鋪墊，對比自己經歷的幾個階段就容易表達了：
????? 責任：
??????????野生派階段：看到某個算法，誒，有味道，搞搞，開飯了，撤，回來興致過了，就搞忘了。
????????? 學院派階段：看到某個技術領域似乎比較潮，Test一把，搞個Demo，能把所關注的核心技術用到，就爽屁了。
????????? 商業派階段：拿人錢財替人消災。不僅要解決當前問題，作為產品化軟件的設計和開發者，還需要顧及到數以萬計甚至十萬記的存量客戶的相同問題的解決。不同的運行環境、網絡條件、使用習慣、誤操作……不怕有問題，就怕補丁發出去是拆了東墻補西墻，被客戶認為態度有問題，那就嚴重了。
????? 于是，在商業派階段，每一個版本都想方設法的把程序搞的健壯一些、可伸縮一些、完善一些、再完善一些。要知道一個丁點兒大的疏忽可能會導致幾十上百萬用戶辛苦的為程序打補丁，那個成本高啊！那個責任重啊！

????? 效率和效果：
????????? 野生派階段：效什么果？效什么率？不就是玩玩嘛。
????????? 學院派階段：效率不重要，咱有的是時間，就是要折騰。效果？能學到東西就成了。
????????? 商業派階段：效率很重要，效果更重要。不能冒風險，不熟悉的技術？慎重；不確定的需求？慎重；測試的不徹底？慎重；代碼沒讀透？慎重再慎重……
????????? 所以，商業派階段，聽過一個老總說到：穩定壓倒一切。

????? 平衡之道
????? 新技術與穩定的平衡之道：其實我也是個追新族，什么新奇技術都會去摸摸、搞搞，但是新技術所帶來的風險和穩定有必然的矛盾：太新，所以了解不透徹，一行代碼下去，會有什么影響心里是沒底的。而技術是為產品服務，產品是為用戶服務，沒有透徹的技術了解，不能做出穩定的產品，就不能為用戶服務。出于這個原因，我對在生產環境使用新技術是有自己的平衡之道的：每一個版，引入新技術的部分不能超過本版變更的百分之十——技術創新與新技術應用是產品生命周期中重要的組成部分，但所有的變更必須可控。
????? 成本與效果的平衡之道：沒有好的過程，就不會有好的產品。但是好的過程也不是一蹴而就的。對每一個項目組而言，它的過程都是唯一的。沒有一個可以放諸四海而皆準的過程標準可以萬試萬靈，但是我們會不斷的去發現開發過程中問題——這是一種樂趣——去解決問題——這是一種成就感——這樣的問題往往需要通過平衡的藝術來解決。解決問題的成本和解決問題的效果之間的平衡，沒有絕對的正確與否，讓客戶滿意、讓伙伴滿意并讓成本可接受，足也，但也難也。
????? 產品的平衡之道：客戶總是希望產品具備所有他希望的功能，銷售人員總是希望所有的客戶都能滿意，產品經理希望所有的銷售人員都滿意，老板希望以最小的花銷讓所有的人都滿意，開發人員希望不要加班，還要漲工資……而我需要讓他們都滿意——這是不可能的。一個產品永遠不能讓所有人都滿意，但是可以通過平衡讓最多人滿意——夠了。

????? 題外話：其實商業化的商品開發，是非常講求目的性的，而客戶滿意就是終極目標，所有的技術、方案、架構、流程、方法學，一切的一切，都是圍繞這個中心在轉的。而這個中心的基礎是穩定壓倒一切——沒有客戶愿意用一個折磨人的軟件。看到有些同學不滿，那你是不是就是不創新了？但是我要告訴你，童鞋，商業軟件中的創新也是講求目的性的，而這個目的是客戶滿意的同時降低成本。脫離了這個目的，那就是為了創新而創新，沒有價值。國產凌凌漆中的要你命三千，也是創新，但是它的價值何在呢？無意義。很多學習Java的童鞋癡迷于某個框架，常常自稱精通Spring、Struts等等等等，我在面試的時候經常問一個問題，Spring框架是為解決什么問題而生的？分層！為什么要分層？……什么時候，我們是不是應該反省一下，我們是該關注這個東西本身，還是該關注解決問題本身呢？有童鞋說，外國的軟件開發都是大型的、系統級的、框架級的、平臺級的，都是牛逼的，牛魔王的，我們國家卻沒有，于是我以后要做大型的、系統級的、框架級的、平臺級的、牛逼的軟件。但是根本的問題卻沒有想過：外國產生這樣的軟件都是為了解決他們看到的特定的問題，我們沒有，不是因為我們做不出來，而是因為我們看不到這樣的問題——我們太關注這個東西本身而忘記了它的本源——而這正是商業軟件開發所關注的問題的核心。
????? 我們關注解決問題的效率和效果，所以我們采用實用而成熟的技術。
????? 我們為客戶負責，所以我們不會領著客戶冒風險。

在項目修改過程中永遠要保證可運行版本

剛剛上來寫篇博文，看到了《我心中的商用化開發》征文公告。看了肖老師老師的幾篇文章，獲益匪淺。

其實如果不是這個商用化開發的公告，我也會寫這篇博文，來鞭笞自己。提醒自己，隨時注意在項目開發中注意，可運行版本這個概念。

昨晚，被我們老大狠狠的教訓了一頓。

?我先說下我現在的狀況。我們的java team不大，一直在開發自己的商業信息平臺的。從平臺的開始到現在，陸陸續續來了一些人，也走了一些人。基本上，從框架的搭建到現在二期維護，除了老大做一些架構的調整工作，剩下的細微調整，從架構到業務的需求和代碼編寫都是由我來調整。

前些日子，我做了個struts2 Convertion和spring annotation的可行性報告后，老大決定將平臺原來struts2的xml配置改成convertion。

我嫌一個個功能改太麻煩，要不停的重啟服務器做功能測試，先將所有Action改成convention的形式，然后再改jsp頁面。導致最后，整個平臺的后臺管理的很多鏈接失效。

其實，老大在我改的時候，已經強調了，要一個一個功能的改。任何時候保證有一個可運行版本。。但是我就是沒聽。他狠狠罵了我一頓后，然后讓我想為什么。

我知道，can run version的概念自己沒有把握好。商業化開發的概念沒在自己心中牢牢鞏固。

晚上，做老大的車回家，他說，雖然我們現在不是做項目。但如果真的趕項目的話，如果客戶讓你明天給他一個版本，那你死活給不了的。因為，你一頭扎到了修改Action文件中，你要是跟客戶說，現在在修改Action文件？所以影響了進度？那你準備扣錢吧。。客戶不會管你這個的。

回去想想，也是。任何時候保證可運行版本，真的很重要。特別是在商業化開發中

1.在修改中如果以功能為單位修改，無論什么時候都能得到一個可運行版本。

2.按功能修改，有利于其他人進入團隊，能根據已修改功能作為demo去進行其他模塊的修改。

有點兒離題。。呵呵，現在就自己的理解，說說自己在工作中的所謂的商用化開發。

1.在商業化開發中，永遠保持可運行版本。

2.商業化開發不是新技術的戰場和試驗場所。

??? 有時候，自己很喜歡用新的技術，新的方法注入到現行的項目中。什么都想試試新。如，之前用的Fckeditor(網絡文本編輯器)，后來知道出了Ckedtor（fckeditor的升級版），就開始蠢蠢欲動了。和老大溝通后，被他攔了下來。原因很簡單，現時的編輯器基本能解決問題沒有必要換。我說，沒事啊，就2，3天的時間。他最后說的一句話，讓我很有感觸，他說，你關注的是時間，那么我問你，折合下來的修改成本是多少呢？什么新技術也好，你可以去做。但是做的時候，首先要你能handle它，然后寫一份教程，一份可行性報告。因為，你要是提它出了，那別人有什么問題當然找你了。你必須handle它。二，教程是為了讓新進的同事能快速的掌握它，三，可行型報告是為了綜合下現時的情況，其他同類技術，做個對比才能“動手”的。

3.商業化開發需要每一個程序員要有一個share的習慣

???? 一個教程，一個想法，一個新技術的觸角。。。很多人都喜歡把一些“小竅門”藏起來，作為自己的一個競爭力。這在開發中其實是很不利的。比如，A在開發時，需要學習jquery，他用了3天，那么他將自己的筆記整理了5頁筆記，全部藏起來了，下次，B在開發中又要用到jquery，那么難道又要給他3天時間嗎？那整個項目期限就都浪費在了學習上了，那么 我們就需要讓A也好，自己也好，將自己3天學到的東西寫成筆記share出來。這樣，幫助別人，利于團隊。也減少了項目的學習時間。何樂不為呢？

4.商業化開發需求不是你訂的

??? 有很多時候，有些顧客會按照自己的一些想法提出一些“實體屬性”，雖然你認為不合適，但是你千萬不要改。雖然一些你看著不符合實際情況的屬性也好，關系也好。你做就是了。。沒有關系的。我們在開發中，經常會過分的為顧客考慮，總想著，這個需求怎么行，根本沒有道理的。什么什么的。。其實，很多時候，需求，特別是我們做商業平臺的，都是由業務決定你需求的去向。不要輕易的提問題。即便它有問題。。

好了，就寫這么多了。。。呵呵，還有很多想法，但是不能寫了因為

5.商業化開發不是你的聊天，看文章了解新技術的過程。 很多人都喜歡不讀書，看“聊效”。。我反對這種行為。呵呵

商用產品開發不同于學校作業

?文/陳尚義

今聞CSDN征文，討論商用軟件開發的話題。我對此非常感興趣，也有很多感想。

???? 我是一名老程序員，在國內外干過20多年，頭15年是做產品開發工程師，2004年開始做商用產品開發的管理工作。現將我的一些心得體會貢獻出來與大家分享。

???? 商用軟件，之所以叫商用，其最大的特點就在于它是用作商業目的的。商業目的就是有人花錢買你的軟件。人家掏錢買你的軟件而不買別人軟件的原因無外乎兩點，一是你的軟件能幫他解決問題，二你的軟件比別人的好。商用軟件是講究成本的，是要盈利的。公司不是學校，學校要看你的知識學懂沒有，公司要看投入到軟件開發中的錢能否賺回來，并且要盈利。

在你動手開發之前，即使需求已經確定，作為程序員，你必須考慮軟件是否能用，是否好用。下面我舉幾個簡單的例子。

???? 例子一， XML數據系統，是我在美國公司開發的一款商用系統，它和我們經常使用的關系型數據有某些相同之處，里面都有用戶和角色的概念，用戶都可以向數據庫中加入XML文檔，加入XML文檔的用戶就是這個文檔的擁有者（Owner）。

下面我問你，刪除一個用戶的操作應該是個很簡單吧，要是你開發這個模塊，你怎么做？（閉上眼睛，想想看:-)）可是，你想到沒有，當你把一個用戶簡單地刪除之后，那么他以前加入的那些XML文檔歸誰所有呢？作為商用產品的開發者，你必須要處理類似這樣的問題。

還比如，關閉數據庫管理系統看起來也是個很簡單的操作，但實際上，當數據庫被很多人都在連接使用的時候，你去關閉數據庫系統，必將造成很多用戶的事務(Transaction)被中斷，甚至導致數據的紊亂。“停止數據庫服務”模塊必須要考慮這個因素。我們當時的解決方法是，當“停止數據庫服務”的命令下達后，數據庫要等一段時間（如10S），看看是不是所有的用戶都斷開了連接，如果沒有用戶連接（使用）數據庫，停止數據庫是安全的；如果還有用戶在使用數據庫，數據庫服務可以強行停止，但在下次數據庫啟動時，要將紊亂的數據恢復過來。

在數據庫系統開發的兩個例子中，我們看出，程序員不解決這些問題，系統將無法使用。

????? 例子二，是關于系統好不好用的問題。一個初出茅廬的畢業生開發一個功能模塊，該模塊負責將一些文件從服務器推送到成百上千的計算機上去。該生開發出來的軟件，用戶只能一次推送到一臺計算機，一千臺計算機，用戶需要推送一千次。從理論上講，只要用戶一次輸入一臺計算機的名字（或IP地址），也能完成所有計算機的推送任務。但我問你，這個軟件好用嗎？如果允許用戶一次填寫所有計算機的名字，然后發一個命令去推送呢？毫無疑問，用戶的使用體驗是完全不一樣的。實際上，用戶不會去使用前一種方式的。

????? 例子三，我們一定有過這樣的體會，將小批量的文件從硬盤（比如C盤）拷貝到U盤是輕而易舉的事。但當我們拷貝大量文件的時候，總會遇到很多麻煩，比如U盤滿，拷貝程序被迫中止；比如源文件是隱藏的，系統提問你：要不要拷貝這些文件？如果你不在現場，系統一直在那里等，直到你看到提示、并給出明確回答為止。

類似的，我們也有一個功能模塊，要將服務器上大量的數據進行備份，以防止數據丟失。數據量少在幾十G、幾百G，多則幾個T。服務器上的數據有文件系統里的文件，也有數據庫里的表。一位工程師做完了程序，簡單地用幾十M數據做了測試，就準備交付。

到此，你也許已經看出，商用的軟件的開發絕不同于學校作業。學校作業是老師為了考察學生對課堂上講的語言知識是否都掌握了，如語法、概念、算法、數據結構之類的，出的題目都是一些簡單功能的實現，答題的結果是獨立的小程序，和外界根本沒有關系。除了你的老師，沒有其他人會使用你的程序。學校作業也不用考慮升級、補丁、數據遷移和系統參數設置、配置管理等等。

而商用軟件呢？除了運用語言的基本知識實現需求中的功能之外，還有很多事情要考慮。比如事務（Transaction）、伸縮性（Scalability）、穩定性(Stability)、可靠性(Reliability)、可擴展性(Extensibility)、安全性(Security)等等。再舉一個簡單的例子，如果是基于數據庫的應用系統，你還要考慮數據庫不可能無限制地膨脹吧，在開發完功能之外，你不得不開發另一個相應的工具，用于數據庫備份和恢復。如此等等，學校作業都不可能涉及到。

我發現很多同學剛參加工作的時候，都有一種擔心，擔心自己的“技術”不行。這個很自然，我也是從剛畢業的時候過來的，一開始生怕自己對語言的掌握不及老員工，心想只要掌握了語言的編程技能和技巧，也就能立住腳了。作為過來人，我發現技能問題并不是想象那樣中的那么可怕，反倒是編程之外的其他問題，成為商用軟件的關鍵。

基于RUP的軟件過程及應用

1 引言

　　軟件過程(Software Process)是人們建立、維護和進化軟件產品整個過程中所有技術活動和管理活動的集合 [1]。目前，軟件過程技術是一個非常活躍的研究領域，吸引了大批來自學術界和工業界的專家和學者。從1984年起每年有軟件過程國際研討會(ISPW)，從1991年起開始召開軟件過程國際會議(ICSP)，每個國家幾乎都有自己的軟件過程改進網絡(SPN)。軟件過程技術的研究主要有三個方向：

　　(1)軟件過程分析和建模。軟件過程建模方法是軟件過程技術的起點，其中形式化半形式化建模方法有基于規則的，基于過程程序的等等。過程分析和過程建模對于保證過程定義的質量、建立全面和靈活的過程體系具有重要的作用。

　　(2)軟件過程支持。軟件過程支持主要是指研究和開發支持軟件過程活動的CASE工具，過程支撐工具作為一種技術基礎設施能夠很好地支持、管理并規范化軟件過程。軟件過程支持工具主要包括軟件過程流程工具、過程文擋工具、評審工具和人員管理工具。

　　(3)軟件過程評估和改進。軟件過程改進對生產高質量軟件產品和提高軟件生產率的重要性已被越來越多的軟件開發組織所認同。由美國卡耐基·梅隆大學軟件工程研究所(CMU/SEI)提出的軟件能力成熟度模型(SW-CMM)除了用于軟件過程評估外，還向軟件組織提供了指導其進行軟件過程管理和軟件過程改進的框架。

　　Rational Unified Process(RUP)是Rational軟件公司的一個軟件過程產品，是由Objectory過程演化而來的，其初始版本為5。0，先后經歷了5。1、5。1。1、5。5等版本直到最新的Rational Unified Process 2000版本。RUP將項目管理、商業建模、分析與設計等統一起來，貫穿整個開發過程。RUP采用Internet技術，可以增強團隊的開發效率，并為所有成員提供最佳的軟件實現方案，它使團隊中每個開發人員的見解和思想得到統一，使開發小組成員的溝通更為容易，而這正是任何項目要取得成功的關鍵因素;它可以增強開發人員對軟件的預見性，最終的好處就是提高了軟件質量，并有效縮短了軟件從開發到投放市場的時間。RUP過程為軟件開發提供了規范性的指南、模板和范例，可用來開發所有類型的應用。

　　本文的第2節討論基于RUP的軟件過程，第3節給出一個應用實例，第4節是本文的結論。

　　2 基于RUP的軟件過程

　　RUP中的軟件過程在時間上被分解為四個順序的階段，分別是初始階段(Inception)、細化階段(Elaboration)、構建階段(Construction)和交付階段(Transition) [2]。每個階段結束時都要安排一次技術評審，以確定這個階段的目標是否已經滿足。如果評審結果令人滿意，就可以允許項目進入下一個階段。基于RUP的軟件過程模型如圖1所示。

　　圖1 基于RUP的軟件過程

　　從圖1中可以看出，基于RUP的軟件過程是一個迭代過程。通過初始、細化、構建和提交四個階段就是一個開發周期，每次經過這四個階段就會產生一代軟件。除非產品退役，否則通過重復同樣的四個階段，產品將進化為下一代產品，但每一次的側重點都將放在不同的階段上。這些隨后的過程稱為進化過程。

　　用戶需求的變化、運行環境的變更、基礎技術方面的變更等都會引發進化過程。通常情況下，進化過程的初始階段和細化階段都比較簡單，因為基本產品定義和體系結構在前面的開發過程就已經決定。但也有例外情況，例如對軟件體系結構(Software Architecture)進行重新定義的進化過程。

　　2.1 初始階段

　　初始階段的任務是為系統建立業務模型并確定項目的邊界。在初始階段，必須識別所有與系統交互的外部實體，定義系統與外部實體交互的特性。在這個階段中所關注的是整個項目的業務和需求方面的主要風險。對于建立在原有系統基礎上的開發項目來說，初始階段可能很短。初始階段的實現過程如圖2所示。

　　圖2 初始階段子過程

　　(1)明確項目規模

　　建立項目的軟件規模和邊界條件，包括驗收標準;了解環境及重要的需求和約束，識別系統的關鍵用例(Use Case)。

　　(2)評估項目風險

　　軟件過程主要關心的是軟件開發的已知方面，只能準確描述、計劃、分配和評審那些已經知道將要完成的事情。風險管理則主要關心未知方面。在基于RUP的迭代式軟件過程中，很多決策要受風險決定。要達到這個目的，開發者需要詳細了解項目所面臨的風險，并對如何降低或處理風險有明確的策略。

　　(3)制訂項目計劃

　　估計整個項目的總體成本、進度和人員配備。綜合考慮備選體系結構，評估設計和自制/外購/重用方面的方案，從而估算出成本、進度和資源。在這個過程中，要通過對一些概念的證實來證明可行性，該證明可采用可模擬需求的模型形式或用于探索高風險區的初始原型。初始階段的原型設計工作應該限制在確信解決方案可行就可以了，具體實現留到細化階段和構建階段。

　　(4)階段技術評審

　　初始階段結束時要進行一次技術評審，檢查初始階段的目標是否完成，并決定繼續進行項目還是取消項目。在評審過程中，需要考慮項目的規模定義、成本和進度估算是否適中，估算根據是否可靠?需求是否正確，開發方和用戶方對軟件需求的理解是否達成一致?是否已經確定所有風險，并且有針對每個風險的規避策略等問題。

　　2.2 細化階段

　　細化階段的任務是分析問題領域，建立健全的體系結構基礎，淘汰項目中最高風險的元素。在細化階段，必須在理解整個系統的基礎上，對體系結構做出決策，包括其范圍、主要功能和諸如性能等非功能需求，同時為項目建立支持環境。細化階段的實現過程如圖3所示。

　　圖3 細化階段子過程

　　(1)確定體系結構

　　確保體系結構、需求和計劃足夠穩定，充分減少風險，從而能夠有預見性地確定開發所需的成本和開發進度。通過處理體系結構方面重要的場景(Scene)，建立一個已確定基線的體系結構。證明已建立基線的體系結構將在適當時間、以合理的成本支持系統需求。

　　(2)制訂構建階段計劃

　　為構建階段制訂詳細的過程計劃并為其建立基線。

　　(3)建立支持環境

　　建立支持環境，包括開發環境、開發流程、支持構建團隊所需的工具和自動化/半自動化支持。

　　(4)選擇構件

　　評估現有的(構件庫)和潛在構件，充分了解自制/外購/重用決策，以便有把握地確定構建階段的成本和進度。集成所選構件，并按主要場景進行評估。

　　(5)階段技術評審

　　評審時，需要檢驗詳細的系統目標和范圍、體系結構的選擇以及主要風險的解決方案。在技術評審中，需要考慮的問題有：

　　(1)產品需求是否穩定，體系結構是否是穩定的?

　　(2)可執行原型是否表明已經找到了主要的風險元素，并且得到妥善解決?

　　(3)構建階段的迭代計劃是否足夠詳細和真實，是否有可靠的估算支持，可以保證工作繼續進行?

　　(4)所有與項目有關的人員是否一致認為，如果在當前體系結構環境中執行當前計劃來開發完整的系統，則當前的需求可以實現?

　　(5)實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受?

　　2.3 構建階段

　　在構建階段，要開發所有剩余的構件和應用程序功能，把這些構件集成為產品，并進行詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制操作，以優化成本、進度和質量。

　　構建階段的主要任務是通過優化資源和避免不必要的報廢和返工，使開發成本降到最低;完成所有所需功能的分析、開發和測試，快速完成可用的版本;確定軟件、場地和用戶是否已經為部署軟件作好準備。

　　在構件階段，開發團隊的工作可以實現某種程度的并行。即使是較小的項目，也通常包括可以相互獨立開發的構件，從而使各團隊之間實現并行開發。這種并行性在較大幅度地加速開發進度的同時，也增加了資源管理和工作流程同步的復雜程度。

　　構建階段結束時也要進行技術評審，評審產品是否可以在β測試環境中進行安裝和運行。在評審中，需要考慮的問題有:

　　(1)該產品發布版是否足夠穩定和成熟，可安裝和運行在用戶的實際環境中?

　　(2)所有與項目有關的人員是否已準備好將產品發布給用戶?

　　(3)實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受?

　　2.4 交付階段

　　當基線已經足夠完善，可以安裝到最終用戶實際環境中時，則進入交付階段。交付階段的重點是確保軟件對最終用戶是可用的。

　　交付階段的主要任務是進行β測試，制作產品發布版本;對最終用戶支持文檔定稿;按用戶的需求確認新系統;培訓用戶和維護人員;獲得用戶對當前版本的反饋，基于反饋調整產品，如進行調試、性能或可用性的增強等。

　　根據產品的種類，交付階段可能非常簡單，也可能非常復雜。例如，發布現有桌面產品的新發布版可能十分簡單，而替換一個國家的航空交通管制系統可能就非常復雜。

　　交付階段結束時也要進行技術評審，評審目標是否實現，是否應該開始進化過程，用戶對交付的產品是否滿意等。

　　2.5 技術評審

　　在每個階段結束時都要進行一次技術評審，以確定在完成該階段的最終迭代后是否應該讓項目進入下一階段。技術評審要考慮的主要問題應該主要與項目管理有關，因為主要的技術問題應該已經在該階段的最終迭代以及隨后的活動中得到解決。技術評審的步驟如圖4所示。

　　圖4 技術評審的步驟

　　(1)安排評審會議日程

　　技術評審會議的參加者必須包括外部人員(用戶代表和領域專家)、項目的管理團隊(項目經理以及項目團隊各功能區域的團隊負責人)和項目評審委員會。

　　與會者一旦確定，就應安排會議的召開日期和時間，以便為與會者留出充足的準備時間，讓他們能夠評審有關材料。

　　(2)分發會議材料

　　在會議召開之前，應當將技術評審材料分發給評審人員。要在會議召開之前及早地將這些材料分發出去，讓評審人員有充足的時間對其進行審閱。

　　(3)召開評審會議

　　在會議期間， 評審人員主要關注狀態評估。在會議結束時，評審人員應作出是否批準的決定。技術評審會議可能會得到以下結果之一：

　　(Ⅰ)階段被接受：評審委員會認為項目實現了該階段的預期目標，可以進入下一階段。

　　(Ⅱ)有條件接受：評審委員會同意項目可以進入下一階段，但必須先完成指定的糾正操作。如果發現的問題很少并且不是很重要，則客戶可能決定在項目團隊執行某些糾正操作的同時有條件地接受該產品。在這種情況下，項目經理需要根據問題的重要性，或選擇開始新的迭代，以處理所出現的問題，或只是通過延長最終迭代來處理問題，二者的差異在于所需的計劃工作量。

　　(Ⅲ)階段不被接受：項目沒有實現該階段的預期目標，項目經理就可能必須開始另一次迭代，甚至項目經理無法決定對問題的解決方案，而需要由有關人員根據合同重新確定項目規模或終止項目。

　　(4)記錄會議決定

　　在會議結束時應完成評審記錄，其中包括重要的討論或活動以及評審的結果。如果結果是"階段不被接受"，則應暫時安排一次后續復審。

　　3 應用實例

　　在為某水電廠開發的綜合信息管理系統中，我們全面采用了基于RUP的軟件過程。水電廠綜合管理信息系統是一個大型信息管理系統，其中包含運行管理、設備管理、安全管理、圖形開票、生產技術管理、行政管理、人事管理、技術臺帳管理、班組建設、學習培訓、系統維護等十多個模塊。不僅如此，系統還要與現有的某些監控設備接口，從中獲取數據。系統能對水電廠實行全面的運行管理，能及時對系統的信息作統計分析處理，能給管理者提供及時準確的數據，對水電廠的運行決策提供必要的依據。

　　在項目的初始階段，我們主要建立項目的軟件規模和邊界條件，明確用戶的需求，形成規格說明書，作為驗收標準。同時，估計了整個項目的總體成本和進度，評估了潛在的風險，作出了具有20%資源預留的項目計劃。最后，根據客戶要求，我們選擇了Rational Rose 2000作為分析和建模工具、Project 2000作為項目管理工具。系統開發工具采用Visual Studio 6。0，后臺數據庫管理系統采用MS SQL Server 7。0。

　　在項目的細化階段，我們根據實際需求，選擇了B/S和C/S混合的異構軟件體系結構。對一些關鍵性的算法，制作了探索型的原型。并在此基礎上，為構建階段制訂了詳細的迭代計劃。在構件的選擇方面，我們決定主要采用已有構件(我們曾經開發過變電站綜合管理信息系統)，對構件庫中沒有的構件，則重新開發。

　　在項目的構建階段，我們的主要任務是完成新構件的開發和測試，集成所有構件，進行集成測試。在這一階段，我們采用并行開發方式，大大地提高了開發效率。

　　在項目的交付階段，我們把經過集成測試的軟件制作安裝盤，安裝在水電廠，接受實際環境的測試。然后對有關用戶和維護人員進行培訓和指導。

　　在以上各階段結束時，我們都進行了階段技術評審。在評審中，我們不但按要求邀請了客戶代表，還邀請了第三方專家參與評審。

　　由于全面采用了基于RUP的軟件過程，規范了管理和開發流程，有效地控制了資源，該項目在沒有使用預留資源的情況下順利完成。在系統運行期間，根據水電廠的要求和我單位的商業戰略，我們又對該軟件進行了三次進化過程，最終由軟件項目過渡到一個產品。現在，該軟件產品已經在全國的多個水電站使用，用戶反映良好。

　　4 結論

　　RUP在迭代的開發過程、需求管理、基于構件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。

　　本文討論了基于RUP的軟件過程，并把該過程應用于水電廠綜合管理信息系統的開發。與傳統的軟件過程相比較，基于RUP的軟件過程可以降低產品風險，規范管理和開發流程，有效地控制資源，提高開發效率。

?