软件工程基础知识

最新推荐文章于 2024-08-25 11:37:56 发布

那夜的星空分外清澈

最新推荐文章于 2024-08-25 11:37:56 发布

阅读量942

点赞数

分类专栏：计算机基础

本文链接：https://blog.csdn.net/u011374318/article/details/89302282

版权

计算机基础专栏收录该内容

7 篇文章 0 订阅

订阅专栏

软件工程基础知识

概述

20世纪60年代中期，人们把在软件开发和维护过程中所遇到的各种问题称为“软件危机”，为应对该危机，1968年在德国召开的 NATO（North Atlantic Treaty Organization，北大西洋公约组织）会议上首次提出了“软件工程”这个名词，希望用工程化的原则和方法来克服软件危机。

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

程序是计算任务的处理对象和处理规则的描述。

计算任务是指任何以计算机为处理工具的任务。

处理对象是数据或信息，如数字、图像、文字和声音等。

处理规则是指处理动作和步骤。

文档是为了便于了解程序所需的阐述性资料。

按照软件的应用领域，将计算机软件分为七大类：系统软件、应用软件、工程/科学软件、嵌入式软件、产品线软件、Web应用软件、人工智能软件。

软件工程基本原理

用分阶段的生命周期计划严格管理
- 项目概要计划
- 里程碑计划
- 项目控制计划
- 验证计划
- 运行维护计划
坚持进行阶段评审
实现严格的产品控制
采用现代程序设计技术
结果应能清楚的审查
开发小组的人员应少而精
承认不断改进软件工程实践的必要性

软件生存周期

可行性分析和项目开发计划，该阶段要确定解决的问题是什么，有何可行办法，费用的多少，需要多少资源、时间等，产生可行性分析报告和项目开发计划。
需求分析，该阶段要明确软件系统的功能、性能、数据和界面等要求，从而确定软件系统的逻辑模型，该产生软件需求说明书。
概要设计，该阶段要将各个需求功能转换为需要的体系结构，各个功能模块与需求对应，要确定模块内的层次结构，模块间的调用关系，还要确定系统要存储什么数据以及数据是何种结构，和数据间存在何种关系，产生概要设计说明书。
详细设计，该阶段主要任务是对每个模块完成的功能进行具体描述，将功能描述转变为精确的、结构化的过程描述。有软件设计师和程序员参与，产生详细设计文档。
编码，将每个模块用特定的程序设计语言进行实现，产生源程序清单。
测试，由其他部门或单位的软件设计师或系统分析师对软件的各个组成部分进行测试，产生软件测试计划、测试用例和软件测试报告等主要文档。
维护，软件生命周期中时间最长的阶段，软件投入正式使用后，即进入维护阶段，可以持续几年甚至几十年。

软件过程

在开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）称为软件过程。过程是活的的集合，活动是任务的集合。

能力成熟度模型（CMM）

软件过程能力成熟度模型（Capability Maturity Model of Software，CMM），其研究目的是提供一种评价软件承接方能力的方法，同时它可以帮助软件组织改进其软件过程。

CMM 将软件过程改进分为以下 5 个成熟度级别：
- 初始级
- 可重复级
- 已定义级
- 已管理级
- 优化级
能力成熟度模型（CMMI）

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

阶段式模型类似于 CMM ，关注组织的成熟度。
- 初始的：过程不可预测且缺乏控制。
- 已管理的：过程为项目服务。
- 已定义的：过程为组织服务。
- 定量管理的：过程已度量和控制。
- 优化的：集中于过程改进。
连续式模型关注每个过程域的能力，该能力分为 0～5 六个等级（Capability Level，CL）。
统一过程（UP）

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由 UML 方法和工具支持。

统一过程定义了 4 个技术阶段及其制品：
- 起始阶段
- 精化阶段
- 构建阶段
- 移交阶段

软件过程模型

软件过程模型也称为软件开发模型，是软件开发全部过程、活动和任务的结构框架。

瀑布模型（waterfall Model）

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，是以文档作为驱动，适用于软件需求很明确的软件项目的模型。

瀑布模型的一个变体 V 型模型，提供了一种将验证确认活动应用于早期软件工程工作中的方法。

优点：容易理解，管理成本低，强调阶段性早期计划、需求调查和产品测试。

缺点：进度状态难评估、系统能力只能在项目结束后演示、需求和设计错误往往在项目后期才能发现，项目风险控制能力弱，从而造成项目延期以及预算超支。

增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。

优点：作为瀑布模型的变体，有其所有优点，另外，每个增量单独交付所需成本和时间少，所承担风险不大，用户的变更也会减少，项目开始时的投资减少。

缺点：用户需求未进行合理规划，那么可能会导致增量的不稳定，迫使其重新开发、发布，使得管理成本，项目进度和配置复杂性增大而超出组织的能力。

演化模型（Evolutionary Model）

软件会随着时间的推移而演化，需要一种过程模型来应对这种不断演变的软件产品。演化模型时迭代的过程模型，适用于对软件需求缺乏准确认识的情形。

原型模型（Prototype Model）

鉴于瀑布模型不适应需求的不确定性和变化，故使用快速原型（rapid prototype）这种新的开发方法，通过沟通，确定软件的总体目标，快速构建一个原型，并交付给用户使用，进而收集反馈意见，在下一轮中对原型进行改进。
- 探索型原型：为了确认目标要求和希望特性，探讨方案的可行性。
- 实验型原型：为了验证方案或算法的合理性，在大规模开发和实现前，考查方案是否合适、规格说明是否可靠等。
- 演化型原型：将原型作为目标系统的一部分，逐步改进原型直至演化为最终的目标系统。
螺旋模型（Spiral Model）

螺旋模型将瀑布模型和演化模型相结合，并加入风险分析，通过多个螺旋周期开发多个原型，来适应庞大、复杂并且具有高风险的系统开发。

每个螺旋周期都和瀑布模型大致相符，分为 4 个工作步骤：
- 制定计划
- 风险分析
- 实施工程
- 用户评估
该模型强调风险分析，要求开发人员具有相当丰富的风险评估经验和专门的知识。但是，要注意过多的迭代次数会增加开发成本，延迟交付时间。

喷泉模型（Water Fountain Model）

喷泉模型时一种以用户需求为动力，以对象作为驱动的模型，适用于面向对象的开发方法。

这种开发方法使得开发活动可以重复多次进行且各个阶段不在有明显边界，提高了开发效率，节省了时间，但是也造成了开发人员的臃肿，项目管理的难度加大。

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

基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品（Commercial Off-The-Shelf，COTS）软件构件。

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

形式化方法模型（Formal Methods Model）

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

软件开发方法

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

结构化方法：由结构化分析、结构化设计、结构化程序设计构成，是一种面向数据流的开发方法。
Jackson 方法：是一种面向数据结构的开发方法。
- 一个问题的数据结构和处理该数据结构的控制结构很相似，根据这一思想，形成了最初的 JSP（Jackson Structure Programming）方法。首先描述问题的输入/输出数据结构，分析其对应性，推出程序结构，从而给出问题的软件过程描述。JSP 方法以数据结构为驱动，适用于小规模的项目。
- 当输入和输出数据结构之间没有对应关系时，JSP 不再适用，那么使用其扩充后的 JSD（Jackson System Development）方法。JSD 方法是一种事件驱动，基于进程的开发方法，适用于时序特点较强的系统。
原型方法：关键在于初始原型的开发以及之后的改进，适用于用户需求不清、需求变更频繁的情况。且系统规模不宜过大，不宜过于复杂。
面向对象方法：客观世界由许多具体的事物、事件、概念和规则组成，这些都可以看作对象。面向对象方法正是以对象作为最基本的元素，它也是分析问题、解决问题的核心。面向对象方法包括面向对象分析、面向对象设计和面向对象实现。统一建模语言（Unified Modeling Language，UML）是面向对象的标准建模语言。
敏捷方法：通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。
- 极限编程（XP），由价值观、原则、实践和行为 4 个部分组成。
- 水晶法（Crystal），水晶法认为每个不同的项目都需要一套不同的策略、约定和方法论。
- 并列争求法（Scrum），每 30 天进行一次迭代，多个自治小组并行递增实现产品。
- 自适应软件开发（ASD），包含 6 个基本原则。

软件工具与软件开发环境

计算机辅助软件工程（Computer Aided Software Engineering，CASE），是指使用计算机及相关的软件工具辅助软件开发、维护、管理等过程中各项活动的实施，以确保这些活动能高效、高质量的进行。

软件工具

用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件称为软件工具。

软件开发工具
- 需求分析工具
- 设计工具
- 编码和排错工具
- 测试工具
软件维护工具

用来辅助维护人员对软件代码及其文档进行各种维护活动的软件称为软件维护工具。
- 版本控制工具
- 文档分析工具
- 开发信息库工具
- 逆向工程工具
- 再工程工具
软件管理和软件支持工具

辅助管理人员和软件支持人员进行管理活动和支持活动，从而确保软件高质量完成的软件称为软件管理和软件支持工具。
- 项目管理工具
- 配置管理工具
- 软件评价工具

软件开发环境

软件开发环境（Software Development Environment）指支持软件产品开发的软件系统，由软件工具集和环境集成机制构成。

工具集：用于支持软件开发的相关过程、活动和任务。

环境集成机制包含如下集成：

数据集成
界面集成
控制集成
方法和过程集成
平台基础

软件开发环境的特征如下：

环境的服务是集成的
环境应支持小组工作方式，并为其提供配置管理
环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、测试、调试和文档等。

集成型开发环境是一种把支持多种软件开发方法和开发模型的软件工具集成在一起的软件开发环境，这种环境应该具有开放性和可裁剪性。

软件项目管理

软件项目管理是指软件生成周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内有效地利用人力、资源、技术和工具，使软件系统和软件产品按原定计划和质量要求如期完成。

软件项目管理设计的范围

有效的软件项目管理集中在 4 个 P 上，即人员（Person）、产品（Product）、过程（Procedure）和项目（Project）。

人员：项目管理人员、高级管理人员、开发人员、客户、最终用户。
产品：产品的目标和范围必须是无二义的和可理解的，包含项目环境、信息目标、功能和性能等相关问题。
过程：基于软件工程的过程，通常将项目分解为任务、子任务等，对这些过程进行控制。
项目：明确目标及过程、保持动力、跟踪进展、做出明智的决策、进行事后分析。

软件项目估算

常用的估算方法：

基于已完成的类似项目进行估算
基于分解技术进行估算
基于经验估算模型的估算

成本估算方法
- 自顶向下估算方法
- 自底向上估算方法
- 差别估算方法
- 专家估算法
- 类推估算法
- 算式估算法
COCOMO 估算模型
- 基本 COCOMO 模型，是一个静态单变量模型，对整个软件系统的估算公式如下：
  $E=a(L)^b$
  $D=c(L)^d$
  - L 是项目源代码行估算值，单位：千行
  - E 表示工作量，单位：人月
  - D 表示开发时间，单位：月
  - a、b、c、d 是常数
- 中级 COCOMO 模型，是一个静态多变量模型，将软件系统模型分为系统和部件两个层次，部件构成系统。该模型基于 COCOMO 模型，并考虑 15 种影响软件工作量的因素，通过工作量调节因子（EAF）修正对工作量的估算，公式如下：
  
  $E=a(L)^bEAF$
- 详细 COCOMO 模型，将软件系统模型分为系统、子系统和模块 3 个层次，在中级模型基础上，进一步考虑了需求分析、软件设计等每一步的成本驱动属性的影响。
COCOMOⅡ 模型

COCOMOⅡ 模型由最初的 COCOMO 模型演化而来，同样是一种层次结构的估算模型，分为 3 个阶段性模型。
- 应用组装模型
- 早期设计阶段模
- 体系结构阶段模型
Putnam 估算模型

Putnam 模型是一种动态多变量模型，其假设在软件开发的整个生存周期中工作量有特定的分布。
$L=C_kE^{1/3}t_d^{4/3}$
- L 表示源程序代码行数（LOC，Length Of Code）
- td 表示开发持续时间（年）
- E 表示软件开发和维护在整个生存期所花费的工作量（人年）
- kd 表示技术状态常数，该值依赖于开发环境（2000<8000<11000）

进度管理

软件项目进度管理的目的是确保软件项目在规定的时间内按期完成，这个时间可以是确定的，也可以是大致的年限。

进度管理的基本原则
- 划分，基于产品和过程的分解，将项目划分为若干个活动和任务。
- 相互依赖性，划分后的任务间的依赖关系必须是明确的。
- 时间分配，每个任务需要分配合适数量的工作单位（人天）。
- 工作量确认，任意时间段中的人员数量不能超过项目团队中的总人数。
- 确认责任，每个任务应当指定负责人。
- 明确输出结果，每个任务必须要有一个明确的输出结果。
- 确定里程碑，每个任务（组）都应该和一个项目的里程碑相关联。
进度安排

使用图示的方法来表示各项任务的进度，及其间的依赖关系，从而监控项目的实际进展情况。

在图示中明确标明：
- 各个任务的计划开始时间和完成时间。
- 各个任务的完成标志。
- 各个任务与参与工作的人数，各个任务与工作量之间的衔接情况。
- 各个任务需要的物理资源和数据资源。
进度安排的图形描述方法：
- 甘特（Gantt）图，一种简单的水平条形图，以日历为基准描述项目任务。能描述各个任务的开始和结束时间，进展情况以及各个任务间的并行性。但是，无法反映各个任务间的依赖关系。
- 项目计划评审技术（Program Evaluation & Review Technique，PERT）图，是一个有向图，箭头表示任务，结点称为事件。当所有流入该结点的任务都结束后，该事件才出现，而流出该结点的任务才可以开始。事件本身不会消耗时间和资源，其拥有一个事件号、最早出现时刻和最晚出现时刻。每个任务除了所需时间外，还有一个松弛时间，另外，为了表示任务间的关系，还可以使用虚线箭头表示空任务。PERT 图能反映任务的开始、结束时间及任务间关系，但是不能反映任务之间的并行关系。

软件项目的组织

软件项目组织原则：尽早落实责任、减少交流接口、权责均衡。

组织结构的模式
- 按项目划分的模式
- 按职能划分的模式
- 矩阵模式（上述两种模式的组合）
程序设计小组的组织方式
- 主程序员制小组
- 民主制小组
- 层次式小组

软件质量管理

软件质量管理是指反映软件系统或软件产品满足规定或隐含需求的能力的特征和特性全体，由质量保证、质量规划和质量控制 3 个主要活动构成。

软件质量特性

ISO/IEC 9126 软件质量模型分为质量特性、质量子特性和度量指标三个层次。
- 功能性：适合性、准确性、互用性、依从性、安全性
- 可靠性：成熟性、容错性、易恢复性
- 易使用性：易理解性、易学性、易操作性
- 效率：时间特性、资源特性
- 可维护性：易分析性、易改变性、稳定性、易测试性
- 可移植性：适应性、易安装性、一致性、易替换性
Mc Call 软件质量模型从软件产品的运行、修正和转移 3 个方面确定了 11 个质量特性。其同样是三层模型框架，分为质量特性、评价准则和度量指标。
- 产品运行：正确性、可靠性、易使用性、效率、完整性
- 产品修正：可维护性、灵活性、可测试性
- 产品转移：可移植性、复用性、互用性
软件质量保证

为了保证软件系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其强调下面 3 个要点。
- 软件必须满足用户规定的需求
- 软件应遵循规定标准所定义的一系列开发准则
- 软件应满足某些隐含需求
软件质量保证包括了与以下 7 个主要活动相关的各种任务。
- 应用技术方法
- 进行正式的技术评审
- 测试软件
- 标准的实施
- 控制变更
- 度量
- 记录保存和报告
软件评审

设计质量：设计的规格说明书符合用户的要求。

程序质量：程序安装设计的规格说明所规定的情况正确执行。

设计质量评审的对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明，以及在软件概要设计阶段产生的软件概要设计说明书等。

程序质量评审是对软件本身的结构、与运行环境的接口以及变更带来的影响而进行的评审活动。
软件容错技术

软件容错技术，指规定功能的软件能够屏蔽自身错误，或在错误发生后能够进行恢复或仍能够完成预期功能。

实现容错，主要是冗余技术，通过提供多余的资源来提高系统的可靠性。
- 结构冗余：静态冗余、动态冗余、混合冗余
- 信息冗余：在待运算或传输的信息中添加一部分信息
- 时间冗余：重复执行指令或程序来消除瞬时错误带来的影响
- 冗余附加技术：为实现上述冗余技术所需的资源和技术