基於Pytorch框架實現ENAS算法優化的圖像識別技術探索-α迭代隨筆

設想和目標

1. 咱們的軟件要解決什麼問題？是否認義得很清楚？是否對典型用戶和典型場景有清晰的描述？

• 咱們但願經過將ENAS的網絡架構優化算法轉變爲實例化項目，可以在有必定實際意義下解決對於Pytorch圖像識別的探索問題。
• 項目性質爲科研項目，因爲是依託算法研究產生產品，故對於產品自己性質並不明確，經過與老師交流後初步定義爲基於微信前端與後臺學習框架交互的識別平臺，主要以微信小程序的交互形式開放給用戶。
• 對於典型用戶，實質爲使用微信且對於某些特定物品有識別需求的人。而對於典型場景來講，目標是達到對於非熟悉場景與非限定化場景下對於物品的認知服務，但因爲時間與技術的限制，目前只能作到特定環境下對於數據集訓練完成的少部份內容進行識別。

 

2. 咱們達到目標了麼（原計劃的功能作到了幾個？  按照原計劃交付時間交付了麼？ 原計劃達到的用戶數量達到了麼?)

　　從項目完成狀況來講，確實達到了預期的目標，本次迭代主要完成了基本CNN網絡的構建，微信小程序前端界面的設計以及交互呈現，先後端交互以及服務器部署，爲第二次迭代開發做爲軟件基礎，主要實現瞭如下功能塊：

• 原計劃功能：

　　　　前端頁面設計與頁面交互，數據互通，服務器搭建及環境配置，實現手寫體識別功能及服務器部署

• 實現狀況：

　　　　前端頁面除與數據庫交互頁面外均設計並完成，頁面間邏輯關係通順並具備良好的用戶體驗，可是數據連通性目前較差，數據庫未創建。

　　　　服務器搭建已經成功實現，而且已經成功將代碼部署在服務器上，實現了對服務器的應用。

　　　　可以成功實現手寫體識別，而且實現了數據預處理，使得後臺應用能夠適應圖像的大小，形狀變化，對於特徵明顯的圖片識別精度能夠達到95%。

 

3. 用戶量, 用戶對重要功能的接受程度和咱們事先的預想一致麼? 咱們離目標更近了麼?

• 對於用戶量，項目目前處在未發佈階段，且成效未達到投產要求，用戶量較低，而且對於相似的科研項目，用戶量並不在咱們的考慮範圍內。
• 前端、後端以及先後端框架實際上在本次迭代中都已經徹底部署，咱們的主要目標爲ENAS的實現，其次爲基本交互與數據通路的組建，現階段已經完成對於平臺的創建以及網絡組建，與目標較爲接近。

 

4.有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

　　首先，因爲課程須要，咱們不可能單獨分出人員專門進行ENAS的算法實現，這勢必會致使人員分工的不平衡。故在本次迭代內不可能將人員排除在外以專門進行研究類學習。其次，本項目中對於平臺的創建涉及到框架搭建與環境配置，計算機網絡基礎，前端，後臺，學習成本較高。α迭代中沒有徹底的實現先後端人員分離，大部分精力主要用在粘合性解決與框架學習上。若是從新進行一次迭代，首先要作的是先後端分離，同時對於β版本中涉及的算法應當組織五人一塊兒進行討論，最終由後端設計進行實現。前端負責數據庫與頁面的設計，保留接口文檔。這都是咱們須要作卻沒有作好的地方。

 

計劃

1. 是否有充足的時間來作計劃?  

　　時間相對來講仍是較爲充足，平臺搭建自己較爲簡單，主要時間花費在於填補知識盲區與實踐。可是由於指導老師並無給咱們明確需求的緣由，整個項目的計劃並無十分的明確，直到α迭代結束時，需求分析也並無徹底打磨結束，仍然呈現較爲粗糙狀態，具體的需求不少須要在項目跟進的過程當中摸索。所以，咱們將日程進行了大幅度推動，迅速進入開發狀態，在不斷的摸索過程當中進行深度的動態需求分析。

 

2. 團隊在計劃階段是如何解決同事們對於計劃的不一樣意見的？

 　　團隊實際上分工是由PM來決定，可是因爲項目的算法性質，以及團隊內有部分紅員具備必定的深度學習基礎，故項目時間主要依託我與另外一位算法設計人員決定，對於設計與交互邏輯，主要由你們協商解決，根據不一樣方案所產生的後續開發利弊進行權衡。

 

3. 你原計劃的工做是否最後都作完了? 若是有沒作完的，爲何?

 　　團隊的工做除數據庫的部署和設計放在了第二次迭代計劃中外，均所有完成。

 

4. 有沒有發現你作了一些過後看來不必或沒多大價值的事?

 　　首先對於服務的配置，在沒有徹底進行需求分析的狀況下盲目選取技術棧，致使我和另外一位組員長時間糾結於使用哪種後端框架，以及如何解決https請求的問題，在實驗之初對於官方文檔並無很仔細的探查，致使數據類型出現不匹配或傳輸數據失敗的情況，這些都是因爲初期對於文檔不夠熟悉。對於基礎知識不足而盲目進行探查，致使大量時間浪費，出現了Apache和Nginx同時安裝的情況，項目進度停滯。

 

5. 是否每一項任務都有清楚定義和衡量的交付件?

 　　對於項目的檢查基本處在動態平衡的狀態，當某些功能塊出現沒法知足的需求時，會當即與開發負責者進行溝通，對模塊進行動態的調整，保證標準的統一。

這是較爲不規範的一點，但願在β迭代中可以以作好爲標準，而不是可用。（引覺得戒）

 

6. 是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，爲何沒有估計到?

•  是按照計劃進行，可是計劃不如變化快，在模型訓練時起初未考慮數據預處理問題，然後投入了大量時間解決數據的處理。
• 顯然數據處理是未預估風險，對於計劃重點，咱們主要關注了模型與算法，但對於數據的自己分析不足，致使未考慮數據來源。

 

7. 在計劃中有沒有留下緩衝區，緩衝區有做用麼?

　　有留下緩衝區，在α階段驗收前一週項目進入冷卻期，留出了充足的時間進行測試與修正。

 

8. 未來的計劃會作什麼修改？（例如：緩衝區的定義，加班）

 　　因爲接下來的項目難度較大，因此可能會須要較長時間專一於項目，而且要着重實現完成項目，可能會減小緩衝區的設置，多加班。

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

　　項目的完成過程當中，首先我理解最深的應該是團隊合做。即使一我的能夠作到再多事情，它的精力也是有限的，而這時，團隊合做的重要性便顯得尤其重要。其次，在項目開發過程當中，對溝通表達能力，基本的技術能力有了進一步提高，更加了解了項目的開發過程與基本框架的使用。若是再來一次，我必定會嘗試將分工與計劃落實到位，避免出現計劃不如變化快的狀況。

 

資源

1. 咱們有足夠的資源來完成各項任務麼?

　　時間資源上，咱們的時間仍是比較充分的，完成任務的過程當中也沒有時間緊張感。但相應的，形成了β階段迭代任務過爲艱鉅。軟件資源上，咱們在項目開始之初就選擇了購買服務器資源進行部署嘗試。對於算法自己，經過對於ENAS的論文以及對於其引述論文的分析，基本瞭解了實現，但細節上須要其餘資源進行豐富。

 

2. 各項任務所需的時間和其餘資源是如何估計的，精度如何?

• 各項任務主要以其任務總量與參與人員數目進行估計，而人員各自的時間則由我的獨立決定。
• 暫未尋求到其餘資源。
• 項目總體精度很差，不能老是保持高效與有序狀態。對於整個迭代，只有總計的時間節點，並無將分任務點的提交時間細化，同時也沒有預留出分任務點的解決時間，這是很差的。

 

3. 測試的時間，人力和軟件/硬件資源是否足夠? 對於那些不須要編程的資源 (美工設計/文案)是否低估難度? 

• 對於測試，沒有進行完整的測試例設計。僅簡單進行了測試集測試與負載測試。
• 人力資源足夠，對於硬件資源，主要缺乏GPU實例，致使模型訓練速度與開發速度不匹配。
• 美工的任務量較少，須要完成的內容不是不少，可是對於頁面設計與交互邏輯上須要下必定功夫，對於這方面估計與實際基本相符，故未產生較大阻礙。

 

4. 你有沒有感到你作的事情可讓別人來作（更有效率）?

　　我認爲咱們的分工較爲合理，每一個人各司其職，效率已經處於一種臨近飽和的狀態，故不存在相似情況。

 

有什麼經驗教訓? 若是歷史重來一遍, 咱們會作什麼改進?

　　並無認真進行資源 - 目標 -進度的負反饋調節，若是再來一遍咱們會從三個方面入手，提升開發效率。

 

 

變動管理

1. 每一個相關的員工都及時知道了變動的消息?

　　天天都會在羣裏討論，確保全部人的信息透明，準確，可達。

 

2. 咱們採用了什麼辦法決定「推遲」和「必須實現」的功能?

 　　首先咱們保證了用戶的基本使用路線的聯通，在此基礎上添加其餘功能模塊，故其餘功能模塊爲推遲，必須實現是用戶的關鍵路徑模塊。

 

3. 項目的出口條件（Exit Criteria – 什麼叫「作好了」）有清晰的定義麼?

　　完成CNN對圖片的預處理，簡單分析辨識後將結果經過微信小程序反饋給用戶。

 

4. 對於可能的變動是否能制定應急計劃?

 　　並無制定應急計劃，因爲未碰到緊急變動情況，這部分弊端沒有暴露出來，可能也是需求較爲模糊致使的。

 

5. 員工是否可以有效地處理意料以外的工做請求？

 　　對於忽然須要的數據集，咱們能夠作到緊急集合而且在三十分鐘內完成了數據集的製做與預處理過程。

 

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

　　首先對於可能遇到的突發情況應該有必定的處置措施，而不是遇到緊急需求時手忙腳亂的緊急集合。同時，咱們應當區分緊急需求與可推遲需求，以便發生緊急情況時能夠有預留時間進行處置。再來一遍咱們必定會指定應急處理預案，保證項目進度有序

 

設計/實現

1. 設計工做在何時，由誰來完成的？是合適的時間，合適的人麼？

　　整個模式的設計是在項目初期，進行需求分析時，由pm和老師溝通商定的。實際上在前八週設計開發過程當中都有設計工做，需求在動態的調整。由PM與老師進行溝通磨合我認爲是較爲合適的，同時咱們積極與老師溝通了時間，確保了每一位成員都能準確的瞭解需求，第一時間提出本身的疑問。

 

2. 設計工做有沒有碰到模棱兩可的狀況，團隊是如何解決的？

　　沒有，每個設計都須要詳細的討論是否可行，每個作出的決定都帶有很強的目的性和可行性，不存在模棱兩可的狀況。

 

3. 團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其餘工具來幫助設計和實現？這些工具備效麼？

　　咱們的每個模塊都是進行單元測試後嚴格對照接口來進行使用的，但因爲接口與接口之間的適配問題，致使對於集成測試的處置遇到了困難。

　　小組使用UML圖進行詳細的項目分析管理，經過活動圖、用例圖等分析項目的需求和對象。下面是小組設計的整個信息流與UML圖：

 

用例圖：

泳道圖：

時序圖：

 

從這幾個圖例能夠獲得咱們軟件的使用流程，功能的劃分，進而獲得α迭代的任務。

 

4.比較項目開始的 UML 文檔和如今的狀態有什麼區別？這些區別如何產生的？是否要更新 UML 文檔？

• 文檔更加豐富了，會在項目推動中，不斷完善、更新文檔，豐富項目中的類構建。同時隨着對項目的不斷理解，對UML文檔進行了更新與完善，增強了對UML文檔的設計。
• UML須要更新，咱們沒有設計ENAS算法的UML圖，實際上整個算法纔是項目的核心內容，在聽取老師建議後須要對算法設計UML圖，將核心算法分解爲子模塊與子算法，進一步細化功能。

 

5. 代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

 　　經過組與組之間代碼互審進行的。咱們的代碼的代碼規範有些缺失。

 

咱們學到了什麼? 若是歷史重來一遍, 咱們會作什麼改進?

 　　首先咱們學會了使用UML圖來指導項目設計，同時對於整個項目各個部件間的溝通也主要依據UML圖來進行。其次須要對代碼的規範性進行復查和嚴格審覈，代碼的規範性尚有待提升。我認爲咱們主要須要規範代碼，同時嚴格按照UML圖中的走向進行程序開發。

 

測試/發佈

1. 團隊是否有一個測試計劃？爲何沒有？

　　有針對驗收標準進行商議和參考，可是沒有針對具體的計劃。對於初期開發，整個團隊並無創建很強的自信心，整個項目從無到有咱們很難說本身有一個能夠拿出來進行測試的成品。固然第一次迭代以後會對項目設計測試計劃，對ENAS的性能進行系統測試。

2. 是否進行了正式的驗收測試？

　　是

 

3. 團隊是否有測試工具來幫助測試？

　　沒有

 

4. 團隊是如何測量並跟蹤軟件的效能的？從軟件實際運行的結果來看，這些測試工做有用麼？應該有哪些改進？

　　暫未考慮

 

5. 在發佈的過程當中發現了哪些意外問題？

　　小程序的發佈須要備案審覈等，不考慮進行發佈。

 

咱們學到了什麼? 若是重來一遍, 咱們會作什麼改進?

 　　程序的完成與測試仍是重點，同時要合理安排時間，留下確切的冷卻期。在單元模塊的開發過程當中進行單元測試，同時對於集成測試應當留有測試樣例與接口文檔，必要時能夠安排專人進行測試樣例設計。

 

團隊的角色，管理，合做

1. 團隊的每一個角色是如何肯定的，是否是人盡其才？

　　團隊角色肯定，以尊重我的意願爲首要因素，再根據實際狀況協商肯定角色。參照自身的學生身份，現階段我認爲仍是以開闊眼界，尋找本身感興趣的方向爲主，儘量保證普遍涉獵，從而選擇適合本身的方向。

 

2. 團隊成員之間有互相幫助麼？ 

　　有，諸如宋朝都同窗與我積極探討了關於ENAS的算法實現，以及顏岑同窗曾與我探討的對於圖片的預處理的一些見解，都是難得的幫助。

 

3. 當出現項目管理、合做方面的問題時，團隊成員如何解決問題？

　　你們共同商量，綜合每個人的意見，儘量達到讓每一個人以爲公平，平衡。

 

總結:

你以爲團隊目前的狀態屬於 CMM/CMMI 中的哪一個檔次?

　　屬於CMMI一級，完成級

 

你以爲團隊目前處於 萌芽/磨合/規範/創造 階段的哪個階段?

　　磨合基本完成，接下來是規範

 

你以爲團隊在這個里程碑相比前一個里程碑有什麼改進? 

　　你們彼此更加熟悉，互相的配合會比以前更有效率，同時漸漸有了明確的分工和側重點，好比咱們這邊PM側重前端開發，而其餘人員多側重於先後端鏈接與數據通路設計，我主要側重算法分析與後端的建設。

 

 你以爲目前最須要改進的一個方面是什麼?

　　提升效率，劃分分工界限。

 

對照敏捷開發的原則, 你以爲大家小組作得最好的是哪幾個原則? 請列出具體的事例。 

　　在團隊內部，最具備效果而且富有效率的傳遞信息的方法，就是面對面的交談。咱們小組每週都有交流，也每週都會開會討論，無論線上線下（雖然有的時候沒有寫會議記錄）。你們相互之間的交流也有助於咱們進步。並且你們相互幫助，在面對問題時互相助力，共同解決。如對於數據通路的聯通問題，咱們曾專門留出一個下午進行集中開發，衡量了迭代的優先級，最終迅速的解決了問題。