[软工顶级理解组] 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。
[软工顶级理解组] Alpha阶段项目展示的更多相关文章
- [软工顶级理解组] Beta阶段项目展示
目录 团队成员 软件介绍 项目简介 预期典型用户 功能描述 预期目标用户数 用户反馈 团队管理 分工协作 项目管理 取舍平衡 代码管理 程序测试 代码规范 文档撰写 继续开发指导性 用户沟通 需求分析 ...
- [软工顶级理解组] Alpha阶段测试报告
[软工顶级理解组] Alpha阶段测试报告 在测试过程中发现了多少Bug? 测试阶段发现并已修复的bug: 尚且存在,但是难以解决或者不影响使用的bug: 计算重修课程的时候,如果重修课程的课程号和原 ...
- [软工顶级理解组] Alpha阶段事后分析
目录 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 质量提高 会议截图 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰 ...
- [软工顶级理解组] Alpha阶段团队贡献分评分
评分总表 下述表格适用于前端.后端.爬虫开发者的评分,基础分数为50分,在此基础上进行增减. 类别 程度 加减分 准时性 提前完成 +0 按时完成 +0 延后完成,迟交时间一天内或未延误进度 -2 延 ...
- [软工顶级理解组] Beta阶段事后分析
目录 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 质量提高 会议截图 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰 ...
- [软工顶级理解组] Beta阶段团队贡献分评分
贡献分评分依据 下述表格适用于前端.后端.爬虫开发者的评分,在此基础上进行增减. 类别 程度 加减分 准时性 提前完成 +0 按时完成 +0 延后完成,迟交时间一天内或未延误进度 -2 延后完成,迟交 ...
- [软工顶级理解组] Beta阶段测试报告
在测试过程中发现了多少Bug? 测试阶段发现并已修复的bug: 尚且存在,但是难以解决或者不影响使用的bug: 计算重修课程的时候,如果重修课程的课程号和原课程号不同,则GPA计算会出现误差.但我们无 ...
- [软工顶级理解组] 团队任务拆解(Alpha)
一.任务概述 在alpha阶段,我们需要完成功能规格说明书中所提到的所有功能,在一个阶段的开发周期内,交付最小可行的可用版本. 二.任务分配及时长 分组&成员 具体任务 预计时长(小时) 前端 ...
- [软工顶级理解组] 团队规划和任务拆解(Beta)
目录 需求再分析 功能增减 管理改进 任务分解 人员管理 需求再分析 在Alpha阶段,我们的产品得到了用户的广泛好评,但是还是存在一些问题. 登录不稳定,登录速度慢等问题:这是北航VPN本身的不稳定 ...
随机推荐
- Python - 面向对象编程 - __del__() 析构方法
del 语句 Python 提供了 del 语句用于删除不再使用的变量 语法 del 表达式 删除变量的栗子 var = "hello" del var print(var) # ...
- WPF 过渡效果
http://blog.csdn.net/lhx527099095/article/details/8005095 先上张效果图看看 如果不如您的法眼 可以移步了 或者有更好的效果 可以留言给我 废话 ...
- Linux系列(33)- rpm命令管理之RPM包校验提取(5)
校验 格式 rpm -V 已安装的包名 选项: - -V:校验指定RPM包中的文件(verify) 例子 rpm -V httpd 后, 无任何提示, 代表该文件没有被做任何修改 # 判断本地的apa ...
- Park-2018论文
太阳射电图:Solar magnetograms, EUV images, GOES X-ray flux data. Magnetograms: http://solar-center.sta ...
- javascript 比较版本号大小 字符串
* 不用系统比较大小的函数 // 不考虑字母 function s2i(s) { return s.split('').reduce(function(a, c) { var code = c.cha ...
- MySQL修改root密码的多种方法, mysql 导出数据库(包含视图)
方法1: 用SET PASSWORD命令 mysql -u root mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpass ...
- python实现rtsp取流并截图
import cv2 def get_img_from_camera_net(folder_path): cap = cv2.VideoCapture("rtsp://admin:admin ...
- nginx 利用return实现301跳转
第一种: server { location / { rewrite ^/(.*)$ http://www.baidu.com/$1 permanent; } } 第二种: server { loca ...
- vue three.js 结合tween.js 实现动画过渡
参考地址:https://www.jianshu.com/p/d6e3b4b153bb https://www.jqhtml.com/10513.html 官方文档:https://github.co ...
- 鸿蒙内核源码分析(中断切换篇) | 系统因中断活力四射 | 百篇博客分析OpenHarmony源码 | v42.02
百篇博客系列篇.本篇为: v42.xx 鸿蒙内核源码分析(中断切换篇) | 系统因中断活力四射 | 51.c.h .o 硬件架构相关篇为: v22.xx 鸿蒙内核源码分析(汇编基础篇) | CPU在哪 ...