1组-Alpha冲刺-总结

https://www.cnblogs.com/Klein-Wang/p/15586147.html

一、基本情况

1.1组长博客链接

https://www.cnblogs.com/Klein-Wang/p/15586147.html

1.2现场答辩总结

• 现场答辩总结
  • 现场答辩就Alpha两周冲刺成果进行了展示，完成了预计的初步算法功能，采集数据并构建数据集，同时生成初步输出视频，且实现60%前后端的设计与架构。
  • ppt关于前端原型部分讲解较少，但对算法实现以及功能展势部分的介绍较为详细，演示视频功能展示齐全，后续应加快前后端的实现与对接。
  • 答辩中无同学提问，老师提议应加快进度，确保按期完成。

1.3全组讨论的照片

1.4评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例

姓名	团队分工	贡献比例
陈志良	产品原型设计，收集素材	10%
施可婳	素材整理，界面设计与美化	10%
王业震	Insightface人脸识别算法，ppt制作，答辩	17%
郑浩彬	Yolov5目标检测算法，博客编写	16%
张静	openpose动作识别算法，ppt制作，博客编写	16%
毛长江	Yolov5&&Deepsort多目标跟踪算法，博客编写	15%
黄志翔	后端api设计与实现，视频制作	16%

二、总结思考

2.1设想和目标

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

• 随着经济社会发展和物质消费水平大幅提高,生活垃圾产生量迅速增长,已经成为新型城镇化发展的制约因素。城市中生活垃圾的产生量急剧增高，小区或宿舍垃圾存放点的负载逐渐增大。在垃圾桶数量多、分散广的实际情况下，垃圾监管难、及时清倒难等一系列问题不断涌现。针对上述痛点，我们提出了一种基于深度学习的垃圾投放状态智能检测与识别方法。该方法以实时监控视频作为基础，使用目标检测技术，对垃圾桶进行实时监测，查看其空满状态以及是否存在异样，并对投放垃圾的居民进行动作识别判断其对垃圾是否按规定定点投放，采用人脸识别技术对投放垃圾行人进行记录可追溯垃圾投放来源，并对不合规投放垃圾的人群加以标记，有效缓解了人手紧缺和监管不力等一系列问题。

• 定义清楚

• 本产品的可能应用场景还包括学生生活区、工厂园区、人流密集的公园垃圾点监测等。本产品面向社区管理者，于非正常状态，系统对社区管理者发出提示，社区管理者只需对异常垃圾点进行清理即可，大大提升了监管效率。

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

• 目标目前尚未全部完成。

• 经历alpha冲刺我们小组采集了超过三千张多场景的数据集，包括白天、傍晚、夜晚与降雨等场景，并且运用可视化的图像标定工具 LabelImg进行数据集的标注。已经实现

• 1. 系统对垃圾桶的边缘轮廓以及空满状态进行深度学习，将其状态分为正常状态：盖子已关。非正常状态：盖子未盖、垃圾桶已满、垃圾溢出。
  2. 对垃圾点附近单个或多个人群进行跟踪，区分其是否进行垃圾投放，对垃圾投放的行人的运动轨迹进行记录；
  3. 对行人投放垃圾动作是否合规进行分析，对不合规投放垃圾的人群使用人脸识别算法加以记录，当其记录次数达到一定数量时对其进行警告及处罚；

• 我们的项目未按照原计划交付，由于前端人员经验不足、知识匮乏，前端开发还在进行中，由于考试等的原因还未完成前后端的对接。

• 本项目原计划首先面向福州大学教师群体，该群体对新技术的接收能力高，同时在社会上有广泛的影响力。高校创业团队的身份， 则有利于我们与高校教师群体迅速建立信任，获得支持。后期扩展到政府、事业单位、企业等。这种模式的成功实施，一方面有赖于产品性能优势，另一方面在于建立信任和口碑效应。现如今还未完成。

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

• 没有开发完全，暂时没有用户，用户量未接近预想。

• 我国已经进入了垃圾管理的高负担期，具有“存放点分散、用人成本高、存放点监管难、垃圾倾倒不及时”的特点。垃圾桶垃圾溢出，居民随意投放垃圾等现象让无数社区管理者头疼。该产品可以做到管理者仅需监控摄像头就能实现垃圾桶状态实时知。我们组核心人员对重要功能可以接受。

• 接下来我们会进一步完善前后端的对接，实现我们预期的目标。

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

• 经历了alpha冲刺我们小组总结了以下几个经验教训：

  • 由于拍摄设备与拍摄地点等问题，有部分数据集并不能很好模拟摄像头的效果。

  • 在进行数据集标注时，由于团队约定不够明确，导致出现某些标注不合规范或标注名不同等问题。

  • 综合几个算法时，需要找到每个算法都能运行起来的环境，这个普适环境难以确定。

  • UI界面由于技术原因，一些控件与效果难以达到预期。

  • 组员之间要多进行沟通交流。

2.2计划

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

• 有。目前项目主要功能已经基本实现，在beta冲刺阶段进行前后端的对接以及算法整合。

2.2.2团队在计划阶段是如何解决组员对于计划的不同意见的？

• 在会议上如果对于计划有不同意见大家会当场提出，然后进行小组讨论，达成共识。我们有一个QQ群，也可以在群里进行交流。

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

• 原计划还未全部做完，实现了60%左右。现在后端实现了用户，意见反馈 日志，video四个模块，还未实现前后端的对接。

• 原因：

  • 在一些功能的实现上，我们一开始预期太过于乐观，在接触后发现实现比预期要复杂以及困难，需要更多的时间来实现预期的功能。

  • 在alpha冲刺阶段几乎每个成员都有一门两门的考试，大家都忙于准备考试。

  • 前端在学习ing

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

• 暂时没有，在分工上每一个人都实现自己的功能，每一个功能都是这个项目所需要的。

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

• 在每一次任务发布时，我们都会对任务划分成几个模块进行分配，在最大程度上对每一项任务都进行了清楚的定义和衡量的交付件。

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

• 没有完全按照计划进行，在alpha冲刺阶段预期实现前后端以及前后端的对接，但是现如今只实现了后端用户，意见反馈 ，日志， video四个模块，对于前端的实现也还未全部完成，前后端对接工作还未开展。

• 意外出现在没想到考试全部聚集在alpha冲刺阶段，每人都要准备他自己的考试，有人甚至有两门考试，在紧凑的复习中暂时就把任务放下了。

• 前端的学习成本过高，训练数据集的时候显卡不够给力，训练得有些慢

• 没能预估到考试的风险和alpha冲刺工作量的强大。

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

• 在计划中几乎没有留下缓冲区，对于一开始的数据采集就花费了较多的时间，采集完数据后就马上开始对数据集标注，对于三千多张图片在大家熬夜标注下也是花了大把的时间，在标注初期还出现了对标注进行改动，导致要重新修改标注。数据集标注结束后大家立马开始学习前后端开发以及各个算法的环境配置，显得能够预留缓冲区的时间少之又少。

• 缓冲区是有作用的，在一定程度上可以，调整了工作进度和工作节奏。

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

• 在将来的计划中会规划一到两天的缓冲区用来调整工作进度以及工作节奏，成员可以利用缓冲区时间对自己的工作进行了解以及进一步的学习。

• 在alpha阶段大家已经经历了一次又一次的熬夜，在将来的工作中大家也会齐心协力，尽自己最大一份力将项目预期功能实现并且进行完善。

2.2.9学到了什么? 如果历史重来一遍, 会做什么改进?

• 学习到了数据的采集，LabelImg进行数据的标注，YoloV5算法对垃圾桶及附近垃圾进行识别与检测，Insightface的人脸识别及MTCNN的人脸检测算法对投放垃圾行人进行记录，YoloV5及DeepSort算法的目标跟踪技术，Openpose算法的学习。

• 如果历史重来一遍我们会考虑到考试等不可抗力的因素，将任务进行更加细致的划分进行交付。

2.3资源

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

• 没有。

• 一些所需的功能团队大部分人都是没有接触过的，所以需要额外的时间来学习，而时间资源正是我们现在紧缺的。

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

• 首先由组长进行估计，在小组会议上大家再进行更加细致的估计，但是每个人已有的技术水平和学习能力都不一样，分配下去的任务能按时做完就已经很好了。

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

• 对于已经完成的部分，测试所需要的资源是足够的。
• UI原型设计的难度确实是十分巨大的，设计人员不懂技术，其实并不能很好的还原我们想要做什么或者能做什么，只能慢慢修改。

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

• 没有。在分配项目的时候，大家都会争取到最适合自己以及自己最愿意去做的模块，在达成共识后每个人所做的部分都是自己最擅长的。

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

• 对于时间的管理过于乐观，到最后却来不及。如果历史重来一遍，对于时间资源，会更加细致的计划时间。

• 希望大家以后都能往全栈发展，各个领域都懂一点，再专精某个领域，才能更好地交流，更好地编程。

2.4变更管理

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

• 每个相关的成员都能在qq群里看到变更的消息，对于一些需要讨论的变更会通过腾讯会议的方式大家一起讨论最后达成共识。

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

• 看功能核心与否

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

• 基本条件就是预期功能全部实现，目标客户可以正常使用，前端页面可以正常跳转，可以给后端发送正确的消息，后端处理请求不报异常，返回正确的信息。

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

• 可以。一出现变更大家会通过线上或者线下的方式进行讨论，制定应急计划。

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

• 可以，比如写博客。

2.4.6学到了什么? 如果历史重来一遍, 会做什么改进?

• 对于出现的变更，要及时提出并且分配给最适合这项工作的成员。

• 交流大于一切，不能做或者短时间内无法做出来的事情尽早告诉队友，不要一个问题自己琢磨半天。

• 在项目初期应该进行一定的风险评估，预测到可能出现的变更，提前想好相应的应对措施，以便在之后工作的开展中对于突然的变更有所准备。

2.5设计/实现

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

• 设计工作于十月中旬构建项目时进行，由小组7人共同商讨完成，时间和人员合适。

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

• 在接口设计讨论时，实现方式摸棱两可，后经二次讨论达成统一标准。

2.5.3团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

• 暂时还没有使用单元测试，后面会考虑。但是，用到了UML，感觉效果甚微。

2.5.4比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

• UML文档在设计中不断更新，增加若干功能，且部分功能进行了改进；在推进中发现不合理的地方，并对设计进行了修改，故产生区别；UML文档应在推进中实时更新以确保设计合理性。

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

• 人脸识别功能产生Bug最多。由于Insightface没有同一配置标准，在配置算法时出现兼容性问题多；发布后发现算法性能与运行时间较先前降低；由于整合后算法功耗太大，目前设备运算能力不足以完美承载，导致处理数据耗时较长。

• 设计与开发只是纸上谈兵，是骡子是马，代码跑起来才知道，代码的错误很多都是不可预知的。

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

• 代码复审由人工检测核验，确保运行无误，严格执行了代码规范。

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

• 学习了软件设计具体过程及算法实现，增长了开发设计经验。如果重来，在初始设计时应增加细节，避免不必要的修改与debug。

2.6测试/发布

2.6.1.团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？

• 对各部分算法性能及可行性进行了测试，未进行正式验收测试。

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

• 后端有idea自带的测试工具

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

• 根据数据流传输的速率及处理时间来评价软件效能；有用，从测试中发现存在优化的空间；后续可对算法鲁棒性及速率进行优化。

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

• 由于前后端对接时出现问题，目前产品尚未发布，仅为内测版，后续将继续跟进。

2.6.5.学到了什么? 如果历史重来一遍, 会做什么改进?

• 学习了对产品进行测试，且根据数据反馈进行性能改进。

2.7团队的角色，管理，合作

2.7.1团队的每个角色是如何确定的，是不是人尽其才？

• 根据大家学习的内容不同，以及擅长领域不同，进行前后端分工，以达到人尽其才。

2.7.2团队成员之间有互相帮助么？

• 有。在算法配置运行处理时，成员互相协助，分享经验；在标注处理数据时也进行了帮助与讨论。

2.7.3当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢。学到了什么? 如果历史重来一遍, 会做什么改进?

• 王业震：我感谢郑浩彬对我的帮助。因为某个具体的事情：是他，与我共同奋战到深夜，只因那一行行报错的代码；是他，时而眉头紧皱，时而眉头舒展，与我共同寻找错误的根源。成功实现了insightface人脸识别算法与mtcnn算法，别学习了算法相关知识。如果历史能够重来，我希望自己可以把bug一次改对。

• 毛长江：我感谢郑浩彬对我的帮助，因为某个具体的事情：在配置算法的时候，存在版本兼容性的问题，安装的pytorch无法正常运行，在交流与分享经验后下载了适配版本，成功解决。学习了标注数据，安装配置环境，从应用到原理层面理解算法并改善，如果重来会在配置前多询问他人经历，减少不必要的失败尝试

• 郑浩彬：我感谢黄志翔对我的帮助， 因为某个具体的事情:让我明白整个开发软件的大体流程，和各个模块的分工，让本来脑海中架构混乱的我，变得清晰起来。

• 张静：我感谢施可婳对我的帮助， 因为某个具体的事情: 因为在代码测试时给我巨大帮助。学会了数据集的标注，算法环境的配置。如果能够重来一遍我会先精通语言，便于后续的学习。

• 陈志良: 我感谢郑浩彬对我的帮助，因为他教了我对标题栏如何进行处理。学到了如何自定义标题栏。如果历史重来一遍，我会对界面的美观进行加工。

• 黄志翔: 我感谢王业震对我的帮助, 因为在项目开始的时候缺少了一个具体的方向, 在多个模块中犹豫不决, 他帮我确定了模块的优先级后项目才能够顺利开始。本次的软工冲刺从零到有开始学习了spring的使用, 在极短的时间内学习了后端的知识, 如果历史重来一遍会更有针对性地去学习框架。

• 施可婳：我感谢张静对我的帮助，因为某个具体的事情：帮我解决了关于前端方面以及人工智能算法方面的疑惑。学到了页面设计的规范及技巧、UI设计工具的使用、如何进行目标检测以及前端的相关知识。如果历史重来，我会提高学习效率，花更多时间学习前端知识。

2.8总结

• 王业震：通过Alaph冲刺，我成功实现了从0到1的突破。作为一个本科生，之前从未想过能把顶会顶刊的算法重现，也从未想过人脸识别这种高大上的技术也能触手可及。当算法成功运行的拿一刹那，之前所有的压力与焦虑全部都烟消云散，只想对自己说一句666！
• 毛长江： 本次alpha有不少收获，增加了不少开发经验与实际性操作，同时借此也对机器学习领域有了一定探索，希望下次也能在完善与尝试中学到东西。
• 郑浩彬：经过这次Alpha冲刺，我学习到了许多人工智能方面的相关知识，比如如何标注数据集，如何使用Yolov5算法训练数据集等，也感受到了时间真的很少，每天都被很多事所困扰。真的希望时光能多倒回一点，让我学习完软工要用到的方方面面的知识，再来更好地软工实践。
• 张静 ：在alpha冲刺阶段，第一次跑开源代码的一头雾水，第一次学习环境配置以及对源码的学习。在无数的error之后终于跑出了第一个版本，上一次这么兴奋还是北京申奥成功。在这个阶段还和队友一起完成了榕创天眼的商业计划书，还一同制作了alpha冲刺阶段的ppt。在制作ppt和写BP的时候，队友要求事事完美并且格式一定要对齐的处女座情节给我影响最大，导致如今的我已经成功加入强迫症阵容。
• 陈志良：经过这次冲刺，我已初步掌握qt设计师这个页面设计工具，也对前端有了更深的认识和理解。也感谢我的队友，在我遇到问题而不知所措时给我的帮助。
• 黄志翔：本次的软工冲刺从零到有开始学习了spring的使用, 在极短的时间内学习了后端的知识。本次软工的作业极大的培养了我的团队合作的意意识。提高了赶DDL的能力。提高了忙中摸鱼的水平。
• 施可婳：经过这次Alpha冲刺，我学到了很多，如前端的相关知识、页面设计的规范及技巧、UI设计工具的使用、如何进行目标检测等，也感受到了开发过程中Alpha冲刺的紧张感。同时也发现了自己的许多不足：掌握的知识、技巧还远远不够多等，在今后的学习里，我会努力学习，克服不足，提高开发水平。