概述

Beta 阶段评分,按照之前的规则,主要组成部分为:

  • 博客部分,基于 Beta 阶段博客的评分(每篇正规博客 10 分,每篇 Scrum5 分,评定方式类比往年)
  • 评审部分,基于 Beta 阶段展示、答辩以及现场工作的评分(150 分)
    • 现场评分。基于现场点评给出的排名进行打分,以此分项评级并打分,全员以及大众评审团(除参与复审的人员之外,即韩滏婧、刘紫涵、刘取齐、赵博名、胡绪佩五位助教、各个小组以及大众评审团成员)都将参与,总计 50 分(评审整体规则见:Beta阶段现场评审规则及表格,表格见:Beta现场评审表格
    • 复审评分。基于客观上限定的给分点进行专业性更高的打分,仅由部分主要助教和老师(暂定:罗杰老师、任建老师、刘乾、张少昂、刘阳、周雨飞)共同参与,总计 100 分(目前的参考评分标准:Beta阶段复审规则及表格,评审表见:Beta阶段复审表格

上述评分组成的具体详情见后文。

评分

博客评分

博客部分评分整体上参考2020年Beta阶段评分规则,其中

  • 功能规格说明书技术规格说明书发布说明测试报告事后分析,满分为 10 分,各团队之间作业质量进行对比,最高得 10 分,最低得 0 分。
  • 每日例会博客的评分规则为:
    • 满分为 5 分;
    • 报告每个人的工作、燃尽图、每日例会的照片三个部分,并且内容属实的,得满分;
    • 少任何一个,或者某一项内容不真实,扣除 2 分,以此类推,扣完为止;
    • 若某一项内容不完整,酌情扣 1 分;
    • 对于格式混乱的情况,酌情扣 1 分;
    • 迟交两周以内,得 0 分;
    • 迟交两周或更多,倒扣全部分。
团队名称 功能规格说明书(10) 技术规格说明书(10) 发布说明(10) 测试报告(10) 事后分析(10) 每日例会博客(一次5分) 合计 排名
1 2 3 4 5 6 7
谜语人队 10 9 10 7 9 4 3 5 4 5 5 5 76 7
发际线和我作队 10 9 10 8 9 5 5 5 5 5 5 4 80 3
美滋滋甜兮兮队 10 10 10 10 10 4 5 5 5 5 5 5 84 1
万里阳光号 8 7 9 10 8 5 5 5 5 5 5 5 77 5
是兄弟就来摸鱼 9 9 10 10 8 3 5 4 5 4 5 4 76 7
助教团队 10 9 10 10 9 5 4 4 4 5 5 4 79 4
删库跑路对不队 10 9 10 10 10 5 5 5 5 5 5 5 84 1
荡起双桨 9 10 8 7 9 5 5 5 5 5 5 4 77 5

现场评分

评审规则

本次现场评审部分基本规则如下所示:

评分说明 评分方式与要求
现场展示质量
  • 到场情况——团队成员是否有无故缺席的情况?
  • 展示效果——现场讲解、回答问题的水平如何?
  • 互动意愿——现场互动的积极性和质量如何?
  • 采用评级方式,依据如下
    • A——优秀,无无故缺席情况,现场展示效果优秀,且互动积极
    • B——良好,无无故缺席情况,现场展示效果良好,有一定的互动
    • C——一般,存在人员无故缺席,或展示效果欠佳,完全无讲解以外的互动
    • D——较差,存在较多人员无故缺席,或展示内容令人难以理解
  • 理由要求
    • 对于 C、D 档,必须明确说明理由,不少于 20 字
软件质量
  • 需求指标——需求指标是否合理?
  • 数据真实性——所展示的用户量、日活等数据是否真实?有多大的水分?
  • 软件效果——软件是否可以较好且便捷的解决用户的需要?
  • 指标完成度——预定的需求指标完成程度如何?
  • 采用评级方式,可参考以下标准
    • S——卓越,需求指标合理且有挑战性,软件效果极好,且大幅度超额完成需求指标(原则上不少于300%)或做出了长远贡献(成功的开源、被认定为官方应用、得到融资等)
    • A——优秀,需求指标合理且有挑战性,软件效果优秀,可以较好解决用户需求,圆满完成了需求指标(原则上不少于95%)
    • B——良好,需求指标合理,软件效果良好,可以解决用户的需求,基本完成了需求指标(原则上不少于80%)
    • C——一般,需求指标较低,软件效果一般,可以解决用户部分需求,面向了用户且勉强完成了部分需求指标(原则上不少于50%)
    • D——较差,需求指标很低,软件效果较差,难以解决用户大部分需求,完成的需求指标量很低或未面向用户。
  • 评级要求
    • S 共计不超过 1 个
    • S、A 总计不超过 3 个
    • 同一评级不超过 3 个
  • 理由要求
    • 无论任何评级都必须详细说明理由,不少于 40 字
软工质量
  • 软件性能——软件经过测试和实际运行,能达到什么样的高性能水平?
  • 软件可靠性——系统可以保证多大程度上的持续运行?团队是否有压测?是否有收集错误反馈的相关机制?
  • 软件安全性——软件有多少维持系统本身安全的能力?有多少保护用户数据安全的能力?
  • 工程可扩展性——代码架构如何?是否配备了单元测试?整体代码质量如何?是否有长期持续维护这一质量的手段(如CI中运行单元测试)?
  • 工程可维护性——代码风格如何?注释完整性如何?文档是否完善?整体工程质量如何?是否有长期持续维护这一质量的手段(如CI中运行代码风格检查)?是否配有自动构建/打包/发布/部署等环节?
  • 采用评级方式,可参考以下标准
    • S——卓越,软件性能极高,可靠性经测有很大的余量,安全性高,可扩展性极高且配备完整的持续化手段,可维护性极高且配备完整的持续化手段
    • A——优秀,软件性能优秀,可靠性完全满足要求,安全性高,可扩展性较好且有一些持续化手段,可维护性较好且有一些持续化手段
    • B——良好,软件性能满足要求,可靠性没有大问题,安全性较高,可扩展性满足持续扩展的要求,可维护性满足持续开发的要求
    • C——一般,软件性能有少量问题,可靠性存在少量问题,有一定的安全风险,可扩展性较低,可维护性较低
    • D——较差,软件性能难以满足基本需求,可靠性较差,有高危的安全风险,可扩展性很低,可维护性很低
  • 评级要求
    • S 共计不超过 1 个
    • S、A 总计不超过 3 个
    • 同一评级不超过 3 个
  • 理由要求
    • 无论任何评级都必须详细说明理由,不少于 40 字
综合 基于上述三方面,给出一个整体的排名
  • 采用排名方式
    • 需要与各部分的评级相匹配,保证最基本的合理性

助教1

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 A β阶段日活跃用户为40人 A 前端设计精美、丰富,特别是引导页面。
总体完成效果好,较好地满足了目标需求。
针对文本和音频的可视化特殊性太强。
A Gitlab 使用情况好,milestone、issue 设置合理,说明详细、燃尽图真实、较好地完整完成了计划任务。
代码风格检查、CI/CD 使用情况好。
2
发际线和我作队 A 发布一周后,下载量 200-300,活跃用户量 50-100 B 游戏完成度较好、可玩性强,按计划完成任务。游戏存在出现概率较大的 bug。 B 讨论过的 apk 过大的问题仍未解决。软件可靠性一般。 5
美滋滋甜兮兮队 A 一周后用户量 300 S 对需求目标完成情况良好,对项目进一步推广、拓展、立项。数据真实性强,给出的日活、用户量等数据已自行去除水分,软件整体质量效果好。 S 项目管理详细、真实。几乎针对每个 issue 都有具体内容的说明和关联信息。也给出了许多值得学习的精彩范例。 1
万里阳光号 B 注册人数 200-300 人,活跃用户数 100-200 C 软件存在较为明显的小 bug,应当在早期测试中就发现。
软件在一些小问题上的处理方法不够简洁、使用感受一般。
C 使用多种工具进行项目文档管理。
测试方面展示出的工作内容不太充分。
gitlab 上的 issue 较少。
8
是兄弟就来摸鱼 B 发布一周内使用次数达到 300 C 顺序练习时只要退出后再次进入时又会从第一道开始 C 代码仓库的使用情况不够好。CI/CD 的使用情况一般。 6
助教团队 A 一周日活 200,两周日活 300 B 界面与 alpha 相比,更加人性化,而且支持移动端。
部分功能,如疫情相关机构的搜索功能,提示不明显。
整合各种数据源。
A 团队的分工计划表格具体、详细,团队成员贡献记录详细。
测试完善,完成了对多种设备的适配性测试,可靠性好。
3
删库跑路对不队 A 制作了生动精美的展示宣传视频。 日活用户为 400 A 宣传力度大、手段丰富 B 没有做代码风格检查,代码管理使用整体放入一个仓库与各部分分别仓库结合的方法,项目文档详细、规范。 4
荡起双桨 A 发布一周网页端用户量 200-400 C 实际的应用效果一般,不太能识别出询问的相关主题。 B 没有做代码风格测优,使用项目管理工具情况一般。 7

助教 2

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 A 展示效果较佳,互动积极,回答问题流畅有重点 β阶段日活跃用户为40人 B 考虑了多种数据类型,进行了相应的可视化,较好解决了用户的需求,但日活离预定指标还有一点差距,未给用户在使用上给出更好的指导 A 分工较明确,issue 粒度划分较细,采用 CI/CD 进行了较完整的单元测试和代码规范检查。 3
发际线和我作队 A 展示效果佳,制作了小视频。互动较好。 发布一周后,下载量 200-300,活跃用户量 50-100 B beta 阶段增加了游戏的随机性和趣味性,实现了多人联机功能。基本解决了轻量级、联机等需求,日活达到预期指标,但软件存在一些小 bug。 C 采用了 Plastic SCM+git 两种工具进行管理。单元测试覆盖率达 98%。数据库 中存放的是明文密码,安全性稍有欠缺。 6
美滋滋甜兮兮队 A 制作了 demo 视频,展示充分有重点。互动阶段,对答如流。 一周后用户量 300 B 软件功能全面, 完整性较高。在 alpha 的基础上进行了很多细节的优化。累计用户达 253 人,与预定指标有一点差距,但在有效宣传之后有望完成指标。 A 以 issue 和石墨文档进行管理,对 issue 的具体进展情况进行实时追踪,流程清晰。进行了单元测试和压力测试。对前端采用了 CI/CD,但整体部署不完善,仓库管理存在部分未整理的东西。 2
万里阳光号 B 展示效果较好,有互动 注册人数 200-300 人,活跃用户数 100-200 C 基本完成预期功能,注册人数完成了预期指标,但真实日活的数据尚存疑。软件存在一些小 bug,交互有些不流畅。 C 摒弃了轮值 PM 的制度。基于飞书和 gitlab 进行项目管理,但 issue 粒度较大。对各位同学的工作进行组内互评。进行了单元测试和压力测试,并部署了 CI。 8
是兄弟就来摸鱼 A 展示效果较好,制作了视频 发布一周内使用次数达到 300 B 累计注册用户达到 408 人,达到预期;日活量平均 100 人左右。打卡和成就系统不错。 B 项目管理流程清晰,并进行了文本规范。部署了 CI/CD,但并不完善。 5
助教团队 A 展示效果较佳,互动积极 一周日活 200,两周日活 300 A 目标用户明确,基本解决了用户的需求,出色地完成了日活等指标。相关的功能较全面,提供了一些人性化的优化,但新增的出行建议界面略显简陋。 C 利用 issue 进行项目管理,issue 划分粒度合理,但任务完成的跟踪情况并不好,很多 issue 下并没有评论。CI/CD 并没有实际上用上。 4
删库跑路对不队 A 制作了视频,视频质量很高,并做了视频总结。 日活用户为 400 A 日活达到 200,但预期指标可能较高,具有挑战性。功能覆盖全面,界面也非常优美,实时判题和统一判题功能优秀。 S 项目管理优秀,划分为题士,产品主页和后台管理三个项目分别管理。部署了 CI/CD,测试覆盖率高 1
荡起双桨 B 展示较好,有一定的互动 发布一周网页端用户量 200-400 C 产品累计浏览次数超过 300 次,活跃注册用户 30 人左右,与预期。项目难度可能较大,实现的功能并不完善,未能很好地解决用户的需求。 B 项目拥有完整的文档和清晰的存档结构,拥有全面的开发文档。项目部署了 CI/CD 进行自动化测试。 7

助教 3

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 A 没有什么太大问题,听得清,项目展示到位,做了的的功能都展示出来了 β阶段日活跃用户为40人 B 相比于上一阶段有了非常大的改进,不过小问题还有一些,突然出现的英文标签以及不会收回的悬浮框,可改进地方不少。 S 少昂都夸了那没啥好说的了 3
发际线和我作队 A 这个视频我很喜欢,有那感觉了,这次发言的同学相较于上次也更自信了,讲的很不错。 发布一周后,下载量 200-300,活跃用户量 50-100 A 加入了更多的棋子以及联机对战让可玩儿性变高了很多,虽然用户们反馈的一些问题例如屏幕还没解决,但总体质量不错,我也亲自玩儿了一下,我比较喜欢的是他们的想法,这种结合炉石和自走棋,对运气,运营,和对卡组的理解三者缺一不可,是一种不错的玩儿法。 C 其实我本来想给 B,但我感觉这个明文密码还是有点儿问题的,属于比较大的安全性问题了,此外关于 git 的使用雅哲说的也有可以借鉴提高的地方。 4
美滋滋甜兮兮队 A 远航唯一的问题是语速有点儿快,其它都挺好。 一周后用户量 300 S 该软件在 alpha 阶段后吸取了广大用户的意见进行了改进,虽然目前还存在 bug,但其功能完备,能满足绝大多数用户需求。上一次 alpha 阶段我的质疑点在 A4 纸背单词法是否真的有效,但经过询问我外交学院的同学,他认为该项目有意义,能提高背单词效率。此外该软件还成功申请了大创,有开创性的贡献。因此我认为该软件非常优秀。 A 给 A 主要是我在实际使用时感觉复习时加载速度有点儿缓慢,同时还有一些 bug 存在,所以稍微扣一点儿分,此外代码管理里.idea 和不同分支没 merge 也有点儿问题。 1
万里阳光号 A 讲的听清楚的 注册人数 200-300 人,活跃用户数 100-200 C 折线图显示有问题,扇形图标题和模板有重合,交互不流畅 B gitlab 的测试 milestone 开了但是进度为 0,gitlab 的 milestone 普遍开的 issue 较少 6
是兄弟就来摸鱼 A 发言老哥声音蛮好听的,中气很足,展示到位 发布一周内使用次数达到 300 C UI 相较于上一阶段变好看了很多,但由于这个项目比较特殊,有直接的对比小组,因此在我看来这个组做的远不及题士(功能,界面),工作量感觉也不是很大 C 文档有点儿草,git 管理不太到位,基本把所有放到了一块儿。 8
助教团队 A 可能是录播的问题,声音很小,断断续续的,有点儿影响观感。 一周日活 200,两周日活 300 B 我在 alpha 阶段认为该项目的问题是工作量,很多要完成的任务我看都没完成,而 beta 阶段适配了移动端以及优化界面解决了一部分问题,但我感觉之前画的大饼没吃完,还有工作可以去完成 C 理由同上,CI/CD 甚至是基本 failed。 5
删库跑路对不队 A 图文并茂,qsy 语速也很适中,回答问题很清晰 日活用户为 400 A 我大概试了一下,首先主页已经吸引了我,真的很不错。相比于单词组,其实这两个软件我认为都很不错,个人我更喜欢单词组的创意,因此给题士第二名 A 我个人没发现啥问题,感觉不错 2
荡起双桨 A 其实可以在博客里多做对比,而不是让观众去回想你们 alpha 阶段的界面,这样不直观,其他都不错 发布一周网页端用户量 200-400 C 我个人不是很懂 NLP,但我使用感觉是这个 AI 也并不是很智能(甚至我都认为这不能算个合格的 AI 产品的验收标准),如下图

B git 也没有 merge,老问题 7

助教 4

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 A β阶段日活跃用户为40人 A 展示效果与实际体现相符合,对于现有的数据集可视化软件做出了改进,其支持数据集管理的特点在未来有利于发展成为社区模式,具有较大的前景和空间,但是美中不足的是既然已经调研到了其他软件有 leaderboard 的功能,可以考虑提供对公开数据集榜单的支持。 A 完备的前后端开发以及文档管理,每一条 MR 的分类和具体做的事清晰明了,无论是 unittest 还是 os 兼容性测试都非常完善,如果有在线的发布就可以是 S 级别了 1
发际线和我作队 A 发布一周后,下载量 200-300,活跃用户量 50-100 C 首先承认其工作量,开发一款游戏从建模到各个流程和步骤的编写是十分困难的,但是就是因为想要做好一款游戏所需要花费的时间和人力巨大,在软件工程这一门一个学期的课程上想要做到一款有可玩性的游戏还是比较仓促,目前从展示视频看来受限于玩法的单一,真正开始战斗之后用户的参与度可能不足(个人主观感受,本身对卡牌类游戏不是很感冒),还有一定的开发空间。 D CI/CD 中仅看到对后端少有的一点 unittest 以及缺少 linttest,unity 部分没有任何测试。MR 和 Issue 的管理比较迷惑,对仓库介绍的欠缺,仓库中 .vscode 和 pycache 的存在,以及隐患无穷的明文密码存储。 8
美滋滋甜兮兮队 A 一周后用户量 300 A 社区的建立让我对 A4 记单词更加耳目一新,创新的分享和 fork 词图让网页端的 A4 记单词有其存在的价值,对于一开始可能怀疑的为什么能比纸质记单词好的一系列疑问不攻自破。
为什么没有 S 级:选题的价值决定了评级的上限,背单词的软件就算做成现在这种可以进行大创立项的较为完备的产品,还是缺少其作品的内在价值,大概是雪中送炭>锦上添花的意义
B 比较可惜的是没有找到线上 CI/CD 的解决方案,本地的 CI/CD 不太具有说服力,不能做到每次 submit 都触发的回顾测试和单元测试。文档的整理和前后端都比较齐全。MR 的使用方式虽然不是不行,但是挺令人疑惑的。 2
万里阳光号 A 注册人数 200-300 人,活跃用户数 100-200 B 首先从开始就没有真正回答心中的疑惑,为什么要在手机上绘制图表,这种繁琐的需要手动选择数据调节的事项,最后的成品来看虽然 beta 有较于 alpha 的改进,但是受限于手机的屏幕大小和操作性,图表的展示也没有特别吸引用户的地方,也没有非常的特色。 C 缺少 unittest 和 codelint 部分,仓库缺少说明,对 .DS_Store 等文件没有进行过滤,后端仓库给人一种凌乱的感觉,里面有各种类型的文件和表意不明的 commit 内容。前端完全没有配置 CI/CD,不太清楚是如何进行单元测试和发布的。 7
是兄弟就来摸鱼 A 发布一周内使用次数达到 300 B Beta 阶段的产出相较于 Alpha 阶段有了明显的改进,微信小程序的各项功能也非常齐全,比赛模式也具有特色,但是相较于其他组的选题上还是差了一点,核心的刷题功能确实很难做出创新。 C unittest 和 linttest 全是失败,但是 MR 和 issue 部分做的比较细致,仓库如果能将前后端和文档分开会更好一些。 6
助教团队 A 一周日活 200,两周日活 300 A 非常有意义的工作,将疫情的动态通过各种展示方式呈现出来,但是时效性可能存疑,比如 6 月 20 日中国总计接种超 10 亿次,网站依然是 9.6 亿,对于一个健康相关的工具类的网站而言,时效性应该放在首位。 C unittest 全是失败,install 步骤中也有 cannot stat 的错误。MR 信息没有含义,仓库中存在 .vscode 等没有过滤的无用信息。 4
删库跑路对不队 A 日活用户为 400 B 整个软件的完成度达到了要求,各种功能也非常完备,但是从选题的意义出发还是没有达到 A 的水平,毕竟前有 Questionor 和航概斩,同期有自救题库,后有 ios 航概,差异化在 ui,核心功能比较雷同。 A 非常完备的 unittest 测试,细致的文档管理和仓库管理,前后端和文档如果能拆分成为不同的仓库可能会更好。Issue 和 MR 部分做得非常细致。 3
荡起双桨 A 发布一周网页端用户量 200-400 C 目前的产品从使用的体验来说感觉还可以真正称作 AIBot,当然受限于较短的开发时间和 AI 问答自身的学习开发难度,想要做到可以流畅问答不太现实。对于特色的静态代码检查功能感觉实现比较仓促,从有一些没有翻译的英文提示来说感觉就是一个套壳的其他网站的 API 调用,可以再细化一下包括翻译警告和提示。 B unittest 覆盖率只有 50%,注册邮箱缺少验证,仓库中前后端和文档最好分开,MR 和 issue 部分无功无过。 5

助教 5

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 展示比较枯燥但基本到位。互动回答问题也比较正常。 β阶段日活跃用户为40人 B 日活数据完成度达 90%,软件效果良好,基本功能完成指标比较合理。 A 软件安全性满足基本要求,没有较为出彩的说明该问题,软件测试比较完善 3
发际线和我作队 B 演示情感饱满,表述清晰。有 demo 视频演示,直观易懂。 发布一周后,下载量 200-300,活跃用户量 50-100 B 日活数据完成度较好,其他需求指标也完成较好。 B 软件测试模化有提及,覆盖率达 98%,比较突出。
传输虽然加密,但是数据库中是明文存储,安全性影响较大。
5
美滋滋甜兮兮队 A 声音洪亮,demo 视频展示较为直观清晰,互动积极。 一周后用户量 300 A 用户量较高,同时指标计算合理,日活数据正常,并且访问量及宣传方面完成的非常优秀。 A 安全性较高,测试比较完善,全程 git 管理存在瑕疵。 2
万里阳光号 B 展示动图具体讲解,声音洪亮,但回答问题还需要提高。 注册人数 200-300 人,活跃用户数 100-200 B 用户量较为合理,功能部分存在部分缺陷,指标完成还算正常,但计算不够完美严谨。 C 测试及安全性可靠性问题还存在一些,代码风格存在缺陷,git 使用还有一些问题。 7
是兄弟就来摸鱼 B 声音洪亮,感情饱满,动图 demo 演示直观清晰。 发布一周内使用次数达到 300 B 宣传手段不错,各个用户量指标完成的也非常不错。 C 代码仓库管理不够好,工程性有些欠缺,CI/CD 使用存在一些问题。 8
助教团队 B 展示内容较为全面,声音洪亮,视频播放存在一定问题。 一周日活 200,两周日活 300 A 用户指标完成较不错,用户留存率较高,很不错。 C CI/CD 使用及仓库代码属于仓促完成,数据仓库使用存在部分问题,git 使用不够好。 6
删库跑路对不队 A 展示视频非常新颖有趣直观,但内容还不够完整充实。 日活用户为 400 S 日活 200+,虽然和预期有些差距,但是还是非常不错,宣传手段很丰富。 S CI/CD 使用较好,并且代码仓库管理也很不错。 1
荡起双桨 A 声音洪亮,展示逻辑较好 发布一周网页端用户量 200-400 B 技术壁垒较强,功能完善,并且用户指标完成度较高。 B 代码仓库较为规范,相比 alpha 阶段进步很大。 4

谜语人队

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 β阶段日活跃用户为40人
发际线和我作队 B 不同同学对不同方面问题回答,现场交活跃。 发布一周后,下载量 200-300,活跃用户量 50-100 B 增加了联网、教程,用户活跃较好。 C 1、CI/测试浮于表面。
2、明文存储密码存在较大安全隐患(托库等)。
3、缺乏对于代码风格的规范。
4、一方杀后台时,可导致联机对象 app 异常,同样体现了测试的覆盖不到位。
4
美滋滋甜兮兮队 A 展示效果佳,现场活跃,回答较完备。 一周后用户量 300 S 1、对于 alpha 版本中出现的问题均做了有效的修复。
2、推广效果较好,手段丰富,但最终用户量未达到预期,是一个遗憾。
3、软件需求实现较好,功能丰富,整体上圆满达成目标。
B 1、CI 中使用 root 用户外部登录,可能会出现安全性问题。
2、CI 上流程缺失单元测试,但在大数据量上也可以理解。
3、各文档较为分离,可上手性不太高。
4、开发过程进度把握较好,记录详细。
1
万里阳光号 C 展示比较单薄,对软件的整体效果无明显展示,比较迷惑。 注册人数 200-300 人,活跃用户数 100-200 C 1、需求:分析了三个新功能和两个旧功能对应的需求和改进。
2、日活数据良好,用户反馈较多。
3、语音功能存在 bug。
C 1、轮值 PM 转为指定 PM,使用飞书进行统一管理,有互评保证质量但未坚持。
2、存在文档和单元测试覆盖率未呈现在 CI/CD,无 checkstyle
3、测试不充分。
6
是兄弟就来摸鱼 B 1、展示时间把握不合理
2、对产品介绍全面
发布一周内使用次数达到 300 B 1、参加比赛功能较为新颖,也比较全面。
2、前端界面有待加强。
3、用户量达标。
4、实现了多学科题库,可满足不同学生的需求。
C 1、在开发过程中文档、测试、代码规范都有使用,较好。
2、压力测试未涉及。
3、没有将各端区分测试。
4、文档比较混乱,应加强管理。
5、CI/CD 不合理,未起到理想效果。
3
助教团队 B 1、对产品介绍较完整。
2、视频无法播放
3、未展示具体效果
一周日活 200,两周日活 300 C 1、预测功能较为新颖,但准确度?
2、与 Google 平台相比?
3、可视化不够完整,性能问题比较严重。
D 1、未使用 CI/CD(基本上)。
2、仓库未分开,分支管理较差。
5
删库跑路对不队 B 1、多个视频展示,比较丰富。
2、对产品展示较少,缺乏使用产品的展示。
日活用户为 400 A 1、产品整体较好,功能较多。
2、在细节处有一些小 bug 和风格不统一。
3、用户量达标。
B 1、有自动测试且覆盖率较高,但未作部署。
2、未进行代码风格测试。
3、文档全面模块化。
4、仓库管理有一定问题
5、测试缺少对 UI/UX 上的测试。
2
荡起双桨 C 对产品展示分析较多,效果展示较少。 发布一周网页端用户量 200-400 C 1、产品使用时出现无明确答案的情况。
2、渲染时出现了一部分问题,对分辨率适配不足。
D 1、线下交流较多,issue 粒度较细,使用 wiki 管理。
2、单元测试不充分,缺少风格检查。
3、出现安全性漏洞,对性能有影响。
7

发际线和我作队

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 C 就一个人上来,也没有视频 Demo,讲解感觉一般 β阶段日活跃用户为40人 B 对用户的需求把握可以,需求范围虽然不广,但很有针对性,确实能够满足一定指标 B 软件的可扩展性和可维护性没有看到体现,完全性看来没有问题,性能应该也没有问题 6
发际线和我作队 发布一周后,下载量 200-300,活跃用户量 50-100
美滋滋甜兮兮队 A 现场展示十分精彩,有很多交互 一周后用户量 300 A 能够很好对应影虎需求,且在发布,推广上都花了很大功夫,软件使用效果好,需求指标看来都完成的不错 A 密码等都做的十分到位,可靠性有很大的保证,对数据库保护比较到位,CI/CD 都做的很好,可维护性也很高 2
万里阳光号 B 有图文并茂的感觉,效果理想,超时了。 注册人数 200-300 人,活跃用户数 100-200 B 在用户需求方面有一定把握,该产品对市场的吸引程度应该是有的,在软件的指标完成上较好,基本对提出的需求都进行了满足 B 在测试上该团队完成较好,可靠性和安全性都没有问题,但据说 API 上因为 bug 做了一些妥协?在文档和维护上表现一般 3
是兄弟就来摸鱼 B 讲解比较中肯,感觉讲到位了 发布一周内使用次数达到 300 C 航概题库是一个面向北航的产品,走出校园、进入市场的可能性有多大呢?对任务的完成性还是较好,软件效果还行 C CI/CD 中有很多 Fail,可维护性上虽然有文档,但实际文档的可读性有待商榷,软件性能不错,可靠性团队说是可以 4
助教团队 C 展示超时,展示表现力尚可,希望多一点丰富的元素 一周日活 200,两周日活 300 B 需求指标尚可,对于用户需求,想知道该可视化在市场上的优势何在。不论竞争,但确实满足了该领域中存在的用户需求。 C 助教说近几小时还在修改?这似乎有点不合适,代码规范性和可维护性上是否优秀值得商榷,可扩展性也许是有的 5
删库跑路对不队 A 有动画展示,展示效果好,介绍比较清晰。 日活用户为 400 A 对市场把握到位,宣传尽心尽力,主页做的很好看,在题库的数量、范围,精度上都做的不错,任务指标完成突出。 A 在安全性上考量比较到位,在大量访问量之下依旧保证服务的运行,在可靠性上很优秀,在维护性软件质量上更没话说 1
荡起双桨 B 展示风格大气,展示内容丰富,展示方面广泛 发布一周网页端用户量 200-400 D 软件存在较多明显 bug,如登入密码位数提醒错误等。问答系统效果较差,测试的简单问题均未得到合理的回答 C 文档,可维护性,这些不论。可靠就没有很好的保证,从功能上无法满足很多东西,存在部分 bug 7

美滋滋甜兮兮队

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 1.无缺席
2.展示性尚可,语速稍快
β阶段日活跃用户为40人 B 1.主页比较精致
2.数据集种类少,内容单一,与科研人员的实际需求不太吻合。
3.日活用户相对较少
A 1.单元测试,CI/CD 比较完善
2.似乎没有进行压测
3.未体现本地软件运行的效果
4.可展示性、可维护性较好
3
发际线和我作队 A 1.无缺席
2.有视频,效果相对较好
发布一周后,下载量 200-300,活跃用户量 50-100 B 1.活跃用户未达到预期目标,且下载量这个指标不好追踪
2.不清楚是否满足了用户需求。
3.联机功能很有用,但好像有 bug
C 1.下载方式放在服务器上,易影响性能。
2.似乎无单元测试,CI/CD,压测 3.注释较为完善。
4.联机测试如何进行?
4
美滋滋甜兮兮队 一周后用户量 300
万里阳光号 B 1.图片较多,很丰富
2.超时
注册人数 200-300 人,活跃用户数 100-200 C 1.未达到日活等预期指标
2.多种模板内容较丰富
3.活跃用户等定义不清晰
4.用户需求定义不够明确
B 1.互评机制不错
2.进行了 CI/CD 等测试
3.安全性等方面展示不够充分
4.代码风格不太理想
6
是兄弟就来摸鱼 C 1.有视频
2.有缺席,人数不足
3.总体效果较好(贡献分显示有 7 人实际只有 6 人)
发布一周内使用次数达到 300 B 1.基本满足预期需求,CI 界面相对较简单
2.日活比较详细,数据较充实
3.总体功能较单一,杀手级功能,感觉缺乏一定实用性
B 1.文档规范良好,注释良好
2.CI、CD、单元测试、压测建议进一步评述
3.未说明软件的可靠性
4.分支管理建议做进一步完善
5
助教团队 B 1.无缺席
2.正常完成
一周日活 200,两周日活 300 A 1.功能完备,各类地图都有,出行打分功能很赞
2.值传手段很丰富
3.用户日活未完全达到预期标准,点击量这一数据说服较弱
B 1.接口说明文档很详细
2.压测效果比较好
3.未看到 CI/CD、单元测试相关内容
4.安全性未进行说明,数据
2
删库跑路对不队 B 1.视频很多
2.核心功能未得到充分展示?
日活用户为 400 A 1.主页等 UI 界面设计的比较美观
2.缺乏用户对手级功能的实用性反馈
3.用户数比较多,题库很丰富
A 1.API 文档内容比较丰富
2.对环境管理的规范比较弱
3.有 CI/CD、单元测试覆盖率较高
4.前端热区比较小?界面风格比较统一?
1
荡起双桨 C 1.有缺席,贡献分显示有 6 人,实际只有 5 人 发布一周网页端用户量 200-400 C 1.代码分析,NLP 模型比较有特点
2.注册等部分适配尚有问题
3.UI 相比 alpha 有比较大改进,但兼容性较弱
4.部分回答的针对性不够强
C 1.有相应的接口规范代码
2.单元测试覆盖率较低,无代码风格测试
3.风险未知,NLP 鲁棒性不足
4.错误反馈机制,不清楚在哪
7

万里阳光号

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 展示效果较好 β阶段日活跃用户为40人 B 数据达标,软件效果良好 A 自动化测试、自动化部署做的较好,可扩展性可维护性较好 4
发际线和我作队 C 展示效果一般互动较少感觉是在照念博客 发布一周后,下载量 200-300,活跃用户量 50-100 C 需求完成的还行,但展示数据并不能够充分证明,下载量并未提及,活跃用户采用人次有点不合理,游戏下载时速度超级,慢作为用户的轻量级显然很痛苦,下载需 50 分钟左右一段时间后需 5 小时 C 良好性能,但现场提出的闪退问题以及安全问题仍然存在,后续扩展也还可以,测试并未很充分仍存在少量问题 5
美滋滋甜兮兮队 A 现场展示效果优秀 一周后用户量 300 B 需求指标设置不合理,有严格要求的设置,所以预期用户量并不合理,显然达不到,但满足用户需求。 A 网站性能优秀,页面丝滑,可扩展性更好,后续的持续化手段也很好。软件的安全性较好,采用加密等多种方式。 1
万里阳光号 注册人数 200-300 人,活跃用户数 100-200
是兄弟就来摸鱼 B 现场展示效果良好。 发布一周内使用次数达到 300 B 注册用户、回话等数据基本达标,功能基本满足用户需求。 B 测试不完善、文档部分不完善文档,更新机制不太合理,还是有一些可以改进的地方。 6
助教团队 A 现场展示逻辑较为清晰,互动多。 一周日活 200,两周日活 300 A 接种点能够实事解决了用户的需求,用户使用人数也基本达标。 B 整体不错,git commit 不够规范文档不够,后期接手不方便,然后测试覆盖率较低,不太合规范。 2
删库跑路对不队 A 现场展示效果良好,声音清晰。 日活用户为 400 A 达到预期水平较好的解决了用户刷题的需求,但是功能还是偏简单。 B 文档较为简单,后期接手不方便。CI 测试,非常不错 3
荡起双桨 A 现场展示效果良好,用户交互多。 发布一周网页端用户量 200-400 C 界面美观挺不错,但是对大部分问题得到的解答基本无用,用户使用情况一般。 C 测试还是有一部分的,但是文档好像没看见。 7

是兄弟就来摸鱼

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 C 1.团队成员缺席一人。2。现场讲解水平尚可。3.互动积极性:只有助教老师 β阶段日活跃用户为40人 B 需求指标合理;数据真实性:√,软件效果:中英文问题;指标完成度:在某几日未完成。 B 软件性能:高性能;软件可靠性:系统可保持较高程度持续运行;安全性未发现问题,架构使用现有架构,可维护。 4
发际线和我作队 B 1.无缺席,有讲解视频,有助教,老师提问 发布一周后,下载量 200-300,活跃用户量 50-100 C 需求;有使用引导;有完成;退出程序可能存在问题 D 直接在服务器上发布下载;安全性问题:密码存储明文;代码管理存在问题 7
美滋滋甜兮兮队 A 无缺席;有详尽的解释视频;互动优良,听的清。 一周后用户量 300 A 拼写单词功能有创新点,用户量为 250 人左右,未达到目标。 S 石墨文档加 gitlab issue;前后端分离;文档代码解耦;团队管理,线下开发,测试完备;安全性可能存在问题 1
万里阳光号 B 无缺席,互动一般 注册人数 200-300 人,活跃用户数 100-200 B 画面较为美观,有静态教程;杀手级功能效果一般;达到需求指标,需求指标本身含混且较低 D 进行了基本测试,算法存在问题,只采用一个分支进行开发,单元测试覆盖率不足,代码风格不可以 6
是兄弟就来摸鱼 发布一周内使用次数达到 300
助教团队 B 无缺席,解释视频未展示,语速合适。 一周日活 200,两周日活 300 A 基本达到需求目标,需求目标较为合理,功能较为合理,数据修复。 B CI/CD 存在问题,无实质性内容,Git 版本管理较差。 3
删库跑路对不队 A 无缺席,有动画视频,互动很好 日活用户为 400 A 需求达到目标,需求高标准。 A 多分支开发。环节管理存在问题,文档安排存在问题。 2
荡起双桨 A 无缺席,听得清。 发布一周网页端用户量 200-400 B 功能较好,采用对话形式,模板形式,需求完成 C 线下交流与开发无法返回消息,功能存在问题,安全性存在问题。 5

助教团队

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 A 展示比较全面,问题的回答也比较流利。 β阶段日活跃用户为40人 B 相比 alpha 阶段,功能的完整性和全面性都有很大的提升,对目标需求的满足较好。 B 使用了 CI 工具,进行了单元测试并有自动部署功能。软件的文档也比较完整。 3
发际线和我作队 B 展示效果较好,时间控制的也不错,但问答有些不流畅。 发布一周后,下载量 200-300,活跃用户量 50-100 B 游戏的可玩性有了很大提高,并新增了联机功能,用户量基本完成目标,日活量较低。 B 软件的测试上被指出了一点问题,但总体的成果还行。版本控制做的不错,值得学习。 4
美滋滋甜兮兮队 A 展示效果不错,对问题的回答也很流利 一周后用户量 300 A 软件效果很好,宣传工作做得很不错,但是日活数量相比不是很高。软件的概念很新颖,界面的设计也很美观。 A 测试工作做的非常完备,软件的总体质量很高,软件的可靠性不错。虽然助教指出了一些问题,但总体完成度很高。 1
万里阳光号 C 展示时间掌握的一般,整体效果尚可,对问题的回答稍有卡顿 注册人数 200-300 人,活跃用户数 100-200 C 用户量达成目标,功能相比 Alpha 就有了很大完善,界面设计也丰富了很多,但美观性可以再提升。 B 做了一定的 CI/CD 工具的使用,测试工作还不够完善。软件性能不错,使用比较流畅。 6
是兄弟就来摸鱼 B 软件使用效果介绍的比较全面,详略比较得当。 发布一周内使用次数达到 300 C 功能进一步完善,用户量基本达标,使用中存在一些明显的 bug,加载速度也比较慢。 C 测试工作做得不够完善,文档的管理也有些混乱,但总体的结果完成度尚可。 7
助教团队 一周日活 200,两周日活 300
删库跑路对不队 B 项目展示良好,对问题的回答较好,可以礼貌一些,不打断他人讲话更好。 日活用户为 400 A 软件完成度较高,宣传工作做的很充分,日活用户达标,测试工作完成度高,有一些没有考虑到用户体验的地方但整体不错。 A 使用了 CI 工具,进行单元测试并自动部署功能。有专门的反馈群并经常更新软件修复 bug。 2
荡起双桨 A 项目展示较好,现场讲解表述清除,问答时多位成员都与现场进行了互动。 发布一周网页端用户量 200-400 C 平台活跃用户数较少,应加大宣传力度,且用户反馈较少;在软件使用方面,问答的准确度及范围可以进一步增大。 B 使用了 CI 进行单元测试,且进行了代码分析,管理方面比较完备,交互记录部分做得也比较好。 5

删库跑路对不队

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 存在缺席 β阶段日活跃用户为40人 B 需求指标很低且只完成 90%的需求指标,可以解决用户需求 B 性能方面无具体说明,对可靠性与安全性的要求有待提高,部署了 CI 以及进行了单元测试可靠性高。 2
发际线和我作队 A 表达清晰,有热情。 发布一周后,下载量 200-300,活跃用户量 50-100 B 日活指标未达到。需求指标合理且有挑战,用户真实,可以解决用户需求,但 UI 界面小,实现困难具有挑战性 A 作为游戏开发,量级控制较好,性能与可靠性达到一定要求,安全性有待提高以及代码风格需要完善统一。 3
美滋滋甜兮兮队 B 视频声音卡 一周后用户量 300 A 需求合理且具有挑战性,但利用 PCA4 记忆效果远不如纸质 A4 记忆效果,实际用户也说明此问题。 A 对于量级优化不够,对于项目管理上进行了一定优化。对于测试方面,不够完善,但在安全性上进行较大的投入。 4
万里阳光号 B 展示效果一般。部分内容未说明如性能可靠性。 注册人数 200-300 人,活跃用户数 100-200 B 需求合理单目标活跃用户估计不到 50%,展示使用点击次数近似日活不合理。 B 在性能处理较好,未说明其对安全性可靠性的处理方案,部署了 CI/CD,有较为规范的代码规范。 6
是兄弟就来摸鱼 B 展示效果一般。部分内容为说明如性能可靠性。 发布一周内使用次数达到 300 C 需求合理,达到使用人数,但发布的功能来看打卡不是必须的,且只是另一个小程序的子集。 C 功能单一,UI 设计与先前产品(航概题库)高度相似,测试较少,安全性较 Alpha 有所提高,但依旧欠缺。 7
助教团队 B 展示效果一般,不够激情。 一周日活 200,两周日活 300 A 需求较为合理,在疫情后期有一定需求。前端页面较为美观简洁,虽然需求指标达标,但考虑宣传受众,可以理解,功能完成度较高。 A 功能在需求前提下完成度高。对于数据处理到位。可靠性与安全性的答理较为完善。代码规范也较为到位,但管理存在一定问题。 1
删库跑路对不队 日活用户为 400
荡起双桨 A 展示效果良好,对产品重点突出到位,展示有激情。 发布一周网页端用户量 200-400 B 需求较合理,达到了使用人数,从软件使用上,对于 AI 回答,完成效果不太好,另一方面前端交互方式不太友好。 C 测试不到位,采用技术较为先进,但对于模型训练,数据集有所欠缺,前端页面较为普通,不太支持多种浏览器,但代码规范较好。 5

荡起双桨

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B β阶段日活跃用户为40人 B 软件具有良好的 UI,但关键功能(个人认为)即提供的数据数量有点少,任务难度也没有太体现。 A 团队配置了完善的 CI,包括测试、发布与部署等,且团队有统一的 PM 对团队进行管理与协调。 4
发际线和我作队 B 发布一周后,下载量 200-300,活跃用户量 50-100 B 软件效果从展示来看还可以,但以 APK 形式发布软件(且较大)仍是一个弊病。 C 首先正如助教所说,程序存在一定的安全性问题,且软件的单元测试与代码质量在展示中体现的也不完善。 5
美滋滋甜兮兮队 A 一周后用户量 300 S 团队对用户指标的定义很明确,且软件整体确实有很好的效果,提供的功能也很完善。 B 通过多个仓库实现前端、后端、接口的分离,管理清晰,但是存在明文密码打印至日志、root 运行服务器程序等问题,CI 未运行单元测试。 2
万里阳光号 B 注册人数 200-300 人,活跃用户数 100-200 C 就使用来说,虽然小程序提供了丰富的模板,但就实际使用情况来说用手机输入数据有些太不方便了,导致实际的使用体验不是特别好。 A 单元测试覆盖率较高,但与 CI 的配合较混乱。利用飞书增强项目管理。 7
是兄弟就来摸鱼 B 发布一周内使用次数达到 300 B 软件提供了刷题、比赛、打卡等功能,对处于需要军理、航概题库中刷题的人来说很有用,但适用人群还是很有限。 C CI 存在 fail,但刻意通过调整 CI 脚本使得 CI 通过,掩盖错误。 6
助教团队 A 一周日活 200,两周日活 300 A 在特殊时期下,这个网站提供的信息显得较其他项目来说有用得多,且提供的信息类型也比较全。 B 利用 CI 进行单元测试,工作进度没有及时以书面形式记录下来,issue 进用较简陋。 3
删库跑路对不队 A 日活用户为 400 A 团队的首页比较惊艳,且同时提供了程序与 APP。此外提供的题库也不局限于航概,提高了受用性。 S 前后端均有 CI 单元测试,代码规范,覆盖率较高,并且进行了压力测试。 1
荡起双桨 发布一周网页端用户量 200-400

大众评审团 1

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 展示逻辑清晰,要点明确,但缺乏互动 β阶段日活跃用户为40人 A 技术难度,实现难度合理。需求剖析合理,杀手级应用完善,但对比竞品尚缺关键优势 UI UX 不够直观 A 1、产品经过了充分、完整 的测试
2、产品分工、开发流程合理;
3、性能优化优秀可见功夫;
4、代码架构优秀,维护性好
2
发际线和我作队 B 展示逻辑清晰、有条理,多媒体展示优秀 发布一周后,下载量 200-300,活跃用户量 50-100 B 需求分析合理,目标用户完善,软件质量及技术难度合理,初级游戏雏形,团队有持久运的合理考虑 B 1、密码安全性存在漏洞,有显见的信息安全风险,但团队进行了相应的考虑
2、优化仍存在问题,安装包过大
6
美滋滋甜兮兮队 A 展示逻辑清晰,条理清楚,有吸引力,有说服力 一周后用户量 300 S 1、功能完善优秀,反馈合理
2、易用性、性能、用户友好度优秀,功能亮点多,实绩号
3、推广考虑完整,收效甚优
A 1、项目分工合理,成员贡献优秀;轮值 PM 机制合理;
2、项目管理流程符合标准,单元测试流程完善取舍合理
1
万里阳光号 B 展示逻辑清晰,但交互性较差,犹如念稿 注册人数 200-300 人,活跃用户数 100-200 C 1、功能不清晰,需求分析不明确,目标用户不明朗;
2、活跃用户数据统计方式有问题,存在疑问,量度不佳
B 1、项目管理存在龃龉,分工比较明确,但 workflow 存在问题;
2、仓库、分支、提交管理有问题
3、测试缓解考量不完善
8
是兄弟就来摸鱼 A 展示逻辑清晰,多媒体运用合理 发布一周内使用次数达到 300 A 1、需求解析优秀、交互合理;
2、精确瞄准用户需求,好用易用,功能取舍合理
3、宣传得宜,效果优秀,覆盖面广
B 1、项目管理有部分问题 commit message 存在龃龉
2、单元测试存在较大问题
3、CI 利用不合理
4、文档书写不合理
3
助教团队 B 展示清晰但缺乏交互 一周日活 200,两周日活 300 B 1、需求把握合理,考虑到位
2、精到、精致地确定了需求的范围,使产品切中肯綮
3、影响推广思路清晰合理
B 1、项目管理多有可指摘之处
2、开发流程管理混乱,commit message 不充分
3、CI 利用亦存在问题
5
删库跑路对不队 A 展示逻辑合理,借助视频优势。 日活用户为 400 B 1、项目展示逻辑美观
2、覆盖需求广泛,但缺乏针对性优化,交互颇有问题
S 项目管理流程优秀且完善 4
荡起双桨 A 发布一周网页端用户量 200-400 C B 7

大众评审团 2

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 展示顺序可优化,功能展示部分操作过快 β阶段日活跃用户为40人 A 1.软件 UI 好看,展示效果良好
2.交互良好流畅,新手使用无障碍
3.做出了差异化(用户友好、初学者友好),完成了需求指标
A 1.有完整的测试流程(单元测试、CI)
2.没有出现安全性方面的问题
3.CI 上的测试流程较完善。包括代码规范等
2
发际线和我作队 B 可以模仿游戏宣传片,逻辑不够清晰 发布一周后,下载量 200-300,活跃用户量 50-100 B 1.没有玩法/画面上的创新。同质化较高,缺少吸引用户的要素
2.UI 显示上有一些小问题,使用流程上存在问题(强制退出)
C 1.安装包过大,没有压缩素材
2.密码明文存储,存在安全性问题
3.测试流程不够完善
4.没有 ignore 缓存文件等
6
美滋滋甜兮兮队 A 展示逻辑清晰,时间安排合理 一周后用户量 300 S 1.界面简洁,用户体验良好,功能丰富,使用直观
2.完成度非常高,对竞品差异化大
B 1.软件架构清晰,扩展性强
2.存在潜在的安全性问题
1
万里阳光号 B 层次逻辑清晰,演讲时间安排可以改善 注册人数 200-300 人,活跃用户数 100-200 C 1.用户体验一般,UI 有待优化
2.没有做出区分度,和已有的竞品相比没有竞争力
B 1.测试流程完善,但缺少风格检查
2.项目管理清晰
7
是兄弟就来摸鱼 B 讲解比较沉闷,没有条理 发布一周内使用次数达到 300 A 1.成就系统比较新颖
2.UI 有待优化
B 1.CI 配置中有缺陷
2.安全性、可靠性上没有发现明显的问题
4
助教团队 B 层次逻辑不清晰,时间安排不合理 一周日活 200,两周日活 300 B 虽然有竞品对比,但感觉竞争力不大。特别是已有的常用 app 都有类似功能 B 1.commit message 信息可以改善
2.CI 部署不够完善
3
删库跑路对不队 B 层次逻辑不清晰 日活用户为 400 B 产品和官网显示效果有区别(UI 等方面),需要改进 B 缺少代码风格方面的检查(CI) 5
荡起双桨 B 演讲时间安排不合理,缺少关键部的展示 发布一周网页端用户量 200-400 C 1.适配上存在问题(自适应)
2.问题集数量少。使用体验上比较差,经常找不到相关数据
B CI 上有些不完善,缺少代码风格测试 8

大众评审团 3

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 人员是否存在缺席不明,认为无无故缺席。 β阶段日活跃用户为40人 A 不太懂深度学习这一块,从展示效果上看可以解决用户需求,基本完成了需求指标。 A 进行了一些黑箱测试,没有发现明显问题,进一步阅读代码没有找到明显的安全问题,可读性较好。 3
发际线和我作队 B 可以确定人都到齐了。 发布一周后,下载量 200-300,活跃用户量 50-100 B 功能正常,相比 Alpha 有一定进步,不过小人对砍等问题还是未解决。此外文件还是太大。 C 存在 apk 放仓库,明文存储用户密码的问题,虽然使用了 HTTPS 保护但是个人认为还是不够安全。 6
美滋滋甜兮兮队 A 可以确定人都到齐了,有比较好的互动。 一周后用户量 300 A 软件效果优秀,功能较为强大,完成了需求指标,虽然个人不太喜欢这种背词方式,但不可否认软件挑战性和优秀性。 A 有较好的安全性,仓库的设置比较合理,虽然存在包括后台 print 密码等行为但同样不可否认其优秀性。 1
万里阳光号 B 可以确定人都到齐了。 注册人数 200-300 人,活跃用户数 100-200 C 软件效果一般,界面不够美观,可以解决部分用户需求,语言识别算法不够准确,基本完成需求指标。 C 后端基于 Java,架构尚可,前端基于微信,安全性算是有保障,进行了测试,但覆盖和数据强度不足。 7
是兄弟就来摸鱼 B 可以确定人都到齐了。 发布一周内使用次数达到 300 B 软件效果尚可,比较不错的一点是有军理题库,感觉测试进行的不够充分,基本完成了需求指标。 B 一个可能的隐患是没有限制反馈文本的大小,可能会被卡,由于前端基于微信,安全性尚可。 5
助教团队 B 可以确定人都到齐了。 一周日活 200,两周日活 300 B 界面比较美观,对各平台都有较好的适配,不过修改分辨率后刷新才可见,基本解决需求指标。 B 没留用户登录等接口,自然有很高的安全性,对反馈信息等进行了校验,感觉没啥硬伤。 4
删库跑路对不队 B 可以确定人都到齐了。 日活用户为 400 A 功能强大,很好地完成了需求和指标,唯一不爽的是单选和多选,的确作者有自己的考虑,单个人认为加一项设置更好。 A 使用 HTTPS,基于微信小程序作为前端,有较好的安全性,(看代码发现 alpha 或有 sql 注入漏洞?) 2
荡起双桨 B 可以确定人都到齐了。 发布一周网页端用户量 200-400 C Windows 下无法加载,Linux 下加载成安卓的响应式,用起来比较卡,且回答的准确性不足。 C 存在安全隐患,刷新时加载全部提问信息又不限制单个信息的大小或信息数量,可能被恶意提问导致他人加载时卡在获得提问上。 8

大众评审团 4

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B β阶段日活跃用户为40人 B 最终实现效果比较完整。图片展示效果在配色上稍有不满。整体还挺不错。 A 分支管理 CI Milestone 用得不错,git 仓库也比较赶紧,无大瑕疵 3
发际线和我作队 B 发布一周后,下载量 200-300,活跃用户量 50-100 C 教程做的不完整?按钮 UI 风格不一致。“你已选择”有显示 bug。 C SSL 私钥放入仓库__pycache__Log Temp 明文存密码 6
美滋滋甜兮兮队 A 不愧是 OO 助教团队,演讲很强 一周后用户量 300 S 美观,功能强大,可以看出下了不少功夫来做,前途可期 A 模块化分离开发
轮值 PM
密码安全出现瑕疵
分支名不太好,PR 不太对
1
万里阳光号 B 注册人数 200-300 人,活跃用户数 100-200 C Bug 多,测试不足,前端图片作按钮
滚动不按页,都不太好看
C 大量 DS_Store, log_IS_UNDEFINDED 证书文件 8
是兄弟就来摸鱼 B 发布一周内使用次数达到 300 B 从α->β开发了小程序并有这样的完成是非常不容易的,不过UI方面设计和交互仍有欠缺 C failure 直接忽略过 CI 传了,idea 文件夹 5
助教团队 B 一周日活 200,两周日活 300 A 还有一点显示上的问题没有处理好,如字色、图示,左下角数没单位,功能上很丰富,手机端适配
B CI 没有用吗?别的也看不出什么问题 2
删库跑路对不队 C 好刚啊
上场要谦虚!
日活用户为 400 B 考期日历没什么用,主刷题功能用户操作没有太多改进,操作不如 IOS 版的,β阶段看不出太多改进 A 没大毛病
SSL 私钥传到仓库里不好
4
荡起双桨 B 发布一周网页端用户量 200-400 C 不太好用,不太有用,只能说没有功劳也有苦劳。只能说项目完全不明确 B 安全问题又被打了
build 文件夹不应上传,仓库只有一个
7

大众评审团 5

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 有一人未到,展示后期略仓促 β阶段日活跃用户为40人 B 日活用户数未达到总指标,指标不太合理,主页视觉效果好,网页操作方便,应用场景较广,标签很用户友好,本地端功能较为完整,但网页端功能不太全面 A 软工采用的工具较多,应用了 docker 等开发工具,gitlab ci 等工具应用合理(仍有提升空间),团队分工明确,内部文档,代码规范等较好 5
发际线和我作队 A 时间控制较好,有视频且制作精美,讲解较详细 发布一周后,下载量 200-300,活跃用户量 50-100 B 游戏设计较好,没什么大问题,有教程,对新手友好,指标基本达到,较合理,界面有美化空间 C 明文密码存储,安全性问题较为严重。
alpha-beta 阶段有改进,测试不太充分
6
美滋滋甜兮兮队 A 视频讲解占展示时间较长,宣传效果好,演讲同学声音清晰,有互动 一周后用户量 300 S 功能较为丰富,指标未完成(电脑背单词的需求量可能不大),界面美观,对背单词的视觉刺激较好,功能完善,有社区等,发展空间大,词图创意好 A 团队管理较为明确,API 文档丰富,线下开发效率较高,但组织形式有提升空间,系统功能架构较复杂,模块分解开发较好 1
万里阳光号 B 展示超市,有使用方法的动画展示 注册人数 200-300 人,活跃用户数 100-200 C 教程页面进入小程序按钮不太明显,需向下翻页(这点不太好),需求较少,指标未达到,实用性一般 C 存在一些功能上的 bug,团队管理模式责任落实的较好,CI 使用存在一些问题,gitignore 未 ignore 掉:Ds_store。commit 记录有点模糊 7
是兄弟就来摸鱼 A 讲解展示较清晰 发布一周内使用次数达到 300 B 活跃度目标达到了预期,功能完整性还行,打卡等成就机制、错题等功能很完整,完成度高 B 文档有点混乱,只有一个仓库,CI/CD 使用存在不当(很多 fail) 4
助教团队 B 演讲超时,比较清晰详细 一周日活 200,两周日活 300 A 日活指标基本完成,使用体验还可以,数据展示比较清晰实用完成度比较完整 B 最后一次 CI 未通过(mysql 启动未成功),分工、进度控制等还可以 3
删库跑路对不队 A 动画制作精美,讲解上有些粗糙 日活用户为 400 A 访问量达到标准,功能完整,社区机制完整,界面精美 A Ci 未进行风格测试,安全性好,API 文档完整,模块化 2
荡起双桨 A 展示很详细清晰 发布一周网页端用户量 200-400 C 较好完成了需求指标,界面美观程度有待提高,使用效果,回答准确率较低,适配不充分,使用价值不高 B 单元测试覆盖率不高,CI、文档等较完善 8

大众评审团 6

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 讲解略显仓促,没有突出重点,总体不错 β阶段日活跃用户为40人 B 指标较为合理,且软件效果较好,界面美观人性化,但是日活指标未达到 B 团队分工较为合理,CI/CD 流程优秀,代码检查严格,进行了多平台的测试 5
发际线和我作队 A 讲解较为详细,有视频展示环节,有一定的互动 发布一周后,下载量 200-300,活跃用户量 50-100 C 指标合理且具有挑战性,基本圆满完成,但界面和动画效果仍需要一些打磨,设计上存在不够人性化的地方 B 使用明文密码,安全性存在问题?
对 git 的使用和管理较好,测试较为完备
6
美滋滋甜兮兮队 A 录音讲解有一点模糊,讲解有点仓促,但基本清晰 一周后用户量 300 A 需求指标合理,在完成了背词网页界面优美等基本需求之后,也完成一定的兴奋需求(如词图),指标达成情况一般,完成度高,词库量大 A 对用户密码管理存在泄露可能。用看板方式协同开发较好,对多场景都进行了测试,文档丰富 2
万里阳光号 B 讲解比较清晰,有小程序功能的演示,展示超时 注册人数 200-300 人,活跃用户数 100-200 B 需求指标合理,预期目标完成度高,自动导入功能较为方便,但图标类型较少,不能完成用户需求 C 对 API 的使用缺乏测试,遗留了较为影响用户体验的 Bug,测试不够完善,团队沟通对接模式完整 7
是兄弟就来摸鱼 A 讲解清晰,功能演示完善 发布一周内使用次数达到 300 B 需求指标略低,但完成度超越指标较多,实现了刷题软件所需的大部分功能和成就鼓励机制 B 实现了前后端的分离,成员分工较为合理,文档规范还有待提高,CI/CD 测试有遗留问题 4
助教团队 A 讲解清晰,功能直接明了 一周日活 200,两周日活 300 S 需求指标较有难度,但完成度较好。界面美观,功能完善,完成了多个平台的适配,各种数据得到了直观展示对错误数据应对有缺陷 A 团队分工合理,对文档的管理较为合适,最后一次 CI 测试没有通过 1
删库跑路对不队 B 讲解过于简单,没有涉及到优势,但宣传片等部分较好 日活用户为 400 A 日活较有挑战性,达成情况一般,但有时间因素,网页和小程序界面设计较为精美 S 代码风格没有严格测试,有较好的安全性,文档管理全面规范 3
荡起双桨 A 讲解详细,能够突出重点和优势,整体效果较好 发布一周网页端用户量 200-400 C 需求指标合理有挑战性,达成情况一般,功能新颖但是部分功能有缺陷,界面美观,使用体验一般 C 有完整的前后端代码规范和文档,CI/CD 测试较为完善,在不同平台上出现了适配的问题 8

大众评审团 7

待评审小组 现场展示质量 软件质量 软工质量 综合排名
评级 理由 需求指标 评级 理由 评级 理由
谜语人队 B 有缺席 β阶段日活跃用户为40人 A 日志输出密码 A 优秀的 CI 使用(pylint +unittest+server deploy);并有压力测试和不同部署平台的相关测试。 2
发际线和我作队 B 发布一周后,下载量 200-300,活跃用户量 50-100 B 明文密码存储 C 测试单薄,代码风格无检查。

6
美滋滋甜兮兮队 A 一周后用户量 300 A 日志输出密码,服务器用 root 密码登录。
B 代码仓库整体问题。 3
万里阳光号 B 注册人数 200-300 人,活跃用户数 100-200 B C 矩阵测试只有表格,临近 ddl 才做测试,大量冗余文件,无代码风格测试。 8
是兄弟就来摸鱼 B 发布一周内使用次数达到 300 B C 屏蔽错误,先部署后测试。 7
助教团队 B 一周日活 200,两周日活 300 B 有出行指标推荐,整好很多数据源,但因为国内数据相关问题,存在实用性问题,无法应用数据修改。 C 扩展性问题,大量冗余文件,假 CI,混乱的 commit message,但有一定的 bug 管理。 5
删库跑路对不队 A 日活用户为 400 A A 1
荡起双桨 A 发布一周网页端用户量 200-400 B 神经网络数据范围优先。 B 无依赖库 list
文件夹命名
无神经网络测试
代码风格
4

总体结果

现场评审部分助教们所给出的结果为

待评审小组 助教 1 助教 2 助教 3 助教 4 助教 5 总和 排名
谜语人队 2 3 3 1 3 12 3
发际线和我作队 5 6 4 8 5 28 5
美滋滋甜兮兮队 1 2 1 2 2 8 1
万里阳光号 8 8 6 7 7 36 8
是兄弟就来摸鱼 6 5 8 6 8 33 7
助教团队 3 4 5 4 6 22 4
删库跑路对不队 4 1 2 3 1 11 2
荡起双桨 7 7 7 5 4 30 6

小组互评结果为

待评审小组 谜语人队 发际线和我作队 美滋滋甜兮兮队 万里阳光号 是兄弟就来摸鱼 助教团队 删库跑路对不队 荡起双桨 总和 排名
谜语人队 6 3 4 4 3 2 4 26 4
发际线和我作队 4 4 5 7 4 3 5 32 5
美滋滋甜兮兮队 1 2 1 1 1 4 2 12 1
万里阳光号 6 3 6 6 6 6 7 40 7
是兄弟就来摸鱼 3 4 5 6 7 7 6 38 6
助教团队 5 5 2 2 3 1 3 21 3
删库跑路对不队 2 1 1 3 2 2 1 12 1
荡起双桨 7 7 7 7 5 5 5 43 8

大众评审团所给出的结果为:

待评审小组 评审团 1 评审团 2 评审团 3 评审团 4 评审团 5 评审团 6 评审团 7 总和 排名
谜语人队 2 2 3 3 5 5 2 22 3
发际线和我作队 6 6 6 6 6 6 6 42 6
美滋滋甜兮兮队 1 1 1 1 1 2 3 10 1
万里阳光号 8 7 7 8 7 7 8 52 8
是兄弟就来摸鱼 3 4 5 5 4 4 7 32 5
助教团队 5 3 4 2 3 1 5 23 4
删库跑路对不队 4 5 2 4 2 3 1 21 2
荡起双桨 7 8 8 7 8 8 4 50 7

现场评审部分最终结果为

待评审小组 助教意见 互评意见 大众评审意见 总和 总和排名 折算分数 排名
谜语人队 12 26 22 60 3 45 3
发际线和我作队 28 32 42 102 5 40 5
美滋滋甜兮兮队 8 12 10 30 1 50 1
万里阳光号 36 40 52 128 8 36 8
是兄弟就来摸鱼 33 38 32 103 6 40 6
助教团队 22 21 23 66 4 44 4
删库跑路对不队 11 12 21 44 2 48 2
荡起双桨 30 43 50 123 7 37 7

共计分为三档,在统一档内分数按照总和差异线性映射,依次是:

  1. 第一档:删库跑路对不队、美滋滋甜兮兮队
  2. 第二档:谜语人队、助教团队
  3. 第三档:发际线和我作队、是兄弟就来摸鱼、万里阳光号、荡起双桨

复审评分

评审规则

复审部分的评分规则为分为以下四个部分:

  • 软件的质量,具体来说软件应符合用户的需求,且有实际的数据来证明用户的需求确实被满足了(40 分)

    • 预订目标合理性(10 分,并决定完成度权重)

      • 预定目标完全合理,具备足够的挑战性,令人期待——10分,系数1.0
      • 预订目标基本合理,符合北航大三学生应有的水准——8-9分,系数1.0
      • 预订目标勉强合理,给人比较保守的感觉——6-7分,系数0.8
      • 预订目标不合理,但仍有基本的标杆在——3-5分,系数0.6
      • 预订目标很荒唐,完全不重视也不想认真对待——0-2分,系数0.2
    • 预订目标完成度(30 分,最终分数会再乘上面所说的系数
      • 预订目标圆满完成(原则上不低于 95%),用户评价优秀——26-30分
      • 预订目标基本完成(原则上不低于 85%),用户评价良好——22-25分
      • 预订目标勉强完成(原则上不低于 70%),用户评价尚可——18-21分
      • 预订目标较多未完成,但仍有部分完成(原则上不低于 35%),并且面对了用户——10-18分
      • 预订目标基本未完成(低于 35%),并且面对了用户——1-10分
      • 预订目标基本未完成,并且未面对用户——0分
      • 在目标基本合理及以上的情况下,较高幅度地超额完成目标(原则上至少超额 200%以上)跳出了课程本身做出了长远性质的成果(如广泛传播的开源、获得了真实的投资等)——酌情额外加分1-5分
      • 预订目标完成情况经核实存在数据造假、谎报、拒不配合、阻挠审核等情况——无条件0分计,无视以上全部得分,并保留进一步追究其他学业不端行为的权力
      • 上述分数均需要按照预订目标合理性的系数进行打折
  • 过程的质量,具体来说软件应是整个团队按照一定的软件流程共同努力开发出来的,有相关的证据和记录展现(15 分)
    • Gitlab 使用规范性(5 分)

      • 较为完整的使用了 Gitlab Issue/Milestone 等一系列功能,并且充分利用功能特性在 Gitlab 上展开讨论与协作,且 Gitlab 组织结构合理——5分
      • 较为完整的使用了 Gitlab Issue/Milestone 等协作类功能,但 Issue 上记录不完整或讨论极少,组织结构存在少量问题(例如仓库规范性上的小问题)——3-4分
      • Issue/Milestone 等功能使用偏少且较为苍白,组织结构存在较大问题(例如没有合理分仓库或开启后未使用等情况)——1-2分
      • Issue/Milestone 等功能几乎没有使用,也没有多少维护——0分
    • 团队协同配合程度(5 分)
      • 团队内部配合高度默契,成员安排有亮点,协作得以高效推进——5分
      • 团队内部配合较好,成员安排合理,协作得以有序推进——3-4分
      • 团队内部配合尚可,有较多不当之处,但协作得以勉强维持——2分
      • 团队内部配合欠佳,普遍存在消极怠工、内部矛盾等情况,协作难以推进——1分
      • 团队内部几乎无配合,较多存在成员独走、单干等情况——0分
    • 博客互动程度(5 分)
      • 对课程组的点评一直有及时而积极地互动与讨论,问题修复及时——5分
      • 大部分情况下对课程组的点评有积极回应,并且对问题有及时的修改与反馈——3-4分
      • 时常不回应、消极回应、很慢回应评论,并且对指出的问题存在不配合或拖拉情况——1-2分
      • 经常性不回应或很久才回应评论,并且对指出的问题不加修改和反馈——0分
      • 有过一次或多次博客精彩讨论——酌情额外加1-2分,需要指明精彩讨论之处
  • 工程的质量,具体来说软件应是可维护和扩展的,并且有充分的数据和证据来展现(30 分)
    • 性能水准(5 分)

      • 定位为产品的性能,以及数量意义上的抗压能力
      • 经过实测,全功能均可以承受需求指标高出至少一个数量级的压力——5分
      • 经过实测,核心功能可以承受需求指标高出至少一个数量级的压力,其余功能均可以承受需求指标同数量级的压力——4分
      • 经过实测,核心功能可以承受需求指标同数量级的压力,其他功能可以承受基本的压力——3分
      • 经过实测,核心功能可以承受一定压力,但是无法保证能满足需求指标需要——1-2分
      • 性能水准未进行实测,或实测信息无法证明最基本的性能——0分
      • 如有测试报告存在伪造等行为——无条件倒扣5分,并保留进一步追究其他学业不端行为的权力
    • 可靠与稳定性水准(5 分)
      • 定位为产品的可靠性与稳定性,即产品可以保证多大覆盖面上的可用
      • 产品可以保证持续的可用,在基本约束限制下的任何情况都可以保持正常提供服务——5分
      • 产品可以保证基本的可用,在基本约束限制下的绝大部分情况可以正常提供服务,不会出现系统级别的停机,且在出现小问题时可以快速地恢复正常不会影响主要业务(例如出现异常后可以引导用户快速跳出并重新开始)——4分
      • 产品可以保证基本的可用,在基本约束限制下的大部分情况可以正常提供服务,在出问题时需要进行有限度的的维护才能维持运行,存在少量足以影响主要业务的问题(例如验证码发送失败将导致用户被卡死在这一步无法前进也无法后退)——3分
      • 产品经常性出现不可用的情况,经常性需要系统维护,存在较多足以影响业务的问题——1-2分
      • 产品几乎无法保证可用——0分
    • 安全性水准(5 分)
      • 定位为产品的安全性,即保证用户数据安全以及系统本身安全的能力
      • 安全性整体优秀,难以找到足以造成实质后果的安全性问题——5分
      • 安全性整体良好,存在一些安全性上的不足之处(例如对爬虫限制过弱、未配备 https 等),或存在少量且不算严重的安全性问题(例如少量非关键用户数据可以被预期外的方式获取、可以通过特定操作稳定造成系统整体波动等)——2-4分
      • 存在严重的安全性问题,可以造成系统服务崩溃、关键权限非法获取、用户数据大量泄露等严重后果——0-1分
      • 特别说明一下安全性测试的界限
        • 不要进行根本上依赖于大量资金等外部资源投入的安全测试,例如

          • DOS 攻击测试要注意限度,因为对强力 DOS 的防御主要靠的还是防火墙、CDN、服务器计算资源与带宽等资源投入量
          • 不要进行 DDOS 攻击,因为对 DDOS 的有效防御很难靠小团队力量完成,主要还得靠云平台的系统安全服务支持
        • https 应该算是标配,不然在现在的移动应用环境下,先抓包再重放,或者再顺道劫持一下客户端,就足以让接口沦陷
        • 服务器/数据库的弱口令登录、sql 注入、抓包重放等算是基本操作,属于必测项目
    • 易用性水准(5 分)
      • 定位为产品是否方便使用,给用户(尤其是新用户)的体验如何
      • 产品简单直接,用户可以基于不依赖过多的指引、介绍即可开始使用,并能很顺畅的解决需求——5分
      • 产品设计清晰,用于依赖一定程度上的指引和介绍可以顺利地解决需求——4分
      • 产品设计一般,用于在解决需求的过程中可能遇到不少的麻烦,不过也最终可以在有限的时间内解决需求——2-3分
      • 产品设计混乱,用于难以解决需求,也难以了解如何去解决需求——0-1分
    • 工程质量水准(10 分)
      • 代码质量水准(5 分)

        • 定位为工程代码本身的质量(即代码本身的可扩展、可维护性),以及长期维护这一质量的能力
        • 工程代码质量优秀,并通过 CI/CD 的形式(即必须在 CI 中运行并能报错)对代码质量进行了有效的约束——5分
        • 工程代码质量优秀,设有代码规范(需要在仓库里有约束脚本或配置文件,并能说明如何运行自动代码规范测试),但未设置自动化质量约束——4分
        • 工程代码质量良好,无明确代码规范,但有较好的可读性——3分
        • 工程代码质量尚可,配合有限度的相关人员讲解可以做到理解——1-2分
        • 工程代码质量堪忧,可读性很低,且相关人员讲解依然难以理解或相关人员也搞不清楚——0分
      • 效果质量水准(5 分)
        • 定位为工程代码的效果质量(即代码是否可以正确完成预期内工作),以及长期维护这一质量的能力
        • 配备了有效、规范的自动化单元测试,且有高覆盖率(原则上对于不少于 400 行的代码应不低于 95%,其他代码不低于 90%)——5分
        • 配备了有效、基本规范的自动化单元测试,且有一定的覆盖率(原则上对于不少于 400 行的代码不低于 80%,其他代码不少于 75%)——4分
        • 配备了相对有效的单元测试,但是规范性或覆盖率欠佳(例如有单元测试但是覆盖率明显不达标)——3分
        • 配备了单元测试,但是测试效果很低,说服力也不足(例如只是象征性的运行了一下单元测试,几乎起不到实际测试效果)——1-2分
        • 几乎未配备单元测试——0分
  • 团队在达成这些目标的过程中的努力程度(15 分)
    • 现场展示质量(5 分)

      • 现场无成员无故缺席,展示内容完整且生动,展示效果优秀,互动相当积极(至少 4 次以上质量不低的提问)——5分
      • 现场无成员无故缺席,展示内容完整充实,展示效果良好,有一定的互动(至少 1 次以上的提问)——4分
      • 现场无成员无故缺席,展示内容完整,展示效果尚可,互动较少或无互动——3分
      • 现场有组员无故缺席,展示内容有明显的不完整之处,展示效果一般偏苍白——2分
      • 现场有多名成员无故缺席,展示内容缺漏较大,效果较差——0-1分
    • 团队成员投入量(10 分)
      • 团队成员全员付出了大量努力——10分
      • 团队成员大多付出了大量努力,其他人也做出了应有的贡献——8-9分
      • 团队成员大多付出了大量努力,但存在部分人贡献过低——6-7分
      • 团队成员整体投入与付出的努力有限——3-5分
      • 团队成员整体投入甚微,甚至消极怠工——0-2分

老师 1

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 8 25 0 33 5
发际线和我作队 8 24 0 32 6
美滋滋甜兮兮队 9 27 2 38 2
万里阳光号 7 23 0 25.4 7
是兄弟就来摸鱼 7 22 0 24.6 8
助教团队 9 26 0 35 3
删库跑路对不队 9 28 3 40 1
荡起双桨 9 24 1 34 4
  • 最后一个项目的选题难度最大
  • 进取 Key 在创新创业项目中继续开发
  • 题士开源代码
  • 荡起双桨相对于 Alpha 阶段有显著改善
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 5 5 4 0 14 1
发际线和我作队 4 5 4 0 13 5
美滋滋甜兮兮队 4 5 5 0 14 1
万里阳光号 3 4 4 0 11 7
是兄弟就来摸鱼 3 4 4 0 11 7
助教团队 4 5 5 0 14 1
删库跑路对不队 4 5 5 0 14 1
荡起双桨 4 5 4 0 13 5
  • 总体上互动程度比 Alpha 阶段有了加强,主要参考了各个团队对助教最后的反馈的回复情况
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 4 4 4 4 5 5 26 3
发际线和我作队 3 3 3 4 4 4 21 8
美滋滋甜兮兮队 5 5 3 5 5 4 27 2
万里阳光号 5 4 5 3 3 4 24 4
是兄弟就来摸鱼 5 5 5 4 3 1 23 5
助教团队 5 4 5 4 3 2 23 5
删库跑路对不队 5 5 5 5 4 4 28 1
荡起双桨 4 3 4 5 3 3 22 7
  • 发际线组采用了第三方的联机服务,有服务质量上限,无需进行压力测试,建议该团队将具体限制说明,但该团队未进行明确说明
  • 摸鱼组和助教组在单元测试上基本上没有说服力,连博客上都没有截图
  • 荡起双桨覆盖率较低
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 4 9 13 3
发际线和我作队 4 9 13 3
美滋滋甜兮兮队 5 10 15 1
万里阳光号 3 9 12 7
是兄弟就来摸鱼 3 9 12 7
助教团队 4 9 13 3
删库跑路对不队 5 10 15 1
荡起双桨 4 9 13 3
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 33 14 26 13 86 3
发际线和我作队 32 13 21 13 79 6
美滋滋甜兮兮队 38 14 27 15 94 2
万里阳光号 25.4 11 24 12 72.4 7
是兄弟就来摸鱼 24.6 11 23 12 70.6 8
助教团队 35 14 23 13 85 4
删库跑路对不队 40 14 28 15 97 1
荡起双桨 34 13 22 13 82 5

老师 2

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 7 27 5 28.6 3
发际线和我作队 8 28 5 41 1
美滋滋甜兮兮队 7 27 5 28.6 3
万里阳光号 6 26 5 26.8 7
是兄弟就来摸鱼 6 26 5 26.8 7
助教团队 7 27 5 28.6 3
删库跑路对不队 7 27 5 28.6 3
荡起双桨 8 28 5 41 1
  • 依据难度分了 678 三等
  • 都很棒
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 4 4 4 2 14 2
发际线和我作队 4 4 4 2 14 2
美滋滋甜兮兮队 4 5 4 2 15 1
万里阳光号 4 4 4 2 14 2
是兄弟就来摸鱼 4 4 4 2 14 2
助教团队 4 4 4 2 14 2
删库跑路对不队 4 4 4 2 14 2
荡起双桨 4 4 4 2 14 2
  • 都值得奖励
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 4 4 5 5 5 5 28 1
发际线和我作队 4 4 4 4 5 5 26 8
美滋滋甜兮兮队 4 4 5 5 5 5 28 1
万里阳光号 4 4 5 5 5 5 28 1
是兄弟就来摸鱼 4 4 5 4 5 5 27 5
助教团队 4 4 5 5 5 5 28 1
删库跑路对不队 4 4 5 4 5 5 27 5
荡起双桨 4 4 5 4 5 5 27 5
  • 4 分密码明文
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 4 7 11 7
发际线和我作队 5 9 14 1
美滋滋甜兮兮队 4 8 12 4
万里阳光号 4 7 11 7
是兄弟就来摸鱼 4 8 12 4
助教团队 4 9 13 3
删库跑路对不队 4 8 12 4
荡起双桨 5 9 14 1
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 28.6 14 28 11 81.6 5
发际线和我作队 41 14 26 14 95 2
美滋滋甜兮兮队 28.6 15 28 12 83.6 3
万里阳光号 26.8 14 28 11 79.8 7
是兄弟就来摸鱼 26.8 14 27 12 79.8 7
助教团队 28.6 14 28 13 83.6 3
删库跑路对不队 28.6 14 27 12 81.6 5
荡起双桨 41 14 27 14 96 1

助教 6

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 6 22 1 23.6 6
发际线和我作队 7 23 0 25.4 5
美滋滋甜兮兮队 6 22 2 23.6 6
万里阳光号 8 23 0 31 2
是兄弟就来摸鱼 7 25 0 27 4
助教团队 8 22 0 30 3
删库跑路对不队 9 27 3 39 1
荡起双桨 7 17 0 20.6 8
  • 谜语人队要是能部署到pypi官方站的话,拿3分也没任何问题
  • 美滋滋甜兮兮队确实有长远贡献,不过只是一个创业比赛说服力虽有但是也有限
  • 删库跑路对不队有明确开源迹象,并且有持续计划,果断 3 分
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 5 5 3 0 13 2
发际线和我作队 4 4 4 0 12 4
美滋滋甜兮兮队 4 5 4 0 13 2
万里阳光号 4 4 4 0 12 4
是兄弟就来摸鱼 3 3 5 0 11 6
助教团队 3 4 4 0 11 6
删库跑路对不队 4 5 5 1 15 1
荡起双桨 3 4 4 0 11 6
  • 是兄弟就来摸鱼、助教团队、荡起双桨所有内容集中在一个仓库,扣分
  • 谜语人队隔三差五就不回复博客,但是整体上改进还算到位
  • 删库跑路对不队对博客回复很及时,对深度评审博客有很及时且内容翔实的回应,肉眼可见的行动力拉满,额外加一分
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 3 4 5 5 5 5 27 1
发际线和我作队 0 4 1 3 2 1 11 8
美滋滋甜兮兮队 4 5 2 4 3 3 21 4
万里阳光号 4 4 4 3 3 2 20 5
是兄弟就来摸鱼 4 4 5 5 3 1 22 3
助教团队 4 4 3 4 2 0 17 6
删库跑路对不队 5 5 5 5 3 3 26 2
荡起双桨 3 4 4 2 3 1 17 6
  • 发际线和我作队没有做压力测试的迹象
  • 发际线和我作队明文存密码,属于不可容忍级别的的安全问题
  • 美滋滋甜兮兮队有日志打印密码的行为,且服务器用root密码登录,安全问题很大
  • 助教团队缺少https,在现行网络环境下风险较大
  • 发际线和我作队的游戏产品手感还是略生涩
  • 美滋滋甜兮兮队产品上的老问题还是存在,但是易用性上有了很大的进步
  • 万里阳光号的图表软件还是没有根本上解决手机端操作困难的困局
  • 荡起双桨的AI质量肉眼可见的欠佳,解决问题的能力较差
  • 这次代码风格上大多数组普遍缺乏自动化codelint
  • 是兄弟就来摸鱼队将代码风格和单元测试直接放在末尾且允许失败,这样的测试根本形同虚设,视为没测试
  • 这次依然普遍缺乏足够有效的单元测试,自动化程度也不足
  • 美滋滋甜兮兮队和删库跑路对不队均配备了实质上有效的单元测试,但是均没有充分落实到CI上
  • 万里阳光号配备了所谓的“关键区域”单元测试,但并不是全局单元测试,在思路上存在问题
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 5 9 14 3
发际线和我作队 3 8 11 6
美滋滋甜兮兮队 5 10 15 1
万里阳光号 3 7 10 8
是兄弟就来摸鱼 4 8 12 4
助教团队 4 8 12 4
删库跑路对不队 5 10 15 1
荡起双桨 4 7 11 6
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 23.6 13 27 14 77.6 2
发际线和我作队 25.4 12 11 11 59.4 8
美滋滋甜兮兮队 23.6 13 21 15 72.6 4
万里阳光号 31 12 20 10 73 3
是兄弟就来摸鱼 27 11 22 12 72 5
助教团队 30 11 17 12 70 6
删库跑路对不队 39 15 26 15 95 1
荡起双桨 20.6 11 17 11 59.6 7

助教 7

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 6 22 0 23.6 6
发际线和我作队 8 24 0 32 1
美滋滋甜兮兮队 6 22 0 23.6 6
万里阳光号 8 23 0 31 2
是兄弟就来摸鱼 7 24 0 26.2 5
助教团队 8 22 0 30 3
删库跑路对不队 7 27 0 28.6 4
荡起双桨 7 18 0 21.4 8
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 5 5 5 0 15 1
发际线和我作队 3 4 3 0 10 5
美滋滋甜兮兮队 5 5 5 0 15 1
万里阳光号 3 4 5 0 12 4
是兄弟就来摸鱼 1 5 4 0 10 5
助教团队 1 4 4 0 9 8
删库跑路对不队 3 5 5 0 13 3
荡起双桨 3 4 3 0 10 5
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 3 4 3 5 5 4 24 3
发际线和我作队 0 4 3 4 3 0 14 8
美滋滋甜兮兮队 4 5 5 5 4 3 26 1
万里阳光号 3 4 5 2 1 2 17 6
是兄弟就来摸鱼 3 4 5 4 2 0 18 5
助教团队 3 4 3 4 1 1 16 7
删库跑路对不队 3 5 5 5 5 2 25 2
荡起双桨 3 4 4 3 3 2 19 4
  • 谜语人队压力测试不是很完善,而且实测性能没有超数量级的表现
  • 谜语人队没有使用https,安全性直接-2,其它队同理
  • 前端未做测试-1,后端未做测试-3
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 5 8 13 3
发际线和我作队 5 8 13 3
美滋滋甜兮兮队 5 9 14 1
万里阳光号 5 8 13 3
是兄弟就来摸鱼 5 8 13 3
助教团队 5 8 13 3
删库跑路对不队 5 9 14 1
荡起双桨 5 8 13 3
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 23.6 15 24 13 75.6 3
发际线和我作队 32 10 14 13 69 5
美滋滋甜兮兮队 23.6 15 26 14 78.6 2
万里阳光号 31 12 17 13 73 4
是兄弟就来摸鱼 26.2 10 18 13 67.2 7
助教团队 30 9 16 13 68 6
删库跑路对不队 28.6 13 25 14 80.6 1
荡起双桨 21.4 10 19 13 63.4 8

助教8

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 7 21 0 23.8 8
发际线和我作队 8 23 0 31 1
美滋滋甜兮兮队 7 23 0 25.4 6
万里阳光号 8 23 0 31 1
是兄弟就来摸鱼 7 22 0 24.6 7
助教团队 8 22 0 30 4
删库跑路对不队 8 23 0 31 1
荡起双桨 8 21 0 29 5
  • 大多数偏保守,部分团队过于保守
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 4 5 5 0 14 2
发际线和我作队 3 4 5 0 12 6
美滋滋甜兮兮队 5 5 5 0 15 1
万里阳光号 4 5 5 0 14 2
是兄弟就来摸鱼 3 4 5 0 12 6
助教团队 3 5 4 0 12 6
删库跑路对不队 4 5 5 0 14 2
荡起双桨 4 5 4 0 13 5
  • milestone个数和issue分配较为合理才可以
  • issue的交互记录是否充足
  • 团队合作主要看每日例会的工作分配和展示中的贡献比,部分团队的进度不足会扣分
  • 博客回复依据每篇博客回复情况计算
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 3 4 3 5 5 4 24 3
发际线和我作队 0 3 4 4 4 0 15 8
美滋滋甜兮兮队 4 5 5 4 4 3 25 1
万里阳光号 4 4 5 3 2 1 19 4
是兄弟就来摸鱼 4 3 5 4 2 0 18 5
助教团队 4 4 4 4 1 1 18 5
删库跑路对不队 4 5 5 4 5 2 25 1
荡起双桨 3 3 4 3 3 1 17 7
  • 工程质量按照助教 7 的标准来的
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 5 9 14 3
发际线和我作队 5 8 13 7
美滋滋甜兮兮队 5 10 15 1
万里阳光号 5 9 14 3
是兄弟就来摸鱼 5 8 13 7
助教团队 5 9 14 3
删库跑路对不队 5 10 15 1
荡起双桨 5 9 14 3
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 23.8 14 24 14 75.8 4
发际线和我作队 31 12 15 13 71 7
美滋滋甜兮兮队 25.4 15 25 15 80.4 2
万里阳光号 31 14 19 14 78 3
是兄弟就来摸鱼 24.6 12 18 13 67.6 8
助教团队 30 12 18 14 74 5
删库跑路对不队 31 14 25 15 85 1
荡起双桨 29 13 17 14 73 6

助教 9

小组 目标合理性(10) 目标完成度(30) 奖励分(5) 合计(40) 名次
谜语人队 5 26 0 20.6 8
发际线和我作队 6 24 1 25.2 5
美滋滋甜兮兮队 7 28 2 29.4 2
万里阳光号 7 25 0 27 3
是兄弟就来摸鱼 6 22 0 23.6 6
助教团队 7 25 0 27 3
删库跑路对不队 8 28 4 36 1
荡起双桨 7 20 0 23 7
  • milestone 用的很好
小组 Gitlab 使用规范性(5) 团队协同配合程度(5) 博客互动程度(5) 博客奖励分(2) 合计(15) 名次
谜语人队 5 4 5 0 14 2
发际线和我作队 4 5 4 0 13 4
美滋滋甜兮兮队 4 5 5 0 14 2
万里阳光号 4 4 3 0 11 6
是兄弟就来摸鱼 2 3 5 0 10 8
助教团队 2 5 5 0 12 5
删库跑路对不队 5 5 5 0 15 1
荡起双桨 4 4 3 0 11 6
小组 性能水准(5) 可靠与稳定性水准(5) 安全性水准(5) 易用性水准(5) 代码质量水准(5) 效果质量水准(5) 合计(30) 名次
谜语人队 2 4 4 4 5 5 24 2
发际线和我作队 0 3 3 5 4 4 19 7
美滋滋甜兮兮队 3 5 3 4 4 4 23 3
万里阳光号 4 4 5 3 1 5 22 4
是兄弟就来摸鱼 4 5 5 4 1 3 22 4
助教团队 4 4 5 4 2 3 22 4
删库跑路对不队 5 5 5 5 4 4 28 1
荡起双桨 3 2 4 5 2 3 19 7
  • 荡起双桨的测试接口数不多,实测部分接口比较慢
  • 谜语人压力测试过于简陋
  • 荡起双桨的服务有些挂了
  • 荡起双桨的服务有些挂了
  • 单词组明文密码与打印密码,password 打印也不符合日志规范
  • 谜语人没有对 Labels 的说明,扣一分
  • 摸鱼允许 Fail
  • 单词组的单元测试没做好
  • 单词实际体验较差 233
小组 现场展示(5) 成员投入(10) 合计(15) 名次
谜语人队 3 6 9 6
发际线和我作队 4 6 10 4
美滋滋甜兮兮队 5 8 13 1
万里阳光号 2 7 9 6
是兄弟就来摸鱼 1 6 7 8
助教团队 4 7 11 3
删库跑路对不队 5 8 13 1
荡起双桨 3 7 10 4
小组 软件质量(40) 过程质量(15) 工程质量(30) 努力程度(15) 总分(100) 排名
谜语人队 20.6 14 24 9 67.6 5
发际线和我作队 25.2 13 19 10 67.2 6
美滋滋甜兮兮队 29.4 14 23 13 79.4 2
万里阳光号 27 11 22 9 69 4
是兄弟就来摸鱼 23.6 10 22 7 62.6 8
助教团队 27 12 22 11 72 3
删库跑路对不队 36 15 28 13 92 1
荡起双桨 23 11 19 10 63 7

总表

待评审小组 教师 1 教师 2 助教6 助教7 助教8 助教9 最终得分 名次
谜语人队 86 81.6 77.6 75.6 75.8 67.6 77.367 3
发际线和我作队 79 95 59.4 69 71 67.2 73.433 6
美滋滋甜兮兮队 94 83.6 72.6 78.6 80.4 79.4 81.433 2
万里阳光号 72.4 79.8 73 73 78 69 74.200 5
是兄弟就来摸鱼 70.6 79.8 72 67.2 67.6 62.6 69.967 8
助教团队 85 83.6 70 68 74 72 75.433 4
删库跑路对不队 97 81.6 95 80.6 85 92 88.533 1
荡起双桨 82 96 59.6 63.4 73 63 72.833 7

复审部分前三名依次是:

  1. 删库跑路对不队
  2. 美滋滋甜兮兮队
  3. 谜语人队

总体评分

基于上述三项,最终的总体评分为:

待评审小组 博客 现场评审 复审 总分 排名
谜语人队 76 45 77.367 198.367 4
发际线和我作队 80 40 73.433 193.433 5
美滋滋甜兮兮队 84 50 81.433 215.433 2
万里阳光号 77 36 74.2 187.2 6
是兄弟就来摸鱼 76 40 69.967 185.967 8
助教团队 79 44 75.433 198.433 3
删库跑路对不队 84 48 88.533 220.533 1
荡起双桨 77 37 72.833 186.833 7

千帆竞发图

现场纪实

在本次答辩中,项目小组、老师、助教、评审团进行了内容丰富的碰撞,本部分将进行一些简单的纪实。

谜语人队:

发际线和我作队:

美滋滋甜兮兮队:

万里阳光号:

是兄弟就来摸鱼:

助教团队:

删库跑路对不队:

荡起双桨:

此外,这学期大众评审团中有几位同学自己设计了一款用于iOS端的航概APP刷题软件,并且在学生中进行了一定程度的推广,取得了不俗的成绩也颇有些见解,我们邀请了他们也来讲讲自己在做这样一件事情时的心得与理解:

鸣谢与总结

这次我们组织了一次内容相当充实的Beta阶段项目展示与答辩,在此我需要向以下人员表达感谢:

  • 各项目小组的一整学期的不懈努力,以及对现场展示的辛苦准备
  • 两位老师在课程中的付出,以及组织安排上所付出的努力
  • 各位助教在答辩之前的项目评测,答辩中的各司其职,以及答辩后细致入微的评分(包括几位无法到场的助教,也都根据现场录播视频进行了详细的评分
  • 7位评审团成员对课程项目的长期关注与体验,以及站在用户和技术视角上提出来的一系列实际问题
  • 牛雅哲大佬作为评审团对本次答辩的鼎力支持,对各个团队工程管理规范鞭辟入里的指导
  • 吴家焱、熊安杰两位制作iOS端航概APP同学内容充实的项目经验分享
  • 邹欣老师在beta阶段评审方法上提供的关键性指点
  • 周筠老师对本学期课程的持续关注

总的来说,同学们表现的都各有亮点,但是也暴露出了比较多的问题,其中比较集中的问题有:

  • 软件工程意义上

    • 单元测试没有用到位

      • 对单元测试的核心思想理解有误,或不够重视
      • 单元测试覆盖率严重不足,测试效果不够
      • 单元测试放在最后去做,而不是去与开发协同前进
    • 代码风格限制性普遍不够,大多数组
      • 没有足够明确代码规范
      • 没有配备基于自动化代码风格检查工具的风格检查
    • 没有充分使用CI/CD
      • 单元测试大多数组都没有在CI/CD上自动化,即便自动化了的组也大多没有在CI/CD上做到足够有效的自动化(allow_failure、低覆盖率、该忽略的不忽略等)
      • 代码风格测试大多数组没有做到CI/CD上自动化,即便自动化了的组也基本上没有做到有效约束(基本上都是直接忽略测试结果)
      • 自动化部署大多数组没有做到CI/CD上自动化,实现了的组也多少都存在一定的不规范操作
    • 对Issue的理解与使用有较大问题
      • Issue的意义不只是列出一项工作,而是应该在上面进行任务的持续追踪,和必要的讨论,一个Issue应该足以反映一个任务的前世今生,让组内人员任何时候翻到都能了解其完整生命周期
      • 然而大部分组Issue基本上就是当做一个task,然后完事了close了事,其中没有任何过程
      • 笔者之前在各小组博客里面轮番轰炸了数波之后,大部分小组开始学会在Issue中关联代码、Merge Request和成果展示,但是依然很少有必要的讨论,还是更喜欢用微信群讨论,更喜欢在熟悉但是低效的泥潭里打滚
    • 对Merge Request的理解与使用有较大问题
      • Merge Request的意义在于代码从开发者分支(或者fork仓库)进入主分支(或者上级分支)的过程,注意这是一个过程,其中也应该包含这次代码提交的前因后果,以及必要的审核、修正与讨论
      • 然而一部分组完全没有用上Merge Request这一机制
      • 对于用上了的组,也常常在把Merge Request单纯的当做代码提交,一路通过,毫无内容的记录,甚至看都不看(一个Merge Request用到底、盲目merge等)
  • 软件产品意义上
    • 很多小组还是明显的表现出“唯技术”的思维,认为一切事项都该给开发让路,在其他同样重要但没那么熟悉的事情(例如实打实的需求分析、产品的非技术层面设计与宣传推广等)上却不肯下足功夫,或者只肯下作业意义上的功夫且大多流于表面。殊不知方向错了,再努力也只会在不归路上一路疾驰直至毁灭
    • 不少小组在推广的时候还是局限于手边的人和圈子。在这个问题上,可以引用一个故事

从前有个人,晚上回家,看到一个人在路灯下找东西。询问之下,原来对方是在找钥匙,遂帮助他一起找。

找了半天,仍然没有找到,又问:“你是在哪里丢的?”

“大约就在这一块。”对方比划了很大一个区域,答道。

“那为什么不去那里找呢?”这个人指向对方比划区域内的另一块地方。

“因为那里没有灯光。”对方回答道。

道理基本上就是这样——真正的目标用户不去挖掘,也不肯去好好接触,美其名曰不好弄,实际上可不就是和上面只肯在亮光下找钥匙一个思路么?况且就算没光,难道自己就不可以带一根手电筒,然后去该找的地方好好找找,活人就该被尿憋死?归根结底,还是在心理上重视与否,而这也是对课程组而言最难的地方。破山中贼易,破心中贼难,这些事情不仅对于未来的项目团队来说应当警醒,对课程组来说也是务必引起重视的。私以为,这其中最需要的还是各方的戒骄戒躁,少些主观臆断的沉溺,多些心思踏实的践行,才是正道

以上就是对beta阶段的一些总结,感谢各位的付出。实际上笔者无论是作为个人,还是作为今年的敏捷软工助教头子,都还是有不少话想说的。以及今年的改革不管怎么说,也还是在不少事情上有过探索也迈出了步子的。这些笔者打算后续专门用一篇博客做总结与介绍,敬请期待。

2021北航敏捷软工Beta阶段评分与总结的更多相关文章

  1. [BUAA软工]Beta阶段测试报告

    Beta阶段测试报告 Bug发现与报告 BUG 出现原因 解决方案 将shell加上编辑器UI以后,两边显示的文件不同步 两边的根目录不一致 修改编辑器获取根目录的函数,使其与shell的/home目 ...

  2. [BUAA软工]beta阶段贡献分

    团队成员在Beta阶段的角色和具体贡献: 名字 角色 具体的可衡量的可验证的贡献 zpj 前段+ 前后端对接 博客X1 20+ commits ui 设计与实现 bug fixed: 2 推广:10 ...

  3. [敏捷软工团队博客]项目介绍 & 需求分析 & 发布预测

    项目 内容 2020春季计算机学院软件工程(罗杰 任健) 博客园班级博客 作业要求 团队项目选择 我们在这个课程的目标是 在团队合作中锻炼自己 这个作业在哪个具体方面帮助我们实现目标 了解项目整体情况 ...

  4. 软工 · BETA 版冲刺前准备(团队)

    软工 · BETA 版冲刺前准备(团队) 过去存在的问题 组员之间缺乏沟通,前后端缺乏沟通协作 组员积极性不高 基础知识不够扎实 手动整合代码效率过低 我们已经做了哪些调整/改进 通过会议加强组员之间 ...

  5. [技术博客] 敏捷软工——JavaScript踩坑记

    [技术博客] 敏捷软工--JavaScript踩坑记 一.一个令人影响深刻的坑 1.脚本语言的面向对象 面向对象特性是现代编程语言的基本特性,JavaScript中当然集成了面向对象特性.但是Java ...

  6. [敏捷软工团队博客]Beta阶段事后分析

    设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的软件要解决的问题是:现在的软工课程的作业分布在博客园.GitHub上,没有一个集成多种功能的一体化 ...

  7. [敏捷软工团队博客]Beta阶段项目展示

    团队成员简介和个人博客地址 头像 姓名 博客园名称 自我介绍 PM 测试 前端 后端 dzx 秃头院的大闸蟹 大闸蟹是1706菜市场里无菜可卖的底层水货.大闸蟹喜欢音乐(但可惜不会),喜欢lol(可惜 ...

  8. [敏捷软工团队博客]Beta阶段发布声明

    项目 内容 2020春季计算机学院软件工程(罗杰 任健) 博客园班级博客 作业要求 Beta阶段发布声明 我们在这个课程的目标是 在团队合作中锻炼自己 这个作业在哪个具体方面帮助我们实现目标 对Bet ...

  9. [敏捷软工团队博客]Beta阶段测试报告

    项目 内容 2020春季计算机学院软件工程(罗杰 任健) 博客园班级博客 作业要求 Beta阶段测试报告 我们在这个课程的目标是 在团队合作中锻炼自己 这个作业在哪个具体方面帮助我们实现目标 对Bet ...

随机推荐

  1. Python - 面向对象编程 - 实战(4)

    需求:士兵突进 士兵许三多有一把 AK47 士兵可以开火 枪能够发射子弹 枪装填子弹,可以增加子弹数量 需求分析 很明显有两个类:士兵类,枪类 AK47 是枪名,是枪类的属性,每把枪都有子弹数,所以子 ...

  2. 异步处理方式之信号(三):kill、raise、alarm、pause函数简介

    文章目录 6. 函数kill和raise 7. 函数alarm和pause 7.1 alarm() 7.2 pause() 6. 函数kill和raise kill函数用来将信号发送给进程或者进程组. ...

  3. php-fpm进程数控制

    一.名词解释 CGI是Common Gateway Interface(通用网管协议),用于让交互程序和Web服务器通信的协议.负责处理URL的请求,启动一个进程,将客户端发送的数据作为输入,有Web ...

  4. AgileConfig轻量级配置中心1.4.0发布,重构了发布功能

    加入 NCC 先说一个事,AgileConfig 在 7 月底终于通过了 NCC 社区的审核,正式成为了 NCC 大家庭的一员.这对 AgileConfig 来说是一个里程碑,希望加入 NCC 后能更 ...

  5. 74cms v3.3 后台SQL注入

    注入存在于后台 admin_baiduxml.php 代码 52-63行 elseif($act == 'setsave') { $_POST['xmlmax']=intval($_POST['xml ...

  6. Java-SpringBoot整合SpringCloud

    SpringBoot整合SpringCloud 1. SpringCloud特点 SpringCloud专注于为典型的用例和扩展机制提供良好的开箱即用体验,以涵盖其他情况: 分布式/版本化配置 服务注 ...

  7. 回忆之placeholder

    直接看效果点这里 HTML <!DOCTYPE html> <html> <head lang="zh-CN"> <meta charse ...

  8. PHP中的MySQLi扩展学习(六)MySQLI_result对象操作

    在之前的文章中,我们就已经接触过 MYSQLI_result 相关的内容.它的作用其实就是一个查询的结果集.不过在 PDO 中,一般直接通过 query() 或者 PDOStatement 对象进行查 ...

  9. 一起学习PHP中断言函数的使用

    原来一直以为断言相关的函数是 PHPUnit 这些单元测试组件提供的,在阅读手册后才发现,这个 assert() 断言函数是 PHP 本身就自带的一个函数.也就是说,我们在代码中进行简单的测试的时候是 ...

  10. Postman 如何调试加密接口?

    大家好,我是安果! 众所周知,Postman 是一款非常流行且易用的 API 调试工具,在接口调试或测试时经常被使用针对普通 API 接口,我们可以直接在 Postman 中输入 URL.Query ...