Beta阶段项目展示

最新推荐文章于 2024-09-11 08:13:00 发布
最新推荐文章于 2024-09-11 08:13:00 发布
阅读量234 收藏
点赞数
文章标签： ui 软件工程
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/gg_equal_g/article/details/131146553
版权

项目与团队亮点

一、项目管理

1.1 团队成员

姓名任务
CJJ多功能侧边栏实现，偏好设置与菜单
CZHTextUI 的编辑悬浮框，公式补全，细节优化
GXY美工，榕林和榕树功能实现
LZNFICIR 生态，重构后端代码，配合榕功能
QS功能设计，UI 设计，文档，宣发
WZ自由人和运维，lute 功能
ZCX主进程相关任务

具体的信息可以参见我们的团队页面 。

1.2 项目管理

采用分层次沟通的方式：

  • 线下会议：讨论需要全体知会的问题，一般是设计或者架构方面。
  • 线上大群：一般用于发布通知等事宜。
  • 线上小群：一般用于讨论具体的实现问题。
  • 线下结对：用于肝对接实现。

二、用户场景

2.1 笔记内容过于零散

场景描述

阿榕平时很喜欢记笔记，每天都会将上课的收获记下来，有的时候中午追剧突然想到一个好的典故也会记录一下，但是笑笑却很不爱回看笔记，因为他的笔记都是这样的

// monday.md
“唧唧复唧唧”原来有两种解释，一种是织布机，一种是木兰的叹息声。
1 + 2 = 3

// tuesday.md
“自挂东南枝”这个典故似乎被《探清水河》化用了诶。
3 * 10 = 30

// wedsday.md
“谢公屐”是谢灵运穿的。
2^10 = 1024
分析

每一天的笔记都是很细碎的，因为人们的感官系统决定了大部分人读入信息只能以“流水账”的方式进行，但是这种线性而且杂乱的笔记，显然是不方便让人回看的。

解决方法

利用 ficus 林功能，进行文档的合并

在这里插入图片描述

可以看到原本每天的“流水账”变成了数学和语文两个有逻辑的 md 文档。

2.2 笔记内容过于冗杂

场景描述

阿榕平时很喜欢记笔记，但是他习惯把所有的东西都寄到一个文档中，时间长了一个 md 文档有 1 万多字，用滚轮滑都要滑很长时间，他根本不想回看。他的笔记长这样（我们挑了一个结构很清晰的，实际上阿榕的笔记没有这么有条例）

// note.md

# 网路实验入门实验内容
...
# 网路实验入门实验环境及设备简介
...
# 网路实验入门网线的制作
...
# 数据链路层实验内容
...
# 数据链路层实验以太网链路层帧格式分析
...
# 数据链路层实验 VLAN 的配置与分析
...
# 网络层实验 ARP 分析
...
# 网络层实验 ICMP 分析
...
# 网络层实验 VLAN 间通信
...
分析

人们在写笔记的时候是很难想清楚再动笔的，以一种模块化的方式去记笔记，就好像很多程序员喜欢 “一 main 到底”的程序设计思路一样，但是非结构化的笔记并不利于人们的反复观看和知识体系的构建。

解决方法

利用 ficus 林功能，进行文档的拆分。

在这里插入图片描述

可以看到原来 1 个文档被拆分成了 3 个有序的文档。

2.3 不知道如何构建体系

可以利用 fic prop 转换成 fic root 的功能进行体系化的构建，同时可以用 root 转 prop 进行撤销。

构建唯一的体系是必要的！

2.4 无法发现知识间的联系

可以用 fic aerail 转 prop 的功能，aerail 提供双链功能构建 tag。

三、杀手功能

3.1 榕功能

目前完成开发的是所有的榕功能和辅助功能，具体的功能可以在官网功能介绍处查阅，界面效果如图所示：

榕林：

在这里插入图片描述

榕图：

在这里插入图片描述

3.2 用户体验

公式补全：

在这里插入图片描述

偏好设置：

在这里插入图片描述

编辑悬浮框：

在这里插入图片描述

四、产品发布

4.1 产品官网

官网的具体数据如下：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VyzNgxhm-1686401967465)(Beta阶段项目展示/image-20230610162922387.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NAFEHHpQ-1686401967470)(Beta阶段项目展示/image-20230610162940180.png)]

4.2 网站宣发

网站阅览数点赞数收藏数评论数总结
知乎66431不知道为啥似乎不太行
CSDN246000其实也还可以了，感觉有一定的推荐机制
V2EX212null00似乎沉底了
程序员头条null1null0宣传效果不够好
链滴83111效果似乎不如 alpha 好
小众软件8201null27黑红未尝不是红
HelloGithub0000非常遗憾，审核时间超过了一月，没能在我平时很喜欢的一个网站上投稿

小众软件好恐怖！

4.3 社交媒体

在这里插入图片描述

4.5 宣发成绩

截止 2023.06.10 ，我们的宣发成绩如下：

指标内容
官网浏览量总浏览量为 48125，日均浏览量为 800 人，浏览时长为 5 min
下载量下载次数为 570 次，下载人数为 342 人
网站宣发总浏览量为 1420，细节信息可以参考 3.1 节
Github239 star, 6 fork, 5 watch, 3 discussion, 21 vssue comment
用户群65 人群，200 多元打赏

五、软件工程质量

5.1 代码规模

我们的主仓库[Ficus](GitHub - Thysrael/Ficus: Ficus is a software for editing and managing markdown documents, developed by the gg=G team.)的src目录下代码统计如下

languagefilescodecommentblanktotal
JavaScript484,9288107846,522
vue254,425103934,828
CSS23,6362149664,816
JSON31,587031,590
Markdown11701128

5.2 代码质量分析

我们采用plato对我们软件的代码质量进行分析。plato整合了来自复杂度计算工具complexity-report和代码规范工具eslint的数据并进行可视化展示。不过目前只能对javascript代码进行统计，这主要包含了来自主进程和解析器的代码，渲染进程部分代码因为是vue文件并没有参与统计。

参与统计的文件的代码行数7309（包含空行和注释），平均114行。

可维护性

BETA阶段我们的可维护性指标为72.93。比较而言，marktext该指标为65.94（共39497行，平均139行），vscode该指标为56.23（共20281行，平均494行）。

同时，可维护性指标较低的代码基本上为markdown解析器代码，这部分实际上没有太好的质量优化空间。

在这里插入图片描述

在这里插入图片描述

复杂度度量

在基于Halstead复杂度度量（包括圈复杂度）的错误估计上，我们平均可能错误数较少且分布均匀。

在这里插入图片描述

代码规范

在代码规范上，我们所有的代码都满足我们使用的规范（‘plugin:vue/vue3-essential’, ‘standard’）。

项目与团队总结

一、项目管理

1.1 团队成员的简介和个人博客地址

姓名任务
CJJ多功能侧边栏实现，偏好设置与菜单
CZHTextUI 的编辑悬浮框，公式补全，细节优化
GXY美工，榕林和榕树功能实现
LZNFICIR 生态，重构后端代码，配合榕功能
QS功能设计，UI 设计，文档，宣发
WZ自由人和运维，lute 功能
ZCX主进程相关任务

具体的信息可以参见我们的团队页面 。

1.2 团队是如何进行项目管理的？

设计阶段

整体榕功能的设计是在 alpha 阶段就已经完成了的，所以基本上只需要由 PM 优化和丰富具体的要求和细节即可。同时采用实现人员反馈的方式，避免设计出难以实现的功能。

在其他功能的设计方面，主要考虑在 alpha 阶段获得的用户反馈意见，然后设计出对应的功能，争取给用户营造较好的使用体验。

实施阶段

我们采用 github 来管理我们的仓库，用 notion 管理我们的文档，用 github issue 管理我们的开发事项，用研讨室组会来进行对接。用一些插件来进行进程的可视化。

在会议方面，将开会商议事宜提前列出并公示，可以很好地提高会议效率。

在代码实现方面，利用北航提供的研讨室进行“线下结对编程”是一个很好的体验，因为架构师的设计只能自顶向下提供指导，而不同模块负责者线下对接，则是一种对设计自底向上的补充，并且结对编程对于摸鱼有很好的效果。这种方式在冲刺阶段比微信私聊的效果要好一些。不过缺点是很容易沉迷编程。

在开发事项方面，在冲刺阶段，我们又用回了 notion 看板，相比于 github issue，看板更加轻量化，编辑更加简便，更适合冲刺。

审核检验阶段

在日常开发过程中，我们对重要模块进行了单元测试。

在发布前，我们进行了使用测试，从使用人员的角度对功能进行了全面测试。

我们的发布分为两个阶段，第一个阶段发布先行版，然后立即收集用户意见和建议，然后更新发布迭代版。当迭代版趋于稳定后，进入第二个阶段，发布最终版。

1.3 团队的成员如何分工协作的？有什么经验教训？

因为 alpha 阶段已经完成了基础的搭建工作，所以在 beta 阶段大家可以专注于特定的模块解决问题，没有很多需要配合的实现。

在 beta 阶段我们将更多的功能集成到了 FicIR 相关，这要求基本上所有人都需要与 lzn 同学对接，幸亏 lzn 同学作为架构师，得心应手，极大地提高了我们的开发效率。

beta 阶段后期出现了烤漆、夏令营、新冠等消极时间，在进行计划时没有考虑到，导致有一些延期的出现。

1.4 团队成员如何沟通和对接的？有什么记录留存？

采用分层次沟通的方式：

  • 线下会议：讨论需要全体知会的问题，一般是设计或者架构方面。
  • 线上大群：一般用于发布通知等事宜。
  • 线上小群：一般用于讨论具体的实现问题。
  • 线下结对：用于肝对接实现。

其中“线下结对”和“线上小群”是两个比较高效的设计。“线下结对”的优势在前文分析过了，对于“线上小群”，这是一个我们很有效的管理方式，因为我们的分工偏向于“层次”而不是“模块”，所以为了弥补一些缺点，我们按照模块建立了多个小群，每个小群仅仅包括与当前模块相关的人员。

这种方式出人意料的高效（因为是架构师而不是 PM 提出的，所以比较意外），这可能是由于大家比较怕在大群里说话（虽然只有 8 个人），不只是害羞的原因，而且还有担心自己的发言打扰了他人的休息，而在小群里，因为大家的工作高度相关，所以大家更加畅所欲言。

缺点可能是同步性，有些通知在小群里说了，就忘了更新到其他小群或者大群里，但是和大家畅所欲言的表达而言，这点代价不值一提。

我们每次都有组会记录，可以在这里进行查阅。

1.5 团队如何平衡 时间/质量/资源 争取如期完成任务的？

在 alpha 阶段我们的思路是“质量第一”，但是发现在 beta 阶段因为疫情、夏令营、竞赛、烤漆等事情，确实难以完全牺牲时间和资源保证质量。

因此我们采用了更加灵活的管理制度，不再设置强硬的 ddl，留出缓冲区，方便大家调度自己的时间和资源。这么做的代价是对于项目的追踪和协调能力有了更高的要求，对于 PM 和架构师都是一个挑战。

1.6 团队项目的实际进展如何？在项目管理中，scrum的燃尽图是如何真实反映项目的状态的？或者燃尽图美化了状态？

最终的燃尽图如图所示：

在这里插入图片描述

基本上完成了预定的开发任务。

但是有一些用户体验部分的任务虽然被提成了 issue，但是没有被计入燃尽图，导致我们中期有一个平台期。

1.7 Alpha阶段的角色和具体贡献

姓名任务团队贡献分数issue 数量pr 数量
CJJ多功能侧边栏实现，偏好设置与菜单48918
CZHTextUI 的编辑悬浮框，公式补全，细节优化49614
GXY美工，榕林和榕树功能实现53943
LZNFICIR 生态，重构后端代码，配合榕功能51375
QS选题、功能设计、UI 设计、团队管理、文档撰写和宣发工作5026
WZ功能设计，UI 设计，文档，宣发52418
ZCX主进程相关任务47112

代码贡献表，由 git log 和 cloc 在 dev 分支上统计，文档的统计范围不包括 notion，查询命令为

git log --format='%aN' | sort -u | while read name; do echo -en "$name\t"; git log --author="$name" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' -; done
姓名added linesremoved linestotal lines文档行数
CJJ12420989625240
CZH4660717606290010
GXY157424894108480
LZN6224551265109800
QS373922814138
WZ11636495140
ZCX225770115560

二、用户场景

2.1 项目开发前的目标，预期的典型用户场景，预期的功能描述

开发前的目标：功能规格说明书

典型用户场景：用户场景

预期功能描述：功能描述

2.2 项目发布的功能，在哪里发布了软件。

项目发布的功能在官网文档可以查询。我们在多个网站发布了我们的软件：

  • 水群：包括 2006，2106 水群
  • 超算社：感谢东哥
  • 知乎：https://zhuanlan.zhihu.com/p/635752092
  • ld246：https://ld246.com/article/1686235241764
  • 程序员头条：https://toutiao.io/posts/jmwcxo4
  • v2ex：https://www.v2ex.com/t/947123
  • CSDN：https://blog.csdn.net/living_frontier/article/details/131117688?spm=1001.2014.3001.5501
  • 小众软件：https://meta.appinn.net/t/topic/44441/27

2.3 项目发布后是否满足了全部典型场景？剩下的为何没有满足？

满足了全部的应用场景

2.4 项目发布后真正符合用户需求了吗？列出目标用户使用产品的过程和评价。

随着 beta 阶段的结束，功能已经开发全面了。

其实最希望知道的，是大家对于榕功能的反应，但是由于时间原因，大家表示了对于这个新模式十分感兴趣，但是似乎没有深度体验。在本组内的一名组员使用了一下，说是很好用（不是托）。

因为评价较多，仅罗列几条。

ld246：

在这里插入图片描述

小众软件：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XDlmafBh-1686401967476)(Beta阶段项目展示/image-20230610162747813.png)]

相比于 alpha 的期待，这次提出的评价都比较严厉，可能是因为我们真正接近一款正式的软件了。

三、用户日活

3.1 项目发布时团队做了哪些努力来推广项目？

我们的宣发大致分为四个部分：

  • 搭建官网：搭建了一套完整的官网体系，在宣发的时候不止宣传仓库，还宣传官网
  • 网站宣发：包括知乎，CSDN，V2EX，ld246，HelloGithub，程序员头条等网站
  • 社团联动：主要是北航超算社团
  • 社交媒体宣发：包括水群和微信朋友圈，并建立了用户群

官网的具体数据如下：

在这里插入图片描述

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iJzHyjW0-1686401967477)(Beta阶段项目展示/image-20230610162940180.png)]

宣发网站已经是第二次了，依然妙趣恒生

网站宣发统计如下

网站阅览数点赞数收藏数评论数总结
知乎66431不知道为啥似乎不太行
CSDN246000其实也还可以了，感觉有一定的推荐机制
V2EX212null00似乎沉底了
程序员头条null1null0宣传效果不够好
链滴83111效果似乎不如 alpha 好
小众软件8201null27黑红未尝不是红
HelloGithub0000非常遗憾，审核时间超过了一月，没能在我平时很喜欢的一个网站上投稿

水群宣传：

在这里插入图片描述

3.2 软件的日活跃用户量是否达到了预先定义的数量？你们认为还有什么指标可以佐证你们的软件对用户“有用”？

截止 2023.05.04 ，我们的宣发成绩如下：

指标内容
官网浏览量总浏览量为 48125，日均浏览量为 800 人，浏览时长为 5 min
下载量下载次数为 570 次，下载人数为 342 人
网站宣发总浏览量为 1420，细节信息可以参考 3.1 节
Github239 star, 6 fork, 5 watch, 3 discussion, 21 vssue comment
用户群65 人群，200 多元打赏

在初期我们订的目标是 1000 次的下载量，目前已经达到了。

在这里插入图片描述

3.3 是否有用户在功能改进上有所反馈？

为了倾听用户的反馈，我们构建了多条反馈通道：

  • 微信私聊
  • 官网评论区
  • 用户群
  • Github issue

我们广泛收集了用户的反馈，并做出了许多调整：

  • 加入搜索替换功能。
  • 增加了编辑悬浮窗。
  • 增加了 hover tip。
  • 优化了榕树性能。
  • ……

3.4 是否有用户在Bug上有所反馈？有什么样的bug？这是预料之中的还是没想到的？

是有反馈的。

bug 有很多中，主要集中于以下几个方面：

  • 搜索替换功能。
  • 软件交互。
  • 内存泄漏。
  • 其他 bug。

关于搜索替换功能，我们当时确实只是做了一个，并没有投入太多的精力，所以可能会有一些 bug。软件交互方面的 bug 大部分是开发不完了，只能先写一个不太适合交互，但是能用且稳定的方式。内存泄漏 bug 在 alpha 阶段出现过，我们以为换了插件就没有问题了，但是依然又问题，已经在修了。其他 bug 主要是与主进程相关，都是很容易调整的。

四、杀手功能

4.1 项目的杀手级功能，与竞品相比最特色的功能展现

目前开发完全了所有榕功能，包括：

  • 榕林模式的编辑和浏览。
  • 榕图模式的编辑：
    • 根柱转换
    • 柱须转换
  • 榕树的节点内容编辑。

具体的效果可以在官网功能介绍处查阅，总体界面效果如图所示：

在这里插入图片描述

4.2 思考一下竞品出于什么原因并没有囊括该特色功能，团队凭借什么样的优势实现了它？

Ficus 最大的优势是它的设计思想，它是第一个将用户的知识进行结构化的软件，其核心就是“结构化”，这是 Ficus 与其他软件不同的地方，很多的竞品的目标是开发一款 md 的编辑器，或者是一款功能强大的编辑器恰好有了 md 支持。

至于榕图和榕林的功能，可能因为一开始设计的时候，就希望设计出独一无二的杀手功能，所以才会如此吧。

可能是团队的力量吧。

4.3 团队成员对这些功能的自我评价如何，是否达到了预期目标，为什么？

在功能上完全开发了，甚至是超额完成任务（比如说多种榕树榕林样式，折叠粒度的控制，节点内编辑等）。

在交互方面，榕图的编辑会导致剧烈抖动（本质是刷新），如果需要去掉，可能需要自己开发插件。这里并不太理想，但是我们没有时间了。

4.4 用户对这些功能的评价如何，是否认为这些功能富有特色，为什么？

用户的评价基本上是正面的，是支持态度的，具体的可以看我们上面列出的宣发网站上的评论。

而且用户确实认为这些功能是富有特色的，都做出了正面评价。

五、软件工程质量

5.1 项目有完善的文档吗，是否有约定代码规范？

项目有完善的文档，这是因为我们采用地是‘按层次划分’的分工，所以每个层次的沟通都需要完善的文档，同时因为选题的新颖性，功能文档也必须保证完善易读的要求。

我们不仅约定了代码规范，我们还采用 eslint 和 CI/CD 结合的方式来保证代码风格的质量，规范具体可以参考这里。

我们的配置方法如下：

代码风格

使用 eslint 控制代码风格，首先按照 eslint 在开发环境依赖中，并进行初始化。其中代码风格为 eslint-config-standard

npm i -D eslint
./node_modules/.bin/eslint --init

然后 package.json 中补充脚本方便格式化，格式化对象包括 js, vue。同时除了检测码风问题外，还通过 --fix 对代码风格进行自动修复。

// package.json
{
    "scripts" : {
        "eslint": "eslint \"./src/**.{js,vue}\" --fix",
    }
}

在 vscode 中安装 ESLint 插件，并通过 ./.vscode/settings.json 进行配置，使其可以保存是自动格式化。

// settings.json
{
    "eslint.format.enable": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    }
}

此外还需设置 tab 的大小为两个空格，最终设置如下

{
    "eslint.format.enable": true,
    "editor.codeActionsOnSave": {
        "source.fixAll.eslint": true
    },
    "editor.detectIndentation": true,
    "editor.insertSpaces": true,
    "editor.tabSize": 2,
}

Git commit style

利用 commitizen cz-conventional-changelog 进行 commit 信息的管理

npm i -D commitizen cz-conventional-changelog

此时需要利用如下命令进行 commit

npm run commit

为了达到这个目的，需要在 pakage.json 中进行如下配置

// package.json
{
    "scripts" : {
        "commit": "git-cz",
    }
}

在进行 commit 时，应当至少填写 type, tense description 。

最终效果如下：

在这里插入图片描述

另外还有一个东西被称作 standard-version 可以根据 git commit 的信息生成 CHANGELOG.md ，但是我没有找到他生成的文档在哪里，十分遗憾。

安装如下：

npm i -D standard-version

同样可以在脚本中进行补充，使其可以在输入 npm run version 时工作

 // package.json
{    
    "scripts" : {        
        "version": "standard-version",
    }
}

5.2 项目是否有出现代码混乱，没有注释，没有详细文档的问题？如果一个新学生在一台新机器上想编译并运行你的项目， 请问能顺利完成么？有什么样的文档能指导新学生？

从 cloc 的统计结果来看，我们的代码有大约为 10% 的注释量

在这里插入图片描述

考虑到我们用的插件 viditor 有大量的 CSS 样式，其实实际上注释占比应当更多一些。

文档确实足够详细。目前文档是 5000+ 行，并且有生动的图片介绍架构。

为了指导同学们使用我们的软件，我们特意编写了一个快速上手。

5.3 项目是否有单元测试，测试用例数目，代码覆盖率等

可以在这里这里查看详细信息（beta 也更新在这里了）。

5.4 项目是否采用了CI/CD，并说明理由

主项目部分

我们使用 Github Action 为主项目的所有分支配置了 eslint 检查。在分支被推送到仓库时，会触发一个 Github Runner 对项目中所有的 js 文件进行一次格式检查。在合并 PR 时，需要等待并检查提交的 eslint 检查的结果，只有 eslint 通过的代码才可以合入上级分支。

对主项目的 master，release，dev 分支，我们配置了自动构建。所有向这些分支的 push 操作，都会触发以 Mac、Windows、Linux 为目标的构建。

构建结果以 Artifacts 形式存在
在这里插入图片描述

在这里插入图片描述

所有到 release 的合并，会触发一次自动的 Release 操作。脚本获取当前的版本号，将当前版本构建的 artifacts 作为附件，产生一个 Release 到仓库首页供用户下载。

在远端的更新服务器上，我们使用 Jenkins 对仓库进行监听。当 release 分支 出现变动时，会获得 release 上的最新版本号和构建出的 asar 资源，将最新版本和资源发布在更新站点上。

目前，主项目上已累计触发 500 余次 workflow，有效的提高了代码质量，尽早发现问题。

发布页部分

在发布页项目上，我们使用 Jenkins 实现了自动部署。Jenkins 会接受 Github 上发布页 push 的事件。所有到 master 分支的 push 操作都会触发服务器的一次 pull，构建，并使用 nginx 发布网页的过程。

发布页有一个小型的后端，与发布页前端共享仓库。后端使用 django 实现，用于对所有的下载量进行统计。Jenkins 也会负责这个后端的更新操作。 django 上存在一些较敏感的配置项存储在 settings.py 中。仓库中的 settings.py 仅用于本地调试。 Jenkins 会使用一个服务器本地的发行版替换这个仓库中的版本，并对数据库进行迁移和初始化后启动 django 服务。

Jenkins 已被触发超过 60 次，有效的提高了发布页更新的效率。

在这里插入图片描述

5.5 学到的经验和教训

整个团队在Beta阶段学到了什么

  1. 快速迭代开发：如何快速迭代开发并快速构建原型。

  2. 需求分析：如何进行需求分析，以确保正在构建的软件满足客户需求。

  3. 用户体验设计：如何设计出易于使用和易于理解的用户界面，以提高用户满意度。

  4. 团队协作：如何与团队成员协作，以确保项目进度和质量。

  5. 风险管理：如何识别和管理项目中的风险，以确保项目成功。

  6. 软件宣发：如何宣传和发布自己的软件，以保证软件有用一定的用户。

对软件工程有什么样的经验教训

  1. 人是有极限的。
  2. 有许多事情都需要提前协调。
  3. 无法满足每一个人。
gg_equal_G
关注
alpha测试和beta测试的区别是什么？
Pitbull2014的博客
07-09 1119
1、测试时间不同： Beta测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段。 alpha测试简称“α测试”，可以从软件产品编码结束之时开始，或在模块(子系统)测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。 2、测试的目的不同： α测试的目的是评价软件产品的FLURPS（即功能、局域化、可...
Beta阶段项目展示博客
weixin_30535043的博客
01-01 329
Beta阶段项目展示 团队成员的简介 详细见团队简介 角色 姓名 照片 项目经理，策划 游心 策划 王子铭 策划 蔡帜 美工 赵晓宇 美工 王辰昱 开发、架构师 解小锐 开发 陈鑫 开发 李金奇 开发 杨森 团队成员个人博客地址 游心：http://www.cnblogs.com/jefhq/ 王子铭：http://www.cn...
【HelloKitty团队项目】Beta阶段项目展示
HelloKittyTeam的博客
06-10 841
【HelloWord】Beta阶段项目展示
Agile-埃杰Beta阶段项目展示
ljrgtdxh_777的博客
06-10 537
Agile-埃杰
【Beta阶段项目展示】Time Shaft·时间轴
mjkf_66666666的博客
06-18 1304
beta阶段项目展示
「MOSS - 32」MOSS队：Beta阶段项目展示
MOSS2023的博客
06-10 325
MOSS - 00」MOSS队：团队介绍。在项目进行的过程中，我们也根据实际情况进行了一定调整。成员分工于敬凯PM，项目管理，运维姜雨竺前端开发，架构设计，原型设计史泽宇前端开发，前端测试，原型设计王小鸽前端开发，API对接，原型设计王雪竹前端开发，原型设计陈楚岩后端开发，数据库叶颜函后端开发，后端测试以字典序陈楚岩我喜欢睡觉。在本次团队开发中主要担当后端开发的工作。姜雨竺。
Okidoki - Beta阶段项目展示 - TEAM LESS ERROR
czl_yt的博客
06-18 934
Beta阶段项目展示
公客网beta阶段项目展示
weixin_30367543的博客
01-01 109
课程评价网站——公客网 为大学生选课排忧解难 公正客观的评课网站 为大学生提供发表自己看法的平台 为每一门课程打出公正的评分 beta阶段的新功能 beta阶段发布说明 评价的增删改 对课程发表评价 删除与追加修改评价 评价下的讨论，使用@与对方交流 为评价点赞 用户详细信息与发言记录 邮箱验证 网站实现了细节美化 动态效果增强 团队合作过程 ...
Beta项目展示
qq_43568318的博客
07-10 447
项目 内容 这个作业属于哪个课程 2021春季软件工程（罗杰 任健） 这个作业的要求在哪里 Beta-项目展示 我们是谁 删库跑路对不队 我们在做什么 题士 进度如何 进度总览 一、项目与团队亮点 1.关于我们 1.1 团队成员与分工简介 姓名 负责 具体工作简介 QSY PM&前端 产品主页与后台管理系统设计与开发，服务器nginx与SSL等部署与维护，例会报告与产品相关博客的撰写，推进项目进度，审查项目质量 LKL 后端 题目、知识卡片和考...
Beta阶段项目总结
weixin_30468137的博客
01-15 87
beta阶段的postmortem报告 1：每个成员在beta阶段的实践和alpha阶段有何改进 成员：张运涛：beta阶段比alpha的阶段的开发起来更加的有经验，更加的熟练 刘瑞欣：beta阶段比alpha阶段，微信开发者工具的使用以及界面之间参数的跳转更加熟练 徐召阳：更改界面上，使用更加简洁的界面，使用户体验感...
团队项目-Beta阶段项目展示
Cyclonius的博客
06-10 95
小明是一名大学生，要编写大量实验报告，想练习双拼提高自己的打字速度。兼顾中英文练习，多种输入方式，支持多种内容选择，附加辅助记忆功能。小红是一名高中生，想以打字的方式练习自己的英文单词拼写。对所有接口进行1-2个测试，对所有异常进行一个测试。风格规范：prettier+checkstyle。接口功能测试：mockmvc。重点问题讨论：线下研讨室。设计文档：明确的出口定义。整体测试：实际用户使用。
Alpha阶段项目展示
ljrgtdxh_777的博客
05-04 293
埃杰典型用户场景与解决方案BUAA MapForum的主要用户是BUAA校内的同学。但即便是同一所学校的学生，也可以划分为好几个完全不一样的群体，因为BUAA中既有懵懵懂懂的一年级学生 🤵，也有身经百战的四年级学生；既有社恐的A同学，也有社牛的B同学；既有想“尝遍鲜”的BUAA积极探索者，也有偶尔想玩转校园但是不知从何入手的佛系大师……尽管需求不同，但是任何一位BUAA的同学都可能成为BUAA MapForum的潜在用户。典型用户名字咖啡豆用户身份刚进入BUAA的大一新生年龄18岁。
在 RT-Thread 上使用单色屏 UI 库 - U8G2
随便转转
09-09 1184
基于 RT-Thread 使用 U8G2 驱动单色屏
详细阐述Activity的生命周期
LLZjiayou的博客
09-10 431
Android 中的 Activity 生命周期定义了 Activity 从创建到销毁所经历的状态。了解这些状态对于管理应用中的资源分配、用户交互和后台进程至关重要。
单源最短路径 洛谷【P4779】
2302_79865304的博客
09-07 855
给定一个 nn 个点，mm 条有向边的带非负权图，请你计算从 ss 出发，到每个点的距离。数据保证你能从 ss 出发到任意点。第一行为三个正整数 n,m,sn,m,s。 第二行起 mm 行，每行三个非负整数 ui,vi,wiui​,vi​,wi​，表示从 uiui​ 到 vivi​ 有一条权值为 wiwi​ 的有向边。输出一行 nn 个空格分隔的非负整数，表示 ss 到每个点的距离。输入 #1 4 6 1 1 2 2 2 3 2 2 4 1 1 3 5 3 4 3 1 4 4 输出 #1 0 2 4 3
yolo-2
默子昂
09-10 414
创建ui/ 目录，下面所有文件都在ui下面。
QT之QML从入门到精通（第一章）
m0_58233509的博客
09-08 727
Window{ //root控件 主界面//自定义一个信号onMySig: { //触发信号所执行的函数，信号名加on，并且第一个字母大写onWidthChanged: { //窗口的宽度改变时会触发这个函数console.log("width change ",width) //打印语句，打印宽度property int myValue: 0 // 创建一个int类型的属性，他也会自动生成信号和槽width: 640x:500;
Android13_SystemUI下拉框新增音量控制条
十年饮冰，难凉热血
09-09 1093
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档。
有关 Element-ui 的一些思考
最新发布
小白小白从不日别的博客
09-11 393
这里列举了一些我们在使用element-ui时的一些实用技巧，比如主题样式修改、el-form-item label宽度自适应等
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值