软件工程第三次作业

项目	内容
姓名 学号	102401206 吴怡霏　102401213 薛锦荣
这个作业属于哪个课程	H202601 软件工程与软件工程实践
这个作业要求在哪里	2026秋软件工程个人作业(第三次)
原型链接	校园失物招领小程序
代码仓库	school-things-find

本文作者：吴怡霏 102401206

一、客户的困扰与主要用户

校园里丢东西是高频事件——校园卡、钥匙、水杯、雨伞、耳机、教材都很常见。大家现在习惯在班级群、宿舍群、朋友圈里发消息，但这套办法有三个绕不开的问题：信息分散（各群互不相通，教学楼里捡到校园卡的同学发了招领，失主未必看得到）、容易被刷掉（群消息更新太快，昨天发的寻物今天已经翻不到）、没有统一搜索（想找"校园卡"只能一条条翻聊天记录）。

主要用户有三类：失主要发布寻物、搜索是否有人拾到、联系拾主；拾主要发布招领、确认身份、联系失主；浏览者想随手看看有没有自己丢的东西。三类人的诉求可以归纳成一句话：把信息集中起来，按物品名称就能搜到，并且能看出东西现在是什么状态。

二、解决方案与主要功能

软件的核心思路是：用"集中发布 + 关键词搜索 + 状态管理"替代分散的群消息。

功能	说明	优先级
浏览信息	首页按时间倒序展示，可切换全部 / 寻物 / 招领	必须
发布寻物	填写物品名称、分类、地点、时间、描述、联系方式	必须
发布招领	同上，字段语义变为"拾取地点 / 拾取时间"	必须
搜索物品	按物品名称、分类、地点搜索，可加类型与时间筛选	必须
查看详情	展示物品图、描述、地点时间、联系人、联系方式	必须
修改状态	发布者可标记"已找到 / 已归还"	必须
我的发布	管理自己发布过的信息	应该
收藏	详情页收藏，在"我的"里统一查看	可以

其中修改状态是关键：物品找到后标记为已解决，避免继续被同学打扰。

三、基本使用流程

flowchart LR A[进入首页] --> B[浏览或按关键词搜索] B --> C[查看物品详情] C --> D[查看联系方式] D --> E[联系发布者] E --> F[线下归还或找回] F --> G[发布者标记为已解决]

发布流程与"一次讨论"的最终流程图见第五节

四、原型设计

要求的四个页面（首页、发布信息页、搜索页、信息详情页）全部实现，另加"发布成功页"和"我的"，共 6 个页面。

主要设计考虑

• 首页：搜索框放在最显眼处，下方用“全部 / 寻物 / 招领”过滤；卡片用橙红、绿两种标签区分寻物与招领，不点进详情也能判断是否和自己有关。

• 发布信息页：第一步先选“我丢了东西 / 我捡到东西”，决定后面填的是“丢失地点”还是“拾取地点”；必填项标红星。

• 搜索页：输入关键词回车即出结果，另有热门搜索词与类型 / 时间筛选；无结果时给出空状态提示。

• 信息详情页：联系方式中间四位打码，兼顾联系需要与隐私；底部固定“联系 TA”按钮。

• 我的：分“我的发布 / 我的收藏”，每条信息可一键标记状态。

关于原型工具：本次使用 HTML + CSS 手写的高保真交互原型。好处是交互是真的——筛选、搜索、收藏、发布、状态修改都会真正改变数据；单文件，可直接用 GitHub Pages 生成在线链接。

五、结对过程

5.1 分工

我们采用每个阶段一人主导、另一人评审的方式结对，避免出现一边忙一边闲：

成员	角色	具体工作
薛锦荣 102401213	项目经理 / 需求与文档	拆解客户困扰，整理用户需求与功能清单，绘制流程图，维护 GitHub 仓库，撰写博客与 PSP 表
吴怡霏 102401206	UI/UX 与原型、测试	确定页面结构与视觉规范，制作原型，截图，以普通用户视角走查每一条流程

5.2 讨论过程

我们没有反复开会，而是走了一次"分头准备 → 汇总意见 → 二次审查 → 定稿"的完整流程：

• 第一步：各自搜集资料

两人分头准备。薛锦荣负责梳理客户描述，把三段话拆成 4 条痛点和 3 类用户，并列出功能设想；吴怡霏负责查同类失物招领小程序的界面，整理出配色、标签、卡片布局等视觉规范。

• 第二步：汇总意见（出现分歧）

把各自的成果摆到一起后，两人从不同角度提出了几乎相反的意见：

1. 薛锦荣（偏功能完整）：为了"联系更方便、找起来更准"，建议加入站内即时聊天（不用暴露手机号）、地图标记丢失位置（校园很大，光写"三教 201"不够）和实名认证（保证信息可信）。

2. 吴怡霏（偏简单可用）：担心页面一多用户根本用不下去；本次作业重点是原型设计，功能一旦膨胀，第二次结对编程就做不完了。主张把"联系发布者"简化为展示联系方式，地点用文字描述解决。

• 第三步：二次审查与修改

分歧没有靠互相说服解决，而是各自回去对照作业要求复查，再碰头修改。复查后达成四点一致：

砍掉即时聊天、地图定位、实名认证——作业明确不要求，还会拖垮第二次结对编程；
"联系发布者"改为详情页展示联系方式（中间四位打码，兼顾联系与隐私），线下自行联系；
补上最初遗漏的发布流程和"物品找到之后怎么办"的状态处理；
按"必须 / 应该 / 可以"给 8 条功能排定优先级。

• 第四步：得到最终意见

最终确了上述 6 个页面与下面的流程图，并定下 5.1 的分工，约定所有产出必须经对方 Review 才能提交。

flowchart LR A[进入首页] --> B[浏览或按关键词搜索] B --> C[查看物品详情] C --> D[查看联系方式] D --> E[电话或微信联系发布者] E --> F[线下归还或找回] F --> G[发布者标记为已解决] H[点击发布] --> I[选择寻物或招领] I --> J[填写物品信息并发布] J --> K[发布成功] K --> G

5.3 具体做了什么

需求侧（薛锦荣）：把客户描述拆成 4 条痛点与 3 类用户，整理出 8 条功能并按“必须 / 应该 / 可以”排优先级；画了两版流程图；建立 GitHub 仓库，把原型和文档推上去，并开启 GitHub Pages 生成在线链接。

原型侧（吴怡霏）：先定下配色（主色蓝，寻物橙红、招领绿）与卡片布局，再逐页实现——首页的分类过滤、搜索页的关键词过滤与筛选、详情页的信息展示与收藏、发布页的表单与类型联动、我的页面的状态标记；随后逐条走查，提出“发布入口由两个合并为一个”“卡片上要能看到地点和时间”等修改意见并完成修改。

共同完成：三次需求讨论与功能取舍、三条基本流程的走查验证（查看信息 → 查看详情、搜索物品 → 查看结果、发布信息 → 发布成功）、博客互审。

六、结合《构建之法》的学习与运用

按作业要求阅读《构建之法》第 3 章与第 8 章之后，我们在三个地方直接改了做法：

1. 结对合作：把"复审"变成固定动作（第 3 章）

书里强调两人合作要把复审（Review）当作制度而不是靠自觉。我们据此约定"任何产出必须经对方 Review 才能提交"，并用 GitHub 的 Pull Request 落实——谁改了什么、对方有没有看过，仓库记录里一目了然。汇总意见出现分歧时，我们也没有"各让一步"就完事，而是各自回去查作业要求再回来对，这比单纯互相说服有效得多。

2. 需求分析：先分清"想要的"和"该做的"（第 8 章）

书里讲需求分析要把用户模糊的描述转化成分层的功能清单，并排定优先级。我们据此把客户的三段话拆成 4 条痛点、3 类用户，再把 8 条功能按"必须 / 应该 / 可以"排序。正是这个排序让"即时聊天""地图定位"这类"想要但不必做"的功能被果断砍掉——需求分析的价值有一半在于明确不做什么。

3. 原型设计：用"典型场景"反推界面

书里建议用典型用户 + 典型场景来驱动设计，而不是拍脑袋画页面。我们给三类用户各设了一个具体场景（失主在教学楼丢了校园卡、拾主在食堂捡到雨伞……），再逐个走查："在这个场景下，他要几步才能完成目标？"卡片上补地点和时间、发布入口由两个合并成一个，都是这样走查之后改的。

七、PSP 表格

阶段	预估耗时	实际耗时
需求分析	2h	0.5h
流程图设计	1h	1h
原型设计	4h	3h
评审与修改	1h	1h
博客撰写	2h	2h
个人总结	0.5h	0.5h
合计	10.5h	8h

八、个人总结

吴怡霏 102401206

我主要负责原型设计与流程走查，这次最大的感受是："能用"和"看起来清楚"是两回事。

原型做出来之后我自己走了一遍流程，发现首页卡片如果只写物品名称，用户根本判断不出是不是自己丢的那个，于是补上了地点、时间和"寻物 / 招领"标签，用橙红和绿色区分——不点进详情也能快速筛掉无关信息，这是我觉得最有用的一处改动。《构建之法》里讲要用"典型用户 + 典型场景"驱动设计，我们后来就是照这个思路走查的：给三类用户各设一个具体场景，再问自己"在这个场景下他要几步才能完成目标"，发布入口由两个合并成一个、搜索无结果时要给空状态提示，都是这样查出来的。

遇到的问题也有两个。 一是最初把发布做成两个独立入口（发布寻物 / 发布招领），走查时发现用户得先想清楚点哪个，比较别扭，后来改成"一个入口、第一步二选一"；二是配色一开始用了很多种颜色，页面显得很乱，最后收敛到蓝色主色加两种状态色。

做原型还让我第一次体会到"原型不是画得好看就行"。 交互能不能走通、异常情况有没有反馈（搜索没结果、发布没填名称），这些细节才是用户真正会遇到的。另外这次我们完整用了 GitHub 的分支和 PR 流程来协作，比互相传文件清楚很多。