Re: [請益]不能賣OS，也要學寫OS打下基礎：從程式뤠…
※ 引述《MasterChang (我愛ASM)》之銘言：
: 標題重點是「從程式實作中教軟體工程」
: 教的老師需要：一、實務經驗 二、理論基礎 三、教學熱誠
: 「教」要不要動手做？要不要有專案管理及系統發展的概念
: ，算一算大學裡有幾個這樣的老師？這就是為何需要真的找
: 有實務經驗的技術教師教學。
這是您的主張.
: 怎樣的規模可以導入軟體工程？什麼情況下要用軟體工程？
: 從CMM的5個階段來看，要達成Level3會很難嗎？顯然本身並
: 不難，問題是在人，在學校時，同學忽視軟體工程，老師也
: 軟體工程，交出來的學生到社會歷練，從基層員工到高階主
: 管會重視軟體工程嗎？跟請鬼開藥單差不多吧！？學校教師
: 忽視軟工的程度可能比我們想像的還糟糕。
這是您認定的問題所在--重視與否 ?
如果是是否重視的話, 那麼靠教育單位重視就能因此解決嗎 ?
: 唸過專案管理的人，下面5個Level的內容很多都是專案管理
: 要care的，甚至專案管理考慮的更多。那為何輕忽軟工的現
: 象一直都在，講難聽的就是連教育單位都不重視( 雖然軟工
: 是資工人會修的科目 )，另提到人月神話這本書，其實把他
: 當作閒書看看就算了，裡面有些內容其實與系統分析設計、
: 專案管理的理念有衝突，需要視實際情況調整。畢竟不是全
: 部人都對這些領域相互間的矛盾與衝突能有較深的體會( 我
: 也是一樣 )。
以上算是對 人月神話 的見解 ? 有甚麼衝突 ? 需要如何調解 ?
對於人月神話, 底下有篇比較分析, 可以參考:
=======================================================================
軟體尚方寶劍(Silver Bullet)何在
──Fred Brooks 和Brad Cox的不同觀點
歐陽進（臺灣）
前言
二十年來﹐人們一直尋找解決軟體危機的方法﹐包括結構化、人工智慧、物件導向
等方法﹔但軟體大師Fred Brooks 在1986年發表的文章裏預言在10年內找不到解決
軟體危機的尚方寶劍﹐歷經了十年﹐果然不幸被他言中。1995年裏﹐Brooks與Cox
兩位大師分別再深思軟體尚方寶劍﹐Brooks仍持懷疑態度﹐而Cox 則相當樂觀。
本文以時間的前後﹐依序交叉介紹兩位大師的見解﹐期能引起讀者對軟體未來的些
微興趣。由於筆者的學養和功力遠不如兩位大師﹐只能介紹他們文章裏的精華﹐並
未添加筆者的闡釋或見解以免您受到筆者有限能力的誤導或局限您的思想和視野。
希望您有空細讀兩位大師的原文著作﹐培養您自己的思維和創意。
介紹
二十年前(1975)﹐IBM大型電腦之父──Fred Brooks 出版一本書﹕"The Mythical
Man-Month"。 收集了他在1960年代領導1000多人共同發展OS/360大型軟體系統的心
得和經驗。從實際經驗中﹐他體會到開發大型軟體過程中﹐難以彙集參與人員的設
計理念然後提供給使用者一致的設計概念(conceptual integrity)﹐因而導致軟體
的高度複雜性﹐使得大型軟體系統往往會進度落後、成本暴漲及錯誤百出﹐就是所
謂的軟體危機(software crisis)。
經過了10年(1986)﹐Brooks發表了一篇著名的論文──
"No Silver Bullet: Essence and Accidents of Software Engineering"
他斷言﹕
「在10年內無法找到解決軟體危機的尚方寶劍（銀彈）」 (There will be no
silver bullet within ten years)。
這文章激起許多軟體專家的討論與爭辯﹐而"No Silver Bullet"也成為膾炙人口的
名詞。Brooks認為軟體專家所找到的各種方法皆捨本逐末﹐解決不了軟體的根本困
難──即概念性結構(conceptual structure)的複雜﹐無法達到概念的一致性﹐軟
體自然不親切不好用﹗
到了1990年﹐曾首先提出"Software IC"名詞的OO大師──Brad Cox針對Brooks的觀
點而發表了一篇重要文章── "There Is a Silver Bullet"
說明他找到了尚方寶劍──即有些經濟上的有利誘因會促使人類社會中的文化改變
(culture change)﹐人們會樂於去製造類似硬體晶片(IC)般的軟體組件(software
component)﹐將組件內的複雜結構包裝得完美﹐使得組件簡單易用﹐由這些組件整
合而成的大型軟體﹐自然簡單易用﹔軟體危機於焉化解了。
在1995年初﹐Brooks的上述名著第二版出爐了﹐書中含有一篇關於尚方寶劍的新文
章── "No Silver Bullet Refired"。文章裏﹐Brooks讚揚Cox的文章﹐但他認為
Cox誤解了他的本意。
儘管歷經了十年﹐軟體開發方法也有所進展﹐但Brooks 仍然認為尚方寶劍仍未出現
﹔大型軟體系統的開發工作仍然困難重重﹐只能漸進地改善﹐不要奢望短期內會出
現尚方寶劍﹐一舉解決軟體的困境。
在1995年底﹐Brad Cox發表了新文章──"No Silver Bullet Reconsidered"。這文
章裏﹐Cox更深刻探討文化和思維變遷(paradigm shift)的話因與效果﹐從人類文化
的觀點闡釋軟體危機的原因﹐而得到樂觀的結論──軟體的尚方寶劍是可能的。
過去10年﹐Brooks的預測是千真萬確的﹐果真軟體的困境不但未解決﹐反而更加嚴
重。那麼下個十年又會如何呢﹖有趣的是﹐大家來欣賞一下兩位大師的深思灼見﹐
然後再看看您個人的見解﹐也許會激勵出許多新創見也說不定﹐不是嗎？
1975
Brooks在"The Mythical Man-Month"書中之看法
該書是論文集﹐其中有一篇文章叫"The Mythical Man-Month"﹐他就以此作為書名。
在1956~1965 之間﹐Brooks實際領導IBM 360 大型電腦的開發計劃﹐包括硬體結構及
龐大的OS/360作業系統在內﹐因之他具有「IBM 大型電腦之父」之尊稱。由於OS/360
是多達1000位程式師共同合作的大型軟體開發工作﹐讓他深刻瞭解到大型軟體開發的
技術和管理上所面臨的種種困難和挑戰。於是﹐他就將其領導開發OS/360軟體系統的
經驗心得收集在這本書裏。
人們常拿Man-Month （多少人﹐做多少個月）來計算軟體的工作量﹐但是Brooks發現
軟體的開發工作是需要人與人之間密切溝通的﹐使得設計工作不易分割﹐所以
Man-Month 為單位的計算方法是有問題的(mythical)。也就得出著名的Brooks
法則── 「對於進度已落後的軟體開發計劃而言﹐若再增加人力﹐只會讓其更加落
後。」(Adding manpower to a late software project makes it later)
這是該書名稱的涵義。
Brooks從經驗中深深感覺到參與人員之間的概念一致性(conceptual integrity)是軟
體設計中最重要的一環(conceptual integrity is the most important
consideration in system design)
。一旦軟體師們有一致的設計概念﹐其所共同創造出來的軟體才有可能達到簡單
(simplicity)及好用(straightforward) 之效果。
為了達到這效果﹐Brooks主張應注重軟體的主架構(architecture)﹐並將它與實施
細節(implementation)分開來。所謂主架構﹐就是﹕對使用者介面之完整而詳細之
敘述(the complete and detailed specification of the user interface) 。
主架構彙集各軟體師的不同思緒﹐融合成為一致的概念﹐然後呈現給使用者﹐讓使用
者感覺軟體是源自于單一的設計理念(single philosophy) ﹐而不是基於龐雜無序的
眾多思緒。將主架構與施行細節分開來﹐是讓大型軟體計劃獲得一致性概念的有力途
徑(separation of architectureal effort from implementation is a very
powerful way of getting conceptual integration on very large projects)。
1987
Brooks在"No Silver Bullet"文章中的看法
自從"The Mythical Man-Month"一書上市以來﹐歷經了十年﹐儘管軟體專家們努力研
究新方法來解決軟體的困難﹔但是Brooks認為這些方法﹐包括高階語言、OOP 、AI等
皆捨本逐末﹐只解決了一些概念的表達(representation)技巧而已﹐並無法解決根本
性的概念結構(conceptual structure)問題。在"No Silver Bullet"文中﹐他藉亞裏
斯多德(Aristotle)的用詞而將軟體之困難分為兩種﹕
●Essence ──此為概念上(conceptual)的根本困難。
●Accidents ──此為將概念轉換為電腦表示法時﹐在表達(representation)上之困
難。
例如﹐OOP 上的抽象資料型態（即類別）觀念﹐只是改進了設計的表示方式而已﹐所
以抽象時只去除掉表達性(accidents)的複雜和困難﹐但並未去除掉任何根本性的複雜。
由於沒辦法解決這種根本性的困難﹐使得原本單純可愛的軟體﹐逐漸演變為進度落後
、成本暴漲、錯誤叢生等﹐像惡夢中的狼群般蜂踴而至﹐於是哀號而希望有種「銀彈」
（silver bullet 又譯為尚方寶劍）能即刻平息牠們。然而Brooks認為﹕
「不僅眼前找不到尚方寶劍﹐由於軟體的本質使然﹐未來也不太可能找得到。」
(Not only are there no silver bullets now in view, the very nature of
software makes it unlikely that there will be any)
Brooks列出的根本性困難包括﹕
●複雜性(complexity)──「複雜」是軟體的根本特性﹐可能來自于程式師之間的溝
通不良﹐而產生結構錯誤或時間延誤﹔也可能因為人們無法完全掌握程式的各種可能
狀態﹔也可能來自新增功能時而引發的副作用等等。
●一致性(conformity)──大型軟體開發中﹐各小系統之介面常會不一致﹐而且易於
因時間和環境的演變而更加不一致。
●易變性(changability) ──軟體的所處環境常是由人群、法律、硬體設備及應用
領域等各因素融合而成的文化環境﹐這些因素皆會快速變化。
●不可見性(invisibility)──軟體是看不見的﹐既使利用圖示方法﹐也無法充分表
現其結構﹐使得人們心智上的溝通面臨極大的困難。
這些是軟體的本性﹐Brooks認為沒有捷徑可解決之(there is no royal road)。但可
以漸進式地改善之。他認為可行的方案有﹕
＊買來裝配(buy and build) ──軟體的建造儘量使用現有零組件﹐不要一切都從頭
做起。
＊快速雛型(rapid prototyping) ──使用重複式的開發方法(iterative development)
來漸進地改善軟體的雛型﹐裨逐步厘清使用者需求。
＊有機成長(growing organically) ──有生命的東西皆是由小慢慢長大的﹐建造大型
軟體的方法應該是逐漸成長﹐而不是一次建造完成。
＊優秀設計者(great designer) ──人是軟體設計的核心﹐良好的方法可改善人的創造
過程﹐但無法激勵人的原本創造力﹐須藉重有創意的人。
1990
Cox在"There Is a Silver Bullet"文章中的看法
Cox 在文章開頭就提到Brooks在"No Silver Bullet"一文中的悲觀看法﹐Cox 寫道﹕
And in "No Silver Bullet: Essence and Accidents of Software Engineering,"
he(Brooks) argues that the difficulties are inevitable, arising from
software's inescapable essence--not from accident, but from some deficiency
in how programmers build software today.
（在"NSB" 文中﹐Brooks聲稱這些軟體的困難是無法避免的﹐是源自軟體上無法逃避的
根本質──亦即不是來自一些旁技細節﹐而是今日程式師設計軟體時缺點）
接著﹐Cox 針對Brooks所提的軟體困境所在﹐Cox從新的觀點來闡釋之﹐而得到樂觀的
結論。
Cox認為軟體危機是必然會面臨的(irresistible)的困境﹐但並非是無法克服
(immovable)的。當全球經濟進入資訊時代﹐市場對資訊殷切需求而產生的經濟誘因
(economic incentive)﹐將促成人們社會中的文化改變(cultural change)
。加上目前遭遇的軟體困境﹕成本過高、品質不良、以及人們無力去改善它們。使得
人們對軟體的看法和思維產生巨大的變遷(paradigm shift)﹐從過去一行一行撰寫指
令的土法煉鋼方法轉而嘗試去建立可重複使用的標準組件(standard component)以及
組件交易市場(market)。在這種新環境中﹐軟體的價值體系(value system)、權力結
構(power structure) 、以及軟體師與消費者關係重新定位﹔徹底從過去重視程式的
撰寫過程(process) 轉而重視組件價值、擁有、及買賣系統等基本文化要素、而導致
軟體產業的革命(software industry revolution)。
軟體組件類似於硬體的晶片(IC)一般﹐把組件的複雜封裝起來﹐對使用者而言﹐調組
件再也不複雜了。因之﹐建立軟體晶片市場﹐讓人們不再受困於組件內程式撰寫的複
雜﹐而專注在組件本身的使用、價值和買賣上﹐軟體的複雜和困難就自然煙消雲散了。
因之﹐文化和思維的變遷將是一把尚方寶劍﹐能克服軟體的困境﹔而且這種變遷是即
將來臨的﹐並非海市蜃樓！
1995
Brooks在"No Silver Bullet" Refired文章裏的看法
自從1987年Brooks發表"No Silver Bullet"一文之後﹐激發了許多人對到底有沒有尚
方寶劍的討論與爭辯﹐例如前述的Cox 之"There Is a Silver Bullet"文章﹐以及Harel
的"Biting the silver bullet"文章等等。
Brooks在理解各方的反應﹐以及檢驗當今各種軟體設計方法之後﹐他仍認為尚方寶劍尚
未出現(the magic solutions are not just around the corner)。
Brooks讚揚Cox 的"There Is a Silver Bullet"文章是一篇極佳的文章﹐可是他認為
Cox 誤會了他的本意﹐誤解之處有二﹕
《1》 如上節所述﹐Cox 在文章中寫道﹕
"...but from some deficiency in how programmers build software today."
Cox 把根本性困難解釋為軟體建造方法上的缺失﹐事實上Brooks所謂的根本性困難是
指軟體上概念性的複雜所導致的﹐無論使用什麼方法﹐無論在任何時刻﹐皆必然呈現
的軟體固有特性。
《2》如上節所述﹐Cox 在文章中寫道﹕
"...Brooks argues that the difficulties are inevitable..."
事實上﹐Brooks認為他自己只是持懷疑之態度﹐並非認為尚方寶劍是完全沒希望的。
例如﹐Brooks認為軟體系統的複雜是可分層次(level) 的﹐若軟體下層的小組件
(object)組成上層的大組件﹐再由大組件組成更大之組件﹐層次分明地組織起來﹐則
複雜度就可以減低了。還有﹐當軟體由小而大漸進地有機成長時﹐雖然複雜有系統地
增加﹐但可確保軟體的正確性。導致這種困難的原因仍可藉漸進式地改善或去除﹐只
是沒有捷徑罷了。
Brooks認為OO是個有希望的途徑﹐但由於牽涉到人們思維方式的轉換﹐使得企業組織
必須先投下資金(front-loaded cost) ﹐才能逐漸回收其利益(down-stream benefits)
﹐因而OO的進展會是慢如蝸牛。既使它可解決軟體危機﹐也不會是在眼前。
1995年底
Cox在"No Silver Bullet" Reconsidered 文章中的看法
Cox 認為Brooks所謂的根本(essential)困難──complexity、conformity、
changability 及invisibility──並非最根本﹐而是由一個隱藏在深處的病因(cause)
所造成的症狀(symptoms)罷了。這個病因就是﹕
目前文化中缺乏有利的誘因來鼓勵企業公司生產、買賣軟體的組件(component)以及更
少的子子孫孫組件(subcomponent)。
如果買賣各層組件者皆有利可圖﹐自然會想盡辦法將組件封裝得簡單易用﹐則Brooks所
指的軟體困難自然消失了。
Cox 覺得Brooks的觀點是以技術為核心(technocentric) ﹐而他的觀點則是以人為核心
(human-centric) 。由於觀點的差異﹐對軟體危機的闡釋自然會獲得不同的結論。他的
結論是﹕尚方寶劍是可能的﹐只是這把劍是軟體思維的變遷(paradigm shift)﹐而不是
技術(technology)。
想一想﹐造鉛筆的公司賣掉了一支鉛筆﹐就少了一支鉛筆﹐亦即少了這鉛筆的各小組件﹐
如鉛筆擦、筆心等。為了要再造另一支鉛筆﹐就得付費去購買鉛筆擦和筆心﹐使得製造
筆心等小組件之企業公司也有利可圖。因之﹐鉛筆到鉛筆擦、筆心等製造者皆會用心去
把組件包裝好﹐使其簡單易用﹗
但是﹐在軟體中﹐製造試算表軟體的公司﹐賣出一套試算表軟體﹐只是個拷貝動作﹐並
不會少掉一個位元﹔不必再向小組件的製造者購買﹐使得小組件製造者無利可分﹐自然
無法進行生產、包裝和買賣了﹔這是目前軟體業的困境。
在未來新文化之中﹐使用者(end user)每使用一次某物件(object)﹐就必須付一次費用
給這物件的生產者﹐而這生產者則必須付一次費用給其內部各次物件(subobject)
的生產者﹐依此類推到最小的組件為止。在此環境中﹐各層次物件之複雜結構皆封裝得
完義無缺﹐使得各層物件皆簡單好用﹐軟體的複雜與困難就迎刃而解了。
結論
在前言中已提到﹐本文只是介紹Brooks與Cox 的文章精華﹐筆者因能力所限而不做推
論﹐當然不會有結論﹐盼您在細讀過這兩位大師的原文後﹐才做出您自己的結論。如
果您願意﹐也盼您有所結論時﹐能與筆者分享﹐自當感激不盡﹗再會了。
[參考資料]
[1] Brooks, Frederick. The Mythical Man-Month. Reading, MA:Addison-Wesley,
1975.
[2] Brooks, Frederick. "No Wilver Bullet:Essence and Accidents of Software
Engineering," IEEE Computer(April 1987"), PP.10-19.
[3] Brooks, Frederick. The Mythical Man-Month, the 20th anniversary edition.
Reading, MA:Addison-Wesley, 1995.
[4] Cox, Brad. Object-Oriented Programming:An Evolutionary Approach,
Reading,MA:Addison-Wesley.
[5] Cox, Brad. "There Is a Silver Bullet." Byte(October 1990), PP. 209-218.
[6] Cox, Brad. Superdistribution "Objects as Property on the Electonic
Frontier. Reading, MA:Addison-Wesley, 1995.
[7] Cox, Brad. "'No Silver Bullet'" Reconsidered," American Programmer
(Novermber 1995), PP.2-8.
[8] Harel, D. "Biting the silver bullet:Toward a brighter future for
system development," IEEE Computer(January 1992), PP.8-20.
Fred Brooks 在1956-1965 之間領導IBM System/360大型電腦的開發計劃﹐建立了IBM
在商業電腦市場上的盟主地位。目前任教於University of North Carolina at Chapel
Hill。
1975年他出版的"The Mythical Man-Month"一書﹐是軟體設計方面的經典名著。歷經
20年﹐該書第二版終於在1995年上市﹐一出爐就發行250000冊。1986年﹐他發表了重
要文章──"No Silver Bullet"﹐激起眾多人士對軟體危機與奇跡的好奇與爭論﹐一
直持續到今天。
Brad Cox是著名的OO大師﹐他的重要著作── “Object-Oriented Programming: An
Evolutionary Approach"
家喻戶曉的「軟體IC」一詞就是來自他的著作。他是Objective-C 語言的創造人；目
前任教于Geoge Mason 大學。他最近出版一本新書－－ “Superdistribution:
Objects as Property on the Electonic Frontier”
探討在朝向全球性資訊密集產業過程中所面臨的各種問題和困難。Cox相信化解軟體
危機的尚方寶劍是文化的改變﹐即人類思維模式的變遷(paradigm shift)﹐而不是
技術(technology)。
========================================================================
: CMM的軟體工程的成熟度五個等級如下...一般公司要有Level 3
: 且確實執行並不是這樣難。
: [引用 蔡學鏞 沒人在乎軟體工程]
: 根據 CMM 的定義，軟體工程的成熟度分成五個等級，簡單介紹如下：
: 1. CMM-Level 1（initial）：軟體程序漫無章法，程序未被定義。
: 專案計劃的成功仰賴於工作人員個別
: 的努力。
: 2. CMM-Level 2（repeatable）：已建立基本的管理程序，對成本、
: 時程、和職務權責能加以追蹤、查
: 詢。已有作業程序所須具有的紀律
: ，所以有能力重覆使用相類似的專
: 案成功的案例與經驗。
: 3. CMM-Level 3（defined）：屬於管理和工程的活動都已設計、定
: 義好，並且文件化，完整地整合成組
: 織內的標準作業程序。各個專案計劃
: 延用標準程序或被認可的標準程序修
: 改程序。
: 4. CMM-Level 4（managed）：組織可收集詳細的軟體程序以及軟體
: 產品的量測資料。軟體作業程序和產
: 品都有一組量測的數據，可讓工程師
: 和經理們了解程序和產品的狀況。
: 5. CMM-Level 5（optimized）：評估革新性的新技術，有規則地依
: 序導入採用，以持續不斷地改進程序。
: 回到ephesians的問題。
: 1.你目前有沒有在帶什麼專案計畫?有沒有親自著手寫程式?
: 2.如果有個小小工作,是需要程式做點system call,你能不能解決?
: System call如果不聽話,其中的問題你能不能夠排除?
: 3.學生做OS練習真的很容易碰到上述問題,既然說要帶學生多練練,
: 你是否具體實踐了?
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.115.1.146
推
06/21 12:56, , 1F
06/21 12:56, 1F
推
06/21 18:07, , 2F
06/21 18:07, 2F
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 39 之 66 篇)：