在進行系統分析與設計時 , 沒有經驗或是沒有動腦的SA/SD 常常會給出錯誤的分析與設計結果
為何說是分析與設計 , 而不單提分析或是單提設計呢 ?
因為常常有很多人以為分析人員可以不需要了解技術 , 不需要了解實作 , 所以常常搞了一堆不會寫程式的人來當 SA ,
可是要記住 , SD 的上游 是SA 的產出 , 當 SA 的產出就是錯誤的時候 , 你就不要期望 SD 的產出會是對的
所以以下的解說，會把 SA/SD 等等混在一起解說
案例1: Web 應用系統的設計 - 長時間的批次作業
使用情境：
在企業環境下 , 可能有某些作業是需要'長時間的且是大量資料處理的作業項目 , 這些作業有一種是由排程自動定時啟動執行(不需要人工介入 , 去啟動) , 另一類則是需要由人工介入 , 來啟動．
原始需求分析：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．
轉檔作業執行結束後，頁面顯示轉檔作業執行成功．
解說：
這上面的需求有幾個盲點，
盲點1: 這是web系統
盲點2: 轉檔作業的需要時間
盲點3:轉檔作業的結束狀態與結果
盲點4: 轉檔作業的過程狀態與監控
首先是web 系統的問題 , web 系統一般來說會有 session timeout 的設定 , 避免有人員連入系統之後 , 一直沒有登出而佔用系統的資源．
而需求上是使用者直接由Ｗｅｂ頁面輸入資料，按下按鈕之後，然後系統直接轉檔，轉檔完成後，就直接顯示結果在頁面上．(這是同步作業的樣式 , 但是錯 , 這個需求應該要轉成非同步作業的樣式)
這樣的做法在 desktop 的應用程式可行 , 但是在Web 應用程式上卻是大錯特錯 , 理由是很有可能會因為 session timeout 而結束轉檔作業, 有人會說 那把 session timeout 調長一點 , 例如 24 小時(那肯定是大外行的人會這樣說) , 有哪一個人會真的需要掛在系統上 24 小時的 , 如果設成這樣 , 不如將 session 設成永不 timeout , (那為何要設計 session timeout 呢 ? , 就是要避免系統資源的浪費 , 希望系統在相同的硬體架構下可以服務更多的使用者)
第二是轉檔作業的時間，可能需要一次整批處理幾百萬筆的資料，不太可能在30分鐘內處理完成,可能需要幾個鐘頭才能處理完成．
第三是轉檔作業執行結束，轉檔不見得一定會成功，如果失敗了要如何處理？
這個也是大外行的分析跟設計人員常犯的錯誤 ,
他們都會只考慮作業一定會成功 , 而不考慮如果發生錯誤要如何進行錯誤處理與錯誤回覆
所以如果你問他們如果發生錯誤 , 頁面會如何顯示時 , 他們就答不出來,
如果發生錯誤時 , 轉檔的資料是否會 Rollback 還是會部分寫入 , 他們可能也會答不出來 ,
我的建議解: 請將上述的需求由同步處理 轉成 非同步處理的樣式
需求：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．(頁面會將需求轉成排入批次作業 , 並取得處理批號 , 這裡就是要轉成非同步處理 , 而不是直接進行作業然後等到作業處理完成後 , 才回應結果)
頁面回應 轉檔作業處理批號．
另有批次處理監控頁面，顯示批次處理作業的處理批號，起始時間 , 結束時間 , 目前處理狀態(啟動/處理中/結束) , 結束狀態(成功/失敗) , 結束狀態備註(失敗原因) , 處理筆數 , 啟動人員代碼 , 系統代碼 , 作業代碼．
系統背端會有一服務程式每隔 10 min(閒距可以調整) 去監控批次處理作業的狀態,
如果有發現到批次處理作業沒有結束時間 , 但是起始時間已經超過 4 小時者 , 則需要發警訊(Email) 給系統維護人員進行檢視 , 看看是否該批次作業已經當掉 , 需要重新執行或是進行其他補救動作等等
補充說明:
還有很多更細節的需求 , 例如系統需要根據起始年月 , 結束年月到資料庫的某某 table 去取什麼資料 , 做處理 , 或是要對起始年月 , 結束年月進行輸入資料的檢核等等 , 這些就不用特別標示出來談 , 因為這些是更基本的．
有的沒經驗或是沒有動腦想的分析設計人員真的會做出如上例的原始需求分析，
而且他們還沒有意識到哪裡有錯誤，反正這樣也能執行，然後就Coding , 結果就會是慘不忍睹 ,
這些是我在公司的外包廠商碰到的經驗 , 他們還會理直氣壯的告訴你 , Session Timeout 設長一點(反正就是要你改公司的Server 設定來配合他們的程式)
為何說是分析與設計 , 而不單提分析或是單提設計呢 ?
因為常常有很多人以為分析人員可以不需要了解技術 , 不需要了解實作 , 所以常常搞了一堆不會寫程式的人來當 SA ,
可是要記住 , SD 的上游 是SA 的產出 , 當 SA 的產出就是錯誤的時候 , 你就不要期望 SD 的產出會是對的
所以以下的解說，會把 SA/SD 等等混在一起解說
案例1: Web 應用系統的設計 - 長時間的批次作業
使用情境：
在企業環境下 , 可能有某些作業是需要'長時間的且是大量資料處理的作業項目 , 這些作業有一種是由排程自動定時啟動執行(不需要人工介入 , 去啟動) , 另一類則是需要由人工介入 , 來啟動．
原始需求分析：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．
轉檔作業執行結束後，頁面顯示轉檔作業執行成功．
解說：
這上面的需求有幾個盲點，
盲點1: 這是web系統
盲點2: 轉檔作業的需要時間
盲點3:轉檔作業的結束狀態與結果
盲點4: 轉檔作業的過程狀態與監控
首先是web 系統的問題 , web 系統一般來說會有 session timeout 的設定 , 避免有人員連入系統之後 , 一直沒有登出而佔用系統的資源．
而需求上是使用者直接由Ｗｅｂ頁面輸入資料，按下按鈕之後，然後系統直接轉檔，轉檔完成後，就直接顯示結果在頁面上．(這是同步作業的樣式 , 但是錯 , 這個需求應該要轉成非同步作業的樣式)
這樣的做法在 desktop 的應用程式可行 , 但是在Web 應用程式上卻是大錯特錯 , 理由是很有可能會因為 session timeout 而結束轉檔作業, 有人會說 那把 session timeout 調長一點 , 例如 24 小時(那肯定是大外行的人會這樣說) , 有哪一個人會真的需要掛在系統上 24 小時的 , 如果設成這樣 , 不如將 session 設成永不 timeout , (那為何要設計 session timeout 呢 ? , 就是要避免系統資源的浪費 , 希望系統在相同的硬體架構下可以服務更多的使用者)
第二是轉檔作業的時間，可能需要一次整批處理幾百萬筆的資料，不太可能在30分鐘內處理完成,可能需要幾個鐘頭才能處理完成．
第三是轉檔作業執行結束，轉檔不見得一定會成功，如果失敗了要如何處理？
這個也是大外行的分析跟設計人員常犯的錯誤 ,
他們都會只考慮作業一定會成功 , 而不考慮如果發生錯誤要如何進行錯誤處理與錯誤回覆
所以如果你問他們如果發生錯誤 , 頁面會如何顯示時 , 他們就答不出來,
如果發生錯誤時 , 轉檔的資料是否會 Rollback 還是會部分寫入 , 他們可能也會答不出來 ,
我的建議解: 請將上述的需求由同步處理 轉成 非同步處理的樣式
需求：
在web 系統 , 某某頁面，由操作人員輸入＂起始年月＂，＂結束年月＂，然後按下＂開始轉檔作業＂按鈕．(頁面會將需求轉成排入批次作業 , 並取得處理批號 , 這裡就是要轉成非同步處理 , 而不是直接進行作業然後等到作業處理完成後 , 才回應結果)
頁面回應 轉檔作業處理批號．
另有批次處理監控頁面，顯示批次處理作業的處理批號，起始時間 , 結束時間 , 目前處理狀態(啟動/處理中/結束) , 結束狀態(成功/失敗) , 結束狀態備註(失敗原因) , 處理筆數 , 啟動人員代碼 , 系統代碼 , 作業代碼．
系統背端會有一服務程式每隔 10 min(閒距可以調整) 去監控批次處理作業的狀態,
如果有發現到批次處理作業沒有結束時間 , 但是起始時間已經超過 4 小時者 , 則需要發警訊(Email) 給系統維護人員進行檢視 , 看看是否該批次作業已經當掉 , 需要重新執行或是進行其他補救動作等等
補充說明:
還有很多更細節的需求 , 例如系統需要根據起始年月 , 結束年月到資料庫的某某 table 去取什麼資料 , 做處理 , 或是要對起始年月 , 結束年月進行輸入資料的檢核等等 , 這些就不用特別標示出來談 , 因為這些是更基本的．
有的沒經驗或是沒有動腦想的分析設計人員真的會做出如上例的原始需求分析，
而且他們還沒有意識到哪裡有錯誤，反正這樣也能執行，然後就Coding , 結果就會是慘不忍睹 ,
這些是我在公司的外包廠商碰到的經驗 , 他們還會理直氣壯的告訴你 , Session Timeout 設長一點(反正就是要你改公司的Server 設定來配合他們的程式)
沒有留言:
張貼留言