软件工程导论—软件与软件工程

文章目录

• • • 1. 软件与软件危机
    • • 1.1. 软件的概念和特点
      • 1.2. 软件规模的分类与发展阶段
      • 1.3. 软件危机
      • • 1.3.1. 软件危机的表现
        • 1.3.2. 软件危机产生的原因
        • 1.3.3. 软件危机如何解决
    • 2. 软件工程学
    • • 2.1. 软件工程学的概念
      • 2.2. 软件工程项目的基本目标
      • 2.3. 软件工程的八项原则
      • 2.4. 软件工程的本质特征
      • 2.5. 软件工程的七条基本原理
    • 3. 软件工程方法学
    • • 3.1. 软件工程方法学的概念
      • 3.2. 传统软件工程与面向对象软件工程
      • • 3.2.1. 传统软件工程与面向对象软件工程的对比
        • 3.2.2. 传统软件工程的生命周期
    • 4. 软件开发模型
    • • 4.1. 传统开发模型
      • • 4.1.1. 瀑布模型(waterfall model)
        • 4.1.2. 快速原型模型(rapid prototype model)
      • 4.2. 演化开发模型
      • • 4.2.1. 增量模型(incremental model)
        • 4.2.2. 螺旋模型(spiral model)
      • 4.3. 面向对象开发模型
      • • 4.3.1. 构件集成模型(component integration model)

1. 软件与软件危机

1.1. 软件的概念和特点

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。

其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发，维护和使用有关的图文材料。

与之相似的是，在1983年IEEE组织对软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必需的数据。

比软件定义更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

软件有以下七个特点：

1. 软件是一种逻辑实体，而不是具体的物理实体，因而它具有抽象性；
2. 软件的生产与硬件不同，它没有明显的制造过程；
3. 在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。但就目前的软件工程环境应用而言，在不更新升级的情况下软件的平均寿命大约为5年，如果一个软件5年内没有任何更新，那么它将面临淘汰；
4. 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性；
5. 软件的开发至今尚未完全摆脱手工艺的开发方式；
6. 软件本身是复杂的，这种复杂性可能来自它所反映的实际问题的复杂性，例如相当多的软件工作涉及到 会因素，复杂性也可能来自程序逻辑结构的复杂性；
7. 软件产品质量不可靠。 软件可靠性和质量保证的确切的定量概念刚刚出现不久，软件质量保证技术(审查、复审和测试)还没有坚持不懈地应用到软件开发的全过程中，这些都导致软件产品发生质量问题;计算机软件不仅仅是程序，还应该有三整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，而且应该是”最新式的”(即和程序代码完全一致的)。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况:软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息;对于软件维护人员而言，这些文档:资料更是必不可少的。
8. 缺少软件文档，大型软件系统经常失败。 缺乏方法指导和工具支持导致很多程序中的错误是非常难改正的，甚至一旦换了一个新的硬件环境就不能正常运行，也不能根据用户的需要在原有程序中增加一些新的功能。”可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件
9. 软件开发效率不高，与计算机应用的迅速发展不匹配。 软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件产品”供不应求”的现象使人类不能充分利用现代计算机硬件提供的巨大潜力。

1.3.2. 软件危机产生的原因

客观原因：软件本身特点，例如逻辑部件复杂、规模庞大等等。

在软件开发和维护的过程中存在这么多严重问题，一方面与软件本身的特点有关，另一方面也和软件开发与维护的方法不正确有关。软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件，在运行过程中不会因为使用时间过长而被”用坏”，如果运行中发现了错误很可能是遇到了一个在开发时期引入的，在测试阶段没能检测出来的错误。

软件不同于一般程序，它的一个显著特点是规模庞大，而且程序复杂性将随着程序规模的增加而呈指数上升。

主观原因：程序员不正确的开发方法，忽视需求分析，并且错误地认为软件开发等于程序编写，轻视软件维护。

主观上的错误认识和作法主要表现为忽视软件需求分析的重要性，认为软件开发就是写程序并设法使之运行，轻视软件维护等。目前相当多的软件专业人员对软件开发和维护还有不少其他的糊涂观念，在实践过程中或多或少地采用了错误的方法和技术，这可能是使软件问题发展成软件危机的主要原因。

对用户要求没有完整准确的认识就匆忙着手编写程序是许多软件开发工程失败的主要原因之一。另一方面还必须认识到程序只是完整的软件产品的一个组成部分，一个软件产品必须由一个完整的配置组成，主要包括程序、文档和数据等成分，他们缺一不可。

软件问题要尽早解决
作好软件定义时期的工作，是降低软件，成本提高软件质量的关键。在实际的软件开发中，在软件开发的不同阶段进行修改需要付出的代价是很不相同的，大约如下图所示，它表示了错误发现的越晚，付出的代价越高。

2.3. 软件工程的八项原则

1. 抽象
   抽取事物最基本的特性和行为，忽略非基本的细节。采用分层次抽象，自顶向下、逐层分解的办法控制软件开发过程的复杂性。例如，软件瀑布模型、结构化分析方法、结构化设计方法，以及面向对象建模技术等都体现了抽象的原则。
2. 封装(信息隐蔽)
   将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则。使用者只能通过模块接口访问模块中封装的数据。
3. 模块化
   模块是程序中逻辑上相对独立的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。
4. 局部化
   要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于加强模块的独立性，控制解的复杂性。
5. 确定性
   软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。这有助于人们之间在交流时不会产生误解、
   遗漏，保证整个开发工作协调致。
6. 一致性
   整个软件系统(包括程序、文档和数据)的各个模块应使用一致的概念、符 和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致。
7. 完备性
   软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。
8. 可验证性
   开发大型的软件系统需要对系统自顶向下逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。

2.4. 软件工程的本质特征

软件工程关注于大型程序的构造
“大”与”小”的分界线并不十分清晰。通常把一个人在较短时间内写出的程序称为小型程序，而把多人合作用时半年以上才写出的程序称为大型程序。

软件工程的中心课题是控制复杂性
软件所解决的问题十分复杂，通常不得不把问题分解，使得分解出的每个部分是可理解的，而且各部分之间保持简单的通信关系。用这种方法并不能降低问题的整体复杂性，但是却可使它变成可以管理的。

软件经常变化
绝大多数软件都模拟了现实世界的某一部分。现实世界在不断变化，软件为了不被很快淘汰，必须随着所模拟的现实世界一起变化。因此，在软件系统交付使用后仍然需要耗费成本，而且在开发过程中必须考虑软件将来可能的变化。

开发软件的效率非常重要
目前， 会对新应用系统的需求超过了人力资源所能提供的限度，软件供不应求的现象日益严重。因此，软件工程的一个重要课题就是，寻求开发与维护软件的更好更有效的方法和工具。

和谐地合作是开发软件的关键
软件处理的问题十分庞大，必须多人协同工作才能解决这类问题。为了有效地合作，必须明确地规定每个人的责任和相互通信的方法。纪律是成功地完成软件开发项目的一个关键。

软件必须有效地支持它的用户
开发软件的目的是支持用户的工作。软件提供的功能应该能有效地协助用户完成他们的工作。

有效地支持用户意味着必须仔细地研究用户，以确定适当的功能需求、可用性要求及其他质量要求(例如，可靠
性、响应时间等)。有效地支持用户还意味着，软件开发不仅应该提交软件产品，而且应该写出用户手册和培训材料。

在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人
软件工程师是诸如Java程序设计、软件体系结构、测试或统一建模语言(UML)等方面的专家，他们通常并不是图书馆管理、航空控制或银行事务等领域的专家，但是他们却不得不为这些领域开发应用系统。缺乏应用领域的相关知识，是软件开发项目出现问题的常见原因。

有时候，软件开发者通过访谈、阅读书面文件等方法了解到用户组织的“正式”工作流程，然后用软件实现这个工作流程。但是，决定软件系统成功与否的关键问题是，用户组织是否真正遵守这个工作流程

2.5. 软件工程的七条基本原理

著名的软件工程专家B.W.Boehm综合学者们的意见，于1983年在一篇论文中提出了软件工程的七条基本原理。这七条原理是确保软件产品质量和开发效率的原理的最小集合。

这七条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理。同时这七条原理又是相当完备的，虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的一百多条软件工程原理都可以由这七条原理的任意组合蕴含或派生。

七条基本原理：

1. 用分阶段的生命周期计划严格管理
   经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的。因此应该把软件生命周期划分成若千个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划；一般来说软件的生命周期分为定义阶段、可行性研究阶段、需求分析阶段、程序设计阶段、编码阶段、测试阶段、运行维护阶段。
2. 坚持进行阶段评审
   软件的质量保证工作不能等到编码阶段结束之后再进行，这样说至少有两个理由：
   第一，大部分错误是在编码之前造成的，根据统计，设计错误占软件错误的63%，编码错误仅占37%；
   第二，错误发现与改正得越晚，所需付出的代价也越高；
   因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。
3. 实行严格的产品控制
   在软件开发过程中改变需求是难免的，只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。
   所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成分。基准配置管理也称为变动控制，指的是一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。绝对不能谁想修改软件，就随意进行修改。
4. 采用现代程序设计技术
   从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术，并进一步研究各种先进的软件开发与维护技术。实践表明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。
5. 结果应能清楚地审查
   软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限来规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。
6. 开发小组的人员应该少而精
   软件开发小组的组成人员的素质应该好，而人数则不宜过多。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。
   此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成的通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着大数N的增大，通信开销将急剧增加。
7. 承认不断改进软件工程实践的必要性
   遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅有上述6条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第7条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。

3. 软件工程方法学

3.1. 软件工程方法学的概念

软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的整套技术方法的集合称为方法学(Methodology)，也称为范型(Paradigm)。

软件工程方法学包含3个要素:

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

3.2. 传统软件工程与面向对象软件工程

3.2.1. 传统软件工程与面向对象软件工程的对比

目前使用得最广泛的软件工程方法学有传统方法学（面向数据流/结构化方法学） 和 面向对象方法学。他们分别代表了两种程序设计方法：即结构化程序设计(程序=数据结构+算法) 和 面向对象程序设计(程序=对象+请求消息)

两种方法学的软件开发流程如下所示：
传统软件工程：软件分析→总体设计→详细设计→面向过程的编码→测试。会有一个清楚的流程体系。
面向对象软件工程：软件分析与对象抽取→对象详细设计→面向对象的编码→测试。

3.2.2. 传统软件工程的生命周期

所谓软件生命周期，软件从产生、发展到成熟，直至衰亡为止的整个过程。

它由八个小阶段组成：

国标《计算机软件开发规范》将软件生存周期分为可行性研究与计划、需求分析、总体设计、详细设计、实现(编码和单元测试)、集成测试、确认测试、使用和维护共八个小阶段

这八个小阶段又可以分为三个时期：

1. 计划时期。问题定义、可行性分析
   问题定义阶段必须回答的关键问题是”要解决的问题是什么如果不知道问题是什么就试图解决这个问题，显然是盲目的。尽管确切地定义问题的必要性是十分明显的，但是在实践中它却可能是最容易被忽视的一个步骤。通过对客户的访问调查，系统分析员扼要地写出关于问题性质、工程目标和工程规模的书面 告，经过讨论和必要的修改之后这份 告应该得到客户的确认。
   可行性研究阶段的关键是明确要解决问题，找出行得通解决方法，并且给出粗略的计划。系统分析员需要从经济、技术、 会(操作)等方面对软件项目进行可行性分析。可行性研究应该比较简短，这个阶段的任务不是具体解决问题，而是研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法。可行性研究的结果是使用部门负责人作出是否继续进行这项工程的决定的重要依据。可行性研究以后的那些阶段将需要投入更多的人力物力。及时终止不值得投资的工程项目，可以避免更大的浪费。
2. 开发时期。需求分析、软件设计(总体设计、详细设计)、编码、测试(单元测试和集成测试)
   需求分析阶段需要确定目标系统的任务目标以及必须具备哪些功能。系统分析员必须和用户密切配合，充分交流信息以得出经过用户确认的系统逻辑模型。通常用数据流图、数据字典和简要的算法表示在需求分析阶段确定的系统逻辑模型是以后设计和实现系统的基础。这个阶段的一项重要任务，是用正式文档准确地记录对目标系统的需求，这份文档通常称为需求《规格说明书》。
   总体设计阶段应该明确用什么方法去实现目标系统。首先，应该根据需求分析阶段的结果设计出实现目标系统的多种可选的方案。通常至少应该设计出低成本、中等成本和高成本等3种方案。软件工程师在充分权衡各种方案的利弊的基础上，推荐一个最佳方案。制定出实现最佳方案的详细计划。一个程序应该由若干个规模适中的模块按合理的层次结构组织而成。总体设计的另一项主要任务就是设计程序的体系结构，也就是确定程序由哪些模块组成以及模块间的关系，最终完成总体设计后需要记录在文档中，这份文档称为《总体设计说明书》。
   详细设计阶段的任务就是把实现目标系统的方法具体化。详细设计也称为模块设计，在这个阶段将详细地设计每个模块，确定实现模块功能所需要的算法和数据结构，最终形成一份《详细规格说明》，这种规格说明应该包含必要的细节，程序员可以根据这些细节写出实际的程序代码。
   编码和单元测试阶段的关键任务是写出正确的、容易理解、容易维护的程序模块。程序员应该根据目标系统的性质和实际环境，选取适当的程序设计语言，把详细设计的结果翻译成用选定的语言书写的程序，并且仔细测试(调试)编写出的每一个模块。
   集成测试阶段的关键任务是通过各种类型的测试(及相立的调试)使软件达到预定的要求。最基本的测试是集成测试和验收测试。所谓集成测试是根据设计的软件结构，把经过单元测试检验的模块按某种选定的策略装配起来，在装配过程中对程序进行必要的测试；所谓验收测试则是按照规格说明书的规定，由用户对目标系统进行验收。必要时还可以再通过现场测试或平行运行等方法对目标系统进一步测试检验，集成测试和验收测试结束后应该形成文档《测试 告》，里面应当写明测试计划、测试方案和结果。
3. 运行时期。软件维护
   软件维护阶段是要通过各种必要的维护活动使系统持久地满足用户的需要”。通常有四类维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化，例如Windows迁移到Linux；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件为将来的维护活动预先做准备。每一项维护活动都实质上是经历了一次压缩和简化了的软件定义和开发的全过程。

实际从事软件开发工作时，软件规模、类型、开发环境及技术方法等因素会影响到阶段划分，及各阶段的执行顺序，形成不同生存周期模型，又称过程模型。也就是说以上的三个时期所包含的阶段不一定非要按照国标来进行，应当按照实际情况灵活安排软件周期。

4. 软件开发模型

软件开发模型实际上是软件工程三要素中”过程”要素的展开，下面介绍几种经典的软件开发模型

4.1. 传统开发模型

4.1.1. 瀑布模型(waterfall model)

瀑布模型一直是唯一被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的文档驱动的过程模型。如下图所示为传统的瀑布模型

4.1.2. 快速原型模型(rapid prototype model)

快速原型模型是低成本的，进行循环需求分析的一个快速开发模型。它的基本结构如图所示。

一个螺旋式周期包括下面4个完整步骤：

1. 确定目标，选择方案，选定完成目标的策略
2. 从风险角度分析该策略
3. 启动一个开发阶段
4. 评价前一步的结果，并计划下一轮的工作

4.3. 面向对象开发模型

4.3.1. 构件集成模型(component integration model)

构建集成模型是一个典型的面向对象开发模型，它的一个典例就是各种开发IDE，例如Visual Studio，可以查找加载各种构建。

构建集成模型有着以下五个特点：面向对象、基于构件库、融合螺旋模型特征、支持软件开发的迭代方法、软件重用