软件工程基础知识-CSDN博客

为什么80%的码农都做不了架构师？>>>

1、软件工程概述

软件工程是指应用计算机科学、数学及管理学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

计算机软件是指计算机系统中的程序及其文档。

按照软件的应用领域，可以将计算机软件分为7大类：

系统软件：服务于其他程序的程序
应用软件：解决特定业务需要的独立应用程序
工程/科学软件：带有数值计算算法特征的软件
嵌入式软件
产品线软件
Web应用软件
人工智能软件
开放计算
网络资源
开源软件

2、软件工程基本原理

2.1 用分阶段的生命周期计划严格管理

这条原理意味着应该把软件生命周期划分为若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。计划分为：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划

2.2 坚持进行阶段评审

有统计结果显示，大部分错误是在编码之前造成的。设计错误占软件错误的63%，编码错误仅占37%，而且错误发现与改正得越晚，所需付出的代价越高。因此，在每个阶段都应进行严格的评审，以便尽早发现在软件开发过程中所犯的错误。

2.3实现严格的产品控制

在软件开发过程中不应随意改变需求，因为改变一项需求需要付出较高的代价。但是，在软件开发过程中改变需求是不可避免的，这就需要采用科学的产品控制技术来顺应这种要求。在需求改变时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。基准配置又称为基线配置，它是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。

2.4 采用现代程序设计技术

2.5 结果应能清楚的审查

2.6 开发小组的人员应少而精

2.7 承认不断改进软件工程实践的必要性

3、软件生存周期

通常，软件生存周期包括可行性分析与项目计划、需求分析、设计（概要设计与详细设计）、编码、测试、运维等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。

3.1 可行性分析与项目开发计划

确定软件的开发目标及其可行性。

产生文档：可行性分析与项目开发计划。

该阶段参与人：用户、项目负责人和系统分析师。

3.2 需求分析

准确确定软件系统必须要做什么，确定软件的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。

产生文档：软件需求说明书。

该阶段参与人：用户、项目负责人和系统分析师。

3.3 概要设计

开发员把确定的各项功能需求转换成需要的体系结构。在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求想对应。因此，概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构是怎样的。

产生文档：概要设计说明书。

参与人：系统分析师和软件设计师

3.4 详细设计

详细设计阶段的主要任务是对每个模块完成的功能进行具体描述，要把功能描述转换为精确的、结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件规定，有些什么重复处理等，并用相应的表示工具把这些控制结构表示出来。

产生文档：详细设计文档。

参与人：软件设计师和程序员。

3.5 编码

编程实现

3.6 测试

测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检查软件的各个组成部分。

3.7 维护

软件维护是软件生存周期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段。

4、软件过程

软件过程有3个含义：一个是个体含义：即指软件产品或系统在生存周期中某一类活动的集合。二是整体含义：即指软件产品或系统在所有上述含义下的软件过程总体；三是工程含义：即指解决软件过程的工程，应用软件的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化。

4.1能力成熟度模型(CMM)

软件过程能力成熟度模型（Capability Maturity Model of Software，CMM）是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步提高。
CMM将软件过程改进分为以下5个成熟度级别

初始级（Initial）

软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用

可重复级（Repeatable）

建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复一千在同类项目中的成功。

已定义级（Defined）

管理和工程两方面的软件过程已经文档化、标准化，并综合这个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。

已管理级（Managed）

制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制

优化级（Optimized）

加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程不断持续地改进。

4.2 能力成熟度模型（CMMI）

CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程质量和工作效率。
CMMI提供了两种表示方法：阶段式模型和连续式模型

阶段式模型

阶段式模型的结构类似CMM，它关注组织成熟度。
初始的：过程不可预测且缺乏控制
已管理的：过程为项目服务
已定义的：过程为组织服务
定量管理的：过程已度量和控制
优化的：集中于过程改进

连续式模型

连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（CL）。CMMI中包括6个过程执行能力等级，登记号0~5.
CL0（未完成的）:过程域未执行或未得到CL1中定义的所有目标
CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标
CL2（已管理的）：其共性目标集中于已管理的过程的制度化
CL3（已定义的）：其共性目标集中于已定义的过程的制度化。
CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化
CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户要求的改变和持续改进计划的过程域的功效

5、统一过程(UP)

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。迭代的意思是将整个软件开发项目划分为许多小的“袖珍项目”，每个“袖珍项目”都包含正常项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。
统一过程定义了4个阶段
1）起始阶段（inception phase）
起始阶段专注于项目的初创活动，产生的主要工作产品有构想文档、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划、业务模型以及一个或多个原型。
2）精华阶段（elaboration phase）
精华阶段在理解了最初的领域范围之后进行需求分析和架构演进，产生的主要工作产品有用例模型、补充需求（非功能性需求）、分析模型、软件体系结构描述、可执行的软件体系结构原型、初步的设计模型、修订的风险列表、项目计划以及初始用户手册
3）构建阶段（construction phase）
构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）
4）移交阶段（transition phase）
移交阶段关注于软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、测试报告和综合用户反馈。

6、软件过程模型

软件过程模型也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构建的开发模型和形式化方法模型等。

6.1 瀑布型模型（Waterfall Model）

瀑布型模型将软件生存周期中的各个活动规定为依线性顺序链接的若干阶段的模型，包括需求分析、设计、编码、测试、运行和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级降落。它是以文档作为驱动、适合于软件需求很明确的软件项目。
瀑布模型假设，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生!

6.2 V模型

V模型是瀑布模型的变种。V模型描述了质量保证活动和沟通、建模相关活动及早期构建相关的活动之间的关系。随着软件团队工作沿着左侧不知后详细推荐，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤乡下推进过程中所形成的每个模型。V模型提供了一种将验证确认活动应用于于早期软件工程工作中的方法。

6.3 瀑布型模型的优缺点

瀑布型模型的优点是，容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。不足之处是，客户必须完整、正确和清晰地表达他们的需要；在开的两个或三个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；知道项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发周期超出预算。

6.4 增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的可发布的增量。当时用增量模型时，第一个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，知道产生了最终的完善产品。
增量模型强调每一个增量均发布一个可操作的产品。
增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点，并且它还有以下优点：
第一个可交付版本所需要的成本和时间较少；
开发由增量表示的小系统所承担的风险小；
由于很快发布了第一个版本，因此可以减少用户需求的变更；
运行增量投资，即在项目开始时，可以进队一个或两个增量投资。
增量模型的不足之处：
如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；
如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；
管理产生的成本，进度和配置的复杂性可能会超出组织的能力。

6.5 演化模型（Evolutionary Model）

在开发过程中，常常会面临以下情形：商业和产品的需求经常发生变化，直接导致最终产品难以实现；严格的交付时间使得开发团队不可能圆满的完成软件产品，但是必须交付功能有限的版本以及应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种应对不断演变的软件产品的过程模型。
演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型。

6.5.1 原型模型（Prototype Model）

原型是预期系统的一个可执行的版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。
原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些意见可在下一轮中对原型进行改进。
根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化性模型3种。
探索型原型的目的是弄清楚目标的要求，确定所希望的特性，并探讨多种方案的可行性。
实验型原型的目的是验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。
演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终目标系统。

6.5.2 螺旋模型（Spiral Model）

螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，每个螺旋周期分为
1）制定计划。确定软件的目标，选定实施方案，明确项目开发的限制条件
2）风险分析。分析所选方案，识别风险，消除风险
3）实施工程。实施软件开发，验证阶段性产品
4）用户评估。评价开发工作，提出修正建议，建立下一个周期的开发计划
螺旋模型强调风险分析，高明星特别适用于庞大、复杂并且具有高风险的系统。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的使用能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。

6.6 喷泉模型（Water Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适用于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。
喷泉模型使开发过程中具有迭代性和无间隙性。
迭代性：模型中中的开发活动常常是需要重复多次，在迭代过程中逐渐完善软件系统
无间隙性：在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它允许各开发活动交叉、迭代地进行。

6.7 基于构件的开发模型（Component-based Development Model）

基于构件的开发是指利用预先包装的构件来构造应用系统。基于构件的开发模型具有许多螺旋型模型的特点，它本质上是演化模型，需要以迭代的方式构建软件。不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。

6.8 形式化方法模型

形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。

7 软件开发方法

软件开发方法是一种使用早已经定义好的技术集及符号表示习惯来阻止软件生产的过程。

7.1 结构化方法

结构化方法由结构化分析、结构化设计、结构化程序设计构成，它是一种面向数据流的开发方法

结构化方法总的指导思想是自顶向下、逐层分解，它的基本原则是功能的分解与抽象。

7.2 Jackson方法

Jackson方法是一种面向数据结构的开发方法。Jackson方法以数据结构为驱动，适用于小规模的项目。JSD方法是一个完成的系统开发方法。首先建立显示世界的模型，再确定系统的功能需求，对需求的描述特别强调操作之间的时序性。它是以事件为驱动的，是一种基于进程的开发方法，所以适用于时序特点较强的系统，包括数据处理系统和一些实时控制系统