『編程題全隊』需求分析與設計

『編程題全隊』需求分析與設計

需求分析

1.訪問用戶

本次用戶訪問，咱們結合了調查問卷和線上線下采訪老師朋友的方式。

• 問卷星連接

• 線上採訪：

• 線下采訪：（emmm應要求厚碼）

由於好友圈子的限制，咱們所調查的用戶年齡職業範圍相對小，基本是二十歲左右的在校學生↓

調查中能夠發現被調查人對這種我的事務軟件仍是很須要並對市面上已有軟件進行使用↓

問卷反饋中，咱們相對於市面上已有軟件的不足之處及用戶須要的功能進行採集↓

「我以爲以日曆界面顯示任務頗有必要，有的軟件的日曆界面能夠看到一天的任務，可是一個日曆（好比一個月）就沒有那麼直觀；奇妙清單裏的文件夾裏不能再分文件夾，清單沒有分子清單的功能；最重要的一點，不能收費！」
——不願透露身份姓名的大佬

「但願支持多平臺同步，手機和web電腦客戶端；操做不要太複雜；支持簡單的分類（自建列表）；日程提醒相結合；支持事件緊迫度的選擇（好比：緊急（48小時內）、通常、長遠計劃），將原型中的下拉框換成互斥性的選擇按鈕，簡單操做；軟件的特殊標誌作到用得恰到好處（如：五角星有收藏等意義，不要用於裝飾）。」
——鄭如濱老師

被調查用戶表示，但願新開發的軟件可以實現平常事務管理和提醒、多人任務共享和協做編輯、並支持備忘錄功能。
咱們將繼續開放調查問卷便於蒐集更多的信息。

2.需求規格說明書

  Gugua需求文檔-Git附件

3.競爭性需求分析

殺手功能見第一象限

4.NABCD分析

列舉出項目的NABCD
NABCD:

1. Need 需求
   當須要處理的任務事項等多到必定程度時，就須要一個我的任務管理工具來幫助管理。它能從混亂的事項團中篩選出最主要的部分，引導使用者逐步完成計劃；一樣，人們也有與團隊之間分享、或者是共同承當一些任務的需求。
2. Approach 實現
   使用C++/QT 設計桌面客戶端，使用python設計服務器端，即不失開發效率，也保證了軟件性能。
3. Benefit 收益
   • 我的事項管理+提醒事項收納+團隊協做分享+甚至是計劃流程kanban模式，所有合爲一體，讓你的生活井井有理。
   • 避免了用戶面對許多的待辦事項而無從下手的狀況
   • 同時避免了用戶忘記重要的提醒事項
   
4. Competition 競爭
   並無找到能將團隊協做,團隊開發流程,以及我的事項管理等合爲一體的軟件 , 而設計中還有很重要的一點是將提醒事項這一特殊的任務抽取出來,成爲獨立的一部分,同時學習了"石墨文檔","kanban開發方法"等技術的優勢,加強了產品的團隊屬性
5. Delivery 交付
   發佈計劃是先部署在git雲倉庫的release模塊，後期在服務器上提供web端下載連接

進一步分析

1. N（Need）：通過咱們的訪問和調研，瞭解到無論是高校學生、教師、公司職員、創業者等，天天、每週或者每個月都有一些或者繁多的事務須要處理，他們一般採用手動制定計劃、編寫電子備忘錄，他們但願經過安排簡單但內容詳細的事務安排來增長本身的工做效率，提升本身的工做質量。許多年輕人也開始使用相應的事務安排軟件來進行管理，同時許多輕量級的團隊也有着團隊協做的需求，能夠提供給團隊有效的合做平臺，體驗合做帶來的樂趣、便利和高效。
2. A (Approach 作法)：咱們PM擅長編程語言和工具C++/QT，對於中小型項目有必定的經驗，其餘前端開發的人員也有小型項目的基礎，對於前端的設計基本沒有什麼問題，具體的bug會由開發人員和測試人員共同協做修改；後端的主要負責人對於MySQL的運用和管理有必定的基礎，後端咱們決定用python實現。咱們在有必定實例的基礎上，可以在項目進行的同時不斷學習新知識點以完善項目。進過咱們團隊的協商，決定本產品的客戶端版本須要鏈接到本地的SQLite數據庫，數據庫軟件已內置在桌面端的編程語言工具C++/QT中，使用版本爲QT5內置版本SQLite。服務器方面使用的爲MySQL數據庫，使用版本爲 MySQL 5.0.10。服務器與客戶端之間網絡通訊協議爲HTTPS，採用的同步通訊機制爲客戶端和服務器之間的鏈接時無狀態的，服務器架設模式相似網站服務器。客戶端在須要數據的時候向服務器發出POST請求，服務器經過本地中央數據庫查詢返回結果，以後關閉該次短鏈接。在須要實時同步數據的狀況下，客戶端啓用輪詢的方法，每過一段時間向服務器發起更新請求。直接採用加密由HTTPS協議內部的TLS協議負責來實現通訊安全。
3. B (Benefit 好處)：具備很高的可用性和穩定性（系統在一些異常狀況下有恢復能力），產品內部使用技術爲編程語言C++的跨平臺庫QT，該GUI庫致力於跨平臺性，在跨平臺方面有着自然優點，實現多平臺的使用給用戶帶來便利性。咱們提供人性化的GUI界面，有我的任務界面，也有團隊管理界面，讓我的和團體用戶都能輕鬆使用。具備同步功能也有離線功能，用戶能夠隨時隨地使用，保證用戶按時完成任務。同時由於咱們本身團隊也在使用這個軟件，至關於邊測試邊開發，確定會作到更完美。

4. C (Competitors 競爭)：市場上有一些功能與該產品部分重疊的產品，有微軟旗下的Wunderlist，評價很高的TickTick等，可是本產品結合了我的管理軟件和團隊協做軟件的特色，在設計理念上，分離出了提醒事項這一特殊類型的任務事項，不只有我的事項管理功能，還兼顧了輕量級的團隊協做需求。咱們最大的優點就是跨平臺性，如今的人都有各類不一樣的設備，保證用戶在持有不一樣設備的同時也能享受服務。咱們後期仍是提供個性化設計，爲不一樣的人羣提供不一樣的版本。

5. D (Delivery 交付)： 首先，咱們會利用本身已有的社交平臺（微博、微信、集大通）進行宣傳，咱們會制定相應的動畫演示視頻上傳 大型視頻網站，經過互聯網信息的傳播性，介紹產品的特色和特點，給網友以辨識度，儘可能提升產品的知名度。咱們還將走進校園，經過擺點介紹和讓用戶實際體驗，學生用戶的好評將會是一個無形的廣告；咱們還會經過街頭測試，讓行人體驗事務管理軟件，並同時給出評價和建議，製做成相應的視頻，上傳到網站，讓潛在的用戶看到咱們用心和誠心。

5.NABCD電梯演說

  各位領導/投資人/用戶/合做夥伴：咱們的產品事項管理系統Gugua是爲了解決有事務管理須要的人羣的痛苦, 他們須要 一個便利和高效的我的和團體事務管理平臺，可是現有的方案並無很好地解決這些需求，咱們有獨特的辦法是提供跨平臺的軟件和完善的事務管理安排邏輯設計，它能給用戶帶來隨時隨地使用同時具備高可用性和穩定性的體驗，遠遠超過目前市場上的競爭對手TickTick。 同時，咱們有高效率的社交宣傳、視頻宣傳、實地宣傳的方法，能很快地讓大部分用戶知道咱們的產品，並進一步傳播。

下面來看咱們團隊的知名up主、聲優主播WW進行的演說視頻 點一下，玩一年

---

原型設計

原型設計展現

主要界面展現

• 登陸界面
  
• 我的任務界面
  主要由任務框和列表框組成，右側的彩色小點是提醒事項的形象化表現
  
• 團隊管理界面
  這裏採用了一個三級目錄結構
  每個團隊都有多個項目，而每一個項目都有多個看板
  看板上的團隊任務就是團隊界面下的最小單位
  
  

演示界面：墨刀-Gugua prototype

原型工具介紹

使用的原型工具爲墨刀
能夠很容易地使用拖拽控件的方法構建原型界面，並且能夠模擬出交互的效果，最重要的是分享演示原型十分地容易，支持導出爲各類演示包（例如能夠直接在手機上運行的apk安裝包、能夠在本地經過瀏覽器演示的html包等等）

---

任務分解

1. 給出團隊項目的WBS(Work Breakdown Structure)

使用工具爲: ProcessOn-在線做圖網站

2. 團隊成員估計各自任務的所需時間

成員	任務模塊	估計時間(hour)
孫志威	客戶端GUI模塊以及網絡通訊等	105
孫慧君	客戶端GUI模塊以及數據庫等	100
黃華林	服務器端的事務邏輯實現	80
王威	服務器端的架構和通訊協議等	83
連燕波	負責產品的測試和審覈	103
倪兢飛	服務器的數據庫設計實現	82

---

編碼規範

1. 制定團隊的編碼規範

• 具體規範
  • C++部分使用Google C++規範
    
  • Python部分遵循Google python規範
    
• 總結要求
  • 可以讓隊友迅速理解代碼
    

  • 通過很長一段時間後代碼依然可讓人容易理解

    2. 上傳至Git

• 客戶端Git附件地址
• 服務器端Git附件地址

---

系統設計

1. 系統架構

整體架構圖

分層架構圖

2. 數據庫設計

本項目在服務端和客戶端使用了兩種數據庫:

• 服務端使用MySQL
  • 維護全部用戶的信息
  • 負責同用戶多設備之間的信息同步
  • 負責協做用戶之間的數據交流
• 客戶端使用SQLite
  • 主要充當離線緩存數據庫
  • 可做爲中央數據庫關於本地用戶的數據備份

所以，客戶端數據庫實際上是中央數據庫的子集,故在此主要介紹服務端數據庫設計

• 數據庫關係表圖
  

• ER圖
  

---

團隊分工

成員	角色	分工
孫志威	PM/Dev	主要編寫了需求規格說明書，參與了系統架構設計等
孫慧君	UI/Dev	主要設計了軟件的原型，參與用戶採訪等
黃華林	Dev	主要對產品進行了NABCD的需求分析，參與了用戶採訪等
王威	Dev	主要設計了數據庫，參與了系統架構等
連燕波	QA	主要編寫了需求規格說明書，參加了用戶採訪等
倪兢飛	Dev	主要對數據庫進行設計，參與了任務分解過程

完成狀況

everybody	100%

做爲PM，我很高興地看到個人隊友們都十分的積極，分配的任務也都較快地完成了，但願在以後的學習過程當中咱們依然能保持活力和激情。

我的感想

• 孫志威(201521123077)：
  感想：
    本週咱們團隊對咱們的產品進行了需求分析和設計。
    做爲團隊的PM，這周我作了不少規劃和架構的工做，這讓我對咱們的項目有了更深的認識，學習到了不少軟件工程的知識和方法，能夠說是受益不淺。
    在你們的協做下，咱們還算優雅地完成了此次的衆多任務。學習到了不少知識，更重要的是體會到了與隊友們一塊兒懷着共同的目標一塊兒協做的感受。

  ---

• 孫慧君(201521123098)：
  感想：本週，我完成了軟件原型的設計，並參與了用戶的採訪。
  這是我第一次較爲完整地完成一個軟件原型設計，使用了墨刀原型設計工具，很順利地完成了任務，值得高興的是也獲得了隊友們的確定。
  團隊的每個人都積極參與了項目的製做，隊友之間都能相互探討研究，提出本身的意見和建議，努力完成好本身的部分，儘可能作到最好。
  可以在這樣資一個共同進步、相互鼓勵的團隊裏成爲其中的一員，我感到很驕傲，這是一個好的開始，但願可以繼續合做，順利走好項目的每一步。
  下週開始就是第一次七天衝刺了，有一點緊張又有一些期待，不能由於本身一我的拖了隊員們的後腿，要加油啊！

  ---

• 倪兢飛(201521123061)：
  感想：這周個人任務是與另外一位同窗一塊兒設計咱們這款GTD軟件的數據庫，設計數據庫的過程分爲幾個部分，首先要進行需求分析，與團隊內的成員進行進行交流，肯定當前計劃內須要的基本數據；其次進行概念設計，把所需數據經過ER圖表現出來；接下來就是實現將ER模型到關係模型的轉換；最後經過MySQL創建數據庫；在概念設計階段，要遵循設計數據庫時的範式準則，並考慮周全。

  ---

• 連燕波(201521123081)：
  感想：這周要作的事項比上週多了，每一個人也都開始忙碌起來，通過簡單的商議以後，每一個人都投入到緊張的工做當中。
  我也開始着手市場需求調查以及需求規格說明的編寫。對於市場調查，咱們想到了許多需求，也收到了反饋，在不使產品失去核心功能的前提下篩選精華。
  用戶的需求正是產品的走向；
  而產品的規格說明是創建在整體的系統架構設計上完成的，咱們參考了老師的模板以及上網查詢了相關資料，可以比較順利地完成。
  整個過程，團隊分工明確，有條不紊的進行着各自的工做。

  ---

• 黃華林(201521123082)：
  感想：本週，個人任務主要是負責NABCD的需求分析。我在咱們PM的安排和幫助下，將咱們項目的NABCD寫出來。在此過程當中考慮了產品的前景、考慮產品應該具備的產品功能和特點，根據不用用戶的習慣和需求，提供不一樣的服務，提升給用戶儘可能完美的體驗。同時咱們也對比市場已有的產品，取其精華，去其糟粕；咱們也認識到一個好的產品須要有好的宣傳方法和必定的用戶數量，才能證實其價值，因此討論了幾種可行的宣傳方式。特別感謝王威同窗提供其悅耳的聲音，流暢的介紹，給咱們的產品的宣傳帶來的正面影響。

  ---

• 王威(201521123076)： 感想：這周個人任務主要是數據庫的設計，目前只是把最基本的核心模塊的數據組成架構好了，讓咱們有一個比較完整的概念，還不可以適應接下來的動態需求，下週開始還須要與前端人員進行溝通交流，完善數據庫的設計。