小白吃们的需求分析
目录
- 项目整体计划安排
- 项目logo及思维导图
- 一分钟宣传视频
- 团队作业贡献比
- 评审表格
- 答辩总结
- 需求报告改进
- 需求规格说明书
- 困难及解决
- PSP
- 学习进度条
团队项目整体计划安排
| 阶段 | 主要任务 | 计划时间 | 内容 |
|---|---|---|---|
| 1 | 项目选题 | 18.09.27—18.10.12 | 项目选择，经市场调研并与老师沟通后确定选题 |
| 2 | 需求分析 | 18.10.13—18.11.04 | 完成需求规格说明书 |
| 3 | 设计分工 | 18.11.04—18.11.11 | 项目详细分工，代码规范，平台环境基本架构，界面初步美化设计，视觉识别算法完善 |
| 4 | 模块编程及对接 | 18.11.11—18.11.23 | 后端服务器搭建完成，界面交互完全实现，各模块编码基本完成后，进行对接 |
| 5 | 测试 | 18.11.24—18.12.07 | d对alpha版本进行应用测试，根据测试结果确定beta版本优化内容 |
| 6 | 优化完善 | 18.12.07—18.12.21 | 根据上一阶段测试反馈内容，对项目进行进一步优化改善，形成正式版本 |
| 7 | 项目实施 | 18.12.21—19.01.08 | 争取在实际场景中能够试点实施，投入运营 |
项目logo及思维导图
- 项目logo
- 思维导图
一分钟宣传视频
团队作业贡献比
| 成员 | 分工 | 贡献比 |
|---|---|---|
| 葛亮 | 原型优化 | 14% |
| 文斌 | 视频剪辑+评审表设计 | 14% |
| 黄泽 | 报告整理、规范+视频演员 | 15% |
| 静茹 | 视频idea+视频演员+答辩记录 | 14% |
| 敬甲 | logo+思维导图+功能描述+博客整理 | 14% |
| 泽明 | 功能验收标准 | 14% |
| 刘浩 | ppt制作演讲 | 15% |
评审表格
答辩总结
- 答辩得分
| 组号 | 得分 |
|---|---|
| 1 | 79 |
| 2 | 73 |
| 3 | 76 |
| 4 | 72 |
| 5 | 66 |
| 6 | 78 |
| 7 | 75 |
| 8 | 80 |
| 9 | 77 |
最后得分：75.71分
- 问题收集与回答
第1组
1、在早上的答辩中，为了解决诚信问题所提出的解决方法需要付出额外的人力成本进行诚信核查，这是否会影响到项目初衷提高支付效率？答：出现诚信问题，需要诚信核查的情况属于少数情况，不会影响整体的结算效率。
2、如果算法识别不出菜品，之后软件的处理逻辑是什么？
答：在服务器正常运行情况下，不会出现识别不出菜品的情况，如果出现极少数识别错误的情况，会在项目落地实施后，若出现极少数识别错误的情况，我们会与商家协定相应处理措施。
3、识别算法所需要的数据集有一个收集的标准吗？
答：我们的数据集的标准：要求可以拍摄餐盘内的所有菜品，并且同一个餐盘从菜品不同分布拍摄，每种分布100张。
第2组
1、会不会出现使用产品时识别不出菜品的情况，到时候该如何解决呢？答：在服务器正常运行情况下，不会出现识别不出菜品的情况，如果出现极少数识别错误的情况，会在项目落地实施后，若出现极少数识别错误的情况，我们会与商家协定相应处理措施。
2、消费者的信用问题该如何得到更好的解决？
答：以项目投入使用前的宣传手段和信用支付监管手段共同完善对信用问题的解决。
3、会不会出现识别菜品出错，从而导致算错了价格，导致用户（包括学生和商家）的体验变差
答：算法的置信度现已达到95.4%以上，在投入使用前会达到99%以上，识别错误概率极低。在项目落地实施后，若出现极少数识别错误的情况，我们会与商家协定相应处理措施。
第3组
1、你们提到的在线支付允许支付宝、微信、学生卡等多方支付平台，请问是否有考虑过可行性呢？因为我自己平常还没有遇见过在小程序里允许支付宝支付的情形。答：因为平台和模式限制，我们目前只提供微信支付的接口，基于微信支付的普遍性，可以满足绝大多数用户的需求。
2、产品的推出主要是为了方便学生群体，但是商家可能存在直营、外卖以及使用小二结账等多平台导致应接不暇的情况，如何去处理使得商家更愿意使用你们的产品？
答：我们的产品主要针对食堂的使用场景，满足商家的直营需求，而在学校的监管下经营外卖的食堂商家会越来越少直至没有，所以不会存在经营应接不暇的情况。
3、你们在数据分析中提到可以分析出卡路里、热量等等关乎健康的数据，但就我个人而言，这样的数据不太能得到我的认同，因为可信度不高，有什么更精准更有说服力的数据分析方式吗？
答：提供的健康数据分析，基于菜品中的食材种类给出相应的数据，但提供给用户具有一定的参考价值。除此外，我们会基于用户的用餐量，提供“猜你喜欢”的推荐功能。
第4组
1、识别错误的后续处理是否能保证到用户体验呢？答：识别错误势必导致用户体验不佳，所以我们在尽可能减少用户不良体验的情况下，会把更多精力放在提高识别准确率上。
2、识别错误率控制在1%以下是十分困难的一件事，如果是基于速度快的YOLO算法的目标检测来完成，是否在准确性方面达到的效果不会特别好呢？
答：是的，确实比较困难。目前我们用YOLO检测了1W张图片，准确率在95.4%。并且还在优化中。在我们优化模型之后，我们有信心将准确率提高到99%。
3、产品的市场前景非常宏大，是否存在一个详细的规程来协助产品的迭代维护呢？
答：暂时没有，精力有限，能力有限，放眼当下。
第5组
1、你们是否有考虑到用户使用你们的产品会出现的逃费行为，就是买了产品不付钱，或者只拍部分的食品，这种行为你们有考虑到如何检测到或避免吗？答：逃单行为我们会采用摄像头人脸识别，匹配账户的选餐记录和支付记录来做监管。对于只拍部分食品的行为，也在我们的考虑范围内，但没有很好的解决方案，但这种情况属于极少数，损失可弥补。
2、你们PPT给出的自选窗口菜品识别错误率控制在1%一下，是否有些偏高呢，毕竟涉及到商家的利益，能否再降低错误率，否者商家如何会选择你们的产品呢
答：不会偏高，技术虽好也有瓶颈和天花板。识别错误率控制得极低，也有相应的反馈机制，在这两个前提下，即便有错误和损失，成本也极低，在给商家带来足够的利益的前提下，商家能够接受这样的额外成本。
3、你们的产品主要卖点就是不用排队，但你们是否有考虑到排队实际上是能帮助食堂消化人流，如果每个人都不排队的话，那么是会出现很多人找不到座位的，而且取餐人流和取完餐回座位的人流是否会产生冲突混乱呢
答： 排队消化人流是因为食堂本身硬件限制，才会有这样的畸形的好处。而排队结算点单是食堂用餐体验的硬核需求，我们不会为了一粒芝麻丢掉一个西瓜。
第6组
1、你好，请问原型登陆页面老师、学生登录按钮不够清晰，原型不够美观，有考虑改进吗？答：现有原型主要为了展现项目逻辑，美观度会在项目实施时改进。
2、你好，请问视频背景音乐太过嘈杂，是否考虑改进？
答：会在上传到b站时使用强降噪改进。
3、你好，请问是否考虑分析用户喜好?
答：会根据用户的点单量，为用户提供“猜你喜欢”功能。
第7组
1、请问当大量用户没能及时取餐，而导致有大量的餐盘堆积在商家工作区，这样给工作人员带来了极大的不便，你们打算怎么解决？是否只能到商家附件才可以点餐，还是可以预约点餐？答：参考现在市场上已有的点单小程序，例如：“汉堡王”等，提供用户位置选择界面，让用户自己选择是否到达食堂，同时也有GPS系统的定位，确保用户到达食堂才可点单。
2、你们软件拍照识别支付的操作复杂度是否会大于直接扫窗口的支付宝二维码？如果这样对于效率的提升似乎并不是很大。
答：拍照支付的位置是在座位上，二维码是在窗口前，即便操作复杂度相同，也是更好的体验。
3、请问你们调查过商家愿意使用你们产品的比例吗？当商家使用的比率不高的时候，你们打算怎么说服商家？
答：没有调查过。宣传和合作方式有很多种，不是技术层面简单明了，涉及到人的意愿的问题，总是复杂的，也总是有解决办法的。
第9组
没有问题
需求报告修改
根据其他组的意见和建议，没有需要修改的地方。
需求规格说明书
困难及解决
困难描述
1、规格说明书规范化
2、logo以及短视频的idea
3、验收标准的完善
4、ppt演讲的练习
做过哪些尝试
1、在网上查找比较好的一整套文档规范，并写入文档
2、logo参考了ofo的配色，短视频引用了“真香系列”的思路
3、验收标准参考了之前学长学姐们的格式，结合自己的实际来完成
4、组内有提前做ppt演练
是否解决
1、文档规范合格
2、在老师的要求和条件限制下，做出的视频和logo都不错
3、验收标准基本完善，后期会根据情况做小的调整
4、ppt演讲流畅，但还存在过分依赖演讲稿的问题
有何收获
1、学习到了比较好的文档规范
2、视频和logo的制作，让我们更贴近自己的项目
3、有了一套基本完善的标准，也是为之后的完成定下了一个目标和方向
4、关于ppt演示认识到了很多细节问题，不再一 一详述，演讲展示仍需继续改进
PSP
| PSP | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 45 |
| •Estimate | •估计这个任务需要多少时间 | 390 | 545 |
| Development | 开发 | 0 | 0 |
| •Analysis | •需求分析 (包括学习新技术) | 60 | 60 |
| •Design Spec | •生成设计文档 | 60 | 60 |
| •Design Review | •设计复审 | 30 | 45 |
| •Coding Standard | •代码规范(为目前的开发制定合适的规范) | 30 | 60 |
| •Design | •具体设计 | 60 | 90 |
| •Coding | •具体编码 | 0 | 0 |
| •Code Review | •代码复审 | 0 | 0 |
| •Test | •测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 60 | 120 |
| •Test Repor | •测试报告 | 0 | 0 |
| •Size Measurement | •计算工作量 | 30 | 20 |
| •Postmortem & Process Improvement Plan | •事后总结, 并提出过程改进计划 | 30 | 45 |
| 合计 | 780 | 1090 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 4 | 0 | 340 | 5 | 25 | Leangoo工具的学习 |
| 5 | 300 | 640 | 15 | 40 | 哈希算法、优先队列、结构体等c++算法复习 |
| 8 | 0 | 640 | 10 | 50 | 代码方面暂无 |
2863
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
