【观隅】项目展示
项目与团队亮点
成员分工和项目管理
整体上采用模块式开发，因此在任务分配上直接将模块对应到具体成员即可。成员分工具体如下：
前端：
| 成员 | 分工 |
|---|---|
| LYL | 架构设计、环境设置、UI优化、代码整合 |
| DSY | card模块、数据集画廊模块、首页设计、数据集详情页、可视化页面、数据画廊 |
| LXY | 分页控制、侧边栏、加载动画 |
后端：
| 成员 | 模块 | 备注 |
|---|---|---|
| WPB | 数据集解析模块 | 负责数据集解析引擎的实现 |
| YZM | 可视化模块 | 负责后端中与可视化有关的API，实现图层的绘制 |
| GTC | 数据集、配置文件等模块 | 负责后端中与数据库相关的内容，包括表的定义与相关API的实现 |
| MR | 后端的其他模块 | 参与数据库相关API的实现 |
在Alpha阶段的开发中，我们主要使用 Docs 仓库中的Issue进行项目管理，如下图所示，详细说明请参见下文中“项目管理”部分。
典型用户场景
本项目主要考虑到入门深度学习的高校学生、模型设计与模型优化等相关从业者、深度学习相关研究者、深度学习方面课程的教师四大典型用户。
入门深度学习的高校学生
- A同学，刚选了一门叫“计算机导论”的课程，就被要是要求实现xxx神经网络的训练，该同学不太理解数据集中的标注，于是打开了本软件，导入下发的标注好的数据集，本软件提供的可视化的标注信息能帮助他快速理解标注的意义，他同时可以和其他同学一起查看并共同讨论，使他更容易的理解课程内容。
- 相关功能：数据集搜索，数据集概述，数据集条目总览，数据集条目详细可视化
模型设计与模型优化等相关从业者
- B工程师，盯着训好的目标网络，再看看效果不佳的测试集，无法找出其中的原因。使用本软件，可以查看数据集中的标注情况，让他对难以完成的调优工作有了一丝思路，同时还可以可视化的与同事讲解，交流可能的问题。使他更轻松的完成工作。
- 相关功能：数据集条目交互，自定义数据集上传（Beta版本），信息反馈
深度学习相关研究者
- C研究员，刚读完顶会的最新paper，准备复现一下实验，于是先下载了数据集，使用本软件查看数据集中的标注情况，同时保存了一些图片，为之后的组会presentation，论文中的插图做了不少准备。本软件使他更轻松的完成科研。
- 相关功能：数据集搜索，数据集条目总览，数据集条目详细可视化
深度学习方面课程的教师
- D讲师，为了在课堂上展示数据集的标注工作，于是打开了本软件，向同学们展示标注好的可视化数据集。使用本软件，让同学们更容易的理解数据集的标注工作，拉近了师生距离，使用本软件，让老师们更轻松的完成了教学任务。
- 相关功能：数据集浏览，数据集搜索，数据集概述，数据集条目总览，数据集条目详细可视化，数据集条目交互，信息反馈
特色功能
杀手级功能
我们的杀手级功能是：数据集可视化和数据集可视化交互。分别指的是对数据集的各个条目进行可视化，和在这个基础上，可以选择性显示如蒙版(mask)，标签(label)，物体(object)等标注情况的可视化结果。
竞品比较
✔：完全实现相关功能，可以满足用户需求
✖：未实现相关功能，不能满足用户需求
⭕：部分实现相关功能，部分满足用户需求
| 功能 | 观隅(Ours) | 格物钛 | 各数据集简介界面 |
|---|---|---|---|
| 数据集概述 | ✔ | ✔ | ✔ |
| 数据集条目详细可视化 | ✔ | ✔ | ⭕ |
| 数据集条目交互 | ✔ | ✔ | ✖ |
| 数据集浏览 | ⭕ | ✔ | ✖ |
| 数据集条目总览 | ✔ | ✖ | ✖ |
| 数据集搜索 | ⭕（即将增强） | ⭕ | ✖ |
| 数据集本地管理 | TODO | ✖ | ✖ |
可以看出，我们相比于各数据集简介界面，提供了聚合且丰富的可视化方案。而相比较于比较成熟的数据集可视化平台格物钛，我们由于数据集积累较少，在数据集种类上有所欠缺。但是已经有的数据集，我们提供的主要功能已经可以媲美，而且存在差异化的数据集条目总览功能，这是格物钛没有的。我们还即将对格物钛做的不够好的搜索功能进行增强，并且提供更具安全性的数据集本地管理功能。
项目发布
项目推广
我们将开发环境服务器的配置部署到生产环境，做针对性的配置优化，增加域名以方便用户访问
同时，我们还在朋友圈、QQ空间、机器学习交流群等渠道分享项目引流
项目日活
定义：日活跃用户是指在网页停留超过5min的用户，日点击量是进入网页的用户数。同时我们引申出来日活跃用户转化率的概念，指日活跃用户数/日点击量。
| 5.13 | 5.14 | 5.15 | 平均 | |
|---|---|---|---|---|
| 日活跃用户数 | 28 | 40 | 31 | 33 |
| 日点击量 | 44 | 63 | 50 | 52.3 |
| 日活跃用户转化率 | 63.63% | 63.49% | 62% | 63.06% |
实际日活
实际点击量
点击量向活跃用户的转化率
用户反馈
| 功能反馈 | 团队意见 | Bug反馈 | 团队意见 |
|---|---|---|---|
| 登录账号，添加收藏 | 可以在Beta阶段添加相关功能 | 加载数据集图片时加载提示不充分 | 已添加Loading样式 |
| 加入一些经典RNN数据集 | 将添加atis、Conll2003等数据集 | 搜索无结果时提示不充分 | 已记录 |
| Gallery界面加入指定页面跳转 | 可以在Beta阶段添加相关功能 | ||
| 左上角加入退回按钮 | 可以在Beta阶段添加相关功能 | ||
| 将分类和标签页面进行分割 | 可以在Beta阶段添加相关功能 |
反馈截图：
Bug反馈：
总体都是对前端的展示效果的反馈，是我们在用户需求分析阶段没有充分注意到用户的使用场景所造成的，属于意料之外的Bug。
软工质量
文档与代码规范
我们的项目配备了相应的文档，可以帮助用户和开发者快速上手本项目
- 后端项目使用Swaager建立了完善的前后端接口文档，以及数据库设计文档.md
- 数据集解析引擎以及配置文件相关内容形成了详实的文档，并在网站上公开以供预览，将在beta阶段继续晚上并正式放出功能。数据集描述文件结构
- 前端项目为了方便上手创建了readme文件，展示了基本的工作流程，起到指导作用。同时代码中有丰富的注释。项目仓库
前后端项目均有对相应的代码规范
- 前端强制执行代码规范
- 使用eslint工具对代码规范进行检查并在ci中进行配置，不通过者pipeline会失败
- 使用prettier工具对代码风格进行检查，并配置相关命令进行自动修复
- 采用husky设置GitHook，每次commit时都将触发进行代码格式的自动修复和Ts检查
- 后端提供代码规范，但没有强制执行，将在beta阶段逐步开启强制执行
- 使用pylint工具和pylint-django插件进行代码规范的检查，并在ci中进行配置
项目可继承性
前后端项目的代码均遵照相应的规范配置，熟悉相关技术栈的人都可以快速上手。
后端无需额外配置，直接按照普通的django项目运行即可。
前端提供了readme文档对编译运行项目提供了指导。
后端项目较为简单，仅在必要地方添加了注释，前端项目由于使用typescript这一新工具，给出的注释也相应更多。
单元测试
后端项目部署了单元测试，对除了数据解析引擎/可视化等难以测试的部分外的代码进行了测试。去除上述部分后项目整体覆盖率为71.25%。针对客户最常接触的接口均配置了测试用例。
前端项目配置了单元测试相关插件，但并未真正启用。因为项目以可视化为核心，需要人进行确认，实现端到端的测试。为了保证软件质量，我们要求前端项目开发者必须在本地测试后才可上交。
CI/CD
项目整体采用CI/CD加速工作流程，及时发现问题并持续集成。
后端项目采用CI/CD对每次提交进行代码规范检查和单元测试，及时发现基础问题。同时检查是否有没提交的migration，保证部署的正常进行。在master和develop分支上的提交会，项目会在服务器上自动构建，并推送方便部署的镜像形式至腾讯云镜像服务仓库，master分支和develop分支使用不同的镜像。此外我们还配置了自动部署功能，develop分支的改动都会在开发服务器上实时显示供大家实验，master分支的改动则发布至生产服务器，只有在开发环境验证过的内容才会移动至生产服务器上。
前端项目也在develop和master分支上配置了类似的自动构建/部署功能。同时前端CI/CD会对语法和单元测试进行检查并尝试编译，如果都没有问题才会进入构建部署。
CI/CD的使用极大加速了项目的开发，前端可以不需要掌握后端部署方式的情况下完成开发和测试工作。
经验教训与Beta计划
Alpha阶段中，由于在计划阶段完成任务过于匆忙简陋，整体开发进度和过程都不是很令人满意。即使利用了各种包括CI/CD、API文档等技术手段和代码规范来约束和规范开发的过程，仍然会在开发中遇到描述不够清晰的问题。即使是敏捷开发，人员之间的交流仍然是一个难点。然而计划阶段是很难预料到产品开发过程中会出现什么问题的。beta阶段，我们会更加注重计划上所花的时间，同时考虑参考其他小组，安排固定时间线下共同开发，提高开发效率，减少不必要的时间。
项目与团队总结
项目管理
团队成员简介：https://www.cnblogs.com/RiddleMan/p/14655399.html
个人博客地址：
经验教训--关于轮值PM
在Alpha阶段开始之前，我们预采用了轮值PM的方式，即每周由不同的成员担任PM，这样能够使得团队所有成员都有从整体上对项目进行观察的和具体投身开发工作的机会。但是，在具体实践中这样的方式出现了一些问题，造成了其效果与预期的偏离。这一偏离主要体现在，首周PM使用Swagger完成了接口API，这一工具有一定的上手难度，造成第二周开发过程中对API文档进行修改的工作也大多是由第一周PM完成的。从结果上来看，第二周PM的工作仅是例会的组织与例会报告的编写，而一些接口上的同步工作则由其他成员承担，造成了PM名实不符的现状。
在Beta阶段的开发中，将直接指定一位PM。
项目管理办法
我们使用GitLab提供的Issue，Milestone，Wiki对项目进行管理。
我们通过Milestone和Issue为项目创造了不同粒度的任务，并进行管理。
我们在Wiki中通过日报的形式记录例会之间各成员的工作情况。
分工协作
Alpha阶段刚开始的时候，我们采取的分工机制为“任务发配制”。即每进行一次例会，就由leader给相应的组成员分配相应的任务。不过经历了三四次例会后，进度却十分缓慢。经过分析和思考后发现其相应的弊端如下：
- 成员每次将下一次例会的时间作为dll，导致具体任务的交付往往集中在每一次例会冲刺的最后一部分时间。由于验收的时间点过晚，导致
leader无法在下次例会开始前给出修改意见并做出整改，因此不得不把重新设计或一些需要改进的部分放到下一次例会所分配的工作中，由此新模块的开发难以进行。 - 团队无法对整体的工作量进行一个把控，因为每次发配任务只从这次要完成的任务的角度出发，没有思考总共还有哪些工作需要完成。除此之外，完成了此次的任务，由于要等到下一次例会进行分配任务，成员不知道闲余的时间去完成哪些工作。
leader由于有很多其他的非软工的事情要去做，因此一人承担任务规划与分配的工作，负担过重。应该让成员也帮忙出谋划策，参与到任务的设计与规划中去。
因此在开发阶段进行到一半的时候，我们更改了分工方式，即“任务池机制”。即每隔一个较长的时间段（例如两到三次的例会间隔），时间段开始时团队成员一起思考还有哪些工作尚未完成，取最近最迫切的一个大的任务板块进行任务细分工作，说明每一条工作要实现的东西，并放进在gitlab的一个帖子中去（即一个任务池）。成员自己去任务池中领取相应的任务，并且标注loading...的字段与签署个人名称，表示自己会承担这一部分的任务。其他成员只能领取尚未被领取的任务。截图如下：
用这种方式去进行分工协作，相较于之前的“任务发配制”，有很多改善：
- 成员知道新的大任务板块总共有哪些小任务，可以选取几个有联系的小任务去进行完成，弥补了之前“成员不知道还有哪些任务”的短板。
- 成果展现的较快，因为每次完成一个小任务成员就将其提交至主分支，
leader可以尽快的进行验收以及给与反馈。 - 团队可以调整自己的开发节奏，当剩余任务量较多时加快开发速度，较少时可以稍微放松。
不过“任务池机制”也有以下缺点：
- 任务无法做到平均分配，有精力且有时间的成员会去承担更多的任务，而剩下的成员可能会去摸鱼。
- 非常依赖于每个时间段开始时所商讨的总任务的过程。倘若小任务的描述不够清晰，成员仍然会有很多不清楚的地方，有时会较难以进行开发。
alpha阶段中间开始一直到最后我们使用的都是“任务池机制”，虽然还有些缺陷，不过却帮助我们在一定程度上解决了分工协作问题。beta阶段我们会对该分工协作进行进一步的改善。
沟通对接
我们的沟通对接是这样的，前端和后端存在一名leader，负责本部分的整体框架设计，前后端部分各自和自己的leader沟通，前后端之间的接口规范由leader之间进行沟通。沟通方式包括线下沟通和线上腾讯会议沟通，详情可见 谜语人队 Scrum Meeting 博客汇总。
实际进展
观察上述燃尽图，有以下几个发现：
- 存在“摸鱼期”，例如第三周与第七周的燃尽图为水平，表示这两周没有完成相应的工作
- 整体看上去完成度似乎较为良好，任务按时间线较为有规律的推进中
但是这与我们实际的开发体验严重不符，实际开发中冲刺阶段完成的任务量过少，大部分的任务集中在了每日例会结束过后，而这一时期我们并没有记录相应的燃尽状况。思考了一下，燃尽图与开发过程不符合的原因有以下几点：
- 初期规划做的过于潦草，相应的工作要么划分过大，要么就有许多任务为加入到燃尽图规划的任务列表中。任务划分有非常大的问题。
- 团队的开发不依赖于燃尽图，即对燃尽图中的任务会有较大的忽视，导致燃尽图不能反映我们真实的开发情况。
工作量
| 人员 | 岗位 | 工作量 | 贡献分 |
|---|---|---|---|
| GTC | PM，后端 | 完成了数据库设计文档，总计60行 完成并维护了API文档，总计719行 完成了三次例会报告编写 进行了一次发布推广 在后端编写了数据库相关定义与API代码，共计217行 在后端编写了数据库相关API的单元测试，共计约100行 |
49 |
| MR | PM，后端 | 后端代码总行数184行 | 47 |
| YZM | 后端开发与测试 | 后端代码量总计634行 参与可视化模块和统计模块的API编写 完成了可视化模块和统计模块 完成了统计模块的单元测试编写 对可视化图片进行压缩减少带宽压力 进行了一次发布推广 |
50 |
| WPB | 支援 | 后端代码量总计655行 完成前后端CI/CD配置 完成数据集描述文件的初步设计和文档 完成数据集解析引擎的初步实现 完成服务器的部署 在空间进行推广 为网站设置域名进行推广 |
53 |
| LYL | 前端 | 前端代码总计1444行 参与了前端的CI/CD与开发工具链、项目骨架的构建 配置了前端的Axios请求部分的代码与注释，给出各部分的最佳实践 详情页Markdown渲染展示 路由Bug修复与部分CSS修正 |
51 |
| LXY | 前端 | 前端代码总计1361行 前端导航栏 反馈页面 gallery和data gallery的分页与接口 详情页侧边信息栏 data gallery的loading |
48 |
| DSY | 前端 | 前端代码总计3314行card模块的设计与编写主页布局设计与代码编写 数据集画廊代码编写 数据集详情页面的布局设计 详情页面头部代码的编写 详情页面数据画廊的设计与编写 单个数据的可视化详情页面的设计与编写 |
52 |
用户场景相关
开发前目标
总访问量达到500人次，日访问量达到20人次
预期功能
| 模块 | 功能 |
|---|---|
| 主页 | 提供引导、功能入口 |
| 管理数据集 | 查看，管理数据集 |
| 设置页面 | 控制个性化选项 |
| 反馈界面 | 用户提供反馈 |
| 数据集内容查看 | 查看数据集具体内容 |
| 数据集格式解析 | 形象解析数据集格式 |
- 管理数据集功能——用户可以自行添加我们所支持的种类的数据集，或者删除曾经上传过的但不再需要的数据集。
- 查看数据集功能——对于用户所上传的合法数据集，我们会对该数据集进行可视化处理并展示。
- 筛选数据集功能——我们会分析数据集的"格式配置文件"，并得出一些可以用作筛选的字段，用户可以选择某一字段并输入相应的筛选范围，我们会先将结果筛选后再进行可视化处理与展示。
- 解析数据集功能——我们可以对所展示的可视化载体上标出该数据集格式文件每一字段所表示含义的位置，以辅助用户理解每一字段的含义
- 反馈功能——用户可以向我们进行反馈
发布功能
| 功能 | 具体描述 |
|---|---|
| 数据集浏览 | 用户可以在主页画廊中浏览已经预支持的多种类型的多个数据集的概要信息 |
| 数据集搜索 | 用户可以模糊查找所需的数据集 |
| 数据集概述 | 用户可以在数据集的详情页中查看数据集的概要信息 |
| 数据集条目总览 | 用户可以在数据集的详情页中查看数据集条目可视化的总览 |
| 数据集条目详细可视化 | 目前共支持三类数据集，以下分类介绍： 1. MNIST数据集，能够显示图片以及分类情况 2. 语义分割类数据集，能够显示图片、可开关的图层与额外信息，确定不同语义区域及其解释 3. 目标识别类数据集，能够显示图片、可开关的框图和额外信息，确定不同目标及其解释 |
| 数据集条目交互 | 用户可以显式控制数据集条目内可视化图层的具体显示情况 |
| 信息反馈 | 用户可以对现有功能和可能出现的Bug进行反馈 |
是否满足全部场景
未满足全部应用场景，例如模型设计与模型优化等相关从业者的应用场景，需要使用本地部署端上传个人数据集进行可视化，这部分将在Beta阶段实现
用户评价
对深度学习有所接触的同学：
深度学习相关从业者：
