軟體工程中的系統文獻映射研究-設計和執行過程的第三步

接着上一篇（“軟體工程中的系統文獻映射研究-設計和執行過程的第二步”），繼續講軟體工程中的系統文獻映射研究。

上一篇給出了文獻的正式檢索和篩選過程的圖，這裡把整個流程梳理一遍。

文獻的正式檢索和篩選過程一般包括7個步驟：  

步驟1：在資料庫中檢索文獻。  

收錄文獻的資料庫非常多，怎麼選擇非常重要。例如在我前面對軟體開發中的假設條件及其管理的研究中，選擇的标準一個是根據我們自身的經驗，另一個就是根據其他類似文獻的選擇情況。在該研究中我們最終定下了7個資料庫。選取的資料庫未包括Google Scholar，因為針對軟體工程的文獻，該資料庫的精度存在問題，且可能與其他資料庫的檢索結果大量重複[1]。

選取的資料庫描述如下。

（1）ACM Digital Library  

（2）IEEE Explore  

（3）Science Direct  

（4）Springer Link  

（5）Wiley InterScience  

（6）EI Compendex  

（7）ISI Web of Science 

其次就是檢索詞的問題，因這七個資料庫采用不同的檢索引擎和政策，是以在各資料庫中的檢索範圍也不同。例如在Springer Link資料庫中，其檢索引擎支援使用者檢索 “with all of the words”、“with the exact phase”、“with at least one of the words”、“without the words”、“where the title contains”、“where the authors / editor is”、“show documents published”。但是該引擎并不支援基于關鍵字或摘要的檢索。是以針對Springer Link資料庫，本研究設定其檢索範圍為标題。

再次是檢索時間的範圍。時間範圍是影響研究的一個關鍵因素。目前軟體工程中的系統文獻映射研究還無法做到自動化，基本上還是依賴于大量的人工參與。如果不控制時間範圍，往往會檢索到海量的結果，光靠人工很難在合理的時間内篩選完。但如果控制時間範圍，那就涉及到怎麼選擇開始時間和截止時間的問題。截止時間很好确定，比如可以是我們開始這項研究的時間。但是開始時間往往需要一些政策。

（1）這個領域是否有裡程碑？裡程碑可以是該領域内的某個著名事件（比如靈活開發領域中靈活宣言的提出），也可以是某篇具有重要意義文章的發表（比如軟體架構領域Perry and Wolf發表的文章被認為是該領域的奠基成果）。如果有，則可以考慮選擇裡程碑的時間節點作為開始時間。

（2）如果實在找不到裡程碑，那就要考慮以一個固定年限做檢索（如10年、15年、20年）。但到底是10年、15年，還是多少年，應綜合判斷：a. 檢索篩選過程是否能在合理時間内完成。b. 是否能得到足夠數量的入選文獻以形成有意義的結論。不可否認，這裡面主觀性較大。

例如在我前面對軟體開發中的假設條件及其管理的研究中，檢索的時間範圍為2001年1月到2015年12月（系統文獻映射研究的開始時間）。該研究中，若采用不設定時間範圍的檢索與篩選過程，會導緻需要極高的成本以及并不能在合理的時間内完成。然而因為軟體開發中假設條件及其管理的主題廣度較大，我們并未發現任何文獻可以充當此主題的裡程碑。考慮到對此系統文獻映射研究而言，十五年是一個合理的時間範圍，是以該研究設定2001年1月為起始時間點。

最後是檢索表達式的問題。在“軟體工程中的系統文獻映射研究-設計和執行過程的第二步”中，已經提過在文獻的試驗性檢索和篩選過程中會嘗試不同組合的檢索表達式，是以在這隻需要直接采用前面得到的結論即可。例如在我前面對軟體開發中的假設條件及其管理的研究中，我們在這一步采用的檢索表達式為：(software) AND (assumption OR assume OR assuming)。

步驟2：基于資料庫的檢索結果進行第一輪篩選（标題和摘要）。

從資料庫檢索出一定數量的文獻後，就轉入了第一輪篩選。這一輪篩選中我們會閱讀每一篇從資料庫中檢索出的文獻的标題和摘要，結合事先拟定好的篩選标準，以判斷某文獻是否可以進入下一輪篩選。在這一步中可以淘汰大部分的文獻。

注意：也有研究将标題和摘要分為兩輪篩選，是以文獻的正式檢索和篩選過程也可能有8個步驟。 

所有的軟體工程中的系統文獻映射研究都必須有文獻的篩選标準，這些标準同樣需要在文獻的試驗性檢索和篩選過程中進行設計、精化、驗證。例如在我前面對軟體開發中的假設條件及其管理的研究中，我們采用的标準如下所述。

入選标準：  

I1：該文獻關注軟體開發中的假設條件（如需求的假設條件）。  

排除标準：  

E1：該文獻關注方法或工具的假設條件。  

E2：該文獻未經同行評審（如技術報告）[2]。  

E3：如果同一工作在多篇文獻中出現，排除較不成熟的文獻。  

E4：該文獻的語言不是英語。  

E5：該文獻僅有摘要而無全文。  

E6：該文獻僅僅提到假設條件的術語。  

E7：該文獻沒有用于回答研究問題的有效資料。  

采用E1的原因是現存兩種類型的假設條件：（1）在軟體開發中制定的假設條件（例如假設某軟體的使用者多為老年人）以及（2）為特定方法和工具制定的假設條件（例如對方法或工具的設計做出假設）。因為此系統文獻映射研究的主題為軟體開發中的假設條件及其管理，是以采用E1來排除那些關注方法或工具的假設條件的文獻。

步驟3：基于步驟2的結果進行第二輪篩選（全文）。  

顧名思義，這一步中要針對步驟2中過濾出來的文獻，進一步閱讀其全文，并結合拟定好的篩選标準以判斷某文獻是否進入下一輪。

步驟4：基于步驟3的結果采用滾雪球技術[3]對其參考文獻進行人工篩選。

滾雪球包括對一篇文獻的參考文獻進行篩選（逆向滾雪球）或者對引用該文獻的其他文獻進行篩選（正向滾雪球）以識别額外的相關文獻[3]。

例如在我前面對軟體開發中的假設條件及其管理的研究中，我們首先采用逆向滾雪球技術識别額外的相關文獻（即步驟4-1），然後通過标題和摘要篩選識别的文獻（即步驟4-2），最後基于步驟4-2的結果通過全文篩選文獻（即步驟4-3）。  

步驟5：擴充檢索。

在前面檢索和篩選的過程中，有可能發現研究設計不完備的地方，那麼這個時候就應該加以補救。

例如在我前面對軟體開發中的假設條件及其管理的研究中，我們還執行了一步擴充檢索，即在七個資料庫中檢索和篩選關于rely-guarantee和assumption-commitment的方法。執行該步驟的原因是在執行步驟3和步驟4的同時，研究執行過程中發現一些入選文獻使用assume-guarantee方法（又名rely-guarantee或者assumption-commitment）在軟體開發中管理假設條件。  

以我的經驗來說，在這一步結束後得到的文獻數量在大部分研究中為50-200。小于50很難形成有意義的結果，而大于200則需要花費大量的時間成本。當然這個50和200的資料非常主觀，不能作為絕對标準衡量，僅供參考。

步驟6：資料抽取（包含試驗性的資料抽取）。

當篩選出一定數量的文獻後，則轉入抽取資料的階段。抽什麼資料，怎麼抽這些設計上的問題應該預先就已經确定下來。特别值得強調的是，抽取的資料必須覆寫且有能力回答所有的研究問題。 例如在我前面對軟體開發中的假設條件及其管理的研究中，抽取的資料如下所述。

#	資料項	描述	研究問題
D1	ID	文獻的辨別	不适用
D2	标題	文獻的标題	不适用
D3	作者	文獻的作者	不适用
D4	作者類型	學術界、工業界、兩者皆有	不适用
D5	發表類型	書籍、期刊、會議、研讨會	不适用
D6	發表來源	文獻的發表來源（如期刊名）	不适用
D7	發表年度	文獻的發表年度	不适用
D8	定義	假設條件的定義	研究問題一
D9	軟體開發活動	與假設條件有關的軟體開發活動（如需求工程）	研究問題二
D10	制品	與假設條件有關的軟體制品（如需求）	研究問題三
D11	假設條件管理活動	假設條件管理活動（如制定假設條件）	研究問題四
D12	方法	假設條件管理方法	研究問題五
D13	工具	假設條件管理工具	研究問題五
D14	涉衆	與管理假設條件有關的涉衆	研究問題六
D15	收益	軟體開發中管理假設條件的收益	研究問題七
D16	挑戰	軟體開發中管理假設條件的挑戰	研究問題七
D17	後果	軟體開發中未被妥善管理的假設條件造成的後果	研究問題八
D18	經驗	軟體開發中管理假設條件有關的經驗	研究問題九

步驟7：資料分析。

資料分析包括很多方法，比如描述性的統計分析以及Constant Comparison方法 [4][5]。

這裡簡單介紹一下Constant Comparison方法。

Constant Comparison為從資料中生成概念提供了系統的方法，并針對生成的概念和分類的驗證提供了一個持續的過程[4][5]。本研究遵從Adolph等提出的關于執行Constant Comparison的指南[5]。例如在我前面對軟體開發中的假設條件及其管理的研究中，我們将抽取的資料編碼為事件；比較這些事件以生成概念；然後繼續比較這些事件和概念以生成分類。例如一篇文獻提到：“Sometimes changes could be adopted easily; but sometimes even crucial parts of the application had to be rewritten, often because its assumptions did not hold any longer”，先将其編碼為：“Consequences caused by not well-managed assumptions”。其中本研究會使用子編碼來細化特定的事件。考慮以上的例子，采用的子編碼為：“Consequences caused by not well-managed assumptions: Invalid assumptions”。請注意事件的長度可能為一個簡單的單詞，也可能是幾個段落。

參考文獻

[1] L. Chen, M.A. Babar, and H. Zhang. Towards an evidence-based understanding of electronic data sources. In: Proceedings of the 14th International Conference on Evaluation and Assessment in Software Engineering (ESEM), Bolzano-Bozen, Italy, pp. 135-138, 2010. 

[2] B. Kitchenham and S. Charters. Guidelines for Performing Systematic Literature Reviews in Software Engineering, Version 2.3. EBSE Technical Report EBSE-2007-01, Keele University and Durham University, 2007.

[3]C. Wohlin. Guidelines for snowballing in systematic literature studies and a replication in software engineering. In: Proceedings of the 18th International Conference on Evaluation and Assessment in Software Engineering (EASE), London, UK, Article No. 38, 2014.

[4] B.G. Glaser and A.L. Strauss. The Discovery of Grounded Theory: Strategies for Qualitative Research. New York: Aldine Publishing, 1967.

[5] S. Adolph, W. Hall, and P. Kruchten. Using grounded theory to study the experience of software development. Empirical Software Engineering, 16(4): 487-513, 2011.