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，但因爲修復性價比過低從而暫時將其擱置。