這是一篇軟工課程作業博客
| 項目 | 內容 |
|---|---|
| 這個作業屬於哪個課程 | 北航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，連接並創建項目后借助該工具對其進行標注，然后訓練模型，即可得到一個識別該格式表單的模型。此后，將需要識別的新表單輸入訓練好的模型，即可導出格式化后的表單數據。
個人體驗
總的來說我很喜歡這個工具，我認為它可以大幅改進目前表單處理需要大量人力的境況。具體來說，我認為優點有：
- 借助ocr預標注實現的快速字段選擇，及基於快捷鍵的操作，這樣的設計十分用戶友好，標注效率相當高
- 一站式模型訓練，標注好的數據立即移交模型，訓練后立即使用，節省了大量繁瑣的api調用，隱藏了機器學習訓練-推斷工作流的大量細節，即使沒有相關技術背景的人員也可以輕松上手使用
- 基於react spa，以web應用的形式提供，免去安裝部署等步驟，開袋即食
- 對於后端模型配置只需要提供其base url，這使得工具可以輕松接入任何使用相同api接口的模型后端，有較強的可擴展性
- 清爽的界面
雖然整個工具體驗過程很順滑，但個人認為依舊存在一些小問題：
- 標注界面的功能提示過於隱晦，對於新用戶不易理解新建tags上的數字圖標代表對應標注按鍵；也沒有提示使用delete鍵刪除已框選字段
- 雖然提供了tag類型，但是不點開tags設置菜單是不能看到tag類型的，因此對tag類型設置的審閱比較麻煩，當tag較多時容易產生設置疏漏。一般來說模型對不同的特征類型會選用不同的預編碼處理，因此錯誤的tag類型可能會導致模型采用次優或錯誤的特征編碼方式，影響模型精度。（這里建議，在標注界面和下方這個訓練結果表格上都加注tag類別）
- 現在的模型只支持Azure存儲服務，對於已經有自己的表單存儲解決方案的用戶稍顯不友好
- 模型預測不能批量上傳、批量推斷
- 下載的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等多款主流瀏覽器上進行了大量黑箱測試，均沒有發現明顯的功能或顯示錯誤。
需求理解與功能分析
在完整運行一遍后，我對這個項目的功能已經有了大致認識。我的理解是，這是一個為后端表單識別算法設計的表單標注工具，提供了非常高效易用的格式化表單文件標注功能，借助其可以快速構建訓練集；同時其也簡化了后續工作，可以立即訓練、使用給定訓練集上訓練的識別模型。
我認為這個工具解決的痛點有：
- 表單數據難以標注的問題。正常來講，學習算法關注的數據大多包括：目標字段在文檔中的位置、目標字段的真實值、目標字段的數據類型。由於大多數文檔格式（pdf、docx等）以xml或類xml的形式組織文檔，同時還有大量的純圖像格式表單需要處理，字段在文檔中的位置（一般是角點坐標）難以以符合直覺的方式給出，因此標注一個特征往往需要基於各種圖形工具測量文本元素坐標，並手動鍵入其真實值后才能完成——這是十分麻煩的工作，因此人力成本很高。而正如前文分析，這個標注工具很好地簡化了這個過程。
我理解目前這個項目暫定的用戶群體是：
- 微軟OCR-Form的用戶。這個工具正如README描述，是一系列表單工具中打頭陣的一個，它旨在（並確實可以）大幅優化OCR-Form的使用體驗。借助該工具可以快速標注數據、訓練模型、驗證模型
同時我認為這個工具有潛力解決的痛點為：
- 非技術人員難以學習使用機器學習模型處理表單數據的問題。考慮人力、財務等部門，每天有大量的紙質簡歷、報表需要被數字化處理以方便統計，這個過程是十分繁瑣的簡單重復勞動——而表單識別模型正是可以解放這些生產力的利器。然而這些報表格式經常變化，對應的識別模型也相應需要重新訓練——但人力、財務等部門的職員往往不具備調取api訓練模型所需的專業技能，因而這個願景很難實現。這款工具將整個工作流濃縮簡化，隱藏了算法、api調用等技術細節，使得新技術也有望為這些人員賦能。
因此，我認為這個項目未來的潛在用戶是：
- 上文提到的這些非技術從業人員。企業中有大量的報表工作，這個前端項目可以繼續發展為（或衍生出）更實用的工具，為他們提供非常強勁的業務武器，解決企業中實際存在的迫切痛點。
為了迎合潛在用戶，我認為這個工具還需要完成的功能包括：
- 上文提到的批量推斷、excel下載等功能。我認為一個基於其的理想工作流是，用戶上傳並標注某種格式的報表，完成模型訓練，然后上傳大量未經處理的報表數據，批量推斷后可以下載一張已經濾去多余信息的excel匯總表格：表格每行對應一個報表文件，每一列對應一個tag（或報表文件名等基本信息）
- 進一步打磨界面，完善使用提示與內嵌幫助，進一步降低使用門檻
作業問題：開發難度預估與綜合分析
Q: 使用此服務的所有功能，估計這個軟件/網站/服務做到這個程度大約需要多少時間(團隊人數6人左右，計算機大學畢業生，並有專業UI支持)。（必答）
這個項目是一個前端項目，基於react開發。我們合理假設，6人學生團隊中，至少2人熟練掌握vuejs或reactjs前端開發，剩余四人的專業水平與代碼能力滿足畢業要求，因此這個團隊不需要過多的學習開銷，開箱即食。整體規划采用雙線開發模式：
- 起步工作，包括梳理需求並初步制定okr、部署生產與測試環境、CI/CD配置、基礎組件搭建、以及補充學習相關技術，這個工作一般一周內就能完成
- 【feat1】pdf reader開發，這是表單識別工具的核心功能，因此需要首先開始迭代，方便之后根據實際開發進度調整開發計划。pdf讀取與顯示本身是非常難以開發的，幸好如今前端生態趨於完善，可以借助第三方包來實現相關功能。查閱
package.json可以看到，OCR Form Tools基於pdfjs實現相關功能。考慮到文檔查閱、調整布局等開銷，pdf預覽工作可以由一到三個人在一個sprint內初步完成。 - 【feat2】pdf editor開發，這是pdf reader的后繼項目，需要在讀取pdf后調取ocr接口對pdf做預識別，再提供基本的點選工具，響應鍵盤事件，實現識別-點選-標記的邏輯。需要考慮接入ocr時的學習成本和一些意料外的適配工作，保守估計這項任務也需要一整個sprint完成。
- 【feat3】數據管理模型，借助redux（或vuex）實現，給出connection、secure key、project、file、tag、model等數據模型的curd，個人經驗來看這項工作涉及的內容比較瑣碎但對后續開發尤為重要，需要較多測試與回歸，因此需要一到三個人在2個sprint內完成，第一個sprint主要關注代碼實現，第二個sprint則側重問題修復與更詳細的驗證測試
- 【feat4】tag創建與設定，為pdf editor提供復數tag、多種類tag的支持；【feat5】接入模型訓練后端，將標注好的數據送交模型訓練並拿到返回結果。【feat4】和【feat5】一共需要一個sprint，參與人數3人左右
- 【feat6】異常捕獲與處理。需要可以在出現各類錯誤時捕獲並以模態框的形式輸出，告知用戶錯誤信息。主要難點在於為axios編寫中間件捕獲並處理各種http錯誤。這部分工作可以為【feat5】提供更高效的調試工具，配合react或vue的debug模式可以方便地調試http錯誤及各種promise帶來的隱晦錯誤。這個工作需要一個sprint，且應該配合【feat5】的開發進度優先提供對開發有幫助的異常處理。
- 【feat7】模型推斷，上傳本地文件並調用訓練好的模型預測並在pdf reader中展示結果。這個工作在一個sprint內完成，對於【feat5】沒有完成的工作可以視情況在這個sprint內完善
- 【feat8】完善各表單頁面。包括新建/編輯connection、新建/編輯project、創建secure key等表單，添加提示、placeholder，並添加必要的前端類型檢查與報錯提示（如某些字段不能為空、sas uri字段必須符合uri格式，等）。這項工作較為瑣碎，預留一個sprint
- 【feat9】補全各頁面間跳轉邏輯與數據組織關系，串通創建-預覽-標注-訓練-測試-結果匯總的整體功能流程。這個工作設計項目各組件細節，需要整個團隊合作完成，占用一個sprint。這項工作完成后基本功能定型，可以釋出alpha版
- 【feat10】優化UI，包括配色、圖標、字體、頁面布局精調、瀏覽器適配、移動端適配等工作。一到兩個sprint的迭代后預期調整出用戶體驗良好、界面美觀的應用，同時修復alpha中發現的問題，可以釋出beta版。
- 充分測試並迭代完善后，可以在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，但由於修復性價比太低從而暫時將其擱置。