福大软工 · 第十次作业 - 项目测评（团队）

拖鞋旅游队项目测评

前言

• 队名：拖鞋旅游队
• 组长博客：https://www.cnblogs.com/Sulumer/p/10087665.html
• 本次作业：https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2436

第一部分 调研，评测

评测

Android端评测

• 上手体验：功能全面，易于上手，占用内存小，页面设计人性化。
• 思维导图：
  
• Bug1：
  
• Bug2：
  
• 为什么这个产品组的人没有发现这些bug：测试小组测试不仔细，不全面；这些功能前后端开发可能不同步。

IOS端评测

• 上手体验：运行流畅，图标简洁，配色清爽，部分图片失真，功能种类多但是不完善，夜间模式，导入日历功能方便，实用性高
• 思维导图：
  点我查看原图
  
• Bug1：
  
• Bug2：
  
• 为什么这个产品组的人没有发现这些bug：第一个bug可能是因为开发者对于考试安排的理解错误。第二个bug是前后端对分享功能的开发不同步。

假设你们团队需要开发这套系统，需要注意哪些方面(架构、部署运维、微服务等)。

• 我们会加强宣传。
• 根据反馈修复bug。
• 跟进更新如历年卷、易班等功能。

采访

• 采访对象背景：附件某高校大三学生，没有使用过类似app。
• 采访对象需求：需要一款可以查看课表、考场、成绩及一些在校日常查询的功能。
• 采访照片：
  
• 采访对象的使用体验：
  • 采访对象对日常一些所需要的查询信息的问题都可以完美地解决。
  • 数据量很齐全且丰富，所需要查询的信息都可以查到。
  • 界面较为简洁明了且醒目，但不同界面间的字体风格不够统一。
  • 功能比较齐全和丰富，但部分易班上的功能使用度过低。
  • 准确度上做的较好，使用到目前未发现不准确现象。
• 采访对象的改进意见：这位用户强烈建议增加一个课表分享和成绩分享的功能，他想分享到微信上给别人看他的课表，以及家长对于成绩的查询，能够简单明了直观的看到所需的数据。
• 结论：非常推荐！

第二部分 分析

• **估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。 **
  我们估计这个项目做到这个程度只需要一个月，因为既然是本校大学毕业生，应该会有比较好的基础，而且做这个项目应该会受到学校极大的支持，对接口的获取难度应该较低，而且有专业的UI支持，我们认为一个月时间足够了。

• 分析这个软件目前的优劣（和类似软件相比），并推理出开发团队在软件工程 方面可以提高的一个重要部分（具体建议）。
  这款软件优势在于拥有较为广阔的群众而且功能也算齐全，劣势就在于有些功能可以有时候无法使用（空教室功能），在软件工程方面可以提高的一个重要部分就是对历年卷这一模块的管理，许多科目都上传了不相关的信息从而干扰大家获取正确的信息，希望能够加强这一块的管理。

• 根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果。
  点我查看原图
  

• 针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分。
  用户体验方面打7分：因为有些功能经常无法使用而且历年卷功能没有维护。
  UI界面美观打9分：界面简洁明了，矢量图也很精美。
  核心功能8分：查询课程表、查询成绩、查询考场、历年卷应该都是核心功能，大多数都好用。

第三部分 建议和规划

• 如果你是项目经理，如何提高从而在竞争中胜出？
  • 加强宣传。这款产品宣传力度在同类中非常低，大部分同学没有使用过甚至没有用过。
  • 解决bug，增强用户体验。
  • 增强功能，如查看课表，查询成绩，查找历年卷。
• 目前市场上有什么样的产品了：超级课程表、福大教务通、课程格子。
• 你要设计什么样的功能？
  • 历年卷代打印及送货上门服务。
  • 学分查询。
  • 教师基本信息查询。
• 为何要做这个功能，而不是其他功能？
  据我们作为学生的角度以及综合前期的调研等，这几个功能现有方式较为不方便，而这些功能又都是刚需。
• 为什么用户会用你的产品/功能？
  • 到期末的时候大家都会有打印历年卷的需求，这样比较方便同学。
  • 目前福大助手易班中的学分查询已经不能用了。学分查询对于同学来了解自己还差多少学分还是很有必要的。
  • 教师基本信息查询可以帮助同学们在学期选课的时候看到教师的基本信息帮助同学们选择任课老师。
• 你的创新在哪里？可以用 NABCD 分析。
  我们的创意解决了用户打印历年卷，查询学分，已经在选课时可以比较老师的挂科率和高分率。相对于其他竞争者而言，不太可能做到这么本土化的功能，他们的课表app固然很优秀，但也伴随着广告多，社交性太强等诸多问题。而我们的app更能满足用户的需求。
• 如果你来领导这个团队，会有什么不一样？
  如果我来领导这个团队，说实话，我觉得不一定会比现在的团队做得好。但是站在另一个角度，用户反馈、运营方面并没有得在这个产品的现有团队得到很好的体现。如果是我来领导，在产品上线后，我会加强运营这个产品，至少做到让全校学生都知道又这款app。用户反馈也是极其重要的，它可以帮助我们不断的修复和完善产品，我会重视用户反馈，有时间甚至会与用户深入沟通，以此来不断提升产品。
• 如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
  这是一款工具类的产品，同时具有非常强的竞争力，因此我认为这款产品的美工任务还是比较小的，同时开发周期也是比较紧张的，不足以分配一人。我会配置两名人员作为前端开发（其中一名为前端组长），两名后端开发（其中一名后端组长），一人项目经理兼产品经理兼美工兼运营，全员开发（两名组长与项目经理主要测试，其他人员辅助测试）。
• 描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定。
  
  
• 项目发布后，有没有考虑过项目该怎么部署才能满足需求。依据附录图（某校教务处系统的部署）作为参考，分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置) 。
  

第四部分 增量开发设计

• 优化/新增功能点的原型界面

  • 新增历年卷上传入口。
  • app消息推送功能。

• 基本实现思路

  • 历年卷上传入口

  • 后端新增一个文件上传接口，为了安全要加入token以及AES加密，同时不能直接发布，需要有一个标识标记审核情况。
  • 前端在历年卷页面加一个上传按钮，上传参数：学院、科目、文件、学号、时间....同时上传只是上传，管理员在后端页面通过审核之后，才允许出现在历年卷里。
  • 奖励还是无奖励机制，后续再看积极性。

  • app消息推送功能

  • 出成绩或者考试日期公布临近，就会推送。
  • 校招，每天的招聘信息推送。 由于考虑到出成绩、考试、校招这些都会提前出来，而且也不是紧急时间，所以可以采用轮询的方式，频率每12小时或每6小时跟服务器请求一次，如果有新通知则在安卓端弹出。

• 优化/新增功能点与原有产品如何接入
  历年卷入口简要原型：
  

第五部分 答辩总结

• 团队贡献比例
  | 学号 | 成员 | 分工 | 贡献分 |
  | --------- | ------ | ------------------ | ------ |
  | 031602428 | 苏路明 | 撰写博客，回答问题 | 9|
  | 031602401 | 陈瀚霖 | 评测，评审表，提出问题| 11|
  | 031602406 | 程晓宏 | PPT制作与演示| 12|
  | 031602438 | 叶一帆 | 增量开发 | 9.5|
  | 031602407 | 何家健 | 评测，评审表，提出问题| 10|
  | 031602410 | 黄海潮 | 采访| 9|
  | 031602429 | 王锦扬 | 建议与规划 | 9.5|
  | 031602442 | 郑孔宇 | 分析|9.5|
  | 031602439 | 俞凯欣 | 建议与规划| 9.5|
  | 031602421 | 林世杰 | 项目评测报告| 11|

• 评分：去除最高分（81）最低分（71）后的平均分：75.84

  组号	团队名	评分
  1	爸爸饿了	71
  2	拖鞋旅游队	81
  3	彳艮彳亍	79
  4	火箭少男100	72
  5	起床一起肝活队	75
  6	404 Note Found	76
  7	第三视角	74
  8	小白吃	79

• 问题&回答

第一小组的问题：

• Q1:增量开发中的打印送上门服务可行性强吗，毕竟打印成本很低，但是人力送货上门的成本很高？
• A1:我们觉得可行性还是挺强的，至少打印利润高，用户在这方面需求也比较强。可通过用户自行选择上门或者自取，上门收取额外费用（1-2元），其实在校内送货上门地点还是比较集中的，可以考虑一天送一次等，数量上去了，成本就降低了，同时校内打印服务市场划分还是比较明确的，这一服务能有效提升合作打印店的市场扩张。
• Q2:是否考虑过对增量功能采用其他的送货方式，比如用户到店自提或者使用类似丰巢快递柜的设变来支持这个功能？（只是假设）
• A2:有考虑过多种方式结合，如果只是纯粹到店自提，资料的管理也是一件很棘手的事情，我觉得在这一场景不适用类似丰巢快递柜的设变，成本过高，没有必要。
• Q3:测评除了采访对象外是否有发布问卷调查？
• A3:这一方面我们相对其他组确实比较欠缺，我们没有发布具体的问卷调查，只有通过一些数据收集，以及采访交流。

第三组的问题

• Q1:请问你们的致命级bug2是什么系统的bug？
• A1:我们在测试报告以及PPT都有以系统来分割bug，我们展示了不止一个致命级bug，好像没有分清这里说的是哪个bug。
• Q2:请问再找其他学校同学测试的过程中两者学校易班或是大物实验等一些福大助手核心功能模块在现实中的作用是否相似？
• A2:易班类有相似，大物实验没有具体了解。
• Q3:请问那位被采访同学说希望增加课表分享,课表分享不是已经有了么？
• A3:但是目前福大助手这方面做得好像并不够完善，也不能成功分享吧。IOS系统没发现课表分享功能。

第四组的问题

• Q1:ppt中部分图片建议考虑使用透明的底，而不是白底。
• A1:作为白底主要是考虑到图片的界限问题，以后会注意。
• Q2:bug展示的不够多，是没有发现更多的呢还是选了两个有代表性的呢
• A2:选取了两个有代表性的，其他的相对感觉不是很重要或者频率不是很高。
• Q3:采访用户数量是否有些不足呢
• A3:这一方面我们相对其他组确实比较欠缺。

第五组的问题

• Q1:采访对象是否太少，结果会不会出现特殊性
• A1:这一方面我们相对其他组确实比较欠缺。但是我们也有收集其他的数据，从反映情况还是没有出现特殊性的。
• Q2:ios端的bug没有体现系统环境，查询不到是否足以够作为理由
• A2:福大助手软件内没有注明版本，在app store中查询应是3.9.12.版本。
• Q3:测评报告第八页，BUG2中的b小点，“几点”是否为错别字，这能否体现后期对报告成品的审核不够充分
• A3:确实是错别字，这是我们的失误，我们考虑将撰写报告的人员“祭天”。

第六组的问题

• Q1:ppt24页的改进意见中，课表分享福大助手已经实现了
• A1:但是目前福大助手这方面做得好像并不够完善，也不能成功分享吧。IOS系统没发现课表分享功能。
• Q2:逻辑框图和思维导图显示不清楚
• A2:本次截图确实都显示比较模糊，我们也有尽力在处理。
• Q3:能否关闭APP消息推送功能
• A3:确实应加入app消息推送的选择。

第七组的问题

• Q1:ppt功能设计中第一点是：历年卷代打印及送货上门服务。此功能实现起来有点难度，想知道怎么来具体实现这个功能？
• A1:用户选择打印，后台数据发送给打印店并产生单号，提取方式选择送货上门（考虑收取1-2元服务费）或者自取，现在跑腿这么发达，送货上门应该不会问题。
• Q2:在增量功能中，对于那个历年卷的功能，假设会去实现，那请问你们怎么判断历年卷的真实性，以及可靠性？
• A2:历年卷上传肯定是需要后台人工审核的，也可以考虑在前台注明不明真实性，用户发现历年卷的不真实可K它，被K多了的历年卷将考虑暂时下架重新审核。
• Q3:ppt功能逻辑图中你们认为“大物实验”的完成度是0，你们是怎么判断出是0的？
• A3:目前好像登录不上？

第八组的问题

• Q1:测试报告中的中功能点的重要程度与完成程度的数值是否具有准确性和科学性？
• A1:只能说是预估吧。
• Q2:ppt中表示福大教务通作为一款福大助手工具是不合格的，但是为什么福大教务通的使用率依旧如此之高？
• A2:首先其在产品推出前期做了良好的推广效应，同时其实官方产品，有官方光环保护。最重要其实感觉其是针对教务通方面，不具备其他的助手功能，其使用率高我觉得是因为用户习惯（本人也是教务通忠实粉丝，对此方面思考认为是如此）。
• Q3:历年卷打印功能在期末考啦上面已经失败过了，你们是否有更好的实施方法？
• A3:其的用户需求度不言而喻，失败不代表不可行，失败也有很多种原因。良好的服务和用户的便利是这方面最重要的条件，至于实施方案不清楚之前的期末考啦是怎么操作的，觉得这方面在打印源与配送上有非常大的优化空间。

第六部分 个人部分

• 个人PSP表格

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	20
· Estimate	· 估计这个任务需要多少时间	5	10
Development	开发	20	20
· Analysis	· 需求分析 (包括学习新技术)	30	40
· Design Spec	· 生成设计文档	5	10
· Design Review	· 设计复审 (和同事审核设计文档)	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	10	30
· Coding	· 具体编码	40	110
· Code Review	· 代码复审	30	30
· Test	· 测试（自我测试，修改代码，提交修改）	10	20
Reporting	报告	10	10
· Test Report	· 测试报告	5	5
· Size Measurement	· 计算工作量	5	5
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	20	30
	合计		220

• 学习进度表

第N周	新增代码(行)	累计代码(行)	本周学习耗时(小时)	累计学习耗时(小时)	重要成长
9	0	800	12	82	java语法，编程练习
10	0	800	10	92	学习mybatis
11	0	1500+	15	97	学习mybatis、编写算法题，学习java