2.6 小型信息系统的组建
知识点
1.什么是"小型"信息系统
小型信息系统指规模小、用户少、功能相对单一、开发周期短的信息系统，通常服务一个班级、一个社团、一家小店或一个家庭。
判断标准（三条满足即可）：
- 用户规模——几十到几百人，不追求高并发；
- 功能范围——解决一个明确业务（借书、测温、点单），不追求大而全；
- 资源投入——一两人即可开发，用现成技术栈，成本低。
典型例子：班级图书借阅系统、教室环境监测系统、社团报名系统、小店点单系统、宿舍报修系统。
为什么要学"小型"系统：它是信息系统的完整缩影——需求、设计、数据库、编码、测试、部署、运维，一个环节都不少，只是规模缩小。学会了小型系统，大系统的框架是一样的。
2.开发的完整流程（七步，必背）
| 步骤 | 做什么 | 产出 |
|---|---|---|
| 1. 需求分析 | 搞清楚"给谁用、解决什么问题" | 需求清单、功能列表 |
| 2. 可行性分析 | 判断"能不能做、值不值得做" | 可行性结论 |
| 3. 方案设计 | 定架构、定技术、定数据库、画界面 | 系统方案、原型图 |
| 4. 开发实现 | 建库、写后端、做前端、接硬件 | 可运行的版本 |
| 5. 系统测试 | 验证功能对不对、能不能扛住 | 测试报告、缺陷清单 |
| 6. 部署上线 | 放到真实环境让别人用 | 可访问的地址 |
| 7. 运维与迭代 | 修问题、加功能、做备份 | 版本更新记录 |
一句话记法：要什么 → 能不能 → 怎么做 → 做出来 → 试试看 → 用起来 → 养下去。
最重要的经验：需求分析做不好，后面全在返工。这是所有项目的第一规律。
3.第一步：需求分析
要回答四个问题：
| 问题 | 说明 | 举例（班级图书借阅系统） |
|---|---|---|
| 谁用（用户角色） | 列出所有角色及权限 | 学生（借还、查询）、管理员（录入、统计） |
| 做什么（功能需求） | 每个角色要做哪些事 | 扫码借书、到期提醒、按书名搜索 |
| 什么要求（性能需求） | 速度、并发、容量、可用性 | 页面 2 秒内打开、支持 50 人同时用 |
| 什么限制（约束条件） | 预算、时间、技术、设备 | 两周完成、零预算、只能用学校机房 |
功能需求要写成"可验收"的句子：
- 差的写法："能管理图书"——太模糊，做完无法判断对错；
- 好的写法："管理员能录入图书（书名、作者、
ISBN、册数），学生能按书名或作者模糊搜索，借书后 30 天内未还将收到提醒"——明确、可测。
用户故事的常用句式：
"作为（某角色），我希望（做某事），以便（达成某目的）。"
例：作为学生，我希望按书名搜索图书，以便快速知道能不能借到。
4.第二步：可行性分析
| 维度 | 要判断什么 |
|---|---|
| 技术可行性 | 现有技术与人员能力能否实现 |
| 经济可行性 | 成本（设备、软件、人力）是否可接受 |
| 操作可行性 | 用户是否愿意用、会不会用 |
| 时间可行性 | 能否在规定周期内完成 |
| 法律与伦理可行性 | 是否涉及隐私、版权、数据合规问题 |
结论不一定是"做"——也可能"缩小范围做"或"用现成产品代替"。能判断"不该做"，也是一种能力。
小型项目最常踩的坑：功能贪多。先做"最小可用版本"（MVP）——只实现最核心的一条业务闭环，跑通后再加功能。
5.第三步：方案设计
（1）选架构：B/S 还是 C/S
| 对比 | B/S（浏览器／服务器） | C/S（客户端／服务器） |
|---|---|---|
| 安装 | 免安装，有浏览器就行 | 每台设备都要装客户端 |
| 升级 | 只改服务器，用户无感 | 客户端要逐台更新 |
| 跨平台 | 好（电脑手机都能用） | 差（要分别开发） |
| 性能与体验 | 一般 | 更好，能调用本地资源 |
| 适用 | 小型系统首选 | 专业软件、需硬件交互 |
结论：小型信息系统优先选 B/S，因为维护成本最低。
（2）划分功能模块（自顶向下）
以班级图书借阅系统为例：
| 模块 | 子功能 |
|---|---|
| 图书管理 | 录入、修改、下架、分类 |
| 借阅管理 | 借书、还书、续借、逾期计算 |
| 查询统计 | 按书名／作者搜索、借阅排行、逾期名单 |
| 用户管理 | 学生名册导入、权限分配 |
| 提醒通知 | 到期提醒、逾期通知 |
模块划分原则：高内聚、低耦合——一个模块内部的事紧密相关，模块之间尽量少依赖。这样改一个模块不至于牵连全局。
（3）设计数据库（第3单元会详细展开，这里先建表）
| 表名 | 主要字段 |
|---|---|
book | id、书名、作者、ISBN、册数、在架数 |
reader | id、学号、姓名、班级 |
borrow | id、图书id、学号、借出日期、应还日期、归还日期 |
设计要点：用 id 做主键，表之间用 id 关联，不要用"书名"当关联字段（书名会重复、会改）。
（4）画界面原型
用纸笔或原型工具画出主要页面：登录页、图书列表页、借阅页、统计页。先画再做，能省掉大量返工。
6.第四步：开发实现
（1）常见技术选型（小型系统够用就好）
| 层次 | 可选技术 | 说明 |
|---|---|---|
| 前端 | HTML＋CSS＋JavaScript、Bootstrap | 做页面与交互 |
| 后端 | Python Flask／Django、PHP、Node.js | 处理业务逻辑与接口 |
| 数据库 | SQLite（零配置、单文件）、MySQL | 小系统用 SQLite 足够 |
| 硬件 | 掌控板、Arduino、树莓派、USB 摄像头 | 采集现场数据 |
| 部署 | 校园服务器、云服务器、树莓派本地 | 看访问范围 |
选型原则：用自己最熟的，不用最时髦的；能跑起来比架构漂亮重要。
（2）后端的最小骨架（以 Flask 为例）
from flask import Flask, request, jsonify
app = Flask(__name__)
# 模拟数据存储，实际应写入数据库
books = []
@app.route("/api/books", methods=["GET"])
def list_books():
return jsonify(books)
@app.route("/api/books", methods=["POST"])
def add_book():
data = request.get_json()
books.append({"id": len(books) + 1, "name": data["name"]})
return jsonify({"ok": True})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=5000)
这段代码说明了三件事：
- 路由决定"访问哪个地址执行哪段代码"；
- 接口用
JSON传数据，前后端靠它对接； - 数据要落库——示例里的列表只是演示，真实系统必须写数据库，否则重启就丢。
（3）硬件接入（如果是物联网类系统）
采集端循环执行"读—判—传"：
import time
def loop():
while True:
value = read_sensor() # 读：采集数据
if value > 30: # 判：与阈值比较
upload(value, "alarm") # 传：上报并可触发告警
else:
upload(value, "normal")
time.sleep(60) # 每 60 秒一次
三个工程细节：
- 加异常捕获——传感器读不到时不能让程序崩掉；
- 加上报失败重试——网络不稳定是常态；
- 控制采集频率——太频繁耗电、占带宽，太稀疏会漏掉异常。
7.第五步：系统测试
测试不是"点几下看看"，而是有方法、有记录。
| 测试类型 | 目的 | 举例 |
|---|---|---|
| 功能测试 | 每个功能是否符合需求 | 借书后"在架数"是否减 1 |
| 边界测试 | 极端输入是否正常 | 借第 0 本、借超过馆藏数、空书名 |
| 异常测试 | 出错时是否优雅处理 | 断网、断电、数据库被占用 |
| 性能测试 | 多少人同时用会卡 | 50 人同时查询响应时间 |
| 兼容测试 | 不同设备能否正常用 | 手机、平板、电脑浏览器 |
| 安全测试 | 有无越权与注入风险 | 学生能否直接访问管理页面 |
测试用例的写法（四要素）：
| 要素 | 内容 |
|---|---|
| 前置条件 | 已登录为学生账号 |
| 操作步骤 | 搜索"Python"→ 点击"借阅" |
| 预期结果 | 提示借阅成功，在架数减 1 |
| 实际结果 | 与预期一致／不一致（记录缺陷） |
边界值举例（最能发现问题）：
- 借书数量上限是 3 本 → 测 2 本、3 本、4 本；
- 借期 30 天 → 测第 29 天、第 30 天、第 31 天；
- 输入框限 20 字 → 测 19 字、20 字、21 字。
8.第六步：部署上线
三种常见部署方式：
| 方式 | 适用 | 要点 |
|---|---|---|
| 本机运行 | 单人使用、演示 | 电脑关机即停，不能长期服务 |
| 校园服务器／机房主机 | 校内使用 | 需固定 IP、开机自启、定时备份 |
| 云服务器 | 校外也能访问 | 需配置安全组、域名、HTTPS |
上线的四个必做动作：
- 改掉默认口令，数据库不用空密码；
- 配置开机自启与进程守护（崩了能自动拉起）；
- 设置定时备份（数据库每天备份到另一块盘或云端）；
- 打开日志（谁访问了、报了什么错，都要留痕）。
部署 ≠ 完工：真正的考验从"别人开始用"那一刻开始。
9.第七步：运维与迭代
| 工作 | 内容 |
|---|---|
| 日常监控 | 服务是否在线、磁盘是否写满、有无异常报错 |
| 数据备份 | 定期备份并验证能否恢复（只备份不验证等于没备份） |
| 问题修复 | 收集用户反馈，按影响面排序处理 |
| 功能迭代 | 按"最小可用"原则小步增加 |
| 文档维护 | 更新使用说明、部署说明、数据库结构说明 |
版本管理建议：每次发布记录"改了什么、什么时候、谁改的"，出问题能快速回退。
用户培训常被忽略：系统再好，没人会用等于零。一份三页的图文操作说明，往往比多加三个功能更有价值。
10.完整案例：教室环境监测系统
（1）需求
- 每 5 分钟采集温度、湿度、光照；
- 教师可在网页查看当天曲线与实时值；
- 温度高于 30 ℃ 或湿度低于 30% 时在页面标红提醒。
（2）方案
| 项 | 选择 |
|---|---|
| 架构 | B/S |
| 采集端 | 掌控板＋温湿度传感器＋光敏传感器 |
| 通信 | 校园 Wi-Fi，MQTT 上报 |
| 后端 | Flask 接收数据并提供接口 |
| 数据库 | SQLite，表 env_data（时间、温度、湿度、光照） |
| 前端 | 网页表格＋折线图 |
（3）关键设计点
- 时间是主键的一部分——按时间查询是最高频操作，要建索引；
- 数据量估算——每 5 分钟一条，一天 288 条，一学期约 3 万条，
SQLite完全够用； - 阈值放在配置里，不写死在代码中，方便调整；
- 异常要留痕——传感器离线也记一条"缺测"，否则曲线会"骗人"。
（4）测试要点
- 拔掉传感器 → 页面应显示"离线"而不是显示上一次的旧值；
- 断电重启 → 应自动恢复上报；
- 把系统时间改错 → 检查数据时间是否正常（时间同步很重要）。
（5）价值
把"凭感觉"变成"看数据"：什么时候教室最闷、哪个时段光照不足、空调开到几点最合适——这些结论只有连续数据才能给出。
11.速查表
| 序号 | 考点 | 结论 |
|---|---|---|
| 1 | 小型系统判断标准 | 用户少、功能单一、周期短、成本低 |
| 2 | 开发七步 | 需求 → 可行 → 设计 → 开发 → 测试 → 部署 → 运维 |
| 3 | 最关键的一步 | 需求分析（做不好全返工） |
| 4 | 需求四问 | 谁用、做什么、什么要求、什么限制 |
| 5 | 需求写法要求 | 可验收，避免"能管理"这类模糊表述 |
| 6 | 可行性五维 | 技术、经济、操作、时间、法律伦理 |
| 7 | 最小可用版本 | MVP，先跑通核心闭环 |
| 8 | 小型系统首选架构 | B/S（免安装、易升级） |
| 9 | 模块划分原则 | 高内聚、低耦合 |
| 10 | 数据库关联字段 | 用 id 主键，不用名称 |
| 11 | 小系统数据库 | SQLite 足够 |
| 12 | 选型原则 | 用最熟的，不用最时髦的 |
| 13 | 接口数据格式 | JSON |
| 14 | 采集程序三动作 | 读 → 判 → 传 |
| 15 | 采集频率权衡 | 太频耗电占带宽，太疏漏异常 |
| 16 | 测试类型 | 功能、边界、异常、性能、兼容、安全 |
| 17 | 测试用例四要素 | 前置条件、步骤、预期结果、实际结果 |
| 18 | 最易发现问题的测试 | 边界值测试 |
| 19 | 上线必做 | 改口令、自启守护、定时备份、开日志 |
| 20 | 备份的关键 | 验证能否恢复 |
| 21 | 运维常被忽略 | 用户培训与操作文档 |
| 22 | 部署不等于完工 | 真正考验从用户使用开始 |
12.课堂提示（讲课参考）
- 本节的落点是"做一遍"，不是背流程。建议用 4~6 课时做一个真实小项目（班级图书借阅或教室测温），学生分组承担需求、数据库、后端、前端、测试五类角色，两周一迭代。
- "需求写不清楚"要现场演示后果：教师给出"做一个图书系统"这一句话，让三组学生各自理解并画出功能清单，结果必然各不相同——顺势讲"可验收的需求"怎么写。这个活动十分钟，效果极好。
B/S与C/S别讲架构图，讲"改一次功能要动几台机器"：B/S只改服务器，C/S要跑遍每台电脑升级。学生立刻明白为什么小系统选B/S。- 测试环节建议"互相找茬"：两组交换系统，各写 10 条测试用例去挑对方的错，包括边界值（借第 4 本、输 21 个字、把书名输成空格）。学生会发现"自己觉得没问题的功能，别人一试就崩"。
- 务必强调备份与日志：很多教学项目上线后数据一丢就全白做。让学生亲手做一次"删库→用备份恢复"的演练，比讲十遍"要备份"都管用。