学习软件工程心得体会

大学很快过去了两年，大三已经接近了尾声，学习了两年的计算机，从原先的只知道计算机可以上网，逐渐明白了它的原理，它运行的规律，怎么存放数据，如何取出数据，以及读写。这个学期中又学习了软件工程，真正意义上体会到了的一个工程的内涵，一件看起来很简单的事，想要通过计算机智能化实现，都是一个艰辛的过程，我们首先要做到自己与计算机的沟通与对话，然后还要考虑到使用计算机的人的需求，也就是还要人与人的对话，而计算机就是这个中介。

在这门课程中, 老师多元化教课,不但从理论上掌握软件工程,还从不同的实例中,让理论和实践得到了很好的结合。软件工程与其说是一门课程，不如说是一种思想的构架。是一个如何去分析和处理问题的过程，应该说其范畴已经远远不止局限于这门课，更多的是成为了一个综合的能够解决问题的思想集合。这本书的逻辑清晰，由浅入深、循序渐进。软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。它的生存周期是从定义到开发、使用和维护，直到最终被弃用，要经历一个漫长的时期，这个漫长的时期就是它的生命周期。这无形中内让自己想到人的出生与死亡。人的这辈子的真正意义也就是人这生的内涵所在，默默中，不得不想到软件的生命周期就像人的思想的具体化，只是通过了计算机把它表现了出来。

软件开发的整个过程需要项目团队，组建优秀的团队可以开发出更搞质量的软件产品。任务开发团队要求小而精，成员大多在8人以内，主要成员有项目负责人、开发人员、资料管理员和软件测试员。项目计划使软件开发各项工作有秩序地进行，包括任务分配和基于里程碑的进度安排，甘特图和任务网络图是用来描述进度计划的工具。项目计划书可以作为软件开发的工作指南。项目成本估算，由于项目有来自各方面的成本包括工资开支、场地费、差旅费、设备费和资料费等，但是软件主要是对人力成本的估算，常用的方法有程序代码成本估算法等。软件风险管理包括很多不确定的风险因素，如计划风险、管理风险、需求风险、技术风险、人员风险、产品风险、用户风险和商业风险等等，而风险管理的主要任务是：风险识别、风险评估、和风险防范。软件文档管理，软件文档是工程模式软件开发的成果体现，包括技术文档、管理文档和用户文档。

计算机系统由硬件、软件、数据资源、网络资源、使用系统的人等诸多元素。有三种典型的计算机体系结构主机结构，主机集中了全部智能，并依靠终端接口与外部设备连接。Client/Server结构，智能分布于服务器与客户机，并依靠网络连接成系统，其中，服务处于核心位置，提供被动核心服务；客户机处于边缘位置，可主动访问服务器，寻求服务支持。Browser/server结构，可适应互联网远程交互的特殊结构，基于Web服务器构建。需求分析：系统开发前期需求分析很重要，它是为了有效解决用户问题的需要进行的一项工程活动，所需要考虑的需求问题是功能需求、数据需求、性能需求和接口需求，开发者承担分析任务，核心是用户。结构化分析建模：它是建立在需求规约基础上的，对软件问题进行全面解说，包括数据建模，ER图涉及实体、关系、属性等图形元素，在业务层面建立数据库概念模型，一般用于前期的建模构想。功能建模，是对系统数据加工的图解，数据流程图是常用的建模工具，涉及数据接口、数据处理、数据流、数据存储等图形元素，用于描述系统数据加工细节。行为建模，行为模型用于说哦名软件系统与环境的交互，状态转换图常用的软件行为建模工具涉及状态、事件等图形元素。数据字典，是用于定义软件的元素，使软件元素获得严肃的、详密的、精确的规格说明。需求分析模型中的数据、功能、行为等诸多方面的元素，都有必要通过数据字典给予细节说明，以达到对系统较完整全面的规格定义。基于UML对象面向对象分析建模：UML是统一建模语言，有统一的语法、语义和语用规则，其建模过程的特点是：用例驱动、以构架为中心和增量迭代，通过包实现对模型的有效的一体化管理。包括三部分：用例建模，它面向用户需求的，能够反映系统的用户价值，用例图的基本元素有用例、参与者、交流；用例之间有泛化、延伸和包含关系。活动建模，活动图用于描述系统动态过程，主要图形元素有：活动、转换、起点、终点、判断、并发、同步、泳道等。可描述高层业务级活动，涉及整个业务流程，针对每个用例活动建模，反映用例内部活动细节。类分析建模，这里就只考虑实体类，实体类所代表的数据相互之间通常有一定的关系，依靠这种关系可形成有组织的程序数据结构。实体类之间的主要数据关系有：关联、聚类、泛化。

上课的时候听老师所讲述的内容的，觉得他的思想和我们一向以来的培养计算机学生综合素质的理解还是在一定程度上的得到了统一，所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的编编程序就能解决的问题了。计算机系的学生不是被别人说成是个带着厚眼镜的，只能够在电脑前编编程序的，在交际场上不知道说什么而一个字都说不出来的人。因为这样的人进入社会之后缺乏了与人沟通交流的能力。而这门课程在一定程度上给我们一个机会来锻炼自己在另一方面的能力，设想一下，一个又有技术又能够与人交流合作的人所取得的成就自然要比一个单单只会编程序的人要大得多。其次，这门课程教给了我们在完成一个实际项目时的一般程序及过程，我认为这是一份非常具有实际意义的教学内容。当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，我们即使是从事与其它行业，也是要从需求获取开始，一直有条有理地到最后成品的出炉。应该说就是这门课的价值所在，无论是在上课，还是在学生会里面做学生工作，我都深深地感觉到，技术性的工作就好比变魔术，其实原理是非常简单的，甚至可以说简单的可笑，但是当你就是做出这么一个简单的东西出来之后，一些外行们有时候会用崇拜的眼光看着你，觉得你很厉害，很高深莫测。但是制作的过程他们却不知道，也许知道之后他们只是会哑然失笑，原来这个东西的制作过程是如此的简单。这个可以说就是技术的魅力了，而作为需求获取及之后的一系列过程则是类似于魔术揭秘的过程，但是作为这个秘密我们并不需要一揭到底，至于揭的程度如何那就是我们那就是我们学出的程度如何了，我们要让对方知道我们在做什么？以及如何去做？这些东西需要我们以一定的技巧叙述出来，所起到的作用就是能够让对方了解自己的进度，却又能够不让对方来干涉自己的工作过程。因为我们是技术员，对方只是外行，即使对方知道了这个魔术的操作过程，也并不代表他们就能够向变着魔术的我们来随便修改这个魔术的变法，况且我们能够用不同的过程来得出一个同样的结果，这个过程的得出的主动权如何掌握在我们的手上，就看我们如何以高明的方式来揭开这个魔术的谜底了。当然了，在纯粹的理论上，我觉得开设这样一门课程是很成功的。但是毕竟现实里有太多的不确定的因素。最重要的因素就是授课的老师和听课的学生。这两个可以说是这门课成与败的决定性的因素。

作为我们学生来说，应该负起比较主要的责任。在大学里有了太多的基础课程，基础课程大多都比较枯燥无味，也许在第一个学期里我们还能够保持着新鲜感，但是在几个学期之后，可以说再有新鲜感就是一件比较困难的事情了，我们都已经开始变得迟钝了。其次的，没有认识到这门课程的价值。这门课的价值我已经在上面说过了，是不言而喻的。但是并不是每个同学毕业之后都回从事计算机行业，也不是每个同学都知道这门课程的意义已经不仅仅局限于计算机这个范畴。或许有些人觉得反正以后不是这个发展方向，也就不在乎这个课程吧。我个人觉得这门课确实是挺好的，如果认真学必能学到很多东西，动手实践能力和从整个大体分析系统开发的逻辑性思维也会明显增强，不管以后从事哪个方面的工作，这对以后来说都是一笔很大的隐性财富。

这门课既强调基本概念和基本知识的理解和掌握，又侧重软件项目的分析、设计、实现和维护的基本技能。比较注意“点”和“面”的结合。充分扩展了我们的思维，让我意识到理论学习很重要，它是指导我们实践的重要依据，我们也只有具备良好的思想基础，灵活的思维方式，才能在实践中巧妙的与实践结合起来，这样我们才能立足当下，展望未来，为自己的未来美好生活打下坚实的基础，为国家和社会做贡献。

第二篇：软件维护小论文 软件工程

《软件工程小论文》

软件的易维护性差是软件维护工作量和费用激增的直接原因，因此在软件工程的各个阶段都要保证软件具有较高可维护性，从而降低软件维护成本，这是软件工程的重要目标之一。国外的统计数字表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%，其他维护活动只占4%左右，本文对软件维护做了比较详细的介绍。

1 软件维护的概念

1.1软件维护的定义

在软件运行／维护阶段对软件产品进行的修改就是所谓的维护。

维护的类型有四种：

1．改正性维护：在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。

2．适应性维护：在使用过程中，外部环境（新的硬、软件配置），数据环境（数据库、

数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

3．完善性维护：在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。

为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。

4．预防性维护：预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改

进软件打下良好基础。预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。软件

维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。

三类维护占 维护在软件生存期

总维护比例 所占比例

1.2影响维护工作量的因素

在软件的维护过程中，需要花费大量的工作量，从而直接影响了软件维护的成本。应

当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。影响因素如下：

系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需

要更多的维护工作量。

程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，

生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。

系统年龄：老系统随着不断的修改，结构越来越乱；维护人员经常更换，程序又变得越

来越难于理解。许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。

数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，

还可以减少生成用户报表应用软件的维护工作量。

先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。

1.3软件维护的策略

1．改正性维护：通常要生成100％可靠的软件并不一定合算，成本太高。但通过使用

新技术，可大大减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级(第四代)的语言。以及新的开发方法、软件复用、防错程序设计及周期性维护审查等。

2．适应性维护：这一类维护不可避免，但可以控制。

(1) 在配置管理时，把硬件、操作系统和其它相关环境因素的可能变化考虑在内。

(2) 把与硬件、操作系统，以及其它外围设备有关的程序归到特定的程序模块中。

(3) 使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。

3．完善性维护：利用前两类维护中列举的方法，也可以减少这一类维护。特别是数据

库管理系统、程序生成器、应用软件包，可减少维护工作量。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。

1.4维护成本

有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响：一些合理的修复或修改请求不能及时安排，使得客户不满意；变更的结果引入新的故障，使得软件整体质量下降；把软件人员抽调到维护工作中，干扰了软件开发工作。

软件维护的代价是降低了生产率，在做老程序的维护时非常明显。例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。

维护工作量的模型：

其中M是维护中消耗的总工作量，p是上面描述的生产性工作量，K是一个经验常数，c

是因缺乏好的设计和文档而导致复杂性的度量，d是对软件熟悉程度的度量。

模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。

二 软件维护活动

为了有效地进行软件维护，应事先就开始做组织工作。

A．首先建立维护的机构

B．申明提出维护申请报告的过程及评价的过程

C．为每一个维护申请规定标准的处理步骤

D．建立维护活动的登记制度以及规定评价和评审的标准。

2．1 维护机构

除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。

虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。

维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。一旦做出评价，由修改负责人确定如何进行修改，在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。在维护之前，就把责任明确下来，可以减少维护过程中的混乱。

2．2软件维护申请报告

维护申请报告或称软件问题报告，由申请维护的用户填写。用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。维护申请报告将由维护管理员和系统监督员来研究处理。他们应相应地做出软件修改报告，指明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况.

软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。

尽管维护申请的类型不同，但都要进行同样的技术工作：修改软件需求说明；修改软件设计；设计评审；对源程序做必要的修改；单元测试；集成测试( 回归测试)；确认测试；软件配置评审等。

在每次软件维护任务完成后进行情况评审，对以下问题做一总结：

(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?

(2) 哪些维护资源应该有但没有?

(3) 工作中主要的或次要的障碍是什么?

(4) 从维护申请的类型来看是否应当有预防性维护?

情况评审对将来的维护工作如何进行会产生重要的影响。

2．3维护档案记录

维护档案记录包括：程序名称、源程序语句条数、机器代码指令条数、所用的程序设计

语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序增加的源程序语句条数、修改程序减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等。

2．4维护评价

评价维护活动比较困难，因为缺乏可靠的数据。如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值：每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；每个程序、每种语言、每种维护类型的程序平均修改次数；因为维护，增加或删除每个源程序语句所花费的平均“人时”数；用于每种语言的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。

据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。

三 程序修改的步骤及修改的副作用

3.1分析和理解程序

A． 理解程序的功能和目标；

B． 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等；

C． 了解数据流信息，即涉及到的数据来源何处，在哪里被使用

D． 了解控制流信息，即执行每条路径的结果；

E． 理解程序的操作(使用)要求。

3.2修改程序

1. 设计程序的修改计划。

程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。

2. 修改代码，以适应变化。

3. 修改程序的副作用。

所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。

3.3重新验证程序

在将修改后的程序提交用户之前，需要进行充分的确认和测试，以保证整个修改后程序的正确性。

静态确认：修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查：

计算机确认：在进行了以上确认的基础上，用计算机对修改程序进行确认测试：

(1) 确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部

分，最后再把它们集成起来进行测试。这种测试称为回归测试。

(2) 准备标准的测试用例。

(3) 充分利用软件工具帮助重新验证过程。

(4) 在重新确认过程中，需邀请用户参加。

维护后的验收：在交付新软件之前，维护主管部门要检验：

(1) 全部文档是否完备，并已更新；

(2) 所有测试用例和测试结果已经正确记载；

(3) 记录软件配置所有副本的工作已经完成；

(4) 维护工序和责任已经确定。

四 软件可维护性

4．1 软件可维护性的定义

软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。可维护性、可使用性、可靠性是衡量软件质量的主要质量特性。软件的可维护性是软件开发阶段各个时期的关键目标。

目前广泛使用的是用如下的七个特性来衡量程序的可维护性：可理解性、可使用性、可测试性、可移植性、可修改性、效率、可靠性。而且对于不同类型的维护，这七种特性的侧重点也不相同。

在各类维护中的侧重点 ：

五 提高可维护性的方法

提高可维护性的方法很多，包括如下：建立明确的软件质量目标和优先级；使用提高软件质量的技术和工具；进行明确的质量保证审查；选择可维护的程序设计语言；改进程序的文档。

六 小结

通过对《软件工程》和一些资料的学习，我受益匪浅，对软件开发有了一个系统的了解，对一些概念也有了一定了解，虽然这只是一些理论，可能在实际工作中很少用到，但理论知识用于指导实践，亲身体验才能真正领悟软件工程的妙用。我感觉到学习这门课需要花费大量的时间来思考，从而换取宝贵的经验。学习软件工程的过程是枯燥的，但我认为若能把这些枯燥的理论学好，在将来的学习和工作中一定会大有益处。