[T.12] 团队项目：Alpha 阶段项目展示

[T.12] 团队项目：Alpha 阶段项目展示

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

项目与团队亮点

团队成员与分工简介

项目管理与需求分析

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

地图建模与数据采集

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

前端开发与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] 团队项目：每日例会报告，整体分工进行的较为顺利，保证了开发的顺利进行。但以两天为单位分配任务时间跨度仍然较大，一次的变故或者任务分配的失误就会消耗两天的时间，产生了一些时间上的浪费，后续应当减小任务分配的时间跨度，让工作安排更加高效合理。

团队的沟通和对接

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

时间、质量与资源的平衡

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

团队项目的实际进展

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

前端

后端

燃尽图对项目状态的反映

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

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

组员	负责	贡献分	具体贡献
余欣实	PM	52	负责最初产品概念与原型的设计与验证，同时完成几乎全部的文档撰写工作；同时负责设计前端ui界面，给出5个页面的ui建模原型，同时向前端提供修改意见；在前后端衔接中负责API文档的制定和统一规范，同时进行bug收集与反馈
胡健	前端	48	负责最初框架的搭建与微信登录模块的编写，总代码约2200行
梁骁	后端	52	基本完成了后端框架及数据库的搭建，后端服务主要包括用户、导航、图片、历史记录、反馈、评论、收藏模块，功能基本齐全，受限于前端进度，部分模块如用户模块只是demo的性质，不能直接投入使用。代码量共3507行（包括新增及修改涉及的总量）
王睿风	后端	46	撰写了团队项目分发工作文档和团队基础设施及 DevOps准备文档 后端：构建了项目图床，负责租用服务器，搭建了开发环境 前端：负责燃尽图的生成工作 bug修复：修复了图床上传的图片无法显示的bug
张鑫	地图建模&前端	54	文档：撰写了技术规格说明书 后端：完成了寻路算法的设计（777行） 前端：完成了“地点详情”页面（560行）；完成了寻找“最近页面”（129行）；对api调用进行封装（240行）；将前端各页面嵌入api调用 地图数据：数据处理代码（约200行）；绘制了一、四、五楼的地图绘制（21张visio文件）；绘制了供测试人员参考的数据标注参考图（35张visio文件）;对地图数据进行标注（约1400行Excel数据）； Bug修复：对负责的上述相关代码和数据进行了bug测试和修复 注释：对负责的后端代码中所有暴露出来的函数均编写了注释（约100行）
张艺轩	地图建模&美工	48	基本完成了地图所需数据采集工作与前端ui界面设计，地图数据主要包括各层地图数据采集，卫生间及零食柜位置标注、地图建模、图片，前端主要负责设计前端ui界面，给前端提供修改意见与图片来源（5层数据采集；3层地图建模；2次ui建模）； bug收集与反馈：收集前端问题并反馈总结 文档:撰写了测试文档，设计单元测试与场景测试；前端：完成了寻找“最近页面”调整与ui修改(129行)； 地图数据：采集地图图片数据与实地勘测（70张图片文件）
张亿杰	前端	50	初步进行小程序ui的设计；撰写功能规格说明书的博客；完成前后端接口设计；对小程序所有页面进行了简单实现（约3100行代码）；实现并部署了小程序嵌入的两个webview网页，即首页和导航页（总计978行代码）；发现并修复诸如webview嵌入网页无法与小程序通信、小程序页面栈溢出导致无法进入新页面、用导航栏切换页面后导航栏依旧显示首页高亮等bug

用户场景

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

用户画像

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

典型应用场景

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

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

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

产品功能

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

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

功能模块	解决的问题
寻找楼内教室	- 室内环境复杂，用户难以凭借平面图快速定位目标教室； - 传统地图缺乏实时定位和跨楼层指引，导航体验差。
寻找附近设施	- 用户临时需求（如找卫生间、售货机）常因不熟悉楼内布局而走冤枉路。
收藏与评论	- 复用场景下需要反复搜索同一教室； - 缺少用户间交流反映教室环境的平台。

项目发布后满足了全部典型场景，主要功能均按预期实现，真正符合了用户需求，在实际使用中受到用户一致好评。

用户日活

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

特色功能

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

软件工程质量

我们的项目有完善的设计文档，对代码规范也有一些不成文的约定，对CI/CD和单元测试也进行了些许尝试。在 Alpha 阶段，我们完成了从概念验证到第一版可用系统的快速迭代，也积累了一系列宝贵的经验与教训：

首先是需求调研与原型验证要充分。在最初的需求分析中，我们通过问卷和小范围访谈收集了同学对室内导航的主要痛点，但由于样本量有限，部分功能优先级判断出现偏差。因此早期需扩大调研范围，进行更广泛的可用性测试，避免主观臆断。

其次是跨部门沟通与任务分配需落地。虽然我们在事前明确了前后端分工，但在具体实现中，接口定义、数据格式偶有改动，前端一度出现接口不匹配的状况，耽误了进度。应在每个迭代开始前，通过 API 文档固定接口契约，并在日会上由接口负责人负责同步更新，确保前后端对齐。

通过在 Alpha 阶段对“需求验证—版本管理—团队协作—测试文档”四个环节的实践与反思，我们不仅快速交付了可用系统，也为 Beta 阶段的规模化测试和稳定运营奠定了扎实基础。