課程改進
今年在輔大招開的TSCE11，其中在Panel Discusion中(主題：軟體核心能力)，我提議軟工教育訓練由OO modeling概念開始，而程式則依據models來撰寫，這種提議可能須修改教學程序，不過我認為，「軟體核心能力」的目的乃是要建立優良的軟體系統，而models比複雜的程式容易描述系統，也比較容易保養系統，因為其抽象層次較高，也符合程式語言以及軟體發展方法的演變之故。我提出這種意見，希望對軟體工程教育有興趣的人士能夠討論，提供意見。
CMMI是什麼?
CMMI(Capability Maturity Model Integration) 將軟體開發流程視為一種工程 ( 製造 ) 流程，利用控制、量測、改善 (control, measure, and improve) 等循序漸進的方法，達到軟體流程改善的一個框架。 CMMI 是在美國國防部 DoD 以及國防工業協會 (NDIA) 的支持下， CMU 的軟體工程學院 (Software Engineering Institute, SEI) 發展出來的模型。 CMMI 中許多的概念與原理來自於創立 SEI 軟體流程計畫 (software process program) ，並曾任職於 IBM 、領導大型系統軟體開發的 Watts Humphrey 。根據 IBM 與 SEI 的經驗， Humphrey 將廣泛運用在製造流程中的統計流程控管 (Statistical process control, SPC) 的概念，加以修正、擴充後運用於軟體流程管理中。 在一方面，定義軟體開發流程中的各種活動與其彼此間的關係，是將軟體開發流程視為一種製造流程，並實施量化控制的前提之一。在另一方面，由於這些活動相當繁多、複雜且彼此牽動，故唯有在軟體開發活動結構定義清楚之後，方能找出可量測事物，並根據其關連性推論量測值的意義。 CMMI 將軟體開發相關活動的實務作法分為 25 個流程領域 (process area, PA) ，定義其需管理的項目，含一般目標、特定目標、具體作法等，並找出其彼此間的關連性。 依性質來分，這些 PA 分屬於流程管理、專案管理、工程、與支援等四大類 流程管理 ： CMMI 的目的是流程改善，因此流程的定義、維護、修正等均為重要活動。 專案管理 ：因為軟體開發、維護均以專案為單位，以便在專案進行前進行人力、資源、時間、經費計算以及專案進行中管控，如需求變更、進度監控等。 工程 ：軟體開發實質上涵蓋許多軟體工程的原理與具體作法，如需求發展、分析、應用設計、系統設計、實作、測試、部署、維護等相關活動，這些活動需要加以管理。 支援 ：支持前三類活動進行之環境與工具之支援活動等，例如提供產出物與組態管控、議題追蹤等活動。 CMMI 有連續式 (continuous) 與階段 (staged) 式兩種表示法。採用連續表示法
同意~ 先從抽象層及架構教起，再去教導程式撰寫的細節
回覆刪除黃教授的觀點，我們（北科大）在OOAD（碩一下）一門課中實施。多年來陳偉凱教授與我以約略相同的模式進行這門課程。課程含一個專題，由學生大致依循unified process從提出問題、分析problem context、撰寫需求（use cases and nonfunctional requirements）、conceptual modeling and design modeling（使用UML）、test plans等、寫程式、demo等，並以2~3個iteration完成。
回覆刪除由於時間的關係，OOAD並未涵蓋MDA相關工具與議題。因此，學生仍需『手動』將OO model翻譯成C++ 或Java程式。說起來仍脫離不了coding。
OOAD的課程，是在學生修完pattern oriented software design（碩一上，必修）之後進行。這門課涵蓋GoF 23 個 patterns中15~20個patterns，學生需要做完一個規模大約2000~3000行的程式。如果以pattern數來算，大約涵蓋4~6個patterns（每年因作業題目有不同）。
關於這兩門課程最近開課的相關資訊，請參考陳偉凱教授網頁http://www.cc.ntut.edu.tw/~wkchen/courses/ooad992/index.htm與
http://www.cc.ntut.edu.tw/~wkchen/courses/gposd991/index.htm
我的看法與郭譽伸教授接近，modeling與coding並非競爭關係，而是合作關係。以前述二門課程的設計而言，modeling始於POSD而應用於OOAD。
另外，如MDA方式產生程式，勢必在OO Models上需要更為嚴謹，且需有適當地工具可用。
雖與OO Modeling無直接關係，近來我曾多次與陳教授討論改以Scrum作為流程框架，但這個規劃需進一步探討。
「課程改進」我認為是一項嚴肅的議題，我很敬佩北科大陳偉凱教授早就對這個議題所做的努力，我提出這個議題並非否定學生學習coding的重要，而基本概念是讓學生學習軟體發展技術由modeling入門，也許這樣學生才不會只成為「coding匠」，也不至於如Q43諺語所說的那麼「淒慘」，而提升分析、設計、‧‧‧的能力。
回覆刪除至於MDA，如果觀察Grady Booch等人提出的MDA Manifesto(見The MDA Journal一書)包括Direct Representation, Automation, Open Standards，其中Automation一項直接與Agility相關，所謂Agile MDA，Agile MDA的基本觀念是code與executable models相等，我不擬在此多討論MDA，只不過訓練學生發展軟體似應由modeling入門。
如果這個議題值得討論，我建議軟工學會提供討論的機會。
北科大的陳偉凱及鄭有進(漏提，抱歉)教授對OOAD課程的努力似與本人想法有出入，而且北科大的課是針對碩一學生所開授，我的提議是針對大一的計摡或大二軟工的入門課程而言，這個提議可能會有點爭議，因為可能有「顛覆」傳統的嫌疑，所以才要討論。
回覆刪除我想補充一些我個人的想法。首先，就我個人觀察，目前就業市場似乎仍然需要大量的programmer寫code，而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』，而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗，更遑論良好的架構了。我覺得這樣的code，即使可以動，也不能算是「好code」，當code需要維護時一定會造成很大的困擾。因此，我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗，以指導學生寫「漂亮的code」，將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立，如果使用MDA以及code generation的機制，問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海，應該更能培養Modeling能力，比較不會被code牽著走。舉例說，一般大學部OOP的課多著重於程式語言的文法與演算，反而少了物件模型、互動、UML，更遑論設計樣式，在這種情形下，就算會寫code，也不會很OO，而這些東西如果等到高年級(甚至研究所)的OOAD再學，似乎又嫌晚了。暑假期間，個人參與軟體工程課程模組教材編撰，則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介，希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程，增加MDA或其他modeling的教學，我覺得也是可行的。但是，我並沒有很明確的idea，不知道黃教授有沒有什麼構想？
我想補充一些我個人的想法。首先，就我個人觀察，目前就業市場似乎仍然需要大量的programmer寫code，而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』，而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗，更遑論良好的架構了。我覺得這樣的code，即使可以動，也不能算是「好code」，當code需要維護時一定會造成很大的困擾。因此，我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗，以指導學生寫「漂亮的code」，將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立，如果使用MDA以及code generation的機制，問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海，應該更能培養Modeling能力，比較不會被code牽著走。舉例說，一般大學部OOP的課多著重於程式語言的文法與演算，反而少了物件模型、互動、UML，更遑論設計樣式，在這種情形下，就算會寫code，也不會很OO，而這些東西如果等到高年級(甚至研究所)的OOAD再學，似乎又嫌晚了。暑假期間，個人參與軟體工程課程模組教材編撰，則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介，希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程，增加MDA或其他modeling的教學，我覺得也是可行的。但是，我並沒有很明確的idea，不知道黃教授有沒有什麼構想？
我想補充一些我個人的想法。首先，就我個人觀察，目前就業市場似乎仍然需要大量的programmer寫code，而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』，而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗，更遑論良好的架構了。我覺得這樣的code，即使可以動，也不能算是「好code」，當code需要維護時一定會造成很大的困擾。因此，我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗，以指導學生寫「漂亮的code」，將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立，如果使用MDA以及code generation的機制，問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海，應該更能培養Modeling能力，比較不會被code牽著走。舉例說，一般大學部OOP的課多著重於程式語言的文法與演算，反而少了物件模型、互動、UML，更遑論設計樣式，在這種情形下，就算會寫code，也不會很OO，而這些東西如果等到高年級(甚至研究所)的OOAD再學，似乎又嫌晚了。暑假期間，個人參與軟體工程課程模組教材編撰，則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介，希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程，增加MDA或其他modeling的教學，我覺得也是可行的。但是，我並沒有很明確的idea，不知道黃教授有沒有什麼構想？
我想補充一些我個人的想法。首先，就我個人觀察，目前就業市場似乎仍然需要大量的programmer寫code，而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』，而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗，更遑論良好的架構了。我覺得這樣的code，即使可以動，也不能算是「好code」，當code需要維護時一定會造成很大的困擾。因此，我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗，以指導學生寫「漂亮的code」，將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立，如果使用MDA以及code generation的機制，問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海，應該更能培養Modeling能力，比較不會被code牽著走。舉例說，一般大學部OOP的課多著重於程式語言的文法與演算，反而少了物件模型、互動、UML，更遑論設計樣式，在這種情形下，就算會寫code，也不會很OO，而這些東西如果等到高年級(甚至研究所)的OOAD再學，似乎又嫌晚了。暑假期間，個人參與軟體工程課程模組教材編撰，則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介，希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程，增加MDA或其他modeling的教學，我覺得也是可行的。但是，我並沒有很明確的idea，不知道黃教授有沒有什麼構想？
由於陳偉凱教授回應本文時遭遇一些困難，故由我代post：
回覆刪除===
我想補充一些我個人的想法。首先，就我個人觀察，目前就業市場似乎仍然需要大量的programmer寫code，而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』，而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗，更遑論良好的架構了。我覺得這樣的code，即使可以動，也不能算是「好code」，當code需要維護時一定會造成很大的困擾。因此，我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗，以指導學生寫「漂亮的code」，將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立，如果使用MDA以及code generation的機制，問題自然就消失了。
我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海，應該更能培養Modeling能力，比較不會被code牽著走。舉例說，一般大學部OOP的課多著重於程式語言的文法與演算，反而少了物件模型、互動、UML，更遑論設計樣式，在這種情形下，就算會寫code，也不會很OO，而這些東西如果等到高年級(甚至研究所)的OOAD再學，似乎又嫌晚了。暑假期間，個人參與軟體工程課程模組教材編撰，則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介，希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程，增加MDA或其他modeling的教學，我覺得也是可行的。但是，我並沒有很明確的idea，不知道黃教授有沒有什麼構想？
由 陳偉凱 於 2011年7月25日下午5:08 張貼在 輕鬆談軟工
===
我很感謝北科大的鄭有進與陳偉凱兩位教授對於這個議題的興趣與意見，同時也敬佩他們訓練學生撰寫好程式的努力，我未曾教過學生如何寫程式，也許不太了解教學生寫程式的困難，但我並非忽視這件事，我只不過提議教學生寫程式之前教一些modeling的觀念與技術，也就是：modeling → programming的程序，採用這種教學程序，將來學生寫的程式可能比較容易保養，建構容易保養的軟體是很重要的事，例如早讓學生懂得應用一些design principles或design patterns，這樣可能可以讓發展的軟體易於修改與擴張，軟體也比較有「彈性」，我的想法在於此，至於是否使用MDA或code generator，應該是另一議題。
回覆刪除我舉兩種範例參考。1989年Kent Beck與Ward Cunningham在OOPSLA'89介紹CRC cards時，主要目的是要提供一種工具以教授學員OO想法，這些學員也許無OO概念，但可能撰寫程式經驗豐富，沒想到CRC cards後來移出教室變成分析與設計的「天才工具」(Nancy M. Wilinson)(註：雖然這項工具已有二十幾歲，但仍然「老當益壯」，據我所知台灣很少人重視它，也很少用它)，我想這是modeling → (OO)programming的範例。另外一則例子是Georgia Institute Technology的K.A.Gray, et al.等教授發表一篇他們的教學經驗："Extending CRC Cards into a Complete Design Process"，其基本觀念是：Scenarios → CRC Cards → Code，前半段是modeling，或許可以說由modeling入門再到coding，至於是否必須使用CRC cards技術，則另當別論。
如果說大一或大二的課程增加MDA或許不必，雖然OMG說MDA是他們的「標準」軟體發展方法，而且前途「光明」，但是引進入大一課程，我想大可不必，因為裏面有一些標準與技術並非大一甚或大二學生容易了解。至於教modeling方式很多，也許早一點教學生UML，以及如何使用它以表達OO觀念與設計，可能可以考慮。
這個議題蒙鄭、陳兩位教授以及TCSE Panelists討論過很多，我想已很清楚，我只不過主張提升教學「抽象層次」而已，至於是否得當，見仁見智，也許其他人士另有看法，值得討論。
我想再補充一下。簡而言之，這兩年我在大二OOP一門課中，也嘗試以Class-Responsibility-Collaboration（CRC）法，讓學生做一些簡單的modeling。相關的理念發表在TCSE 2010（中央大學），我將該paper『融入軟體工程實務於物件導向程式設計課程）』的introduction摘錄於後，全文pdf可自我的網頁下載（http://www.cc.ntut.edu.tw/~yccheng/papers/tcse2010_OOP.pdf）。
回覆刪除＝＝
大二物件導向程式設計(Object-oriented Programming)課程，是資工系學生第一次接觸到物件導向觀念與程式語言語法的機會。學生在這門課中需學會物件導向的重要元素如封裝(encapsulation)、資訊隱藏(information hiding)、繼承(inheritance)、多型(polymorphism)、泛型(genericity)等技術；這些技術普遍被認為適用於開發具規模的中大型軟體，透過妥善的物件導向設計，程式可被賦予適當的耦合度(coupling)、內聚度(cohesion)、可修改性(modifiability)、 與可維護性(maintainability)。雖然這些物件導向技術構為軟體的構成提供一個良好的基礎，但要開發一個好的軟體，則需要更多的軟體工程技術。在北科大資工系大二物件導向程式設計課程中，我們嘗試在固有的物件導向相關議題之外加入工作規劃(work planning)[4]、單元測試(unit testing)[5]、重構(refactoring)[6]、例外處理(exception handling)[7]等當前普遍受軟體工程界重視的幾種軟體工程實務(software engineering practices)。我們以George Polya著稱於世的How To Solve It解題方法(problem solving)中所揭櫫的的四個步驟，即瞭解問題(understand the problem)、規劃解法(devise a plan)、依規劃解題 (carry out the plan)與回顧(look back)等四個步驟[1]，作為導入軟體工程實務的框架。在瞭解問題之後，以物件-責任-合作(class-responsibility-collaboration, 簡寫為CRC)的物件導向設計法[2]列出物件及其方法，並將實做每個方法的工作當作一個待辦工作；這些待辦工作被列管於一個簡單的工作庫存表(task backlog)。此外，工作庫存表亦包括方法的程式碼與測試程式的撰寫，以及其他相關工作。在單元測試的撰寫上，我們採用xUnit單元測試框架。在此作法下，每一個程式撰寫(coding)的工作的完成(done)變得極為清晰；亦即所有單元測試都必須獲得通過，才認定該工作依規劃執行結束。最後，在每一個物件的實做告一段落時，以檢視程式的設計進行回顧，指出問題點，作為下一個解題循環的工作規劃參考，如有找出明確的工作則將之列入工作庫存。整個程式設計的工作在工作庫存中的工作完全去化之後宣告完成。
在一個學期中，我們至少在課堂上以How to solve it的框架完成三到四個完整的程式設計範例，並讓學生以同樣的模式完成八到十個程式作業。在這個過程結束後，學生不僅寫完物件程式碼，亦進一步獲得單元測試碼、工作規劃、工作庫存去化紀錄等產出物。在完成本課程後，學生將能具備足夠的物件導向程式設計基礎，修習大二下的物件導向程式設計實習，目標是在應用框架（application framework）下撰寫一個規模約為2000~3000行的2D的互動遊戲[3]。
＝＝
過去兩年的OOP的實施上，我只花了一堂課談CRC，學生應當只知道皮毛，遠遠不足。事實上，我非常認同黃教授modeling first 的見解，因此，下學期我打算以2~3堂課談CRC，並讓學生有機會在課堂/作業中練習。不知道軟工教育界的先進們，有無實施CRC的經驗可供借鏡？
鄭教授既然談到CRC cards用於北科大的教學，我想針對CRC cards簡單說幾句話，我希望有機會寫一篇文章比較詳細介這種有趣，但在國內不太引起注意的工具，或稱之為方法。
回覆刪除話說，有人問發明Responsibility-Driven Design(RDD)的Rebecca Wirfs-Brock：CRC cards是否有用，為甚麼UML工具並不將其納入，她的回答是：CRC cards大部分是用來做訓練，有時也用來做分析與設計，至於UML工具不將其納入，是因UML工具並不支援模式原素在各種抽象層次(level of abstraction)的behavior 與characteristics的描述，所謂抽象層次可以很多，不過依照Martin Fowler的說法，你的設計抽象層次包括：conceptual view，specification view，以及implementation view，而CRC card的層次對conceptual view 的描述最佳，這個view主要是描述所謂key abstractions(構成問題範疇部分字彙的類別或物件)，事實上，其貌不揚的CRC cards，其功能恐不止於此，可以用來發展軟體，其程序大致如下：(Use Case Model + UI Prototype) → CRC Model → Class Model (以上是Scott W. Ambler的說法，我加上 "→ Code")。我在TCSE2010投了一篇小文章，名為"From CRC Cards to MDA: A Software Development Process"，主要精神是要顯示，Informal的CRC cards可以作為Formal Methodology的input，似與Wirfs-Brock說法有些吻合。我覺得鄭教授團隊使用CRC cards大慨止於訓練之用，並未將其導入implementation(coding)的層次。
抱歉打擾，文章回覆的行距實在太窄了，很難閱讀，不知道能不能調整一下? 設定 line-height: 1.4em; 就好的多。
回覆刪除