第一篇:软件工程学习总结和体会2015
西安交通大学
2015级研究生课程专题作业
软 件
工 程 心 得专 业: 班 级: 学 号: 姓 名: 电 话:
二○一五年十月
体 会
一、软件生命周期各阶段任务目的和主要方法
在分阶段总结之前,首先要明确以下三个问题:
1、什么是软件生存周期?
软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。主要包括:
(1)问题定义;(2)可行性研究;(3)需求分析;(4)概要设计;(5)详细设计;(6)编码;(7)测试;
(8)软件维护。
2、软件生存周期为什么划分成阶段?
(1)任何一个阶段的具体任务不仅独立,而且简单,便于不同人员分工协作,从而降低整个软件开发工作的困难程度。
(2)可以降低每个阶段任务的复杂程度,简化不同阶段的联系,有利于工程的组织管理,也便于采用良好的技术方法。
(3)使软件开发的全过程以一种有条不紊的方式进行,保证软件的质量,特别是提高了软件的可维护性。
3、应该怎样来划分阶段?
(1)每一个阶段的任务尽可能独立;(2)同一阶段内的任务性质尽可能相同;
(3)每一个阶段任务的开始和结束有严格的标准。
下面分别对各阶段进行讨论:
1、问题定义
目的是将用户提出的要求具体化、定量化,任务是确定研制系统的范围,明确研制的边界。
方法步骤:
(1)通过调查研究,了解系统要求;
(2)需求方与开发方讨论确定系统的功能、性能、可靠性、安全保密性等方面的要求,以及费用、进度等方面的要求。
2、可行性研究
可行性研究说明该软件开发项目的实现在技术上、经济上和社会条件上的可行性,评述为合理地达到开发目的可能选择的各种方案,目标是用最小的代价在尽可能短的时间内确定问题是否能够解决。
可行性研究的方法是首先需要进一步分析和澄清问题定义;然后分析员导出系统的逻辑模型;最后对未来的行动方针提出建议。
在导出逻辑模型的过程中,具体要根据以下四个方面分析可行性:
(1)经济可行性:进行成本效益分析,评估项目的开发成本,估算开发成本是否会超过项目预期的全部利润.分析系统开发对其它产品或利润的影响。
(2)技术可行性:根据客户提出的系统功能,性能及实现系统的各项约束条件,从技术的角度研究实现系统的可行性。(3)法律可行性:研究在系统开发过程中可能涉及的各种合同,侵权,责任以及各种于法律相抵触的问题。
(4)开发方案的选择性:提出并评价实现系统的各种看法方案.从中选出一种用于软件项目开发。
3、需求分析
需求分析是为了有效解决用户的需要而进行的一项工程活动,要考虑的问题是功能需求、数据需求、性能需求和接口需求,开发者承担分析任务,核心是用户。
软件项目的失败大半源于需求分析没有做好,软件开发人员首先应该明确用户的意图和要求,正确获取用户的需求,然后形成一个软件需求规格说明,它是软件开发的重要基础。
需求分析的方法:
(1)需求获取:获取客户需求,客户泛指某个人或机构部门等,一般方法是调查,包括访谈座谈、问卷、跟班和收集资料,需求规约可表达用户的软件价值。
(2)需求分析与规格说明:建立需求模型,它是用户需求的图解,一些常用的模型有:业务树图、用例图、活动图。分别用于结构化需求建模、系统业务举例和反映系统工作流程。
(3)需求验证:要验证的主要内容有:有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。
需求建模的方法:
(1)关联模型
(2)面向对象模型(3)原型方法
4、系统设计
此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等,一般分为概要设计和详细设计,好的软件设计将为软件程序编写打下良好的基础。
概要设计是对需求规格说明书中提供的软件系统逻辑模型进行进一步的分解,从而建立软件系统的总体结构和各个子系统间及各个模块间的关系,定义各子系统接口界面和各模块的功能描述,并根据设计结果产生概 要设计文档。
概要设计在早期有模块化方法、功能分解方法;在60年代后期提出了面向数据流和面向数据结构的设计方法;近年来又提出面向对象的设计方法等。
详细设计过程根据概要设计形成的结果对各个模块的内部实现进行规划设计,并根据设计结果产生详细设计文档。
详细设计主要方法是通过采用结构化和面向对象的方法从视图、控制、模型三层模型上细化概要设计的各个模块,并完成伪代码为编码阶段做准备。
5、编码和测试
编码是将软件设计的结果转换成计算机可执行的程序代码。主要方法是依据详细设计文档实现设计中的算法、功能、接口、数据结构,采用结构化和面向对象化的方法编写代码。
编码过程中要制定统一,符合标准的编写规范,以保证程序的可读性,易维护性,提高程序的运行效率。
软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。
测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随 意性。
6、软件维护
软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。要延续软件的使用寿命,就必须对软件进行维护。
软件的维护包括纠错性维护和改进性维护两个方面。
二、课程主要收获
《软件工程》课程强调概念和知识的理解和掌握,侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合,是一门理论性和实践性都较强的学科。作为一名已经在IT领域工作十年之后又重返校园的大龄学生,虽然已经不是第一次学习这门课程了,去年也刚在单位取得了信息系统项目管理高级工程师资格,从另一个侧面对软件开发过程有了更深层次的理解。不过温故而知新,这次仍然选修这门课,我还是得到了一些新的启示。最大的收获就是在我看来,软件工程与其说是一门课程,不如说是一门思想,是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,它已经成为了一个综合的能够解决问题的思想集合。
此外,通过对软件开发过程的重学习,并结合之前在软件开发管理工作中的经验,我对自己在软件开发主要阶段管理工作中的不足有了更进一步的认识,总结了相应的管理要点,具体阐述如下:
1、概要设计
主要任务:系统应该怎样做,或概括地说,系统应该如何实现。本阶段特点:将用户的具体要求转为抽象的计算机软件设计。管理要点:
通过分析对比,从多种可能的实现方案和软件结构中选出最佳方案及最合理的,即: 设想供选择的方案→推荐最佳方案→选取合理的方案功能分解→ 软件设计结构 → 数据库设计 3 确定测试要求并确定测试计划
作为项目管理者必须从概要设计开始就应该从全局角度开始把握整个系统的进展,并必须从此阶段开始,时刻从全局观的问题来发现问题,解决问题。
2、详细设计
主要任务:系统应该怎样具体地做,或概括地说,系统应该如何具体地去实现所有的要求。
本阶段特点:将抽象的计算机软件设计转为形象的,具体的,面向用户的计算机界面设计。
管理要点:
本阶段尚未涉及具体编写程序,而是要设计出程序的“蓝图”,所以详细设计的结果基本上决定了最终的程序代码的质量。逻辑是否正确性能是否满足要求是否容易阅读和理解 作为项目管理者在详细设计阶段,应始终不忘从一名用户的使用角度出发,审视每一个界面的详细设计,以保证设计出来的界面以及程序能够满足一般用户希望将来的系统能够通俗易懂,简单实用的要求。
3、编码
主要任务:用某种程序设计语言书写计算机能够识别的程序。
本阶段特点:将详细设计书的内容“翻译”成计算机语言,直接关系到整个项目的质量。
管理要点:
本阶段的编码是设计的自然结果,因此,程序的质量主要取决于软件设计的质量。但是,程序设计语言的特性和编码途径也对程序的以下特性产生深远的影响: 程序的可靠性 2 程序的可读性 3 程序的可测试性 4 程序的可维护性
作为项目管理者在编码阶段,必须从把握进度与质量这两个基本方面来有效地实施对项目的管理。首先应该根据项目进度计划来合理地安排每一名作业成员的作业日程,并且随时监督每一作业的进展情况,还需要针对项目的最新变更及时对计划进行调整,以保证项目的按时完成。同时,在项目的进展过程中还需要通过小组讨论,检查评审等形式洞察每项作业的质量,以保证项目的保质保量完成。可以说,本阶段是一名项目管理者在项目开发过程中极为忙碌也异常重要的阶段。
4、测试
主要任务:通过单元测试和综合测试来保证软件工程的高质量。
本阶段特点:尽可能早地发现并纠正差错,往往占到软件开发总工作量的40%以上,是保证软件质量的关键。
管理要点:
软件测试在软件生命周期中横跨两个阶段。通常在编写出每个模块之后就对其作必要的测试(称之为单元测试),模块的编写者和测试者是同一人,编码和单元测试属于软件生命周期的同一个阶段。在此阶段结束之后,对软件系统还应该进行各种综合测试,这是软件生命周期的另一个独立阶段,通常由专门的测试人员来承担这项工作。
作为项目管理者在编码阶段,必须高度重视软件测试工作,甚至可以说应该把测试看作与编写程序同等重要的任务来对待。在要求每一名开发人员完成自己分内的单元测试,并且监督测试人员认真进行各项综合测试的同时,应该把自己完全当成一名本软件工程的用户,从用户的角度以一种高度负责,甚至近乎苛刻的严格态度来对软件进行彻底的测试。在本阶段通过严把质量关来确保软件工程的质量。
所以说,尤其在软件进入具体开发阶段后,能否遵循要点进行管理是很重要的。
总之,实际工作当中软件项目为什么会失败?为什么交付日期会一拖再拖?我觉得项目失败只有一个原因:就是项目经理不合格。除非这个项目经理在项目开始阶段就已经提出来了这个项目会失败,或者是完全属于项目之外不可抗拒的原因导致失败。也许还会有一些我的同行跳出来说不服,那么请继续:
难道是新增需求的原因导致失败?客户会让你新增100个需求而要你二天交货吗?必然是分析设计阶段没有充分考虑好可扩展性和新增需求导致现在不可控制而失败的!
难道是程序员人力不足导致?人都没有到位,怎么会失败,多少人做多少人的事,多少人做多少人的计划,不会有失败。
难道是程序员技能不够?项目经理是如何面试的?怎么在项目失败了才发现是程序员技能不够?有问题早提出来嘛。
难道测试人员没有做好?少来了,测试人员只是加了一道保障证明。程序很多流程都通过不了,程序还属于开发调试阶段,与测试人员有什么关系?
我曾经在单位参加一些项目,发现有这样一个概念很多项目经理都没有搞清楚:什么叫开发阶段?我认为开发阶段最多只能包括单元测试这一部分。综合测试绝对不能属于开发阶段了,也就是说不能到了最后交付阶段还有程序流程走不通,程序随便正常操作都会失败。程序随便正常操作都出现好多bug属于开发还没有完成,绝对还没有过单元测试阶段,离综合测试和验收阶段还早着呢。说白了,还属于代码审查阶段。
不懂程序设计的项目经理,往往不注重code开发人员,其实这是一个严重的错误。软件的质量来源于什么?由谁来保证?有的项目经理说是由测试人员来保证,就算测试人员的测试用例写得很详细,把需求中的每一个功能点都测试到了,那最后就没有问题了吗?当然不是,很多逻辑上的东西要程序员来保证不出问题的,而测试人员只是起一个验证的作用,问题不应该由测试人员来发现,而应该由开发人员来发现。也就是说,我们尽量不要让测试人员来发现问题。如果第一次测试有至少25%以上的用例通不过,那说明质量控制出了问题。这样的版本根本就不应该拿出来进行测试。由此可见,软件的质量是由程序员来保证的,而不是测试人员。
总的说来,一个项目的成败与否,与项目的各个阶段皆有关系:需求都不清楚,开发起来肯定是南辕北辙;分析设计不够好,会让程序员难以维护,随着新增需求的增多,会导致整个系统混乱不可控制;编码不好,整个系统不稳定是必然的,Bug也是抓不尽的;测试不做好,系统是没有保证的,少了哪个环节都不行。
所以做软件项目开发过程管理工作,我认为重点要放在项目计划、进度控制、质量控制、风险预测这四个方面。不要说项目的失败是因为新需求引起的,一个没有新增需求和风险的项目是不存在的,承认这一点之后,我们就不会有很多怨言了。
以下针对这四个方面进行详述:
项目计划:没有项目计划,那失败还有什么话好说?大家都知道凡事预则立,不预则废。项目计划一定要包括这几方面的内容:各阶段里程碑时间点,各个里程碑的输出结果,风险预测,意外应对。计划时间一定要提前于交货时间,并注意风险意外是否留下足够的应对时间和处理方案。
进度监控:对每个阶段把握好,每个阶段要完成的任务一定要完成,如果完不成,是什么原因导致的?我们的应对策略是什么?我们要信任别人,但是不要忘记锁门。同样的,别人说完成了,你不能就认为别人完成了,要看到结果才能证明完成了。有的项目经理说,我也进度监控啦,他说完成了就完成了,谁想到没有完成?到底是程序员不诚实还是项目没有管理好?你没有锁好门,能怨别人偷你东西吗?还有一种情况就是不懂如何锁门,根本就不知道这一阶段的输出结果是什么?当然进度监控就是一句空话了。
质量监控:也应该是分阶段进行的,每一个阶段的质量监控内容有所不同。
需求分析阶段的质量监控就是完整而又正确的理解用户需求,需求是否清楚可懂,写用例的测试人员是否明白需求?
分析设计阶段的质量监控就是设计是否完全满足需求?这个设计方案是否满足以后新功能的扩展?以及是否有考虑到新功能的意外和设备环境,运行平台的变化?
编码阶段的质量监控就是变量命名是否规范?代码是否可读?是否有详细的注释?是否有重复代码?要知道重复代码是必然会造成系统不稳定,bug成群的。可变部分的代码和不可变部分的代码是否分离。要知道上面讲的每一部分如果没有做好,都会导致后期的产品出现大量问题。代码阶段还有一个重要的工作就是做code review代码公开评审,你自己发现不了的问题别人也许就看得见。
单元测试阶段的质量监控任务就是单元测试代码是否测试通过?代码覆盖是否完全?单元测试报告提交情况如何?单元测试用例有没有做好? 综合测试阶段质量监控任务当然就是看用例是否完全?是否全部真正执行?测试报告有没有写好?
回归测试当然得看以前测试的Bug是否还在,如果还在,当然是无条件打回去重新开发。
测试阶段最主要的监控就是看用例是否真正执行,是否有安全性测试?破坏性测试?异常测试,压力测试?
以上的每个阶段最好完成了才进行下一阶段,否则会造成混乱出现问题的,造成想并行进行节约时间却反而浪费了时间。
以上就是我重学《软件工程》并结合实际工作经验所得到的启示,不妥之处请刘老师批评指正!
第二篇:软件工程学习总结
软件工程学习总结
通过一个学期系统的学习软件工程这门课,结合与小组成员一起开发设备管理系统的经验,让我对软件的开发有了更深的了解,学习到每一个软件的开发都不仅仅是写代码,还有更加复杂的系统性的开发流程。
要开发一个软件,就拿设备管理系统来说,我们不能一上手就开始写代码,这样会浪费大量的人力物力财力还得不到理想的结果,首先我们应该先做好市场及需求方面的调查,了解用户需求有助于我们开发更加实用高效的软件,做好市场调研可以让我们对成本、利润、市场情况等有深层了解,让我们做出最优决策。
调查结束后,我们要写出详细的报告,包括项目开发计划书、软件需求规格说明书等,有了这些调查结果,我们才可以系统的,条理的来编写我们的软件。从前我们写代码都非常的盲目,杂乱无章,想到哪写到哪,浪费了大量的时间,写的代码结构也很松散,错误率高。学习软件工程后,我们学习了多种软件开发模型,学会了模块化的开发方法,小组成员每人完成不同的模块,最后综合起来,这样能够节省大量的时间,缩短开发时间,使代码结构更加紧凑,易于管理维护。如果说代码是一种工具的话,那么软件工程就是使用工具的经验指导,他能指导我们更好的使用这个工具,发挥它最大的潜能,帮助我们完成项目,不管使用什么程序语言,软件工程教给我们的开发方法都无条件适用,我们需要认真学习理解这门课程,它将伴随我们在程序开发的路上走下去。
第三篇:软件工程实施体会
软件工程实施体会
——本学期对软件工程实验使我学会的
软件工程项目是需要团体作业才能够完成的。团体作业就需要交流,有交流,就必然会有合作;有合作,就需要有分工;有分工,就需要有协调;有所有这些,就需要有管理。然而一个人的项目是否不需要管理?当然不是,因为有文档,有代码,有灵感,有经验,等等都需要管理。只是此刻的管理是自己完成的,可以更简单一点。我们已经有过一遍又一遍的调试以前已经fix过的bug体验,也有过一遍又一遍的查找以前自己实现过的技术的经历。软件工程的理论,在开发过程中的作用,就是指导如何做好管理,以取得软件的可用性、正确性和合理性。如果我们清楚知道这是它的目标,就可以抛开一些对自己不适用的枝节。
那么我们如何实现它呢?
我认为软件工程中最重要的,最有实际意义的,是它界定了工作职能,从而也确定了责任归属。什么意思?说白了,就是什么人做什么事,出了问题谁负责。那么它是怎么界定工作职能的?是通过对软件开发流程的划分来实现的。软件工程把软件的开发划分成很多个相对独立的阶段,每一个阶段都有相关的人员来实现,也就有相关的人员来负责。分工不清,责权不明,是导致管理混乱的最主要的因素。所以即使是两个人的项目,也是需要软件工程来指导的,因为通过它,可以更好的知道如何可以合理分工,划分工作职权以取得最终的成果。当然,走教条主义的道路是非常愚蠢的。
软件工程是针对“软件危机”提出来的。它是一种工程,把经验和理论应用到实践中来,解决软件开发中出现的各种问题。这是什么意思?就是说,软件工程是用来解决实际问题的。如果软件开发中没有遇到管理问题,软件工程就不需要管理的内容;如果软件开发中没有遭遇文档混乱,软件工程就不需要文档的部分。但是如果很幸运的遭遇到了这些,那么这一切都是不可或缺的。软件工程不是一个固定的呆板的框框,而是一个有弹性的概念。
所以,如果不是要去申请iso或是cmm认证,完全不必要一板一眼的按照iso或是cmm的规范去做。所谓“有企业特色的软件工程”,完全可以从吸收现有的模式和规范中完善起来。但这并不是说所有在开发过程中出现的都是软件工程,只有那些能引导开发走向成功的才是真正有意义的软件工程。其他的,最多只是失败的尝试。
软件工程实施的时机;
首先要知道软件工程,理解软件工程;然后要了解现有的软件工程的模式和规范。ISO、CMM或是Agility,都定义了一套规范。这些规范是经验与技术,以及理论的积累。它们存在很多合理的、可行的模式,可以引用和参考;但银弹是没有的。当然,我们可以重头再来,造他们造过的轮子,摔他们摔过的跤;但很明显,这是不必要的。
实施的最好方法,也是最可行的方法,成本最小的方法,是根据开发的客观的因素,修改那些规范,以符合我们的开发过程;但是最主要的,是修改我们的主观认识,以符合那些规范;而最重要的,是在实施中发现那些规范不合理的地方,并改正它。我们担心过小的项目应用软件工程是否会陷入官僚主义,从而加重项目的负担?我们再来看什么是软件工程?软件工程并没有定义什么才是软件工程!也没有定义软件工程自身的规模。软件工程的意义在于对开发阶段的划分,以及分工和责任归属。这与项目的规模没有什么冲突。相反,越是小的项目越是需要软件工程的管理。
软件开发的一个共识,是把一个大的项目划分成一些小的模块,再把小的模块划分成更小的模块。如果这些小模块是独立的(或者原来就是一个独立的项目),那么软件工程至少可以提高它的重用性。对于一个软件工程观念不深的团队,不要期望他们在接手大的项目的时候可以使用软件工程,如果他们在小项目中不愿使用的话。前者的复杂度不是他们可以想象和承受的。软件工程对工作量有什么影响?针对那些在不使用软件工程管理的项目中很轻松的人而言的。软件工程会使他们要么失业,要么负起责任来。相对工程师而言,他们会从混乱的毫无头绪的状态中解放出来,他们的工作会变得有效率。损失的是以前尸位素餐的人将暴露出来——这可能是它的唯一的缺陷,同时也是它受到很多企业/个人抵制的可能原因之一。
第四篇:学习软件工程的心得与体会
学习软件工程的心得体会
整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内 容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模等。接着我就详细介绍下我对这门课程知识点的理解概括:
软件工程是指导计算机软件开发和维护的工程学科。
软件生存周期:一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。软件的生存周期可分为八个阶段:①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护; 瀑布模式:原型进化模式:增量模式:螺旋模式:
软件开发的整个过程:①需要项目团队,组建优秀的团队可以开发出更搞质量的软件产品。任务开发团队要求小而精,成员大多在8人以内,主要成员有项目负责人、开发人员、资料管理员和软件测试员。②项目计划是为了使软件开发各项工作有秩序地进行,包括任务分配和基于里程碑的进度安排,甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。③项目成本估算,由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等,但是软件主要是对人力成本的估算,常用的方法有程序代码成本估算法等。④软件风险管理包括很多不确定的风险因素,如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等,而风险管理的主要任务是:风险识别、风险评估、和风险防范。⑤软件文档管理,软件文档是工程模式软件开发的成果体现,包括技术文档、管理文档和用户文档。⑥软件配置管理与软件质量管理,包括配置规划、软件变更控制、软件版本控制和质量控制计划。
《软件工程》课程既强调基本概念和基本知识的理解和掌握,又侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合。我还是蛮喜欢这门课的,通过对这门课的学习让我意识到理论学习很重要,实践更重要,实践是检验真理的唯一标准,只有将理论与实际结合,才更能发挥我们所学的知识的作用,更能直接的创造效益,社会和国家做出贡献。
第五篇:软件工程课程设计个人体会
数学与信息工程学院
项目名称: 实验室设备管理系统 专业班级:11计教1班
学号:1129020025 姓名:蒋一瑭
承担角色:美工,问题处理 组号:08 同组组长:邓磊
同组其他成员:王宇翔 马富伟 江涛 指导教师:钟美
完成起止日期:2014.6.12 《软件工程课程设计个人体会》 1.美化软件和对在设计过程中所遇到的问题进行处理 2.在设计是会出现两种错误,一种是系统部分自定义错误和数据库错误。系统部分自定义错误在权限方面,管理员出现错误,而输入方面用户帐号和密码出错,查找方面找不到符合要求的记录。对于数据库,代码出错。
对于系统部分 自定义错误,需要添加/修改操作只能给几十对输入数据进行验真。分析错误的类新。并给出相应的错误提示语句。
对于数据库错误,可以在可能出错的地方中输入相应的出错语句,并将程序重置,最后返回输入阶段。
此外,还有未解决的问题:未添加设备选购数量属性,输入账户密码后,退出登录后,账户密码自动填充。
至于美工方面,就添了一张图片,一切从简,只留必须要留下的。
3.软件工程课程设计课程设想心得体味,这也激起了我尔后勤奋进修的乐趣,我想这将对我以后的进修发作主动的影响。其次,此次课程设想让我充实熟悉到团队协作的主要性,只要合作协作才干保证整个项目标有条不絮。经过此次设想,我懂得了进修的主要性,体会到实际学问与实际相连系的主要意义,学会了坚持、耐心和勤奋,这将为自己尔后的进修和任务做出了最好的表率。我感受作为一名软件工程专业的先生,此次课程设想是很故意义的。更主要的是若何把自己日常平凡所学的工具利用到理想中。固然自己关于这门课懂的并不多,良多根本的工具都还没有很好的放纵,感受很难,也没有很有效的法子经过自身去了解,可是靠着这一个多礼拜的“进修”,在小组同窗的辅佐和解说下,渐渐对这门课逐渐发作了些许的乐趣,自己起头自动进修并逐渐从根本渐渐起头弄懂它。
所以我以为此次的课程设想意义很深,和其他4位同窗的配合进修、配合、勤奋的进程也很欢快,别的还要感谢感动教员的耐心教育。