團隊作業(劉暢,陳傑,楊有存,唐祎琳,王曉哲,邵汝佳)
一、團隊介紹
1、團隊構成:
2、隊名:
Daily target,我們的口號是Target your day!
3、團隊項目描述:
我們計劃寫一個用於老師發布任務,學生接受任務的安卓app。教師安排課程,發布課後作業和測驗、考試;學生完成教師發布的各項任務,並且也可以給自己安排日程。
初步的功能如下:
(1)課程(老師端和學生端):
<1> 教師端:發布教學資料以及作業,測驗,考試安排,發布通知
<2> 學生端:下載教師的教學資料,提交作業和測驗報告,查看老師發布的安排與通知,可以共享優秀的學習資源
(2)日程:
<1> 設定將要完成的任務以及到時提醒功能
<2> 設定長期任務和短期任務,能展示任務的完成情況。
(3)附加功能:
<1> 自定義功能
<2> 留言板功能
4、隊員風采
5、團隊合照:
6、團隊特色
成員技術分配均勻,性格和善容易相處合作,是極佳的合作夥伴。不怕難,不怕苦,每個人都有積極向上學習的心態。所以我們不怕隊員人心離散,不怕完不成項目。我們app的功能並不復雜,大家每個人都有相關的基礎。所以,我們相信,有誌者事竟成。
二、選題
1、項目的概述和意義:
這是一個專為學生設計的時間計劃,接受任務的app
對現在的大學生來說,由於學習的科目多,不同的科目老師會布置相關的作業與任務,積攢起來,學習任務也挺多,有可能會出現忘記具體的學習任務,或者是忘記了要完成的學習任務。也有不少同學在學校或學院社團、組織中擔任相關角色,有許多部門、組織任務要完成,事情往往繁多而瑣碎,如果沒有把任務安排合理到位,很有可能就會忘記去做。針對這種情況,我們希望開發一款能夠記錄學習任務和日程安排的軟件,以提醒同學們按時完成學習任務,合理安排自己的日程規劃,以幫助大家能夠更有條理地處理事務,達到事辦功倍的效果。
我們團隊決定開發一款學習教育型軟件。這款軟件設置了教師端和學生端,老師能夠上傳教學資源,發布教學通知,如作業、考試安排等;學生能夠下載資源和作業,查看老師發布的通知,達到師生互動的目的。此外,同學們對於作業中的疑難問題,也能夠進行留言,尋求老師或同學的幫助。對於同學們的學習和日常生活,同學們可以用這款軟件提前記錄將要完成的任務,並且設定好提醒時間,以監督和提醒同學們按時完成設定好的日程任務,讓同學們學會管理自己的時間,成為學習的主人翁。這款軟件隨時記錄了同學們的日程安排,方便大家日後查看,從而能夠進一步改進自己對任務的安排,以及增強對實踐的管理。
2、NABCD分析項目
1) N (Need 需求)
無論是開會,還是考試,總會發現有些同學遲到或者幹脆忘記了這回事,老師們通過通知群給同學發布任務,有許多弊端。
(1)事有輕重緩急,通知群無法體現到這一點,有的時候消息多了或者時間久了就特別容易忽略一些事情
(2)總有一些同學因為某某原因將通知群收進群助手的,而導致不能及時收到消息的。無論怎麽說還是有人這麽做。
(3)一直以來,是學委不辭幸苦負責記錄任務並發布作業,工作量大,處處小心不能失誤。
(4)有很多同學做事沒有目的性,規劃安排的不合理,不會管理自己。
2) A (Approach 做法)
楊有存和王曉哲具有不錯的html、css基礎,之前參與完成一體化實踐項目,並良好的完成了前端代碼的部分。不過仍需強化js以及JQuery.
邵汝佳曾經參與甲骨文企業javaWeb培訓,獲得過良好的代碼規範以及相關後端技術,還需學習一些相關的安全技術。
陳傑是ACM大佬,算法方面無壓力。
唐祎琳擁有良好的JAVA編程能力,具備完成測試的能力。
劉暢具有良好的前後端基礎,擅長JAVA,有過架構程序經驗。可以給其它小組成員一些學習路線的建議,以及有能力做好對團隊發展的規劃。
如果團隊碰到技術難題,那麽大家一起克服求解。如果對學習路線存疑,可以向各個成員求助。
前端可能碰到的問題,數據可視化難題:
.
解決方法:盡快提前安排相關的學習。
後端可能碰到的難題,用戶量過大,服務器崩潰問題;被黑客攻擊問題。
解決方法1:用戶量過大可考慮在阿裏購買200/年的雲服務器來支持程序運行。
2:通過算法加密數據並且防止sql註入等安全技術防止低級黑客迫害。
程序架構可能碰到的問題,對架構安卓app程序不熟悉。
解決方法:花錢買時間,已經在慕課網購買了相關課程。
3) B (Benefit 好處)
對客戶:加強對時間的管理,按時完成設定的任務,提高生活質量;對我們:掌握開發技術,了解用戶需求,為用戶創造一個良好的平臺
課程任務繁雜,無需翻找qq群,避免遺忘及手動記錄,幫助同學們合理規劃每日學習任務,提前設定好將要完成的任務,起到提醒同學們完成任務的作用,以使同學們有計劃有目標的完成當天的學習任務,使每天的學習更加有條理性。
另外,項目支持資料的上傳和下載功能,老師能夠上傳學習資料,同學們也能夠進行下載,對資料的統一管理,便利同學們的學習。
這款記錄日程的app,不僅僅限於學習,也可以安排和記錄日常生活。可以用不同顏色來分輕重緩急。
4) C (Competitors 競爭)
經過搜索,我們軟件的功能和市場中存在的app功能是有重疊的,比如日歷,還比如日程。但我們擁有特色功能,就是將學生和老師聯系在一起,替代qq或者微信通知群,並以此為優勢點發展其它有利於學生管理時間的功能。
市場上,能具備代替通知群的功能的軟件還沒有出現,然而它的的確確是學生和老師的一個需求,雖然不迫切,但是會明顯提高老師或者學生的管理效率。
5) D (Delivery 交付)
如何將軟件交付給需求用戶呢?對於我們這款軟件來說,太簡單了。因為我們是面向老師和學生的。如果我們做成了,就可以直接找導員商量一下這款app,讓導員試用一下,如果讓她感覺到明顯的好處,這事兒就成了。
3、團隊所具技術
前端 : 兩名界面美化,前端數據和後端數據交匯,需要良好的js和css基礎,需要盡快完成demo。組員:楊有存,王曉哲負責。
後端 : 主要負責數據庫和代碼的鏈接 (數據庫表的設計會比較花精力,sql查詢不是簡單的select,可能需要平衡樹等可以提升查詢效率的算法)防止sql註入,對數據庫數據加密,需要掌握jdbc,sql,jsp。組員:邵汝佳負責。
核心算法 : 負責設計工程優先級算法,幫助後端設計查詢算法,加密算法。組員:陳傑負責。
維護測試 : 負責設計測試樣例,找出bug,並且做好良好的性能分析報告,壓力測試等等。 組員:唐祎琳負責。
程序架構 : 負責完成app的設計文檔,並給予其他隊友學習路線及建議,規定規範,完成app的基本框架,同時對團隊進度負責。組長:劉暢負責。
楊有存和王曉哲具有不錯的html、css基礎,之前參與完成一體化實踐項目,並良好的完成了前端代碼的部分。不過仍需強化js以及JQuery,技術熟悉度為6.
邵汝佳曾經參與甲骨文企業javaWeb培訓,獲得過良好的代碼規範以及相關後端技術,還需學習一些相關的安全技術,技術熟悉度為7.
陳傑是ACM大佬,算法方面無壓力,技術熟悉度為9.
唐祎琳擁有良好的JAVA編程能力,具備完成測試的能力,技術熟悉度為7.
劉暢具有良好的前後端基礎,擅長JAVA,有過架構程序經驗。可以給其它小組成員一些學習路線的建議,以及有能力做好對團隊發展的規劃,技術熟悉度為8.
三、團隊貢獻分配方式
評分標準:
得分= 工作量*I +工作難度*J + 工作完成程度*K + 工作積極性+小組成員自評與互評;
其中權值I ,J ,K根據不同的項目可以有相應的浮動,但是比重最大的應該是工作難度。
個人對於團隊項目有著類似的屬性,大致可以概括為工作量,工作難度(我們也可以稱為工作關鍵性),工作完成程度和工作積極性這四個方面。
工作量:百度百科上給出了這樣的一個解釋:一個部門或其他集團的工人在一段時間內完成的全部工作。對於我們的軟件工程項目來說,包括主程序的代碼編寫,模塊功能實現量,程序測試人員對於軟件後期維護,項目的風險分析和軟件的功能分析等等不同的工作,這些工作分配到每個成員的實際量就是我們這裏所說的工作量。所以工作量更多的取決的個人的專業領域,這一點我們在項目開發之前就應該根據個人的專業素養和能力分配好。
工作難度:對於團隊項目,僅僅用工作量來衡量個人的工作實際投入肯定是不夠的。比如說在項目開發過程中,組員們每天都在一起工作,所以工作的時間大體上是相同的,但是我們不能說一個主程序員用了一天的時間完成了一個難度很大的模塊設計的工作投入和一個輔助人員用了一天的時間寫了一份簡單不重要的相關報告的工作投入是一樣的,這也就是我們所說的工作關鍵性。我們應該對於項目開發中負責難度較大的模塊的組員更多的分數獎勵,這樣才是公平的,也間接地體現了知識的價值。
工作完成程度:這也可以說成工作實現效果。在我們最初分配不同的工作量後,對於每個人的完成程度我們應該有實時的跟蹤記錄,這樣也更能督促組員。即使你有能力,分配到了最重要的工作,但是你因為某種原因並不能很好的完成任務,甚至於在最後期限也沒有完成任務,這肯定是對個人得分有著很大的影響的,如果你選擇了較為簡單的工作,但是你在這份工作中完成地相當出色或富有創造性,這就是一個加分點,這樣一定程度上也能促進一個出色的軟件的形成。
工作積極性:我們現在畢竟是一個學生組成的團隊項目,不能要求的那麽苛刻和嚴肅,要鼓勵同學們的積極性和自主學習的興趣,這個工作積極性的加分就能很好的提高目前能力不能達到要求的同學也能積極的投入到項目開發小組活動中來。也就是工作積極,認真學習的組員我們在這方面給予小小的加分獎勵,這樣才更人性化。當然,這個加分不能給多了。
這裏附上我們設計的用於評判貢獻的幾張表。
表一 項目評價標準
項目完成 情況 |
評分細則 |
項目最終得分 |
優秀(9-10) |
實現了所有的功能,並且所有的功能都能夠正常使用,用戶界面美觀並讓人感覺舒適,並且用戶使用率達到100以上 |
|
良好(7-8) |
實現了主要的功能,並且實現的功能能夠正常使用,用戶界面普通,不影響視覺效果,並且用戶使用率達80以上 |
|
合格(6) |
實現了少部分功能,並且實現的功能能夠正常使用,用戶界面普通,並且用戶使用率達50以上 |
|
不合格(0-5) |
沒有實現功能,或者已實現的功能不能正常使用,用戶界面不合格,並且用戶使用率不超過50 |
表二 成員評價標準
評價標準表
評分條目 |
評分細則 |
||||
9-10 |
7-8 |
5-6 |
3-4 |
0-2 |
|
工作量 |
完成分配的任務 |
完成大部分分配的任務 |
完成一半分配的任務 |
完成少部分的分配任務 |
完成極少部分或者沒有完成分配的任務 |
完成效果 |
完成的功能能夠正常運行 |
完成的功能大部分能正常運行 |
完成的功能部分能正常運行 |
完成的功能少部分能正常運行 |
完成的功能基本不能正常運行 |
出勤率 |
團隊會議不缺席,請假次數不超過1次 |
團隊會議基本不缺席,請假次數2-3次 |
團隊會議缺席較多,請假次數4-5次 |
團隊會議經常缺席 ,請假次數5次以上 |
未出席團隊會議或僅出席1-2次 |
團隊貢獻率 |
積極參與團隊討論,為團隊項目的進行出謀劃策,幫助團隊成員完成任務 |
比較積極參與團隊討論,能提出好的建議 |
參與團隊討論,能提出比較好的建議 |
參與團隊討論,但不能提出較好的建議 |
很少或基本不參與團隊討論 |
評分表
成員 |
工作量 |
完成效果 |
出勤率 |
團隊貢獻率 |
得分 |
劉暢(組長) |
|
|
|
|
|
陳傑 |
|
|
|
|
|
王曉哲 |
|
|
|
|
|
楊有存 |
|
|
|
|
|
唐祎琳 |
|
|
|
|
|
邵汝佳 |
|
|
|
|
團隊作業(劉暢,陳傑,楊有存,唐祎琳,王曉哲,邵汝佳)