项目展示-Beta

Beta阶段项目展示

Name Not Found
GitHub wiki : 你想了解的一切都在这里！🤔🤔

项目 内容
北航-2020-软件工程（春季学期） 班级博客
要求 Beta阶段项目展示
课程目标 通过团队合作完成一个软件项目的开发

1. 团队成员简介及个人博客地址

姓名 有图有真相 博客地址 分工 —— 姓名 有图有真相 博客地址 分工
wyk 链接 后端 zyc 链接 前端
ly 链接 PM llj 链接 后端
dxy 链接 后端 lzh 链接 前端

2. 软件工程

项目定位

本项目虽然基于微软原项目进行增量开发，但是后续开发过程逐步转向了自主开发，功能和原项目并不重叠！

  • 本项目是一个表单处理分析工具，兼具表单数据生成的功能。从这角度出发，我们基于微软的Fott项目，进行了增量开发，Alpha阶段主要是实现了数据生成的功能，Beta阶段主要实现了自动化训练表单的功能。
  • 目前支持处理的表单为电子表单，且表单类型必须一致。
  • 支持两种处理方式（具体使用见后续）。
  • 支持的语言为英语。

项目目标

  • Alpha阶段主要目标
    在各类表单识别和OCR服务的机器学习模型中，训练数据占据很重要的地位。而真实表单中数据往往涉及用户隐私，不能直接使用，因此需要花费大量的资金和人力伪造一些与真实表单各个字段值相近的“虚假”表单作为训练数据。我们希望能够设计一个表单数据自动化生成工具，它能根据用户提供的空白表单和表单中各个字段的生成要求，自动随机生成多个满足用户要求的标注好的高质量表单，作为训练数据以供各个表单识别项目开发者使用，从而节省花费在训练数据上的人力物力。

  • Beta阶段主要目标
    微软原项目Fott项目使用认知服务来识别表单。我们基于Alpha阶段的数据生成，进一步把模型训练和使用结合起来，使整个软件有一个完整的流程，即：上传->标注->数据生成->模型训练->表单处理。
    我们认为标注过程对用户是不友好的，在这一方面进行了主要的改善，将软件的使用设计为两种主要的模式：空白表单模式和自动处理模式。
    同时，为了方便用户使用处理结果，我们对预测结果进行了整理，并且设计了可视化展示的接口，方便用户直观的观察数据。


预期的典型用户

  • 典型用户1
    用户信息 用户情况
    姓名 卡罗尔·狗蛋·史密斯
    用户身份 微软表单项目开发测试人员
    用户情况 为了测试项目的bug，需要雇用大量的人力来填写表单
    用户痛点 大量人力意味着大量的薪水，另外耗时较多
    典型场景 新的模型开发出来了，又到了紧张刺激的训练和测试环节，但是真实表单数据，公司有要求不让用，只能花钱请人伪造表单来训练测试了，又费时又费钱。发现有一个自动生成表单数据的项目，可以把数据生成到Azure里，还能下载下来，真是非常方便呀！
    用户比例 20%
    重要性 ***** 非常重要，开发测试者的时间非常宝贵，节省下来的时间与财力可以用于更多有意义的事

这一类典型用户的主要需求是数据生成，因此使用的模式是空白表单模式。也是Alpha阶段针对的主要用户群体，Beta阶段对此做了扩充，典型用户2（见下文）也可以使用这一模式，忽略生成的数据即可。


  • 典型用户2
    用户信息 用户情况
    姓名 李华
    用户身份 高一3班英语课代表
    用户情况 处理同学们的调查问卷，由于无法直接导入到Excel，需要手动处理
    用户痛点 有急事，需要快速处理这些表单
    典型场景 北航附中的学生开学了，今天高一3班的同学们填写了一份关于疫情期间线上英语学习的调查问卷，李华作为英语课代表，老师让他处理这些表单，但是他还没有写完英语作文，你可以帮帮他吗？🙏🙏🙏
    预期场景 李华发现了我们的软件
    李华使用软件，上传了5份用来训练
    训练结束后李华批量处理了所有的表单并且得到了处理后的Excel文件
    李华完成了工作
    用户比例 80%
    重要性 ***** 非常重要，本类软件就是为这类主要用户使用，因此用户的体验和反馈对于软件的后续发展尤为重要

这一类用户是日常中占绝大多数的用户群体，他们可能了解相关技术或者完全是小白，因此，表单识别工具不应该带给用户过多的技术壁垒，于是我们这里开发了模式2——自动处理模式。用户只需要上传5份已有的表单数据作为训练，我们会在后端处理训练模型，之后用户就可以直接使用表单处理的功能，很大程度上释放了用户，使用简单轻松！

预期的用户数量

  • 开发人员
    预期用户是一些表单数据的使用者（即需要使用人力物力来进行表单填写的人、相关软件的开发者等）和微软表单识别项目的使用者（借助我们的工具会方便很多）。
  • 办公人员
    日常办公人员需要处理大量的表单，有时候表单中的数据无法直接使用工具处理，需要手动提取，这时就可以使用我们的软件，一个简单的训练过程之后就可以实现自动化处理大量表单的任务。

Alpha阶段预计的用户数位100，建立的项目为150；
Beta阶段预计用户数为100，建立项目为150；

alpha阶段结束的时候数据库中的项目是192个，所以beta阶段总的增加是164个项目，其中包含我们测试用的大概是不到100个，也就是说并没有达到预计的用户数。
我们考虑后认为原因有几下几点：

  • 我们的软件对于大家来说需求不是很明显，所以可能大家尝试的意愿不高
  • 考虑到临近烤漆，大家都在复习，我们的软件对于复习没有帮助，所以不使用很正常
  • 软件本身还是不够吸引人

预期功能描述

Beta阶段发布说明
在beta阶段，我们预期的功能主要是两个方面：

  • 将预测模型的训练添加到软件中，使得软件能够处理表单，而不仅仅是一个数据生成的工具
  • 自动化处理表单训练过程，解放用户，使软件的使用更加简单方便
  • 处理结果整理+可视化展示

具体功能描述见下面的部分

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

Beta阶段成员变动：

  • PM更换
  • 一位成员转会
  • 一位成员新加入团队

首先，Alpha阶段的主要开发人员没有大变动，新成员顶替转会成员的工作，在前端开发。团队分为前后端协同开发，PM负责总体任务推进，每日例会商讨之后的工作细节。

成员 分工
ly PM，博客维护，后端服务器开发+维护
zyc 前端开发成员
lzh 前端开发成员
dxy 后端开发成员
wyk 后端开发成员
llj 后端开发成员

经验教训：

  • 我们在开发初期遇到过一些问题，成员之间不理解相互之间开发模块的目的和联系，导致开发缓慢，后续是在例会上明确每个人当前的工作，逐步做出调整来解决的

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

GitHub项目规范

项目管理通过GitHub来完成，每个成员都有自己的开发分支，前端的测试分支为 dev ，前端部署分支是 master 分支，后端代码维护在 ly 分支。整体上，在push代码、增加issue等方面上遵守微软的项目规范。
Beta阶段在GitHub的issue中设置了两个milestones：Beta、BUG。

  • 开发阶段的事务都更新在Beta上
  • 测试阶段的问题都更新在BUG上

代码复审：前端是互相审查代码后合并到master分支更新部署；后端是在审查代码后合并到ly分支上

时间/质量/资源的平衡

我们关注的点是时间和质量，资源（服务器等）对于我们来说相对充足，不作为主要的考虑要求。
beta阶段新增功能其实比alpha阶段多，但是开发的速度反而上升了。一方面体现出团队的磨合越来越好，工作效率显著提升，另一方面，经过alpha阶段的开发，每个成员对项目更加了解，开发起来越发得心应手。
最终我们的开发是如期完成，测试也稳步进行。

在产品之外，团队代码的软件工程质量如何？如何用数据来证明？

测试报告

前后端在开发过程中都遵守各自的代码规范

  • 前端：tslint
  • 后端：pylint

测试

详情见Beta阶段测试报告

  • 前端：

对于每一个issue会开启一个名为issue-(issue_number)-(name)的分支，在其上进行开发，开发完成后进行自动化测试和浏览器中的实际操作测试。

测试包括以下部分，逐一进行检查：

  1. Jest自动化测试
  2. 被修改组件的功能是否符合期望。
  3. 页面的功能是否正常。
  4. 进行完整的工作流程，检查是否存在错误和异常。

测试正常后会合并到dev分支，进行代码复审。
每天将复审后的dev分支合并到master分支。

使用tslint进行前端代码的规范
每次提交和复审时确保没有tslint的错误和警告。

  • 后端：（分不同的成员介绍）

llj：

代码经过复审后再合并进master，主要测试的是调用接口对多种实体的识别情况，测试样例中涵盖我们所需要处理的字段以及不匹配实体的字段：

代码覆盖率：

wyk：

使用pylint做代码格式审查，风格良好：

使用unittest做单元测试，构造多个测试函数：

运行结果良好

使用coverage做覆盖率测试，结果如下：

dxy：

代码规范：

使用pylint进行**代码规范的度量**，取得满分

ly：

  • 模拟前端对后端http服务器进行测试，主要测试API的正确性，采用Postman来进行测试。
  • 测试后端各模块综合起来的正确性，并进行代码规范的修改。

运行测试用例得到代码覆盖率的视频录像

展示时运行

代码规范、文档

维护在GitHub的wiki页面——传送门

目录

技术博客篇

其他

项目可扩展性

后续团队进行增量开发的可能性

后端

目前我们的项目使用的全套工具都是微软的服务——Azure、FOtt、服务器等，这就导致在国内存在一定的网络延迟，所以考虑到后续的维护和开发，可以将现有的后端和数据库都搬迁到本地服务器上，就可以很大程度上降低延迟。

数据生成的扩展性

Beta阶段我们没有针对这一功能做主要的开发，但从数据生成的多样性和可能性来考虑，这一功能，可以做的更丰富，具有较大的扩展性

自动化处理效果增强

目前软件整体的泛化性还不是很高，对于很复杂的表单处理结果可能很差，后续的开发可以基于目前的功能，作进一步扩展，实现更多表单的识别以及考虑更多的干扰因素，比如：扫描件、光影干扰等

3. 项目进展、发布功能

燃尽图：


milestones


发布的功能

  • 介绍页面

用户点击软件右上角的 ? 按钮即可看到软件的操作说明！

  • 项目模式

目前软件支持三种模式

  1. 空白表单模式。该模式可以生成基于模板的表单数据，也支持生成数据直接训练模型以处理新的表单
  2. 自动处理模式。该模式用户只需要上传5份填好数据的表单，后端会自动处理识别字段并且训练，用户可直接使用预测的功能
  3. 原项目的标注训练模式——传送门
  • 原项目功能恢复

我们把原项目的功能恢复了，用户可以手动上传5个表单，对每一个表单进行标注，之后进行训练，最后拿训练好的模型预测新的表单。

  • 自动化训练

用户只需要上传5份填好数据的PDF表单

之后可以在标注页面进行查看，但是这一模式下无法进行标注

用户可以直接在训练页面进行训练，等待训练结束

现在用户就可以使用模型处理新的表单了

  • 预测结果自动整理
  • 预测结果可视化
新功能

发布的地点

  • 微信群: 课程微信群 + 1706大班群

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

后端开发的代码都维护在ly分支

评价体系

根据完成的工作来计算每个人的分数，然后折算为贡献分占比，乘以团队分数300作为个人分数

代码行数+开发issue

  • 因为代码行数很难量化为个人工作代表，因此设置代码行数的因子是0.01，最后添加

  • 这一部分的主要分数由GitHub上的issue完成情况以及开发的任务来评判

    commit * 2 + issue * 2 + 额外开发任务 * 2

测试

是否进行测试，以及测试的数目和可靠性

测试工作的因子设置为0.2

开发是否准时

分为5个档次：1，2，3，4，5分别代表最终分数

PM评价

评价均分为4.33，换算成分数为+1.33

其他工作的量化

  • 技术博客+10
  • 视频制作+10
  • 服务器部署+10
  • 资源提供+10
  • PM博客维护+5

互相评价

成员之间互相评价，乘以0.1的因子最后相加

成员 代码分数 测试 BUG 技术博客 其他贡献 互评 贡献分 最终分数
ly 35 2 6 10 5 1.6 +1.3 59.6 55
zyc 28 10 10 0 10 1.2 59.2 54
lzh 29 8 8 10 0 1.3 56.3 52
dxy 30 10 4 10 0 1.0 55 50
wjk 25 10 6 0 5 0.8 41.8 43
llj 20 5 4 10 10 0.9 49.9 46

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

我们的特色功能也就是我们的主要功能：

  • 数据生成
    表单数据涉及到隐私问题，获得的成本较高，为了开发表单识别模型，数据又是必不可少的。这种情况下，我们提供表单数据生成的功能，用户只需要上传一个空白表单的模板，标注要生成的数据字段的位置及属性，就可以批量生成想要的数据。

  • 自动处理
    对于普通用户来说，更多的是使用模型来处理表单，而且不希望操作很复杂。这种情况下，我们的第二种模式就可以处理，用户只需要上传5份已有的数据进行训练，之后就可以直接使用识别功能，完全释放用户，轻松简单！

用户反馈

用户反馈——打分：

反馈词频分析：

某些用户的反馈：

整体上，用户比较满意。

  • 词频图和用户都指出软件存在缓慢的问题，这个在alpha阶段也遇到过，我们在beta阶段进行了改进，但还是无法从根本上解决。这是因为原项目在前后端对接的过程中存在着一个较大的延迟，前端是北京的服务器，后端是香港的服务器（Azure服务所在地），所以这一点暂时无法解决，只能尽量优化。
  • 有用户提到了英文的问题。这个是因为我们是基于微软的项目进行开发，初期为了遵守他们的规范，就选择了英文，不过使用说明都有维护中文版本，供用户查看。

总结与建议

总结

成员 总结
ly alpha阶段主要做的是开发工作，基于Azure Functions + Python开发Http响应服务器，逐渐掌握了Azure+Python的开发流程，尽管遇到了一些难题，但是最终都得以解决，顺利上线！Beta阶段转职为团队的PM，期间体会到了博客和文档维护的不易，PM还要协调工作，进行任务分配和进度管理，整个流程下来，感觉自己的沟通能力以及协调能力都有所提升。尽管整个项目都是线上交流，作为PM我还是比较相信自己的队友的，最终也是能够提前完成功能实现，进行测试部署等工作。最近临近烤漆，大家也尽职尽责，再次感谢努力付出的每一个人！👍
zyc 过去对前端接触的不多，使用的更多是比较简单的技术，而这次开发是基于微软一个有一定规模的前端项目，一开始感到有些力不从心，不过随着对代码理解的深入，以及过程中查阅各种资料，逐渐能够比较好的实现新的功能。在技术方面最大的收获是熟悉了前端React框架的使用，对前端的理解也更加深入，相信之后再做相关的开发不会感到很大的困难了。在软件工程上也收获很大，熟悉了软件开发的流程和各个要点，也让我明白了软件开发流程以及各种规范的重要性，有助于今后进行更好的软件开发。
lzh 在为期一个月的工作过程中，我深深体会到了敏捷的精神：跳槽进入团队、无缝接手前端、每天更改的需求、边做边设计的过程…微软OCRFormTools这样一个庞大的项目，自己也是从中慢慢的一点点啃了下来，不仅从中学习到了与以往经验不同的另外一种前端写法，还强化了自己对于js的编译、初始化、异步操作、ajax等等技术的知识和经验。除了技术，我更从中感受到了微软专业人士开发过程中代码的规范、自洽和优雅，以及学会了在规范代码的同时给敏捷留下足够多的空间。
dxy 对于json分析部分的代码，逻辑较为简单，但是对细节要求较高。从json中获取的内容数据出现的问题包括：属于同一字段的文本被拆分、本来存在在表格中的内容也被识别（应该只保存用户天写内容）。所以需要处理的主要是这两部分内容，设计算法流程为：首先对比多个json的完全相同的数据，进行删除，从而将本来存在于表格中的所有内容全部去除掉；其次对剩余字段进行遍历，根据字段的文本大小、相对位置，设置阈值，从而判断两个文本是否需要进行拼接。由于采用了硬编码而非机器学习的模式，处理起来稍显僵硬，但可以基本满足软件的需求。这部分主要是对算法的设计比较繁琐，并没有新的学习到其它知识，类似于机器学习中的调参，需要设置合理的阈值，从而将文本正确拼接，交给下游任务实体识别。最后是自己的收获，我认为团队之间的讨论是最重要的。最开始发现json的内容比较凌乱，我只想出了比较粗糙的处理方法，在经过和团队成员的讨论之后，才将本方法进行了相应的完善。要和上游任务负责人保持好联系，从而对数据的格式有一个比较好的把控。beta阶段虽然没有使用新的包，但学习使用了pylint，进行了代码的规范，虽然修改的比较繁琐，但是代码比之前规整了许多。我感觉获益匪浅。
wyk 说实话之前没怎么写过python代码，这次beta开发经历下来，对python程序开发更加熟悉了。另外，对于一个团队项目的开发也有了很大的认识，从github的管理到需求和功能的设计再到代码的对接都有了更多的了解。回顾alpha阶段的PM一职也对整个项目的前前后后开发流程有了一个框架概念，受益匪浅。
llj alpha阶段是在前端进行开发，beta阶段转入了后端和大家一起完善新的功能；bata阶段我主要的收获是学习到了如何在python中调用其他的API以实现自己的需求，也了解到了认知服务的优越性，它可以将看、听、说、搜索、理解的能力嵌入到应用中，帮助我们开发出更智能，更有吸引力的产品。在这个过程中我也更深刻的体会到了软件工程中文档的重要性，文档是开发人员交流沟通的重要渠道，好的文档在开发中可以起到事半功倍的作用。前端到后端，虽然接触到的技术不同，但是软件工程开发的规范性却是不变的，我也系统地学习到了相关流程和技术，收获颇丰😀

建议

  • 感觉课程组的初衷很好，不过受今年疫情影响，很多方面可能做的并不是很好。如果结对编程和团队作业是线下交流的话，应该会产生很好的效果。
  • 对于个人作业和结对作业的要求上可以适当放低，因为觉得有些太过紧凑，不太像是学习而更像是工作。
  • 对于团队作业可以增加一些项目或者自由度放高，即给同学们更多的选择余地，比如本次作业，很多组都想选pytorch模型可视化，但只能由一组去做，而且也没有类似的平行项目。
    批评：
  • 所需要写的文档数目过多，个人觉得有的时候没必要事无巨细的进行文档的要求，更何况在撰写文档时，经常会有话题之间有交叉，就导致了部分问题的答案只能通过换个说法表达同样的意思。
posted @ 2020-06-09 21:26  Name+Not+Found  阅读(277)  评论(4)  编辑  收藏  举报