第02组 Beta版本演示
[toc]
1. 博客链接及组员信息（2分）
- 组长博客
- 组员信息
| 短学号 | 姓名 |
|---|---|
| 031702640 | 张越洋（组长） |
| 031702626 | 杨世杰 |
| 031702436 | 苏伟欢 |
| 031702438 | 陈文彬 |
| 031702445 | 林文涛 |
| 031702542 | 林小棠 |
| 031702522 | 邓志雄 |
| 031702443 | 龚洋林 |
| 031702446 | 林宏海 |
| 031702437 | 王淇弘 |
2. 贡献比例（3分）
- 工作流程
- 组员分工、工作量比例
| 组员 | 贡献百分比 | 完成的任务 |
|---|---|---|
| 杨世杰 | 15% | 接口的设计与维护、提问、回答别组的提问 |
| 林宏海 | 15% | 接口调用、校园百科的界面设计 |
| 陈文彬 | 12% | 修改任务悬赏的筛选页、美化UI |
| 林文涛 | 11% | 美化UI |
| 苏伟欢 | 10% | 接口的设计与维护 |
| 林小棠 | 10% | 接口的设计与维护 |
| 龚洋林 | 9% | 接口调用 |
| 张越洋 | 7% | 制作PPT、展示、写博客 |
| 邓志雄 | 5% | 提问、评分及评论、制作评审表 |
| 王淇弘 | 5% | 测试 |
3. GitHub 项目链接（1分）
4. 博客汇总（2分）
Beta 冲刺 （1/5）
Beta 冲刺 （2/5）
Beta 冲刺 （3/5）
Beta 冲刺 （4/5）
Beta 冲刺 （5/5）
5. 燃尽图（3分）
6. 原计划、达成情况及原因分析（6分）
- 原计划将什么功能做到什么程度？
- 原计划是在Beta冲刺实现项目的主要功能，也就是实现任务整合的筛选功能，校园百科的词条创建、修改、展示、搜索功能
- 实际做得怎样了？
- 成功完成任务整合的筛选功能，以及校园百科的词条展示、搜索功能。但是词条的创建和修改还在进行中，用户暂时无法参与到词条的维护工作中。
- 如果没有达成，反思是哪些因素影响的？
- 外在表现主要是时间不足。应该是和数据库实践的时间相重合的缘故。并且在校园百科该如何实现的问题上，我们之间存在较大争议，在一定程度上也拖慢了开发进度。
7. Beta 版本展示（10分）
审核未通过ヽ(`З’)ﾉ，大家只能先看看视频演示了
8. 本组的现场答辩得分（1分）
- 现场答辩得分：50.77
9. 回答提问，并回答（10分）
| 提问小组 | 问题 | 解答 |
|---|---|---|
| 1 | UI界面有打算再美化一下吗？(特别是任务详情界面)如果用户也能进行词条维护，如何避免虚假信息？ | UI会考虑进行美化，只有自己创建的词条才可以进行维护，其他用户无权维护。暂时只有人工审核的方式。 |
| 2 | \ | \ |
| 3 | 界面有待完善，如果任务被发布者修改任务内容，会不会造成接单人与发布者双方的误会？ | 一旦有用户接单之后，任务内容将锁定，无法修改。 |
| 4 | 类似于py交易如何处理 | 违规交易会封禁 |
| 5 | 市场任务的修改是随时的吗？还是任务被人接收后就无法修改？ | 不是随时的，接受后任务内容将锁定，无法修改。 |
| 6 | 市场任务如果修改，可以做到通知到接单人吗？ | 有用户接单后，任务内容将锁定，无法修改。 |
| 7 | 如果有人一直接单，等一段时间，再取消接单，再接单，导致有些单被恶意接收（无法完成）怎么办 | 目前暂时没有取消接单，若存在违规现象，将人工审核并封禁微信账号。 |
| 8 | 如何吸引用户群体？ | 项目的优点在于整合，且有规范化的流程，能够吸引到一定量的用户。 |
| 9 | 你们说百科是问答系统 是发布问题然后等人回答吗 我看你们有词条 如果词条上没有我要问的问题呢 | 问答反响太慢体验不好，暂时采用主动提供词条的方式 |
| 10 | 校园百科是每个人都能改吗，有人恶意更改怎么办 | 只有创建者才有权限更改 |
| 11 | 一些违法的任务是否有解决方式 | 目前暂时采用人工审核的方式。 |
| 12 | 校园百科是否有编辑记录 | 暂无，但会考虑您的建议 |
10. PSP与学习进度条（2分）
个人PSP
PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟） Planning 计划 30 15 · Estimate · 估计这个任务需要多少时间 30 15 Development 开发 50 30 · Analysis · 需求分析 (包括学习新技术) 50 30 · 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 报告 30 120 · Test Report · 测试报告 0 0 · Size Measurement · 计算工作量 0 0 · Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 30 120 合计 110 165 个人学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
| ----- | -------------- | -------------- | -------------------- | -------------------- | ----------------------------------------------- |
| 1 | 0 | 0 | 0 | 0 | 无 |
| 2 | 300 | 300 | 5 | 5 | 不应毫无规划就打代码、学会用Axure画简陋的原型图 |
| 3 | 1100 | 1400 | 23 | 28 | 学习网络接口的使用、学习pygame模块的使用 |
| 4 | 0 | 1400 | 15 | 43 | 学会画燃尽图 |
| 5 | 0 | 1400 | 10 | 53 | 无 |
| 6 | 0 | 1400 | 3 | 56 | 意识到事先规划的重要性 |
| 7 | 153 | 1553 | 12 | 65 | 明白了团队开发的一般流程、如何使用管理团队代码、初步学习软件测试 |
| 8 | 0 | 1553 | 10 | 75 | 学习11组组长陈郑铧的跑宿舍“交流”。反思 |
| 9 |120 | 1673 | 12 | 82 | 软工的理论课掌握得更好了 |
| 10 |90 | 1763 | 10 | 92 | 软工的理论课掌握得更好了 |
| 11 |50 | 1813 | 12 | 104 | 现场展示的效果终于不算太糟糕了 |
和上一次提交处于同一周，代码增量为0
