软件工程
2019-12-25 10:37:53 1 举报AI智能生成
软件工程期末复习详细思维导图
作者其他创作
大纲/内容
软件工程
第二章 软件过程模型
软件过程与过程模型定义
软件过程定义：开发和维护软件及其相关产品所涉及的一系列活动。
软件过程模型定义
它是软件开发全部过程、活动和任务的结构框架。
它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。
软件过程模型也常称为：软件开发模型、软件生存周期模型、软件工程范型。
各过程模型特点、优缺点、适用场合
瀑布模型 (经典的生命周期模型)
特点
适用场合：瀑布模型适用于系统需求明确、技术成熟、工程管理较严格的场合
优缺点
演化过程模型
原型模型
适用情况
并行开发模型
基于构件模型
增量过程模型
增量模型
RAD
适用范围：管理类信息系统开发
螺旋模型
优点
缺点
适用场合
其他过程模型
智能模型
敏捷过程模型
第四章 软件设计工程
主要技术、主要内容、主要方法
抽象
含义：是感性认识世界的手段，是“忽略具体的信息将不同事物看成相同事物的过程”，是发现实物本质特征和方法的过程
抽象机制：参数化、规范化
规范化抽象：过程抽象，数据抽象，控制（迭代）抽象
设计模式
含义
目的：为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性
范围：由面向对象的程序构造，到(可视化的)对象框架构建
模块化
含义：软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求
软件的模块性：程序可被智能管理的单一属性
模块化的理论依据：基于人类解决问题观测数据
功能独立
含义：每个模块只解决了需求中特定的子功能并从程序结构的其他部分看该模块具有简单的接口
好处
易于开发：功能被划分，接口被简化
易于维护（和测试）：次生影响有限，错误传递减少，模块重用
细化
含义：逐步求精的过程
与抽象的关系
抽象使设计师确定过程和数据，但不局限于底层细节
细化有助于设计者在设计过程中揭示底层细节
重构
含义：不改变组件功能和行为条件下简化组件设计（或代码）的一种重组技术
方法：检查现有设计的冗余情况、未使用的设计元素、无效或不必要的算法、较差的构建方式或不恰当的数据结构，或任何其他可更改并导致更好设计的错误
模块独立标准
功能独立含义：每个模块只解决了需求中特定的子功能并从程序结构的其他部分看该模块具有简单的接口
定性衡量标准
内聚性：模块的功能相对强度
耦合性：模块之间的相互依赖程度
模块数量的确定
模块化含义：软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求
第七章 测试技术
软件测试
定义
在特定的条件下对系统或组件进行观察或记录结果，对系统或组件的某些方面进行评估的过程
分析软件各项目以检测现有的结果和应有结果之间的差异（即软件缺陷），并评估软件各项目特征的过程
目标
静态分析法
主要方法
黑盒测试
含义：黑盒测试指忽略系统或组件的内部机制，仅关注于那些特定输入响应及相应执行条件的输出测试，也称功能性测试
目的
主要测试方法
等价类划分方法
含义+步骤
等价类
例子
边界值分析方法
边界含义及选取
原因及例子
状态测试
必要性及含义及步骤
白盒测试
含义：白盒测试指考虑系统或组件内部机制的测试（如分支测试、路径测试、语句测试等），也称结构性测试
逻辑覆盖测试：以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。
语句覆盖：是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次
分支覆盖：是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次
条件组合覆盖：是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次
控制流图覆盖测试：将代码转变为控制流图，基于其进行测试的技术。它属于白盒测试
注意
分类
节点覆盖：即对于图G 中每个语法上可达的节点，测试用例所执行的测试路径的集合中至少存在一条测试路径访问该节点
边覆盖：即对于图G 中每一个可达的长度小于等于1 的路径（即一条边），测试用例所执行的测试路径集合中至少存在一条测试路径经过该路径（该边）
路径覆盖测试：是设计足够的测试用例，覆盖程序中所有可能的路径
基本路径测试
详细介绍
续上图
灰盒测试：黑盒和白盒测试混合方法
第八章 软件测试策略
各测试过程概念、内容
单元测试
介绍
进出入条件
单元测试用例的设计
单元测试的环境
图解
主要内容
模块接口测试
测试项目
内外存交换时应考虑
局部数据结构测试
内容
路径测试
错误处理测试
边界测试
集成测试
集成测试用例的设计
集成测试的主要方法
自顶向下的集成方法
含义+优缺点
自底向上的集成方法
含义+特点+优缺点
注：在实际工作中，常常是综合使用自底向上和自顶向下的集成方法
SMOKE方法
含义+内容
系统测试
为什么还要进行系统测试？
系统测试的主要内容
功能测试
含义：在规定的一段时间内运行软件系统的所有功能，以验证这个软件系统有无严重错误
可靠性测试
强度测试
含义+例子
续前图
性能测试
含义+表现
恢复测试
启动／停止测试
目的+例子
配置测试
含义+包括类型
安全性测试
目的及破坏方法
接上图
验收测试
验收测试的主要形式
根据合同进行的验收测试
用户验收测试
现场测试
α测试和β测试
α测试
目的及时间
β测试
第一章 软件工程概述
软件、软件工程定义
软件定义： 软件=程序+数据+文档
程序：按事先设计的功能和性能需求执行的指令序列。
数据：是程序能正常操纵信息的数据结构。
文档：与程序开发、维护和使用有关的图文材料。
软件的性质：复杂性、难以描述性、不可见性、变化性。
软件工程定义
将系统化的、科学化的、可量化的方法应用于软件的开发、运行和维护，即针对软件的工程应用。以及对上述应用方法的研究。
软件工程三个要素：方法、工具、过程。
软件危机定义、表现
软件工程危机定义：在计算机软件的开发和维护过程中所遇到的一系列严重问题。
软件危机的具体表现（周期长、成本高、质量差、维护难）
开发成本和进度估计不准，开发进度难以控制
用户对“已完成的”软件系统不满意
软件质量和可靠性差强人意
软件常常是不可维护的
软件通常没有适当的文档资料
软件成本逐年上升
软件开发生产率滞后于硬件和计算机应用普及
软件工程原则
使用阶段性生命周期计划的管理
进行连续的验证
保证严格的产品控制
使用现代编程工具/工程实践
用更好更少的人
保持过程改进
保持清晰的责任分配
第三章 需求分析
需求分析过程、步骤
需求分析过程
需求分析的步骤
需求获取
需求的类型
功能性需求：描述系统应该做什么
非功能需求：必须遵循的标准
有几种原因使需求分析变得困难：（1）客户说不清楚需求；（2）需求自身经常变动；（3）分析人员或客户理解有误。
需求提炼
分析建模
结构化分析模型
结构化思维
分解论基础：化简复杂系统的简单方法是分解，将系统分解为不同的部分，各个击破
面向对象分析模型
需求描述
需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。
需求验证
对需求文档进行检查
有效性检查：检查不同用户使用不同功能的有效性。
一致性检查：在文档中，需求不应该冲突。
完备性检查：需求文档应该包括所有用户想要的功能和约束。
现实性检查：检查保证能利用现有技术实现需求。
结构化分析策略：自顶向下逐步求精
结构化分析方法
UML用例图
数据流图
第五章 软件生产率和工作量度量
软件生产率测量
直接测量：如在一个特定时间内产生的代码行数
面向规模的度量标准
基于代码行数的度量方法的优缺点
间接测量 ：如一个给定时间内生产出的功能点和目标点
功能点计算方法
功能点度量标准
代码行数和功能点之间的关系依赖于编程语言
项目工作量测量
算法成本模型—基于经验的度量
通过任务分解度量项目工作量
通过目前可用的资源估算项目工作量
第九章 软件维护
软件维护的定义及必要性
定义：软件维护是指由于软件产品出现问题或需要改进而对代码及相关文档的修改，其目的是对现有软件产品进行修改的同时保持其完整性
必要性
软件维护的类型
纠错性维护
适应性维护
完善性维护
预防性维护
0 条评论
回复 删除
下一页
