团队信息
- 队名：火箭少男100
- 本次作业课上成员
- 原组成员
团队分工
分而治之
- 在划分具体工作模块上，我们也更愿意从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
- 交付件即可独立实现且与其他模块的耦合度较低的功能模块。
- 对于我们的主功能——AR识别商铺名返回商铺信息
及我们的副功能——基于GPS定位的智能推荐，我们可依次分割这两个功能为以下几个模块。 - AR识别商铺名返回商铺信息
- 关于AR模块的三个功能，这里我简单阐述一下：
- 运动追踪
- 在物体运动或者设备运动的过程中，追踪目标物体，具体取决于虚拟物体和在场人员的数量。还要考虑移动手机使用 AR 时，可能会引起不安全或者阻碍了与现实世界的互动。
- 虚拟交互
- 主要为体现在与虚拟资源交互，如选择允许用户辨别、操纵虚拟物体，以及与虚拟物体交互，同时要避免在平移过程中物体的突然变换或缩放比例。
- 环境增强
- 当 AR 内容对现实世界环境做出反应时，通过阴影、光照、遮挡、反射和碰撞来模拟物体的真实存在，但是用户可能因此难以在增强现实体验中感知深度和距离。利用阴影、遮挡、透视、纹理、常见物体的比例，以及放置参考物体来可视化表达深度。例如：商铺招牌的流水单引起的光线变化，通过这样可视化方式表明空间深度。
- 基于GPS定位的智能推荐
- 在获取位置输入的前提下，我们将推荐算法模块分为两个部分，基于位置的协同过滤以及基于用户的协同过滤，首先介绍一下协同过滤
- 协同过滤
- 它的原理很简单，就是根据用户对物品或者信息的偏好及兴趣采样；
- 发现物品或者内容本身的相关性，或者是发现用户的相关性，
- 然后再基于这些关联性进行推荐。
- 接下来在介绍一下基于位置的协同过滤以及基于用户的协同过滤
- 基于位置的协同过滤
- 在给用户做推荐的时候，根据用户过往兴趣偏好、地理位置及其时间衰减因子的比重来得到推荐信息。
- 基于用户的协同过滤
- 在给用户做推荐的时候，根据多用户的共同兴趣偏好、地理位置及其时间衰减因子的比重来得到推荐信息。
alpha版本实现内容
- ①我们实现安卓前端设计(UI设计) 以及 后端开发
- ②我们实现目标检测模块以及文字识别模块的算法实现以及优化
- ③通过AR接口实现后端与自然场景下文字识别模型的连接。
分工
分工明细
- 具体模块如下图所示
- 我们的alpha模块主要针对于我们的核心功能AR识别商铺名返回商铺信息来实现，我们也为各组覆盖到每名成员划分了工作细则——TODO list。
TODO list
| 短学号 | 名 | 工作细则 |
|---|---|---|
| 2325 | 燊(队长) | 目标检测模块与文字识别的模块间的接口设计及性能优化 |
| 1232 | 志豪 | 前端UI设计、开发 |
| 1131 | 喜源 | 完成数据库的架设、建立服务器端与数据库的连接 |
| 2523 | 宏岩 | 数据爬取，数据集标注 |
| 2230 | 恺翔 | 文字识别算法实现 |
| 2509 | 钧昊 | 目标检测算法实现 |
| 2507 | 俞辛 | 文档编写 |
| 2501 | 宇航 | 实现后端与AR识别模块间的交互模块 |
| 2502 | 柏涛 | 实现后端与前端UI间接口、附加功能尝试性开发 |
燃尽图
- 以下是我们设计的任务卡片，其中文字识别和目标检测模块以及完成初步实现，只是仍需对现有模块进行针对应用的改进
- 燃尽图如下所示
- 由于部分任务的实现环节甚至在团队作业开始之前我们已经完成，所以我们后续的规划包括任务分割也会对此做一定调整。
UML
PART 1 —— 用例图
- 个人管理系统和登录系统
- 这里描述的是系统哪部分？
- 这里是用户个人管理系统和登录系统的用例图。
- 这部分面临什么样的问题？
- 这部分要面临用户登录、注册验证、忘记密码的基本问题，用户的管理系统涉及个人信息维护、系统缓存和恢复加载等问题。
- 以下设计解决了哪些问题？
- 展现了客户与我们软件之间的交互联系，便于我们对用户个人管理系统和登录系统的可视化和软件原型设计，使用户能够理解使用登录和个人信息的联系，更方便操作，并使开发者能够有条理的实现这些元素。
- 附：
- 社区管理系统
- 这里描述的是系统哪部分？
- 这里是社区管理系统的用例图。
- 这部分面临什么样的问题？
- 这部分要面临搜索店铺，推荐店铺等算法问题，以及查看附近动态的及时性。
- 以下设计解决了哪些问题？
- 展现了社区管理的基本框架，便于我们对社区系统的可视化和软件原型设计，用户可以通过这个图更加理解社区的基本功能，便于操作。
- 附：
PART 2 —— 类图
- 这里描述的是系统哪部分？
- 描述了系统每个部分之间的关系、连接情况。
- 这部分要面临什么样的问题？
- 对于Yolo和CRNN类的使用，需要使用预先训练的参数。参数的训练，需要包含大量数据的数据集，然而，现在还没有有针对性的已经标注好的数据集，这就需要我们手动收集数据，进行标注，需要大量的人力物力。
- 卷积运算需要强大的运算能力支持，较低端的单核CPU服务器计算能力较弱，可能无法满足实时性的需求。将会采用更高性能的CPU服务器甚至GPU服务器。但是这样成本较高。
- 以下设计解决了哪些问题？
- 解决了开发者对于各个类体之间关系的宏观认识。
- 附：
PART 3 —— 活动图
- 这里描述的是系统哪部分？
- 描述软件的大致使用流程，以及店铺扫描、评论分享功能的使用流程。
- 这部分面临什么样的问题？
- 用户在使用软件的时候流程较为复杂，活动图可以帮助用户梳理整个软件的使用流程。
- 以下设计解决了哪些问题？
- 帮助用户理清软件的使用流程，明确各个功能的使用细节。
- 附：
PART 4 —— 状态图
- 登入界面
- 这里描述的是系统哪部分？
- 用户登入注册的部分。
- 这部分面临什么样的问题？
- 面临账号的登入注册以及游客登入的设计逻辑的问题。
- 以下设计解决了哪些问题？
- 解决了在设计登入注册找回密码以及游客登入这几个方面的逻辑顺序。
- 附：
- 主要功能
- 这里描述的是系统哪部分？
- 用户社交，店铺搜索以及进行店铺收藏评论的部分。
- 这部分面临什么样的问题？
- 面临在用户使用软件的几个主要功能时候的交互操作的逻辑。
- 以下设计解决了哪些问题？
- 解决了在设计界面主要功能时候。面临搜索店铺卡片，查看店铺介绍，收藏店铺，点评店铺。此外，从收藏的店铺中进行评论店铺。还有对社交部分的交互逻辑，设计点赞和评论的功能。
- 附：
PART 5 —— 实体关系图
- 这里描述的是系统哪部分？
- 这是系统内部各个部分之间的实体关系图。
- 这部分面临什么样的问题？
- 这部分将面对如何构建整体数据库与内部细分以及各数据库之间的联系问题。
- 以下设计解决了哪些问题？
- 使得各个环节与内部关系之间的联系更加的明确，更方便地在后续的编码过程里明确定义各实体对象。
- 附：
PART 6 —— 时序图
- 这里描述的是系统哪部分？
- 描述系统中各个对象之间发送消息的时间顺序，显示整个系统和用户之间的动态协作。
- 这部分面临什么样的问题？
- 系统各个部分及使用者之间的同步、异步等等时序逻辑的问题。
- 各个模块之间传递细节的差异问题。
- 以下设计解决了哪些问题？
- 描述了各个部分之间的消息通信，确认了模块间的请求、等待等等关系。
- 附：
PART 7 —— 泳道图
- 这里描述的是系统哪部分？
- 描述系统中各工作组工作规划流程，显示整个系统和用户之间的动态协作。
- 这部分面临什么样的问题？
- 系统各个部分及使用者之间的同步、异步等等时序逻辑的问题。
- 各个模块之间传递细节的差异问题。
- 以下设计解决了哪些问题？
- 描述了各部分内部连接关系以及各部分与部分之间的连接关系
- 附：
PART 8 —— 功能流程图
- 这里描述的是系统哪部分？
- 该部分描述了系统的核心功能实现的流程图
- 这部分面临什么样的问题？
- 处理图片切片、数据获取接口问题
- 算法实现稳定性问题
- 以下设计解决了哪些问题？
- 描述目标检测模块和文字识别模块间具体流程图
- 附：
PART 9 —— 功能实现图
- 这里描述的是系统哪部分？
- 这里描述了我们主要功能的实现步骤。
- 这部分面临什么样的问题？
- 系统各个部分间联系，并行部分的实现的问题。
- 模块间传递参数的不稳定性问题。
- 以下设计解决了哪些问题？
- 描述目标检测模块和文字识别模块间的关联以及内部实现的具体流程
- 附：
工具选择
本次作业团队的最终选择为 Process On
作业发布之后，团队就召集了一次小规模会议（因为比较突然，有部分人没能出席）。主要是在 Process On 和 Visio 两者之间进行选择。最终考虑到以下几点选择了Process On：
- Process On 可以很方便的在网页上打开使用，而 Visio 需要在机房电脑上重新安装
- Process On 的基本功能完全免费，而 Visio 则是需要收费的
- 团队中大部分成员都有使用 Process On 的经历，个别同学还是资深用户
使用后对工具的评价
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 40 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 40 | 60 |
| Development | 开发 | 445 | 500 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 150 |
| · Design Spec | · 生成设计文档 | 60 | 60 |
| · Design Review | · 设计复审 | 20 | 40 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 15 | 20 |
| · Design | · 具体设计 | 30 | 30 |
| · Coding | · 具体编码 | 120 | 120 |
| · Code Review | · 代码复审 | 20 | 20 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 60 |
| Reporting | 报告 | 50 | 60 |
| · Test Repor | · 测试报告 | 10 | 15 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 35 |
| 合计 | 535 |
评估成员的贡献分配
- 本队“临时队长”给出的“课上”贡献分评估
课堂贡献度
| 短学号 | 名 | “课上”贡献分 |
|---|---|---|
| 2507 | 俞辛(临时队长) | 14% |
| 2523 | 宏岩 | 14% |
| 1131 | 喜源 | 14% |
| 2502 | 柏涛 | 16% |
| 2431 | 源 | 16% |
| 2439 | 凯欣 | 13% |
| 2219 | 奇豪 | 13% |
| 2230 | 恺翔 | 0% |
| 2509 | 钧昊 | 0% |
| 2325 | 燊 | 0% |
说明：13%是最基础的贡献度，其中奇豪和凯欣都按时完成了任务，但是都进行了返工。而柏涛和源提前完成任务并且高质量完成任务。剩下的同学都是按时完成任务并且没有返工。0%贡献度的同学本次课请假没能参与，在线编程由于比赛会场的网络原因，只能给出适当修改意见。
课后贡献度
| 短学号 | 名 | “课后”贡献分 |
|---|---|---|
| 2507 | 燊 | 16% |
| 2523 | 宏岩 | 7% |
| 1131 | 喜源 | 7% |
| 2502 | 柏涛 | 7% |
| 2431 | 宇航 | 8% |
| 2439 | 志豪 | 7% |
| 2219 | 俞辛 | 8% |
| 2230 | 恺翔 | 20% |
| 2509 | 钧昊 | 20% |
说明：由于燊、恺翔、钧昊三人因比赛会场网络原因，没能及时将绘制的UML类图发给软工时间的各位导致了软工实践课程的其他同学工作量大。所以在课后的安排中将绝大部分工作都安排给了燊、恺翔、钧昊三人身上，所以这一次课后作业的大部分贡献度都分给了这三位同学。
个人心得
燊
- 首先作为团队的队长，没有参加这次软工现场实战，我感到十分遗憾。由于比赛时间冲突的缘故，再加上赛场网络限制的影响，我们很难参与到现场实战环节中。我们设计的UML类图也没有办法及时交付给现场的队友们。
- 我们只能通过后续采取的补救措施——承担课后作业的大部分工作量来尽量弥补我们“肝”到心累的队友们。我们后续做的燃尽图也尽量贴合实际完成了各模块及子模块工作的划分，希望能够在之后的alpha环节，跟大家一起取得更好的表现。
宏岩
- 对于这次团队作业，我本来应该是交换到别的队伍去完成任务的。但是由于我们组的三位成员外出参加比赛，团队内成员不足。经过和乐忠豪同学的沟通之后，他允许了我留在原组的请求，首先要在这里感谢他的理解！
- 本次作为团队成员，由于团队的人员较以前减少一些，加上临时队长比较温顺，所以团队的氛围相较以前会显得沉寂一些。但是大家都可以专注于自己的任务，并及时的沟通，但是沟通只限于两三个人之间，没有整组成员没有进行过共同的交流。评价被换进来的三位同学，他们在和我们明确了软件的功能之后，迅速的的完成了各类UML图的制作，但是却存在着质量不高的问题，有几张UML也被队长退回修改多次（可见临时队长真的很严格）。接下来评价一下新的队长，和老队长相比，新队长显得温顺一些，不能调动起大家的积极性，团队缺少共同的交流机会，这应该是新队长要加强的地方。但是新队长会比老队长有更严格的要求。对我们的贡献度评分也很公平公正，并在最后下课的时候也给我们解释了评分原因，这也是老队长应该向新队长学习的。
- 总而言之，对于这次集体作业，感谢大家可以积极配合认真的完成各自的任务，队长有条不紊的进行汇总并按时提交，学习了大家身上的优点，带给我很多的思考。
喜源
- 本次课堂UML设计迎来了一个特殊环节——团队换人环节。身为一个没有被换走的队员来说，在换队之前，一想到别队的成员来我们队帮忙做UML还是挺害怕的，因为UML设计需要对整个软件有深入的了解，而一个不是本组的人做起来会不会很吃力？
- 但是事实发现，新队友还是很强的，简单的沟通后就明白了自己负责的图形应该是个什么样。整体来看，我们在临时队长的带领下，整个过程井然有序，完全不输原队长。新团队的氛围很平静，讨论比较少，各做各的，分工得当。原团队讨论会比较多，这是新团体所欠缺的。
柏涛
- 本次团队任务为增加趣味性，采取互换团队成员的形式。我很幸运没有被换到其他组去。
- 对临时队长的感受：
- 1.在三位成员请假，队长不在的情况下，我们的副队长勇于承当重任，主动肩负起带领全队的责任，对团队各成员的任务进行合理分配，调度协调，确保了各成员工作的顺利开展。
- 对被换来的新队友的感受：
- 1.与被换来的新队友一起工作，由于大家彼此都不认识，在工作时少了嬉闹，大家都认认真真的干活，更加高效；
- 2.由于大家都不熟悉，没什么顾忌，可以直接指出对对方方案的不足。利于方案的改进。
- 3.常说“物以类聚，人以群分。”能组成一个团队，很大可能是同一类人，有着相似的思想。换来的新队友来自另一个完全不同的团队，有着与原来团队截然不同的思想，站在一个全新的角度思考问题，更容易想出新的创意，为团队注入新鲜血液。
- 新旧团队氛围对比
- 1.新团队比旧团队多了几分严肃，少了几分欢乐。优点是可以更加高效地工作，缺点是工作变得无趣枯燥。
宇航
- 本次作为幸运的被选中的交换队员，体验了一次别的组的工作氛围，仅仅是这一次uml团队作业来看（两队风格差异明显，但从最后成果差异不大，另外对于“拖鞋旅游队”的工作氛围可能只体验了一次，感受是片面的）。
- 相比于原队伍，其他队伍优点：行动力很高，缺点：工作氛围交流沟通有所欠缺。“拖鞋旅游队”临时队长分工明确，制作uml图时每个图都有对应的队员分工，临时队长和原队长风格不同，但是对于分工都是很明确的。
- 从行动力上看，“拖鞋旅游队”的执行力很高，各个成员很快就完成了自己的工作。但是对于制作不同uml图的队员之间缺乏沟通。对于我个人来说，更喜欢原队伍的工作氛围，队员之间沟通交流多，在明确分工的前提下互帮互助，原队伍的执行力也是很高的。
- 同时也感谢这次交换机会，能感受别的队伍的工作氛围，有幸能在“拖鞋旅游队”中参与他们项目的一部分（uml图设计制作），感受了这一队伍的行动力（很赞的）。最后除了上面几点的差别，在我看来两支队伍都是很优秀的。
志豪
- 作为被换走的临时队员，我内心是有些拒绝的。从一个熟悉的环境到陌生的地方合作，总会有种强烈不适应的感觉。刚开始的确有些尴尬，看着旁边两三个同学谈笑风生，玩着我不是很懂的梗，硬接两句，更尴尬了。还好我脸皮够厚，还好尴尬总会被工作冲淡，也要感谢赵畅同学以及他们小组成员的热情款待。我在这一组并不会被孤立，相反，在我的积极争取下，还能多做一个图，得到了不错的贡献分。
- 虽然我觉得我做的图比较简单，给的贡献偏高了，但至少这次换组我仍然能够实现自己的价值。即食组的工作氛围还是很活泼的，但行动力和执行力也很强，谈笑风生中把任务做完，这是能力强的表现。
- 在一上午的接触看来，在工作中，临时队长赵畅同学比我们的林燊大哥更随和一些，也可能是因为我是新来的组员。林燊组长在工作中更为严肃，把工作和生活分的很开，气场很强，工作效率也很高。两组各有优劣，今后要更加努力，在林燊和宏岩的带领下实现一个又一个“稳”。
俞辛
- 其实做为临时队长，我的感受没有太多的不同。我认为这是因为从一开始我就对团队很上心，每次团队作业参与度都很高。所以很自然而然的就接过了临时队长的任务。
- 至于新换来的同学，执行力都很强，而且会主动承担任务。印象最深的就是源，在作业发布之后就联系了我们，和我们一起对作业的一些细节进行了讨论，所以在贡献度的分配上他也得到了最高分。
- 因为这次有了新的队员，队内的几个开心果这次也都没能到场，所以一开始团队氛围显得很沉闷。后来经过我和宏岩的一些斗嘴，气氛慢慢活跃了起来，大家之间得沟通交流也多了起来，效率一下就上去了。所以说不论从个人体验还是从对团队的贡献而言，维护一个好的团队氛围还是很有必要的，这也算是队长的一个责任吧。
- 满分10分，给自己这次的临时队长打个9分，小小自恋一下:-）唯一不足的就是没能让远在青岛的三个小朋友一起参与进来。
恺翔
- 由于本次外出时，虽然我们在线上制作了很多类图，但是由于所在会场的网络环境不好，导致我无法及时上传类图，与软工小伙伴们同“肝”共苦，心里十分内疚，于是我和钧昊决定完成剩余文档的全部制作，来弥补小伙伴们的损失和他们的精神损失。而且听说今天来了一个换组游戏，我觉得这次没有参与进去感到十分可惜，如果有下次的话，希望能够体验一下。
- 我在课后也尽力承担下课后的任务，并且添加上我们绘制的UML图，以及框架图。下次作业我们也会尽力承担更多的任务的。
钧昊
- 本次由于早上同燊、恺翔两人比赛答辩，且由于会场的网络条件限制，做好的UML类图无法发给团队的其他同学，只能通过提出一下修改意见的方式来完成UML设计的实现。其实我是很期待能够体验一下在陌生的团队中共同完成设计开发。可是碍于时间冲突，没有办法很好完成。
- 期待下一次能够再有这样有趣的的点子来活跃软工团队的气氛，这里我也想提供一个可能比较有趣的点子： 在答辩环节交换成员，怼自己组的场景简直不要要有趣。