软件工程第三次个人作业

软件工程第一次结对作业

项目	内容
课程	https://edu.cnblogs.com/campus/fzu/2026-01SoftwareEngineeringandSoftwareEngineeringPractice/
作业要求	https://edu.cnblogs.com/campus/fzu/2026-01SoftwareEngineeringandSoftwareEngineeringPractice/homework/16742
作业目标	完成「校园失物招领小程序」需求分析和原型设计
学号和姓名	同学 A：102401614 林志涛；同学 B：102401625 朱铮睿

一、阅读《构建之法》的思考

阅读第 3 章“软件工程师的成长”后，我最大的体会是：工程能力并不只是“把代码写出来”，更在于能否用 PSP 的方法科学地估计任务、记录过程、复盘偏差。第 8 章“需求分析”则提醒我们，需求要从“用户困扰”出发，而不是从“功能清单”出发。如果一个小程序只能发布信息，却无法快速检索、无法确认物品是否已经归还，那么用户的核心痛点依然存在。因此我们在设计中把“搜索、详情展示、状态反馈”作为三个优先打磨的模块，并在结对评审时要求彼此说明每一处设计的业务理由。

二、项目来源与用户需求

校园失物信息目前散落在班级群、宿舍群和朋友圈中，容易被海量聊天记录覆盖，拾取者和失主之间还存在信息壁垒。系统的目标用户分为三类：失主（发布寻物、搜索招领）、拾取者（发布招领）、帮忙留意的同学（浏览与搜索）。核心问题可以概括为：信息难集中、难精准匹配、难确认闭环状态。

典型场景是：一位同学捡到校园卡后发布招领启事，失主搜索“校园卡”，核对时间地点无误后联系对方完成交接，最后由发布者把状态更新为“已归还”，形成业务闭环。

三、功能与页面设计

围绕“发布—查找—联系—结束”这一闭环，我们精简出 9 页原型：首页、发布信息、发布成功、搜索结果、信息详情、联系发布者、我的发布、状态已更新等。主要功能包括：

• 浏览与搜索：首页按类型浏览，输入关键词查看搜索结果。
• 发布寻物／招领：填写名称、时间、地点、描述与联系方式，照片可选，提交后进入成功页。
• 查看与联系：详情页展示图片、时间地点和状态，再进入联系页查看联系方式。
• 修改状态：在“我的发布”中标记“已找回／已归还”，并查看状态更新反馈。

考虑到迭代周期，实名认证、即时聊天和 LBS 地图定位暂不列入本次核心范围。

四、用户流程与改进设想

用户主流程为：打开小程序 → 首页浏览或搜索 → 查看信息详情 → 点击联系发布者；发布流程为：点击底栏“发布” → 选择寻物／招领 → 填写信息 → 确认发布 → 发布成功。流程图中用实线表示本次已落地的路径，虚线表示后续迭代设想。

下一轮迭代拟将笼统的“地点”拆分为“校园大区域＋详细地点”，增加“寻物／招领＋校园区域”复合筛选，详情页补全特征标签并支持照片缩放，同时在点击联系前增加核对与隐私提示。

五、原型工具与检查

本次作业采用 Figma 设计移动端界面，所有文字、卡片、按钮均采用独立图层与组件库化处理，避免“整页贴图”。内部验收时我们进行了角色扮演，成功走通“查看详情”“发布成功”“搜索结果”三项核心任务，并检查了状态更新的交互反馈。

原型在线链接：https://www.figma.com/design/uqIdAMnXmbEUCrGxY2w4w0

六、结对过程

初期我们用 AIGC 工具做多轮结构化 Prompt 对话，快速梳理校园失物场景的痛点与用户旅程。初稿曾尝试整页贴图配合热区演示，复盘时发现需求一变就要整图替换，成本极高，于是改用 Figma 生成九页可编辑高保真原型。过程中两人通过屏幕共享和语音保持高频沟通，磨合了协作节奏。

PSP 记录

PSP 阶段	预估耗时/分钟	实际耗时/分钟
计划与需求分析	55	65
流程与页面设计	75	90
原型制作与连线	155	180
评审与修改	40	35
博客与最终检查	100	85
合计	425	455

七、个人总结

这次结对作业让我最深的体会是“先跑通再打磨”。一开始我总想一次把筛选、地图、聊天都加上，结果发现时间根本不够，反而连最基础的发布和搜索都做得很粗糙。后来我们用实线和虚线区分“本次交付”和“后续设想”，先把核心闭环敲定，心里才踏实。另一个收获是结对评审的价值：自己画图时容易忽略细节，队友往往一眼就能看出交互逻辑的遗漏，比如状态更新后缺少反馈提示。问题也有，比如初期对 Figma 组件库不熟，返工了几次；好在通过分工——一人主攻页面、一人主攻流程与检查——最终按时完成了任务。