【二食堂】Beta - 项目展示

项目展示

1. 团队介绍

二食堂很难排队

姓名		介绍	职务
刘享		热爱游戏，尤其是RPG和metrovinia类的游戏。 会C/C++, python, java。	后端
左正		一个普通的大学生，Python、HTML、PHP、JavaScript、Ruby、Basic，这些都不会。会一点点C和Java，喜欢看动漫、打游戏，有丰富的赶ddl经验。	后端
李健		会C，Java，以及那么一丁点的C++和C#，总结：狭义上的菜。	前端
柴博		这里6系底层玩家，技术了解过很多，没有精通，主攻休闲游戏，喜欢各种。	前端
窦铮		C C++ java 都会一点，不精通，开发工作更喜欢前端一点。美剧迷。	测试
刘阳		写过c++，java，熟练度一般，了解过ruby，没有熟练度。Debug苦手，守夜冠军。团队开发经验较少，但可以保证DDL。	PM

点击姓名跳转至成员个人博客

2. 工程相关的问题

团队项目的目标，预期的典型用户，预期的功能描述，预期的用户数量

• 项目的目标

  实现一个互联网上面向特定领域的专业知识文本中知识的提取系统，对给定的专业书籍文本，对文本中的专有名词术语（实体）和不同术语指代对象之间关系进行标注，构建专业领域的知识图谱，支持多用户协同标注，能够记录每个标注数据的来源并同步更新；支持对标注的文本对应的实体进行链接，通过图形化的界面对标注结果进行展现，并支持双向的定位。

• 预期的典型用户

  王亨利

  用户信息	用户情况
  姓名	王亨利
  用户身份	某高校本科学生
  知识层次/能力	就读于某理工科专业，专业能力较强。对本专业知识有一个较为全面的了解。
  生活/工作	日常学习十分认真，课前预习课后复习。烤漆不抱佛脚。
  用户动机	希望期末复习时能快速地构建某门课程的知识图谱，帮助加深记忆。
  用户困难	构建知识图谱时，手写工作量大；使用画图软件操作别扭，排版比较费时间。
  典型场景	期末复习，王亨利决定将专业知识“过一遍”。他将相关专业书籍导入应用，快速地浏览了一遍课本，将一些重要的概念标记出来并标注关系。标注完成，他可以快速地生成知识图谱。
  用户偏好	专业术语勾选便捷，实体之间的关系类型丰富，快速生成图谱。
  用户比例	60%

  李约翰

  用户信息	用户情况
  姓名	李约翰
  用户身份	某高校教师
  知识层次/能力	专家
  生活/工作	负责某一专业课程的授课
  用户动机	某一年课改，准备更新原有的讲义和PPT，要在其中插入专业知识图谱。
  用户困难	专业知识体系庞杂，构建知识图谱工作量巨大。
  典型场景	李约翰老师找来了几位同事/学生，大家同时在应用中标注实体，可以很快完成知识图谱的构建
  用户偏好	协同标注更新同步，操作简单快捷
  用户比例	20%

  乔保罗

  用户信息	用户情况
  姓名	乔保罗
  用户身份	某高校计算机专业研究生
  知识层次/能力	熟悉机器学习
  生活/工作	在实验室做研究，主攻机器学习。
  用户动机	希望把知识图谱作为训练数据来进行特征学习。
  用户困难	知识图谱构建困难。
  典型场景	保罗同学找来了相关地书籍，手动进行标注。最终将知识图谱以数据地格式导出，用于机器学习。
  用户偏好	导出地数据结构清晰明了。
  用户比例	20%

• 预期的功能描述

  在Beta阶段的计划阶段，我们的预期功能描述参考博客Beta设计与计划

• 预期的用户数量

  Beta阶段发布后一周内，用户注册累计200人，新建项目300个。

事先定义的软件下载量达到了么？为什么没有达到？

截止6月9号，注册用户135人，新创建项目147个。没有达到预期的目标。分析原因：

• 推广力度不够，只在北航6系内部进行了推广。
• 项目功能不够吸引人。今年6系烤漆基本没有考试，相对而言计算机学院的专业术语较少，知识脉络也比较清晰，构建知识图谱进行复习不是刚需。

总之项目的功能没有太多娱乐元素，不够吸引人。有上手难度，需要花费二十分钟以上时间进行摸索，很容易劝退新人。可以考虑在网页中添加新手指引功能。

团队的成员如何分工协作的？有什么经验教训？

成员	分工
刘享	后端，负责好友邀请部分的开发
左正	后端，负责图谱部分后端的开发。
柴博	前端，主要负责EChart部分知识图谱的渲染。
李健	前端，主要负责文本区域地开发。
窦铮	测试
刘阳	PM

后端负责接口开发，前端进行页面开发。PM进行原型设计以及沟通前后端工作。

经验教训：测试与后端不能完全分离，后端写完代码应该进行一些简单的单元测试。测试要尽早，等前端发现bug会严重耽误项目的进度。

团队是如何进行项目管理的？

我们使用了github进行项目的记录和管理。点击访问

1. PM对Beta阶段的任务进行规划，做出原型设计，将任务划分为三周时间完成。
2. 每周开始给每位成员分配对应的任务，由组员自行安排。PM在每天的例会上追踪成员的任务进度。
3. 所有代码从主分支迁出，前后端分别使用front和back分支。完成自己的工作后，push到相应的分支下。由测试人员进行测试后确保代码质量，合并前后端代码，push到master分支下。

团队如何平衡 时间/质量/资源 争取如期完成任务的？

主要的平衡方法：

• 根据组员的反馈以及技术难度，修改原型设计。
• 明确分工，每位成员有自己的技术方向，有针对性地学习、开发。
• 测试协助进行前后端的合并。

测试用例数目，代码覆盖率

参见测试报告

后端主要进行了单元测试，共22个测试用例，代码覆盖率90%

进行了服务器的压力测试

前端随着项目进度一直在进行测试，目前只测试了win10环境下的10款常见浏览器。填写了测试矩阵。

代码规范以及文档

前端代码规范参考了一篇博客，简书-前端代码规范

后端使用ide自带的代码规范（pep8）

文档：

• API接口文档
• 后台数据架构

明年的同学继续开发这个项目，会不会出现代码混乱的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？

• Alpha阶段，后端代码接口文档完备，可读性高，可以很轻松接手；前端无参考文档，但注释丰富，可以正常使用。
• 新学生可以顺利运行，安装pyhton环境即可。README可指导新学生。

你们如何找到学生做需求分析？他们给你什么样的反馈？

我们在发布项目的同时发放了调查问卷，填写调查问卷的人比较少：

其他用户的反馈：

1. 操作有点复杂
2. 界面刷新跳转有点生硬
3. 初次加载Graph页面缓慢
4. Text页面放大后点击右键会出现轻微的移位

3. 团队项目的实际进展，说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？

前后端分别开发，对接完成后关闭issue，反映在燃尽图上就是一个时间点关闭了大量issue。

进度有些许的拖延。

4. 团队成员在Alpha阶段的角色和具体贡献

姓名	角色	贡献	贡献分
左正	后端	300行代码，30行注释，维护了1份接口文档	50
刘享	后端	500行代码，3800字接口文档	44
柴博	前端	1800行代码	56
李健	前端	400行代码，发现前端bug3处，后端bug5处，修复前端bug4处，写了1200字的技术博客	55
窦铮	测试	22个测试用例，500行代码，服务器部署	47
刘阳	PM	100行代码，12篇会议记录，5篇博客作业。4次推广，4次用户调查	48

5. 所做软件最有特色的功能是什么，请着重介绍一下。活的用户如何从你的软件中获益的，请现场展示。

参见博客 发布声明

这部分进行现场展示

6. 团队从用户那里得到了什么反馈，有什么样的bug？这是预料之中的还是没想到的？

• 导入文本中文乱码
• 导出知识图谱信息的文件名无法修改
• 给同一实体添加过多的关系，实体会在图中消失
• 若未进入项目，直接访问Relation和Text会出现一些意料之外的文本。

大部分都是前端的bug，前端测试不够详细，没有发现。未进入项目这个bug开发阶段就发现了，因为涉及到cookie方面，不好修复。

7. 总结，整个团队在Beta阶段学到了什么，对软件工程的教育，对这个具体的课程有什么批评建议？

收获：

• 自学了很多知识
• 团队合作技能
• 与队友交流沟通能力

建议：

• 任务量很大，Beta阶段冲刺与计网期末赶在一起
• 希望可以加入一些技术上的支持，会出现开发人员无法实现功能设计的情况