第一篇:软件工程心得体会(推荐)
软件工程学习心得
这个学期我学习了软件测试这门专业课程,在学期即将结束的时候,我也对这门课程建立基本的了解。软件测试这门课程作为软件工程专业中一门很重要的课程,已经在软件领域占据了不可替代的角色,当一个软件从雏形到真正的在一台计算机是哪个运行的时候,谁也不能保证计算机软件能一步到位的满足人们的需求。所以就有了软件测试,其目的的:第一是确认软件的质量,其一方面是确认软件做了你所期望的事情,另一方面是确认软件以正确的方式来做了这个事情。
我认为,在整个庞大的软件工程中,不管是需求分析、架构设计,甚至是最后的debug,都会产生引入不管的机会,这就要去作为一个软件测试师要掌握丰富的软件工程原理和知识。测试的工作将会存在于整个项目周期,即在项目开始时需要各种分析调研时就开始了,尤其是在形成需求规格说明书时就有对文档的测试需求,甚至主导整个项目的走向。
软件测试对逻辑思维、学习能力、反应思维要求很高,是否有严密的思维和逆向思维也非常重要。做测试还要考虑到所有出错的可能性,有时候还要用一些非常规的测试方法。软件测试还很注重软件性能问题,也
就是要保证软件运行得很好;在不同环境下,考虑软件 的兼容性同样重要。对于测试人员来讲,会比开发人员更加重视软件产品的质量问题。在测试过程中,测试者可能会为可会的需求角度考虑更多,由此我们可以认为测试人员有权利决定产品是否可以发布。然而,通过一个学期的学习,我们又不得不懂得,软件测试人员不是万能的,测试人员在面对一个设计烂编码的软件时,也是无法不低头的,再怎么测试它也变不成优秀的软件。
通过课上的理论和课下的实践,以及在网上和一些论坛里讨论和学习,使我对测试有了大致的接触和深入的了解。以下就是我在软件测试方面的认识:
每项测试都包括三个部分,一组操作,一组预期结果和一组实际结果。另外要尽量用最少的测试用例覆盖软件功能的绝大方面。考虑到各个方面的原因,我们应考虑尽可能多的条件下的测试,这样我们的测试才能更具有全面性和普遍性。大体上我们的测试可以分一下几个方面:
(1)边界测试,测试用户输入框中的数值的最大数和最小数,以及为空时的情况。
(2)非法测试,例如在输入数字的地方输入字母。
(3)跟踪测试,跟踪一条数据的流程,保证数据的正确性。
(4)在开始测试之前应保证数据的正确性,然后再从系统中找出各种BUG。
(5)接口测试,程序往往在接口的地方很容易发生错误,要在此模块测试勿掉以轻心。
(6)代码重用测试,在开发过程中有些模块功能几乎相同,开发人员在重用代码时可能忘记在原有代码上修改或修改不全面,而造成的错误。
(7)突发事件测试,服务器上可能发生意外情况的测试,如网络中断,电源断电等极端的情况。
(8)外界环境测试,有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
(9)系统兼容测试,例如有些程序在IE6能运行正常,到IE5下不能运行。有些程序在WIN2000下能运行,而到WIN98却不能运行。
(10)用户的易用性测试,往往用户的需求是不断的变化的,而其中的一部份变化的原因,是由用户操作上不方便引起的。
虽然课程已经接近尾声,我却开始对软件测试产生浓厚兴趣,也增加了我对其的知识,在以后的大学课余时间中我一定会更加努力,永不放弃,世上无难事,只怕有心人!通过刻苦钻研,相信有付出就一定有回报,总有一天,我定能在计算机和软件测试方面有所成就。
第二篇:软件工程心得体会
《软件工程》的感悟
时间飞逝,不知不觉间《软件工程》的学习已经过了大半了。在这将近半学期的学习中,虽然我不能说我将《软件工程》学习的有多么的好,但是通过学习,我还是受益良多。
在以前,我一直对软件存在一些偏见或则是误解,认为软件就是程序,软件的开发就是编写程序,只要编完了程序,一切也就ok了,而且我还片面的认为只要我掌握了时下最新的语言和工具,那么我就能写程序了。一个人,只要会编程,就能写软件,就是程序员;一个公司,只要招聘一些程序员,就能开发好的软件产品。只要有几个有经验的程序员,再找些兼职的大学生,就能组成一个软件公司。
但是通过了《软件工程》这门课的学习,使我认识到了我以前的错误。软件其实不仅仅是程序,软件开发其实也不仅仅是编写程序,软件是思想在硬件上的载体和体现,处理的是逻辑和信息。唯有对软件和软件的开发过程,有充分的认识,才能更好的开发出,过程受控、质量受控的软件产品。
而且在以前,我一直以为软件的开发其实是一件很轻松快乐的事情,只要一天坐在电脑旁敲敲键盘,那么一切就可以了,但是现在我才发现,我以前的很多的思想是多么的肤浅可笑。编程其实是一种乐趣和苦恼共存的一项创造性活动。因为编程不仅能够满足我们内心深处进行创造的渴望,而且还能愉悦我们内在的情感。
而且通过学习《软件工程》,我还学到了很多其他的东西。比如通过学习《软件工程》,特别是老师每次用实际的软件现场的讲解,为我提供了一个尽早接触世界工作和真实项目的机会。让我知道如何在以最小的成本中,训练自己的基本工程素质和能力,如何激发自己的积极性等。而且通过学习《软件工程》,还让我认识和培养了我的团队协作能力,特别是对于我们这些在校的学生来说,这种学习更是能让我在以后工作中少走很多的弯路。
所以,通过《软件工程》的学习,我是真的学习到了很多有用的东西,让我明白了很多的道理。在此我对老师的辛勤教育表示感谢,因为是你让我学习到了这些,是我获益良多。
第三篇:软件工程心得体会
软件工程心得体会
未接触软件工程之前一直都很想学这门课程,因为觉得这门课很牛,是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课,终于知道了个软件工程的大概。学的时候总觉得很抽象,理解起来好像不难,但总是摸不着头脑一种很茫然的感觉。
曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
经过倪老师的讲解,理解了软件工程,就是一套用于软件的团队开发,以提高软件质量和程序员工作效率为目的的规范。其核心就是,对于软件开发的5个重要组成部分:需求分析,设计,编码,调试,维护,如何组织这5个部分的工作,以及如何完成每一个工作。
吾生也有涯,而知也无涯,学习永无止境。起初,对软件工程处于一知半解的状态,分工比较混乱。在划分模块后明确了各自分工,渐渐形成良性循环。
在学习过程中,知道了团队合作十分重要,争议固然存在,但通过讨论、协商,群策群力,在不断磨合中能够达成一致与默契。团队成员中能力各有高下,互相尊重,各取所长,不宜妄自菲薄。组长多加协调,组员积极配合,才能合作愉快。
学习能力体现在能尽快接受新的知识,顺应变化,学为所用。上《软件工程导论》这门课,我的收获大概如下:
我们为什么需要软件工程呢?上面已经给出了一些原因。专业点讲,软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计,没有设计指导的编程是无序的忙碌的。根据开发的软件的规模,应该适当程度的运用软件工程化的思想,需要灵活,毕竟我们开发的软件大多数是中小型的,大型的并不多见(我是这么认为的)。但只要涉及人员间的交流和沟通,或多或少都要需要软件工程才能更有效率,工作成果更稳定。
其实开发软件,就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法,即我写的这个程序是要干什么的;然后就是对要实现的核心功能大概构思一种或多种实现方法,并从中选出一种自认为是较好的;接下来就是将涉及的各种主要或次要功能分成各个模块;最后就是分模块来编码和DEBUG。在我看来,除了第一步外,其余的步骤应该是一个循环的过程。在编码的过程中,你总是需要不断地回过头来修改原先的模块设计,甚至最初选定的实现算法。
具体到每一步的工作要怎样完成,是非常灵活的,只要把握住大体的方向就行。在进行分析,设计,编码,调试,维护这几部分的工作的时候,最核心的就是文档的编写。
1.可行性分析就是关于当前项目能不能干的分析结果。
2.项目描述这是在决定立项以后,对当前项目的一份扼要说明。3.需求分析就是对客户要求的功能的定义。
4.软件设计这就是对程序的每一个模块的详细设计的说明文档。5.开发日志我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档,它的形式可以很随意,主要是记录一些在写程序时突然萌发的灵感,或对代码的一些微小的修改,或对程序结构的一些微小变动等,还要对上述这些修改变动作些说明。
6.测试分析 用于指出程序存在或潜在的缺陷和错误,以及程序性能的数字描述。
第四篇:软件工程的心得体会(模版)
软件工程心得
我本来可以很快完成心得体会的,回味那段美好的时光。或许未来的某一天,我重新翻开这个实验报告,又会想到那段日子,想起组里的每个人,怀念我们的实验。
现在回想起大学的生活,真的是愧疚比高兴多一点,“浪费了不少时间啊!”。正像老师所说的,我用学强势知识的大好时光浪费在学习一些垃圾知识上。也许这是我自身的错。如果把一个人的一生看成是一个软件产品的生存周期,我想我在本科求学时,就没有做好需求分析,以致于生命的项目出现了设计错误。“软件工程的重点不是在编程,而是怎么你才能进行好的管理”,这是曹老师第一次理论课里给我们树立的第一个观点。在曹老师给我们讲这一口号时,我心里就在犯嘀咕:软件工程和项目管理需要什么商业智慧,会编程开发不就行了么。而且自信自己也曾经所谓的研究过几本有关软件工程方面的著作,对软件工程这门课程根本就没往心里去,只是觉得既然开了这门课,混两个学分就得了。然而,在经过曹老师旁征博引、引经据典的阐释下,我发现以前的观点确实幼稚的可笑。确实,如果一个搞技术的人不懂得商业之道,不能彻底地明白一个企业的根本目标,不能真正了解用户的需求,那么他就不能开发正确的产品和正确地开发产品,因而所开发出来的产品就不能满足客户乃至社会需求,导致产品开发的失败进而使企业蒙受巨大的损失。
这门课的内容紧贴市场,将商业的观念灌入课堂,给我们讲解在今后的职业生涯中如何赚钱,且观点独到。从小学到现在,这样的内容是汗牛充栋的书海中所没有的,是我们传统教育所接触不到的。正因为这样,它使我感觉到:我终于在课本上看到了实话,在课堂中听到了实话。正是这种独特的见解给了我独特的感受,给我了一种全新的理念,给了我一次思想的洗礼。而被传统教育所桎梏了这么多年的我们,正需要这样崭新的,符合时代的观念来打破我们头脑中的顽固的迂腐的思想。也许通过这门课的学习,使我在以后的工作生涯中,我会在做某件事之前首先考虑这件事值不值得做,有没有商业利益,怎样才能将商业利益最大化。当然我所说的事情是指商业上的事情,不是生活中的每一件事情。但是我也明白了生活中不能只有商业这个概念,还要有亲情,爱情,友情。好朋友在生活的道路上是不可少的。所以我会在今后的人生道路上,职业生涯中无形的坚持这一准则。
在实验过程中,我做的是软件设计的需求分析和总体设计阶段,在这以前倒是也做过类似的课题,但是没有这次做的这么严格,以前就是做个东西能运行就行了,但是现在不同,不仅仅似能运行的问题,许多商业的因素我们必须考虑,例如:软件设计的是不是符合用户的要求,即使符合用户要求,那么我们是否能在软件在完成之后让用户满意的用,而不是让产品成为玻璃球,一碰就碎,我们的设计是否为以后的维护做了很好的铺垫,等等。这些我们必须考虑,所以通过这次的实验,我学到的不止是怎么进行一个软件工程,也使我学到了在很多地方学不到的知识。在这个实验以前,我总是认为只要自己努力做,没有干不成的事情。现在想起来那时的想法是多么幼稚,在某个领域不是那个人或是那个天才能干了的,只有通过大家的努力,众志成城,才能很好的完成每一件事情。这不只是在做软件工程上,在其它方面也是一样的。
原来的我,写程序、开发软件的观点思路有偏激的趋势,总将目光局限在某些技术和功能的实现上,失去了宏观的角度。而现在的我,有了新的理念作支撑,我将不遗余力地将这些新方法、新思路贯彻到今后的学习和工作中去。
软件工程已经结束了,但是我觉得这并没有结束,这是一个好的开端,因为它留给里我们的是改变了的思维方式,做事的方法,和对事物的不同的理解。可能这只是我人生的一个小小的经历,但是我觉得它给我在以后的道路上做了一个标记,使我知道怎么做才是对的,怎么做才能做好。最后让我用一句话结尾吧,“梦已经结束,但是梦还会开始”。
第五篇:软件工程学习心得体会
软件工程学习心得体会范文
我们从一些事情上得到感悟后,写一篇心得体会,记录下来,这样可以帮助我们总结以往思想、工作和学习。应该怎么写才合适呢?以下是小编为大家整理的软件工程学习心得体会范文,仅供参考,欢迎大家阅读。
软件工程学习心得体会范文1学习了这门课程,还有老师们的多元化教课,不但让我从理论上掌握软件工程,还有从不同的实例,让理论和实践得到了很好的结合。整一个学期下来,总的来说还是学到了很多东西的,有很多地方是值得肯定的,其实在我看来,软件工程与其说是一门课程,不如说是一门思想。是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,成为了一个综合的一个能够解决问题的思想集合。
整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模等。接着我就详细介绍下我对这门课程知识点的理解概括:
软件:软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据,加上描述程序的操作和使用的文档。
软件的特征:①软件是一种逻辑实体,而不是具体的物理实体,因而它具有抽象性。②软件是通过人们的智力活动,把知识与技术转化成信息的一种产品。③软件成为产品后,其生产只是简单的拷贝,不同于硬件制造。④维护过程比硬件复杂的多,甚至会引发新的错误。软件危机:指的是软件开发和维护过程中遇到的一系列严重问题。出现软件危机的原因:①软件维护费用急剧上升,直接威胁计算机应用的扩大。②软件生产技术进步缓慢。软件工程是指导计算机软件开发和维护的工程学科。软件生存周期:一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。
软件的生存周期可分为八个阶段:①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护;
瀑布模式:是传统的软件开发模式,其中的“瀑布”是对这个模式的形象表达,由山顶倾泻下来的水,自顶向下、逐渐细化。其特点是:线性化过程;分为分析、设计、编码、集成等几个阶段,并且各阶段逐级推进,不允许跨越。里程碑管理;阶段评审;文档驱动;简洁便于工程应用的线性化过程步骤,并可以通过里程碑管理机制而使项目进程量化。其明显的优点就是没个阶段结束前都要对所完成的阶段成果进行评审,这使得软件的错误能够在个阶段内尽早发现并尽早解决,总的来说瀑布模式具有良好的质量保证机制,有很强的生命力。
原型进化模式:对软件进行直接模拟或仿真,只需要分析需求框架后进行原型创建,再对原型系统进行逐步细化与完善,通过版本更新逐步满足用户对于软件的多方面需要。
增量模式:开发过程有三个任务域,分别是设计结构、开发构件和集成系统,它既有完善的工程管理机制,又能适应用户需求变更,有利于质量的监控,并且各局部基于构件构造,有利于逐步构建与完善;由于先交付核心构件可利于降低项目的技术风险。
螺旋模式:是一种可较好的规避开发风险过程的模式,项目是基于任务的螺旋式推进,每个螺旋由内之外分别是需求分析、软件设计、系统集成、验证与交付。
软件开发的整个过程:①需要项目团队,组建优秀的团队可以开发出更搞质量的软件产品。任务开发团队要求小而精,成员大多在8人以内,主要成员有项目负责人、开发人员、资料管理员和软件测试员。②项目计划是为了使软件开发各项工作有秩序地进行,包括任务分配和基于里程碑的进度安排,甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。③项目成本估算,由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等,但是软件主要是对人力成本的估算,常用的方法有程序代码成本估算法等。④软件风险管理包括很多不确定的风险因素,如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等,而风险管理的主要任务是:风险识别、风险评估、和风险防范。⑤软件文档管理,软件文档是工程模式软件开发的成果体现,包括技术文档、管理文档和用户文档。⑥软件配置管理与软件质量管理,包括配置规划、软件变更控制、软件版本控制和质量控制计划。
计算机系统由硬件、软件、数据资源、网络资源、使用系统的人等诸多元素。有三种典型的计算机体系结构:①主机结构,主机集中了全部智能,并依靠终端接口与外部设备连接。②Client/Server结构,智能分布于服务器与客户机,并依靠网络连接成系统,其中,服务器处于核心位置,提供被动核心服务;客户机处于边缘位置,可主动访问服务器,寻求服务支持。③Browser/server结构,可适应互联网远程交互的特殊结构,基于Web服务器构建。
需求分析:系统开发前期需求分析很重要,它是为了有效解决用户问题的需要进行的一项工程活动,所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求,开发者承担分析任务,核心是用户。其步骤有三个:①获取客户需求,客户泛指某个人或机构部门等,一般方法是调查,包括访谈、座谈、问卷、跟班和收集资料,需求规约可表达用户的软件价值。②建立需求模型,它是用户需求的图解,一些常用的模型有:业务树图、用例图、活动图。分别用于结构化需求建模、系统业务举例和反映系统工作流程。③进行需求验证,要验证的主要内容有:有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。结构化分析建模:它是建立在需求规约基础上的,对软件问题进行全面解说,包括四个方面:①数据建模,它与数据库设计密切相关,ER图涉及实体、关系、属性等图形元素,在业务层面建立数据库概念模型,一般用于前期的建模构想。②功能建模,是对系统数据加工的图解,数据流程图是常用的建模工具,涉及数据接口、数据处理、数据流、数据存储等图形元素,用于描述系统数据加工细节。③行为建模,行为模型用于说哦名软件系统与环境的交互,状态转换图常用的软件行为建模工具涉及状态、事件等图形元素。⑤数据字典,是用于定义软件的元素,使软件元素获得严肃的、详密的、精确的规格说明。需求分析模型中的数据、功能、行为等诸多方面的元素,都有必要通过数据字典给予细节说明,以达到对系统较完整全面的规格定义。
基于UML对象面向对象分析建模:UML是统一建模语言,有统一的语法、语义和语用规则,其建模过程的特点是:用例驱动、以构架为中心和增量迭代,通过包实现对模型的有效的一体化管理。包括三部分:①用例建模,它面向用户需求的,能够反映系统的用户价值,用例图的基本元素有用例、参与者、交流;用例之间有泛化、延伸和包含关系。②活动建模,活动图用于描述系统动态过程,主要图形元素有:活动、转换、起点、终点、判断、并发、同步、泳道等。可描述高层业务级活动,涉及整个业务流程,针对每个用例活动建模,反映用例内部活动细节。③类分析建模,这里就只考虑实体类,实体类所代表的数据相互之间通常有一定的关系,依靠这种关系可形成有组织的程序数据结构。实体类之间的主要数据关系有:关联、聚类、泛化。
接下来我就简单说下我上这门课的简单的心得体会,我们是大四的学生了,也只有这个学期有课了,刚开始课表安排出来的时候觉得挺意外的,只有前八周有课,当时我还是有点小感动的,大四事情很多,有要考研的和工作的,大家也都有各自的事情,如果有16周的课,那么每周课不是特别多,但是时间特别分散,也不能集中某段时间去做什么事情。但是相对于老师的压力也有,课程压缩了相当于每节课的教学任务大大增加了,在加上有些假期冲掉课,就感觉我们好像上课学不到什么东西,也只是一些关键的和考试挂钩的才重点讲,完全没有扩展的时间和空间了。但是总的来说,学校开了这门课,我们上了这门课,总是学到了点东西的,不可能明明上了软件工程这门课,却像没上一样什么都不懂。在上课的时候我还是很认真地去听老师所讲述的内容的,我觉得他的思想和我一向而来的培养计算机学生综合素质的理解还是在一定程度上不谋而合了,所谓的需求获取,那就是一个谈判,辩论,交流的过程,已经不是单纯的编编程序就能解决的问题了。从我所看到的听到的来说,我最怕的就是计算机系的学生被别人说成是个带着厚眼镜的,只能够在电脑前编编程序的,在交际场上不知道说什么而一个字都说不出来的人。我觉得这样的人进入社会之后是没有什么前途的,起码他们缺乏了与人沟通交流的能力。而这门课程在一定程度上给了我们这些学生一个机会来锻炼自己在另一方面的能力,设想一下,一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。其次,这门课程教给了我们在完成一个实际项目时的一般程序及过程,我认为这是一份非常具有实际意义的教学内容。当我们在毕业之后,这是我们实际要运用的一项非常有用的技能,而且不仅仅局限于软件工程的范畴,我们即使是从事与其它行业,不也是要从需求获取开始,一直有条有理地到最后成品的出炉吗?应该说这就是这门课的价值所在。无论是在上课,还是在学生会里面做学生工作,我都深深地感觉到,技术性的工作就好比变魔术,其实原理是非常简单的,甚至可以说简单的可笑,但是当你就是做出这么一个简单的东西出来之后,一些外行们有时候会用崇拜的眼光看着你,觉得你很厉害,很高深莫测。但是制作的过程他们却不知道,也许知道之后他们只是会哑然失笑,原来这个东西的制作过程是如此的简单。这个可以说就是技术的魅力了,而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程,但是作为这个秘密我们并不需要一揭到底,至于揭的程度如何那就是我们那就是我们学出的程度如何了,我们要让对方知道我们在做什么?以及如何去做?这些东西需要我们以一定的技巧叙述出来,所起到的作用就是能够让对方了解自己的进度,却又能够不让对方来干涉自己的工作过程。因为我们是技术员,对方只是外行,即使对方知道了这个魔术的操作过程,也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法,况且我们能够用不同的过程来得出一个同样的结果,这个过程的得出的主动权如何掌握在我们的手上,就看我们如何以高明的方式来揭开这个魔术的谜底了。当然了,在纯粹的理论上,我觉得开设这样一门课程是很成功的。但是毕竟现实里有太多的不确定的因素。最重要的因素就是授课的老师和听课的学生。这两个可以说是这门课成与败的决定性的因素。
作为我们学生来说,应该负起比较主要的责任。在大学里有了太多的基础课程,基础课程大多都比较枯燥无味,也许在第一个学期里我们还能够保持着新鲜感,但是在6学期之后,可以说再有新鲜感就是一件比较困难的事情了,我们都已经开始变得迟钝了。其次的,没有认识到这门课程的价值。这门课的价值我已经在上面说过了,是不言而喻的。但是并不是每个同学毕业之后都回从事计算机行业,也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴。或许有些人觉得反正以后不是这个发展方向,也就不在乎这个课程吧。我个人觉得这门课确实是挺好的,如果认真学必能学到很多东西,动手实践能力和从整个大体分析系统开发的逻辑性思维也会明显增强,不管以后从事哪个方面的工作,这对以后来说都是一笔很大的隐性财富。说到我自己对这么课的学习,还是有点愧疚的,前面四周我每周每节课都去上的,并且上课也认真听,一边听老师讲课一边自己看书本的介绍,但是后来我上这门课的次数就降低了,因为觉得时间很紧吧,而且老师上课的节奏我个人觉得有点慢,我都可以自己预习看到后面去了,但是这门课我还是每周至少上一节课的,虽然我早上7点多一点就出门,在自习室,但是有时候明明知道到了上课的时间,明明上课的地方离自习的地方不远也不太想去。我记得有次上课时候老师生气了,说来上课的人少,我仔细环顾了下四周发现确实人很少,稀稀疏疏的分散着,看起来确实不太舒服,让我不得不反思了,这大学的教育到底怎么了,怎么到了大四大家都不来上课,虽然我不是每节课都来,但是我还是时不时来上课的,可能是比较浮躁吧,快毕业了,觉得上课学不到什么实际的东西,要么实际一点好好考研继续深造,要么去培训增强实践能力这样才能较好的为找个满意的工作做好铺垫。
《软件工程》课程既强调基本概念和基本知识的理解和掌握,又侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合。我还是蛮喜欢这门课的,通过对这门课的学习让我意识到理论学习很重要,实践更重要,实践是检验真理的唯一标准,只有将理论与实际结合,才更能发挥我们所学的知识的作用,更能直接的创造效益,社会和国家做出贡献。
软件工程学习心得体会范文2软件工程心得体会未接触软件工程之前一直都很想学这门课程,因为觉得这门课很牛,是那些有工程师称号的高手才摆弄的东西。学了一个学期的软件工程课,终于知道了个软件工程的大概。学的时候总觉得很抽象,理解起来好像不难,但总是摸不着头脑一种很茫然的感觉。曾经以为程序就是软件,软件就是程序。学习这门课程第一个收获是,知道了二者的不同之处。以前做过的一些小型的软件比如加密软件,我也只是在程序旁边附上一个软件的说明,看来已经很接近作坊了。不过大的项目没有接触过,用软件工程的方法还是第一次。我想也是程序的不断复杂化导致了软件危机的发生,使得人们不得不探索新的解决方法。
经过倪老师的讲解,理解了软件工程,就是一套用于软件的团队开发,以提高软件质量和程序员工作效率为目的的规范。其核心就是,对于软件开发的5个重要组成部分:需求分析,设计,编码,调试,维护,如何组织这5个部分的工作,以及如何完成每一个工作。吾生也有涯,而知也无涯,学习永无止境。起初,对软件工程处于一知半解的状态,分工比较混乱。
在划分模块后明确了各自分工,渐渐形成良性循环。在学习过程中,知道了团队合作十分重要,争议固然存在,但通过讨论、协商,群策群力,在不断磨合中能够达成一致与默契。团队成员中能力各有高下,互相尊重,各取所长,不宜妄自菲薄。组长多加协调,组员积极配合,才能合作愉快。学习能力体现在能尽快接受新的知识,顺应变化,学为所用。
上《软件工程导论》这门课,我的收获大概如下:我们为什么需要软件工程呢?上面已经给出了一些原因。专业点讲,软件工程最终是为了实现“软件制造业”的社会化,工业化大生产,提高其劳动生产效率。只有如此,软件业才能实现社会化,工业化大生产,才能“做大做强”。没有管理的设计是失败和混乱的设计,没有设计指导的编程是无序的忙碌的。根据开发的软件的规模,应该适当程度的运用软件工程化的思想,需要灵活,毕竟我们开发的软件大多数是中小型的,大型的并不多见(我是这么认为的)。但只要涉及人员间的交流和沟通,或多或少都要需要软件工程才能更有效率,工作成果更稳定。
其实开发软件,就像是解决一个逻辑问题。想想自己平时是怎样写程序的。首先是要有一个想法,即我写的这个程序是要干什么的;然后就是对要实现的核心功能大概构思一种或多种实现方法,并从中选出一种自认为是较好的;接下来就是将涉及的各种主要或次要功能分成各个模块;最后就是分模块来编码和DEBUG。在我看来,除了第一步外,其余的步骤应该是一个循环的过程。在编码的过程中,你总是需要不断地回过头来修改原先的模块设计,甚至最初选定的实现算法。具体到每一步的工作要怎样完成,是非常灵活的,只要把握住大体的方向就行。在进行分析,设计,编码,调试,维护这几部分的工作的时候,最核心的就是文档的编写。
1.可行性分析就是关于当前项目能不能干的分析结果。
2.项目描述这是在决定立项以后,对当前项目的一份扼要说明。
3.需求分析就是对客户要求的功能的定义。
4.软件设计这就是对程序的每一个模块的详细设计的说明文档。
5.开发日志我一直都认为这是文档中最有趣的部分。开发日志相当于编码阶段的文档,它的形式可以很随意,主要是记录一些在写程序时突然萌发的灵感,或对代码的一些微小的修改,或对程序结构的一些微小变动等,还要对上述这些修改变动作些说明。
6.测试分析用于指出程序存在或潜在的缺陷和错误,以及程序性能的数字描述。
软件工程学习心得体会范文3在本学期的软件工程课程的学习中,我们学习了十一章的内容。第一章软件与软件工程的概念,这一章主要讲解的是一些概念性和基础性的内容,例如软件的概念、特性,软件危机的主要表现,软件工程的概念以及软件生存期、典型生存期模型等等。第二章软件工程方法与工具,这一章主要对软件工程方法进行介绍,包括三种方法:传统方法、面向对象方法、形式化方法。还引出了工具UML。第三章软件需求获取与结构化分析方法,本章详细介绍了需求获取与需求分析阶段的任务以及结构化分析方法,画分层的数据流图、E-R图以及状态图式本节的重点。第四章结构化分析方法,这一章重点讲解了使用变换型映射方法和事务型映射方法生成初始的模块结构以及模块结构的改进。第五章编码,这一章重点讲解了编码的风格及规范,还告诉我们编码规范说带来的好处,并告诫我们将来一点要形成好的编码风格。第六章软件测试方法,本章讲解了软件测试相关的概念及重要性,软件测试与开发各个阶段的关系;还介绍了白盒测试技术以及黑河测试技术。第七章统一建模语言UML概述,本章详细介绍了UML的基本模式、事物、关系及建模时用到的各种图进行了介绍。第八章面向对象分析,这一章主要讲解了面向对象分析的3种模型,包括功能模型、静态模型和动态模型。第九章软件体系结构与设计模式,本章对软件体系结构的基本概念、典型风格等进行了讲解。第十章面向对象设计,本章的重点是对面向对象分析时建立的对象模型进行调整和细化。第十一章软件维护,本章主要介绍软件维护的任务、软件维护活动以及软件维护方法进行了介绍。
要学习软件工程,学会如何系统的思考,以及养成良好的编码习惯,想学好软件工程,就必须知道软件工程的目标、过程和原则:软件工程目标:生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题,它们形成了对过程、过程模型及工程方法选取的`约束。
软件工程过程:生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义,又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构,包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明,包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程,实现完成后的确认,保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程,还有管理过程、支持过程、培训过程等。
软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。
我们学习了详细设计的方法,其原则是过程描述是否易于理解、复审和维护,进而过程描述能够自然地转换成代码,并保证详细设计与代码完全一致。包括程序流程图、N-S图、PAD图、HIPO图
程序流程图:程序流程图又称之为程序框图,它是软件开发者最熟悉的一种算法表达工具。它独立于任何一种程序设计语言,比较直观和清晰地描述过程的控制流程,易于学习掌握。在流程图中只能使用下述的五种基本控制结构:顺序型;选择型;while型循环;until型循环;多情况型选择。
N-S图:一种符合结构化程序设计原则的图形描述工具,称为盒图,又称为N-S图。在N-S图中,为了表示五种基本控制结构,规定了五种图形构件。顺序型;选择型;WHILE重复型;UNTIL重复型;多分支选择型。
PAD图:它是用结构化程序设计思想表现程序逻辑结构的图形工具。PAD也设置了五种基本控制结构的图示,并允许递归使用。
HIPO图:HIPO图是由一组IPO图加一张HC图组成。它是美国IBM公司在软件设计中使用的主要表达工具。
HC图既是层次图,用于表示软件的分层结构。HC图中的每一个模块,均可用一张IPO图来描述。IPO图由输入、处理和输出三个框组成,需要时还可以增加一个数据文件框,这种图形的优点,是能够直观地显示输入—处理—输出三者之间的联系。
还有测试方法:按照测试过程是否在实际应用环境中来分,有静态分析与动态测试。测试方法有分析方法(包括静态分析法与白盒法)与非分析方法(称黑盒法)。
静态分析技术:不执行被测软件,可对需求分析说明书、软件设计说明书、源程序做结构检查、流程分析、符号执行来找出软件错误。
动态测试技术:当把程序作为一个函数,输入的全体称为函数的定义域,输出的全体称为函数的值域,函数则描述了输入的定义域与输出值域的关系。
还学习了其他很多工具、语言、方法等,虽然不是都学得很透彻,但我相信在今后的学习中一定会慢慢的完善的。
软件工程对于初学者来说,知识基础较薄弱,对一些应用操作、概念、工具方法等理解起来较为困难,要能从整体概念上较好地理解和把握、学好软件工程,不是仅仅把几本专业书籍细致地看几遍,然后上机练习几次就可以成功,学习过程中要注意多看多练要注意结合实际,更要多思考,面对错误不要一范就问,要尝试自己去解决。但是还要注意什么都学,肯定是什么都学不透的,要集中精力打攻坚战,学习软件工程首先要明白自己的学习目标究竟是什么,根据自己的实际工作出发,有针对性的在相应的学习方向上进行提高,制定出详细的学习规划。还要注意与其他科目的相辅相成,就像我们在学习面向对象分析的时候要结合大一学习的面向对象及其方法学这一专业科目进行研究拓展;在学习语言时,要看看与C语言的联系,多思多想,把从各个科目学到的知识通汇贯通。
在软件工程的学习中,我了解到了软件并非是一些代码这么简单,在开发软件的过程中,编写代码的工作量其实只占不到所有工程量的30%,而后期的管理和维护更是占了60%到80%之多。一个完整的项目规划须包括,软件的定义,可行性分析报告,项目开发计划,软件需求说明书,概要设计说明书,详细设计说明书,用户操作手册,测试计划,测试分析报告,开发进度报告,项目开发总结报告,软件维护手册,软件问题报告,软件修改报告,等多个文档,每个文档都要上级验收审查,而文档数量众多,要做好这点真的不是很容易,而恰恰写好文档正能保证完成软件工程其中一个目的的关键,既研究如何用最小的开销做出生存期较长的软件,再加上各个阶段都要进行周密的策划、详细的分工部署和人员安排,且各阶段要据具体情况不断的反复才能达成,所以代码只是开发软件这个浩大的工程的一个小小的过程。
而编码的学习中,我更了解到形成自己独特的规范的编码风格是非常重要的事。因为这影响到了软件后期繁重的维护,大家都要阅读你的程序,如果你写的程序毫无规范可言,那么别人怎么能读懂你的程序?读不懂程序,维护又从何谈起呢?所以,我们在今后的学习中,一定要注意这方面的培养,在写程序的过程中,要逐步的在规范的基础上形成属于自己的风格,即方便自己的修改,也方便日后他人的阅读。
在学习中,我们还要注意比较三种方法的优缺点,例如:传统方法虽然使软件摆脱了混乱和无序,但其在适应需求变化的方面不够灵活,而且传统方法要么面向行为,要么面向数据,缺乏两者的有机结合。而面向对象方法的程序设计和问题求解更符合人们日常自然的思维习惯,适合大型、复杂及交互性比较强的系统。形式化方法则是一中基于形式化数学变换的软件开发方法,它可将系统的规格说明转换为可执行的程序。
在今后的学习中要注意多读书、多思考、多练习、多讨论,不断熟悉书本的基础,并以此为基础将其扩散开来,应用于今后的实践。不断锻炼自己,向一名合格的程序设计师迈进。