软件工程知识点归纳.docx
《软件工程知识点归纳.docx》由会员分享，可在线阅读，更多相关《软件工程知识点归纳.docx（14页珍藏版）》请在冰豆网上搜索。
软件工程知识点归纳
软件工程知识点归纳
第1章软件工程学概述
1.1软件危机
1.软件危机的定义、表现、产生原因
2.消除软件危机的途径
3.软件产品必须由一个完整的配置组成，软件配置主要包括程序、文档和数据等成分。
1.2软件工程
软件工程是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。
1.软件工程的定义
2.软件工程的基本原理
3.软件工程方法学
软件工程方法学的三要素：
方法、工具、过程。
目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学。
1.3软件生命周期
1.软件生命周期由软件定义、软件开发和运行维护（也称为软件维护）3个时期组成，每个时期又进一步划分成若干个阶段。
2.软件定义、开发和运行维护3个时期的各自任务
3.软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。
该时期又称为系统分析，由系统分析员负责完成。
4.开发时期具体设计和实现在前一个时期定义的软件，它通常由下述4个阶段组成：
总体设计，详细设计，编码和单元测试，综合测试。
其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。
5.运行维护时期的主要任务是使软件持久地满足用户的需要。
每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。
1.4软件过程
1.软件过程的定义：
是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
2.过程定义了运用方法的顺序、应该交付的文档资料、为保证软件质量和协调变化所需要采取的管理措施，以及标志软件开发各个阶段任务完成的里程碑。
3.通常使用生命周期模型简洁地描述软件过程。
生命周期模型规定了把生命周期划分成哪些阶段及各个阶段的执行顺序。
瀑布模型
是软件工程中应用得最广泛的过程模型。
瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。
快速原型模型
快速原型定义：
是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。
快速原型的本质是“快速”。
开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。
增量模型
使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
螺旋模型
螺旋模型是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
主要适用于内部开发的大规模软件项目。
喷泉模型
是面向对象软件开发过程，软件开发过程类似“喷泉”的迭代和无缝的特性。
模型的特点和缺点比较如下：
瀑布模型文档驱动系统可能不满足客户的需求
快速原型模型关注满足客户需求可能导致系统设计差、效率低，难于维护
增量模型开发早期反馈及时，分批提交系统增量构件易于维护需要开放式体系结构，可能会设计差、效率低
螺旋模型风险驱动风险分析人员需要有丰富的经验
关于选择生命周期模型的最后总结
1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.
第2章可行性研究
2.1可行性研究的任务
可行性研究的目的不是解决问题，而是确定问题是否值得去解决。
可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。
一般说来，至少应该从下述三方面研究每种解法的可行性：
技术、经济、操作。
2.2可行性研究过程
可行性研究过程包括：
复查系统规模和目标、研究正在使用的系统、导出新系统的高级逻辑模型（数据流图和数据字典）、进一步定义问题、依次从技术、操作、经济三个方面导出和评价供选择的可行性方案、推荐行动方针、草拟开发计划、书写文档提交审查（可行性分析报告）。
2.3系统流程图
概括地描绘物理系统的传统工具，是物理数据流图。
它的基本思想是用图形符号以黑盒子形式描绘组成系统的每个部件（程序，文档，数据库，人工过程等）。
系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程。
2.4数据流图
1.数据流图描绘信息流和数据从输入移动到输出的过程中所经受的变换，只是描绘数据在软件中流动和被处理的逻辑过程。
数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具。
2.数据流图包括的图形元素：
正方形（或立方体）表示数据的源点或终点；圆角矩形（或圆形）代表变换数据处理；开口矩形（或两条平行横线）代表数据存储；箭头表示数据流，即特定数据的流动方向。
3.数据存储和数据流的区别：
数据存储和数据流都是数据，仅仅所处的状态不同。
数据存储是处于静止状态的数据，数据流是处于运动中的数据。
4.数据流图按照“数据处理”进行细化分层。
2.5数据字典
1.数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。
2.数据流图和数据字典共同构成系统的逻辑模型。
3.数据字典应该由对下列4类元素的定义组成：
（1）数据流
（2）数据流分量（即数据元素）（3）数据存储（4）处理
4.数据字典是开发数据库的第一步，而且是很有价值的一步。
2.6成本/效益分析
软件开发成本主要表现为人力消耗（乘以平均工资则得到开发费用）。
成本估计不是精确的科学，有3种估算技术：
代码行技术、任务分解技术、自动估计成本技术。
第3章需求分析
3.1需求分析的任务
需求分析的基本任务是准确地回答“系统必须做什么?
”这个问题。
需求分析的成果：
以书面形式准确地描述软件需求，写出软件需求规格说明书。
确定对系统的综合要求
功能需求、性能要求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的需求。
分析系统的数据要求
常用的图形工具有层次方框图和Warnier图
导出系统的逻辑模型
数据流图和数据字典等
修正系统开发计划
3.2与用户沟通获取需求的方法
访谈、面向数据流自顶向下求精、简易的应用规格说明技术、快速建立软件原型
3.3分析建模与规格说明
1.模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。
2.需求分析过程应该建立3种模型，它们分别是数据模型（实体-联系图）、功能模型（数据流图）和行为模型（状态转换图）。
3.4实体-联系图
描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。
3.5数据规范化
1.数据规范化的必要性:
为减少数据冗余，避免出现插入异常或删除异常
2.范式的定义:
消除数据冗余的程度
3.第一范式（1NF）数据冗余程度最大，第五范式（5NF）数据冗余程度最小。
但是，范式级别越高，存储同样数据就需要分解成更多张表，范式级别提高则需要访问的表增多，因此性能（速度）将下降。
从实用角度看来，在大多数场合选用第三范式都比较恰当。
3.6状态转换图
状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为，建立起软件系统的行为模型。
3.7其他图形工具
1.层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。
2.Warnier图表示信息层次结构。
3.IPO图是输入、处理、输出图的简称，描述数据流图中各个处理的基本算法。
3.8验证软件需求
从四个方面验证需求：
一致性、完整性、现实性、有效性。
第4章形式化说明技术
1.按照形式化的程度，可以把软件工程使用的方法划分成非形式化、半形式化和形式化3类。
2.用自然语言描述需求规格说明，是典型的非形式化方法。
用数据流图或实体-联系图建立模型，是典型的半形式化方法。
3.形式化方法的定义：
是描述系统性质的基于数学的技术，也就是说，如果一种方法有坚实的数学基础，那么它就是形式化的。
4.非形式化和半形式化方法的不足
5.形式化方法的优点
6.形式化方法的种类
第5章总体设计
总体设计的基本目的就是回答“概括地说，系统应该如何实现?
”这个问题，总体设计又称为概要设计或初步设计。
总体设计的任务：
（1）划分出组成系统的物理元素——程序、文件、数据库、人工过程和文档等等；
（2）设计软件的结构，也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互间的关系。
总体设计的过程：
（1）首先寻找实现目标系统的各种不同的方案，需求分析阶段得到的数据流图是设想各种可能方案的基础。
（2）然后分析员从这些供选择的方案中选取若干个合理的方案，为每个合理的方案都准备一份系统流程图，列出组成系统的所有物理元素，进行成本/效益分析，并且制定实现这个方案的进度计划。
总体设计的必要性：
可以站在全局高度上，花较少成本，从较抽象的层次上分析对比多种可能的系统实现方案和软件结构，从中选出最佳方案和最合理的软件结构，从而用较低成本开发出较高质量的软件系统。
5.1设计过程
总体设计过程通常由两个主要阶段组成：
系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。
典型的总体设计过程包括下述9个步骤：
设想供选择的方案、选取合理的方案、推荐最佳方案、功能分解、设计软件结构、设计数据库、制定测试计划、书写文档、审查和复审。
5.2设计原理
模块化
1.模块的定义：
模块是由边界元素限定的相邻程序元素（例如，数据说明，可执行的语句）的序列，而且有一个总体标识符代表它。
2.过程、函数、子程序和宏等，都可作为模块。
面向对象方法学中的对象是模块，对象内的方法（或称为服务）也是模块。
模块是构成程序的基本构件。
3.模块化的定义：
把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能满足用户的需求。
抽象
软件工程过程的每一步都是对软件解法的抽象层次的一次精化。
在可行性研究阶段，软件作为系统的一个完整部件；在需求分析期间，软件解法是使用在问题环境内熟悉的方式描述的；当由总体设计向详细设计过渡时，抽象的程度也就随之减少了；最后，当源程序写出来以后，也就达到了抽象的最低层。
逐步求精
1.逐步求精的定义：
为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
2.求精实际上是细化过程。
信息隐藏和局部化
1.信息隐藏的定义：
应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。
2.应该隐藏的不是有关模块的一切信息，而是模块的实现细节。
3.局部化是指把一些关系密切的软件元素物理地放得彼此靠近。
模块独立
1.模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。
2.模块独立的重要性：
有效的模块化的软件比较容易开发，独立的模块比较容易测试和维护。
3.模块独立程度的两个定性标准度量：
内聚和耦合。
模块独立的目标：
高内聚和低耦合。
4.内聚衡量一个模块内部各个元素彼此结合的紧密程度。
功能内聚是最高程度的内聚。
5.耦合衡量不同模块彼此间互相依赖的紧密程度。
模块间耦合程度分为：
无耦合、数据耦合、控制耦合、特征耦合、公共环境耦合、内容耦合。
5.3启发规则
启发规则往往能帮助找到改进软件设计提高软件质量的途径。
主要有：
改进软件结构提高模块独立性、模块规模应该适中、深度、宽度、扇出和扇入都应适当、模块的作用域应该在控制域之内、力争降低模块接口的复杂程度、设计单入口单出口的模块、模块功能应该可以预测。
5.4描绘软件结构的图形工具
描绘软件的层次结构的层次图，HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图，结构图。
5.5面向数据流的设计方法
面向数据流的设计方法把数据流图变换成软件结构。
第6章详细设计
详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个蓝图写出实际的程序代码。
衡量程序的质量不仅要看它的逻辑是否正确，性能是否满足要求，更主要的是要看它是否容易阅读和理解。
6.1结构程序设计
1.是详细设计的逻辑基础。
2.只用3种基本的控制结构（“顺序”、“选择”和“循环”）就能实现任何单入口单出口的程序。
3.结构程序设计的定义：
如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
6.2人机界面设计
1.人机界面设计的重要性：
人机界面设计是接口设计的一个重要的组成部分，人机界面的设计质量，直接影响用户对软件产品的评价，从而影响软件产品的竞争力和寿命。
2.设计人机界面需要考虑的问题：
系统响应时间、用户帮助设施、出错信息处理和命令交互。
3.系统响应时间的定义和两个重要属性、常见的用户帮助设施、
4.用户界面设计是一个迭代的过程，主要依靠设计者的经验。
6.3过程设计的工具
过程设计的工具指描写程序处理过程的工具。
主要有：
程序流程图、盒图、PAD图、判定表、判定树、过程设计语言。
他们的主要特点如下：
程序流程图是历史最悠久、使用最广泛的描述过程设计的方法
盒图表现嵌套关系，也可以表示模块的层次结构
PAD图翻译成程序代码比较容易
判定表能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。
判定树是判定表的变种形式简单到不需任何说明，一眼就可以看出其含义，因此易于掌握和使用
过程设计语言称为伪码，是用正文形式表示数据和处理过程的设计工具。
6.4面向数据结构的设计方法
面向数据结构的设计方法设计每个模块的处理过程。
Jackson图和Warnier方法是最著名的两个面向数据结构的设计方法
6.5程序复杂程度的定量度量
如何度量详细设计阶段设计出的模块质量，比较广泛的McCabe方法（根据程序控制流的复杂程度定量度量程序的复杂程度）和Halstead方法（根据程序中运算符和操作数的总数来度量程序的复杂程度）。
第7章实现
编码和测试统称为实现。
编码就是把软件设计结果翻译成用某种程序设计语言书写的程序。
程序的质量主要取决于软件设计的质量。
测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。
测试的作用目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。
大量统计资料表明，软件测试的工作量往往占软件开发总工作量的40%以上。
调试的目的诊断并改正错误通过测试发现的错误。
软件工程的根本目标：
开发出高质量的完全符合用户需要的软件。
7.1编码
编码过程中需要做的工作有：
选择程序设计语言、编码风格。
1.选择程序设计语言应该有良好的模块化机制，以及可读性好的控制结构和数据结构，应该有良好的独立编译机制。
2.编码风格应该是逻辑简明清晰、易读易懂。
7.2软件测试基础
测试规则：
（1）测试是为了发现程序中的错误而执行程序的过程；
（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
（3）成功的测试是发现了至今为止尚未发现的错误的测试。
（4）测试决不能证明程序是正确的。
（5）测试发现的错误中的80%很可能是由程序中20%的模块造成的。
（6）穷举测试是不可能的。
（7）为了达到最佳的测试效果，应该由独立的第三方从事测试工作。
（8）应该从“小规模”测试开始，并逐步进行“大规模”测试。
测试方法
1.黑盒测试又称为功能测试：
把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。
也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用。
2.白盒测试又称为结构测试：
按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作。
测试步骤
1.模块测试又称为单元测试
模块测试的目的是保证每个模块作为一个单元能正确运行。
2.子系统测试
模块相互间的协调和通信是这个测试过程中的主要问题，这个步骤着重测试模块的接口。
3.系统测试
子系统测试还是系统测试，都兼有检测和组装两重含义，通常称为集成测试。
发现的往往是软件设计中的错误，也可能发现需求说明中的错误。
4.验收测试也称为确认测试，是在用户积极参与下进行的，而且可能主要使用实际数据（系统将来要处理的信息）进行测试。
其目的是验证系统确实能够满足用户的需要，在这个测试步骤中发现的往往是系统需求说明书中的错误。
5.并行运行
所谓平行运行就是同时运行新开发出来的系统和将被它取代的旧系统，以便比较新旧两个系统的处理结果。
7.3单元测试（模块测试）
1.单元测试主要使用白盒测试技术,单元测试期间着重从下述5个方面对模块进行测试:
模块接口、局部数据结构、重要的执行通路、出错处理通路、边界条件
2.代码审查：
审查小组进行代码检查
3.计算机测试：
模块并不是一个独立的程序，因此必须为每个单元测试开发驱动程序和（或）存根程序。
通常驱动程序也就是一个“主程序”，它接收测试数据，把这些数据传送给被测试的模块，并且印出有关的结果。
存根程序代替被测试的模块所调用的模块。
因此存根程序也可以称为“虚拟子程序”。
它使用被它代替的模块的接口，可能做最少量的数据操作，输出对入口的检验或操作结果，并且把控制归还给调用它的模块。
7.4集成测试（子系统测试和系统测试）
由模块组装成程序时有两种方法。
一种方法是先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，这种方法称为非渐增式测试方法；另一种方法是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。
这种每次增加一个模块的方法称为渐增式测试（普遍采用）。
当使用渐增方式把模块结合到程序中去时，有自顶向下和自底向上两种集成策略。
回归测试的定义：
指重新执行已经做过的测试的某个子集，以保证上述这些变化没有带来非预期的副作用。
7.5确认测试（验收测试）
确认测试通常使用黑盒测试法。
验收测试是由最终用户而不是系统的开发者进行的。
Alpha测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
开发者负责记录发现的错误和使用中遇到的问题。
总之，Alpha测试是在受控的环境中进行的。
Beta测试是软件在开发者不能控制的环境中的“真实”应用。
用户记录在Beta测试过程中遇到的一切问题（真实的或想像的），并且定期把这些问题报告给开发者。
接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
7.6白盒测试技术
测试方案包括具体的测试目的（例如，预定要测试的具体功能），应该输入的测试数据和预期的结果。
逻辑覆盖
逻辑覆盖是对一系列测试过程的总称，这组测试过程逐渐进行越来越完整的通路测试。
覆盖源程序语句的详尽程度分析，大致有以下一些不同的覆盖标准。
1.语句覆盖：
选择足够多的测试数据，使被测程序中每个语句至少执行一次。
2.判定覆盖又叫分支覆盖：
不仅每个语句必须至少执行一次，而且每个判定的每种可能的结果都应该至少执行一次，也就是每个判定的每个分支都至少执行一次。
判定覆盖比语句覆盖强
3.条件覆盖：
不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。
条件覆盖通常比判定覆盖强，因为它使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。
4.判定/条件覆盖：
选取足够多的测试数据，使得判定表达式中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。
能同时满足这两种覆盖标准的逻辑覆盖。
5.条件组合覆盖是更强的逻辑覆盖标准，它要求选取足够多的测试数据，使得每个判定表达式中条件的各种可能组合都至少出现一次。
控制结构测试
1.基本路径测试
2.条件测试
3.循环测试
7.7黑盒测试技术
黑盒测试着重测试软件功能。
黑盒测试并不能取代白盒测试，它是与白盒测试互补的测试方法，可以发现下述类型的错误：
①功能不正确或遗漏了功能；②界面错误；③数据结构错误或外部数据库访问错误；④性能错误；⑤初始化和终止错误。
白盒测试在测试过程的早期阶段进行，而黑盒测试主要用于测试过程的后期。
等价划分
将程序的输入域划分成若干个数据类，据此导出测试用例。
边界值分析
按照边界值分析法，应该选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据。
错误推测
不同类型不同特点的程序通常又有一些特殊的容易出错的情况。
在很大程度上靠直觉和经验进行。
它的基本想法是列举出程序中可能有的错误和容易发生错误的特殊情况，并且根据它们选择测试方案。
7.8调试（修改测试发现的错误）
调试是软件开发过程中最艰巨的脑力劳动。
调试的目标都是寻找软件错误的原因并改正错误。
3种调试的途径。
7.9软件可靠性
1.软件可靠性的定义：
是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。
2.按照IEEE的规定，术语“错误”的含义是由开发人员造成的软件差错（bug），而术语“故障”的含义是由错误引起的软件的不正确行为。
3.软件可用性的定义：
是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。
第8章维护
软件维护是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。
大型软件的维护成本高达开发成本的4倍左右。
目前国外许多软件开发组织把60%以上的人力用于维护已有的软件。
8.1软件维护的定义
软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
软件维护的类型：
改正性维护、完善性维护、适应性维护、预防性维护。
软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。
8.2软件维护的特点
1.结构化维护与非结构化维护差别巨大。
2.维护的代价高昂
3.维护的问题很多
8.3软件维护过程
软件维护过程本质上是修改和压缩了的软件定义和开发过程。
1.建立正式的维护组织
2.提交维护报告
3.维护的事件流
4.保存维护记录
5.评价维护活动
8.4软件的可维护性
软件的可维护性：
维护人员理解、改正、改动或改进这个软件的难易程度。
决定软件可维护性的因素主要有下述5个：
可理解性、可测试性、可修改性、可移植性、可重用性。
文档是影响软件可维护性的决定因素。
文档比程序代码更重要。
8.5预防性维护
当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件
8.6软件再工程过程
包括库存目录分析、文档重构、逆向工
升级会员 