【软件工程】重要知识点

一、软件工程概述

软件工程的诞生

1968年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，讨论软件危机问题。在这次会议上正式提出并使用了“软件工程”这个名词，一门新兴的工程学科就此诞生了。

软件危机

① 对软件开发成本和进度的估计常常很不准确。

② 用户对“已完成的”软件系统不满意的现象经常发生。

③ 软件产品的质量往往靠不住。

④ 软件常常是不可维护的。

⑤ 软件通常没有适当的文档资料。

⑥ 软件成本在计算机系统总成本中所占的比例逐年上升。

⑦ 软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。

产生原因：一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。

重要的原因之一：在软件开发的不同阶段进行修改需要付出的代价是很不相同的。在早期引入变动，涉及的面较少，因而代价也比较低；在开发的中期，软件配置的许多成分已经完成，引入一个变动要对所有已完成的配置成分都做相应的修改，不仅工作量大，而且逻辑上也更复杂，因此付出的代价剧增；在软件“已经完成”时再引入变动，当然需要付出更高的代价。

软件是程序、数据及相关文档的完整集合。

1983 年 IEEE（电气和电子工程师协会）为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

七条基本原理

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

②坚持进行阶段评审

③实行严格的产品控制

④采用现代程序设计技术

⑤结果应能清楚地审查

⑥开发小组的人员应该少而精

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

十大领域

①软件需求（software requirements）

②软件设计（software design）

③软件构建（software construction）

④软件测试（software testing）

⑤软件维护（software maintenance）

⑥软件配置管理（software configuration management）

⑦软件工程管理（software engineering management）

⑧软件工程过程（software engineering process）

⑨软件工程工具和方法（software engineering tools and methods）

⑩软件质量（software quality）

问题

一、什么是软件？有何特点？

目前对软件比较公认的解释是：软件是程序，支持程序运行的数据以及与程序有关的文档的完整集合。

程序：按事先设计的功能和性能要求执行的指令序列
文档：与程序开发，维护和使用有关的图文材料
- 文档分为三大类：开发文档、用户文档、管理文档
- 文档的作用：记录、通信和交流、管理和维护
数据：使程序能正常操纵信息的数据结构

软件的特点：

软件是逻辑的，而不是物理的产品
软件是由开发化或者工程化形成的，没有明显的制造过程
软件在运行和使用期间，不存在硬件那样的磨损和老化问题，但存在退化问题，所以需要维护软件
- 软件的故障率是由于软件修改呈现锯齿状，因为软件修改可能带来新的错误
大多数软件是自定的，软件开发尚未完全摆脱手工的方式
软件成本相当昂贵
软件本身比较复杂

二、什么是软件危机？如何解决？

软件危机（Software Crisis），所谓软件危机，就是指在软件开发和软件维护过程中所存在的一系列严重问题。

软件危机的表现：

软件开发没有计划性
对于软件需求的获取不充分
缺乏良好的软件质量的评测手段
软件的可复用性、可维护性不如人意
软件开发过程没有“规范化”
软件开发的人力成本持续上升
缺乏自动化的软件开发技术

解决软件危机：

基于软件危机产生的角度，应该从两个方面来解决软件危机：软件工程技术和软件工程管理

管理层面上考虑：应当注意推广和使用在实践中总结出来的开发软件的成功的技术和方法，并且探索更好的、更有效的技术和方法，注意积累软件开发过程中的经验数据财富，逐步消除在计算机系统早期发展阶段形成的一些错误概念和做法
从技术角度考虑：应当开发和使用更好的软件开发工具，提高软件开发效率和开发工作过程的规范化程度
- 目前广为使用的统一建模语言(UML)、各种配置管理工具、缺陷管理工具和自动测试工具都在软件工程活动中发挥了很好的作用

三、软件工程是一门什么学科？

研究“大型”软件开发和维护的技术、方法、工具、环境和管理的工程学科。

软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明是正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它。

软件工程三要素：工具、方法、过程

软件工程的内容：软件开发的技术、软件开发的管理、软件过程管理技术

四、什么是软件工程方法学？

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称为范型

包括传统方法、面向对象的方法、形式化方法

五、什么是软件的生存期？

软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程。

划分软件周期的目的：给每个阶段赋予确定而有限的任务，能够简化每一步的工作内容，使软件复杂性变得较易控制和管理

软件生存期的三个阶段、六个时期：

定义时期
- 软件计划（可行性研究）
- 需求分析
开发时期
- 软件设计
- 实现（编码）
- 测试
使用和维护时期
- 运行维护

六、软件工具包含哪些？

软件工具是指能支持软件生存周期中的某一阶段（如软件计划、需求分析、软件设计、编码、测试、运行维护等）的需要而使用的软件工具。

一般按照软件过程的活动来分类：①支持软件开发过程的工具；②支持软件维护过程的工具；③支持软件管理过程和支持过程的工具

二、软件过程

软件工程过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

当开发产品或构建系统时，遵循一系列可预测的步骤（路线图）是非常重要的，它有助于及时交付高质量的产品；其中所遵循的路线图就是软件过程。

软件过程的任务

软件过程贯穿软件开发的各阶段，并建立阶段里程碑（Milestones）；
管理者在软件工程过程中需要对软件开发的质量、进度、成本进行评估、管理和控制；
技术人员在软件过程中需采用相应的方法和工具生成软件工程产品，如模型、文档、数据、报告、表格等

软件过程的组成要素

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

活动(activity)：实现宽泛的大目标
动作(action)：阶段目标
任务(task)：关注小而明确的目标，产生实际产品

软件生命周期的基本任务

软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又可进一步划分成若干个阶段。

软件定义：问题定义、需求分析、可行性研究

软件开发：概要设计、详细设计、编码和单元测试、综合测试

运行维护时期的主要任务是使软件持久地满足用户的需要

问题定义阶段必须回答的关键问题是：“要解决的问题是什么”。可行性研究阶段要回答的关键问题是：“上一个阶段所确定的问题是否有行得通的解决办法”。需求分析的任务仍然不是具体地解决客户的问题，而是准确地回答“目标系统必须做什么”这个问题。概要设计阶段的基本任务是：概括地回答“怎样实现目标系统？”概要设计又称为初步设计、逻辑设计、高层设计或总体设计。详细设计阶段的任务就是把解法具体化，也就是回答“应该怎样具体地实现这个系统”这个关键问题。编码和单元测试阶段的关键任务是写出正确的，容易理解、容易维护的程序模块。综合测试阶段的关键任务是通过各种类型的测试（及相应的调试）使软件达到预定的要求。软件维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。

我国国家标准《计算机软件开发规范》（GB8566——88）也把软件生命周期划分成8个阶段，这些阶段是：可行性研究与计划，需求分析，概要设计，详细设计，实现，组装测试，确认测试，使用和维护。其中，实现阶段即是编码与单元测试阶段，组装测试即是集成测试，确认测试即是验收测试。

问题

一、软件过程的含义？

当开发产品或构建系统时，遵循一系列可预测的步骤（路线图）是非常重要的，它有助于及时交付高质量的产品；其中所遵循的路线图就是软件过程

二、软件过程中有哪些共同的、基本的活动？

一个通用的软件工程过程框架通常会包含以下5个基本的框架活动：
- 沟通：在技术工作开始前，先和利益相关者进行沟通与协作，以理解项目目标，并收集需求
- 策划：制定项目计划，包括需要执行的技术任务、可能的风险、资源需求、工作产品、工作进度计划等
- 建模：构思软件的体系结构、构件如何结合等
- 构建：包括编码和测试
- 部署：交付全部软件或部分增量，由用户使用并反馈意见。

三、如何建立过程模型？什么是过程模式？

软件过程常使用“过程模型”来表述
- 一个通用的软件过程模型，包括以下工作：
- 1. 选择一种过程流。
  2. 定义框架活动：针对给定的问题、开发人员和利益相关者，制定每个框架活动中需要完成哪些动作。
    - 例如在沟通活动中，可能包括启动、需求获取、需求系统、谈判、规格说明、确认等动作。
  3. 明确任务集：为每个动作制定所需要的任务集
    - 任务集由工作任务、相关工作产品、质量保证点和项目里程碑等部分组成
    - 对于不同的软件项目，即便是相同的动作，确定的任务集也可能不一样。
  4. 编写或查找过程模式。
开发团队在软件过程里会遇到很多问题，如果团队能得到已有的经过验证的解决方案，将有助于快速地分析和解决问题。
因此在软件过程中，最好能将遇到的过程问题、问题环境、解决方案等记录下来，形成过程模式(process pattern)。

四、惯用（传统）过程模型

软件工程发展到现在，已经出现了很多不同的过程模型，其中有一些可归属为“传统过程模型”
传统过程模型以秩序和一致性作为主要问题，规定了一整套的过程元素，包括：过程流、框架活动、软件工程动作、任务、工作产品、质量保证、变更控制机制等。
常见的几种传统过程模型：瀑布模型、V模型、增量过程模型、原型开发模型、螺旋模型、协同模型
瀑布模型：前提：需求稳定而明确、由文档驱动、前一阶段的结果是后一阶段的输入、推迟了软件实现、现实开发中添加反馈机制、阶段评审和文档控制
- （1）阶段间具有顺序性和依赖性
  
  这个特点有两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。
  
  （2）推迟实现的观点
  
  （3）质量保证的观点
- V模型、W模型
增量模型：该模型先对系统最核心或最清晰的需求进行分析、设计、实现、测试，再按优先级逐步对后续需求进行上述工作，并集成到系统中，逐步形成一个完整系统
- 综合了线性、并行、演化的特征；每一个增量都提交一个可以运行的产品；适用于人手不足的情况；客户的需求可以逐步提出来；可以规避技术风险；增量粒度难以选择
原型开发：原型：模拟某种产品的原始模型（“样机”）。在获得一组基本需求后，可以先通过快速地分析和设计，构造出一个小型的软件系统原型。用户使用原型系统，开发人员根据用户反馈修改或重建系统。
- 仅包含主要功能以及重要接口，不包括系统的细节
- 强调快速，不建议过多地采用新技术
- 原型可作为一种技术，用于其它过程模型中
螺旋模型：螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点，能快速开发软件的增量版本。
- 是一种风险驱动的过程模型
- 螺旋模型沿着螺线顺时针由内而外每旋转一圈便开发出一个新的版本
- 螺旋模型并不要求每一个螺旋的产品都是可以运行的程序
- 螺旋模型不是当软件交付后就结束过程，而是应用在软件的整个生命周期中。
- 适用于大型系统和软件开发；把软件质量作为一个重要目标；把维护也看做是一种开发
喷泉模型：喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。
- 较容易地实现活动的迭代和无间隙
- 各个阶段没有明显的界限，开发人员可以同步进行开发
- 开发过程中需要大量的开发人员，因此不利于项目的管理

五、统一过程

RUP： Rational Unified Process
RUP是一个面向对象的基于web的程序开发方法论，它建立了迭代、增量的过程流，提供了演进的特性。RUP从传统软件过程中挖掘了最好的特征和性质，也可用敏捷软件开发中的许多最好的原则来实现。RUP既是一种软件过程模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中。RUP实际上是一种重量级过程，描述得非常完善和具体，特别适用于大型软件团队开发大型项目，实际应用时也可进行裁剪简化
五个阶段：起始、细化、构建、转换、生产
特点：用例驱动，以架构为核心，迭代且增量

六、敏捷软件开发

敏捷开发方法保留了软件过程中基本的框架活动：沟通、策划、建模、构建和部署，但将其缩减到一个推动项目组朝着构建和交付发展的最小任务集。因此敏捷方法也被称为轻量级方法、精简方法
敏捷开发强调：
- 开发人员和客户之间主动和持续的沟通
- 小而高度自主的项目团队
- 让客户满意和软件的早期增量发布
- 超越分析和设计（但不排斥这类活动）的发布
- 整体精简开发，并使用最小化的软件工程工作产品

七、软件能力成熟度的五个阶段：CMM1 → CMM5，从低到高

三、需求获取与结构化分析方法

软件需求的类别

功能：软件应该具有的功能
质量：软件应该具备的质量要求
约束：成本、进度、技术选型、标准和规范等要求

需求分析的目标：精确化、一致化、完全化、无冗余

需求分析任务

需求分析过程

确定利益相关者
获取和理解软件需求
描述和分析软件需求
文档化和评审需求

需求获取的主要方法基于交流

需求技术

需求导出、建模和分析

需求建模技术：问题分解、抽象、多视点、快速原型、建模语言（数据流图、统一建模语言UML）

需求描述

软件需求规格说明书SRS

需求评审

目的、要求和结果

需求评审是为了减少和避免需求分析的结果可能存在的问题以及缺陷，以及他们可能带来的严重后果

如何进行需求评审？评审的对象就是需求模型以及软件需求规格说明书

结构化分析方法

传统的分析建模方法称为结构化分析（ structured analysis，SA）方法

最有代表性的是一种面向数据流进行需求分析的方法，最初于20世纪70年代由D.Ross提出，后来又经过扩充，形成了今天的结构化分析方法的框架。

结构化分析方法是一种建模技术

功能建模

功能建模的思想就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止。

数据流图

功能模型用数据流图来描述。

数据流图的基本图形符号

数据流图的多个数据流之间的关系

环境图

环境图（context diagram）也称为顶层数据流图（或0层数据流图），它仅包括一个数据处理过程，也就是要开发的目标系统。

环境图的作用是确定系统在其环境中的位置，通过确定系统的输入和输出与外部实体的关系确定其边界。

典型的环境图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mNoPkQfy-1653638581743)(https://fastly.jsdelivr.net/gh/RealBeBetter/image/img/202205271600686.png)]

E-R图

关联数量的表示：一对一、一对多、多对多

关系的属性

行为建模

状态转换图（简称状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。

状态图中使用的主要符号

数据字典

数据字典定义中的符号

加工规格说明

决策表

四、结构化设计方法

软件设计的概念及原则

一、分而治之

分而治之是人们解决大型复杂问题时通常采用的策略。将大型复杂的问题分解为许多容易解决的小问题，原来的问题也就容易解决了
软件的体系结构设计、模块化设计都是分而治之策略的具体表现

二、模块独立性

定义: 是指软件系统中每个模块只涉及软件要求的具体的子功能, 而和软件系统中其它模块的接口是简单的。
有效的模块化使软件便于分工协作开发。
独立的模块比较容易测试和维护

模块独立性的度量准则

耦合：是模块之间的互相连接的紧密程度的度量
内聚：是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量
模块独立性比较强的模块应是高内聚低耦合的模块

耦合度排序

非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的；非直接耦合的模块独立性最强。
数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。也是较理想的耦合。
控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
公共耦合（Common Coupling）：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
内容耦合 (Content Coupling)
- 一个模块直接访问另一个模块的内部数据。
- 一个模块不通过正常入口转到另一模块内部。
- 两个模块有一部分程序代码重迭。 (只可能出现在汇编语言中）
- 一个模块有多个入口。

设计原则

尽量使用数据耦合
少用控制耦合
限制使用公共耦合（除非传递大量数据）
完全不用内容耦合

内聚度排序

偶然内聚（Coincidental Cohesion）：当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为偶然内聚模块，内聚程度最低。
逻辑内聚（Logical Cohesion）：把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪个功能。
时间内聚（Classical Cohesion）：时间内聚模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
过程内聚（Procedural Cohesion）：如果一个模块内的处理是相关的，而且必须以特定次序执行，则是过程内聚。
顺序内聚：一个模块中的处理元素和同一功能密切相关，而且这些处理必须顺序执行，而且一个成分的输出作为另一个成分的输入，则称为顺序内聚。
功能内聚 (Functional Cohesion)：一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。则称该模块为功能内聚模块。模块的所有成分对于完成单一的功能都是必须的。