軟工藝術 : [轉貼]從軟體架構師(Architect)的觀點來看軟體開發流程

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案，本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的 問題，更要兼顧到專案開發的過程中， 」人」 的互動所衍生而來的諸多問題，包括想法的歧異、見解的落差、不同的觀點與角度，甚至情緒問題等等，這些都需要與專案經理協同合作，一同來解決問題。

軟體的開發，最終目標雖然是 「完成高品質」 的軟體系統，但在進行階段過程中，所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process)，卻是首要需克服的階段目標。而該兩大議題，均是係以 「人」 為核心的考量，專案管理講究的是 「領導統御」、」人和」；開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度，保持產出的一致性)」。專案管理的部分，筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當)，倒是相關於開發 流程的議題，筆者倒是可以把藉由所觀察到諸多各形的開發型態，以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之，文中內容會是筆者比較偏以 「主觀意義」 的表達。

軟體系統的專案開發，特別的是，需求往往不明確，更何況是經常處於變動中，所以導致專案的範圍與規模無法界定，連帶也引起時程無法估算(人月？ 神話吧)。那麼，是不是開發成本的成本也無法預估，而往往也因為成本與時程的低估，更容易導致品質不佳、粗製濫造的軟體系統。

正是由於軟體別於如硬體產業的變動性問題，使得在其它成熟領域的專案管理經驗，並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知 識與創新的產業，那麼一成不變且僵化的專案管理方式，並不妥當；除非是將軟體產業當成是軟體工廠，需求固定且明確，工作者(worker) 各司其職，負責實做局部的小功能，再由 「大一點」 的工作者，來組裝成大功能。請記得，這樣的方式，其假設前提是需求不容易變動，工作者也不太需要具備創新獨立思考的能力。

個人是很難相信需求不會變動，同時也認為正是因為軟體的多變性，才造就了更多的好機會，所以軟體的開發，不應該視善變為畏途，反而是把變動看成是理 所當然，更是多添了許多的好機會。我們所要作的事情只是，如何將變動抑制或收斂在某一程度可以被控管的範圍內，同時，學會如何在某一問題領域 (Problem Domain)，重覆性、同質性高的軟體系統，來找出不容易變動的部分，成為系統的框架(framework)，或稱之為主結構(Main- Structure)。而容易變動的部分，又是如何從主結構中抽離出來，爾後只花少許的 「工作量(effort)」，就可以輕而易舉的滿足客戶的需求。

很難嗎？ 只要有兩個滿足的要素即可：一為開發的資源(包括成本與時程)多一點；另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難，該如何才有可能達成這種 「夢幻」 的要件呢？

這就回到最現實 「人」 的因素了，要能爭取到多一點的開發資源，如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder)，是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源，而資源越多，當然專案成功的機會就更大。後文會提及，「反覆與漸增(I&I, Iteration and Incremental) 」，會是提升專案開發 「實績」 的好手段。

再探討另外一點，如何才能讓團隊成員對軟體的基礎養成與默契好一點？ 默契要好，溝通必然要多，要能溝通多，當然就是要勇於把自己的想法給表達出來，而這些，則是有賴於專案領導者的支援與協調。總之，好的專案領導者是要能懂 得 「觀察」 在整個專案開發的過程中，成員之間互動所衍生出的種種問題，然後找出 「解決方案」 來謀和 「人」 的問題；另外回到最根本的是，畢竟這是軟體的開發，軟體的基礎養成功夫不足，當然也不太可能作得好軟體開發，軟體人員持續的學習與成長，更會是軟體產業的 命脈。

正是由於 「變動無常」 的軟體開發專案，有些人的想法是想要 「凍結」 住需求，然後依照固定不變的製程，一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts)，例如預估一年開發期的專案，三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design)，六個月的實做與測試(Implement and Test)，這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程，參考如圖1。

圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式

這樣有何好處？ 開發時間是否會縮短？ 其實並沒有，反而一開始開發時間會拉長，慢慢習慣這樣的開發模式後，才能倒吃甘蔗般，效率會提升上來。 反覆式最大的好處就是在於提早可以揭露潛藏的風險(Risk)，而儘早處理掉。 如 果軟體開發人員必須要在數個月等需求分析、設計的階段過後才開始實作程式碼，一旦發現問題，要再回頭去修正，則必須花費相當長的時間來做修正；另外因為開 發人員之間可以在一個 Iteration 期間內就可以看到具體的結果(可執行的程式碼)，他們可以維持良好的注意力在實際結果上，也能很快得到工作上的回饋(Feedback)，當過程中有小錯 誤，開發人員可以回頭去修正，時間不會離得太遠。

反覆式流程的開發方式有下列優點：

• 提早降低風險。
• 較早能具有可視性(Visible)的進展(Progress)。
• 較早能得到回饋，較可以得到使用者的保證(engagement)及適應性(adaptation)，由此再精緻(refine)系統的設計，以更進一步契合使用者的需求。


• 增加團隊的信心，並且可以一直持續學習。
• 產品的整體品質較佳。

看來 I&I 好處多多，而且技術上其實很容易呈現，但是卻很難達成它。因為它同時會衍生出許多的管理議題，而最主要的一個因素就是： 人們往往無法忍受不確定性。 這是心理層面的議題，而個人是這麼認為，如果它是對的方向，那麼，你幹嘛太在乎與恐懼於現實上的困難？ 這些問題本來就是應該克服的，包括文化、政治(沒錯，這是最大的問題)、溝通等等。以筆者在任職顧問單位所輔導的專案來說，這幾年是一直堅持 I&I 的開發，老實說，遇到的問題的確很多、也很辛苦，但同時也是持續在過程中，思考與找到解決問題的方案(Solution)，這條路可是不能退縮、妥協與放 棄的。 」Do the right thing (往對的方式走)」 後，才有可能 「Do the thing right (把事情做好)」。

其中的不確定性，其實團隊可以就整體來建立共識，那個整體，就是以架構為中心。

以架構為中心，就是希望擔任各個角色的軟體開發成員，都能對開發中的系統有一致性(consistence)的全貌見解。專案中有架構師最好 (若沒有，也最好組成架構團隊)，他必須具備關照系統整體觀的能力，也需要時時刻刻來 「調和」 各個角色的觀點與產出。擔任架構師者，可不是只偏往實做面的平台技術(這其實是技術長的執掌)，還包括與領域專家(Domain Expert)的溝通，如何萃取其智慧，並得以抽像化(abstract)，分離出善變的功能部分，與比較穩定、重用價值高的主結構部分；他同時也知道該 如何與 IT 平台的專家合作，將源自於領域知識的需求  軟體設計模型，具體實現在企業層級的平台(包括 .NET, J2EE 等)；當然，更知道事情不可能一次就那麼順利，所以會透過快速反覆來取得開發過程中的回饋，據此來作為下一循環的修正，或也可能透過實做才知道設計的茫點 (或無法貼近現實)，而回過頭來作設計的變更。請注意，所有開發的產出與修正，都是基於以架構為中心的考量，不會是偏頗於某一個觀點，而這些會是整個團隊 開發成員們都需要具有的共識。

以架構為中心，那麼具體的呈現會是什麼呢？參考下圖3，RUP 是提出 「4+1」 的架構觀點，筆者是把它再精簡一下，只用了三個觀點來代表架構的呈現，而每一個觀點，會有其開發產出 (artifacts)，並可能成為另一個觀點的參考來源。這裡筆者直接舉小小的例子，來說明下圖的意涵。

圖3、以架構為中心、動態調和軟體開發的三大構面

需求功能面，代表的會是系統的外部觀點，是站在 「用」 的角度來看系統所提供的功能，而功能其實就是源自於使用者的需求，或者是領域專家的知識。 「新增訂購」、」查詢訂購訂購」、」查詢採購」 等，都是屬於使用者對系統的期望，也就是系統開發人員會來協助實現 (Realize)的。

而結構面，代表的是系統內部，會有哪些元素的互動合作，來完成系統所交付的功能。善於抽像的結構分析師，觀察 「訂購單(Order Form)」、」採購單(PurchaseOrder Form)」，會把兩者視為是 UI(User Interface) 的元素，而不是單一的物件；兩種表單都可能會共用到某些固定的資訊，然後分析找出了 「訂購(Order)」、」訂購細項(Order LineItem)」、」產品(Product)」、」項目(Item)」 等支撐系統，且再利用性 (ReUse)價值高的企業物件(Business Object)。
落實到現實的平台上，就需要考量到安全性(security)、交易(Transaction)控管、永續性(Persistence) 等現實的議題，尤其光以後者永續性 O-R(Object-Relation) Mapping的問題，就需要花上許多的功夫在系統底層細部設計的思考上，能兼顧到效能又要維持結構的完整性(Integrity)，這就不是一件容易的 事。

從需求分析、結構設計到系統的實做(同時就會涵蓋到上述三個觀點)，是要快速循環、走過一遍的。再次強調，每個 Iteration 的開發週期是以 「週」 為單位，最晚不得超過 2 週。如果將每一個功能單位(使用案例或功能點)規劃為三個Iteration，每一個循環要作的事可能是：

Iteration #1：確認使用案例所要完成的目標(Goal)，建立結構與程式碼框架，找出從分析至實作的風險因子，建立溝通的管道。
Iteration #2：將實現使用案例的細節部分補足，包括規則、流程、欄位明細與資料型態等。
Iteration #3：作例外處理(Exception Handling)的考量與實現。

以架構為中心，必然會是學習型的開發團隊，相當重視對整體的關照與大量的溝通。溝通越形順暢，風險自然越低，開發效率也才有可能提升(這可不是透過 工具與自動化來做到的，它們僅是輔助用的機制，是建立在溝通順暢的前提下)。而這整個開發過程，就是要快速跑過整個涵蓋開發的觀點(功能需求、結構、實 做)，再回頭來調整，修正，繼續再跑下一循環 ．．．

以架構為中心的開發流程正是具備了： 正回饋環路 (Feedback Loop) 的特質！

下一期的主題，筆者會來介紹「以架構為中心的主要設計產出」，並說明這些產出的應用與時機。