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

所属课程	软件工程导论
作业要求	团队作业6——复审与事后分析
作业目标	复审与事后分析
github链接	CampusSecond-handMarket--NoBailanGroup

团队作业五——测试与发布链接：https://www.cnblogs.com/kinsonlin/p/17873194.html

目录

• 团队作业五——测试与发布链接：https://www.cnblogs.com/kinsonlin/p/17873194.html
• 一、团队
  • 1、团队名称：摆烂就不队
  • 2、团队成员
• 二、Alpha阶段项目复审
• 三、事后诸葛亮分析
  • 1、二手交易市场项目总结报告
    • a.设想和目标
    • b.计划
    • c.资源
    • d.变更管理
    • e.设计/实现
    • f.团队的角色，管理，合作
    • g.总结
  • 2、全组讨论的照片。
  • 3、团队成员在Alpha阶段的角色和具体贡献（满分100)：

一、团队

1、团队名称：摆烂就不队

2、团队成员

姓名	班级	学号
林劲辰（组长）	计科2班	3121004707
许庆阳	计科2班	3121004931
苏建澎	计科2班	3121005007
黎灿宇	计科2班	3121004867
伊尔凡江·艾合买提	计科2班	3121005017
鄞灿	计科2班	3121005018
于杨	计科2班	3221004940

二、Alpha阶段项目复审

小组的名字和链接	优点	缺点，bug报告	最终名次
花开富贵队	在测试过程中，团队发现了一些bug，并进行了修复。这表明团队具备良好的测试和问题解决能力，能够及时修复潜在的问题。场景测试：团队考虑到不同类型的用户使用软件的需求和目标，针对普通用户和管理员用户设计了相应的功能，以满足他们的不同需求。测试矩阵：团队列出了测试矩阵，明确了测试的功能、测试点以及预期结果，有助于组织和执行测试工作，确保软件的质量。	在场景测试部分，只列举了普通用户和管理员用户的需求和目标，并简单描述了功能如何满足这些需求。然而，没有展示更多的用户角色、不同情景下的测试用例和预期结果。建议扩展场景测试的范围，包括更多用户角色和测试用例，以确保软件在各种情况下都能正常运行。缺乏关于测试环境的详细信息：在测试矩阵中，只提到了使用的开发工具和硬件配置，没有提及操作系统版本、浏览器类型和其他必要的环境信息。为了更好地理解软件的兼容性和稳定性，建议提供更详细的测试环境信息。用户界面和交互设计的改进空间	1
硬工队	程序有什么具体的bug：添加水印只能处理图片列表中的第一张图片子窗口闪退保存，图片出现IO错误。项目的目标实现了吗：项目的目标是实现一个拥有GUI的基于OpenCV的图像处理软件，包含图片风格化处理、图片拼接、图片水印三大功能，并允许对多个图片进行同时处理。根据发布说明，Alpha版本包含了图像风格化处理、图片拼接、图片水印和历史记录功能，但还存在诸多Bug和已知问题限制，因此整体来说，目标尚未完全实现。项目的风险是如何应对的：项目风险主要包括进度风险、技术风险和人力资源风险。团队采取了严格监控项目开发进度，预留时间以应对开发不足和测试优化时间过长等情况。在技术风险方面，团队成员已基本完成所需技术的学习，并通过自我提升确保熟悉相关技术。此外，预留时间以应对可能的人力资源不足情况。找到用户的痛点并解决了吗：项目团队在需求&原型改进中提到针对用户的一般电脑用户、大学生和公司职员的需求，提出了如使操作更简便、提供更多样化滤镜选择等改进措施。	然而，由于Alpha版本存在诸多Bug和已知问题限制，这些痛点尚未完全得到解决。对主要和次要的需求是如何取舍的：根据需求&原型改进的描述，团队在针对问题1、2、3的修改中，主要是针对用户体验和功能的改进，包括简化操作、支持批量处理、增加滤镜选择等。在项目进度计划中，团队对任务进行了分解和优化安排，以确保主要需求的实现。源代码管理如何：版本控制、团队协作、分支管理等表现不错。如果换成我来领导这个小组，我会做什么不一样的事情：更加严格的质量控制和Bug管理，确保软件稳定性和功能完整性；强调用户体验设计，确保软件易用性和用户满意度	2
六佬带一坑	该小组的项目功能完整，且具有实用意义，且作为闲聊机器人能闲聊和确定疾病和症状，	如果是作为闲聊机器人的话，应该对日常可能发生的对话都能应对，但是该机器人能进行的对话直能实现闲聊和医疗咨询，如果能有这些功能我相信会更完美，且无法对医疗咨询做出建议。我们再测试的过程中发现此程序运行的速度比较慢且经常卡死，且有一些疾病是不能识别出来的	3
在线学习系统开发小组	针对学习系统存在的问题，提出了具体的改进方案，并对原有功能进行了扩展和完善。在数据库中设计了课程表和题库表，通过代码与数据库交互来实现相关功能，具体的数据库设计和代码逻辑使得整体方案更为可行。	程序具体的bug：从测试报告中可以得知程序共发现了17个Bug，其中包括修复的Bug、不能重现的Bug、不是Bug（产品设计如此）、无修复、延迟修复等各种类型。需要进一步的分析每个Bug的具体情况和影响，以便进行修复和改进。项目目标的实现：根据需求文档和测试报告来看，项目对学习系统的功能和性能进行了全面的改进和验证，新功能的添加和改进的具体实施都在进行中，因此在很大程度上项目目标得到了实现。项目风险的应对：在测试报告中提到了17个Bug，并对其进行了分类，并且给出了不同类型Bug的处理方式，这展现了团队对项目风险有清晰的认识并且有相应的风险应对措施。找到用户痛点并解决：通过需求文档和测试报告可以看出，团队针对学习系统的功能和性能进行了较全面的改进，这些改进主要是基于用户需求和问题点，因此在很大程度上找到了用户的痛点并且进行了相应的解决。主要和次要需求的取舍：需求的改进和完善是基于团队的讨论和用户的反馈，因此在改进的过程中可能会对主要和次要的需求进行权衡和取舍，需要在需求分析和设计过程中充分考虑用户的核心需求。源代码管理：版本控制、团队协作、分支管理等表现良好领导小组的不同做法：加强对源代码管理的规划和实施，以确保团队的协作开发效率和代码质量；另外，可以加强对需求分析和用户反馈的收集，以更好地把握用户需求和项目风险，从而更好地指导团队的项目实施和改进过程。	4
烦死了作业队	项目整体完整性较高，可以正常使用，界面简约，操作方便易懂，项目预期要满足的客户需求完备	alipay支付宝p2无法使用的bug， 用户地址手机号的格式判断失败。只能用电脑的浏览器打开平台，用手机浏览器打开网址会出现图片与画面不兼容，导航条稍微错位等情况；注册账户时接受的邮箱有限，使用国外邮箱不一定能注册成功	5
嘉嘉🐔（++j）	1.已经基本上实现全部的功能，没有产生过多的无效功能2.根据燃尽图可以知道任务完成的效率良好，但是软件的质量良好，可以成功在不同的主机上构建成功。3.项目代码保存在github的网址上，内容完整，质量良好。4.功能完整性强，能准确完成用户的需求，每隔几天会进行一次维护。能及时解决产生的问题，并不断完善优化功能	产生的bug: 数据维护方面添加的模块在合同录入中没有显现。添加维护用户时数据未加入数据库（均以解决）未说明产生风险的时候应该如何进行解决。缺少对于用户实际应用情况的全部说明，虽有测试项目，但是为实际给用户进行实操改进。项目主次结构不是很分明。如果我进行项目负责人可能会在原有的基础项目完成后不停的进行测试，并寻找不同的用户进行实际操作，与不同小组进行协同合作，最后晚上用户端功能。	6
Pixel Wizards	1.任务分布明确，具有良好的规划过程和团队协作过程。2.代码优化过程良好，能基本实现维护的周期性。3.根据燃尽图可知每次的进度实现都较为稳定，虽然有时候进度会稍慢。4.功能解释完整，能实现需求的基本完成。5.UI界面设置好看，有让人眼前一亮的感觉。拓展功能的实用性很强。	Bug:出现传参错误，当出现分辨率较高的图片时容易出现运行时间过长或者运行报错的情况。可能出现无法导出正常结果。基本实现功能完整，拓展功能的应用也良好，但是出现的bug较多。如果我进行项目负责人可能会在原有的基础项目完成后不停的进行测试，并寻找不同的用户进行实际操作，与不同小组进行协同合作，最后晚上用户端功能。	7
七神无主队	这个项目的成功不仅体现在高完成度上，还在于其美观实用的界面设计和广泛适用的功能。受欢迎程度也体现了用户对其认可。这个项目能够满足多种需求，丰富了用户的使用体验。	该网站的Alpha版本存在一些问题，其中之一是数据库中可用数据较少，还需要进一步完善功能。此外，该网站受限于不同浏览器的兼容性问题，在支持程度上也存在差异。尽管存在这些问题，但整体而言，该项目的完成度仍然相当不错。	8
OTTO小队	Bug的数量本身较少，已经解决了逻辑上出现的bug，有两个bug是设计上会出现的，不用修改。软件顺利运行，运行速度中等。用户有三个，文档在此方面描述得较少，只能判断用户的基本需求应该得到实现。代码在github上；代码能在新的机器上构建成功；代码的可维护性中等；有每日构建。项目通过社交软件传输文件以及更新GitHub上传的代码来进行管理，燃尽图基本反映真实状况。	操作难度略大，软件实用性不高，没有体现该团队目的“本系统主要面向于初学图形学与人机交互的同学，通过开源的方式为初学者提供一个较为轻量、易解读的图形交互界面。	9
代码敲不队	该项目具有高度的实用性和可发展性，用户在试用过程中遇到的bug较少。它具备广阔的发展空间。	为了解决跳转报错页面的问题，需要修复这个会导致报错的页面。	10
我知道你很急但你先别急	考勤管理系统的界面设计的非常简约，符合用户的需求，提高了管理效率	可以使用多台设备或者多个浏览器允许同一用户同时登陆，安全性低；尝试修改用户名，修改完成后直接退出登录了；对申请过的课程不可重复申请；注册时，用户的手机号码没有限制符合实际的常见的开头形式，也没有进行手机验证码验证，安全性有待加强	11
KAODAPU	测试场景考虑了不同用户的需求和目标，对快递中转系统的功能进行了细分，以满足管理员、快递员和用户的不同需求。测试矩阵明确列出了各个功能的测试项、检验点以及预期结果，并对两种常见浏览器进行了测试，确保了系统在不同浏览器下的兼容性。	缺少针对性的功能测试：测试矩阵中列出了各个功能的测试项，但可能还可以增加更多针对性的功能测试，以覆盖更多可能的使用情况。使用的浏览器限制：测试矩阵中只列出了Chrome浏览器和Edge浏览器的测试结果，可能还需要考虑其他常见浏览器的兼容性。缺少关于系统性能和稳定性的测试：测试报告中主要集中在功能性测试，可能还需要考虑对系统的负载测试、并发性能测试等，以评估系统在高负荷情况下的表现。Alpha版本发布说明中提到的问题和限制较为简单，可能可以进一步详细描述系统目前存在的局限性和待改进的方面。	12
四大天王	可以正常使用，项目设计完整	管理界面较简单，管理界面较为混乱，使用感不佳；系统的安全性不高；场景测试和项目预期等规划较为简易，没有完备的方案；施工队和小组信息显示bug，性别显示为0/1数字，修改信息时并未检查信息正确性，无法确保输入的信息是有效和合法的；创建方式不完善，可以命令不属于自己的同职位人员，用户可以越权使用系统功能；一个账号可以同时登录	13

三、事后诸葛亮分析

1、二手交易市场项目总结报告

a.设想和目标

• 问题定义与用户场景描述： 我们的软件旨在解决大学校园内二手商品信息流通不畅的问题。通过校园网提供的平台，用户可以方便快捷地发布和交流二手商品信息，解决了传统信息交流方式的不便利性。

• 目标达成度评估： 我们在原计划中实现了大部分功能，但部分功能可能需要进一步优化。交付时间上，我们基本按计划进行，但用户数量未达到预期。需要进一步分析原因。

• 软件工程质量提高： 在整个开发周期内，我们对软件工程进行了不断的改进。代码质量、设计规范以及测试流程都有了明显的提高，反映在较低的Bug率和用户反馈的改善上。

• 用户量和功能接受度： 用户量较初期有所增加，但还未达到预期水平。重要功能的接受程度较高，用户反馈表明他们对平台的认可度逐渐提升，但仍需要更多宣传和改进以拉动用户增长。

b.计划

• 充足的时间： 在计划阶段，我们花费了足够的时间来仔细制定计划，考虑了各项任务的复杂性和时间需求。

• 解决意见分歧： 团队成员在计划阶段通过定期的会议和讨论来解决对计划的不同意见，确保每个人都能够理解并支持计划。

• 原计划完成情况： 大多数原计划的工作都得以完成，但一些细节和优化的任务可能没有在原计划时间内完全实现。

• 事后反思： 我们回顾了一些任务，发现有一些事后看来并没有太大价值的工作，可能在规划阶段需要更好的筛选和优先级制定。

• 任务定义和衡量： 每一项任务都有清晰的定义和明确的交付标准，以确保工作的可量化和可测量性。

• 按计划进行： 大部分项目按照计划进行，但在用户测试阶段遇到了一些问题，需要迅速调整计划以满足用户反馈的需求。在计划中没有充分考虑到用户反馈可能导致的调整。

• 缓冲区： 我们在计划中留下了一些缓冲区，但在项目的后期阶段，这些缓冲区并没有完全发挥作用，需要更有效地管理缓冲区的使用。

• 将来的计划修改： 下一阶段的计划中，我们将重新定义缓冲区，更灵活地处理可能出现的问题，并考虑引入一些弹性的计划调整机制。

• 我们学到了什么?
  我们学到了在计划阶段更加重视细节和优化的重要性，以及在项目进行中及时调整计划的灵活性。

c.资源

• 足够的资源： 虽然我们在项目开始时有足够的资源，但在项目中期我们发现一些资源分配不够合理，需要更好地优化资源。

• 时间和资源估计： 任务的时间和其他资源估计较为准确，但在美工设计和文案方面，我们低估了其对整个项目的影响。

• 测试资源： 测试的时间、人力和软件/硬件资源在项目初期并没有足够考虑到，导致在测试阶段出现一些延迟。

• 任务分配效率： 我们有时感到一些任务可以由其他团队成员更有效率地完成，下一次需要更灵活地进行任务分配。

• 经验教训和改进
  我们学到了对资源进行更灵活的优化，随着项目的进行进行合理的重新分配。

d.变更管理

• 及时通知变更： 我们在变更管理方面做得相对较好，确保每个相关的员工及时了解到变更的消息。

• 推迟和必须实现的功能决策： 我们采用了集体讨论和投票的方式决定推迟和必须实现的功能，确保决策的公平性和透明度。

• 出口条件定义： 出口条件在项目开始前就有清晰的定义，但在实际执行中需要更加细化和明确。

• 应急计划： 我们为可能的变更制定了应急计划，但需要在未来的项目中进一步优化和细化。

• 处理意外工作请求： 团队成员在处理意料之外的工作请求方面需要更有效地沟通和协作，以提高应对突发情况的能力。

• 学到了什么?
  我们学到了及时沟通变更、决策的透明性、出口条件的重要性，以及对意外请求更加灵活的应对策略。

e.设计/实现

• 设计工作时间和人员： 设计工作由专业人员在合适的时间完成，但可能需要更早一些介入，以更好地支持整个开发过程。

• 解决模棱两可的情况： 团队通过定期会议和沟通来解决设计中的模棱两可的情况，但需要更强调决策的及时性。

• 工具的使用： 我们运用了UML等工具来帮助设计和实现，但在项目进行中，由于一些设计变更，UML文档有一些过时，需要更及时地更新。

• Bug产生和发布后的问题： 一些功能在发布后产生了较多的Bug，我们意识到在设计/开发阶段需要更全面地考虑各种使用场景。

• 代码复审： 代码复审严格执行了代码规范，但在一些复杂功能的实现中可能需要更深入的复审。

• 学到了什么?
  我们学到了更早介入设计的重要性，及时更新文档的必要性，以及在复杂功能实现中更深入的代码复审。

f.团队的角色，管理，合作

• 团队成员角色： 团队成员在明确的角色分工下，展现出了各自的专长，但仍需继续优化角色的配备。

• 团队协作： 团队成员之间的互相帮助和合作相对较好。每个成员在博客中表示对其他成员的感谢是一个良好的团队建设做法。

• 项目管理问题处理： 团队在面对项目管理和合作方面的问题时，表现出较强的解决问题的能力。继续保持团队协作氛围的建设。

g.总结

• 团队状态评估： 目前团队的状态可能属于规范阶段，具备了一定的项目管理和软件工程质量。有待进一步提高用户数量，达到创造阶段。

• 改进方向： 未来的重点应放在提高软件工程质量、优化计划、增加用户数量等方面。通过更全面的宣传和改进功能，争取更多用户的认可。

• 敏捷开发原则： 团队在灵活性、客户满意度等方面做得较好，但还需加强自我反思和改进的能力。

• 软件工程的下一步提高： 在代码管理、架构设计、项目管理、用户数据跟踪等方面进行进一步改进，确保软件工程的全面提高。

2、全组讨论的照片。

3、团队成员在Alpha阶段的角色和具体贡献（满分100)：

姓名	角色	团队贡献分	可验证的贡献
林劲辰（组长）	PM 项目经理	96	博客、项目文档
许庆阳	UCD 以用户为中心的设计	94	需求分析文档
苏建澎	FE 前端开发	94	程序运行
黎灿宇	TEST 测试	95	测试文档
伊尔凡江·艾合买提	UED 用户体验设计	94	需求分析文档
鄞灿	DEV 后端开发	96	代码
于杨	UID 界面设计	94	程序界面

每个人都是团队不可或缺的一员，为项目的实现奉献了自己的力量，使得本次项目顺利完成！