软件工程导论软件工程学概述
Posted BkbK-
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件工程导论软件工程学概述相关的知识，希望对你有一定的参考价值。
软件工程学概述
文章目录
一、软件危机
1.1 计算机系统的发展阶段
(1)第一代(20世纪60年代中期以前)
第一代：通用硬件相当普遍，软件却是为每个具体应用而专门编写的。这时的软件通常是规模较小的程序，编写者和使用者往往是同一个(或同一组)人。除了程序清单之外，没有其他文档资料保存下来。
第一阶段软件特点:
•面向批处理•有限的分布•自定义软件
(2)第二代(从20世纪60年代中期到70年代)
第二代：这个时期的一个重要特征是出现了“软件作坊”，广泛使用产品软件。 但“软件作坊”基本上仍然沿用早期形成的个体化软件开发方法。
第二阶段软件特点
•多用户•实时•数据库•软件产品
(3)第三代(70年代到80年代)
第三代：这是一个交叉时期。
第三阶段软件特点：
• 低成本硬件•分布式系统• 消费者的影响•嵌入“智能”
(4)第四代(80年代以后)
第四代：80年代以后第四代开始，真正开始是70年代末或80年代初期。
第四阶段软件特点：
•强大的桌面系统•面向对象技术•专家系统•人工神经网络•并行计算•网络计算机
1.2 软件危机的介绍
软件危机的表象：软件危机是指在计算机软件的开发和维护过程
中所遇到的一系列严重问题。
软件危机的本质：落后的软件生产方式无法满足迅速增长的计算机软件需求。
概括地说，软件危机包含下述两方面的问题：
(1)如何开发软件，以满足对软件日益增长的需求；
(2)如何维护数量不断膨胀的已有软件。
1.3 软件危机典型表现
- (1) 对软件开发成本和进度的估计常常很不准确
- (2) 用户对“已完成的”软件系统不满意的现象经常发生
- (3) 软件产品的质量往往靠不住
- (4) 软件常常是不可维护的
- (5) 软件通常没有适当的文档资料
- (6) 软件成本在计算机系统总成本中所占的比例逐年上升
- (7) 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。
1.4 产生软件危机的原因
1.4.1 一方面与软件本身的特点有关
- (1)它是计算机系统中的逻辑部件而不是物理部件。
- (2)程序是软件的组成部分。程序复杂性将随着程序规模的增加而呈指数上升。
- (3)软件本身独有的特点确实给开发和维护带来一些客观困难
1.4.2 另一方面也和软件开发与维护的方法不正确有关
①对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一
②缺乏开发方法
③对软件组成缺乏认识
④维护不规范
1.5 消除软件危机的途径
-
对计算机软件有一个正确的认识：
软件定义：计算机程序、方法及规则、相关的文档资料 以及在计算机上运行程序时所必需的数据。
软件 = 程序 + 数据 + 相关文档+技术和方法
◆程序：是能够完成预定功能和性能的可执行的指令序列；
◆数据：是使程序能够适当地处理信息的数据结构；
◆文档：是开发、使用和维护程序所需要的图文资料；
◆技术和方法：是生成软件的一套严格的工程规范。 -
应用成熟的技术和方法
◆ 充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法
◆ 特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。 -
工具集
在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当的软件工具辅助下，开发人员可以把这类工作做得既快又好。 -
加强项目管理
项目管理：人员组织、人员分工、人员协调、项目分解、进度管理、阶段监督和验收、文档的制作和管理等。
二、软件工程
2.1 软件工程的定义
2.1.1 NATO会议定义
1968年在第一届NATO会议上曾经给出了软件工程的一个早期定义：
“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，并建立和使用完善的工程原理。”
这个定义不仅指出了软件工程的目标是经济地开发出高质量的软件，而且强调了软件工程是一门工程学科，它应该建立并使用完善的工程原理。
2.1.2 IEEE定义
1993年IEEE进一步给出了一个更全面更具体的定义：
软件工程是：
①把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件开发；
②研究①中提到的途径（过程）。
2.2 软件工程的本质特性
- 软件工程关注于大型程序的构造
- 软件工程的中心课题是控制复杂性
- 软件经常变化
- 开发软件的效率非常重要
- 和谐地合作是开发软件的关键（团队）
- 软件必须有效地支持它的用户
- 在软件工程领域中是由具有一种文化背景的人替代具有另一种文化背景的人创造产品
2.3 软件工程的基本原理
著名的软件工程专家巴利.伯姆（B.W.Boehm）综合学者们的意见并，总结了
TRW公司多年开发软件的经验，于1983年在一篇论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率的原理的最小集合。
2.3.1 软件工程基本原理的特点
相互独立：
这7条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合。
相当完备：
可以证明在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。
2.3.2 软件工程的7条基本原理
1. 用分阶段的生命周期计划严格管理
2. 坚持进行阶段评审
3. 实行严格的产品控制
4. 采用现代程序设计技术
5. 结果应能清楚地审查
6. 开发小组的人员应该少而精
7. 承认不断改进软件工程实践的必要性
2.4 软件工程方法学
软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。
通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学(methodology)，也称为范型(paradigm)。在软件工程领域中，这两个术语的含义基本相同。
2.4.1 软件工程方法学要素
方法、工具和过程
- 方法是完成软件开发的各项任务的技术方法，回答“怎样做”的问题；
- 工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；
- 过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
2.4.2 传统方法学与面向对象方法学
(1)传统方法学
定义：
传统方法学也称为生命周期方法学或结构化范型。 它采用结构化技术(结构化分析、结构化设计和结构化实现)来完成软件开发的各项任务,并使用适当的软件工具或软件工程环境来支持结构化技术的运用。
特点：阶段
这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。 采用这种方法学开发软件的时候，从对问题的抽象逻辑分
析开始，一个阶段一个阶段地进行开发。
阶段意识：
（1）前一个阶段任务的完成是开始进行后一个阶段工作的前提和基础，而后一阶段任务的完成通常是使前一阶段提出的解法更进一步具体化，加进了更多的实现细节。
（2）每一个阶段的开始和结束都有严格标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一阶段的开始标准。
阶段意识的优点：
1.把软件生命周期划分成若干个阶段，每个阶段的任务相对独立，而且比较简单，便于不同人员分工协作，从而降低了整个软件开发工程的困难程度；
2.在软件生命周期的每个阶段都采用科学的管理技术和良好的技术方法，而且在每个阶段结束之前都从技术和管理两个角度进行严格的审查，合格之后才开始下一阶段的工作，这就使软件开发工程的全过程以一种有条不紊的方式进行，保证了软件的质量，特别是提高了软件的可维护性。
3.采用生命周期方法学可以大大提高软件开发的成功率，软件开发的生产率也能明显提高。
阶段意识地位和作用：
1.传统方法学仍然是人们在开发软件时使用得十分广泛的软件工程方法学。
2.如果没有完全理解传统方法学，也就不能深入理解这种方法学与面向对象方法学的差别以及面向对象方法学为何优于传统方法学。
(2)面向对象方法学
定义：
与传统方法相反，面向对象方法把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。
面向对象方法学4个要点：
(1) 把对象(object)作为融合了数据及在数据上的操作行为的统一的软件构件。
(2) 把所有对象都划分成类(class)。
(3) 按照父类(或称为基类)与子类(或称为派生类)的关系组织结构
(4) 对象彼此间仅能通过发送消息互相联系。
面向对象方法学的优势：
1.降低复杂度：
◼降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作。
2.提高复用性：
◼对象是相对独立的实体，容易在以后的软件产品中重复使用。
3.提高灵活性：
◼面向对象方法特有的继承性和多态性，进一步提高了面向对象软件的可重用性。
三、软件生命周期
3.1 软件生命周期阶段定义
软件生命周期由软件定义、软件开发和运行维护(也称为软件维护)3个时期组成，每个时期又进一步划分成若干个阶段。
-
软件定义时期通常进一步划分成3个阶段:
问题定义、可行性研究、需求分析。 -
软件开发时期：具体设计和实现在前一个时期定义的软件
通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。 -
软件维护时期：主要任务是使软件持久地满足用户需要。
改正性维护：当软件在使用过程中发现错误时应该加以改正；
适应性维护：环境改变时修改软件以适应新的环境；
完善性维护：当用户有新要求时应该及时改进软件以满足用户的新需要；
预防性维护：对维护要有预见性的准备工作。
3.2 阶段基本任务
1. 问题定义：
问题定义阶段必须回答的关键问题是：“要解决的问题是什么?”
提交问题定义报告，通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。
2. 可行性研究
这个阶段要回答的关键问题是：“对于上一个阶段所确定的问题有行得通的解决办法吗?”
可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。
3. 需求分析
这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。
系统分析员在需求分析阶段必须和用户密切配合，充分交流信息，以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典、E-R图、状态图、简要的算法表示系统的逻辑模型。
这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书(specification)。
4. 总体设计
这个阶段必须回答的关键问题是：“概括地说，应该怎样实现目标系统?”总体设计又称为概要设计。
制定出实现最佳方案的详细计划。设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系。
5. 详细设计
详细设计阶段的任务就是把解法具体化，也就是回答下面这个关键问题：“应该怎样具体地实现这个系统呢?”
详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。
6. 编码和单元测试
这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块代码。把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测 试编写出的每一个模块。
7. 综合测试
这个阶段的关键任务是通过各种类型的测试(及相应的调试)使软件达到预定的要求。
最基本的测试是集成测试（系统测试）和验收测试:
- 集成测试:
根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试。 - 验收测试:
按照规格说明书的规定，由用户对目标系统进行验收。
8. 软件维护
维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。
四、软件过程
4.1 软件过程定义
软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。
软件过程定义了：
1.运用方法的顺序
2.应该交付的文档资料
3.为保证软件质量和协调变化所需要采取的管理措施
4.标志软件开发各个阶段任务完成的里程碑。
4.2 软件过程模型
(1) 瀑布模型
在20世纪80年代之前，瀑布模型一直是惟一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。
瀑布模型的特点:
1.阶段间具有顺序性和依赖性
①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
②前一阶段的输出文档就是后一阶段的输入文档，因此，只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。
2.推迟实现的观点
①瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。
②清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。
3.质量保证的观点
软件工程的基本目标是优质、高产。
① 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
实际的瀑布模型
传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。实际的瀑布模型是带“反馈环”的，
当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
瀑布模型特点：文档驱动
各个阶段产生的文档是维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。
遵守瀑布模型的文档约束，将使软件维护变得比较容易一些。
由于绝大部分软件预算都花费在软件维护上，因此，使软件变得比较容易维护就能显著降低软件预算。
瀑布模型优点
1 可强迫开发人员采用规范的方法（例如，结构化技术）；
2 严格地规定了每个阶段必须提交的文档；
3 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
瀑布模型缺点
由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。
在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。但是，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品。
(2) 快速原型模型
快速原型模型定义
所谓快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。让用户在计算机上试用它，通过实践来了解目标系统的概貌。一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档、开发软件。
快速原型模型特点
优点：有效适应用户需求的变化
缺点： 不知循环多少次，进度难以控制
不带有反馈环：（能做到基本上线性顺序开发）
（1） 原型系统已经通过与用户交互而得到验证
（2） 开发人员通过建立原型系统已经学到了许多东西
快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。
原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。
(3) 增量模型
增量模型也称为渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
增量模型特点
采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。
增量模型则与之相反，它分批地逐步向用户提交产品，整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。
优点：
1 从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成部分工作的产品。
2 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
使用增量模型的困难：
1 在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。
2 必须把软件体系结构设计得便于按这种方式进行扩充。
3 从某种意义上说，增量模型本身是自相矛盾的：
一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。
(4) 螺旋模型
螺旋模型的基本思想是：使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。
螺旋模型优点：
对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；
减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；
在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别。
螺旋模型缺点：
除非软件开发人员具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还认为一切正常
(5) 喷泉模型
主要用于采用面向对象技术的软件开发，该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的。
对象概念的引入，使得表达分析、设计、实现等活动只使用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙。通过各个步骤的多次反复迭代，达到认识的逐步深化。每次反复都会增加或明确一些目标系统的性质。
喷泉模型优点：
“无间隙”的特点，使得开发人员可以同步进行开发，提高开发效率，节省开发时间。
喷泉模型缺点：
“无间隙”的特点，开发过程是重叠的，需要大量的开发人员，对项目管理带来了压力；尤其面对随时可能加入的各自信息、需求与材料的情况，导致开发出现无序的状态。
(6) Rational统一过程
Rational统一过程（Rational Unified Process,RUP）是由Rational公司推出的一个完整的（完美的）软件过程。是一个面向对象软件开发方法；是一个用例驱动的，以架构为核心，迭代和增量的软件过程框架。
6条最佳实践
RUP经过多年的商业化验证，总结出了6条最有效的开发经验，被称为最佳实践。
- 迭代式开发
- 管理需求
- 使用基于构件的体系结构
- 可视化建模
- 验证软件质量
- 控制软件变更
9个核心工作流
6个核心过程工作流程：
- 业务建模：深入理解目标系统实际，评估目标系统对用户机构的影响。
- 需求：捕获客户需求。
- 分析与设计：将需求分析结果转换成分析模型和设计模型。
- 实现：将设计模型转换为实现结果，用构件实现类和对象，对构件进行单元测试，将模块集成为可执行的系统。
- 测试：检查子系统之间交互与集成，验证满足需求，识别和确认缺陷。
- 部署：成功生成可执行版本，并把软件移交给用户
3个核心支持工作流程：
- 配置与变更管理：跟踪并维护在软件开发过程中产生的所有制品的完整性和一致性。
- 项目管理：为软件开发项目制定计划、人员配备、执行和监控等方面的准则，并为风险管理提供框架。
- 环境：向软件开发机构提供软件开发环境，包括过程管理和工具集。
4个工作阶段
- 初始阶段：建立业务模型，定义最终产品试图，并且确定项目的范围。
- 精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需求。
- 构建阶段：开发出所有构件和应用程序，把它们集成为客户需求的产品，并且详尽地测试所有功能。
- 移交阶段：将开发出的产品提交给用户使用。
RUP迭代式开发
- RUP强调采用迭代和渐增的方式来开发软件，整个项目开发过程由多个迭代过程组成。
- 每次迭代只针对一部分需求进行分析、设计、实现、测试和部署等工作。
- 每次迭代都在已完成的部分的基础上进行，每次给系统增加一些新功能，如此循环下去，直到完成最终目标。
- RUP重复一系列组成软件生命周期的循环。每次循环都经历一个完整的生命周期，每次循环结束都向用户交付产品的一个可运行版本。
(7)敏捷过程与极限编程
敏捷过程
为了使开发团队具有快速响应变化的能力，17位软件专家于2001年2月联合起草了敏捷软件开发宣言。宣言由4个简单的价值观生命组成：
- 个体交互胜过过程与工具：团队成员的合作、沟通以及交互能力要比单纯的软件编程能力更重要。强化团队意识。
- 可以工作的代码胜过面面俱到的文档：开发人员应该把精力放在创建可工作的代码上面，仅当迫切需要并且具有重大意义时，才进行文档编制工作。代码先于文档。
- 客户合作胜过合同谈判：能指导开发团队与客户协同工作的合同才是最好的合同。真正的工作大于形式
- 响应变化胜过遵循计划：软件过程应该有足够的能力及时响应变化，软件计划必须有足够的灵活性和可塑性。
极限编程（eXtreme Programming, XP）
1、极限编程的有效实践：
- 客户作为开发团队的成员
- 使用用户素材（用户所知道的必须，更易懂的形式和内容）
- 短交付周期
- 验收测试
- 结对编程（一人编程一人审查测试）
- 测试驱动开发（测试方案和测试结果优先）
- 集体所有，集体负责
- 持续集成：多次集成，应对需求变化，不断回归测试
- 可持续的开发速度：开发速度稳定
- 开放的工作空间：空间舒适，便于交流和讨论
- 及时调整计划：没有一成不变的计划
- 简单的设计：不断调整设计，使它相对于正在实现的用户素材而言始终处于最佳状态
- 重构：就是在不改变系统行为的前提下，重新调整和优化系统的内部结构，以降低复杂性、消除冗余、增加灵活性和提高性能。
- 使用隐喻：使用更易懂的隐喻描述系统如何运作
2、极限编程的整体开发过程
3、极限编程的迭代过程
(8)微软过程
微软公司具有自己独特的软件开发过程。微软过程综合了Rational统一过程和敏捷过程的许多优点，是对众多项目的开发经验的正确总结。
1、微软过程准则
- 项目计划应该兼顾未来的不确定因素
- 用有效风险管理来减少不确定因素的影响
- 经常生成并快速地测试软件的过渡版本，从而提高产品的稳定性和可预测性
- 采用快速循环、递进的开发过程
- 用创造性的工作来平衡产品特性和产品成本
- 项目进度表应该具有较高的稳定性和权威性
- 使用小型项目组并发地完成开发工作
- 在项目早期把软件配置项基线化，项目后期则冻结产品
- 使用原型验证概念，对项目进行早期论证
- 把零缺陷作为追求的目标
- 里程碑评审会的目的是改进工作，切忌相互指责
2、微软软件生命周期
3、微软过程模型
微软过程的每个生命周期发布一个递进的软件版本，各个生命周期持续、快速地迭代循环。
以上是关于软件工程导论软件工程学概述的主要内容，如果未能解决你的问题，请参考以下文章