沒頭沒尾--專案開發筆記：UML，IDEF在我們專案中的失敗應用 (轉)

沒頭沒尾--專案開發筆記：UML，IDEF在我們專案中的失敗應用 (轉)[@more@]

標題：沒頭沒尾--專案開發筆記：UML，F在我們專案中的失敗應用

關鍵詞：分散式開發 專案分工 UML IDEF

  11月21號：下午，有些感慨不吐不快

先宣告，我是第一次做這種進銷存專案的整體設計，以前多多少少用過一點UML，用過一點IDEF。不過都不精。

專案一開始我是試圖用User case來畫出的需求，然後興致很高的和同志們一起討論（我記得當時我先把幾個大的模組定義出來，然後針對基礎設定與一個單據的提交各做了一個User case的圖。對應畫了幾張順序圖）。可以想向出來是什麼回應嗎？哈，我告訴你們，同志們的反應是：“哦…………，這玩意你應該去和客戶說，和我們說幹嘛？”；“這玩意太虛了！”；“我覺得我還是想看見一棵大樹，可以知道我們一共要幹多少事情！”。搞的我暈頭轉向。

然後我直接在白板上畫了畫總體的IDEF圖，有位同志大歡喜，說：“這圖好，這圖好，這種圖才說明問題呀！”。鬱悶！

又花了三天把UML轉成畫IDEF0，給同志們講了講，然後大家看了看，談了談，然後就放在safe裡沒有人看了。

那麼專案還是在按需求寫出來的向下做，向下做…………。

從上面這點來看，從開始階段我想專案實際上就已經有很多的問題，比如由於專案人員的組織中可能沒有人很懂這些。（主要是我不懂業務，對UML與IDEF也是一知半解）。然後又試圖在不當的場合去使用這樣東東，（比如我試圖拿這些圖去給客戶講，我感覺客戶的感覺就是，這小子在講什麼呀，這不都是我告訴他的，他又來告訴我幹嘛？有病！）開發人員對這玩意也不感冒（靠，不畫圖我也能做，你的圖我還要跳來跳去的看，我要做的你的圖上又畫不全，玩那虛的沒用。）浪費了很多的時間。

沒有時間去感慨為什麼人家的工具用的好，我們咋就用不好，工程還是要向下走。一些契機使用採用了另一種開發方式。下一次我會對這個開發方式做個描述。

這裡想談一下我對開發這件事本身的感受。

l  開發使用的設計工具選擇：

流行的說法是開發時用UML來整，傳統的說法是用IDEF來整，可是你要是沒有本事就別去用這些東東來做。能看懂需求，畫出幾個大家都看的懂的圖就好，形式真的不重要。（特別是對小屁的公司，我們公司的需求業務水平極高，客戶要什麼他都清楚，不過你把你的理解用ROSE畫出的case圖給他們看，他們還是會說，這個是什麼狗*……），如果你的文件要存檔，有必要與其它人，其它的公司什麼的進行交流，那麼可能一定要用一種這類的東東來搞清思路。如果不是這樣，老闆又天天在屁股後問你的進度如何，員告訴你他看你那個圖還要好幾天才能完全的理解！！真的讓我想罵娘。

l  開發目的

開發是為了什麼？這個問題一定所有人都會有自己的回答。想聽聽我以前怎麼跟我的一個當老闆的朋友說的。“開發一個產品的目的就是要讓客戶滿意，最低要滿足客戶的需求，最好是可以滿足客戶的期望！如果可能的話，可以把開發的存在公司，而不把開發的經驗放在每個程式設計師身上”。當我還在對我說的這些深信不疑的時候，朋友告訴我：“小同志，我告訴你呀，如果你要認認真真的去做一個專案的話，是一定會賠錢的！！！！！”（巨寒）。一開始真是接受不了這句話，但是後來靜下心來想想，其實如果這句話應該加上一個前提，這才是真理呀“如果你要去開發一個新的型別的專案，如果你開發完以後公司可能並不會再在這個方面發展自己的業務的話，那麼你認認真真的去做一個專案是一定會賠錢的。”。這就是現實，如果你沒有辦法用關係搞來專案，而只能用你公司的技術力量來接這種型別的專案，你的前期投入是一定會賠錢的。我記不清楚我學這個半調子的UML用了多長時間，學會理解IDEF用了多長時間，不過如果在這種型別的公司，這種型別的專案中，我的感覺就是用這些還不如不用。不要被這些東東的美好的假象給蒙了。專案開發的目的是在於你可以在指定的時間做出一個客戶要的東東，其它的先一邊放。（靠，這樣來當一個專案技術經理是不是太不負責了？！）

l  牢騷

還有就是要談談我對開發過程的理解了。如果看過上一篇的筆記的朋友應該瞭解。我對開發的劃分從設計上來說就是兩種，一種是面向業務的使用者需求，一種是面向的設計。然後要做的事說是把這兩個東東聯絡起來。如果把這兩個在實現上當做一對矛盾的話。為什麼會出現這種矛盾？我們如果用CASE工具是不是可以解決這些矛盾？不能，從我的實踐來看是不能。

RUP我看過幾眼。但現在已經記不清楚了。不過我記得大概是把一次的開發分成需求、設計、開發、測試、實施這麼幾個過程，然後再做迭代的開發，進行這樣的過程反覆，以期達到客戶需求。當我已經漸漸的把這個過程當成真理時，有一天我反問自己，為什麼要經過這幾個步驟？如果這個過程是完美的話，那麼為什麼還要迭代？是因為客戶總在變化嗎？還是因為一開始不能保證完全去理解需求，還是因為本身這個過程就有問題。中間我想過一些時間，這裡就不去羅嗦了。反正極有可能是不對的。不過我想把我的結論與大家分享一下，如果大家有意見可以討論。

1.  這個過程的假設前提是做這事的人在一開始完全不懂業務（至少這個過程的default值是開發的人不懂業務。）

2.  這個過程設計之初應該是基於我們已經非常的習慣用關聯式資料庫來開發。物件導向的關係與關聯式資料庫的關係是混然天成的。如果業務簡單的都可以不用關聯式資料庫呢？（這是個假設）

3.  做這種型別的專案總是思路上很不連貫，從需求來看看，使用者要的是實現業務，然後設計的人員開始去提煉，找出物件，從物件中挖空心思來寫資料庫，這個正規化那個正規化的。寫完了資料庫，設計完事了開始寫程式。寫程式以前的過程是一人一塊事，頂多有個人寫中間的支援之類。這樣搞就搞的每個人都會比較混亂，每一個開發階段都有不同的任務，不高（特別是對小公司5555555）

4.  這些步驟其實非常明顯的說明了一個問題，那就是在基於這種過程的開發中，我們最有把握的是從設計到實施的過程，最沒有把握的是需求，使用者的需要。這也是為什麼我們要迭代開發之所在（不是技術問題，是業務問題。）開發過程所能解決的問題只是把你的資料存好，組織好。而不是將你的業務做好。這個過程一點都不爽。

5.  我總是不自覺得把自己當成一個不是程式設計師的角色，當我意識到如果我們只是提交給客戶一個純粹與徹底的物件導向的（包括介面，介面上只有一個物件叫XXX系統，點進去之後發現有一個物件叫單據，再點進去發現有一個物件叫採購單，再點去告訴你有一堆方法，其中一個叫做新增。點一下讓你修改一堆屬性…………），使用者一定會說你是白痴。我不覺回頭看看為什麼我們要使用面嚮物件的技術。為什麼？可以給一個答案是這樣子，從七十年代的關聯式資料庫的思路出來之後我們就被迫走到物件導向的路子上。滿足程式設計師寫出精彩程式的虛榮。滿足sales要賣產品時需要說產品中應用了什麼好的新的技術，而去忽略真正軟體的意義。

 :namespace prefix = o ns = "urn:schemas--com::office" />

牢騷也發了一通，發牢騷也解決不了問題，事情還是要接著乾的。下一節我會寫我們是採用什麼過程來搞的。