需求分析
軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。
1.訪問軟件項目的真實用戶（至少10個），確保軟件真正體現用戶的需求，為軟件最終可用奠定基礎。
我們調研的方式是采取的方法是問卷調查和采訪想結合
下面是此次我們問卷調查的分析：
首先是性別分布百分比：
年齡段分布百分比：
對游戲是否有真實的興趣：
受調查者玩的游戲類型分布:
受調查者玩手機游戲的真正目的：
對受調查者手機里的游戲數目進行調查：
受調查者玩手機游戲的頻率：
受調查者玩游戲的時間段：
從問卷調查報告可以看出，玩手機游戲的大部分都是男生，有小部分女生群體。由於我們的用戶調查大部分都是由大學生填寫，所以年齡分布這塊不多說。其次，從數據出可以看出，大部分同學是喜歡玩游戲的，並且是為了排解我們平常的學習、工作壓力，而且大部分游戲的時間都是用在上課（這樣可不好）和短暫的休息時間。
我們一共采訪了5個人，年齡為21~24歲之間，以下為部分采訪內容。
1.請問現在有玩什么手機游戲嗎？
Z：現在有在玩決戰平安京，和刺激戰場還有就是一些單機小游戲。
2.是什么樣的小游戲呢？
Y：有很多啊，比如象棋，斗地主。跳一跳之類的。
3：你有興趣試玩一下我們做的一款24點的益智小游戲嗎？
Z：玩是可以玩一下，因為現在快畢業了，有考公的想法，那些大型手游太耗費時間，所以更會玩一些小游戲來放松自己，也不會沉迷進去。
4.你認為現在的跳一跳這塊小游戲成功的原因是什么呢？
X：可能現在人都很浮躁吧，不會持續的玩一個游戲，這個時候玩些沒有連續性的小游戲也能打發時間而且還能跟朋友一起比一比吧。
經過對幾位同學以及其他人的采訪，我們認為現在的小游戲還是很有市場的，既能夠放松自我，也不會沉迷進去。而且我們也收到了很好建議，可以加入排行榜好友系統，這樣與朋友一起也會更有樂趣。我們的用戶就是那些不會讓游戲干擾到正常學習生活，同時又想偶爾放松自我的年輕人，就從這點看，雖然我們的游戲並不復雜，但是還是能有一定的競爭性。
不願透露姓名的Z同學：
2參考《軟件需求規格說明書》國標規范文本，撰寫對應項目的軟件需求規格說明書。提供《需求規格說明書》的Git鏈接。
https://gitee.com/ljl36/team_programming/attach_files
3.NABCD 寫作，視頻
請同學們把自己項目的NABCD 都寫出來。
列成詳細的條目，用具體的事實和分析說明。
-
N (Need 需求)
現在的人們大都面臨着各種各樣的壓力，在閑暇之時如果能有一款休閑益智類的小游戲放松心情，獲得樂趣再好不過了。我們的游戲就是為此而誕生。我們的產品可以將碎片化的時間利用起來放松心情，也不用像王者榮耀之類的游戲一樣花費大量的時間，還能鍛煉我們的思維能力。
-
A (Approach 做法)
我們的APP是一款基於安卓平台的程序，我們將采用java 、Kotlin進行軟件開發，服務器采用Java EE進行編寫，數據記錄將使用Oracle數據庫進行存儲。前期做出一個初代版本進行測試，加以修改提升。
-
B (Benefit 好處)
1.玩家可以利用碎片化時間進行游戲體驗加以放松；
2.游戲益智性顯著，能夠在一定程度上鍛煉我們的思維能力。 -
C (Competitors 競爭)
市場上類似的APP小游戲不少，且這類的游戲已經逐漸被王者榮耀等moba游戲所壓過，但是這類游戲的受眾應該不會少，我們的功能會更加豐富，競爭力並不弱。
-
D (Delivery 交付)
交付我們將投放到各大應用平台上，並采用由小及大的推廣方式，即先在團隊周邊的人脈間進行推廣，由第一代的用戶逐步向各自交際圈推廣的模式。
各位用戶：我們的產品24點小游戲是為了解決的痛苦, 他們需要 繁重生活壓力下的減壓，但是現有的方案並沒有很好地解決這些需求，我們有獨特的辦法，我們的游戲時間短，用戶可以把碎片化的時間利用起來放松，它能給用戶帶來好處是放松之余加強思維能力，遠遠超過目前市場上的競爭對手。同時，我們有高效率的由點及面逐步推廣的方法，能很快地讓大部分用戶知道我們的產品，並進一步傳播。
殺手功能：我們的游戲設有排名，以及闖關（beta階段爭取實現）兩點，能夠使游戲更具挑戰性和趣味性。
4.原型設計
原型設計使用的工具：墨刀
4.任務分解WBS
一個團隊項目要在一段時間內完成諸多任務，滿足用戶需求，實現團隊目標，從哪里入手？
WBS（Work Breakdown Structure）即工作分解結構，是根據項目目標把工作分解成許多層次分明的、可交付成果的工作任務，然后用邏輯圖形或樹形結構表示出來。
請給出團隊項目的WBS；
團隊成員估計各自任務所需時間
| 功能 | 預計完成時間（h） | 負責成員 | |
|---|---|---|---|
| 前端界面展示 | 開始界面 | 15 | 張朝瑋 |
| 游戲界面 | 40 | 侯帥軍 | |
| 排行榜界面 | 15 | 張朝瑋 | |
| 后台和算法實現 | 算法模塊 | 45 | 李嘉廉 |
| 數據庫維護 | 55 | 李嘉廉 | |
| 軟件測試和調優 | 80 | 張翔，林正晟 | |
| 模塊和系統設計及擴展 | 30 | 陳偉澤 |
6.編碼規范
(1)代碼規范
- 使用Tab進行代碼縮進。
- 斷行與空白的{}行
“{”與if和for在同一行。 - 操作符的兩邊各留一個空格，逗號和分號也各留一個空格。
- 局部變量和方法按照駝峰風格命名，類名采用Pascal風格。
- 分行：不把多個變量定義在一行上，將變量分為多行定義。
- 注釋要簡單明了，邊寫代碼邊注釋，修改代碼同時修改相應的注釋，以保證注釋與代碼的一致性，含義准確，防止注釋二義性。
(2)函數 - 函數的規模盡量限制在200行以內。
- 一個函數僅完成一個功能。
- 用注釋詳細說明每個參數的作用、取值范圍及參數間的關系。
- 函數的返回值要清楚明了。
- 減少函數本身或函數間的遞歸調用。
7.系統設計
在設計階段，我們要清楚：軟件是怎么解決這些需求的？
一個好的分層式結構，可以使得開發人員的分工更加明確。一旦定義好各層次之間的接口，負責不同邏輯設計的開發人員就可以分散關注，齊頭並進。
如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計
完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖（如果必要）
8.團隊任務分配
| 成員 | 分工 | 完成度 |
|---|---|---|
| 張朝瑋 | 任務分解wbs | 100% |
| 侯帥軍 | 系統設計 | 100% |
| 李嘉廉 | 原型設計，用戶調研：調查問卷 | 100% |
| 林正晟 | 需要規格說明書編寫 | 100% |
| 張翔 | NABCD寫作 | 100% |
| 陳偉澤 | 用戶調研：采訪 | 100% |
9.個人感想
林正晟：
我這次負責的模塊是軟件需求說明書，軟件需求說明書的編制是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解， 使之成為整個開發工作的基礎。說明編寫這份軟件需求說明書的目的，是指出預期的讀者。軟件需求說明書的作用在於便於用戶、開發人員進行理解和交流，反映出用戶問題的結構，可以作為軟件開發工作的基礎和依據，並作為確認測試和驗收的依據。本周的作業中，我負責的任務算是沒那么重的，主要還是隊友比較carry，希望在下次作業中，我能發揮出更大的作用。
張朝瑋：
這次團隊分配的我的任務是制定任務分解wbs，團隊想要成功完成一個項目，一份詳盡的計划表示必須的，只有我們按照計划表上一步一步前進，我們最后才能獲得成功，做任務分解wbs不是簡單的分配任務就行，還需要了解團隊中每個成員的特長和技術水平，除此之外還需要了解整個項目的流程，程序的大體框架。一開始我想當然的認為代碼的做完整個程序不需要太多的時間，直到隊員們想我反饋我才意識到安排的時間不夠充足，經過這周的團隊作業，我會更加謹慎小心的進行了解。希望在下次作業不會出現這樣的失誤，能夠更好的和隊員們進行交流。
侯帥軍：
為了這次博客作業，我們小組進行了一次小的開會，對我們要做的24點游戲這個項目進行了一次更加詳細的分析，明確分配了一下各自的職責，在寫博客作業時候，我負責了系統設計這一塊，這次博客作業量大，通過合理分工，我們還算是比較及時的完成了，也讓我感受到了團隊合作的重要性，團隊合作的確使得任務完成起來效率了很多，希望下次作業可以完成的更好。
張翔：
本周團隊博客我負責NABCD部分的編寫以及部分原型設計，只有自己親自動手寫的時候才明白，軟件開發需要考慮這么多，不親身參與是絕對寫不出來的。但是像N（need），不去采訪去了解用戶的痛點根本就寫不出來；C（Competitors）不去事先了解一下現在的市場上類似的產品的優缺點，自己的產品的優勢和不足也是沒有辦法憑空想象的。原型設計我們使用的工具是墨刀，不得不說真的很方便，不用編寫具體的界面就能做出我們想要的界面。
李嘉廉：
我主要負責程序和數據庫的代碼編寫，我們游戲的算法其實並不算難，只是各個界面功能的實現比較費工夫。這周實驗大家都完成了自己的工作，也了解了自己在隊伍內的定位，我們磨合的已經越來越熟練，完成一個項目，只靠一個人肯定是不行的，只有大家各司其職，相互監督才能成功。這周的博客園作業量相比之前多了很多，我們開始也是手忙腳亂的，但是經過隊內的討論分析，也逐漸找到了自己的道路。希望在之后的項目開發中，我們能夠進一步的提高自身的知識水平，更加熟練的完成各種任務。
陳偉澤：
我負責的是用戶調研部分，一個項目需要知道它為什么人群服務，用戶需要什么才能做好。我們采用了問卷調查和實際采訪兩種方式相結合，這樣能更清楚的明白我們項目真正需要的是什么，而這次的調研結果表明大部分人還是對休閑類小游戲很感興趣的，一個好的項目並不是說它的代碼編寫要有多復雜，完成起來有多困難，而是要滿足用戶的需求，這對我們接下來的開發過程至關重要，我希望的我們的項目能夠完美的收尾，並在這個過程中，我們能夠收獲頗豐。