福大软工 · 第八次做业（课堂实战）- 项目UML设计（团队）

团队信息

• 队名：火箭少男100
• 本次做业课上成员

短学号	名	本次做业博客连接
2507	俞辛(临时队长)	http://www.javashuo.com/article/p-wbhimzck-ce.html
2523	宏岩	http://www.cnblogs.com/031602523liu/p/9822823.html
1131	喜源	http://www.cnblogs.com/comeony/p/9823369.html
2502	柏涛	http://www.cnblogs.com/cbattle/p/9823300.html
2431	源	http://www.cnblogs.com/circlek/p/9823269.html
2439	凯欣	http://www.cnblogs.com/ykxx/p/9822397.html
2219	奇豪	http://www.cnblogs.com/S031602219/p/9822576.html
2230	恺翔	http://www.cnblogs.com/leolkx/p/9823308.html
2509	钧昊	http://www.cnblogs.com/tomvii/p/9823307.html
2325	燊	http://www.cnblogs.com/linshen/p/9823348.html

• 原组成员

短学号	名	本次做业博客连接
2325	燊(队长)	http://www.cnblogs.com/linshen/p/9823348.html
1232	志豪	http://www.cnblogs.com/dldr/p/9823347.html
1131	喜源	http://www.cnblogs.com/comeony/p/9823369.html
2523	宏岩	http://www.cnblogs.com/031602523liu/p/9822823.html
2230	恺翔	http://www.cnblogs.com/leolkx/p/9823308.html
2509	钧昊	http://www.cnblogs.com/tomvii/p/9823307.html
2507	俞辛	http://www.javashuo.com/article/p-wbhimzck-ce.html
2501	宇航	http://www.cnblogs.com/mercuialC/p/9823310.html
2502	柏涛	http://www.cnblogs.com/cbattle/p/9823300.html

团队分工

分而治之

• 在划分具体工做模块上，咱们也更愿意从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
• 交付件便可独立实现且与其余模块的耦合度较低的功能模块。
• 对于咱们的主功能——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 —— 用例图

1. 我的管理系统和登陆系统

• 这里描述的是系统哪部分？
  • 这里是用户我的管理系统和登陆系统的用例图。
• 这部分面临什么样的问题？
  • 这部分要面临用户登陆、注册验证、忘记密码的基本问题，用户的管理系统涉及我的信息维护、系统缓存和恢复加载等问题。
• 如下设计解决了哪些问题？
  • 展示了客户与咱们软件之间的交互联系，便于咱们对用户我的管理系统和登陆系统的可视化和软件原型设计，使用户可以理解使用登陆和我的信息的联系，更方便操做，并使开发者可以有条理的实现这些元素。
• 附：

1. 社区管理系统

• 这里描述的是系统哪部分？
  • 这里是社区管理系统的用例图。
• 这部分面临什么样的问题？
  • 这部分要面临搜索店铺，推荐店铺等算法问题，以及查看附近动态的及时性。
• 如下设计解决了哪些问题？
  • 展示了社区管理的基本框架，便于咱们对社区系统的可视化和软件原型设计，用户能够经过这个图更加理解社区的基本功能，便于操做。
• 附：
  

PART 2 —— 类图

• 这里描述的是系统哪部分？
  • 描述了系统每一个部分之间的关系、链接状况。
• 这部分要面临什么样的问题？

  • 对于Yolo和CRNN类的使用，须要使用预先训练的参数。参数的训练，须要包含大量数据的数据集，然而，如今尚未有针对性的已经标注好的数据集，这就须要咱们手动收集数据，进行标注，须要大量的人力物力。

  • 卷积运算须要强大的运算能力支持，较低端的单核CPU服务器计算能力较弱，可能没法知足实时性的需求。将会采用更高性能的CPU服务器甚至GPU服务器。可是这样成本较高。
• 如下设计解决了哪些问题？
  • 解决了开发者对于各个类体之间关系的宏观认识。
• 附：
  

PART 3 —— 活动图

• 这里描述的是系统哪部分？
  • 描述软件的大体使用流程，以及店铺扫描、评论分享功能的使用流程。
• 这部分面临什么样的问题？
  • 用户在使用软件的时候流程较为复杂，活动图能够帮助用户梳理整个软件的使用流程。
• 如下设计解决了哪些问题？
  • 帮助用户理清软件的使用流程，明确各个功能的使用细节。
• 附：
  

PART 4 —— 状态图

1. 登入界面

• 这里描述的是系统哪部分？
  • 用户登入注册的部分。
• 这部分面临什么样的问题？
  • 面临帐号的登入注册以及游客登入的设计逻辑的问题。
• 如下设计解决了哪些问题？
  • 解决了在设计登入注册找回密码以及游客登入这几个方面的逻辑顺序。
• 附：
  

1. 主要功能

• 这里描述的是系统哪部分？
  • 用户社交，店铺搜索以及进行店铺收藏评论的部分。
• 这部分面临什么样的问题？
  • 面临在用户使用软件的几个主要功能时候的交互操做的逻辑。
• 如下设计解决了哪些问题？
  • 解决了在设计界面主要功能时候。面临搜索店铺卡片，查看店铺介绍，收藏店铺，点评店铺。此外，从收藏的店铺中进行评论店铺。还有对社交部分的交互逻辑，设计点赞和评论的功能。
• 附：
  

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 的经历，个别同窗仍是资深用户

使用后对工具的评价

• 本次做业采用了Process on实现，虽然简单易用，可是在功能上仍简略了许多。
• Process On提供基于云服务的免费流程梳理、创做协做工具，与团队成员之间协同设计，实时建立和编辑文件，并能够实现更改的及时合并与同步，这意味着跨部门的流程梳理、优化和确承认以即刻完成。
• 在结束课程后的设计，咱们大部分仍是采用了 Visio 实现.
• Visio集成了多种模板能够快速完成开发，虽然在安装上较麻烦，可是使用上高效性仍不输于Process On

PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	35	60
· Estimate	· 估计这个任务须要多少时间	35	60
Development	开发	445	500
· Analysis	· 需求分析 (包括学习新技术)	100	150
· Design Spec	· 生成设计文档	60	60
· Design Review	· 设计复审	20	40
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	30	20
· Design	· 具体设计	15	30
· Coding	· 具体编码	120	110
· Code Review	· 代码复审	20	20
· Test	· 测试（自我测试，修改代码，提交修改）	60	60
Reporting	报告	40	60
· Test Repor	· 测试报告	20	20
· Size Measurement	· 计算工做量	10	5
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	30	35
	合计	510	610

评估成员的贡献分配

• 本队“临时队长”给出的“课上”贡献分评估
  

课堂贡献度

短学号	名	“课上”贡献分
2507	俞辛(临时队长)	14%
2523	宏岩	14%
1131	喜源	14%
2502	柏涛	16%
2431	源	16%
2439	凯欣	13%
2219	奇豪	13%
2230	恺翔	0%
2509	钧昊	0%
2325	燊	0%

说明：13%是最基础的贡献度，其中奇豪和凯欣都按时完成了任务，可是都进行了返工。而柏涛和源提早完成任务而且高质量完成任务。剩下的同窗都是按时完成任务而且没有返工。0%贡献度的同窗本次课请假没能参与，在线编程因为比赛会场的网络缘由，只能给出适当修改意见。

课后贡献度

短学号	名	“课后”贡献分
2507	俞辛	8%
2523	宏岩	7%
1131	喜源	7%
2502	柏涛	7%
2431	宇航	8%
2439	志豪	7%
2219	燊	16%
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设计的实现。其实我是很期待可以体验一下在陌生的团队中共同完成设计开发。但是碍于时间冲突，没有办法很好完成。
• 期待下一次可以再有这样有趣的的点子来活跃软工团队的气氛，这里我也想提供一个可能比较有趣的点子： 在答辩环节交换成员，怼本身组的场景简直不要要有趣。