軟體工程諺語

2015年11月12日 星期四

使用CRC cards的『責任驅動設計』方法

本文簡單介紹一般人比較不熟習的所謂『責任驅動設計』(Responsibility-Driven Design 簡稱 RDD),這種設計方法是根據系統的責任,來設計類別的行為與方法或功能,因此RDD可運用在軟體發展上。

1989年Rebecca Wirfs-Brock與Brain Wilkerson在OOPSLA'89發表『責任驅動設計』的軟體設計方法,後來她們與Lauren Wiener共同寫了一本叫『Designing Object-Oriented Software』(PTR Prentice Hall 1990)的書用以實作RDD,2003年Wirfs-Brock與Alan McKean合著『Object Design - Roles, Responsibilities, and Collaborations』(Addison-Wesley)一書更深入介紹RDD,讀者如沒有這兩本書而有興趣的話可從網路叫出RDD相關文章參考。

本文介紹這種軟體設計方法,乃是因為在OOSE或OOAD的書籍很少提到,據我所知上課時老師也很少介紹,這種方法的設計觀念是認為,軟體物件以及大型原件的設計是基於『責任』(responsibilities)、『角色』(roles)、以及『合作』(collaborations),這種觀念,有部份異於諸如UP之類的「傳統」軟體發展想法,但是RDD是一種非正規(informal)的設計概念,其後半部如與傳統的設計與實作連結,這個方法應該值得關注,不過我在此地必須說明,RDD並非完全脫離一般OOAD甚至OOSE的觀念,只不過它對於物件的定義有別於UML的型態 ,物件並非單純資料與演繹的結合,而認為物件是結合其『角色』與『責任』的東西,當要執行某些責任時需與其他物件合作才能完成。因此,RDD的重點在於,發展物件之間的合作與溝通模式,以及物件責任與動態,而不在於物件的內部狀態(internal state)與結構,CRC cards的內涵剛好符合這種需要。如果我們定義軟體應用系統是由一群物件間的相互作用(interactions)而成,則這種相互作用就是得自於client/server模式。

Client/Server模式

物件的作業元(operations)在RDD中視為『服務』,這種服務可以提供需要的其他物件,因此只要服務存在,我們說物件就有責任提供給需要服務者,所謂責任依照Wirfs-Brock et al.的定義包括下列主要項目:
  • 物件所保養的知識(knowledge),以及
  • 一個物件能夠履行的行為(actions)。
所謂知識(資料)形成一群責任提供給需要這些資料的物件,這些物件如需要可以改變這些資料,至於履行行為就是提供給需要服務的物件的責任,由於物件時常都具備給要求服務的其他物件,這種關係就是所謂client/server的關係。

因此,RDD重點在於物件的何種責任需要完成,有些責任除物件本身可以自行完成外,須要合作者(collaborators)來協助完成,合作可以依照client/server的相互作用(interactions)完成,因此client/server模式影響RDD。所謂client/server模式(或說機制)是client發出要求server提供資訊或履行一些作業,Server就適當地提供資訊或依照要求完成履行作業,但client並不知道server如何完成其要求,這就是所謂『資訊隱藏』(information hiding)。Client與server交換資訊是根據兩者間的合約(contract)進行,這種合約集中在:(1) 物件負責何種行為(actions)?(2)物件提供何種資訊?這兩種的問題答案相當我們在CRC cards一文所提的『責任』(responsibilities): doing與knowing責任,下圖表示這種client與server的關聯:

                        
     此地我們不擬詳細說明RDD,只是提供「另類」的軟體發展方法,讀者或可參考「現代軟體工程─物件導向軟體發展策略」書籍。


2015年3月15日 星期日

現今軟體發展流程趨向

     降低發展軟體系統的工作量、減少發展所需的時間是現今軟體發展流程的主要趨勢,因此由郭忠義、薛念林、馬尚彬與黃為德共同發展一本書名為『現代軟體工程─物件導向軟體發展策略』,這本書有別於傳統的軟體工程書籍,引進現代的先進軟體工程技術,並具有下列特色:
  • 全面理解基本軟體工程與物件導向的觀念。
  • 提供『案例研究』(case study)以說明物件導向軟體發展流程。
  • 介紹系統化軟體測試與方法,導引出各種敏捷軟體發展方法,如Scrum方法。
  • 根據軟體設計原理與發展樣式,協助發展者發展可保養的軟體系統,提高設計品質。
  • 以敏捷觀念介紹一些有用的建模原理與應用,例如責任驅動設計(Responsibility-Driven Design,RDD)、模型驅動架構(Model Driven Architecture,MDD)。
  • 專章介紹軟體度量預測與使用CRR卡模型,兼顧傳統與實用性。
依照上述特色,本書的目的主要用來說明物件導向軟體工程的特徵,同時提供簡易而實用的物件導向的特有功能與技術,由於軟體發展不能只抱持單一種類的方法或流程,因此本書介紹的軟體發展流程是基本流程的框架(framework),發展者可將這種框架『客製化』以適合其需求,讀者學習完本書後,就有能力應用物件導向技術從事其發展軟體的工作。
     本書主要提供大專院校研究生或大四學生研讀,同時也提供工業界人士,需要以傳統或敏捷方法發展可保養的軟體系統時參考,研讀本書,必須具有軟體工程,以及物件導向程式語言的知識,如Java或C++語言。作者深切期盼任何對本書的評論,以便將來修正。
     本部落格僅提供對於近代軟體發展策略有興趣的人士參考,而無意做任何商傳,謹特別聲明。     

2013年11月10日 星期日

『簡單』- 讓混亂發展成規則 (Order from Chaos)

我在治療期間,抽空讀了一本肯恩‧西格爾(Ken Segall)著作,書名為『簡單』的書 (應該稱為『極致簡單』- Insanely Simple),西格爾主要在闡述史蒂夫‧賈伯斯(Steve Jobs)以『簡單』至上的觀念引導蘋果的成功故事,其實,賈伯斯曾經被蘋果「放逐」11年,於1997年再度回到蘋果擔任執行長,賈伯斯不在期間,蘋果每下愈況,一直到賈伯斯回來時,蘋果已經岌岌可危,幾近破產邊緣,賈伯斯以『簡單』至上的觀念重振蘋果。『簡單』至上的概念很難說得清楚,它可能是一種選擇,一種氛圍或一種指引,視你的需要而定,簡言之,『簡單』就是『打破複雜,創造絕對優勢』,你/妳如果用過蘋果的產品如iPad,可能就會有所感受,例如更新作業系統(iOS)就很簡單,總之,蘋果的基本理念是:『硬體簡單化,而背後的軟體卻豐富化』。賈伯斯如何以『簡單』至上的觀念讓蘋果起死回生,有興趣的朋友可看看西格爾的書。

發展軟體的需求,開始時都顯得比較混亂,不過『簡單』可以讓混亂發展成規則,我想,『簡單』這種觀念是否可以運用在軟體發展上,謹提供個人的看法。眾所熟悉的"KISS"原則 (Keep It Simple, Stupide) ,就是勸導人們撰寫程式與設計軟體時,要保持簡單清楚但不要太複雜,發展C語言的P.J. Plauger與B.W. Kernighan在他們的"The Elements of Programming Style"書裡,提供數十條寫程式必須遵循的『簡單』原則,例如其中有一則原則是說"Keep it simple to make it faster",所以程式如寫得太複雜,則可能會降低效率。此外,『簡單』也可以說是敏捷方法的原則之一,2001年Agile Alliance所發表的敏捷宣言(manifesto),是『簡單』的價值闡述,『簡單』的優點是你不必花費太多的時間去實作困難的解決方案(除非簡單的方案無法解決你的問題),總之,簡單的解決方案容易保養也容易改進。

談到『簡單』,我想到去年12/8我在本部落格po了一篇題為『CRC cards - 非正規物件導向發展技術』的文章(惜因少有反應,所以最近我把它列入草稿),CRC cards雖然屬非正規方法,但可做為軟體分析、設計以及敏捷思考的簡單工具,而且也可做為正規方法的輸入,如UP、Booch方法或OMT等。Craig Larman曾以隱喻(metaphor)的方式解釋何謂物件,個人認為,CRC cards可能是詮釋物件及其功能最簡單的圖示,也是教授學生物件導向觀念的入門利器,只可惜在國內似並未受到重視。下圖表示如何利用CRC cards發展軟體的簡單流程,這個流程雖然不能用來發展大型複雜的軟體,但或可做為發展軟體系統前端或軟體雛型之用,這個流程可能是最簡單的軟體發展流程,有機會再來討論。


這篇文章只不過是以表面方式闡述『簡單』這種觀念,而不在描述蘋果的種種,特此註明。

2012年12月8日 星期六

CRC cards - 非正規物件導向發展技術

最近看到Kent Beck與Martin Fowler講的一句『諺語』,說:"Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文,提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』,溝通在軟體發展的過程中十分重要,尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto),此地不宜對宣言多做闡述),問題是你要使用何種工具或方法來溝通?我想除use cases外,CRC cards可能是最佳工具之一,它是隨時隨地可得的低技術工具,易學易用。

軟體開發與維護時,工作夥伴的合作十分重要,換言之,團隊合作是發展工作成敗的關鍵,夥伴合作必須有好的工具或技術協助,CRC cards可能是適當的工具之一,據我所知,在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997),而這種技術雖然簡單,但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別,因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術,而且也希望各界人士能予指正。

CRC cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html),其出現時期與WWW相同,至今約有20幾年的歷史,這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作,後來的演變卻超乎在教室內的需要,而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach),雖然屬非正規方法,但CRC cards可做為正規方法的輸入或前端作業,如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOSE、Shlaer/Mellor方法、Unified Process以及Rebecca Wirfs-Brock的RDD(Responsibility-Driven Design)等等,因此CRC cards適用於『任何』軟體發展方法上。

使用CRC cards技術時對於「物件」一詞的想法應有所改變,Craig Larman在"Applying UML and Patterns"一書裡,以隱喻(metaphor)的方式說:『軟體物件有如人們具有責任(responsibilities),有些責任必需與他人合作(collaborte)才能完成工作』,CRC cards就是這種隱喻的圖形表示,其與UML表示物件的方式不同,UML思考物件是"data+algorithms"(下圖右),而CRC cards的物件是"roles+responsibilities"(下圖左),其中roles是物件所扮演的角色,同一個物件可以扮演各種不同的角色,責任也就依所扮演的角色而異。

左圖是Beck/Cunningham的原圖,但非標準圖形,CRC cards並無標準型態,使用者可以依需要客製化,但卡片至少需具載類別名稱、類別責任與合作者三項,一般使用所謂index card,其大小可以是3in x5in或4in x6in,卡片左上角書寫的類別名稱,也可以是原件、子系統、角色、或其它物件,卡片後面可以簡單說明類別的特性或屬性。卡片中「責任」是以高層次(不涉及實作)的方式說明類別的目的,責任包含3種型態:(1) 物件執行的動作,即doing責任;(2) 物件保養的認知或資訊,即knowing責任;(3) 物件主要的決定以影響其它物件,即decision making責任。

那麼,UML工具為何不支持CRC cards,我們要從Martin Fowler所提出的3種模式層次來看,這3種抽象層次包括(可能有更多層次,但3種層次已夠說明),即:
  • 觀念層次(conceptual level)或範疇層次(domain level) ─ 說明一群責任;
  • 規格層次(specification level) ─ 說明一群涵蓋的方法(methods);
  • 實作層次(implementation level) ─ 說明程式與資料。
但大部分的UML工具重點放在從規格轉成實作層次,而有點忽略觀念層次的觀點價值,如果UML工具能夠涵蓋處理觀念層次,我想喜愛使用工具發展軟體的人士應會樂觀其成。由於CRC cards的基本優點在於描述觀念層次,這就是我們說CRC cards技術可以連接各種正規方法做為分析甚至設計工具的理由。

至於物件可扮演何種角色,Wirfs-Brock用角色型別 ( role stereotypes)來定義6種物件可能扮演的角色,每一種角色有不同的責任,這些角色都可以使用CRC cards來描述,包括:
  • 資訊保持者(information holder) ─ 知道或提供資訊,也就是說保持事實,例如郵件地址,帳號,交易記錄等;
  • 結構者(structurer) ─ 保養物件間的關聯以及與這些關聯相關的資訊,例如檔案系統的folder;
  • 服務提供者(service provider) ─ 執行工作,一般來說提供運算服務,例如信用授權;
  • 協調者(coordinator) ─ 委託工作,例如交通號誌燈,文字處理器的字體管理;
  • 管制者(controller) ─ 決定並指揮它物的行動,例如交通指揮員;
  • 介面者(interfacer) ─ 支持系統內外各部門的間通訊,例如ATM的金錢出口。
確定物件屬於何種角色有助於擬定物件的責任以及要完成某責任的合作物件,每一種物件都有可能(但不一定)扮演兩種以上的角色,例如EmailAddress(Wirffs-Brock 2003)將扮演「資訊保持者」與「服務提供者」,因此EmailAddress物件知道送與受者以及SMTP資訊地址,此外它可輸送訊息,為要完成這些責任,他必須與Mailer與UserProfile合作,否則無法完成EmailAddress的運作,上述責任與合作者可以以下列CRC card表示 (使用CRC工具繪製):

物件導向軟體發展法的首要工作,就是先定義與問題範疇相關的物件, CRC cards是提供發展者集體透過腦力擊盪設計軟體系統的工具,這種集體工作稱為CRC session,理想參與的成員大約5-6人,包括主事者(facilitator),這種人必須熟練物件導向技術,此外須有範疇專家(domain expert)以及發展者。這種集體腦力擊盪的工作方式,其優點是,使用CRC cards作業可以沒有風險(nonthreatening)而且非正規(informal),而且允許參與的任何人提供意見,這也是CRC cards的強項。(註:上圖STMP是SMTP之誤)

為何要使用CRC cards來分析與設計?可以綜合下列幾點:
  • CRC cards便宜、具彈性而且垂手可得,最重要的是具可攜性(portable),也就是說,不必依 賴電腦而且在任何地方皆可使用,如果修改或不需要時可隨時撕毀;
  • 可以讓參與的團隊第一時間就可討論系統如何運作而不必依賴電腦工具;
  • 可用於教授物件導向發展方法 (Beck/Cunningham發明CRC cards的原意);
  • 可做為許多正規方法的前端,如Booch,Wirfs-Brock ,Jacobson等人的方法。
至於本身可用來當做發展軟體的方法(methodology),這一點可參考下面圖示,以說明如何使用下圖所示的發展流程來發展軟體:           (上圖發展流程請參考2011年TCSE研討會論文集Session 1C: Software Processs內本人 一  篇小文章:"From CRC Cards to MDA: A Software Development Process")

CRC cards的非正規性與彈性,以及與其相關的發展流程是其強項之一,這種流程易予客製化,當然,因其非正規化,所以對物件導向的初學者會有某種程度的困擾,例如不同的專案可能會有不同但適合該專案的句法 (syntax),不過初期能擬定指引,而該指引或許可成為適合團隊使用的標準,一旦使用者熟習CRC cards技術,則CRC cards將可顯示發展者的觀念,以及幫助其對於需求的了解,從這種角度來看,CRC cards技術的彈性與易予客製化可以說是其優點,而且CRC cards技術可以讓你/妳在發展初期容易發揮你/妳的智慧,或無庸置疑。

這篇報告只約略介紹CRC cards及其技術,其主要用在『責任導向設計』方法 (RDD)的部分,希望有機會再來『輕鬆談』。

這篇報告原在2012/12/8發表,除匿名指正筆誤與劉教授的意見外,因沒有其他反應意見,所以暫時「打入」草稿,現蒙劉立頌教授的鼓勵,我略作修正重新發表,提供修習物件導向軟體工程的學生參考,謹向劉教授致萬分謝意。

2012年9月24日 星期一

學習軟體工程中的學習障礙(五)

此外在實際應用此方法於資工系大三學生的教學過程中也發現,有些教學的內容可由學生的討論與推理中發展出來。如圖三的內容,由第二節的例子討論過程中可由學生自行發展出來。而教師可以接續學生的討論進行整理以及補充細節,接著再介紹相關技術,教學的過程便會相對較為平順。此外由於是由學生自行討論而來,學生會對自己發展出來的資料更加有真實性。同時也更容易將自我經驗連接到課程的教學資料。


圖三:介紹專案管理的程序的投影片

使用以上的方式進行教學,師生之間可以有更多的互動。且學生較容易理解所學內容的目標為何,可以應用在什麼地方。另外的好處是課程進行的節奏明快,學生在學習後可以馬上有一個小產品;而在一陣子的累積之後可以產生較大的產品。而有產品可以讓上課的氣氛較為輕鬆,學生學習的士氣也可以較只有口頭講授的方式更加高昂。
然而此種教學方式須要教師額外的時間準備教材,以及進行良好的授課時間估算。同時教師須引導學生討論,因此對教師的溝通能力也有一定程度的要求。

四、總結
本論文說明三種主要阻礙學生學習軟體工程的學習障礙,並提出相關的解決方案。我們也提出了一個類比於軟體開發流程中的Agile方法的教學方法。提出相關的程序,並說明此種教學方式的優缺點。
在教學的準備上此三種障礙的提出,有助於教師在準備教材時的評估。本文所提之方法也可作為教師在考慮提昇學生學習流暢度的準則。
本論文並非提出一個全新的教學方式,或是意圖推翻傳統課堂講授方式;所提的要點及教學流程係作為原本教學內容的加強。相信在教學的過程中若能注意到這些要點,將有助於學生的收獲與專業的應用能力。




參考文獻
[1]  陳昱志、吳啟仲、劉立頌, “軟體工程觀念於資料結構課程之範例,” 第二十一屆物件導向技術及應用暨第六屆台灣軟體工程研討會論文集。桃園,2010722~23.
[2]  鄭有進、陳偉凱,融入軟體工程實務於物件導向程式設計課程第二十一屆物件導向技術及應用暨第六屆台灣軟體工程研討會論文集。桃園,2010722~23.
[3]  Mayr, H., Teaching software engineering by means of a “virtual enterprise”, Proc. 10th Conference on Software Engineering Education & Training, 1997 , pp. 176 – 184.
[4]  忠信, “虛擬軟體工廠–讓實習變成真實工作第二十一屆物件導向技術及應用暨第六屆台灣軟體工程研討會論文集。桃園,2010722~23.
[5]  鄭永斌, “一種導引與限定式的軟體工程課程專題設計─四年經驗報告第二十一屆物件導向技術及應用暨第六屆台灣軟體工程研討會論文集。桃園,2010722~23.
[6]  L. R. Hubbard, Basic Study Manual, Bridge Publication, 2004.

[7] B. Buckler, “A learning process model to achieve continuous improvement and innovation,” The Learning Organization, vol. 3, no. 3, 1996, pp. 31-39.

2012年9月13日 星期四

學習軟體工程中的學習障礙(四)

在實際的教學上發現利用這種討論式的例子來進行教學,比較貼近學生的真實性。且能由此引申到教師欲進行的內容。在內容中沒有太多專有詞彙,但可以將原本教師講授的重點說明清楚。
承續此思路我們也可將這種方法用於軟體開發流程的介紹當中。例如介紹軟體開發流程的需求分析,設計,實現,測試,撰寫文件的過程也可以由學生討論程式設計的過程中衍生而出。如圖二為由程式設計介紹軟體開發步驟的過渡投影片。教師可在學生討論程式設計的過程中,引進軟體開發的觀念,如可以詢問學生:若這個過程不是一個人完成的話,那須要注意那些事?
  
圖二:介紹軟體開發程序的投影片

不論學生背景知識為何,此種方法較只說明原始投影片的內容能進行討論。然而由於此種討論的方式在時間的控制上須要教師多花心思加以控制。在下一章節我們將提出一軟工教學上的敏捷式方法以改進原始口頭講授可能造成的問題,以及提昇學生討論的興趣跟學習成效。另一個在資料結構引進軟體工程的實例可以參考[1]

三、軟體工程教學中的Agile 方法
由於傳統的口頭講授投影片的方法進行過程大致上為:教師講授課程大綱及目的;說明一系列內容;學生回家實作家庭作業;考試或測驗。而在其中或有穿插大型專題讓學生實作,在期末進行報告。
在此過程中若將講授課程大綱及目的類比為需求分析,教學過程便是分析與設計;而學生利用學到的東西進行實作則是系統實現,最後的考試及報告便是測試。這樣的過程事實上與軟體開發程序的Waterfall model是很相似的。而產生的問題也相當雷同:教師到期末才能了解到學生的學習成效。
在一個學生對學習相當積極的班級中,這種方式並不會造成太多的困擾。因為學生可以配合教師的教師內容,藉由同儕的幫忙與主動學習,自行查資料及課外書籍,以克服學習中的障礙。
然而在學習動力並不是太過強烈,甚至低落的班級中,這些學習障礙便很有可能形成相當大的困擾。教師可能要付出相當大的心力來提昇學生的學習意願。
為此在本論文中我們提出一個類似軟體開發過程的Agile 方法來避免以上的問題。此方法的過程如下:
  1. 提出問題:針對要教授的觀念或方法提出貼近學生真實性的問題,讓學生思考找出方法解決。以建立學生的學習目標。
  2. 說明技術:講解教材中的解決方法或技術,讓學生與所提方法進行比較。
  3. 實際應用:進行一個快速的案例讓學生應用所學或與之前經驗進行連結。
  4. 驗收成效:由學生的實作驗收所學的成效。讓學生有所產出,確認學生是否理解教學的內容。
  5. 反覆以上過程:對所要教授的內容反覆進行以上過程,直到學生吸收了解且能應用所學。

我們以圖一的軟體專案管理為例說明以上流程的進行。
          首先教師可以使用前一章節所提之方式提出符合學生真實性的問題。在經過短暫的思考與討論之後,將學生所提的解決方案羅列出來,進行比較。然後說明解決問題的方法。如圖一(b)中提出了三個議題:準時交貨,控制成本,及品質管控。
操作者要如何才能準時交貨而要準時交貨一定要先知道:有那些工作要作?這些工作要花多少時間?發生意外怎麼辦? 而此時便可引出WBS (Work Breakdown Structure),要徑分析法,里程碑,專案風險管理等相關的在接下來的投影片要介紹的內容,以說明克服前面相關問題的技術。而每提一個技術方法便可以讓學生說明如何應用所介紹的技術,以解決前面的問題。最後可以利用所介紹的方法來設計作業。而在討論之後教師便可以由學生的反應及報告驗證學生的理解程度,再適度加以修正或補充。

2012年9月3日 星期一

學習軟體工程中的學習障礙(三)

2.      技術梯度過陡
教學與學習的過程都須循序漸進,一步一步地教會或學會整個方法,進而應用。然而若學習的過程中在部份技術尚未掌握的情形下,學習更進一步的技術便會讓學生產生困惑。
如圖一(c)中學生從來沒有經歷過,或是在不了解何謂評估與選擇的前題下,說明軟體專案管理包含有評估與選擇便容易造成學生的困惑。更不用論專案規劃,組織設計,與專案控制,團隊領導了。期待學生能在短暫的時間內了解這張投影片內的內容是相當不切實際的。如此當學生帶著困惑持續學習的結果便是對課程內容晃然,造成在某個地方開始便不知所云。
另一問題是在學生程度不一的情形下,各別具有的背景知識不一,須要的梯度也有所不同。教師說明太細容易造成程度好的學生不耐煩,而太粗略則部份學生則會有跟不上的情況。

3.      未被理解的詞彙
在軟體工程的教學過程中,或多或少須使用一些專業詞彙來解釋說明所使用的技術。例如文件撰寫時使用的UML(Unified Modeling Language),或軟體設計時的Design Patterns 。而objectmodulesGUI(Graphical User Interface) API(application interface)app(application)等更是用來說明一些技術的常見專有名詞。
在教學的過程中,教師往往假設學生對這些名詞背後所代表的意涵有一定程度的理解,且能使用這些所了解的東西來學習新的技術與概念。然而現況往往不是如此。學生可能對物件Object 一知半解;軟體模組Module很可能被理解為一支比較大的程式;而GUIAPI則很有可能混淆不清;而APP則是跟手機上的遊戲程式直接劃上等號。
若在教學過程中學生經歷許多不理解的詞彙後,可能的現象便是教師講到第3張投影片時,學生對之前的投影片內容呈現一片空白的情形。以圖一為例,當學生對規格人力資源成本品質評估選擇組織與控制等詞彙無法理解或有與教師不同的認知時,對內容的吸收便可能不太順暢或與教師所預期的有相當大的差異。如最後學生可能對專案理解為一個須要很多人參與要花不少錢的活動,所以找同學一起外出唱歌也是一件專案。
在三頁的投影片介紹完畢後若學生遭遇以上的學習障礙,則最後可能得到的結論是:
       專案管理很複雜,有許多注意事項
       軟體專案管理很難,我要注意聴
       專案管理很專業,會了就很厲害
       老師真是專業
       聽不懂沒關係,出社會用到時再說
       反正考試不會考
       ….

這樣的結論相信與大多數教學者的期待是有相當的差距的。然而如何克服此一現象則通常會因為一些想法而被忽視。如:反正只是簡單的介紹,缺乏的部份到後面再補足便可以了。導致最後當學生注意力無法再集中時,學習成效便大打折扣。
事實上若教師直接講授投影片內容的話極易造成以下的弊病:
        學生的注意力由解決問題被轉移到過多專有名詞的定義
        一次太多的項目使得學生注意力分散
        沒有提供學生思考自行解決問題的空間
        大量的專有名詞定義對解決問題幫助有限
        吸收大量資料但沒有產品

通常人們買車的目的是為了騎上路,而車子的型態和機件的研究及相關定義並不是人們買車的目的,只是幫助理解的過渡。而學生學習軟體工程的目的也是為了提昇自我或團隊開發軟體的能力,以期可以直接應用到目前的專題或程式的開發當中。學生若是產生所學的東西要二年或多年後才有應用的地方,那失去或移轉興趣那也是在所難免!
然而基本觀念及專有名詞的介紹又是理解內容最常用的方法,如此則造成教學者的二難。事實上,筆者在教學的過程中發現只要依照此三種學習障礙的方向思考,了解何者會造成學習者的困擾,便可以針對原先的教材予以加強。進而避免掉上述的問題。 在本論文中我們提出針對以上三個學習障礙的解決方案:

  1. 提供與學生經驗相連結的實例:在每一個抽象觀念的說明後提供學生具有真實性的適當實例,以幫助學生結合抽象的理論與實際的例子。另一個部份是可以利用圖片來替代原始的文字說明,或邀請學生演練部份要介紹的內容,學生便可以更有真實性。例如要介紹指標如何運作,可以請學生直接當資料,用手當指標,而說明指標變化的過程則以移動學生的手加上講解。
  2. 協助學生由其先備知識過渡到所教授的觀念:在學生能舉出實例的範圍內舉例,以幫助學生由既有的想法進展到新提出的觀念。
  3. 儘可能使用學生可以理解的詞彙:介紹新觀念時所使用的詞彙,以學生曾經學過或能理解的為主。若一定要使用到專有詞彙須事先準備相關的說明。

以下我們以圖一(a)為例說明如何應用以上三個原則,以克服原本投影中資料可能產生的學習障礙。我們以粗斜體字表示原資料的每一個段落,下方則接著所舉之例子。
           所謂「專案」(Project)是指:「針對某一項獨特與唯一任務,採取一系列的行動來完成既定目標與交付任務地工作。」因此,每ㄧ項專案均有以下特性:
若今天你要跟同學一起辦一個資訊學院程式設計比賽,以提昇同學們對程式的投入程度。你必須要申請相關經費及場地,找人出題目及當裁判,最後利用此活動激起同學對程式撰寫的投入,及從中找出有意願參加校外程式設計比賽之人員。
           某一種規格範圍內的明確目標。
此次比賽預計邀請參賽同學200人,預計由其中選出志願參加校外程式設計比賽人員310人。
           開始與結束的時間。
規劃時間從現在開始,一個月後舉行比賽。
           有限的經費。
預計活動經費由學院各系學會支出,最多不超過三萬元。
           需耗費人力資源與非人力資源(例如設備、資 )與其他專案所需資源。
請你列出工作人員清單以及所使用電腦設備等資源的需求
           跨越不同部門與各種不同專長的成員參予。
裁判可以邀請各系老師担任,而軟體界面創意部份則請藝術學院老師或學生協助訂定規則及担任此部份之評分。