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