一、团队介绍
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次 |
团队贡献率 |
积极参与团队讨论,为团队项目的进行出谋划策,帮助团队成员完成任务 |
比较积极参与团队讨论,能提出好的建议 |
参与团队讨论,能提出比较好的建议 |
参与团队讨论,但不能提出较好的建议 |
很少或基本不参与团队讨论 |
评分表
成员 |
工作量 |
完成效果 |
出勤率 |
团队贡献率 |
得分 |
刘畅(组长) |
|||||
陈杰 |
|||||
王晓哲 |
|||||
杨有存 |
|||||
唐祎琳 |
|||||
邵汝佳 |
原文地址:https://www.cnblogs.com/anheqiao/p/8724520.html