软件工程-期末总结

软件工程期末总结

课程：xxxxx

姓名：xxxxx

学号：xxxxxx

班级：xxxxxx

目录

1.软件工程学概述 (1)

1.1软件危机 (1)

1.2软件工程 (1)

1.3软件生命周期 (2)

1.4软件过程 (2)

2.可行性研究: (2)

2.1可行性研究的任务 (2)

2.2可行性研究的过程 (3)

2.3数据流图 (3)

3.需求分析 (3)

4.形式化说明技术 (4)

5.模块设计 (4)

1．耦合： (4)

2．内聚 (4)

6.详细设计 (5)

6.1结构程序设计 (5)

6.2人机界面设计 (5)

7.软件测试 (5)

7.1软件测试的目标 (5)

7.2软件侧试准则 (6)

7.3测试方法 (6)

8.软件可靠性 (7)

8.1软件质量 (7)

1.软件工程学概述

1.1软件危机

1.1.1 软件危机的介绍:是指在计算机软件的开发和维护过程中所遇到的一系列严重

问题。具体地说，软件危机主要有以下一些典型表现：1.对软件开发成本和进

度的估计常常很不准确。2.用户对“已完成的”软件系统不满意的现象经常发

生。3.软件产品的质量往往靠不住。4.软件常常是不可维护的。5.软件通常没

有适当的文档资料。6.软件成本在计算机系统总成本中所占的比例逐年上升。

7.软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

1.1.2产生软件危机的原因:在软件开发和维护的过程中存在这么多严重问题，一方面

与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软

件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。

1.1.3消除软件危机的途径:1、认识到软件是程序、数据及相关文档的完整集合。

2.

认识到软件是一种组织良好、管理严密、各类人员协同配合、共同完成的工程

项目；3、推广使用在实践中总结出来的开发软件的成功的技术和方法，探索

更好更有效的技术和方法；4、开发和使用更好的软件工具。。总之，为了解决

软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。软

件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一

门新兴学科。

1.2软件工程

1.2.1软件工程的介绍:软件工程是指导计算机软件开发和维护的一门工程学科。定

义：采用工程的概念、原理和方法来开发与维护软件，把经过时间考验而证明

正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出

高质量的软件并有效地维护它。

1.2.2软件工程的基本原理:1、用分阶段的生命周期计划严格管理2、坚持进行阶段

评审3、实行严格的产品控制4、采用现代程序设计技术5、结果应能清楚地审

查6、开发小组的人员应该少而精7、承认不断改进软件工程实践的必要性

1.2.3 软件工程方法学:通常把在软件生命周期全过程中使用的一整套技术方法的集

合称为方法学，也称为范型。软件工程方法学包含3个要素方法、工具和过程。

目前使用得最广泛的软件工程方法学，分别是传统方法学和面向对象方法学

1.3软件生命周期

软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。软件定义的3个阶段：问题定义、可行性研究、需求分析; 软

件开发的四个阶段：总、详（系统设计）、编、综（系统实现）

软件生命周期每个阶段:1.问题定义2.可行性研究3.需求分析4.总体设计5.详细设计6.编码和单元测试7.综合测试8.软件维护

1.4软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

1.4瀑布模型瀑布模型

一直是唯一被广泛采用的生命周期模型,有下述的几个特点：1.阶段间具有顺序性和依赖性（1）必须等前一阶段的工作完成之后，才能开始后一阶段的工作（2）前一阶段的输出文档就是后一段的输入文档，因此，前一阶段的输出文档必须正确。2.推迟实现的观点；3.质量保证的观点（1）每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务，（2）每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题改正错误。

优点：可强迫开发人员采用规范的方法；严格地规定每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。

缺点：瀑布模型是由文档驱动的

2.可行性研究:

可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

2.1可行性研究的任务

可行性研究的目的不是解决问题，而是确定问题是否值得去解决。可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程，也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。在澄清了问题定义之后，分析员应该导出系统的逻辑模型。然后从系统逻辑模型出发，探索若干种可供选择的主要解法（即系统实现方案）。对每种解法都应该仔细研究它的可行性，一般说来，至少应该从下述3个方面研究每种解法的可行性。

1）技术可行性使用现有的技术能实现这个系统吗？

2）经济可行性这个系统的经济效益能超过它的开发成本吗？

3）操作可行性系统的操作方式在这个用户组织内行得通吗？

必要时还应该从法律、社会效益等更广泛的方面研究每种解法的可行性。

可行性研究需要的时间长短取决于工程的规模。一般来说，可行性研究的成本只是预期的工程总成本的5%-10%。

2.2可行性研究的过程

步骤：1.复查系统规模和目标2.研究目前正在使用的系统3.导出新系统的高层逻辑模型4.进一步定义问题5.导出和评价供选择的解法6.推荐行动方针7.草拟开

发计划8.书写文档提交审查

2.3数据流图

数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。

数据流图有四种基本符号：

正方形（或立方体）表示数据的源点或终点；

圆角矩形（或圆形）代表变换数据的处理；

开口矩形（或两条平行横线）代表数据存储；

箭头表示数据流，即特地数据的流动方向。

在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。数据存储和数据流都是数据，仅仅所处的状态不同。数据存储是处于静止状态的数据，数据流是处于运动中的数据。数据流图的基本要点是描绘“做什么”，而不是“怎么做”。数据流图的4种成分：源点或终点，处理，数据存储，数据流数据流图的基本目的是利用它作为交流信息的工具，另一个主要用途是作为分析和设计的工具。

3.需求分析

3.1.1确定对系统的综合需求1.功能需求2.性能需求3.可靠性和可用性需求

4.出错

处理需求5.接口需求6.约束7.逆向需求8.将来可能提出的需求

4.形式化说明技术

PSL/PSA系统的主要优点是它改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用。数据存放在数据库中，便于增加、删除和更改，这也是它的一个优点。

5.模块设计

模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结果。

开发具有独立功能而且和其他模块之间没有过多的相互作用的模块，就可以做到模块独立。

1．耦合：

耦合是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度因此，模块间的耦合程度强烈影响系统的可理解性、可测试性、可靠性和可维护性。公共环境耦合的复杂程度随耦合的模块个数而变化，当耦合的模块个数增加时复杂程度显著增加。如果只有两个模块有公共环境，那么这种耦合有下面两种可能。1.一个模块往公共环境送数据，另一个模块从公共环境取数据。这是数据耦合的于一种形式，是比较松散的耦合。2.两个模块都既往公共环境送数据又从里面取数据，这种耦合比较紧密，介于数据耦合和控制耦合之间。如果两个模块共享的数据很多，都通过参数传递可能很不方便，这时可以利用公共环境耦合。最高程度的耦合是内容耦合。如果出现下列情况之一，两个模块间就发生了内容耦合。一个模块访问另一个模块的内部数据。一个模块不通过正常入口而转到另二个模块的内部。两个模块有一部分程序代码重叠（只可能出现在汇编程序中）。一个模块有多个入口（这意味着一个模块有几种功能）。应该坚决避免使用内容耦合。事实上许多高级程序设计语言已经设计成不允许在程序中出现任何形式的内容耦合。总之，耦合是影响软件复杂程度的一个重要因素。应该采取下述设计原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。

2．内聚

内聚标志着一个模块内各个元素彼此结合的紧密程度，它是信息隐藏和局部化概念的自然扩展。简单地说，理想内聚的模块只做一件事情。内聚和耦合是密切相关的，模块内的高内聚往往意味着模块间的松耦合。内聚和耦合都一是进行模块化设计的有力工具，但是实践表明内聚更重要，应该把更多注意力集中到提高模块的内聚程度上。低内聚：偶然内聚、时间内聚、逻辑内聚；中内聚主要有两类：过程内聚和通信内聚；高内聚也有两类：顺序内聚和功能内聚。功能内聚是最高程度的内聚。

6.详细设计

详细设计阶段的根本目标是确定应该怎样具体地实现所要求的系统，也就是说，经过这个阶段的设计工作，应该得出对目标系统的精确描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。详细设计阶段的任务还不是具体地编写程序，而是要设计出程序的“蓝图”，以后程序员将根据这个蓝图写出实际的程序代码。因此，详细设计的结果基本上决定了最终的程序代码的质量。考虑程序代码的质量时必须注意，程序的“读者”有两个，那就是计算机和人。在软件的生命周期中，设计测试方案、诊断程序错误、修改和改进程序等都必须首先读懂程序。实际上对于长期使用的软件系统而言，人读程序的时间可能比写程序的时间还要长得多。因此，衡量程序的质量不仅要看它的逻辑是否正确．性能是否满足要求，更主要的是要看它是否容易阅读和理解。详细设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程应该尽可能简明易懂。结构程序设计技术是实现上述目标的关键技术，因此是详细设计的逻辑基础。

6.1结构程序设计

如果一个程序的代码块仅仅通过顺序，选择和循环这3种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称为程序的结构化。

6.2人机界面设计

人机界面设计是接口设计的一个重要的组成部分。在设计人机界面过程会遇到下面4个问题：系统响应时间，用户帮助设施，出错信息处理和命令交互。用户界面设计过程是一个迭代的过程，首先创建设计模型，再用原型实现这个设计模型，并由用户试用和评估，然后根据用户意见进行修改。为了支持上述迭代过程，各种用于界面设计和原型开发的软件工具产生。它们为简化窗口，菜单，设备交互，出错信息，命令及交互环境的许多其它元素的疮疖提供各种历程或对象。用户界面评估周期如下，完成初步设计之后就创建第一级原型，用户使用并评估该原型，直接向设计者表述对界面的评价，设计中根据用户意见修改设计并实现下一级原型。

7.软件测试

7.1软件测试的目标

1.测试是为了发现程序中的错误而执行程序的过程。

2.好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。

3.成功的测试是发现了至今为止尚未发现的错误的测试。从上述规则可以看出，测试的正确定义是“为了发现程序中的错误而执行程序的过程”。这和某些人通常想象的“测试是为了表明程序是正确的”,“成功的

测试是没有发现错误．的测试”等是完全相反的。正确认识测试的目标是十分重要的，测试目标决定了测试方案的设计。如果为了表明程序是正壑耍进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。因此，在综合测试阶段通常由其他人员组成测试小组来完成测试工作。此外，应该认识到测试决不能证明程序是正确的。即使经过了最严格的测试之后，仍然可能还有没被发现的错误潜藏在程序中。测试只能查找出程序中的错误，不能证明程序中没有错误。关于这个结论下面还要讨论。

7.2软件侧试准则

怎样才能达到软件测试的目标呢？为了能设计出有效的测试方案，软件工程师必须深人理解并正确运用指导软件测试的基本准则。下面讲述主要的测试准则。1.所有测试都应该能追溯到用户需求。2.应该远在测试开始之前就制定出测试计划。3.把Paret原理应用到软件测试中。Pareto原理说明，测试发现的错误中的80%很可是由程序中20％的模块造成的。当然，问题是怎样找出这些可疑的模块并彻底地测试它们。

4.应该从“小规模”测试开始，并逐步进行“大规模”测试。通常，首先重点测试单个程序模块，然后把测试重点转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。

5.穷举测试是不可的。所谓穷举测试就是把程序所有可能的执行路径都检查一遍的测试。即使是一个中等规模的程序，其执行旋的排列数也十分庞大，由于受时间、人力以及其他资源的限制，在测试过程中不可能执行每个可能的路径。囚此，测试只能证明程序中有错误，不能证明程序中没有错误。但是，精心地设计测试方案，有可能充分覆盖程序逻辑并使程序达到所要求的可靠性。

6.为了达到最佳的测试效果，应该由独立的第三方从事测试工作。所谓“最佳效果”是指有最大可能性发现错误的测试。由于前面已经讲过的原因，开发软件的软件工程师并不是完成全部测试工作的最佳人选（通常他们主要承担模块测试工作）。

7.3测试方法

测试任何产品都有两种方法：如果已经知道了产品应该具有的功能，可以通过测试来检验是否每个功能都能正常使用琅口果知道产品的内部工作过程，可以通过测试来检验产品内部动作是否按照规格说明书的规定正乒进行。前一种方法称为黑盒测试，后一种方法称为白盒测试。对于软件测试而言，黑盒测试法把程序看作一个黑盒子，完全不考虑程序的内部结均和处理过程。也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序否能适当地接收输人数据并产生正确的输出信息，程序运行过程中能否保持外部信息（例如，数据库或文件）的完整性。黑盒测试又称为功能测试。白盒测试法与黑盒测试法相反，它的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按测程序中的主要执行通路是否都能按预定要求正确工作。照程序内部的逻辑测试程序，白盒测试又称为结构测试。

8.软件可靠性

可靠性定义：软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功的运行的概率可用性定义：软件可用性是程序在给定的时间点，按照规格说明书的规定，成功的运行的概率基本假定 1.在测试之前每1000条指令中大约有5~20个错误 2.失效率正比于剩余的错误数，平均无故障时间MTTF与剩余错误数成反比3.为了简化讨论假设发现的每一个错误都立即正确地改正了。

8.1软件质量

概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

上述定义强调了下述的6个要点:

1.正确性（它按我的需要工作吗？）系统满足规格说明用户目标的程度，即，在预定环境下能正确的完成预期功能的程度。

2.健壮性（对息外环境它能适当地响应吗？)在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能做出适当的响应程度。

3.效率〔完成预定功能时它需要的计算机资源多吗？）为了完成预定的功能，系统需要的计算资源的多少。

4.完整性（安全性）（它是安全的吗？)对未经授权的人使用软件或数据的企图，系统能够控制（禁止）的程度。

5.可用性（我能使用它吗？)系统在完成预定应该完成的功能时令人满意的程度。

6.风险（能按预定计划完成它吗？)按预定的成本和进度把系统开发出来，并且为用户所满意的概率。