软件工程概述

软件工程概述

一、软件危机

20世纪60年代以前，计算机刚刚投入实际使用，软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制。当时的软件采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。

60年代中期，随着大容量、高速度计算机的出现，计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现，操作系统的发展引起了计算机应用方式的变化，大量数据处理导致第一代数据库管理系统的诞生。

软件系统的规模越来越大，复杂程度越来越高，甚至达到了开发者难以控制的程度，软件可靠性问题也越来越突出，这就导致了开发效率低下、维护困难度急剧增大、软件可靠性急剧下降的严重后果。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。

1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而60年代中期开始爆发众所周知的软件危机，为了解决该问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。

二、软件危机解决途径

作为一个新兴的工程学科，软件工程主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本 、改进软件产品质量、提高软件生产率水平的目标。

软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得良好的效果。

在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境，以期从管理和技术两方面解决软件危机问题。

此外，人工智能与软件工程的结合成为80年代末期活跃的研究领域。基于程序变换、自动生成和可重用软件等软件新技术研究也已取得一定的进展，把程序设计自动化的进程向前推进一步。在软件工程理论的指导下，发达国家已经建立起较为完备的软件工业化生产体系，形成了强大的软件生产能力 。软件标准化与可重用性得到了工业界的高度重视，在避免重用劳动，缓解软件危机方面起到了重要作用。

三、软件工程定义

软件工程自诞生以来，一直都缺乏一个统一的定义，很多学者、组织机构都分别给出了自己认可的定义。

例如最早的定义是由Friedrich L. Bauer给出的：软件工程是为了经济地获得能够在实际机器上高效运行的、可靠的软件而建立和应用一系列坚实的软件工程原则。

美国梅隆卡耐基大学软件工程研究所（SEI）给出的定义则是：软件工程是以工程的形式应用计算机科学和数学原理，从而经济有效地解决软件问题。

目前普遍使用的软件工程定义是由IEEE给出的，即软件工程是将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护。

软件工程概念实际存在两层含义，从狭义上看，软件工程着重体现在软件过程中所采用的工程方法和管理体系，例如，引入成本核算、质量管理和项目管理等，即将软件产品开发看作是一项工程项目所需要的系统工程学和管理学。从广义上看，软件工程涵盖了软件生命周期中所有的工程方法、技术和工具，包括需求工程、设计、编程、测试和维护的全部内容，即完成一个软件产品所必备的思想、理论、方法、技术和工具。

四、软件工程的目标

软件工程的目标是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。追求这些目标有助于提高软件产品的质量和开发效率，减少维护的困难。

五、软件工程的内容

针对软件生命周期全过程及其每个具体阶段的工程方法、技术细则、文档规范、技术支持、管理制度、人员组织以及质量保证体系等，每个软件开发者必须按工程的统一要求行事，不能随意地自由发挥。每个开发阶段都要产生健全的、符合工程规范的文档。软件产品是这些文档的总合，而不仅仅是程序。

六、软件工程三要素

方法、工具和过程是软件工程的三要素。

方法：完成软件开发的各项任务的技术方法，为软件开发提供 “如何做” 的技术。

工具：为运用方法而提供的自动的或半自动的软件工程的支撑环境。

过程：为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤，如何将软件工程方法与软件工具相结合，合理、及时地进行软件开发。

七、软件生命周期

软件生命周期是从软件的产生直到报废或停止使用的周期，周期内有问题定义、可行性分析、需求分析、系统设计、编码、测试、验收与运行、维护升级到废弃等阶段。

软件生命周期中的每一个阶段都有确定的任务，并产生一定规格的文档（资料），提交给下一个周期作为继续工作的依据。

按照软件的生命周期，软件的开发不再只单单强调“编码”，而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续；因此，每一周期都是按“活动 ── 结果 ── 审核 ── 再活动 ── 直至结果正确”循环往复进展的。

1.问题定义

要求系统分析员与用户进行交流，弄清“用户需要计算机解决什么问题”然后提出关于“系统目标与范围的说明”，提交用户审查和确认。

2.可行性分析

系统分析员在用户的配合下对用户的要求和现有的环境进行深入调查并写出调研报告。从经济可行性、技术可行性、操作可行性、法律可行性等方面研究并论证该项目的可行性，即该项目是否值得去做，是否存在可行的解决办法，最后形成可行性分析报告。

3.需求分析

系统分析员和用户反复讨论和商量，充分交流信息，确定待开发的软件系统“做什么”，确定软件系统的功能需求和非功能需求，用某种方法和工具构件软件系统模型，并编写软件需求规格说明书和初步的用户手册，提交评审。

4.系统设计

根据需求分析阶段确定的功能需求和非功能需求，对整个系统进行总体框架设计、详细功能设计和数据库设计等。

简单来说，需求分析阶段回答“做什么”的问题，而系统设计阶段要回答“怎么做”的问题。

设计阶段又分为概要设计和详细设计。概要设计是以需求分析的结果为依据定义系统的主要构成成分和它们之间的关系，而详细设计是定义每个系统成分内部的构造细节。

此阶段主要形成的文档有概要设计说明书、详细设计说明书、数据库设计说明书。

5.编码

编码，即系统实现阶段，本阶段主要根据详细设计说明书，用某种选定的程序设计语言把详细设计的结果转化成机器可运行的源代码，这是一个编写和调试程序的过程。

6.测试

通过各种软件测试方法和测试工具，测试软件质量，使软件的Bug降到最低，此阶段应形成软件测试报告。

7.验收与运行

将软件成果交付给客户验收，验收通过正式上线运行。

8.维护

通过各种必要的维护活动使系统持久地满足用户的需要，所涉及文档主要有软件问题报告、软件变动记录、软件维护记录。

通常维护活动有四类：

• 改正性维护：诊断和改正系统使用过程中发现的软件错误。
• 适应性维护：修改软件以适应环境的变化。
• 完善性维护：根据用户的要求改进或扩充软件使它更完善。
• 预防性维护：即修改软件为将来的维护活动做准备。

八、周期模型

软件开发过程是在软件生命周期的系统开发过程中，一系列活动和软件生成结果的集合。软件过程模型描述软件开发过程的各项活动、角色、产品及其相互关系的模型。

目前有若干软件生命周期模型，各种模型有其不同的特点，并适用于不同的开发方法。例如，瀑布模型、迭代模型、螺旋模型、增量模型和喷泉模型等。

不同的软件开发方法和软件开发模型要求有不同的工程体系。从历史看，使用最多的是结构化方法和瀑布模型，代表当前技术主流的是面向对象方法和喷泉模型。

1.瀑布模型

瀑布模型（Waterfall Model）是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。

瀑布模型开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改。项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。

瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。

缺点：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，增加了工作量。
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
• 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
• 不适应用户需求的变化。

尽管瀑布模型招致了很多批评，但是它对很多类型的项目而言依然是有效的，如果正确使用，可以节省大量的时间和金钱。对于我们的项目而言，是否使用这一模型主要取决于我们是否能理解客户的需求以及在项目的进程中这些需求的变化程度，对于经常变化的项目而言，瀑布模型可能毫无价值。

2.喷泉模型

喷泉模型（fountain model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。

喷泉模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。

优点：

• 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
• 可以从任何一个开发阶段转到另一个开发阶段，整个过程中补漏拾遗、纠错的切入点增多，不受开发阶段的限制。
• 可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

缺点：

• 由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
• 模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。