誰還記得 TSR

最近蘋果陣營裡面除了 iPad 首賣之外，另外一個同樣受人矚目的消息就是蘋果透露 iPhone OS 4.0 將要推出的新功能了。iPhone OS 4.0 將要支持多工（multitaksing）是蘋果宣布的消息裡面，很受人矚目與議論的項目，在眾媒體與評論家的回饋反應中，我最欣賞 Geek and Poke 的 Finally Apple Has Discovered TSR ！

Geek and Poke 說的妙，今夕何夕？ TSR，好遙遠卻又能激發我熱血的字眼，從大學畢業之後，我的第一份工作的第一個項目，就是用 Turbo C 開發一個 TSR 呢！！！

Really? WOW!

天那麼黑，風那麼大

在網路上衝浪（surfing）的時候，發現舊日國語課本剪影，想起「天那麼黑，風那麼大」的那個年代，還有站在小溪邊看魚兒奮力往上流游的偉人，不禁莞爾。

網路上有人把「爸爸捕魚去」的課文默寫出來，據說過去三十年間課文內容曾經有過少許異動，我已經不記得當初我唸得是那個版本，下面的版本據說是較早的文字，和我生長年代的氛圍比較接近。

記憶是靠不住的，所以不必細究，就當是這個版本吧。

天這麼黑 風這麼大 爸爸捕魚去
為什麼還不回家
聽狂風怒吼 真叫我害怕

爸呀 爸呀
只要你平安回家
就算是空船也罷

我的好孩子
爸爸回來了
滿船魚和蝦
你看有多少

賣了魚蝦買米布
全家大小得溫飽
爸爸不怕累
只要你們好

有網友抓了一些令人懷念的圖片，有興趣的人自己去挖寶吧....

• 令人懷念的遠古時代小學國語課本
• [懷舊] 爸爸捕魚去 - 小學國語課的共同回憶(國編本)
• [懷舊]五、六、七年級國民小學國語課本

BIRGIT'S JOY～BIRGIT逍遙遊@PIXNET星球 - 令人懷念的遠古時代小學國語課文 via kwout

和竹中合唱團有關的幾個網址

以前常看潘震澤教授的科普文章，但是直到最近才從他的部落格中知道，他是57年的竹中合唱團員，對於我們這些余生也晚的後生來說，他們那個年代的事蹟都是永遠在記憶裡的傳奇。潘教授在他的部落格裡放了竹中合唱團在53-55年間作的錄音，非常珍貴，而且透過他的部落格，還找到其他學長作的合唱相關的網站。

為了紀念，也為了備忘，把相關的書籤紀錄如下：

• 合唱欣賞～永遠的合唱人
• 合唱影片欣賞
• 蘇森墉音樂館─多媒體視聽區
• 寂寞的先知——悼念蘇森墉老師
• 蘇森墉合唱音樂欣賞（五)
• 蘇森墉合唱音樂欣賞（四)
• 蘇森墉合唱音樂欣賞（三)
• 蘇森墉合唱音樂欣賞（二)
• 蘇森墉合唱音樂欣賞（一）
• 我的音樂淵源（三）——竹中音樂經驗（II）
• 我的音樂淵源（二）——竹中音樂經驗（I）

即將走出人們視野外的 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 的資料了）。不過在那個時空環境，帶給業界和許多從業個人的影響，不容抹煞、忽視，也不可能輕易被抹去消失的。