电子科技大学 软件工程 期末考试
需积分: 12 128 浏览量
2022-08-19
09:38:11
上传
评论
收藏 1.67MB PDF 举报
软件工程
软件工程介绍
软件过程模型
期末考试
概论（8）
软件过程（8）
需求分析（18）
软件设计（10）
生产率和工作量度量（8）
软件测试（25）
测试策略（10）
软件维护（8）
项目管理（5）
软件的定义
软件过程模型的定义
软件工作量度量（基于功能点和基于代码估算，比较不同和优缺点）。。
软件的特点
软件的双重作用
软件危机的概念
软件工程的概念
软件工程的目标与原则
软件工程中的一些误解
将系统化的、科学化的、可量化的方法用于软件的开发、运行和维护，即针对软件
的工程应用
- 是逻辑的
- 开发是工程化不是制造
- 开发环境对产品影响大
- 开发时间和工作量难估计
- 会多次修改
- 开发进度无客观衡量标准
- 测试难
- 不会磨损老化
- 维护易产生新问题
- 生产是简单的拷贝
软件 = 程序 + 数据 + 文档
程序：按事先设计的功能和性能需求执行的指令序列
数据：是程序能正常操纵信息的数据结构
文档：与程序开发、维护和使用有关的图文材料
软件既是一个产品也是开发其他软件的工具
支持或直接提供系统所需的功能
控制其他程序：如操作系统
改善通信：如网络软件
帮助开发其它软件：如软件开发工
在计算机软件开发和维护过程中遇到的一系列严重问题（效率、质量）
目标
在给定时间和预算内，按照用户需求，开发易修改、高效、可靠、
可维护、适应力强、可移动、可重用的软件
原则
- 使用阶段性生命周期计划的管理
- 进行连续的验证
- 保证严格的产品控制
- 使用现代编程工具/工程实践
- 保持清晰的责任分配
- 用更好更少的人
- 保持过程改进
管理者
客户
开发者
1. 书的知识点可能与实际情况不匹配
2. 人多不一定就干的快
3. 外包公司不一定懂得如何从内部管理和控制项目
1. 以为后期增加需求很容易实现
1. 以为完成运行了就ok了
2. 程序运行前无法评估其质量
3. 成果不止一个可运行的软件
4. 认为文档不重要
软件工程的中心和三要素
软件生存期模型
瀑布模型
快速原型模型
增量模型
螺旋模型
如何选择过程模型
能力成熟度模型集成五个级别的名字、每个级别的侧重点
过程和产品的关系
是软件开发全部过程、活动和任务的结构框架
概述
优点
缺点
概述
优点
缺点
概述
优点
缺点
优点
缺点
适用
概述
与软件生命周期一致，以固定次序逐级下落，以文档为驱动的模型
适用
适用
适用
系统需求明确、技术成熟、工程管理较严格的场合
- 简单，过程透明性高、可管理性高
- 推迟实现
- 阶段评审和文档控制对质量控制
- 灵活性差
- 风险控制能力弱
- 大量的文档增加了工作量
模拟要开发的系统的原始模型，反应系统的一些重要特征
- 强调用户参与和决策
- 加快需求的确定
- 简化项目的管理、缩短开发时间、降低开发风险
- 客户定义一个总体目标集，但是他们并不清楚系统的具体输入输出
- 或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式
- 软件可维护性差
- 用户合作性要求高
- 不适合开发大型系统
- 不需要提供完整的需求
- 不需要投入太多的人力资源
- 有效管理技术风险
- 增加客户信心
- 增量粒度难以选择
- 确定所有基本业务困难
原型模型+迭代的特征，采用了基于时间的线性序列，每个确定线性序列都会输出
该软件的一个“增量”
需求不明确的大型软件系统
结合瀑布模型+原型模型
- 支持需求的动态变化
- 原型可看作可执行的需求规格说明书
- 强调原型的可扩充性和可修改性
- 降低开发风险
- 增加成本并推迟提交时间
- 要求开发队伍水平较高
模型是不断发展的，每个模型都有各自的优缺点，不必拘泥与某种模型，可组合多
种模型，可以创建新的模型
中心 质量
三要素 过程+方法+工具
1：初始级：持续的过程改进
2：可重复级：量化管理
3：已定义级：过程标准化
4：已管理级：基本项目管理
5：优化级：有能力的人和个人英雄主义
软件过程决定了软件产品的质量
一部分
二部分
三部分
需求的定义
需求的特征
功能性需求(进一步划分为哪些需求，可参考惠普的公司的FURPS，教材p46）
非功能性需求(进一步划分为哪些需求，可参考惠普的公司的FURPS，教材p46）
需求分析的四个步骤
需求变更的必要性
结构化分析方法的分析策略
结构化分析建立的模型以什么为核心
围绕该核心建立的三种图及对应的规格说明的名字
面向对象的分析建立的三大模型
一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的
陈述的一个集合（制定一个开发大纲）
- 可验证
- 可量化
- 优先级
描述系统应该做什么，即为用户和其它系统完成的功能、提供的服务
必须遵循的标准，外部界面的细节，实现的约束条件，质量属性等等
- 需求获取
- 需求提炼
- 需求描述
- 需求验证
遵循需求变更控制规程实施
成本估算的方法之一
cOCOMO模型
基于功能点
基于代码估算
优点
- 简单实用
- 能在项目早期进行规模度量
- 比其他方法客观
优点
LOC、KLOC和相关度量容易计算
许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入
有大量的关于LOC的文献和数据
缺点
LOC依赖于使用的语言，这对短小精悍的程序不利
不太适用于非过程化语言
LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很
难获得
软件测试的基本原则
软件测试的目标
测试用例的设计应力求达到什么目的
软件缺陷、调试与测试的相同点与不同点
测试用例的定义
测试与质量的保证
软件测试人员的目标是什么
软件质量保证人员的主要职责是什么
软件测试的评估准则
覆盖率
故障插入
变异分值
覆盖率 = 测试集合T / 测试需求集合TR
黑盒测试
白盒测试
灰盒测试
静态测试
范围
目的
基本思想
三种评审类型
忽略系统或组件内部机制，仅关注于那些特定输入响应及响应执行条件的输出测试
考虑系统或组件内部机制的测试
黑白盒混合方法
- 同事审查
- 走查
- 审查
不实际运行程序，通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术
- 对代码标准及质量的监控
- 对源代码的检查
- 代码审核
- 检查需求
- 检查设计
- 检查代码
- 满足预期
- 解决所需解决的问题
- 建立责任和可解释性
- 及早发现异常
- 性能评估
- 管理提供真实信息
- 异常集聚之处
- 决定哪些更重要
- 不能保证没有错误
- 越早发现修改成本越低
- 一个问题出错导致多个错误现象出现
- 用一样的测试用例是不可取的
- 自己测试自己是不可取的
找出软件可能存在的缺欠
相同点 都包含有处理软件缺陷和查看代码的过程
不同点
- 测试的目标是发现软件缺陷的存在
- 调试的目标是定位与修复缺陷
是测试输入、执行条件，以及预期结果的集合（是为特定的目的开发的）
尽早找出软件缺陷，并确保缺陷得以修复
创建和执行改进软件开发过程并防止软件缺陷发生的标准和方法
定义
定义
定义
三种方法
等价类划分
边界值分析
状态测试
把所有可能的输入数据划分成若干部分，然后从每一部分中选取少数有代表性的数
据做为测试用例
测试用例
选边界值来测试
一种基于模型测试，用状态图来描述时间序列，由此产生测试用例
基本选择覆盖方法
各种覆盖准则
基本路径测试 测试用例
控制流图
计算环路复杂性
语句覆盖
选择足够多的测试数据，使被测程序中每个语句至少执行一次
分支覆盖
选择足够多的测试数据，使被测程序中每个判断的取真分支和取假分支至少经历一次
条件覆盖
选择足够多的测试数据，使被测程序中每个判断的每个条件的可能取值至少执行一
次
条件组合覆盖
选择足够多的测试数据，使被测程序中每个判断的所有可能的条件取值组合至少执
行一次
V(G) = e − n + 2
n为节点数，e为图中边数
自顶向下逐步求精
数据字典
三种图（会画数据流图）
实体关系图
数据流图
状态迁移图
数据对象描述
加工规格说明
控制规格说明
功能建模
行为建模
数据建模
用例图由哪三个元素构成
用例模型
对象模型
动态模型
UML中的 用例图
UML中的 类图
UML中的 状态图+交互图
用户
参与者
关系
用户与计算机系统完成一次交互作用，代表系统的一个完整功能
与系统交互的人或物，代表外部实体
参与者与用例之间的关系（泛化、包含、扩展）
软件设计包含的两类活动
创新设计不属于软件设计
软件的质量属性
模块化为什么不能无限划分模块？
信息隐藏原则的定义
重构的定义
抽象
设计模式
功能独立
细化
软件架构设计
软件详细设计
- 功能性
- 易用性
- 可靠性
- 性能
- 可支持性
忽略具体的信息，将不同的事物看成相同的事物
逐步求精的过程
在给定上下文环境中，一类共同问题的共同解决方案
各种设计技术
- 模块彼此相互隐藏
- 保证模块内信息不可以被不需要这些信息的其他模块访问
每个模块只解决需求中特定子功能，并作为简单的接口
简化组件设计的一种重组技术
模块过多导致集成成本增加
程序结构
深度
宽度
扇入数
扇出数
程序结构的层次数
层次结构中同一层模块的最大模块个数
调用一个给定模块的模块数
一个模块直接调用其他模块的个数
信息隐蔽原则有利于提高模块的内聚性
完整的设计规格包括哪四种设计模型
软件体系架构
- 数据中心架构
- 数据流体系架构
- 调用和返回架构
- 面向对象架构
- 层次架构
客户机/服务器（C/S） 基于资源不对等，为实现共享，由服务器、客户机、网络组成
浏览器/服务器（B/S）
三层体系结构的一种实现方式
用户界面设计
- 用户为中心
- 减少用户记忆负担
- 保持界面一致三条原则
三种分析内容
- 人机交互
- 操作逻辑
- 界面美观
结构化程序设计
概念
详细设计
流程图 缺点
代码仅通过顺序、选择、循环三种基本控制结构进行连接，且每个代码块只有一个
入口和一个出口
流程图
伪代码
NS图
PAD图
- 不是逐步求精的好工具
- 可以不顾结构程序设计的精神，随意转移控制
- 表示数据结构方面存在不足
一部分
二部分
改进的V模型
四个级别的测试的主要目的
回归测试
回归测试可以在所有的测试级别进行，并能够应用于功能和非功能测试中
回归测试应尽量采用自动化测试
桩模块
驱动模块
替代被测模块
调用被测模块
单元测试的主要内容
模块接口
1.
边界条件
3.
选择适当的测试用例，对模块中重要的执行路径进行测试。
独立路径
4.
出错处理
5.
局部数据结构
2.
为什么单元测试依据不是代码？
因为其测试的不仅有代码
集成测试
自顶向下集成方法
自底向上集成方法
SMOKE方法
定义
优点
缺点
定义
优点
缺点
将模块按系统程序结构，沿控制层自顶向下进行集成
- 验证了主要控制和判断点
- 实现和验证一个完整的软件功能
桩的开发量较大
从软件结构最底层模块开始，按照接口依赖关系逐层向上集成
每个底层模块都已经测试，无需桩模块
- 每个模块都需编写驱动模块
- 缺陷的隔离和定位不如自顶向下
定义
优点
缺点
是一种预测试，能快速验证基本功能
节省测试时间，防止构造失败
覆盖率低
广度优先
先找完同级再往下找
深度优先
先找完全部子级
系统测试
基本概念
主要内容
从用户的角度，在真实的运行环境下测试
- 功能性测试
- 性能测试
- 压力测试
- 恢复测试
- 安全测试
验收测试
基本概念
主要形式
- 根据合同进行的验收测试
- 用户验收测试
- 现场测试
由用户参加设计测试用例，使用生产中的实际数据进行测试
α测试
β测试
一个用户在开发环境或开发人员在模拟实际操作环境下进行测试
多个用户在实际使用环境下进行测试
软件维护
定义
类型
对代码和相关文档进行修改并保持其完整性
- 纠错性维护
- 适应性维护
- 完善性维护
- 预防性维护
必要性
困难性
在维护阶段的最初一段时期，纠错性维护的工作量较大，随着错误发现率逐渐降低
并趋于稳定，适应性维护和完善性维护的工作量逐步增加
可维护性
定义
决定因素
纠正软件系统出现的错误，以及对新要求修改的容易程度
- 可理解性
- 可使用性
- 可测试性
- 可修改性
- 可移植性
- 效率
- 可靠性
过程模型
估算维护工作量的模型
软件再工程
定义
流程
软件逆向工程
定义
方面
对现有软件重新构造
软件开发过程的逆过程
- 代码重构
- 提取抽象
- 求精简化
软件需求分析和开发方法的缺陷
软件管理
要素
团队组织方式
虚拟团队
定义
优点
缺点
策划一个项目之前，需要做哪些事？
项目估算的方法
- 分解技术
- 经验模型
软件范围
- 人员
- 产品
- 过程
- 项目
- 民主分权制（DD）
- 有控制的分权制（CD）
- 有控制的集中制（CC）
在不同地域、空间的个人通过各种各样的信息技术来进行合作
- 提高生产力
- 扩大市场机会
- 知识转移
- 沟通不足
- 领导不力和管理
- 不称职的团队成员
功能、性能、约束、接口和可靠性
- 有目标
- 有生命周期
- 任务可分解
- 有客户
- 有资源
- 有不确定因素
需求确定，工作能够采用线性的方式完成的软件
- 数据设计
- 架构设计
- 接口设计
- 组件设计
缺点 - 计算结果带有主观性，不直观
单元测试：验证软件模块是否按设计规格正确执行
集成测试：检查多个模块间是否按照概要设计协同工作
系统测试：验证整个系统是否满足需要规格
验收测试：从用户的角度检查系统是否满足合同需求
评论0