软件工程第三次作业

软件工程第三次作业

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

本文作者：薛锦荣 102401213

---

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

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

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

二、解决方案与主要功能

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

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

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

三、基本使用流程

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

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

四、原型设计

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

主要设计考虑：

• 首页：搜索框放在最显眼处，下方用“全部 / 寻物 / 招领”过滤；卡片用橙红、绿两种标签区分寻物与招领，不点进详情也能判断是否和自己有关。
• 发布信息页：第一步先选“我丢了东西 / 我捡到东西”，决定后面填的是“丢失地点”还是“拾取地点”；必填项标红星。
• 搜索页：输入关键词回车即出结果，另有热门搜索词与类型 / 时间筛选；无结果时给出空状态提示。
• 信息详情页：联系方式中间四位打码，兼顾联系需要与隐私；底部固定“联系 TA”按钮。
• 我的：分“我的发布 / 我的收藏”，每条信息可一键标记状态。

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

五、结对过程

5.1 分工

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

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

5.2 讨论过程

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

第一步：各自搜集资料

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

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

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

• 薛锦荣（偏功能完整）：为了"联系更方便、找起来更准"，建议加入站内即时聊天（不用暴露手机号）、地图标记丢失位置（校园很大，光写"三教 201"不够）和实名认证（保证信息可信）。
• 吴怡霏（偏简单可用）：担心页面一多用户根本用不下去；本次作业重点是原型设计，功能一旦膨胀，第二次结对编程就做不完了。主张把"联系发布者"简化为展示联系方式，地点用文字描述解决。

第三步：二次审查与修改

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

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

八、个人总结

薛锦荣 102401213

这次结对作业我主要承担需求分析与文档撰写，也是我第一次把《构建之法》里的方法真正用到实际作业里。

最大的收获是理解了"需求分析不等于把客户的话抄一遍"。 客户只说"群消息容易被刷掉、找起来不方便"，我们要把它翻译成"集中发布 + 关键词搜索 + 状态管理"这样能设计、能实现的功能。书里讲需求要分层、要排优先级，我们据此把 8 条功能分成"必须 / 应该 / 可以"——正是这个排序让我敢砍掉"即时聊天""地图定位"这些听起来很吸引人的功能。需求分析的价值有一半在于明确不做什么。

遇到的问题主要有两个。 一是功能一开始列得太多，被同伴质疑"这个真做得完吗"，才意识到范围控制的重要；二是第一版流程图只画了"看信息"这一条路，把"发布"和"找到之后怎么办"漏掉了，二次审查时才补上。另外画流程图时我一开始想把所有分支都画进去，结果图复杂到没法看，后来只留主干才清楚——这也印证了书里说的"分而治之，逐步细化"。

这也是我第一次完整地用 GitHub 协作。 以前小组作业都是互相传文件，版本一多就分不清哪份最新；这次用分支和 Pull Request，谁改了什么、对方有没有 Review 过，记录里一目了然，正好对应书里讲的"把复审变成制度，而不是靠自觉"。