📔个人主页📚： 秋邱-CSDN博客
☀️专属专栏✨： 软考------软件设计师
🏅往期回顾🏆： 软件设计师------信息安全
🌟其他专栏🌟： C语言_秋邱
一、软件工程概述
1.1、考点1、信息系统基本生存周期 (⭐⭐⭐)
- 可行性分析与项目开发计划
- 需求分析
- 概要设计
- 详细设计
- 编码
- 测试
- 维护
1.2、考点2、软件过程
1.2.1、CMM
- 初始级：杂乱无章，甚至混乱，几乎没有明确定义的步骤项目的成功完全依赖个人的努力和英雄式核心人物的作用。
- 可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中成功。
- 已定义级：管理和工程两方面的软件过程已经文档化、标准化并综合成整个软件开发组织的标准过程。
- 已管理级：制定了软件过程和产品质量的详细度量标准。
- 优化级:加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。
1.2.2、CMMI
1.2.2.1、阶段模型
- 初始的：过程不可预测且缺乏控制
- 已管理的：过程为项目服务。
- 已定义的：过程为组织服务。
- 定量管理的：过程已度量和控制。
- 优化的：集中于过程改进。
1.2.2.2连续式模型
|-------------|------------------------------------------------------------------------------------------------------|-----------------------------|
| 等级 | 说明 | 关键字 |
| CL0 (未完成的) | 过程域未执行或未得到CL1中定义的所有目标。 | 未执行或未得到 |
| CL1 (已执行的) | 其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标。 | 可标识的输入工作产品转换成可标识的输出工作产品 |
| Cl2 (已管理的) | 其共性目标是集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制、和评审 | 已管理的过程的制度化 |
| CL3 (已定义级的) | 其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。 | 已定义的过程的制度化 |
| CL4 (定量管理的) | 其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的质量目标作为管理准则。 | 可定量管理的过程的制度化 |
| CL5 (优化的) | 使用量化(统计学)手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。 | 量化(统计学)手段改变和优化过程域 |
二、软件开发方法
结构化方法（ 需求明确 ）
用户至上
严格区分工作阶段，每阶段有任务和结果
强调系统开发过程的整体性和全局性
系统开发过程工程化，文档资料标准化
自顶向下，逐步分解(求精)
原型法（ 需求不明确 ）
面向对象法（ 复杂，大项目 ）更好的复用性
关键在于建立一个全面、合理、统一的模型
分析、设计、实现三个阶段，界限不明确
面 向服务的方法抽象级别：操作、服务、业务流程
Jackson面向数据结构
三、软件开发模型(⭐⭐⭐)
3.1、考点1：瀑布模型与V模型(⭐⭐⭐)
瀑布模型特点 ：以文档作为驱动 、适合于软件需求很明确的软件项目。
V模型特点：将验证确认活动应用于早期软件工程工作中，测试贯穿始终
3.2、考点2：演化模型(原型模型、螺旋模型)(⭐⭐⭐)
演化模型 ：演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏确认识的情况
原型方法比较适合于用户需求不清、需求经常变化的情况，当系统规模不是很大也不太复杂时，采用该方法比较好。
原型有多种分法：抛弃性原型、演化性原型
探索性原型、实验性原型、演化性原型
螺旋模型：瀑布模型 和演化模型 结合，加入了风险分析。特别适用于庞大、复杂并且具有高风险的系统。 
3.3、考点3：增量模型(⭐⭐⭐)
第1个增量往往是核心产品。将需求分段为一系列增量产品，每一增量可以分别开发。
3.4、考点4：喷泉模型（面向对象）
以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。
特点:迭代无间隙
3.5、考点5：统一过程UP(RUP)
3.6、考点6：敏捷方法(⭐⭐⭐)
3.6.1、基本原则
- 短平快的会议
- 小型版本发布
- 较小的文档
- 合作为重
- 客户直接参与
- 自动化测试
- 适应性计划调整
- 结对编程
- 测试驱动开发
- 持续集成
- 重构
总体目标是通过"尽可能早地、持续地对有价值的软件的交付"使客户满意。适用于:"小步快跑"的思想，适合小项目小团队。
3.6.1.2、敏捷开发方法
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 敏捷方法 | 特点 |
| 极限编程XP | 4大价值观、5个原则、12个最佳实践 |
| 水晶法(Crystal) | 认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响(以人为本)，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性交付，软件生产力得到提高。 |
| 开放式源码 | 程序开发人员在地域上分布很广 |
| 并列争球法( SCRUM) | 把每30天一次的迭代称为一个"冲刺"，并按需求的优先级来实现产品。 多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄球中的"并列争球"。 |
| 功用驱动开发方法FDD | 首席程序员和"类"程序员 |
| 自适应软件开发ASD | 核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。ASD有6个基本的原则：有一个使命作为指导;特征被视为客户价值的关键点;过程中等待是很重要的，因此"重做与"做"同样关键;变化不被视为改正，而是被视为对软件TAS开发实际情况的调整，确定的交付时间造使开发人员认真考虑每一个生产的版本的关键需求;风险也包含其中。 |
|-------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 极限编程XP |||
| 4大价值观 | 5大原则 | 12大最佳实践 |
| 沟通 简单 反馈 勇与 | 快速反馈 简单性假设 逐步修改 提倡更改 优质工作 | 计划游戏：快速制定计划、随着细节的不断变化而完善小型发布:系统的设计要能够尽可能早地交付 隐喻：找到合适的比喻传达信息 简单设计：只处理当前的需求，使设计保持简单 测试先行：先写测试代码，然后再编写程序 重构：重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求 结对编程 集体代码所有制 持续集成 ：可以按日甚至按小时为客户提供可运行的版本 每周工作40小时 现场顾客：系统最终用户代表应该全程配合XP团队编码标准 |
四、需求分析(⭐⭐⭐)
4.1、考点1：需求分析的概念
软件需求包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性要求、软件成本消耗与开发进度需求、其他非功能需求。
需求分析阶段的输出包括：数据流图、实体联系图、状态迁移图、数据字典，补充材料。
4.2、考点2：需求的分类
4.3、考点3：需求分析的工具
4.3.1、数据流图(⭐⭐⭐)
4.3.1、数据字典(⭐⭐⭐)
数据字典有以下四个条目：数据流、数据项、数据存储和基本加工，（源点和终点不在系统之内，不在字典中说明）
4.3.3、判定表
4.3.4、判定树
五、系统设计
5.1、考点1：系统设计概述
系统设计分为概要设计 和详细设计
概要设计：
- 设计软件系统总体结构
- 数据结构及数据库设计
- 概念设计
- 逻辑设计
- 物理设计
- 编写概要设计文档
- 评审
详细设计：对每个模块进行详细的算法设计
5.2、考点2：模块设计(⭐⭐⭐)
5.2.1、模块设计原则：
- 保持模块的大小适中
- 尽可能减少调用的深度（适中）
- 多扇入，少扇出（适中）
- 单入口，单出口
- 模块的作用域应该在模块之内
- 模块的作用域应该在模块之内
控制域>作用域
被调用模块和调用模块组成控制域名
高层依赖低层
5.2.2、高内聚、低耦合
内聚
|------------|----------------------------|
| 内聚类型 | 描述 |
| 功能内聚 | 完成一个单一功能，各个部分协同工作，缺一不可 |
| 顺序内聚 | 处理元素相关，而且必须顺序执行 |
| 通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
| 过程内聚 | 处理元素相关，而且必须按特定的次序执行 |
| 瞬时内聚(时间内聚) | 所包含的任务必须在同一时间间隔内执行 |
| 逻辑内聚 | 完成逻辑上相关的一组任务 |
| 偶然内聚(巧合内聚) | 完成一组没有关系或松散关系的任务 |
5.2.3、耦合(板块与板块之间的关联)
|-------|--------------------------------------------------------------------|
| 耦合类型 | 描述 |
| 非直接耦合 | 两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的 |
| 数据耦合 | 一组模块借助参数表传递简单数据 |
| 标记耦合 | 一组模块通过参数表传递记录信息(数据结构) |
| 控制耦合 | 模块之间传递的信息中包含用于控制模块内部逻辑的信息 |
| 外部耦合 | 一组模块之间传递的信息中包含用于控制模块内部逻辑的信息 |
| 公共耦合 | 多个模块都访问同一个公共数据环境 |
| 内容耦合 | 一个模块直接访问另一个模块的内部数据;；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠;一个模块有多个入口 |
5.3、考点3：人机界面设计考(⭐⭐⭐)
黄金三原则
- 置于用户控制之下
- 允许用户交互可以被终端和撤销
- 当技能级别增加可以使交互流水化并允许定制交互
- 减少用户的记忆负担
- 建立有意义的缺省
- 定义直觉性的捷径
- 保持界面的一致性
5.4、考点4：架构设计(⭐⭐⭐)
5.4.1、软件架构风格
架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
数据流风格：批处理序列、管道-过滤器调用/返回风格：主程序/子程序、面向对象、层次结构J(MVC、C/S、B/S)
独立构件风格：进程通信、事件驱动系统(隐式调用)
虚拟机风格：解释器、基于规则的系统
仓库风格： 数据库系统、超文本系统、黑板系统
5.4.2、数据流风格
批处理序列
构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始数据必须是完整的，以整体的方式传递。
管道-过滤器
每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理:然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。
早期编译器就是采用的这种架构。要一步一步处理的，均可考虑采用此架构风格。
5.4.3、调用/放回风格
主程序/子程序
单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性
面向对象
构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的
层次结构
构件 组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)
优点：
1、这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。2、不同的层次处于不同的抽象级别:越靠近底层，抽象级别越高;越靠近顶层，抽象级别越低;
3、由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。
缺点:
1、并不是每个系统都可以很容易地划分为分层的模式。
2、很难找到一个合适的、正确的层次抽象方法。
5.4.4、层次架构风格
两层C/S
客户端和服务器都有处理功能。处理在表示层（客户端）和数据层（服务器）进行
三层C/S架构
将处理功能独立出来。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。
三层B/S架构
将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构.
5.4.5、MVC架构风格
Model(模型)是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View(视图)是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。
J2EE体系结构中:
- 视图(View):JSP
- 控制(Controller):Servlet
- 模型(Model ): Entity Bean、 Session Bean
5.4.6、独立构件风格
进程通信
构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。
事件驱动系统(隐式调用)
构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便:其缺点是构件放弃了对系统计算的控制。
5.4.7、虚拟机风格
解释器
解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
基于规则的系统
基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存一般用在人工智能领域和DSS中。
5.4.8、仓库风格（以数据为中心的风格）
数据库系统
构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态;另一类是多个独立处理单元，处理单元对数据元素进行操作。
黑板系统
包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板;黑板是一个全局数据库包含问题域解空间的全部状态，是知识源相互作用的唯一介;知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
超文本系统
构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
现代集成编译环境一般采用这种架构风格。
六、系统测试
6.1、考点1：测试的基本概念及分类
测试遵循的原则：
- 尽早、不断的进行测试
- 程序员避免测试自己设计的程序
- 既要选择有效、合理的数据，也要选择无效、不合理的数据
- 修改后应进行回归测试
- 尚未发现的错误数量与该程序已发现错误数成正比
6.2、考点2：黑盒测试
等价类划分
- 确定无效与有效等价类
- 设计用例尽可能多的覆盖有效类
- 设计用例只覆盖一个无效类
边界值分析
- 处理边界情况时最容易出错
- 选取的测试数据应该恰好等于、稍小于或稍大手边界值
6.3、考点3：白盒测试(⭐⭐⭐)
|----------------|------------------------------------------------------------|--------------------------------------|
| | 定义 | 特点 |
| 语句覆盖 | 被测试程序中的每条语句至少执行一次。 | 对执行逻辑覆盖很低，一般认为是很弱的逻辑覆盖。 |
| 判定覆盖(分支覆盖) | 被测程序每个判定表达式至少获得一次"真"值和"假"值(或者程序中每一个判定取"真"分支和取"假"分支至少通过一次。） | 判定覆盖比语句覆盖更强一些。判定可以是1个条件，也可以是多个条件的组合。 |
| 条件覆盖 | 每一个判定语句中每个逻辑条件的各种可能的值至少满足一次。 | 条件覆盖和判断覆盖没有包含关系。 |
| 判断/条件覆盖 | 判定中每个条件的所有可能取值(真/假)至少出现一次，并使每个判定本身的判定结果(真/假)也至少出现一次。 | 同时满足判定覆盖和条件覆盖 |
| 条件组合覆盖 | 每个判定中的各种可能值的组合都至少出现一次。 | 同时满足判定覆盖、条件覆盖、判定/条件覆盖。 |
| 路径覆盖 | 覆盖被测试程序中所有可能的路径。 | |
| 基本路径测试 | 每一条独立路径都执行过(即程序中可执行语句至少执行一次)。 | 测试用例个数与环路复杂度致。判定为关键控制结点，必须出现在基本路径中。 |
| 循环覆盖 | 循环中每个条件都得到验证。 | 注意数组参数可循环验证 |
6.4、考点4：测试阶段划分
单元测试：模块测试，模块功能、性能、接口等
集成测试：模块间的接口
系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接。
确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试（开发）、Beta测试（用户），验收测试。
**回归测试：**测试软件变更之后，变更部分的正确性对变更需求的符合性。
6.5、考点5：McCabe复杂度计算(⭐⭐⭐)
计算有向图的环路复杂度公式：V=m-n+2
说明：其中V是有向图中的环路个数，m是G中的有向弧数，n是G中的节点个数。
上图：15-12+2=5
七、软件维护(⭐⭐⭐)
可维护性因素决定
- 可理解性
- 可测试性
- 可修改性
软件维护类型
- 改正性维护
- 适应性维护
- 预防性维护
- 完善性维护
**适应性维护：**指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业的外部市场环境和管理需求的不断变化也使得各级管理人员不断提出新的信息需求。
**完善性维护：**扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。
八、软件文档(⭐⭐⭐)
|---------------------------------------------------------------------------------------------------|-----------------------------------------|--------------------------------------------------------|
| 开发文档 | 产品文档 | 管理文档 |
| * 可行性研究和项目任务书 * 需求规格说明 * 功能规格说明 * 设计规格说明(包括程序和数据规格说明) * 开发计划 * 软件集成和测试计划 * 质量保证计划、标准、进度 * 安全和测试信息 | * 培训手册 * 参考手册和用户指南 * 软件支持手册 * 产品手册和信息广告 | * 开发过程的每个阶段的进度和进度变更的记录 * 软件变更情况的记录 * 相对于开发的判定记录 * 职责定义 |
| | | |
九、软件质量保证模型(⭐⭐⭐)
|--------------------------------|----------------------|-----------------------|------------------|----------------------------|------------------------|
| 功能性 | 可靠性 | 易用性 | 效率 | 维护性 | 可移植性 |
| 适合性 准确性 互操作性 安全保密性 依从性 功能性的依从性 | 成熟性 容错性 易恢复性 可靠性的依从性 | 易理解性 易学性 易操作性 易用性的依从性 | 时间特性 资源利用性 效率依从性 | 易分析性 易分析性 稳定性 易测试性 维护性的依从连 | 适应性 易安装性 易替换性 可移植性的依从性 |