摘要:文章探討了指導學生進行模擬軟件項目開發的方法。作為教學改革的一個環節,最終的目的是讓學生能有一定的軟件開發體驗,能夠在以后的實際工作中較快進入角色。
關鍵詞:軟件開發教學;項目教學;教學改革
目前針對計算機軟件專業學生進行的項目開發式實踐性教學主要是課程設計環節和畢業設計環節。但當前一般的課程設計環節主要突出的重點是某門課程的知識運用。本文旨在探討在學生完成部分專業課學習,具備開發一個簡單而有代表性的完整軟件的基礎之后,如何引導學生進行第一次完整軟件開發。在軟件專業教學領域,最終應以綜合運用多門課程知識的項目導向式綜合課程設計取代原來教學環節中單獨針對某門課程的課程設計。
教學過程
(一)選題
指導教師應引導學生選擇一個力所能及的開發題目。所以指導教師應向學生提出幾個選題的原則:(1)選擇一般的管理或商業運用領域。不要選擇系統軟件和實時軟件等復雜程度很高且質量要求很高的軟件領域,也不要選擇工業控制、嵌入式或科學計算等專門程度太高的軟件領域。(2)選擇一個易于理解的業務邏輯流程。畢竟我們的目標是去體會怎樣開發軟件而不是做企業管理。(3)選擇學生已經學過的課程或開發工具適合做的項目。(4)選擇規模很小的項目。作為第一次軟件開發,過大的規模很可能會導致學生不能完成而產生挫折感;同時,對于第一次軟件開發,指導教師不必強調分工合作而更注重每個學生都應該獨立完成整個過程,獲得完整的體驗。(5)為便于教學和學生平時交流、對比,所有學生做同一個項目。
在向學生闡述這些原則后,指導教師與學生一起討論做什么樣的項目。根據上述第二條原則,學生一般會選擇比較容易理解的成績管理、宿舍管理、學籍管理、人事管理、考勤管理、便利店進銷存、家政管理、工資管理、物業服務等沒有什么特殊業務性質的系統中的一個或一部分作為初次軟件開發的題目。根據學生所學的課程,往往會用到一種圖形化的開發工具和數據庫結合來完成項目的具體編碼(一般使用VB+SQL Server)。
在確定好題目后,指導教師應給學生講一講軟件開發模型的知識(已學過軟件工程課程的則可以提綱挈領地復習一下相關知識)。作為第一次軟件開發,應該采用技術成熟、步驟清晰的自頂向下的結構化生命周期方法。這也是我們要求業務邏輯簡單的原因,簡單清楚的業務邏輯非常適合自頂向下的方法。結構化方法一般把軟件生命周期分為系統分析(SA-System Analysis)、系統設計(SD-System Design)、編碼(Coding)、測試(Testing)等若干階段。
雖然項目規模小、業務邏輯簡單清楚,系統分析的工作量不大,但考慮到學生不知如何入手,指導教師可以在確定題目后剩下的1~2個小時內給學生示范本項目編寫系統說明書的系統分析部分,與學生一邊討論一邊一起編寫系統分析文檔的初稿,簡單地描述項目目標,功能分類和范圍等。最好畫出一個本項目完整的功能模塊圖。
選題完成后,指導教師給學生一周左右的時間(這個軟件開發過程教學均為利用學生正常上課的課外時間進行,以下的時間間隔概念均與此相同)根據系統分析框架初稿思考和完善系統分析文檔。可建議學生參考一些案例書籍來完成這項工作。一周以后,指導教師應評閱所有學生的系統分析文檔對各個層次的典型作品進行點評,還要請被點評學生就這個階段的工作談體會(工作方法;參考資料、方式;困難與收獲等)。要求學生根據點評結果最終定稿系統分析文檔,一般還需要2~3天,形成3~5頁的文件。
這個階段的任務對大多數學生而言都能順利完成。這是建立在項目規模小、業務邏輯簡單清楚的基礎上。學生設計初期的畏懼感大大地減弱了。
(二)系統設計
雖然整個項目相對不太復雜,不再細分為概要設計和詳細設計兩個階段,但設計的工作量還是比較大,也是整個軟件開發過程教學的一個難點和重點。
通過實際觀察,我發現對初次進行軟件開發的學生而言,如果僅僅給幾個參考文檔或者案例就讓他做系統設計的效果是不理想的,絕大多數情況下學生會生搬硬套,不能根據系統分析階段確定的規劃要求作出符合當前標準的設計。最大的原因是學生還不能很好消化課堂上和參考資料里的知識點,仍孤立地看待完整的問題并作出分析。當然,在現有的教學計劃中,也沒有這方面的訓練,最多是在開設的軟件工程課程中有概念性的講解。因此我采用的辦法是在教學課堂上由指導教師進行一部分設計并詳細剖析設計的原理和規范,學生跟著模仿設計,再在這個基礎上布置類似模塊讓學生獨立完成。這種方式需要指導教師做好準備工作。采用這種方式的主要目的是讓學生對設計工作有直觀的認識和模仿的基礎。
一般說來,整個設計過程的教學可以分為數據庫設計和界面及功能設計兩個部分,具體如下:
數據庫設計根據系統分析中的功能要求和范圍,確定實體-關系模型(E-R模型),在E-R模型基礎上確定數據庫的邏輯和物理設計。數據庫設計是整個軟件開發教學過程中學生最弱的環節,因為這是一個實踐性很強的問題,需要很多數據規劃的經驗,而學生沒有也不可能一下子獲得這些經驗。從實踐效果看,幾乎所有學生都不可能獨自完成合適的數據庫設計。因此我采用的辦法是(針對學生的第一次軟件開發)數據庫設計以指導教師設計為主,學生僅僅是在指導教師形成的數據庫設計文檔基礎上根據要求稍微完善和補充一些比較容易理解的細節。設計采用ERWin或者Visio等圖形化工具畫出ER圖,并結合數據庫理論中的第一、第二、第三范式詳細給學生講解怎樣確定一個表的主鍵和取舍其他字段;什么情況下需要拆成主、從表,怎樣拆,怎樣確定合適的外鍵;怎樣存放和處理實際數據。然后根據ER圖生成具體的數據庫結構并整理成表格文檔。指導教師在設計課的第一次課上完成大部分數據庫設計和講解。剩余部分布置學生課外完成,一周以后的第二次課檢查學生完成情況。實際情況表明,能基本準確完成的學生仍不多,指導教師在第二次課上將整個數據庫設計完成并針對學生在獨立設計數據庫結構中的問題做具體分析。整個數據庫設計共計一周左右,學生沒有很好地完成。但通過指導教師的演示,可以獲得一些經驗,在下一次的軟件開發中能更有效地分析參考案例或資料中的數據庫設計。
模塊界面及功能設計因為這個環節的內容比較直觀,完成設計的情況比數據庫設計要好一些。在完成數據庫設計后,指導教師可以給學生在課堂上示范按系統分析功能要求進行模塊設計。根據功能劃分畫出相應的界面并布置好對應的控件,然后對每個控件作功能說明,還要作相應數據處理說明以及頁面跳轉的說明。需要注意的是,這個階段一般要求使用后續編碼階段要采用的可視化編程工具來進行界面設計,以利于編碼階段的重用,但一定要強調界面規范——界面大小、控件擺放、控件大小、什么字體、不同界面間的統一風格等等。不同的項目,模塊界面及功能設計的完成時間不一樣,一般需要3周左右。平時表現和成績較好的學生基本都能完成并初步達到設計的要求,未能完成的學生的主要問題是沒有投入相應于較大工作量的工作時間。指導教師在期間召開一次會議組織學生討論并點評有代表性的學生的階段成果。
特別需要指出的是,整個設計過程會經歷一些反復,很多沒考慮周全的細節會在后續的編碼或測試階段暴露出問題,因此設計文檔也需要根據實際開發情況作出一些調整。適當的調整也有助于培養學生嚴密的思維。
編碼和測試
比較而言,編碼是學生較為熟悉的工作,能夠較快進入角色。但實際情況中編碼階段的問題并不少。雖然學生不必像前面系統分析和設計階段那樣由指導教師來親自示范進行前期引導。編碼階段的問題主要體現在以下幾個方面:(1)編碼規范。雖然在相應的課程學習時都多少有所提及,但絕大多數學生仍然編寫的是非常零亂的程序。這需要指導教師經常提醒或示范并要求學生及時改正已有的程序。在編碼階段后期,部分學生開始自覺按規范編寫程序。這時指導教師應以這些學生的作品為示范,并要求他們幫助指導其他學生。(2)程序錯誤調試。這是最突出的問題。學生往往在程序出錯時不知所措,難以自己解決問題。指導教師可以以學生作品中出現的典型問題為例,結合調試程序的一般原理,多次在機房示范講解怎樣調試程序。但這個問題不能光通過指導教師的講解來解決,還需要學生自身不斷實踐,投入大量時間、精力去調試、完善自己的程序。在編碼階段后期,應要求學生相互交流調試程序的經驗。對于學生討論后還不能解決的問題,指導教師應給予支持。(3)學生的情緒不穩定。碰到問題長時間不能解決后,多數學生有畏難情緒,甚至想放棄。指導教師這個時候應該及時組織學生一起交流,特別是鼓勵取得階段性成果并帶有喜悅、興奮情緒的學生談體會,讓別的學生分享其喜悅,大家相互促進。指導教師如果直接給學生加油鼓勁往往不能起到好效果,學生間的相互感染要直接有效得多。
測試階段在實際工作中也很重要。但在第一次的軟件開發教學過程中不必太強調。因為要求苛刻的測試會讓多數學生感到作品一無是處,從而沒有成就感。一般說來,要求學生在編碼過程中同步做初步的功能測試,在完成編碼后做初步的運行測試即可。可能的話,可以鼓勵學生相互間做功能和運行測試。
編碼和測試階段共需要4~6周。設計階段完成較好的學生在這個階段會順利一些。很多學生在這個階段經歷挫折后取得了成功,從而激發了學習興趣。
待學生作品基本完成后,可組織全體學生介紹展示自己的作品并談談體會。還請一些教師來為學生的作品評分。從結果看,整個軟件開發教學過程達到了預期目的。學生普遍感到經歷這樣的過程后,提高了軟件開發能力。□