软件工程期末复习.docx
《软件工程期末复习.docx》由会员分享，可在线阅读，更多相关《软件工程期末复习.docx（23页珍藏版）》请在冰豆网上搜索。
软件工程期末复习
第一章软件工程概述
v软件危机的典型表现：
1.成本和进度估计常不准确
2.用户的满意度常不高
3.质量往往靠不住
4.软件通常很难维护
5.文档资料不完整、不合格
6.软件的成本高，所占比例逐年上升
7.软件开发生产率提高的速度慢
v产生软件危机的原因：
8.客观原因
⏹软件缺乏“可见性”，管理和控制其开发过程相对困难
⏹软件大多规模庞大，而复杂性随规模以指数速度上升
9.主观原因
⏹错误的认识和做法
⏹忽视软件需求分析的重要性—急于求成，仓促上阵
⏹认为软件开发就是写程序—编程只占全部工作量的10%--20%，软件配置主要包括程序、文档和数据
⏹轻视软件维护—维护费用占总费用的55%--70%
v软件生命周期每个阶段的基本任务
10.问题定义
⏹问题：
“要解决的问题是什么”
⏹扼要写出关于问题性质、工程目标和工程规模的书面报告，并得到客户的确认。
11.可行性研究
⏹问题：
“对于上一阶段所确定的问题有行得通的解决办法吗？
”
12.需求分析
⏹准确地确定“为了解决这个问题，目标系统需要做什么”，确定系统必须具备哪些功能
13.总体设计
⏹问题：
“概括地说，应该怎样实现目标系统？
”
⏹确定程序的体系结构，即模块组成及模块间的关系
14.详细设计
⏹“应该怎样具体地实现这个系统呢？
”
⏹详细地设计每个模块，确定实现模块功能需要的算法和数据结构
15.编码和单元测试
⏹写出正确的容易理解、容易维护的程序模块
16.综合测试
⏹通过各种类型的测试使软件达到预定的要求
17.软件维护
⏹通过各种必要的维护活动使系统持久地满足用户的需要
v各个软件过程（了解）：
给定一个工程的特点，要求选择用什么模型
瀑布模型
⏹特点：
⏹阶段间的顺序性和依赖性；
⏹文档驱动性；
⏹严格阶段评估；
⏹开发初期需要清楚全部需求；
⏹开发周期长、风险大。
⏹优点：
⏹它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
⏹虽然有不少缺陷但比在软件开发中随意的状态要好得多。
⏹缺点：
⏹实际的项目大部分情况难以按照该模型给出的顺序进行，而且这种模型的迭代是间接的，这很容易由微小的变化而造成大的混乱。
⏹经常情况下客户难以表达真正的需求，而这种模型却要求如此，这种模型是不欢迎具有二义性问题存在的。
⏹客户要等到开发周期的晚期才能看到程序运行的测试版本，而在这时发现大的错误时，可能引起客户的惊慌，而后果也可能是灾难性的。
⏹会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去，有可能花在等待的时间比开发的时间要长。
称之为“堵塞状态”。
快速原型模型
⏹特点：
⏹原型可以作为标识软件需求的一种机制；
⏹原型作为第一个系统，常常是抛弃的；
⏹开发过程的交互性和迭代性；
⏹充分发挥用户在软件开发初期的作用；
⏹开发周期较短、成本较低、风险较小。
⏹优点：
⏹如果客户和开发者达成一致协议：
原型被建造仅为了定义需求，之后就被抛弃或者部分抛弃，那么这种模型很合适了
⏹迷惑客户抢占市场，这是一个首选的模型
⏹缺点：
⏹没有考虑软件的整体质量和长期的可维护性。
⏹大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
⏹由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
增量模型
⏹优点：
⏹人员分配灵活，刚开始不用投入大量人力资源，当核心产品很受欢迎时，可增加人力实现下一个增量。
⏹当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径，这样就可以先发布部分功能给客户，对客户起到镇静剂的作用。
⏹具有一定的市场。
⏹缺点：
⏹加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
⏹需求变化，很容易使增量模型退化为边做边改模型，从而是软件过程的控制失去整体性
⏹如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析
螺旋模型
⏹特点：
⏹螺旋模型的每一个周期都应用了原型模型排除风险，在确定了原型之后，又启动生命周期模型继续过程的演化；
⏹软件开发的每个阶段都是一次迭代，每旋转一个圈就前进一个层次，得到一个新的版本；
⏹强调可选方案和约束条件有利于软件重用；
⏹减少测试过多或不足带来的风险；
⏹维护看成是模型的另一个周期；
⏹需要开发人员有丰富的风险评估经验和相关专门知识。
⏹优点：
⏹对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
⏹减少测试过多或不足带来的风险；
⏹维护知识模型的另一个周期，在维护和开发之间并没有什么本质区别
⏹缺点：
⏹需要相当的风险分析评估的专门技术，且成功依赖于这种技术。
⏹很明显一个大的没有被发现的风险问题，将会导致问题的发生，可能导致演化的方法失去控制。
⏹这种模型相对比较新，应用不广泛，其功效需要进一步的验证。
喷泉模型
⏹特点：
⏹种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。
⏹认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
⏹优点：
⏹可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
⏹缺点：
⏹由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
⏹这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
第二章可行性研究
v探索若干种可选系统实现方案，至少从以下3个方面研究每种方案的可行性：
1.技术可行性使用现有的技术能实现这个系统吗？
2.经济可行性这个系统的经济效益能超过它的开发成本吗？
3.操作可行性系统的操作方式在这个用户组织内行得通吗？
v数据流图和数据字典（要会画）
第三章需求分析
v软件需求包括三个不同的层次:
⏹业务需求
⏹反映了组织机构或客户对系统、产品高层次的目标要求。
⏹用户需求
⏹文档描述了用户使用产品必须要完成的任务。
⏹功能需求—也包括非功能需求
⏹定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
v软件需求分析的目标和任务
⏹软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。
⏹需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。
v需求分析过程
⏹通过对现实环境的调查，获得当前系统的物理模型
⏹去掉具体模型中非本质因素，抽象出当前系统的逻辑模型
⏹分析当前系统与目标系统的差别，建立目标系统的逻辑模型
vE-R图、数据流图、分解图、数据字典、状态图（要会画）
v判定表、判定树（给定伪码描述能画出这两个）
v层次方框图、Warnier图、IPO图（不要求画，知道是什么样子的干什么的）
第四章形式化说明技术
v按照形式化的程度，可以把软件工程使用的方法划分为3种：
（了解）
⏹非形式化——用自然语言描述需求规格说明
⏹半形式化——如用数据流图或实体-联系图建立模型
⏹形式化——描述系统性质的基于数学的技术
v常用的形式化表示方法（了解）
⏹有穷状态机
⏹Petri网（不用细看）
⏹Z语言（不用细看）
第五章总体设计
v软件设计的目标
⏹软件需求：
解决“做什么”
⏹软件设计：
解决“怎么做”
v软件设计的任务
⏹问题结构（软件需求）——映射——>软件结构
⏹从软件需求规格说明书出发，形成软件的具体设计方案。
v遵循的基本原则（从设计原理中知道哪些是对的，哪些是错的）
⏹模块化
◆模块化是把程序划分成独立命名且独立访问的模块，每个模块完成一个子功能，把这些子功能集成起来构成一个整体，可以完成指定的功能满足用户的需求。
◆过程、函数、子程序和宏等，都可作为模块。
◆面向对象范型中的对象是模块，对象内的方法也是模块。
◆模块是构成程序的基本构件。
⏹抽象
◆人们在实践中认识到，在现实世界中一定事物、状态或过程之间总存在着某些相似的方面（共性）。
把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。
◆或者说抽象就是抽出事物的本质特性而暂时不考虑它们的细节。
⏹逐步求精
◆“为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。
”
◆求精实际上是细化过程。
◆求精要求设计者细化原始陈述，随着每个后续求精（细化）步骤的完成而提供越来越多的细节。
⏹信息隐藏和局部化
◆“为了得到最好的一组模块，应该怎样分解软件？
”
◆信息隐藏原理指出：
应该这样设计和确定模块，使得一个模块内包含的信息（过程和数据）对于不需要这些信息的模块来说，是不能访问的。
⏹模块独立
◆模块独立性
●是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其它的模块的接口是简单的
●例如,若一个模块只具有单一的功能且与其它模块没有太多的联系,则称此模块具有模块独立性
◆模块的独立程度可以由两个定性标准来度量：
●内聚——模块之间的互相连接的紧密程度的度量
⏹功能内聚
◆一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。
则称该模块为功能内聚模块
⏹信息内聚
◆这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。
这个模块将根据不同的要求，确定该执行哪一个功能。
由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块
⏹通信内聚
◆如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。
通常，通信内聚模块是通过数据流图来定义的。
⏹过程内聚
◆使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。
例如，把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。
⏹时间内聚
◆时间内聚又称为经典内聚。
这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
例如初始化模块和终止模块。
⏹逻辑内聚
◆这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能
⏹巧合内聚
◆巧合内聚（偶然内聚）。
当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块
●耦合——模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量（尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，完全不用内容耦合。
）
⏹非直接耦合
◆两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。
⏹数据耦合
◆一个模块访问另一个模块时，彼此之间是通过简单数据参数（不是控制参数、公共数据结构或外部变量）来交换输入、输出信息的
⏹标记耦合
◆一组模块通过参数表传递记录信息，就是标记耦合。
这个记录是某一数据结构的子结构，而不是简单变量
⏹控制耦合
◆如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
⏹外部耦合
◆一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
⏹公共耦合
◆若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。
公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等，公共耦合的复杂程度随耦合模块的个数增加而显著增加
⏹内容耦合
◆如果发生下列情形，两个模块之间就发生了内容耦合
◆一个模块直接访问另一个模块的内部数据;
◆一个模块不通过正常入口转到另一模块内部;
◆两个模块有一部分程序代码重迭（只可能出现在汇编语言中）;
◆一个模块有多个入口。
v根据数据流图画出结构图
第六章详细设计
v详细设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。
v在详细设计过程中，需要完成的工作是：
⏹确定软件各个组成部分内的算法以及各部分的内部数据组织
⏹选定某种过程的表达形式来描述各种算法
⏹进行详细设计的评审
v能画出程序流程图、盒图（注意选择型）、PAD图、能画出流图，计算环形复杂度
第七章实现
v软件测试的目标（了解）
⏹测试是为了发现程序中的错误而执行程序的过程；
⏹好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；
⏹成功的测试是发现了至今为止未发现的错误的测试。
v软件测试的准则（了解）
⏹Good-enough:
一种权衡投入/产出比的原则：
选择测试
⏹保证测试的覆盖程度，但穷举测试是不可能的：
有限测试
⏹所有的测试都应追溯到用户需求
⏹越早测试越好，测试过程与开发过程应是相结合的
⏹测试的规模由小而大，从单元测试到系统测试
⏹为了尽可能地发现错误，应该由独立的第三方来测试
⏹不能为了便于测试擅自修改程序
⏹既应该测试软件该做什么也应该测试软件不该做什么
v软件测试度量
v测试覆盖率
●有多少需求、代码已经被测试了
v缺陷发现率
●缺陷是何时被发现，并且有多少缺陷已经被发现。
缺陷可以根据严重性来分类。
需记录以下值：
●缺陷数目
●缺陷的严重性
v测试成功率：
●有多少测试已经通过了，并且有多少是运行正常的？
需记录以下值：
⏹已通过的测试用例的数目
⏹可利用的测试用例的数目
v软件测试的对象（了解）
⏹软件测试并不等于程序测试。
软件测试应贯穿于软件定义与开发的整个期间。
⏹需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为软件测试的对象
v软件测试技术分类图
v每个测试要做什么
v开始是单元测试，集中对用源代码实现的每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。
v组装测试把已测试过的模块组装起来，主要对与设计相关的软件体系结构的构造进行测试。
v确认测试则是要检查已实现的软件是否满足了需求规格说明中确定了的各种需求，以及软件配置是否完全、正确。
v系统测试把已经经过确认的软件纳入实际运行环境中，与其它系统成份组合在一起进行测试。
v组装测试（又叫集成测试、联合测试）的种类和优缺点
⏹通常，把模块组装成为系统的方式有两种
⏹一次性组装方式
⏹测试时会遇到许许多多的错误，改正错误更是极端困难，以为在庞大的程序中想要诊断定位一个错误时非常困难的。
而且一旦改正一个错误后，马上又会遇到新的错误，这个过程将继续下去，看起来好像永远也没有尽头
⏹增殖式组装方式
⏹在这个过程中比较容易定位和改正错误，对接口可以进行更彻底的测试，可以使用系统化的测试方法
v设计覆盖测试用例（课本作业题）
v黑盒测试又叫做功能测试或数据驱动测试，设计黑盒测试用例
v从哪些角度进行单元测试
⏹模块接口
⏹局部数据结构
⏹重要的执行通路
⏹出错处理通路
⏹边界条件
v测试种类（了解）
⏹功能测试
⏹可靠性测试
⏹强度测试
⏹性能测试
⏹恢复测试
⏹启动/停止测试
⏹配置测试
⏹安全性测试
⏹可使用性测试
⏹可支持性测试
⏹安装测试
⏹过程测试
⏹互联测试
⏹兼容性测试
⏹容量测试
⏹文档测试
v测试和调试的区别
v估算平均无故障时间
第八章维护
v维护的分类
v改正性维护（correctivemaintenance）
●诊断和改正软件中存在的错误的活动。
●通常占整个维护活动的17-21%。
v适应性维护（adaptivemaintenance）
●为了和变化了的环境适当地配合而进行的修改软件的活动。
●通常占整个维护活动的18-25%。
v完善性维护（perfectivemaintenance）
●为了满足用户在使用软件的过程中提出的增加新功能、修改已有功能或其它一般性改进的要求而进行的软件修改活动。
●通常占整个维护活动的50-66%。
v预防性维护（preventivemaintenance）
●为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件的活动。
●通常占整个维护活动的4%。
v维护过程（了解）
⏹首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列
v软件再工程过程（了解是什么、为什么）
第九章——第十一章
v给题目（应用题）给描述，设计一些模型
v三种模型（对象模型、动态模型、功能模型）及其关系
v了解分析步骤
v熟悉设计准则
v了解各个子系统设计（知道描述哪些方面）
第十二章面向对象实现
v测试策略（面向对象的测试特点）
⏹传统的测试计算机软件的策略是从“小型测试”开始，逐步走向“大型测试”。
即，从单元测试开始，然后逐步进入集成测试，最后是确认测试和系统测试
⏹在传统应用中，单元测试集中在最小的可编译程序单位——子程序（如，模块、子例程、进程）一旦这些单元均被独立测试后，它被集成进程序结构中，这时要进行一系列的回归测试以发现由于模块的接口所带来的错误和新单元加入所导致的副作用最后，系统被作为一个整体测试以保证发现在需求中的错误。
⏹在OO语境中的单元测试
⏹考虑面向对象软件时，单元的概念发生了变化。
⏹封装驱动了类和对象的定义，这意味着每个类和类的实例（对象）包装了属性（数据）和操纵这些数据的操作（方法或服务），而不是个体的模块。
⏹最小的可测试单位是封装的类或对象。
⏹类包含一组不同的操作，并且某特殊操作可能作为一组不同类的一部分存在;不再孤立地测试单个操作（传统的单元测试观点），而是将操作作为类的一部分。
⏹OO软件的类测试等价于传统软件的单元测试
⏹不同：
传统软件的单元测试往往关注模块的算法细节和模块接口间流动的数据，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的。
⏹如果类的实现正确，则类的每个实例的行为也应该是正确的。
⏹在OO语境中的集成测试
◆因为面向对象软件没有层次的控制结构，传统的自顶向下和自底向上集成策略就没有意义
◆对OO软件的集成测试有两种不同策略:
●基于线程的测试
⏹集成响应系统的一个输入或事件所需的一组类，每个线程被集成并分别测试，应用回归测试以保证没有产生副作用。
●基于使用的测试
⏹通过测试那些几乎不使用服务器类的类（称为独立类）来开始系统的构造
⏹在独立类测试完成后，下一层的使用独立类的类，称为依赖类，被测试
⏹这个依赖类层次的测试序列一直持续到构造完整个系统
◆与传统集成不同，尽可能避免使用驱动程序和桩（stubs）作为替代操作
⏹在OO语境中的确认测试
⏹在确认或系统层次，类连接的细节消失了。
⏹和传统确认一样，OO软件的确认关注于用户可见的动作和用户可识别的系统输出。
⏹为了协助确认测试的导出，测试员应该利用作为分析模型一部分的use-case实例。
⏹Use-case提供了在用户交互需求中很可能发现错误的一个场景。
⏹传统的黑盒测试方法可被用于设计确认测试用例，但主要是从动态模型和描述系统行为的脚本来设计确认测试用例。
⏹在OO语境中的系统测试
⏹系统是指一种“完整”的环境，其中包括：
●所开发出来的程序、操作系统、虚拟机、Web浏览器、硬件环境等。
⏹系统测试是指测试整个系统以确定是否能够提供应用的所有需求行为。
⏹测试的目的：
●发现导致系统出现故障的缺陷；
●发现导致系统实际操作和系统需求之间存在差异的缺陷。
v构建测试用例的方法（不会出大题，知道构造方法）
⏹测试类的方法
◆随机测试
◆划分测试
◆基于故障的测试
⏹集成测试的方法
◆多类测试
◆从动态模型到场测试用例
第十三章软件项目管理
v项目管理的概念
⏹项目是以一套独特而相互联系的任务为前提，有效地利用资源，为实现一个特定的目标所做的努力
v估计软件规模的两种方法的优缺点
⏹代码行技术
⏹代码行技术的主要优点：
◆代码是所有软件开发项目都有的“产品”，而且很容易计算代码行
⏹代码行技术的缺点：
◆源程序仅是软件配置的一个成分，用它的规模代表整个软件的规模似乎不太合理
◆用不同语言实现同一软件所需的代码行数并不同
◆不合适于非过程性语言
⏹功能点技术
⏹功能点数与所用的编程语言无关，因此，功能点技术比代码行技术更合理一些。
⏹但是，在判断信息域特性复杂级别及技术因素的影响程度时，存在相当大的主观因素。
v进度计划：
用Gantt图、工程网络画出进度计划
v了解三种组织方式（记住名字）
⏹民主制程序员组
⏹主程序员组
⏹现代程序员组
升级会员 