[I.2] 个人作业：软件案例分析

第一部分 调研与评测

1.1 软件选型与使用情况

  • 软件名称：Gitee
  • 对比竞品：GitHub、GitLab

1.1.1 软件使用

我曾使用过Gitee，参与一些实验室项目，并在项目中撰写部分代码，进行一些提交和管理工作

  1. 注册/登录：邮箱注册并登录。
  2. 创建仓库：创建一个私有/公共仓库，上传或导入已有项目。
  3. 浏览和搜索仓库：查看一些热门开源项目、尝试搜索关键字。
  4. Issue 管理与 PR 提交：在自建仓库中提交一个 Issue，并模拟 Pull Request 流程。
  5. 项目看板与 Wiki：简单查看 Gitee 提供的项目管理功能，看板、Wiki 等。

1.2 软件分析

1.2.1 基本流程

  1. 用户登录或注册
    • 与 GitHub 类似，Gitee 支持邮箱注册，也可用第三方账号（如微信、QQ、Gitee 自带的 OAuth）登录。
  2. 创建/导入仓库
    • 可以直接在网页端创建一个新仓库，或从本地使用 git push 将已有项目上传。
  3. 管理代码
    • Web 界面提供版本历史查看、Issue 跟踪、Pull Request 合并等常见代码托管功能。
  4. 项目协作
    • 有简单的项目管理功能，如看板、Wiki，以及团队协作权限设置。
  5. 发现开源项目
    • 有类似「探索/发现」功能，方便搜索或浏览国内的开源项目。

1.2.2 是否满足用户需求

  • 国内访问速度更快：相较于 GitHub，Gitee 在国内访问速度和稳定性上占优，满足了对速度敏感的用户需求（尤其是网络环境不佳的地区或学校）。
  • 开源项目托管：大多功能与 GitHub 相似，满足团队协作、个人项目托管、Issue 管理等需求。
  • 界面易用性：提供中文界面，对英文不熟练的用户更加友好。

1.2.3 数据量/界面/功能/准确度/用户体验

  • 数据量
    • Gitee 上项目数量虽不及 GitHub，但在国内依然积累了相当数量的仓库，整体能满足用户基本需要。
  • 界面
    • 中文化程度高，界面清爽简洁，功能布局较直观；部分模块与 GitHub 相比依旧略显简化。
  • 功能
    • 提供基本的代码管理功能（Issue、PR、Wiki、CI/CD 等），但与 GitHub 的 Actions 等生态相比仍有一定差距。
  • 准确度
    • 基本功能（代码版本、Pull Request 合并、分支管理等）都很稳定，能准确地呈现代码版本历史。
  • 用户体验
    • 注册与创建仓库门槛较低。
    • 一些高级功能在易用性上尚有提升空间，比如企业级项目管理、自动化测试支持、看板等的细节功能略有不足。

1.3 改进意见

  1. 丰富项目管理工具：
    • 与 GitHub Actions 类似的自动化构建/测试/部署可以进一步完善，提供更多免费配额或插件。
  2. 社区生态与互动：
    • 目前社区氛围不如 GitHub 浓厚，可以适度激励开源开发者在 Gitee 进行讨论和维护。
  3. 个性化定制：
    • 在项目看板、权限管理上可以提供更灵活的定制选项。
  4. 文档与帮助中心：
    • 改进官方文档的丰富程度，帮助新人快速上手 CI/CD、Webhook 等功能。

1.4 用户调研

1.4.1 采访对象背景

  • 采访对象：一名北航大四学长。
  • 为什么采访他：
    • 该同学个人开发常用Github，但是在某些项目中也被要求使用过Gitee，具有对比体验。

1.4.2 采访过程记录

1.4.3 采访对象评价

  • 缺点
    • Gitee作为一个开源代码托管平台，生态活跃度低
    • 与各个开发平台联动度低（相较于Gitee，Github发布自己的编码助手copilot，嵌入各个IDE中）
  • 优点
    • 采用中文界面，对新手友好
    • 访问速度快

1.5 评测结论

综合上述分析和用户调研，我对 Gitee 的整体评价为：

d) 好，不错

原因：

  • 国内访问与网络稳定性表现很好，使用体验流畅。
  • 对中文用户和初学者非常友好。
  • 与 GitHub 相比，生态略有不足，但基础功能基本到位。

1.6 定量评价思考

  • 参考文章（博客链接）中类似的量化维度，针对 功能完备度、访问速度、社区活跃度、界面友好度 等几个维度分：
    1. 功能完备度：满分 10，我给 7 分
    2. 访问速度：满分 10，我给 9 分
    3. 社区活跃度：满分 10，我给 5 分
    4. 界面友好度：满分 10，我给 7 分
    5. 文档丰富度：满分 10，我给 6 分
  • 最终可计算一个综合得分，然后与 GitHub、GitLab 等进行横向对比。

第二部分：Bug 分析与提交

2.1 Bug 列表总览与严重程度量化标准

这里用「星级」来量化 Bug 的严重程度：

  • 五星（★★★★★）：致命性系统故障、致命安全漏洞、用户体验极度受损
  • 四星（★★★★☆）：严重系统故障、重要数据泄露或重大安全隐患、用户体验明显受损
  • 三星（★★★☆☆）：功能性故障，影响正常使用，但有可行的替代方案
  • 两星（★★☆☆☆）：非致命性问题或小范围兼容性问题，对核心功能影响不大
  • 一星（★☆☆☆☆）：非常轻微的体验缺陷或界面用词错误，不影响主要功能

2.2 Bug分析与提交

我在对Gitee软件进行的详细功能测试过程中，暂未发现明显的功能性Bug。以下是具体说明：

测试环境：

  • 操作系统：MacOS
  • 浏览器：Google Chrome
  • 测试时段：2025年3月12日
  • 测试方法：按照软件提供的核心功能和用户可能的常规使用场景进行了逐项测试，包括：
    • 仓库创建、导入及提交代码
    • Issue提交和关闭流程

测试结果

  • 测试过程中，未发现严重的或明显影响功能使用的Bug。
  • 各功能正常运行，用户体验较为流畅，未发现明显阻塞或卡顿现象。

关于“未发现Bug”的可能原因分析：

  • 软件自身经过长时间的迭代优化，主要功能成熟且稳定，基本Bug已在测试阶段或之前版本迭代中修复。
  • 本次评测时间相对有限（仅10~30分钟），可能尚未触及到更深层次或特殊场景的潜在Bug。
  • 软件开发和测试团队的质量控制机制相对完善，功能覆盖度较高。

第二部分：分析

2.4 工作量预测

假设：团队由 6 名计算机专业毕业生和 1 名专职 UI 组成，共同开发了 Gitee 这样一个平台。

  • 功能范围：

    1. 用户系统（注册/登录/权限）
    2. 仓库管理（创建/导入/上传/下载）
    3. Issue、PR、Wiki、看板、权限管理
    4. 社区与发现板块
    5. 平台运维与 CI/CD

  • 初步估算：

    • 前后端分工，前端 2 人（负责网页与交互），后端 3 人（负责业务逻辑、数据库、服务器运维），测试与运维 1 人，UI 设计 1 人。
    • 开发周期：若从零开始，预估至少需要 14-15 个月左右（仅做粗略估算，不考虑学习成本）的开发和内测，再经历数月迭代上线到正式可用。
    • 如果只是核心功能（版本控制 + Issue + PR），或许 6-8 个月能出 MVP（最简可用版本），后续再不断迭代升级。

2.5 软件质量分析

  • 优点：
    1. 国内访问快
    2. 中文界面完整
    3. 基础功能稳定
  • 缺点：
    1. 高级功能不够完善（尤其自动化构建、生态等）
    2. 社区活跃度较弱

若与 GitHub、GitLab 同类产品对比，Gitee 整体水平大约排在：

  1. GitHub（生态最丰富）
  2. GitLab（自建 CI/CD 强）
  3. Gitee（国内速度快、中文支持好，但国际生态与高级功能上稍逊）

排名：第三左右。

2.6 软件工程方面的改进建议

  • 建议：加强产品的持续集成/交付（CI/CD）系统，比如学习 GitHub Actions 或 GitLab CI，完善自身生态。
  • 原因：
    • 用户除了代码托管，还需要自动测试、自动部署等一站式服务。
    • 可以通过插件或社区 Marketplace 的方式吸纳更多开发者生态。

第三部分：建议与规划

参考教材第 8 章功能定位与优先级，第 9 章项目经理相关内容

3.1 市场现状

3.1.1 市场概况

  • 直接用户：国内开发者、企业级开发团队、学生群体，大概数百万至上千万级（潜在用户也包括高校、科研机构）。
  • 潜在用户：尚未使用版本管理工具的普通技术爱好者，中小企业想转型使用云端协作。

3.1.2 竞争产品

  • GitHub：国际通用，无可争议的开源社区核心。
  • GitLab：提供自建服务器等差异化功能。
  • Coding 等国内托管平台：功能各有侧重。

3.1.3 产品定位与优势劣势

  • 定位：主打「国内访问速度快、中文支持友好」的代码托管平台，兼顾开源与私有仓库。
  • 优势：国内网络支持、中文社区、政府与企业客户背书。
  • 劣势：国际影响力小，生态不够完善。

3.2 市场与产品生态

3.2.1 核心用户群

  • 典型用户画像：
    • 年龄：20-40 岁之间；
    • 教育背景：IT、计算机相关专业居多；
    • 收入：中高水平；
    • 需求：高效率代码协作 + 国内访问稳定；
    • 潜在需求：自动化测试、社区交流、学习资料等。

3.2.2 用户群体之间的关系

  • 很多用户是团队协作关系，也可能是学校同学关系；具备一定社交属性，可通过动态关注、Fork、Star 等功能形成社群生态。

3.2.3 产品子产品与相关生态

  • 子产品：CI/CD、Wiki、企业版 Gitee（私有化部署）等。
  • 可结合：教育平台、培训机构、比赛平台（如与各类编程大赛合作）等，共同构建更广泛的开发者生态。

3.3 产品规划

3.3.1 新功能设计（NABCD 分析示例）

  1. Need（需求）：在 Gitee 上进行自动化测试、部署等 DevOps 流程。
  2. Approach（做法）：集成类似 GitHub Actions 的 CI 工作流，通过简单配置文件触发测试与部署。
  3. Benefit（好处）：国内用户无需切换到外网或借助第三方 CI，即可享受一站式 DevOps 服务，节省时间与成本。
  4. Competitors（竞争）：与 GitHub Actions、GitLab CI 的对比在于本地化部署、更好的国内服务器资源。
  5. Delivery（推广）：通过社区活动、技术沙龙、开源项目合作等方式进行宣传和教育，让更多开发者尝试并反馈。

3.3.2 角色配置（6 人，16 周）

  • 角色分工：

    1. 项目经理（1 人）：统筹进度、沟通需求、对外协调
    2. 后端开发（2 人）：实现 CI 流程、后端 API、数据库
    3. 前端开发（1 人）：实现用户界面的 CI/CD 工作流配置页
    4. 测试工程师（1 人）：编写自动化测试脚本，对关键功能回归测试
    5. UI/UE 设计（1 人）：负责新功能的界面与交互设计

  • 16 周详细规划（示例）：

周数 主要工作内容 负责人
1 - 明确需求、竞品分析、方案讨论
- 制定项目目标和里程碑		 项目经理、全体
2 - UI/UE 初步设计
- 后端架构与数据库设计
- 确定开发环境和工具链		 UI、后端、项目经理
3-4 - 后端搭建核心模块（CI API、任务队列）
- 前端搭建基础界面框架		 后端、前端
5-6 - 实现核心业务逻辑（任务触发、日志存储）
- UI 设计定稿并开始前端整合		 后端、前端、UI
7-8 - 测试环境搭建，自动化单元测试开发
- 修复第一批缺陷		 测试、后端、前端
9-10 - 初步上线内测版本
- 收集用户反馈，性能优化		 项目经理、测试、后端
11-12 - 新功能迭代（增加可视化测试报告、部署脚本模板）
- UI 细节打磨		 后端、前端、UI
13-14 - 测试完善、Bug 修复
- 编写使用文档和帮助中心		 测试、后端、前端
15 - 正式版发布前的预演，压测、回归测试 项目经理、测试
16 - 正式发布、团队总结、向社区公示版本更新内容 项目经理、全体

目标：在第 16 周发布改进版 Gitee，集成基本的 CI/CD 流程，并保证核心功能稳定上线。

posted @ 2025-03-12 13:27  凝纤  阅读(177)  评论(0)    收藏  举报