4.软件工程基础知识
-
图
-
Gantt图
-
不能得到各任务之间的依赖关系，不能确定项目的关键所在，不能反映计划中有潜力的部分
-
-
-
软件需求
-
功能需求
-
必须具备
-
-
非功能需求
-
属性或品质，可靠性，性能，响应时间，扩展性，精度，含有数字的等等
-
-
设计约束
-
解决方案的一些约束说明
-
-
-
软件风险
-
两个特性
-
不确定性
-
风险发生的可能性（概率）
-
-
损失
-
风险发生所产生的后果
-
风险的本质，范围和时间是影响风险所产生的后果的3个因素
-
-
-
-
识别风险时需要识别的因素
-
员工
-
预算
-
-
风险分析
-
风险识别
-
系统化确定项目计划（估算，进度，资源分配）的威胁
-
-
风险预测（风险估算）
-
两个特性
-
-
风险评估
-
预测是否影响参考水平值
-
成本
-
速度
-
性能
-
-
-
风险控制
-
建立处理风险的策略，计划
-
风险避免（最好）
-
风险监控（全程监控）
-
风险管理（风险压到最低）
-
损失控制
-
风险转移
-
风险保留
-
-
-
风险优先级根据风险暴露确定
-
风险影响×风险概率
-
-
-
-
软件开发过程
-
（逆向工程）需求分析阶段输出
-
数据流图
-
实体联系图
-
状态迁移图
-
数据字典
-
视图在数据字典中保存的是视图定义
-
视图是一个虚表，视图所对应的数据不进行实际存储
-
数据库中存储的是视图定义
-
-
软件需求规格说明书
-
-
软件设计阶段
-
软件体系结构
-
仓库风格
-
数据仓库
-
体系结构的中心
-
-
若干个其他构件
-
数据库系统、超文本系统和黑板系统都属于仓库风格
-
体系结构的优点
-
对可更改性和可维护性的支持
-
可复用的知识源
-
支持容错性和健壮性
-
-
缺点
-
测试困难
-
能保证有好的解决方案
-
难以建立好的控制策略
-
低效
-
昂贵的开发工作
-
缺少对并行机制的支持
-
-
-
管道过滤器体系结构
-
每个过滤器负责执行特定的数据处理任务，通过管道将处理结果传递给下一个过滤器。
-
软件构件具有良好的隐蔽性和高内聚、低耦合的特点
-
允许设计者将整个系统的输入输出行为看成是多个过滤器的行为的简单合成
-
支持软件复用
-
系统维护和增强系统性能简单
-
允许对一些如吞吐量、死锁等属性的分析
-
支持并行执行
-
管道过滤器应用场景
-
如文本处理、音频和视频流处理等
-
数据清洗与转换原始数据
-
身份验证、日志记录等Web服务
-
（网络安全）对网络流量进行多层次的分析和过滤
-
-
-
-
概要设计规格说明书
-
-
敏捷开发
-
尽可能早地、持续地对有价值的软件的交付
-
极限编程XP
-
轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式
-
由价值观、原则、实践和行为4个部分组成
-
4大价值观： 沟通、简单性、反馈和勇气
-
5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作
-
12个最佳实践
-
计划游戏（快速制定计划、随着细节的不断变化而完善）
-
小型发布（系统的设计要能够尽可能早地交付）
-
隐喻（找到合适的比喻传达信息）
-
简单设计（只处理当前的需求，使设计保持简单）
-
测试先行（先写测试代码，然后再编写程序）
-
重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）
-
结队编程
-
集体代码所有制
-
持续集成（可以按日甚至按小时为客户提供可运行的版本）
-
每周工作40个小时
-
现场客户
-
全程配合xp团队
-
-
编码标准
-
-
-
激发开发人员创造性、使得管理负担最小的一组技术
-
集体所有权
-
承担了非正式的代码审查过程
-
代码质量更高
-
编码速度一般，与传统单人编程相当
-
-
水晶法Crystal
-
每一个不同的项目都需要一套不同的策略、约定和方法论
-
-
并列争球法Scrum
-
使用迭代的方法，并按需求的优先级来实现产品
-
把每30天一次的迭代称为个冲刺
-
协调是通过简短的日常情况会议进行
-
-
自适应软件开发 ASD
-
6个基本原则
-
设立了项目的目标，但不描述如何达到这个目标
-
项目是围绕着构造的构件来组织并实现特征
-
重做与做同样重要，变化也包含其中；
-
变化视为对软件开发实际情况的调整
-
确定的交付时间迫使开发人员认真考虑每一个生产版本的关键需求
-
风险也包含其中，它使开发人员首先跟踪最艰难的问题
-
-
-
-
软件质量依赖于软件开发过程的质量
-
人（最主要的因素）
-
开发技术
-
过程质量
-
成本时间
-
进度
-
-
软件质量模型
-
ISO/IEC9126软件质量模型
-
功能性
-
适合性，准确性，互用性，依从性，安全性
-
-
可靠性
-
成熟性，容错性，易恢复性
-
-
易使用性
-
易理解性，易学性，易操作性
-
-
效率
-
时间特性，资源特性
-
-
可维护性
-
易分析性（可理解性），易改变性（可修改性），稳定性（可靠性），易测试性，可使用性，效率
-
易分析性是描述诊断缺陷或失效原因、判定待修改程度的难易程度的特性
-
稳定性是描述修改造成难以预料的后果的风险程度，风险程度越低，稳定性越好
-
易测试性是描述测试已修改软件的难易程度的特性
-
易改变性是描述修改、排错或适应环境变化的难易程度
-
-
软件开发各时期的关键目标
-
受软件开发文档影响
-
-
可移植性
-
适应性，易安装性，一致性，易替换性
-
满足“平台无关”和“通用”的特性
-
-
-
McCall软件质量模型
-
运行
-
正确性、可靠性、效率、完整性、使用性
-
-
修正
-
维护性、测试性、灵活性
-
-
转移
-
维护性移植性、复用性、共运行性
-
-
-
CMMI
-
将已有的几个CMM模型结合
-
构成 集成模型
-
-
成熟度模型
-
支持阶段性过程改进和连续性过程改进
-
CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标
-
表明过程域的一个或多个特定目标没有被满足
-
-
CL1（已执行的）：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标
-
关注于过程域的特定目标的完成
-
-
CL2（已管理的）：其共性目标是集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制、和评审
-
针对单个过程实例的能力
-
-
CL3（已定义级的）：其共性目标集中于已定义的过程的制度化。过程是按照组织的裁剪指南从组织的标准过程中裁剪得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进。
-
关注过程的组织级标准化和部署
-
-
CL4（定量管理的）：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的质量目标作为管理准则。
-
CL5（优化的）：使用量化（统计学）手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效
-
表明过程得到很好地执行且持续得到改进
-
-
-
-
CMM
-
目前最流行一个模型框架（不是一个标准）
-
能力成熟度缩写（Capability Maturity Model）
-
对软件组织进化阶段的描述
-
5级为成熟度最高
-
初始级
-
无秩序
-
-
可重复级
-
对类似的应用项目，有章可循并能重复以往所取得的成功
-
-
已定义级
-
软件过程均已文档化、标准化
-
高质量的文档特点：针对性、无二义性、易读性、完整灵活性、可追溯性
-
-
-
已管理级
-
软件过程和产品质量有详细的度量标准
-
-
优化级
-
能够不断地、持续地对促进过程进行改进
-
-
计划精度越高，每单位工程的生产周期越短，每单位工程的成本越低
-
-
解决软件过程存在问题
-
改进过程将改进产品，尤其是软件产品，进行评估后需要把发现的问题转化为软件过程改进计划
-
4个方面构成了软件过程改进的框架
-
过程改进基础设施
-
过程改进线路图
-
软件过程评估方法
-
软件过程改进计划
-
-
程序改进通常不可能是一次性的，需要反复进行
-
每一次改进要经历4个步骤：评估、计划、改进和监控。
-
-
-
-
-
软件配置管理SCM
-
用于整个软件工程过程
-
其主要目标是标识变更、控制变更、确保变更正确的实现
-
其主要内容包括版本管理、配置支持、变更支持、过程支持、团队支持、变化报告和审计支持等。
-
内容包括：软件配置标识、变更管理、版本控制、系统建立、配置审核和配置状态报告。
-
-
配置数据库
-
开发库
-
受控库
-
产品库
-
-
软件过程模型
-
瀑布模型
-
高角度，要求事件序列
-
缺乏灵活性，不能适应变化的需求
-
适用于需求已确定，对交付时间有严格要求，规模大，开发小组对项目了解）
-
-
计划、分析、设计、编程、测试和维护
-
-
V模型
-
说明测试活动是如何与 分析和设计 相联系的
-
-
原型模型
-
获知用户需求，引发系统需求
-
适用于需求不明确
-
适合小规模软件开发
-
-
探索特殊的软件解决方案
-
-
螺旋模型
-
开发活动和风险管理相结合
-
大型
-
制订计划、风险分析、实施工程、客户评估
-
自内向外旋转，每转一圈都要对风险进行识别和分析，并采取相应的对策
-
-
喷泉模型
-
迭代（不断完善），无间隙（开发活动不存在明显边界）
-
以用户需求为动力，以对象作为驱动
-
面向对象开发模型
-
-
增量模型
-
需求不明确，快速构造可运行的产品
-
用例图通过捕获需求获得
-
-
是瀑布模型和原型模型的结合
-
容易理解，管理成本低
-
提高可维护性
-
开放式的体系结构
-
对软件体系结构有更高要求
-
-
缺点：不利于模块划分
-
-
演化（迭代）模型
-
适用于缺乏准确认识的情况
-
使用过程中不断完善
-
-
UP（统一过程）模型
-
以用例和风险为驱动，架构为中心，迭代且增量
-
由UML方法和工具支持
-
定义了五个阶段
-
起始（初启）阶段
-
产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品
-
里程碑是生命周期目标
-
-
-
精化阶段
-
产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品
-
生命周期架构
-
-
-
构建阶段
-
成果是一个准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述
-
初始运作功能
-
-
-
移交阶段
-
产生移交给用户产品发布版本。
-
产品发布
-
-
-
产生阶段
-
-
多次迭代，每个迭代都包括
-
计划
-
分析
-
设计
-
构造
-
集成
-
测试
-
单元测试（模块测试）
-
主要是发现程序代码中的问题，针对详细设计和软件实现阶段的工作进行的
-
总体设计（概要设计）
-
结构设计
-
数据库设计
-
数据库性能下降时，管理员要对数据库进行再组织和重构
-
重新安排存储位置，回收垃圾，减少指针链
-
对数据库设计重构造
-
-
-
-
详细设计
-
算法
-
算法复杂度分析
-
时间复杂度
-
lgn<n^2/3<n<n^4<2^n<n!
-
有向图n个顶点连接e条边，邻接表存储时间复杂度为O（n+e）
-
-
空间复杂度
-
程序复杂度（环路复杂度）
-
流程图中封闭区域+1
-
McCabe度量法
-
箭头数-节点数+2
-
合并到一个的箭头算2个
-
-
-
-
排序算法
-
-
-
堆排序在原数据上进行
-
归并排序占用辅助存储空间最多
-
-
Kruskal算法
-
最小生成树：包含所有顶点，不能有环（生成树不唯一，权值唯一）
-
先写出所有顶点，从最小权值出发，比如1 2 3依次画，不能使图变成环
-
-
-
适合于点多的图
-
顶带数量为n，连接边的数量为n-1
-
-
属于贪心算法
-
-
prim算法
-
部分出发，找到其他顶点，每次相加总数最小的
-
-
-
适合于点少边多的算法
-
属于贪心算法
-
-
dijkstra迪杰斯特拉算法求最短路径
-
和工程问题不同
-
-
-
-
-
-
0/1背包问题
-
价值最大
-
-
-
-
第二行第三列，表示第三个背包包含前两种物品的最大价值，最右下角就是答案
-
背包容量最大为3的情况下，对前两种物品取舍选择后的最大价值
-
按行填写
-
新纳入考量的物品重量是否超过背包总容量
-
若>,则继承上方单元格
-
若<
-
第一组数据：不考虑新纳入的物品（上方单元格的值）
-
第二组数据：装入葡萄后，葡萄占据背包两个容量，且葡萄无法再次被选择
-
问题从背包容量最大为j的情况下，对前n种物品取舍选择后的最大价值变成了背包容量最大为（x-i.weight）的情况下，对前（n-1）种物品取舍选择后的最大价值
-
最大价值为0，再加上新加入的葡萄的价值，就是我们要的第二组数据
-
-
理解：比如现在背包是5，你装了一个3的，是不是还剩2？直接去前面找背包容量是2的时候那个最大价值。当时你已经算过了呀，所以只需要把这两个加起来就好啦
-
-
选择两组数据较大的就是局部最优解
-
-
-
-
-
-
-
每个物品只能背取1/0次
-
动态规划
-
-
完全背包问题
-
贪心
-
-
-
数据结构
-
关系代数，笛卡尔集
-
自然连接
-
同名列相等进行过滤，A1,A2
-
重复的去掉
-
-
左外连接
-
以左表为标准
-
匹配上或者不上也留下来
-
-
-
-
关系代数
-
-
笛卡尔集包含全部，不去掉重复的
-
-
-
-
-
-
-
除法求全部的。可以得到在课程号相同的条件下的所有学号信息
-
-
-
-
Armstrong公理
-
关系模式R（U,F）
-
U是关系模式R的属性集
-
F是U上一组函数依赖
-
-
自反律
-
若Y《X《U，则X->Y为F所蕴含
-
X 和 Y 可以相同，即 X=Y，这样就得到了 X→X，满足自反律的要求
-
-
对于任意的属性集 X，都有 X→X 属于 F。
-
-
增广律
-
若X->Y为F所蕴含，且Z《U，则XZ->YZ为F所蕴含
-
-
传递律
-
若X->Y，Y->Z为F所蕴含，则X->Z为F所蕴含
-
-
合并规则
-
若X->Y，X->Z为F所蕴含，则X->YZ为F所蕴含
-
-
伪传递规则
-
若X->Y，WY->Z为F所蕴含，则XW->Z为F所蕴含
-
-
分解规则
-
若X->Y，Z《Y，则X->Z为F所蕴含
-
-
-
哈夫曼编码（树
-
主要用于对文本进行编码，以压缩文本
-
待编码文本中出现次数越多的字符，其编码长度越短
-
-
根据生成的字典构建哈夫曼树（频率
-
-
左0右1
-
两个节点向上组成一个新的节点
-
每个节点要么是叶子节点，要么就是有两个孩子
-
-
-
-
二分查找
-
元素有序
-
序列均分
-
二分查找的判定树为平衡二叉树
-
-
折半查找是一种分治法
-
成功失败ASL（平均查找长度）
-
-
-
中间向下取整，左子树从左边找，右子树从右边找
-
-
第二层每个节点找两次，第三层每个节点找三次
-
-
-
空节点，第四层每个空节点找三次，第五层每个空节点找四次
-
-
-
-
森林
-
二叉树
-
-
-
兄弟转换的孩子，有兄弟就变成右孩子
-
满二叉树，父节点m，右孩子满足公式n=2*m+1
-
-
-
转为二叉树，第一棵树不动，第二棵树作为第一棵树的右孩子，第三棵树作为第二棵树的右孩子
-
-
-
若一个节点的左孩子存在，则将左孩子的右孩子节点，右孩子节点的右孩子节点都与该节点连线
-
去除与右孩子节点的连线
-
-
-
-
-
-
段页式存储管理
-
分层管理体系
-
-
地址空间
-
-
位图
-
-
基本原理：将整体主存划分成大小相等的存储块（页框），程序分为若干个段（赋予段名），每个段分为若干个页，以页框为单位离散分配
-
段号6
-
最大有2^6段
-
-
段内页号14
-
每个段最多有2^14页
-
-
页内地址12
-
页的大小2^12=2^10*2^2=4K
-
-
-
-
红黑树
-
一种自平衡的二叉查找树
-
O(logN)
-
红黑树保证最长路径不超过最短路径的二倍，因而近似平衡
-
最短路径就是全黑节点
-
根、叶子节点（外部节点，空节点）是黑色
-
在红黑树中真正被定义为叶子结点的，是那些空节点
-
-
最长路径就是一个红节点一个黑节点
-
当从根节点到叶子节点的路径上黑色节点相同时，最长路径刚好是最短路径的两倍
-
-
红黑树通过牺牲一点平衡性来换取更好的插入和删除性能，同时保持了良好的查找性能
-
满足特性
-
-
旋转操作
-
左旋是将某个节点旋转为其右孩子的左孩子，而右旋是节点旋转为其左孩子的右孩子
-
-
-
-
插入操作
-
红黑树插入新节点（红色）后，需要进行调整
-
-
-
外部接口
-
用户界面
-
-
-
侧重于模块中的内部处理逻辑和数据结构
-
模块接口
-
保证了测试模块的数据流可以正确地流入、流出
-
测试模块的输入参数和形式参数在个数、属性、单位上是否一致
-
调用其他模块时所给出的实际参数和被调用模块的形式参数在个数、属性、单位上是否一致
-
调用标准函数时所用的参数在属性、数目和顺序上是否正确
-
全局变量在各模块中的定义和用法是否一致
-
输入是否仅改变了形式参数
-
开/关的语句是否正确
-
规定的I/O格式是否与输入输出语句一致
-
使用文件之前是否已经打开文件或是用文件之后是否己经关闭文件
-
-
局部数据结构
-
变量的说明是否合适
-
是否使用了尚未赋值或尚未初始化的变量
-
•变量的初始值或默认值是否正确
-
变量名是否有错
-
-
重要的执行路径（最基本的任务）
-
需要精心设计测试例子来发现是否有计算、比较或控制流等方面的错误
-
计算方面的错误：算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型彼此不相容
-
算法错误；表达式的符号表示不正确等
-
比较和控制流的错误：本应相等的量由于精度造成不相等
-
同类型进行比较； 逻辑运算符不正确或优先次序错误
-
循环终止不正确（如多循环一次或少循环一 次）、死循环
-
不恰当地修改循环变量
-
当遇到分支循环时，出口错误等
-
-
出错处理
-
好的设计应该能预测到出错的条件并且有对出错处理的路径。
-
-
边界条件
-
边界条件的测试是单元测试的最后工作，也是非常重要的工作。软件容易在边界出现错误。
-
-
-
黑盒测试（功能测试）
-
在完全不考虑软件的内部结构和特性的情况下来测试软件的外部特性
-
等价类划分
-
同时覆盖所有无效等价类，不符合测试用例
-
-
边界值分析
-
错误猜测
-
因果图的报告
-
-
白盒测试（结构测试）
-
根据程序的内部结构和逻辑来设计测试用例
-
对程序的执行路径和过程进行测试
-
检查是否满足设计的需要
-
逻辑覆盖
-
基本路径测试
-
-
功能测试
-
检查软件是否能实现需求中指定的那些功能
-
-
性能测试
-
测试软件的安全性、精确性、速度和可靠性
-
-
回归测试
-
识别在改正当前故障的同时可能会引入新的故障
-
-
验收测试
-
客户对系统进行测试以验证软件系统是否符合他们对需求的理解
-
-
-
集成测试
-
模块以及模块之间的接口的测试
-
自顶向下集成
-
较早地验证了主要控制和判断点
-
可以首先实现和验证一个完整的软件功能
-
功能较早证实，带来信心;
-
只需一个驱动，减少驱动器开发的费用
-
支持故障隔离
-
-
自底向上集成
-
对底层组件行为较早验证;
-
比自顶向下效率高
-
减少了桩的工作量
-
支持故障隔离
-
x/y，y赋值0，出现故障，属于事务故障
-
-
-
三明治
-
优势是结合了自底向上和自顶向下的优点，如较早地验证了主要的控制构件和底层模块，并行测试程度较高
-
缺点是需要写较多的驱动模块和桩模块
-
-
一次性
-
-
系统测试
-
验证系统是否确实执行需求规格说明中描述的功能和非功能要求
-
-
-
内部和外部发布
-
-
-
-
-
软件度量
-
软件复杂性度量
-
规模
-
源程序行数
-
-
难度
-
程序中出现的操作数的数目
-
-
结构
-
与程序结构有关的度量来表示
-
-
智能度
-
算法的难易程度
-
-
-
冗余技术
-
结构冗余
-
信息冗余
-
时间冗余
-
冗余附加技术
-
为实现其他类型冗余技术所需要的资源和技术，包括程序指令、数据、存放和调动它们的空间和通道等
-
在屏蔽硬件错误的容错技术中，冗余附加技术包括
-
关键程序和数据的冗余存储及调用：检测、表决、切换、重构、纠错和复算的实现
-
-
在屏蔽软件错误的容错技术中，冗余附加技术包括
-
冗余备份程序的存储及调用；实现错误检测和错误恢复的程序；实现容错软件所需的固化程序。
-
-
-
-
-
软件设计质量评审
-
规格说明是否合乎用户的要求
-
评审可靠性
-
保密性
-
操作命令和操作信息的恰当性
-
评审性能实现情况
-
评审软件是否具有可修改性，可扩充性、可互换性和可移植性。
-
可测试性
-
复用性
-
-
系统分析阶段的复审过程中
-
应该指出软件的可移植性问题以及可能影响软件维护的系统界面
-
应该从容易修改、模块化和功能独立的目的出发，评价软件的结构和过程
-
代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素
-
-
成本估算
-
Wolverton模型
-
成本矩阵，软件类型和难易成本
-
-
COCOMO模型
-
COCOMO II
-
规模
-
考虑软件开发的不同阶段
-
应用组装模型
-
早期设计阶段模型
-
体系结构阶段模型
-
-
规模估算选择
-
对象点
-
功能点
-
代码行
-
-
-
