Part 0.开篇
Part 1.调研,评测
· 评测
- 描述最简单直观的个人第一次上手体验
整体深蓝配浅灰的色调,第一眼看起来并不会有违和感,主界面课表页课程分块的底色多样,可通过刷新换色,直观漂亮。
功能上基本满足学生群体的必备需求,例如课表与成绩的查询,图书馆的便利服务,空教室的查找,实验预约等等,同时结合融入易班工具与期末考啦等等其他软件,形成一个整合平台,这一点足以吸引大多数本校学生群体。
同时单独提一下该软件的苹果客户端,增设一键评议与二手市场工具等功能,功能虽小却给人带来相当便利的用户体验。
-
按照描述的bug定义,找出至少两个功能性的比较严重的bug
- 断网环境下,二手市场功能因无法获取数据而进入无休止的加载状态(ios)
-
bug曝光:
- 具体描述: 断开wifi后,启用福大助手的二手市场功能,因无法从服务器端获取数据,程序在加载状态中执行循环等待,但未设置跳出条件判断而陷入无休止的加载等待状态中。
- 可能发生的原因: 网络不稳定出现断开网络或用户无接入网络
- 没有发现此类bug的原因: 没有充分考虑断网未能获取数据的异常处理
-
- 设置下的推送设置点击后导致软件未响应(ios)
-
bug曝光:
- 具体描述: 进入设置模块,点击推送功能,程序出现快闪跳回设置界面后卡死未响应,软件整体奔溃。
- 可能发生的原因: 软件自身内部存在代码错误
- 没有发现此类bug的原因: 没有在软件测试阶段及时修复以至于该模块应用无法正常使用甚至导致软件自身奔溃。
-
- 图书馆无用户信息注销功能(ios)
-
bug曝光:
- 具体描述: 使用图书馆账号登陆后,用户无法进行注销操作,用户登陆后点击账号持续如图界面。
- 可能发生的原因: 设计存在缺漏,欠考虑
- 没有发现此类bug的原因: 不算重点功能,所以开发过程容易忽略
-
- 图书馆无具体的书籍详情(ios)
-
bug曝光:
- 具体描述:用户通过图书馆检索搜索到需要的对象,点击了解详情时发生无信息显示(此功能Android端正常)
- 可能发生的原因: 内部代码存在问题
- 没有发现此类bug的原因: 开发过程中的疏漏
-
- 二手市场设计缺陷(ios)
- bug曝光:
- 具体描述:当用户使用二手市场功能进行登录操作时,无法返回上一界面,仅可通过注册账户链接做一个中间跳板,同时跳转后整体样式改变,宛如两个全然不同的设计
- 可能发生的原因: 设计存在缺漏,欠考虑
- 没有发现此类bug的原因: 不算重点功能,所以开发过程容易忽略
- bug曝光:
- 缺少201702的数据(ios&android)
- bug曝光: 图略
- 具体描述:用户进行绩点查询,但并未返回真实数据,仅为默认值0
- 可能发生的原因: 可能是数据源自身的问题,导致没有办法获取真实数据
- 没有发现此类bug的原因: 未及时反馈信息
- 断网环境下,二手市场功能因无法获取数据而进入无休止的加载状态(ios)
-
假设你们团队需要开发这套系统,需要注意哪些方面(架构、部署运维、微服务等)
可采取微服务的软件架构方式,即将整体软件应用构建成一系列按业务领域划分模块的、小的自治服务,这些自治模块会处理他们自己的数据、执行不同的功能。这种服务分离的方式很大程度上使得整体可以轻易的构建、修改并拓展整合。独立开发、独立部署、错误隔离等,这些都非常适合于整套系统一个健壮的开发过程。
· 采访
某同学甲
-
介绍采访对象的背景和需求(他们有没有用过类似的APP,除了现有的功能还有别的需求么)
一位福州大学大三的学生。他目前在使用福大教务通和易班。他除了现有的功能没有其他更多的需求。
-
描述用户使用这个产品的过程, 用户的问题解决了么?软件在数据量/界面/功能/准确度上各有什么优缺点?用户体验方面有问题么?
使用过程中他认为该软件的界面比福大教务通要好看一些,福大教务通的功能它基本都有,而且还集成了其他的小功能,不用再去下载多余的软件。十分的方便。
-
用户对产品有什么改进意见?
主界面的悬浮按钮太靠下了,不容易按到。无法通过向右滑动的方式打开侧边栏,使用起来不太习惯。在使用一项侧边栏的其他功能时无法通过返回键回到主页面。
-
结论:经过这么多工作,你一定有充分的理由给这个软件下一个评价,请选择一个结论
非常推荐
某同学乙
-
介绍采访对象的背景和需求(他们有没有用过类似的APP,除了现有的功能还有别的需求么)
一位福州大学大三的学生。他目前在使用福大教务通。他除了现有的功能没有其他更多的需求。
-
描述用户使用这个产品的过程, 用户的问题解决了么?软件在数据量/界面/功能/准确度上各有什么优缺点?用户体验方面有问题么?
这个软件的功能很丰富,基础的功能与福大教务通使用的感觉一致,界面会更好一些,在课表的显示上可以将未开始或以结束的课以灰色状态显示,这个功能很不错。
-
用户对产品有什么改进意见?
对历年卷这个功能希望里面的内容能更新更丰富一些。
-
结论:经过这么多工作,你一定有充分的理由给这个软件下一个评价,请选择一个结论
非常推荐
Part 2.分析
- 估计这个项目做到这个程度大约需要多少时间(团队人数6人左右,计算机大学毕业生,并有专业UI 支持)
估计大概要3个月左右,有专业的UI支持可以省去较多逻辑界面的问题,但是由于系统功能较多,需要爬取的数据量比较大,和原应用涉及的关系也比较多,因此开发和沟通周期应该不会太短,但是应该也会有一些现成接口,所以估计3个月左右。
- 分析这个软件目前的优劣(和类似软件相比),并推理出开发团队在软件工程方面可以提高的一个重要部分(具体建议)
与福大教务通相比,福大助手的操作比较简洁,但是可视化稍弱。
福大助手较期末考啦功能会比较少一些。
易班的界面和功能比较美观和齐全,但是逻辑不如福大助手简洁和清晰。
福大图书检索系统加载速度快,但是不如福大助手界面简单。
相似APP或网页端:福大教务通、课程盒子、期末考啦、福大易班、福大图书检索系统、福大大学物理实验选课平台、福大教务处官网等。
相比较下,福大助手的页面简洁,逻辑清晰,加载快,但是功能不齐全,美观性较弱。
- 根据理解和体验,画出整个软件所有功能逻辑框图,根据重要度标识出各模块的重要度、完成度、出发点及效果
- 针对不同的维度评分,对用户体验方面、UI界面美观度、核心功能,分别打分
评分内容 | 满分 | 团队打 | 评分理由 |
---|---|---|---|
用户体验 | 10 | 8 | 一站式的服务十分便捷,但存在少量bug |
UI界面 | 10 | 7.3 | 界面简洁,逻辑清晰,但图标等美感较差 |
核心功能 | 10 | 8.5 | 功能较多,速度快,但是子模块功能不够齐全 |
Part 3.建议和规划
-
如果你是项目经理,如何提高从而在竞争中胜出?
提高产品的稳定性。尽量减少登录错误的情况发生,避免出现某个功能忽然无法使用的情况发生。
-
目前市场上有什么样的产品了?
福大教务通和福大易班。功能基本上差不多,都是可以查成绩,考试安排和课表。
-
你要设计什么样的功能?
成绩详情。可以查看每门课的平均分和和最高分,了解自己的学习情况。
-
为何要做这个功能,而不是其他功能?
从学生的需求出发,成绩是他们所关心的。而出于竞争心理,他们也会有了解大家总体考试情况的需要。
-
为什么用户会用你的产品/功能?
因为学生都是比较关心成绩的,不仅关心自己考得如何,也会想知道大家的情况,知道自己处于什么样的水平。
- 你的创新在哪里?可以用 NABCD 分析。
-
Need 需求:
对于以上的创新,我们不禁可以想到,会有同学使用“福大助手”查看成绩时,不仅仅是想要看到一堆数据,更多的要查看到图表的类型,从而能够更清晰的查看到自身成绩所处的位置。
同时对于过于单一的界面形式,当功能过于多时,希望界面可以形式多样化一些。 - Approach 方法:
- 增加适当的图表信息,借助统计学的方法进行对数据的分析。
- 对于各个不同功能的模块采用相对不同但又独具功能风格的界面。
- Benefit 好处:
- 使用图表可以便于用户直观地查看到相关信息。
- 多样且个性化的界面不仅可以很直观的让用户区分开各个功能的界面模块,而且还可以丰富产品的内涵,这不仅是审美上的提升,还是功能上的改善。
-
Competitors 竞争:
针对市面上的类似产品,我们主打集成功能型的产品。一款产品就可以满足用户对于诸多功能的需求,我们的产品虽然功能众多,但是功能使用方面却不逊色于单一功能的产品。 -
Delivery 推广:
首先,将我们的方案给客户审核,若审核通过,我们将进行推广,可以配合客户的方法进行推广,线上和线下进行推广。线上,如:微信、微博、推特等App以及电视广告等进行推广;线下,如:传单宣传、讲座宣传等措施进行。
-
-
如果你来领导这个团队,会有什么不一样?
如果让我来领导这个团队,我应该会比较注重团队的规范化和制度化。比如时间表的成立,哪个时间该完成什么事情强制的列出来,并且比较详细的对队员要求工作,而不是等到截止日期之前才来完成。而且技术文档的建立也很重要,比如遇到的技术上的bug有同学解决了,那么就更新到文档里,遇到同样问题的同学可以进行查阅,从而降低学习成本。
- 如果你的团队有5个人, 4个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?
任务 | 人数 | 所占时间比 |
---|---|---|
后端代码研发 | 2 | 40 |
美工和界面 | 1 | 30 |
测试 | 1 | 20 |
灵活调整部分(统筹和监管等) | 1 | 10 |
- 文字说明:
一个人负责监管和统筹整个项目进程,合理把握产品的研发方向;两个人完成主要的后端代码的开发;一个人负责界面和美工;一个同学完成测试。具体情况还应当根据团队的实现能力来进行,根据完成的质量和效率进行调整。整体时间比例:开发和测试整体占60%;美工和界面的实现占30%;剩余的10%属于灵活时间的调配,可根据具体情况增加或减少。
- 描述你的团队在16 周期间每周都要做什么,才能在第16周如期发布软件,大小里程碑绩点设定。
周数 | 任务安排 |
---|---|
第一周 | 小组第一次会议,将接下去的工作列表化和明确化;讨论整体的功能布局;分配任务。 |
第二周 | 小组进行考察,考察市面上类似的产品,并对其进行产品评估,列出类似产品的优缺点,为接下来的研发做好准备。 |
第三周 | 进行界面的设计和布局的规划。 |
第四周至第七周 | 进行产品后端的代码研发,同时界面和美工组进行相应的调试以及跟后端组进行会谈,改进原始方案。 |
第八周至第九周 | 测试人员进行产品测试,此时前端、后端、测试人员一齐进行协作。 |
第十周至第十五周 | 针对前期遇到的问题每个小组进行改整,继续完善产品。 |
第十六周 | 灵活时间,继续完善产品,(养成在deadline前完成的好习惯。)等待最终的发布。 |
- 项目发布后,有没有考虑过项目该怎么部署才能满足需求。依据附录图(某校教务处系统的部署)作为参考,分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置)
应用服务器配置:2 核 2G * 12
后端服务器配置:16 核 64G * 4
关系型数据库数量:12(备份 4)
缓存数据库数量:6(备份 2)
网站安全性:WAF、DDOS
Part 4.增量开发设计
优化/新增的功能点
优化功能:
想必都有用过一键评议功能,期末查成绩的时候或者选课的时候还要逼迫我们评议,虽然福大助手的一键评议对学生很友好,但是评议的分数都是随机的,对于那些你喜欢的老师就不是很友好,所以希望在一键评议功能上新加一个可以选择分数的功能。
新增功能:
线上打印资料功能:线上打印ppt或历年卷,线下到店取或者出点小钱线下送货。
选课功能:现在为止好像任何一个软件都无法实现选课功能,选课还要登陆教务处网上很麻烦,希望能增加一个选课功能。
基本实现思路:
评议功能优化:
在评议界面加入分数选择,可以设置整体分数,也可以为每位老师设置分数。
新增线上打印资料功能:
这个功能实现起来需要成本,但是也是能够赚钱的主要功能。实现上分为线上与线下两部分。
线上:在资料的下载界面上新增打印资料功能,即可跳转到设置界面,设置打印的格式,如单面双面、份数、一面多页、是否装订、是否送货上门、以及收件地址等功能,还可以新加选择商家功能,设置完毕后跳转支付页面,支付成功后商家接单处理。
线下:可以自立门店,与别的商家竞争,也可以与校内商家合作,从中赚钱利润。
新增选课功能:
这个功能需要自立门户,在主菜单中加入选课功能,相关的选课操作和教务处一致。
优化/新增功能点与原有产品如何接入:
一键评议新增设置分数功能接入:
此功能在一键评议功能上新增,系统自动评议时获取分数的数据从用户的输入栏上获取,而不是随机获取,对于用户未输入分数的栏目还是使用随机数。
线上打印资料功能接入:
此功能在历年卷功能下接入,在用户下载文档界面选择在线打印,随后跳转到在线打印设置界面。
选课功能接入:
此功能从主界面加入,选课信息要从教务处调入,主要设计好符合人性的选课界面,将学生选完的信息返回教务处。
Part 5.答辩总结
组员得分细则
姓名 | 得分(百分制比例%) |
---|---|
柯奇豪 | 24 |
蒋熊 | 21 |
黄志铭 | 12 |
黄毓明 | 7 |
林翔宇 | 8 |
丁水源 | 8 |
杨礼亮 | 12 |
林淇 | 8 |
评审表格设计
Final Score
小组 | 评分 |
---|---|
第一组 | 74 |
第二组 | 82 |
第三组 | 78 |
第四组 | 77 |
第五组 | 72 |
第六组 | 71 |
第七组 | 72 |
第八组 | 79 |
最低分 | 71(第六组) |
最高分 | 82(第二组) |
有效分数 | 74,78,77,72,72,79 |
最终平均得分 | 75.4 |
Q&A
第一组
Q1. 增量开发的打印功能有更详细的实施前调查吗?
A1. 暂时没有,但是个人认为打印功能很有用处,但是期末考啦上面的做的就不够完善,宣传力度也不够,所以很少人用过。
Q2. ppt中有些页面的字太小了
A2. 好的以后会注意。
Q3. 演讲时的bgm有点出戏(迫于需要提三个问题)
A3.下次会注意。
第二组
Q1. 能否多寻找几处BUG?
A1. 可以看我们的测评文档哦,其实我们找了挺多bug的,只是处于初始PPT时间问题,没有放在PPT上。
Q2. 增量功能的打印功能需不需要配送,如果需要要怎么解决?
A2. 可以自由选择是否配送,我们觉得可以效仿美团和饿了么的订单功能。
Q3. 为什么Android和IOS的BUG没有分开设置一个区块来讲述?
A3. 这个是我们的问题,测评人员通宵做的,后来新增很多bug,来不及改PPT,下次我们会注意的,谢谢。
第四组
Q1: 现场播放音乐让人有些分心,下次希望可以换一种音乐或者不放。
A1: 好的,我们会吸取经验,争取下次能够让你们满意。
Q2: PPT中第五页左上角的饼状图让人难以分辨,希望可以改进。
A2: 谢谢你们的提意,我们会对这一部分进行适当地改进的。
Q3: 有的bug有标注是ios系统,那么没有描述的bug是否是安卓端的呢?
A3: 由于设备原因,其余的大多数是安卓端的,我们也认识到了我们的测试不足,会争取进行改进的。
第五组
Q1:BUG测试记录的第五点图片太多引起接下来的表格很多空白,能够
否适当排版一下,还有第二张图片反了
A1:好的,我们会对此问题进行修改,并引起注意
Q2:报告中IOS的BUG测试是否太少了?
A2:你好,你应该是说反了,应该是安卓较少,可能我们测试的时候疏忽,我们下次会注意。
Q3:能否再测试报告中加上具体的人员分工?
A3:好的,我们会对此问题进行修改,并引起注意
第六组
Q1: 在测试的过程中并未提及对应的软件产品的版本号,这就使得bug没有针对性,有些或许并不是所有用户目前所使用的版本都潜在的问题,存在指向不明的情况
A1: 谢谢指正,我们后续会补充说明的。
Q2: 虽然有着详细的测试数据,但并没有给出一定的解释性说明,这造成虽然堆有大量数据但大众很难去理解其所代表的含义,可以挂出你们对于数据的解读吗?
A2: 具体的解读在文档里有
Q3: 指出的分析大都和数据的安全性相关,能否就你们所目前所指出的安全性给福大助手app提出具体的一揽子解决方案呢?
A3: 数据安全无论在哪,一直是个难题。我们目前也没有很好的解决办法。
第七组
Q1:PPT的bgm是忘记从模板中删去还是故意设计?
A1:这个当然是故意的呀,我们前一天晚上演示过2-3遍,最后才想到才配乐的哈
Q2:PPT演讲部分指代不明,有误导。
A2:具体是哪方面呢?我们下次会再仔细检查的,谢谢!
Q3:对提出的增量设计是否考虑过具体的实现方法或衡量过它们的实现难度?
A3:有设想过的,实施起来其实不会太难呀,问题主要是需要再和学校以及商家一同合作协商。
第八组
Q1: ppt的右侧的黄色栏感觉看的很不舒服很多余,字很小,希望能考虑到听众的视觉感受
A1: ppt的问题我们会根据大家的意见去改进,同时也学习一些ppt做的好的组的ppt。
Q2: 考卷打印的具体实施方案能否分享一下?
A2: 考卷打印我们想做一个外卖的入口,打印店作为商家,商品为打印的份数,将资料的编号作为外卖的备注添加。这是我们觉得目前比较可行也比较容易实现的方式。
Q3: 虽然有一定难度,但是还是一提研究生和导师账号登录后的界面是否有过测评?
A3: 这个我们当时没有想过这方面的,也没有获得这些账号的渠道。
Part 6.个人部分
- 个人PSP
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | ||
· Estimate | · 估计这个任务需要多少时间 | 0 | 0 |
Development | 开发 | ||
· Analysis | · 需求分析 (包括学习新技术) | 30 | 60 |
· Design Spec | · 生成设计文档 | 0 | 0 |
· Design Review | · 设计复审 (和同事审核设计文档) | 0 | 0 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
· Design | · 具体设计 | 0 | 10 |
· Coding | · 具体编码 | 60 | 100 |
· Code Review | · 代码复审 | 0 | 0 |
· Test | · 测试(自我测试,修改代码,提交修改) | 10 | 10 |
Reporting | 报告 | ||
· Test Report | · 测试报告 | 0 | 0 |
· Size Measurement | · 计算工作量 | 10 | 10 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 10 |
合计 | 120 | 200 |
- 个人学习进度条(每周追加)
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
10 | 50+ | 2650+ | 2 | 120 | 小程序API部分的学习和接口 |