成員 | 分工 |
---|---|
鮑子涵 | 分配職責,整合代碼 |
吳宜航 | UI設計與實現 |
鍾博 | UI設計與實現(Main Coder) |
黃海東 | 數據整理 |
王鎮隆 | 前端api接口分析和使用(Main Coder) |
高鵬 | api接口分析和整理 |
駱友鵬 | 數據整理 |
陳志明 | api接口分析和整理 |
劉俊傑 | 數據整理 |
羅繼鴻 | 數據整理 |
林得翔 | 特殊狀況,請假未參與 |
java version "1.8.0_221"
Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)前端
準備工做:提早先收集好幾張編程時可能會用到的UI的背景圖還有一些要插入的小部件。java
具體編程完成的工做:在主題明確了之後選取了以原諒色爲主題的背景圖,可是因爲背景之間的風格色調有些誤差,因此用了pscc把原來的背景圖用camera row把背景的色調給調柔和了些,原本現場想p些小部件到背景裏去,但奈什麼時候間不夠就先湊合着用了,背景圖的插入用的是Jpanel進行背景圖插入。git
開始界面github
困難:最大的困難就是時間不夠,其次就是由於時間不足,沒有太多的時間去進行P圖,致使有些素材的展現效果不是很好,還有在主要功能的頁面設計完之後和其餘人設計的接口對接的時候發現本身的有些設計和原來預想的展現方式有點誤差,影響了一部分頁面交互的時候的美觀性。算法
解決辦法:提早去進行P圖,找素材會節省大量時間,還有就是工做開始前和組員事先商量好數據的接受還有發送的形式編程
成員 | 貢獻佔比 |
---|---|
鮑子涵 | 13% |
吳宜航 | 12% |
鍾博 | 13% |
黃海東 | 6% |
王鎮隆 | 13% |
高鵬 | 12% |
駱友鵬 | 6% |
陳志明 | 8% |
劉俊傑 | 6% |
羅繼鴻 | 6% |
林得翔 | 5% |
PSP2.1 | Personal Software Process Stages | 預估耗時(分鐘) | 實際耗時(分鐘) |
---|---|---|---|
Planning | 計劃 | 180 | 180 |
Estimate | 估計這個任務須要多少時間 | 180 | 180 |
Development | 開發 | 120 | 120 |
Analysis | 需求分析(包括學習新技術) | 5 | 6 |
Design Spec | 生成設計文檔 | 20 | 15 |
Design Review | 設計複審 | 3 | 5 |
Coding Standard | 代碼規範(爲目前的開發制定合適的規範) | 2 | 3 |
Design | 具體設計 | 8 | 10 |
Coding | 具體編碼 | 110 | 113 |
Code Review | 代碼複審 | 4 | 6 |
Test | 測試(自我測試,修改代碼,提交修改) | 9 | 10 |
Reporting | 報告 | 11 | 14 |
Test Report | 測試報告 | 6 | 8 |
Size Measurement | 計算工做量 | 2 | 4 |
Postmortem & Process Improvement Plan | 過後總結,並提出過程改進計劃 | 11 | 15 |
合計 | 665 | 689 |
週數編號 | 新增代碼 | 累計代碼 | 本週學習耗時(小時) | 累計學習耗時(小時) | 學習內容 |
---|---|---|---|---|---|
1 | 500 | 500 | 3 | 3 | 團隊代碼整合、算法框架優化 |
根據你所能獲取到的數據,分析出你認爲最有潛力的商圈。(此題沒有明確的標準,同窗們能夠發散思惟,最終結果言之有理便可,例如能夠綜合考慮:交通、居民密度、人員素質、地理位置等等)(10%)api
根據多方平臺獲取的數據(如星級、評分人數、交通密度數據、人口密度數據、衛星監控數據等),加以不可公開(保密等級:Euclid )的後臺計算算法後,咱們認爲倉山萬達雖然目前並非最熱門的商圈,確實將來5年內最有發展潛力的商圈。框架
高級數據可視化。(5%)學習
數據測試
其餘與該題有關且有趣的分析。(10%)
經過分析發現,很多商鋪廣泛存在「刷分」現象,甚至有商鋪刻意「刷低分」來逆向宣傳,且必定程度上達成了正向的宣傳效果(其中一家依靠「刷低分」的商鋪在以後真的收到了很多差評,大多數差評的理由竟然是吃客認爲該商鋪的商品沒有他們想象中的難吃)。