【二食堂】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进行项目的记录和管理。点击访问
- PM对Beta阶段的任务进行规划,做出原型设计,将任务划分为三周时间完成。
- 每周开始给每位成员分配对应的任务,由组员自行安排。PM在每天的例会上追踪成员的任务进度。
- 所有代码从主分支迁出,前后端分别使用front和back分支。完成自己的工作后,push到相应的分支下。由测试人员进行测试后确保代码质量,合并前后端代码,push到master分支下。
团队如何平衡 时间/质量/资源 争取如期完成任务的?
主要的平衡方法:
- 根据组员的反馈以及技术难度,修改原型设计。
- 明确分工,每位成员有自己的技术方向,有针对性地学习、开发。
- 测试协助进行前后端的合并。
测试用例数目,代码覆盖率
参见测试报告
后端主要进行了单元测试,共22个测试用例,代码覆盖率90%
进行了服务器的压力测试
前端随着项目进度一直在进行测试,目前只测试了win10环境下的10款常见浏览器。填写了测试矩阵。
代码规范以及文档
前端代码规范参考了一篇博客,简书-前端代码规范
后端使用ide自带的代码规范(pep8)
文档:
明年的同学继续开发这个项目,会不会出现代码混乱的抱怨?如果一个新学生在一台新机器上想编译并运行你的项目, 请问能顺利完成么?有什么样的文档能指导新学生?
- Alpha阶段,后端代码接口文档完备,可读性高,可以很轻松接手;前端无参考文档,但注释丰富,可以正常使用。
- 新学生可以顺利运行,安装pyhton环境即可。README可指导新学生。
你们如何找到学生做需求分析?他们给你什么样的反馈?
我们在发布项目的同时发放了调查问卷,填写调查问卷的人比较少:
其他用户的反馈:
- 操作有点复杂
- 界面刷新跳转有点生硬
- 初次加载Graph页面缓慢
- 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阶段冲刺与计网期末赶在一起
- 希望可以加入一些技术上的支持,会出现开发人员无法实现功能设计的情况