【轉】尋求一種更好的軟件工程研究方法

時間 2019-11-10

標籤尋求一種更好軟件工程研究方法简体版

原文原文鏈接

Mary Shaw
html

尋求一種更好的軟件工程研究方法架構

Mary Shaw框架

School of Computer Science, Carnegie Mellon University工具

摘要關於對物理學，生物學和醫學的研究過程，人們早已有了公開的精準的解釋。即使是在形式上看似簡單，但這個領域的內和外也算提供了有價值的「高水準研究」的指導。可是軟件工程就不一樣了，人們至今還沒有明確找到並解釋如何研究以及用何種方法去進行研究。（方法論也是頂層設計，只有找到了高屋建瓴的研究方法，才能推進這個行業的進步。本論文發表於2002年，通過多年的努力，人們（包括Mary Shaw在內的有識之士），已經找到了一些研究方法，軟件工程取得了長足的進步。因此軟件業已經獲得了日新月異的發展，它對社會變革和發展起到了舉足輕重的做用。---譯者注）性能

在科學與工程研究領域描述了根據他們發現的有價值的調查，適合他們的研究方法，和他們評估結果採用的標準。我也爲軟件工程都勾勒出一個輪廓，以展現他們的想法成熟度在轉變中研究策略和方法中的差別性。瞭解這些戰略可以清楚地幫助軟件工程師們的設計研究計劃和報告結果；它也有助於詳細地解釋軟件工程研究在計算機科學和其餘科學家的特徵。（軟件工程學科與其餘工程類的學科同樣，是生產（或開發）軟件系統的基礎，如果沒有軟件工程專業知識，軟件系統就會搞得亂七八糟，難道不是嗎？中國目前的情況就是這樣。因此Mary Shaw們經過大量的調查研究，尋找合適的研究方法，制定恰如其分的評估標準，爲軟件系統的開發尋求一條光明之路。如今看來，這條道路已經慢慢明朗了，不論的由DOD委託CMU制定的CMM，仍是微軟，IBM等本身制定的軟件開發內部標準都是行之有效的。固然還有更多的前後出臺的關於軟件工程教育方面一整套教育教學標準等---譯者注）測試

一、引言google

許多學科對它們的研究策略有很好的解釋。這些解釋包括不只給研究人員有詳細的指導，並且也有簡約方式給到公衆和其餘觀察人員。接受其結果依賴於獲取結果的過程，以及分析的結果自己。小學生作物理的實驗模型：有假設，對照實驗，分析和可能的反駁。公衆瞭解大規模雙盲醫療研究足以討論實驗治療的風險，從對照組預提治療倫理和利益衝突，被致盲的過程解決了。spa

軟件工程不會有這種很好理解的分類指導。軟件工程研究人員不多有人會寫明確的關於他們研究的範式以及他們評判質量結果的標準。曾經有過一些表徵着軟件工程研究的嘗試，但他們始終沒有勾勒出一幅對軟件工程全面理解的關係圖來。1980年，我曾考察了工程學科基於工藝和技術的關係，並制定爲軟件制定了一個工程學科的預期計劃。1984至1985，Redwine，Riddle，和其餘人一塊兒從研究思路到普遍的實踐提出了一個軟件工程技術發展的模型。最近，軟件工程研究人員在報告中曾批評這個領域中常見的實踐，在收集，分析和報告實驗度量的缺陷。在2001年我提出了一些軟件工程研究的成功範例，從軟件體系結構中繪製了大量的例子的草圖在科學的和工程的研究領域，能夠經過如下的特徵來識別他們的價值：
• 什麼樣的問題是「有興趣」的？
• 什麼樣的結果有助於回答這些問題，和什麼樣的研究方法能夠產生這些結果？
• 什麼樣的證據能夠證實結果的有效性，以及如何有良好的效果來區分優劣？
在本文中，我試圖經過在軟件工程領域中廣泛能夠接受的研究策略，以肯定哪些研究是在實踐中被普遍接受的。。（尋找一套如何解決軟件開發過程當中行之有效的策略，研究人員首先從學校課堂上經過工程類的思想出發，積極探究軟件開發過程當中特色，逐步造成軟件工程的全面的關係圖。---譯者注）操作系統

1.一、軟件技術日趨成熟
Redwine和Riddle驗證了一些軟件技術，看看它們是如何發展和繁衍的。他們發現，軟件技術從概念制定到推廣的準備一般須要15-20年的發展。他們肯定了六個典型階段：設計

• 基礎研究 審視基本思路和理念，從初始結構上尋找問題，研究軟件框架重要的問題。

• 概念造成 從非正式想法，發展成一個研究團體，彙集一組兼容的想法，發佈具體的子解決方案。

• 發展和延伸 初步使用的技術，明確基本思路，歸納的方法。

• 內部提高和探索 擴展到另外一個領域方法，使用技術的實際問題，穩定技術，開發培訓材料，顯示在結果中的價值。

• 外部加強和探索 相似的內部，但涉及更普遍的社區的人但他們不是開發者，展現大量證據的價值和適用性。

• 推而廣之 開發生產，確保質量，版本的技術支持，商業化和市場技術，擴大的用戶羣體。

Redwine和Riddle羅列出20世紀80年代中期幾個軟件技術進展階段的時間表。我也提出了一個20世紀90年代成熟的軟件體系結構相似的分析。

這裏，咱們的興趣是在最初的3個階段，即研究階段。軟件工程研究的目的是幫助提升軟件開發的實踐性，所以研究計劃應規定過渡。 Redwine - Riddle數據代表，花費約15-20年中的10年用來進化概念成型與發展和推廣（更多的時間都用在基礎研究，但它是很是困難的，以肯定這一階段的開始）。所以，充分了解研究戰略必須考慮到隨着時間的推移積累的證據，以及個別項目和論文的形式和內容。

影響項目提供了從研究到實踐路徑的跟蹤軌跡。該項目的目的包括識別所作貢獻的類型，所起到實質性影響和成功研究的類型。目前正在會議上討論了初步取得結果。

1.二、軟件工程及相關研究前期的反思

關於軟件工程的研究，但不限於此，包括對實驗的研究。此外，它相似於在某些方面，好比像在人機交互的研究。

W. F. Tichy

Professor of Computer Science, Karlsruhe Institute of Technology Software engineering - parallelism - empirical software engineering - configuration management - software architecture

1.2.一、對實驗性軟件工程的批判

在1993年，Basili提出了軟件工程實驗研究範式的方法。後來，Tichy和他的同事在會議論文報告中批評了缺少定量驗證的實驗：「計算機科學家們不多發表有實驗驗證結果的論文，。。。論文低比率有驗證結果彷佛是計算機科學研究的一個嚴重的弱點。這種弱點必須糾正。」

根據論文的貢獻程度，他們在計算機科學分類出246篇論文進行比較，其餘兩個學科的有147篇論文。大多數的論文（259/403）都是說起設計和建模的結果。然而，他們肯定每一篇論文它的結果評定，基於文章文字的一小部分對評估的貢獻。他們發現，例如，在全部樣本中假設檢驗是罕見的，很大一部分（43％）計算機科學的設計和建模論文，而沒有任何實驗的評估，比通常計算機科學，軟件工程樣品就更糟了。

Marvin V Zelkowitz Delores Wallace Victor R. Basili

Zelkowitz和Wallace架構了關於Basili實驗範式的描述並評估了600篇計算機科學論文，和從其餘學科出版超過10年時間的100餘篇論文。他們一樣發現，過多篇論文沒有實驗的驗證或僅是非正式的實驗驗證，雖然他們也注意到在他們的研究中所涵蓋的10年期間取得了一些進展。

以這些批評爲前提，軟件工程研究應遵循經典的實驗範式。下面是筆者探索一個不一樣的問題：軟件工程研究在這個領域中如何認識高質量的特色是什麼？（大量文獻代表，從已有的計算機科學，或軟件工程學科的論文缺乏實驗性的內容，定性的內容較多，而定量的成分少些。這可能與專業或學科特色有關，軟件系統能夠有模型，固然模型的種類隨着軟件技術的發展和進化也發生屢次變化；而開發的過程很難用實質性的指標，由於都是跟人打交道的，關於人員的量化，工做量化，以及進度等方面量化，雖然有些量化指標，可是若是與其它工程類相比較，相差許多。---譯者注）

Willian Newman

Consultant, Professional Speaker, Writer, and Author - Mr. Newman brings over 25 years of experience in strategy and IT planning across multiple industry sectors. He is a Certified Management Consultant (CMC) since 1995 and has led consulting practices at several tier-1 strategy firms and global systems integrators. He is a former executive of Volkswagen of America's IT division.

1.2.二、用摘要預估的方法來研究分析

在工程的研究方面，Newman經過人機交互（HCI）的方式進行比較性研究。他認爲工程的特色就是實踐，肯定了三種主要類型的研究成果，並在5個工程領域進行了初步調查並提出研究報告。他發現，超過90％的貢獻是三種：

l 加強型建模分析技術，基於相關理論，能夠用來判斷設計方案是否可行，或預測性能是否可行;

l 加強型解決方案，克服不相溶性方面的問題，或者說是更容易與現有的模擬技術分析;

l 加強型工具和方法，應用分析模型和在建構功能的模型或原型。

Newman建立了用摘要預評估的方法 - 風格化的模板摘要都會捕獲到論文的本質 – 每一篇論文對這些類型的貢獻。例如，摘要預評估方法爲加強的建模技術是「現有<模型類型>模型在處理<求解策略>是<特性>上是有缺少的。一種加強型<模型-類型>的描述，可以提供更準確的分析/預測的設計在<求解策略>的<特性>。
模型進行了測試，經過比較分析/預測與經驗的<特性>測量值。「他發現，以佔可比部分的HCI文學，他須要兩個以上的範本，爲「激進的解決方案」，「經驗和/或啓發式」。

據紐曼報告，除了能幫助你識別一份論文肯定是什麼樣的研究報告之外，同時摘要評估方法還幫你注意力集中閱讀論文。這彷佛是合理的假設，若是做者是典型的論文類型更加自覺地意識到，他們會發現它更容易寫論文，介紹了他們的結果和證據清楚。經過摘要評估方法文件特徵的方法也可用於軟件工程，但更有表現力的描述性模型（以下文所述）提供了更好的匹配文件。

Frederick P．Brooks，Jr．
Pro.Frederick P．Brooks，Jr．曾榮獲美國計算機領域最具聲望的圖靈獎(A．M．TURING AWARD)桂冠。美國計算機協會(ACM)稱讚他「對計算機體系結構、操做系統和軟件工程做出了里程碑式的貢獻」。

1.2.三、開闊的研究視野

Brooks的報告顯示了人機交互之間分歧（tension）的研究

l 「狹隘的真理，證實了使人信服的可靠的統計實驗，並

l 普遍的「真理」，廣泛的適用，但僅支持可能不具表明性的意見」。

前者知足科學的黃金標準，但不多，相比設計師們天天的決定而言較狹隘。後者提供了務實的指導，但可能有過分概況的風險。

布魯克斯建議，經過肯定性殼的結構以紓緩緊張- 認識到三個嵌套類的結果：

• 結果：信譽卓著的科學真理，真實性和嚴謹性的判斷;

• 觀察：報告實際現象，趣味性的判斷;
• 經驗法則：由做者簽署的歸納，但可能不徹底支持的，判斷與做爲標準的全部三個新鮮有用的數據。

這種緊張是真正的軟件工程中人機交互的關係。

當發現出現問題的時候，觀察和經驗法則提供了寶貴的意見和實踐指導。他們還有助於理解和領域的研究奠基了基礎，時間，產生的調查結果。

二、軟件工程中的問題，結果和驗證
通常來講，軟件工程研究人員尋求更好的方式來開發和評估軟件。他們的動機來源於實際問題，研究的主要目標每每是軟件產品的質量，成本和時效性。

本節提出了一個模型，解釋了軟件工程的研究論文的研究，他們所問的問題，所產生結果的類型，以及他們所提供的驗證特徵類型的分類。這種模式已經發展了好幾年。這是一份完善的版本，是一份我基於2001年ICSE，2002年ICSE會議，經研究生課堂和提出摘要的屢次討論結晶。它的狀態是，在布魯克斯的意義上說，一組觀察，或許成爲了一種歸納。

2.一、研究問題的類型

研究問題多是有關的軟件開發方法，關於方法的分析軟件，有關的具體制度的設計，評估，實施，約歸納整個系統類，或純粹的可行性的任務。表1顯示了研究問題的類型的軟件工程師要求，再加上一些例子，具體的典型問題。

在ICSE提交的論文中，最多見的論文類型是一種軟件開發的一個改善方法或手段。另外比較常見的論文是關於方法進行分析，主要分析的正確性（測試和驗證）。回顧軟件工程過去的歷史，有一些跡象代表，由於該領域日趨成熟，問題的類型也在改變。例如，通常化，特別是在更正式的模型的形式上，變得愈來愈普遍，隨着該領域的日趨成熟，可行性論文彷佛變得不那麼常見。

表1 軟件工程研究的問題

問題的類型	實例
分析方法或手段	咱們該如何生成/建立（或自動）這個X？有什麼更好的方式生成/建立這個X？
分析方法	我如何評估X軟件的質量/正確性？我該如何在X和Y之間作出選擇？
設計，評估或分析的特定實例	什麼是X應用程序（更好的）設計或實施？ Y的什麼工藝品/方法是X的屬性？ X如何與Y比較？ X的什麼當前狀態/實踐Y？
通常性與特殊性	給出X，Y（必定）是什麼？到底是什麼，咱們的意思是X？ X有哪些重要特色？對於X而言，什麼是一個很好的正式/經驗模型？什麼是X，它如何相連？
可行性	若是x存在，是什麼樣子的？是否有可能完成X？

2.2 研究結果的類型

研究產生新知識。這種知識是一種特殊的結果的表達形式。這個結果多是一種特殊的程序或軟件開發或軟件分析的技術。從更普遍的意義上來講，捕捉一種模型上必定數量的特殊結果；這種模型在精度上和格式上產生許多層級。有時，這種結果能解決一個特殊的問題或克服一種特殊的分析。最後，根據Brooks調查，觀察和經驗法則，多是很好的初步結果。表二列出了這些類型，收集了一些特殊典型問題舉例。

到目前爲止，最多見的一種ICSE論文報告了一個新的程序或軟件開發或分析技術。它能夠描述敘述，或它能夠具體表達一個工具。分析性模型和描述性模型也很常見，分析模型的支持預測分析，而描述性模型解釋問題區域的結構或暴露重要的設計決策。經驗模型不可能產生良好的統計數據備份。

表2、軟件工程中的研究結果

問題類型	舉例
程序或技術	新的或更好的方法完成一些任務，如設計，實施，測試，評價，選擇中的取捨，包括操做技術實施，表達，管理和分析，但不建議或指引
經驗模型	基於觀察數據的經驗模型
分析模型	結構模型精確到足以支持正式分析或自動操做
符號或工具	正式的語言以支持實施技術或模式（應該有一個微積分，語義，或其餘基礎計算或推理）的工具，它體現了一種技術
具體的解決方案	解決應用問題，演示瞭如何使用軟件工程的原則 - 多是設計，而不是實現一個系統或運行系統的發展體現告終果的仔細分析，它多是載體的結果，或它的實施能夠說明一個原則能夠適用於其餘地方
回答或判斷	具體分析，評估，或比較結果
報告	有趣的觀察，經驗法則

2.三、研究驗證的類型
良好的研究不只要有好的結果，並且結果也應該是明確的和證據的使人信服的。這種證據，應是根據經驗或系統的分析，而不是簡單的有說服力的論據或課本上的例子。表3顯示了一些常見類型的驗證，驗證在實踐中並不老是很清楚和使人信服的。

Table 3. Validation techniques in software engineering

驗證的類型	舉例
分析	我分析個人結果，並經過正常分析）找到滿意的嚴格推導和證實（經驗模型）控制使用精心設計的統計實驗（控制）實驗數據
經驗	個人研究結果用到真實的案例中去，可被其餘人用得比我還多，驗證它的正確性/有用/有效性的證據是…定性模型）… 敘述（經驗模型，數據，一般的統計在實踐中（符號，工具）比較相似的結果在技術，實際用途
舉例	下面是一個例子，它是如何工做（玩具爲例）的玩具，也許是出於現實（生活片）......我一直在開發一個系統。
評估	鑑於標準的規定，個人結果... （描述性模型）...充分描述的現象（定性模型）佔感興趣的現象... （經驗模型）是可以預測......由於......，或使結果符合實際的數據... 包括可行性研究，試點項目
勸導	我想很難過這個問題，我相信... （技術）...若是你作了下面的方法，... （系統）構成的系統像這樣... （模型），這種模式彷佛是合理的須要注意的是，若是原來的問題是，一個工做系統的可行性，甚至不加分析，能夠有說服力的
公然斷言	沒有嚴重的嘗試評估結果

三、對策研究

本文第二小節羅列出了以報告形式在表明性會議上或期刊論文中我的研究結果的三個重要方面。很顯然，良好的科學研究策略範圍包括計算機科學意義上的實驗，它也一樣清晰地勾勒出更普遍意義上的關於對實驗的研究。固然，它不包含對全部問題，結果，和驗證的組合的理解。檢查表1-3顯示了有意義的組合。持續報告所接受的策略，而不是設定一個規定的標準，在本節中，我觀察和評論了出如今一些文獻中報告的模式。

3.一、建立研究對策

在軟件工程中最多見的研究策略，經常是經過想出一個新的過程（步驟）或技術分析或討論它使用和驗證的案例；在實際應用中使用案例是引人注目的莫過於使用理想化問題的例子，解決了某些軟件開發方面的問題。

另外一種常見的研究策略提供了一種分析方法來分析一些軟件開發方面，每每是正式的，模型並驗證，經過其使用的正式分析或它的經驗。
表4顯示了策略，有40篇研究論文收錄在ICSE2002年的摘要。有些論文是不包括在內，由於策略從摘要看不是明確。
這些描述符合紐曼的預覽摘要。這些模板識別兼容的問題，結果，驗證集。例如，第1.2.2節中所引述的「加強模式」對應的泛化或特性的問題回答的分析或實證（或精確的描述）模型，經過實證分析或控制的實驗驗證。經過幾種選擇打包在一塊兒，命名的集合，紐曼清楚地標識選定的策略。然而，嘗試將其應用到軟件工程文獻中發現缺點的覆蓋面。

3.二、從優秀論文中創建良好的結果

咱們這裏討論的主意集中在我的會議報告和期刊論文的結果中。然而，隨着時間的推移，取得的主要成果連續得到的可信度的結果逐步獲得改善，進一步加強了可信度。評估軟件工程結果的重要性應該在大背景下進行。

隨着進展狀況出現的增加，他們提供了保證持續投資於研究會獲得回報。所以，在某個領域的初次報告中提交的探索性研究的有說服力的案例能夠是非正式的和定性的，然後期遞交的報告中要驗證大規模的投資後，要有經驗和要有正式模型。這種增加模式符合Redwine-Riddle所提出的技術成熟模式。這裏提出的模型不解決這個累積創建信任。
表4中。 ICSE2002年的基礎上提交的摘要的研究策略

問題	結果	確認	計數
開發方法	程序	分析	3
開發方法	程序	經驗	4
開發方法	程序	案例	7
開發方法	定性模型	經驗	2
開發方法	定性模型	說服	1
開發方法	分析模型	經驗	3
開發方法	符號或工具	分析	1
開發方法	符號或工具	經驗	1
開發方法	符號或工具	案例	2
分析方法	程序	分析	1
分析方法	程序	經驗	3
分析方法	程序	案例	2
分析方法	分析模型	經驗	1
分析方法	分析模型	案例	1
分析方法	分析模型	案例	2
分析方法	工具	分析	1
實例評估	特性分析	分析	3
實例評估	特性分析	案例	1
實例評估	答覆	分析	1