软件工程知识体系 自考13005
2025-08-26 15:37:30 2 举报
AI智能生成
自整理24版考试知识点
作者其他创作
大纲/内容
1. 软件开发与软件工程概述
<b>正确认识软件开发:</b> 是从事软件开发实践和软件工程项目管理的思想基础
<b>软件工程构成:</b> 软件开发技术 + 软件工程管理
<b>软件危机:</b>
<b>背景:</b> 20世纪60年代以来计算机广泛应用
<b>原因:</b> 软件生产率、质量远不能满足社会需求
<b>影响:</b> 成为社会、经济发展的制约因素
<b>软件工程发展历程:</b>
<b>a. 20世纪60年代末到80年代初:</b> [3a]
<b>特点:</b> 前期主要研究系统实现技术,后期开始关注软件质量和软件工程管理
<b>里程碑:</b> 提出了瀑布模型
<b>开发语言:</b> 过程式语言,如Pascal、C、Ada等
<b>b. 20世纪80年代以来:</b> [3b]
<b>特点:</b> 大力开展了计算机辅助软件工程(CASE)的研究与实践
<b>里程碑:</b> 提出了面向对象软件开发方法;Smalltalk-80语言的推出标志着面向对象的程序设计已进入实用阶段
<b>研究与实践:</b> 软件生产技术,特别是软件复用技术和软件生产管理
<b>开发语言:</b> 面向对象语言,如Smalltalk、C++、Eiffel等
<b>软件开发面临的挑战:</b>
问题域与运行平台间的差异
复杂问题的结构化处理
多抽象层间的有效映射
<b>解决复杂问题策略:</b> 分解
2. 软件需求工程
<b>可行性研究目的:</b> 用最小代价在尽可能短时间内确定该软件项目是否能够开发,是否值得去开发
<b>可行性研究实质:</b> 进行一次简化、压缩了的需求分析
<b>可行性研究主要内容:</b> 技术可行性、经济可行性和社会可行性分析
<b>软件需求基本属性:</b> 标识符、名称、描述、来源、优先级、版本、状态(如已批准、待审核、已废弃等)
<b>用途:</b> 用于管理和跟踪需求的全生命周期
<b>软件需求层次:</b>
<b>a. 业务需求:</b> 反映了组织机构或客户高层次的战略目标,包含了功能需求和非功能性需求两部分
<b>b. 用户需求:</b> 描述了用户希望系统具有的功能、性能等特性
<b>c. 系统需求:</b> 从系统实现角度对用户需求的技术化、细化描述
<b>专业角色 (系统分析师):</b> 主要职责之一就是与用户进行密切沟通,理解用户业务流程、问题和期望,从而有效地收集、分析和整理用户需求
<b>需求分析定义:</b>
确定系统必须具有的功能和性能,系统要求的运行环境,并且预测系统发展的前景
一种清晰、简介、一致且无二义性对一个待开发系统中各个有意义方面的陈述的一个集合
对软件提出的需求进行分析并给出详细定义,即准确地确定软件系统的功能
<b>需求分类:</b>
<b>a. 功能需求:</b> 整个需求的主体(例:系统应能产生月销售报表) [11a]
<b>b. 非功能需求:</b> [11b, 59]
<b>i. 性能需求:</b> 系统或系统构件在性能方面必须具有的一些特性(例:系统应在5分钟内计算出给定季度的总销售税) [11bi, 59]
<b>ii. 外部接口需求:</b> 对要构建的账户接收系统,必须为月财务状况系统提供更新信息 [11bii]
<b>iii. 设计约束:</b> 任取1秒钟,一个特定应用所消耗的可用计算能力平均不超过50% [11biii]
<b>iv. 质量属性:</b> 可靠性、存活性、可维护性和用户友好性 [11biv]
<b>需求分析阶段任务:</b>
<b>首要任务:</b> 建立系统功能模型
<b>基本任务:</b> 准确定义新系统的目标,回答系统必须“做什么”
<b>最终结果:</b> 产生需求规格说明书
<b>需求规格说明书 (SRS):</b>
<b>又称:</b> 需求规约
<b>定义:</b> 软件开发组织和用户之间一份事实上的技术合同书,给出了用户与开发人员对软件需求的共同理解
<b>作用:</b>
产品/系统设计的依据
创建产品验收测试计划和用户指南的基础
双方对软件要做什么的共同理解
需求分析的最终结果
<b>基本性质:</b> 重要性和稳定性程度、可修改的、完整的、一致的
<b>内容:</b>
<b>a. 引言:</b> 叙述在问题定义阶段确定的关于软件的目标与范围 [19a]
<b>b. 数据描述:</b> [19b]
<b>i. 数据流图(DFD):</b> 用来表达系统的逻辑模型(确切的说是目标系统的逻辑模型) [19bi]
<b>ii. 数据字典(DD):</b> 汇集了在系统中使用的一切数据的定义 [19bii]
<b>c. 功能描述:</b> 对软件功能要求的说明 [19c]
<b>d. 性能描述:</b> 对软件性能要求的说明(包括软件的处理速度、响应时间、安全限制等内容) [19d]
<b>e. 质量保证:</b> 阐明在软件交付使用前需要进行的功能测试和性能测试,并且规定源程序和文档应该遵守的各种标准 [19e]
3. 软件分析与建模
<b>软件开发所涉及的系统模型分类:</b>
<b>概念模型:</b> 标识要解决的问题,即描述了“系统是什么”
<b>软件模型:</b> 描述了实现概念模型的软件解决方案 (分为设计模型、实现模型和部署模型)
<b>软件开发所涉及的系统模型通常分类:</b> 功能模型、行为模型、数据模型
<b>创建系统的分析模型活动:</b>
结构分析
用况分析
类的分析
包的分析
<b>服务包特点:</b>
不可分离
一般只涉及一个参与者或很少几个参与者
可独立执行
服务包之间的依赖通常是非常受限的
<b>结构化分析方法 (SA):</b>
<b>构成:</b> 结构化分析(SA)、结构化设计(SD)、结构化程序设计(SP)
<b>基本思想:</b> 自顶向下,逐步求精
<b>表达功能模型的工具:</b> 数据流图(DFD图)
<b>主要描述工具:</b> DFD(数据流图)与DD(数据字典)
<b>数据流图(DFD图):</b>
<b>定义:</b> 一种描述数据变换的图形化工具
<b>包含元素:</b> 数据流、数据存储、加工、数据源和数据潭等
<b>图形符号:</b> 箭头表示数据流,椭圆表示加工(处理),双杠表示数据存储,矩型框表示外部实体(数据源点或终点)
<b>规则:</b> 每个加工、数据存储至少有1个输入流和1个输出流
<b>数据字典(DD):</b>
<b>定义:</b> 定义了包含所有的数据流和数据存储的数据结构
<b>四类条目:</b> 数据流条目、数据项条目、数据存储条目、加工条目
<b>描述加工的工具:</b>
结构化语言
判定表
判定树
<b>适用场景:</b> 当 DFD 中某加工的一组动作存在多个复杂组合判断时,宜用判定表或判定树
<b>结构化自然语言:</b>
介于形式语言与自然语言之间
保留自然语言简单易懂的特点
通过引入外层语法(如顺序、选择、循环等)来避免自然语言结构上的松散性
使得描述加工逻辑更加清晰、规范
<b>软件模型技术与方法:</b>
<b>对象模型技术(OMT):</b>
包含:对象模型、动态模型、功能模型
模型化过程是一个迭代的过程,每一次迭代都将对这3个模型做进一步的检验、细化和充实
<b>面向数据流的设计方法 (SD - 结构化设计):</b>
是一种面向数据流的开发方法
数据流图(DFD)是一种常用图形工具,用于描绘数据在系统各组件之间的流动情况,反映系统的逻辑处理过程
<b>Jackson方法:</b> 一种面向数据结构的开发方法 [60a]
<b>维也纳开发方法(VDM):</b> 一种形式化的开发方法,软件的需求用严格的形式语言描述,然后逐步变换成目标系统 [60b]
<b>数据库设计阶段对应:</b>
概念设计 ←→ 需求分析
逻辑设计 ←→ 概要设计
物理设计 ←→ 详细设计
<b>UML图表与建模:</b>
<b>类图(Class Diagram):</b> 静态结构建模工具,描述系统中的类、接口、关系和属性等元素,显示继承、关联、依赖关系,属性和方法
<b>对象图:</b> 用于描述对象间关系
<b>组件图(Component Diagram):</b> 表示系统构件及其关系的建模工具,描述组件、接口、依赖关系和协作关系
<b>部署图(Deployment Diagram):</b> 表示系统物理架构,展示系统构件的部署方式和物理节点之间的关系(软件和硬件之间的部署)
<b>活动图(Activity Diagram):</b> 行为建模工具,描述系统中的业务流程和操作流程,展示活动顺序、条件和并发关系
<b>顺序图(Sequence Diagram):</b> 交互建模工具,描述系统中不同对象之间的消息传递和交互流程,展示交互顺序和时间顺序
<b>状态图:</b> 主要用于描述系统的动态行为,展示对象在不同状态间的转移以及触发状态变迁的事件
<b>用例图:</b> 用于描述系统功能视图
4. 软件设计与体系结构
<b>软件体系结构 (Software Architecture) 定义:</b> 系统的基本组织结构,包括组件、它们之间的关系、组件与环境之间的关系,以及指导其设计与演进的原则
<b>软件体系结构作用:</b> 为系统提供高层次的抽象,指导系统设计与实现,影响系统的质量属性(如性能、安全性、可维护性等)
<b>软件设计基本原理:</b> 模块化、抽象、信息隐蔽、模块独立性
<b>信息隐蔽:</b> 可定义和实施对模块的过程细节和局部数据结构的存取限制
<b>模块结构图:</b>
总体设计阶段的重要工具
用于描述系统的模块划分以及模块之间的调用关系
展示了系统的总体架构和层次结构
<b>内聚与耦合 (高内聚,低耦合原则):</b>
<b>耦合性:</b> 模块之间的联系越紧密,其耦合性就越强,模块的独立性就越差
<b>最低耦合:</b> 无直接耦合
<b>数据耦合:</b> 一个模块把数值作为参数送给另一个模块
<b>公共耦合:</b> 两个模块内部都使用同一张表
<b>内聚性:</b> 模块内各元素的联系越紧密,其内聚性就越高,模块的独立性就越好
<b>最高内聚:</b> 功能内聚
<b>通信内聚:</b> 一个模块内部各程序段都在同一张表上操作
<b>面向对象设计中内聚:</b> 操作内聚、类内聚、泛化内聚(一般-具体内聚)
<b>概要设计阶段:</b> 产生概要设计说明
<b>详细描述处理过程常用工具:</b> 过程设计语言、判定表、判定树
<b>设计模式:</b>
针对在软件设计中反复出现的问题,总结出的一套最佳实践解决方案
目的不是直接提高程序运行效率或减少代码量
而是为了提升软件的可读性、可维护性以及系统的灵活性和可扩展性,使代码易于理解、修改和复用
<b>HIPO (Hierarchy plus Input/Processing/Output):</b>
全称:“层次图+输入/处理/输出”
H图即层次图
<b>结构化程序设计 (SP):</b>
<b>本质:</b> 使程序的控制流程线性化,实现程序的动态执行顺序符合静态书写的结构,从而增强程序的可读性
<b>设计要点:</b> 使用三种基本控制结构,自顶向下逐步求精构造算法
<b>三种基本控制结构:</b> 顺序结构、选择(分支)结构、重复(循环)结构
<b>PAD图:</b> 一种算法描述工具,它是一种由左往右展开的二维树型结构
<b>编码风格有关因素:</b>
源程序文档化
数据说明
语句构造
输入和输出
程序效率
5. 软件过程与项目管理
<b>软件生存周期过程 (ISO/IEC 12207-1995标准):</b>
<b>划分原则:</b> 各阶段的任务尽可能相对独立,同一阶段各项任务的性质尽可能相同
<b>a. 基本过程:</b> [27a]
获取过程
供应过程(意图是为获取方提供满足所协商需求的产品或服务)
开发过程
运行过程
维护过程
<b>b. 支持过程:</b> [27b]
文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程、问题解决过程等
<b>c. 组织过程:</b> 管理过程、基础设施过程、培训过程和改进过程 [27c]
<b>剪裁过程意图:</b> 使该过程满足围绕一个组织、影响一个项目和反映一个组织的需要这些特定情况
<b>软件过程模型:</b>
<b>瀑布模型:</b> 将生存周期各活动规定为依线性顺序联接的若干阶段的模型
<b>喷泉模型:</b> 一种以用户需求为动力,以对象为驱动的模型
<b>UP (Unified Process) 统一过程模型:</b>
<b>特点:</b> 以用例为驱动、以体系结构为中心、迭代和增量的软件开发过程
<b>5个工作阶段:</b>
<b>a. 起始阶段:</b> 包括客户沟通和策划活动。识别基本的业务需求,并用用例初步描述每一类用户所需要的主要特征和功能 [38a]
<b>b. 细化阶段:</b> 包括沟通和通用过程模型的建模活动。扩展了起始阶段定义的用例,并创建了体系结构基线以包括5种模型:用例模型、分析模型、设计模型、实现模型和部署模型。该阶段通常要对项目计划进行修订 [38b]
<b>c. 构件阶段:</b> 与通用软件过程中的构建活动相同。在源代码中实现软件增量(如发布的版本)所要求的必须具备的特征和功能 [38c]
<b>d. 转换阶段:</b> 包括通用构建活动的后期阶段以及通用部署(交付和反馈)活动的第一部分。软件被提交给最终用户进行Beta测试,用户反馈软件存在的缺陷,提出必要的变更 [38d]
<b>e. 生产阶段:</b> 与通用过程的部署活动一致。在该阶段,对持续使用的软件进行监控,提供运行环境的支持,提交并评估缺陷报告和变更请求 [38e]
<b>RUP (Rational Unified Process):</b>
<b>阶段与迭代:</b> 包括初始、细化、构造和移交4个阶段,每个阶段又分为若干次迭代
<b>核心工作流:</b> 每次迭代都有一个核心工作流,包括5个活动:需求、分析、设计、实现和测试
<b>设计模型主要内容:</b> 包含了多个衍型类,依赖于实现语言、比较形式化、结构层次多、动态的,但更多关注定序方面等
<b>CMMI (Capability Maturity Model Integration):</b>
<b>全称:</b> 能力成熟度集成模型
<b>成熟度等级:</b>
<b>a. 1. 初始级:</b> 软件过程是无序的,有时甚至是混乱的,对过程几乎没有定义,成功取决于个人努力。管理是反应式的 [118a]
<b>b. 2. 已管理级:</b> 建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功经验 [118b]
<b>c. 3. 已定义级:</b> 已将软件管理和工程两方面的过程文档化、标准化,并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件,软件产品的生产在整个软件过程是可见的 [118c]
<b>d. 4. 量化管理级:</b> 分析对软件过程和产品质量的详细度量数据,对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据,管理能够在定量的范围内预测性能 [118d]
<b>e. 5. 优化管理级:</b> 过程的量化反馈和先进的新思想、新技术促使过程持续不断改进 [118e]
<b>子实践:</b>
定义:对专用实践、共用实践的详细描述,为解释和实现一个专用实践或共用实践提供指导
<b>软件项目管理 (Software Project Management) 范围:</b> 涉及软件项目的计划、组织、领导和控制,以实现在限定的时间、成本和质量目标内交付软件产品
<b>软件项目管理关键领域:</b> 项目计划、项目调度、风险管理、人员管理、质量管理等
<b>估算规模的工作产品类型:</b>
可交付的和不用交付的工作产品 [42a]
文档和文件 [42b]
运行和支持的硬件、固件和软件 [42c]
<b>文档:</b>
定义:有关计算机程序功能、设计、编制、使用的文字或图形资料
<b>软件配置管理 (Software Configuration Management, SCM) 定义:</b> 对软件开发过程中产生的配置项(如源代码、文档、数据等)进行标识、版本控制、变更管理和状态报告的过程
<b>软件配置管理目的:</b> 确保软件产品的完整性、追踪性和可控性,管理软件变更,支持团队协作
6. 面向对象技术
<b>对象的抽象:</b> 是类
<b>类的具体化:</b> 就是对象
<b>类属性:</b> 对象的状态的抽象,用数据结构来描述
<b>类操作:</b> 对象的行为的抽象
<b>类之间结构关系:</b>
<b>一般——具体关系(泛化关系):</b> 如汽车与小汽车
<b>继承性:</b> 面向对象程序设计语言的最主要特点,这是其他语言没有的
<b>整体——部分关系(聚集关系):</b> 关系中有整体类和部分类之分,如汽车与发动机
<b>关联:</b> 有方向的,可以用一个实心三角形来指示关联的方向
7. 软件测试与质量保障
<b>软件测试定义:</b>
根据软件开发各阶段的规格说明和程序内部结构而精心设计测试用例,利用这些测试用例运行程序,以发现程序中潜在错误的过程
为了发现程序中的错误而执行程序的过程
<b>软件测试目的:</b> 在于发现错误。一个好的、成功的测试是能够发现至今未被发现的错误
<b>软件测试目标:</b> 以最少的时间和人力找出软件中潜在的尽可能多的各种错误和缺陷
<b>软件测试步骤:</b>
单元测试(模块测试)
组装测试(集成测试)
确认测试
系统测试
<b>软件测试方法分类:</b>
<b>静态测试法:</b> 被测试程序不在机器上运行而采用人工分析检测或计算机辅助分析检测
<b>动态测试法:</b> 使被测试程序在机器上运行的测试方法
<b>黑盒法:</b> 主要测试程序功能,检查程序是否满足功能要求
集成测试最常用的是黑盒技术,确认测试仅使用黑盒技术
<b>白盒法:</b> 测试程序的内部逻辑是否正确,测试程序内部结构及处理过程的方法
单元测试大量使用白盒技术;集成测试也可能使用一定数量的白盒技术
白盒测试中常见的5种路径类型
<b>测试覆盖率策略 (偏序关系,从弱到强):</b>
语句覆盖
分支覆盖
条件组合覆盖
路径覆盖
<b>路径测试技术支持的测试覆盖:</b> 语句覆盖、分支覆盖、条件组合覆盖和路径覆盖
<b>软件质量要素评价准则:</b>
<b>a. 可审查性:</b> 检查软件需求、文档、过程、标准等是否一致的难易程度
<b>b. 准确性:</b> 计算和控制的精确程度
<b>c. 简明性:</b> 程序源代码的紧凑程度
<b>d. 简单性:</b> 程序易于理解的程度
<b>e. 通信通用性:</b> 使用标准接口、协议和带宽的程度
<b>f. 数据通用性:</b> 在程序中使用标准数据结构和类型的程度
<b>g. 容错性:</b> 在各种异常情况下软件能继续提供操作的能力
<b>h. 执行效率:</b> 软件运行效率
<b>i. 通用性:</b> 程序潜在应用领域的多少
<b>j. 硬件独立性:</b> 软件与其运行的硬件环境无关的程度
<b>k. 检测性:</b> 程序监视自身运行并标识错误的程度
<b>l. 可操作性:</b> 操作该软件的难易程度
<b>m. 可扩充性:</b> 结构、数据、过程等设计可以扩充的程度
<b>n. 安全性:</b> 控制或保护程序和数据不被破坏、非法访问等机制的能力
<b>o. 自文档化:</b> 源代码提供自身说明文档的程度
<b>p. 软件独立性:</b> 软件与非标准编程语言特征、操作系统特征等软件环境约束无关的程度
<b>q. 易培训性:</b> 软件对使用它的新用户的支持程度
<b>r. 完全性:</b> 整个软件系统不丢失任何重要的成分,软件完全实现系统所需的功能、行为和性能
<b>s. 一致性:</b> 整个软件系统均使用统一的符号、概念和术语
<b>t. 模块化:</b> 模块是程序中一个逻辑上相对独立、具有良好的接口定义的编程单位:过程、函数、类、程序包等
<b>u. 可追踪性:</b> 对软件进行正向和反向追踪的能力
<b>度量可维护性软件特性方法:</b> 质量检查表、质量测试(用于定量分析和评价)、质量标准(用于定量分析和评价)
<b>代码审查:</b> 一种质量保证活动,通过人工或自动化工具检查源代码的风格、结构、规范性以及潜在缺陷,提升代码质量和维护性
<b>变更控制:</b> 对软件开发过程中产生的变更请求进行有效管理,确保变更经过适当审批、评估影响、规划实施和跟踪验证,最小化变更对软件质量和项目进度的不利影响
<b>衡量性能的四个指标:</b>
周转时间
响应时间
吞吐量
精度
<b>软件安全性 (Software Security) 定义:</b> 保护软件系统免受攻击、损害或未经授权的访问的能力,确保数据的保密性、完整性和可用性
<b>软件安全性关注点:</b> 识别和消除软件漏洞、实施安全机制(如身份验证、授权)、安全编码实践、安全测试、安全架构设计等
<b>软件可靠性 (Software Reliability) 定义:</b> 软件在给定时间内,在给定环境下,无故障运行的概率 [11biv]
<b>软件可靠性度量:</b> 平均无故障时间 (MTTF)、失效率等
<b>软件可靠性提升方法:</b> 容错设计、严格测试、冗余、可靠性模型分析 [11biv]
8. 软件维护与运维
<b>软件维护分类:</b>
改正性维护
适应性维护:为使软件适应其运行环境变化而修改软件的过程
完善性维护:为使软件增加功能、增强性能、提高效率而修改软件的过程;往往占据最大的工作量(约占整个维护活动的50%)
预防性维护
<b>软件运行与运维 (Software Engineering Operations / DevOps) 定义:</b> 一种文化和实践集合,旨在统一软件开发 (Dev) 和软件运维 (Ops),通过自动化和流程优化,提高软件交付的速度、效率和可靠性
<b>DevOps核心实践:</b> 持续集成 (CI)、持续交付 (CD)、持续部署 (CD)、监控与日志、自动化测试等
<b>DevOps目的:</b> 缩短发布周期、提高部署频率、减少故障率、更快地恢复服务
9. 软件复用
<b>定义:</b> 在新的软件系统开发中,有目的地使用已有的、领域相关的软件构件、资产或经验
<b>目的:</b> 提高开发效率、降低成本、提升软件质量和可靠性
<b>方法:</b> 代码复用、组件复用、模式复用、服务复用(如云服务)等
0 条评论
下一页