| 姓名 | 学号 |
|---|---|
| 杨雨丝（组长） | 031702102 |
| 林郁昊（副组长） | 081700209 |
| 郑木平 | 111700233 |
| 于婕 | 031602342 |
| 许钰梅 | 031702503 |
| 张铮 | 031702123 |
| 朱玥轩 | 031602347 |
| 宋娟 | 181700134 |
| 李钒效 | 031702245 |
| 吴崎 | 031702144 |
| 吴之昊 | 111700632 |
| 角色 | 姓名 | 具体任务 | 最终得分 |
| 组长、产品经理 | 杨雨丝 | 主讲人 UI | 9% |
| 副组长、开发人员 | 林郁昊 | 前端设计、部分后端 | 34% |
| 组员、开发人员 | 吴之昊 | PPT | 10% |
| 组员、开发人员 | 郑木平 | 后端设计 | 13% |
| 组员、产品经理 | 宋娟 | 提问 | 2% |
| 组员、宣讲人员 | 李钒效 | UI | 6% |
| 组员、后勤人员 | 朱玥轩 | 评分评论 | 4% |
| 组员、后勤人员 | 吴崎 | 评论以及评分 | 4% |
| 组员、后勤人员 | 于婕 | 撰写博客 | 10% |
| 组员、后勤人员 | 张铮 | 评论以及评分 | 4% |
| 组员、后勤人员 | 许钰梅 | 评分及评论 | 4% |
| 合计 | 100% |
- 原计划是要将产品上架，筛选拼友及用户的信用评分、投诉机制要完善
- 实际上产品已经提交申请，但还未通过；筛选拼友仅能一些基本信息筛选，还不能看到用户的信用评分；评分和投诉机制还不够完善，用户无法投诉或评价其他用户。
- 未能成功上架的原因还在分析中，基本功能模块都已完成，主要是现阶段准备的考试科目很多，没法花太多时间在软工项目上，而且组内的技术担当比较少，整体的编程能力比较弱，所以分工有点不平衡，最后导致一些bug没能修复成功、部分功能没能实现。
本组产品为微信小程序，用微信扫码即可进入
- 第一组：除了拼车以外还有什么原创功能吗
- 答：目前还没有，主要功能就是拼车。
- 第二组：拼车成功后是否有取消机制，如用户临时有事等，是否会有信用惩罚机制？
- 答：会的，有限次内可以免费取消，如果多次取消应该会降低信用值。
- 第四组：学生认证存在漏洞
- 答：确实学生认证功能还未能完善，后端负责人员会持续修复和完善，谢谢提醒。
- 第五组：之后打算怎么推广获得第一批用户？
- 答：主要是线上推广，在空间朋友圈贴吧等社交空间推广介绍，线下可以在节假日前后申请场地，现场准备小礼品之类的，邀请用户使用。
- 第六组：拼车如何保证安全
- 答：有信用反馈机制，通过筛选拼友用户可以看到其他用户的信用分，后续也会推出功能，让用户可以联系客服人员等。
- 第七组：是否有考虑增加一键报警功能
- 答：有考虑，正在设计实现当中。
- 第八组：这类应用软件最受用户关注的是安全问题，想问一下目前你们是否保证了安全或者说有做一些趋向安全化的措施了，这方面在PPT中没有体现。
- 答：信用评分和投诉机制还没能完全实现，正在改善当中，之后也会考虑增加一键报警的功能来保证用户的安全性。
- 第九组：手动输入地址可以改善成自动弹出地址吗？以及你们的数据筛选的标准和地址有什么关系吗？
- 答：之前没有考虑过改成自动弹出，如果之后有需要的话可能会改，筛选是根据目的地进行的，目前设计是目的地附近五百米之内的拼单。
- 第十组：上车地点手动输入是否会出现歧义
- 答：目前还没有发现有这个问题。
- 第十一组：完成度目前看起来稍慢了一点，希望能加快一下进度
- 答：感谢提醒，beta版本有很多未能完善的地方，在后续的工作中我们会加快进度，不断的进行完善。
- 第十二组：是否考虑用户的优先级排序？比如利用用户过往行为
- 答：信用值高的用户创建的拼单应该会优先推荐，利用用户过往行为进行优先排序，这个暂时还没有考虑，之后有可能的话我们会尽量实现。
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 15 |
| Development | 开发 | 200 | 250 |
| · Analysis | · 需求分析 (包括学习新技术) | 300 | 400 |
| · Design Spec | · 生成设计文档 | 50 | 50 |
| · Design Review | · 设计复审 | 20 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 60 | 80 |
| · Design | · 具体设计 | 100 | 150 |
| · Coding | · 具体编码 | 500 | 560 |
| · Code Review | · 代码复审 | 30 | 35 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 100 | 120 |
| Reporting | 报告 | 100 | 100 |
| · Test Repor | · 测试报告 | 30 | 30 |
| · Size Measurement | · 计算工作量 | 15 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 50 |
| 第N周 | 新增代码(行） | 累计代码(行) | 本周学习耗时(小时） | 累计学习耗时(小时) |
|---|---|---|---|---|
| 1 | 50 | 50 | 2 | 2 |
| 2 | 20 | 70 | 1 | 1 |
| 3 | 5 | 75 | 1 | 1 |
| 4 | 5 | 80 | 1 | 1 |
| 5 | 0 | 80 | 0 | 0 |
| 6 | ||||
| 7 | ||||
| 8（待续） |
原文：https://www.cnblogs.com/wu-js/p/12041118.html