為什麼這篇軟體設計規格書鄉民發文收入到精華區：因為在軟體設計規格書這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者oaz (幸福治安：破案數/十萬人)看板Soft_Job標題Re: [請益] 有公司用這種開發方...
軟體設計規格書 在 Sowilo 太陽塔羅 X 雷諾曼 Instagram 的最佳貼文
2021-08-03 12:55:28
2021托特塔羅+雷諾曼 🔥雙卡課程 第11班 線上課程🔥 ❤️報名開始(報名截止8/14 23:59) 🌈上課時間/日期/價格(每班10人/6人即開班) 🍀週一晚上線上課程/NT$16000 （晚上7點～晚上10點） 8/23~10/18(9/20停課) 八週共24小時 🍀週日晚上線上...
※ 引述《sniffer (again)》之銘言：
: ※ 引述《oaz (幸福治安：破案數/十萬人)》之銘言：
: : 前在公司上過軟體外包管理的課程
: : 有提到類似的事，提到的例子好像是花旗
: : 我個人的心得是
: : 一、系統架構要很強（SA），設計出來的東西不能到實作才發問題
: : 二、規格要很明確，明確到每個函式都要定出來
: 永遠都會有沒考慮到的問題, 不然瀑布架構不會被檢討,
基本上，台灣的規格書是比較接近需求搜集，然後下一步就要實作
譬如：
規格書定義：一個畫面有三個按鈕，按了第一個要做什麼，第二個要做什麼事，第三個要做什麼事
但比較學院派的人作法，是比較接近物件導向分析與設計
譬如，會從使用者案例開始玩起
就使者案例來說，除此需求之外
還要考慮，使用者按了第一個按鈕後，再按第二個按鈕，這時候會如何？
或者，使用者連續第一個按鈕，會不會出什麼問題？
或者，這時系統發生了什麼事件，譬如網路斷線、東下下載完了
程式是否要通知使用者或更新書面
每種用法都要清清楚楚的列出來。如果有些結果還不確定，就要再回去
如果做得好，不會等到程式實作差不多後才發現
如果使用者怎麼做，會有大問題，所以要改架構
如果系統這時網路斷線，會有大問題，所以要改架構
做完使用者案例，還要做系統架構分析、物件分析
要達成每個案例，系統該包含哪些物件，有什麼責任
再根據每個物件
理論上，這都是 SA 、SD 的人要做的
但是，台灣只有 PM 提出要做什麼（還很不明確），
然後 RD 要身兼 SD、SD、PG
: Boss, HW bug, OS bug 都會引起各種架構變化,
基本上，每種因素都會引起各種架構變化
因此：
一、當設計的時侯要儘量有彈性，這也是 SA、SD 要有足夠能力
二、就風險管理的角度，儘管有一百種各式各樣的因素導致架構變化
SA、SD 還是要能儘管可能掌控各種因素，譬如其中的九十種
SA、SD 不能因為還有十種因素不能掌控，所以連那九十種因素都不掌控
: 而且這樣做, 規格書可能比程式還多, SA自己寫全部code還比較快
照比較正規的作法（學院派），可能規格書真的比較 code 多
不過要考慮一個因素，是因為這種規格書比較因素比較多，所以才會比較厚
至於所謂的 SA自己寫全部code還比較快
基本上，這純粹是規模問題：
譬如要蓋一間狗屋，應該不會有人大材小用還給出一個規格書
當然是先動手做再說
但如果要蓋一棟高樓大廈，
總不會說規格書會太厚
設計師自己去蓋房子說不定還比較快
: 每個函式都要定出來, 是用在程式模組之間的介面,
: 不是要SA把程式架構裡的每個函式都弄出來,
: programmer越高段, 模組就可以越粗略, 自行發揮就好,
: 無法自行發揮的, 回去賣雞排啦
: 無法理解程式運作的人, 同時也等於無法debug的人,
: 能分工寫出來卻不能debug, 這算什麼分工
: : 三、公司要有明確的程式設計風格，如
: : 基本上， coding 是沒什麼大不了的
: : 因為規格都詳細到函式，而且程式設計風格有明確規範
: : 不同的人寫出來的差不大
: : 但以台灣的現況：
: : 一、台灣的公司不怎麼注重系統架構
: : 真正的系統架構強者大概也不會受到重視，公司也不會想到要去培育
: 君不見園區各大公司裡面, 往往只有幾個人負責設計,
: 只是他們職稱都很大, 一般人以為他們沒做事而已, 他們累死了,
: 如果還要他們寫架構書, 再去讓英文很爛的咖啡工程師把英文轉成程式,
: 只會更沒效率, 更多咖啡工程師抱怨賣肝
所以說，是台灣不重視 SA 、 SD
否則，為什麼只有幾個人負責設計？
只有幾個 SA 、SD ，然後有幾百個 PG 嗎？
那是因為，在台灣， RD 要身兼 SA、SD、PG
如果是原作者說的那種玩法
那就要有數十位以至數百位 SA、SD，是公司最重要的資產
然後 PG 找工讀生或外包
: : 二、台灣的公司規格一改再改是理所當然，規格詳細到函式根本是自討苦吃
: : 而且，台灣的公司規格稱不上是規格
: : 頂多是需求的定義（譬如要做什麼，要有什麼功能），然後就開始實做
: : 之後的系統設計、實做，都是 RD 的責任
: 改規格是一定的, 如果需求都不會改變, 什麼都作成ASIC就好,
: 哪裡需要軟體業, 軟體業就是為了"改"而生的, 全世界都一樣
改規格是一定的，但是 SA 、SD 要儘可能分析各種可能
儘可能設計到有彈性，使得之後的改變最小化
SA、SD 不能因為還有十種因素不能掌控，所以連剩下的九十種因素都不掌控
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.112.30.46
→ howshou:開發要有彈性，件事要很小心。有時候雙方白紙黑字寫的很沒 11/12 15:16
→ howshou:彈性，簽約後才不會有玩文字遊戲的空間。這當中頗多淺規則 11/12 15:18
→ howshou:，簡單的說有時候要裝笨，對開發方會較有利。 11/12 15:21
→ leiyan:專業SA/SD都去做套裝軟體了 委外的東西只好給PG做 11/12 15:32
→ askeing:應該不少情況是看著PRD就必須要開始寫了… 11/12 17:44
推 yoco315:這篇有夠中肯，真的寫大程式才會知道.. 11/13 21:07