软工实践第八次作业——项目需求答辩
前言
- 本次作业链接
- 组长博客链接
- 宣传视频链接
项目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 | 图标设计技能提高、视频后期制作技能习得 |
转载于:https://www.cnblogs.com/SoundOfSilence/p/9905509.html
软工实践第八次作业——项目需求答辩相关推荐
- 软工实践第八次作业(软件工程实践总结)
原博客 目录 一.请回望暑假时的第一次作业,你对于软件工程课程的想象 二.个人或结对或团队项目实践中的经验总结+实例/例证结合的分析 三.对下一届实践的建议和告知.对于后来人的期许. 四.分析一下自己 ...
- 软工实践第八次作业(课堂实战)- 项目UML设计(第五组)
本次作业博客 团队信息 队名:起床一起肝活队 原组长: 白晨曦(101) 原组员: 李麒 (123) 陈德斌(104) 何裕捷(214) 黄培鑫(217) 王焕仁(233) 林志华(128) 乐忠豪( ...
- 2018福大软工实践第八次作业
目录 团队信息 分工选择 课上分工 课下分工 ToDolist alpha版本要做的事情 燃尽图 UML 用例图 状态图 活动图 类图 部署图 实例图 对象图 时序图 包图 通信图 贡献分评定 课上贡 ...
- 软工实践 - 第八次作业
课堂实战 - 项目UML设计 本次作业博客 团队信息 队名:起床一起肝活队 原组长: 白晨曦(101) 原组员: 李麒 (123) 陈德斌(104) 何裕捷(214) 黄培鑫(217) 王焕仁(233 ...
- 软工实践第八次作业——第五组
本次作业博客 团队信息 队名:起床一起肝活队 原组长: 白晨曦(101) 原组员: 李麒 (123) 陈德斌(104) 何裕捷(214) 黄培鑫(217) 王焕仁(233) 林志华(128) 乐忠豪( ...
- 软工实践第三次作业-结对项目1
软工实践第三次作业-结对项目1 简要目录: Step1 · 结对信息 成员信息 项目简介 Step2 · 项目信息 设计说明 原型模型 Step3 · 结对过程 ...
- 2022秋软工实践 第一次结对编程作业
2022秋软工实践 第一次结对编程作业 需求分析 (1)Need,需求 (2)Approach,做法 (3)Benfit,好处 (4)Competitors,竞争 (5)Delivery,推广 UML ...
- 2021秋软工实践第一次结对编程作业
这个作业属于哪个课程 构建之法-2021秋-福州大学软件工程 这个作业要求在哪里 2021秋软工实践第一次结对编程作业 这个作业的目标 实现博饼软件原型并进行博客写作 学号 031902139 队友学 ...
- 软工实践 - 第六次作业
软工1816 · 第六次作业 - 团队选题报告 组长本次作业的博客 NABCD模型 Need: 这个想法来源于生活,目前市面上的闹钟,只是针对个人的时间提醒设置.而我们的这个想法是在两个及以上的人数共 ...
最新文章
- 基于Python进行相机校准
- Windows 文件过滤驱动经验总结
- n条直线相交最多有几个邻补角_【初一】 n(n1)模型在相交线中的应用
- Requirejs2.0笔记
- Delphi动态事件
- nginx系列之八:使用upsync模块实现负载均衡
- Schedulerx2.0工作流支持数据传输
- 高并发 数据库操作比如插入,修改等解决办法
- 用Supermemo背单词达到8000词条
- 力扣每日一刷-144,二叉树前序遍历-递归解法
- python_ 学习笔记(基础语法)
- 数据可视化—如何利用R,制作DashBoard
- 单片机(ISIS 7 Professional):简易红绿灯代码项目
- MATLAB线性规划相关函数用法
- 暨南大学人文社科a类期刊_暨南大学A类期刊目录.pdf
- 深圳宝安学区房_查查吧深圳学区地图
- 计算机如何重新连接打印机,电脑打印机脱机怎么重新连接
- html5 dat.gui,Dat.gui 使用教程
- 买到招行CMP1一天赚90
- 元素偏移offset的常用属性
热门文章
- CMM和CMMI的关系
- 通过Rsync进行3CX备份和录音文件冗余,确保3CX数据安全
- 用PB开发多媒体数据库管理系统
- 抖音之电脑版剪映的使用
- 织梦安装,访问http://域名/install/index.php 出现空白页或Not Found 问题
- Zabbix discoverer processes more than 75% busy原因及解决方法
- 最好用的pdf转ppt软件
- python 适合做什么生意赚钱投资小_使用Python进行优化:如何以最小的风险赚取最多的收益?...
- fiddler stave插件
- 使用Acrobat DC将扫描格式的PDF文件转换为可编辑形式