第01组 Beta版本演示
组长博客
1.1 本组成员
林睿（组长） 031702504
蔡雅菁 031702501
吴洁敏 031702502
邓泽源 031702147
姚彬锟 031702419
张庆焰 031702420
朱宏 031702422
周鑫煌 031702525
陈展鸿 031702530
王景弘 031702531
陈观鸿 031702538
1.2 工作流程、组员分工、组员工作量比例
1.3 GitHub 项目链接
1.4 本组 Beta 冲刺站立会议博客链接汇总
Beta 冲刺 （1/5）
Beta 冲刺 （2/5）
Beta 冲刺 （3/5）
Beta 冲刺 （4/5）
Beta 冲刺 （5/5）
1.5 燃尽图
1.6 原计划、达成情况及原因分析
①原计划将功能做到什么程度
首先想做到基本功能的完成 例如完整的租借流程然后再考虑其他的额外功能，比如社区功能，
最后如果有必要的话再考虑性能优化。
②实际做得怎么样了
实际上除了最后的性能优化没做，其他均已完成。
③如果没有达成，反思是哪些因素影响的
性能优化没有达成，我认为是时间成本的问题，时间太少，需要学习的内容较多。
1.7 Beta版本展示
使用说明：
本产品采用app的形式，针对的是有闲置物品租用需求或对活动室有借用需求的目标用户群。
本产品的核心功能是借用空闲活动室与个人闲置物品的租借。此外，本产品还有提供社区发布、教务通知的功能。同时为了更好地服务用户，我们严格规范借还步骤并设置了信用度功能。
租借物品或活动室：①点击页面中间的物品或活动室推送；②点击页面下方“预约/借用”跳转按键；③填写借用表并确认提交
查看“我的资料”：①点击下方的“我的”按键；②根据需求可点击页面上方的头像查看个人资料，或者点击页面中间“我租借的”查看已租借物品
在“社区”发帖：①点击下方的“社区”按键；②编写帖子
1.8 本组的现场答辩得分
54.3分
1.9 回答其他小组对本小组的提问
1.信用分是否足够客观，若加分细则过于明细是否会导致用户恶意刷分？?（第二组）
在现有条件下我们认为足够客观，其实并不会产生刷分的现象，因为即使你信用分再高如果你损坏了物品的话依然要赔偿，这就使得信用分不会被别有用心的人利用
2.学校通知的具体内容没有在 PPT 展示，不清楚这个通知是哪方面内容（第三组）
通知就例如教务处网站的公开通知
3.暂无提问（第四组）
暂无
4.钱是线上交易还是线下交易，如果线上交易有考虑收取手续费吗，如果线下该如何运营呢?（第五组）
钱财可以选择线上或线下交易，当然会考虑按比例收取手续费因为这是能创造营收的重要手段，线下交易的问题得由借用者和租借者来协商
5.有没有一个良好的方式来管理信用分呢?（第六组）
按照每次出借归还的时候，出借者与借用者之间互相评分来综合认定
6.有没有考虑增加闲置物品售卖功能（第七组）
暂时未考虑，如果平台使用者有意愿的话可以在社区模块里发布消息，以私人名义出售物品，平台对这种行为不予负责
7.之前说的确定各个时段借出活动室后活动室内物品的情况（查看是否损坏），是否有做相关的功能，是如何实现的？（第八组）
这个确定物品是否损坏的步骤，我们将其设置在归还物品或活动室时以拍照的形式，借用者要对其进行确定才算完成物品或活动室的归还
8.信用分有上限吗？完成即可以一直往上涨？如何科学反映用户的信用水平？（第九组）
信用分以百分制为基础，按照归还物品时借用者和租借者的相互评分来认定，不会超出上限，除此之外没有别的方法来故意刷分
9.暂无提问（第十组）
暂无
10.信用分的机制细节是什么样的，如何防止刷分?（第十一组）
信用分以百分制为基础，按照归还物品时借用者和租借者的相互评分来认定；其实并不会产生刷分的现象，因为即使你信用分再高如果你损坏了物品的话依然要赔偿，这就使得信用分不会被别有用心的人利用
11.信用分的具体机制和规则是否有明确的说明？服务器这次比较耐操了，是否按量计费？（第十二组）
说明参考前几题回答；服务器不是按量计费的，依然是包月计费
1.10 PSP与学习进度条
个人PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时 (小时) |
实际耗时 (小时) |
|---|---|---|---|
| Planning | 计划 | 0 | 0 |
| · Estimate | · 估计这个任务需要多少时间 | 1.5 | 2 |
| Development | 开发 | 0 | 0 |
| · Analysis | · 需求分析 (包括学习新技术) | 0.9 | 1.4 |
| · Design | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定或选择合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 0 | 0 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试(自我测试，修改代码，提交修改) | 0 | 0 |
| Reporting | 报告 | 0 | 0 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0.1 | 0.1 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出改进计划 | 0.5 | 0.5 |
| · 合计 | 1.5 | 2 |
个人学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 12 | 12 | 基本了解了原型图的设计理念与实现方法，掌握了墨刀的基础用法 |
| 2 | 412 | 412 | 20 | 32 | 构思算法，实现基本框架 |
| 3 | 660 | 1072 | 36 | 68 | 算法改进 |
| 4 | 148 | 1220 | 15 | 83 | 了解接口的使用，学习了github使用规范 |
| 5 | 0 | 1220 | 15 | 98 | 明确了团队项目选题 |
| 6 | 0 | 1220 | 15 | 113 | 明确了团队项目需求 |
| 7 | 0 | 1220 | 3 | 118 | 帮忙找了需要的数据，之后要努力学习技术 |
| 8 | 0 | 1220 | 3 | 121 | 重新安排了alpha阶段的分工，验收团队的成果 |
| 9 | 0 | 1220 | 3 | 124 | 安排了alpha答辩的分工，验收团队alpha阶段的成果，准备alpha答辩 |
| 10 | 0 | 1220 | 2 | 126 | 安排了beta阶段的分工，验收了beta阶段的成果 |
| 10 | 0 | 1220 | 5 | 131 | 验收了beta阶段的成果，完成了beta答辩 |
