這個作業屬於哪個課程
2019秋福大軟體工程實踐z班
這個作業要求在**
團隊作業第五次—專案衝刺
團隊名稱
t-max
這個作業的目標
1.衝刺的時間計畫安排2.答辯問題的回答3.針對前幾次作業的不足的地方進行思考和總結
作業正文
t-max-凡事預則立
參考文獻
鄒欣.構建之法[m].3版:人民郵電出版社,2014.
進行了部分修改，將準備的時間安排劃去了，將衝刺七天的任務劃分了出來。
日期時間安排
第一天熟悉框架、ui庫，編寫大體架構，資料庫建庫建表
第二天完成註冊，登入頁面，個人資訊修改等功能
第三天完成使用者的基本操作
第四天完成商家，管理員的基本操作
第五天完成主介面和商家介面功能
第六天第七天
**統一整合執行，ui介面美化，程式bug的查詢與測試，總結歸納本階段的不足與可改進的地方
針對週六的答辯，其他小組對我們小組提出的問題中，主要為四個問題：
1、q:資料庫安全性問題，安全設計的實現
a:1.軟體的安全問題的話問得實在太過於沒必要，現在的軟體框架都很成熟，基本不會出現安全問題，其次安全問題往往和利益有關係，而我們的產品實在沒有什麼誘人的資料擔心洩露。
2.資料庫的安全的話分為一下幾個部分實現：
（1）安全控制
（2）登入名
（3）資料庫使用者
（4）許可權管理
（5）角色
對有意的非法活動可採用加密存、取資料的方法控制；對有意的非法操作可使用使用者身份驗證、限制操作權來控制；對無意的損壞可採用提高系統的可靠性和資料備份等方法來控制。
在大型dbms中，使用者訪問資料庫資料要經過三個安全認證過程：確認使用者是否是資料庫伺服器的合法使用者（具有登入名）；第二個過程，確認使用者是否是要訪問的資料庫的合法使用者（是資料庫使用者）；第三過程，確認使用者是否具有合適的操作許可權（許可權認證）
2、q：設計類圖和資料庫表不匹配問題
a：經過討論和修改，我們進行了如下修改：
（1）把管理員和申請成為管理員兩張表進行了合併
（2）刪除了動態類和推薦類
（3）增加了菜品資訊類和舉報資訊類
3、q:關於商家刷讚現象的處理：
a:我相信同學們對於一家店的菜品好壞、服務態度有自己的評價，如果它的服務質量真的很差，那麼是不會有同學願意給好評的。 而且，我們會不定期的審核處理資料。
4、q:我們小組團隊協作的問題：
a：在這兩次團隊任務中，暴露出了我們團隊中存在的一些問題，團隊協作性不夠，團隊交流不夠，隊員之間交流的不足，使得我們的作業出現了紕漏，在接下來的衝刺中，前端組和後端組要加強交流，多討論，才能讓任務完成的更好。
在這兩次團隊任務中，暴露出了我們團隊中存在的一些問題，團隊協作性不夠，團隊交流不夠，隊員之間交流的不足，還有就是部分隊員的積極性不足，導致任務不能夠及時的完成，經常需要加班加點的趕工，這樣工作的質量也不能得到有效的保障。接下來需要加強團隊的協作，資訊的通知也需要到位，還有效率也需要提高。
分工計畫改進：之前的任務中，團隊的分工有點限制的太死了，就是細分的各小組只是完成自己的部分，各小組之間交流不足，還有就是各小組截止時間沒能夠定好，接下來要進行更細緻的定製。
開會效率改進：要提高開會的效率，簡明扼要，之前幾次會議都有點拖沓，無用的東西講的有點多，需進行改進。
問題討論改進：各小組之間的問題需及時討論和反饋，避免浪費時間。
「福大吃點啥」**規範
團隊專案編碼
凡事預則立
昨天想到了乙個問題 凡事預則立。任何事情都需要準備好，甚至考慮到當時的場景，做乙個導演而不是觀眾。每次的tm會議，我去之前總是做做一些計畫，想象當時的場景，以便讓自己保持活躍的狀態。我的做法是只列綱，不打具體的草稿.胸中有數，而後隨意而至。這實在是在不知不覺中養成的乙個習慣,生活中平常的事情也是這樣...
凡事預則立
吸取之前alpha衝刺的經驗教訓，也為了這次的beta衝刺可以更好更順利地進行，更是為了迎接我們的新成員瑋詩。我們開了一次組內會議，進行beta衝刺的規劃。上一張我們的合照 具體會議議程如下 重新組隊後，我們進行了組內評選組長的投票。投票結果如下 成員意向組長 周龍榮李家鵬 李家鵬周龍榮 曾瑋詩周龍...
凡事預則立
1 討論組長是否重選的議題和結論。組長不重選，因為沒有人想當這個組長，所以還是由我繼續。2 下一階段需要改進完善的功能。alpha版本尚未完成的功能很多，預計先將基本功能完成 發布資訊和修改 3 下一階段新增的功能。暫無新增功能，先把聊天功能完成 4 需要改進的團隊分工 針對之前的不足，需要加強和改...