第三次任务 《始于构建之法》

目录

项目总结作业安排

项目计划与实施情况：

项目中软件工程的体现：

个人总结作业安排

其它任务

项目总结作业安排

项目计划与实施情况：

• 口罩识别功能模块	需求	设计	实现	测试
  调用本地摄像头	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）
  人脸裁剪	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）
  卷积神经网络训练	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）
  口罩佩戴判定（卷积神经网络）	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）
  可视化标注	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）
  低置信度图片保存	完成（杨继红）	完成（陈锦泓）	完成（陈锦泓）	完成（杨继红）

• 代码仓库地址 https://gitee.com/chenjh6015/pypapa/tree/master/FaceMaskDetection
• 卷积模型参数
• 
• 运行效果 
• 本小组两名成员，任务各占约50%，杨继红主要负责需求分析与测试，陈锦泓负责设计与代码实现
• 具体的工作时间如下表所示：

• 口罩识别功能模块	需求	设计	实现	测试
  调用本地摄像头	4.13（杨继红）	4.17（陈锦泓）	4.20（陈锦泓）	4.24（杨继红）
  人脸裁剪	4.16（杨继红）	4.18（陈锦泓）	4.23（陈锦泓）	4.26（杨继红）
  卷积神经网络训练	4.16（杨继红）	4.20（陈锦泓）	4.24（陈锦泓）	4.26（杨继红）
  口罩佩戴判定（卷积神经网络）	4.16（杨继红）	4.21（陈锦泓）	4.25（陈锦泓）	4.27（杨继红）
  可视化标注	4.13（杨继红）	4.22（陈锦泓）	4.26（陈锦泓）	4.27（杨继红）
  低置信度图片保存	4.16（杨继红）	4.23（陈锦泓）	4.27（陈锦泓）	4.27（杨继红）

• 制订项目改善计划：目前该程序还未完成封装，目前仅基于python 3.5 环境运行，后续计划对该程序进行封装，并部署在不同设备上进行测试其稳定性。

项目中软件工程的体现：

• 使用的软件工程方法主要有双人合作模式、敏捷开发流程、根据典型用户和典型场景提出需求等，使用了码云代码仓库的管理工具，具体开发中使用了PYCHARM自带的测试工具
• 本次课程让我们接触到了如何科学高效的进行团队合作，例如在本次项目中，组员有较为明确的分工，且互相监督工作进度，使用了码云代码仓库工具进行在线协作，大大的提升了项目完成效率。在需求分析阶段，设定了典型用户和典型使用场景，将解决用户痛点作为需求分析的最主要的出发点，然后快速构建原型系统，不断根据需求的变化进行调整，最终完成了本阶段的所有任务。
• 

个人总结作业安排

• 该博客标题定为《始于构建之法》
• 之前认为该门课程主要学习的是传统的基于项目的开发流程学习，学习了之后，对现代软件开发流程有了全新了认识。
• 新的问题是，对于现代的软件开发方法主要是迭代式的开发方式，那么在最终交付时开发文档会不会较为混乱
• 需求阶段  学会了构建典型用户和典型场景
• 设计阶段：熟悉了流程图的使用
• 实现阶段：熟悉了团队合作模式，以及pycharm 开发软件的使用
• 测试阶段：学习了PYcharm中PYTEST工具的使用方法
• 发布阶段：掌握了码云的基本使用操作
• 此次项目最大的收获是对于软件工程有了全新的认识，从原来单人作坊式的开发转变为团队协作的开发，并且了解了诸多项目管理工具，也提升了沟通能力和表达能力

• 本团队基本能够完成本课程最初的计划，此次项目我在开发中担任了程序员和产品经理的角色，杨继红通信担任了项目经理和测试工程师的角色，我认为我更适合担任产品经理，此项目中虽然运用了python编写，但从技术的角度我更加擅长JS  中的ECHARTS 技术，主要能够完成数据可视化呈现的功能，目前JS除了可以做前端以外，也可以调用NODE.JS库实现 后台的编写，甚至能够胜任许多深度学习的需求，其中各阶段都能够通过ECHARTS技术进行较为清晰的呈现。

其它任务

• 慕课学习：随着项目开发进度，学习到14章，并给出完成情况截图。

• 《梦断代码》中对软件工程所面临的种种困难与艰难的描述，很符合当下编程工作，自己对于软件编程也有切身感受。正如一队人马并肩扛起代码大石，虽历经磨难仍欲将其推上山顶的故事。正是这种磨砺与艰难的爬山过坎，成就了各种各样的运行的软件，构成了一个五彩缤纷的虚拟世界。

          自身对于何为软件，何为代码仅有一些肤浅的认识，半学期下来，编程能力也有了较大的提高。但是其中的痛苦和艰辛，也很值得自己去慢慢的回味。

  书中描述一群人们怀抱着改变世界的理想上路了，却在追寻时发现，那些近在眼前的理想之峰，变得那么的遥不可及；每当翻过一座横亘在面前的山峰时，总以为已经来到理想之峰的脚下，却发现这又是另一座需要攀越克服的阻隔之峰。

            是什么原因，导致软件开发有时会进入这样一个令人惋叹的黑洞？

            书的作者没有，也不可能给我们一个答案，但通过作者忠实记录于书的、就发生在当下不久的、这一真实案例，以及对软件开发历史和方法的部分介绍，本书应当能带给我们很多有益的启示和思考。

             为什么软件如此难做？这是我本人，我想也是很多人都在苦苦思索的一个问题，虽然无人能有完全确定的答案，但通过书中的记述，和个人思考，还是可以获得一些启示，其本质还是主要在于沟通：

       一是计算机严格的逻辑性和精确性。同人类不严密的逻辑，模糊多变的思维模式之间的矛盾，造成的人与机器之间沟通的障碍。

       二是项目目标不明确，标靶变来变去，因此有时决定说什么，比怎么说更困难。

       三是项目目标不切实际，从一开始就想做一个适合所有人的，能做所有事的系统，造成就如要做永动机一样的结局。

            我想人们大多都知道古老圣经中巴别塔的寓言，软件工程难于成功的原因，也许就蕴藏在这寓言启示之中，本质上在于沟通的问题。软件使用者与软件的沟通，软件需求者与开发者的沟通，程序员与程序员的沟通，程序员与机器的沟通。

            所有这些层层累叠起来，构筑了一道道通往成功彼岸的屏障。也许有一天所有这些沟通的障碍都能被消除，人们能轻易的相互理解，软件工程的巴别塔真的就能轻易的建造起来了。