[软工顶级理解组] Alpha阶段项目展示
团队成员
普通程序员预备一枚。喜欢编程，想要做软件。担任过计组助教，进行过一段时间的网页后端开发。自己没事也喜欢鼓捣一些无聊的小脚本、小程序。
希望在软件工程这门课上能够做出自己未曾实现过的级别的软件，相信团队的力量。
目前掌握技术：C/C++， Java， Python控制台编程，C# Winform开发，Django后端开发，（一定程度上的）Linux服务器维护
职位：PM
什么都会一点但是什么都不精通，非ddl玩家，喜欢提前把任务做完。
希望在软件工程的项目上可以通过担任测试的岗位，学习其他人的代码风格和编程思想，提高自己的编程能力、设计测试用例的能力、执行自动化测试的能力，提高项目软件的质量。
目前掌握技术：C/C++， Java， Swift， Ruby和基础Rails框架， Python控制台编程
职位：后端开发
精通C语言，能熟练使用java，python，c++等语言，作为组长组织过无线网络系统项目的编写和集成，对团队工作有一定经验。本学期是我第二次参加团队项目，希望能有更多收获。
目前掌握技术：C， C++， Java， Python， Ruby on Rails.
职位：前端开发
能够熟练使用C，C++，python，java等语言，曾做过数据库课设，对于MySQL有一定的了解，自己也比较喜欢计算机图形学相关知识。在这次想进行前后端开发。
目前掌握技术：C，C++，Java，Python，MySQL
职位：后端
个人属于ddl玩家，不过希望且愿意接受push。上学期安卓课上做过一点客户端开发。在这次软工中希望和大家一起做意思的项目，学习团队合作的经验。在这次团队项目中想做前端或者测试的工作。
目前掌握技术：C/C++， Java， python，安卓客户端开发
职位：前端开发
C/C++，Java，Python均有所涉及，会用其中一部分内容。写代码时经常上网查函数定义。
我希望在这次软件工程的项目中担任前端或者后端的开发。有了PM和测试人员的存在，在团队中进行开发工作可以使我得到更多的收获。
目前掌握技术：C/C++，Java，Python，MySQL
职位：爬虫开发
会使用C/C++， Java， Python，但都不是十分精通，具备一定的网上搜索能力，有过写简单UI的经验。对于软件测试比较感兴趣。希望和团队里的成员一起合作完成较为综合的软件项目。
职位：前端开发
软件介绍
项目简介
我们团队做的是一款集课表查询、空教室查询、成绩查询、课程评价等教务服务为一体的北航教务助手APP。目前App名称：航胥——北航教务小助手。
在校园生活中，学习、教务是我们绕不开的话题。我们常常需要进行一些课表、教室查询等操作，而且亟待一款能够获取课程真实评价的软件。在之前，“同袍”这款北航教务助手软件曾被北航同学广泛使用，但是由于一些不可抗力因素，该软件不能再为同学们提供服务。因此经过团队讨论分析，我们决定对标“同袍”，开发一款便捷、好看、实用的教务助手APP，并希望能集成更多教务功能，为北航同学的学习生活带来便利。
预期典型用户
-
北航普通学生
用户信息 用户情况 姓名 吉良吉影 用户身份 北航一位普普通通的学生党 用户动机 希望能有一个美观、迅速且无需手动导入的软件来查询课表、空教室、成绩等信息 用户困难 教务系统需要电脑操作，且界面透露出过时的气息，手机端的北航小程序运行速度慢 典型场景 通过手机查询自己的课表等信息 用户比例 40% -
经常忘记DDL的冒失同学
用户信息 用户情况 姓名 广濑康一 用户身份 经常忘记课程中心作业截止时间的同学 用户动机 希望能有一款产品时刻查看、提醒自己作业DDL，且无需手动导入 用户困难 课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦 典型场景 通过手机端直接收到了作业DDL的截止信息，立马投入工作 用户比例 40% -
对定制化有要求的同学
用户信息 用户情况 姓名 岸边露伴 用户身份 对软件的自定义有一定偏好的同学 用户动机 希望教务软件能够按照自己的需求进行一定的定制 用户困难 课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦 典型场景 上课周将主界面设置为课表，考试周结束后将主界面自定义为成绩 用户比例 20%
功能描述
| 模块 | 功能介绍 |
|---|---|
| 登录绑定 | 使用北航的统一认证账户登录，即可在APP上看到数据。当然密码错误是看不到的。 |
| 课表查询 | 自动从教务网站获取课表并展示 |
| DDL查询 | 自动从课程中心网站获取所有课程的“作业”信息并展示 |
| 成绩查询 | 自动从教务网站获取学生成绩并查询，同时计算GPA和加权平均分 |
| 主页设置 | 用户可以自定义主页需要展示的内容 |
| 版本更新 | 当软件有更新时，会自动提醒到用户 |
预期目标用户数
- 发布一周内注册用户数：200人
- 发布一周内主动查询次数：1000次
下面是实际使用人数统计。注册人数在5月4日达到222人，可以认为达到了用户数量指标。
而主动查询次数是下述四种查询的总和，同学们的查询次数远远高于我们的预期，我们可以认为达到了指标。
| 时间 | 注册人数 | 课表访问次数 | 成绩访问次数 | ddl访问次数 | 空教室访问次数 | 登录次数 |
|---|---|---|---|---|---|---|
| 4/29 16:00 | 61 | 2300 | 445 | 241 | 60 | 174 |
| 4/29 20:00 | 133 | 3989 | 788 | 429 | 81 | 316 |
| 4/30 18:00 | 157 | 5243 | 941 | 588 | 85 | 399 |
| 5/1 18:00 | 213 | 6710 | 1164 | 716 | 98 | 505 |
| 5/2 18:00 | 223 | 7252 | 1233 | 810 | 98 | 520 |
| 5/3 18:00 | 226 | 7432 | 1250 | 848 | 110 | 525 |
| 5/4 18:00 | 222 | 7678 | 1265 | 896 | 112 | 527 |
用户反馈
由于发布时的疏忽，没有在软件发布时一同发布调查问卷，所以收集的反馈信息均是通过发布渠道的反馈直接获取的，如大班群的回复，朋友圈的评论等。
发布阶段一周，我们统计到的典型反馈如下：
| 反馈类型 | 内容 |
|---|---|
| 新需求 | DDL可选择已完成内容不显示 |
| 新需求 | 添加校车、校历查询 |
| 新需求 | 添加意见栏 |
| 新需求 | 开发ios版 |
| 优化 | 优化服务器登录速度 |
| 优化 | 报错信息更加准确 |
团队管理
分工协作
我们团队没有将开发和测试人员分开，而是让每部分的开发人员兼任测试，这是考虑到我们需要开发的板块本身就较多，且功能之间沟通性强，可以由不同的开发部分之间进行互相测试。
团队分工如下：
| 人员 | 岗位 | 职责 |
|---|---|---|
| 乔玺华、单彦博、张艺璇 | 前端 | 进行Android软件界面开发 |
| 胡彬彬、李嘉铖 | 后端 | 进行服务器交互逻辑代码编写 |
| 杜博玮 | 爬虫 | 负责从教务获取学生数据存到数据库 |
| 郭骏 | PM | 监督工作、写博客 |
在近一个月的开发测试过程中，我们这套团队制度的优点和不足都有所体现，也让我们吸取了不少的经验教训。
- 优点：开发效率高，部门之间通过接口交流，耦合度低，测试出bug时能够很快定位到bug所在。
- 缺点：由于缺乏专门的测试人员，只是在每个功能上线前进行本地测试，难以产出课程组想要的测试数据，如代码覆盖率等，同时测试方面有所不足，在测试阶段修复大量bug。
项目管理
我们的项目在GitHub上分为两个repo，分别是前端和后端。前端和后端的所有代码签入均需要通过Pull Request来进行，而PR需要经过code review后才能够合并进master分支。这样可以避免代码的更新不及时导致的各种git冲突，也能让写好的代码得到二次审查。
而我们项目所有的任务、bug等，均通过issue来发布。PR会和issue进行绑定，从而将代码和任务一一对应。issue记录着团队的开发历程，贡献分等数据均通过issue计算得到。
取舍平衡
我们想做的事情有很多，但是由于时间、资源、质量等限制，不可能在Alpha阶段一一做到。因此，我们对项目所能想到的开发任务进行了优先级排序，优先级排序的理由如下：
- 用户安全为先，功能支持为后（用户信息加密）
- 程序可用为先，功能点缀为后（版本更新提示）
- 功能有用新奇为先，传统为后（课程中心DDL查询）
- 易用亲民为先，庞杂纷繁为后（课表查询、成绩查询）
- 疫情期间有用为先，无用为后（被搁置的博雅课堂、校车时间表）
最终，形成了我们现在的功能列表。因为我们的任务是在Alpha阶段交付最小可用版本，所以难免会出现一些功能上的缺陷和不足，有待我们后续阶段的迭代开发改进。
代码管理
程序测试
我们对后端进行了单元测试，测试用例47个，测试覆盖率78%。
测试覆盖率不算很高，其主要原因有：
- 覆盖率插件对所有代码都进行了检测，但是Django框架下有很多“无用”的代码，即使用正常的Django测试用例是无法触发的错误，例如manage.py中的exception。
- 有一个空模块test_query，原本规划做考期考表查询，但是现在无法获取相关数据，于是就空在那里了，也没有进行测试。
- 爬虫的登录错误，例如网络错误，IP封禁等，在本地无法通过常规单元测试复现，所以登录模块测试率较低。
我们录制了单元测试的视频以供播放。
前端没有进行单元测试，因为Flutter框架不同于原生Android，没有合适的覆盖率插件来帮助我们进行测试。且前端本身逻辑较为简单，常规的用户使用已经足够测出许多错误。所以前端的测试通过在测试阶段有限分发我们的apk安装包来进行。
代码规范
Alpha阶段，我们没有对代码规范提出过多的要求，例如没有使用pylint，checkstyle等工具来强制要求代码风格。但是，我们对最基本的缩进、空格和注释有所要求。
- 后端所有的缩进、空格使用方式应当符合pylint规范，变量、函数命名均使用小写+下划线。
- 前端使用dart语言，所有的代码规范向Java靠拢，变量命名使用驼峰命名法。
- 所有的代码文件都需要注释。
为了尽快交付可用版本，我们在代码规范上做了许多让步，目前阶段对组员的要求只有这些。后续阶段会考虑引入代码风格审查器。（其实有个GitLab平台是最好的）
文档撰写
前端没有专门编写文档，只是在每个文件中写了该文件内容的注释。文件位置遵循flutter框架的规范。
后端的接口文档相对非常详细，写在后端repo的README.md中。
这些文档都是为了部门之间能够更好地交流沟通而开发的文档，定义和描述了对外的接口、使用方式，所以后端有详细的文档，而前端没有。如果Beta阶段有新的组员加入接手，或者项目有下一届同学接手，可能需要阅读我们的代码注释，而非接口文档。
继续开发指导性
就目前而言，我们的文档对开发的指导性不足。但是，如果有下一届同学接手我们的项目，并且具备相关框架的基础知识，是能够很容易上手我们的项目的。原因如下：
- 我们使用的是现成的框架，启动方式是现有框架的常见启动方式，无需我们在文档中赘述。
- python后端有requirements.txt，可以帮助其他同学很快的配置我们的项目依赖。
在有些安装存在坑点的地方，可能确实需要我们的文档进行指导。不过我们暂时不想让其他同学能在新环境下运行我们的代码，所以有些只存在本地/服务器上的配置脚本没有放进repo。一个用于配置爬虫环境的脚本展示如下：
在项目顺利结束时，我们会把这些内容一并完善，放入repo，从而解决迭代开发问题。
用户沟通
需求分析
我们的目标用户是一般的北航本科生，所以在开发阶段，我们寻找用户做需求分析，主要是通过聊天软件直接询问身边的人。大部分同学给我们的反馈是“做一款像同袍一样的软件就好”。当年有一款成功的软件作为先驱，不仅是同学们的需求思路，甚至连我们的开发思路都是沿着先驱者走过的路在走。所以我们最开始部署的功能，均是同袍已有的功能。
后来，了解到大家在疫情期间经常通过课程中心提交作业，DDL繁杂，很容易遗忘，所以我们应大家的需求，开发了课程中心DDL的功能。目前来说，我们的软件创新性依然不够，开发者和用户的思维都很容易被前人的成功所限制。
我们认为，用户的提需求方式是被动的，即他们不会从虚无中创造需求，而是在我们已经给出软件初版时添加需求。在规划阶段，我们从用户收到的内容较为有限，而在软件真正发布之后，我们才收到了一些有意思的需求提案。后续阶段，我们也会一边做，一边寻求用户反馈。
数据分析
我们对从用户收集到的数据，画出了用户数量随时间变化的折线图。
数据验证了我们如下的假设：
- 通过大班群、朋友圈等推广，可以带来短暂的爆发式用户增长，但是很难保持用户的稳定增长，且如果没有人传人的主动转发，用户范围较难跳脱出开发者的交际圈。
- 五一黄金周期间，使用人数和注册人数都会相应减少。
- 空教室查询现阶段确实没人用。
数据也带来了我们不希望看到的情况：
- 用户数量在减少。用户数量减少意味着，有同学修改了自己的统一认证账户的密码，且修改后没有再次使用我们的软件。这些用户应当没有从我们的软件中获得任何好的体验，且对我们的软件保持不信任的态度。这类用户的出现，每一个都是对我们的打击。
- 用户数量稳定后，每位用户每天平均只打开1次我们的软件。这样的活跃度让我们深知自己的不足，没有创造出能够绑定用户每天使用的功能。
数据告诉我们，需要开发出能够提高用户粘度的功能，让用户多使用我们的软件。同时，需要想办法让用户将我们的软件推广到自己的交际圈中，实现软件使用的“人传人”。可能会考虑加一个“一键分享”按钮等。
软件发布
发布文档：（博客发布公告）
https://www.cnblogs.com/se2020djlj/p/12800303.html
发布位置：大班群，朋友圈。
用户反馈截屏：
最终燃尽图：
我们认为，燃尽图较为真实的反映了我们项目的状态，项目如同燃尽图一样平稳推进。因为燃尽图绑定了issue，而issue绑定了PR，所以燃尽图上的每一个节点，都是我们的代码。
但是，有一些设计不太合理的issue，比如测试之类的issue，比较笼统，不知道何时应该点完成，或者谁来点击完成，所以会有一两条issue的误差。
团队贡献
虽然说按照课程组要求给出了量化贡献，但是以下量化贡献和我们的打分依据有所出入。具体的打分规则请详见Alpha阶段贡献分评分博客。
我们的评分思路遵循以下原则：
- 不同开发部门之间的代码行数、PR数目等不能直接比较。
- 综合考虑Bug数开发issue数目。
- 不对开发完成的时间做出奖励。
| 姓名 | 贡献分 | 量化贡献 |
|---|---|---|
| 乔玺华 | 50 | 代码行数2220，Pull Request 21个，Bug 2个，额外开发issue 4个 |
| 张艺璇 | 48 | 代码行数1780，Pull Request 13个，Bug 2个，额外开发issue 2个 |
| 单彦博 | 51 | 代码行数4011（包含框架打底代码），Pull Request 21个，Bug1个，额外开发issue 2个 |
| 李嘉铖 | 47 | 代码行数1502，Pull Request 42个，Bug 3个，额外开发issue 2个 |
| 胡彬彬 | 52 | 代码行数1582，Pull Request 32个，Bug 2个，额外开发issue 4个 |
| 杜博玮 | 49 | 代码行数2116，Commit 49个，Bug 9个，额外开发issue 5个 |
| 郭骏 | 53 | PM，会议记录18篇，博客作业9篇，服务器管理 |
功能展示
我们的软件在Alpha阶段最有特色的功能，也是最受好评的功能，便是DDL查询了。
应该可以在答辩时使用模拟器演示。
关于用户反馈的bug：
其一是登录时容易出现“服务器错误”，可能是教务抽风，也有可能是后端服务器顶不住压力。在我们换了登录方式后，此类情况得到了缓解。
其二是课表、课程中心解析有问题。因为教务对课表的表现格式千奇百怪，所以对于我们无法分析的课程，其教师、教室信息等均会显示“未知”。同时，当我们察觉到有这种课表出现的时候，我们会对其进行针对性修改，尽量不影响到用户使用。
总结
所学到的
- 团队的力量是伟大的，众人拾柴火焰高，可以做到许多难以想象的事情。
- 庞大的任务可以分解为多个小任务，逐个击破。
- 软件质量、运行速度、开发时间很难做到三者兼优，取舍和得失也是敏捷开发的魅力。
- 给北航学子一个DDL，真的可以创造奇迹。
课程建议
- 团队里的人都非常努力，也都热爱这个项目，跳槽非常难选人，是否可以让部分组不换人？
- 做推广、发布是一个不小的门槛，用户群体越广阔的项目反倒更对推广无所适从。是否可以考虑降低用户数量的评分标准？
Beta阶段展望
- 重构爬虫。目前使用的Selenium框架太吃服务器内存。
- 完成用户提出的改进建议功能。
- 更加强调代码规范和文档撰写。
- 制作课程评价功能。
- 考虑将项目部署到GitLab。
