软工实践第八次做业——项目需求答辩

前言

• 本次做业连接
• 组长博客连接
• 宣传视频连接

项目logo及思惟导图

项目logo

• 项目Logo设计思路：咱们的项目基于福州大学的各个食堂展开服务，因此咱们的图标是一个抽象的碗，碗由字母“J”和“S”（即食的拼音缩写）组成，色调使用了相近的两种橙色，整个logo意在使得用户一看到咱们的图标就联想到热闹的食堂并与咱们的app名产生联系。

• 思惟导图

组队后的团队项目的总体计划安排

阶段	主要任务	计划时间	内容
1	项目选题	2018.09.27-2018.10.12	肯定选题，完成项目的市场调研和竞品分析，指定推广战略
2	需求分析	2018.10.20-2018.11.04	编写需求说明书
3	编码规范	2018.11.05-11.11	完成接口规定、编码规范、编码环境搭建
4	Alpha冲刺	2018.11.11-2018.11.23	完成项目的核心功能开发、先后端对接
5	改进总结调整	2018.11.24-12.07	项目完善、用户试用反馈、测试计划改进
6	Beta冲刺	2018.12.13-2018.12.21	完成附加功能的开发以及根据用户反馈改进

队员本次做业贡献比例

姓名	比例（%）	完成工做
王彬	14	视频拍摄、界面原型设计、logo设计
赵畅	10	类图设计、Word汇总、思惟导图汇总
李恒达	12	思惟导图、视频拍摄、验收标准撰写
胡展瑞	12	验收标准撰写、PPT制做、视频制做
王源	12	类图设计、思惟导图、食堂平面图设计
佘岳昕	10	验收标准撰写、思惟导图
陈志炜	10	功能描述撰写、思惟导图
陈文垚	10	引言编写、思惟导图
林煌伟	10	类图设计、思惟导图

撰写需求规格说明书的分工

答辩总结

小组得分

• 去掉一个最高分，去掉一个最低分，小组最终得分为77分

组号	组名	打分
1	爸爸饿了队	81
2	拖鞋旅游队	78
3	彳艮彳亍队	79
4	火箭少男100	76
5	起床一块儿肝活队	60
6	404 Note Found队	71
7	第三视角	78
8	小白吃	78
9	我头发呢队	79

问题汇总

第二组的提问：

• 问题1：用户一开始使用怎么能最快得知其口味喜爱并进行正确的推荐，推荐的正确性如何保证？

• 答：咱们的推荐是创建在用户使用软件的当时口味偏好进行推荐的，此外在软件开发初期，咱们会积极尝试可能的算法来达到咱们对推荐精确度的要求，初步调查后，随机森林、kNN等线性回归算法在咱们的考虑范围内， 咱们在项目计划书中，以及现场PPT展现中都明确阐述了咱们的软件是基于用户使用时对3-4道布尔选择题的选择来衡量用户的口味。

• 问题2：关于推荐到菜品若是是自选类，可否进行正确的推荐且保证大部分自选都符合用户的口味？

• 答：在团队选题报告答辩中咱们就回答过，自选窗口存在每日菜单变更的问题，这一客观局限使得咱们并不打算向用户推荐自选档口的菜品，不过如今在考虑面对自选档口时只推荐档口的招牌菜的作法的可行性。

• 问题3：如何更大程度吸引用户选择大家的产品？

• 答：这个问题咱们在团队选题报告的项目推广中已经有了全面且清晰的阐述。

第三组的提问：

• 问题1：每家店铺都有不一样的菜品,若是须要细化菜品的话是否须要大量的调查

• 答：是的，将各家不一样的菜品进行口味量化是咱们的项目没法避免的一部分，也是推荐的可信度的保障，因此咱们在项目初期已经对各个食堂的菜品进行录入与分析。

• 问题2：对于学生街以及食堂来讲不少店铺都在不停的更换,如何及时的更新店铺数量,须要维护人员按期的调查吗

• 答：咱们目前只针对福大的各个食堂展开咱们的服务，按照经验来看，食堂大部分的店铺并不会进行频繁的菜品轮换，但对店铺及其菜品的维护也是须要定时进行

• 问题3：如何保证评价的可信程度,若是是别的商家恶意评论或者是水军好评该如何解决？

• 答：咱们的用户评价更多的是用户对店铺的意见和建议，且咱们也不打算提早开发产品的社交属性，在产品上线后得试运行期间咱们会注意恶意差评得状况是否出现，并对此采起相应措施

第四组的提问：

• 问题1：请问推荐的准确性如何保证呢？仅采用简单的线性回归虽然效率高可是很难评估准确性。

• 答：咱们在项目需求答辩中已经阐述了咱们对推荐算法的验收标准，咱们会在训练模型时努力达成咱们的目标

• 问题2：产品的适用推荐范围是多大呢？

• 答：咱们的推荐范围框定在福州大学各个食堂的非自选档口的菜品中，针对自选档口也可能会采起推荐档口特点菜品的方式。

• 问题3：产品是否存在按期的迭代规程？

• 答：感谢您的建议与提醒，咱们已在项目需求计划书中补上这部份内容
  
  
  

第五组的提问：

• 问题1：有没有可能出现重复推荐了相同的店可是用户并不喜欢却没法屏蔽的现象？

• 答：咱们在原型设计中就已经考虑到这个问题，当用户对当前的推荐不满意时用户能够要求程序给出其余推荐，二被否决的推荐在日后的推荐结果中的权重会相应减少

• 问题2：遇到多人出行不知道吃什么的时候这款软件还能适用嘛？

• 答：如何使用本款软件是用户的自由，咱们会尽力保证应用自己功能的易用性

• 问题3：关于大家组的logo，与嘀嘀打车的有些类似（涂上色就差很少了），后期有考虑进行修改避嫌么

• 答：在咱们看来二者差别十分明显

第六组的提问：

• 问题1：请问用户的口味细化大家打算怎么作到？

• 答：咱们经过用户获取推荐菜品前作的4道与非选择题来获知用户当下的口味偏好，并做为咱们推荐的依据

• 问题2：请问软件推广过程打算作出什么努力？

• 答：这部分咱们在项目选题报告中的推广方式部分已经作出充分详细的阐述。

• 问题3：如何突显产品竞争优点吸引用户

• 答：咱们的产品在一开始的定位就将目标人群设置为FZU在校大学生，将使用场景设定在大学食堂的范围，目标清晰，需求明确。市面上存在一些相似菜品推荐的小程序或APP，但它们的核心都是随机推荐菜名而没有综合考虑用户需求，也没有结合所在地区的商铺进行本地化。此外现阶段的类大众点评软件的应用理念和操做逻辑基本大同小异，都是根据用户的地理位置给出附近区域的餐厅推荐，但却没有进一步深刻达到某一菜品级别的推荐。以上就是咱们的软件的竞争优点。

第七组的提问：

• 问题1：请问”用户分析报告“中“总营业额”、“周客源数”、“支付笔数”大家要怎么获取？并非使用大家的产品推荐菜品而且点击了”带我去“，或者评论了，就能肯定他为这道菜品消费了啊

• 答：这是咱们的产品原型对后期产品可能的产品形态的一种展望，为了达成这个目标，咱们须要打通支付方式、食堂商家的中间道路，因此在产品开发初期，问题中提到的统计信息暂时没法上线，在先期的开发中咱们会将精力主要集中在普通用户端的开发与推荐算法的完善，若是产品运行稳定再向咱们的远期产品愿景努力。

• 问题2：请问大家怎们确保推荐的菜肴就是用户适合的？怎们肯定及断定用户的口味及喜好？

• 答：用户对推荐菜品是否满意是一个主观问题，咱们所能作的就是尽可能保证推荐算法的客观合理性。对用户口味的断定是经过用户每次获取推荐前的4道布尔选择题来获取的，以后咱们的推荐算法会根据用户的选择推荐出最可能得到用户青睐的菜肴

• 问题3：请问大家怎们保证菜品推荐的真是可靠？菜品推荐应该是要基于大量的用户，请问大家前期推广打算怎么吸引用户？

• 答：咱们推荐的菜品都是经过到食堂实地采集相应的数据并录入到咱们的数据库中，因此推荐的菜品都是真实可靠的。关于产品推广，咱们已经在以前的项目选题报告中的推广方式部分作出明确详细的阐述。

第八组的提问：

• 问题1：商家端管理是否须要配备硬件，仍是说只要用手机就行？

• 答：商家端的应用会基于Web端提供服务，由于分析报告内容多样，采用Web端展现更方便用户浏览。

• 问题2：关于ppt的讲解，老师是建议说让上次没有参与的非pm的优先，为何仍是pm讲解的？

• 答：由于此次答辩是关于整个软件的总体方向的报告，PM参与了项目需求报告的撰写、PPT的制做、宣传视频的制做，对此次项目有更全面的认识，因此此次PPT演讲依然由PM承担，在以后深刻到技术层面的演讲中会优先让其余组员承担演讲任务。

• 问题3：对于推荐算法的那一部分，要作到花费时间少和匹配相对准确，真的能有相对较好的平衡嘛？

• 答：算法的时间复杂度与其准确性之间并无直接的关系，咱们指定了相应的验收标准对咱们的推荐算法的性能表现进行衡量，确保推荐算法的准确性和运行速度达到应用的要求。

第九组的提问（暂无）：

• 问题1：

• 答：

• 问题2：

• 答：

• 问题3：

• 答：

修改完善本组需求分析报告

• 新增推荐算法验收标准

• 新增对项目的可维护性要求

• 格式审查:去除首页的页码

《需求规格说明书》附件

需求规格说明书

评审表格设计

评审表格下载

遇到的困难及解决办法

• 困难一：原型设计时没有思路

• 解决方法：查看Goole Material design设计规范，了解质感设计的出发点与相应设计理念，参考了MD设计官网的例子，并找到了灵感。

• 问题二：宣传视频制做完成后，场景的转场和过渡太生硬

• 解决方法：在视频的初稿完成后，将PR的工程文件导入到AE中进行进一步的后期制做。

PSP

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

学习进度条

第N周	新增代码	累计代码	本周学习耗时	累计学习耗时	重大成长
1	300	300	5	5	初步了解基于python的网页爬虫原理，阅读urllib和beatufsoup官方文档
2	0	300	3	8	学习Blasiq模型设计工具
3	200	500	10	18	简单python爬虫编写，爬取数据处理
4	580	1080	25	43	较复杂C++代码逻辑的实现
5	150	1230	5	48	linux套接字编程
6	300	1530	6	54	linux图形界面编程
7	0	1530	10	64	视频制做技能提升、原型制做技能提升、了解MD设计规范
8	0	1530	3	67	图标设计技能提升、视频后期制做技能习得