項目展現$\alpha$

項目	內容
課程：北航-2020-春-軟件工程	博客園班級博客
要求	強制轉會與項目展現
咱們在這個課程的目標是	提高團隊管理及合做能力，開發一項滿意的工程項目
這個做業在哪一個具體方面幫助咱們實現目標	展現項目並總結

VisualPytorch發佈域名+雙服務器以下：
http://nag.visualpytorch.top/static/ (對應114.115.148.27)
http://visualpytorch.top/static/ (對應39.97.209.22)

1、成員簡介

我的介紹詳見：團隊介紹和採訪

「假」相	姓名(博客園)	成員簡介	角色定位
	孫Y	管控項目進度、成員任務分配、貢獻分計算、項目部署、會議組織、項目分享、博客撰寫等多種任務。	PM/後端開發者/項目部署者/博客撰寫者
	鍾RH	提出許多新穎的idea，推進前端部分進度。進行項目的部署並修復了不少bug。	前端負責人/項目部署者
	吳F	查找了前端模板，實現了模型搭建模塊的主要邏輯。	前端開發者
	蘇HX	實現了模型保存及幫助文檔的前端邏輯。	前端開發者
	陳CW	撰寫了詳細的幫助文檔，設計了先後端對接的json接口，推進後端部分進度。	後端負責人/文檔撰寫者
	許TL	4月中旬加入團隊，在後端進行部分輔助工做。	後端開發者

2、軟件工程

1. 團隊概述

• 團隊項目的目標：提高團隊合做能力，瞭解工程開發流程，開發一項滿意的工程項目
• 預期的典型用戶： 學生，deep learning初學者
• 預期的功能描述：繼承了上一屆的VisualPytorch，宏觀架構基本一致。在上一屆實現拖拽生成模型代碼並提供打包下載、用戶登陸、訪問量統計的基礎上，添加更多的網絡層，支持封裝、經典模型、模型共享等功能，讓小白也能親手實現圖像分類、圖像分割等功能。具體內容見：功能設計
• 預期的用戶數量：alpha階段註冊100人，生成模型數300個
• 團隊的產品如何知足了用戶的需求：deep learning初學者因爲對pytorch不夠熟悉，不知道各個網絡層以及全局數據的參數應該怎麼選擇，在看了幫助文檔中對他所需參數的大體介紹後，配置出了本身的模型，並生成了代碼，成功運行。

2. 過後回顧

• 看到目標用戶使用產品的過程和評價，見用戶反饋&bug

• 事先定義的目標達到了麼：模型生成數（332）達到了，但註冊人數（64）還差一點，可能有如下緣由：

  • 項目還不足夠吸引人：沒有知足面向用戶的需求，以前預約的封裝功能尚未實現
  • 使用起來還不方便
  • 網站的安全機制，加載速度不盡人意
  • 宣傳力度還不夠

• 團隊的成員如何分工協做的？有什麼經驗教訓？

  分爲前端和後端兩部分，由PM進行協調工做。互相之間可能存在誤解，由於需求不是很是明確。

• 團隊是如何進行項目管理的？

  經過github平臺每人一個功能分支。

• 團隊如何平衡 時間/質量/資源 爭取如期完成任務的？

  實際上並無徹底按照需求完成任務。因爲時間不足，開發僅有兩個星期，同時免費版Jsplumb不支持，網絡層封裝這一功能仍是沒有實現，所以在此基礎上的經典模型也不能實現。轉而實現了擴展更多的靜態參數（如損失函數、優化器等）及模型保存。

3. 測試

• 測試用例數目，代碼覆蓋率數目

  • 先後端結合：4個數據集對應的經典模型，從搭建到代碼跑通獲得正確率結果

  • 後端：使用Anaconda的coverage庫進行後端覆蓋率測試，19個樣例（9個測試網絡層，9個測試靜態參數），整體覆蓋率達到88%

• 運行測試用例獲得代碼覆蓋率的視頻錄像

4. 文檔與規範

• 代碼規範在哪裏？NAG小組代碼規範

• 齊全的文檔在哪裏？

  • 先後端接口文檔：alpha先後端接口文檔（一） alpha先後端接口文檔（二）
  • 使用幫助文檔：幫助文檔 幫助文檔2
  • rest api文檔：Visual Pytorch

• 有些項目是在原來的基礎上改進的，那麼咱們團隊的軟件工程項目質量有什麼樣的提升？

  在前端設計與後端編譯上有明顯的提升。

  • 後端：新增了6類網絡層，並對原有的網絡層參數進行擴充。同時新增多種靜態參數（如損失函數、優化器等）
  • 前端：對原有頁面進行了改進設計，並新增了多個頁面，根據後端新增內容添加模型建立頁面內容。
  • 測試方面，原有項目僅對後端用戶註冊登陸模塊進行了自動化測試，本項目則對後端一系列方法進行了自動化測試，大大提高了代碼覆蓋率。

• 原來的項目有些代碼混亂，沒有註釋，沒有詳細的文檔，大家的項目是如何更好解決這個問題的？明年的同窗繼續開發這個項目，會不會出現相似的抱怨？若是一個新學生在一臺新機器上想編譯並運行你的項目， 請問能順利完成麼？有什麼樣的文檔能指導新學生？

  • 事實上原有項目留下了詳細的接口設計文檔，可是仍有大量的框架學習與代碼閱讀任務。
  • 先後端均學習Django/DjangoRestfulFrameWork，後端重點在於修改Json並根據Json輸出對應代碼,前端重點學習了JS/CSS/HTML/JQuery/Jsplumb等知識，經過修改Bootstrap模板解決了設計問題，經過與後端交流Json傳輸格式解決了新增網絡問題。
  • 明年的同窗作增量開發時也會面臨大量的框架學習與代碼閱讀任務，其對應的時間投入很難下降（即便咱們已經有了詳細的先後端接口文檔）。
  • 編譯運行較爲簡單，根據ReadMe進行實現便可。

5. 需求分析

• 對於項目的目標用戶是通常學生的項目， 大家如何找到學生作需求分析？他們給你什麼樣的反饋？

  在需求分析中，咱們以組內分析爲主，不過也經過詢問、調查等方式作了一些需求分析，好比將項目推廣給同窗時，會收集他們對項目的反饋信息。例如，有同窗在使用後反映在項目生成的代碼loss有點高，以及網站反應速度不夠快的問題，咱們將在之後的版本中進行相應調整。

  除此以外，咱們的項目還提供了問題反饋界面，用戶能夠直接在項目中反饋相關問題，包括有關用戶需求方面的問題。不過，目前還未收到有效的反饋信息。

  在接下來的版本中，咱們會結合現有項目，作更爲深刻的需求分析。

• 全部的項目都會收集到用戶的數據，請問大家對這類數據作了什麼樣的分析，這些分析如何驗證或推翻了原來的假設？這些數據如何幫助項目改進軟件工程的質量？

  咱們的項目中，共蒐集了歷史訪問量、註冊用戶數和生成模型數三個數據。

  咱們分析了訪問量的狀況，感受訪問量並不如咱們的預期，多是因爲咱們的宣傳力度不夠大，也多是因爲對可視化神經網絡模型的興趣沒那麼高，也多是生成的代碼性能不理想等其餘緣由。註冊用戶數和生成模型數也是相似的結論。

3、項目進展

1. 團隊項目的實際進展：

使用了工做記錄代替燃盡圖，由於其信息含量更大，更能反映小組成員的工做。

2. 發佈的功能：

詳見發佈聲明α

3. 在哪裏發佈了軟件， 用戶反饋的截屏

菜市場、同窗羣、博客

4、團隊成員在Alpha階段的角色和具體貢獻

1. 工做記錄概覽：

2. 互評

0：孫燁；1：鍾瑞豪；2：吳凡；3：許天立；4：康洪基；5：陳從文；6：蘇海翔

評分規則詳見：團隊貢獻分分配規則

按照團隊貢獻分=300*(0.7*softmax(工做記錄分+50)+0.3*互評分)獲得如下結果：

名字	角色	工做記錄分	互評分	團隊貢獻分
孫燁	PM	178	0.15976067589741974	67
鍾瑞豪	前端Dev	130	0.15553176387411125	57
吳凡	前端Dev	69	0.15702927958866533	43
蘇海翔	前端Test	101	0.1547674682579001	50
陳從文	後端Dev	98	0.15643689451435042	50
許天立	後端Test	0	0.12225508130759383	23

5、特點功能

所作軟件最有特點的功能是什麼，請着重介紹一下。活的用戶如何從你的軟件中獲益的，請現場展現。見 VisualPytorch

頁面	功能描述	頁面展現
登陸界面	一、用戶的註冊功能 二、用戶的登陸功能
框架構建	一、個性化構建本身的框架 二、可以保存爲本身的個性化構建 三、可以實現參數調整
模型管理	一、模型的刪除功能 二、模型的查看 三、導出代碼
代碼生成	一、根據所選框架生成特定代碼
問題反饋	一、能夠向後臺反饋存在的bug 二、能夠看到以前反饋問題的應答
用戶統計	一、統計網站ip的訪問次數，記錄用戶使用人數
關於咱們	一、羅列有製做團隊的具體信息，能夠發郵件進行詢問
幫助文檔	一、動圖展現操做方式 二、對模型參數的文檔

6、用戶反饋&bug

咱們測試獲得的bug詳見：測試報告α

如下4個評價，在用戶體驗上反映出了不一樣的bug：

1. 助教：

用戶註冊的時候是否會考慮到強校驗呢？
試了一下，用戶名長度、符號，密碼長度、符號沒有校驗，沒有郵箱驗證。
安全性這方面，若是想攻擊服務器的話，腳本批量發送POST請求會產生垃圾用戶數據，量大可能會拖垮服務器。

這確實是咱們沒有考慮到的bug。

前端JS中對長度是有限制的，比較寬鬆。後端對應部分直接繼承本來項目的代碼，未作修改。郵箱驗證後續版本會經過django相關插件實現，提高安全性。

2. 昂神：

建議把靜態資源整合整合，如今資源請求太多了加載賊慢
還有有條件的話建議掛上cdn
以及感受還算來得及的話，js部分能夠整合整合邏輯，更來得及一點的話，能夠乾脆換上vue

在1核1G的服務器上掛載的靜態資源太多，現已將gif及圖片改爲外連接的形式，緩解資源請求壓力。後續考慮其餘緩解方式。

3. 同窗A：

不支持經典模型的導出，搭建一個模型對於一個新手來講仍是太麻煩
建議設置一些典型的樣例，否則根本不知道該怎樣操做

原本在\(\alpha\) 階段應該實現經典模型功能的。實際上後端json已經基本實現了。但無奈卡在了前端工具上，\(\beta\)階段會實現這一功能。

4. 同窗B:

大家的項目對於我來講沒有什麼吸引力，感受拖來拖去尚未手寫來得方便
建議添加一些新功能，好比reference，實時查看大家代碼的效果

這位同窗說的的確很正確，咱們的項目對於多數人來講沒有什麼吸引力，不多會有人直接用咱們的網站去寫代碼。後續添加reference功能，上傳訓練好的模型在線推理。

7、總結&計劃

1. 每人總結

總結	在Alpha階段學到了什麼	對軟件工程的教育、課程的批評建議
孫燁	對於這一龐大的工程進行分解，合理分工，協做完成。在討論和會議中鍛鍊本身組織和管理能力。 瞭解瞭如何作一個PM協調小組成員，清晰了項目從設計到發佈維護的全過程。	老實說，課程設計的不是很人性化，讓我想起上學期的無線網絡系統：老師覺得咱們會了一切，卻根本不能理解做爲剛入門學生進行工程化項目的曲折之路，可是又一邊Push進度，提出不少強制要求。 實際上痛苦事後纔會有收穫，被軟工折磨的日日夜夜，成長和收穫也是成正比的。
鍾瑞豪	系統瞭解了先後端的各類框架/服務器部署相關知識，加強了與同組同窗的合做。 系統瞭解了軟件工程的相關知識並進行了實踐	與其餘老師的平行班級相比，分數基本一致，任務量感受不在一個數量級。
吳凡	溝通的重要性	但願博客少一點
蘇海翔	學到了django等模型框架（本身還稍微看了一點其餘的框架，好比vue什麼的），還有jsplumb這樣的插件，掌握瞭如何快速套用前端模板的方法，同時對前端debug的方法更加熟悉。對於不一樣功能，不一樣樣式的前端代碼，都能快速讀懂並進行須要的操做。	關於軟件工程的教育，我以爲單靠項目+博客的形式，不足以使學生充分學習和體驗工程化方法的每一個步驟。 我的項目和結對項目的難度有點大，時間也比較緊，自由度也比較低，感受不像是軟件工程課的做業，而是編程課的做業。雖然在代碼質量與代碼測試方面學習到不少東西，但感受仍是應該選擇一些需求比較模糊，而開發難度不是特別大的項目做爲軟工項目的題目。 另外，雖然課程上並無明確的限制，但不管是從給定的題目來看，仍是從各組最終選定的項目來看，項目的主題大多偏向於學習性質（特別是計算機學習），不少項目均把學生做爲典型用戶，有些項目的應用場景被限制在校園範圍內。雖然這樣的選擇也有本身的道理，但考慮軟件應用的普遍性，適當打開思惟，拓寬選題思路也何嘗不可。
陳從文	pytorch神經網絡概念知識，django的使用以及先後端交互和DEBUG的基本流程 瞭解了團隊分工和軟件開發的大體流程。	能夠更多點實踐知識少點理論知識，同時讓助教參與到項目開發中。
許天立	軟件開發的技能不少是我以前從沒接觸過的。好比說咱們此次用的django這個框架，我在這以前就歷來沒用過，也沒接觸過任何一種框架。而現有的框架那麼多，更新換代那麼快，也不能說精通全部的框架，這個時候，學習能力很重要，alpha階段，我最大的收穫可能就是自學的能力	無

2. Beta階段大致計劃

在接下來的版本中，咱們會更多地花時間去支持更多模型的搭建、豐富產品內容、提高用戶體驗。

包括\(\alpha\)階段但願實現而還沒有實現的：

• 支持網絡封裝成基本模塊
• 經典模型（如U-Net, ResNet, AlexNet, VGG-16等）

已經實現還能夠進一步改進的：

• 更精美的可視化
• 幫助文檔的撰寫

以及須要在將來實現的：

• 模型的本地部署與在線運行
• 集成tensorboard可視化
• 模型分享與交流
• 模型參數分析與可視化

在\(\beta\)階段，咱們會繼續努力，爭取完成以上預約的目標，提供一個儘量實現的最好的產品