组队后的团队项目的整体计划安排（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分）
| 姓名 | 主要工作 | 贡献比例 | ||||||||||
| 方瑞雄 | 评审表设计，博客撰写，最终评审表整理 | |||||||||||
| 严欣 | 报告中验收验证标准的编写 | |||||||||||
| 陈苏苏 | 报告中验收验证标准的编写，报告细节更改 | |||||||||||
| 翁世豪 | 报告中功能描述的编写，思维导图设计 | |||||||||||
| 潘海东 | 报告中功能描述的审核 | |||||||||||
| 刘诗琳 | 原型图设计，记录课堂提问问题 | |||||||||||
| 郑裕恒 | PPT制作，文档中交互原型设计，PPT演讲人员，图片修整与美化 | |||||||||||
| 王玥 | 报告中验收验证标准的编写，原型设计，logo设计与解读 | |||||||||||
| 张万聪 | 原型图设计，博客撰写 | |||||||||||
| 余廷龙 | 对报告的排版与整理，UML图设计，报告引言撰写 | |||||||||||
| 马丽华 | 报告中验收验证标准的编写 |
评审表设计（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分）
本组现场答辩得分
针对其他小组提问回答
提供《需求规格说明书》作为随笔的附件（经过修改的最终版本）（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，评审表制作。最终评分，博客撰写 。 |