组队后的团队项目的整体计划安排（1 2分）
| 序号 | 持续时间 | 主要任务 | 是否完成 |
|---|---|---|---|
| 一 | 9.28 | 组队 | √ |
| 二 | 10.1-10.21 | 制作团队选题报告 | √ |
| 三 | 10.22-10.27 | 制作团队需求分析报告 | √ |
| 四 | 10.28-11.2 | 团队编程准备与制作 | × |
| 五 | 10.28-11.11 | alpha冲刺准备 | × |
| 六 | 11.12-11.22 | 进行alpha冲刺，并发布alpha版本 | × |
| 七 | 11.23-12.3 | beta冲刺准备 | × |
| 八 | 12.4-12.13 | 进行beta冲刺，并发布最终版本 | × |
| 九 | 12.14-课程结束 | 课程总结 | × |
团队分工（2 5分）
-
alpha版本需做事情明细
- 1）.先完成实现小程序必须完成的界面以及接口，拓展功能暂不考虑
- 2）.前端为本组6位女生，各自负责自己的原型模块
- 3）.后端为本组5位男生，其中3个负责函数，2个负责数据库
-
成员分工明细及TODO list
成员分工
| 项目经理 | 郑裕恒 |
| 函数与接口设计 | 潘海东，余廷龙，方瑞雄 |
| 数据库 | 郑裕恒，翁世豪 |
| 原型修改与实现 | 张万聪，刘诗琳，严欣，陈苏苏，王玥，马丽华 |
TODO list
-
燃尽图
思维导图（3 2分）
总思维导图
功能模块
市场定位与分析模块
营销策略模块
风险管理模块
团队分工与贡献比例（4 2分）
| 姓名 | 主要工作 | 贡献比例 | ||||||||||
| 方瑞雄 | 评审表设计，博客撰写，最终评审表整理 | 10% | ||||||||||
| 严欣 | 报告中验收验证标准的编写 | 5% | ||||||||||
| 陈苏苏 | 报告中验收验证标准的编写，报告细节更改 | 10% | ||||||||||
| 翁世豪 | 报告中功能描述的编写，思维导图设计 | 8% | ||||||||||
| 潘海东 | 报告中功能描述的审核 | 2% | ||||||||||
| 刘诗琳 | 原型图设计，记录课堂提问问题 | 10% | ||||||||||
| 郑裕恒 | PPT制作，文档中交互原型设计，PPT演讲人员，图片修整与美化 | 15% | ||||||||||
| 王玥 | 报告中验收验证标准的编写，原型设计，logo设计与解读 | 10% | ||||||||||
| 张万聪 | 原型图设计，博客撰写 | 10% | ||||||||||
| 余廷龙 | 对报告的排版与整理，UML图设计，报告引言撰写 | 15% | ||||||||||
| 马丽华 | 报告中验收验证标准的编写 | 5% |
评审表设计（5 1分）
UML（6 10分）
- 由于我们产品功能不多没办法拆分得那么细，所以每个图整合后只做一份（很用心做的，此条已征得助教的同意）
用例图
- 描述的部分：
- 下单用户与配送用户之间通过订单进行联系
- 面临的问题：
- 不同用户双方可能会对订单产生争议
- 订单无法第一时间更新
- 解决了哪些问题：
- 下单用户与配送用户对订单的操作有主动权，并且实现对订单的可视化
类图
- 描述的部分
- 用户的个人信息和用户对订单的操作
- 广场订单的表现形式
- 订单本身的状态以及订单衍生出的信息交互
- 面临的问题
- 用户信息可能不够全面，导致无法准确得到用户信息
- 订单的处理问题
- 解决了哪些问题
- 使用评论与点评功能解决了用户之间的交互
- 使用标签让订单更具体，让用户更方便
活动图
- 描述的部分
- 订单生成与实现功能
- 面临的问题
- 订单管理功能
- 用户对订单的要求操作
- 解决了哪些问题
- 让用户对订单有更多的主动权
状态图
- 描述的部分
- 描述了用户创建订单与查找订单的过程
- 面临的问题
- 用户订单无人受理
- 用户订单无法被搜索
- 解决了哪些问题
- 解决了用户之间对订单的评论
- 解决了用户订单发布错误重新下单的功能
实体关系图
- 描述的部分
- 用户，订单，评论三者时间的属有关系
- 面临的问题
- 用户信息未能如实呈现
- 订单与用户间的匹配不够完善
- 评论无法完全解决用户与订单间的矛盾
- 解决了哪些问题
- 订单与用户关系之间的可视化
- 评论与订单之间的平衡
- 用户对评论的操作可执行
工具选择（7 2分）
UML图设计的工具
- 我选择的是starUML，因为这学期选修了《面向对象分析与设计》，老师要求我们自学UML，并且需要在课程设计里使用UML做软件建模，然后他就推荐给我们这一款软件，因为比较容易上手。
实体联系图是用亿图图示做的，因为starUML没法做实体联系图，所以就百度了一个软件。（廷龙提供）
原型图设计的工具
- 墨刀，Axure Rp 9（万聪诗琳提供）
对工具的评价（8 2分）
- 对于starUML,老师诚不欺我，这款软件确实非常容易上手，只需要用鼠标拖动工具栏的控件和线条便可以轻松绘制各种UML图，导出图片也非常方便，但是这款软件也有明显的缺点，就是画出的图比较不够美观，但是也还看得过去。对于亿图图示，我觉得这款软件也非常方便使用，可以画各种图，而且可以画得非常漂亮，但是这款软件是收费的，而且价格不低，它有15天试用期，但是在试用期导出的图会有试用水印，所以我就只好通过调整画图的位置让我的图避开水印，然后再把我需要的部分截取下来。
- 墨刀界面不能批量导出为图片，但是很多图标都是现成的，可以生成链接分享、团队多人协作以及各种对齐、参考线都挺好用的。
- Axure Rp 9 不知道为什么在加入交互效果的时候会出现闪退，功能比墨刀更全面，可以生成HTML文件、可以批量导出图片。
答辩总结（9 9分）
本组现场答辩得分
针对其他小组提问回答
第一组提问：对于紫荆一楼这种菜品不固定的档口，有没有考虑增加显示菜品的功能，有没有考虑过如果在食堂排队的同学会因为配送员点好几份等待过久而发生纠纷
由于我们平台现在不是定位为为食堂进行销售，而是通过点单方自行决定吃什么东西，所以暂时没有考虑过引进菜品。当这个小程序后期成熟后，会考虑加进去。配送员应该是避开高峰排队时间的，我们的小程序目的也是错峰购买，所以这个问题产生的几率应该不大。
第二组提问：我觉得挺不错的，就是好像跟我们的项目有些撞车了，建议多增加些额外小功能来吸引用户和凸显自己的卖点
谢谢建议！我们现在主推的是食堂带饭的这一功能，在把这一功能尽善尽美之后我们也会加入代购超市奶茶店，代取快递，文印店打印等功能
第三组提问：各大外卖平台上的店家都可以显示哪些套餐、菜品已售罄，但是对于学校的食堂来说，可能会出现配送员点菜的时候某些菜品已售罄，如何解决这一问题
我们鼓励在食堂的人来当配送员，所以他们对食堂的菜品是否销售一般能够及时掌握，如果无法满足点单人的要求，可以联系取消订单或者更换菜品。
第四组提问：无
第五组提问：咦我们不就是第五组吗
第六组提问：发布配送可否有时间范围约束？
在发布订单的时候就可以设置配送时间约束
第七组提问：食品产生问题时平台如何界定责任？
首先在注册的时候用户需要签订协议，在发生食品问题的时候告知平台，平台会出面联系配送员和商家，并积极协助调查，具体的责任认定要在了解责任源头之后协商。
第八组提问：如何解决因一个人接单太多，而导致食品的新鲜度不好，从而导致用户对使用软件的意愿降低的问题？
1.对于文档和PPT的问题，我们以后会更加注意，谢谢提醒！
2.食物的购买打包和配送全部由配送的同学完成，因此不存在掉包的问题，如果点单的同学发现收到的食物与自己订单描述不同，可以当面和配送同学解决问题，对于付款凭证的真假，我觉得作为福大学生，不会为了几块钱去造假，另外，食堂饭菜的价格大家都比较了解，如果价格真的偏高，很容易被发现，再者，付款凭证里都有商家名和付款时间，假设一个人想要制造一个时间商家相同的凭证，那他就必须再买一份比较便宜的饭，这样岂不是得不偿失。总之，出示假凭证发生的概率非常小，即使真的发生，下单的同学觉得价格偏高也可以当面提出质疑，最后我们要声明一下，我们只提供一个平台，对于交易细节问题，原则上都需要用户自行解决，如果用户无法解决，可以联系我们，我们会在第一时间出面协助解决。
第九组提问：食堂食物的标价是该应用后台更新吗？怎么样保证及时快速更新？如果食堂有打包费这样的额外要求是用户私下交易还是平台来监管？
由于食堂饭菜的价格及物价的波动无常以及本产品的适用人群是通过校园认证的学生，本平台只提供点单方和配送方提供食堂菜品、配送价格等信息的公布，所涉及的金钱只包括配送价格。具体饭菜的价格（包含打包费）以支付宝、微信、一卡通等的消费记录凭证为基础进行支付。在信用机制和身份认证机制下，服务方与被服务方的交易是私下进行的。
第十组提问：是否考虑过以可视化地图的形式向用户展示配送员的配送情况？
现阶段暂时没有考虑以可视化的形式展示配送员的送餐情况，原因如下：校内食堂离宿舍距离近，一旦接单成功配送时间会很短。但这会是我们平台可以争取的方向，如果条件允许，我们可能会在beta版本加以实现。
第十一组提问：能不能预计送达时间呢
可以，在点单和配送的界面都有填写预计送达时间和预计配送时长。
第十二组提问：建议加入商家端，商家可以自定义菜单，价格也可以更及时透明更新。另外关于封条那个建议我觉得非常不错，这里+1
提供《需求规格说明书》作为随笔的附件（经过修改的最终版本）（10 1分）
遇到的困难及解决方法（11 2分）
- 困难描述
- 对验收验证标准没有明确的定义导致工作推迟
- 从无到有的原型设计，工具无法确定
- 做过哪些尝试
- 从多份文档提取验收验证标准的写法，并加以理解
- 尝试多种原型设计工具，最终决定使用墨刀
- 是否解决
已全部解决 - 有何收获
很多东西不懂需要多尝试，才能有突破
PSP（12 1分）
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | · 计划 | 60 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 60 | 60 |
| Development | · 开发 | 1770 | 2550 |
| · Analysis | · 需求分析 (包括学习新技术) | 240 | 300 |
| · Design Spec | · 生成设计文档 | 60 | 60 |
| · Design Review | · 设计复审 | 60 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| · Design | · 具体设计 | 60 | 120 |
| · Coding | · 具体编码 | 1200 | 1800 |
| · Code Review | · 代码复审 | 30 | 90 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 90 | 90 |
| Reporting | 报告 | 140 | 140 |
| · Test Repor | · 测试报告 | 60 | 60 |
| · Size Measurement | · 计算工作量 | 20 | 20 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 60 |
| · 合计 | 1970 | 2750 |
学习进度条（13 1分）
| 周数 | 本周学习耗时（小时） | 实际完成任务 |
|---|---|---|
| 1 | 46 | 完成了原型的设计 ,报告，PPT，评审表制作。最终评分，博客撰写 。 |