11_1 软件工程【软件设计阶段，重点】

狂野小白兔

已于 2023-05-27 17:15:39 修改

阅读量1.2k

点赞数 1

分类专栏：中级软考文章标签：软件工程

于 2022-10-23 19:00:17 首次发布

本文链接：https://blog.csdn.net/qq_40572023/article/details/127358805

版权

中级软考专栏收录该内容

71 篇文章 10 订阅

订阅专栏

在这里插入图片描述

补充知识

11.19 考察标准ISO/IEC9126《软件工程产品质量》
11.20 项目开发中文档的作用
11.21 判断覆盖

软件工程

11.00 开发模型前言

开发模型

在这里插入图片描述
概念：软件工程当中指导开发的一种开发思想，开发体系

不同开发模型分不同阶段

11.01 瀑布模型（SDLC）

由来

197几年提出，随着时代发展逐渐退出神坛

淘汰原因

延期，成本超支，做不下去

瀑布模型特点

在这里插入图片描述

每层会有评审
制定了标准化
是一个结构化方法当中的模型

瀑布模型升级版—添加回溯功能

在这里插入图片描述

淘汰底层原理

在这里插入图片描述
需求阶段难以把控

做到最后面，客户需求不对等之后需要重新返工

适用场合

需求明确和二次开发

总结

结构化方法中的模型
只适用于需求明确的项目

11.02 原型、演化、增量模型

在这里插入图片描述

原型模型

适用于需求不明确的时候
一般用在需求分析阶段

步骤：

项目开发初期，构造一个简易的系统【可以是一个界面原型或者初步系统】
- 客户就可以可视化看到，提出更好的需求
在经过多轮的调整
比如1.0，1.1，1.2，2.0这样

演化模型

通过多轮演化原型成为最终产品

螺旋模型

原型+瀑布+演化模型特征的思想称为
将风险分析加入到了该模型中
适合于大规模、复杂且具有高风险的项目
螺旋模型将开发过程划分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符
在螺旋模型中过多的迭代次数会增加开发成本

增量模型

原型+瀑布模型特征的思想称为
可以快速提供一个初始化版本给用户

步骤

先做项目的核心模块
做好后先拿去给客户用，然后修正相应问题
同理一部分一部分的开发模块，使项目越来越大，最终成为最终产品

总结

原型模型强调构造一个简易的系统，针对需求不明确的情况

原型和增量的区别

原型：根本不知道做什么
增量：知道要做什么，但是太多了，所以先把核心做出来

例题讲解【2023模考一】

在这里插入图片描述

11.03 增量模型与螺旋模型

在这里插入图片描述

螺旋模型

原型+瀑布+演化模型特征的思想称为
将风险分析加入到了该模型中
适合于大规模、复杂且具有高风险的项目
螺旋模型将开发过程划分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符
在螺旋模型中过多的迭代次数会增加开发成本

增量模型

原型+瀑布模型特征的思想称为
可以快速提供一个初始化版本给用户

问：需求不明确的项目选原型还是螺旋模型？

选原型

例题讲解【2021上】

在这里插入图片描述

11.04 V模型

这种模型，测试有了更重要的地位

强调测试的模型

与瀑布模型的区别：

瀑布模型：先铺路，在拉线测试路直不直，不直就打掉重新铺
- 验证能找到问题，但是修正问题成本过高
V模型：先拉水平线，才开始铺路

V型的初衷：

如图两边有着对应关系
- 需求分析结束后就去写：验收测试和系统测试的计划
- 概要设计【模块设计】结束后就去写：集成测试
- 详细设计结束后就去写：单元测试

总结

之前模型都是结构化方法当中的模型

11.05 喷泉模型与RAD

在这里插入图片描述

喷泉模型

特点

面向对象模型
- 所以就继承了面向对象的特性：迭代和无间隙

RAD（快速开发模型）

目前常用

可以快速构建应用系统
由SDLC（瀑布模型）和CBSD（构件组装模型）组合
- 简单理解就是：可视化开发

11.06 构件组装模型（CBSD）

基本思路

把软件开发当中的各个模块，都可以考虑做成标准的构件
将构件进行组织，就得到了最终的软件

优势

极大提高了软件开发的复用性
开发时间，成本降低
软件可靠性增加
- 构件过程会创建一个构件库，再新开发软件的时候就可以直接利用库里构件

开发步骤
在这里插入图片描述

11.07 敏捷统一过程【统一过程】（UP，以前叫AUP）

在这里插入图片描述
应用于大型项目【目前常用】

特点

用例驱动的：创建好用例之后，各个阶段都通过用例来推动
以架构为中心
迭代与增量

开发过程：

初始阶段：核心阶段为创建用例
细化阶段：核心阶段为建立软件架构基础【完成架构】
构建阶段：核心阶段为构建的组装
交付阶段：核心阶段为β测试——用户阶段测试，比如qqbate测试版本，下上供用户使用测试
- 还有一种是α测试：开发环境去做的【了解】
这个1.0版本交付之后，再有问题或者更新迭代就在等2.0版本的交付（新的一轮）

总结：

敏捷统一过程(Agile Unified Process，AUP)采用“在大型上连续"以及在"在小型上迭代"的原理来构建软件系统。采用经典的UP阶段性活动(初始精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。

例题讲解【2021 下】

在这里插入图片描述

11.08 敏捷开发方法

在这里插入图片描述
应用场景：小型项目

目的

由于前面追求高质量开发模型，造成文档过多（还不一定能用到），所以提出该模型来减轻开发人员的负担
- 把不必要的文档减去

敏捷开发方法是一组模型

例题讲解：关于敏捷开发中极限编程（XP）相关知识

在这里插入图片描述

企业信息化战略与实施

11.09 信息系统开发方法

在这里插入图片描述
信息系统开发方法主要分为四类

结构化法

缺点

一旦开发完成，它的流程是固化的，不灵活的
后期要改非常的麻烦，所以就出现了后面的面向对象法

原型法

主要用在需求分析阶段
- 做一个简易的系统，给客户用来探明需求
适用于需求不明确的开发
补的是结构化方法（比如：瀑布模型）的短板

面向对象法

将现实的人或物抽象成对象，不同对象用属性来区分，对象能干什么就写成方法
相当于开发就是在组件流程

面向服务法

了解概念和SOA（面向服务结构）即可

需求工程

11.10 需求的分类

在这里插入图片描述

设计约束
- 比如：这个平台可以用php和java开发，但是需求方只会用java开发
QFD（质量展开功能）
- 基本需求：客户提出来的
- 期望需求：用户没有提出，但是理所应当提供的需求
- 兴奋需求：客户没提出来，开发自行补充的一些功能
  - 不该做，因为提高了项目开发时间，若逾期则由项目组承担

系统设计

11.11 结构化设计

概念：结构化方法当中软件设计问题

基本原则

在这里插入图片描述

多扇入，少扇出【就是多是别人调用我，我调用的模块尽量少】
- 多层模块调用当中，上层模块调用A模块（下层），称为扇入
- 被A模块调用的称为扇出

模块设计遵循以下几个主要原则：

模块独立
模块的规模要适当
- 模块越小，就会降低模块的独立性，越大也不行，分解不够充分
分解模块时候要注意层次

详细如下：
在这里插入图片描述

模块设计遵循主要原则——例题讲解【2021下】

考察：模块的规模要适当
在这里插入图片描述

模块设计遵循主要原则——例题讲解：

考察：

模块的规模要适当

模块设计原则的考察

模块控制域：这个模块本身以及所有直接或间接从属于它的模块的集合。
模块作用域：指受该模块内一个判定所影响的所有模块的集合。
模块的作用域应该在控制域范围之内【重点】

模块设计原则的考察——例题讲解【2021年上】

在这里插入图片描述

软件详细设计阶段与软件概要设计阶段

软件详细设计阶段
软件详细设计阶段的主要任务包括：对模块内的数据结构进行设计；对数据库进行物理设计；对每个模块进行详细的算法设计；代码设计、输入/输出设计、用户界面设计等其他设计。
软件概要设计阶段
软件概要设计阶段的主要任务包括

软件系统总体结构设计，将系统划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。
数据结构及数据库设计。

软件详细设计阶段与软件概要设计阶段——例题讲解【2021上】

在这里插入图片描述

内聚和耦合

内聚：一个模块内部各个部件连接的紧密程度
耦合：模块与模块之间的衡量概念

注意：
图中内聚程度由高到低排列
图中耦合程度由低到高排列

扩展：耦合类型

数据耦合传的是单个数据
- 是通过参数表传递简单信息。
标记耦合 传的是多个数据【比如传递数据结构X】
公共耦合两个模块共享外部复杂（多个）数据
- 是多个模块访问同一个公共数据环境。
外部耦合两个模块共享外部一个简单数据
- 是一组模块访问同一个全局简单变量而没有通过参数表传递。
内容耦合是一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口。本题描述的是内容耦合。

例题讲解【2023模块一】

在这里插入图片描述

耦合类型——例题讲解【2021上】

考察：内容
在这里插入图片描述

例题讲解

在这里插入图片描述

系统结构/模块结构

在这里插入图片描述

软件工程

软件测试是考点

11.12 测试原则与类型

测试原则

在这里插入图片描述

尚未发现的错误与已发现的错误成正比：就是A，B两个模块，A发现30个bug，B发现100个bug，则修改完之后主要去看B模块，因为它不够成熟还会有别的bug，而且新修改完的100也可能出现bug

测试类型

在这里插入图片描述
分为两大块

动态测试：利用到计算机的测试

灰盒就是把黑，白盒结合起来

静态测试：纯手工的测试

代码走查：就是看一段代码最后结果是多少
代码审查：我看你的代码，你看我的代码，一种交叉审查

11.13 测试用例设计

在这里插入图片描述

黑盒测试

知道输入和输出是什么，但是不知道内部结构

白盒测试

可以看到内部结构
白盒比黑盒更全面
语句覆盖和路径覆盖是两种具体的白盒测试方法

例题讲解【2021】

路径覆盖

例题讲解：2017年上

在这里插入图片描述

例题讲解：2017年下

第1题:1、两个测试用例，一个走真分支，一个走假分支即可。
第2题:2、看分支1：要走两个分支，则一个用例中A>2，另一个用例A<=2（此时，可排除D），
看分支2：要走两个分支，则其中一个用例必须满足A=5和X>3，
结合两个分支，则有一个用例为A=5，满足第一分支条件，且执行了X=X/A 后满足X>3，（X是int型）推出X>=20（此时，可推出选择B）。
可以再验证一下：
用例1：（1，1，5；5）
不满足分支1，也不满足分支2，走N—N；
用例2：（5，2，20；9）
满足分支1，X=X/A，则X=20/5=4；
继续执行，满足分支2，执行X=X+5=9，输出X=9。’

11.14 测试阶段

在这里插入图片描述
冒烟测试：做完修改后的一次充分的测试而已

理解：修好的管道里放进去烟气，哪里漏烟了，就表明哪里还有问题

几种测试的关系

先做单元测试，再做集成测试
普通项目，最后做确认测试
做集成项目时候（软硬件结合时候），会先做系统测试，再做确认测试

单元测试【—对应详细功能设计】（1）

关注的是模块级（局部）的测试

集成测试【—对应模块和接口】（2）

各个模块联合起来测试，测试的是各个模块之间衔接，接口会不会有问题
需要完成组装

确认测试（3，集成项目时候（软硬件结合时候）是4）

根据需求来测试
产品（项目组用不到）测试往往才会用：Alpha测试和Beta测试
- Alpha测试：开发环境去做的
- Beta测试：用户环境去做的
验收测试：用户参与进来来决定是否愿意验收

系统测试【—对应需求分析】【集成项目时候（软硬件结合时候）用到，变成第3个步骤】

偏重于压力，性能方面的测试
负载测试：并发1000的时候，响应多少毫秒
强度测试：资源突然下架能否应对
压力测试：在极限值情况

例题讲解【2021 下】

在这里插入图片描述

软件测试的基本目标是为了发现软件中的错误但软件测试分为几个不同的阶段，每个阶段的侧重点是有所不同的。
**单元测试【—对应详细功能设计】**主要是发现程序代码中的问题，针对详细设计和软件实现阶段的工作进行的;
**集成测试【—对应模块和接口】**验证系统模块是否能够根据系统和程序设计规格说明的描述进行工作，即模块以及模块之间的接口的测试
**系统测试【—对应需求分析】**则是验证系统是否确实执行需求规格说明中描述的功能和非功能要求，因此测试目标在需求分析阶段就已经定义。

系统开发基础

11.15 McCabe复杂度计算

考察：必考题
在这里插入图片描述

有向图G的环路复杂度公式：V(G)=m-n+2
程序流程图的环路复杂度为——闭环个数加1
该题：边11条，8个点，结果是5

注意点：

m是边，n是点
图转箭线图时候，抽象节点问题
- 连线交叉处不抽象为节点，直接连线可以，抽象为节点也可以
- 建议直接将分叉位置直接连线，不做抽象节点

例题讲解：2017年上

在这里插入图片描述

第二空，答案是4

在这里插入图片描述

例题讲解：2021年下

在这里插入图片描述

第一空答案：1
解析：
- 该流程图的作用是从小到大排列数组A的n个元素，例如排列数组元素3、2、1，只用一个测试用例即可实现。
第二空答案：3
解析：
- 图中有两个循环形成两个闭环，环路复杂度为闭环个数加1等于3个。

软件工程

11.16 系统运行与维护

在这里插入图片描述
考察：可维护性和维护类型

系统可维护性

是指维护人员理解、改正、改动、改进软件系统的难易程度
- 概念：系统方面有什么缺陷，我们对系统做调整，会涉及到编码过程

可理解性

指别人能理解系统的结构、界面功能和内部过程的难易程度。模块化、详细设计文档、结构化设计和良好的高级程序设计语言等都有助于提高可理解性。

可测试性

诊断和测试的容易程度取决于易理解的程度。好的文档资料有利于诊断和测试，同时，程序的结构、高性能的测试工具以及周密计划的测试工序也是至关重要的。为此，开发人员在系统设计和编程阶段就应尽力把程序设计成易诊断和测试的。此外，在系统维护时，应该充分利用在系统调试阶段保存下来的调试用例。

可修改性

诊断和测试的容易程度与系统设计所制定的设计原则有直接关系。模块的藕合、内聚、作用范围与控制范围的关系等，都对可修改性有影响。

例题讲解【2021 下】

在这里插入图片描述

维护类型

在系统运行过程中，软件需要维护的原因是多样的，根据维护的原因不同，可以将软件维护分为以下四种：
改正性维护

改正性维护。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就称为改正性维护。

适应性维护

适应性维护。在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方式、数据存储介质)可能发生变化。为使软件适应这种变化，而去修改软件的过程就称为适应性维护。

完善性维护

完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动称为完善性维护。更快地得到搜索结果，即提升了搜索引擎的性能，扩充功能或提升性能是完善性维护的工作。

预防性维护

预防性维护。这是指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护可定义为“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编码和测试。
千年虫问题

例题讲解【2021上】

在这里插入图片描述

MTTF & MTTR

MTTF：平均无故障时间
MTTR：平均故障修复时间

例题讲解【2021上】

在这里插入图片描述

11.17 软件能力成熟度模型集成（CMMI）【重点考察】

考察：询问等级

CMM发展而来：能力成熟度模型

是软件开发的成熟度
判定软件承包商改善软件质量的能力

CMMI体系分为阶段式和连续式

阶段式

在这里插入图片描述
分五个等级

一级：混乱级【初始级：没什么经验，靠个人】
二级：已管理级【可重复级：有一定经验】（考虑项目级别问题——这个项目组会但是公司整体不会）
三级：已定义级【有了标准化，文档化等】（考虑公司，组织级别的问题——公司模板不完美，还有一些功能不完善，有项目组做成模板提供给公司）
四级：定量管理级【管理级：质量管理体系】（量化管理）
五级：优化级【优化】（持续优化）

连续式

该式更注重个人能力的发展，不需要按等级提升而是哪里缺失，哪里不足就直接去弥补哪里
在这里插入图片描述

例题讲解【2023模考一】

在这里插入图片描述

系统开发基础

11.18 项目管理基础知识【1-2分】

考察：时间管理的概念和计算；风险管理的概念

在这里插入图片描述

时间管理【进度管理->进度安排】

时间管理主要考两种图
Gantt图：用图来展示进度的安排

优势：可从图直观看到整个计划是什么样子的，计划开展时间等
缺点：过于简单不能清晰表达任务之间的依赖关系

项目活动图——PERT图【考试重点】：可以给出那些任务完成后才能开始另一些任务

主要了解计算问题
项目的最短工期：就是从开始到结束最长的路径
- 也称为：关键路径：完成整个工程\项目，所需最长时间的路径。（最长天数）
- 一般题目问：完成该项目的最短时长，就是求关键路径长度。
计算完成最少时间、某活动的松弛时间
任务的松弛时间：表示不影响整个工期的前提下，完成该任务有多少机动余地。
- 说法一:某个任务的松弛时间 = 工程关键路径 - 包含该任务的最长路径耗时
- 说法二:总关键路径 - 次要路径长度
- 说法三：最迟开始时间 - 最早开始时间
扩展知识

项目活动图——PERT图的例题讲解【2021上】

考点：

关键路径：完成整个工程\项目，所需最长时间的路径。
任务的松弛时间：表示不影响整个工期的前提下，完成该任务有多少机动余地。
- 某个任务的松弛时间 = 工程关键路径 - 包含该任务的最长路径耗时

项目活动图——PERT图的例题讲解【2021下】

考察：

关键路径是AEGHKL、ABDIJL、ABDIJKL，工期20天。
BI的松弛时间等于最迟开始时间-最早开始时间=4-3=1。
EG在关键路径上，松弛时间是0。

在这里插入图片描述

时间管理例题讲解【综合题】

在这里插入图片描述
第一问：Gantt图得缺点不能清晰表达任务之间的依赖关系
第二问6最晚开始时间求解步骤

先正推，将所有的最早开始时间算出来
- 本题求出15，13，所以最迟开始时间是15
然后逆推的方式，把所有最晚开始时间求出来
- 逆推得结果10

风险管理

在这里插入图片描述
概念：损失或损害的可能性

风险是可能发生的事件，并且可能会带来损失，预测到风险后，可以进行干预以期减少损失，但是无法避免的

风险分类

项目风险：项目本来计划5万开发出来，结果用了10万
技术风险：用了新的技术带来的缝隙
商业风险：上面都做得很好，但是发现市场不需要这样的产品

风险曝光度=出现概率*可能的损失

量化一个风险，来衡量我们管理那些风险

例题讲解【2021上】

例题讲解【2021下】

考察：

在风险管理中，通常需要进行风险监测，其目的不包括(消除风险)。
风险监测主要是对风险进行预测，评估，收集相关的信息，用来防止风险，从而做好相关的防范措施
风险是无法被消除掉的，只能尽量避免

在这里插入图片描述

11.19 考察标准ISO/IEC9126《软件工程产品质量》

使用质量是从用户观点出发，而不是开发者、维护者的观点，来看待软件产品用于特定环境和条件下的质量。它测量用户在特定环境中达到其任务目标的程度，而不是测量软件自身的性质。
ISO/IEC软件质量模型由三个层次组成: 第一层是质量特性，第二层是质量子特性，第三层是度量指标。易使用性是指与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。
其子特性包括适应性、易安装性、共存性、易替换性、依存性。