901软件工程思维导图
2021-09-26 20:32:07 2 举报AI智能生成
901软件工程思维导图
作者其他创作
大纲/内容
1.对软件开发成本和进度的估计常常很不准确
2.用户对已完成的软件系统不满意的现象经常发生
3.软件产品的质量往往靠不住
4.软件常常是不可维护的
5.软件中没有适当的文档资料
6.软件成本在计算机系统总成本所占的比例逐年上升
7. 软件开发生产率提高的速度，往往跟不上计算机应用迅速普及深入的趋势
典型表现
软件不同于硬件，他是计算机系统中的逻辑部件而不是物理部件，缺乏可见性，软件开发过程的进展难以测量
1.软件本身独有的特点确实给开发和维护带来了困难
2.与软件开发和维护的许多错误认识和做法的形成有关
3. 对用户要求没有完整准确的认识就着手编写程序
软件日益复杂和庞大
软件开发管理困难和复杂
软件开发技术落后
生产方式落后
开发工具落后
软件开发费用不断增加
产生原因
1.认识到软件是程序、数据、相关文档得完备集合
2.认识到软件开发是一种组织良好，管理严密，各类人员协同配合，共同完成得工程项目
3.推广和使用在实践中总结出来的开发软件的成功的技术和方法
4.开发和使用更好的软件工具
消除危机的途径
软件危机
问题定义
项目开发计划和可行性分析报告
可行性研究
软件需求规格说明书
初步的用户手册
确认测试计划
需求分析
概要设计说明书
总体设计（概要设计）
详细设计说明书
详细设计
源程序清单
编码和单元测试
测试报告
综合测试
维护报告
软件维护
软件生命周期
按顺序的规范化的软件开发过程
定义
阶段间具有顺序性和依赖性
推迟实现的观点
质量保证的观点
文档驱动的
特点
在产品交付前，用户只能通过文档了解产品
灵活性差，后期一但修改会很麻烦
缺点
需求清晰明确
相关技术成熟且熟练
使用情况
瀑布模型
快速建立得可以运行的计算机程序，让用户实践来提供修改意见
快速
开发过程式一个不断修改的过程，软件质量难以保证
用户和开发者都缺乏相关经验
探索型
对设计没有把握
实验型
用原型过程代替全部开发阶段
迭代
演化性
分类
快速原型模型
把软件产品作为一系列的增量构件来设计，编码和测试
逐步增加产品功能，使用户有充足的时间来学习和适应产品
优点
需要开发人员技术水平过关，否则可能会冒构件无法集成的风险
开发时，必须设计开放的软件结构体系，每次把新的构件加入系统时不能破坏原来的产品
人员配备不充裕，不能在软件项目期限之前实现一个完全版本的软件情况
适用范围
增量模型
可以理解为加了风险分析过程的快速原型模型
风险驱动得快速原型模型
可以很好的控制风险
有利于已有软件的重用
适用于内部开发的大规模软件项目
风险识别
风险评估
风险管理
风险分析
确定目标，选择方案
评估方案，识别并排除风险
开发，验证下一级产品
计划下一阶段
阶段
包含维护周期，因此维护和开发之间没有本质区别
螺旋模型
面向对象的软件开发过程模型
迭代和无缝
喷泉模型
软件生命周期模型（过程模型）
用分阶段的生命周期计划严格管理
坚持进行阶段评审
实行严格的产品控制
采用现代程序设计技术
结果应该能清楚地审查
开发小组的成员应该少而精
承认不断改进软件工程实践的必要性
软件工程的基本原理
程序设计
程序系统
软件工程
软件发展的阶段
确定软件开发过程必须完成的总目标
系统要解决的问题是什么
上一阶段确定的问题有解决方案吗
技术可行性
投资回收率
最重要的参考数据
经济可行性
操作可行性
描绘信息流和数据输入移动到输出过程中所经受的变换
数据的源点和终点
变换数据的处理
数据存储
数据流
组成
接口设计的主要依据
描述系统功能
数据流图
对数据流图中包含的所有元素得定义集合
数据流分量（数据元素）
处理
数据字典
描述高层物理模型
系统流程图
确定目标系统必须做什么
功能和非功能性需求
确定系统的综合需求
分析系统的数据要求
导出系统的逻辑模型
修正系统开发计划
任务
功能需求
性能需求
可靠性和可用性需求
出错处理需求
接口需求
约束
逆向需求
将来可能提出的需求
需求
访谈
面向数据流自顶向下求精
简易的应用规格说明技术
快速建立软件原型
需求的获取方法
实体联系图（ER图）
状态转换图
用树形结构的矩形框描绘数据的层次结构
层次方框图
面向数据结构
与层次结构相比提供了更丰富的描绘手段
Warnier图
方便地描绘输入，对数据的处理和输出数据之间的关系
IPO图（Input Process Output）
图形化工具
需求之间不能互相矛盾
一致性
用户所有的需求都已经包括在内了
完整性
现有的技术可以解决这些问题
现实性
需求确实能解决用户问题
有效性
验证方面
验证软件需求
数据模型
功能模型
行为模型
三大模型
软件定义（系统分析）
系统设计阶段
结构设计阶段
模块化
抽象
逐步求精
应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的
信息隐藏原理
把一些关系密切的软件元素物理地放得彼此靠近
局部化
信息隐藏和局部化
模块独立是模块化，抽象，信息隐藏和局部化概念的直接结果
软件结构中不同模块之间互联程度
系统中必须存在的耦合
俩个模块通过参数交换信息，信息仅仅是数据
数据耦合
模块适当分解后可以被数据耦合代替
交换的信息含有控制信息
控制耦合
丧失了对数据的访问控制
整个数据结构作为参数被传递过去，而调用模块只需要其中的一部分
特征耦合
俩个或多个模块通过一个数据环境相互作用
一读一取，松散的耦合
既读又取，紧密的耦合
公共环境耦合
一个访问另一个得内部数据
一个模块不通过正常入口转到另一个模块内部
俩个模块有一部分程序代码重叠（只可能出现在汇编语言中）
一个模块有多个入口（意味着该模块有多种功能）
发生以下情形之一就认为出现了内容耦合
内容耦合
分类（低到高）
尽量使用数据耦合，少用控制和特征耦合，限制公共环境耦合的范围，完全不用内容耦合
原则
耦合
一个模块内各个元素彼此结合的紧密程度，是信息隐藏和局部化概念的自然拓展
最理想的內聚
模块内所有元素属于一个整体，完成一个单一的功能
功能內聚（10）
模块内得处理元素同一个功能密切相关，且必须按顺序执行
顺序內聚（9）
模块中的所有元素都使用同一个输入数据或产生同一个输出数据
通信內聚（7）
模块内得处理元素是相关的，而且必须以特定次序执行
过程內聚（5）
例如：初始化
模块内的任务必须在统一时间段内执行
时间內聚（3）
例如：一个模块产生各种类型的全部输出
模块内的任务属于相同或相似的一类
逻辑內聚（1）
一个模块完成一组任务，这些任务没关系或即使有关系也很松散
偶然內聚（0）
分类（高到低）
內聚
度量标准
模块独立
改进软件结构提高模块独立性
模块规模应该适中
软件结构中控制的层数
深度
同一层次的模块总数的最大值
宽度
一个模块直接控制（调用）的模块数目
扇出
反应程序的重用率
表明有多少上级模块直接调用他
扇入
深度，宽度，扇出和扇入都应适当
受该模块内判定影响的所有模块的集合
作用域
这个模块本事以及所有直接或间接从属于他的模块的集合
控制域
模块的作用域应该在控制域之内
力争降低模块接口的复杂程度
设计单入口和单出口的模块
相同的输入应该产生相同的输出
模块的功能应该可以预测
启发规则
层次图和HIPO图
详细设计与概要设计衔接的工具
结构图（Structure Chart）
描绘软件结构的图形工具
把信息流映射成软件结构
变换流
事务流
信息流类型
面向数据流的设计方法
设计原理
设想可供选择的方案
选取合理的方案
推荐最佳方案
功能分解
设计软件结构
设计数据库
制订测试计划
书写文档
审查和复审
步骤
只允许使用顺序，IF_THEN_ELSE型分支和和DO_WHILE型循环（顺序选择循环）
经典的结构程序设计
除经典以外，还允许使用DO_CASE型多分支结构和DO_UNTIL型循环结构
扩展的结构程序设计
除扩展以外，还允许使用LEAVE（或BREAK）
修正的结构程序设计
结构程序设计
长度
系统响应时间相对于平均响应时间的偏差
易变形
俩个重要属性
系统响应时间
用户帮助设施
出错信息处理
命令交互
设计问题
人机界面设计
箭头代表控制流，因此程序员可以不受约束随意转移控制
对控制流程的描绘很直观，便于掌握
程序流程图
功能域（作用域）明确
不能任意转移控制
很容易确定局部和全程数据的作用域
很容易表现嵌套关系以及模块的层次结构
盒图（N~S图）
PAD图是面向高级程序设计语言的，很容易把它转换成与之对应的高级语言
PAD图（problem analysis diagram）
清晰地表示复杂的条件组合和应做的动作之间的对应关系
简洁而无歧义地描述处理规则
判定表
形式简单不需任何说明
简洁性不如判定表，同一个值往往需要重复写多遍，越接近叶端重复次数越多
判定树
过程设计语言（PAD，伪码）
过程设计的图形化工具
Jackson图
改进的Jackson图
Jackson方法
根据输入输出的数据结构，按一定的规则映射成软件的过程描述，即程序结构
JSP（Jackson structure programimg）方法
面向数据结构的设计方法
画出流图
线性无关的区域数
边数—点数+2（E—N+2）
判定结点数+1（P+1）
计算环形复杂度
McCabe方法
根据程序中运算符和操作数的总数来度量程序的复杂程度
Halstead方法
程序复杂度的定量度量
工程和科学计算
FORTRAN
商业领域
COBOL
系统和实时应用领域
C语言和Ada语言
组合问题领域
LISP
表达知识和推理
PROLOG
程序设计语言
好的注释占到程序总量的三分之一
注释
编码风格
发现编码错误
模块接口
局部数据结构
重要的执行通路
出错处理通路
边界条件
测试重点
代码审查
计算机测试
测试方法
单元测试
找出程序中的错误，不能证明程序中没有错误
测试的目标
所有测试都应该追溯到用户需求
应该远在测试之前就开始指定测试计划
Pareto原理：测试发现的错误中的80%很可能是由程序中20%中的模块造成的
把Pareto原理应用到软件测试中
应该从小规模测试开始，并逐步进行大规模测试
穷举测试是不可能的
为了达到最佳的测试效果，应该由独立的第三方从事测试工作
测试准则
把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程
软件功能
等价类划分
边界值分析
错误推测
有效地检测输入条件的各种组合可能会引起的错误
因果图
黑盒测试
把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法
程序的内部逻辑
语句覆盖
判定覆盖
条件覆盖
判定/条件覆盖
条件组合覆盖
点覆盖（相当于语句覆盖）
分支主题
边覆盖（相当于判定覆盖）
路径覆盖
图论
逻辑覆盖
计算流图环形复杂度
基本路径测试
条件测试
循环测试
控制结构测试
白盒测试（结构测试）
测试策略
发现模块的接口错误
测试和组装软件的系统化技术
子系统测试
发现性能，质量不合要求的错误
系统测试
从主控制模块开始，沿着程序的控制层次向下移动，逐个把各个模块结合起来
不需要测试驱动程序
能够在测试阶段的早期实现并验证系统的主要功能
需要存根程序，可能遇到与此相关的测试困难
底层错误发现较晚
早期不能充分展开人力
自顶向下集成
从原子模块(即在软件结构底层的模块)开始组装和测试
因为从底部向上结合模块，总能得到所需的下层处理模块，因此不需要存根程序
需要驱动模块
自底向上集成
基本上使用自顶向下的测试方法，但在早期使用自底向上方法测试少数软件的关键模块
改进的自顶向下集成测试方法
上层使用自顶向下，底部使用自底向上
混合法
混合策略
集成策略
重新执行已经做过得测试的某个子集，以保证上述这些变化没有带来非预期的副作用
保证由于调试或其他原因引起的变化，不会导致非预期的软件行为或额外错误的测试活动
目的
回归测试
集成测试
发现功能错误
保证软件正确地实现了某个特定要求的一系列活动
验证
为了保证软件确实满足了用户需求而进行的一系列活动
确认
如果软件的功能和性能如同用户所合理期待的那样，软件就是有效的
验证软件得有效性
目标
用户在开发者的场所进行，并在开发者的的指导下进行测试
Alpha测试
软件的最终用户在一个或多个客户场所，开发者通常不在Beta测试的现场
Beta测试
验收测试（确认测试）
平行运行
测试步骤
测试发现错误之后排除错误的过程
蛮干法
回溯法
对分查找法
归纳法
演绎法
原因排除法
方法
调试
软件开发
使软件持久地满足用户的需求
修改和改正错误
改正性维护
为了和变化的环境适当地配合而进行的修改软件的活动
适应性维护
软件维护的最主要部分
用户提出增加新功能和修改已有功能
完善性维护
微课给未来的改进奠定更好的的基础而修改软件
预防性维护
可理解性
可测试性
可修改性
可移植性
可重用性
文档
可维护性复审
可维护性的决定因素
编码副作用
数据副作用
文档副作用
维护的副作用
结构化维护
非结构化维护
文档的完整性
主要区别
软件维护（运行维护）
软件在给定的时间间隔内，按照规格说明书的规定，成功运行的概率
软件可靠性
程序在给定的时间点，按照规格说明书的规定，成功运行的概率
软件可用性
成功运行的概率
平均无故障时间
度量指标
软件系统能最有效的利用计算机的时间和空间资源
软件有效性
传统方法学
每个人根据经验估算出软件最大规模a，可能规模m，最小规模b
计算a，m，b的平均数
计算估计值L=（a+4m+b）/6
代码行技术
输入项数
输出项数
查询数
主文件数
外部接口数
确定信息域
计算未调整的功能点数UFP
计算14种技术因素对软件规模的影响程度（1到5），求和得DI
计算技术复杂性因子TCF=0.65+0.01*DI
计算技术复杂性因子
计算功能点数FP=UFP*TCF
功能点技术
估算软件规模
软件开发的工作量，单位人月（pm）
Walston_Felix模型
Bailey_Basili模型
Boehm简单模型
Doty模型（KLOC＞9时适用）
面向KLOC（代码行）的估算模型
Albrecht&Gaffney模型
面向FP（功能点）的估算模型
静态单变量模型
动态多变量模型
构造性成本模型（constructive cost model）
COCOML2
工作量的估算
原始的COCOMO模型
COCOMO2模型
动态多变量
Putnam模型
估算开发时间
直观简明
容易掌握
容易绘制
进度计划和进度管理的有力工具
Gantt图
描绘任务的分解情况以及每项工作的开始结束时间
显式的描绘各个作业彼此间的依赖关系
系统分析和设计的强有力工具
工程网络
进度规划工具
进度计划
小组成员完全平等，享有充分民主，通过协商做出决策
组员们对发现程序错误持积极的态度，有助于发现更快速的发现错误，从而提高代码质量
组内具有高度凝聚力，组内技术氛围浓厚，有利于技术难关的攻克
没有明确的权威指导开发工作的进行，组员间将缺乏必要的协调，最终可能导致工程失败
民主制程序员组
选用经验多，技术好，能力强的程序员最为主程序员
配有一名编程秘书（完成项目的事务性工作）和后备程序员（必要时接替主程序员的工作）
专业化
层次性
主程序员是高级程序员和优秀管理者的结合体，社会上缺乏这类型人才
后备程序员更难找，需要和主程序一样的能力但大多数时间无事做
编程秘书难找，一般程序员不喜欢这类事务性
主程序员会把发现的程序错误与小组程序员工作业绩联系起来，造成小组程序员不愿意发现错误的心理
主程序员组
在主程序员组的基础上，取消主程序员的大部分行政工作
主程序员划分为技术负责人（负责技术活动）和行政负责人（负责所有非技术性事务的管理决策）
现代程序员组
人员组织
软件与明确地和隐含地定义的需求相一致的程度
产品修改
产品转移
产品运行
软件质量
技术复审的必要性
走查
审查
只能证明程序功能是正确的，并不能证明程序的动态特性是符合要求的
程序正确性证明
软件质量保证措施
McCall等认为，特性是软件质量的反映，软件属性可用做评价准则，定量化地度量软件属性可知软件质量的优劣。
McCall软件质量模型
软件质量模型
质量保证
软件配置项
已经通过了正式复审的贵哥说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它
基线
软件配置
标识软件配置中的对象
版本控制
变化控制
配置审计
状态报告
软件配置管理过程
标识变化
控制变化
实现变化
报告变化
软件配置管理活动
软件配置管理
能力成熟度模型（capability maturity model，CMM）
用于评价软件机构的软件过程能力成熟度模型
初始级
可重复级
已定义级
已管理级
优化级
等级（从低到高）
能力成熟度模型
软件项目管理
尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是问题域与求解域尽可能一致
出发点和基本原则
认识客观世界是由各种对象组成的，任何事物都是对象，复杂的对象可以由比较简单的对象以某种方式组合而成
把所有的对象都划分成各种对象类，每个对象类都定义了一组数据和方法
按照子类与父类的关系，把若干个对象类组成一个层次结构的系统
对象彼此之间仅能通过传递消息互相联系
要点
与人类习惯的思维方法一致
稳定性好
可重用性好
封装性好，易分解，独立性好
较易开发大型软件产品
可维护性好
封装就是信息隐藏，把数据和实现操作的代码集中起来放在对象内部，通过封装对外界隐藏了对象的实现细节
封装
子类自动地共享基类中定义的数据和方法的机制
继承
类等级的不同层次中可以共享一个行为的名字，然而不同层次中的每个类却各自按自己的需要来实现这个行为
多态
若干个参数不同的函数可以使用相同的函数名字
函数重载
同一个运算符可以施加于不同的类型的操作数上面
运算符重载
重载
特性
描述系统的静态结构
边界类
控制类
实体类
接口类
类
属性
服务
一般关联
共享聚集（聚合）
组合聚集
聚集
关联
泛化（继承）
依赖
细化
关系
对象模型
规定了对象模型中的对象得合法变化序列
动态模型
指明系统该做什么
面向对象建模
概述
抽取和整理用户需求并建立问题域精确模型的规程
识别主题
主题层
找出类与对象
类与对象层
识别结构
结构层
定义属性
属性层
定义服务
服务层
五个层次
类图
对象图
uml图
确定类与对象
确定关联
划分主题
确定属性
识别
建立对象模型
描绘事件与对象状态的关系
状态图
顺序图
是系统的一次具体执行过程
系统在某一执行期间内出现的一系列事件
编写脚本
设想用户界面
画事件跟踪图
画状态图
审查动态模型
建立动态模型
用例图
画出基本系统模型图
画出功能级数据流图
描述处理框功能
建立功能模型
面向对象分析
信息隐藏
对象间的耦合通过消息连接来实现
交互耦合（松散）
一般化类与特殊类之间耦合的一种形式，应该提高继承耦合程度
继承耦合（紧密）
弱耦合
一个服务应该完成且仅完成一个功能
服务內聚
一个类应该只有一个用途，他的属性和服务应该是高內聚的
类內聚
设计出的一般特殊结构，应该符合多数人的概念，即这种结构应该是相对应的领域知识的正确抽取
一般特殊內聚
强內聚
尽量使用已有的类
如果必须创建新类，应该考虑将来的可重复使用性
可重用
面向对象设计准则
设计结果应该清晰易懂
一般特殊结构的深度应适当
设计简单的类
使用简单的协议
使用简单的服务
把设计变动减至最小
同一事务不作修改或稍加改动就多次重复使用
知识重用
方法和标准的重用
代码重用
设计结果重用
分析结果重用
重用级别
项目计划
成本估计
体系结构
需求模型和规格说明
设计
源代码
用户文档和技术文档
用户界面
数据
测试用例
典型的可重用软件成分
软件成分的重用
软件重用的层次
模块独立性强
具有高度可塑性
接口清晰，简明，可靠
可重用软构件应具备的条件
实例重用
继承重用
多态重用
类构件的重用方式
类构件
软件重用
系统分解
设计问题域子系统
设计人机交互子系统
设计任务管理子系统
设计数据管理子系统
面向对象设计
面向对象实现
面向对象方法学
收藏
收藏
0 条评论
回复 删除
下一页
