[软工顶级理解组] Beta阶段项目展示

团队成员
软件介绍
团队管理
代码管理
用户沟通
- 需求分析
- 数据分析
软件发布
团队贡献
功能展示
总结
- 所学到的
- 课程建议

团队成员

郭骏（https://www.cnblogs.com/sharinka0715/）

普通程序员预备一枚。喜欢编程，想要做软件。担任过计组助教，进行过一段时间的网页后端开发。自己没事也喜欢鼓捣一些无聊的小脚本、小程序。

希望在软件工程这门课上能够做出自己未曾实现过的级别的软件，相信团队的力量。

目前掌握技术：C/C++， Java， Python控制台编程，C# Winform开发，Django后端开发，（一定程度上的）Linux服务器维护

职位：PM

李嘉铖（https://www.cnblogs.com/bakahentai/）

什么都会一点但是什么都不精通，非ddl玩家，喜欢提前把任务做完。

希望在软件工程的项目上可以通过担任测试的岗位，学习其他人的代码风格和编程思想，提高自己的编程能力、设计测试用例的能力、执行自动化测试的能力，提高项目软件的质量。

目前掌握技术：C/C++， Java， Swift， Ruby和基础Rails框架， Python控制台编程

职位：后端开发

单彦博（https://www.cnblogs.com/shanyanbo/）

精通C语言，能熟练使用java，python，c++等语言，作为组长组织过无线网络系统项目的编写和集成，对团队工作有一定经验。本学期是我第二次参加团队项目，希望能有更多收获。

目前掌握技术：C， C++， Java， Python， Ruby on Rails.

职位：前端开发

胡彬彬（https://www.cnblogs.com/ilwf/）

能够熟练使用C，C++，python，java等语言，曾做过数据库课设，对于MySQL有一定的了解，自己也比较喜欢计算机图形学相关知识。在这次想进行前后端开发。

目前掌握技术：C，C++，Java，Python，MySQL

职位：后端

张艺璇（https://www.cnblogs.com/zhyixuan/）

个人属于ddl玩家，不过希望且愿意接受push。上学期安卓课上做过一点客户端开发。在这次软工中希望和大家一起做意思的项目，学习团队合作的经验。在这次团队项目中想做前端或者测试的工作。

目前掌握技术：C/C++， Java， python，安卓客户端开发

职位：前端开发

杜博玮（https://www.cnblogs.com/cuogeihong/）

C/C++，Java，Python均有所涉及，会用其中一部分内容。写代码时经常上网查函数定义。

我希望在这次软件工程的项目中担任前端或者后端的开发。有了PM和测试人员的存在，在团队中进行开发工作可以使我得到更多的收获。

目前掌握技术：C/C++，Java，Python，MySQL

职位：爬虫开发

孙旭东（https://www.cnblogs.com/ring-of-sun/）

来自高工大三计算机专业的老笨比，会使用python，C++，Java等编程语言，具有爱运动和死肥宅的双重属性，喜欢社交，为人友善，希望能在软件工程这门课上学到新知识，交到新朋友。

职位：前端开发

软件介绍

项目简介

这里是航胥，一款更懂你的教务助手。

Beta阶段发布声明

我们团队做的是一款集课表查询、空教室查询、成绩查询、课程评价、校历查询、课程中心DDL查询等教务服务为一体的北航教务助手APP。

预期典型用户

北航普通学生

用户信息	用户情况
姓名	吉良吉影
用户身份	北航一位普普通通的学生党
用户动机	希望能有一个美观、迅速且无需手动导入的软件来查询课表、空教室、成绩等信息
用户困难	教务系统需要电脑操作，且界面透露出过时的气息，手机端的北航小程序运行速度慢
典型场景	通过手机查询自己的课表等信息

经常忘记DDL的冒失同学

用户信息	用户情况
姓名	广濑康一
用户身份	对日期和DDL不敏感的同学
用户动机	希望能有一款产品时刻查看、提醒自己作业DDL，且无需手动导入
用户困难	课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦
典型场景	通过手机端直接收到了作业DDL的截止信息，立马投入工作

对定制化有要求的同学

用户信息	用户情况
姓名	岸边露伴
用户身份	对软件的自定义有一定偏好的同学
用户动机	希望教务软件能够按照自己的需求进行一定的定制
用户困难	课程中心没有手机相关的适配，且电脑端访问课程中心比较麻烦
典型场景	上课周将主界面设置为课表，考试周结束后将主界面自定义为成绩

想评价课程的同学

用户信息	用户情况
姓名	东方仗助
用户身份	很想了解课程评价，以及参与评价的同学
用户动机	希望能有一个有学校开设课程信息的软件，供大家分享不同课程的口碑
用户困难	目前市面上没有这种东西，只能靠大家在微信群口口相传
典型场景	通过航胥来查询课程评价

功能描述

模块	功能介绍
登录绑定	使用北航的统一认证账户登录，即可在APP上看到数据。当然密码错误是看不到的。
课表查询	自动从教务网站获取课表并展示
课程评价	对北航开设的课程进行打分、评论、给老师点赞，且可以对评价进行点赞
DDL查询	自动从课程中心网站获取所有课程的“作业”信息并展示
DDL通知	我们会在DDL截止前24小时向您的手机发送推送通知，提醒您完成DDL
校历查询	查询学校校历，并与课程中心DDL结合，显示待办事项
用户反馈	在软件内设置页面获取用户意见和建议
成绩查询	自动从教务网站获取学生成绩并查询，同时计算GPA和加权平均分
主页设置	用户可以自定义主页需要展示的内容
版本更新	当软件有更新时，会自动提醒到用户

预期目标用户数

发布一周内注册用户数：400人
发布一周内主动查询次数：4000次

下面是实际使用人数统计。因为我们的推广方式是朋友圈等社交网络，所以在Alpha阶段，组员社交圈内的用户数量已经趋于饱和。Beta阶段使用朋友圈和大班群推广无济于事。

为了进一步扩宽用户，我们组员尽力发给了所有认识的外系的同学，包括但不限于1系、2系、3系、4系、17系、21系、高等理工学院、高研院等。最终，我们的用户数定格在此表。

时间	注册人数	课表访问次数	成绩访问次数	DDL访问次数	空教室访问次数	登录次数	校历
发布前	210	0	0	0	0	0	0
6/3	262	2799	333	180	16	94	292
6/4	285	3809	475	259	18	129	353
6/5	301	4549	652	330	19	158	413
6/6	347	5787	987	415	26	313	492
6/7	355	6338	1080	467	26	324	532
6/8	377	7174	1204	548	30	355	588
6/9	379	7547	1259	578	31	359	605

用户反馈

在Beta阶段，我们设置了用户反馈页面，用户可以直接在个人中心—用户反馈页面将对软件的意见反馈到服务器后台。如果是BUG方面的反馈，我们会及时进行修复。其他方面的反馈如图所示：

团队管理

分工协作

我们团队没有将开发和测试人员分开，而是让每部分的开发人员兼任测试，这是考虑到我们需要开发的板块本身就较多，且功能之间沟通性强，可以由不同的开发部分之间进行互相测试。

团队分工如下：

人员	岗位	职责
孙旭东、单彦博、张艺璇	前端	进行Android软件界面开发
胡彬彬、李嘉铖	后端	进行服务器交互逻辑代码编写
杜博玮	爬虫	负责从教务获取学生数据存到数据库
郭骏	PM	监督工作、写博客

在近一个月的开发测试过程中，我们这套团队制度的优点和不足都有所体现，也让我们吸取了不少的经验教训。

优点：开发效率高，部门之间通过接口交流，耦合度低，测试出bug时能够很快定位到bug所在。
缺点：由于缺乏专门的测试人员，只是在每个功能上线前进行本地测试，难以产出很详尽的测试数据。不过在Beta阶段项目框架完成，开发技术趋于熟练之后，Alpha阶段在测试阶段爆出大量BUG的现象不复存在。这代表着我们团队的磨合更上了一层楼。

项目管理

Repository

将前端和后端的仓库分开，分别维护不同语言的代码，以不同的标准进行开发。
Pull Request & Code Review

所有代码签入使用PR进行，而所有PR需要经过负责人的Review。这样可以有效避免提交冲突，且代码复审会减少设计阶段出现的bug数量。
Issue

我们项目的所有任务放在Issue中，每个Issue都绑定着对应的开发人员，且有PR的Issue都会和PR绑定。Issue的性质和工作量标签可以帮助我们更好的进行项目的时间管理，在计算贡献分时也有更加具体的数据。
Code Style

前端遵循Dart语言的一般代码规范。由于Android Studio没有合适的适配Dart语言的Checkstyle配置文件，所以我们主要靠AS自带的Reformat功能对缩进换行等进行限制，而变量名、程序结构等其他风格由组员自行维护。

后端和爬虫使用Python，我们使用pylint和pylint-django第三方包对代码进行静态检查，并配置了适合于我们项目的.pylintrc配置文件。目前提交到主分支中的每一个commit都要求通过代码风格检查。
GitHub Action

后端和爬虫的代码中设置了GitHub的Action，每次commit或merge时自动触发。Action会检查代码风格，并运行Django单元测试。如果有一项不通过，则PR不会允许通过，需要重复修改。
Documentation

除了在仓库的主目录下编写合适长度的README.md文件，我们项目的所有文档维护在GitHub Wiki中。Wiki文档中包括编译运行指导、接口规格说明、错误处理说明、更新日志等详细信息。

取舍平衡

我们想做的事情有很多，在Beta阶段我们依然无法一一完成。我们在纠结中，选出了以下几个功能作为优先开发项：

用户呼声较高的内容

校历查询、意见栏、iOS版（因为苹果开发者账号688一年被劝退）
效率问题

爬虫彻底重构——从selenium换成requests包，内存占用大大降低，并且登录速度大大提升。所使用的爬虫服务器数目由4个降低到2个。
“杀手功能”

课程评价——我们项目规划时的核心，也是和DDLKiller项目组试图区分开的功能
不得不放弃的功能

考期考表查询，因为一直到发布阶段才出数据，所以在这之前爬虫没法做，我们也无法实现。

博雅课程功能，因为本学期博雅叫停，无法测试，所以我们没有实现相关功能。

代码管理

程序测试

Alpha阶段单元测试：测试用例47个，测试覆盖率78%。

Beta阶段单元测试：测试用例94个，测试覆盖率88%。

使用django-coverage工具测试覆盖率，我们录制了单元测试的视频以供播放。

前端没有进行单元测试，因为Flutter框架不同于原生Android，没有合适的覆盖率插件来帮助我们进行测试。且前端本身逻辑较为简单，常规的用户使用已经足够测出许多错误。所以前端的测试通过在测试阶段有限分发我们的apk安装包来进行。

代码规范

Alpha阶段，我们没有对代码规范提出过多的要求。Beta阶段，我们吸取了之前的教训，有了一定的进步。

前端遵循Dart语言的一般代码规范。由于Android Studio没有合适的适配Dart语言的Checkstyle配置文件，所以我们主要靠AS自带的Reformat功能对缩进换行等进行限制，而变量名、程序结构等其他风格由组员自行维护。

后端和爬虫使用Python，我们使用pylint和pylint-django第三方包对代码进行静态检查，并配置了适合于我们项目的.pylintrc配置文件。代码风格检查在GitHub平台上使用Action功能进行了自动化部署，每个commit都需要通过代码风格检查。

为了改进我们Alpha阶段堪称混乱的代码风格，我们在Beta阶段伊始引入pylint时，将一条条报错suppress的过程，工程量几近重构。但是最后做出来的成果是值得的，如今的代码非常整齐清爽，格式整齐。

文档撰写

在之前已经提过。除了在仓库的主目录下编写合适长度的README.md文件，我们项目的所有文档维护在GitHub Wiki中。Wiki文档中包括编译运行指导、接口规格说明、错误处理说明、更新日志等详细信息。

继续开发指导性

如果有下一届同学接手我们的项目，并且具备相关框架的基础知识，是能够很容易上手我们的项目的。原因如下：

我们使用的是现成的框架，启动方式是现有框架的常见启动方式。
我们的文档中有对新手较为友好的编译指导说明，可以帮助用户上手我们的项目。
我们的文档中有详细的功能和结构说明，代码中也有足够的注释来指导新人上手。
抛弃selenium后，我们的依赖安装过程几乎不存在难点，只需要用pip安装requirements.txt即可上手。

用户沟通

需求分析

从立项开始调研到的需求“做一款像同袍一样的软件就好”，我们在Alpha阶段靠着方便的DDL查询功能，吸引到了200位用户，也展现出了我们能和同袍、北航小程序等不一样，我们有我们的优势。我们更快捷、功能更多样、迭代开发更及时、界面更丑。

但Alpha阶段收到的用户反馈较少，依然没有什么新功能，所以我们只能沿着我们先前规划的道路走。通过之前提到过的一番取舍之后，我们最终产出了现在的项目。

数据分析

我们对从用户收集到的数据，画出了用户数量随时间变化的折线图。

可以看到，因为我们在发布的一周中每天都在推广，所以我们的数据增长较为平稳。但总的来说，没有达到我们的预期400人。其主要原因有：

没有像预期一样开发出iOS版本，导致没有争取到占比不小的iOS用户。
考期阶段，大家对课表查询、课程评价等的需求大大降低，而可能有高需求的内容（比如考表查询等）我们并没能实现。

软件发布

发布文档：（博客发布公告）

https://www.cnblogs.com/se2020djlj/p/13034817.html

发布位置：大班群，朋友圈，委托进行“口口相传”。

用户反馈截屏：

最终燃尽图：

（后端最后一个是PM的贡献分统计）

我们认为，燃尽图较为真实的反映了我们项目的状态，项目如同燃尽图一样平稳推进。因为燃尽图绑定了issue，而issue绑定了PR，所以燃尽图上的每一个节点，都是我们的代码。

前端的曲线相较于预测实线偏上，原因是当时前端存在部分技术难题，加上大家计网实验比较忙，卡了比较久的时间，在之后催更一波进度之后渐渐好转。

团队贡献

我们的评分思路遵循以下原则：

不同开发部门之间的代码行数、PR数目等不能直接比较。
综合考虑Bug数开发issue数目。
不对开发完成的时间做出奖励。

下面是Beta阶段个人代码提交量。代码行数使用git log输出，等于增加行数减去删除行数。只计算5月12日之后的commit。

贡献分评分参考之前的规则，具体评分博客在此。

姓名	贡献分	量化贡献
孙旭东	53	代码行数1411，Pull Request 12个
张艺璇	51	代码行数1926，Pull Request 8个
单彦博	48	代码行数818，Pull Request 22个
李嘉铖	52	代码行数823，Pull Request 30个
胡彬彬	47	代码行数611，Pull Request 11个
杜博玮	50	代码行数813，Commit 46个
郭骏	49	PM，会议记录14篇，博客作业9篇

功能展示

在答辩时使用模拟器演示。

我们Beta阶段的特色功能——校历和课程评价，是我们着重需要介绍的部分。

总结

所学到的

团队的力量是伟大的，众人拾柴火焰高，可以做到许多难以想象的事情。
庞大的任务可以分解为多个小任务，逐个击破。
软件质量、运行速度、开发时间很难做到三者兼优，取舍和得失也是敏捷开发的魅力。
给北航学子一个DDL，真的可以创造奇迹。
无脑撸代码不是唯一，代码规范、项目管理、合理规划、充分调研都是软工不可或缺的部分，磨刀不误砍柴工。

课程建议

做推广、发布是一个不小的门槛，用户群体越广阔的项目反倒更对推广无所适从。如果没有用户量的要求，课程内是否会有更多的组选择开发更有意思的项目呢？
如果课程组认可，我们的软件是否可以交由下一届继续开发？