即將走出人們視野外的 SDG 2.0

最近，有個朋友接了個不大不小(不是 quick and dirty 的小案，但也不是可以讓供應商穿金戴銀的數字，所以叫做不大不小)的系統開發案，甲、乙雙方為了文件交付標準，起了不小的爭執。經過協調，最後兩方都同意不用 CMMI 的標準（天曉得什麼是 CMMI 文件標準），改用最低的標準「 SDG 2.0」作為文件的撰寫。

過去十幾年來，大部分政府的軟體開發案，都要求以軟體發展指引（Software Development Guidelines簡稱為SDG）2.0，作為交付文件撰寫的標準。有點資歷年紀的老骨頭們，對於這套東西都很熟悉。當時，只要案子的規模大一點，每個廠家都得照著規矩弄出一套套的 FSD、 SDP、 SRS、 SSS、 SDP、 STP、 SDD、 SUM、 OPM 等等...


SDG （軟體發展指引） ，是經濟部於民國七十五年委託資策會以美國國防部的 DoD-STD-2167A（1,2）為藍本，參酌國內的情形，所制訂的軟體發展方法與準則，規範軟體發展的作業程序，並且提供了一套文件撰寫的範例。1986年3月，資策會發表 SDG 1.0，1988年12月1日SDG 2.0出版，全套共18冊。

1. 軟體發展指引總論	10. 系統規格指引
2. 建議書徵求文件指引	11. 軟體需求規格指引
3. 建議書指引	12. 軟體設計規格指引
4. 合約指引	13. 軟體測試規格指引
5. 軟體發展計畫指引	14. 軟體使用手冊指引
6. 軟體建構管理計畫指引	15. 操作手冊指引
7. 軟體品質保證計畫指引	16. 介面需求規格指引
8. 可行性研究文件指引	17. 介面設計文件指引
9. 成本效益分析文件指引	18. 版本說明書文件指引

稍後，資策會和凌群電腦合作開發 SDG Workbench，可以自動產生符合 SDG 2.0 規範的文件章節架構，協助開發人員製作和交換文件。當時，我用 workbench 產生了一份章節架構的空白文件，現在還在我的書架上(參閱上圖)。而當年凌群電腦研發處參與這個案子的工程師，現在已經是凌群電腦的處級主管了。


因為 SDG 主要是以承襲(翻譯乎？抄襲乎？)自美軍的 DoD-STD-2167A，所以自然也繼承了 2167A 的缺點。在 Wikipedia 的文章裡，介紹了業界對於 2167A批評(See below)。而受了軍方行事風格影響，文件的種類、格式過於繁雜、冗遢，則是我個人最受不了的地方；工業局軟體工業五年發展推動計畫（軟五）的軟體技術文件指引手冊前言中，也自述新的文件指引比SDG 2.0 精簡；ISO/IEC12207標準中也主張「在軟體專案發展流程中不要像DOD-STD-2167A要求許多繁雜的文件手冊」之原則，可見在這一點上，英雄所見略同啊。

One criticism of the standard was that it was biased toward the Waterfall Model. Although the document states "the contractor is responsible for selecting software development methods (for example, rapid prototyping)", it also required "formal reviews and audits" that seemed to lock the vendor into designing and documenting the system before any implementation began.

Another criticism was the focus on design documents, to the exclusion of Computer-Aided Software Engineering (CASE) tools being used in the industry. Vendors would often use the CASE tools to design the software, then write several standards-required documents to describe the CASE-formatted data. This created problems matching design documents to the actual product.

One result of these criticisms was to begin designing a successor standard, which became MIL-STD-498. Another result was a preference for formal industry-designed standards (such as IEEE 12207) and informal "best practice" specifications, rather than trying to determine the best processes and making them formal specifications.

隨著軟體開發方法論的進展，以及網際網路的盛行，今日所開發的軟體規模、複雜度都比當年要龐大複雜多了，原本的指引已經不敷使用。時至今日，美軍已經用 MIL-STD-498 取代 2167A，軟五辦公室也用軟體技術文件指引手冊取代了SDG2.0。跟著 SDG 一起度過江湖歲月的年輕人，也變成江湖裡的老骨頭，變成更年輕的傢伙們口中討厭的前輩了。

雖然 SDG 文件範例和指引，沒有考慮到新的軟體工程進展，也不像新的文件指引那麼彈性，但是其中所蘊含的養分，恰好是那個年頭台灣軟體產業所缺乏的。許多我這一輩的同儕，從那些枯燥、乏味的文件裡，各自找出一套理解這個世界的方法，發展出屬於個人的武功。從這個角度來看，SDG 的貢獻比想像中要大得多了。

SDG 2.0 不完美，也快走出人們的視野外，（網路上已經很難找到 SDG 2.0 的資料了）。不過在那個時空環境，帶給業界和許多從業個人的影響，不容抹煞、忽視，也不可能輕易被抹去消失的。