软件工程知识点整理（复习用）

最新推荐文章于 2024-06-26 21:58:57 发布

懒懒哇

最新推荐文章于 2024-06-26 21:58:57 发布

阅读量5.2k

点赞数 11

分类专栏：复习

本文链接：https://blog.csdn.net/qq_22326285/article/details/110749882

版权

复习专栏收录该内容

1 篇文章 1 订阅

订阅专栏

文章目录

概述
软件过程
需求工程
设计工程
软件实现与验证
软件维护
软件项目管理

概述

1.1 什么是软件

软件 = 程序 + 数据 + 相关文档
专业化开发的软件包括
- 计算机程序
- 数据结构
- 配置文件、系统文档、用户文档

1.2 优良软件的属性

可维护性
可依赖性
有效性
可用性

1.3 工程与工程活动

共性特征：
- 大规模设计与建造
- 复杂问题与目标分解
- 团队协作与过程控制

1.4 软件危机

软件危机指的是软件发展过程中逐渐出现的一系列严重的问题。
软件工程是能够解决软件开发严重问题的有效途径

1.5 什么是软件工程

软件工程是设计软件生产各个方面的一门工程学科
方面包括：
- 软件生命周期的各个方面
- 人为因素
- 经济因素
- 法律因素
软件工程的另一种说法（IEEE【IEEE93】）：
- 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件
- 研究上述方法

1.6 软件过程与软件生命周期

软件过程是指开发或制作软件产品的一系列活动及其成果
所有的软件过程包括四个基本活动：
- 描述
- 开发
- 有效性验证
- 进化
软件生命周期是软件过程的另一种形象描述，通常包括需求定义、分析与描述、软件设计、实现、测试、维护与退役等活动。

1.7 软件工程方法

软件工程方法是软件生命周期中使用的一整套技术方法的集合，包括系统模型描述、约束规则、设计建议、过程指南等元素。
软件方法经历的四个阶段：
- 面向过程
- 面向对象
- 面向构件
- 面向服务
四个阶段软件复用程度逐渐提升，软件开发效率越来越高。

1.8 软件项目的成功要素

按时交付
不超预算
满足用户要求

1.9 职业与道德责任

软件工程师应遵循的行为准则：

保密
工作能力
知识产权
计算机滥用

软件过程

2.1 瀑布模型（顺序模型）

瀑布模型的特点和使用情况

反映了工程设计的基本思想
把一个软件过程划分成几个界限清晰的阶段，而这些阶段有严格的顺序，导致很难对用户的需求变更做出及时的调整
只适合需求非常清楚、需求变更被严格限制的情况

2.2 进化式开发模型

基本思想：通过开发系统原型和用户反复交互以明确需求，是系统在不断调整与修改中得以进化成熟。又叫做原型式开发方法
两种基本类型：
- 探索式开发
- 抛弃式原型法
较之瀑布模型有三大优势：
- 降低了适应需求变更的成本
- 用户的深度参与可以提供更及时有效的反馈
- 可以更早的交付和部署有用的软件给客户
问题
- 缺乏过程可见性
- 系统结构通常会很差
- 需要一些特别的技术，通常与主流技术不兼容
适用情况
- 中小规模的交互系统
- 大型系统的局部开发，与瀑布模型混合使用
- 生命周期较短的系统

2.3 增量式开发

特点：

系统不是作为一个整体交付，而是被分解成若干个可以单独交付的模块——增量，每个增量交付系统的部分功能
用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中

2.4 基于构件的软件工程

软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程
软构件是标准的、可互换的、经过装配可随时使用的软件模块
软件复用的意义：
- 使软件系统的开发不再“一切从零开始”，能够充分利用已有的知识和经验
- 避免重复劳动，提高开发效率，降低开发成本
- 避免全新开发可能引入的错误，提高软件质量

基于构件的软件工程和瀑布模型的区别

2.5 敏捷软件开发

这类方法允许开发团队更关注软件本身而不是编制文档
敏捷宣言：
- 个体和交互胜过工具和过程
- 编写软件胜过书写详尽的文档
- 用户合作胜过合同谈判
- 响应变更胜过遵循计划
极限编程和Scrum等敏捷开发方法都是建立在增量式开发和迭代开发的概念上，都基于敏捷宣言，基本原则相同
敏捷开发方法的基本原则：
适用情况
- 中小规模的开发团队
- 每个团队成员都可以参与决策
- 需求变更频繁的项目
- 风险高的项目

需求工程

3.1 需求分析基础

需求的两个不同层次的描述
- 用户需求
  - 从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明
- 系统需求
  - 一种结构化的文档，要运用一些专业的模型详细的描述系统的功能及其约束。
功能需求和非功能需求
- 功能需求
  - 对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。某些情况下还包括系统不应做什么
- 非功能需求
  - 对系统提供服务或功能时受到的约束进行描述。
- 领域需求
  - 这种需求来自于系统的应用领域，反映领域特征。可能是功能需求也可能是非功能需求。
- 非功能需求往往更为关键，因为非功能需求表示的是系统的整体特征
- 功能性需求描述应具备全面性和一致性
- 非功能需求的常见问题是检验困难，描述时应该设定明确目标并设定可测试的度量标准
适用自然语言描述需求的准则
- 设计一个标准格式
- 使用一致的语言
- 使用文本加亮来突出关键性需求
- 尽量避免使用计算机专用术语

3.2 需求工程过程

可行性研究
- 信息评估、信息汇总、书写报告
- 信息的评估与汇总需要分析人员与信息持有者相沟通，通过提出问题汇总信息
需求导出与分析
- 通常与需求描述交叉进行
- 需求导出的过程活动包括：
  - 需求发现
  - 需求的分类与组织
  - 优先排序和冲突解决
  - 需求文档化
- 需求的发现与识别是整个过程中最为关键的活动
- 信息来源：
  - 已有的文件
  - 系统的信息持有者
  - 相近系统的规约描述
- 需求要从多个视点进行分析
- 视点：用来表述不同角度的需求来源。每一个视点代表系统需求的一个子集
  - 从多视点对系统进行分析是十分重要的
  - 视点一般可分为：
    - 直接视点
    - 间接视点
    - 领域视点
- 访谈
  - 分为两种
    - 封闭式访谈（限定式访谈）
    - 开放式访谈
  - 对于访谈者，要求思维开阔、愿意聆听、不会对问题有先入为主的看法
需求描述
需求有效性验证
需求管理

3.3 结构化分析建模

结构化分析方法是一种面向数据流的系统建模技术
结构化分析建模的核心是==数据词典==
围绕着这个核心有三种图：
- 实体——关系图：描述数据对象及数据对象之间的关系，用于数据建模
- 数据流图：描述数据在系统中如何被传送或变换，用于功能建模
- 状态——迁移图：描述系统对外部事件如何响应，用于行为建模
数据流图的画法

3.4 UML与面向对象分析方法

3.4.1 理解uml

UML是一种 标准的图形化建模语言，它为不同领域的人们 提供一种统一的交流标准

3.4.2 需求导出工作流程

3.4.3 需求精化工作流程

重点

用例图
用例表
活动图
CRC
类模型

3.5 需求有效性验证

目的：检验需求描述是否正确地反映了客户的意愿
需求检查：
- 有效性
- 一致性
- 完备性
- 现实性
- 可检查性

设计工程

4.1 软件工程中的设计

设计是一个把问题转换成解决方案的创造性过程
设计解决的是==“如何实现系统”==的问题
从工程管理的角度，软件设计可以分为概要设计（总体设计、系统设计）与细节设计（详细设计）

4.2 设计概念

4.2.1 模块化（理解）

把软件划分为可独立命名和编址的构件
目的：更好的解决问题

4.2.2 信息隐藏与独立性

模块应该是功能独立的
好处
- 支持模块并行开发
- 减少测试和后期维护的工作量
- 整个系统扩充功能只需要插入新模块
模块独立性
- 两个定性准则来度量：耦合性和内聚性
- 耦合是模块之间相对独立性的量度，内举是模块功能相对强度的量度
- 模块的内聚性越强，耦合性越弱，独立性越强

4.2.3 抽象（理解）

抽象就是抽出事物的本质特性而暂时不考虑它们的细节

4.2.4 逐步求精（理解）

早期的一种自顶向下设计策略
主要思想：针对某个功能的宏观描述，用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止
层次结构的上一层是下一层的抽象，下一层是上一层的求精

4.3 体系结构设计

任务：识别出组成系统的子系统并建立子系统的控制和通信框架
系统的组成：
- 反映的是系统组织所采用的基本策略
- 组成类型：
  - 数据中心体系结构
  - 客户/服务器体系结构
  - 抽象机或分层体系结构

4.3.1 数据中心体系结构

基本特点：所有共享数据放到一个中心数据库中，所有子系统都能从中存取数据
当系统中存在大量的数据共享时，数据中心模型是最常用的体系结构风格

4.3.2 客户/服务器体系结构

分布式系统模型
主要组成：
- 一组为其他子系统提供服务的服务器
- 一组向服务器请求服务的客户机
- 连接客户机与服务器的网络

4.3.3 分层体系结构

把系统组织成一系列的层次，每一层提供一组服务
支持增量式开发，不同层次的服务可以单独交付
层与层之间以接口相联系

4.4 体系结构视图

软件体系结构式对系统构成与部分间联系的多角度描述，每一种模型只能描述系统的一个侧面
一个体系结构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖了系统的某一特定方面，而省略了于此方面无关的实体

4.5 控制模型

考虑子系统之间的控制流
两种一般性方法：
- 集中式控制：一个子系统专门负责控制，控制其他子系统的启动与停止
  - 调用——返回模型
  - 管理者模型
- 基于事件的控制：每个子系统都能够接受来自系统外部的事件并作出响应
  - 广播模型
  - 中断驱动模型

4.6 鲁棒性分析

鲁棒性分析的输入：
- 一个用例
- 该用例的用例场景
- 该用例的活动图
- 与模型
鲁棒性分析的输出：
- 通过一个UML序列图和一些设计组件：边界、服务、实体，得出用鲁棒图表示的设计模型
鲁棒性分析建立设计模型的过程
- 选择适当用例
- 把参与者放入协作图
- 分析用例（活动图）
  - 确定并增加边界组件
  - 确定并增加服务组件
  - 确定并增加实体组件
  - 画出组件间的关联
  - 贴上动作标签
  - 把协作图转化为序列图

4.7 用户界面设计过程

原型法

4.8 界面设计的一般原则

用户熟悉
一致性
意外最小化
可恢复性
用户差异性

4.9 错误消息

错误消息应该是礼貌的、简明的、一致的、建设性的
能够分析不同错误信息提示的优劣，能够设计符合上述规则的消息提示

4.10 帮助系统设计

软件帮助系统不能是用户手册的简单复制

软件实现与验证

5.1 程序设计与调试

任务：把设计转换成程序以及在程序中去除错误，包括编程与调试两个过程
调试：程序要对自己开发的程序进行测试，程序中的一些明显的错误会被暴露出来并被根除

5.2 验证和有效性确认

验证：检查软件是否符合它的规格描述（不符合为“软件缺陷”）
有效性确认：检查软件是否满足客户的期待（要检查系统是否符合客户的真实愿望）

5.3 用来实现V&V目标的测试模型

缺陷测试
- 目标：找出软件中的缺陷和不足，发现程序与规格描述之间的不一致性
- 成功=找出了系统存在某个目前未知的缺陷
有效性测试
- 目标：向开发者和用户证实系统满足了用户需求
- 每个需求至少要有一个测试

5.4 V&V过程的两种基本方法

软件审查：通过对系统的各种静态成果进行检查和分析发现问题
软件测试：通过使用测试数据执行系统，检查运行结果来发现问题
测试的目的：揭示程序中存在错误
按照测试的不同目标可以把测试分成 有效性测试和缺陷测试
静态审查无法检验软件是否可用，也不能检验非功能需求，因此==程序测试是必不可少的，是起决定性作用的V&V技术
程序测试和静态审查通常是结合在一起使用的
测试和调试：测试和调试是不同的过程，通常交叉进行
- 缺陷测试的目的是确定系统中存在缺陷
- 调试考虑的是定位和修改缺陷

5.5 V&V规划

仔细的规划能够使程序检查和测试工作得到更多回报
⭐️ V&V过程的规划应该从开发过程的早期就开始
明确的说明静态检查与测试任务的分工
主要是制定测试过程标准

5.6 系统开发的V模型

5.7 软件测试阶段活动

组建测试
- 测试单个程序组件
- 通常由程序开发者完成
- 大多依靠测试者的经验
系统测试
- 测试由组件整合成的子系统和系统
- 专门的测试团队测试
- 依据需求规格说明进行

5.8 集成测试

自顶向下集成
自底向上集成
增量集成测试

5.9 测试用例设计

测试用例的基本构成：
- 设计的输入
- 期望的输出
- 测试环境
- 测试对象的描述
通过设计输入数据和预计的输出来测试系统
目的：建立一组测试用例集合，用尽可能少的测试代价有效的发现系统缺陷并证明系统能够满足需求
常用方法：
- 黑盒测试（功能测试）：划分测试与边界值分析
- 白盒测试（结构测试）：结构化测试

5.10 等价划分测试

⭐️⭐️⭐️
把数据输入域划分成若干等价类，等价类中的每个数据以同样的方式处理，因此对于揭露程序中的错误是等效的。这样就可以用较小的代价暴露较多的程序错误

5.11 结构化测试

根据软件的结构知识导出测试用例的测试方法
目标：
- 保证一个模块中的所有独立路径至少被执行一次
- 对所有的逻辑值均需测试真假
- 在上下边界以及可操作的范围内执行所有循环
- 检验内部结构以确保其有效性
相对黑盒测试，白盒测试能够发现更细小的缺陷

5.12 逻辑覆盖法

按照不同的测试目标，逻辑覆盖又可分为

语句覆盖
判定覆盖
条件覆盖
判定——条件覆盖
条件组合覆盖
路径覆盖
其中，语句覆盖覆盖度最弱，路径覆盖最强

5.13 基本路径测试

⭐️⭐️
分析控制结构的环路复杂度，并用这个复杂度为指南定义执行路径的基本集合，从而导出基本可执行路径集合，设计出测试用例并保证 每个可执行语句至少执行一次，而且每个条件在执行时都将分别取真假两种值

软件维护

6.1 系统变更与进化

变更不可避免，软件系统开发的一个关键问题就是如何实现和管理现存软件的变更
系统进化过程：软件系统随变更要求不断更新改进的过程
理想的进化模型

6.2 软件维护与维护成本

软件维护是指在软件交付使用之后，为了改正错误和满足新的需要而修改软件的过程
⭐️ 四种类型：
- 纠正性维护
- 适应性维护
- 完整性维护
- 预防性维护
⭐️ 维护成本
- 维护成本一般会高于开发成本
- 影响维护成本的有技术因素也有非技术因素
- 开发阶段多投入有助于减少维护成本
- 软件年龄越大，维护成本越高
影响维护成本的主要因素
- 团队稳定性
- 合同责任
- 人员技术水平
- 程序年龄结构