第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/slyn0422/p/11749380.html