软件工程学习心得体会

1、 软件工程学习心得体会 软件工程学习经验i ：学习软件工程的经验，学习这门课程，以及教师多样化的教学，不仅让我在理论上掌握了软件工程，而且让我从不同的例子中把理论和实践很好地结合起来。经过整整一个学期，我学到了很多东西，有很多地方值得表扬。事实上，在我看来，软件工程与其说是一门课程，不如说是一个想法这是一个如何分析和处理问题的过程。应该说，它的范围远远超出了课程的范围，它已经成为一套可以解决问题的综合思想整本书的内容逻辑非常清晰和渐进，从浅到深。首先，我将大致描述一下我们学到了什么。第一章从整体上分析了软件工程的发展和社会环境，接下来的章节深入分析了软件开放过程和模式、软件项目管理、计算机工程

2、、需求分析、基于uml的结构化分析建模和面向对象分析建模等。然后我将详细介绍我对本课程知识点的理解，包括：软件：软件是一个可执行的计算机程序，它可以完成预定的功能和性能以及程序正常执行所需的数据，加上描述程序操作和使用的文档。软件特性：(1)软件是一个逻辑实体，而不是一个具体的物理实体，所以它有抽象。软件是通过人们的智力活动将知识和技术转化为信息的产品。软件成为产品后，它的生产只是一个简单的拷贝，不同于硬件制造。维护过程比硬件复杂得多，甚至会导致新的错误。软件危机：以上指软件开发和维护过程中遇到的一系列严重问题。软件危机原因：(1)软件维护成本急剧上升，这直接威胁到计算机应用的扩展软件生产技术

3、进展缓慢。软件工程是一门指导计算机软件开发和维护的工程学科软件生命周期：一个软件经历了从定义到开发、使用和维护的漫长时期，直到最终被放弃，这通常被称为生命周期。软件的生命周期可以分为八个阶段：(1)问题定义；可行性研究；需求分析；总体设计；详细设计；编码和单元测试；综合测试；软件维护；瀑布模式：这是一个传统的软件开发模型，其中“瀑布”是这个模型的形象表达。从山顶倾泻而下的水是其特征是：线性化过程；分为几个阶段，如分析、设计、编码、集成，每个阶段都是逐步推进的，不允许跨度。里程碑管理。阶段审查；文档驱动。简化工程应用的线性化过程步骤，并通过里程碑管理机制。量化项目过程其明显的优点是每个阶段的成果

4、必须在每个阶段结束之前进行评审，这使得软件错误能够在每个阶段尽早被发现和解决。总的来说，瀑布模式具有良好的质量保证机制和强大的生命力。原型进化模式：要直接模拟或模拟软件，我们只需要分析需求框架，然后创建原型，然后逐步细化和完善原型系统，通过版本更新。逐步满足用户对软件的各种需求增量模式：开发过程中有三个任务区域，即设计结构、开发组件和集成系统，不仅有完善的工程管理机制，还能适应用户需求的变化，有利于质量监控，每个部分都是基于组件构建的，有利于逐步构建和完善；因为首先交付核心组件有助于降低项目的技术风险。螺旋模式：这是一个可以更好地避免开发风险过程的模型。这个项目基于任务的循环。每个螺旋是:需要

5、分析、软件设计、系统集成、验证和交付。软件开发的整个过程：(1)需要项目团队，成立优秀的团队可以开发更多优质的软件产品。任务开发团队需要小而精确，其成员大多少于8人。主要成员是项目负责人、开发人员、数据管理员和软件测试人员。项目计划是使软件开发工作有序进行，包括任务分配和基于里程碑的进度安排。甘特图和任务网络图是用来描述进度计划。的工具项目计划可以作为软件开发的工作指南项目成本估算，因为项目有各方面的成本，包括工资费用、场地费、差旅费、设备费和资料费等。，但软件主要估算人工成本，常用的方法有程序代码成本估算法等。软件风险管理包括许多不确定的风险因素，如计划风险、管理风险、需求风险、技术风险、人

6、员风险、产品风险、用户风险和商业风险等。风险管理的主要任务是：风险识别、风险评估、风险预防。软件文档管理，反映工程模式下软件开发的成果，包括技术文档、管理文档和用户文档。等软件配置管理和软件质量管理，包括配置规划、软件变更控制系统、软件版本控制和质量控制计划。计算机系统由硬件、软件、数据资源、网络资源、用户和许多其他元素。组成有三种典型的计算机体系结构：(1)主机结构，主机集中所有智能，并依靠终端接口与外部设备连接。(2)客户机/服务器结构，智能分布在服务器和客户机之间，通过网络连接成一个系统，服务器处于核心位置，提供被动的核心服务；客户端处于边缘，可以主动访问服务器并寻求服务支持。基于web

7、 server 。构建浏览器/服务器结构，能够适应互联网远程交互的特殊结构需求分析：系统开发早期的需求分析非常重要。这是一项有效解决用户问题的工程活动。需要考虑的要求是功能要求、数据要求、性能要求和接口要求。开发人员承担分析任务，核心是用户。有三个步骤：(1)为获取顾客需求，顾客一般指某个人或组织部门等。一般的方法是调查，包括访谈、讨论、问卷、服务员和数据收集，而需求规格可以表达用户的软件价值。(2)建立需求模型，即用户需求图。一些常用的模型是：业务树图、用例图、活动图。用于建模结构化需求、系统业务示例，并反映系统工作流。进行需求验证，待验证的主要内容为：验证、一致性、完整性、真实性和可验证性

8、。结构化分析建模：它基于需求规范，解释软件问题的所有方面，包括四个方面：数据建模，与数据库设计密切相关。电流变图包括图形元素，如实体、关系、属性等。，并在业务级别建立数据库的概念模型，通常用于早期建模概念。功能建模是系统数据处理的示意图，数据流图是一种常用的建模工具，涉及数据接口、数据处理、数据流、数据存储等图形元素，用于描述系统数据处理细节。行为建模，用于描述软件系统与环境之间的交互。状态转换图中常用的软件行是建模工具涉及状态、事件和其他图形元素。事件数据字典用于定义软件元素，因此软件元素变得严肃、详细、精确规格。数据、函数、行为和需求分析模型中的许多其他元素需要通过数据字典来详细解释，以便

9、实现系统。的完整和全面的规范定义基于uml对象：的面向对象分析建模uml是一种统一的建模语言，具有统一的语法、语义和语用规则，其建模过程的特点是：案例驱动、以架构为中心的增量迭代，通过包对模型进行有效的集成管理。包括三个部分：(1)用例建模，面向用户需求，能够反映系统的用户价值。用例图的基本元素是有用的案例、参与者、交流；用例之间存在泛化、扩展和包含关系。的关系活动建模:活动图用于描述系统的动态过程，主要图形元素为：活动、转换、起点、终点、判断、并发、同步、泳道等。可以描述高级业务级别的活动，涉及整个业务流程，为每个用例活动建模，反映用例的内部活动细节。班级分析和建模。这里，只考虑实体类。由实

10、体类表示的数据通常相互之间有一定的关系，通过这种关系可以形成一个有组织的程序数据结构。实体类之间的主要数据关系是：关联、聚类、泛化。接下来，我将简要谈谈我在这门课中的简单经历。我们是高年级学生，只有这学期有课。起初安排日程时，我很惊讶。只有前八周有课。当时，我还是有点感动。我大四的时候有很多事情。有些人需要参加研究生入学考试和工作，每个人都有自己的东西。如果有xxxx年，将占35% 4xxx年，上升到4xxx年和7xxxx年。随着检错率急剧下降并趋于稳定，它进入正常使用周期。但是，由于改造的需要，适应性维护和完善性维护的工作量逐渐增加，在这个维护过程中会引入新的错误，从而增加维护工作量。实践表

11、明，在几次维修活动中，完美维修的比例最大。也就是说，大多数维护工作是为了改变和加强软件，而不是为了纠正错误。因此，维护不一定是消防应急维护，而是计划好的、有预谋的再开发活动。事实证明，扩展、增强软件功能、用户需求性能的维护活动约占整个维护工作的50% = 2%预防性维护。除了上述三种类型的维护之外，还有一种称为预防性维护的维护活动。这是为了提高软件的可维护性、可靠性等。，为今后进一步完善软件打下良好的基础。通常，预防性维护定义为：“将今天的方法应用于昨天的系统以满足明天的需求”。也就是说，高级软件工程方法用于设计需要维护的软件或软件的一部分、编译和测试。在整个软件维护阶段所花费的总工作量中，预

12、防性维护只占很小的比例，而完美维护占了几乎一半的工作量，软件维护活动占了整个生命周期工作量的70%。这是因为在软件的长期运行过程中，有必要不断地修改软件以纠正新发现的错误、适应新的环境和用户的新要求。这些修改需要大量的精力和时间，有时它们是不正确的，新的错误。将被引入同时，软件维护技术并不像开发技术那样成熟、标准化，消耗的工作量自然更多。5.软件维护：数据维护随着应用规模的不断扩大和用户环境的快速发展，不仅基本信息，而且所有其他特殊信息都需要经常维护和更新。根据系统的规模和实际需要，建立系统数据维护和更新机制，规定数据维护和更新周期，使系统的所有数据始终处于最新状态。人们越来越认识到数据对软件

13、的重要性然而，如果数据不经常更新，它可能会失去其应用价值，这是每个软件维护和操作应该注意的问题。硬件维护在软件运行过程中，应建立硬件设备的日常维护制度，并根据设备的使用说明进行及时维护，以确保设备完成，系统正常运行。但是，当设备的处理能力不能满足要求，或设备本身过时、被淘汰，或设备损坏，备件无法购买，或修理不值得时，应考虑硬件更新。的情况应根据硬件评估指数。的要求重新选择系统硬件更新软件维护有许多原因，可以归纳为三种类型。纠正在特定使用条件。下暴露的一些潜在程序错误或设计缺陷由于在软件使用过程中数据环境发生变化或处理环境发生变化，因此有必要修改软件以适应这种变化。用户和数据处理器经常提出改进现有功能、增加新功能和提高整体性能的要求。为了满足这些要求，有必要修改软件并将这些要求纳入软件。中6.软件维护流程提交维护申请后，如果审核后需要维护，则按照以下程序进行维护。首先，确定维护类型。在许多情况下，用户可以将一个请求视为正确的维护，而软件开发人员可以将这个请求视为自适应的或完美的维护。此时，不同的意见需要通过协商解决。纠正性维护从评估错误的严重性。开始如果出现严重错误，例如系统的重要功能无法执行，经理将立即组织相关人员开始分析问题。如果错误不严重，纠正性维护应与软件的其他任务一起进行，维护工作应按计划进行。适应