DSE ICT｜系統開發生命週期與項目管理備課指引（導師用）｜六階段、瀑布對敏捷與四個常見錯誤

2026-11-05

學生背得出「分析、設計、實作、測試、推行、維護」，但一問邊個階段出錯最貴、敏捷同瀑布分別在邊，就答唔出。呢一堂用一個 120 工作日的項目把六個階段串起來，再用 1:10:100 講清楚為何要早測試。

本堂目標　學生能夠：① 畫出六個階段並講出每階段的交付物（可行性報告、系統設計書、程式、測試報告、訓練手冊、維護記錄）；② 用一個 120 工作日的項目分配各階段工期，並解釋瀑布與敏捷在交付節奏上的分別（5 個兩週 sprint 共 50 工作日）；③ 用測試案例數與缺陷率（48 個案例找出 6 個缺陷，即 12.5%）說明測試覆蓋，並用 1:10:100 的比例算出同一個缺陷在不同階段修復的成本差距。

01　先備知識（開課前 3 分鐘快檢）

以下任何一項未過關，本堂就會卡住，先補該項：

技能	快檢題	過關標準
系統與資訊系統	資訊系統由哪五個部分組成	硬件、軟件、數據、程序、人
數據庫基本概念	主鍵的作用是什麼	唯一識別每一行記錄
項目基本元素	一個項目最常見的三重限制是什麼	範圍、時間、成本

02　課堂流程（60 分鐘）

時間	環節	導師做什麼	學生做什麼
0–6 分	先備快檢	三題快問，重點問三重限制	口頭作答，錯的寫在黑板角落
6–20 分	六階段與交付物	畫出六階段並填上 120 工作日分配	學生自己填交付物一欄
20–34 分	瀑布對敏捷	比較兩種模式，計 5 個 sprint 的交付點	學生講出一個適用場景
34–48 分	測試與缺陷率	48 個案例、6 個缺陷，算覆蓋與密度	學生設計三條邊界測試
48–56 分	修復成本 1:10:100	3 個設計缺陷的成本由 3 升到 300	學生換算自己項目的人日
56–60 分	離場檢查	三題收回即批，標明跌在邊一幕	獨立完成

03　講解腳本（照著說就可以）

第一幕：第一幕：六個階段，每個階段都有交付物

開場要學生背六階段，通常個個都背得出，但一問「分析階段交什麼」就靜。所以第一幕的重點不是名單，是交付物：可行性研究交報告（技術、經濟、時間、法律四方面）、系統分析交需求規格、系統設計交設計書（含數據庫結構與介面）、實作交程式與單元測試、測試交測試報告與修正記錄、推行交訓練與轉換計劃、維護交更新記錄。
用一個 120 工作日的項目做分配：分析 10、設計 15、實作 40、測試 35、推行 12、維護 8 日，合共 120 日；四人團隊即 480 人日。要學生看出實作與測試佔七成時間，這就是「寫程式只是冰山一角」。
最常見誤解提示框：「維護是最短的階段」——錯，維護通常最長，因為系統上線之後要改幾年。

要學生複述：「六個階段，每個都有交付物；實作同測試佔最多時間。」

第二幕：第二幕：瀑布與敏捷的分別在交付節奏

第二幕講兩種開發模式。瀑布是一層一層落：需求 freeze 之後才設計，設計完成才寫程式，好處是文件齊、合約清晰，壞處是客戶要到最後才見到成品，一旦需求理解錯，改動成本極高。
敏捷則把項目切成短 sprint：5 個 sprint、每個 10 工作日，合共 50 工作日，每個 sprint 完都交出一個可用增量，客戶可以即時給回饋。要學生比較同一個項目：瀑布只在第 100 日左右才有東西看，敏捷在第 10 日就見到第一個可用版本。
然後講適用場景：需求穩定、法規要求嚴格（例如銀行核心系統）適合瀑布；需求會變、要快速試市場（例如手機 app）適合敏捷。要學生明白兩者不是「新舊」，是取捨。

要學生複述：「瀑布一次過交付，敏捷每個 sprint 交付；需求穩用瀑布，需求變用敏捷。」

第三幕：第三幕：測試與修復成本——越遲發現越貴

第三幕用數字講質量管理。48 個測試案例，執行後找到 6 個缺陷，缺陷率 12.5%，這不代表系統只餘下六個問題，而是「這組案例覆蓋到的範圍有六個」，所以要講覆蓋率與邊界值。教學生寫三類案例：正常值、邊界值、非法輸入；三類齊全才算測得過。
再講 1:10:100：同一個缺陷，設計階段修復成本 3 個單位，開發階段 30，上線後 300。3 個設計缺陷留到上線，就是 300 個單位，是原本的 100 倍。這條數解釋了為何要有設計評審與早期測試，不是為了程序員的面子。
最後把成本換成人日：若 1 個單位等於 0.5 人日，300 個單位就是 150 人日，比整個測試階段還要長。

要學生複述：「三類測試案例；越遲發現越貴，比例大約一比十比一百。」

04　必教題型與步驟

題型	例子	步驟	答案
階段與交付物	系統分析階段完成後應產出什麼	① 講階段目標 ② 對應交付物 ③ 說明誰簽收	需求規格書（功能與非功能需求）
工期分配	120 工作日項目怎樣分配到六階段	① 按比例 ② 合計等於總數 ③ 講風險緩衝	分析 10、設計 15、實作 40、測試 35、推行 12、維護 8 日
瀑布對敏捷	客戶需求常在開發途中改變，選哪種模式	① 講需求穩定度 ② 講交付節奏 ③ 講風險	敏捷，用短 sprint 換回饋
缺陷成本	3 個設計缺陷留到上線，成本是設計階段的幾倍	① 用 1:10:100 ② 對應階段 ③ 換算人日	100 倍（300 對 3）

合理性檢查（一定要教）：計完先問「合理嗎」：六階段加起來要等於 120 日，唔可以多過或少過；四人團隊 480 人日，若算出比 120 還少，就是忘了乘人數；缺陷率 12.5% 屬合理範圍，若算出 120% 就是案例與缺陷兩個數字調轉；修復成本一定是由左至右遞增，若上線後比設計階段便宜，就是比例寫反了。

05　獨立練習三題

題目	答案	想觀察什麼
寫出系統開發六個階段，並各舉一個交付物。	分析（需求規格）、設計（設計書）、實作（程式）、測試（測試報告）、推行（訓練手冊）、維護（更新記錄）	有無漏階段、交付物是否對應
120 工作日項目中實作與測試合共佔幾多百分比？	62.5%（75 日）	有無用兩階段相加再除總數
3 個設計缺陷留到上線才修，按 1:10:100 成本是多少個設計階段單位？	300 個單位（100 倍）	有無按階段乘比例、有無講出倍數

06　學生常見錯誤與糾正句

錯誤	學生通常這樣寫	導師這樣說
把維護當最短階段	答「維護一兩個月就完」	「系統用幾年，維護通常最長；你寫嘅程式只係起點。」
瀑布與敏捷當成新舊	答「敏捷一定好過瀑布」	「唔係新舊，係取捨：需求穩定、要審計就用瀑布；需求會變就用敏捷。」
測試只寫正常值	48 個案例全部用正常輸入	「冇邊界值同非法輸入，等於冇測過；三類都要有。」
缺陷率當成剩餘缺陷數	答「系統只剩 6 個 bug」	「呢個係案例覆蓋範圍內嘅發現數，唔係全系統剩餘數。」

07　家課建議（直接指到練習卷題號）

本章重做　重做練習三題（第 1–3 題），每題寫出所用階段與公式
ICT 科章節索引　揀「數據庫」一章，做卷內第 2 題並標出主鍵與外鍵
自製測試表　為一個登入功能寫九條測試案例：正常、邊界、非法各三條

08　離場檢查（最後 5 分鐘）

題目	答案	判定
六階段中哪個通常最長	維護	答實作＝重講第一幕
瀑布與敏捷最大分別	交付節奏：一次過對每個 sprint 交付	答「敏捷快啲」＝重講第二幕
1:10:100 講什麼	同一缺陷在設計、開發、上線後的修復成本比	答「測試比例」＝重講第三幕

09　導師常問

DSE 會考敏捷嗎？

課程以瀑布為主，但比較題常要求講出敏捷的好處，兩種都要識講。

可行性研究包括哪幾方面？

技術、經濟、時間（進度）、法律與運作可行性，答四項已足夠。

單元測試與系統測試分別？

單元測試針對個別模組由開發者做，系統測試針對整合後的整體由測試員做。

立即免費搵導師導師登記 →

本頁為 TutorZone 導師備課指引，內容由 TutorZone 團隊編寫；題目與流程為原創，並非任何學校或出版社的教材。