组长博客链接
1、整体计划安排
| 阶段序列 | 阶段时间 | 主要阶段任务 | 完成情况 |
| 第一阶段 | 9.18 | 团队成立 | 已完成 |
| 第二阶段 | 9.18-9.25 | 确定选题及协商分工 | 已完成 |
| 第三阶段 | 9.25-10.14 | 前期学习及准备 | 已完成 |
| 第四阶段 | 10.14-10.20 | 选题报告 | 已完成 |
| 第五阶段 | 10.20-10.27 | 需求分析报告 | 已完成 |
| 第六阶段 | 10.27-11.9 | 完成用户登录模块 | 待完成 |
| 第七阶段 | 11.9-11.23 | 完成用户车辆登记板块 | 待完成 |
| 第八阶段 | 11.23-11.30 | 完成用户留言板块 | 待完成 |
| 第九阶段 | 12.1-12.10 | 完成动态板块 | 待完成 |
| 第十阶段 | 12.10-12.18 | 完成灰度测试 | 待完成 |
| 第十一阶段 | 12.19-12.27 | 团队工作量整理，公测 | 待完成 |
| 第十二阶段 | 12.28 | 团建 | 待完成 |
2、团队分工
确定 alpha 版本需要做哪些事情
| 状态 | 分工内容 | 截止时间 | 负责人 |
| 进行中 | 注册界面 | 11月09日 | 石晓楠 |
| 进行中 | 登录界面 | 11月09日 | 陈启昌 |
| 未开始 | 车辆登记模块 | 11月23日 | 刘晓翔 |
| 未开始 | 用户留言模块 | 11月30日 | 王焱 |
| 未开始 | 动态板块 | 12月10日 | 杨晋南 |
| 未开始 | 其他界面设计 | 12月10日 | 宋奕 |
各成员分工明细及 TODO list
| 成员姓名 | 分工 | to do list |
| 宋奕 | 项目经理、后端工程师 | 1.负责成员分工及组织会议，推动项目进程 。2.负责后端接口及逻辑功能的实现，服务器的部署及数据库的构造 |
| 林少惠 | UI设计师、团队资源管理师 | 1.负责项目原型的逻辑功能设计，app的UI设计。2.负责设计及撰写文档，拍摄记录团队进程，沟通前后端 |
| 杨蓝婷 | UI设计师、团队资源管理师 | 1.负责项目原型的逻辑功能设计，app的UI设计,2.负责设计及撰写文档，拍摄记录团队进程，沟通前后端 |
| 张雨 | UI设计师、团队资源管理师 | 1.负责项目原型的逻辑功能设计，app的UI设计,2.负责设计及撰写文档，拍摄记录团队进程，沟通前后端 |
| 陈启昌 | 前端工程师 | 负责web端界面的功能实现，及前后端交互 |
| 石晓楠 | 前端工程师 | 负责web端界面的功能实现，及前后端交互 |
| 陈靖雯 | 前端工程师 | 负责web端界面的功能实现，及前后端交互 |
| 杨晋南 | 移动端工程师 | 负责安卓端及iOS端的接口交互，和页面的实现 |
| 刘晓翔 | 移动端工程师 | 负责安卓端及iOS端的接口交互，和页面的实现 |
| 王焱 | 移动端工程师 | 负责安卓端及iOS端的接口交互，和页面的实现 |
| 刘华一 | 算法工程师 | 负责算法学习、设计及开发 |
燃尽图
3、思维导图
4、评估贡献比例
撰写需求规格说明书的工作流程
- 项目经理确定需求规格说明书的内容
- 小组开会确定app界面的各个模块和功能。
- 一部分人先完成说明书的文字部分和原型、UML图等。
另一部分人最后完成PPT制作、PPT演讲准备、整合需求说明书内容。
组员分工
任务内容 分工情况及分数 需求报告文字描述部分 晓楠6、张雨2 思维导图 晓楠2 类图 宋奕2 ER图 晋南2 数据字典 晋南4 外部需求 宋奕4 状态图、活动图 张雨4 验收验证标准 张雨2 整合报告内容、排版 晓楠2、靖雯4 原型设计 少惠15、靖雯5、晓楠3 PPT制作 蓝婷15 PPT演讲 启昌6 评审表设计 靖雯1 评审表汇总、录入 张雨2 填写评审表和提问 宋奕2、启昌2、晋南2、晓翔2、王焱2、华一2、蓝婷2、少惠2、张雨2、晓楠2、靖雯2 博客撰写 张雨4 开会 宋奕2、启昌2、晋南2、晓翔2、王焱2、蓝婷2、少惠2、张雨2、晓楠2、靖雯2 分工、计算贡献率、提交材料 靖雯3 组员工作量比例
姓名 贡献率 宋奕 10/130=8% 启昌 10/130=8% 晋南 10/130=8% 晓翔 4/130=3% 王焱 4/130=3% 华一 2/130=2% 蓝婷 19/130=15% 少惠 19/130=15% 张雨 18/130=14% 晓楠 16/130=12% 靖雯 16/130=12% 5、评审表格设计
6、UML
必做图
用例图
描述的部分：
（1）描述了我们软件必须完成的任务，定义了必须完成的软件功能；
（2）基本呈现用户与用例之间的具体关系；
（3）基本表达系统的基本功能；
（4）基本表达系统的具体行为。
面临的问题：
（1）如何具体对用例进行分类，使得用例更加具体；
（2）如何对用户与不同用例之间的关系详细分析。
解决的问题：
（1）初步获取用户的需求；
（2）指导测试；
（3）在整个过程中对其他工作流起到指导作用。
类图
活动图
描述的部分：
(1)动态生成过程。
(2)联系车主过程。
面临的问题：
（1）面临账户管理问题。
（2）面临联系车主问题。如何使用户较为快速的联系到对应的车主。
解决的问题：
使用户可以查询到车主，方便快捷的解决难题。
状态图
【part1】
描述的部分：描述了用户登录及未登录使用的状态。
面临的问题：面临用户账号管理的问题。
解决的问题：
（1）解决了用户注册登录流程的问题。
（2）解决了用户找回密码的问题。
【part2】
描述的部分：描述了用户寻找车主的状态。
面临的问题：面临扫描识别及车牌识别的问题。
解决的问题：
（1）解决了用户通过扫描车身进行识别的问题。
（2）解决了用户通过输入车牌号进行识别的问题。
（3）解决了用户通过本平台寻找车主的问题。
【part3】
描述的部分：描述了用户动态编辑、展示及评论的状态。
面临的问题：面临用户添加自定义动态及其显示、评论的问题。
解决的问题：
（1）解决了用户自定义创建动态、显示动态的问题。
（2）解决了用户评论他人动态的问题。
实体关系图
其他图
成员成果汇集
part1
（1）这里描述的是系统的登录部分
（2）这里面临的是实名认证的问题
（3）我们通过添加数据库的学生表来解决了这个问题
这个表记录了从1998-2019的学生身份数据。part2
（1）这里描述的是系统的车牌绑定部分
（2）这里面临的是套牌车的问题
（3）我们通过多拍几张照片或者选取特点来解决了这个问题这边增加了两个表
7、工具选择
ProcessOn在线作图工具
8、对工具的评价
ProcessOn是一个在线作图工具的聚合平台，它可以在线画流程图、思维导图、UI原型图、UML、网络拓扑图、组织结构图等等，高效易用，而且支持团队协作，可多人同时制作。
9、答辩总结
本组的现场答辩得分 去除最高总分，最低总分，求平均分（保留2位小数）
团队组别 第01组 第02组 第03组 第04组 第05组 第06组 第07组 第08组 第09组 第10组 第11组 第12组 本组最终得分 他组队本组的评分 89 87 79.9 88 86 90 86 85 84 85 81 77 85.09
回答其他小组对本小组的提问
| 团队组别 | 提出的问题 | 回答 |
| 第01组 | 车牌识别提取号码的功能打算怎么实现？自己写算法还是直接用别人的轮子？ | 用别人的轮子 |
| 第02组 | Q1：如何说服用户将自己的车牌信息录入？Q2：以及别人随意查看车主信息似乎有些不合理？Q3：且替人挪车的收益感觉不是那么大，时效性也不高，受众和使用频率也不会很高 | A1：这就靠我们的前期宣传，如果可能的话，我们会尝试与学校合作，加大用户量；A2：车主的信息是可以自行选择是否进行完全公开的，类似电话号码，如果车主不想透露，可以通过平台进行联系；A3:我们会设立奖励机制，如果你正好在求助的用户附近，通过帮他挪车是乐于助人的同时又可以赚的积分，和乐而不为呢 |
| 第03组 | 产品如何盈利，如何鼓励不是车主的其他用户帮忙挪车？ | 通过发放优惠券和别的商家或者小组合作 |
| 第04组 | 未提问... | |
| 第05组 | 初期用户量不足的情况下，你们的项目等于没有挪车功能，一个没有功能的应用就算客户使用了，怎么保证它在你们功能成熟前不删了它呢？ | 我们的app主要功能是挪车，但是不止这一个功能哦，还可以在平台上发布你的买卖车信息以及如果您不小心将别人车的某些部分弄坏掉可以进行留言之类的哦 |
| 第07组 | 多次发出挪车消息无人应答，导致用户体验感很差，如何避免？ | 这个在项目初期是不可能避免的，但是中后期用户总量增加，应该可以缓解 |
| 第08组 | 建议是如果挪的不是自己的车而使用这个软件来帮别人挪车或者通过其它方式，可以收取适当的费用，来增加产品的盈利性 | 这个建议我们会纳入考虑的，谢谢 |
| 第09组 | 能查看他人那么多信息，信息安全如何保障？ | 我们严格控制每条信息得保密，只要设置是保密，他人就看不见的 |
| 第10组 | 未提问... | |
| 第11组 | 获取用户手机号和车牌如何实现，真的会愿意自己填上这些私密信息吗，如果从其他渠道获取，是不是有侵犯个人隐私的问题？ | 手机号是可以有隐藏的选项的，如果您不愿意将自己的手机号公布出来，可以隐藏起来 |
| 第12组 | Q1:电话加密如何实现？Q2:基于网络电话还是传统电路域电话？Q3:电路域电话存在一段传输无法加密，网络电话如何保证用户能接到 | A1: 电话加密是基于阿里云的功能；A2:基于网络电话；A3:阿里云对用户功能应该是有所保障 |
根据答辩中其他组提出的意见和建议修改完善本组需求分析报告，并标明修改之处
针对永福所说的缩进问题，有做修改
对于token类型的改进
10、需求说明书
11、遇到的困难及解决方法
困难描述
对《软件需求规格说明书》较为陌生，不知从何入手
做过哪些尝试
我们认真阅读了作业中给出的 checklist，然后请教了之前的学长学姐。并阅读了一些前辈的报告，最终确定出框架，然后开始分工撰写。
是否解决
是
有何收获
了解了《软件需求规格说明书》的框架和内容，明白了团队协作的重要性，并体会到其中的乐趣。
12、psp
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 60 | 100 |
| Estimate | 估计这个任务需要多少时间 | 10 | 5 |
| Development | 开发 | 150 | 180 |
| Analysis | 需求分析 (包括学习新技术) | 180 | 200 |
| Design Spec | 生成设计文档 | 300 | 300 |
| Design Review | 设计复审 | 30 | 60 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| Design | 具体设计 | 180 | 150 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 120 | 100 |
| Test Repor | 测试报告 | 0 | 0 |
| Size Measurement | 计算工作量 | 5 | 5 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 60 | 60 |
| 合计 | 1095 | 1160 |
13、学习进度条
| 第N周 | 新增代码（行） | 累积代码（行） | 本周学习耗时（小时） | 累积学习耗时（小时） | 重要成长 |
| 1 | 0 | 0 | 10 | 10 | 做前期准备工作 |
| 2 | 0 | 0 | 12 | 22 | 撰写选题报告 |
| 3 | 0 | 0 | 13 | 35 | 撰写需求报告 |