第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分）
|
|
|
|
|
|
|
|
|
|
|
|
|
| 姓名 |
主要工作 |
贡献比例 |
|
|
|
|
|
|
|
|
|
|
| 方瑞雄 |
评审表设计，博客撰写，最终评审表整理 |
|
|
|
|
|
|
|
|
|
|
|
| 严欣 |
报告中验收验证标准的编写 |
|
|
|
|
|
|
|
|
|
|
|
| 陈苏苏 |
报告中验收验证标准的编写，报告细节更改 |
|
|
|
|
|
|
|
|
|
|
|
| 翁世豪 |
报告中功能描述的编写，思维导图设计 |
|
|
|
|
|
|
|
|
|
|
|
| 潘海东 |
报告中功能描述的审核 |
|
|
|
|
|
|
|
|
|
|
|
| 刘诗琳 |
原型图设计，记录课堂提问问题 |
|
|
|
|
|
|
|
|
|
|
|
| 郑裕恒 |
PPT制作，文档中交互原型设计，PPT演讲人员，图片修整与美化 |
|
|
|
|
|
|
|
|
|
|
|
| 王玥 |
报告中验收验证标准的编写，原型设计，logo设计与解读 |
|
|
|
|
|
|
|
|
|
|
|
| 张万聪 |
原型图设计，博客撰写 |
|
|
|
|
|
|
|
|
|
|
|
| 余廷龙 |
对报告的排版与整理，UML图设计，报告引言撰写 |
|
|
|
|
|
|
|
|
|
|
|
| 马丽华 |
报告中验收验证标准的编写 |
|
|
|
|
|
|
|
|
|
|
|
评审表设计（5 1分）
UML（6 10分）
- 由于我们产品功能不多没办法拆分得那么细，所以每个图整合后只做一份（很用心做的，此条已征得助教的同意）
用例图
- 描述的部分：
- 面临的问题：
- 不同用户双方可能会对订单产生争议
- 订单无法第一时间更新
- 解决了哪些问题：
- 下单用户与配送用户对订单的操作有主动权，并且实现对订单的可视化
类图
- 描述的部分
- 用户的个人信息和用户对订单的操作
- 广场订单的表现形式
- 订单本身的状态以及订单衍生出的信息交互
- 面临的问题
- 用户信息可能不够全面，导致无法准确得到用户信息
- 订单的处理问题
- 解决了哪些问题
- 使用评论与点评功能解决了用户之间的交互
- 使用标签让订单更具体，让用户更方便
活动图
状态图
- 描述的部分
- 面临的问题
- 解决了哪些问题
- 解决了用户之间对订单的评论
- 解决了用户订单发布错误重新下单的功能
实体关系图
- 描述的部分
- 面临的问题
- 用户信息未能如实呈现
- 订单与用户间的匹配不够完善
- 评论无法完全解决用户与订单间的矛盾
- 解决了哪些问题
- 订单与用户关系之间的可视化
- 评论与订单之间的平衡
- 用户对评论的操作可执行
工具选择（7 2分）
UML图设计的工具
- 我选择的是starUML，因为这学期选修了《面向对象分析与设计》，老师要求我们自学UML，并且需要在课程设计里使用UML做软件建模，然后他就推荐给我们这一款软件，因为比较容易上手。
实体联系图是用亿图图示做的，因为starUML没法做实体联系图，所以就百度了一个软件。（廷龙提供）
原型图设计的工具
对工具的评价（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，评审表制作。最终评分，博客撰写 。 |
原文地址：https://www.cnblogs.com/xgsw/p/11749254.html