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 团队编写；题目与流程为原创，并非任何学校或出版社的教材。