导图社区 软件工程
- 857
- 56
- 7
- 举报
软件工程
软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件,以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。
编辑于2021-06-16 10:54:04- 相似推荐
- 大纲
软件工程
2、可依赖性和信息安全性
可依赖系统
设计可依赖性系统时考虑的方面
1.硬件失效
2.软件失效
3.操作失效
可依赖属性
5个维度
1.可用性
2.可靠性
3.安全性
4.信息安全性
5.韧性
开发可靠软件需要做到
1.避免软件规格说明和开发过程中引入意外的错误
2.设计检验和确定过程
3.设计容错机制
4.设计保护机制
5.正确的配置和部署系统以及它的支持软件
6.提高系统能力以识别外部网络攻击并抵抗
7.设计恢复机制
社会技术系统
社会技术系统栈
1.设备层
2.操作系统层
3.通信和数据管理层
4.应用系统层
5.业务过程层
6.组织层
7.社会层
规章和守约
冗余和多样性
实现和提高可依赖性
可依赖的过程
属性
1.可审计
2.多样性
3.可文档化
4.鲁棒性
5.标准化
包括的活动
1.需求评审
2.需求管理
3.形式化规格说明
4.系统建模
5.设计和程序审查
6.静态分析
7.测试规划和管理
形式化方法和可依赖性
可靠性工程
可能性和可靠性
可靠性需求
可靠性度量
1.请求失败概率（POFOD）
2.失败发生率（ROCOF）
3.可用性（AVAIL）
非功能性可靠性需求
刻画可靠性需求时的3条准则
1.针对不同类型的失效定义可用性和可靠性需求
2.针对不同类型的服务定义可用性和可靠性需求
3.考虑是否真的需要高可靠性
功能性可靠性规格说明
1.检查需要
2.恢复需要
3.冗余性需要
4.过程性需要
容错体系结构
保护性系统
自监控系统体系结构
自控系统必须设计成
1.每个通道上使用的硬件都是不一样的
2.在不同的通道上是使用不同的软件
N版本编程
软件多样性
可靠性编程
编程准则
1.限制程序中信息的可见性
2.检查所有输入的有效性
3.为所有异常提供处理程序
4.尽可能不要使用容易出错的结构
5.提供重启功能
6.检查数组边界
7.调用外部构件时加入超时处理功能
8.为每一个代表现实世界值的常量命名
可靠性度量
可靠性测试的统计测试
适用于可靠性测量而不是故障查找
1识别运行概况
2.准备测试数据集
3.对系统进行测试
4.计算观察到的可靠性
运行概况
安全工程
安全关键系统
两大类
1.主要的安全关键软件
2.次要的安全关键软件
利用危险驱动技术来增强这些方法
这些方法指的是：故障避免、故障检测和排除、容错
1.危险避免
2.危险检测和排除
3.限制损失
安全需求
危险识别
危险评估
1.不可容忍的风险
2.低于合理的实际水平风险
3.可接受的风险
危险分析
风险降低
3个可行策略
1.危险避免
2.危险检测和排除
3.灾害限制
安全工程过程
安全保证工程
1.危险日志和监控
2.安全评审
3.安全认证
形式化验证
模型检测
静态程序分析
3个级别检验
1.特有错误检查
2.用户定义错误检查
3.断言检查
安全案例
结构化论证
软件的安全论证
信息安全工程
了解
3个信息安全维度
1.机密性
2.完整性
3.可用性
组织角度信息安全3个层次
1.基础设施信息安全
2.应用信息安全
3.操作信息安全
信息安全和可依赖性
可能出现的4种信息安全威胁
1.拦截威胁
2.中断威胁
3.修改威胁
4.伪造威胁
增强信息安全性
三种基本思想
1.规避
2.检测
3.恢复
控制手段
基于思想
1.漏洞规避
2.攻击检测和压制
3.暴露限制和恢复
其他属性
1.信息安全和可靠性
2.信息安全和可用性
3.信息安全和安全性
4.信息安全和韧性
信息安全和组织
文档化的信息安全策略
1.必须保护资产
2.不同类型资产所要求的保护水平
3.个人用户、管理者和组织的职责
4.现有的信息安全程序和技术
信息安全风险评估
步骤
1.初步风险评估
2.设计风险评估
3.运行风险评估
信息安全需求
风险驱动的信息安全需求阶段
1.资产识别
2.资产价值评估
3.暴露评估
4.威胁识别
5.攻击评估
6.控制识别
7.可行性评估
8.信息安全需求定义
信息安全系统设计
设计风险评估
体系结构设计
考虑两个基本问题
保护
分布
设计准则
1.将信息安全决策建立在明确的信息安全策略之上
2.避免单点失效
3.可恢复性失效
4.寻求信息安全和可用性间的均衡
5.记录用户行为
6.通过冗余性和多样性降低风险
7.验证所有输入
8.划分资产
9.部署设计
10.可恢复性设计
信息安全系统编程
两个重要方面
1.漏洞通常是语言特定的
2.信息安全漏洞与程序可靠性密切相关
可靠的编程准则
1.限制程序中信息的可见性
2.检查所有输入有效性
3.为所有异常提供处理程序
4.最小化易出错结构使用
5.提供重新启动功能
6.检查数组边界
7.调用外部构件时包含超时
8.命名表示真实世界值的所有常量
信息安全测试和保证
1.基于经验的测试
2.渗透测试
3.基于工具的测试
4.形式化验证
韧性工程
系统问题的发现和恢复4个相关韧性活动
1.发现
2.防御
3.恢复
4.复原
网路安全
3类威胁
1.对资产机密性的威胁
2.对资产完整性的威胁
3.对资产可用性的威胁
安全控制
1.身份认证
2.加密
3.防火墙
规划过程中关键阶段
1.资产分类
2.威胁识别
3.威胁发现
4.威胁防御
5.资产恢复
6.资产复原
社会技术韧性
组织韧性的4个特点
1.应对能力
2.监控能力
3.预见能力
4.学习能力
1.为人错误
两个角度
1.人的角度
2.系统的角度
提高系统面对不利的外部事件韧性
1.降低可能触发系统失效的外部事件发生的概率
2.增加防护层数量
3.设计系统时将不同类型的的屏障包含其中
4.尽可能减少系统中潜在隐患的数量
2.运行和管理过程
韧性系统设计
两个相关的工作流
1.识别关键性服务和资产
2.设计支持问题发现、防御、恢复和复原的系统构件
可生存性系统分析
1.系统理解
2.关键性服务识别
3.攻击模拟
4.可生存性分析
韧性工程方法中5个相关联工作流
1.识别业务韧性需求
2.受攻击后复原正常运行状态
3.识别危险和攻击并防御
4.迅速恢复受攻击导致的关键性服务的失效
5.测试韧性规划的所有方面
4、软件管理
项目管理
风险管理
风险识别
1.估算风险
2.组织风险
3.人员风险
4.需求风险
5.技术风险
6.工具风险
风险分析
1.风险出现的可能程度可以是
微乎其微
低
中
高
非常高
2.风险的严重程度可以是
灾难性的（严重威胁项目的存活）
严重的（可能引起很大的延迟）
可以容忍的（可能引起小的延迟）
可以忽略的
风险计划
应对策略
1.规避策略
2.最小化策略
3.应急计划
风险监控
人员管理
激励人员
1.生理需求
2.安全需求
3.社会需求
4.受尊重的需求
5.自我实现的需求
团队协作
成员的挑选
小组的结构
小组的沟通
项目计划
软件报价
影响因素
1.合同条款
2.成本估算的不确定性
3.财务状况
4.市场机遇
5.需求易变性
计划驱动的开发
项目计划
计划过程
项目进度安排
进度安排表示方法
敏捷计划
软件以增量方式进行开发和交付给客户
估算技术
算法成本建模
COCOMO成本建模
应用组合模型
早期设计模型
复用模型
后体系结构模型
项目的工期和人员配备
质量管理
软件质量
属性
信息安全性
可靠性
韧性
鲁棒性
软件标准
ISO 9001标准框架
评审和审查
评审过程
1.评审前活动
2.评审会议
3.评审后活动
程序审查
质量管理与敏捷开发
1.提交之前进行检查
2.决不破坏构建
3.发现问题就修复它
软件度量
产品度量
动态度量
静态度量
软件构件分析
1.选择要做的度量
2.选择要评估的构件
3.度量构件特性
4.识别异常度量
5.分析异常构件
度量歧义
软件解析
配置管理
版本管理（VC）
两种现代版本控制系统
1.集中式系统
2.分布式系统
主要特征：1.版本和发布版本识别； 2.变更历史记录； 3.独立开发； 4.项目支持； 5.存储管理；
系统构建
特征
1.构建脚本生成
2.版本控制系统集成
3.最小化子再编译
4.可执行系统创建
5.测试自动化
6.报告
7.文档生成
3种不同的系统平台
1.开发系统
2.构建服务器
3.目标环境
变更管理
考虑因素
1.不做变更会引起的后果
2.变更的收益
3.变更影响的用户数
4.变更的成本
5.产品发布周期
发布版本管理
1.配置文件
2.数据文件
3.安装文件
4.电子和书面文档
5.包装和相关宣传
3、高级软件工程
软件复用
复用概览
复用的软件单元
1.系统复用
2.应用复用
3.构件复用
4.对象和函数复用
规划复用时的关键因素
1.软件开发进度
2.所期待的软件生命周期
3.开发团队的背景、技能和经验
4.软件的关键性及其非功能性需求
5.应用领域
6.系统在其上运行的平台
应用框架
web应用框架
构件和类支持的功能
1.信息安全
2.动态web页
3.数据库集成
4.会话管理
5.用户交互
其他三种框架
1.系统基础设施框架
2.中间件集成框架
3.企业应用框架
软件产品线
应用系统复用
可配置的应用系统
特性
1.若干支持不同业务功能的模块
2.与每个模块相关联的一组定义好的业务过程模型，它们与模块中的活动相关
3.维护所有相关业务功能的信息的通用数据库
4.适用于数据库中所有数据的一组业务规划
集成的应用系统
4个重要的系统集成问题
1.对功能和性能缺少控制
2.系统互操作性的问题
3.无法控制系统演化
4.来自系统供应商的支持
基于构件的软件工程
了解
基于构件软件工程的要素
1.完全有接口进行规格说明的独立构件
2.构件标准使构件集成变的更加容易
3.开发过程适合基于构件的软件工程
基本的CBSE设计原则
1.构件时独立的，不影响彼此操作
2.构件通过良好定义的接口进行交互
3.构件基础设施提供可用在应用系统的标准服务
构件和构件模型
构件模型
定义了构件实现、文档化及开发标准
基本要素
1.接口
2.使用信息
3.部署
提供的两种服务
1.平台服务
2.支持服务
CBSE过程
CBSE是定义、实现、集成或者组装 松散耦合的独立构件成为系统的过程
面向复用的CBSE
基于复用的CBSE
过程是：构件获得；构件管理； 构件认证。
构件组装
组装方法
1.顺序组装
2.层次组装
3.叠加组装
3种不兼容的情况
1.参数不兼容
2.操作不兼容
3.操作不完备
分布式软件工程
5个优势
1.资源共享
2.开放性
3.并发性
4.可伸缩性
5.容错性
分布式系统
重要的设计问题
1.透明性
2.开放性
3.可伸缩性
1.规模
2.分布
3.可管理性
4.信息安全性
5.服务质量
6.失效管理
交互模式
过程式交互
基于消息的交互
中间件
提供两种支持
1.交互支持
2.提供公共服务
客户 - 服务器计算
表示层
数据管理层
应用处理层
数据库层
分布式系统的体系结构模式
主从体系结构
两层客户 - 服务器体系结构
瘦客户机模型
胖客户机模型
多层客户 - 服务器体系结构
分布是构件体系结构
好处
1.允许系统设计者延迟决定在哪里和如何提供服务
2.是一个非常开放的体系结构
3.系统具有很好的灵活性和可伸缩性
4.通过构件在网络上的迁移达到对系统的动态配置是有可能的
缺点
1.其设计比客户 - 服务器系统更复杂
2.分布式构件模型或中间件没有通用标准
对等体系结构
适用于
1.系统是计算密集的
2.系统主要涉及个人计算机在网络上的信息交换
软件即服务
面向服务的软件工程
面向服务的体系结构
SOA中的服务构件
RESTful服务
资源是RESTful体系结构中的基本元素
资源有一个唯一标识符，URL
资源的4种基本的多态操作
1.创建-创建资源（POST）
2.读取-返回资源的一种表现形式(GET)
3.更新-改变资源的值(PUT)
4.删除-使资源不可访问(DELETE)
网络协议http和https 都是基于这四种动作
服务工程
可选服务识别（Erl）
实用服务
业务服务
协同或过程服务
服务接口设计
服务实现和部署
服务组合
通过组合构建服务的过程的6个阶段
1.表达概要工作流程
2.发现服务
3.选择可能的服务
4.精炼工作流
5.创建工作流程序
6.测试已完成的服务或应用
工作流设计与实现
服务组合测试
系统工程
社会技术系统
涌现特性
功能性涌现特性
非功能性涌现特性
不确定性
成功准则
概念设计
系统采购
3种类型的系统或系统构造可能必须购买
1.无须修改就可以使用的第三方成品应用
2.必须通过修改代码或者使用内建的配置特性进行修改或适配
3.必须特别设计和实现才能使用的定制化系统
系统开发
1.需求工程
2.体系结构设计
3.需求划分
4.子系统工程
5.系统集成
6.系统测试
7.系统部署
系统运行和演化
系统演化
系统之系统
系统复杂度
1.系统的技术复杂度
2.系统的管理复杂度
3.系统的治理复杂度
系统之系统的分类
受控系统
协作系统
虚拟系统
还原论和复杂系统
系统之系统工程
系统之系统工程过程
1.概念设计
2.系统选择
3.体系结构设计
4.接口开发
5.集成和部署
接口开发
集成和部署
系统之系统的体系结构
系统之系统的体系结构模式
实时软件工程
嵌入式系统设计
实时系统建模
实时编程
实时软件体系结构模式
实时软件设计过程
1.平台选择
2.激励/响应识别
3.时序分析
4.进程设计
5.算法设计
6.数据设计
7.进程调度
观察和反应模式
环境控制模式
处理管道模式
时序分析
3个关键因素
1.最后时限
2.频率
3.执行时间
实时操作系统
进程管理
两个优先级
1.时钟等级
2.中断等级
两个调度策略
1.非抢占式调度
2.抢占式调度
1、软件工程导论
软件过程
软件过程模型
瀑布模型
对过程活动进行计划和进度安排
基本开发活动
1.需求分析和定义
2.系统和软件设计
3.实现和单元测试
4.集成和系统测试
5.运行和维护
适用类型系统
1.嵌入式系统
2.关键性系统
3.大型软件系统
增量式开发
方法可以是计划驱动的、敏捷的或者这些方法的混合
规格说明、开发和确认等活动交织在一起
与瀑布模型相比的优势
降低成本
容易得到反馈意见
客户可以跟早使用软件
管理问题
过程不可见
系统结构会逐渐退化
集成和配置
过程阶段
1.需求规格说明
2.软件发现和评估
3.需求精华
4.应用系统配置
5.构件适配好和集成
优势
降低开发量以及成本和风险
更快的实现交付
劣势
需求权衡不可避免
失去一些对系统演化的控制
过程活动
软件规格说明
1.需求抽取和分析
2.需求规格说明
3.需求确认
软件设计和实现
体系结构设计
数据库设计
接口设计
构件选取和设计
软件确认
验证和确认
是否符合规格说明
是否符合系统客户的期望
程序测试是最基本的确认技术
测试过程阶段
1.构件测试
2.系统测试
3.客户测试
软件演化（软件维护）
应对变化
原型
增量式交付
过程改造
过程成熟度方法
目的：提高产品质量和过程的可预测性
过程阶段
1.过程度量
2.过程分析
3.过程改造
过程成熟度模型等级
1.初始级
2.受管理级
3.已定义级
4.质量管理级
5.优化级
敏捷方法
关注：迭代化的开发降低软件过程中的额外开销
特征：快速交付；对客户需求快速响应
敏捷软件开发
敏捷方法
原则
1.客户参与
2.拥抱变化
3.增量交付
4.保持简洁
5.人而不是过程
在两类系统开发中取得成功
用于市场销售的中小规模产品
组织内的定制化系统开发
敏捷开发技术
用户故事
重构
测试先行的开发
结对编程
敏捷项目管理
敏捷方法的伸缩
敏捷方法的实践问题
敏捷方法不适用如嵌入式系统工程或者大型复杂系统的开发
存在的问题
与大型企业的基于法律的合同定义不相符
适合新软件的开发而不适合软件维护
适合应用于小的、同处一地的团队
敏捷和计划驱动的方法
影响基于计划或者敏捷开发方法选择的因素
系统
类型
生命周期
规模
监管
团队
技术
分布
竞争力
组织
合同
交付
文化
面向大型系统的敏捷方法
面向整个组织的敏捷方法
需求工程
功能性需求
功能性需求
非功能性需求
需求功能过程
3个关键活动
1.抽取需求
2.需求规格说明
3.需求确认
实践中需求工程是一个迭代的过程，其中活动相互交织
需求抽取
活动过程
1.需求发现和理解
2.需求分类和组织
3.需求优化级排序和协商
4.需求文档化
需求抽取技术
访谈
封闭式访谈
开放式访谈
人种学调查
从实际工作方式中得出需求
从与他人合作以及他人活动中了解得出的需求
故事和场景
需求规格说明
自然语言规格说明
结构化规格说明
用况
软件需求文档
需求确认
对需求文档不同类型的检查
1.正确性检查
2.一致性检查
3.完整性检查
4.现实性检查
5.可验证性检查
需求确认技术
1.需求评审
2.原型化
3.测试用例生成
需求变更
需求管理计划
1.需求标识
2.变更管理过程
3.追踪关系策略
4.工具支持
需求变更管理
1.问题分析和变更规格说明
2.变更分析和成本考虑
3.变更实施
系统建模
上下文建模
交互模型
用况建模
用况模型在系统设计的早期
顺序图
用去建模参与者与系统中的对象之间的交互以及这些对象自身相互间的交互
结构模型
类图
泛化
聚集
行为模型
数据驱动的建模
输入数据以及生成相关的输出过程
时间驱动的建模
系统如何对外部和内部事件做出响应
模型驱动个工程
软件开发方法，产物是模型不是程序
模型驱动的体系结构（MDA）
产生3种类型抽象系统模型
1.计算无关模型(CIM)
2.平台无关模型(PIM)
3.平台相关模型(PSM)
体系结构设计
体系结构设计决策
体系结构的选择应根据系统的非功能性需求决定
1.性能
2.信息安全
3.安全性
4.可用性
5.可维护性
体系结构视图
1.逻辑视图
2.进程视图
3.开发视图
4.物理视图
体系结构模式
分层体系结构
知识库体系结构
客户-服务器体系结构
管道和过滤器体系结构
应用体系结构
事务处理系统
信息系统
语言处理系统
设计和实现
使用UML的面向对象设计
系统上下文和交互
体系结构设计
对象类识别
设计模型
结构模型
动态模型
接口规格说明
设计模式
实现问题
复用
软件复用在不同级别上发生
1.抽象级
2.对象级
3.构件级
4.系统级
配置管理
4个基本的配置管理活动
1.版本管理
2.系统集成
3.问题追踪
4.发布管理
宿主机（开发） - 目标机（运行）开发
开源开发
开源许可证
软件测试
开发测试
单元测试
测试程序构件的过程
自动化测试3部分
1.一个设置部分
2.一个调用部分
3.一个断言部分
选择单元测试用例
选择测试用例的策略
1.划分测试
2.基于指南的测试
构件测试
可能发生的接口错误的类型
1.参数接口
2.共享存储接口
3.过程式接口
4.消息传递接口
接口错误的类型
1.接口误用
2.接口误解
3.时间性错误
系统测试
测试驱动的开发
开发过程步骤
1.识别功能增量
2.为这个功能编写测试并且是自动化测试
3.运行该测试以及所有其他已经实现的测试
4.实现该功能并重新运行测试
5.测试运行成功转而实现下一个功能
优势
1.代码覆盖
2.回归测试
3.简化的调试
4.系统文档化
发布测试
是一个黑盒测试过程（功能测试）
基于需求的测试
场景测试
性能测试
用户测试
α测试
β测试
验收测试
验收测试过程
1.定义验收准则
2.计划验收测试
3.设计验收测试用例
4.运行验收测试
5.协商测试结果
6.接受或拒绝系统
软件演化
演化过程
遗留系统
遗留系统中的元素
1.系统硬件
2.支持软件
3.应用软件
4.应用数据
5.业务过程
6.业务政策和规划
遗留系统管理
对遗留系统进行评估做出决策
1.彻底废除这个系统
2.不再大幅度修改系统仅保持常规维护
3.对系统进行再工程以改善其可维护性
4.用一个新的系统来代替整个或者部分系统
评估视角
从业视角
1.系统的使用
2.支持的业务流程
3.系统的可靠性
4.系统的输出
技术视角
应用系统自身
1.可理解性
2.文档
3.数据
4.性能
5.编程语言
6.配置管理
7.测试数据
8.人员技能
系统的运行环境
1.供应商稳定性
2.失效率
3.年限
4.性能
5.支持需求
6.维护成本
7.互操作性
软件维护
3种类型软件维护
1.修复软件缺陷
2.使软件适应不同操作环境
3.增加或修改系统功能
维护预测
预测可维护性
预测维护成本
预测系统变更
软件在工程
与直接替换系统 相比的优势
1.较小风险
2.较低的成本
再工程过程中的活动
1.源代码转换
2.逆行工程
3.程序结构改进
4.程序模块化
5.数据再工程
软件重构
能够重构被改进的情况
1.冗余代码
2.长方法
3.选择语句
4.数据聚集
5.假设的一般性