寫碼才是確保 UML 分析/設計的信心來源!

這兩天與 Ringle 一同至高雄某家規模蠻大的專案開發公司,從年前兩日的 UML 課程教育,然後年後第三日係以座談的方式,面對面聽取學員們在實際專案開發時,利用 UML 設計時,所遇到的問題,同時並檢驗他們的設計產出是否正確與適當。其實呢,算起來也有半顧問的意味,當場就拿出他們利用 EA 所開發的設計圖,檢驗、評論、說明,然後協助直接修改,甚至轉出程式碼。

我覺得學員們真的很認真,讓我有些訝異,在年前只上過短短的兩天 UML 基本課程後,竟然在一個月的時間,就已經將某一系統的需求訪談記錄建構為使用案例圖,並且還產出系統分析的類別圖與循序圖,就只差程式碼還沒出來而已。

一整天的座談,就針對這些設計產出來 “指指點點”,說明他們在 SA/SD 設計的一些茫點與比較顯明的謬誤。但大致上,我們到蠻給予高度肯定的評價,重點是有沒有 “心” 要做,其它的都還是次要而已。他們專案經理,也非常認真,提問了很多的問題。我發現到,都比較偏向是專案管理面的範疇,諸如設計產出是如何承接、由擔任什麼角色的開發人員負責、該如何 “檢驗” 他們設計的品質 …等等。專案經理重視 “制度”、”製程” 等,那也是當然的,不過,到讓我發現到,一個很明顯的問題:想太多了。 這會導致在分析/設計階段因瞻前顧後,花太多不必要的時間在小細節上,而陷入了「癱瘓(paralysis)」

如同寫文章,越想求完美的人,越不容易動筆。分析/設計 也是如此,就是因為想要 “分析” 更精確、”設計” 得更完美,讓系統開發規格更明確 …這些心理因素的作祟,而導致在某個開發的局部就 “僵住”,好像是動彈不得、陷入瓶頸的感覺。

何以見得? 答案太明顯了:程式碼沒有出來!

傳統 SA/SD/PM 最大最大的一個茫點是,如果沒有開立明確的系統分析與設計的規格,包括 Database Schema,那如何能讓程式人員寫碼呢? 這不就是傳統 “Waterfall(瀑布式)” 開發流程的詬病? 許多軟體公司以為,採用如 RUP 先進、國際標準典範的開發流程,就會從 “瀑布式” 的開發魔咒解套,問題是,當你把 SA/SD 拉長數星期以上的開發,才開始展開 “Implement” 的實做階段。這種方式,如同 “藍皮綠骨”,根本還是 “瀑布”,因為,RUP,甚至是現今必然要嚴謹遵循的開發原則,最重要的一個精髓之一: I&I (Incremental and Iteration),根本沒有確實實踐。

從需求分析、設計、至實做,甚至包含測試,要花多久時間? 我與該公司 PM、系統開發人員說,完成一個使用案例的實現,第一個 Iteration 不能超過三天。 他們聽了覺得挺不可思議的。怎麼可能?

唉,為了證明,所以,又要請出我們的 “呂布” 級戰將 Ringle,將他們系統的一個使用案例,從頭作一個分析,補充上使用案例敘述、設計類別圖,描述循序圖,然後利用 EA 的 “Code generator” 功能產出程式碼框架到 Visual Stuio .Net 的 C# 專案,再補上一些虛擬碼的註解,同時又加上功能測試程式碼。第一個 Iteratin,整個過程,還不到兩小時。

第一個 Iteratin 當然不可能包括完整的屬性與行為細節,那並不是第一個循環要關注的事情。即使資訊不足、流程不明確,一旦確定使用案例的目標(Goal),就應該快速跑過一次 RA/SA/SD/Implement 等開發階段,用最短的時間,完成可以執行的程式碼。如此,最重要的幾個目的就能達成::增進團隊整理信心、建立系統雛形結構、快速取得回饋(Feedback)。:

這麼說好了,確定目標(使用案例)、找出達成目標的手段(分析/設計)、馬上執行與測試(Implement and Test)、問題收集與回饋,這才是 “Iteration” 的真諦。

況且,程式碼是最現實的產物,客戶、老闆眼中一定要看到程式碼,才算 “眼見為憑”。我一直傾向是要在最快的時間內,一確立實作的目標,先經過簡單的設計(Simple Design),就要快速產出可執行的應用程式碼以及功能測試碼,這才能確保軟體分析/設計的信心主要來源。

請記得,世間沒有一開始就是完美的事,分析/設計更是如此。我從來都假設需求不明確、企業流程有問題,但只要經由需求分析確立目標,就可以馬上著手系統分析與設計,當然也就可以立即產出程式碼了。當有個 “框” 之後,再來才是逐步修正細節,包括企業規則與邏輯等。 (當然,也不可能無限上綱,永無止盡的 Iteration。過與不及,均不妥。)

分析/設計,甚至包括程式碼,都只是手段,既然是手段,當然不需要太重視,因為手段會時時視需要調整與修正的。我最重視的是原則,什麼原則呢? “把握當下,泰然面對無常”!

文章導覽

   

共有 12 則迴響

  1. Hi 門外漢:
    我實在不知道你既然是要開發簡單的討論區系統,為何要使用狀態圖? 如果不瞭解為何要利用這些設計圖設計,那麼,為何要使用這些設計圖呢? 那是一點都沒有意義的。

  2. 一個簡單的討論區系統
    state diagram 想不出來~~
    來此求救就好像不太好~~
    可以給我些方向嗎?

    還有好多圖還沒想出來…
    迫在眉燒…>

  3. Hi 門外漢:
    你所關注的主題(context),若想觀察它的狀態變化情形,就可以為其繪製狀態圖。所以可以有一個(系統),也可以有多個(單一物件,如訂購)狀態圖。

  4. 一個系統是不是會有多個”狀態圖”呢?
    還有什麼圖…
    可能也不單單只有一個呢…?

  5. uml 在一個系統的開發
    是屬於”分析”階段還是”設計”階段
    這個問題會不會很笨~~
    不好意思喔
    因為我是學生~
    要交”系統設計分析報告書”
    目錄有系統分析、系統設計這2塊
    有點搞不清楚uml的那些圖示要放在哪一塊

  6. Hello 各位:
    UML 並不一定等同於軟體設計;程式開發也不是全然沒有軟體分析與設計。沒必要分得好像有分析/設計與程式等那麼地 “三分法”。

    “呂布” 是我個人對我 partner 的戲稱,這好像也沒啥去批評這或哪的,那是我的感覺,但卻不一定會是別人的感覺。 而之所以發表在我的 blog,是因為,我只是在表達我的感覺,如此而已。

    我比較欣賞 sune 的說法,為什麼,為什麼,尤其是對自己提問。 還有,「與其抱怨,不如做些事」,嗯,相當欣賞!

  7. 賈斯丁回覆:
    “呂布” 級戰將 Ringle
    不是每家公司都有呂布時,空有分析/設計有何用呢?

    我會問:我為什麼不是”呂布” 級戰將?我要怎麼作才能成為”呂布” 級戰將?

    如果我是管理經理,我還會問:我手下為什麼沒有”呂布” 級戰將?我要怎麼作才能找到/培養出一個”呂布” 級戰將?

    先問對問題了,然後迴繞著問題,一步一步制定出應該要作的事,再一步一步完成,就像是開發某個系統一樣。

    與其抱怨,不如作些事。

  8. 沒錯~

    開發軟體是不斷Refine的過程。

    其實任何事都是不斷Refine的過程。

  9. “呂布” 級戰將 Ringle
    不是每家公司都有呂布時,空有分析/設計有何用呢?

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *