软件工程研究的基本内容是什么

软件工程研究的基本内容，通常按知识体系划成八块：需求工程、软件设计、软件构造、软件测试、软件维护、配置管理、质量保证、软件过程。八块不是并列的工种，而是一条从「要什么」到「怎么造」再到「怎么养」的链，也是各类课程大纲的骨架。

八块各自解决什么问题

需求工程解决「做对的东西」，包括获取、分析、规约、验证、管理变更。软件设计解决「怎么分层」，分体系结构设计和详细设计。软件构造是写代码，包括编码规范、复用、单元测试。

软件测试解决「有没有错」，分单元、集成、系统、验收四级。软件维护解决「上线之后怎么办」，分纠错性、适应性、完善性、预防性四类。配置管理管版本与变更，质量保证管流程与标准，软件过程管「用什么套路做」。

这八块对应 IEEE 计算机学会发布的《软件工程知识体系指南》（SWEBOK）。较早版本列十五个知识领域，近年版本有扩充，八块是其中最核心的部分，也是各类认证考试和课程大纲的骨架。

因为需求错误的代价最高。业界常引的估算曲线是：需求阶段发现并修正一个错误，成本记为 1；到设计阶段变成 3 到 5；到编码阶段变成 10；到上线之后变成 20 到 100。数量级不一定精确，趋势是公认的。

需求工程里最难的不是写文档，是变更管理。需求一定会变，问题在于变的时候有没有人知道会影响哪些模块、哪些测试用例、哪些接口。这就是为什么需求要建基线、要走变更流程。

一个具体做法是需求追踪矩阵：每一行是一条需求，每一列是设计、代码、测试用例，双向可查。它看起来笨，但审计和交接时最管用。

计算机科学问「计算是什么、什么可计算、怎样算得更快」，关心算法、复杂度、计算模型。软件工程问「一群人怎么在有限的时间和预算里，把软件造出来并且维护十年」，关心规模、协作、进度、成本。

一句话概括：计算机科学关心「能不能」，软件工程关心「值不值、稳不稳、改得动改不动」。前者是发现，后者是建造。

这个区分解释了一个现象：算法竞赛拿奖的人，未必能带好一个十人的项目。因为项目的主要难点不在算法，在沟通、约定和变更。

「软件工程」这个词本身也有来历。1968 年北约在德国加米施召开的一次会议上，面对软件项目普遍延期、超支、质量失控的「软件危机」，与会者第一次把 engineering 和 software 并置，用来指称一门尚未成型的学科。此后几十年，这门学科的主要工作就是给「造软件」找一套可重复的规矩。

软件生命周期里，维护阶段的花费通常占总成本六成以上，有些系统更高。原因不是程序员爱改代码，是业务在变、环境在变、缺陷在暴露。

维护难易取决于前期设计。模块边界清楚、依赖方向单一、测试覆盖充分，改起来就快；反之，改一处崩三处，维护成本指数上升。

四类维护里，纠错性维护只占一小部分，大头是完善性维护——用户提新需求、业务加新规则。所以「上线即结束」的想法最要不得，上线只是维护期的开始。

《人月神话》里那条著名的判断，向进度落后的项目增加人手，只会让进度更落后，说的也是这件事。人多了，沟通路径按平方增长，而维护成本主要来自理解代码，不是敲键盘。

本科阶段的课程大致是：大一大二打基础，学程序设计、数据结构、离散数学、数据库、操作系统、计算机网络；大二大三进专业课，学软件工程导论、需求分析、软件设计、软件测试、项目管理；大四进实训和毕业设计。

国内学科目录里，软件工程是工学门类下的一级学科，本科专业代码 080902。它与计算机科学与技术（080901）并列，课程重合度高，但软件工程更偏工程管理，计算机科学更偏理论。

想判断一个学校的软件工程强不强，看三样：有没有稳定的校企实训基地、有没有通过工程教育专业认证、毕业设计的题目是不是来自真实项目。这三样比排名更能说明问题。

不是。写代码是「构造」这一块，八块里只占一块。其余七块大部分时间在沟通、建模、写文档、做评审。

不需要特别好，但离散数学、概率统计、线性代数是基础课。做算法方向要求高，做工程管理方向要求相对低。

人工智能是应用领域，软件工程是建造方法。做人工智能产品同样要走需求、设计、测试、维护这一套流程，只是多了数据管理和模型评估两个环节。