软件工程概览-CSDN博客

本文链接：https://blog.csdn.net/weixin_39505814/article/details/127306427

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

1️⃣软件工程概述

1.1软件概念

计算机软件是由专业人员开发并长期维护发软件产品。完整的软件产品包括了在各种不同内容和体系结构计算机上的可执行程序，运行过程中产生的各种结果，以及以硬复制和电子表格等多种方式存在的软件文档。
软件包含三部分：
计算机程序，即人们为了完成特定的功能而编制的一组指令集。
数据，即程序能处理的具有一定数据结构的信息。
软件文档，它是与程序的开发、维护和使用的有关的图文资料，如软件开发设计规划、需求规格说明书、设计说明书、测试分析报告和用户手册。

1.2软件的特点

1）具有抽象性
2）无明显的制造过程
3）存在退化问题
4）对计算机系统有着不同程度的依赖性
5）尚未完全摆脱人工的开发方式
6）软件本身是复杂的
7）成本相当昂贵
8）相当多的软件工作涉及社会因素

1.3软件的分类

1.4产生软件危机的原因

1.软件开发是一项复杂的工程，需要用科学的工程化的思想来组织和指导软件开发的各个阶段。
2.没有完善的质量保证体系。
3.软件文档的重要性没有得到软件开发人员和用户的足够重视。
4.从事软件开发的专业人员对这个产业认识不充分，缺乏经验。
5.软件独有的特点也给软件的开发和维护带来困难。
人们对软件产品认识的不足以及对软件开发的内在规律理解的偏差是软件危机出现的本质原因。

1.5软件危机表现

1.开发人员开发的软件产品不能完全满足用户的需求。
2.软件产品的质量难以得到保证。
3.软件产品的开发周期、开发经费和维护费用很难被准确地估计，从而给项目的管理带来很多麻烦。
4.随着技术的更新，用户需求的扩大，已有的软件产品往往不能灵活地适应环境的改变。
5.软件文档不完备，并且存在文档内容与软件产品不符的情况。软件文档的不完整和不一致会给软件的开发和维护等工作带来很多麻烦。

【补充】解决危机的途径

技术措施
使用更好的软件开发技术、开发方法和开发工具
组织管理措施
（1）创造良好的组织、严密的管理与协调工作的机制。软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。
（2）摆脱软件危机的主要出路是，按工程化的原则和方法组织软件的开发工作。
（3）强调文档的重要性。 “口说无凭，立字为据”是解决软件危机的格言。

【补充】软件危机的启示

（1）软件危机给我们的最大启示，是使我们更加深刻的认识到软件的特性以及软件产品开发的内在规律。
（2）软件产品是复杂的人造系统，具有复杂性、不可见性和易变性，难以处理。个人或小组在开发小型软件时使用到的非常有效的编程技术和过程，在开发大型、复杂系统时难以发挥同样的作用。
（3）从本质上讲，软件开发的创造性成分很大、发挥的余地也很大，很接近于艺术。它介于艺术与工程之间的某一点，并逐步向工程一段漂移，但很难发展到完全的工程。

1.6软件工程的概念

1968年，首次提出了“软件工程”的概念，并将其定义为“为了经济地获得可靠的和能在实际机器上高效运行的软件，而建立和使用的健全的工程规则"。
软件工程的目标主要包括以下几点∶
（1）使软件开发的成本能够控制在预计的合理范围内。
（2）使软件产品的各项功能和性能能够满足用户需求。
（3）提高软件产品的质量。
（4）提高软件产品的可靠性。
（5）使生产出来的软件产品易于移植、维护、升级和使用。
（6）使软件产品的开发周期能够控制在预计的合理时间范围内。
随着40多年的发展，软件工程已经成为一门独立的学科，对软件工程有了更全面、更科学的认识。
IEEE对软件工程的定义为∶
（1）将系统化、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件（2）对（1）中所述方法的研究。
具体说来，软件工程是以借鉴传统工程的原则、方法，以提高质量，降低成本为目的指导计算机软件开发和维护的工程学科。它是一种层次化的技术。

【补充】如何理解软件工程

软件工程包括三个要素——过程、方法和工具，三者共同以质量管理为基础。

【补充】软件工程目标

软件工程要达到的基本目标包括：
达到要求的软件功能
取得较好的软件性能
开发出高质量的软件
付出较低的开发成本
需要较低的维护费用
能按时完成开发工作，及时交付使用

【补充】软件工程研究的内容

软件工程研究的内容软件工程研究的内容主要包括以下两个分。
1）软件开发技术。主要研究软件开发方法、软件开发过程、软件开发工具和环境。
2）软件开发过程管理。主要研究软件工程经济学和软件管理学。必须强调的是，随着人们对软件系统研究的逐渐深入，软件工程研究的内容也在不断更新和发展。

【补充】软件工程的基本目标

◆到达要求的软件功能
◆取得较好的软件性能
◆开发出高质量的软件
◆付出较低的开发成本
◆需要较低的维护费用
◆能按时完成开发工作，及时交付使用

1.7软件工程的基本原则

◆将软件的生命周期划分为多个阶段，对各个阶段实行严格的项目管理。
◆坚持阶段评审制度，以确保软件产品的质量。
◆实施严格的产品控制，以适应软件规格的变更。
◆采用现代程序设计技术。
◆开发出来的软件产品应该能够清楚地被审查。
◆合理地安排软件开发小组的人员，并且开发小组的人员要少而精。
◆不断地改进软件工程实践。

【补充】软件工程开发方法

软件开发方法是一种使用定义好的技术集及符号表示组织软件生产的过程，它的目标是在规定的时间和成本内，开发出符合用户需求的高质量的软件。
常见的软件开发方法包括∶结构化方法、面向数据结构方法、面向对象方法、形式化方法，此外，软件开发方法还有问题分析法、可视化开发方法等。

1.8 软件工程的知识体系

IEEE在 2014年发布的《软件工程知识体系指南》中将软件工程知识体系划分为以下 15个知识领域。
1.软件需求、 2.软件设计、3.软件构建、
4.软件测试、5.软件维护、6.软件配置管理、
7.软件工程管理、8.软件工程过程、9.软件工程模型和方法、10.软件质量、11.软件工程职业实践、12.软件工程经济学、
13.计算基础、14. 数学基础、15.工程基础。

1.9 软件工程人员的职业道德

（1）保密（2）能力（3）知识产权（4）计算机滥用

1.10 软件工程职业道德和职业行为准则

（ACM/IEEE-CS联合制定以规范软件工程行业的职业道德和职业行为
（1）公众（2）客户和雇主
（3）产品（4）判断力
（5）管理（6）职业感
（7）同事（8）自我

2️⃣软件工程过程

2.1软件过程概念

软件的诞生和生命周期是一个过程，我们总体上称这个过程为软件过程。软件过程是为了开发出软件产品，或者是为了完成软件工程项目而需要完成的有关软件工程的活动，每一项活动又可以分为一系列的工程任务。任何一个软件开发组织，都可以规定自己的软件过程，所有这些过程共同构成了软件过程。
过程定义了运用方法的顺序，应该交付的文档资料，为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。通常，使用生命周期模型简洁地描述软件过程。生命周期模型规定了把生命周期划分为哪些阶段及各个阶段的执行顺序，因此也称为过程模型。

2.2软件生命周期

作为一种工业化的产品，软件产品的生命周期是指从设计该产品的构想开始，到软件需求的确定、软件设计、软件实现、产品测试与验收、投入使用以及产品版本的不断更新，到最终该产品被市场淘汰的全过程。
软件产品的生命周期一般可以划分为6个阶段∶
1.可行性研究：可行性研究阶段为后续的软件开发做必要的准备工作。它首先要确定待开发的软件产品所要解决的问题。开发人员还应该确定总体的开发策略与开发方式，并对开发所需要的资金、时间和各种资源做出合理的估计。还需要对开发软件产品进行可行性分析，并制定初步的开发计划。
2.需求分析：需求是指，为了解决用户提出的问题，目标系统需要做什么。在需求分析阶段，开发人员首先要通过各种途径对需求进行获取。开发人员需要对原始的需求进行抽象与概括，从功能、性能、界面和接口等诸多方面对需求进行详细的描述，并最终反映到软件需求规格说明书中。
3.软件设计∶软件设计就是指在需求分析的基础上，软件开发人员通过制定设计方案，把需求文档中描述的功能可操作化。设计可以分为概要设计和详细设计两个阶段。概要设计旨在建立系统的总体结构，从总体上对软件的结构、接口和全局数据结构等给出数据说明。详细设计关注每个模块的内部实现细节，为后续的编码工作提供最直接的依据。
4.编码∶在编码阶段，开发人员根据设计阶段制定出的设计方案，编写程序代码。
5.软件测试∶软件测试是保证软件质量的关键步骤。软件测试的目的是发现软件产品中存在的软件缺陷，进而保证软件产品的质量。
6.软件维护∶在软件产品被交付后，其生命周期还在继续。在使用软件产品的过程中，软件开发人员需要对产品进行维护，以保证软件产品的正常运行。

2.2.1 瀑布模型

瀑布模型是出现得比较早的软件开发模型。在这种模型中，各阶段之间的组织方式就如同瀑布流水一样，逐级下落。开发人员必须在完成前一阶段的任务后，才能开始下一阶段的工作，各个阶段之间通常是按固定顺序连接的，前一阶段的输出往往就是后一阶段的输入。瀑布模型是一种线性的开发模型，具有不可回溯性。由于其不可回溯性，如果在软件生命周期的后期发现并要改正前期的错误，那么需要付出很高的代价。

特点∶

瀑布模型是一种线性的软件开发模型，回溯性很差。
瀑布模型是一种基于里程碑的阶段过程模型。
瀑布模型强调软件开发过程的阶段性，每个阶段完成特定的任务。
优点∶过程模型简单，执行容易
缺点：无法适应变更
瀑布模型适用于具有以下特征的软件开发项目。
（1）在软件开发的过程中，需求不发生或很少发生变化，并且开发人员可以一次性获取到全部需求。否则，由于瀑布模型较差>的可回溯性，在后续阶段中需求的经常性变更需要付出高昂的代价。
（2）软件开发人员具有丰富的经验，对软件应用领域很熟悉。
（3）软件项目的风险较低。瀑布模型不具有完善的风险控制机制。

2.2.2 快速原型模型

快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。
从下图可以看出，快速原型模型是不带反馈环的，这正是这种过程模型的主要优点∶软件产品的开发基本上是按线性顺序进行的。

优点：可低成本、快速地确认需求、按线性顺序进⾏开发
缺点：选⽤的开发技术和⼯具不⼀定符合主流的发展

2.2.3增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行提交。

增量模型的最大特点就是将待开发的软件系统模块化和组件化。
◆优点
（1）将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
（2）以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
（3）开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
◆缺点
要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
增量模型适用于具有以下特征的软件开发项目。（1）软件产品可以分批次地进行交付。（2）待开发的软件系统能够被模块化。
（3）软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。（4）项目管理人员把握全局的水平较高。

2.2.4螺旋模型

螺旋模型是一种用于风险较大的大型软件项目开发的过程模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。它把开发过程分为制定计划、风险分析、实施工程和客户评估4种活动。制定计划就是要确定软件系统的目标，了解各种资源限制，并选定合适的开发方案。

优点∶将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。
缺点∶这种模型的控制和管理较为复杂，可操作性不强，对项目管理人员的要求较高。

2.2.5喷泉模型

喷泉模型是一种过程模型，同时也支持面向对象开发。喷泉模型的示意图如图所示。在分析阶段，定义类和对象之间的关系，建立对象-关系和对象-行为模型。在设计阶段，从实现的角度对分析阶段模型进行修改或扩展。在编码阶段，使用面向对象的编程语言和方法实现设计模型。在面向对象的方法中，分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行。

喷泉”一词体现了面向对象方法的迭代和无间隙性。迭代是指各阶段需要多次重复，例如，分析和设计阶段常常需要多次、重复进行，以更好的实现需求。无间隙性是指各个阶段之间没有明显的界限，并常在时间上互相交叉，并行进行。
喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。

2.2.6基于组件的开发模型

基于组件的开发模型使用现有的组件以及系统框架进行产品开发，由于现有组件大多已经历实际应用的反复检验，因此其可靠性相对新研发组件高出很多。
基于组件开发模型的示意图如图所示，在确定需求之后，开发人员开始从现有的组件库中筛选合适的组件，并对组件功能进行分析。在对组件分析之后，开发人员可能适当修改需求来适应现有组件，也可能修改组件或寻找新的组件。组件筛选完成之后，开发人员需要根据需求设计或使用现有的成熟开发框架复用这些组件，一些无法利用现有组件的地方，则需要进行单独的开发，新开发的组件在经历时间考验之后也会加入到组件库中。最后将所有组件集成在一起，进行系统测试。组件库可能是组织内部开发的，也可能是商业授权组件，后者常常需要支付费用并且不能任意修改和传播，但也有一些开源组织（如著名的GNU）或自由开发人员提供免费并可自由修改和传播的组件。

基于组件的开发模型充分的体现了软件复用的思想，降低了开发成本和风险，并加快了产品开发。

2.2.7统一软件开发过程模型

统一软件开发过程（Rational Unified Process，RUP）模型是基于UML（统一建模语言）的一种面向对象软件开发模型。它解决了螺旋模型的可操作性问题，采用迭代和增量递进的开发策略，并以用例驱动为特点，集中了多个软件开发模型的优点。RUP模型是迭代模型的一种。RUP模型的示意图如图所示。

上图中的纵轴以工作的内容为组织方式，表现了软件开发的工作流程。工作流程可以分为核心工作流程和核心支持工作流程。
上图中的横轴以时间为组织方式，表现了软件开发的4个阶段∶先启、细化、构建和产品化，每个阶段中都可能包含若干次迭代。这4个阶段按照顺序依次进行，每个阶段结束时都有一个主要里程碑。阶段与里程碑的关系如下图所示。
统一软件开发过程模型是基于迭代思想的软件开发模型。采用迭代的软件工程思想可以多次执行各个工作流程，有利于更好地理解需求、设计出合理的系统架构，并最终交付一系列渐趋完善的成果。可以说，迭代是一次完整地经过所有工作流程的过程。
基于统一软件开发过程模型所构造的软件系统，是由软件构件建造而成的。这些软件构件定义了明确的接口，相互连接成整个系统。在构造软件系统时，RUP 采用架构优先的策略。软件架构概念包含了系统中最重要的静态结构和动态特征，架构体现了系统的总体设计。架构优先开发的原则是RUP开发过程中至关重要的主题。
统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。

2.2.8 敏捷模型

敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。
敏捷开发开始于“敏捷软件开发宣言”。在2001年2月，17位软件开发方法学家在美国犹他州召开了长达两天的会议，制订并签署了“敏捷软件开发宣言”，该宣言给出了4个价值观。
（1）个体与交互高于过程和工具
（2）可运行软件高于详尽的文档
（3）与客户协作高于合同（契约）谈判
（4）对变更及时响应高于遵循计划
特点：
敏捷模型避免了传统的重量级软件开发过程复杂、文档繁琐和对变化的适应性弱等弊端，强调软件开发过程中团队成员之间的交流、过程的简洁性、用户反馈、对所作决定的信心以及人性化的特征。
敏捷模型包括多种实践方法，比如
◆极限编程（eXtreme Programming，XP）
◆自适应软件开发（Adaptive Software Development，ASD）
◆动态系统开发方法（Dynamic System Development Method，DSDM）、ScrumCyrstal
◆特征驱动开发（Feature Driven Development，FDD）等
下面介绍极限编程的相关内容
极限编程（eXtreme Programming，xP）是一种实践性较强的规范化的软件开发方法，它强调用户需求和团队工作。利用极限编程方法进行软件开发实践的工程师，即使在开发周期的末期，也可以很快地响应用户需求。在团队工作中，项目经理、用户以及开发人员都有责任为提高软件产品的质量而努力。XP特别适用于软件需求模糊且容易改变、开发团队人数少于10人、开发地点集中（比如一个办公室）的场合。
极限编程包含了一组相互作用和相互影响的规则和实践。在项目计划阶段，需要建立合理和简洁的用户故事。在设计系统的体系架构时，可以采用CRC （Class，Responsibility，Collaboration）卡促使团队成员共同努力。代码的质量在极限编程项目中非常重要。为了保证代码的质量，可以采用结对编程以及在编码之前构造测试用例等措施。在测试方面，开发人员有责任向用户证明代码的正确性，而不是由用户来查找代码的缺陷。合理的测试用例及较高的测试覆盖率是极限编程项目测试所追求的目标。

XP方法的开发过程模型，分为5个阶段探索阶段、计划阶段、迭代到发布阶段、产品化阶段和维护阶段。XP中的各阶段之间并没有明显的界限，各个阶段之间常常存在往复，每个阶段的持续时间也随项目的不同而有所变化，比如计划阶段可能只需几个小时即可完成。

2.2.9几种模型之间的关系

瀑布模型与RUP模型之间的关系

在宏观上，瀑布模型是静态模型，RUP模型是动态模型。RUP模型的每一次迭代，实际上都需要执行一次瀑布模型，都要经历先启、细化、构建、产品化这4个阶段，完成瀑布模型的整个过程。
在微观上，瀑布模型与RUP模型都是动态模型。瀑布模型与RUP模型在每一个开发阶段（先启、细化、构建、产品化）的内部，都需要有一个小小的迭代过程，只有进行这样的迭代，开发阶段才能做得更好。
瀑布模型中有RUP模型，反过来，RUP模型中也有瀑布模型。
2. 瀑布模型与增量模型之间的关系
增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，一个模块接着一个模块地进行开发，直到开发完所有的模块。
在开发每个模块时，通常都是采用瀑布模型，从分析、设计、编码和测试这几个阶段进行开发。所以，增量模型中有瀑布模型，即宏观上是增量模型，微观上是瀑布模型。
增量模型也体现了迭代思想，每增加一个模块，就进行一次迭代，执行一次瀑布模型，所以，增量模型本质上是迭代的。
3. 瀑布模型与快速原型模型之间的关系
快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，在此基础上之后的每一次迭代，都可能会用到瀑布模型。
快速原型模型中不但包含了迭代模型的思想，而且包含了瀑布模型的思想。
4. 瀑布模型与螺旋模型之间的关系
螺旋模型是瀑布模型和快速原型模型的结合，快速原型模型是原型模型的简化，原型模型又是迭代模型和瀑布模型的组合，这些模型之间是相互依存的、彼此有关的。
螺旋模型每一次顺时针方向旋转，相当于顺时针方向迭代一次，都是走完一次瀑布模型，这就是瀑布模型与螺旋模型之间的关系。实际上，瀑布模型与喷泉模型也有关系。

【补充】选择软件过程模型

各种软件过程模型反映了软件生命周期表现形式的多样性。在生命周期的不同阶段也可采用不同的软件过程模型。在具体的软件开发过程中，可以选择某种软件过程模型，按照某种开发方法，使用相应的工具进行软件开发。
在选择软件过程模型时需要考虑以下几点∶
①符合软件自身的特性，如规模、成本和复杂性等
②满足软件开发进度的要求
③对软件开发的风险进行预防和控制
④具有计算机辅助工具的支持
⑤与用户和软件开发人员的知识和技能相匹配
⑥有利于软件开发的管理和控制
一般来说，结构化方法和面向数据结构方法可采用瀑布模型或增量模型进行软件开发而面向对象方法可采用快速原型模型、喷泉模型或RUP模型进行软件开发。
在实际的软件开发过程中，选择软件过程模型并非是一成不变的，有时还需要针对具体的目标要求进行裁剪、修改等，从而构成完全适合开发目标要求的软件过程模型。
现实中的软件系统有各种各样，软件开发方式也千差万别。对同一个问题，不同的开发组织可能选择不同的开发模型（过程模型）去解决，开发出的软件系统也不可能完全一样，但是其基本目标都是一致的，即应该满足用户的基本功能需求，否则，再好的软件系统也是没有意义的。