[软工*理解组] Alpha阶段项目展示

目录

• 团队成员
• 软件介绍
  • 项目简介
  • 预期典型用户
  • 功能描述
  • 预期目标用户数
  • 用户反馈
• 团队管理
  • 分工协作
  • 项目管理
  • 取舍平衡
• 代码管理
  • 程序测试
  • 代码规范
  • 文档撰写
  • 继续开发指导性
• 用户沟通
  • 需求分析
  • 数据分析
• 软件发布
• 团队贡献
• 功能展示
• 总结
  • 所学到的
  • 课程建议
  • Beta阶段展望

团队成员

郭骏

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

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

目前掌握技术：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。