茫茫網海中的冷日 - 對這文章發表回應
茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1704350 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
IMG_0026.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

對這文章發表回應

發表限制: 非會員 可以發表

發表者: 冷日 發表時間: 2008/3/17 5:26:46
Kenming | 22 Mar, 2007 12:13(原文
前言

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案,本身的職務是擔任軟體架構師(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)的開發方式
圖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、以架構為中心、動態調和軟體開發的三大構面
圖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) 的特質!

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

內容圖示
url email imgsrc image code quote
樣本
bold italic underline linethrough   












 [詳情...]
validation picture

注意事項:
預覽不需輸入認證碼,僅真正發送文章時才會檢查驗證碼。
認證碼有效期10分鐘,若輸入資料超過10分鐘,請您備份內容後,重新整理本頁並貼回您的內容,再輸入驗證碼送出。

選項

Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|