Software Cinema

最近開始改用短小的 TexMaker 取代 Kile 作為我主要的 LaTex 編輯工具. Kile 的介面實在太雜了, 以我使用特殊語法跟符號的頻率來說, 還是介面簡潔的 TexMaker 比較適合.

不過剛剛才發現在 Mandriva 2008 下, 利用 Package Manager 裝的 TexMaker, 其 Spelling Check ( 使用 Aspell ) 預設居然是採用 zh 語系, 所以用英文寫 paper 時怎樣檢查都不會發現拼字錯誤. 無怪乎我上一篇 research proposal 打完居然都沒發現錯字, 還以為自己變神了 ^^b, 高高興興地就寄給 Advisor. ( 慘了下次 Meeting 要被 Advisor 鞭了 )

要把 TexMaker 的 Spelling Check 語系改回到 en 才能夠正確地對於英文拼字作檢查. 下次重設系統千萬要記得 @@

可以把 Staged View 看成是 Level by Level, 每個 Level 含有多個 Process Area, 包含在四個大類別 ( Process Management, Project Management, Engineering, Support ) 中.


同時在各個 Level 之間, 也可以四個類別為導向, 垂直地 ( Vertically ) 串起 Process Area, 也就是 Continuous View.

這篇 paper [1] 主要提供了一個對於目前在 Software Engineering Experiments 中, 對於 Theory 使用的檢討之外, 其用來進行的方法, 同時也提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法.

如下圖所示意, 整體概念為自 Software Engineering Experiments 的範疇內, 定出一個 Factors 集合, 藉由串聯這些 Factors 集合, 對於所有目標的 Papers 作討論與分類, 最終結合將這些 Factors 串聯的方式, 以及利用 Papers 所作的驗證, 得到一個 Theory Use Model.


其中有價值的分為三部分. (1) 此 Process 本身, (2) 對於 Factors 進行串連的方法, 以及 (3) 一個呈現出具體成果的 Factors 集合.

此 Process 本身並非創新的提出, 而是一個 Common 的 Process, 但是這篇成功的 Paper 在討論 Software Engineering Experiments 的 Theory 使用上, 展示了此 Process 的合理使用. 自此可預見此 Process 會是往後相關延伸研究的基本 Process 之一.

對於 Factors 進行串聯的方法我認為是最有價值的部分. 往往我們可以列出許多的 Factors, 但是卻不知道怎樣對於 Factors 作取捨以及相互搭配, 主要原因我認為是所立足的基準點 ( Base ) 認識不清楚所致. 而這篇 paper 在整個過程中, 逐步穩固地解釋選擇 Factors 的合理理由, 同時以兩個軸去分析最重要的 Factors. 兩個軸分別是 (1) 對於 Theory Type 以及 Theory Components 的分析, (2) 對於 Theory Role 的分析, 這兩個軸事實上源自於同樣基準點 : 提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法, 換句話說, 跟如何選擇以及如何使用有很大的關係.

最終的部分, 一個呈現出具體成果的 Factors 集合, 我認為比較算是副產品. 除了可以驗證這樣的進行方式之外, 同時也是站在 Theory 於 Software Engineering Experiments 內, 以偏向 Empirical Study 的角度選擇了 Materials 以及相對的 Factors, 同時隨後進行的討論內容進一步證實了此 Factors 集合可以發揮的作用.

About Paper Writing

在 Paper 撰寫上我認為此篇 Paper 採用較為平鋪直敘的寫法. 首先在 Introduction 就說明問題, 以及本篇 Paper 所謹守的研究範圍. 接著承接研究目的及範圍, 說明上述的兩個主軸. 兩個主軸剛好對應到 Theory 本身的特性分析 ( Theory Type ) , 以及使用上的分析 ( Theory Role ), 因此分析立論一開始的空間感就很充足, 為之後的 Findings 解釋立下很說服人的基礎.

Section 3 說明此次 Review 的 Data 來源, 以及 Extract Data 的方法及原則. Section 4 則反向說明 Findings. 這裡的反向是指, 先從看完第三段後, 讀者可能會比較直覺想到的 Articles 與 Theories 之間的關係說明起, 再往回接到 Theory Roles 以及 Theory Types, Theory Components.我認為這樣寫的好處是不容易有文章閱讀上的斷點產生. 而後 Subsection 4.4, Subsection 4.5 則回歸到對於 Theory 出處以及所列為觀察的 Paper 之 Authors 之間, 對於 Theory 使用的分析, 我認為這邊事實上是回映到 Background 一開始的敘述. 回頭來稍微探討以 Theory 使用的觀點, Software Engineering 是否算是一個 Mature Science. Section 5 就以 Theory Use 為中心, 探討各項 Issues, 但是這邊我還看不出什麼 Regulation, 例如怎樣列出這些 Issues 之類的.

Remained Questions

• Paper 中提到, 對於所觀察的 Papers 選擇是自 1993 到 2002, 是否有特殊的理由 ? 或僅僅是因為 Time 以及 Effort 的考量而作此決定 ? 是否與 Empirical Study 的數量歷年增加比率有關 ?
• 本篇 Paper 本身是否也算是利用了 Role Theory ?
• Figure 1. 中, 左右的順序之意義為何 ?
• Figure 1. 中, Experiment 與 explain 所涵蓋的範圍是一樣嗎 ? 又所涵蓋的範圍應該怎樣解釋其意義. 同時 Theory 所涵蓋的範圍以及意義又是如何 ?
• 最後的 Section 5. Discussion 是否有任何的 Regulation 存在 ? 往後進行相似的 Researches 時, 應該怎樣進行 Discussion ?
  

References

[1] Jo E. Hannay, Dag I.K. Sjøberg, and Tore Dyba°, "A Systematic Review of Theory Use in Software Engineering Experiments," IEEE Transactions on Software Engineering, vol.33, no.2, pp.87-107, Feb. 2007

此篇文章以台大本身所建立的 CEIBA 數位課程管理平台 為例, 藉由使用統計數據, 說明 Learning Management System 在教師使用情況上, 成功關鍵在於系統設計之初, 是否針對校內教師的需求進行設計, 而非系統平台本身的技術性問題.

Before investing time and money to develop technically advanced tools, it is necessary to investigate the needs of the faculty [1].

這在軟體開法方法論中, 其實並不是甚麼新的結論, 但是如果我們以國內的情況來說, 卻很少有學校的管理階層體認到這一點.

在文章中也特別提到 CEIBA 建構團隊針對台大人文相關系所的教師需求, 在 CEIBA 上提供建立多媒體互動教學資料的輔助工具, 使得不懂 PC 操作的人文科系教師也很容易可以利用該系統建立所需要的教學資料. 這點聽起來似乎不簡單, 好像似乎要提供很強大的使用者介面的感覺. 但是我覺得如果真的有實地去蒐集教師的需求, 在 CEIBA 內可能只需要很簡單的功能就可以達成相當好的效果. Software 只是解決問題的 Solutions 其中一種, 而選擇 Software 的理想目的應該是為了使用者省下許多麻煩, 在幾乎不用改變正常工作流程下享受 Software 的好處.

從下圖可以看到, 自 2000 年到 2007 年, 人文相關科系的教師使用情況, 遠比理工科系的來的理想. 除了上述的原因, 可能也跟理工科系的老師習慣自己或請學生準備教學資料, 再放到網路上, 而非使用統一的教學平台有關. 不過文章並沒有針對此一部份進行說明.


另外在文章中也針對 CEIBA 上各項功能在 95 年第二學期的使用情況做了統計. 其中 Interaction 部份的使用情況都偏低, 相對來說 Knowledge 部份則比較高. 可以看出學生還是不習慣使用網路平台進行互動式學習. 這可能也跟台灣學生習慣在講堂上單方面接受來自於教師的知識傳授, 但是較少藉由團體合作進行課程學習有關.

另外我覺得值得一提的, 但是文章中可能因為與重點無關所以沒有說明的是, 看起來 CEIBA 自 1995 開始歷經了數年幾代的發展, 目前是CEIBA 4, 其中自 CEIBA, CEIBA 2, CEIBA 3, 到 CEIBA 4 每一代的發展維護人員幾乎都不相同. 很好奇 CEIBA 本身的 Quality 如何, 畢竟在 1995 到 2000 年, 對於 Web-based System 的 Quality 觀念應該還不成熟, 同時許多功能應該是最近幾年才加上去的. 很想看看是否有 CEIBA 對照 New Features 與 Quality 變化的相對數據圖表.


References

[1] Hsiu-Ping Yueh and Shihkuan Hsu, "Designing A Learning Management System to Support Instruction," Communications of the ACM, vol.51, no.4, pp.59-63, April 2008