事后诸葛分析

事后诸葛分析

软件工程 🔗计科21级34班
作业要求 🔗团队作业6——复审与事后分析
Github连接 🔗CampusTheards
作业目标 复审与事后分析

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    我们的软件主要解决的是在校大学生无法有效的与大学教师之间通过一个公共的平台沟通交流的问题。

    典型用户：学生、教师、校友

  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

    我们原计划的所有功能都按交付时间完成了，用户数量并未达到。

  3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    软件的质量极大的提高了，不论是在软件的规模还是在功能数量，以及界面的美观程度都有很大的提高。

  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    用户量虽然还未到达目标值，但是根据目前用户的反馈，用户的接受程度比我们预想的还高，我相信，我们离目标更近了。

计划

  1. 是否有充足的时间来做计划?

    有

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    我们采用辩论的方式，若有一方被另一方说服，问题就解决了。

  3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    全部工作都完成了。

  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

    并没有。

  5. 是否每一项任务都有清楚定义和衡量的交付件?

    并不是很清楚每个任务的定义，在完成的过程中再逐渐清楚。

  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    基本按照计划进行，项目在敏捷冲刺的某一天出现了意外，发现一个功能比预想中的要难以实现，我们花了大量时间去解决，这个问题我们但是没有估计到，是因为错估了这个功能点的实现难度。

  7. 在计划中有没有留下缓冲区，缓冲区有作用么?

    有留下缓冲区，缓冲区为我们后续 Bug 修复提供了宝贵的时间。

  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    每一次进行站立会议，必须有一个人负责记录下会议内容，也可能是使用某种工具记录。

资源

  1. 我们有足够的资源来完成各项任务么?

    有的。

  2. 各项任务所需的时间和其他资源是如何估计的，精度如何?

    时间与其他资源估计精度较为准确，偏差不超过 10%。

  3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    人力、软硬件资源足够，但是对于 UI 设计的难度确实低估了。

  4. 你有没有感到你做的事情可以让别人来做（更有效率）?

    并没有，我们的分工挺合理的。

  5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

    如果再来一次，我们一定会在开始前定好代码命名的规范。

变更管理

  1. 每个相关的员工都及时知道了变更的消息?

    我们的消息变更会发布在通知群。

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    小组内成员讨论决定。

  3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

    • 基本功能完成： Alpha版本应该包含软件的基本功能，以便用户能够执行最基本的任务。这不一定是最终功能集，但必须包含一个可用的、基本的产品版本。
    • 内部测试通过： 在Alpha发布之前，团队通常会进行内部测试。这包括开发团队自己的测试，确保软件在核心方面是可靠的。
    • 核心稳定性： 虽然Alpha版本可能仍存在一些缺陷，但核心功能应该是相对稳定的。不能有太多的严重错误，阻止用户正常使用软件。
    • 初步性能优化： 软件的性能可能不是最优的，但在Alpha版本中，应该确保没有明显的性能瓶颈。用户不应该遇到过于显著的延迟或性能问题。
    • 合适的用户群体： Alpha版本通常是面向内部团队、特定测试用户或早期采用者的。确保目标用户群体了解软件的预期状态，并能够提供有价值的反馈。
    • 错误和问题跟踪： 设定一个错误跟踪系统，以便及时收集和解决用户报告的问题。这有助于提高软件的质量。
    • 版本控制和备份： 在发布Alpha版本之前，确保有适当的版本控制系统，并对数据进行适当的备份。这有助于在发现严重问题时进行回滚或修复。
    • 用户文档和支持： 提供基本的用户文档，以帮助用户了解软件的基本用法。此外，准备好提供支持，以解答用户可能遇到的问题。

  4. 对于可能的变更是否能制定应急计划?

    通过腾讯会议开启紧急会议可以制定应急计划。

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么?

    设计工作由主要编码人员来完成，在工作开始前开始。

  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的?

    有，大家通过讨论解决了。

  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档?

    是的，运用了 UnitTest 、 TDD 、 UML 这些工具来帮助设计与实现，保证了代码的质量和可维护性。通过持续集成和持续交付，项目团队能够更快速地响应变化，确保软件始终保持高水平的稳定性。这种注重测试与设计的开发方法使得团队更容易排查和解决潜在问题，为软件的长期发展奠定了坚实的基础。

  4. 什么功能产生的Bug最多，为什么?在发布之后发现了什么重要的bug?为什么我们在设计/开发的时候没有想到这些情况?

    Bug最多的功能通常是涉及复杂业务逻辑或涉及多个模块交互的部分。这是因为这些功能往往存在更多的边界情况和可能的执行路径，导致开发人员在设计和实现时难以覆盖所有可能的情况。

    在发布后发现的一些重要bug可能是由于在真实环境中出现了特定的使用情境或者用户行为，这些情境在测试阶段难以完全模拟。有时候，这些问题可能是由于系统的规模、负载或与其他外部系统的集成引起的，而这些方面在开发过程中难以完全预测。

    在设计和开发阶段没有考虑到这些情况的原因可能有几个。首先，时间和资源的限制可能导致无法对所有可能性进行详尽的测试和分析。其次，可能存在对真实用户行为和使用环境的了解不足，导致在设计时未考虑到所有的使用情景。此外，团队成员之间的沟通不畅，或者设计评审过程不够严密也可能导致一些潜在问题在设计和开发阶段未被发现。

  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范?

    代码复审是我们项目中的重要环节。我们采用了以下步骤来进行代码复审：

    1. 提出变更请求（Pull Request）： 开发人员完成任务后，会创建一个变更请求，包括相关的代码修改、新增功能或修复。
    2. 团队成员审查： 其他团队成员（通常是有经验的开发人员）会审查这个变更请求。审查过程包括检查代码质量、功能实现是否符合需求、是否有潜在的问题等。
    3. 反馈和讨论： 审查者会提出建议和反馈，开发人员需要及时回应并进行必要的修改。这一过程可能包括讨论代码结构、性能优化、潜在的安全问题等。
    4. 自动化工具： 我们还使用自动化工具来检测潜在的代码问题，确保符合代码规范。这些工具可以检查语法错误、代码风格、安全漏洞等。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？

    是的，我们团队有一个测试计划。测试计划是确保软件质量的重要组成部分，它有助于识别和修复潜在的问题，确保软件满足用户需求并且在各种条件下都能正常运行。

  2. 是否进行了正式的验收测试？

    是

  3. 团队是否有测试工具来帮助测试？

    是的，我们团队使用了多种测试工具来帮助测试，以确保软件质量和稳定性。以下是一些我们常用的测试工具类型：

    1. 单元测试工具： 我们使用单元测试工具来测试代码的个别单元，确保其按照预期工作。
    2. 性能测试工具： 我们使用性能测试工具来评估系统的性能、稳定性和可伸缩性。我们使用 JMeter用于模拟多用户并发访问，以评估系统在负载下的表现。
    3. 安全测试工具： 用于检测和缓解潜在安全风险的工具。静态代码分析工具、漏洞扫描工具等都可以用于安全测试。
    4. 代码覆盖工具： 用于评估测试覆盖率，确保测试覆盖了代码的大部分区域。我们使用了 JaCoCo

  4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

    团队测量和跟踪软件效能的方法通常包括性能测试和压力测试。以下是一些我们可能采用的方法和改进建议：

    1. 性能测试： 我们使用性能测试工具来模拟不同负载下的软件行为，以评估其响应时间、资源利用率和整体性能。这通常包括负载测试、并发用户测试和基准测试。我们关注的性能指标可能包括响应时间、吞吐量、并发用户数等。
    2. 压力测试： 压力测试是通过模拟高负载条件来测试系统的稳定性和性能极限。这种测试有助于确定系统在超过正常使用情况的负载下是否能够正常工作。我们使用压力测试工具如Apache JMeter来执行这类测试。
    3. 测量和跟踪工具： 我们使用监控和分析工具来实时监测系统的性能。这些工具包括应用性能管理（APM）工具、日志分析工具、服务器监控工具等。通过这些工具，我们可以及时发现性能问题并采取相应的措施。

  5. 在发布的过程中发现了哪些意外问题？

    数据迁移或更新可能导致数据库中的问题，例如数据丢失、不一致性或者数据格式错误。

成员角色与具体贡献

姓名 学号 角色 贡献分
林程星 3121005133 PM，Test 25.4
邓梓荣 3121005121 Dev，Test 25.5
曾中港 3121005151 Dev，Test 25.2
刘鸿杰 3121005134 Dev，Test 25.3
刘苑佳 3121005136 Test, Dev 25.3
陈昊宇 3121005115 Test, Dev 25.3
冯威炀 3121005123 Test, Dev 25.2
posted @ 2023-12-12 22:07  _xxdd  阅读(39)  评论(0)    收藏  举报