软件工程基础知识

本文主要介绍软件工程的定义、软件需求分析与定义、软件架构设计、软件测试与维护，以及软件质量保证和质量评价等知识。

什么是软件工程

“软件工程”这个概念最早是在 1968 年召开的一个当时被称为“软件危机”的会议上提出的。自 1968 年以来，软件工程领域已经取得了长足的进步，极大地完善了我们的软件开发活动，尤其是对于大型软件系统。

人们从软件危机中获得的最重要教训是：大型的、复杂的软件系统的开发是一项工程，必须按工程学的方法组织软件的生产与管理，必须经过计划、分析、设计、编程、测试、维护等一系列的软件生命周期阶段。这一认识也促使了软件工程学的诞生。

简单来说，软件工程学就是研究如何有效地组织和管理软件开发的工程学科。IEEE 在 1983 年将软件工程定义为 —— 软件工程是开发、运行、维护和修复软件的系统方法。

软件工程方法学包含 3 个要素，即方法、工具和过程。

• 方法是指完成软件开发的各项任务的技术方法；
• 工具是指为运用方法而提供的软件工程支撑环境；
• 过程是指为获得高质量的软件所需要完成的一系列任务的框架。

软件需求分析与定义

软件需求的定义

软件需求就是系统必须完成的事，以及必须具备的品质。具体来说，软件需求包括功能需求、非功能需求和设计约束 3 方面内容。

• 功能需求：是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作。
• 非功能需求：是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等。
• 设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。例如必须采用国有自主知识产权的数据库系统，必须运行在 UNIX 操作系统之下等等。

另外，我们还经常听到业务需求、用户需求、系统需求等词语，这里也顺便介绍一下。

• 业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
• 用户需求：是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度出发确定的需求。
• 系统需求：是从系统的角度来说明软件的需求，它包括用特性说明的功能需求、质量属性，以及其他非功能需求，还有设计约束。

软件需求分析

需求分析是在收集软件需求信息的基础上，进行分析、建立模型，然后将其进行规格化，形成《软件需求规格说明书》，最后通过客户和管理层验证的过程。

需求分析的目标是检测和解决需求之间的冲突、发现系统的边界、详细描述出系统需求。

注意：需求必须可以被验证。

软件需求验证

在实际工作中，我们一般通过需求评审和需求测试的方法来对需求进行验证。

需求验证所包括的活动是为了确定以下几方面的内容：

• 软件需求规格说明正确描述了预期的系统行为和特征；
• 从系统需求或其他来源中得到软件需求；
• 需求是完整的和高质量的；
• 所有对需求的看法是一致的；
• 需求为继续进行产品设计、构造和测试提供了足够的基础。

软件架构

软件架构是描述系统的草图，描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象设计中，组件之间通常用接口来实现连接。

软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标一样，软件架构师（系统架构师）陈述软件架构以作为满足不同客户需求的实际系统设计方案的基础。

软件架构的根本目的是解决好软件的复用、质量和维护问题。

软件设计

软件设计的基本原则

软件设计需要遵循信息隐蔽和模块独立性原则。

信息隐蔽是指每个模块的实现细节对于其他模块来说是隐蔽的，模块中所包含的信息（包括数据和过程）不允许其他不需要这些信息的模块使用。这样，在将来由于某些因素需要修改软件时，只需要修改对应的模块即可，其他模块不会受到任何影响。

信息隐蔽技术不仅提高了软件的可维护性，而且也避免了错误的蔓延，改善了软件的可靠性。如今，信息隐蔽原则已成为软件工程学中的一条重要原则。

模块独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的。模块独立的概念是模块化、抽象、信息隐蔽和局部化概念的直接结果。通常我们会采用两个准则度量模块独立性，一个是模块间耦合，另一个是模块内聚。

• 耦合是模块之间的相对独立性（互相联系的紧密程度）的度量。模块之间的联系越紧密，联系越多，耦合度就越高，而其模块独立性就越弱。
• 内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。一个模块内部各个元素之间的联系越紧密，那么它的内聚性就越高。相对的，它和其他模块之间的耦合度就会降低，使得模块独立性更强。

因此，模块独立性比较强的模块，应该是“高内聚低耦合”的模块。

软件测试

软件测试是为了发现错误而执行程序的过程，是根据程序开发阶段的规格说明及程序内部结构而精心设计的一批测试用例（输入数据及其预期结果的集合），并利用这些测试用例去运行程序，以发现程序错误的过程。

注意，软件测试并不等于程序测试。软件测试应贯穿于软件定义与开发的整个期间，需求分析、概要设计、详细设计，以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计文档、详细设计文档，以及源代码，都应成为软件测试的对象。

建议软件开发者把「尽早地和不断地进行软件测试」作为座右铭。

关于软件测试部分的详细教程，请阅读 软件测试教程。

软件工程过程管理

尽管我们已经有了各种信息系统开发方法和开发模型，但在不同的管理水平下能发挥出来的作用却是千差万别的。为了解决软件项目过程改进难度增大，软件工程的并行与多学科组合的问题，实现过程改进的最佳效益，就有必要引入过程管理方法。

软件过程（Software Procedure）是指软件生存周期所涉及的一系列相关过程。过程是活动的集合，活动是任务的集合，任务要起着把输入进行加工然后输出的作用。活动的执行可以是顺序的、重复的、并行的、嵌套的或者是有条件触发的。

目前，业界常用的软件工程过程管理模型是 1994 年由美国国防部和卡耐基·梅隆大学下的软件工程研究中心以及美国国防部工业协会共同研制的 CMMI 模型，全称为 Capability Maturity Model Integration，即能力成熟度集成模型。

在汽车领域，则采用由 CMMI 模型发展而来的 ASPICE 软件过程改进及能力评定模型。