2026秋软件工程个人作业(第三次)
| 课程 | H202601软件工程与软件工程实践 |
|---|---|
| 作业要求 | 2026秋软件工程个人作业(第三次) |
| 作业目标 | 完成「校园失物招领小程序」需求分析和原型设计 |
| 学号姓名 | 102401231 赵紫龙、102401228 林彦翔 |
一、《构建之法》读后感
读完第三章,我认为真正有意思的是软件工程师的思维误区这一板块,前面的内容并没有过多引起我的关注。就好像很平常的道理拿出来讲,就比如怎么衡量初级软件工程师的成长,软件开发的工作量和质量该怎么衡量等这种问题,前者感觉主要就在说要不断学习,后者就是强调效率(re-work是好事吗,按时交付的重要性),就是看完感触不大,可能得我自己经历后才懂,所谓“人教人不会,事教人一次就会了”。对于软件工程师常见的思维误区这一块,看完后我认为,在开发软件的过程中,没必要弄清问题的所有细节和依赖关系,找到重要和次要的部分就可以开始动手操作了。有些次要的东西考虑的太多,反而会影响效率,且不值得投入那么多精力。这部分挺有意思的。
第八章主要就是讲需求分析,该怎么对用户的需求进行分析,才能开发出符合用户心理预期的软件,调研也是一种学问。第八章还提到开发过程中如何做好估计,这个对项目完成的时间进行估计,对用户没有提到的需求进行合理的估计和联想。需求的分析,本质也是为了提高开发效率。
总的来说,一个软件工程师的成长离不开持续地学习,提高自己的水平。同时要对软件的开发要先将用户的需求进行合理的分析(调研),理清主次,对完成的时间进行一个合理的估计,这样才能提高生产效率。
二、题目来源
校园里丢东西是很常见的事:校园卡、钥匙、水杯、雨伞、耳机、课本,几乎每个同学都丢过或者捡到过。
现在的做法是在班级群、宿舍群、朋友圈里发消息。问题有三个:一是分散,不同的人在不同的群里,看到的信息范围完全不同;二是很快被刷走,群聊消息一多,几天前的招领信息就翻不到了;三是没有"结束"机制,东西早就还回去了,消息还挂着,让人白高兴一场。
我们想做的"校园失物招领小程序",就是给学生一个统一的入口:寻物和招领信息集中放在一起,可以按关键词搜索,并且能标明信息当前是否还有效。
三、用户需求分析
主要用户有两类。 第一类是失主,丢了东西以后希望尽快找回,一方面自己发布寻物信息,另一方面主动去查有没有人捡到。第二类是拾获者,捡到东西后想尽快交给失主,但不愿意为了这件事花费太多精力,所以发布操作必须尽量短。
还有一类间接相关的角色是宿舍管理员和保卫处,他们经常收到同学送来的失物。不过这次作业不涉及线下交接流程,我们只把它当作背景,不设计专门的角色和功能。
用户真正的问题不是"没有功能",而是"信息找不到、也不敢信"。 由此我们整理出四条核心需求:
- 统一入口:打开小程序就能看到最近的寻物和招领信息,不需要先加入某个群。
- 能搜到:用户通常已经知道自己丢了什么,用"校园卡""雨伞"这样的关键词直接搜,比一条条翻列表快得多。
- 信息够判断:一条信息要能支持用户判断"这是不是我的东西"。因此物品名称、时间、地点和特征描述是必填的;照片有帮助,但很多同学拿不到照片,所以设为选填。
- 状态要准:物品找回或归还后信息应当可以结束,避免占用别人的注意力。
明确不做的部分。 实名认证、地图定位、站内即时聊天、消息推送都不在本次范围内。它们听起来有用,但地图定位对"一教三楼走廊"这种校园场景帮助有限,站内聊天和推送会显著增加后续实现的复杂度,实名认证则涉及隐私和合规。沟通环节我们用"详情页展示发布者联系方式 + 复制"来解决,把复杂度留在下一步再考虑。
四、功能设计
需求整理完之后,我们把功能收敛成五件事,对应五个页面。
① 首页:顶部是搜索入口,下方是"全部 / 寻物 / 招领"三个分类,主体区域用卡片展示最近发布的信息。卡片只放浏览时需要的信息——物品名称、类型、地点、日期和状态,特征描述和联系方式留给详情页。这样做是为了让用户一眼扫过去就能判断"这条和我有没有关系"。
② 发布信息页面:寻物和招领共用一套表单,用户先选择类型,再填写物品名称、时间、地点、描述和联系方式,照片选填。选择"寻物"时字段是"丢失时间""丢失地点",选择"招领"时自动变成"拾取时间""拾取地点",避免两套页面各写一遍。
③ 搜索页面:解决"我知道自己丢了什么"的情况。用户可以输入关键词,也可以只看寻物或只看招领。搜索结果的展示方式与首页保持一致,不再单独设计一套卡片,减少用户的认知负担。
④ 信息详情页面:展示一条信息的完整内容,包括物品图片、名称、类型、时间、地点、特征描述、联系方式和当前状态。底部提供一个"我已确认是这件物品,联系发布者"的按钮,让"确认信息 → 联系对方"成为一个明确的动作。
⑤ 我的发布:管理自己发布过的信息。物品找回或归还后,可以把状态改成"已找回"或"已归还",也可以继续编辑内容。这个页面是为了让信息有终点,否则列表里会堆满已经无效的内容。
五、原型设计
我们使用的原型设计工具是 Figma(Figma Design),原型在线链接:
打开上面的链接后,点右上角的播放按钮进入演示模式,就可以点着走完整流程:首页点一下进入信息详情,搜索页点一下查看结果对应的详情,发布信息页点一下进入发布成功页,发布成功页可以返回首页,「我的发布」可以进入编辑信息页。
下面是五个界面的状态图。每一张里从左到右是同一个界面在不同情况下的样子——原型不只画了"一切顺利"的那一版,加载中、加载失败、没有结果、必填项没填这些容易出问题的地方也单独画了出来。

首页:① 已有同学发布信息(正常浏览)② 加载中(骨架屏占位,不出现白屏)③ 加载失败(给出重试入口)④ 只看寻物(分类筛选后的列表)。

搜索:① 还没输入(给出最近搜索和热门搜索)② 输入关键词后筛选(只看寻物 / 只看招领)③ 搜索中(骨架屏)④ 没有匹配结果(空状态 + 返回首页浏览)。

信息详情:① 正常(完整信息 + 联系方式)② 加载中(图片和字段都用骨架屏占位)③ 已失效(物品已归还,信息只读、不再接受联系)④ 复制联系方式成功(提示已复制)。

发布信息:① 招领表单 ② 切到"寻物"后字段自动变成"丢失时间 / 丢失地点"③ 必填项没填(字段标红并逐条提示)④ 提交中(按钮显示"发布中…",避免重复提交)。

发布成功、我的发布(修改状态前会二次确认)、编辑信息(必填校验)、个人资料页。
六、用户使用流程
主要流程有两条。找东西:打开小程序 → 首页浏览或搜索 → 查看信息详情 → 核对物品特征 → 复制联系方式联系发布者。发信息:点击底部"发布" → 选择寻物或招领 → 填写物品信息 → 校验必填项 → 发布成功 → 在"我的发布"里管理状态。
除了正常路径,原型也把容易出问题的状态画了出来:列表和搜索结果加载时用骨架屏占位,避免用户看到白屏;加载失败时给出重试入口;搜索没有匹配结果时给出空状态提示和「返回首页浏览」的出口;发布信息时必填项没填会标红并逐条提示,提交过程中按钮变成"发布中…"避免重复提交;物品归还后信息会变成已失效的只读状态;修改自己发布的信息状态前还会二次确认。
七、结对过程
我们两人是同一个宿舍的,所以讨论大多是面对面完成的。整个过程大致分三轮。
第一轮是理需求。 我们先各自写一份"用户会遇到什么问题",然后放在一起对比。赵紫龙负责记录场景和功能点,我负责反问"这个功能真的需要吗"。第一版我们列出了十几个功能,讨论之后砍掉了大半,最后只留下浏览、发布、搜索、详情和状态管理五项。
第二轮是画页面。 一人操作原型工具,另一人对照需求清单逐条检查页面上有没有对应的元素,检查完一轮再交换角色。这个过程里我们发现了一个问题:最初详情页没有"发布者联系方式"以外的任何引导,用户看完信息不知道下一步该做什么。后来才加上了底部那个确认按钮。
第三轮是走流程。 我们按"找东西"和"发信息"两条路径,把每个页面从头到尾点一遍,重点看跳转是否连贯、字段是否前后一致、状态有没有终点。这一轮改动最多的是文案,比如把"提交"改成"立即发布",把"无人认领"改成"待认领"。
八、PSP 表格
| PSP 阶段 | 预估时间 / min | 赵紫龙实际 / min | 林彦翔实际 / min |
|---|---|---|---|
| 阅读任务并讨论需求 | 40 | 35 | 35 |
| 阅读《构建之法》第 3、8 章 | 60 | 50 | 50 |
| 用户需求分析 | 50 | 60 | 45 |
| 功能与页面规划 | 40 | 35 | 35 |
| 整理用户使用流程 | 30 | 25 | 30 |
| 原型页面制作 | 300 | 260 | 240 |
| 结对检查与修改 | 60 | 55 | 55 |
| 博客整理 | 90 | 70 | 50 |
| 个人总结 | 30 | 20 | 20 |
| 合计 | 700 | 610 | 560 |
九、个人总结
我这次主要负责检查,同时也会帮助紫龙思考可能会用到的功能点,把自己代入用户的视角去思考哪些部分是合理的,哪些部分没有必要的。基于最初的方案,我们改了又改,一开始还能比较快的发现问题/想到可以添加的内容,但是后来就要盯比较久的时间去思考,才能憋出一两个点。或许是因为没有调研的原因,只有两个人的视角,想出来的结果还是比较有限的,我们有参考别人的作业,看看以他们的视角设计出来的是什么效果,然后进行增改。
结对作业重要的部分在于沟通,好在我们作为舍友,互相并没有什么东西是不好意思讲出来的,我一有问题就会提出,紫龙经过思考后也会给我分析,或者采用我提出的意见。

浙公网安备 33010602011771号