正文
本次课程内容十分充实，对于我们的技能锻炼十分到位，而我觉得最大的收获是，我们对软件工程有了更深刻的认识，能够充分的吸收来自机械课程限制之外的知识，这是我觉得很不错的一点。下面我来详述我个人认为几点比较重要的事情或者是收获吧！
正文
1、 对于大部分同学来说，接触到了Github 以及 Markdown还有博客园这些新鲜玩意应该属于比较大的收获吧，不过我的话，因为自己老早就入了坑，Github还是大二的时候就申请了，而且我还用Github Education申请了国外主机的优惠券， 50美刀优惠券至今都还没用完！嘿嘿！当然，Github的组织功能因为以前我都是独行侠，所以没感受过，这次确实感受了一把这个强大之处，不愧是风靡世界的代码托管机构，就是强大！！另外的话，我在一个写作平台--简书上谢了快一年的文章了，Markdown的一些常用的方法我都基本掌握，更厉害的那些写法今后有需要了再学吧！另外的博客园我的园龄也有七个多月了。所以这些都还是小的，不过相信应该是很多同学的深刻感受了！
2、 Ubuntu系统，老师要求我们装虚拟机，或者是双系统也可以，我以前倒是经常帮人装windows系统，给自己装linux的系统，比如ubuntu，Kali linux，centos，这些我都大大小小玩过了，不过这次我打算试试双系统，万般艰辛终于还是给我弄成功了，只是引导修复花了很多时间，这个很让我苦恼，为此还写了一篇文章：
Dell-Windows10下装Ubuntu 16.04 双系统，Ubuntu引导开启-经验贴，满干货！
3、 老师教给了我们Qemu的入门，以及一些进程通信的知识，其中我自己完成第二次作业还真是惊心动魄。不管是过去还是现在想想，难度都是蛮高的，面对陌生的环境，之前从未接触的操作，只能硬着头皮上。不过幸运的是我们大部分都完成了，而且都还算是颇有新意的，我的作业链接如下：
FreeRTOS-Qemu 实现三任务同步通信机制以及API信息
4、 《构建之法》这本书，虽然我有点临时抱佛脚的嫌疑，但是我真的觉得这本书开阔了我的视野，其中一些关于软件工程的思想，一些关乎到程序员未来长久发展的理念，对我来说都是很重要的，虽然目前看不到用处，不过相信到了未来投身工作，我会感谢这本书的，当然也要感谢老师的引路
5、 团队协作。虽然我们这支队伍是拉扯着长大的，但是好歹我们也是个队伍。本来是准备平均分配任务，但是在一开始还没整好的时候要去说软件规格说明书，所以我就按照大家的特点初步的分配了任务。仅做参考！！但是扛不住组内大神给力，彭彦毓同学全程Carry我们一群菜鸡，那天召开组会准备再次分配任务的时候，他说他已经快把模块做好了。我只能收回就要出口的“来，我们再次分配任务吧！”，然后按照各自的时间充裕程度以及技能点来分配任务。
我跟陈志平由于时间较为充足，而且有一定的基础。所以我们接下了核心事件流的开发工作，以陈志平同学为主，我为辅，因为我还要担任产品经理一职，负责团队的日常组织活动，开头的软件规格说明书，结尾的项目总结书，还有团队Github日常维护。另外两位同学考研时间比较紧，而且跟进项目不够，所以分配的任务较轻，概要设计以及测试。
本次经历好处就是，体会到了软件开发的一些内在规则，着实过了一把产品经理的日子。不过坏处就是因为分心，所以对于团队的项目了解不够深入，对于每个模块仅仅停留在能够把老师要求的Part按照输入输出讲出来，内部对于我就是黑箱，当然，核心模块因为参与了跟陈志平同学的开发工作，所以还算是比较了解，对于整个咖啡机的工作流程也是很了解的！另外，在项目总结的过程中也慢慢的更深入了解到了咱们的模块的强大之处！为组内同学的战斗力自豪！
6、 基于模型的软件设计流程。这是我们实践过的一个东西，虽然我们组情况比较特殊所以接触不深，但是对于个中内涵还是有了初步的理解。老生常谈下吧，懒得写新的了（更具体的见后面链接）：
优点：
- 强调开发的阶段性，各阶段具有顺序性和依赖性 ，各个Part分模块，格子封装，暴露接口，然后耦合在一起组成一个整体
- 强调早期调研和需求分析，推迟编码实现的观点，在《构建之法》第二章的PSP对比大学生和软件工程师的时候。可以发现，实际的操作中更注重于前期准备和后期的完善，对于编码，不仅仅是由于丰富的资源库，也是因为有了几年的工作经验可以迅速的编码。所以现实中使用模型比较多。不论是模型带动工程师，还是工程师推动模型发展，两者之间的联系都是固定的!
- 提供了一个摸板，这个摸板使得分析、设计、编码、测试和支持的方法可以 在该摸板下有一个共同的指导。相同的模板下，方便后来的工程师阅读前辈写下来的模块。另外也方便任务的交接，同时还可以更方便的借用网络上开源的库，这些都是模型化设计模型的优点。
缺点：
- 文档驱动，用户无法及时了解产品的情况。因为很多程序员甚至不知道自己写的代码的全部部分，API接口的使用使得更多的源代码对于程序员不可见了！所以经过程序员的手，到达用户手中之后就更别说了。很多时候出了问题基本就没法找到具体的“事发”地址。对于后期的维护十分麻烦。这是牺牲了底层构建，实现迅速开发的代价。
- 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定
性。 因为毕竟是模型开发，很多时候为了追求速度会采用一些现成的代码。这样必然存在兼容性问题。而且具体的功能需要对应的模块实现。比较依赖于初期的调研，不然后期修改很麻烦。
- 依赖早期调研和需求分析，很难适应在许多项目开始阶段必然存在的不确定
- 流程单一，必须要完成前一阶段的任务，才能进行下一阶段，开发过程中的 成功经验无法用于本产品。 瀑布模型这儿特点很僵硬，无法实现并行开发。
- 测试在后期引入，对于系统存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成重大损失。 求取速度所必须付出的代价！！
【计算机本科补全计划】<构建之法>读书笔记
我的软件工程师的能力评估和发展
7 、还有一个过程就是PSP2.1 这个个人的能力测评的一样的体系。很有趣，我做了这个就自己的缺陷都摆在明面上，后续做其他项目的时候可以参照这些来进行改进，实在是很好的一个东西。大家有空的，条件足够的都可以去做做！很不错的！
8 、最后就是我们的大作业了。好歹也是心血浇灌的结果啊。怎么能忘了呢？
项目Github地址：
https://github.com/RTCSD2017-Group03/Automatic-Coffee-Machine.git
项目总结：
Software Project Summary Report.docx
项目介绍：
自动咖啡机项目--参照 IEEE Guide to Software Requirements Specifications 标准
我的项目周报：
《实时软件控制设计》大作业周报 No.1
《实时软件控制设计》大作业周报 No.2
《实时软件控制设计》大作业总报 No.3
大作业中，大家有力的出力，没空的也能给予自己力所能及的帮助（考研的同学要抽出三周的一部分时间来做作业确实要背负很大的心理压力。表示理解！）当然，像彭彦毓同学这么牛掰的同学是真心服气的。李佳杰辅助他一起写了周边模块，我辅助陈志平写了核心模块，之后拉拉扯扯把测试做了。功德圆满！！老实说，大四能有投入率这么高的课程真的是难得了。为老师疯狂打call。
正文之后
差不多，《实时控制软件设计》这门课就结束了。谢谢老师送的书，谢谢助教为我们熬得夜，谢谢同组内的同学们大家的合作。这估计是大四最有意思的课了。愿记忆永远珍藏！
