一、组队后的团队项目的整体计划安排
项目阶段 | 阶段时间 | 主要阶段任务 | 完成情况 |
---|---|---|---|
前期准备 | 9.22-10.11 | 确定选题及成员分工、完成基础学习及前期准备工作 | 已完成 |
10.12-10.18 | 进一步细化分工、设计项目logo、完成选题报告 | 已完成 | |
10.19-10.25 | 通过别组提问改进项目功能计划、完成原型设计及界面设计初稿 | 已完成 | |
团队编程 | 10.26-11.2 | 团队编程及前期准备工作 | 待完成 |
alpha冲刺 | 11.3-11.11 | 实现基础功能、改进界面、完成alpha冲刺前期准备 | 待完成 |
11.12-11.22 | 完成核心功能、准备1.0版本上线 | 待完成 | |
11.23-12.3 | 测试1.0版本、收集用户反馈、明确改进方案 | 待完成 | |
beta冲刺 | 12.4-12.13 | 完善功能、修复bug、完成2.0版本 | 待完成 |
二、团队分工
1.Alpha版本需完成功能
- 本产品主要包含的功能有以下几点(其中功能随着软件迭代升级会有适当 的变化):
- 发起拼单
- 查看已发起拼单
- 智能搜索拼单
- 推荐拼单
- 查看历史拼单记录
- 个人认证
- 填写个人信息
- 举报
2.各成员分工明细及 TODO list
成员 | 分工及任务 | TODO list |
---|---|---|
杨雨丝 | 组长 产品经理 | 了解市场需求 制定开发计划、跟进项目进度 |
林郁昊 | 副组长 后端开发 | 搭建数据库 |
吴之昊 | 后端开发 | 搭建服务器 |
李钒效 | 前端开发 | 设计界面、编辑文档 |
郑木平 | 后端开发 | 实现登录注册功能 |
朱玥轩 | 前端开发 | 撰写博客、评分 |
吴崎 | 后端开发 | 实现查询信息功能 |
张铮 | 后端开发 | 实现搜索、创建拼车单功能 |
于婕 | 前端开发 | 制作视频、作图 |
许钰梅 | 前端开发 | 美化界面、编写文案 |
宋娟 | 产品经理 | 了解用户需求、改进计划 |
每次团队任务细节部分有不同分工 详见本次作业个人贡献比例
3.燃尽图
三、思维导图
四、本次作业个人贡献比例
成员 | 本次作业分工 | 个人贡献比例 |
---|---|---|
杨雨丝 | 组长 | |
林郁昊 | 副组长 | |
吴之昊 | ||
李钒效 | ||
郑木平 | ||
朱玥轩 | 撰写博客、博客排版 | |
吴崎 | ||
张铮 | 博客评分、最终评审表整理 | |
于婕 | 小组长 撰写博客、制作uml图 | |
许钰梅 | ||
宋娟 |
五、评审表格设计
评审表
六、UML
1.用例图
2.类图
绿色部分为客户端:
Join 加入拼车类,里面包含了搜索、加入、显示全部的模块。
Additem 发起拼车类,用于发起新的拼车。
Assess 评分类,封装了用户对其他用户评分的方法。
History 历史信息类,用户查看历史拼车信息。
Login 登录类,用于用户登录和认证。
蓝色部分为服务端:
erver 服务器框架类,提供基础网络服务,封装了掉用其他类的方法。
Query 查询类,用于查询历史拼单和为用户匹配拼单。
Insert 插入类,数据库中加入新的拼单、用户评分信息等。
黄色部分为共有的类:
Info 拼单类,里面包含了拼单的详细信息。
User 用户类,里面包含了用户的个人信息
3.活动图
4.状态图
a)查询
b)登录
c)拼车功能
d)评价
5.实体关系图
6.成员成果汇集
Part1:
1.这里描述的是系统哪部分?
- 用户登录认证
2.面临问题
- 保证页面争取跳转
- 个人信息需准确匹配
3.以下设计解决的问题
- 界面更简洁
- 用户操作方便
- 信息能成功匹配
Part2:
1.这里描述的是系统哪部分?
- 个人信息等查询
2.面临问题
- 如何提升用户体验
- 完善查询功能
3.以下设计解决的问题
- 增加客服对话框
- 为用户提供人工服务
- 可查询历史拼单
- 按键跳转 操作方便简单
- 信息能成功匹配
Part3:
1.这里描述的是系统哪部分?
- 拼车功能模块
2.面临问题
- 拼单功能完善
- 缩短用户等待拼车时间
3.以下设计解决的问题
- 用户可在搜索界面先搜索拼车单,若无合适拼车单则创建新订单,等待过程中可返回继续搜索是否有新的拼车单符合要求
Part4:
1.这里描述的是系统哪部分?
- 评价模块
2.面临问题
- 如何在操作界面简单的情况下尽可能保证用户安全
3.以下设计解决的问题
- 行程结束后用户可自行评价为他人打分,若有遇到问题直接举报,管理人员收到反馈后处理
七、工具选择
- 工具
- Mindmaster
- Staruml
- 选择理由:
- Mindmaster有较好的中文支持,操作方便
- Staruml查到博客上有推荐(重点是可以免费用),上手比较快
八、工具评价
- Mindmaster免费版本功能就比较齐全了,界面看着也很舒服,输出格式也没有限制,总体来说还是很好用的
- Staruml操作是很简单,但是不知道是不是因为我没有下载免费版本还没有掏钱的缘故,导出的图片有水印啊啊啊啊啊OTZ崩溃,还得请出ps,费神费心(哭)
九、答辩总结
1.本组的现场答辩得分:
2.回答其他小组对本小组的提问
第一小组:
未提问
第二小组:还是挺不错的,因为是联系滴滴使用的,所以建议多突出一些便利功能来吸引用户
后续会根据用户需要增加一键跳转,屏蔽广告,一键报警等功能
第三小组:
本组为第三小组,未提问
第四小组:
未提问
第五小组:
未提问
第六小组:既然可以链接滴滴为什么不直接用呢?
因为滴滴司机接拼单或者顺风车订单时对每人个人的定价可能都不一样,花费相对高一些,而且会有因为乘客起始地和目的地距离过长而绕路的情况下,我们的小程序是针对想要避免这一系列问题的用户推出的。
第七小组:如何增加用户基数达到快速拼车的效果?
首先是线上线下的推广要做好,再者我们可以在节假日的时候再各个QQ群和公交站等出行人群较多的地方展开免费试用活动,尽可能让用户了解我们的小程序。
第八小组:建议是去明确更多用户的需求,让产品更加的完善,可以让更多人去使用你们的产品
谢谢第八小组的建议,后续如果有需要,我们会再进行用户需求更加具体化的调查,并根据调查来调整我们的产品状况,也会进行推广,让更多的人来使用我们的产品。
第九小组:如何能够在老牌拼车软件中脱颖而出?在没有客源的情况下如何维持APP运行?
目前的老牌拼车软件中,容易遇到司机需要到去到不同的地方去接人的情况,从而导致时间上的浪费,而且价格也比单人乘坐出租车少了一半左右。而“拼拼”是用户的起始位置和目的地一致,共乘一辆车,从而达到时间和金钱上的最大节约。在没有客源的情况下,由小组内部出资维持APP运行,也相信由推广人员进一步的推广后,会有一定的用户进行使用。
第十小组:
未提问
第十一小组:功能可以扩展一下
后期我们会根据需要和用户调查来增加一些功能,如:定位,屏蔽广告,查看拼车同伙信用分等。
第十二小组:是否考虑对接更多平台?
我们是根据问卷调查看到大部分人愿意使用滴滴打车,所以我们一键跳转以滴滴打车为例。我们产品是以拼车交流为主,用户在我们平台上进行拼车后,再自行到需要的打车软件去打车,所以我们可以对接比较多的平台。
3.根据答辩中其他组提出的意见和建议修改完善本组需求分析报告,并标明修改之处
- 提出的建议和意见
- 有些排版问题
- 报告中缩进不恰当
- “基于更高版本的api进行开发”,表述错误。
- 修改之处
- 更改了排版
- 更改了缩进
- 删除了错误的语句
十、修改后的需求分析报告(最终版)
需求分析报告(最终版)
十一、遇到的困难及解决办法
- 困难描述
- 如何对用户的信息进行保密
- 大家缺乏项目开发的经验
- 对实现大部分列举的功能所需的算法有一定的理解,但是技术方面有所欠缺
- 做过哪些尝试
- 数据库对普通用户的访问进行权限设置,以防止信息泄露,也会采用记录生成日志文件,定期备份。
- 借鉴有丰富经验的前辈和搜索引擎
- 不断地学习新的技术
- 是否解决
- 已解决
- 有何收获
- 在开发项目的过程中,大家的时间精力都不相同,但是大家不断地去磨合,互相学习互相借鉴,就会有更好的学习成果。并且在别的小组的建议下,我们会不断的去完善我们的产品,使得它变得更加方便可用。
十二、PSP
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟 | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 30 | 24 |
Estimate | 估计这个任务需要多少时间 | 30 | 24 |
Development | 开发 | 1510 | 1730 |
Analysis | 需求分析 (包括学习新技术) | 600 | 780 |
Design Spec | 生成设计文档 | 30 | 20 |
Design Review | 设计复审 | 30 | 10 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
Design | 具体设计 | 60 | 40 |
Coding | 具体编码 | 360 | 300 |
Code Review | 代码复审 | 60 | 90 |
Test | 测试(自我测试,修改代码,提交修改) | 360 | 480 |
Reporting | 报告 | 90 | 90 |
Test Repor | 测试报告 | 30 | 30 |
Size Measurement | 计算工作量 | 30 | 30 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
totall | 合计 | 1630 | 1844 |
十三、学习进度条
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
1 | 600 | 600 | 6 | 6 | |
2 | 800 | 1400 | 5 | 11 |
原文地址:https://www.cnblogs.com/wu-js/p/11749370.html