 |
|
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！ |
|
|
恭喜您是本站第 1671847
位訪客!
登入 | 註冊
|
|
|
|
對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/19 7:56:44
軟體設計美學之道第7回──隨著UP的樂章，讓軟體美學起舞
三大精神，四大核心，讓你UP起來
秀出設計，才能讓人感受思維的美，而實作出來，才能滿足現實的世界，軟體設計有其美學之道，它和建築一樣，可以利用「工程方法」，讓美學之道和實際需求接軌。在前一篇所介紹的三大UP（Unified Process）精神之下，還有許多在實踐專案時會遇到的開發階段和工作科目，其相互的運作流程與軟體設計之間的關係，是最難想像與實作的部份。
關於這些開發階段與工作科目，我想曾經讀過這個方法論的人都會很熟悉一個詭異的波浪圖（如右圖所示），這張圖是UP的精華，不過我個人覺得對於剛踏入UP的人來說，如果沒有好好地理解它，這張圖會像個鎮煞避邪的石敢當，反而就會把大家嚇跑了。
簡單地來解釋這張圖，它的X軸所代表的是四大開發階段以及許多的反覆期（Iteration），也代表著時間軸；Y軸則代表工作科目，而在此圖表上的大大小小波浪，則是代表專案隨著時間進行時，各個工作科目在各開發階段上的比重，其實這也隱喻著這四個階段有著不同的核心任務，只要能掌握這些靈魂，執行UP就能簡單不少。
是大餅，還是焦油坑－－Inception階段
專案的一開始，絕對不是一頭埋進成堆的客戶需求之中，然後埋頭苦幹地開工實作，因為你不一定會知道，前面的路是個焦油坑還是一塊大餅。雖然有時迫於情勢，就算是個焦油坑專案，我們還是得做，不過起碼我們可以先採行一些預防措施，例如使用符合成本的技術、資源，或者盡早另覓他處等等。
在這個階段的時間會比較短，因為重點在於確立產品範圍，了解專案關係人是否對專案願景有基本的認同。因此，在這個階段裏，我們可能會只先列出大部份使用案例的名稱，描述其中小部份，但卻非常重要、有疑慮或者風險較高的使用案例，甚至建立一些簡單的使用者介面prototype來驗證需求，然後針對一些不確定或者難度高的技術做POC（Prove of Concept）測試。
真正的需求開發以及軟體架構的建立，會是在下一個階段，而在Inception階段可能的唯一一個反覆期（Iteration）裏，是要能了解專案未來的路是通住天堂，或者是條令人心驚膽寒的天堂路。
給我架構，踏出美的第一步──Elaboration階段
當完成了Inception階段的工作並通過里程碑（milestone）的查核後，也不代表我們就可以放心地往前衝了。在這個階段裏，我們必需要釐清大部份的需求，但最重要的，是要能產出一個能夠解決高風險元素的「架構原型（architectural prototype）」。這也是整個UP流程和傳統的開發流程最不一樣的地方了。
實作此階段的關鍵概念就是要進行短時間且長度固定的多個反覆（Iteration）、優先釐清重要或高風險的需求，然後及早開始寫程式並測試，最後再將測試結果以及需求變化回饋到下一個反覆（Iteration）之中。除此之外，我們要記得另一個重要觀念－「建立軟體架構的關鍵在於能夠提供軟體系統未來實用而穩固的發展基礎」。
架構原型只是整個系統的骨幹及部份肌腱，因此，及早開始寫程式的意思是在於及早開始實作「架構原型」，並不是開始實作出系統的大部份哦。因為唯有不斷地透過開發、測試人員，甚至是使用者的回饋，架構原型才能真正的確定系統風險的解決，並成為下一個階段的穩定發展藍圖。
實作這個階段使用到許多軟體美學的重要技術及設計工具，例如，使用Use Case來描述需求細節、利用Domain Modeling來找尋軟體物件靈感、利用Pattern來設計軟體架構中的邏輯觀點等等。因此這個階段可說是整個流程的重心，也是軟體架構師最重要挑戰以及最大的舞台了。
開工、發包──Construction階段
這個階段會是整個流程裏面最熱鬧的一段時期，因為在成本可行並且有計劃的情形下，會有越來越多的人可以在這個時期裏加入團隊，甚至可以多個團隊一起工作，包括外包。為什麼呢？因為上一個階段的結束，代表我們已經了解了大部份的需求，解決了高風險的問題並且完成軟體架構原型、軟體架構書（SAD）以及架構原型的系統設計相關文件等等重要產出。因此，我們也比較能預估專案接下來所需要的工作量及時間，而現階段的開發團隊可以依樣畫葫蘆地照著架構原型的程式碼及其程式風格來開發建構系統其餘的部份。
軟體架構師在這個時期所扮演的角色就是開發團隊的領導以及教練了。軟體架構師此時必須掌握開發團隊所發展的程式是否遵循著軟體架構書所設計的大方向，並且時時利用架構原型都各部份為範本，教導開發團隊來建構系統尚未完成的部份，如此這般的，一個反覆一個反覆地往下走。這個階段的工作有時會有點像在填補Elaboration階段所建構出來的骨架的肉，也就是架構原型以外的所有東西。因此，這個階段的成功，和上個階段的結束，有著非常重要的關係，而這個階段的後期，團隊也該完成一些如使用者手冊等文件以及alpha測試，以便能替下一個階段的beta測試做好準備。
完美的收尾－－Transition階段
在經過前面三個階段之後，在這個最後的階段當然就是要做個漂亮的收尾了。這個階段的主要目的是將系統變成真正的產品，工作的內容可能包含了最後測試、針對測試結果所做的回應、展示、教育訓練以及將產品交付客戶等等。最後，當然就是希望能撇開一些可能的政治問題，順利結案並且拿到錢了。
在執行這些開發階段時，還有一個重要觀念：每個階段的結束，都是為了下一個階段的開始，因此每個階段的結束，都會有一些確實的，可以衡量的產出物（deliverables），例如，文件、程式碼、測試結果等等，這些產出物就是下一個階段最重要的輸入，這是個容易影響UP執行順暢度的觀念。
近兩期文章的種種，僅是極精簡的UP內容，UP方法論的細節的確很繁多，不過，規則永遠是人定的，只要能理解UP的三大精神及四大核心，再找出一個適合你所屬團隊的工作科目，才是真正的王道。
《作者簡介》葉政達
艾群科技研發中心技術經理，中原大學電子工程研究所碩士。曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。 |
|
