第三章　權限控制模組

完成資料建模，或在建模的過程當中，SA 就需要開始進行程程式規劃。程式規劃時，需要規劃一個模組中有幾隻程式，每隻程式的需求規格，包括了畫面規格、資料結構、與使用者界面互動邏輯。

SA在進行程式規劃時第一個要決定的，就是要不要採用標準程式版型。

有人認為程式開發是一種不可控的活動，需要靈感，沒有一定的標準。這種看法，是因為沒有採用標準程式版型，程式規劃時，天馬行空地設計了一堆異型程式，程式界面沒有一致性、操作行為沒有統一性，導致的結果就是，開發的時程不可控、拖延，經費超支，完成的程式臭虫極多，品質低落。

有某公司在軟體公司間被列為黑名單，因為每次它們公司發包的軟體開發案，得標的廠商都虧錢，每個開發案都時程落後Delay，完成品的品質低落，接案的廠商每接一二案後就被它們列為拒絕往來戶，但相對地，它們家的名聲也在業界風傳出去，沒人想接它們家的軟體開發案。

在某個機會，有朋友介紹我進去，我看了需求規格書，找它們的SA談過後，告訴朋友，這個案子，我做不來，你要我接的話，費用會高於市場行情很多，才能如期做出來。以你們目前的經費，我評估會超支27個人月，這種差距，我沒辦法，你們的時程目標，我達不到。

你們公司的需求規格很怪，SA完全沒有標準程式版型的概念，每隻程式都是異型，都是規格外品，都需要特製。我很沈重地跟你說，有異型規格是正常的，但每一隻程式都是異型規格，這就絕對不正常，我不相信有什麼系統，每隻程式都需要如此「獨特唯一」，這不是SA沒經驗，就是SA在弄鬼。

一隻標準規格品和一隻規格外品的開發成本，可以相差八倍以上，你們的一隻異型程式，我用兩隻標準規格程式就可以兜出來，相同的效果，四倍的費用差距。沒經驗的SA才會統統都開異型規格，要是有經驗的SA，那他肯定是在炫耀技術，搞一堆看著好看，實際上一點也不實用的使用者界面。你們SA這樣做，管理部、財務部知道嗎？相同的東西，別人一塊錢可以做出來，你們八塊錢以上才能做，而且品質還沒有保證，需要後期大量的測試。

你們家SA說異型程式，使用上比較順，一隻程式就可以完成所有事情，但是我拆成兩隻後，開發費用可以降為四分之一，難道就不值得犧牲一點使用上的便利嗎？照你們SA的邏輯，哪還要什麼教育訓練？這是走火入魔了，公司用的業務程式，使用者的便利性不是至高無上，要兼顧開發成本才行。

沒有標準程式版型概念的SA，就不懂什麼叫開發成本控制，他認為開發經費和時程不是SA的事，這種想法，會把專案拖到地獄裡去，業務系統開發會變得非常不可控。

以權限模組的程式規劃為例，正常的SA會由ER圖思考資料間的關係 ，先套標準程式版型。套不進去或效果不好的，才會考慮開異型規格。圖四、由ER圖的觀點，進行程式規劃

對於獨立性比較強的資料表，如功能Fun、組織Org、參數Para等實體。我會先用橘框先框起來，這些資料表，可以用「單檔操作」這個標準程式版型來實作。而互動關連性比較強的資料表，如授權群組auth_group和功能授權fun_auth、應用程式使用者app_user和任職duty這兩組，就可以使用「主副檔操作」這個標準版型來實作。列表如下：

• 功能資料維護　[單檔操作] for Fun資料表
• 組織資料維護　[單檔操作] for Org資料
• 參數資料維護　[單檔操作] for Para資料表
• 服務資料維護　[單檔操作] for Service資料表 選用
• 授權群組功能授權設定　[主副檔操作] for auth_group與fun_auth 資料表
• 授權群組資料授權設定　[主副檔操作] for auth_group與data_auth 資料表　選用
• 系統使用者任職設定　[主副檔操作] for app_user與duty資料表

可以看到，初步就有七隻程式需要實作，其中兩隻程式是選用，不需要馬上實作出來，等有需要的時候再進一步實作就可以了。這七隻程式，都是標準程式版型，開發上要投入的人力工時都有標準，是可以估算地，而且因為多次地重覆開發，寫程式的PG不容易犯錯，品質可以保證。可管理、高品質的開發活動，這才是我們需要的。