软件工程论文

软件工程一直缺乏统一的定义，许多学者和组织给出了自己的定义:软件工程(1)和BarryBoehm:利用现代科学技术知识设计和构造计算机程序以及开发、运行和维护这些程序所必需的相关文档。(2)《软件工程术语汇编》中IEEE的定义:软件工程是:1。将系统的、严格约束的、可量化的方法应用于软件开发、运维，即把工程应用于软件；2.研究1 (3)中描述的方法，FritzBauer在北约会议上给出的定义:建立和使用完善的工程原理，以经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。目前，一个公认的定义认为，软件工程是对如何以系统化、标准化和量化的过程方法开发和维护软件，以及如何将经过时间考验的正确的管理技术与目前可用的最佳技术方法相结合的研究和应用。(4)《计算机科学与技术百科全书》中的定义:软件工程是以计算机科学、数学和管理科学的应用原理为基础的软件开发项目。软件工程借鉴传统工程的原理和方法来提高质量，降低成本。其中，计算机科学和数学用于建立模型和算法，工程科学用于制定规范、设计范式、评估成本和确定权衡，管理科学用于管理计划、资源、质量和成本。

[编辑此段]目标

软件工程的目标是在给定成本和进度的前提下，开发具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、适应性、可移植性、可追溯性和互操作性的软件产品，并满足用户的需求。追求这些目标将有助于提高软件产品的质量和开发效率，降低维护的难度。下面介绍这些概念。(1)可变性。允许在不增加原系统复杂性的情况下修改系统。它支持软件的调试和维护，这是一个不可企及的目标。(2)效率。软件系统可以最有效地利用计算机的时间和空间资源。各种计算机软件都把系统的时间/空间开销作为衡量软件质量的重要技术指标。很多场合，追求时间有效性和空间有效性会有矛盾。这个时候，我们就得牺牲时间效率换取空间效率，或者牺牲空间效率换取时间效率。时间/空间权衡经常发生。有经验的软件设计师会在特定的物理环境下，巧妙地运用折中的概念来实现用户的需求和自己的设计。(3)可靠性。它可以防止由于概念、设计和结构的不完善而导致的软件系统故障，并具有恢复由于操作不当而导致的软件系统故障的能力。对于实时嵌入式计算机系统，可靠性是一个非常重要的目标。因为软件要实时控制一个物理过程，比如飞船的航行，核电站的运行等等。如果可靠性得不到保证，一旦出现问题，可能是灾难性的，后果不堪设想。因此，在软件开发、编码和测试过程中，必须把可靠性放在重要位置。(4)可理解性。该系统结构清晰，能直接反映问题的需求。可理解性有助于控制软件系统的复杂性，支持软件的维护、移植或重用。(5)可维护性。在软件产品交付给用户之后，可以对其进行修改，以便纠正潜在的错误、提高性能和其他属性，并使软件产品适应环境的变化，等等。因为软件是一个逻辑产品，只要用户需要，就可以无限使用，所以软件维护不可避免。软件维护成本在软件开发成本中占很大比例。可维护性是软件工程中一个非常重要的目标。软件的可理解性和可修改性有利于软件的可维护性。(6)可重用性。具有相对独立概念或功能的相关模块或一组模块被定义为软件组件。软构件在各种情况下可以应用的程度称为构件可重用性。有些可重复使用的软件不需要修改就可以直接使用，有些需要修改后才能使用。可重用的软件组件应该有清晰的结构和注释，正确的编码和低的时间/空间开销。各种可复用的软件构件也可以按照一定的规则存储在软件构件库中，供软件工程师选择。可复用性有助于提高软件产品的质量和开发效率，降低软件的开发和维护成本。从更广泛的意义上来说，软件工程的可复用性还应该包括:应用项目的复用、规格说明(也称为规格说明)的复用、设计的复用、概念和方法的复用等等。一般来说，重用级别越高，好处越大。(7)适应性。在不同的系统约束下，软件满足用户需求的难易程度。适应性强的软件应该用流行的编程语言编写，在流行的操作系统环境中运行，用标准的术语和格式编写文档。适应性强的软件更容易推广使用。(8)便携性。软件从一个计算机系统或环境转移到另一个系统或环境的容易程度。为了获得较高的可移植性，软件设计通常采用通用的编程语言和运行环境。依赖于计算机系统的底层(物理)特性，比如编译系统的目标代码生成，应该是相对独立和集中的。这样就可以将与处理器无关的部分移植到其他系统中使用。可移植性支持软件的可重用性和适应性。(9)可追溯性。根据软件需求向前追溯软件设计和程序的能力，或者根据程序和软件设计向后追溯软件需求的能力。软件可追溯性依赖于软件开发所有阶段的文档和程序的完整性、一致性和可理解性。降低系统的复杂性将提高软件的可追溯性。当软件测试或维护过程中或程序执行过程中出现问题时，应记录程序事件或相关模块中的全部或部分指令，以便分析和跟踪问题的因果关系。(10)互操作性。多个软件元素相互通信并协作完成任务的能力。为了实现互操作性，软件开发通常遵循一定的标准，支持折衷标准的环境将促进软件元素之间的互操作性。互操作性在分布式计算环境中尤为重要。软件工程活动是“生产一个最终满足需求并实现工程目标的软件产品所需的步骤”。主要包括需求、设计、实现、确认、支持等活动。需求活动包括问题分析和需求分析。问题分析获得需求的定义，也称为软件需求规范。需求分析产生功能规格。设计活动通常包括总体设计和详细设计。概要设计建立了整个软件架构，包括子系统、模块和相关层次的描述，以及每个模块的接口定义。详细设计生成程序员可用的模块描述，包括每个模块中的数据结构描述和处理描述。实施活动将设计结果转化为可执行的程序代码。确认活动贯穿整个开发过程，实现完成后的确认，确保最终产品满足用户的要求。支持活动包括修订和改进。与上述活动相伴随的，还有管理流程、支持流程、培训流程等等。

[编辑本段]流程

生产最终能够满足需求并实现工程目标的软件产品所需的步骤。软件工程过程主要包括开发过程、运行过程和维护过程。它们涵盖需求、设计、实现、验证和维护等活动。需求活动包括问题分析和需求分析。问题分析获得需求的定义，也称为软件需求规范。需求分析产生功能规格。设计活动通常包括总体设计和详细设计。概要设计确立了整个软件体系结构，包括子系统、模块和相关层次的描述，以及各个模块的接口定义。详细设计生成程序员可用的模块描述，包括每个模块中的数据结构描述和处理描述。实施活动将设计结果转化为可执行的程序代码。确认活动贯穿整个开发过程，实现完成后的确认，确保最终产品满足用户的要求。维护活动包括使用过程中的扩展、修改和改进。与上述流程相伴随的，还有管理流程、支持流程、培训流程等等。

[编辑本段]原则

软件工程原理是指围绕工程设计、工程支持和工程管理，在软件开发过程中必须遵循的原则。软件工程原理包括软件工程师的以下四个基本原理:

1)选择合适的开发范式。

这个原理和系统设计有关。在系统设计中，软件需求、硬件需求等因素相互制约、相互影响，往往需要权衡。因此，我们必须了解需求定义的可变性，并采用合适的开发范式来控制它，以确保软件产品满足用户的需求。

2)采用合适的设计方法。

在软件设计中，通常会考虑软件的模块化、抽象性、信息隐蔽性、本地化、一致性和适应性等特点。合适的设计方法有助于实现这些功能，从而实现软件工程的目标。

3)提供高质量的工程支持。

工欲善其事，必先利其器。在软件工程中，支持软件过程的软件工具和环境是非常重要的。软件工程项目的质量和成本直接取决于提供给软件工程的支持的质量和有效性。

4)注重开发过程的管理。

软件工程的管理直接影响到可用资源的有效利用，满足目标的软件产品的生产，以及软件组织生产能力的提高。因此，只有对软件过程进行有效的管理，才能实现有效的软件工程。这个软件工程框架告诉我们，软件工程的目标是可用性、正确性和成本效益；实施一个软件项目，需要选择合适的开发范式，采用合适的设计方法，提供高质量的工程支持，并对开发过程实施有效的管理；软件工程活动主要包括需求、设计、实现、确认和支持，每个活动可以根据具体的软件工程采用合适的开发范式、设计方法、支持过程和过程管理。按照软件工程的框架，软件工程学科的研究内容主要包括:软件开发范式、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE)和软件经济学。

[编辑本段]基本原则

自1968提出“软件工程”这一术语以来，研究软件工程的专家学者提出了100多条关于软件工程的原则或信条。美国著名软件工程专家巴里·博姆综合了这些专家的意见，总结了TRW多年来开发软件的经验。在1983中，他提出了软件工程的七个基本原则。Bohm认为这七个原则是保证软件产品质量和开发效率的最小原则集。它们相互独立，是不可或缺的最小集合。同时，它们是相当完整的。当然，人们无法用数学方法严格证明它们是一个完整的集合，但可以证明，在此之前已经提出的100多个软件工程准则可以包含或衍生出这七个原则的任意组合。以下是软件工程的七个原则:

1，分阶段生命周期计划严格管理

本文是在借鉴前人的基础上提出的。统计数据显示，50%以上的失败项目都是由于计划不周造成的。在软件开发和维护的漫长生命周期中，需要完成许多不同种类的工作。这个原则就是要把软件的生命周期分成几个阶段，并据此制定一个可行的计划，然后严格按照计划管理软件的开发和维护。Bohm认为，在整个软件生命周期中应规定并严格执行六种计划:项目总结计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运维计划。

2、坚持阶段复习。

统计结果表明，大多数错误是在编码前产生的，约占63%。发现错误越晚，纠正错误的成本就越大，差2到3个数量级。所以软件的质量保证不能等到编码结束，要坚持严格的阶段评审，以便尽早发现错误。

3.实施严格的产品控制。

开发人员最讨厌的事情之一就是改变需求。但实践告诉我们，需求的变化往往不可避免。这就要求我们采用科学的产品控制技术来满足这一要求。也就是说要采用变更控制，也就是基准配置管理。当需求发生变化时，其他阶段的文档或代码也随之变化，以保证软件的一致性。

4.采用现代编程技术。

从六七十年代的结构化软件开发技术到最近的面向对象技术，从第一、二代语言到第四代语言，人们已经充分认识到方法和力量一样强大。采用先进的技术不仅可以提高软件开发的效率，还可以降低软件维护的成本。

5.应该清楚地回顾结果。

软件是一种看不见摸不着的逻辑产品。软件开发团队的工作进度可视性差，难以评估和管理。为了更好地管理，应该根据软件开发的总体目标和完成期限，明确定义开发团队和产品标准的职责，以便对获得的标准进行清晰的评审。

6.开发团队的人员要少而精。

开发人员的质量和数量是影响软件质量和开发效率的重要因素，应该少而精。这篇文章基于两个原因:高质量开发人员的效率比低质量开发人员高几倍到几十倍，开发工作中犯的错误也少很多；当开发团队由N人组成时，可能的沟通渠道为N(N-1)/2，说明随着人数N的增加，沟通成本会急剧增加。

7、承认持续改进软件工程实践的必要性。

遵循以上六个基本原则，可以更好地实现软件的工程化生产。但它们只是对已有经验的总结和归纳，并不能保证赶上技术不断发展的步伐。因此，Bohm提出软件工程的第七个原则应该是认识到软件工程实践持续改进的必要性。根据这一原则，既要积极采用新的软件开发技术，又要注意不断总结经验，收集进度、消耗等数据，统计错误类型和问题。这些数据不仅可以用来评估新软件技术的效果，还可以指出必须注意的问题和应该首先研究的工具和技术。

[编辑本段]方法

软件工程的方法有许多含义。包括项目管理、分析、设计、编程、测试和质量控制。软件工程师的软件设计方法可以分为重量级方法和轻量级方法。重量级方法产生大量的正式文档。著名的重量级开发方法包括RUP的ISO9000、CMM和统一软件开发过程。轻量级开发过程不需要大量的正式文档。著名的轻量级开发方法包括极限编程(XP)和AgileProcesses。《新方法论》一文认为，重量级方法呈现防御态势。在应用重量级方法的软件组织中，由于软件项目经理不参与或很少参与编程，他们无法详细掌握项目的进度，所以他们会对项目感到恐惧，不得不要求程序员不断地编写许多“软件开发文档”。而轻量级的方式则呈现出“进攻”的态度，体现在XP方法特别强调的四个原则——“沟通、简单、反馈、勇气”。目前有人认为重量级方法适合大型软件团队(几十人以上)，而“轻量级方法”适合小型软件团队(几个人，十几个人)。当然，关于重量级方式和轻量级方式的优劣也有很多争论，各种方式也在不断发展。一些方法论学者认为，人们应该在开发中严格遵循和执行这些方法。但是有些人不具备实施这些方法的条件。其实开发软件的方法取决于很多因素，受环境制约。

[编辑此段]主菜

外语、高等数学、线性代数、高等代数、电子技术基础、离散数学、计算机导论(C语言)、数据结构、C++编程、JAVA编程、Delphi编程、汇编语言编程、算法设计与分析、计算机组成原理与体系结构、数据库系统、计算机网络、软件工程、软件测试技术、软件需求与项目管理、软件设计案例分析。此外，还包括操作系统、软件架构介绍、设计模式、多媒体技术基础、UML建模、概率论、大学英语等。有些学院还会包括大学物理、工程制图、数值分析等。

[编辑本段]发展方向

敏捷开发被认为是软件工程的一个重要发展。它强调软件开发应该能够充分应对未来可能的变化和不确定性。敏捷开发被认为是一种“轻量级”方法。轻量级方式中最著名的应该是“极限编程”(简称XP)。与轻量级方式相对应的是“重量级方式”的存在。重量级方法强调以开发过程为中心，而不是以人为中心。重量级方法的例子有CMM/PSP/TSP。面向方面编程(AOP)被认为是近年来软件工程的又一重要发展。这里的方面指的是完成一个功能的对象和功能的集合。在这方面，有泛型编程和模板。

[编辑本段]需求分析

软件工程包括需求、设计、编码和测试四个阶段，其中需求工程是软件工程的第一个也是非常重要的阶段。以医院管理软件工程需求分析系统为例，详细介绍了需求工程的组成和实现方法。首先，人们必须了解需求工程与其他项目过程的关系:图1需求与其他项目过程的关系软件需求包括三个不同的层次——业务需求、用户需求和功能需求——以及非功能需求:业务需求解释了新系统提供给客户和产品开发人员的最初好处，反映了组织或客户对系统和产品的高层目标需求，在项目视图和范围文档中有所解释；用户需求文档描述用户在使用产品时必须完成的任务，在用例文档或方案脚本描述中有说明；功能需求定义了开发人员必须实现的软件功能，以便用户完成任务，从而满足业务需求。需求工程分为两个阶段:需求开发和需求管理。这两个阶段解释如下:首先，需求开发分为需求获取、需求分析、规格编写和需求验证。下面列出并解释了分析的常规步骤。当然要根据项目的大小、特点等实际情况来确定合适的步骤。1.需求获取:1)确定需求开发过程:确定需求开发过程中如何组织需求的收集、分析、细化和验证的步骤，并将其写入文档。对重要的步骤给予一些指导，这将有助于分析师的工作，也使安排和调度需求收集活动变得更加容易。2)编制项目视图和范围文档:项目视图和范围文档应包括高层次的产品业务目标，所有用例及功能需求必须符合可实现的业务需求。项目视图描述使所有项目参与者能够* * *理解项目目标。范围用作评估需求或潜在特征的参考。表1项目视图和范围文档的模板A，1背景在这一部分中，我们总结了新产品的理论基础，并提供了产品开发的历史背景或情况的一般描述。2业务机会描述现有的市场机会或正在解决的业务问题。描述商品竞争的市场和信息系统将被使用的环境。它包括对现有产品和解决方案的简要相对评估，并指出建议的产品为什么有吸引力以及它们可以带来的竞争优势。a、3业务目标用一种定量的、可衡量的方法概括产品所带来的重要业务利润，并着眼于赋予业务的价值。a、4客户或市场需求描述了一些典型客户的需求，包括不符合现有市场需求的产品或信息系统。本文对顾客目前在新产品中遇到的问题提出了可能(或不可能)的解释，并提供了顾客如何使用产品的实例。确定了产品可以运行的软件和硬件平台。a、5提供给顾客的价值决定了产品给顾客带来的价值，表明产品如何满足顾客的需求。A.6业务风险概述与开发(或不开发)产品相关的主要业务风险，如市场竞争、时间问题、用户的接受能力、实现问题或对业务可能产生的负面影响等。预测风险的严重性，并指出您可以采取的减轻风险的措施。B.1项目观陈述写一个简短的项目观陈述，概括长期目标和开发新产品的目的。项目观点陈述将考虑权衡具有不同需求的客户的观点。可能有点理想化，但必须基于现有或预期的客户市场、企业框架、组织的战略方向和资源限制。B.2主要功能包括新产品将提供的主要功能和用户性能列表。重点在于区别于以往产品和竞争产品的特点。这些特性可以从用户需求和功能需求中获得。B.3假设和相关环境在构思项目和撰写项目视图和范围文档时，记录所做的任何假设。通常，一方应该持有与另一方不同的假设。c.1初始发布的范围总结了第一批发布产品的性能。描述产品的质量特性，使产品能够为不同的顾客群体提供预期的结果。C.2后续发布的范围如果你设想一个周期性的产品演进过程，你应该指明哪些主要功能开发将被推迟，并预计后续发布的日期。C.3限制和特殊性明确定义包括和排除的特性和功能的界限是处理范围设置和客户期望的一种方式。列出利益相关者期望但你不打算包含在产品中的特性和功能。D.1客户概况客户概述明确了本产品不同类型客户的一些本质特征，以及目标市场部门和这些部门中不同客户的特征。D.2项目优先次序一旦明确了项目优先次序，利益相关者和项目参与者就可以集中精力实现一系列类似的目标。实现这个目标的一个方法是考虑软件项目的五个方面:性能、质量、计划、成本和人员。e .产品成功的因素定义和衡量产品成功，指出对产品成功影响较大的几个因素。它不仅应包括组织直接控制范围内的交易，还应包括外部因素。如果可能，可以建立一个度量标准来评估业务目标是否实现。3)用户群分类:产品的用户在很多方面都是不同的，比如用户使用产品的频率、对应用领域和计算机系统的了解程度、所使用产品的特点、业务流程、地域布局、访问优先级等。根据这些不同，你可以把这些不同的用户分组。用户类不一定指人。您可以将其他应用程序或系统界面使用的硬件组件视为其他用户类的成员。以这种方式查看API可以帮助您确定产品中与外部应用程序或组件相关的需求。对用户群进行分类，总结各自的特点。为了避免忽略某个用户群体的需求，就要做到一切可能的差异化。详细描述他们的个性特征和任务条件将有助于产品设计。4)产品代表的选择:选择每一类用户的产品代表，选择至少一个能真正代表他们需求的人作为该类用户的代表，并能做出决策。这对于内部信息系统的开发来说是最容易的，因为这个时候，用户就是身边的工作人员。对于商业开发，需要在主要客户或测试人员之间建立良好的合作关系，确定合适的产品代表。他们必须始终参与项目的开发，并有权做出决策。每个产品代表代表一个特定的用户类，并充当该用户类和开发人员之间的主要接口。5)建立核心团队:建立典型用户核心团队，集合同类产品或之前版本产品的用户代表，向他们收集当前产品的功能性需求和非功能性需求。这样的核心团队对业务发展特别有用，因为你有一个庞大而多样的客户群。与产品代表不同，核心团队成员通常没有决策权。6)确定用例:让用户代表确定用例，从用户代表那里收集他们需要用软件完成的任务的描述，讨论用户与系统的交互方式和对话需求。使用示例编写文档时可以使用标准模板，基于示例可以获得功能需求。一个用例可能包括许多逻辑上相关的任务和交互序列来完成一个任务。因此，使用示例是相关使用描述的集合，描述是使用示例的示例。描述时列出执行者与系统的交互或对话顺序。当这段对话结束时，执行人也达到了预期的目的。对于一些复杂的用例，绘制图形化的分析模型是有益的，这些模型包括数据流图、实体关系图、状态转移图、对象类和联系图。用例的描述并没有给开发者提供他们想要开发的功能的细节。为了减少这种不确定性，有必要将每个用例描述为详细的功能需求。每个用例可以导致多个功能需求，这将使执行者能够执行相关的任务；并且多个用例可能需要相同的功能需求。使用用例方法获取需求的好处来自于这种方法是以任务和用户为中心的观点。与以功能为中心的方法相比，示例方法可以让用户更清楚新系统允许他们做什么。每个用例描述了一种方法，通过这种方法，用户可以与系统进行交互以实现特定的目标。使用实例可以有效地捕获大多数预期的系统行为，但是您可能有一些与用户任务或其他执行者之间的交互没有特定关系的需求。这个时候，你就需要一个独立的需求说明书。7)召开应用开发联络会:召开应用开发联络会是一个广泛而简单的座谈会，也是分析师和客户代表之间很好的合作方式，从中可以拟定需求文档的草稿。会议能够通过密切和集中的讨论将客户和开发人员之间的伙伴关系付诸实践。8)分析用户工作流:分析用户工作流，观察用户执行业务任务的过程。画一个简单的示意图(最好是数据流图)来描述用户什么时候得到什么数据，如何使用这些数据。编写业务流程文档有助于明确产品的使用示例和功能需求。您甚至会发现，客户并不真的需要一个全新的软件系统来实现他们的业务目标。9)确定质量属性:确定质量属性和其他非功能性要求，在功能性要求之外考虑非功能性质量特性，这将使你的产品满足并超过顾客的期望。系统如何能很好地执行某些行为或让用户采取某些措施的陈述就是质量属性，它是非功能性需求。倾听描述合理特征的意见:快速、简单、直观、用户友好、稳健、可靠、安全和高效。你将与用户讨论，以精确地定义他们的模糊和主观的话的真正含义。10)查看问题报告:通过查看当前系统的问题报告，可以进一步完善需求客户的问题报告，补充需求，为新产品或版本的改进和添加功能提供了大量丰富的思路。负责提供用户支持和帮助的人可以为收集需求的过程提供非常有价值的信息。11)需求复用:跨项目复用需求如果客户要求的功能与现有产品相似，我们可以检查需求是否足够灵活，允许一些现有的软件组件被复用。