為什麼你需要學研究方法？

研究方法 | 教學備課 | 補充教材

大多數人會在大學時期學到「研究方法」這門課程，尤其是理工科可以說是必學課程。

但課程完成後呢？或是畢業之後沒有在求學了呢？大概就不會用到這個東西了...

但在我看來這卻是非常重要、甚至可以說是你學習的路徑指引圖。這也是為什麼我要教高中生「研究方法」這件事。

（但高中其實有開「探究與實作」課程，就是教類似的事情...）

這一篇，我先不講「研究方法」要怎麼學、怎麼做，我想先來聊聊：

• 為什麼學？
• 怎麼學？
• 可以參照什麼方法學？

我認為這些是最重要的事情！

📋 學習目標

看完後，希望你將能夠：

1. 說明「做研究」的本質，以及它和日常解決問題的關係
2. 點出研究常見失敗原因，並對應到軟體工程中的「軟體危機」
3. 解釋軟體工程是什麼、它和「會寫程式」有什麼不同
4. 列舉軟體工程的主要開發方法論（瀑布、V 模型、螺旋、Agile、TDD）
5. 說明為何 SDLC、V 模型與 TDD 可以作為研究方法的思考框架
6. 理解資安研究的本質，以及為何「學資安」需要研究能力
7. 預覽整套課程的架構與學習路徑

0.1 為什麼我們要做研究？

你有沒有遇過這樣的事：

有一天，你的手機剛好沒電了。你好不容易找了兩條充電線，一條是你的，另一條是同學的。但你的線怎麼插都沒反應，同學的線一插就開始充電。

這時，你心裡出現了一個問題：「為什麼我的線不能充電呢？」

或是你沒出現這個問題，只覺得「線壞了，扔掉吧」也可以。

但感覺你好有錢，還缺乾兒子嗎？ (^_−)−☆

然後你可能開始做一些嘗試：

• 換一個插座試試看
• 換另一個充電頭
• 把線的接頭拔下來重新插
• 用同學的線接你的充電頭

你在做什麼？你在「控制變因，一次改變一件事，看看結果是否不同」。

你在做研究。

---

研究，本質上就是對一個問題，系統性地尋找答案。

這個定義聽起來好像很廢話，但其中的「系統性」這兩個字是重要的關鍵。

以剛剛充電線的例子來說，你一次只換一個變因去找尋答案，想知道到底哪個環節出了差錯，這其實就蘊含著「系統性」的關鍵特性。但很多人面對更複雜的問題時，會同時做很多改變，即使問題解決了，也不知道是哪一個改變起了作用。

這就是為什麼我們需要研究方法：讓你的「找答案的過程」變得嚴謹、可靠、可以讓別人相信你的結論。

用遊戲來看「研究方法」

不知道你有沒有玩過一個經典的猜數字遊戲：1A2B。

簡單來說就是出題者心中想一個 4 位、每一個位數都不相同的數字，然後我們透過猜測時，出題者告訴我們這是幾個相同位置（A）或是存在在數字中但不在相同位置（B），來進行猜測。

計算方法例如：

$$\begin{array}{rl}& \begin{array}{rccccl}& 4& 0& 5& 9& \leftarrow \text{題目}\\ -)& 1& 0& 9& 6& \leftarrow \text{你猜的數字}\\ & \text{\_}& \text{A}& \text{B}& \text{\_}& \end{array}\\ & \Downarrow \\ & \text{1A 1B}\end{array}$$

遊戲進行時，通常會限制一定的次數進行猜測（不然就滿無聊的哈）

但初學者也可以不用這樣玩死自己啦！

現在問題是：我們要怎麼樣可以用最少的次數猜到數字？

你可能提出有很多方法，但你怎麼證明這些方法真的有效？

研究，就是在這樣。

對，我沒打算告訴你怎麼做，自己想 (・Д・)ノ

研究在哪裡？

研究不只存在於學術界。它存在於每一個需要「做出有根據的決策」的地方：

• 科學家研究新藥是否有效
• 工程師研究哪種材料最適合橋樑
• 資安研究員研究某個系統有沒有漏洞
• 政策制定者研究哪種政策能有效減少犯罪
• 你研究哪個科系適合你、哪個補習班值得花錢

📌 研究的本質

研究 = 用系統化的方法，對一個問題尋找有根據的答案

「有根據」意味著：你的結論不只是你的猜測，而是有資料、有邏輯支持的推論。

0.2 做研究很難嗎？

長話短說

做壞研究很容易，做好研究很難。

但「很難」不等於「不行」。只是需要學習正確的方法去進行。

以下舉個例子：

這是研究？

喝咖啡有助學習成績提升？

「我感覺喝咖啡有助於念書，因為我上次在咖啡廳念書考得不錯。」

關於這個「推論」有什麼問題？

如果是旁觀者，大家都會說：「啊！只有一次經驗，不算啦！」

沒錯，就是這種感覺！

• 只有一次經驗 --> 樣本太少
• 沒有考慮咖啡廳的環境、你的睡眠狀況、那次考試題目的難度
• 「考得不錯」怎麼定義？比平均高 1 分算嗎？ 10 分算嗎？
• 沒有對照組 --> 沒有咖啡的你，那次念書成果如何？

如果是我在帶的專題生，看到以上的問題他們通常已經不感到意外。這只是他們日常的「Challenging」。

但作為實際體驗的人，被問到以上問題時應該會想打人：「我就是覺得有差啊！ ｡ﾟヽ(ﾟ´Д`)ﾉﾟ」｡

但很抱歉，在科學研究中，個人經驗覺得有差異並不能代表任何事情。

而且，你怎麼能確定

真的有差？

變成是一個「研究」

如果你在說明「喝咖啡有助提升成績」這件事情時，改為這樣子進行：

「我找了 30 名高中生，隨機分配為喝咖啡組和喝安慰劑（假咖啡）組，控制環境、時間、和測試難度，讓他們在相同條件下完成 20 題閱讀測驗，比較兩組的分數差異，並以 t 檢定確認差異是否達到統計顯著水準。」

「哇賽..太麻煩了吧！？」

恩....我承認，連我都嫌麻煩 (*´ω`)人(´ω`*)

但你不覺得這樣子進行後你所得出的結論，比較難被人家說「哎呀，你這沒有什麼根據啦！」

我知道酸民會忽略，但是請忽略酸民 OK？

我在跟你正經八百的談研究方法呢！

以上兩個的差距，就是「有沒有使用研究方法」。

整如前面所說的：系統化、有根據，才能說服大家。

研究真的很難？

研究本身真的不難，難的是：

1. 克制直覺：你以為你知道答案，但真相可能相反
2. 控制混淆因素：影響結果的變因非常多，你必須系統性地排除
3. 誠實面對你不想看到的結果：這是大多數人最難做到的一件事

但這些都是技能，不是天賦。是可以藉由「學習」而學會的！

｡･ﾟ･(ﾉД`)ヽ(ﾟДﾟ )秀秀

0.3 為什麼都做不好研究？

這是研究方法中最核心的問題之一。但在講其他的事情之前，我們先來看常見的失敗原因：

研究的常見失敗模式

失敗模式	具體情境	根本原因
🔥 沒有定義清楚問題就開始做	「我想做關於環保的科展」→ 三個月後還在迷路	沒有進行「研究題目的分析」
🔥 不知道「什麼叫成功」	實驗做完了，不知道結果好不好	沒有事先定義標準
🔥 沒有控制變因	同時改變溫度和濃度，無法得出結論	實驗設計不嚴謹
🔥 做了很多，但沒有回答問題	洋洋灑灑 30 頁報告，但問題是「A 影響 B」，結論卻在討論 C	沒有聚焦、沒有確認、沒有驗證
🔥 先有結論，再找資料	想要證明「喝牛奶讓人長高」，只找支持這個說法的文章	確認偏誤（Confirmation Bias）
🔥 從不修改，死守原計畫	實驗失敗了也繼續，不考慮調整方法	缺乏迭代思維

你以為這些東西是個案？才不是呢！連 50 多年前的電腦工程師們就已經在被這些問題折磨了！

50 年前的折磨

1968 年，一群全球頂尖的電腦科學家聚集在德國 Garmisch，開了一場緊急會議。

那年，電腦數量正在爆炸性成長，但軟體、應用程式卻越來越失控——專案預算超支、延誤交付、做出來的東西根本不能用。這個狀況被他們稱為「軟體危機（Software Crisis）」。

這場會議後來被稱為「NATO 軟體工程大會」，它做了一件很重要的事：確立了「軟體工程（Software Engineering）」這個領域的存在，並宣告：

開發軟體不能只靠天才程式設計師的靈感，

必須要有系統化的方法進行。

因此，開始有大規模的研究、實證開始投入，發展出很多照著流程操作就能把專案好好做完的「方法學」，這也就是「軟體工程」最核心的特色：

關注如何好好把事情妥善、圓滿的完成。

研究也是一樣。

其實所謂「研究危機」一直存在：

• 全球每年發表的學術論文，有相當大比例無法被其他研究者重現（Replication Crisis）
• 很多科展報告的研究設計，存在根本性的邏輯問題
• 許多「發現」其實是確認偏誤的產物

所以...

軟體工程師用了 50 年，把軟體開發從「天才的靈感與頓悟」變成「可以被學習和管理的工程學科」。

現在，我們要借用他們的方法，把研究也做到一樣的程度。

0.4 軟體工程是什麼？

一個常見的誤解

很多人聽到「軟體工程師」，腦海中浮現的是：一個人在黑色螢幕前瘋狂打字，螢幕上滿滿的綠色程式碼在流動。

這個印象，大概只有 5% 是對的。

軟體工程的真實樣貌

軟體工程（Software Engineering） 是一個研究「如何系統化、有紀律地開發高品質軟體」的工程學科。

它關心的問題包括：

• 如何確認使用者真正需要什麼？
• 如何設計一個大型系統，讓它可以維護、可以擴展？
• 如何保證軟體沒有嚴重的錯誤？
• 如何讓一個由 100 人組成的團隊有效率地合作？
• 如何在有限的時間和預算內，交付符合要求的軟體？

📖 IEEE 的定義

IEEE（電機電子工程師學會）對軟體工程的官方定義（IEEE Std 610.12-1990）：

「將系統化、有紀律、可量化的方法，應用於軟體的開發、運作和維護的過程；以及對這些方法的研究。」

注意關鍵字：

系統化、有紀律、可量化

這三個詞，同樣是好的研究應該具備的特質。

軟體工程的誕生故事：1968 年的危機

讓我們回到 1968 年那場德國大會。

當時的軟體世界非常混亂。程式設計師們大多是天才，但他們通常是憑直覺寫程式，沒有說明文件、沒有建置計畫、沒有系統化處理。這在簡單的應用程式設計與實作上當然沒問題，但當一個系統可能就包含幾百萬行程式碼，單靠一個人的直覺是不夠的。

以下幾個典型的慘況：

• 一個系統耗費數年開發，完成後才發現根本不符合使用者需求
• 加一個新功能，結果壞掉三個舊功能
• 原本的設計師離職，新人看不懂舊程式碼，只好全部重寫

1968 年，NATO 召集了 50 位來自 11 個國家的頂尖電腦科學家：包括後來影響整個計算機科學的 Edsger Dijkstra、Peter Naur 等人，在德國 Garmisch 召開會議。

他們達成一個共識：

寫程式必須從「藝術」進化成「工程」

這就是「軟體工程」這個詞被正式確立的歷史時刻。

軟體工程和「寫程式」有什麼不同？

這個問題非常重要，也是很多初學者的盲點。

我們可以用「廚師」與「老闆」來作比較：

• 一個廚師（程式設計師）
  會做菜。他知道各種食材、烹飪技法，可以做出美味的料理。
• 一個餐廳老闆（軟體工程師）
  做菜只是一個可選技能。他主要需要
  • 知道市場上客人要什麼（需求分析）
  • 規劃廚房動線讓出餐效率最高（系統設計）
  • 管理廚師團隊確保出菜品質穩定（品質管理）
  • 制定食品安全標準確保沒有食安問題（測試與驗證）
  • 在客人抱怨時系統性地找出問題（除錯與維護）

維度	寫程式（Programming）	軟體工程（Software Engineering）
規模	個人專案	大型系統（多人協作）
重點	讓程式跑起來	讓系統可靠、可維護、可擴充
產出	程式碼	程式碼 + 文件 + 測試 + 流程
思維	解決眼前的問題	預防未來的問題
工具	程式語言、IDE	開發流程、版本控制、自動化測試、Code Review

為什麼這個區別對研究者很重要？

因為做研究也有類似的區分：

• 「做實驗」
  類似於「寫程式」：你有一個具體的技能，可以把實驗跑出來
• 「做研究」
  類似於「軟體工程」：你需要系統化地規劃整個研究流程，確保結果有意義、可重現、邏輯嚴謹

很多學生只會「做實驗」，卻不懂「做研究」。這門課，就是要彌補這個差距。

軟體工程有哪些方法？有哪些規範？

這個部分我們先建立一個宏觀的視野，後面的模組會深入每一個主題。

主要開發方法論

軟體工程發展了幾十年，產生了多種開發方法論。每一種方法論，都是對之前方法的一種改進或回應。

1. 瀑布模型（Waterfall Model，1970）

由 Winston Royce 在 1970 年的論文中提出五個階段，而且每個階段嚴格遵守上下游原則，不回流（所以被稱為「瀑布」）

雖然他本人認為它有問題，然後普遍的工程師也都覺得有問題。

需求 → 設計 → 實作 → 測試 → 維護

特色：階段嚴格順序，每個階段完成才進入下一個。 問題：現實世界的需求會變化，到了後期才發現前期錯誤，代價極高。

2. V 模型（V-Model，1979）

由 Barry Boehm 在 1979 年的論文中提出，以強調驗證（Verification）和確效（Validation）為核心。

• V 模型的核心思想：
  開發的每一個「左邊」階段，都對應一個「右邊」的測試階段。
  這就是 Verification（你做對了嗎？）和 Validation（你做的是對的事嗎？）的結構化體現。

V 模型與研究的關係

V 模型告訴我們：每一個設計決策，都必須有對應的「驗證方式」。

在研究中這意味著：每一個研究假設（左邊），都應該有對應的「驗證方法」（右邊）。你在設計研究的時候，就必須同時想好「怎麼知道這個假設是對還是錯」。

另外關於 Verification 及 Validation，剛好也應對著研究領域中會提到的「信度」與「效度」。

3. 螺旋模型（Spiral Model，1986）

由 Barry Boehm 在 1986 年提出，強調風險管理和迭代。

• 核心概念：
  把整個開發過程變成多個循環。每一個循環都包含：

  規劃 → 風險評估 → 工程實作 → 客戶評估

螺旋模型是第一個明確強調「先識別最大風險，再決定怎麼做」的開發方法。

4. 敏捷開發（Agile Development，2001）

2001 年，17 位軟體開發先驅在美國猶他州的雪鳥滑雪場聚會，共同簽署了《敏捷宣言（Agile Manifesto）》。

核心宣言（四個核心價值）：

• 個體與互動 勝過 流程與工具
• 可運作的軟體 勝過 詳盡的文件
• 與客戶協作 勝過 合約談判
• 回應變化 勝過 依循計畫

Agile 的精神：把整個開發周期縮短成 2 週的「Sprint（衝刺）」，快速交付可用的東西，從真實反饋中學習，不斷調整。

Scrum、Kanban 是 Agile 的主要實踐框架。

5. TDD（Test-Driven Development，測試驅動開發，2002）

由 Kent Beck 在其 2002 年著作中系統化闡述。

• 核心循環：

  Red（先寫一定會失敗的測試） 
    → Green（用最少行的程式碼讓測試通過）
        → Refactor（最佳化）

TDD 的革命性在於：他不是把「檢查、驗收」當作是一個最後的整理，而是當成「主要目標」。

除了方法，還有規範

軟體工程是有國際標準的。這些標準規範了「好的軟體開發應該是什麼樣子」：

標準	制定機構	主要內容
ISO/IEC 12207	ISO + IEC	軟體生命週期流程的國際標準
ISO/IEC 25010	ISO + IEC	軟體品質模型（功能性、可靠性、效率、安全性等）
IEEE Std 610.12	IEEE	軟體工程術語標準定義
IEEE Std 829	IEEE	軟體測試文件標準
CMMI	Carnegie Mellon SEI	軟體開發成熟度模型評估

這些標準跟我有什麼關係？

你不需要背這些標準的內容，但你應該知道它們的存在。

它們代表的是：世界上最頂尖的工程師，花了幾十年時間，把「什麼叫做做好一件複雜的事」提煉成可以被遵循的規範。

研究方法領域也有類似的「標準」：論文引用格式、科學報告結構（IMRaD）、統計顯著水準的慣例等，這些都是社群共同遵循的規範，讓每個研究者的工作可以被比較和評估。

---

0.5 軟體工程對研究的幫助

這是這篇文章最核心的問題。

先說結論：邏輯是一樣的！

問題的根源一樣

讓我們把「軟體危機」和「研究失敗」的共同問題並排來看：

軟體危機的問題（1968）	研究失敗的問題（至今）
需求不清楚就開始寫程式	問題不清楚就開始做實驗
沒有設計文件，邊做邊改	沒有研究計畫，實驗做到哪算哪
不測試，直到最後才發現問題	不驗證假設，實驗完了不知道代表什麼
系統做出來了，但客戶根本不要	實驗做完了，但沒有回答研究問題
一個人的離開導致整個系統崩潰	沒有文件和紀錄，別人無法重現研究

問題的結構是一模一樣的。所以解決的方法也可以借（ㄓㄠˋ）鑑（ㄔㄠ）。

以下，以及後續的文章，以這三個工具來作為框架：

• SDLC
• V-Model
• TDD

如何對應與應用？

SDLC（軟體開發生命週期）→ 研究流程框架

SDLC 把複雜的開發過程分成幾個清晰的階段，每個階段有明確的任務和產出。

後面會詳細介紹，打到這裡我手酸了...

(シ_ _)シ

研究流程也可以用同樣的方式結構化：問題定義 → 文獻回顧+研究設計 → 執行實驗 → 分析驗證 → 討論反思。

SDLC 提供的是：把「複雜的研究過程」拆解成可管理的步驟。

---

V 模型 → Verification & Validation 思維

V 模型的左邊（開發/計畫）對應研究的「設計階段」，右邊（測試/驗證）對應研究的「驗證階段」。

V 模型帶來了兩個關鍵問題：

• Verification（驗證）：
  你有按照計畫做嗎？（實驗步驟有沒有照著研究設計走？）
• Validation（確效）：
  你做的事情有回答你的問題嗎？（這個實驗真的能回答你的研究問題嗎？）

V 模型提供的是：確保研究「做對了」且「做了對的事」的雙重檢核思維。

---

TDD → 假設驅動研究（Hypothesis-Driven Research）

TDD 的 Red 階段（先寫測試）對應研究的「提出假設」：在開始做實驗之前，先定義清楚「什麼結果代表假設成立，什麼結果代表假設不成立」。

TDD 提供的是：在動手之前先定義「成功標準」的思維習慣。

三個工具的整合視圖

SDLC 是外層結構，V 模型是品質保證機制，TDD 是核心思維習慣。三者可以共同構成了一套嚴謹的研究邏輯系統。

0.6 後續的規劃

現在你已經了解了我要教的「研究方法」整體邏輯。

讓我們看看接下來的旅程：

每一篇基本上不是獨立的，但你想拆開來看也沒什麼問題。

不過我建議完整閱讀，因為它們構成了一個完整的知識鏈。

SDLC 是骨架，TDD 是核心思維習慣，V&V 是品質保證。

資料分析是推論工具，寫作是輸出，資安是應用場景。

---

動手做 0-A：找出你生活中的「研究問題」

IMPORTANT

以下全 AI 產生，沒有修改，請斟酌參閱。

對我想偷懶了 _(┐ ◟;ﾟдﾟ)ノ

📝 練習說明

時間：約 15 分鐘

目的：發現研究問題無所不在，打破「研究=學術」的誤解

任務： 在接下來 24 小時內，找出你生活中至少 3 個「讓你好奇的問題」，並嘗試回答以下問題：

生活中的好奇	這是研究問題嗎？	如何用研究方法回答它？
例：為什麼我打球的時候比較容易念書？	是的，這是「運動與學習效率」的問題	測量運動前後的記憶測驗分數，比較差異
你的問題 1：___
你的問題 2：___
你的問題 3：___

分享： 選一個你最感興趣的問題，想想看：用 SDLC 的「需求分析」來定義這個問題，你會怎麼寫？

---

動手做 0-B：軟體危機 vs. 你的研究危機

📝 練習說明

時間：約 20 分鐘

目的：把「軟體危機」的教訓對應到自己的研究習慣

任務： 下面是 1968 年軟體危機中常見的問題。試著為每一個找出你在做科展或作業時「犯過的類似錯誤」：

軟體危機問題	你的研究/作業經驗中的類似情況
需求不清楚就開始寫程式
沒有文件，別人看不懂你的程式
做出來的東西客戶根本不要
加一個功能，壞掉三個功能
測試留到最後，出問題才發現

反思問題：你認為這些問題，是「工程師個人的問題」，還是「開發流程沒有設計好的問題」？這個反思對你的研究有什麼啟示？

---

章節重點整理

📌 記住這六件事

1. 研究 = 系統性地對問題尋找有根據的答案
   「系統性」是關鍵詞，沒有方法的「研究」只是猜測。
2. 做不好研究的原因，和 1968 年「軟體危機」的原因幾乎一樣
   需求不清、沒有驗證、缺乏迭代思維。
3. 軟體工程 ≠ 寫程式
   它是「如何系統化開發高品質軟體」的工程學科，關心的是流程、品質和方法，而不只是程式碼。
4. SDLC（骨架）+ V 模型（品質保證）+ TDD（假設紀律）= 嚴謹研究的三層結構
   這三個工具的結合，可以解決大多數研究失敗的根本問題。

---

下一步之前的自我評量

在進入下一篇之前，試著回答以下問題（不需要寫出來，在腦海中想一想就好）：

• [ ] 你能說出「研究」和「查資料」的差別嗎？
• [ ] 你能說出軟體工程和「會寫程式」的三個差別嗎？
• [ ] 你能用一句話解釋 SDLC、V 模型和 TDD 各自的核心思想嗎？

如果這五個問題你都能回答，你已經準備好進入下一章節了！

參考文獻

1. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. Agile Alliance. https://agilemanifesto.org/
2. Beck, K. (2002). Test-driven development: By example. Addison-Wesley. ISBN 978-0-321-14653-3
3. Boehm, B. W. (1979). Guidelines for verifying and validating software requirements and design specifications. European Computing Conference.
4. Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72. https://doi.org/10.1109/2.59
5. Federal Bureau of Investigation. (2018, November 2). Morris worm 30 years since first major attack on internet. FBI News. https://www.fbi.gov/news/stories/morris-worm-30-years-since-first-major-attack-on-internet-110218
6. IEEE. (1990). IEEE standard glossary of software engineering terminology (IEEE Std 610.12-1990). Institute of Electrical and Electronics Engineers. https://doi.org/10.1109/IEEESTD.1990.101064
7. ISO/IEC. (2017). ISO/IEC 12207:2017 — Systems and software engineering — Software life cycle processes. International Organization for Standardization.
8. Naur, P., & Randell, B. (Eds.). (1969). Software engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 October 1968. Scientific Affairs Division, NATO. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF
9. Pressman, R. S., & Maxim, B. R. (2014). Software engineering: A practitioner's approach (8th ed.). McGraw-Hill Education.
10. Royce, W. W. (1987). Managing the development of large software systems: Concepts and techniques. Proceedings of the 9th International Conference on Software Engineering, 328–338. (Original work published 1970)
11. Sommerville, I. (2016). Software engineering (10th ed.). Pearson Education. ISBN 978-0-13-394303-0
12. Standish Group International. (1994). The CHAOS report. Standish Group.