前言
- 组长博客:hjj
- 作业博客:第十次作业 - 项目测评(团队)
第一部分 调研,评测
评测
- 小组个人第一次上手体验
-
后敬甲
福大助手定位是,为Fzuer量身定做的校园学习生活助手。
在初次上手之后,可以发现其功能基本覆盖了福大学习生活的各个方面,也符合软件本身的定位。
发现一点不足在于,软件没有固定的首页,各个功能模块同一级并行,在各模块均可独立退出app,页面层次分布不符合多数用户已有的使用习惯
-
刘浩
上手体验:初次运行后第一感觉是app响应很快且功能很多 目前使用到的就其中下载历年卷和查看课程表这两个功能 这两个功能都很齐全 ui设计整体感觉比较和谐 在左边放置功能切换界面让人眼前一亮 总体来说还是一个不错的大学应用工具
-
卢泽明
上手体验:Android端的福大助手界面好看,首页为课程表也是满足了广大学生的需求。运行流畅,功能这几年一直在增加,可以说已经集齐了大部分必备功能。
不足之处:功能部件全部在右侧展开部分,确实有点不够明显。我相对喜欢把各个页面放在底部栏的按钮。其次没有个人中心,可以让用户设置自己的个人信息,比如修改头像,设置基本信息等。
还有就是希望加上一些校园小知识,比如小白的发车时间地点等
-
黄靖茹
上手体验:界面总体来说比较简洁,历年卷和一键评分功能是使用福大助手的主要原因。功能相教福大教务处更齐全。交互方面做的也还可以,但是针对安卓系统,每次按返回键没有返回上一层对于安卓用户来说不是很习惯。小建议:历年卷能按自己专业分就更好了,有的时候不想打字也不必翻很久的目录。
-
葛亮
上手体验:运行速度快功能多,一个app集合了易班和教务处的功能,更有方便同学选课和抢实验的功能。
课程表导入到日历也很方便。
但查考场的界面感觉有美中不足,如果有多门考试连在一起,极有可能把日期和科目看混。
另外没有找到可以修改登录信息和找回密码的界面和功能,在访问登录失败的时候让用户很绝望。
-
蔡文斌
上手体验:Android端的福大助手界面简洁大方,用户容易上手,运行流畅,功能齐全,几乎集齐了其他校园app的功能,是一款不错的校园软件。
不足之处:没有个人中心,可以让用户设置自己的个人信息,比如修改头像,设置基本信息等。可以在抽屉内加上校历的这个功能,方便用户查询节假日等信息。如果可以的话,对于界面的设计可以进一步的改善,有些界面太过于简单,虽然突出了功能,但是对于部分用户,使用体检就不是那么好
-
黄泽
上手体验:整体布局简洁明了,无广告骚扰,交互动作自然柔和,功能相较于福大教务处更加完善齐全,课程导入日历功能比较新颖,美中不足的是单期绩点无法查看,部分交互没有给出明确提示,比如点击左侧栏自己的名字会弹出个人信息一览表,但是不容易被用户发现。总的来说是一个优秀的校园app
-
朱跃安
上手体验:进入界面的首页是课表界面非常方便日常查课表。抽屉界面包含功能丰富,能够为福大学生提供很好的服务,而且还能在设置界面隐藏自己平时用不到的功能。
不足之处:校招功能处没有给出近期校招活动的列表,只能自己一个一个的去查找。如果在不知道校招活动具体情况下,就很难通过搜索框查找,只能自己手动滑动日期条,一个一个的查看每个日期下的校招活动,应该添加一个日历表。有些界面过于简陋不美观,如嘉锡讲堂界面,这很有可能影响到用户使用该功能。
-
张杰
上手体验:Android端整体布局遵循Material Design,以蓝色为默认色彩并可以更改喜欢的颜色,简洁大方。抽屉内功能丰富,整合福大教务通、福大易班、福大历年卷,基本满足用户需求,同时可将课程同步到日历中,方便使用。
不足之处:
内的用户信息占位较大但无功能,建议将个人信息以及账号注销等功能放置其中。
右上角的更多功能用于切换学期较为奇怪。
fab似乎是为了fab而fab,功能可以整合至右上角更多按钮。
-
- 思维导图
-
Bug及原因猜想
点击此查看在线文档
- 假设团队需要开发这套系统,需要注意的方面
- 广泛听取用户的意见,做出适当的改进和调整。
- 界面交互更加良好
- 主题功能模块要有突出特色,不能只是大杂烩。
- 我会加强宣传力度,寻求合作。正如现在的易班一样,不断地在高校内合作推广,知名度就高了起来。很多人是没听过福大助手,那我相信在大力宣传之下,只要用户接触了福大助手,就会发现是值得使用的
采访:
Android手机:
1.背景:数计学院2016级计算机专业某不愿透露名字的蔡同学,据他描述为第一次使用福大助手
2.需求:
需要时常查看课程表,且期末考将近,急需历年卷的帮助,经过短暂使用,蔡同学表示福大助手基本满足他的需求
除了现有的功能外,蔡同学觉得要是App能整合一个及时通讯功能,或者是线上交流功能,让大家可以交流学业或者其他信息的话就更好了
IOS手机:
1.背景:福建师范大学2016级软件工程某不愿透露名字的陈同学,据他描述师大还没有这种学业助手类型的应用
2.使用体验:
初次上手,陈同学表示该程序能在Apple store上线足以说明该程序还是相当厉害的,因为审核要求比较严格,(相对于安卓应用)还表示他很喜欢这种不显示主页,将所有功能简化的设计
而且功能也齐全,采访者问其有什么想法,他表示惊讶于学校愿意将学校数据接口给学生使用,且感叹福大助手团队完成了一个完成度比较高的作品
第二部分 分析
- 估计这个项目做到这个程度大约需要多少时间(团队人数6人左右,计算机大学毕业生,并有专业UI 支持)
计算机专业毕业具有良好的专业素养,在专业UI的额外支持下,三个月比较足够。
- 分析这个软件目前的优劣(和类似软件相比),并推理出开发团队在软件工程方面可以提高的一个重要部分(具体建议)。
优势:
- 作为课程表软件,它比“超级课程表”来的清新,没有烦人的广告,用户体验较好
- 作为学习资料软件,比百度文库,豆丁文档等针对性,福大学习可以精确找到符合条件的资料,与期末考啦相当。
- 作为校园交流软件,比福大易班来的流畅,比福大教务通功能来的多,界面更加整洁,服务器较少瘫痪。
- 尚有很多功能有待完善,比如添加课程方面,经常出现bug,导致用户卸载重装。
- 福大助手作为校园助手,限制了它的上限只能是在福大。相比易班,其推广度大大不如。
- 根据理解和体验,画出整个软件所有功能逻辑框图,根据重要度标识出各模块的重要度、完成度、出发点及效果;
- 成绩查询
- 嘉锡讲坛 -教务通知
- 考场查询
- 课程表
- 空教室查询
- 历年卷
-
图书馆
-校招日历
- 针对不同的维度评分,对用户体验方面、UI界面美观度、核心功能,分别打分。
- 用户体验 9/10
- UI 8.5/10
- 核心功能 9.5/10
第三部分 建议和规划
- 如果你是项目经理,如何提高从而在竞争中胜出?
- 目前市场上有什么样的产品了?
- 福大易班的校本化功能,期末考啦为学生提供学习资料的查询,超级课程表提供课表查询。
- 你要设计什么样的功能?
- 可以设计一个校内百事通的功能。汇总各种常见问题,如:福大哪里有干洗店,哪里可以充电等。
- 可以将学生卡充值整合进来。真正做到上大学只需要一个软件
- 为何要做这个功能,而不是其他功能?
- 福大助手是专门为福大学生服务而设计的,综合了学生对日常生活和学习方面所需的服务,评测出学生需要哪些不需要哪些功能,例如福大易班提供的精品课程功能,对于大部分学生来说使用的频率低,对于福大助手这种轻便的软件是不要这种功能的。又如课表查询,福大助手提供的仅仅是对于课表的查询、更新等日常学生经常用到且必须的功能,而超级课程表添加除课表查询外,还有小纸条功能提供简单的聊天功能,这对学生来说是极少使用的。总之,福大助手提供的功能是学生经常使用到且有帮助的的,删除一切不必要的功能。
- 为什么用户会用你的产品/功能?
- 首先因为功能齐全,整合大学生各种必备的如课程表,空教室查询等。非常的简洁方便。
- 其次界面清晰,运行流畅,没有广告等扰人内容。
- 你的创新在哪里?可以用 NABCD 分析。
NEED:福大助手仅提供对学生日常生活和学习有需求的功能,其他不必要的功能都没有添加,极大的方便学生用户的使用。
APPROCH:福大助手将一个个较大的需求,封装成一个个功能模块,而且用户还可以通过设置隐藏一些较少用到的功能模块,这样更简化操作。
BENEFIT:各个功能模块提供不同的服务,且全部的功能模块涵盖了几乎所有的用户所需的功能,用户只需下载一个软件就能享受到好几个软件提供的服务,而且操作更加轻便。由于删除了不必要的功能,软件所占用的空间也更加的小。
COMPETITORS:一个集成其他几个软件重要功能的软件,操作又简便,是非常吸引用户。
DELIVERY:采用抽屉界面,将所有的功能模块放置在抽屉界面中,由于功能数只有十来个,用户可以很容易的找到自己所需的功能,并且还能通过设置将近期用不到的功能隐藏起来,就能更大方便找到所需的功能。各个功能的界面也是尽量做到简洁明了,提供最佳视觉效果。
- 如果你来领导这个团队,会有什么不一样?
- 首先加强团队凝聚力,使团队工作更高效,和谐
- 其次对代码的规范和质量严格把关。
- 保密,信息安全,用户信息的保密才是重中之重。
- 如果你的团队有5个人, 4个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?
- 大致分为美工一人,前端开发一人,后端开发一人,测试一人,项目经理一人。
- 项目经理在四个月期间中一直负责统筹团队开发,调研市场需求,制定合理的开发计划,负责协调团队队员合作 。
- 前15天,负责美工的人员需要在尽量短的时间内设计出初稿方便其他人员今早开始设计。前后端人员可以简略设计所需要接口,测试人员准备好测试环境和测试数据等。
- 中期的两个半月,前后端人员负责好开发出第一版,并在美工和测试人员的要求下不断修改跟进版本。
- 后期一个月,测试人员不断的测试查找bug,前后端人员负责修改bug。美工人员可以修改美化界面,前后端人员负责跟进。项目经理准备好产品上线的工作。
- 描述你的团队在16 周期间每周都要做什么,才能在第16周如期发布软件,大小里程碑绩点设定。
周数 | 任务 | 里程碑 |
---|---|---|
1-2 | 需求分析,初步确定产品功能,市场调研,完成需求分析报告书.明确分工 | 需求分析完成 |
3-4 | 深化需求分析,制定代码规范,构建架构,进行原型设计,统一开发环境 | 原型设计完成 |
5-8 | 代码实现,前端和后端并行。 | |
9-11 | 前后端接口对接,对各个功能模块进行测试 | Alpha版本发布 |
12-13 | 接受意见反馈,修复bug,完善功能。 | Beta版本发布 |
14 | 进行严格的性能测试、压力测试、集成测试等 | |
15 | 编写用户手册。 | 用户手册完成 |
16 | 项目部署,发布最终版本的产品。 | 发布正式版本 |
- 项目发布后,有没有考虑过项目该怎么部署才能满足需求。依据附录图(某校教务处系统的部署)作为参考,分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置) 。
- 后端服务器:2核4G
- 带宽:人均1M
- 关系型数据库:SQL Server 数量:3(读写分离2、备份1)
- 缓存数据库:Redis 数量:1(主备)
第四部分 增量开发设计
- 主界面设置功能
- 在设置界面加入主界面设置功能,在全局做修改
- 作为设置界面下的子功能接入
- 校园卡充值功能
- 设计相应界面,并接入校园卡充值接口
- 作为平行于各一级功能的功能模块接入
- 原型
- 校园精确导航
- 调用高德地图或者百度地图,并在其基础上细化地图
- 校历浏览
- 设计相应按钮,接入校历网页
第五部分 答辩总结
- 评估团队中每个人对本次作业的贡献比例
成员 | 分工 | 贡献比 |
---|---|---|
测评报告整理 | 11% | |
文斌 | 逻辑框图制作 | 12% |
思维导图制作 | ||
静茹 | Bug测评 | |
敬甲 | ppt制作+演讲+博客整理 | 13% |
泽明 | 软件规划 | 10% |
采访 | 9% | |
增量原型设计 | ||
软件建议 |
- 答辩总结
- 求出本组的现场答辩得分:去除最高总分,最低总分,求平均分(保留2位小数)
组号 得分 1 80 2 72 3 76 4 81 5 92 6 7 77 8 82 - 去掉一个最高分(92),去掉一个最低分(72),最终得分:79.33
- 答辩质询
第一组
Q1:增量设计的4个功能中,团队最看重哪个功能?
A1:校历功能吧~最简单且最实用
Q2:增量设计的实现难度如何,需要团队多少工作量?
A2:实现难度较高,工作量没顾及
Q3:ppt中的bug展示可以使用gif进行更生动的展示
A3:谢谢建议,下次会考虑这种方式
第二组
Q1:是否可以多增添点PPT的 内容
A1:可以,但没有必要
Q2:有没有发现到更多的BUG
A2:已经全部展示
Q3:增量开发的难度如何
A3:实现难度较高
第三组
Q1:你们是否有对用户进行调研来获取一些用户的需求?
A1:未采取调研
Q2:你们的具体的人员分工体现在哪?
A2:在博客和答辩中都有体现
Q3:校园卡充值功能又没
A3:问题没有描述完整哦
第四组
Q1:展示的资料可以有些不充分,希望可以改进
A1:谢谢建议
Q2:增量开发的难度有考虑过吗?
A2:更多是从功能去考虑,难度方面考虑较少
Q3:无
A3:无
第五组
Q1:增量设计里校园卡充值功能是否能确保安全性,怎么确定学校相关部门愿意合作与否?
A1:增加功能的前提就得保证安全性,不能确定
Q2:增量设计里设计主页面会不会多余,把除了课程表以外的模块做主页面是不是并不利于自身使用?
A2:仅代表自己组的意见,不多余
第六组
Q1:您好,请问你们有没有考虑过做采访环节或者问卷调查?
A1:采访环节有做,问卷调查没有做
Q2:您好,请问你们有没有考虑过从不同方面进行测试,如利用网上的软件进行测试?
A2:没有,都是自己来测,从效果来看,这个方法接地气且是个不错的方法
Q3:您好,由于你们ppt内容没那么丰富,是否能够考虑从测评报告中再摘取一些内容?
第七组
Q1:是否有考虑采取采访或调研的方式来听听用户们的想法和建议?
A1:有采访,但没有调研。
Q2:对提出的增量设计是否考虑过具体的实现方法或衡量过它们的实现难度?
A2:有考虑,体现在博客里,欢迎交流。
Q3:展示的资料可以再充分一点,增强说服性。
A3:谢谢建议
第六部分 个人部分
PSP表格
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 45 |
?Estimate | ?估计这个任务需要多少时间 | ||
Development | 开发 | ||
?Analysis | ?需求分析 (包括学习新技术) | 20 | |
?Design Spec | ?生成设计文档 | ||
?Design Review | ?设计复审 | ||
?Coding Standard | ?代码规范(为目前的开发制定合适的规范) | ||
?Design | ?具体设计 | ||
?Coding | ?具体编码 | ||
?Code Review | ?代码复审 | ||
?Test | ?测试(自我测试,修改代码,提交修改) | ||
Reporting | 报告 | ||
?Test Repor | ?测试报告 | ||
?Size Measurement | ?计算工作量 | ||
?Postmortem & Process Improvement Plan | ?事后总结, 并提出过程改进计划 | ||
合计 | 160 | 225 |
- 学习进度条
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
180 | 1500 | 10 | 608 | 学会了微信小程序的各种数据类型的转换 |