※ 引述《cyin0910 (理性過了頭)》之銘言： : 以前大學時上課.. : 總會上一門課叫"系統分析".. : 在其中..教了好多.. : 從訪談需求..到寫需求規格書..到系統設計..到給程式人員開發.. : 在這其中有一堆又一堆的文件.. : 不管是給使用者看..或是給程式開發者看.. : 想問的是.. : 到底有多少公司真的能把每一份文件都做出來後.. : 才開始做程式設計的部門?? : 或是..大多數的公司..都完成了哪些文件??或完成了多少?? : ps. 因為目前小弟待的公司..似乎這些文件做的都很不完整.. 好吧，如果把所產生文件分成四個階段好了，大概會遇到以下幾個問題： 1.需求訪談階段，SA。 在這個階段會遇到什麼問題呢？SA是要作給客戶看的，讓彼此確定要做 的東西是否有一樣的認知，然後提供所有需求實做的追蹤矩陣，但，真 的就跟教科書一樣的那麼完美嗎？ 如果客戶根本不看你的SA呢？如果客戶根本看不懂你的SA呢？如果客戶 看了你的SA也同意了但根本就跟你同意的是兩回事呢？如果你寫的SA太 技術性，客戶不好意思說看不懂然後不懂裝懂亂答應呢？或者，你根本 覺得客戶的需求莫名其妙，但客戶卻堅持要做呢？ 有時候，客戶會把你的SA當屁，等你真的很認真把SA做完然後作SD，才 會發現根本就是白做工，很多時候客戶看到成品才會想到要這個改那個 。 既然是這樣，那你還要SA作啥？ 2.系統設計階段，SD。 假設，假設這樣好了（如果不假設根本不用談SD了），你的SA文件無懈 可擊，客戶也很有水準完全跟你認知110% Match。 於是，你要把需求展開成SD文件，變成PG可以施做的藍圖，等到把所有 的ERD都建立起來，Function Call也展開完畢，所有UML的Class Diag 、Seq Diag、Object Diag....都做好了，MVC的架構也分析好了， Multi-tier的各層架構也都分好了，現在就是讓PG按圖完成工作的時候 了！ 就這樣就結束了嗎？ 你的SD功力有能力在工作前就完成全部的藍圖嗎？有能力想到所有的東 西嗎？每個PG的水準都能了解你做的SD資料嗎？你能夠說服那些PG聽你 的東西施作嗎？還有，你自己又是建築師但同時又是水泥匠，那幹麼脫 褲子放屁多作一次SD？ 有時候，如果當一開始的假設不存在，做出來的東西跟客戶想得是十萬 八千里，那花那麼多時間做那麼完整的SD做啥？ 最常見的狀況就是SD完成了結果一邊做發現很多地方有缺，很多地方有 錯，很多地方有多，在那邊補補、修修、刪刪的結果，你的SD跟成品跟 本變成兩碼子事。 3.系統測試階段-TEST 既然要測試了，最重要的就是測試計畫跟測試報告，好了，測試計畫要 從那邊來呢？ SA。因為你要從SA的觀點來看系統的使用性。 SD。因為每個被撰寫出來的單元理論上都要經過單元測試才能上到整合 測試的程序。 測試有分很多種，黑箱測試、白箱測試、可靠性測試、壓力測試、隨機 測試、極限測試、單元測試、整合測試.... 再假設，你的SD跟程式產出完全吻合，你的SA跟客戶需求100%Match。 但，如果你沒有這些人力進行測試呢？你如果沒有足夠水準的測試人員 進行測試呢？如果交貨的期限極度接近但東西根本沒有測完呢？你有足 夠的平台測試在每個平台上是否都能正常運作嗎？ 最常看到的結果是，「OK！It's work！在我的電腦上他完全正確無誤 地被執行出來了！」 但在客戶端完全不是那麼一回事。 另外，如果SA跟SD的假設不存在，那這個測試大概也不知道能測些什麼 。 OK，那我要TEST幹嘛？ 4.系統交付階段-SA、SD、TEST、OP 東西要交給客戶了，如果客戶要自行維護，那麼SA、SD、TEST都要交付 出去，此外，操作手冊OP是免不了的。 但，當客戶端自行維護時發現SA、SD跟TEST都是賽的時候，公司就又可 以賺一筆維護合約了。 幾年後，公司倒了，這個系統交給別人接手，接手的PG或PM只會看到一 堆無可名狀的甲骨文程式碼，還有早就不知道跟那個便當盒一起丟到太 平洋裡面的相關文件。 == 理想，是在客戶、PM、SA、SD、PG全部都具備質、與量的時候才存在著 的，當客戶是笨蛋、PM不會Coding、SA不會說話、而且還跟SD、PG是同 一個人的時候，甭想產生足夠水準的分析設計文件。 禱告程式碼裡面該有註解的地方沒有少，還有不要有一堆a1、b1、aa1 、bb1的變數名稱才是真的。 -- 界(http://derekhsu.idv.st) 我的世界、世界的界線；我與這個世界的界線 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.230.150.174