1. 团队成员的简介和个人博客地址
刘畅
博客园ID：森高Slontia
身份：PM
个人介绍：
弹丸粉 || 小说创作爱好者 || 撸猫狂魔(x || 生命的价值在于创造
（我绝对不知道，我一个写代码的怎么就当PM去了？）
张安澜
博客园ID：MinstrelZ
身份：后端开发
个人介绍：
张安澜，来自北京航空航天大学2015级计算机学院，喜欢旅游，修仙党，lol大乱斗选手，吃鸡萌新，喊666贼6
辛德泰
博客园ID：Alethia
身份：前端开发
个人介绍：
我是ZnTcTi
赵奕
博客园ID：ohazyi
身份：开发
个人介绍：
擅长做梦，喜欢折腾
*科栋
身份：测试
个人介绍：
无。
2. 团队开发情况
2.1 项目预期
2.1.1 团队项目的目标
红色为Alpha阶段实现的功能，蓝色为Beta阶段实现的功能。
完善功能
Beta阶段中我们对Alpha阶段实现的功能进行了改进，增加了课程收藏功能、资源评价功能、资源分类功能等等，这些细微的功能可以大大增强用户体验。
提供交流平台
我们认为，在学习过程中，同学们最需要的是总结和交流。和Alpha阶段一样，我们的最终目标一直是排除同学们在学习道路上的困难，因此在Beta阶段中，我们增加了讨论版功能，同学们遇到任何问题都可以在讨论版进行交流。
2.2 用户量情况
在排除所有测试账号的情况下：
- 截至Alpha阶段结束，网站访问ip数（不计APP）约为220，注册量为30；
- 截至Beta阶段结束，网站访问ip数为633，同期增长率为187.7%，注册量为148，同期增长率为393.3%。
经统计，截至Beta阶段结束，Android用户占比最高，为45%，其次为网页端用户，为33%，同袍用户占19%。此外，还有少部分用户同时为同袍和Android用户。
结果显示，超过80%用户只是临时使用iCourse获取资源，但依然有近百位用户多次使用iCourse获取资源（访问天数为10以上的ip可能属于开发人员）（该结果仅为网页端）
目前APP下载量为214
2.3 一些进步
2.3.1 分工协作情况
Beta阶段相比于Alpha阶段，团队的分工更明确了。在Beta阶段开始前，我们将要实现的功能分为两类，一类是对资源共享的扩展，一类是全新的博文功能。这两大类功能之间关联性较低，由两位后端成员各自负责一类最为合适，这样各自的工作会变得独立，降低沟通带来的成本。
2.3.2 贡献分分配
在Alpha阶段中，贡献分分配规则太过复杂，如任务难度还要分为预计和实际两部分，记录贡献的成本有些高。在Beta阶段中，贡献分被简化为时长、难度和完成情况三部分，其中难度和完成情况的评分有着明确的标准，而时长一旦确定，之后会尽量避免改动。对本人实现功能的bug修正，不再新建“贡献项”，而是根据bug类型适当提高原“贡献项”的难度。
任务完成得分 = 完成度 * 时长 * (1 + 难度) * 5
2.3.3 文档完善情况
Beta阶段我们有了较为完备的数据库说明文档、API说明文档，并在老师的建议下添加了配置说明文档，全部文档位于/docs/目录下。
在Beta阶段中，成员们可以根据事先设计的API文档实现功能，缩短了沟通的时间，提高了工作效率。
同时，每名成员的贡献分也同样在/docs/目录下，做到了贡献情况的透明，保证公平性。
2.3.4 issue的建立
经老师建议，我们将测试及使用中遇到的bug及时以issue的形式记录在github上，当bug被解决的时候再将其close。
2.3.5 推广手段
Alpha阶段中，我们唯一的推广手段只有朋友圈；而在Beta阶段中，除了在朋友圈中进行推广，我们还在未来花园、同袍App、公众号上进行推广，从用户量增长情况可以看出取得了一定的效果。
未来花园：
同袍：
2.4 时间/质量/资源的平衡
Beta阶段中团队面临的情况十分险峻——前端开发人员的减少（2人变为1人）、编译课设的开始、期末各种DDL轮番轰炸都是我们面临的挑战。不仅人手少了，成员们可分配给软工的时间也远远不如Alpha阶段。最终的结果是后端实现了充分的功能，而前端只能视情况挑选必要的将其衔接到界面中。
2.5 测试情况
-
jmeter中设置用户数为30，循环次数为“永远”，运行起始时间为2017.12.23 00：30， 运行结束时间为2017.11.25 00：34， 平均请求响应时间为3.6s，错误率为0，30个用户，3.6s的平均响应时间偏慢，响应最慢的url是course/contrib，这个是计算课程的用户贡献度的，速度比较慢的原因推测是每次计算课程用户复杂度时，都要重新遍历数据库，重新计算用户贡献度，因此较慢，具体数据见下图：
-
测试人员同样尝试了用户数为35,33,31的情况，运行10min左右后，发现均会出现微小的错误，大约千分之几到百分之几的样子，这说明30个用户已是网站的最大负载。
-
2017.12.28 将服务器上运行的进程数由1增加到10，最大负载增加到141个用户。尝试142/143个用户时都会出现微小错误。
-
2017.12.29 经过刘畅同学和赵奕同学的优化，平均响应时间降至1.4s,较第一次测试的平均响应时间降低61%，最大用户数不变。
2.6 代码规范
我们使用的是npm自带的代码规范审查，包括但不限于：
- 大括号之中的内容和左右大括号之间必须有空格或换行
- 所有引号必须为单引号
- 不允许出现tab
- 每行末尾必须有空格
- 不允许出现声明变量未使用的情况
另外在view.py中，我们对函数实现的功能进行了一个简要的说明，大大提升代码可读性，如图：
2.7 一些反思
- Beta阶段出现的最严重的问题是预计实现的功能太多，而由于临近期末大家时间都很紧，导致最终也只是实现了一部分。当全部功能的实现得不到保证的时候，不同功能之间的优先级就显得很重要，然而PM却没有及时对计划进行调整，实在是缺乏大局观
- 代码管理得不到位，基本上全部后端的实现都堆在几个.py文件里（views.py文件达到了2000行），影响开发效率，而且命名规则也没有统一
- 除了Beta阶段开始时备份过一次数据库，此外再也没有对数据库进行备份
3. 进展情况
3.1 燃尽图
最后一次会议的燃尽图：
这个燃尽图是根据github中issue的关闭情况自动生成的，因此符合开发的实际情况。
由于编译课设比较紧张，而且团队人手又不太充足，团队进展速度时快时慢，最终未能在期限内完成预计的工作，只得暂时放弃一些非核心的功能。
3.2 发布的功能
我们的网站： 北航iCourse课程资源平台
3.2.1 首页
3.2.2 课程搜索页面
3.2.3 课程信息页面
3.2.4 课程资源页面
3.2.5 资源信息面板
3.2.6 课程讨论版
3.2.7 帖子页面
3.2.8 登录面板
3.2.9 个人中心
4. 团队成员在Beta阶段的角色和具体贡献：
4.1 代码贡献
使用如下指令，统计每个人Beta阶段（2017-11-22以后）代码贡献
git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --since==2017-11-22 --author="$name" --pretty=tformat: --numstat | awk '{ if ($1 >= 0) {add += $1; subs += $2; loc += $1 - $2} } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
辛德泰（前端）：3139
方科栋（测试）：170
张安澜（后端）：923
赵奕（后端）：3966
刘畅（PM）：3760
使用如下指令，统计全部代码贡献：
git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --author="$name" --pretty=tformat: --numstat | awk '{ if ($1 < 500) {add += $1; subs += $2; loc += $1 - $2} } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
辛德泰（前端）：5259
窦鑫泽（前端）：2067
方科栋（测试）：519
张安澜（后端）：2283
赵奕（后端）：5380
刘畅（PM）：5360 + 1351
由于git的代码贡献统计不一定准确，该结果仅供参考。
4.2 最终贡献分
各成员贡献情况。贡献分的计算方式依照事先制定的贡献分分配文档（有一定调整）。
由于又出现了同分的情况，具体分配结果有待调整
分配结果：
| 姓名 | 贡献分 |
|---|---|
| 方科栋 | 51 |
| 辛德泰 | 52 |
| 刘畅 | 47 |
| 张安澜 | 40 |
| 赵奕 | 60 |
5. 存在的问题
2018.1.1
搜索到的结果可能会不全，目前还没有定为到具体原因。