软件工程期末总复习---详解

最新推荐文章于 2024-09-20 10:40:43 发布

「已注销」

最新推荐文章于 2024-09-20 10:40:43 发布

阅读量333

点赞数 2

分类专栏：笔记软件工程文章标签：软件工程

本文链接：https://blog.csdn.net/Sinlair/article/details/125188523

版权

笔记同时被 2 个专栏收录

30 篇文章 2 订阅

订阅专栏

软件工程

2 篇文章 0 订阅

订阅专栏

加油💕❤🤞

文章目录

第一章软件工程介绍

1、代码规范

1.1源文件文档化

标识符的命名
注解

序言性注解开头部分

模块的功能模块的接口：包括调用格式、参数的解释、该模块需要调用的其它子模块名重要的局部变量：包括用途、约束和限制条件开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述

功能性注解源程序体内

注解要正确，错误的注解比没有注解更坏；为程序段作注解，而不是为每一个语句作注解；用缩进和空行，使程序与注释容易区分；注解应提供一些从程序本身难以得到的信息，而不是语句的重复。
程序的视觉组织

1.2语句构造

1.3数据说明

1.4输入/输出

2、代码复审

也称代码评审，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。

在这里插入图片描述

3、代码测试

3.1 单元测试

是指对软件中的最小可测试单元进行检查和验证。

3.2 回归测试

在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的稳定状态退化到不正常工作的不稳定状态。 版本回退

4、程序调试

4.1 软件调试

软件调试是在进行了成功的测试之后才开始的工作，它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。

5、版本控制

github、gitee

第二章软件及软件工程

1、软件的本质

1.1 软件构成

计算机软件指计算机系统中的程序、数据及其相关文档

程序：按照特定顺序组织的计算机数据和指令的集合。
数据：使程序能正常执行的数据结构
文档：为了便于理解程序所需的与开发、维护和使用有关的资料

1.2 软件特点

软件是设计开发的，而不是传统意义上生产制造的。

软件不会“磨损”，但会退化。

大多数软件还是用户定制的。

在这里插入图片描述

1.3 软件分类

系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。

支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。

应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。

1.4 软件技术演化

第一阶段：程序设计阶段。1946年到60年代初：个体手工方式。（小程序）

第二阶段：程序系统阶段。60年代初到70年代初：小组化生产，出现软件危机。（软件作坊）

第三阶段：传统软件工程阶段。20世纪70年代中期至80年代中期：把工程化的思想引入到软件开发中，结构化方法的发展，规模化软件开发。

第四阶段：面向对象阶段。20世纪80年代中期至今：面向对象方法学发展，软件定制和满足客户需求。

2、软件危机

软件危机(Software Crisis)：计算机软件的开发和维护过程所遇到的一系列严重问题。

产生原因：**软件自身的特点、软件维护和开发的方法不正确**

3、软件的工程定义

建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。

1993年IEEE进一步给出了一个更全面更具体的定义：“软件工程是：①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件； ②研究①中提到的途径”。

4、软件的生命周期

4.1 软件工程活动

框架活动

沟通-需求获取

策划-项目计划

建模

需求模型、设计模型

构建

编码测试

部署
普适性活动

软件项目跟踪和控制 - 项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。

风险管理 - 对可能影响项目成果或者产品质量的风险进行评估。

软件质量保证 - 确定和执行保证软件质量的活动。

技术评审-评估软件工程产品，尽量在错误传播到下一个活动之前发现并清除错误。

测量 - 定义和收集过程、项目以及产品的度量

软件配置管理-在整个软件过程中管理变更所带来的影响。

可复用管理-定义工作产品复用的标准（包括软件构件），并且建立构件复用机制。

4.2 软件生命周期定义

是软件从产生直到报废的整个时期

4.3 软件神话

增加开发人员不一定会提升开发速度

第三章软件过程及过程模型

1、软件过程

一个为创建高质量软件所需要完成的活动、动作和任务的框架。

2、软件过程模型

也称软件开发模型或软件生存周期模型

是软件生存周期中一系列有序的软件开发活动的流程，是软件开发全部活动的结构框架。

对一个软件的开发无论其大小，都需要选择一个合适的软件过程模型，主要根据软件的类型、规模，开发方法、开发环境等多种因素来确定。

2.1 瀑布模型

瀑布模型将软件生命周期划分为软件计划、需求分析、设计、实现、测试、运行和维护等阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。

过分强调文档

特点：

阶段间具有顺序性和依赖性

推迟实现的观点

质量保证的观点

2.2 原型开发模型（快速原型）

原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。

一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型

2.3 增量模型

增量模型以迭代的方式运用瀑布模型。随着时间的推移，发布一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

第一个增量往往是核心产品：满足了基本的需求，但是缺少附加的特性。

2.4 螺旋模型

风险驱动的软件开发模型

采用循环的方式，逐步加深系统定义和实现的深度确定一系列里程碑，确保stakeholders都支持系统解决方案

结合了原型的迭代性质和瀑布模型的可控性、系统性特点。但是开发难度较大

2.5 基于构件的开发

是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段（集成）高效率、高质量地构造应用软件系统的过程。

2.6 形式化方法模型

形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。

航空航天 等高精度的开发 , 对开发人员的基本素质要求较高

第四章敏捷开发

1、敏捷是什么

1.1 敏捷价值观

个人和他人之间的交流胜过开发过程和工具

可运行的软件胜过宽泛的文档

客户合作胜过合同谈判

对变更的良好响应胜过按部就班地遵循计划

2、敏捷过程

基于敏捷原则进行的软件开发过程，视为敏捷过程

极限编程
Scrum

3、极限编程

极限编程的主要目标在于降低因需求变更而带来的成本

采用迭代的交付方式，每个迭代很短（1-3周时间）。在每个迭代结束的时候，团队交付可运行的，经过测试的功能，这些功能可以马上投入使用。

在这里插入图片描述

4、Scrum模型

采用短周期迭代交付方式

4.1 Scrum活动

Sprint冲刺

Sprint planning meeting冲刺计划会

Daily standup meeting每日立会

Sprint review冲刺评审会

Retrospective meeting回顾会议

燃尽图

5、敏捷团队

敏捷对团队的要求很简单：

自主管理（Self-managing）

自我组织（Self-organizing）

多功能型（Cross-functional）

第五章需求分析

1、软件需求的定义

IEEE软件工程中需求的定义(1977)

用户解决问题或达到目标所需的条件和能力系统或系统部件为满足合同、标准、规范或其它正式规定文档所需具有的条件和能力以上条件和能力的文档说明

Sommerville & Sawyer 1997
需求是指系统必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束

2、软件需求的层次

业务需求
用户需求
- 描述用户使用产品必须完成的任务
功能需求
- 描述开发人员在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

3、软件需求的分类

非功能需求：不直接与系统具体功能相关的需求。
功能需求

4、需求获取技术

面谈

调查

观察实际业务过程

原型法

头脑风暴

场景技术

5、竞争性需求分析

N (Need 需求) 你的创意解决了用户的什么需求?
A (Approach 做法) 你有什么招数, 特别是独特的招数, 来解决用户的痛苦。
B (Benefit 好处) 那你这个产品用户带来什么好处呢?
C (Competitors 竞争) 与竞争对手相比你有什么优势?
D (Delivery) 你怎么让目标用户都知道你的产品? 并且让产品的用户量快速提高?

6、需求规格说明书

对目标软件的各种描述
- 信息描述
- 功能和行为描述
- 性能需求
- 设计约束
- 合适的验收标准

第六章需求建模

1、需求建模概述

1.1 需求分析的目的

说明软件的工作特征

指明软件和其他系统元素的接口

规定软件必须满足的约束

1.2 需求分析的主要任务

描述用户场景、功能活动、类、类之间的关系、系统和类的行为、数据流等

在这里插入图片描述

2、基于场景的建模

2.1 定义

用于表示系统所提供的服务，描述参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话（交互）。

2.2 用例建模的步骤

识别系统的参与者（执行者，actor）

识别用例

绘制用例图

编写用例描述

3、基于数据流的建模

一种面向数据流的传统软件开发方法

以数据流为中心构建软件的分析模型和设计模型

3.1 结构化分析

(Structured Analysis 简称SA)

抽象：忽略一个问题中与当前目标无关的那些方面，以便更充分地关注与当前目标有关的方面

分解：将问题不断分解为较小的问题，直到每个最底层的问题都足够简单为

数据字典是模型的核心，它包含了软件使用和产生的所有数据的描述数
据流图（DFD，Data Flow Diagram）服务于两个目的：一是指明数据在系统中移动时如何被变换，二是描述对数据流进行变换的功能和子功能。

在这里插入图片描述

画分层数据流图的步骤

1．画系统的输入和输出

2．画系统内部

3．画加工内部

4．重复第3步，直至每个尚未分解的加工都足够简单(即不必再分解)

数据字典

数据字典条目包括：数据流、文件、数据项(组成数据流和文件的数据)、加工、源点和终点

符号	名称	举例
＝	定义为	x＝… 表示x由…组成
＋	与	a＋b 表示a和b
［…，…］	或	［a，b］表示a或b
［…│…］	或	［a│b］表示a或b
｛…｝	重复	｛a｝表示a重复0或多次
｛…｝	重复	｛a｝表示a重复3到8次
(…)	可选	(a) 表示a重复0或1次
″…″	基本数据元素	″a″ 表a是基本数据

3.2 结构化设计

(Structuresd Design 简称SD)

3.3结构化程序设计

(Structured Programmin 简称SP)

4、基于数据的建模

5、面向状态的建模方法

第七章软件设计

1、软件设计概念

2、体系结构风格

3、体系结构设计

4、构件级设计

5、用户界面设计

人机界面

用户界面

黄金规则

把控制权交给用户
减少用户的记忆负担
保持界面一致

第八章软件测试

1、基本概念

狭义：为了发现软件错误而执行软件的过程。

广义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

1.1 测试用例定义

测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

在这里插入图片描述

白盒测试（又称为结构测试）

把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作,白盒测试主要用于对模块的测试.
黑盒测试（又称行为测试）

把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求,黑盒测试可用于各种测试.

2、软件测试的分类

按测试方式分类
- 静态测试（不需要执行所测试的程序，查询代码是否符合规范，对程序的数据流和控制流进行分析）
- 动态测试（选择实际测试用例运行测试程序，模拟用户输入）
按测试过程分类
- 单元测试:是针对程序中的模块或构件，主要揭露编码阶段产生的错误
- 集成测试:针对集成的软件系统，主要揭露设计阶段产生的错误
- 确认测试:是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误
- 系统测试:对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误