1、请回望暑假时的第一次做业,你对于软件工程课程的想象
1)对比开篇博客你对课程目标和期待,“但愿经过实践锻炼,加强计算机专业的能力和就业竞争力”,对比目前的所学所练所得,在哪些方面达到了你的期待和目标,哪些方面还存在哪些不足,为何?
回想第一次做业时对软工实践的期待,想必大多数人和我同样都是抱着“参与第一”的态度,也会跃跃欲试,但也不奢求会作出怎么样了不得的软件,整体来讲软工实践基本符合开学初本人对其的期待------一次接近业界真实流程的开发体验。在这其中,有守得云开见月明的欣喜,也有挥散不去的怨声载道,我想这偏偏是这个实践最真实的意义。python
- 满意的方面:在本次软工实践方面,本人被分配在了算法组,负责识别算法的神经网络部分。以前虽然有一些在这方面的基础,可是并无亲自参与设计和调试模型,因此在此次的任务对我来讲也是一次全新而艰巨的任务。识别模型到最后顺利地完成了,也作到了本身满意的正确度。经过此次的经历,最大的收获是对模型的认识更加宏观,可以以更高的角度来看待问题。
不足的方面:,虽然在这其中因为硬件条件不足的客观缘由,最后的结果和最初的设想存在误差,最直接具体的表现就是本来打算使用的近九十万张图的关于3755个字的训练集在实际训练过程当中因为本机性能不够只能不断简略,最后只能选择生活中使用频率最高的500个字。最初时忽略了硬件条件的限制,是一大疏忽,也是一大收获,对之后的相关的开发提早上了一课。再则是对服务器的架设,因为对服务器的不了解和神经网络自己对环境极严格的特色,致使到最后把原来在本机训练好的模型架设在服务器上时遇到困难重重,这是在实际开发过程当中的一大教训-------要充分了解开发平台和架设平台的异同和软件的兼容性。git
2)总结这门课程的实践总结和给你带来的提高:
一、统计一下,你在这门软件工程实践中,完成了多少行的代码;程序员
千行左右,这并很少,也和个人部分的特色有关,主要的调参和训练要花去大部分时间。
做业 | 时长 |
---|---|
软件工程实践2017第一次做业 | 3 |
软件工程实践2017第二次做业 | 4 |
结队项目——第一次做业 | 7 |
团队第一次做业——团队展现 | 0.05 |
结对项目——第二次做业 | 15 |
团队做业—选题报告 | 2 |
我的技术博客(α) | 4 |
团队做业—需求规格说明书 | 3 |
团队做业—预则立&&他山之石 | 1 |
团队做业——系统设计 | 4.5 |
团队做业——UML设计 | 3 |
团队做业——随堂小测(同窗录) | 8 |
我的做业——软件产品案例分析 | 7 |
团队项目课堂展现 | 0.5 |
团队项目测试报告与用户反馈 | 1 |
团队Alpha博客连接目录 | 0.05 |
团队过后诸葛亮博客 | 2 |
Beta冲刺博客集合贴 | 3 |
我的做业——软件工程实践总结做业 | 4 |
Alpha和beta阶段代码 | 100 |
三、哪一次做业让你印象最深入?为何?github
最深入的要数α冲刺,感觉到被deadline支配的恐惧和无能为力,天天在课业和deadline之间徘徊往回,固然还有和团队队友的交流协做。五、学习和使用的新软件;算法
openCV,tessract,墨刀服务器
python相关包如tensorflow ,keras,theano
github,墨刀网络
都是在以前学习的基础上(python , IDE:spyder),没有新语言和平台工具
阅读论文来提高模型的性能;在stackflow上寻找解决方案。性能
经验总结:最大的经验就是必定要在项目开始前就对项目的各方各面尽力作最全面最细节的分析和安排,修正错误的成本随着项目进度的推动不断提升,与其在后期花大量时间弥补初始的疏忽,不如在最初作最好的安排,但变动也是没法避免,从容应对也是必修课
好比在团队项目最初的设想中,咱们并无打算设立服务器,打算将模型直接嵌套进安卓中,一时的想固然致使了这样荒谬的错误,如今想来直以为难以想象,在后期安卓和算法组结合时才发现行不通,大大滞后了项目的进度,不得不在本就紧张的安排中,花费时间和人力去架设服务器,对整个团队形成巨大的不良影响。
3、对下一届实践的建议,或者对于开学初的你,对于大一的你,对于开学初的我,你有什么想建议和告知的呢?对于后来人的期许。 特别地,特别地,下一届要不要中途换队员?
---学习
若是你没时间或者目标研究生甚至出国,不要选实践;若是你不想从事开发相关的职业,不要选实践;若是你想高绩点,不要选实践。最后,必修让上面这些话毫无心义。
可是认真地说,软工实践给予了同窗们一个全新的机会去看待本身正在学习的学科,个人建议是去尝试,只要经历了才知道适合和不适合,才能了解这个行业最核心的人员------程序员是什么样的工做节奏。这门课是好是坏,也许见仁见智,可是鼓励的是必定要去尝试。
对于中途换队员这种事,仍是不要换的好,虽然能够理解老师想让咱们体验职场的不测风云,可是一个初步成型的团队这样的变更无疑是巨大的,对学生来讲只会徒增对项目的负担,更甚是对课的抵触。退一步来讲,这样的体验对之后的职场生活并没有益处,试想,一个刚入职场的程序员,是否会由于有这样的一个经历而能更好地应对突如其来的变故?面对这样的事,还能想起以前软工实践中的小小的体会?再退一步,这样的变化和实际上变故一比,实在是小巫见大巫,不值一提。综上所述,我以为中途换队员的好处和带来的负面影响相比,实在得不偿失。。
构建之法中提到的团队发展有4个阶段,分别是萌芽阶段,磨合阶段,规范阶段和创造阶段。我以为最后咱们的团队到达了“创造阶段”。从最开始的组队,到初步的协做讨论,再到熟悉磨合,到如今,存在了几个问题:
在Alpha阶段的时候,咱们已经把咱们的软件推荐给咱们班的人使用了,并积极收集bug反馈和建议