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

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

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

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

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

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

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

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

       國內大部分公司的目標和需求都不明確。大家可以發現國內的公司有一個最大的特點就是產品種類多，其實這個也不算什麼，最要命的就是，種類多還行業多。比如說有些公司既有煤礦安全監控的產品，又有電子消費方面的產品，甚至還有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天的壓力測試等。

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

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

作者：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的詳細資訊。其他文章將介紹其他元素。

目錄

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 [email protected]。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是此新應用程式模型的基礎。

參考資料

關於作者

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服務架構和規範的開發，並管理與廣泛行業合作伙伴的技術協商。

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

機會總是伴隨著市場需求的到來，如今嵌入式行業的發展如日中天。有些單靠做流媒體行業應用發家的，有些單靠做手持機行業產品發家的。從市場分析來看，所有的這些應用都是基於一個很小的行業發展起來的，深入研究數年就小有成就，正如我去年發表的一片文章中介紹的，如今的嵌入式行業應該定位一個行業，深挖這個行業的需求，並專注於這個行業，致力做到該行業的領導品牌。但是反過來看看，在嵌入式行業，基於行業應用的產品也不乏小數，成功的例子又有幾人? 如此、不禁引起我們的反思，如何構建嵌入式通用行業應用平臺呢？讓我們從下面這幾個問題來慢慢闡述。

什麼是嵌入式通用行業應用平臺的靈魂？

這是一個困撓著無數嵌入式通用行業應用平臺的開發專案經理的大難問題。這個群體中到多數人是從事硬體開發的，由於他們一直以來在硬體技術的沉澱和積累，無形中使得他們產生思維定時，從而一味的追求硬體技術的創新和實現，他們認為硬體平臺是嵌入式通用行業應用平臺的靈魂。孰不知，正是這種定勢在悄悄的扼殺了平臺的靈魂，導致最終的產品像一堆廢鐵一樣堆在倉庫當中，接下來整個團隊就開始不停的接收硬體定製專案，接收之時、才驚訝的發現這個硬體平臺還能應用這樣的行業，孰不知這整個行業的發展機會已經拱手讓給了別人，自己還拼命的興奮與下一個定製專案，如此、整個團隊的創新、激情、活力就將斷送在定製專案，這也是為什麼嵌入式行業人次流動頗大的原因。

什麼才是嵌入式通用行業應用平臺的靈魂呢？我可以毫不誇張的告訴大家，硬體平臺只是基礎，真正靈魂是軟體平臺。在中國，軟體的發展要早於硬體，在嵌入式行業，軟體的規範和管理流程要優硬體平臺，軟體是正真提些行業應用的需求，是擺在客戶面的直接印象，如果把嵌入式通用行業應用產品進行分解，“模具”是產品衣服，“軟體”是產品的中樞，硬體是產品的裸體。舉個例子，相信很多人都用過凱立德導航軟體，凱立德軟體以其獨特的介面風格、精確的地理資訊著稱，從而被應用絕大部分的終端裝置上。現如今有誰能記住，導航產品的硬體結構呢？可以這樣說，凱立德公司是完全可以做到硬體外包，或則直接相容其他硬體平臺。試問硬體平臺還是嵌入式通用行業應用平臺的核心嗎？

怎樣進行軟體平臺的搭建？

如果大家對軟體平臺是嵌入式通用行業應用平臺的靈魂沒有疑意，那麼如何來進行軟體平臺的搭建呢？

首先、需求是整個產品的關鍵所在，沒有需求的產品是肯定的沒有投資的必要。因此軟體平臺的第一份需求材料應該來自於銷售和市場人員，因此搭建軟體平臺首先應該完善銷售和市場人員捕捉需求的機制，應該建立研發人員和市場、銷售人員需求互相的平臺，使得研發人員能夠第一時間獲取需求資訊，調整產品的開發方向。

其次、採用快速原型開發模式進行初期的軟體開發，在如今的中國軟體行業，為搶奪市場正確進一步捕捉需求的時間，我想不到第二種模式能夠跟適合他們的。因此在構建嵌入式通用應用平臺的初期應該迅速根據當前的需求構建出於一個相對完善的軟體平臺，這個初期版本可以當作整個平臺的技術指標，也可以直接參與專案演示，儘量爭取軟體平臺與這個特定行業打交道的機會，這也正是進一步捕捉需求的機會。大家都知道一旦軟體的需求完善了，軟體的靈魂就開始孕育了，不管是重新構建軟體，還是在原型的基礎之上繼續修改開發，最終的軟體都將給整個產品帶來無限活力。

最後、將整個軟體產品化，由於原型開發階段獲取了大量的需求材料，這時候正是考慮產品的時候了，就像凱立德一樣，完全脫離硬體平臺。軟體的產品化需要對整個需求進行篩選、分析，最終根據需求分析說明書制定相應的詳細軟體設計方案，最後參照軟體原型開始進行再次開發，並進行最終的需求確認性測試，如此整個軟體平臺的設計才算完成。

因此，我建議在通用行業應用平臺設計之初，應該同時制定硬體和軟體開發團隊，軟硬體平臺協同開發進行，軟體開發團隊主要的作用就是捕捉硬體平臺適合應用的行業需求，並開發出軟體原型。

怎樣進行軟體平臺的測試？

如果是做過軟體開發的人員都會發現，軟體測試在整個開發流程中都佔據著重要的作用。有時候會發現軟體的測試時間要比軟體開發的時間高出兩倍甚至更多。那麼在嵌入式行業中如何做到軟體平臺的測試呢？

測試不是一成不變的，根據各個行業需求的不同測試的要求也不同，例如軍工、醫療行業就不同，他們對測試的要求就極其之高。但是有一點我們可以肯定，不管那個行業他們對效能的要求總是有個指標的，因此我覺得軟體平臺的測試應該制定測試指標，讓測試指標貫穿整個測試過程，不管是功能測試、單元測試、系統測試、整合測試還是確認性測試。測試指標可以如下定義；

rps：response rate(響應速度)介面響應效能引數，表示每秒最少響應次數

eot：error’s count of thousand (錯誤次數)介面效能引數，千次中出現錯誤的最多次數

fps：frame per sercond軟體功能效能引數，指定每秒最少獲取視訊幀數

可以在具體的行業測試可以根據具體的需求規定這些引數，例如在視訊監控行業，可以根據一些標準規定，如下;

服務連線介面響應效能指標為：0.3 rps

客戶端傳輸過程錯誤次數指標:  10 eot

客戶與伺服器傳輸速度指標: 15 fps

如果規定的這些測試指標一旦獲得了客戶的確認，那麼這個整個測試人員來說測試將是如此明瞭的事情，只需要根據規定編寫測試用例進行測試即可。

    最終、嵌入式通用行業應用平臺必定是嵌入式行業的發展方向，構建嵌入式通用行業應用平臺確實不是一件容易的事情，尤其對於專案負責人來說是多麼大挑戰啊！每次平臺的搭建就好像一次創業，稍有不慎產品的市場就將蕩然無存，整個團隊就將處於定製專案的無效掙扎當中，但是隻要我們堅持不遺餘力的進行產品的演變、軟體需求捕捉和重構，我相信行業最終將屬於我們的團隊。

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

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

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

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

【專案背景】

隨著國家教育事業的發展，很多高校紛紛引進學分制教學體制模式。我所在的學校為跟上時代的步伐，經市教委批准，從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日正式提交軟體，如果軟體能滿足要求則立即投入使用。時間很緊迫，為保證第二次原型開發具有充足的時間，經專案組討論決定製定了以下的工作安排。

專案名稱：學分制收費管理系統       任務安排表