《软件工程导论》经典复习资料.docx

《《软件工程导论》经典复习资料.docx》由会员分享，可在线阅读，更多相关《《软件工程导论》经典复习资料.docx（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第一章：1、什么是软件危机? 是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。2、什么是软件工程? 是指导计算机软件开发和维护的一门工程学科。31、软件危机产生的原因： (1) 软件是逻辑部件而不是物理部件，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量。很难检验开发的正确性且软件开发的质量也较难评价。(2)软件开发人员对软件的开发和维护存在不少错误的观念，在实践的过程中没有采用工程化的方法，或多或少采用了一些错误的方法和技术，这是造成软件危机的主要原因。(3) 开发和管理人员只重视开发而轻视问题的定义，使软件产品无法满足用户的要求。对用户的要求没有完整准确的认

2、识就急于编写程序。这是许多软件开发失败的另一主要原因。(4) 软件管理技术不能满足现代软件开发的需要，没有统一的软件质量管理规范。(5) 在软件的开发和维护关系问题上存在错误的观念。因此，必须把软件维护的观念引入软件开发的各个阶段，建立起软件开发与维护的正确关系。3.2、解决软件危机的途径：（1）为了消除软件危机，首先应该对计算机软件有一个正确的认识：软件是程序、数据及相关文档的完整集合。（2）必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。（3）应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更

3、有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误概念和做法。（4）应该开发和使用更好的软件工具。总之，为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。4、软件危机的表现（1）对软件开发成本和进度的估计常常很不准确。（2）用户对“已完成的”软件系统不满意的现象经常发生。（3）软件产品的质量往往靠不住。（4）软件通常没有适当的文档资料。（5）软件常常是不可维护的。5.1、软件过程：是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤5.2、软件工程方

4、法学：通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学，也称范型，三要素：方法、工具和过程。6、软件生命周期模型6.1瀑布模型：优点：1.可强迫开发员采用规范的方法 2.严格地规定了每个阶段必须提交的文件 3.要求每 个阶段交出的所有产品都必须经过质量保证小组的仔细验证。缺点：传统的瀑布模型过于理想化，是由文档驱动的。注意：传统“瀑布模型”的主要缺陷是：传统的瀑布模型过于理想化了。增加“反馈环”6.2快速原型模型：通过快速构建起一个可在计算机上运行的原型系统，让用户试用原型并收集用户反 馈意见的方法，获取用户真正的需要。6.3增量模型：优点：能在较短时间内向用户提交可完成部分工

5、作的产品；逐步增加产品功能可以使用 户有较充实的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。6.4螺旋模型：优点：对可选方案和约束条件的强调有利于已有软件的重用；减少了过多测试；维护只 是螺旋模型中另一个周期。7、简述结构化范型和面向对象范型的要点及优缺点。 （1）传统方法学（结构化范型）：也称为生命周期方法学或结构化范型。 优点：把软件生命周期划分成基干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作， 从而降低了整个软件开发过程的困难程度。缺点：当软件规模庞大时，或者对软件的需求是模糊的或会承受时 间而变化的时候，开发出的软件往往不成功；而且维护

6、起来仍然很困难。（2）面向对象方法学(面向对象范型)：优点：降低了软件产品的复杂性；提高了软件的可理解性；简化了软件的开发和维护工作； 促进了软件重用。8、软件生命周期划分成哪些阶段8.1、软件生命周期（阶段）：软件定义、软件开发和运行维护三个时期组成。其中：定义时期3个：问题定义、可行性研究和需求分析。开发时期4个：系统设计（总体设计、详细设计）、系统实现（编码和单元测试、综合测试）。维护时期1个：（运行维护）主要任务是使软件持久地满足用户的需要。8.2、软件定义时期的任务：确定软件开发工程必须完成的总体目标，确定工程的可行性，导出实现工程的目标应采用的策略及系统必须完成的功能；估计该项工程

7、需要的资源和成本，并制定工程进度表。 开发时期任务：具体设计和实现前一时期定义的软件。 维护阶段任务：主要任务是使软件持久地满足用户的需要。第二章：9、可行性研究的目的：就是用最小的代价在尽可能短的时间内确定问题是否能够解决。可行性研究的任务：1.进一步分析和澄清问题；2.导出系统的逻辑模型；3.从逻辑模型出发，提出若干种系统实现方案 4.研究每种实现方案的可行性：可行性研究包括：技术上的可行性、经济上的可行性、操作可行性。10、数据流图（DFD）：是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。 符号包括：（必考内容） 数 据 数据存储 数据流 源点 处理 或 处理

8、 11.数据字典：是关于数据的信息的集合，也就是对数据流图中饮食的所有元素的定义的集合。数据流图与数据字典共同构成系统的逻辑模型。12、软件工程订货系统及数据字典：P44-P49P53第2题银行储蓄系统数据流图及E-R图P53第3题银行储蓄系统数据流图及E-R图P53第4题银行储蓄系统数据流图及E-R图第三章：131、需求分析的准则：（1、必须并描述的信息域，根据这条准则应该建立数据模型。（2、必须定义软件应完成的功能，这条准则要求建立功能模型。（3、必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型。（4、必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节。13.2、需

9、求分析的任务：1、确定对系统的综合要求;2、分析系统的数据要求;3、导出系统的逻辑模型;4、修正系统开发计划。其中在确定对系统的综合要求方面有以下8个方面： （1）功能需求，（2）性能需求，（3）可靠性和可用性需求，（4）出错处理需求 （5）接口需求，（6）约束，（7）逆向需求，（8）将来可能提出的要求。13.3、需求分析的发放：E-R图。14、结构化分析方法：就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流的输出端入手分析，这是因为系统的基本功能是产生这些输出

10、，输出数据决定了系统必须具有的最基本的组成元素。分析工具：数据流图，数据字典，IPO，层次方框图，状态转换图。15、快速建立软件原型：是最准确、最有效、最强大的需求分析技术。因为它“快速”，“易修改”。16、数据模型包括：数据对象、数据对象的属性、数据对象彼此之间的关系（E-R）。E-R的基本成分：实体、属性、关系。分析建模：数据模型、功能模型、行为模型。验证需求：一致性、完成性、现实性、有效性。17习题答案：P73第三题：第五章：18、总体设计的任务：划分出组成系统的物理元素程序、文件、数据库、人工过程和文档等等 设计软件的结构。也就是要确定系统中每个程序是由哪些模块组成的，以及这些模块相互

11、间的关系。19、总体设计过程两个阶段（1.系统设计阶段，确定系统的具体实现方案；（2.结构设计阶段，确定软件结构。 总体设计的设计原理：（1、模块化，（2、抽象，（3、逐步求精，（4信息隐藏和局部化，（5、模块独立20、总体设计过程 9 个步骤1 设想供选择的方案 2 选取合理的方案 3 推荐最佳方案 4 功能分解 5 设计软件结构 6 设计数据库7 制定测试计划 8 书写文档 9 审查和审核21、模块独立：高内聚低耦合：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。功能内聚 10 分 时间内聚 3 分顺序内聚9 分 逻辑内聚 1 分通信内聚7 分 偶然内

12、聚 0 分过程内聚5 分 第六章：22、结构程序设计概念：如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接，而且每个代码块只有一个入口和一个出口，则称这个程序是结构化的23、结构程序设计 3 种概念类型：（1、 经典的结构程序设计：只允许使用顺序、IF-THEN-ELSE 型分支和 DO-WHILE 型循环着三种基本控制结构（2、 扩展的结构程序设计还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构（3、 修正的结构程序设计还允许使用EXIT（或BREAK）结构第七章24、软件测试的概念：为了发现程序中的错误而执行程序的过程。测试绝不能证明程序是正确的。目的

13、:（1）测试是为了发现程序中的错误而执行程序的过程；而不是为了证明程序是正确的。（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；（3）成功的测试是发现了至今为止尚未发现的错误的测试。25、测试方法25.1、黑盒测试：（1、 把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程（2 对程序接口进行测试，检查程序功能是否能按规格说明书的规定正常使用；程序是否能适当地接受输入数据并产生正确的输出信息； 程序运行过程中能否保持外部信息的完整性 25.1、白盒测试（1、 把程序堪称装在一个透明的白盒子里，测试者完全知道程序的结构处理算法。（2 按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按预定要求正确工作26、测试步骤单元测试：（模块测试）发现的往往是编码和详细设计的错误集成测试：着重测试模块的接口系统测试：发现的往往是软件设计中的错误，也可能发现需要说明中的错误验收测试：（确认测试）往往发现需求说明书中的错误 27、逻辑覆盖：逻辑覆盖类型 逻辑覆盖是以程序的内部逻辑结构为基础的测试用例设计技术，属于白盒测试。它要求测试人员十分清楚程序的逻辑结构，考虑的是测试用例对程序内部逻辑覆盖的程度。从覆盖源程序语句的详尽程度分析，大致有以下一些不同程度的覆盖标准：1 语句覆盖 2 判定覆盖 3 条件覆盖 4 判定条件覆盖 5 条件组合覆盖