M2 终审
?1、團隊成員簡介
?
左邊：馬騰躍 右邊：陳謀
左上：李劍鋒 ?左下：仉伯龍 右：盧惠明
團隊成員及博客：
李劍鋒： ? ? ? ?Blog： ? ? ?http://www.cnblogs.com/Power-Byte/
陳謀： ? ? ? ? ? ?Blog:????????http://www.cnblogs.com/13061176Terry/
馬騰躍： ? ? ? ??Blog: ? ? ? ?http://www.cnblogs.com/summerMTY/
盧惠民： ? ? ? ??Blog:????????http://www.cnblogs.com/lhm924/
仉伯龍： ? ? ? ??Blog: ? ? ? ?http://www.cnblogs.com/zhangbolong/
2、軟件工程介紹
?
項目目標：
- 在線問答網站中散落著許多有價值的知識和有借鑒意義的經驗，然而對于一個不精通于信息檢索的人來說要尋找這些有價值的信息往往要耗費大量時間，甚至根本不能找到，故而本軟件在此需求的基礎上進行開發，以滿足用戶對于信息檢索，信息篩選，信息翻譯，信息可視化等方面的需求。
預期的典型用戶：
軟件的用戶方一方面是學霸在線教學問答系統后臺的開發人員，開發人員可以通過軟件提供的接口來直接對于數據進行處理，開發人員具有專業計算機水平，
軟件的用戶方另一方面是普通用戶，本軟件將功能性的模塊進行集成與封裝并且提供UI接口服務于普通用戶對于信息檢索，信息篩選，信息翻譯，信息可視化等方面的需求。
預期的功能描述：
軟件產品功能主要包括定義在線教學問答網站的內容結構，能夠從爬到的內容中抽取元數據并將其納入到既定的組織結構中，在用戶查詢時能夠給予快速準確的響應，并且支持標簽，翻譯的功能。
- 在線問答網站的內容結構定義；
主要是對在線問答網站的組織進行格式化提取，（包括網站的用戶提出的問題，以及其他用戶給出的相應的解決方式），然后按照既定的格式整理并且存儲到數據庫中。
- 增量式的數據處理；
對于后續爬取得到的最新數據，能夠按照定義好的內容結構準確地合并到已有的內容中。
- 文本標簽；
對于用戶提出的問題所屬的類別使用標簽進行分類。
- 文本關鍵詞提取；
對于問題中所涉及的主要內容以及術語進行分類提取。
- 文本內容翻譯；
滿足基于不同語言背景的用戶搜集檢索資料的需求。
- 用戶界面與用戶進行交互。
滿足界面友好的要求，對于用戶來說易于上手，易于使用。
- 給在線組和app手機客戶端組上傳數據
當有需求的時候，我們會給在線組上傳一定量的數據，由于給網站上傳大量數據的時候會給網站服務器增加負擔，有時網站拒絕訪問，有時網站崩潰，所以每次我們只上傳一定量的數據，從而讓上傳數據變得穩定。
預期用戶
- 由于我們的應用是給學霸客戶端和在線系統使用，所以的目標就是給他們定時提供數據。
3、產品需求及反饋
?
| ? 需求 | 反饋 |
| 1.上傳數據（在線組、手機app組） | 1.定義Json規格，定義上傳文件類型 2.通過Json向Solr這個搜索引擎后臺上傳數據 |
| 2.視頻文件（在線組） | 1.向爬蟲組提出要求，并且定時進行交流。 2.效果不盡如人意 |
| 3.問答（在線組、手機app組） | 1.剛開始用Stackoverflow的數據進行測試上傳 2.實現搜搜問問、百度知道、德問、cnblogs數據處理 |
| 4.對標簽進行定義（在線組） | 1.通過stackoverflow的api對相應的標簽進行定義。 2.其他標簽從文章中抽取。 |
| 5.標簽、關鍵詞結果分析（老師） | 1.與學長的進行了相應的對比，從F值來看，我們的測試效果比學長高17.8個百分點左右 |
| 6.兩個后端（老師） | 1.將處理數據和上傳數據分成兩部分，不同用戶可以登陸不同后端進行相應的操作。 |
?
用戶評價：
| 在線組 | 數據能夠用，但是上傳的數據太少 |
| app組 | 數據現在能用的太少 |
?
4、預期目標以及實際情況
?
| 預期目標 | 1.處理數量 60000條 上傳數量8000條 2.能夠處理pdf、ppt、視頻、doc 3.問答網站：搜搜問問、百度知道、德問、cnblogs、stackoverflow、知乎 |
| 實際情況 | 1.實際處理數量 55308條 上傳數量240條 2.實際能處理的文件pdf、ppt、小部分視頻 3.實際問答網站：搜搜問問、百度知道、德問、cnblogs、stackoverflow |
?
由于后期時間原因，我們與在線組和app組的交流比較少，導致我們在Json格式定義、測試方面比較緩慢；
視頻部分能夠處理是因為我們獲得的文件不都是特別好，有些是因為視頻的相關文本數據太少，所以沒法給其
添加標簽、關鍵字等重要搜索關鍵字。
5、分工協作
?
我覺得一個PM在擔當總的設計、構建是不太好的，我真心的認為兩個規劃能力好的同學共同擔當效果會更好。
因為我在統籌規劃的同時真心地覺得自身能力的不足，無法完美地擔任這個職責，所以我覺得至少有一個人監督會更好。
?
6、平衡 時間/質量/資源
?
| 時間 |
| ||||||||||||||||||||||||||||||||||||||||||
| 質量 | 進行了單元測試 | ||||||||||||||||||||||||||||||||||||||||||
| 資源 | 我們人力資源、物力資源都比較充足 |
?
7、軟件質量
?
?
對每一個功能都進行了單元測試，雖然有些測試并非完全覆蓋，但是總體來說我們的功能比較完善，而且bug比較少
?
?
8、M2階段的實際進展
?
9、團隊成員在M2的角色和具體貢獻
?
| 名字 | 角色 | 具體的,?可衡量的,?可驗證的貢獻 | 得分 |
| 陳謀 | PM & Dev | 寫了10篇博客，多次和爬蟲組、客戶端、在線系統進行溝通，寫了 3213行代碼 | 90 |
| 李劍鋒 | Dev & Test | 寫了823行代碼, ?200行注釋, 1篇博客? | 60 |
| 盧惠明 | Dev & Test | 完成關鍵詞抽取，寫了495行代碼，并完成相應的測試，2篇博客 | 40 |
| 仉伯龍 | ?Dev & Test | ?測試了關鍵詞抽取代碼，寫了235行代碼，測試其結果等 | 37 |
| ?劉夕霆 | Dev & Test | ?與android客戶端組進行溝通，寫了276行代碼，測試最終版本 | 35 |
| ?馬騰躍 | ?Dev & Test | ?寫了276行代碼,與在線組進行溝通、交流 | 38 |
?
10、成果展示
?
- 登陸界面
?
- 主界面：
- 添加文本：
- 原始數據：
- 去噪：
- 分詞：
- 翻譯原文本：（API）
- 翻譯譯文：
- 中英對照：
- 最終結果：
?
- 上傳數據
?
11、軟件Bug
?
我們的軟件管理中遇到的Bug基本上在http://www.cnblogs.com/cheneygroup/p/5117810.html
?
12、個人總結
?
轉載于:https://www.cnblogs.com/cheneygroup/p/5118595.html
總結
- 上一篇： SpringMVC数据库链接池,以及其他
- 下一篇： 要成为一个 Java 架构师得学习哪些知