[摘要] 隨著信息產業在中國經濟發展過程中重要性的提升,社會對信息系統應用管理人才的需求會顯著增加,對信息系統分析與設計的實驗教學效果的提升的研究將意義重大。本文將借鑒小企業的IT項目管理經驗,對此方面的管理工作進行探討。
[關鍵詞] 信息系統 實驗教學 管理思路
一、信息系統分析與設計實驗教學中培訓學員常犯的錯誤
在信息系統分析與設計的培訓實驗教學中,相對于大型IT軟件項目,學員小組規模的應用實驗課題具有靈活性高、軟件功能相對較少、小組成員人數較少(一般2~4人為宜)、實驗教學周期較短的特點。
我們經常提到“軟件危機”一詞,這是指一些大型軟件項目延期,導致項目順利交接存在困難。當然這并不意味著“軟件危機”就與實驗教學中的學員課題毫無干系。雖然規模較小的學員實驗課題看起來比較簡單,比較容易成功實現,但如果在實驗教學中忽視了必要的教學管理和指導,則學員很容易出現以下的一些錯誤:
1. 對培訓學員實驗課題的小組成員而言
⑴ 草率確定實驗課題的名稱及范圍
對于許多培訓學員來講,對社會、行業及企業的業務實際運作情況了解較少,缺乏業務調研的經驗等是不爭的事實。如果這些情況在實驗教學中得不到切實有效地改善,將對信息系統分析與設計的實驗教學效果造成致命的影響。
因此,應考慮指導培訓學員小組的成員根據其實驗課題的周期長短,謹慎選擇與其技術能力相適應的課題,并控制課題的功能范圍。
⑵ 缺乏對隱性問題的重視
作為一位培訓學員實驗課題小組的成員,當實驗開始時,就把自己與實驗是否成功的命運聯系在一起了。實驗的成功與失敗都無疑會對小組成員造成心理上、情緒上的影響。因此上述因素對小組成員的隱性影響最終會體現在學生學習的積極性上,并最終關聯到信息系統分析與設計課程的實驗教學效果。
⑶ 草率的計劃
信息系統分析與設計的實驗教學課題往往由于規模較小,培訓學員小組成員經常在軟件開發之前沒有認真地進行可行性分析和實驗工作量的估計,便很草率地制定一個實驗工作進度表。同時,由于沒有認真地估計實驗課題的難度,結果實際完成時間與估計完成時間往往有較大差別,這種偏差必將使實驗教學的效果陷入困境。在IT項目管理咨詢行業,許多中小企業對于類似這種偏差的認識,也認為是執行過程除了差錯,其實根源卻是項目的前端出了問題。
2. 培訓學員實驗過程中的蹩腳設計
從較小規模的實驗課題特點來看,學員小組成員人數少,意味著不同人員的程序之間交互、接口相對少一些;開發周期短,意味著往往是同樣的幾個人從頭到尾負責一個實驗課題。上述情況都讓人容易犯些錯誤,例如往往是幾個人碰一下意見,討論一下最基本的數據結構、函數接口便分頭去做自己的工作了,并沒有一份較正式的文檔。這種做法的危險主要表現在:
⑴ 有的人可能會對討論出的接口、結構理解有偏差,應該承認并不是所有參加會議的人總是很明白,人是會犯錯誤的。而往往一個單純的誤解可能造成以后的返回。
⑵ 由于討論時忽略了某些情況,等大家都按當時的分工完成屬于自己的工作后,才發現各個模塊組合起來卻形不成一個完整的系統。其根源在于系統設計不充分,沒有一個負責協調的人員不斷監控整個開發過程。
⑶ 一旦有人中途退出實驗小組,或有其他新人加入時,新來的人難以理解以前別人做好的代碼,索性自己從頭來。
另外,沒有技術文檔的程序,日后維護和版本升級都比較困難。這些對信息系統分析與設計的培訓實驗教學效果的提升都是不利的。
3. 培訓學員實驗過程中的直奔系統現象
直奔系統現象指培訓學員實驗課題的實施中,不經過單元測試而直接進入系統測試。造成這一現象的原因是每個模塊相對比較簡單,但是為了測試一個模塊需要建立一些測試環境。比如為了測試一個函數是否正確,應該用一些測試數據去調用該函數,需要編寫一些測試數據。
應該承認,單元測試的是挺麻煩。因此許多培訓學員會覺得,反正其他模塊也很快出來了,直接用真正的數據來運行幾次就行了。殊不知,一旦直接進入系統測試,發現運行結果不正確后需要一步一步查找。同時,由于模塊間的調用關系,可能查了很久才發現是某個模塊的問題。
直奔系統現象如果僥幸成功,效率可能會很高,但這種成功的概率一般不超過40%。正所謂欲速則不達,如果我們對每個模塊進行單元測試時都進行一下邊界測試,就會很容易消除這些隱患。
二、信息系統分析與設計培訓實驗教學效果的管理思路
要提高信息系統分析與設計課程的培訓實驗教學效果,就教學管理而言,可形容為“麻雀雖小,五臟俱全”。即培訓學員小組形式的應用課題實驗,仍然應該遵循信息系統分析與設計的一般規律,必須的步驟是不能省略的。但也需注意其規模較小的一些特點,實驗過程中可以具體問題具體分析,相對靈活地把握其進度和功能范圍等因素。
1. 需求調研、獲取及文檔整理
在這一環節上面花費相當時間是很必要,也是很值得的。所有的信息系統項目進入正式研發之前,必須先從用戶處獲取準確的需求信息,并加以分析。信息系統項目可以大致分為專用系統和通用系統兩大類。
對于專用系統,一般用戶對于要完成哪些功能,已經有了比較清楚的輪廓,需求相對較為明確,培訓學員實驗小組的成員通過與用戶進行比較具體的交流和討論,結合Internet等途徑采集相關的、較為豐富的素材資料,即可了解清楚用戶心目中的系統究竟是什么樣子。做好這個步驟,則可以避免實驗后期因學員的理解和用戶的要求存在誤解,而造成的時間上的浪費。
對于通用系統,就需要更多地從技術的角度考慮需求。例如現有硬件配置情況、軟件配置情況、網絡使用狀況,數據庫應用等。為得到這些信息,需要根據調研的統計結果決定即將信息系統的一些技術指標。
需求分析就是將需求用一種模型來表示,即借助相應的技術分析文檔表現出來。在采用面向對象的分析方法時,雖然其具有分析、設計、編碼過程統一的優點,但關注瀑布模型、原型模型、增量模型等,對于學生實驗工作流程的推進和技術文檔的完整是有益的。
2. 信息系統的設計過程
這一環節主要是進行系統結構設計、數據結構(數據庫)設計、界面設計等工作,當然包括對分析模型必要的修改和完善。
在面向對象的設計環境中,可能需要對某些類結構進行一些修改,這些修改的原因可能是編程環境的要求,或者為了重用以前的某些工作。比如定義界面部分、數據訪問(數據庫)部分。
3. 信息系統的編碼工作
進入信息系統的編碼環節,培訓學員可能會發現前面分析或設計階段的某些錯誤,這時應返回到前面的階段進行必要的修改。測試階段正如前所述,即使規模較小,也應該嚴格地進行測試。
4. 培訓學員實驗小組成員的指導與管理
規模較小的培訓學員實驗課題,一般可以由2~4名學員來完成,這幾個人基本上從頭到尾參加信息系統的分析與設計。在這幾個人中,通常可以有一位小組負責人,負責分析、設計和協調的工作。當然,小組負責人也要參加編程等實驗工作,如何指導該學員能合理使用有限的實驗時間,提高實驗教學的效果,一般需要遵循下面幾點原則:
⑴ 協調工作比自己去做更重要.
一般而言,IT項目管理的主要工作就是協調,如果協調上出了漏洞,可能導致很大的問題。所以學員實驗小組的負責人必須隨時監控小組各成員的工作進展,例如內容是否與要求發生偏差,進度是否滯后等。只有在完成這些工作之后,小組負責人剩下的時間才能用于編程等其他事務。
⑵ 給每個小組成員明確的任務
不管是用面向對象或者其他方法進行信息系統的實驗,分析、設計模型只是從功能的角度來描述系統。因此,具體實驗過程中每個小組成員必須非常明確自己的任務,這些任務應該采用明確的文檔來描述。
⑶ 讓大家都大致熟悉設計模型
要讓每個小組成員都清楚自己所需要完成的任務在整個系統中處于什么地位,學員小組的成員因此可能會發現設計模型中的漏洞,避免了各人的代碼編寫完畢之后又要修改的后果。
參考文獻:
[1] 信息系統分析與設計,丁浩編著,清華大學出版社,2009年3月
[2] 信息系統分析與設計(第二版),耿騫編著,高等教育出版社,2008年1月
[3] 軟件測試方案分析與研究,郝愛語,中小企業管理與科技,2009年12月