1.团队介绍
- 团队名称：北航红太阳 BuaaRedSun
- 团队成员介绍：（点击名字跳转至个人博客）
| 成员 | 角色 | 自我介绍 | 照骗 |
|---|---|---|---|
| HansBug | 架构师，后端组长。 | 做过一些简单的开发，写过一些简单的算法题，喜欢没事写写程序，偶尔去创造一下奇迹改变一下社会。 |  |
| 马振亚 | 后端开发 | 擅长各种行政打杂事物（给各位大佬端茶递水） 能写 c/java/python/js 求各位大佬带带 |
 |
| 庄廓然 | 后端开发 | 熟悉java,c++,c,c#，参与过的安卓开发，后台开发，写过unity游戏脚本，工作积极，希望向各位大佬学习。 |  |
| 周雨飞 | 前端开发 | 主要负责的工作是给其他几位大佬端茶递水 擅长Java/Python 前端和后端都会一点点 求各位大佬带飞 |
 |
| 李大 | 前端开发 | 活泼开朗。非计算机/软工学生，16级高工3系，接触过一些简单的软件项目（app、unity游戏），希望在软工课上体验较复杂的软件项目团队开发，积累经验。学习写代码，也学习如何进行团队交涉，和科班同学多多接触，补一补不怎么牢固的cs基础。 |  |
| 廖青城 | 前端开发 | ↑来自生医学院<br/>但是喜欢写bug然后debug（什么x），希望通过该项目学会如何严谨的写bug(′゜ω。‵) |  |
| 彭宇飞 | 需求分析，沟通社联 | 社联主席。经管学院信息管理专业，逻辑思维较强，产品经验比较丰富。做过一些小型的算法和数据库，要积极向组内各位同学学习！ |  |
| 谢静芬 | PM | 计算机系大三狗 人送外号分解（所以经常在数学课躺枪...） 虽然逻辑严密，擅长写文档（误） 但是算法能力较弱，编程效率较低 希望在团队中向大佬们学习，提升自我~ |
 |
其中，青城和宇飞没有选软件工程课，属于外援~~
2.回答一些工程问题
1.团队项目的目标，预期的功能描述，预期的典型用户，预期的用户数量在哪里？
整个项目的目标和预期功能
在用户群体上，我们加入了社联管理员，现在一共是三个用户群体：普通学生、社团管理员、社联管理员。
我们打算针对不同的用户群体开发出不同的平台和功能：
- 普通学生：使用“北航社团”小程序，功能包括：浏览各社团活动和动态，浏览各社团的文字和视频介绍，在线申请加入社团支付社费，报名社团活动，接收社团的活动通知，申请创办新社团。
- 社团管理员：使用“北航社团平台”校内网站，功能包括：编辑社团信息，设置入社条件，管理社员，向社联报备活动、申请活动场地，发布投票，发布消息，发布活动、审核报名人员、向报名人员发送活动通知。（多数功能已经由wowotou团队完成）
- 社联管理员：使用“北航社团平台”后台可视化数据库/校内网站，功能包括：线上审批各社团的活动申请和场地申请（甚至一键封装成邮件发给团委老师进行线上审批），全周期记录各个社团的信息和发展动态，便于建立覆盖全社团的星级评定体系。
其实还有很多能够挖掘的功能，比如wowotou团队在前期规划了但尚未实现的一些好功能：在线售卖社团文化产品、社团论坛、社团网盘等，我们认为这些功能还需要进行针对性的需求调查。
整个项目的预期典型用户
- 萌新M
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 萌新M |
| 用户身份 | 某学院大一新生 |
| 用户情况 | 刚入学，对于各个社团的情况不大了解 |
| 用户动机 | 希望能方便地查看各个社团的介绍和活动，同时方便地加入自己感兴趣的社团 |
| 用户痛点1 | 目前找不到集北航社团咨询与一身的平台。社团的公众号太分散，一个个去关注和查看文章十分麻烦；社联推送的社团介绍也比较有限。 |
| 用户痛点2 | 加入社团的步骤比较麻烦，一般需要在百团大战外场中，先填写基本信息问卷，然后支付社费，接着加一位社团管理员为好友，这样才能被拉进群，外场人好多真的好挤。 |
| 典型场景1 | 百团大战马上要来了，萌新M想率先了解各个社团的情况，于是打开了“北航社团”小程序，浏览了自己感兴趣的社团类别，以及热度比较高的几个社团的信息。他觉得A社团很符合自己的兴趣，于是直接在线上交了社费并加入了A社团，他被拉进了A社的群里，感受着老社员们对萌新M的热烈欢迎。 |
| 典型场景2 | 萌新M看到小程序上对于B社的简介，觉得有点兴趣，但是还不确定要不要加入，于是他去看了B社的百团大战外场，十分喜欢，当场通过小程序一键加入了B社，减去了繁琐的入社步骤，还能跟外场小姐姐多交流一会儿，美滋滋。 |
| 使用环境 | 主要是在零散的时间内、在随时可能移动的状态下，去关注社团信息，比如去教室的路上、课间休息时间、食堂排队时间、在宿舍宅着时等。 |
| 用户比例 | 40% |
| 重要性 | ★★★★★ 非常重要，如果从大一开始就认可这个小程序，并时常关注北航社团的信息，那么这部分用户的使用年份会很长；另外，如果萌新M之后当了社团管理员，也会向社员推广这个产品。 |
- 二狗G
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 二狗G |
| 用户身份 | 某学院大二学生（本表也适用于大三学生 三狗） |
| 用户情况 | 因为特别喜欢参加A社的社内活动，所以二狗G加入了A社团，积极参加A社每周末定期举办的活动；同时对于其它社团有趣的公开活动也蛮有兴趣。 |
| 用户动机 | 希望能方便地参加社内活动，同时希望能获取其它社团的公开活动的信息。 |
| 用户痛点1 | 社内活动由于场地等原因，经常会有变化，比如时间、地点的更换，或者本周活动取消，但是由于社团群里聊天消息太多，有时候会错过这样的重要通知信息。 |
| 用户痛点2 | 虽然只加入了A社，但是二狗G对于BCD社的公开活动也很有兴趣，但是这些活动只能通过刷朋友圈，或者主动查看公众号文章的方式来获取信息，十分不便。 |
| 典型场景1 | 由于场地原因，本周末A社的社内活动取消，社长在群里发了通知，同时也用小程序给社员们发了通知，社员们纷纷议论起来，群里聊天消息达到99+。正忙着敏捷开发的二狗G打开微信群，并不想将聊天记录往上翻，他直接点开了小程序给他推送的服务通知，哦看来这周末的时间可以全部用来敏捷开发了，嗯接着干吧！ |
| 典型场景2 | 二狗G觉得自己最近有点宅，想看看有没有什么活动可以参加，他打开“北航社团”小程序，哇塞，B社居然邀请到了知名相声演员郭德纲来讲相声，必须安排！还有10个名额，快抢！10元入场费？值！他心满意足地放下手机，吹起口哨继续debug。 |
| 使用环境 | 主要是在零散的时间内、在随时可能移动的状态下，去关注社团信息，比如去教室的路上、课间休息时间、食堂排队时间、在宿舍宅着时等。 |
| 用户比例 | 50% |
| 重要性 | ★★★★ 很重要，他们占活动参与人员的很大比例。 |
- 社管S：
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 社管S |
| 用户身份 | A社的社团管理员，比如社长、部长等 |
| 用户情况 | 1.对内，需要向社员发布社内活动消息、统计活动报名人员、通知活动变更情况、统计社员基本信息； 2.对外，需要向大家宣传A社，及A社的公开活动，积极拉人进社，完成信息收集、社费收取等入社步骤； 3.对上，需要向社联报备活动、申请场地、上交社员信息、上交星级评定材料。 |
| 用户动机 | 1.希望能方便地管理社员，发布活动、通知、投票等； 2.希望能有好的渠道宣传本社情况，非社员能更方便地入社，也减少社团繁琐的工作； 3.希望能向社联方便地申请场地、报备活动，社联也能保存好各种信息，每年星级评定的材料不用交太多，这样也更公平… |
| 用户痛点1 | 进行社团管理工作时，一般会把通知消息或者报名问卷、信息填写问卷等放到社团的群里，但是这些重要的消息经常被社员的聊天水过去了，需要重发。上述方式不仅麻烦，而且效果不佳。 |
| 用户痛点2 | 百团大战时，前来报名入社的人很多，但是由于报名步骤比较繁杂，导致现场比较混乱；而且百团大战之后，基本就没有什么人会加入社团了，社团缺乏一个好地平台展示自己；宣传公开活动时，大多只能通过公众号文章和朋友圈的形式进行宣传，宣传效果不佳。 |
| 用户痛点3 | 报备活动、申请场地等流程较为繁杂；而且有时候团委要统计各个社团社员的一些情况，比较麻烦；星级评定时需要提交很多材料，比较麻烦。 |
| 典型场景1 | 社团A要给社团内部成员设计一套社服，社管S于是通过“北航社团”网页端编辑了一个投票，并一键推送给了所有社员，社员通过服务通知接收到了该投票进行填写（如果开启了接受社内消息的功能）；投票截止后，社管S通过网页端下载到了社员的投票情况，坐等社长夸奖。 |
| 典型场景2 | 社团A要举办一个公开活动，社管S于是通过“北航社团”网页端编辑了该活动的基本信息，并一键发布活动（这里也考虑加入社联的审核功能），所有“北航社团”小程序的用户都能在“活动”页面查看该活动的情况，并可以在线报名和支付活动费用。哇塞，这次活动有好多非社内成员参加，给活动部的小姐姐点赞。 |
| 使用环境 | 由于需要编辑问卷内容、活动信息等，因此一般在电脑端进行使用。 |
| 用户比例 | 7% |
| 重要性 | ★★★★★ 十分重要，如果能让社长体会到本产品对于他们管理社员、宣传活动、对接社联的便利性，他们会更愿意帮助我们在社员中推广此产品。 |
- 社联L：
| 用户信息 | 用户情况 |
|---|---|
| 姓名 | 社联L |
| 用户身份 | 归属于社联，负责管理各社团事务 |
| 用户情况 | 社团上报的活动需要上交给团委进行审批；需要了解社团的发展情况，并帮助他们发展；需要收集星级评定的资料。 |
| 用户动机 | 1.希望活动审批等流程能更加信息化，更加高效； 2.希望能全面了解社团发展情况； 3.希望能方便地管理各个社团的信息，使星级评定更加合理和客观。 |
| 用户痛点1 | 采用纸质版的审批流程，流程复杂，跑动量大，自己累，还经常被社团管理员抱怨 |
| 用户痛点2 | 想要给社团提供一定的发展支持，但是难以了解社团的情况，无法很好地主动给予帮助支持，只能由社团主动提出自己的需求。 |
| 用户痛点3 | 星级评定材料的收集、审核和打分都主要靠人工进行，工作量大，且有失一定的客观性。 |
| 典型场景1 | 社管S发来了活动报备表，社联L通过“北航社团”这套信息化的系统，及时接受到活动报备表，初步审核后将活动信息通过邮件转发给指导老师和团委老师，审批的老师一键同意了该活动，社联将审批结果下达给社管S，皆大欢喜。 |
| 典型场景2 | 从社团的人数、活动、热度等角度，系统全面地记录了两年来社团A的情况，通过数据来量化社团的整体情况，社联L发现社团A的公众号文章阅读量很低，仔细调查后发现排版不行，于是直接联系社团A宣传部，进行相应的培训；同时还发现社团A的活动经费比较匮乏，社联L主动提出帮该社团联系赞助，真棒！ |
| 典型场景3 | 从社团的人数、活动、热度等角度构建了社团评价体系模型，每年星级评价时，这部分指标直接通过系统进行打分；只需向社团收取一小部分其它资料进行人工打分即可；打分完毕后公式结果，大家对于数据都很服气。 |
| 使用环境 | 由于需要审核活动信息、看到信息表格等，因此一般在电脑端进行使用。 |
| 用户比例 | 3% |
| 重要性 | ★★★★★ 很重要，如果能让社联体会到本产品在管理社团、评价社团、审批活动等方面的便利性，他们可以在社长中大力推广此产品。 |
整个项目的预期用户数量
- alpha阶段小程序发布后一周内，用户量累计500人
- beta阶段小程序发布后一周内，用户累计1000人
- beta阶段网页端发布后一周内，15位社长和社联进行使用，约20人。
- gamma阶段网页端发布后一周内，社联和多数社长进行使用，约80人。
2.团队的产品如何满足了用户的需求？要看到目标用户使用产品的过程和评价 (视频或者活人上台介绍)
alpha满足的用户需求
alpha阶段的小程序由于没有社团管理功能，因此主要满足前两类用户的需求，简单来说就是 浏览社团信息 和 浏览活动信息。alpha阶段的具体功能如下：
| 模块 | 功能 |
|---|---|
| 登录 | 授权登录，游客模式，无需填写信息 |
| 活动展示 | 首页轮播热度最高的四个活动，查看活动详情，关注和取消关注活动 |
| 新闻展示 | 查看新闻简易列表，跳转公众号文章详情，按类别筛选新闻 |
| 社团展示 | 搜索社团，按类别展示社团，查看社团简介、新闻、活动等，关注和取消关注社团 |
| “我的” | 查看自己关注的社团和新闻，查看开发者信息 |
点击此处跳转发布声明，查看展示软件功能的动图。
3.事先定义的软件下载量达到了么？为什么没有达到？
alpha用户量一览
4.19日18:00小程序通过审核。截至4.23日清晨，共有334名用户使用了我们的小程序。累计用户访问数的变化如下图：
之前预估的用户量500，指的是是发布后一周内的用户量，按照这个趋势我们认为可以达到目标用户量，因为目前我们还没有私聊社长帮忙推广。
4.团队的成员如何分工协作的？有什么经验教训？
团队分工及经验教训
（一）团队成员总体分工
| 成员 | 分工协作 |
|---|---|
| 少昂 | 经验丰富，为后端组长，负责架构设计、部署、建立用户系统，并指导振亚和廓然进行接口设计和开发，保证接口质量。 |
| 振亚、廓然 | 进行数据库初步设计，接口设计和开发，同时负责后端的测试。 |
| 雨飞、李大、青城 | 分管不同页面的前端开发；撰写接口设计初步文档，交予后端调整和实现；承担部分UI设计。 |
| 宇飞 | 联系社联和社长，并承担部分UI设计 |
| 静芬 | 需求分析、 联系社联、原型设计、博客撰写、主持和记录例会、协调前后端、前端测试等 |
（二）任务细化分配（为初步计划，与实际进度有出入）：
（三）经验教训：
- 后端三人小组内部，由富有经验的少昂进行指导，并把关代码和文档，能够较好地保证后端代码的合理性、数据库的正确性等，但这依赖性较强，还是应该让两位小白早点独当一面。
- 前端三人小组内部，由于是按页面分工，需要协调的东西少，而且小程序容易上手，因此前端进行得比较顺利。之后仍会以页面进行分工。
- 前后端对接方面，过程是，首先是由前端给出初步的数据请求文档，然后由后端进行调整，并整理成接口文档，再由前端确认无误后，后端再进行接口的实现。这多次握手，虽然表面上能够保证接口设计的正确性，但实际上中间出现了断层：前端人员对需求的理解不够，导致第一步的文档有较大纰漏，同时后端也由于对需求的理解不够，直接根据第一步的文档进行下一步，从而延续了文档的错误，最后出现了经常改动接口文档和代码的现象。教训是，PM要给团队成员讲清楚需求，督促和考察团队成员是否理解了需求，同时要从需求的角度把关接口文档的设计是否正确，在设计正确性得到验证之后，再进行接口实现也不迟。
- 整体设计方面，由于少昂在前期失去沟通，因此前期的后端主要由后端两位小白辛苦摸索出来的，而后期他参与进来后发现一些设计不大合理。所得到的教训是，要早点咨询少昂的意见、和他讨论，他的经验比较丰富，能够给出很好的意见。
5.团队是如何进行项目管理的？
团队项目管理
参考课程组给的链接，我们使用github进行项目记录和管理，同时也使用了gitlab。具体的流程是：
- 每周开始前，由PM定下前后端在本周的任务和目标，并尽量分配到具体每个人的本周任务，同时声明一些特殊时间节点，比如A同学的B任务必须在周x前完成，因为B任务是另一位同学的前置条件。
- 每个人根据自己本周的任务，以及自己本周其它个人事情的安排，列出自己的每日计划，也可以提出对自己的任务进行转移和调整。
- 每日计划上传到gitlab公示，由PM初步判定计划可行性，有需要时做出一定的调整。
- 每天晚上23:30进行线上会议，每个人汇报今日完成的任务、工作量等，对照看是否完成了自己的计划，如果没有完成如何调整。
- 由于课程组要求有燃尽图，因此PM会在每周初将大家的计划转为issue，并每天根据例会上了解到的进度情况更新issue，从而得到每日燃尽图。
6.团队如何平衡 时间/质量/资源 争取如期完成任务的？
时间/质量/资源的平衡
主要是通过两个方法来平衡：
- 每日计划的制定：由团队成员个人来制定自己的每日计划，当然这个计划的周目标是由PM指定的，这个计划接受团队其它成员的监督。这样能让团队成员自由把控时间，这样比PM直接分配每日计划要更方便、更人性化、更有可行性。
- 软件功能的优先级划分：考虑到alpha版本中队员们需要进行磨合、熟悉工具等，因此能实现的功能有限，必须划分优先级，alpha版本实现优先级最高的功能，并同时根据项目实际进展，来暂时砍掉或加上一些功能。核心功能的质量必须得到保证。
7.在产品之外，团队代码的软件工程质量如何？如何用数据来证明？
参见我们的测试报告。
8.测试用例数目，代码覆盖率数目。
9.运行测试用例得到代码覆盖率的视频录像，(需要现场看到。 没有诸如 “我的电脑没有装测试环境”,“文件不全”等等借口)
测试用例和代码覆盖率
- 测试用例数目：50，代码覆盖率：controllers为93%, models为91%。
- 视频录像：暂时用U盘查看
10.代码规范在哪里？
11.齐全的文档在哪里？
14.明年的同学继续开发这个项目，会不会出现类似的抱怨？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？
文档位置和新人入口
- 文档在gitlab上，主要包括：
- 明年的同学若继续开发这个项目，可能会有一些抱怨，但是怨气不会太大。因为我们的文档还算完备（如上），能够让新学生了解整个项目从0到1的过程，以及最重要的接口文档。其中，上述快速搭建环境文档可以指导新人顺利运行我们的项目。
12.有些项目是在原来的基础上改进的，那么我们团队的软件工程项目质量有什么样的提高？例如，代码覆盖率从原来的x增长到y？
13.原来的项目有些代码混乱，没有注释，没有详细的文档，你们的项目是如何更好解决这个问题的？
关于以前的项目
- 答1：虽然我们的项目在名义上，是基于以前的项目，但其实两个项目只是有所交叉，其实区别很大，而且以前项目的版本太旧跑不起来，因此我们决定在Alpha阶段暂不使用以前项目的代码。
- 答2：鉴于两个项目只是有所交叉，其实区别很大，而且以前项目的版本太旧跑不起来，因此我们在Alpha阶段暂不使用以前项目的代码。
15.对于项目的目标用户是一般学生的项目， 你们如何找到学生做需求分析？他们给你什么样的反馈？
整体项目的需求分析
用户需求的调查分为两个部分：
（一）需求调查第一部分：向学生发放问卷调查。
1.发放位置：几个社团内部微信群、去年的体育类社长群、朋友圈。（以此保证参与问卷的人的院系比例、年级比例较为合理）
2.参与问卷调查的人员共126人，人员比例比较合理：有几乎一半人是大一大二的学生，他们有的刚入校园，对社团不甚了解，有的正处于参加社团的活跃阶段。另一半人多为大三学生，他们经历过了参加社团的活跃阶段和冷却阶段，对社团的体验和感受更深刻。
3.调查结果：
（1）在126个学生中：
| 项目 | 内容 |
|---|---|
| 痛点 | 1.约81%的人认为，他们刚入北航时缺乏一个渠道来了解各个社团，其中有近一半希望有个平台能整合一下各个社团的介绍，并进行分类。 2.约89%的人希望在百团大战过后仍能方便地了解各个社团的活动，其中约一半的人认为目前只能通过朋友圈和公众号了解，比较麻烦。 3.约90%的人认为，在他们参加社团活动时，经常需要填写报名信息，这十分不方便。其中有近50%的人认为，每次要填的信息都差不多，令人烦躁；有约20%的人认为，报名问卷容易被社员的聊天水过去；有约31%的人希望能有个小程序帮助他一键报名。 4.令我们惊讶的是，约65%的人表示，他们曾经错过了自己很想参加的社团活动！ |
| 需求 | 1.能方便地查看各个社团的文字和视频介绍，以选择自己想要加入的社团并在线申请加入。 2.即使没有加入某个社团，也希望能方便地浏览各个社团或自己感兴趣的社团的活动和动态。 3.能够及时看到活动通知并一键报名，防止错过自己想参加的活动。 |
| 需求类型 | 辅助性需求 |
| 需求量估计 | 调查显示，有约93%的人表示愿意使用我们的小程序，且由于小程序易于传播、用户群体扎堆等优势，如果用户对产品比较满意，可能比较愿意向他人推荐。 |
（2）由于我们第一版重点在于开发小程序，因此决定后两个版本再由社联协助、覆盖性地调查各个社长的需求。因此本次调查中，我们仅初步调查了一些社长的意愿，在126个学生中有16个社长：100%的社长表示愿意使用我们的产品，用来进行社团管理、活动发布、社团宣传甚至获得赞助等。
（3）附调查问卷的部分结果截图：
（二）需求调查第二部分：对社联办公室和宣传部的代表人员进行了电话和微信采访。
（1）社联办公室的人表示，对我们产品的十分认可，能够提供产品推广、数据收集等的帮助：
这可是个好东西，社联办公室主要负责的是社联与社团的对接与沟通，是可以直接联系到各个社团的，如果有什么需要帮忙的可以来找我们。
（2）社联宣传部的人表示，我们的观点与他们十分吻合，他们能够提供一定的UI支持。
事实上很巧，我们也正在筹备小程序的事情。目前做了一点点UI，但是因为没有需求分析和交互逻辑，所以还在设计主视觉形象，其实并没有什么进度。我正在向部长团征集想法，等征集好了一起发过去。我们这边有新媒体的童鞋能提供UI支持。我们希望社长能在上面申请活动场地，我们能在线审核。而且我们打算一直使用这个产品，但是又不懂运维，希望你们能提供一个后台数据库的非技术型、可视化界面，便于我们进行长久的管理。
用户反馈
- 在整个项目的计划和设计阶段时，通过绘制原型系统，我们招募了12名社联成员进行认真的体验和反馈，最终我们整理出了用户对于原型系统的反馈表格。
- alpha版本推广过程中，有一些同学提出小程序中的数据比较少，包括社团和活动的数据。目前我们的系统中有4个未过期活动，1个已过期活动，29篇微信公众号文章，还有18个社团，多数为手动摘取和录入，我们会尽快实现一个能够让社长增改数据库部分内容的接口。
- alpha版本推广过程中，我们也发放了问卷，但是填写人数较少，填写质量较低。考虑到之前已经有对整体项目的需求问卷，以及社联人员对原型系统的反馈表格，因此这次的用户反馈问卷让用户感觉比较疲惫。前两次调研，已经足够我们进行下一阶段的设计。
16.所有的项目都会收集到用户的数据，请问你们对这类数据做了什么样的分析，这些分析如何验证或推翻了原来的假设？这些数据如何帮助项目改进软件工程的质量？
小程序用户数据分析
微信公众平台自动收集了用户数据。主要分析以下数据项：
-
四天来，每天的累计访问人数：
-
四天来，以半小时为粒度的实时访问次数：
-
四天来的访问分布，包括访问来源、访问时长、访问深度 三个方面：
3.项目情况
进展-燃尽图
- alpha-1（至4.9日）：
- alpha-2（至4.14日）：
说明在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？
答：由于无法细致地制定1-2周后的任务，因此我们将alpha阶段分成两个小段，每个小段开始时，详细定制本段计划，转为issue，这便是燃尽图中第一天的起点高度（虽然在这一小段中，我们可能会根据实际情况添加或删除issue，但issue总量变化不大）。每次例会上每个人总结自己的今日进度，由PM统一更新issue状态，以防止团队成员忘记更新issue。
发布的功能
参见发布文档，简表如下：
| 模块 | 功能 |
|---|---|
| 登录 | 授权登录，游客模式，无需填写信息 |
| 活动展示 | 首页轮播热度最高的四个活动，查看活动详情，关注和取消关注活动 |
| 新闻展示 | 查看新闻简易列表，跳转公众号文章详情，按类别筛选新闻 |
| 社团展示 | 搜索社团，按类别展示社团，查看社团简介、新闻、活动等，关注和取消关注社团 |
| “我的” | 查看自己关注的社团和新闻，查看开发者信息 |
- 最有特色的功能：将社团最近的公众号文章集成到本小程序中，用户无需关注公众号、还可方便地查看和筛选各社团的文章。
软件发布地
小程序发布在微信平台上，有两种获取方式：
- 打开 微信-->发现-->搜一搜-->输入“北航社团帮”，即可搜索到我们的小程序。
- 打开 微信-->扫一扫，扫描下方小程序码，即可进入我们的小程序：
用户反馈截屏
-
用户直接在推广处评价：
-
用户通过问卷反馈，这里显示部分反馈结果：
- 用户对于原型系统的反馈（部分展示）：
- 发布后发现的bug：
- 微信名含有非法字符（如表情）时，登录错误，已修正。
- 社团-->活动-->活动详情，显示错误，下一次发布修正。
4.团队成员角色和贡献
- 团队成员alpha阶段最终贡献分：（贡献分和为 50*8=400）
| 名字 | 角色 | 团队贡献分 | 具体量化的贡献 |
|---|---|---|---|
| 少昂 | 后端开发 | 50 | 3351行代码，179行文档，1篇技术规格博客 |
| 振亚 | 后端开发、后端测试 | 72 | 930行代码，170行文档 |
| 廓然 | 后端开发、后端测试 | 64 | 641行代码，172行文档 |
| 雨飞 | 前端开发 | 50 | 2500行代码，20行注释，50行文档，1篇技术规格博客 |
| 李大 | 前端开发 | 42 | 1000行代码，250行文档 |
| 青城 | 前端开发 | 49 | 6000行代码，50行注释，50行文档 |
| 宇飞 | 需求分析和UI设计 | 11 | 整理一次用户原型反馈，logo设计 |
| 静芬 | PM、前端测试 | 62 | 18篇博客，4次推广，2次用户调查 |
- 去掉外援后，成员得分：
| 名字 | 角色 | 团队贡献分 |
|---|---|---|
| 少昂 | 后端开发 | 45 |
| 振亚 | 后端开发 、后端测试 | 63 |
| 廓然 | 后端开发、后端测试 | 56 |
| 雨飞 | 前端开发 | 44 |
| 李大 | 前端开发 | 38 |
| 静芬 | PM、前端测试 | 54 |
- 贡献分细则：
- 这里是贡献分规则
5.总结和展望
- 学到的东西：
- 技术上更加成熟和规范。
- 互相磨合，对团队合作有了更深入的理解，能够互相理解和包容。
- 对课程的建议：
- 希望在博客作业要求中说明时间节点等重要信息。
- beta阶段初步计划：
- 完善小程序的UI
- 小程序中加入社团管理功能
- 开发网页端进行社团管理，与小程序互通，争取在10个社团中达到实用效果。
posted on
