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

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

这个作业属于哪个课程	<计科22级34班>
这个作业要求在哪里	<作业要求>
这个作业的目标	完成软件的测试与发布
GitHub 链接	https://github.com/tangliweiwww/ChatGpt

一、团队

1.团队名称：Elegance

2.团队成员

姓名	班级	学号
唐立伟（组长）	计科4班	3122005404
吴秋雪	计科3班	3222004892
黄妍仪	计科4班	3222004767
李思柔	计科4班	3222004638
何晓漫	计科4班	3222004765

二、Alpha阶段项目复审

小组	优点	缺点	名次
<拖延是你不对>	该程序具备全面的功能性，满足了流浪动物救助平台的所有关键功能需求。团队成员的角色和职责划分得非常明确，从团队介绍中可以清晰地看到每个成员的专业领域和工作重点。程序的测试阶段非常详尽，包含了对多种操作系统（包括Windows、MacOS和Linux）、不同浏览器和各种硬件配置的全面测试方案。	程序在数据处理方面的能力有所不足，这可能会削弱平台利用数据进行决策的能力，不利于平台的持续发展和竞争力的提升。程序在技术层面存在一些挑战，表现为响应速度慢、图片加载失败、二级评论功能异常以及信息刷新时文本框内容未能自动清除等问题。尽管这些问题中的一部分已经有了解决方案，但它们仍然暴露了开发过程中技术实施的不足，这可能会对用户的体验造成负面影响。	1
<小飞棍队>	功能配置均衡：项目集成了多样化的功能选项，以迎合用户不同的需求，例如个性化商品推荐、实时WebSocket通讯、以及高效的商品搜索能力等。发布标准清晰：项目为Alpha版本设定了明确的发布条件，涵盖了关键功能的开发完成、性能指标的满足、以及通过内部测试等关键要素。	多设备登录限制不足：项目目前允许同一用户在多个设备或浏览器上同时登录，这可能导致账户安全和数据同步的问题。商品推荐算法单一：当前的商品推荐系统主要依赖于整体销售额数据进行推荐，缺乏对用户个人偏好的深入分析和个性化适配，限制了推荐系统的精准度和用户满意度。	2
<虹猫蓝兔七侠队>	功能设计具有高度针对性：项目精心规划了功能模块，以满足不同用户群体（包括家长、学生、毕业生和教师）的特定需求，为他们量身定制了相应的功能。用户评论审核机制严格：项目实施了严格的用户评论管理策略，通过引入学号验证系统来区分校友评论和匿名评论，确保了评论内容的真实性和可靠性。	功能范围较为狭窄，主要局限于提供学校信息和用户评论，缺乏深层次的用户互动和个性化服务，这可能无法满足用户对于复杂功能和定制化体验的需求，从而影响用户对软件的忠诚度和活跃度。在数据收集和处理方面存在不足，尤其是在家长服务模块中，信息来源单一，主要依赖分数线信息，这远远不能满足家长对学校全面信息的需求，限制了家长对软件的依赖和使用频率。	3
<不要指望我们队>	功能测试非常彻底，通过精心设计的测试方案，对各种功能在不同浏览器环境下进行了详尽的测试。功能设计相当周全，从整体的功能框架来看，为不同用户角色（如管理员、教师和学生）提供了多样化的功能模块。	系统承载能力不足：当前系统在面对全校数千名学生的同时使用时显得力不从心，这在大规模部署时构成了一个明显的限制因素，阻碍了软件的广泛推广和持续应用。用户界面设计不足：系统在用户界面方面存在逻辑不清晰和美观度不足的问题，这些问题可能会对用户的视觉感受和操作便捷性产生负面影响。软件部署和分发挑战：软件在推向市场的过程中可能会遇到障碍，难以有效地传递到目标用户手中，这可能会削弱软件的普及率和实际应用效果。	4
<物归原主队>	测试程序严谨：该流程遵循了一套严格的测试规范，确保了测试过程的全面性和系统性。数据管理和保护重视：团队展现出了对数据保护和性能提升的重视，这体现在他们对数据安全和性能优化的持续关注和实际措施上。	软件缺陷较多且部分严重：在测试过程中共发现16个软件缺陷，尽管部分已经得到解决，但仍存在一些难以复现、无法修复或修复进度缓慢的缺陷。用户界面设计存在缺陷：根据缺陷报告，用户界面的布局存在问题，文字、图标和按钮的尺寸和位置设置不当，这可能会影响用户的操作便利性和视觉体验。系统性能问题显著：系统存在响应速度慢、数据库查询效率低下以及硬件资源不足等问题，这些性能问题在实际使用中可能导致用户频繁遭遇等待，影响用户体验。	5
<雄狮搬的男人队>	功能设计满足特定用户需求：系统的功能模块是针对教师和学生的独特需求和目标量身定制的，确保了功能与用户角色的紧密对接。测试流程遵循严格标准：测试过程遵循了一套精确和细致的步骤，确保了测试的严谨性和有效性。	软件性能有待提升：尽管软件已经实现了核心功能，但仍然存在一些性能问题，比如在某些情况下请求处理超时，这些问题仍在解决中。这表明软件在性能优化方面可能存在缺陷，可能会对用户的使用体验造成影响。市场推广和用户增长策略不足：项目目前缺乏有效的推广渠道和用户拓展计划。依赖于朋友推荐这种较为有限的推广方式，这限制了产品向更广泛用户群体的推广，不利于产品的大规模普及和长远发展。	6
<代码敲不完队>	界面直观，功能模块划分明确，让用户能够迅速理解平台提供的各项服务。功能设计紧密贴合用户实际需求，有效响应学生寻找性价比高商品和个人用户出售闲置物品的需求。用户需求精准对接：团队明确区分了不同用户群体（如家长、学生等）及其需求。功能全面且实用：平台提供了包括分数线查询、校园环境展示、伙食住宿信息以及学生评价系统等，特别是通过学号认证区分校友和匿名评论的创新设计。	界面设计需改进：当前界面设计较为简陋，可能降低用户体验。尽管优化界面会增加后端开发负担，但适度的前端改进能显著提高用户的视觉享受和满意度。数据处理和登录系统待加强：数据处理能力有限，限制了平台基于数据进行优化和提供个性化服务的能力。性能和兼容性有待提升：由于服务器性能不足，平台运行可能遭遇卡顿，影响用户体验。Bug修复需持续关注：尽管已修复部分问题，但仍存在如响应延迟、登出后令牌滥用、图片上传失败、评价和收藏重复等问题，需在后续版本更新或部署时解决。	7
<汪汪队>	推广策略合理：采取由近及远、分阶段推进的策略，与社区管理系统的特性相契合。功能模块直观：系统功能模块展示清晰，便于用户和管理人员快速把握系统功能。功能设计细致：系统提供了信息管理、报修流程、社区活动等实用功能，并通过权限设置区分管理员与住户权限，提升了系统的灵活性与安全性。	服务器部署待完善：系统目前仅限本地运行，未部署服务器，影响了系统的广泛使用和便捷性，不利于多社区的大规模应用。浏览器兼容性待提升：尽管支持主流浏览器，但存在UI错位问题，需进一步优化以确保不同浏览器间的一致性。Bug修复和功能完善需跟进：部分UI兼容性和信息同步问题将推迟至下一版本修复。同时，系统功能有待进一步完善，存在车辆资料显示和活动内容溢出等未解决问题，可能影响用户体验。	8
<发际线和我作队>	该系统的使用过程非常用户友好，用户无需复杂的安装步骤。只需通过浏览器访问指定的网址，即可轻松进入系统，开始操作。这种设计大大简化了用户的入门门槛，使得即使是技术不太熟练的用户也能快速上手。此外，由于不需要额外的软件安装，用户可以在任何有网络连接的设备上随时随地访问系统，这不仅提高了使用的便捷性，也增强了系统的可访问性。总的来说，这种基于网页的访问方式为用户提供了一种快速、直接且高效的使用体验。	平台兼容性有待提升：软件目前主要推荐在电脑端使用，对于偏好移动设备的用户来说不太方便，这限制了软件的适用范围和潜在用户基础，影响了软件的普及和广泛应用。用户注册流程需优化：系统在登录界面未提供注册选项，需要管理员先行登录后手动添加用户账号，虽然这可能是出于安全和稳定性的考虑，但对普通用户来说，这大大降低了使用的便捷性，提高了使用门槛，可能会导致一些潜在用户因为注册过程复杂而选择不使用该软件。	9
	发布策略灵活且具备扩展性：该策略允许产品在初期快速收集用户反馈，这对于产品的迭代和完善至关重要。通过这种方式，产品能够迅速响应市场变化和用户需求，从而实现持续优化功能设计精准对接用户角色：系统根据用户角色的不同，如管理员和普通用户（包括购买者和商家），定制了相应的功能。这种设计不仅提高了用户体验，也增强了系统的安全性和操作的便捷性。管理员能够高效地管理平台，而普通用户则可以根据自己的需求使用特定的功能，如购买者的商品浏览和购买，商家的商品管理和订单处理	软件存在待解决的技术问题：尽管已修复一些Bug，但仍有关键问题如商品数据加载失败和搜索功能异常未得到解决，这些问题严重妨碍了用户的日常使用，损害了用户体验。软件性能和功能需进一步提升：软件的功能尚未完全实现，特别是数据库查询效率需要优化，以提高系统性能。同时，存在一些Bug如搜索功能处理错误和商品数据加载问题，这些问题的修复被推迟或尚未找到解决方案，显示了软件在性能优化和功能完善上还有很大的进步空间。	10
<民族大团结>	测试流程周密：该产品在测试阶段表现出了较高的全面性，这有助于在产品推向市场前捕捉并修复潜在的问题。这种细致的测试流程不仅确保了产品的质量，也为产品的持续改进提供了坚实的基础，使得产品团队能够快速响应测试中发现的问题，并据此优化产品性能。功能设计满足用户实际需求：产品的功能设计紧密围绕用户的实际操作需求展开，确保了用户在使用过程中的便捷性和满意度。这种以用户为中心的设计理念，使得产品能够更好地服务于目标用户群体，提高了用户的操作效率，并增强了用户对产品的忠诚度。通过不断调整和优化功能，产品能够满足用户日益变化的需求，从而在竞争激烈的市场中脱颖而出。	系统功能需进一步丰富：目前系统的功能主要集中在基础的登录、信息管理和成绩管理等常规操作上，缺少一些创新或深入的功能。这种局限性使得系统在功能上显得较为单一，未能提供更多特色或增值服务，限制了系统在满足用户多样化需求方面的表现。成绩排序功能存在缺陷：当前系统存在一个未修复的问题，即成绩排序时可能会出现错误，导致学生在根据不同标准查看成绩时遇到排序混乱的问题。这种情况不仅影响了学生查询成绩的便捷性，也降低了成绩信息的准确性，从而损害了用户的整体体验。	11
<白蓝混子队>	用户定制化功能设计：系统根据不同用户群体的需求，提供了定制化的功能。例如，对于学生用户，系统强化了社交互动的功能；而对于其他用户，则提供了以AI为核心的聊天服务。这种差异化的功能设计旨在提升用户体验，满足不同用户的特定需求。全面的功能测试保障：系统经过了全面的测试流程，确保了核心功能的稳定性和可靠性。这种细致的测试策略有助于维护系统的日常运行，确保用户能够顺畅地使用基础功能，从而提升了用户对系统的信任度和满意度。	软件尚需完善：尽管修复了一些Bug，但软件在用户体验上仍有不足，如登录过程中的动画卡顿和验证机制的不完善。许多功能还未达到发布标准，显示出软件在功能完善度和系统稳定性上仍有较大的提升空间。软件推广受限：由于软件尚未完全成熟，目前仅在小范围内测试使用。这种限制阻碍了软件的广泛传播和用户反馈的收集，影响了软件的快速迭代和优化，可能会推迟其在市场上的全面推广。	12
<做不队>	浏览器兼容性测试广泛：进行了广泛的浏览器兼容性测试，确保了软件在多种流行的浏览器上都能稳定运行，增强了软件的通用性和用户覆盖面。Bug修复效率显著：团队在Bug修复方面取得了显著成效，这不仅展示了团队在问题诊断和解决方面的能力，也反映了团队对软件质量控制的重视。	技术问题亟待解决以提升用户体验：目前存在一些技术问题，如登录过程中的动画卡顿和登录验证方式需要改进，这些问题尚未得到解决或被推迟到下一版本。此外，还有如路由守卫可能导致的请求问题和页面刷新导致的文章内容丢失等问题，这些问题可能会干扰用户正常使用博客，降低使用的流畅性和便利性，影响用户体验。产品设计需考虑互动逻辑：产品设计中存在一些不符合常规的互动逻辑，例如允许同一用户对文章多次点赞，这可能会对数据的真实性和互动质量造成影响，不利于构建一个健康、合理的社区互动环境，从而影响平台的长期发展	13
<永远写不队>	用户需求的精准对接：软件通过明确划分用户的日常沟通和学术交流需求，确保了其功能能够精确地服务于这些需求。用户可以轻松地搜索并添加特定的联系人进行对话，有效地满足了他们的日常交流需求。软件的功能设计紧密聚焦于聊天和学术交流这两个核心领域。高便捷性的使用体验：软件的使用流程极为简洁，用户只需通过点击一个链接即可快速访问软件，无需复杂的安装过程。这种简便的操作方式极大地提升了用户的便利性，使得软件的使用变得轻松快捷。	用户体验受阻的技术问题：当前版本中，一些关键功能如图片显示、历史消息检索和好友添加存在问题，这些问题将推迟至新版本中解决。这些技术障碍对用户的日常使用造成了不便，影响了用户的整体体验。功能局限性及扩展需求：软件目前的功能集相对基础，主要限于聊天界面操作和好友管理等核心功能。它缺少高级聊天互动选项（如语音和视频通话）、消息通知和聊天记录管理等增强功能，这些功能的缺失限制了软件满足用户多样化和个性化需求的能力。此外，有三个已知的技术问题（图片显示问题、历史消息查找、好友添加功能）将延期至后续版本更新时修复，进一步凸显了软件在功能完善方面的迫切需求。	14
<赛普拉·伊敏江>	无	无	15

三、事后诸葛亮分析

1.设想和目标

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

我们的软件旨在提供一个平台，让用户能够通过微信公众号登录并访问各种大模型，同时能够根据不同场景设定需求。这个问题定义是清晰的，因为它涉及到了用户便捷性（通过微信公众号登录）、多样性（访问各种大模型）和个性化（设定不同场景）。典型用户可能包括研究人员、开发者、企业决策者等，他们需要利用大模型来解决特定问题或提高工作效率。典型场景可能包括数据分析、自然语言处理、图像识别等。如果你们的软件能够清晰地描述这些用户和场景，并且能够展示如何满足他们的需求，那么问题定义就是清晰的。

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

• 功能实现： 功能基本实现
• 交付时间： 时间合理

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

• 代码质量： 通过代码审查和静态代码分析工具来衡量代码质量的提高。
• Bug率： 通过跟踪bug数据库，计算bug的发现率和解决率。
• 开发周期： 通过项目管理工具跟踪每个功能的完成时间，与上一个阶段进行比较。
• 用户满意度： 通过用户调查和反馈来衡量用户满意度的变化。
• 具体提高：代码审查的通过率从80%提高到了90%，bug率从每千行代码5个降低到了3个，这些都是具体的提高。

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

• 与预期对比：整体符合预期，但在用户体验方面仍有提升空间。

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

• 用户需求调研不足： 我们发现在项目初期对用户需求的调研不够深入，导致产品功能与用户实际需求存在偏差。未来，我们将投入更多资源进行市场调研和用户访谈，以确保产品能够满足目标用户群体的实际需求。

• 敏捷开发实践不够： 项目中敏捷开发方法的应用不够充分，导致产品迭代速度慢，对市场变化的响应不够灵活。我们将加强敏捷开发实践，提高团队的响应速度和适应性。

• 质量控制不足： 在开发过程中，我们发现软件的bug率较高，影响了用户体验。未来，我们将加强代码审查和自动化测试，以提高软件质量。

2.计划

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

在项目初期，我们确实投入了一定的时间来制定计划，但事后看来，我们本可以预留更多的时间来深入分析需求和风险，以及制定更详细的项目计划。如果时间可以重来，我们会在计划阶段投入更多的时间和精力，以确保计划的周全性。

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

我们通过定期的团队会议和工作坊来收集意见和解决分歧。通过开放的沟通和讨论，我们尝试找到共识。如果历史重来一遍，我们会更加重视团队成员的反馈，采用更多的协作工具来收集和整合意见，确保每个人的意见都能被听到和考虑

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

并非所有原计划的工作都完成了。部分任务由于优先级的调整、资源分配的问题或是对项目范围的重新评估而未能完成。如果时间可以重来，我们会更好地管理项目范围和优先级，确保关键任务能够按时完成

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

是的，我们发现在项目中有一些工作事后看来并不必要或者价值不大。这通常是由于对需求理解不充分或市场变化导致的。如果历史重来一遍，我们会加强与用户的沟通，确保我们的工作始终与用户需求保持一致。

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

我们尝试为每项任务定义清晰的交付件，但在实际操作中，有些任务的交付标准不够明确，导致评估和验收过程中出现了一些混乱。如果时间可以重来，我们会为每项任务制定更明确的交付标准和衡量指标

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

项目的进展并不完全按照计划进行。我们遇到了一些意外，比如关键人员的离职、技术难题的解决时间超出预期等。有些风险是由于我们对市场和技术趋势的估计不足，或是对团队能力的过度乐观。如果时间可以重来，我们会在计划中加入更多的风险评估和应对策略。

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

我们在计划中确实预留了一定的缓冲区，但在项目执行过程中，由于一些不可预见的问题，缓冲区并没有起到预期的作用。如果时间可以重来，我们会根据项目的实际风险和不确定性，更加合理地分配缓冲区。

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

将来的计划中，我们会对缓冲区的定义进行调整，确保它们能够更有效地应对项目风险。同时，我们会尽量避免加班，通过更合理的工作分配和时间管理来提高效率。

（9）我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 加强前期调研： 我们会在项目开始前进行更深入的市场和技术调研，以减少项目中的不确定性。
• 优化沟通机制： 我们会采用更多的协作工具和方法，以确保团队成员之间的沟通更加顺畅。
• 明确任务和交付标准： 我们会为每项任务制定更明确的交付标准和衡量指标，以提高项目的透明度和效率。
• 加强风险管理： 我们会在项目计划中加入更多的风险评估和应对策略，以减少意外对项目的影响。
• 合理分配资源： 我们会根据项目的实际需要，合理分配人力和物力资源，确保关键任务能够优先完成。
• 提高灵活性： 我们会在项目计划中预留更多的灵活性，以适应市场和技术的变化。

3.资源

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

在项目执行过程中，我们发现资源分配存在一定的不足，特别是在关键时期，人力资源显得尤为紧张。如果时间可以重来，我们会在项目规划阶段进行更准确的资源需求分析，并预留一定的缓冲资源以应对不可预见的情况。

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

我们通过历史数据、专家意见和类似项目的经验来估计各项任务所需的时间和资源。然而，由于项目复杂性和不确定性，这些估计的精度并不总是很高。如果历史重来一遍，我们会采用更科学的估计方法，如三点估计法，结合更多的历史数据和市场分析，以提高估计的准确性。

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

在项目中，我们确实发现测试资源有时不足，特别是在项目后期，测试时间常常被压缩以赶进度。对于非编程资源，如美工设计和文案，我们有时确实低估了它们的难度和所需时间。如果历史重来一遍，我们会为测试阶段预留更多的时间和资源，并正确评估非编程任务的难度和所需时间，确保这些任务能够得到充分的重视和资源。

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

是的，我们发现有些任务如果分配给具有特定技能或经验的团队成员，可能会更有效率。例如，一些技术性较强的任务如果由技术专家来执行，可能会更快完成。如果历史重来一遍，我们会根据团队成员的专长和经验来更合理地分配任务。

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

• 资源规划： 我们会在项目规划阶段进行更细致的资源需求分析，确保资源的充足性和合理性。
• 估计方法： 我们会采用更科学和精确的估计方法，结合历史数据和市场分析，以提高时间和资源估计的准确性。
• 测试资源： 我们会为测试阶段预留更多的时间和资源，确保软件质量。
• 非编程任务评估： 我们会正确评估美工设计、文案等非编程任务的难度和所需时间，确保这些任务能够得到充分的重视。
• 任务分配： 我们会根据团队成员的专长和经验来分配任务，确保任务能够更高效地完成。
• 持续监控和调整： 我们会在项目执行过程中持续监控资源使用情况，并根据实际情况进行调整，以确保资源的有效利用。

4.变更管理

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

在项目执行过程中，我们努力确保所有相关员工都能及时获得变更消息。我们通过定期会议、电子邮件更新和项目管理工具来沟通变更。然而，有时信息传递可能不够迅速或不够清晰。

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

我们通常基于功能的重要性、紧迫性以及对项目目标的贡献来决定哪些功能需要推迟，哪些必须实现。我们会评估每个功能对用户价值、市场竞争力和项目成功的影响。

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

项目的出口条件在项目开始时应该被清晰定义，包括项目成功的具体标准和验收条件。在实际操作中，我们发现出口条件有时不够明确，导致项目结束时的评估存在模糊性。

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

我们尝试为可能的变更制定应急计划，包括风险评估和应对策略。然而，应急计划的制定和执行有时不够及时或不够有效。

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

工在处理意料之外的工作请求时表现出了不同的效率。一些员工能够迅速适应并有效处理，而另一些则可能需要更多时间来调整。

（6）我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 加强沟通： 我们会加强项目沟通机制，确保所有变更都能及时传达给相关人员
• 优先级决策： 我们会采用更科学的方法来决定功能的优先级，比如基于数据和用户反馈。
• 明确出口条件： 我们会在项目开始时就明确定义项目的出口条件，并确保所有团队成员都清楚这些条件。
• 应急计划： 我们会在项目规划阶段就制定详细的应急计划，以应对可能的变更和风险。

5.设计实现

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

设计工作通常在项目初期进行，由专门的设计团队或具有相关技能的成员来完成。如果设计工作在项目规划阶段及时开始，并且由具备相应专业能力和经验的团队成员负责，那么可以认为是合适的时间和合适的人。如果历史重来一遍，我们会确保设计工作更早地融入项目流程，并由最适合的团队成员负责，以确保设计的质量和效率。

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

设计工作中确实会遇到模棱两可或不确定的情况，团队通常通过集体讨论、原型设计和用户反馈来解决这些问题。我们会组织头脑风暴会议，创建原型以测试设计概念

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

我们确实使用了单元测试、TDD和UML等工具来辅助设计和实现。这些工具在提高代码质量和设计清晰度方面是有效的。项目开始时的UML文档与现在的状态相比，可能存在一些差异，这些差异可能是由于项目需求的变化、设计决策的调整或实际开发过程中的发现所导致的。如果历史重来一遍，我们会定期更新UML文档，以反映项目的最新状态，并确保文档与实际代码保持一致。

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

通常，那些复杂度高、依赖关系多或者需求不明确的特性更容易产生Bug。发布后发现的重要Bug可能是由于测试覆盖不足、需求变更或设计缺陷所导致的。在设计和开发时，我们可能没有充分考虑到所有边缘情况或用户行为，导致一些情况被忽视。如果历史重来一遍，我们会加强需求分析，提高测试覆盖率，并在设计阶段就引入更多的用户反馈，以减少这类问题。

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

代码复审是通过团队成员之间的相互审查来进行的，目的是确保代码质量并遵循代码规范。我们通过代码审查会议和使用代码审查工具来执行这一过程。如果历史重来一遍，我们会确保代码复审更加严格和系统化，严格执行代码规范，并且对复审过程进行记录和跟踪，以确保所有问题都能得到解决

（6）我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 设计融入项目流程： 我们会将设计工作更早地融入项目流程，并确保由最适合的团队成员负责。
• 加强用户沟通： 我们会加强与用户的沟通，更早地引入用户反馈，以减少设计中的模棱两可情况。
• 文档更新： 我们会定期更新UML和其他设计文档，以反映项目的最新状态。
• 提高测试覆盖率： 我们会提高测试覆盖率，特别是在复杂或关键的功能上，以减少Bug的产生。
• 严格代码复审： 我们会严格执行代码规范，并确保代码复审过程更加严格和系统化。

6.测试/发布

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

理想情况下，团队应该有一个详细的测试计划，包括测试的范围、方法、资源和时间表。我们团队没有测试计划，是因为项目时间紧迫、资源有限或对测试的重要性认识不足。如果历史重来一遍，我们会确保在项目早期就制定一个全面的测试计划，并将其作为项目计划的一部分。

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

我们团队没有进行正式的验收测试，可能是因为缺乏明确的验收标准或测试资源不足。正式的验收测试是确保软件满足用户需求和预期功能的关键步骤。如果历史重来一遍，我们会确保在项目计划中包含正式的验收测试，并定义清晰的验收标准。

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

很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
没有

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

使用性能监控工具来测量和跟踪软件的性能，如响应时间和吞吐量。定期进行压力测试，以评估系统在不断变化的负载下的表现。

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

在发布过程中可能会发现意外的兼容性问题、性能瓶颈以及安全漏洞。

（6）我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 制定全面的测试计划： 在项目早期就制定一个详细的测试计划，包括测试的范围、方法、资源和时间表。
• 引入自动化测试： 引入自动化测试工具来执行重复性高的测试，如单元测试和集成测试，并生成自动化测试结果报告。
• 增强性能和压力测试： 定期进行性能和压力测试，以评估系统在不同负载下的表现，并确保测试场景覆盖所有关键的用户路径和极端条件。

7.总结

在过去的项目中，我们经历了一系列的挑战和学习机会。我们认识到，尽管团队在设计、开发和测试方面做出了努力，但仍存在一些关键领域需要改进。我们学到了测试计划的重要性，自动化测试在提高效率和准确性方面的优势，以及性能和压力测试在确保软件稳定性和可靠性方面的必要性。我们还意识到，发布过程中的风险管理、持续集成/持续部署（CI/CD）流程的实施，以及安全审计在减少意外问题和提高软件质量方面的重要性。

姓名	团队贡献分	可验证贡献
唐立伟（组长）	22	负责程序整体设计和开发
吴秋雪	21	负责后端开发
黄妍仪	20	负责前后端开发
李思柔	19	负责前端开发
何晓漫	18	负责测试