Re: [請益]不能賣OS，也要學寫OS打下基礎：從程式뤠…

看板Programming作者ggg12345 (ggg)時間17年前 (2007/06/20 19:25)推噓10(10推 0噓 4→)

留言14則, 6人參與討論串35/66 (看更多)

※ 引述《MasterChang (我愛ASM)》之銘言： : ※ 引述《ggg12345 (ggg)》之銘言： : : 再回想一下標題: : : " 即便不能賣OS，也要學寫OS打下基礎：從程式實作教軟體工程 " : : 這裡強調的是 "教" 軟體工程. : 標題重點是「從程式實作中教軟體工程」 : 教的老師需要：一、實務經驗二、理論基礎三、教學熱誠 : 「教」要不要動手做？要不要有專案管理及系統發展的概念 : ，算一算大學裡有幾個這樣的老師？這就是為何需要真的找 : 有實務經驗的技術教師教學。 : 怎樣的規模可以導入軟體工程？什麼情況下要用軟體工程？ : 從CMM的5個階段來看，要達成Level3會很難嗎？顯然本身並 : 不難，問題是在人，在學校時，同學忽視軟體工程，老師也 : 軟體工程，交出來的學生到社會歷練，從基層員工到高階主 : 管會重視軟體工程嗎？跟請鬼開藥單差不多吧！？學校教師 : 忽視軟工的程度可能比我們想像的還糟糕。 : 唸過專案管理的人，下面5個Level的內容很多都是專案管理 : 要care的，甚至專案管理考慮的更多。那為何輕忽軟工的現 : 象一直都在，講難聽的就是連教育單位都不重視( 雖然軟工 : 是資工人會修的科目 )，另提到人月神話這本書，其實把他 : 當作閒書看看就算了，裡面有些內容其實與系統分析設計、 : 專案管理的理念有衝突，需要視實際情況調整。畢竟不是全 : 部人都對這些領域相互間的矛盾與衝突能有較深的體會( 我 : 也是一樣 )。 : 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）：評估革新性的新技術，有規則地依 : 序導入採用，以持續不斷地改進程序。 ===== 在資工教OS跟在電機教OS是兩種不同的世界, EECS 的人不會去區分純軟體與否, 但CSIE的成員多數自認要跟電機/電子有所區隔, 所以他們強調為純軟體的發展而研究, 教學與服務. 有這種針對 "純軟體" 的發展使命感沒有不好. 台灣能教OS同時達到下面三件事的人不少,不過就觀察看見的, 幾乎都是EECS背景, CIS/CSIE 出身的在特定某校的也有. 但很少. 做研究跟教學的又另當別論. 教學要派習題不難, 一個班總有幾個突出的, 真正要看的是環境與支援, 真正進入狀況的學生比例是多少. 這裡一再要提醒強調的就是: 多數所接觸到做軟工的, CSIE或CS類一再強調"純軟體"的實例願望, 就接觸到較熱心於軟工的, 他們對下例的 System call 這種OS層軟體是不以為然的, 因為 system call 是 trap 是一種硬體提供的機制. 至於切入程式碼攔截轉向, 那更是無法接受這類東東是正規的純軟體工程方法. 這個 "純軟體" 的願望, 才是台灣整個軟體工程的關鍵問題 ! 至於希望延攬業界有實務經驗的人才加入, 個人並不反對, 不過, 不是負責教軟工的實在不必越界多言, 他們有其心目中的業界. 當教師的自然有其標準與看法, 你可以教OS, 但沒必要用OS的例子去教不歸你份內的 "純軟體工程" 去惹來別人蹦蹦跳, 不以然. 寫程式要有軟工概念沒人會反對, 要活學活用軟工的原則也沒人反對, 但是若說把加強溝通, 樣機展示, 付費請專家搾出買方肯付款的規格來, 大概也不會有意見, 但如果說方法之一就是與提出規格方分享利潤, 合作將產品賣給使用者, 譬如請 DELL 這種 Buyer 當 on site customer expert 來認可規格. 十個有九個就像在這一樣的要蹦蹦跳了. 不過, 也別急, 從來沒說這種方法是軟工, 只說這種事跟軟工要強調的溝通方法是不是相關類似 ? 相信很多人心中還是說風馬牛不相及耶 ! 那您說軟工還可以像這樣教這樣解釋嗎 ? 這樣教是自尋死路不是很清楚了嗎 ? 那麼說軟工很重要, 非常重要, 弄通了會無往不利(譬如找 DELL 分工) 總可以了吧 ! 抱歉那也不行, 有沒有心悅誠服用軟工的方式要求學生做實例練習呢 ? 那麼甚麼是軟工的方式 ? "純軟體" 才是喔 ! 那就不要強人所難了 ! OS 不談硬體中斷, 切換, 併行可以嗎 ? 至少, 個人所認知的是不可以至於別人不這樣教, 那是他的專業問題. 這種現象其實也發生在教演算法的, OS 也有一堆演算法與資料結構, 但同理, 教 OS 的人談的演算法都被歸類為實務不是真正的演算法 ! 所以, CSIE 教OS的就很安份的教理念中的 OS , 做 OS 該會的實例, 不去教軟工與演算法總可以了吧 ! 不過, 還是要請各位幫忙替軟工找出一些純軟體的實例才好 ! 因為還是很希望軟體產業能起得來, EECS 才能沾光有飯吃 ! : 回到ephesians的問題。 : 1.你目前有沒有在帶什麼專案計畫?有沒有親自著手寫程式? : 2.如果有個小小工作,是需要程式做點system call,你能不能解決? : System call如果不聽話,其中的問題你能不能夠排除? : 3.學生做OS練習真的很容易碰到上述問題,既然說要帶學生多練練, : 你是否具體實踐了? 想來上課當學生學 OS 嗎 ? 不會讓你失望的 ! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146

推

haryewkun

06/20 19:51, , 1^F

06/20 19:51, 1^F

推

MasterChang

06/20 19:59, , 2^F

06/20 19:59, 2^F

→

MasterChang

06/20 20:01, , 3^F

06/20 20:01, 3^F