团队作业6——复审与事后分析

这个作业属于哪个课程	计科22级34班
这个作业要求在哪里	作业要求
这个作业的目标	复审与事后分析

团队成员：

姓名	学号
木萨江·米吉提	3122004960
巴音才次克	3222004974
李佳聪	3222004509
杨睿	3122004755

Alpha阶段项目复审

组名	优点	缺点	名次
白蓝混子队	功能多样性： 团队提供了较为全面的聊天功能，包括文本消息、图片消息、表情、文件传输等，满足了不同用户的需求。测试覆盖全面： 提供了详细的测试矩阵，覆盖了登录与注册、聊天模块、群聊模块和好友模块等多个方面，确保了基础功能的稳定性。技术栈多样性： 团队使用了多种技术栈，包括java环境、mysql、mongoDB、redis和浏览器等，显示出了较强的技术整合能力。	部分功能延迟： 有3个bug被延迟到下一个版本修复，包括登录连接turms服务器使用的还是userId和password，未来会尽力修改为token校验，这可能会影响安全性和用户体验。性能测试不足： 团队提到正常使用并未进行压测性能，这可能意味着在高负载情况下软件的稳定性和性能尚未得到验证。用户体验细节： 存在一些设计上的考虑，如注册发送验证码之后60秒之后才能再按，这可能影响用户体验。	1
拖延是你不队	Bug修复与分类： 团队在测试过程中发现并修复了4个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。用户需求明确： 团队明确了不同用户群体（学生、管理员）的需求和目标，并提供了相应的功能来满足这些需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了多个平台和浏览器，确保了软件在不同环境下的兼容性。	性能问题： 存在响应缓慢的问题，这可能是性能问题，需要在后续版本中得到关注和改进。功能延迟： 有3个Bug被延迟到下一个版本修复，包括图片显示失败、二级评论失败、信息刷新时文本框未能及时清空，这可能会影响用户体验。环境限制： 网站的限制主要体现在不同浏览器的兼容性问题，以及由于缺乏经济来源导致的服务器性能不足。	2
雄狮般的男人	全面的测试过程： 团队遵循了详尽的测试计划，包括测试准备、功能测试和回归测试，确保了软件质量。详细的测试矩阵： 提供了详细的测试矩阵，覆盖了教师端和学生端的多个关键功能，如注册登录、班级管理、作业设置和成绩管理。用户需求明确： 团队明确了教师和学生的需求和目标，并提供了相应的功能来满足这些需求。	界面设计待美化： 项目存在的问题之一是界面设计需要进一步美化，这可能影响用户体验。推广途径有限： 项目缺乏有效的推广途径，这可能限制了软件的普及和用户反馈的收集。	3
代码敲不完队	Bug修复与分类： 团队在测试过程中发现并修复了4个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。用户界面友好： 提供了登录注册、商品列表、我的订单等多个功能的用户界面截图，显示了界面的直观性和易用性。功能全面： 提供了包括登录注册、商品列表、我的订单、聊天消息、个人信息、我的收藏等在内的全面功能，满足了用户的基本需求。	Bug延迟修复： 存在4个Bug被延迟到下一个版本修复，包括用户登出后仍可使用JWT令牌、图片上传问题、不能重复评价同一订单、不能重复收藏同一商品，这可能会影响用户体验和数据准确性。性能问题： 提到响应缓慢的问题，这可能是性能问题，需要在后续版本中得到关注和改进。环境限制： 网站的限制主要体现在不同浏览器的兼容性问题，因此在各个浏览器上的支持情况存在差异；同时，由于缺乏经济来源，所使用的服务器成本较低，内存性能相对不足。	4
不要指望我们队	Bug修复效率： 团队在测试过程中发现并修复了6个Bug，显示出了较强的问题解决能力。功能全面性： 提供了包括登录、学生管理、课程管理、成绩查询等在内的全面功能，覆盖了学生和管理员的基本需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了多个功能模块，包括登录功能、学生端操作、管理员操作等，确保了核心功能的稳定性和可靠性。	用户体验问题： 界面逻辑上存在欠缺，进行了补充设计，这可能意味着初始版本的用户体验不够流畅。性能问题： 系统还未能承受大规模用户数量，这是后期需要关注和改进的主要方向。功能不完善： 提到功能不完善、界面逻辑不完善、界面不美观等问题，这些都是后续版本需要改进的地方。	5
Elegance	Bug修复效率： 团队在测试过程中发现并修复了6个Bug，显示出了较强的问题解决能力。用户友好的交互设计： 提供了简洁、轻量的网页形式，满足不同用户的需求，如模拟面试、法律咨询等场景。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了登录、对话、充值等多个功能模块，确保了核心功能的稳定性和可靠性。	功能延迟： 有2个Bug被延迟到下一个版本修复，包括前台窗口卡顿问题和用户输入数据的错误鉴别问题，这可能会影响用户体验。功能限制： 目前功能较少，需要后期继续改进优化，特别是对于未部署至服务器的问题，限制了软件的可访问性和实用性。	6
虹猫蓝兔七侠队	Bug修复效率： 团队在测试过程中发现并修复了1个Bug，显示出了较强的问题解决能力，且没有延迟修复的Bug。用户需求明确： 团队明确了不同用户群体（家长、学生、学长学姐、教师）的需求和目标，并提供了相应的功能来满足这些需求。功能全面性： 提供了展示学校分数线、环境、伙食、住宿、学生评价、课表等功能，覆盖了用户的主要需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了学号认证、学生评论、分数线展示等多个功能模块，确保了核心功能的稳定性和可靠性。	功能深度： 家长模块的信息获取有限，目前只有分数线，可能需要更多的信息和更好的排版。后端压力： 提到增加更多排版会对后端接口开发造成较大压力，这可能影响后续功能的扩展和维护。	7
小飞棍队	Bug修复与分类： 团队在测试过程中发现并修复了1个Bug，并对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。功能全面性： 提供了登录与注册、商户模块、消费者模块等多个功能，覆盖了商户和消费者的基本需求。测试覆盖广泛： 提供了详细的测试矩阵，覆盖了登录、注册、商品搜索、购物车等多个功能模块，确保了核心功能的稳定性和可靠性。	功能延迟： 有1个Bug被延迟到下一个版本修复，包括促销热榜和24小时热榜不显示榜单，这可能会影响用户体验。性能问题： 提到多台设备或多个浏览器允许同一用户同时登录的问题，这可能是性能或设计问题，需要在后续版本中得到关注和改进。功能限制： 商户功能比较单一，商品推荐功能未完善，只能根据总流水进行分析推送，无法根据用户个人喜好分析。	8
发际线和我作队	针对性的Bug修复：团队修复了一个具体的Bug，即图标显示错误，显示出对细节的关注。明确的设计决策：团队对于系统设计有明确的决策，例如不在登录页面设置注册功能，以保证系统的安全稳定。测试覆盖：团队提供了测试矩阵，覆盖了多个关键功能，如打开链接、界面展示、货物信息、货物编辑等，并在不同平台（Windows和安卓）上进行了测试。清晰的发布标准：团队明确了Alpha版本发布的出口条件，包括所有功能的完备性、关键Bug的修复以及测试人员的全面测试。	功能延迟：有一个Bug关于货物分类下面不显示当前分类下的货物信息被延迟到下一个版本修复，这可能会影响用户体验。功能限制：团队提到功能还未完善，目前的演示账号只能管理同一个仓库，这限制了软件的实用性。性能问题：没有提供关于性能测试的信息，这可能是一个需要关注的领域。	9
lzw1322	用户需求明确： 团队明确了管理员和用户的需求和目标，提供了相应的功能来满足这些需求，如商品发布、购物车管理等。功能测试覆盖： 提供了详细的测试矩阵，覆盖了用户注册与登录、发布商品、查找商品信息等多个功能模块，确保了核心功能的稳定性。用户界面友好： 提供了登录、注册、商品发布和购物车的用户界面截图，显示了界面的直观性和易用性。	Bug延迟修复： 存在一个Bug关于搜索功能无法正确处理某些商品名，这被延迟到下一个版本修复，可能会影响用户体验。性能问题： 提到商品数据有时候会加载不出来，这可能是性能问题，需要在后续版本中优化数据库，提高查询和访问效率。环境限制： 推荐使用edge浏览器，这可能限制了软件的兼容性和可访问性。	10
民族大团结	Bug修复与分类： 团队在测试过程中发现并修复了3个Bug，并且对Bug进行了清晰的分类，这有助于提高软件质量和维护效率。功能针对性： 团队针对学生、老师和管理员的不同需求提供了相应的功能，如成绩录入、成绩查询和权限管理，显示出对用户需求的深刻理解。测试覆盖： 提供了详细的测试矩阵，涵盖了登录功能、学生端、教师端和管理员端等多个方面，确保了关键功能的稳定性和可靠性。	性能问题： 存在一个Bug关于成绩排序错误，这可能影响用户体验和数据准确性，且被延迟到下一个版本修复。环境限制： 软件对运行环境有特定要求，如Windows10和MySQL 5.5，这可能限制了软件的兼容性和可访问性。数据同步问题： 在多用户同时操作时，可能会出现数据不同步的情况，这需要在后续版本中得到关注和改进。	11
物归原主队	Bug修复数量：团队修复了6个Bug，显示出较强的问题解决能力。功能实现：团队提供了包括用户注册与登录、发布失物信息、查找失物信息、认领失物等功能，覆盖了失物招领平台的核心需求。测试覆盖：提供了详细的测试矩阵，覆盖了关键功能模块，如用户注册与登录、发布失物信息等，确保了核心功能的稳定性和可靠性。	性能问题：存在系统响应时间较长的问题，这可能严重影响用户体验。硬件资源限制：硬件资源有限，无法支撑大规模扩展，这可能限制了软件的可扩展性和稳定性。数据库查询效率：数据库查询效率低，复杂查询影响整体性能，这需要在后续版本中得到关注和改进。	12
做不队	问题解决能力： 团队在测试过程中积极发现并修复了3个Bug，显示出了较强的问题解决能力。例如，使用nextTick解决了栏目切换后请求错误的问题，以及通过设置type:"button"解决了表单提交导致的页面刷新问题。用户反馈考虑： 团队考虑到了用户在浏览文章时刷新页面会丢失内容的问题，并计划在下一个版本修复，显示出对用户体验的重视。代码质量： 提到了代码的可维护性，并且有每日构建的实践，这有助于保持代码的质量和项目的持续集成。	Bug重现困难： 存在一些Bug在正常使用时不会触发，这可能会给未来的维护和测试带来挑战。用户体验问题： 团队提到了用户在修改个人信息后，上传头像无需点击确认修改即可完成更改，这可能会导致用户混淆，建议进一步优化用户交互流程。测试覆盖不足： 仅在Windows平台和两种浏览器上进行了测试，可能未能覆盖所有用户环境，建议增加更多浏览器和操作系统的测试。	13
永远写不队	Bug修复效率： 团队成功修复了3个已识别的bug，显示出了较强的问题解决能力，特别是在身份验证、功能选择和查找用户方面。测试覆盖： 提供了详细的测试矩阵，包括登录功能和聊天功能，这有助于确保软件的基本功能按预期工作。用户需求明确： 团队明确了用户的需求和目标，即日常聊天和学习交流，并提供了相应的功能来满足这些需求。	功能延迟： 有3个bug被延迟到下一个版本修复，包括图片显示失效、查找历史消息和添加好友，这可能会影响用户体验。功能单一： 团队提到功能较为单一，功能尚未完善，这限制了软件的实用性和吸引力。环境适应性： 测试仅在Edge浏览器上进行，没有提及其他浏览器或操作系统的测试，可能存在兼容性问题。	14
赛普拉·伊敏江	无	无	15

事后诸葛亮分析

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   本系统包括了社区内管理各项功能，并针对住户和物业人员两个角色给予不同的权限，从而解决社区管理混乱复杂的问题，达到减少人力资源的使用和降低管理费用、提高信息准确度和可靠性、改进社区管理和人员服务和建立高效的信息传输和服务平台、提高信息处理速度和利用率的效果。定义清楚并对典型用户和典型场景有清晰的描述。

2. 是否有充足的时间来做计划？
   有。

3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
   针对提出的不同意见，全组组员通过线上会议和群聊进行讨论权衡或以投票形式来决定最终意见。

计划

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

杨睿：没有。大部分都完成了，小部分是能力不足或花费的时间较多。

木萨江：基本完成。剩下的一些细节由于时间不够而放弃了。

李佳聪：由于没有涉足难度大的开发工作，所以我能完成我原计划的工作。

巴音才次克：全部完成了，部分接口时间不足弃用功能。

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

有一些，比如说过于纠结页面的某些样式结构，花费了大量的时间研究，最后还是舍弃了这部分内容，因为不合预想或不如之前的好。

以及例如在开发页面时会对一些细节过于钻牛角尖，事后发现并没有必要纠结。

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

是，每一项任务都通过github的issue分模块定义，清晰标明了组员的任务情况、进度进展和交付情况。

4. 是否项目的整个过程都按照计划进行？

并没有严格按照计划进行。计划中某些比较困难的部分花费了较多的时间，也有些较简单的部分花费了较少的时间。虽然实际进度对后面的计划有一定的打乱，但是后期团队也加快了自己的脚步和对接进度，最后基本完成了我们定下的计划。

资源

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

有大部分资源，团队部分成员有开发经验，有引导作用。时间较为充分。

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

由有开发经验的队友给出建议并根据自身情况调整；较为粗糙，实际开发中有其他不可预知的问题。

3. 用户测试的时间，人力和软件/硬件资源是否足够？

测试时间足够；团队6人，人力资源足够；硬件/软件方面也没有较大问题。

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

没有。

变更管理

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

和项目有关的功能改动和对接过程中的BUG，我们采用了GITHUB团队的项目展板进行及时的记录和issue推送，同时在交流群里或私下及时告知任务负责人去执行这个任务。我们可以通过项目展板和issue上的消息和问题具体描述知道自己需要做什么，总体来说在整个项目过程中每个成员接收变更消息的速度良好。

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

在项目中我们会提前决定好整个项目所需实现的功能，以及各组内决定实现的逻辑。对于不可抗力因素难以实现的功能，我们会决定从简到繁的方法，先实现简单的功能，再到逻辑复杂的功能，先实现整体框架，再到具体细节。其次，在功能的实现顺序上，会很大程度影响项目的完整性和用户体验的属于必须实现和优先实现的功能。

3. 项目的出口条件（Exit Criteria）是否得到清晰的定义？

我们项目的出口条件是：后端单元测试通过率100%，方法覆盖率100%，分支覆盖率90%以上，保证后端接口正常；前端页面交互顺畅，基本功能无异常，浏览器适配正常；整体项目功能完整，用户使用体验良好。

4. 员工是否能够有效地处理意料之外的工作请求？

在本次项目中的意料之外的工作请求就是一些前后端交互的BUG修复。成员都能及时高效的接收BUG反馈和及时处理部署。

设计/实现

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

在第一周的时候，全体队员一起进行了项目功能的设计；在第二周后台开发人员进行了数据库的设计、 前端开发人员和后台开发人员进行了接口的设计，随后UI进行了原型设计；以上工作都是在合适的时间由合适的人完成的。

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

起初，UI进行原型设计时参考的项目架构图与接口的设计有出入，经过询问后得知参考的不是同一个架 构图。讨论后决定参考同一个架构图，以接口的设计为主，对一些功能进行调整并体现在UI上。

3. 什么功能产生的Bug最多，为什么？

住户相关和人员管理的部分；因为功能相对其他页面来说较复杂和多样，bug出现的也十分多样。

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

没有严格执行代码复审，一是时间限制，二是团队里多半是第一次接触项目代码，不熟悉代码复审的环节和流程。初期严格执行了代码规范，但到后期出于时间的紧迫，没有很严格执行代码规范，但基本的代码规范是严格遵守的。

测试/发布

1. 团队有没有测试计划？为什么没有？

我们有测试计划，而且因为有了计划，测试人员可以不用胡乱测试。

2. 有没有做过正式的验收测试？

没有，因为时间赶所以只是将流程跑了一遍看看有无问题。

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

没有，我们采用人工测试，通过不断运行代码来检查bug。

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

每天都在测试，如果添加一个新的功能就会立刻测试；有用，会及时发现存在的问题；测试的内容应该更加全面。

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

在个别浏览器下会出现界面编排错乱。

6. 我们学到了什么？如果历史重来一遍，我们会做什么改进？

通过运用软件工程的知识去将进行开发可以使得我们能更加高效地完成项目，敏捷开发的流程也对项目的完成有着不可或缺的作用；如果历史重来一遍，我们会将需求分析的更加透彻，找到用户迫切需要的，不可或缺的功能，在开发上亦先将所需知识深入学习，以便开发的顺利进行。
总结
当前状态属于哪个档次
当前阶段，团队的项目处于Alpha版本，已经实现了大部分核心功能，但存在性能瓶颈、安全性漏洞和数据同步问题。综合来看，属于中等档次。虽然功能完整，但用户体验和系统稳定性仍需提升，尤其在数据处理和性能优化方面。

最需要改进的一个方面
最需要改进的方面是系统的性能优化。当前，平台响应时间较长，数据查询效率低，复杂查询会影响整体性能。此外，数据同步问题和并发处理能力不足也成为影响平台稳定性的关键因素。下一步应集中在性能调优和服务器硬件资源的扩展上，确保在高并发情况下能够正常运行。

对照敏捷开发的原则，做得最好的是哪些
对照敏捷开发的原则，团队在迭代开发和快速反馈上做得较好。通过持续测试和修复bug，团队能够快速响应用户需求，并及时调整开发方向。团队在功能开发过程中注重用户需求，进行了多轮验证与测试，确保核心功能得以实现并满足初期用户的基本需求，符合敏捷中的“交付工作软件”的原则。

下一阶段如何提高软件工程的质量
下一阶段，团队将通过以下方式提高软件工程的质量：首先，进行性能优化，针对查询效率和系统响应速度进行调优；其次，加强安全性设计，提升代码的可维护性，优化项目架构和模块化设计，提升可扩展性。最后，团队将加强代码审查与测试流程，确保代码质量和稳定性。

姓名	团队贡献分	可验证贡献
杨睿（组长）	23	PM&前后端开发
木萨江	21	前端开发
巴音才次克	19	需求设计&开发
李佳聪	17	测试