第05组 团队项目-需求分析报告

组长本次做业博客连接

组队后的团队项目的总体计划安排（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分）

本组现场答辩得分

得分详情：第一组给分56.4分，第二组给分52.8分，第三组给分52分，第四组给分53.4分，第五组给分54分，第六组给分53.4分，第七组给分54分，第八组给分49.2分，第九组给分53.4分，第十组给分49.8分，第十一组给分47.4分，第十二组给分48分
去除一个最高分：56.4分 去除一个最低分：47.4分
取平均分：52分

针对其余小组提问回答

第一组提问：对于紫荆一楼这种菜品不固定的档口，有没有考虑增长显示菜品的功能，有没有考虑过若是在食堂排队的同窗会由于配送员点好几份等待太久而发生纠纷?

因为咱们平台如今不是定位为为食堂进行销售，而是经过点单方自行决定吃什么东西，因此暂时没有考虑过引进菜品。当这个小程序后期成熟后，会考虑加进去。配送员应该是避开高峰排队时间的，咱们的小程序目的也是错峰购买，因此这个问题产生的概率应该不大。

第二组提问：我以为挺不错的，就是好像跟咱们的项目有些撞车了，建议多增长些额外小功能来吸引用户和凸显本身的卖点。

谢谢建议！咱们如今主推的是食堂带饭的这一功能，在把这一功能尽善尽美以后咱们也会加入代购超市奶茶店，代取快递，文印店打印等功能

第三组提问：各大外卖平台上的店家均可以显示哪些套餐、菜品已售罄，可是对于学校的食堂来讲，可能会出现配送员点菜的时候某些菜品已售罄，如何解决这一问题?

咱们鼓励在食堂的人来当配送员，因此他们对食堂的菜品是否销售通常可以及时掌握，若是没法知足点单人的要求，能够联系取消订单或者更换菜品。

第四组提问：无

有问必答，无问不答。

第五组提问：咦咱们不就是第五组吗?

对的咱们就是第五组。

第六组提问：发布配送能否有时间范围约束？

在发布订单的时候就能够设置配送时间约束

第七组提问：食品产生问题时平台如何界定责任？

首先在注册的时候用户须要签定协议，在发生食品问题的时候告知平台，平台会出面联系配送员和商家，并积极协助调查，具体的责任认定要在了解责任源头以后协商。

第八组提问：如何解决因一我的接单太多，而致使食品的新鲜度很差，从而致使用户对使用软件的意愿下降的问题？

咱们会限制配送的同窗在一个时间段内的接单数量，好比在一个小时内最多只能接5单。

第九组提问：食堂食物的标价是该应用后台更新吗？怎么样保证及时快速更新？若是食堂有打包费这样的额外要求是用户私下交易仍是平台来监管？

因为食堂饭菜的价格及物价的波动无常以及本产品的适用人群是经过校园认证的学生，本平台只提供点单方和配送方提供食堂菜品、配送价格等信息的公布，所涉及的金钱只包括配送价格。具体饭菜的价格（包含打包费）以支付宝、微信、一卡通等的消费记录凭证为基础进行支付。在信用机制和身份认证机制下，服务方与被服务方的交易是私下进行的。

第十组提问：是否考虑过以可视化地图的形式向用户展现配送员的配送状况？

现阶段暂时没有考虑以可视化的形式展现配送员的送餐状况，缘由以下：校内食堂离宿舍距离近，一旦接单成功配送时间会很短。但这会是咱们平台能够争取的方向，若是条件容许，咱们可能会在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分）

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	0	0	0	0	0
2	0	0	0	0	0
3	0	0	0	0	0