Lecture 1：软件工程概述

描述：本节说明软件的组成与特点、软件危机的表现与原因，以及软件工程为何产生、要解决什么问题。

1.1 什么是软件

软件是与计算机系统运行有关的程序、数据及配套文档的完整集合，可概括为：

$$ \text{软件}=\text{程序}+\text{数据}+\text{文档}. $$

从使用形态看，它包含两部分：

机器可执行部分：程序和程序处理的数据。
人可阅读部分：与开发、测试、部署、维护和使用有关的需求、设计、测试、操作、维护等文档。

文档不是可有可无的附件。没有需求、接口、部署和维护说明的软件，很难由团队长期演化，也难以验证其行为是否符合预期。

1.2 软件的特点

1.2.1 逻辑性、抽象性和无形性

软件是一种逻辑产品，其结构和行为不能像机械零件一样直接触摸，必须借助源代码、模型、文档、存储介质和运行结果来观察。

1.2.2 智力密集

软件是人类分析、设计和创造活动的产物。其主要成本通常集中在需求、设计、编码、测试、协作和维护，而不是复制介质。

1.2.3 不会发生物理磨损

软件被反复运行不会像硬件那样因摩擦而磨损，复制成本也很低。

但“不会被用坏”不等于“永远不失效”：

潜在缺陷可能在特定输入或环境下被触发。
操作系统、依赖、硬件和业务环境变化会使原软件不再适用。
多次维护若引入新缺陷或破坏结构，会产生常说的“软件退化”或“软件老化”现象。

1.2.4 复杂性和定制性

软件需要针对用户需求进行系统分析与设计，业务规则、状态和交互组合会带来很高的逻辑复杂度。

NOTE 课件写“每一个软件都具有定制性”适合强调需求差异，但不能理解为所有软件都必须从零开发。现代工程广泛使用组件、框架、开源库、软件产品线和配置化平台，只对差异部分定制。

1.2.5 维护复杂

软件交付后仍需修复缺陷、适应环境、增加功能和改善质量。维护人员必须理解原有需求、架构、代码、数据和历史决策，修改还可能影响其他模块，因此维护往往占软件生命周期的大量成本。

1.3 软件危机

1.3.1 定义

软件危机是软件开发和维护过程中遇到的一系列严重问题的统称，不是某一次孤立故障。

1.3.2 典型表现

项目成本和进度难以准确估计，频繁超支、延期甚至取消。
最终产品与真实需求不一致。
软件质量差、缺陷多、可靠性和安全性不足。
缺乏完整文档，维护和交接困难。
生产率增长跟不上软件规模和复杂度增长。
修改一个局部却引发其他模块故障，维护费用持续上升。

1.3.3 主要原因

软件规模、状态和交互迅速增长，复杂度难以由个人直接掌控。
需求不完整、含糊或持续变化。
开发过程缺少规范、计划、评审、度量和风险管理。
只重视编码，忽视需求、设计、测试、文档和维护。
团队沟通、配置管理和质量保证不足。
工具、方法和人员能力不能匹配项目难度。

1.4 软件工程的产生与定义

软件工程是为解决软件危机而形成的工程学科。它使用工程化、系统化、规范化并可度量的方法开发、运行和维护软件。

课件的定义强调：

采用工程的概念、原理、技术和方法。
把经过实践验证的管理技术与当前可用的优秀技术方法结合起来。
以经济方式开发高质量软件。
软件交付后仍要能够被有效维护。

因此，软件工程既不是“会编程”，也不是单纯使用某种工具，而是技术与管理的结合。

1.5 软件工程的基本要素

可以从四个相互配合的方面理解：

要素	作用
质量目标	规定正确性、可靠性、可维护性、性能、安全性等期望
过程	组织需求、设计、实现、测试、交付和维护活动
方法	提供分析、建模、设计、编码、测试和度量技术
工具	对过程和方法提供自动化或半自动化支持

项目管理、质量保证、配置管理、风险管理和评审活动贯穿整个过程。

1.6 常考辨析

1.6.1 程序是否等于软件

不等于。程序只是软件的一部分，软件还包括数据和开发、使用、维护所需的文档。

1.6.2 软件没有物理磨损，为什么仍需维护

因为缺陷会被触发，需求和运行环境会变化，系统还需增加功能和改善质量。软件维护针对逻辑和环境变化，不是修复材料磨损。

1.6.3 软件工程是否只关注开发

不是。软件工程覆盖开发、运行、维护和退役，并包含人员、过程、项目和质量管理。

本节复盘

软件由程序、数据和文档组成，程序不等于完整软件。
软件具有抽象、智力密集、无物理磨损、复杂和维护困难等特点。
软件危机表现为延期、超支、质量差、需求偏离和维护困难，根源既有复杂度，也有过程和管理问题。
软件工程因软件危机而产生，以工程化方法经济地开发高质量、可维护的软件。
软件工程同时依靠质量目标、过程、方法、工具和贯穿始终的管理活动。