[T.17] 团队项目：Beta 阶段项目展示

[T.17] 团队项目：Beta 阶段项目展示

项目	内容
这个作业属于哪个课程	首页 - 2025年春季软件工程（罗杰、任健） - 北京航空航天大学 - 班级博客 - 博客园
这个作业的要求在哪里	[T.17] 团队项目：Beta 阶段项目展示 - 作业 - 2025年春季软件工程（罗杰、任健） - 班级博客 - 博客园
我在这个课程的目标是	作为团队完成一个完整的软件开发流程，学习软件工程与软件开发相关流程和技术
这个作业在哪个具体方面帮助我实现目标	展示 Beta 阶段发布产品功能

项目与团队亮点

团队成员与分工简介

项目管理与需求分析

产品经理与需求分析（余欣实）：负责整体进度把控、需求收集与撰写项目计划书，协调各成员任务分配。

地图建模与数据采集

地图数据采集（张艺轩）：采集地图数据及细节部分，为地图导航提供准确数据。
地图数据标注（张鑫）：将地图信息标准化，服务于导航算法。
导航算法工程师（张鑫）：给出导航算法，生成路线图等导航信息。

前端开发与UI/UX

前端工程师（胡健、张鑫、张亿杰）：

• 胡健：建立初始框架，开发登录和个人信息页。
• 张鑫：开发查找附近设施页，页面兼容性调整，对接前后端接口。
• 张亿杰：开发地图首页和导航页，对接前后端接口。

UI/UX 设计师（张艺轩）：完成整体视觉风格、图标设计及原型图，保证界面简洁易用。

后端开发与运维

后端工程师（梁骁、王睿风）：

• 梁骁：规范API、后端服务构建、后端服务基础测试、服务器运行环境搭建、服务器部署、前后端对接。
• 王睿风：项目部署、服务器配置和维护。

测试

测试工程师（张艺轩）：制定测试计划，撰写测试用例并进行各类测试。

典型用户场景

寻找楼内教室

用户进入小程序，点击底部栏“地图”，先点击上方搜索框跳转进入搜索界面，

进入搜索界面后再次点击搜索框，根据系统提示依次选择楼座、楼层、教室编号，

此时搜索框内会出现目标地点名称，点击搜索框右侧的“搜索”按钮即可跳转至地点详情页面。
在该页面内，上部为地点所在楼层的平面图，下部为其他用户对该地点的评论，右侧有两个按钮，由上到下依次为“更多”和“导航”。

点击导航按钮，系统提示选择选择当前地址，点击选项框依次选择当前所在位置的楼座、楼层和教室名称，然后点击确认即可跳转至导航页面。

用户可根据平面图上的红色路线标识找到目标地点。如果涉及跨楼层导航，可以点击左右两侧的箭头切换至当前楼层的平面导航。

寻找附近设施

用户进入小程序，点击底部栏“找设施”，在“寻找最近设施”框内有三个按钮“厕所”、“售货机”和“确认”。

先选中想找的设施种类，然后点击确认，系统提示选择当前地址，依次选好后点击确认即可进入导航界面，根据引导即可前往目标厕所/售货机。

地图上教室名的点击交互功能

对于要搜索或要导航的教室，除了在搜索栏搜索和在收藏页进入，还可以直接在地图上点击教室名进入。

对楼内教室进行收藏评论

• 添加收藏/评论：进入小程序地图界面，通过顶部搜索框搜索需要收藏/评论的地点，进入地点详情页面。点击在详情页面右侧的“更多”按钮，点击收藏，看到心形图标变成黄色即表明收藏成功，再次点击收藏即可取消收藏；
  
  点击评论按钮，在从底部弹出的输入框中输入评论内容（支持文字与图片），点击提交即可生成评论。
  

• 管理收藏：点击底部栏“收藏”板块进入收藏页面，已经收藏过的内容均以列表的形式显示在这里。
  
  点击一条收藏的右侧“...“按钮，可以选择取消收藏或置顶收藏。取消收藏后收藏内容将不在此处显示；置顶收藏后会将收藏内容置顶。
  

杀手级功能

• 提供新主楼内部各层的总览地图与交互
• 根据起始和目标教室生成平面导航图

发布时的努力

• 已经在微信小程序平台进行发布
• 尝试通过申请后端域名解决小程序对非官方网页的访问限制
• 主要在团队成员的同学与亲友间进行推广

活跃用户统计

自发布日起小程序打开次数、访问人数、新增用户数据如下：

用户访问来源分析如下：

用户访问频次分析如下：

代码的软件工程质量

代码的测试工作主要围绕前端展开，以单元测试和场景测试为主。

前端缺陷分析与质量总结

当前前端代码共计3,718行，累计发现6个有效缺陷，缺陷密度为1.61个/千行，低于行业常见风险水平（2-3个/千行），整体代码健壮性处于可控范围。然而，缺陷解决率仅为33.3%（2/6），未修复问题中包括高优先级的微信登录API调用失败及返回按钮跳转异常，需加速处理以避免用户体验恶化。

从缺陷引入阶段分析，83.3%的问题源于编码阶段，主要体现在页面跳转逻辑错误、异步状态管理缺失及接口调用不规范，反映出开发过程中对技术规范的执行偏差与场景覆盖不足。有1个缺陷（长图片显示异常）可追溯至设计阶段，因未明确定义多端适配规则，开发时依赖临时方案引发后续问题。

缺陷类型分布显示，功能逻辑错误占比50%（3/6），成为最大风险源，其次是UI/UX缺陷（33.3%）与接口集成问题（16.7%）。功能逻辑问题集中表现为路由管理与用户交互流程的漏洞，如微信返回按钮未绑定正确的页面卸载逻辑，导致用户导航混乱；UI缺陷则因硬编码样式与响应式设计缺失，引发跨设备显示异常。值得注意的是，接口集成类缺陷虽数量较少，但直接影响核心功能（如用户登录），修复优先级较高。

针对当前问题，建议采取分层改进策略：短期内优先修复导航栏堆栈溢出与登录API故障；中期推行代码审查清单制度，重点约束页面生命周期管理与异步操作规范；长期则需完善需求评审流程，明确交互规则与多端适配标准，从源头降低设计阶段缺陷引入风险。通过强化自动化测试（目标单元测试覆盖率提升至80%）与开发者质量意识培训，有望在下一版本将缺陷密度控制在1.0个/千行以内，实现质量与效率的可持续平衡。

项目 demo 展示

项目与团队总结

成员的简介和个人博客地址

团队成员的简介博客地址如下：
[T.1] 团队项目：团队成员介绍

各团队成员个人博客地址如下：

成员	个人博客地址
余欣实	https://www.cnblogs.com/yxsyxs
胡健	https://www.cnblogs.com/hjzts666
梁骁	https://www.cnblogs.com/xavi663
王睿风	https://www.cnblogs.com/vonreef
张鑫	https://www.cnblogs.com/Myst-name
张艺轩	https://www.cnblogs.com/zyx2237
张亿杰	https://www.cnblogs.com/jiessi

项目管理

团队项目使用 github 管理，前后端仓库地址分别如下：
前端仓库
后端仓库

成员的分工协作

团队的分工和任务分配以两天为单位，具体任务分配详见[T.9] 团队项目：每日例会报告，整体分工进行的较为顺利，保证了开发的顺利进行。与 Alpha 阶段相比我们减小了任务分配的时间跨度，工作分配不再受限于例会频率，让工作安排更加高效合理。

团队的沟通和对接

团队成员之间主要通过例会进行沟通和对接，平时则使用微信和飞书进行沟通，有会议纪要、消息记录等多种记录留存。会议纪要详见[T.9] 团队项目：每日例会报告。

时间、质量与资源的平衡

团队以最初的设计和规划为首要目标，在项目推进过程中，我们始终围绕“时间、质量、资源”三者之间的动态平衡展开决策。首先，针对有限的时间节点，我们采用了敏捷迭代的方式，把功能拆解为一系列可独立交付的小模块，每次迭代只聚焦最核心、最能体现价值的功能，从而保证关键里程碑前总能交付一个可用版本；与此同时，对那些次要或难度较高的优化需求，则在确保主流程稳定之后再行安排，通过优先级和上线风险评估来合理延后，从而避免时间压力下的大范围返工。其次，在质量把控方面，我们并未盲目追求“零缺陷”，而是将测试与开发紧密结合：开发过程中同步编写单元测试，采用自动化工具对核心接口和用户流程做回归检测，并结合代码评审机制快速发现并修复漏洞，这样既提升了代码稳定性，也节省了后期修复的时间成本。最后，在资源调度上，我们根据任务特点和成员专长灵活分配人力，对于前后端耦合度低的子任务实行并行开发，确保团队整体产能最大化；对于 UI 设计、文案撰写等非编程工作，则视实际负荷适度引入外部协作或跨成员协助，以缓解内部资源瓶颈。正是通过这种“迭代交付＋自动化测试＋灵活分工”的策略，我们才能在保证基础质量与合理利用人力资源的前提下，实现了项目的如期推进。

团队项目的实际进展

项目前后端仓库的燃尽图如下：

前端

后端

燃尽图对项目状态的反映

燃尽图之所以被广泛采用，正是因为它用最直观的方式——剩余工时（或剩余故事点）随时间的变化曲线——来展示团队对迭代目标的达成进度。理想情况下，燃尽图中的“理想燃尽曲线”代表了团队在整个 Sprint 中应当匀速完成工作的轨迹，而“实际燃尽曲线”则实时记录每天结束后剩余工时的真实数据。只要团队及时而准确地更新每日剩余工时，燃尽图就能真实反映出工作推进的节奏：当实际曲线落在理想曲线之下时，说明进度超前；若曲线停滞或高于理想曲线，则表明存在潜在的延期风险。

Beta 阶段各成员角色和具体贡献

组员	负责	贡献分	具体贡献
余欣实	PM	53	负责 Beta 阶段产品改进概念与原型的设计与验证，同时完成几乎全部的文档撰写工作；同时负责设计前端ui界面，给出5个页面的ui建模原型，同时向前端提供修改意见；在前后端衔接中负责API文档的制定和统一规范，同时进行bug收集与反馈
胡健	前端	47	负责微信登录模块和少量页面的优化，总代码约500行
梁骁	后端	50	增了点击吸附、大地图交互以及登陆检查接口，进行了一些已有功能的调整，修改了一些接口的参数形式，以及本阶段大部分时间都消耗于微信用户登陆功能，由于之前的接口存在较大问题，本次登陆模块的修改涉及数据库底层重构，因此对一些涉及用户实体的模块如收藏、评论、历史记录的相关功能都进行了大范围修改。最终版本代码量共4029行
王睿风	后端	46	参与撰写了Beta版本功能规格说明书 维护开发环境和服务器稳定运行 前端：负责燃尽图的生成工作 bug修复：修复了服务器崩溃死机的bug
张鑫	地图建模&前端	54	后端：改进了后端算法的逻辑，增加地图的点击交互（约300行） 前端：在“地点页面”增加评论功能（124行），重写登录界面（121行），重写登录逻辑（103行） 地图数据：数据处理代码（约200行）;对地图上可点击交互点进行数据标注（约1050行Excel数据）;对35张visio文件进行合并以及数据迁移（合成为5张大型visio文件，编写了262行数据迁移代码，以及103行数据迁移测试代码） Bug修复：对负责的上述相关代码和数据进行了bug测试和修复 注释：对负责的后端代码中所有暴露出来的函数均编写了注释（约70行）
张艺轩	地图建模&美工	50	基本完成了地图所需数据采集工作与前端ui界面设计，地图数据主要包括各层地图数据采集，卫生间及零食柜位置标注、地图建模、图片，前端主要包括导航、反馈、评论、收藏模块，功能基本齐全，主要负责设计前端ui界面，给前端提供修改意见与图片来源（5层数据采集；3层地图建模；2次ui建模）； bug收集与反馈：收集前端问题并反馈总结（两阶段共20个bug）； 文档：撰写了测试文档，设计单元测试与场景测试； 前端：完成了寻找“最近页面””调整与ui修改(129行)； 地图数据：绘制了二、三楼的地图绘制(14张visio文件)；采集地图图片数据与实地勘测（70张图片文件）
张亿杰	前端	50	修改了首页和导航页的实现，将一个楼层的某座小图片替换成楼层的大图片，并增加了地图交互功能。（约修改400行代码）；发现并修复了找附近设施时永远找的是售货机的bug

用户场景

项目开发前的目标和设计的用户画像、应用场景、产品功能如下：

用户画像

	学生	校外人士
潜在总量	90%	10%
使用习惯	学期初使用量大。使用教室导航以及附近搜索功能	使用时间较为平均，以教室导航功能为主

典型应用场景

用户信息	用户情况
身份	第一次来某教室上课的学生
使用动机	需要导航帮忙到达教室
用户要求	找到最短最方便的路径
系统提供服务方式	要求用户输入当前位置和目标地点，自动生成最方便的路径
用户比例	40%

用户信息	用户情况
身份	在新主楼上课或自习的学生
使用动机	在饿的时候寻找售卖机，想上厕所时寻找厕所
用户要求	需要能找到离自己最近的售卖机或厕所
系统提供服务方式	要求用户输入当前位置，自动帮忙定位最近的售卖机或厕所，并生成路径
用户比例	50%

用户信息	用户情况
身份	外校来上课的老师和学生
使用动机	对新主楼结构完全不了解，需要从楼外精确导航到目标教室
用户要求	需要提供最精确的路径导航及时到达教室
系统提供服务方式	要求用户输入当前位置(可以是某个门口)和目标地点，生成路径并进行导航，并提供路径上的照片等信息辅助导航
用户比例	10%

产品功能

• 1.用户选择起点与终点，产品提供导航服务
• 2.用户选择当前位置，产品提供附近最近目标导航
• 3.用户可以对路径结点发表评论，为其他用户导航时提供信息辅助

项目小程序在微信小程序平台上线与发布，同时在成员的同学和亲友之间进行宣传和推广。发布后项目的功能如下：

功能与特性	解决的问题
地图预览与导航采用以层为单位的大地图	- 原有地图和导航采用以座为单位的小地图，用户缺少对路线和地图的全局理解 - 同时让导航的地图数减少，大大简化导航功能使用流程，优化用户体验
地图上教室名的点击交互功能	- 原有地图并无交互功能，对于教室的搜索和导航只能通过搜索栏和收藏页面进行
收藏与评论	- 复用场景下需要反复搜索同一教室； - 缺少用户间交流反映教室环境的平台。

项目发布后满足了全部典型场景，主要功能均按预期实现，同时针对部分用户体验上的修改建议，进行了相应的优化，真正符合了用户需求，在实际使用中受到用户一致好评。

用户日活

项目发布时我们主要通过成员亲友间介绍进行宣传推广，在同学之间拥有了一百多名用户，大部分用户都和成员有一对一的建议和反馈渠道。软件日活用户基本达到了我们的预期，作为一个功能性小程序，在应用场景本来就不多的情况下，用户的平均使用次数多大4~5次，足见小程序对用户的用处。用户对小程序功能并无更多意见和建议，也没有发现新的bug。

特色功能

项目的杀手级功能主要是室内大地图的显示和室内大地图上的导航功能，填补了市场上常规地图软件不能在教学楼内进行室内导航的空缺，同时弥补了教学楼内地图和标志分散而不明确的问题。我们的团队以校内学生的优势在楼内进行了大量的地图数据采集，实现了这一功能，在用户中广受好评，达到了我们的预期目标。

软件工程质量

我们的项目有完善的设计文档和前后端API文档，对代码规范也有一些不成文的约定，对CI/CD和单元测试也进行了些许尝试。在 Beta 阶段，我们在 Alpha 阶段的基础上积累了以下几点深刻经验与教训：

首先，持续迭代中的用户沟通至关重要。在 Beta 阶段，我们及时捕捉用户在不同时间、不同场景下的真实需求，通过与用户的多轮互动，我们发现部分原先认为“好用”的功能在用户中的体验并不尽如人意，这促使我们迅速对功能进行更精确的优化，提升了产品的用户体验。

其次，测试覆盖与质量监控需在早期全面铺开。虽然 Beta 阶段我们已搭建基本的单元测试，但还是缺少很多集成测试和压力测试，更很少涉及安全性的检验，大部分功能和代码上的bug都是由测试和用户手动发现。测试的深度与广度要匹配系统发布的成熟度，尤其是安全性测试和压力测试，不能留到产品上线后才补做。