B12 追溯關係(1)──Use Case vs. Use Case

軟體專案裡要實作的功能是所有Use Case的集合，refine好所有的Use Case Diagram後首先要做的事是把所有的Use Case收集成清單；如果Use Case的數量太多時可以加上所屬Package的名稱輔助分群。Project vs. Use Case是第一份應該產生的追溯表（垂直），這簡單到不需要介紹它。

在Use Case Diagram裡，Use Case間有拉上關聯線條的就表示彼此有關係存在。這層關係的意義在於被使用的那一端有任何變動時，另一端的Use Case很可能會跟著變動，為了追溯某一個Use Case有變更的情形時，可以追查到受到影響的所有Use Case，在這個時間點應該產出Use Case的水平追溯表。

簡單來說，一個excel檔案的行與列依序填上所有的Use Case代號，從第一個Use Case開始找到最後一個，只要rose model裡的Use Case下有Association存在，就在交集的那個格子裡標註影響的方向（箭頭朝被使用的那個Use Case）。依序找出所有的Use Case間有關聯的格子並標明即可。

文件做一次都還好，麻煩的是哪天Use Case又重新調整過時要再重覆修改文件內容才是痛苦的事。幸好使用SoDA同樣可以自動產生這個追溯表（雖然不是表格形式）。SoDA可以設計一份文件，依編號順序列出所有的Use Case，同時在每一個Use Case裡定義搜尋所有的Association，記錄下影響到的Use Case與影響自己的Use Case。未來在修改某個Use Case時可以立即使用相互影響的範圍。

Model與View的相輔相成讓使用者只修改一次Model就產生各種想要的View，在此可以得到另一種實例的驗證。

B11 理論串接實作的瓶頸(1)──Refine Use Case Diagram的原則

剛接觸OOAD後，遇到的第一個小專案很興奮地使用UML來試著記錄需求。直接列出Actor與Use Case是很直覺的工作，除了摸索Rose的功能花了點時間之外，並沒有任何的困難。

作refine的動作時，Use Case不斷地被我思考並拆解為許多小型的Use Case，彼此間的關聯也拉了很多線條。同事看了問說關係看起來很複雜希望我說明一下？我就把我的想法說了一遍，包括如何拆解Use Case，如何用Use Case的關係表達心裡複雜的想法；原本十多個的Use Case就這麼被拆解成四五十個。

同事說需求模型並不是作設計，而是表達需求之間的關聯，。以我的切割方式已經幾近於切出元件的範圍，所以數量變得很多，同時關係彼此間串來串去而使得其他人很難看懂。Use Case的切割要以一個完整的功能為原則，在提取共用者時也得保持被提取的Use Case是一個完整而獨立的功能。

這個原則真的很難拿捏，太過時造成Use Case多而繁瑣，不及時也會形成每個Use Case各自為政，多想、多試、多討論應該是取得較佳平衡點的最好方式。如果在切割與不切割看起來都可以的時候，我傾向以不切割的結論，因為切得過多會增加需求模型的複雜度；而且每個Use Case都要附近詳細規格並列入清單時時檢查進度，這些都會是多投入資源的工作。

好的開始是成功的一半；如果製作了一個很難分析與設計的需求模型，那真的會是個悲慘的開始。

B10 Rational Tool(2)──Refined Use Case Diagram

在refine use case diagram時，我會優先處理Actor的整理，因為可以減少Actor對Use Case的使用關係。實作時有交集Use Case的Actor另外拉出一個Actor直接關聯，並消除原先Actor與那些Use Case的關聯。

接著就找出Use Case裡隱含的其他Use Case；例如以“管理”為名稱的Use Case就很可能具有CRUD（Create，Retrive，Update，Delete）四個Use Case。找出所有可以延展開的Use Case並與原本的Actor拉上關聯。

再來是最難做好的部分，我要要去檢視所有的Use Case，研究Use Case的劇本來判斷是否有些步驟適合另外定義出新的Use Case，同時會這些新的Use Case定義與原來Use Case的關聯。如果運作正常的劇本必定會使用這個Use Case，就在stereotype標註include；如果某些特定狀況才會使用這個Use Case就標註extend。

當所有的Actor與Use Case通過review後，就為所有的Use Case標上標號。這時，開發系統所必須完成的功能，就已經包含在所有的Use Case裡頭。

B09 功能需求(2)──Refine Actor & Use Case

完全對應客戶訪談的結果所列出的Actor與Use Case是一種原始的資料，如果直接依這個結果開發系統，每一個Use Case都各做各的事而完全沒有交集。就像每一個人都各自只從頭到尾處理自己的訂單一樣，許多Use Case裡都做了可以抽取出來的相同事項，每一次該事項出現都重覆投入資源去處理。所以在決定原始的Use Case Diagram之後我們緊接著要先做抽取相同部分的工作。

Actor間可以定義的關聯是繼承，繼承可以簡化許多原本複雜的關聯。當Actor1的全部Use Case是Actor2的一部分時，可將Actor1定義為繼承Actor2；當Actor3與Actor4的Use Case有大量的交集時，可以將交集的Use Case定義給一個新的Actor5，而Actor3與Actor4都繼承了Actor5。

Use Case可以定義的關係通常是繼承、include與extend。當Use Case1的定義是Use Case2內容的一部分時，Use Case2繼承Use Case1；當Use Case 3的主要流程一定會執行Use Case4的功能時，Use Case3 include Use Case4；當Use Case5根據某個特殊狀況的成立才需要執行Use Case6時，Use Case6 extend Use Case 5。

Refine需求模型只有原則而沒有標準，但是Actor與Use Case定義的好不好，卻對專案的設計有很大的影響。每個物件定義得越明確對未來會越有利，而且在定義後應讓專案人員review，一方面可以確認自己的定義是否合理，另一方面也讓其他人員明白自己對於系統的想法。

B08 做事的方法(4)──相同的抽取出來，差異的分派下去

現在的社會強調分工，很少再有從頭到尾一人包辦所有事情的情況。例如一張訂單會由業務去接洽合約內容、工程人員去著手設計系統、採購去購買合乎規格的設備、會計會確認所有應付與應收的帳款；以此原則，無論有幾張訂單進來，每個部門所負責的事項都不會改變。從單張訂單的觀點來看，這是分工；改從很多張訂單的觀點來看，同樣的事情集中到同樣的部門處理，這就是抽取。

一張訂單被切割為幾個必要的部分，每個部分都集中給固定的群組處理。業務處理的是接洽合約、工程人員主管設計、採購與會計也各有各的事情要做；所有合約的相同部分抽出給特定人員處理，所有的部分只處理合約特定部分的事項。如果遇到合約出現問題時，再依問題的項目分派給應負責的部門，依該部門的專長來處理特別的情況。

不過以上面的狀況來說，訂單的處理會經歷不同的部門，每個部門都只做好自己的部份再將之依流程給下一個部門。因此會指定一個負責人員來控管訂單這個物件，隨時判斷它目前在什麼階段，是否出現什麼差錯而需要額外指派什麼工作好讓它回到正常流程。這樣的角色在專案控制工作項目的進行者稱為PM(Project Manager)，在系統設計裡專門控制功能執行的程式稱為controller。

雖然控管者與執行者可以是同一個人，但是由同一個人兼任容易造成角色混淆，還有工作交接較複雜的情形。工作因抽取而變為數個不同階段的同時，建議指派一個人負責控管該工作項目的進行狀況。

B07 Rational Tool(1)──Use Case Diagram

不管是Actor還是Use Case，在數量多的時候一定要依特性分開到不同Package存放；當特性明顯到屬於獨立的功能區塊時，Package可使用名為subsystem的stereotype作為識別。需求階段的UML在Rose裡應放置在Use Case View裡頭。

建立需求模型（Requirement Model）時大致上要做的事項是：
◎建立所有需要的Package（含subsystem）。
◎建立所有的Actor並放置在所屬的Package裡，同時一一命名。
◎建立所有的Use Case並放置在所屬的Package裡，同時一一命名。（還不用給UC序號）
◎依序在每個Package建立所需要的Use Case Diagram並予以命名。

接著，對於每張Use Case Diagram，要做到以下事項：
○拉進所有需要的Actor，放置在圖的左邊。
○根據Actor的需要，拉進所有有關聯的Use Case並建立關係；Use Case要放置在圖的中間。
○根據Use Case的需要，拉進所有被該Use Case影響的Actor（外部系統）放置在圖的右邊。

因為沒打算做成Rational Tool的教學，所以這裡只會提到一些思考或實作原則。下面是一個Use Case Diagram的簡單範例。

B06 功能需求(1)──Actor & Use Case

系統的存在是要給人或其它系統操作用的，使用系統的對象稱為Actor。訪談的第一優先是找出未來操作系統的所有Actor。系統應該會有管理者，同時一定會有使用者，使用者依定義的不同可能分為許多類型，我們必須確認出所有Actor的類型並記錄。

接著就開始陸續訪談所有類型的數個Actor，收集他們心裡希望系統提供的功能。訪談Actor有兩個主要目的：一方面要得知每種類型Actor所想要執行的功能清單，另一方面是詢問出每個功能的詳細資料以定出規格。（當然，藉由訪談來拉近客戶的關係同時充實自己對客戶工作領域的知識也是重要的課題）

訪談完後我們應該可以得到每種Actor所要執行的功能清單與每個功能的詳細資料（內容與用途在B13）。在文件記錄的時候一個功能會等同定義為一個Use Case。一開始我們必須建立所有的Actor並寫入其描述，接著建立每個Actor要使用的所有Use Case並拉上關聯，做完的同時我們可以收集所有的Use Case得到系統的完整功能清單。

有的Use Case會被定義為與外部系統有關聯，這個時候被影響的外部系統也被視為一種Actor。它們之間的關係也是應該被記錄下來。

如果有沒有Use Case的Actor或是沒有Actor的Use Case，與客戶確認真的沒有任何使用關係後將之刪除。定義沒事做的使用者與做出沒有人用得到的功能都會浪費資源，必須記得系統是以滿足使用者需求為優先的。

B05 Review的重要

心裡的想法如果不記下來，會有遺忘的風險；但是記下來的想法，保證是對的嗎？同時也保證其他人知道你的想法嗎？

維護沒有設計文件與註解的系統時，曾經遇到幾個看來不難的問題，那時依自己的判斷加以修改，測試後也都沒有問題。但是過了一段時間，以前參與設計的人看到就說，那些問題不應該修改在那裡而是在別的地方。設計的想法沒有同步就會有作法不一致的問題產生。

在我帶幾個人開發系統時，工作分派下去之後每天上下午各抽出半個小時討論，內容是簡單說明自己如何做出功能的想法。說明的同時，所有人會針對不明白的地方提問並要求再解釋；如果作法不順暢的時候，也經由問答間找出更好的想法與作法。經由這個方式，所有成員都清楚知道別人想做的事項與要使用的方法，往後工作產生問題時所有人都可以快速地互相支援。在固定定期review的期間主管還抱怨我們怎麼開會這麼頻繁呢。

review的確需要所有人額外花時間投入，但是可以得到想法正確性的驗證、所有成員瞭解全部工作事項、確認記錄文件的正確性與完整性。在規畫與設計時及早發現問題予以修正，會比實際做到一半才發現不對勁要去修改來得快速且影響較小。如果你曾遇過開發到中途才發現嚴重的問題，必須修改大半原來想法之類的經驗，那麼你應該會接受多花一些review的時間來減低未來的錯誤發生機率。

revieｗ的內容，以需求階段、架構設計、細部設計的文字文件與UML文件為主，最好是全部的設計文件都進行。

B04 記錄工具的決定

不管以什麼方式，只要可以讓別人看得懂記下的東西就是成功的記錄。文字文件是最原始的記錄方式，但在說明每個物件的內容、與其他物件的關係還有處理的流程時，會需要大量的文字說明。UML（Unified Modeling Language）是目前廣為接受的圖形表示法，用圖形表示想法是比文字冗長的描述來得容易看懂，但僅是把記錄文件圖形化的理由並沒法說服別人改用UML。

Model只是模型，製作模型的工具有許多選擇，像Rational Rose、Jude、RSA等都是常聽到的，這類工具的存在是為了輔佐我們表達心裡想法。我喜歡用最簡單的圖形來表達而不用太多元化的圖示（因為複雜的圖示會提高看懂圖形的門檻），所以對我而言使用哪一種工具畫UML都沒有差別。選用工具時最大的考慮因素是：藉由畫出的Model，我們還可以得到什麼？

Model裡物件多的時候，要其他人去看圖形來找內容或是看關聯都很困難，再加上許多要求的文字都會訂出章節的規範，我們並無法直接交出Model檔案就算數，勢必還得產生與Model內容吻合的文字文件。對應這樣的需求，Rational SoDA是一個可以讀取Rational Rose繪製的Model，動態將Model內容貼入各式各樣因應需求設計的範本而產生標準文件的工具。藉由這個工具，我真正享受到只要製作Model，就可以直接產生各式各樣專案需要的文件的輕鬆。

我們不是常說Model與View應該分開設計嗎？Rose與SoDA就是符合這個理念的相關產品。UML不只是為了建立模型，更重要的是我們可以藉由模型的建立快速地產出各種不同觀點所需要看到的各種顯示文件。網路上有很多介紹UML圖示與工具的文章，但很可惜地沒有看到設計各種文件範本來套用UML Model內容的教學資料。

Rational Rose＋Rational SoDA是我目前UML工具的選擇。

B03 專案開發的階段

專案的進行會依選擇的方法論而有不同的階段，並沒打算介紹方法論的部份。就純以自己的想法與經驗值，認定進行專案時可以分為以下七個階段。前面五個階段屬於開發時期，驗收是集合之前所有階段的成果給客戶確認，維護則必須參考前面階段的設計文件來動作。

各個階段簡述如下：

◎需求階段　進行客戶訪談，收集功能需求並進行分析，確認系統所有要實作的功能。同時對功能做refine的動作，進而決定每個功能操作流程。

◎架構設計　決定系統架構層面的設計，包括重要的使用技術與系統相關的外部系統與產品。在這裡也需要依功能流程決定使用到哪些元件。

◎細部設計　元件的內部設計。以架構設計時開立的元件方法為基礎進行細部設計，包括元件內部的結構與流程都需要設計。

◎程式實作　依據架構設計與細部設計產生的設計圖，進行元件的實作。系統的程式碼在這個階段產出。

◎測試階段　測試會分好幾個階段。對應著實作類別、元件、架構、功能等不同層級的設計，必須依序做好對應的測試以保證系統的穩定。

◎驗收階段　客戶要的是可執行、趨近無錯且穩定的系統。使用手冊、教學文件等使用與操作相關的文件當然屬於系統驗收的一部分。

◎系統維護　系統上線後發生的問題，或是新增的功能都必須變更系統的設計才能達成。依據維護流程參考設計的資料，修改系統並留下記錄。

B02 只需做出客戶滿意的系統？

依功能做出可以通過客戶全部驗收準則的系統，是專案的必要條件；達不到這個要求時，無論你在其他方面做得再棒再好，結果都只是零分。因為客戶不驗收表示公司收不到錢，專案收不到錢就會血本無歸。

上面的條件雖是必要，但也只讓系統達到及格的程度而已。除了驗收之外，未來會有增加需求，錯誤修改、修改後的測試等可能發生的風險，這些可能產生的工作項目如果處理的不好，同樣會造成系統無法滿足客戶的新需要或是運行起來錯誤連連甚至不穩定。為了這些可能成為將來風險的工作項目，在專案裡必須要“額外”做許多事情來避免那些風險真的成為問題。

目前維護的系統當初就是以標題名稱作為開發的準則，一切的行動都以滿足當時的需求為目標，其他的部分大多得過且過。一直以來無論是功能的內容或是設計的想法，雖然針對想問的點同事都會熱心地說明，但是詢問整個特性的功能有哪些或者詢問某個地方為什麼會這樣子做時，有時會完全沒有答案，甚至通知說太久沒碰早已經忘記，希望我們自己去看程式碼再提出問題。

這是很沒力的感覺，自己曾經做過的事都忘記了，根本不知道怎麼回事的人可能會曉得嗎？寫下那些程式的人忘記為什麼那樣寫，自己重看時至少會有似曾相識的感覺；從沒開過那些程式的人，每一行對他來說都全然是陌生的呀！這樣的系統有誰敢去修改呢？

聽說這就是台灣軟體業裡大多數的情況……。

B01 軟體專案的目標

軟體專案的目標是十分明確的：做出一個功能合乎客戶期待的系統，同時教會他們怎麼用。

客戶有著自己期待的系統，但通常沒法有條理地描述出來，只能想到什麼說什麼。在專案開始的初期我們會做需求的訪談，一方面整理客戶說得出來的想法，另一方面盡量發掘客戶可能想要但說不出來的需要；並時時依訪談的結果歸納與分析以求得接近真實的需求描述。

訪談與需求收集、分析相互循環進行到一定程度，終會到達專案人員與客戶達成共識的程度，那時所列出的所有需求就是系統要達成的目標。需求分為功能需求與非功能需求兩種，非功能需求是對系統執行時的品質要求，這種品質標準只能註記在其要求的執行功能裡；功能需求（以後將簡稱功能）是可經由投入資源做成的工作項目，系統就是由許許多多可做出來的功能所組合而成的。

較大一點的系統功能往往有幾百幾千個，在收集成功能清單時通常會依特性分別存放，特性裡的功能還是太多時再細分子特性予以區分。在專案的角度，會將所有功能分派下去找人實作；以客戶的立場來說，功能有沒有達成是驗證系統成敗的指標，因而會依據所有功能列出驗收的準則。

簡單地說，反正只要依功能做出可以通過客戶全部驗收準則的系統並教會他們就好。這樣對不對呢？



◎系統的目標

A20 Blog Glossary

為了同步所有人的對於計畫裡使用名詞的概念，會建立計畫用的詞彙表。既然我把撰寫Blog內容的動作視為計畫，那麼提供關鍵字的說明是必要的。放在同一個段落裡的名詞表示看待的等級大約是相當的，不同等級的名詞會以空白行隔開。

這裡的詞彙內容也會依時間來增加內容。名詞前的英文字表示該名詞的定義出現在哪個階段，沒有標示者是通用的概念。階段代號的意義如下：

〔Ａ－基本概念〕
〔Ｂ－需求階段〕
〔Ｃ－架構設計〕
〔Ｄ－細部設計〕
〔Ｅ－程式實作〕
〔Ｆ－測試階段〕
〔Ｇ－驗收階段〕
〔Ｈ－系統維護〕

各個階段在Blog左上角的群組標籤裡都有列示，以兩個中括號框住兩個字元開頭者均是。階段標籤之下是一些常用的關鍵字，點選任一個關鍵字後都會列出與之相關的所有文章。

左下角有張貼歷史，我的發文都依照各個階段循序漸進而且排出序號，輔以Blogger的功能顯示文章的標題，因而可以作為整個Blog的文章的索引使用。這將有助於快速瀏覽全部的文章架構與內容。

A19 做事方法的模型（Model）

經過基本概念這一個章節的描述，我們可以得到一個如下面附圖的工作計畫概念模型。圖中物件間的關係如下：

◎一個工作計畫由一個或一個以上的工作項目組合而成
◎一個工作項目由一個或一個以上的工作步驟組合而成
◎每個工作項目可能需要輸入（可能沒有）
◎每個工作項目都會產生至少一個產出
◎每個工作項目都應該定義該工作項目的可能風險（可能沒有）
◎每個可能風險都要有一個或一個以上以上可能的備選方案
◎一個備選方案由一個或一個以上的工作項目組合而成


這個概念模型在這裡僅是反應出與工作計畫相關的重要物件與關係，但是在專案的不同階段裡都可以發現基本道理的模型是可以在許多地方通用的。

A18 記錄（文件）內容的平衡

人的想法大多都是在腦海一閃即過的，要把一個瞬間的念頭簡短地寫下來或許要一分鐘，詳細地記錄下來說不定要三五分鐘。對於執行的計畫，我們會有許多還沒有記錄的想法不斷出現，在寫的同時說不定又產生更多想法；如果鉅細靡遺地全記下來，寫都寫不完了哪裡還有時間執行計畫？因此，記錄的內容必須有所取捨。

計畫是用來執行以達成目標的，事先切分工作項目與工作步驟是為了把規畫與執行的時期切割開來，規畫時思考最佳的執行順序與方式，執行時依規畫的結果身體力行。顯而易見地，執行時必須參照規畫時的資料，因為那時已經依據可能的狀況找出最適合的執行方法；如果一邊做時才一邊思考，為了掌握心裡的想法立即應用，通常只著重在做而沒人會去寫。

規畫時的記錄主要是給執行的人看的，所以文件應以執行者看得懂的方式留下文件。以執行者的角度設想執行時需要看到些什麼，內容應該有些什麼，如此將可以做出適合執行的資料。

一個重要的原則是：內容可以簡單扼要，但該有的項目一個都不能少！因為有簡短的內容可視作一個再加以思考的入口進而有機會得窺全貌；文件裡連入口都沒有，要是沒有人再想起這裡該有這個入口的話，這個點就永遠不會再出現於世人面前。

A17 清單與項目(2)──清單與項目

計畫的第一步是定義出所需的工作項目，針對每一項工作項目再定義其起始條件、輸入／產出、執行者、工作步驟、風險、對策等等。但這樣是不夠的，因為有時必須找出具有特定內容的工作項，或是比較多個工作項目的差異，總不會有人逐一地把工作項目的檔打開來查看吧？所以我們必須把所有的工作項目與重要內容條列為清單。

在面對許多相同類型的項目時，清單是一個重要的管理。經由清單，我們可以快速地瀏覽所有項目的重要資訊而不需要一一去處理；這很像索引的功能，經由清單的資訊快速地定位我們需要資料的可能範圍，再取得範圍內項目的詳細資訊。如此可以避免花太多時間經手太多不需要的資訊。

生活裡到處可見需要這樣管理的事物。像是喜歡的音樂或電影碟片、自有的書籍，如果習慣去做目錄的話，那表示你已經學會管理。然而賣大補帖的一定比我們更常作目錄，不過那是為了賺錢而並不表示賣的人習慣很好；有一大堆新台幣時是不需要作目錄的，因為每張新台幣除了號碼外只有面額不一樣，而號碼的差異並不會影響價值，所以可以忽略號碼只記錄金額的加總。

由於清單是在逐一做好項目後，“另外”抽出資訊彙整而成的，這就表示得付出代價才能完成。每次資訊改變時得花兩次動作去維護項目裡的資訊與清單上的。以之前的想法，在維護項目資訊的同時自動改變清單上的差異是再好不過的。

A16 作出正確的決策

現狀與計畫有所出入時，管理者必須作出一些臨時的決定以期將現狀拉回到與計畫符合的狀態。這些因臨時改變而必須作出決定的動作，就是決策。

保持隨時掌握所有工作項目的進度是首先必須要做到的。管理者應該判斷實際進度是否已受到（或即將受到）風險影響，造成與計畫進度落差太大；落後到一定程度時，就找出造成進度落後的影響原因。問題通常是預估可能會產生的風險成真，這個時候可依據之前所擬的備選方案擇一實施以補救。

接著我們需要列出所有的備選方案。列出備選方案需要對使用的資源有通徹的瞭解才能涵蓋所有的範圍。就像作一道菜，在選用材料時廚師對於食材都必須知道在該類型中所有常用的食材特性，才不會誤列或漏列了重要的材料。

再來就是評估備選方案所造成的影響。落差的填補都必須花費額外的資源而且會有各自的影響範圍，在此把所有的備選方案裡必須投入的資源列出，同時評估每個備選方案造成的影響。在所有備選方案裡找出花費額外資源最少且影響最小的就是最佳的決策；無法兼顧時就得找出最好的平衡。

風險有如事件，而備選方案就是對應該事件的處理方式。事先作好風險評估與備選方案、時時掌握工作項目進度、在最適當的時機作出最適當的選擇。這就有最大的可能作出最佳的決策。（決策時需要將當時決定的想法與依據記錄在該工作項目的相關文件裡，因為那也是想法的記錄）

A15 風險的產生與評估

計畫的風險是來自工作項目有可能無法如期完成。起始條件無法滿足，做不出要求的產出、預期的執行者沒法進行都是會造成工作項目延誤的風險。

一名好的計畫管理人員，對於每一個工作項目都會慎重評估風險產生的可能性。在風險產生機率較高的工作項目，應該列出所有可能發生的風險並針對每個風險寫上應對的方式；解決某個風險的方法如果超過一個以上，都要同時記錄在工作項目裡（工作項目清單也要有欄位記錄）。

對於發生機率更高的風險，我們應進一步根據追溯來確認該工作項目不能準時完成時的影響。機率高且影響大的風險要考慮好所有的備選方案，以應付實際執行時的變化。同時我們不該在風險發生時才去思考怎麼解決，那時風險說不定已經成為難以解決的問題；問題的代價有可能因為工作項目的關聯造成推倒骨牌的連鎖反應，進而無法收拾。

風險對於工作項目來說，有如之前提到事件對應到人的道理，表示的是特定事件的發生。為了降低計畫被影響到不能完成的機會，做任何事前都應該對“無法如期完成產出”的可能風險加以思考並記錄在工作項目的相關文件裡。

A14 物件的關聯與記錄文件

很多時候，對於物件關係的追溯會被記錄在類似Word的文件裡。用這種記錄方式時，大多會選用工作項目或執行者其中一種作為標題，在標題下列示關聯的資源或項目；當我們需要從另一邊找出關聯時，就使用文字搜尋同時另外記錄與該物件有關的其他物件，或是直接由另一種作標題，重新再作出一份追溯文件。

下面的範例是某高中的運動會的流程。工作項目排列在例圖左邊，各年級的學生在例圖右邊，把每個項目與該項目應參加的年級關聯用實線聯繫起來完成這張圖。從工作項目來看，延伸出去的線條指向該項目所有的參與者；從參與者來看，延伸出去的線條指向他必須參與的所有工作項目。這是不是比清單要更容易看懂？

以Rational Rose的Use Case Diagram建立這種關聯模型的好處是：建立的工作項目與參與的資源就是計畫所需要的全部，物件之間的關聯只需依工作項目的定義拉出線條就能完成。接著再使用Rational SoDA建立六個範本：所有工作項目的清單、工作項目的內容、工作項目所需的資源以及所有資源的清單、資源的內容、資源所參與的工作項目。

以Model記錄的好處是在變更時僅僅只要維護一次Model上的變動，就可依現在的內容自動產生以上的六份文件而不需多餘的動作。第一次建立範本時多投入的時間會因為以後所有計畫能夠套用分攤掉，使用與變更次數多了之後反而會節省下很多時間。

使用Word維護時必須同時依變更以人為方式修改最多三份的文件，不僅費時而且極有可能發生錯誤。變更次數一多，遲早會有嚴重的無力感。

A13 流程與資源的關聯(3)──關聯物件的追溯

記錄追溯關係是一件繁瑣的事，因為這個工作是把存在於現實物件裡的關聯（或是存在於每個物件本身的關係裡），再“另外”記錄在一份易於瀏覽的清單上；在許多人的感覺上會是一項浪費時間的多餘動作。

沒錯，把許多單項的內容集合出來成為清單時，我們必須花時間去提出每一項的內容再另行登記到清單裡。這樣做的好處是，當我們需要清查所有項目的某項資訊時，只要在清單裡搜尋即可，不需要再一項一項地把項目打開才能看到想要的資訊。

關聯的意義之一在於可以查到項目所需要的資源與資源所參與的項目。在建立關聯追溯的時候，我們可以就任一個項目或資源，快速地查到與它有關聯的所有項目。快速地查詢到自己有關聯的物件在任何一個物件變更時，可以立即追溯到它的影響範圍，這將有利於在工作項目或資源變更時很快地瞭解有關聯的另一端必須對應的改變。

在項目與資源多時，要逐一把各個物件的內容與關係抽出到追溯清單裡，是額外費時的巨大工程；尤其在變更時，除了更改變更物件還得同時維護追溯清單。如果有一種工具可以同時維護物件內容又能管理關聯，是不是很理想呢？

A12 表妹的婚禮

在2007年5月小表妹婚禮的前一天，我到她家去拜訪。閒談之中，她忽然笑著對我說：“哥，我覺得我很適合去當結婚顧問呢。”我問她為什麼？她說要男友寫婚禮流程，他只寫了三行就寫不下去，她就拿回來自己做，隨便寫寫就有四五頁之多。

她先在左邊列出婚禮的流程，每一個進行的步驟寫上當時要做的事，同時在左上角標註預期發生的時間；步驟的右邊列出參與該步驟的所有人名與每個人應做的事情。我們可以發現這個流程與前幾篇提到的工作項目與資源的觀念不謀而合，而流程上註記的是工作項目對應到資源的關係。

我對她說工程上的管理跟妳所做的事差不多，同樣是列出工作項目與其應開始與完成的時間點，並安排資源去處理所有的工作項目。不過工程上還會多做一件事，會再列出每個資源應該從事的工作項目；對應到婚禮流程來說，會列出婚禮流程裡所有提到的人名，然後每個人名下條列出什麼時間該做什麼事情，這麼一來每個人都會明白自己什麼時間該做什麼事情。

是的，做事的原則大致上就是這麼回事。有一堆事需要一群人去做，先知道全部有多少事情，再交由每個人於指定的時間做好自己的事。為了不要有交待後發生有人忘記而造成系統延誤的問題，我們同時要作好全盤計畫，然後產出工作項目與執行者的關聯表讓所有人依照計畫進行。

A11 流程與資源的關聯(2)──資源部分

工作項目的目標是為了產出，在一開始我們就應該規定好各種產出的規格與內容。要記得產出的每一個部分都有其用處，不管是作為其他工作項目的輸入，或者是規定的內容。如果產出裡夾雜一些說不出用途的內容，那一定是做著開心的。

在工作項目裡，對於起始條件的判斷應予以註明，用明確的敍述來表達條件的判斷。輸入引用的如果是其他工作項目的產出，最好可以註明引用的是產出的什麼部分。請注意一個現象：使用同一個產出／輸入的物件造成了前後兩個工作項目的關聯

依以上的定義，我們可以得到三種物件：工作項目、產出／輸入、執行者（工作項目雖然不是實物，但它是一個可定義的事，所以可視為一種物件）。其中工作項目與產出／輸入有關聯，與執行者有另一種關聯，另外工作項目與工作項目也有先後的關聯存在。

在這裡有一個很重要的觀念是：“有關聯的物件都應該記錄其追溯關係，而且得是雙向的追溯”。

A10 流程與資源的關連(1)──流程部分

計畫的開始，首先要儘可能地列出所有的工作項目；要記得所有制定的項目都要確實做到review的動作，藉由其他瞭解的人來確認有沒有遺漏或多餘並加以調整。最後確認的所有工作項目應該收集到“清單”裡。

接下來要做的是把工作項目指派給人來執行，被指派的人依照工作項目來訂定工作步驟，決定要做哪些事情。訂定好起始的條件、各個步驟的輸入與產出並集合到工作項目的定義，同時預估每個自己應執行的工作項目各需要多少工時來處理。

理論上，所有的工作項目是沒有關連的，讓工作項目間產生順序關係的是彼此使用的資源。工作項目Ａ的起始條件或輸入如果必須依賴工作項目Ｂ的產出，那麼一定得先做Ｂ再做Ａ；如果工作項目Ｃ與Ｄ都依賴工作項目Ｅ的產出，那麼Ｃ與Ｄ都必須都在Ｅ後面而且Ｃ與Ｄ沒有先後關係。先按照輸入與產出的關係擬定所有工作項目的順序是此時要做的。

還有一個會影響工作項目順序的是執行者，原則上所有的人一次應進行一個工作項目，做完該項後再做另一項。如果有兩個重要的項目必須由同一個人來做，那麼不是找另一個可以處理的人在同一時間來做，就是得把其中一個工作項目排在另一個工作項目之後。

安排工作項目與管理資源，Microsoft Project是一項著名的好用工具。

A09 清單與項目(1)──目標與步驟

不管是里程碑、工作項目，每一項的存在都是為了要達成一個（或以上）的目標，而那些目標必須是可檢驗的。也就是說在進入那個項目之前與之後，會產生目標未完成與已完成的差異；這些差異應該要可以被比較出來。

每一個目標，理論上應該排出一個對應的工作項目作為它的處理。接著根據目標的達成容易與否，再將目標切割為幾個階段性的部分，每個小階段視狀況分配一個（或以上）的工作步驟與之對應。以此原則處理，一個目標對應一個工作項目，一個小階段對應一組工作步驟，就可以保證每個目標都會被處理到，而且每個步驟都是可執行的。

有時在工作項目的起始階段需要某些特定事物成立才能開始，這是起始條件。負責處理工作步驟的是人；工作步驟裡如果需要不是由這個工作項目產出的事物則稱為輸入；而工作項目的目標成果被稱為產出。起始條件、人、輸入與產出等被統稱為“資源”，工作項目執行順序被決定後則是“流程”。

有一個笑話可以作為工作步驟執行條件訂定失敗的例子。小明出去買東西，爸爸叮嚀說：“一定要等車子過了才能過馬路喔！”，結果小明一去去了半天。爸爸問他：“你怎麼買個東西去這麼久？”，小明委屈的說：“我等了快兩個小時才有車子出現……。”

A08 Blog Roadmap

每個人的Blog裡都有許多篇的文章。雖然有作分類與時間排序，但是乍看之下總覺得千頭萬緒，不知從哪裡開始才好。

想表達的想法事先列出來超過六十個標題。如果隨心所欲，想到什麼寫什麼，看的人想由雜亂無章中再組織起來實在是很難的事。所以我事先把各篇文章的標題分類，儘量循序漸進地結構化表達想法而不要跳來跳去。（這就是一種計畫）

這張用Rose裡Activity Diagram所畫的圖大致顯示現在Blog裡文章的表達順序與屬性。看一張結構圖總比一一看過一堆文章後再來推測彼此間的關連快上許多。這張圖將會依Blog最近的狀態時常更新。

Ａ、基本觀念之顏色範例：
淡藍色──記錄的重要性
淡綠色──做事的方法
淡黃色──資源管理
淡灰色──追溯關係

Ｂ、需求階段之顏色範例：
淡藍色──專案的概念
淡綠色──Use Case Diagram
淡紫色──Activity Diagram
淡灰色──其他基本概念
淡黃色－－Data Model

Ｃ、架構設計之顏色範例：
淡藍色──架構設計的基礎
淡綠色──架構設計的層次
淡紫色──MVC的設計方法

Ｄ、架構設計之顏色範例：
淡藍色──細部設計的基礎
淡綠色──細部設計的層次
淡紫色──應該做到的設計

A07 做事的方法(3)──逐步執行且可驗證的計畫

小時候寫我的志願作文時，記得自己寫下了什麼嗎？在作文裡只需志願、達到志願後的好壞與想做的事，但這些並沒包括要怎麼去達成志願。夢想是可以達成的，只要你列得出可以執行的計畫與步驟！

小的目標當然可以針對目標寫下所有要做的事；大型的計畫會在眾多的步驟裡切割出幾個重要的里程碑，並各自訂出達到的檢驗標準。每個里程碑都可視為一個小型的階段性目標，計畫時只需個別針對一個里程碑擬定執行各自的計畫。

當夢想可以切割為數個有希望達成的里程碑，從現在狀況邁向下一個里程碑都擁有計畫，計畫再切割為數個工作項目，每個工作項目再切割出可以執行的簡單工作步驟。從最小的工作步驟開始、累積成工作項目、再到完成里程碑，一項項可以逐步執行並累積的成果，正代表著一步步往夢想目標走去的你。

把一件大的工作切割成多個可執行的部分，是一項重要且應該具備的做事能力。切分工作的原則很難描述清楚，不過大致上與其他的工作項目、輸入及輸出、處理該工作步驟的人有關係（有時這種動作可以稱為決策）。處理的流程與使用的資源會是下面所要討論的。

A06 日常生活中的SOP

標準作業程序（SOP）應用在生活裡會不會小題大作？同時給人太刻板的感覺？

身為資訊人，重灌電腦的經歷一定少不了，安裝的次數少說也有幾百次。以前都比較隨性，直接從事先燒好的軟體光碟裡裝上當時想要的東西，系統的設定也以設定當時想到的。最近使用Windows Mobile手機，同樣經歷需要重灌的過程，但是手機程式小而多，每次安裝選好軟體後都感覺還是少了什麼。

有次終於受不了，真的逐步寫下安裝手機時需要設定的步驟與安裝的軟體。寫的時候花了一些思考與記錄的時間，但是安裝時就不需要再動腦，只要依照手冊按部就班照著做。我在想，如果哪天手機掛掉我卻沒時間處理的話，就可以把手機、軟體與這份SOP拿給別人代為安裝而不需特別交待什麼。（那個人當然必須懂得安裝的基本，這是必要條件）

同樣的想法可以應用在其它方面：比如總會有幾位朋友會來跟你借車，而你需要一一對每位朋友說明車子應注意的事項；朋友不見得每次都記得該注意什麼，為了避免問題你也只能全部再重講一次。沒錯，把你想說的話記錄在一張紙上，請朋友依清單逐一檢視他該遵守的事項，你就不用再囉嗦啦。

在此得到的通則是，需要特別處理的生活事件而且會重覆發生時（參與者可能都是自己也可能是不特定的人），適合記錄下處理的方式讓當事人遵循；如此就可以保證每次處理事件的方法都會相同。

A05 做事的方法(2)──Standard Operation Procedure

反應事件的程式經過測試後，可以保證事件發生時都會有同樣的處理。同一個人在同樣的情況下都不見得會有同樣的處理方式了，更何況換不同的人來處理呢？為了保證不管是誰，都能在指定的事件發生時有同樣的處理，因此產生SOP。

簡單地舉個範例，幼稚園老師面對一群還不會上大號的小孩一定不會一個一個教他們，而會公開宣布首先要脫褲子，再來坐上馬桶，然後排便，擦屁股，最後穿回褲子並洗手。可是不管講了幾遍，一定會有小朋友忘記或是把順序弄反了（譬如先坐上馬桶，排便，才脫褲子）；最後老師把正確的動作順序寫成海報貼在廁所，要小朋友們依海報內容做事，這樣教的人不用一直講，使用的人也不會做錯，大家就跟著輕鬆囉。

可是有一天，小朋友回來哭訴說家裡沒有馬桶，沒法執行坐上馬桶的動作。這時老師就發現在這個動作時可能有一些例外情況，因此就加上例外流程：馬桶要用坐的，蹲式的要蹲下來，在野外的草叢要找隱密點的地方蹲等等。這些相關的程序也應該全部收集到SOP的文件裡。

一個有完整制度的公司，會先設想好所有的事情先行擬好SOP，所有的人員只要照章行事即可。那麼一個設計良好的系統，是不是也應該先依據所有的功能與事件，思考出對應的方式呢？當然，想出的方式如果直接變為可讀性差的程式，會使得除了你之外的所有人要再花時間回溯你的想法。

這些因應功能與事件流程的產出可以用文字檔記錄或是畫成UML裡的Activity Diagram收集起來作系統的正式文件。

A04 做事的方法(1)──事件或狀況發生時

當一個狀況成立的時候，一個人應對這個情景的相關行為，會被定義這個人的做事方法。

每天早上妻在小朋友們上學前都會一項一項問說什麼帶了沒，這對當時還窩在床上的我來說實在是難以忍受的噪音轟炸。有天我終於受不了，先在門口的小白板上寫下“上學”兩個字，並在下面列出五項平時叮嚀要帶的項目。現在小朋友們在“上學”這個事件發生的時候，就依照指定的項目逐一檢查，全部確認完畢後就可以安心出門而不用怕忘記帶什麼東西。

這種思維在程式設計領域裡很眼熟吧？當我們檢查一個變數（或API）傳回我們想要的值或是某個event發生時，controller就會開始執行一段特定的程式碼。系統在不同的時間點，不同的事件發生時，都會有其對應的事情要做；這樣的情形在有使用者操作介面時更多。把這些與系統行為有關的處理記錄下來並加以分析，將會影響到系統的行為模式。

對人來說，事先預想各式各樣有可能發生的事件並決定應對方法，可以加速處理事情的速度。當然，在相同的狀況下應該要保持相同的處理方式。如果每次相同的情況發生系統的反應都不一樣的話，使用者會把系統嫌到爆；這種現象要是發生在人身上的話，就會令人無法相信那個人。

因此，人應該努力維持相同的反應行為才能建立屬於自己的原則。不是嗎？

A03 程式註解的習慣

1997年的某一天，上班後我照例開啟了當時以Ｃ語言開發的。那是一隻已經幾千行的主程式，宣告的變數大約近百個。這時候的我仗著年輕氣盛，同樣只把功能寫進程式而完全沒有註解的模式，至今從來沒出任何差錯過。

忽然之間，程式追到一個很眼熟的變數，可是我一時之間對它卻沒有回憶。我不死心地向下與向下搜尋，試圖從呼叫的串連裡找到宣告它的意義；然而我忙了半個工作天，還是完全沒法子喚起對它的記憶。

科學家已經證實，“忘記”並不是失去，僅是一時間腦海裡沒法搜尋到該事物的記憶。但半天之後，我已經沒有耐性等待記憶鏈結的回復；我耗費了一天半的時間找出所有變數為什麼會宣告的原因，並將之填寫在該變數旁的註解裡。從此之後為避免遺忘，我養成了隨手輸入簡短註解的習慣。

人應該為自己做過的事負責，在軟體工程裡包括解釋自己曾經寫下過的所有程式碼。當旁人問說：“這段程式為什麼這樣寫？”或者“這段程式做了什麼事？”時，回答忘了或我看一下程式再回答，都是沒法負起責任的行為。

我們沒法時時刻刻記得曾經發生過的大小事件，在當下記錄想法成為註解，是一個即時讓人明白你曾經做過事情想法的最佳方式，而且你還不用花任何時間說明喔。（相信我，當你接連被不同的人詢問同一段程式的寫法或意義時，所耗費的時間遠超過你花在寫簡單註解的）