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

标签：有意思   结束   坑点   strong   操作   roi   服务器   变量命名   速度慢   

团队成员

郭骏

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

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

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

功能描述

预期目标用户数

• 发布一周内注册用户数：200人
• 发布一周内主动查询次数：1000次

下面是实际使用人数统计。注册人数在5月4日达到222人，可以认为达到了用户数量指标。

而主动查询次数是下述四种查询的总和，同学们的查询次数远远高于我们的预期，我们可以认为达到了指标。

用户反馈

由于发布时的疏忽，没有在软件发布时一同发布调查问卷，所以收集的反馈信息均是通过发布渠道的反馈直接获取的，如大班群的回复，朋友圈的评论等。

发布阶段一周，我们统计到的典型反馈如下：

团队管理

分工协作

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

团队分工如下：

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

• 优点：开发效率高，部门之间通过接口交流，耦合度低，测试出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数目。
• 不对开发完成的时间做出奖励。

功能展示

我们的软件在Alpha阶段最有特色的功能，也是最受好评的功能，便是DDL查询了。

应该可以在答辩时使用模拟器演示。

关于用户反馈的bug：

其一是登录时容易出现“服务器错误”，可能是教务抽风，也有可能是后端服务器顶不住压力。在我们换了登录方式后，此类情况得到了缓解。

其二是课表、课程中心解析有问题。因为教务对课表的表现格式千奇百怪，所以对于我们无法分析的课程，其教师、教室信息等均会显示“未知”。同时，当我们察觉到有这种课表出现的时候，我们会对其进行针对性修改，尽量不影响到用户使用。

总结

所学到的

• 团队的力量是伟大的，众人拾柴火焰高，可以做到许多难以想象的事情。
• 庞大的任务可以分解为多个小任务，逐个击破。
• 软件质量、运行速度、开发时间很难做到三者兼优，取舍和得失也是敏捷开发的魅力。
• 给北航学子一个DDL，真的可以创造奇迹。

课程建议

• 团队里的人都非常努力，也都热爱这个项目，跳槽非常难选人，是否可以让部分组不换人？
• 做推广、发布是一个不小的门槛，用户群体越广阔的项目反倒更对推广无所适从。是否可以考虑降低用户数量的评分标准？

Beta阶段展望

• 重构爬虫。目前使用的Selenium框架太吃服务器内存。
• 完成用户提出的改进建议功能。
• 更加强调代码规范和文档撰写。
• 制作课程评价功能。
• 考虑将项目部署到GitLab。

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

标签：有意思   结束   坑点   strong   操作   roi   服务器   变量命名   速度慢   

原文地址：https://www.cnblogs.com/se2020djlj/p/12833560.html