1999 天前 
4
「使用案例」分析常見的幾個問題 
「使用案例」分析常見的幾個問題
雖然觀點有點極端，但仍有參考價值。 ...
標籤：
群組：
看看大家怎麼說
其他更多討論
Qing (qing) 1999 天前說...
我大概把他提出的論點看了一下, 覺得還滿合理的, 很多問題看起來都很像是很多初寫 Use Case 的人會做的事
不知道william學長覺得那些觀點極端呢?
william (williamyeh) 1999 天前說...
以下這段話，我覺得有點極端：
使用案例表達的就是「純粹」的資訊系統「局部」功能觀點的需求模型，只要把握這一點，甚至在不需要作系統內部結構分析的情況下，馬上就可以轉移至程式碼的實作階段，而且是很快速直覺。
雖然在稍後幾個段落裡，他有提到「可順應短線的專案開發生態」，也稍微提到事後還可再 refactor architecture，但我不認為這是正統的做法。除非真的只是在做 throw-away prototype，否則我認為 functionality 和 architecture 應該並進，不可過於忽略任何一個。否則以「短線的專案開發生態」而言，我高度懷疑事後是否真的還有精力去 refactor architecture，尤其當 architecture 的亂度已變得難以駕馭時。
Kenming (kenming) 1995 天前說...
Hi, 我是本文的作者，從文章的內容內，諸如 william 所提到，似乎過於極端了點。這應該是個人的文章表達意涵不夠完整。
不過，個人從來是主張 "architecture first"，所以即使是短線的專案生態，仍舊以架構為最優先考量的，若各位到本人的部落格內搜尋 "architecture" 一字即可瞭解個人所重視的程度的。
william 應該是誤解了個人對 "architecture(架構)" 與 "structure(結構)" 二字的定義，在內文中，個人其實沒有提供不做 architecture，而是指可以忽略 structure 結構的分析。但在忽略時的配套措施，一定會加上 analysis class 的框架，才可能讓結構爾後做好重整的。
那麼，為何要忽略結構的設計呢？ 事實上，個人更為重視的才是結構的分析設計！但，國內的專案開發，的確存在太多不合理的現象，現實上在本人所擔任顧問的期間，竟然還沒看過有哪一個專案做好結構分析與設計的。與其如此，倒不如先順應國內短線專案開發的生態，務實一些，先做好使用案例的功能需求分析與實做開發，光這兩點，已是相當不容易了。而在第二個階段，再施以結構重整及程式碼重構的方式，讓系統的品質更有其延展與彈性度，當然，前提是待開發人員的技能、技術與溝通默契成長後，以及老闆肯願意為該系統(可能要準備產品化)釋出更多的資源(resource)。當然，william 的考量點不是沒有道理，所以必然要有配套措施，這也是在內文中提及至少會提供兩個配套措施的。
這是一種務實的作法，並不是昧於現實，也不是妥於現實，而是在理想、目標與現實找出一個動態平衡點。
P.S. 個人覺得 william 與 Qing 的考量與 concern 的建議不錯，個人準備把本討論串轉貼至本人的部落格： http://www.kenming.idv.tw 成為新的文章，也方便繼續討論。
廣告：
訂閱