系統設計心得

系統設計心得

2008/7/05 15:08

系統開發過程中，有了需求文件(SRS)後，接著開始進行系統設計，系統設計是一個過程，系統設計文件(SDS)是這個過程的結果，我們的重點是在「過程」而不是「結果」，白話一點是不要為了做設計文件而設計。

其實系統設計整個過程，就像是在揑黏土，假如想揑一個娃娃，我們會先把整個輪廓揑出，再來是頭形、身體形狀、再來四肢，有了大概的外形後，我們才會慢慢把臉形、手掌、腳掌，到最後的五官、衣服等細微地方。

在大自然界的不同演化進行都找到類似的痕跡，動物胎兒成長歷程也是先有心臟、腦部、骨架、內臟、四肢到最後的五官、皮膚、毛髮等，因此在這些演化歷程中，我們似乎找到一點點系統設計方法的線索。

跳脫軟體設計領域，回頭看一下其它領域的設計方法，無一不是先從規劃著手，再到整個主架構、骨架、抽象性的需求說明，到最後才是真正細部的設計。不過，綜觀我們現在的軟體設計方式，大部份人員是拿到需求文件後，就開始針對每一個需求直接coding下去，一直做到底，100%完成了一個需求後，再接著做下一個需求，可說是「非常垂直」的作業模式，如下圖。

上面的作業模式有何問題呢? 第一、寫「需求1」的code，因未考慮「需求2」、「需求3」，所以想出的方案一定是為「需求1」量身訂做，等到再做「需求2」、「需求3」時，發現有些東西在「需求1」的code可用，但又需要改一點點，懶得reuse的人會直接從「需求1」的code複製過來，想 reuse 的人就得回頭改「需求1」的code，當然，「需求3」、「需求4」、「需求…」都可能會遇到相同問題，也導致整個系統整合度非常低。

這種狀況套到揑黏土娃娃的例子，就像一開始就把頭形、五官、頭髮整個做出來了，才開始做身體、四肢，依這個步驟做出來的很大機會是不協調的。依照合理的發展模式，應該是「水平發展」，每個需求都粗略 review、思考過後，再往細部思考，作業方式如下圖。

因此，依照目前的作業模式，雖然已有部份人員會開SDS給外包人員編程，但一個需求一個需求開 spec，而且一開就開到很細部的設計，似乎仍欠缺整體規劃面的廣度。

假如我們在SDS產品之前，先經過「架構規劃書」、「初部設計書」的洗鍊，系統的整合度相對提高，甚至在系統間的介面整合細節也可以在這個階段先討論，更能提早發現問題。

「初部設計書」是可以用較為抽象性的說明，撰寫時需要「改來改去」的，而且必須很容易就能修改。目前SDS直接寫到很細部，寫到後面發現前面有些想改時，通常就懶得改了，因為好不容易將文件寫得整整齊齊，誰會願意為了更好的設計然後又把前面的翻掉重寫?

事實上，設計的過程本來就會這樣，人家的「服裝設計」、「建築設計」都是畫了一張又一張的設計草圖，摒棄掉了無數的idea，最後又重新拾回，有新的 idea 時還需相互討論，激發創意，這些歷程，就是「設計」。

   

 顯然我們目前製作SDS的方式是沒有經歷這段過程，SRS產出後就一股腦的為了交差，依照Template做出SDS，對解決方案的篩選、構築沒有經過深度思考，當然設計完客戶若稍加異動，系統設計不良的後遺症更原形畢露，這時候，只能怪「客戶亂異動需求」囉。