OCR-Form-Tools项目试玩记录（二）产品评测

这是一篇软工课程做业博客

项目	内容
这个做业属于哪一个课程	北航2020春软件工程 006班（罗杰、任健 周五）
这个做业的要求在哪里	我的博客做业-软件案例分析
我的课程目标	系统地学习软件工程理论知识与实践方案
这个做业在哪一个具体方面帮助我实现目标	学习如何分析一款软件的功能需求与用户群像

在上一篇博客中我简单介绍了OCR Form Tools及其本地部署，这篇博客则将进一步评测整个软件。

首先走一遍软件的完整运行流程，直观了解其功能

本工具的数据存储基于Azure存储服务，下文使用的均为开发老师提供的测试仓库，内含5份训练用表单pdf文件。同时本地有一份相同格式的表单pdf文件，做为测试数据用。

建立项目

运行后看到初始界面。

能够看到总体界面设计走的是微软在10年后一向的扁平风，dark theme的配色让人一会儿联想起其王牌产品vs和vsc。点击New Project尝试新建一个表单识别项目：

这个表单的各类verify都是齐全的，placeholder和键入提示也很是清晰。

注意到这里须要添加一个新的Connection才能与Azure存储服务创建关联。界面中很贴心地提供了“Add Connection”按钮，也能够直接点击界面左侧的小插销图标进入Connection管理页面并完成添加。

完毕后回到刚才的新建项目表单。继续完成其他的信息填写并建立新的表单识别项目

进入编辑器，看到待标注的pdf预览页面。

添加tags

为了训练识别模型，咱们须要把待标注的表单中，咱们感兴趣的信息（如姓名、地址、电邮）标注出来，做为不一样的特征以备模型使用。为了区分这些信息，咱们要将其标上不一样的tag

首先添加名为Name的tag并将它的类型设为string

点选pdf文档中的名字字段John Singer，看到选框变色后按下提示的标注键“1”，看到名字被红框框选并出如今右侧Name tag下，标注成功。

依次添加Email、Zipcode、ExpDate、Amount几个tag，并为其指定string、integer、date、number类型，来测试不一样类型tags的标注；在所有五份pdf上完成上述tags的标注

能够看到已标注的文件会有一个小图标标记。

标注用的pdf阅读器支持滚轮缩放与拖拽移动，因为作了ocr预处理因此文本点选十分便利，按提示键入数字标注，键入delete删除，键鼠配合下能够迅速完成标注。五份文件的五种tags标注我在十分钟内所有完成，效率至关高。

模型训练

标注完成后点击左侧train按钮进入训练页面

点击右侧的train训练一个新模型，完成后返回了模型信息和各tag的预测准确率

模型测试

训练获得模型后点选左侧predict页面，尝试使用刚刚训练的模型预测一份新的pdf。Browse选择文件后在左侧预览，而后点击predict开始预测

完成后返回结果和置信度

能够看到各个tags都被正确框选了。因为这个pdf并无出如今训练集里，所以说明模型训练很成功。注意到还能够下载json格式的预测结果(原文太长，这里截取其中一段)：

"fields":{"Email":{"type":"string","valueString":"jaimeg@outlook.com","text":"jaimeg@outlook.com","page":1,"boundingBox":[2.045,6.0200000000000005,3.345,6.0200000000000005,3.345,6.15,2.045,6.15],"confidence":0.99,"elements":["#/analyzeResult/readResults/0/lines/25/words/0"],"fieldName":"Email","displayOrder":1},"Zipcode":{"type":"integer","valueInteger":5001,"text":"05001","page":1,"boundingBox":[7.2250000000000005,6.55,7.58,6.55,7.58,6.655,7.2250000000000005,6.655],"confidence":0.999,"elements":["#/analyzeResult/readResults/0/lines/33/words/0"],"fieldName":"Zipcode","displayOrder":2},"Amount":{"type":"number","text":"45.00","page":1,"boundingBox":[6.54,7.84,6.875,7.84,6.875,7.95,6.54,7.95],"confidence":1,"elements":["#/analyzeResult/readResults/0/lines/42/words/0"],"fieldName":"Amount","displayOrder":4},"ExpDate":{"type":"date","text":"10 / 21","page":1,"boundingBox":[4.49,7.88,4.92,7.88,4.92,8.01,4.49,8.01],"confidence":1,"elements":["#/analyzeResult/readResults/0/lines/38/words/0","#/analyzeResult/readResults/0/lines/39/words/0","#/analyzeResult/readResults/0/lines/40/words/0"],"fieldName":"ExpDate","displayOrder":3},"Name":{"type":"string","valueString":"Jaime Gonzales","text":"Jaime Gonzales","page":1,"boundingBox":[2.365,5.74,3.35,5.74,3.35,5.845,2.365,5.845],"confidence":0.97,"elements":["#/analyzeResult/readResults/0/lines/15/words/0","#/analyzeResult/readResults/0/lines/15/words/1"],"fieldName":"Name","displayOrder":0}}}],"errors":[]}}

自此这个项目的主体功能被咱们串通了：首先将pdf训练集上传到azure storage blob，链接并建立项目后借助该工具对其进行标注，而后训练模型，便可获得一个识别该格式表单的模型。此后，将须要识别的新表单输入训练好的模型，便可导出格式化后的表单数据。

我的体验

总的来讲我很喜欢这个工具，我认为它能够大幅改进目前表单处理须要大量人力的境况。具体来讲，我认为优势有：

1. 借助ocr预标注实现的快速字段选择，及基于快捷键的操做，这样的设计十分用户友好，标注效率至关高
2. 一站式模型训练，标注好的数据当即移交模型，训练后当即使用，节省了大量繁琐的api调用，隐藏了机器学习训练-推断工做流的大量细节，即便没有相关技术背景的人员也能够轻松上手使用
3. 基于react spa，以web应用的形式提供，免去安装部署等步骤，开袋即食
4. 对于后端模型配置只须要提供其base url，这使得工具能够轻松接入任何使用相同api接口的模型后端，有较强的可扩展性
5. 清爽的界面

虽然整个工具体验过程很顺滑，但我的认为依旧存在一些小问题：

1. 标注界面的功能提示过于隐晦，对于新用户不易理解新建tags上的数字图标表明对应标注按键；也没有提示使用delete键删除已框选字段
2. 虽然提供了tag类型，可是不点开tags设置菜单是不能看到tag类型的，所以对tag类型设置的审阅比较麻烦，当tag较多时容易产生设置疏漏。通常来讲模型对不一样的特征类型会选用不一样的预编码处理，所以错误的tag类型可能会致使模型采用次优或错误的特征编码方式，影响模型精度。（这里建议，在标注界面和下方这个训练结果表格上都加注tag类别）
3. 如今的模型只支持Azure存储服务，对于已经有本身的表单存储解决方案的用户稍显不友好
4. 模型预测不能批量上传、批量推断
5. 下载的json格式包含大量用户不感兴趣的原始数据（如检测框位置等）；没有提供excel等格式的结果导出，使得非专业人员难以将该工具直接整合入工做流。

测试与Bug Report

因为课程做业要求寻找软件Bug，我在不一样运行环境与浏览器下对软件进行了黑箱测试，发现以下问题：

首先在Docker Toolbox虚拟环境下以docker运行时，链接远程仓库会失败。报错信息难以被用户理解，所以这应该是开发者意料以外的未处理异常：

因为官方提供的docker镜像已为release版构建，没有提供足够的调试信息，同时考虑windows下模拟Docker Toolbox的网络环境进行复现较为复杂，所以这里没有进一步尝试定位错误缘由，仅做出错误报告。

另外一个问题有关标注。在标注测试文件中的小数数据时，会发生一次点击后单条数据被重复标注的状况：

上图分别为点选测试文件CCAuth-1.pdf和CCAuth-2.pdf中amount字段并标注的结果，能够发现小数都被错误地选择了两次。分析缘由多是由于pdf文档中处理小数元素分了父子两级，而两级都被ocr单独识别为一个词块，而二者的碰撞框重合了，所以发生复选。针对这个问题，或许能够考虑，当所选两个词块的范围出现重合或包含时，进行一些判断与处理。

须要指出，这些都不是多么严重的问题——前者是在极端运行环境下才会出现的偶发错误，相对软件的目标群体及使用场景而言彻底在可接受范围内；后者则是标注时的一些小几率出现的功能缺陷，也没有显著下降使用体验。

实际上，必须认可这款工具的软件质量是很高的。我在Chrome、Firefox、Edge等多款主流浏览器上进行了大量黑箱测试，均没有发现明显的功能或显示错误。

需求理解与功能分析

在完整运行一遍后，我对这个项目的功能已经有了大体认识。个人理解是，这是一个为后端表单识别算法设计的表单标注工具，提供了很是高效易用的格式化表单文件标注功能，借助其能够快速构建训练集；同时其也简化了后续工做，能够当即训练、使用给定训练集上训练的识别模型。

我认为这个工具解决的痛点有：

1. 表单数据难以标注的问题。正常来说，学习算法关注的数据大多包括：目标字段在文档中的位置、目标字段的真实值、目标字段的数据类型。因为大多数文档格式（pdf、docx等）以xml或类xml的形式组织文档，同时还有大量的纯图像格式表单须要处理，字段在文档中的位置（通常是角点坐标）难以以符合直觉的方式给出，所以标注一个特征每每须要基于各类图形工具测量文本元素坐标，并手动键入其真实值后才能完成——这是十分麻烦的工做，所以人力成本很高。而正如前文分析，这个标注工具很好地简化了这个过程。

我理解目前这个项目暂定的用户群体是：

1. 微软OCR-Form的用户。这个工具正如README描述，是一系列表单工具中打头阵的一个，它旨在（并确实能够）大幅优化OCR-Form的使用体验。借助该工具能够快速标注数据、训练模型、验证模型

同时我认为这个工具备潜力解决的痛点为：

1. 非技术人员难以学习使用机器学习模型处理表单数据的问题。考虑人力、财务等部门，天天有大量的纸质简历、报表须要被数字化处理以方便统计，这个过程是十分繁琐的简单重复劳动——而表单识别模型正是能够解放这些生产力的利器。然而这些报表格式常常变化，对应的识别模型也相应须要从新训练——但人力、财务等部门的职员每每不具有调取api训练模型所需的专业技能，于是这个愿景很难实现。这款工具将整个工做流浓缩简化，隐藏了算法、api调用等技术细节，使得新技术也有望为这些人员赋能。

所以，我认为这个项目将来的潜在用户是：

1. 上文提到的这些非技术从业人员。企业中有大量的报表工做，这个前端项目能够继续发展为（或衍生出）更实用的工具，为他们提供很是强劲的业务武器，解决企业中实际存在的迫切痛点。

为了迎合潜在用户，我认为这个工具还须要完成的功能包括：

1. 上文提到的批量推断、excel下载等功能。我认为一个基于其的理想工做流是，用户上传并标注某种格式的报表，完成模型训练，而后上传大量未经处理的报表数据，批量推断后能够下载一张已经滤去多余信息的excel汇总表格：表格每行对应一个报表文件，每一列对应一个tag（或报表文件名等基本信息）
2. 进一步打磨界面，完善使用提示与内嵌帮助，进一步下降使用门槛

做业问题：开发难度预估与综合分析

Q: 使用此服务的全部功能，估计这个软件/网站/服务作到这个程度大约须要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。（必答）

这个项目是一个前端项目，基于react开发。咱们合理假设，6人学生团队中，至少2人熟练掌握vuejs或reactjs前端开发，剩余四人的专业水平与代码能力知足毕业要求，所以这个团队不须要过多的学习开销，开箱即食。总体规划采用双线开发模式：

1. 起步工做，包括梳理需求并初步制定okr、部署生产与测试环境、CI/CD配置、基础组件搭建、以及补充学习相关技术，这个工做通常一周内就能完成
2. 【feat1】pdf reader开发，这是表单识别工具的核心功能，所以须要首先开始迭代，方便以后根据实际开发进度调整开发计划。pdf读取与显示自己是很是难以开发的，幸亏现在前端生态趋于完善，能够借助第三方包来实现相关功能。查阅package.json能够看到，OCR Form Tools基于pdfjs实现相关功能。考虑到文档查阅、调整布局等开销，pdf预览工做能够由一到三我的在一个sprint内初步完成。
3. 【feat2】pdf editor开发，这是pdf reader的后继项目，须要在读取pdf后调取ocr接口对pdf作预识别，再提供基本的点选工具，响应键盘事件，实现识别-点选-标记的逻辑。须要考虑接入ocr时的学习成本和一些意料外的适配工做，保守估计这项任务也须要一整个sprint完成。
4. 【feat3】数据管理模型，借助redux（或vuex）实现，给出connection、secure key、project、file、tag、model等数据模型的curd，我的经验来看这项工做涉及的内容比较琐碎但对后续开发尤其重要，须要较多测试与回归，所以须要一到三我的在2个sprint内完成，第一个sprint主要关注代码实现，第二个sprint则侧重问题修复与更详细的验证测试
5. 【feat4】tag建立与设定，为pdf editor提供复数tag、多种类tag的支持；【feat5】接入模型训练后端，将标注好的数据送交模型训练并拿到返回结果。【feat4】和【feat5】一共须要一个sprint，参与人数3人左右
6. 【feat6】异常捕获与处理。须要能够在出现各种错误时捕获并以模态框的形式输出，告知用户错误信息。主要难点在于为axios编写中间件捕获并处理各类http错误。这部分工做能够为【feat5】提供更高效的调试工具，配合react或vue的debug模式能够方便地调试http错误及各类promise带来的隐晦错误。这个工做须要一个sprint，且应该配合【feat5】的开发进度优先提供对开发有帮助的异常处理。
7. 【feat7】模型推断，上传本地文件并调用训练好的模型预测并在pdf reader中展现结果。这个工做在一个sprint内完成，对于【feat5】没有完成的工做能够视状况在这个sprint内完善
8. 【feat8】完善各表单页面。包括新建/编辑connection、新建/编辑project、建立secure key等表单，添加提示、placeholder，并添加必要的前端类型检查与报错提示（如某些字段不能为空、sas uri字段必须符合uri格式，等）。这项工做较为琐碎，预留一个sprint
9. 【feat9】补全各页面间跳转逻辑与数据组织关系，串通建立-预览-标注-训练-测试-结果汇总的总体功能流程。这个工做设计项目各组件细节，须要整个团队合做完成，占用一个sprint。这项工做完成后基本功能定型，能够释出alpha版
10. 【feat10】优化UI，包括配色、图标、字体、页面布局精调、浏览器适配、移动端适配等工做。一到两个sprint的迭代后预期调整出用户体验良好、界面美观的应用，同时修复alpha中发现的问题，能够释出beta版。
11. 充分测试并迭代完善后，能够在beta版的基础上获得最终release版并发布。

能够看到，开发采用自底向上的顺序，前4个sprint中预期完成8个feature的实现，分为两组：

分组	sprint1	sprint2	sprint3	sprint 4
第一组：核心功能线	【feat1】	【feat2】	【feat4】【feat5】	（【feat5】）【feat7】
第二组：基础设施线	【feat3】	【feat3】	【feat6】	【feat8】

后两个sprint须要团队总体协做完成各组件间的衔接并释出测试版本、迭代直至产品正式发布。

照这样组织来计算，这个团队开发须要大概12周的时间，其中到第10周的时候应该已经完成大部分开发工做，只剩细节润饰。

分析这个软件目前的优劣(和相似软件相比)，这个产品的质量在同类产品中估计名列第几？（必答）

实际上这个软件在我看来十分新颖，我暂时没有接触使用过相似软件，所以还在进一步调研，若是想法更新将在这里修改。

须要再次强调的是，这个软件自己的质量很高，有理由相信即便存在同类软件，也难以覆盖该项目带来的完整用户体验

从各方面的问题，推理出这个软件团队在软件工程方面能够提升的一个重要方面(具体建议)。

参考上文对潜在客户的分析。我认为这个项目还有进一步演化并解决痛点需求的巨大空间。

另外一方面，我未在这个项目下找到单元测试与e2e测试的相关代码，可是提供了完善的ci配置（参考其azure-pipelines.yml），所以我认为就保证后续迭代质量而言，一些基本的测试工做能够整合入ci

你在第一部分发现的bug，为什么软件团队不能在发布前修复？他们是不知道，仍是有意不修复？你以为是什么缘由？能够从下面的可能性中选取几个

对于Docker Toolbox下的问题，Docker Toolbox做为已通过时的windows下docker解决方案，市场占有率过于小，且并不属于前端开发时须要考虑的典型运行环境，所以极可能软件团队根本无心在此环境下测试并修复问题——这是合理的，不然将会引来额外开发成本但收效甚微。

对于小数标记重合的问题，因为e2e测试等自动化手段很难覆盖这种与输入软件的文件内容相关的问题，所以只能依靠手动测试的方式被发现——这种方式很难保证覆盖率，于是软件团队可能碰巧因为测试用文件均没有相关问题、人工检查未能覆盖等缘由没有发现这个bug。即便已经发现bug，因为pdf预览等相关组件的开发依赖第三方库，不排除这个错误由第三方库引入——若是确实如此，修复这个bug将十分困难。所以我猜想，既有可能开发团队没有发现这个bug，也有可能开发团队发现了这个bug，但因为修复性价比过低从而暂时将其搁置。