大長多多
學生們還是問，為什麼需要軟體工程？和程式設計有什麼不同？為什麼需要作專案管理、監控、控管等等？寫得出程式不是比較實在嗎？
這是因為學生寫的程式太小、參與開發的人太少、專案關係人太少、而維護的時間太短，以致於他們無法想像軟體工程的必要性。
真的軟體專案是『大長多多』的。
到了業界，一個專案要破萬行很容易的，程式一旦大，相互關係就會變複雜，動一行指令可能會牽涉到好多地方。所以需要學軟體工程，學如何切模組、作架構設計。學設計概念，知道如何才容易維護、好擴充功能。程式一旦變大，它的成本也會指數性的上升，你需要學習成本估算的方法。
專案的時間通常很長，不是一個星期能完成的家庭作業。所以你需要專案文件（幫助你記憶），專案管理（來掌握時間與分配人力）。維護當然把整個時程拉的更長，所以設計的時候要考慮彈性、成本要把維護算進去。在組織人力調配上，你需要考慮開發與維護是否是同一組人。在這麼長的時間裡，各種不同的版本會產生，你需要版本控管的機制，也需要需求管理來控管變更。
學生的作業多是老師給好的題目，於是很難體會為什麼需要系統分析。業界的專案牽涉的人多，光是『安排』訪談可能就需要一個月。每個人的意見都不一樣，你必須學習一些系統分析的方法來收集、挖掘、歸納、整理、協調、妥協這些需求，再讓這些需求一個個的被所有人確認。除了清楚的腦袋、好的溝通能力、專業技術的判斷，你也需要一些系統分析的方法論。
一個真正系統的完成，需要的專業知識太多，決不是一個人能夠完成的，我們需要很多人一起來開發。如何組織這些人？如何分工？是依照<專案管理師、系統分析師、系統設計師、系統工程師、系統測試人員>來切割？還是依據領域來切割？這麼多人合作，版本管理更重要了。組織也需要定一套一致的 coding standard 及 SOP來提升整體的效率。
學校的『小短少少』的環境有時候很難體會軟體工程的重要性。透過專題的製作與建教合作或許有些幫助。
非常同意薛老師! 程式設計師的programming skill固然對於專案的成敗與品質影響很大，但是沒有follow大家一致認同的作業方法(軟體工程)，在專案走到一個out of control的地步的時候，只會搞死所有專案成員。
回覆刪除業界與學校最大的差別是 ... 一個賺錢的壓力，一個沒有。
回覆刪除我們真的有"業界"(可以用軟體賺錢，但不是出賣勞力)的發展空間嗎？如果沒有，那又為什麼呢？雖然金融海嘯嚴重打擊了國際各種產業，但最近所報導全世界最富有的前三個人當中仍包括了微軟及甲骨文的老板(他們都是軟體"業界"的成員)。我們跟他們當然無法相比，但偷偷思考一下、罵一下，過過乾癮，也許可以爽到。
回覆刪除他們這種"業界"，就是有辦法不斷推出新的產品、技術、文章，然後不管是疲勞轟炸或是「謊言說多了就變成真的」(沒有吃醋的意思)的行銷技巧，就是能讓年輕人追求，在他們的金箍咒之下重複那些別人已經作過千萬次的程式設計，而且還由他們評鑑來發認證證書。多年來，我們的"業界"(如果有)是否就是在他們的"業界"之下茍衍求生呢？
一般軟體生命週期中程式設計的比例只佔15%，而其他的85%我們大多忽略掉了。如果我們的"產業"還只是建立在軟體從業朋友們的程式設計樂趣以及比不會寫程式的其他朋友而言有著自我的優越感之上，其他就沒有了，那就真的是很悲觀的。
再者，現代的軟體開發方式與老師們當年所學習的"寫程式"已經是完全不同了。當年是除了compiler之外什麼都沒有；現在是只要你能搞定business process或business intelligence，其他什麼都不需要操心。我們的"業界"，客戶，學者專家等通通算進去，到底有多少人可以有能力用如BPMN的方式來描述需求呢？(說不定有很多，臥虎藏龍，不輕易出山或出水。)
學習軟體工程就是一種可以由純粹程式設計逐漸導入健康的軟體產業(那其他的85%部份)的方法；但也請記得，仍然有1/3的朋友(全世界)不認為軟體工程是有助益性的，所以不需要在這個議題上打筆戰(究竟殘酷的"業界"是成者為王、敗者為寇的)。
寫了一堆，我只是要說明現代的軟體產業不是以程式設計為主流(當然程式設計是資訊科系學生必須具備的基本能力，此點不容質疑)，這個事實是存在的，僅供參考。
附帶說明，寫得時候自己有爽到，但各位朋友看看就好；若有不當的描述或得罪之處，還請千萬不要介意。
劉教授的意見中有兩點略表意見：
回覆刪除1. BPMN是OMG於2001與MDA同時發表的發展軟體「標準」，後者已在工業界如火如荼在發展討論，至於BPMN尚待極力提倡，也值得運用來描述需求。
2. 程式設計已漸漸不是軟體產業的主流，這是軟體工程的演進歷史，也就是說，軟體工程的演變歷史是不斷提升抽象度，例如OMG將MDA定為OMG發展軟體的標準，「寫模式」已逐漸代替寫程式，可惜台灣軟體業界似未體會這種趨勢。
我認同劉教授的說法。或許可以如此比對：學生所學的程式語言（劉教授所言的15%)正是我說的小短少少，而其他的部份(85%)就是大長多多吧！
回覆刪除雖然直覺劉教授的說法有些道理，但我實很抱歉也很汗顏，對劉教授的論述不甚了了，也許跟年紀或經驗有關，不知可否請劉教授摘要一下他的論述？
回覆刪除黃老板交辦的事，馬上處理。
回覆刪除基本上，寫的內容算不上什麼論述，主要是看到路過兄所寫"業界與學校最大的差別是..."而有的反應。我的看法摘述如下:
1.目前所累積的程式模組，大概已可滿足98%的一般應用，包括商務及嵌入式系統。(看看Software Reuse, Object Orient Technology, Open Source 等的成果就知道。)新手依其所學的程式設計而開發出來的類似功能模組，在品質及測試記錄方面是比不上那些已累積的，所以除了自己之外別人是不敢用的，更不要說要付錢了。
2.剩下來的2%，也不會輪到新手，而是由非常有經驗的幾個老手以非常高階(如用MDA、彼此使眼色就OK的agile方式)抽象的技巧來開發。如果他們懶得處理細節，也許才交待徒弟去寫。(但通常他們還是自己來，否則MDA就施展不開而agile也失效了。)
3.有這些累積的程式模組及仍在位子上繼續提供新模組的老鳥，是否就表示我們的軟體產業容不下新人呢？不是。因為這些程式模組只是程式，還稱不上"軟體"。怎樣才能把這些程式轉換成可以賺錢的軟體(使用者願意付錢)，也許在軟體工程相關議題中的85%都是有潛在機會的。
4.當今的軟體產業，程式設計工作是紅海，其他的工作(測試嗎？)反而可能是藍海。
希望黃老板滿意。
我們比軟體先進(如微軟、甲骨文)差很多，還不自知，真是可悲。我們曾開發出什麼軟體？
回覆刪除就算軟體設計只佔15%，測試、維護是把程式改到更好，改程式和寫程式哪有那麼不同，別脫離現實太遠。
軟工當然有其作用，但其目的是產出好的程式，不開發程式，軟工只是紙上談兵。MDA、BPMN都有某些用處，但曾有統計，使用者介面(包括Web介面)幾乎佔了大部份應用一半甚至更多的effort，user interface builder雖然有助於產出user interface的static layout，比較困難的dynamic interface behavior只能靠event-driven程式的細部控制，沒聽說有更好的辦法。不程式行嗎？
"目前所累積的程式模組，大概已可滿足98%的一般應用"，這樣說就好像說"藝術已存在幾千年，再也不會有了不起的藝術家了"，不值一駁。
劉教授的摘要敘述，老朽總算明白，有一句話說：軟體不會破損但會變壞(Software doesn't wear out, but it does deteriorate)，為何會變壞，依個人淺見，乃是因其功能不能完全滿足人們「貪得無厭」的需求之故，甚至跟不上硬體的日新月異，所以必須不斷有新的軟體出現，所以說98%的程式模組可以滿足一般應用，可能會逐漸被新的程式模組所替代，這些為滿足人們不斷增長的欲望，可能須用所謂高階的抽象技巧來開發，諸如MDA或agile methods，因為這類發展技巧不但effectiveness(agility)而且efficiency(MDA)，如果你參照Michael Guttman/John Parodi著的"Real-Life MDA"，可能會有感覺，這種抽象技巧已顯示有「徹底」(radical)改變軟體發展的可能，如果真的可能，誰說那2%不會影響已有的98%？
回覆刪除至於樓上匿名說：「我們比軟體先進差很多，還不自知，真是可悲。」我認為不是技術問題(因為技術易學)，而是管理與市場問題，微軟與甲骨文之所以成功不光靠他們的技術，而是他們有良好的管理以及開拓市場的能耐，這兩樣是台灣業界與學術界所欠缺，而且發展方向不太對，並非我們不自知，老實說我們不知如何改進也不去改進，才是「可悲」，不過，即使在美國，有如上述兩家公司那樣成功的軟體公司也不多見。
再精簡一下：
回覆刪除1.如果一個軟體專案費用是100元，那程式設計部份只能分攤到15元。業者為什麼不也考慮去賺那其他85元的部份？(如果瞭解軟體工程，可能就很自然。)
2.一般程式設計師所寫的程式，到最後變成.exe的可執行檔案，平均大概不到2%是自己的貢獻，因為software reuse的效益早已被運用幾十年。當然，如果連compiler都要自己來寫，我沒意見，只是業界的老板們不會同意。至於已經有多少可reuse的東西可用，那也要看功力；否則一定要去寫別人十年前就寫好，大家都普遍使用的程式碼，可能是個人興趣吧，老板知道馬上就跳起來的。
3.我是認為MDA及agile、TDD等這些東西是給有豐富經驗的軟體開發人員(是否是那2%？)使用的。對於一般程式設計師多少都會產生迷惑，因為他不太能體會"見山是山、見山不是山、見山又是山"的意義。
程式設計是軟體開發的技術核心工作之一，但在目前國際市場的強烈競爭之下，要靠寫程式賺錢而在軟體產業中冒出來，應該是很困難的。資工系的學生及業界朋友們除了要能有著優秀的程式設計能力之外，還有很廣闊的領域(在軟體工程中)是可以去涉獵而增加自己的競爭力的。
以現況來說，軟體發展仍然以程式設計為荷心之一，但是自從MDA出現後，這個荷心恐怕逐漸在鬆動，從Agile MDA的角度來看，程式與可執行的模式的作用一樣(Code and executable models are operationally the same)，因此MDA的信徒認為程式設計有一天會被模式設計所取代，不知大家信不信？以模式設計來建構系統，總比設計程式來得高抽象層次(high-level of abstraction)，此地引用Grady Booch的說法作為左證，他說：The history of software engineering is marked by ever-rising levels of abstraction. 因此不斷提升抽象層次乃是發展軟體方法必走的方向，不過Agile Methods仍然以程式設計為主，但是如果結合MDA成為所謂Agile MDA則同時顧慮到effectiveness(aglity)與efficiency(MDA)，可能會改變以程式設計為核心的軟體發展法。不過學生們仍然須先學好程式設計才能做好模式設計的工作。
回覆刪除再度路過, 發現可敬的軟工先進們依然在此奉獻, 我知道爭論軟工技術及程式技術是一個無盡的廻圈, 就程式設計而言, 以樓上匿名者曰: 「比較困難的dynamic interface behavior只能靠event-driven程式的細部控制，沒聽說有更好的辦法。不程式行嗎？」也許是對的, 但就軟工向度不就是試著去對這類問題找出解決之道嗎? MDA不是無法解決事件驅動所要付出的工作量問題, 而是需要有輔助工具的協助, 不是動態UI便是無解, 而是你是否可以將UI中的流程控制式樣化, 再萬變的UI都可以規納出定量的腳本式樣, 再將這些腳本式樣抽出實作成Application Framework, 如此便容易實施MDA了, 因為將複製且可重用的工作抽出製成 Application Framework, 則可以簡化動態實作的程式碼, 善用物件導向技術中的介面(interface)技術, 善用委派(delegate)技術則MDA不是不可能的未來, 技術人的堅持與認知是有必要靜心思考的, 試著用物件導向程式技術讓重用增加(並不是用include方式來使用重用, 而是使用 application framework方式重用), 則系統模型(model)的複製度將會減少, 如此不就可以接近MDA了嗎? 僅此提供本人看法, 望各位先進指教, 並向 薛教授致歉, 一年前的留言今天才發現, 更向 黃教授致敬, 謝謝 您至今仍在此為台灣軟體工程奉獻。
回覆刪除