软件工程心得体会.docx
- 文档编号:9973361
- 上传时间:2023-02-07
- 格式:DOCX
- 页数:27
- 大小:45.22KB
软件工程心得体会.docx
《软件工程心得体会.docx》由会员分享,可在线阅读,更多相关《软件工程心得体会.docx(27页珍藏版)》请在冰豆网上搜索。
软件工程心得体会
软件工程心得体会
篇一:
学习
学习软件工程的心得体会
学习了这门课程,还有老师们的多元化教课,不但让我从理论上掌握软件工程,还有从不同的实例,让理论和实践得到了很好的结合。
整一个学期下来,总的来说还是学到了很多东西的,有很多地方是值得肯定的,其实在我看来,软件工程与其说是一门课程,不如说是一门思想。
是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,成为了一个综合的一个能够解决问题的思想集合。
整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模等。
接着我就详细介绍下我对这门课程知识点的理解概括:
软件:
软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据,加上描述程序的操作和使用的文档。
软件的特征:
①软件是一种逻辑实体,而不是具体的物理实体,因而它具有抽象性。
②软件是通过人们的智力活动,把知识与技术转化成信息的一种产品。
③软件成为产品后,其生产只是简单的拷贝,不同于硬件制造。
④维护过程比硬件复杂的多,甚至会引发新的错误。
软件危机:
指的是软件开发和维护过程中遇到的一系列严重问题。
出现软件危机的原因:
①软件维护费用急剧上升,直接威胁计算机应用的扩大。
②软件生产技术进步缓慢。
软件工程是指导计算机软件开发和维护的工程学科。
软件生存周期:
一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。
软件的生存周期可分为八个阶段:
①问题定义;②可行性研究;③需求分析;④总体(概要)设计;⑤详细设计;⑥编码与单元测试;⑦综合测试;⑧软件维护;
瀑布模式:
是传统的软件开发模式,其中的“瀑布”是对这个模式的形象表达,由山顶倾泻下来的水,自顶向下、逐渐细化。
其特点是:
线性化过程;分为分析、设计、编码、集成等几个阶段,并且各阶段逐级推进,不允许跨越。
里程碑管理;阶段评审;文档驱动;简洁便于工程应用的线性化过程步骤,并可以通过里程碑管理机制而使项目进程量化。
其明显的优点就是没个阶段结束前都要对所完成的阶段成果进行评审,这使得软件的错误能够在个阶段内尽早发现并尽早解决,总的来说瀑布模式具有良好的质量保证机制,有很强的生命力。
原型进化模式:
对软件进行直接模拟或仿真,只需要分析需求框架后进行原型创建,再对原型系统进行逐步细化与完善,通过版本更新逐步满足用户对于软件的多方面需要。
增量模式:
开发过程有三个任务域,分别是设计结构、开发构件和集成系统,它既有完善的工程管理机制,又能适应用户需求变更,有利于质量的监控,并且各局部基于构件构造,有利于逐步构建与完善;由于先交付核心构件可利于降低项目的技术风险。
螺旋模式:
是一种可较好的规避开发风险过程的模式,项目是基于任务的螺旋式推进,每个螺旋由内之外分别是需求分析、软件设计、系统集成、验证与交付。
软件开发的整个过程:
①需要项目团队,组建优秀的团队可以开发出更搞质量的软件产品。
任务开发团队要求小而精,成员大多在8人以内,主要成员有项
目负责人、开发人员、资料管理员和软件测试员。
②项目计划是为了使软件开发各项工作有秩序地进行,包括任务分配和基于里程碑的进度安排,甘特图和任务络图是用来描述进度计划的工具。
项目计划书可以作为软件开发的工作指南。
③项目成本估算,由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等,但是软件主要是对人力成本的估算,常用的方法有程序代码成本估算法等。
④软件风险管理包括很多不确定的风险因素,如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等,而风险管理的主要任务是:
风险识别、风险评估、和风险防范。
⑤软件文档管理,软件文档是工程模式软件开发的成果体现,包括技术文档、管理文档和用户文档。
⑥软件配置管理与软件质量管理,包括配置规划、软件变更控制、软件版本控制和质量控制计划。
计算机系统由硬件、软件、数据资源、络资源、使用系统的人等诸多元素。
有三种典型的计算机体系结构:
①主机结构,主机集中了全部智能,并依靠终端接口与外部设备连接。
②Client/Server结构,智能分布于服务器与客户机,并依靠络连接成系统,其中,服务器处于核心位置,提供被动核心服务;客户机处于边缘位置,可主动访问服务器,寻求服务支持。
③Browser/server结构,可适应互联远程交互的特殊结构,基于Web服务器构建。
需求分析:
系统开发前期需求分析很重要,它是为了有效解决用户问题的需要进行的一项工程活动,所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求,开发者承担分析任务,核心是用户。
其步骤有三个:
①获取客户需求,客户泛指某个人或机构部门等,一般方法是调查,包括访谈、座谈、问卷、跟班和收集资料,需求规约可表达用户的软件价值。
②建立需求模型,它是用户需求的图解,一些常用的模型有:
业务树图、用例图、活动图。
分别用于结构化需求建模、系统业务举例和反映系统工作流程。
③进行需求验证,要验证的主要内容有:
有效性验证、一致性验证、完整性验证、现实性验证和可检验性验证。
结构化分析建模:
它是建立在需求规约基础上的,对软件问题进行全面解说,包括四个方面:
①数据建模,它与数据库设计密切相关,ER图涉及实体、关系、属性等图形元素,在业务层面建立数据库概念模型,一般用于前期的建模构想。
②功能建模,是对系统数据加工的图解,数据流程图是常用的建模工具,涉及数据接口、数据处理、数据流、数据存储等图形元素,用于描述系统数据加工细节。
③行为建模,行为模型用于说哦名软件系统与环境的交互,状态转换图常用的软件行为建模工具涉及状态、事件等图形元素。
⑤数据字典,是用于定义软件的元素,使软件元素获得严肃的、详密的、精确的规格说明。
需求分析模型中的数据、功能、行为等诸多方面的元素,都有必要通过数据字典给予细节说明,以达到对系统较完整全面的规格定义。
基于UML对象面向对象分析建模:
UML是统一建模语言,有统一的语法、语义和语用规则,其建模过程的特点是:
用例驱动、以构架为中心和增量迭代,通过包实现对模型的有效的一体化管理。
包括三部分:
①用例建模,它面向用户需求的,能够反映系统的用户价值,用例图的基本元素有用例、参与者、交流;用例之间有泛化、延伸和包含关系。
②活动建模,活动图用于描述系统动态过程,主要图形元素有:
活动、转换、起点、终点、判断、并发、同步、泳道等。
可描述高层业务级活动,涉及整个业务流程,针对每个用例活动建模,反映用例内部活动细节。
③类分析建模,这里就只考虑实体类,实体类所代表的数据相互之间通常有一定的关系,依靠这种关系可形成有组织的程序数据结构。
实体类之间的
主要数据关系有:
关联、聚类、泛化。
接下来我就简单说下我上这门课的简单的心得体会,我们是大四的学生了,也只有这个学期有课了,刚开始课表安排出来的时候觉得挺意外的,只有前八周有课,当时我还是有点小感动的,大四事情很多,有要考研的和工作的,大家也都有各自的事情,如果有16周的课,那么每周课不是特别多,但是时间特别分散,也不能集中某段时间去做什么事情。
但是相对于老师的压力也有,课程压缩了相当于每节课的教学任务大大增加了,在加上有些假期冲掉课,就感觉我们好像上课学不到什么东西,也只是一些关键的和考试挂钩的才重点讲,完全没有扩展的时间和空间了。
但是总的来说,学校开了这门课,我们上了这门课,总是学到了点东西的,不可能明明上了软件工程这门课,却像没上一样什么都不懂。
在上课的时候我还是很认真地去听老师所讲述的内容的,我觉得他的思想和我一向而来的培养计算机学生综合素质的理解还是在一定程度上不谋而合了,所谓的需求获取,那就是一个谈判,辩论,交流的过程,已经不是单纯的编编程序就能解决的问题了。
从我所看到的听到的来说,我最怕的就是计算机系的学生被别人说成是个带着厚眼镜的,只能够在电脑前编编程序的,在交际场上不知道说什么而一个字都说不出来的人。
我觉得这样的人进入社会之后是没有什么前途的,起码他们缺乏了与人沟通交流的能力。
而这门课程在一定程度上给了我们这些学生一个机会来锻炼自己在另一方面的能力,设想一下,一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。
其次,这门课程教给了我们在完成一个实际项目时的一般程序及过程,我认为这是一份非常具有实际意义的教学内容。
当我们在毕业之后,这是我们实际要运用的一项非常有用的技能,而且不仅仅局限于软件工程的范畴,我们即使是从事与其它行业,不也是要从需求获取开始,一直有条有理地到最后成品的出炉吗?
应该说这就是这门课的价值所在。
无论是在上课,还是在学生会里面做学生工作,我都深深地感觉到,技术性的工作就好比变魔术,其实原理是非常简单的,甚至可以说简单的可笑,但是当你就是做出这么一个简单的东西出来之后,一些外行们有时候会用崇拜的眼光看着你,觉得你很厉害,很高深莫测。
但是制作的过程他们却不知道,也许知道之后他们只是会哑然失笑,原来这个东西的制作过程是如此的简单。
这个可以说就是技术的魅力了,而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程,但是作为这个秘密我们并不需要一揭到底,至于揭的程度如何那就是我们那就是我们学出的程度如何了,我们要让对方知道我们在做什么?
以及如何去做?
这些东西需要我们以一定的技巧叙述出来,所起到的作用就是能够让对方了解自己的进度,却又能够不让对方来干涉自己的工作过程。
因为我们是技术员,对方只是外行,即使对方知道了这个魔术的操作过程,也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法,况且我们能够用不同的过程来得出一个同样的结果,这个过程的得出的主动权如何掌握在我们的手上,就看我们如何以高明的方式来揭开这个魔术的谜底了。
当然了,在纯粹的理论上,我觉得开设这样一门课程是很成功的。
但是毕竟现实里有太多的不确定的因素。
最重要的因素就是授课的老师和听课的学生。
这两个可以说是这门课成与败的决定性的因素。
作为我们学生来说,应该负起比较主要的责任。
在大学里有了太多的基础课程,基础课程大多都比较枯燥无味,也许在第一个学期里我们还能够保持着新鲜感,但是在6学期之后,可以说再有新鲜感就是一件比较困难的事情了,我们都已经开始变得迟钝了。
其次的,没有认识到这门课程的价值。
这门课的价值我已
经在上面说过了,是不言而喻的。
但是并不是每个同学毕业之后都回从事计算机行业,也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴。
或许有些人觉得反正以后不是这个发展方向,也就不在乎这个课程吧。
我个人觉得这门课确实是挺好的,如果认真学必能学到很多东西,动手实践能力和从整个大体分析系统开发的逻辑性思维也会明显增强,不管以后从事哪个方面的工作,这对以后来说都是一笔很大的隐性财富。
说到我自己对这么课的学习,还是有点愧疚的,前面四周我每周每节课都去上的,并且上课也认真听,一边听老师讲课一边自己看书本的介绍,但是后来我上这门课的次数就降低了,因为觉得时间很紧吧,而且老师上课的节奏我个人觉得有点慢,我都可以自己预习看到后面去了,但是这门课我还是每周至少上一节课的,虽然我早上7点多一点就出门,在自习室,但是有时候明明知道到了上课的时间,明明上课的地方离自习的地方不远也不太想去。
我记得有次上课时候老师生气了,说来上课的人少,我仔细环顾了下四周发现确实人很少,稀稀疏疏的分散着,看起来确实不太舒服,让我不得不反思了,这大学的教育到底怎么了,怎么到了大四大家都不来上课,虽然我不是每节课都来,但是我还是时不时来上课的,可能是比较浮躁吧,快毕业了,觉得上课学不到什么实际的东西,要么实际一点好好考研继续深造,要么去培训增强实践能力这样才能较好的为找个满意的工作做好铺垫。
《软件工程》课程既强调基本概念和基本知识的理解和掌握,又侧重软件项目的分析、设计、实现和维护的基本技能。
比较注意“点”和“面”的结合。
我还是蛮喜欢这门课的,通过对这门课的学习让我意识到理论学习很重要,实践更重要,实践是检验真理的唯一标准,只有将理论与实际结合,才更能发挥我们所学的知识的作用,更能直接的创造效益,社会和国家做出贡献。
篇二:
读软件工程案例教程有感
对于学习软件工程这门课程,我认为有许多东西要学习。
其实在我看来学习这门课程的精髓是学习一种方法。
是一个如何去分析和处理问题的过程,应该说其范畴已经远远不止局限于该门课程,成为了一个综合的一个能够解决问题的思想集合。
读完软件工程案例教程这本书,我觉得自己受益匪浅。
整本书的内容逻辑很清晰明了,由浅入深循序渐进,首先我就大概描述下我们所学的内容,第一章是从整体分析软件工程这门学科的发展和所处的社会环境,接着后面的几章深入分析了软件开放过程和模式、软件项目管理、计算机工程、需求分析、结构化分析建模以及基于UML面向对象分析建模和测试等。
对于这本书我主要对需求分析和测试比较感兴趣,在这我要着重的谈一些自己的心得体会以及自己的看法。
一.需求分析
需求分析的重要性
一款成功的软件是建立在成功的需求分析之上的,而高质量的需求于用户与开发人员之间有效的沟通与合作。
当用户有一个问题可以用计算机系统来解决,而开发人员开始帮助用户解决这个问题,沟通就开始了。
由此我们可以看出需求分析的重要性。
需求获取可能是最困难、最关键、最易出错及最需要沟通交流的活动。
对需求的获取往往有错误的认识:
用户知道需求是什么,我们所要做的就是和他们交谈从他们那里得到需求,只要问用户系统的目标特征,什么是要完成的,什么样的系统能适合商业需要就可以了,但是实际上需求获取并不是想象的这样简单,这条沟通之路布满了荆棘。
首先需求获取要定义问题范围,系统的边界往往是很难明确的,用户不了解技术实现的细节,这样造成了系统目标的混淆。
其次是对问题的理解,用户对计算机系统的能力和限制缺乏了解,任何一个系统都会有很多的用户或者不同类型的用户,每个用户只知道自己需要的系统,而不知道系统的整体情况,他们不知道系统作为一个整体怎么样工作效率更好,也不太清楚那些工作可以交给软件完成,他们不清楚需求是什么,或者说如何以一种精确的方式来描述需求,他们需要开发人员的协助和指导,但是用户与开发人员之间的交流很容易出现障碍,忽略了那些被认为是"很明显"的信息。
最后是
需求的确认,因为需求的不稳定性往往随着时间的推移产生变动,使之难以确认。
为了克服以上的问题,必须有组织的执行需求的获取活动。
需求分析的原则
(1)需求分析必须能够表达和理解问题的数据域和功能域。
数据域包括数据流、数据内容和数据结构,而功能域反映上述3方面的控制信息。
(2)需求分析要把一个复杂问题按功能进行分解并逐层细化。
通常,软件系统要处理的问题如果太大、太复杂就很难理解,若划分成几部分,并确定各部分间的接口,就可完成整体的功能。
在需求分析过程中,软件系统的用户需求中的数据、功能和行为都应细化。
(3)需求建模。
模型可以帮助系统分析人员更好地理解软件系统的数据、功能和行为,这些模型是软件工程中下一阶段进行系统设计的基础。
需求分析的注意事项
(1)确定详细的需求,否则经费就算不准。
经费估计错误的原因多为:
用户需求频繁变动、遗漏重要需求、与用户交流不够、需求规格说明书质量低劣、需求分析不充分等。
(2)在编写需求规格说明书之前,应明确要解决的问题。
在试图解决问题之前,要保证已考察了全部可替代的方案。
要搞清哪地方有问题,真正的问题出在哪里。
这样,在编写需求规格说明书时做到有的放矢,把存在的问题暴露出来。
(3)立即确定需求,并记录下该需求的背景。
没有明确问题,就进行下一步的设计,想回避矛盾,可能会带来更大的问题。
用户不确定需求,软件设计人员自己决定需求,将会带来严重的问题。
为了避免将来可能出现的问题和软件工程项目能够尽快地进入到下一个阶段的系统设计中,要尽可能迅速地把用户需求确定下来。
任何决定总比没有决定要好。
(4)一旦在需求规格说明书中发现问题,立即改正。
如果把存在的问题拖延到系统设计阶段去改正,就可能要花数倍的时间和精力才能纠正同一错误。
(5)在众多用户需求中确定各个需求的优先顺序,并确定可能存在的子集,以便为软件设计、实施和项目管理等后续阶段提供有利条件。
(6)需求分析时,不要进行系统设计的工作。
需求分析的主要目的是确定软件系统的外部特征,充分反映软件系统应有的面貌,便于让软件设计人员根据
用户需求,去全面地考虑软件系统的体系结构、算法等。
在需求分析阶段要集中精力解决用户需求存在的问题,尽可能避免产生遗留问题。
(7)对于复杂的软件系统,要从多种视角进行需求分析。
根据软件系统的本质,切合实际地组织多种视角的需求。
例如,可从根据用户的类型,或根据响应的类型,或根据对象的软件工程案例教程类型,或根据系统的模式等视角来组织用户需求。
通过多个视角来研究用户需求问题,把可得到的不同的“投影”组合起来形成完整系统的描述。
当试图从整体观点来描述软件系统发生困难,或者有可能发生错误,或者很有可能遗失软件系统的某些特性。
而从不同的视角来描述软件系统,因为每个视角限制了研究的范围并能够将注意力集中于此,所以很容易保证所研究的问题是真正完整的。
(8)重视形式化方法,但不放弃自然语言。
为了用户需求表达的精确性和方便用户的可理解性,一个好方法是把自然语言的表达与形式化规格说明并立,互相对照,而且在一般情况下,先用自然语言写出,再给出它的形式模型。
(9)用户需求中不应存在“待确定”的条款。
如若有这种需要,应同时说明:
何时由谁来解决该问题。
用户需求的类型
需求分析是从用户最初的非形式化需求到满足用户要求的软件产品的映射过程。
它实际上是一个对用户意图不断进行揭示和判断的过程,其目的在于细化、精化软件的作用范围,确定拟开发软件的功能和性能、约束、环境等。
可将用户的需求分为两大类:
功能性需求和非功能性需求。
(1)功能性需求。
功能性需求主要说明了系统各功能部件与环境之间的相互作用的本质,即拟开发软件在职能上实际应做到什么。
一般来说,它是用户最主要的需求,通常包括系统的输入、系统能完成的功能、系统的输出以及其他反应。
在功能性需求中还应包括备选功能的定义识别。
(2)非功能性需求。
非功能性要求主要从各个角度对所考虑的可能的解决方案起约束和限制作用。
需求分析的方法
在软件工程中,常用的需求分析方法有面向数据流的结构化分析方法(简称SA)和面向对象的分析方法(简称OOA)。
此外,还有以用户为中心的需求分析
方法。
这些方法都采用图文结合的方式,可以直观地描述软件的逻辑模型。
这里仅介绍结构化分析方法和以用户为中心的需求分析方法。
2.软件测试
软件测试概述
软件本身无形态,它是复杂的知识高度密集的逻辑产品,其中不可能没有错误。
软件实施工程过程中必须伴随着软件质量保证的活动,而软件测试是主要活动之一。
在开发软件的过程中,人们使用了许多保证软件质量的方法分析、设计和实现软件,但难免还会在工作中犯错误。
这样,在软件产品中就会隐藏许多错误和缺陷。
对于规模大、复杂性高的软件更是如此。
在这些错误中,有些是致命的错误,如果不排除,就会导致生命与财产的重大损失。
软件测试的目的
测试的目的是“说明程序能正确地执行应有的功能”,还是“表明程序没有错误”?
基于不同的立场,存在着两种完全不同的测试目的。
从用户的角度出发,普遍希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可以接受该产品。
而从软件开发者的角度出发,则希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。
因此,他们会选择那些导致程效概率小的测试用例,回避那些易于暴露程序错误的测试用例。
同时,也不会刻意去检测、排除程序中可能包含的副作用。
显然,这样的测试对完善和提高软件质量毫无价值。
因为在程序中往往存在着许多预料不到的问题,可能会被疏漏,许多隐藏的错误只有在特定的环境下才可能暴露出来。
如果不把着眼点放在尽可能查找错误这样一个基础上,这些隐藏的错误和缺陷就查不出来,会遗留到运行阶段中去。
如果站在用户的角度,替他们设想,就应当把测试活动的目标对准揭露程序中存在的错误。
在选取测试用例时,考虑那些易于发现程序错误的数据。
软件测试的原则
(1)应当把“尽早地和不断地进行软件测试”作为软件开发者的座右铭。
由于原始问题的复杂性、软件的复杂性和抽象性、软件开发各个阶段工作的多样性,以及参加开发各种层次人员之间工作的配合关系等因素,使得开发的每个环节都可能产生错误。
所以不应把软件测试仅仅看成是软件开发的一个独立阶段。
而应当把它贯穿到软件开发的各个阶段中。
在需求分析阶段就应该制订测试计划,以保证每个需求,每个设计单元都是可测试的,便于测试。
坚持在软件开发的各个阶段的技术评审,这样才能在开发过程中尽早发现和预防错误,把出现的错误克服在早期,杜绝某些隐患,提高软件质量。
(2)测试用例应由测试输入数据和与之对应的预期输出结果这两部分组成。
测试以前应当根据测试的要求,选择在测试过程中使用的测试用例(TestCase)。
测试用例主要用来检验程序员编制的程序,因此不但需要测试的输入数据,而且需要针对这些输入数据的预期输出结果。
如果对测试输入数据没有给出预期的程序输出结果,那么就缺少了检验实测结果的基准,就有可能把一个似是而非的错误结果当成正确结果。
(3)程序员应避免检查自己的程序。
测试工作需要严格的作风、客观的态度和冷静的情绪。
自己测试自己的软件不容易发现错误,程序员应避免测试自己的程序。
测试是一种“挑剔性”的行为,人们常常由于各种原因具有一种不愿否定自己工作的心理,认为揭露自己程序中的问题总不是一件愉快的事,这一心理状态就成为测试自己程序的障碍。
心理状态和思维定式是测试自己程序的两大障碍,应由别人或另外的机构来测试程序员编写的程序。
另外,程序员对软件规格说明理解错误而引入的错误则更难发现。
如果由别人来测试程序员编写的程序,可能会更客观、更有效,并更容易取得成功。
要注意的是,这点不能与程序的调试(Debugging)互相混淆,调试由程序员自己来做可能更有效。
(4)在设计测试用例时,应当包括合理的输入条件和不合理的输入条件。
合理的输入条件是指能验证程序正确的输入条件,而不合理的输入条件是指异常的、临界的、可能引起问题变异的输入条件。
在测试程序时,人们常常倾向于过多地考虑合法的和期望的输入条件,以检查程序是否做了它应该做的事情,而忽视了不合法的和预想不到的输入条件。
事实上,软件在投入运行以后,用户的使用往往不遵循事先的约定,使用了一些意外的输入,如用户软件工程案例教程在键盘上按错了键或打入了非法的命令。
如果开发的软件遇到这种情况时不能做出适当的反应,给出相应的信息,那么就容易产生故障,轻则给出错误的结果,重则导致软件失效。
因此,软件系统处理非法命令的能力也必须在测试时受到检验。
用不合理的输件测试程序时,往往比用合理的输入条件进行测试能发现更多
篇三:
《软件工程》的感悟
时间飞逝,不知不觉间《软件工程》的学习已经过了大半了。
在这将近半学期的学习中,虽然我不能说我将《软件工程》学习的有多么的好,但是通过学习,我还是受益良多。
在以前,我一直对软件存在一些偏见或则是误解,认为软件就是程序,软件的开发就是编写程序,只要编完了程序,一切也就ok了,而且我还片面的认为只要我掌握了时下最新的语言和工具,那么我就能写程序了。
一个人,只要会编程,就能写软件,就是程序员;一个公司,只要招聘一些程序员,就能开发好的软件产品。
只要有几个有经验的程序员,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程 心得体会