2026秋软件工程个人作业(第三次)

课程 H202601软件工程与软件工程实践
作业要求 2026秋软件工程个人作业(第三次)
作业目标 完成「校园失物招领小程序」需求分析和原型设计
学号姓名 102401231 赵紫龙、102401228 林彦翔

一、《构建之法》读后感

读完第三章,我认为真正有意思的是软件工程师的思维误区这一板块,前面的内容并没有过多引起我的关注。就好像很平常的道理拿出来讲,就比如怎么衡量初级软件工程师的成长,软件开发的工作量和质量该怎么衡量等这种问题,前者感觉主要就在说要不断学习,后者就是强调效率(re-work是好事吗,按时交付的重要性),就是看完感触不大,可能得我自己经历后才懂,所谓“人教人不会,事教人一次就会了”。对于软件工程师常见的思维误区这一块,看完后我认为,在开发软件的过程中,没必要弄清问题的所有细节和依赖关系,找到重要和次要的部分就可以开始动手操作了。有些次要的东西考虑的太多,反而会影响效率,且不值得投入那么多精力。这部分挺有意思的。

第八章主要就是讲需求分析,该怎么对用户的需求进行分析,才能开发出符合用户心理预期的软件,调研也是一种学问。第八章还提到开发过程中如何做好估计,这个对项目完成的时间进行估计,对用户没有提到的需求进行合理的估计和联想。需求的分析,本质也是为了提高开发效率。

总的来说,一个软件工程师的成长离不开持续地学习,提高自己的水平。同时要对软件的开发要先将用户的需求进行合理的分析(调研),理清主次,对完成的时间进行一个合理的估计,这样才能提高生产效率。

二、题目来源

校园里丢东西是很常见的事:校园卡、钥匙、水杯、雨伞、耳机、课本,几乎每个同学都丢过或者捡到过。

现在的做法是在班级群、宿舍群、朋友圈里发消息。问题有三个:一是分散,不同的人在不同的群里,看到的信息范围完全不同;二是很快被刷走,群聊消息一多,几天前的招领信息就翻不到了;三是没有"结束"机制,东西早就还回去了,消息还挂着,让人白高兴一场。

我们想做的"校园失物招领小程序",就是给学生一个统一的入口:寻物和招领信息集中放在一起,可以按关键词搜索,并且能标明信息当前是否还有效。

三、用户需求分析

主要用户有两类。 第一类是失主,丢了东西以后希望尽快找回,一方面自己发布寻物信息,另一方面主动去查有没有人捡到。第二类是拾获者,捡到东西后想尽快交给失主,但不愿意为了这件事花费太多精力,所以发布操作必须尽量短。

还有一类间接相关的角色是宿舍管理员和保卫处,他们经常收到同学送来的失物。不过这次作业不涉及线下交接流程,我们只把它当作背景,不设计专门的角色和功能。

用户真正的问题不是"没有功能",而是"信息找不到、也不敢信"。 由此我们整理出四条核心需求:

  1. 统一入口:打开小程序就能看到最近的寻物和招领信息,不需要先加入某个群。
  2. 能搜到:用户通常已经知道自己丢了什么,用"校园卡""雨伞"这样的关键词直接搜,比一条条翻列表快得多。
  3. 信息够判断:一条信息要能支持用户判断"这是不是我的东西"。因此物品名称、时间、地点和特征描述是必填的;照片有帮助,但很多同学拿不到照片,所以设为选填。
  4. 状态要准:物品找回或归还后信息应当可以结束,避免占用别人的注意力。

明确不做的部分。 实名认证、地图定位、站内即时聊天、消息推送都不在本次范围内。它们听起来有用,但地图定位对"一教三楼走廊"这种校园场景帮助有限,站内聊天和推送会显著增加后续实现的复杂度,实名认证则涉及隐私和合规。沟通环节我们用"详情页展示发布者联系方式 + 复制"来解决,把复杂度留在下一步再考虑。

四、功能设计

需求整理完之后,我们把功能收敛成五件事,对应五个页面。

① 首页:顶部是搜索入口,下方是"全部 / 寻物 / 招领"三个分类,主体区域用卡片展示最近发布的信息。卡片只放浏览时需要的信息——物品名称、类型、地点、日期和状态,特征描述和联系方式留给详情页。这样做是为了让用户一眼扫过去就能判断"这条和我有没有关系"。

② 发布信息页面:寻物和招领共用一套表单,用户先选择类型,再填写物品名称、时间、地点、描述和联系方式,照片选填。选择"寻物"时字段是"丢失时间""丢失地点",选择"招领"时自动变成"拾取时间""拾取地点",避免两套页面各写一遍。

③ 搜索页面:解决"我知道自己丢了什么"的情况。用户可以输入关键词,也可以只看寻物或只看招领。搜索结果的展示方式与首页保持一致,不再单独设计一套卡片,减少用户的认知负担。

④ 信息详情页面:展示一条信息的完整内容,包括物品图片、名称、类型、时间、地点、特征描述、联系方式和当前状态。底部提供一个"我已确认是这件物品,联系发布者"的按钮,让"确认信息 → 联系对方"成为一个明确的动作。

⑤ 我的发布:管理自己发布过的信息。物品找回或归还后,可以把状态改成"已找回"或"已归还",也可以继续编辑内容。这个页面是为了让信息有终点,否则列表里会堆满已经无效的内容。

五、原型设计

我们使用的原型设计工具是 Figma(Figma Design),原型在线链接:

校园失物招领小程序 · 可点击原型

打开上面的链接后,点右上角的播放按钮进入演示模式,就可以点着走完整流程:首页点一下进入信息详情,搜索页点一下查看结果对应的详情,发布信息页点一下进入发布成功页,发布成功页可以返回首页,「我的发布」可以进入编辑信息页。

下面是五个界面的状态图。每一张里从左到右是同一个界面在不同情况下的样子——原型不只画了"一切顺利"的那一版,加载中、加载失败、没有结果、必填项没填这些容易出问题的地方也单独画了出来。

首页的四种状态

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

搜索的四种状态

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

信息详情的四种状态

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

发布信息的四种状态

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

发布成功、我的发布与个人资料

发布成功、我的发布(修改状态前会二次确认)、编辑信息(必填校验)、个人资料页。

六、用户使用流程

主要流程有两条。找东西:打开小程序 → 首页浏览或搜索 → 查看信息详情 → 核对物品特征 → 复制联系方式联系发布者。发信息:点击底部"发布" → 选择寻物或招领 → 填写物品信息 → 校验必填项 → 发布成功 → 在"我的发布"里管理状态。

除了正常路径,原型也把容易出问题的状态画了出来:列表和搜索结果加载时用骨架屏占位,避免用户看到白屏;加载失败时给出重试入口;搜索没有匹配结果时给出空状态提示和「返回首页浏览」的出口;发布信息时必填项没填会标红并逐条提示,提交过程中按钮变成"发布中…"避免重复提交;物品归还后信息会变成已失效的只读状态;修改自己发布的信息状态前还会二次确认。

flowchart TD A[打开小程序] --> B[首页:浏览全部 / 寻物 / 招领] B --> C{是否已经知道要找什么} C -->|否| D[浏览信息卡片] C -->|是| E[搜索页:输入物品名称] E --> F[查看搜索结果] D --> G[查看信息详情] F --> G G --> H[核对物品特征与地点时间] H --> I[复制联系方式,联系发布者] B --> J[点击底部发布] J --> K[选择寻物或招领,填写物品信息] K --> L{必填项是否完整} L -->|否| M[标出缺失字段,保留已填内容] M --> K L -->|是| N[立即发布] N --> O[发布成功,可查看信息] O --> P[我的发布:管理自己发布的信息] P --> Q[标记为已找回 / 已归还]

七、结对过程

我们两人是同一个宿舍的,所以讨论大多是面对面完成的。整个过程大致分三轮。

第一轮是理需求。 我们先各自写一份"用户会遇到什么问题",然后放在一起对比。赵紫龙负责记录场景和功能点,我负责反问"这个功能真的需要吗"。第一版我们列出了十几个功能,讨论之后砍掉了大半,最后只留下浏览、发布、搜索、详情和状态管理五项。

第二轮是画页面。 一人操作原型工具,另一人对照需求清单逐条检查页面上有没有对应的元素,检查完一轮再交换角色。这个过程里我们发现了一个问题:最初详情页没有"发布者联系方式"以外的任何引导,用户看完信息不知道下一步该做什么。后来才加上了底部那个确认按钮。

第三轮是走流程。 我们按"找东西"和"发信息"两条路径,把每个页面从头到尾点一遍,重点看跳转是否连贯、字段是否前后一致、状态有没有终点。这一轮改动最多的是文案,比如把"提交"改成"立即发布",把"无人认领"改成"待认领"。

八、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

九、个人总结

我这次主要负责检查,同时也会帮助紫龙思考可能会用到的功能点,把自己代入用户的视角去思考哪些部分是合理的,哪些部分没有必要的。基于最初的方案,我们改了又改,一开始还能比较快的发现问题/想到可以添加的内容,但是后来就要盯比较久的时间去思考,才能憋出一两个点。或许是因为没有调研的原因,只有两个人的视角,想出来的结果还是比较有限的,我们有参考别人的作业,看看以他们的视角设计出来的是什么效果,然后进行增改。

结对作业重要的部分在于沟通,好在我们作为舍友,互相并没有什么东西是不好意思讲出来的,我一有问题就会提出,紫龙经过思考后也会给我分析,或者采用我提出的意见。

posted @ 2026-09-26 21:31  kk咸鱼  阅读(21)  评论(0)    收藏  举报