團隊做業第一週

團隊做業第一週

1、團隊展現

團隊成員

趙乾宸（20172316）
蔣子行（20172317）
李聞洲（20172320）
馬瑞蕃（20172327）

隊名

RSP（Rock Paper Scissors)

擬做的團隊項目描述：

基於Android開發的一款三消小遊戲

隊員風采：

• 趙乾宸：

  風格：默默無聞
  擅長技術：各種遊戲、編程，
  編程興趣：濃
  擔任職務：編碼人員，產品發佈人員。
  宣言：小事成就大事，細節成就完美

• 蔣子行：

  風格：獨特（詞窮，沒法描述）
  擅長技術：各種遊戲、編程，英語
  編程興趣：濃
  擔任職務：編碼人員，需求分析員
  宣言：受教育是將來改變社會，而不是爲了社會而改變本身，那會偏離教育的初衷

• 李聞洲：

  風格：瀟灑一身黑，持劍行天涯
  擅長技術：愛遊戲，愛生活，愛跆拳
  編程興趣：濃
  擔任職務：編碼人員，測試人員
  宣言：我是誰？我在哪？我在幹什麼？

• 馬瑞蕃：

  風格：內向，不善表達，能水就水
  擅長技術：繪畫
  編程興趣：濃
  擔任職務：編碼人員，項目經理，美工
  宣言：每一個平凡生活裏都有它的不平凡。

團隊合照

團隊特點描述

團隊特色：性格不一樣，但都很開朗，因此在團隊的合做中，咱們會有更好的交流和默契。
團隊優點：咱們自認爲很牛逼，咱們是王者！

2、團隊選題

1. 項目概述

1.1 產品描述
本產品但願經過結合RPG與經典的三消遊戲玩法，打造一款休閒的小遊戲，做爲學生在學習工做之餘放鬆本身的一種方式，達到勞逸結合的目的。

1.2 產品功能

序號	基礎功能	功能介紹
1	背景音樂	在玩遊戲過程當中有音樂伴隨，與大多數遊戲的BGM相相似
2	音量設定	控制遊戲BGM的音量
3	菜單界面	選擇開始遊戲（選擇難度-待後續開發），並有關於，音量，退出遊戲
4	遊戲界面	設有戰鬥界面（血條）和消消樂矩陣，暫停，設置，退出

1.3 流程圖

1.4 用戶特色
本軟件的用戶限4歲以上羣體使用，無其餘特殊要求，各種人羣均可以成爲該app的用戶，特別適合學生黨和上班族打發空餘時間

1.5 通常約束
進行本軟件開發工做的約束條件以下：
（1）開發週期短：距離本學期結課時間以經很近了，須要開發者合理規劃時間，作到多項目任務併發。
（2）所採用的方法與技術有限：項目團隊成員的技術水平不夠成熟，須要在開發中併發學習多種技術和能力。
（3）團隊默契度不高：咱們幾個是第一次組隊編程，因此各方面配合有些生疏。

1.6 假設與依據
本項目是否可以成功實施，主要取決於如下的條件：
（1）團隊成員的積極合做配合，爲了項目的開發和實施，對我的時間進行合理規劃同時爲團隊作出合理犧牲，配合隊友完成任務。
（2）學院教師提供完整詳細的功能和性能需求資料，以便於團隊對其進行分析，從而造成完善的軟件需求。
（3）團隊掌握先進的可以適用於該項目的技術，這是系統的性能是否優化和項目可否成功的保證。

2.團隊協做方式

2.1 首先咱們集體商討咱們所要開發的這款APP進行分析，站在用戶的角度對咱們的APP的功能以及界面進行合理的思考與討論。

2.2 其次，咱們會由專人撰寫《項目溝通說明書》，經過具體到時間的安排，時app實現進度得以更好規劃。

2.3 在碼雲創建了一個項目，經過四我的能夠從不一樣端傳送代碼，並加入備註。

2.4 在每週，咱們會選出固定的時間開一到兩次會議，在會議上，討論遇到的問題。

2.5 在課下，各負責部分負責人員也可本身碰頭，解決銜接問題。

2.6 每週都會有寫一篇博客，負責記錄本周的進展和感悟

3.程序設計經驗傳授：

編寫程序是一項系統而繁瑣的工做，它不只須要程序設計人員具備必定的功底，更須要有良好的編程習慣和風格。良好的編程習慣和風格不只可使程序代碼更易於讀懂和修改，更重要的是，它可使程序的結構更加合理，有助於提升程序的執行效率。下面是我在網絡上查到的其餘人在程序設計中總結的一些經驗，供你們參考。

3.1 設計順序
在咱們剛開始學習程序設計的時候，要編寫一個程序，老是先進行一番構思，而後就一邊寫代碼一邊調試。這種方法通常只適用於很是小的程序，根據軟件工程的特色，若是對全部程序都還按這種方法進行設計，是不合理的。
其實，設計程序就像咱們蓋高樓大廈，首先要設計圖紙，而後動工。因此，對於我的編寫程序來講，應遵循如下步驟：

　 （1）問題分析：對咱們要使用程序設計手段去解決的問題進行系統地分析，瞭解程序是作什麼的，要達到一種什麼樣的效果等。

　 （2）結構設計：也就是對程序的總體框架進行設計，設計出咱們須要使用的模塊等等，並畫出流程圖。

　 （3）用戶界面設計：在此，咱們要設計出用於與用戶交互的輸入輸出界面。

　 （4）代碼設計：在這個步驟中，咱們要進行代碼的編寫。

　 （5）調試：對程序中正在發生或可能發生的各類錯誤進行處理。

　 （6）維護：通俗地說，維護就是對程序進行升級，對原有錯誤進行修改。

　　 對於以上幾個步驟，我想大多數人會認爲代碼設計最爲重要，但若是程序的結構還沒有清楚，咱們在編寫代碼的時候就會發生混亂，一個程序性能的好壞，主要仍是取決於它的結構是否合理。所以，在程序設計中，咱們要儘量注意這一點，這樣才能使咱們的程序更加完善。

3.2 設計技巧
代碼若是寫得很亂，程序便不易被閱讀與修改，因此，在編寫代碼時要注意如下幾點：

（1）註釋：寫註釋雖然要佔用必定的時間，但在閱讀和修改代碼時卻會節省不少的時間。因此，建議你們在定義一個函數時，在函數的第一行寫出函數的做用，再用一行解釋函數的參數，並在每一個變量的定義語句後註釋出其做用。

　 （2）變量和函數的命名：每一個程序都會使用不少的變量和函數，若是隨意命名變量與函數，每次使用時還得在變量或函數的定義語句處查出它的數據類型及名稱，並且隨意命名還會形成變量與函數重複定義。

　　 建議你們使用匈牙利命名法，方法是：每一個變量或函數的開頭都以其數據類型的縮寫命名，而後再加上表明這個變量或函數的做用的英文單詞簡寫共同組成變量或函數的名稱。

　 （3）控件命名：若是在Windows下編程，你有可能會大量地使用控件，若是不對控件名嚴加管理，會形成很大程度的混亂，所以，建議在給控件命名時，以控件類型縮寫再加上表明這個控件做用的英文單詞的簡寫共同組成此控件的名稱。例如：你要命名一個按鈕控件，做用是進行刪除操做，那麼控件名能夠命名爲cmdDel。

　　 並非每一個人都能成爲頂級程序員，但咱們都在程序員之路上不斷進步，追求更完美、更專業化的程序。不妨好好改造一下你的程序，你會從中感覺到不少好處。

團隊成員項目佔比

姓名	學號	項目貢獻佔比
馬瑞蕃	20172327	30%
李聞洲	20172320	30%
趙乾宸	20172316	30%
蔣子行	20172317	10%

《消消樂》需求規格說明書

連接：需求規格說明書