组队后的团队项目的整体计划安排
| 时间 | 计划 |
|---|---|
| 9.26-10.19 | 选题报告及答辩 |
| 10.20-10.26 | 需求分析报告及答辩 |
| 10.28-10.29 | 接口设计 |
| 10.30-11.3 | 总体框架搭建 |
| 11.4-11.22 | Alpha |
| 11.23-12.13 | Beta |
| 12.14-？ | 完善 |
详见下节的Todo List
团队分工
Alpha Goal
后端
- 用户认证模块完整
- 点记录和分享模块实现
- 轨迹记录和分享模块实现
- 社交模块完整实现
- 平台集成和社会化分享能做多少算多少
App端
- 用户认证模块完整
- 点记录和分享模块实现
- 轨迹记录和分享模块实现
- 社交模块基本实现
- 平台集成和社会化分享能做多少算多少
成员分工明细
| 成员 | 分工 |
|---|---|
| 王永福 | 派任务、催进度、后端、App |
| 孙承恺 | 算法设计和实现、App实现 |
| 邱畅杰 | 社会化分享模块 |
| 丁枢桐 | 社会化分享模块、算法设计和实现 |
| 张凌昕 | App、公共事务 |
| 余琳玲 | App、文案 |
| 林青霞 | App |
| 林星培 | App |
| 徐祖豪 | App |
其中App部分的细分见Todo，采用动态分配的认领制度
Todo
燃尽图
思维导图
本次团队分工
流程
工作量评估
| 成员 | 工作量 |
|---|---|
| 张凌昕 | 5% |
| 孙承恺 | 12% |
| 邱畅杰 | 8% |
| 林星培 | 10% |
| 余琳玲 | 14% |
| 林青霞 | 10% |
| 王永福 | 23% |
| 徐祖豪 | 5% |
| 丁枢桐 | 13% |
具体理由可见前节的流程图
评审表
UML
成员成果汇集
Part 1 类图
- 这里描述的是系统哪部分？
- 描述了系统各部分数据的关系
- 这部分要面临什么样的问题 ？
- 各部分关联和划分
- 以下设计解决了哪些问题
- 解决了开发者对于各个类体之间关系的宏观认识
Part 2 用例图
- 这里描述的是系统哪部分？
- 用户与系统的交互用例
- 这部分要面临什么样的问题 ？
- 哪些用户能干什么
- 以下设计解决了哪些问题
- 明晰了用户类型及操作
Part 3 认证状态图
- 这里描述的是系统哪部分？
- 用户与系统认证的状态
- 这部分要面临什么样的问题 ？
- 面临账号的登入注册的设计逻辑的问题
- 以下设计解决了哪些问题
- 解决了在设计登入注册找回密码这几个方面的逻辑顺序
Part 4 点分享状态图
- 这里描述的是系统哪部分？
- 点分享的状态
- 这部分要面临什么样的问题 ？
- 面临发布和浏览点分享的设计逻辑的问题
- 以下设计解决了哪些问题
- 解决了发布和浏览点分享的状态转换问题
Part 5 轨迹状态图
- 这里描述的是系统哪部分？
- 轨迹的状态
- 这部分要面临什么样的问题 ？
- 面临记录编辑轨迹的设计逻辑的问题
- 以下设计解决了哪些问题
- 解决了记录编辑轨迹的状态转换问题
Part 6 活动图
- 这里描述的是系统哪部分？
- 用户使用系统的流程
- 这部分要面临什么样的问题 ？
- 用户可能不清楚系统的操作逻辑
- 以下设计解决了哪些问题
- 明晰了用户的操作顺序和操作预期结果
Part 7 实体关系图
- 这里描述的是系统哪部分？
- 系统间各实体的关系
- 这部分要面临什么样的问题 ？
- 各实体间如何组织
- 以下设计解决了哪些问题
- 明确了各个实体的属性及其间的关系
Part 8 部署图
- 这里描述的是系统哪部分？
- 系统部署架构
- 这部分要面临什么样的问题 ？
- 系统如何部署
- 以下设计解决了哪些问题
- 明确了系统部署是各个组件的节点分配
关于工具
主要使用了几个工具：Visio、Process On、Visual Paradigm、StarUML
- Visio: 强大，不管对于初学者还是有高级要求的人员都适用
- Process On: 简单易上手，对初学者友好，但高级功能欠缺，且不能导出到能在其他软件编辑的通用格式，偶有小Bug
- Visual Paradigm: 非常高级的工具，学习曲线陡峭，难以掌握
- StarUML: 专门画UML的，易用，强大，但比较卡，且难以破解
答辩总结
得分
| 组号 | 分数 |
|---|---|
| 1 | |
| 2 | 54.6 |
| 3 | 51.3 |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | 47.4 |
| 9 | 50.4 |
| 10 | |
| 11 | |
| 12 | 49.2 |
| 平均分 | 50.3 |
截至本博客撰写时(2019-10-27T17:30)，空白为未评分的小组
Q&A
1
- Q: 请问你们对帖子的内容有限制或审核吗？如何规避大家都不分享轨迹而发布一些与软件无关的内容？
- A: 后期上线时我们可以引入简单的关键词审查机制或引入第三方内容过滤服务提供商缓解这个问题
2
- Q: 创意还是很不错的，希望将重点放在吸引用户量上，或者将分享内容与其他社交平台联动获取更大的关注度
- A: 谢谢您的建议，我们会认证考虑的
3
- Q: 对那些积极分享或是分享内容优秀的用户会不会有适当的奖励机制？
- A: 我们在上线后可以考虑赠送增值服务等方式来奖励，或推出原创激励计划
4
截至本博客撰写时(2019-10-27T17:30)，尚未提问
5
截至本博客撰写时(2019-10-27T17:30)，尚未提问
6
- Q: 记录轨迹的时候是否可以停止一段时间后，再继续上一次的记录？
- A: 我们会考虑加入此功能，如果时间允许
7
- Q: 为什么在这次作业中把使用cordova改成了Android
- A: 我们在前期调研趟坑中发现了Cordova的地图存在较为严重的性能问题
8
- Q: 对用户的需求场景还可以进行多一些的调查，请问如何去审核一些不文明的分享动态？
- A: 谢谢您的建议。后期上线时我们可以引入简单的关键词审查机制或引入第三方内容过滤服务提供商缓解这个问题
9
- Q: 创意挺好的，想请问该软件的可移植性考虑是？
- A: 目前计划使用原生Android开发，暂无其他平台计划
10
- Q: 请问你们靠什么吸引用户在一众同类app中选择使用你们的app呢？
- A: 我们的App目前来说更轻量，不过于商业化，且有在轨迹上进行标记的功能和基于位置的社交功能，相信可以吸引用户
11
- Q: 没有安卓基础或许用小程序上手快一点？
- A: 确实如此。但是小程序对设备能力的调用限制较多，且网页应用有性能问题
需求分析报告
其中有修订记录
另外根据柯老板的建议修改了字体大小
别看了
遇到的困难及解决方法
困难描述
本次作业要求完成一份需求分析报告，组内同学都没有相关经验
做过哪些尝试
根据作业要求和Checklist, 网上找了几份模板，嫖了一下往届学长学姐的报告，最后形成了一份框架，然后根据框架分配任务，完成报告。
是否解决
是
有何收获
了解了一份完整的需求分析报告应该包括哪些内容。以及需求分析报告的目标人群是谁，文字应该如何组织才能够达到写这份报告的目的。对于规范文本的格式也有了更多了解。
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 120 | 80 |
| Estimate | 估计这个任务需要多少时间 | 120 | 80 |
| Development | 开发 | 0 | 0 |
| Analysis | 需求分析(包括学习新技术) | 0 | 0 |
| Design Spec | 生成设计文档 | 0 | 0 |
| Design Review | 设计复审 | 0 | 0 |
| Coding Standard | 代码规范(为开发制定合适的规范) | 0 | 0 |
| Design | 具体设计 | 0 | 0 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试(自我测试,修改,提交修改) | 0 | 0 |
| Reporting | 报告 | 50 | 40 |
| Test Report | 测试报告 | 0 | 0 |
| Size Measurement | 计算工作量 | 10 | 10 |
| Postmortem & Process Improvement Plan | 事后总结并提出过程改进计划 | 40 | 30 |
| 合计 | 160 | 110 |
学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 407 | 407 | 15 | 15 | 学到了十三水的玩法，了解了原型设计工具的使用方法 |
| 2 | 230 | 637 | 14 | 29 | 制定了基本实现思想和前端窗体框架 |
| 3 | 1200 | 1837 | 20 | 49 | 实现基本交互逻辑 |
| 4 | 1045 | 2882 | 20 | 69 | 实现接口对接和后端处理 |
| 5 | 0 | 2882 | 5 | 74 | 对原型设计更加熟练以及学习了uml图的绘制 |