简介：这份文档是《软件工程教程》（第2版，吴迪、马宏茹、丁万宁主编）的课后习题参考答案，面向使用该教材的高校本科生、专升本与考研复习者，以及需要核对作业的任课教师，用于解决课后练习缺少标准解答、简答题要点难以自检的问题。资源包仅含1个doc文件，约1.1MB，按教材章节顺序编排，题号与原文对应，便于按章检索。内容覆盖选择题、填空题与简答题三类题型：既有软件危机表现、软件工程定义与发展四阶段、软件工程六项目标及质量优先的权衡原则、软件生存周期三时期八阶段、瀑布与螺旋等过程模型、SWEBOK十个知识域等概念题的完整作答，也包含可行性研究中技术、经济、社会与操作可行性分析，以及货币时间价值、投资回收期、成本效益计算等需要写过程的题目。目前已有3272人学习，适合课前预习对照、期末复习背诵与答题思路梳理。

1. 知识地图：软件工程教程的复习坐标系

翻开软件工程教程的目录，很多人第一反应是章节多、概念密、名词绕。其实这门课的骨架只有一条主线：先判断项目做不做，再弄清做什么，然后设计怎么做，最后才是实现、测试与维护。课后习题之所以让人头疼，往往不是知识点没背，而是不知道某道题落在主线的哪个位置。这份笔记按这条主线把内容重新排了一遍，适合正在系统学这门课、或者考前想把知识点串成网的人。软件危机、生存周期、数据流图、模块独立性这些高频考点，都会在对应位置标出重点和容易翻车的地方。

2. 概念底座：软件危机、工程目标与生存周期八阶段

概念章看起来最像“背多分”，其实是后面所有计算题和画图题的地基。可行性研究里判断项目做不做，靠的是对软件危机成因的理解；需求分析里画数据流图，靠的是对生存周期阶段的定位。这一章把散落在第 1 章习题里的概念重新归位，先讲危机，再讲目标，然后讲生存周期与过程模型，最后落到 SWEBOK 的知识域划分。

2.1 软件危机：八条原因与七种表现的对照

软件危机不是某一个具体 bug，而是软件生产整体失控的一组症状。教材把原因归为八条：忽视前期需求分析、开发过程缺乏统一规范的方法论、文档不齐全或不准确、忽视与用户及组内成员的交流、忽视测试、不重视维护、从业人员对产业认识不足且缺经验、没有完善的质量保证体系。这八条里，前六条是过程问题，后两条是人和体系问题。

表现则是七条：开发费用和进度失控、功能与实际需求不符、可靠性差、难以维护、没有适当文档、软件成本在计算机系统总成本中占比居高不下且逐年上升、生产率提高速度跟不上应用普及速度。原因和表现最容易背串，原因回答“为什么会这样”，表现回答“看起来是什么样”。复习时可以把原因当成病因，把表现当成症状，一一对应着记。

梳理下来会发现，软件危机的根源几乎都指向“没有工程化”。这也解释了为什么后面要讲生存周期模型、要讲结构化方法，本质都是给软件开发套上可管理的流程。

2.2 软件工程的目标：六目标冲突时质量优先

软件工程的定义要背全：应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、发布和维护的工程或进行研究的学科。拆开看有三个关键词：理论技术、工程管理、按预算和进度。

目标有六个：达到要求的软件功能、取得较好的软件性能、开发出高质量软件、付出较低开发成本、需要较低维护费用、能按时完成开发并及时交付。这六个目标天然互相拉扯，功能加多了成本就上去，进度压紧了质量就可能下来。教材给的解法很明确：在目标冲突之间取得平衡，而软件质量摆在最重要的位置。质量又用六个特性评价：功能性、可靠性、可用性、效率、可维护性、可移植性。

发展阶段也要能串起来：20 世纪 70 年代提出软件生产工程化，80 年代面向对象方法成熟并形成完整体系，90 年代末出现敏捷方法并在 2001 年发表敏捷宣言，21 世纪快速应用开发继续推进，云计算、大数据、物联网、人工智能、移动互联网等技术不断涌现，模型驱动体系结构和构件化软件开发成为可能的方向。

2.3 生存周期三时期八阶段与过程模型选型

软件生存周期是从产品构想开始，经需求确定、设计、实现、测试验收、投入使用、版本更新，直到被市场淘汰的全过程。它由三个时期组成：软件定义、软件开发、运行维护；细分为八个阶段：问题定义、可行性研究、需求分析、概要设计、详细设计、软件实现和单元测试、综合测试、运行维护。

这三个时期和八个阶段的对应关系是考点。软件定义时期包含前三阶段，软件开发时期包含中间四阶段，运行维护时期只有运行维护一个阶段。考试里常问“需求分析属于哪个时期”，答案就是软件定义时期，不是开发时期，这个边界特别容易记混。

软件生存期模型也叫软件过程模型，是从需求定义到运行维护、跨越整个生命周期的过程、活动和任务的结构框架。典型模型包括瀑布模型、快速原型模型、增量模型、螺旋模型、统一过程和敏捷过程。

提示：模型选型题不要只背名字，答题时把“需求是否稳定”“项目规模”“风险高低”三个判断维度带进去，分数会稳很多。

2.4 SWEBOK 十个知识域的两类划分

SWEBOK 把软件工程知识体系划分为十个知识域，分属两类过程。开发与维护过程有五个：软件需求、软件设计、软件构造、软件测试、软件维护。支持过程也有五个：软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法、软件质量。每个知识域还可继续分解为若干论题，形成多级层次结构，用来界定软件工程的内容和边界。

这里的记忆点是“五加五”：前五个是直接产出软件的过程，后五个是支撑前五个的过程。配置管理、工程管理、工程过程、工具方法、质量，这五项不直接写业务代码，但缺了任何一项，开发过程都会失控。很多简答题问“软件工程知识体系包括哪些”，答全十个知识域并说明两类划分，基本就到位了。

3. 可行性研究与需求分析：先决定做不做，再决定做什么

第 2 章和第 3 章的习题集中在两个问题上：这个项目值不值得做，以及要做成什么样。可行性研究负责第一个问题，需求分析负责第二个问题。两章的计算题和画图题占比很高，光背概念不够，得把公式和符号练熟。这一章把四个可行性维度、货币时间价值的三类计算、需求分析四步法、数据流图与数据字典串在一起讲。

3.1 可行性研究的四个维度与一条结论

可行性研究的任务是决定软件项目做还是不做，结论只有“做”或“不做”两种，不是写一份漂亮报告就完事。分析维度包括技术可行性、经济可行性、社会可行性、操作可行性，有的教材还会补上开发方案可行性和运行可行性。

技术可行性看现有技术能不能支撑，经济可行性看投入产出是否划算，社会可行性看是否触碰法律、版权、合同等约束，操作可行性看用户环境能否顺利接手。四个维度里，经济可行性最容易出计算题，技术可行性最容易出简答题。答题时先给结论，再分维度说明理由，最后落到“建议立项”或“建议暂缓”。

可行性研究的输出是可行性分析报告，报告里要有对旧系统的分析、对新系统的设想、可选方案对比、成本效益结论和最终建议。复习时不要只记“四个可行性”这几个字，要知道每个维度下面大概看什么。

3.2 成本效益分析：货币时间价值的三类必考计算

经济可行性里的核心是货币时间价值。未来的钱和现在的钱不能直接相减，必须先把未来收益按利率折现到当前，再和初始投资比较。常用指标有三个：纯收入（净现值）、投资回收期、投资收益率。

净现值的公式是：把每一年收益除以 (1+利率) 的年份次方，累加后减去初始投资。用 Python 写出来更直观：

# 净现值计算：未来收益逐年折现后减去初始投资 def npv(cash_flows, rate, initial_invest): # cash_flows 为每年年末收益列表，rate 为年利率 present_value = sum(cf / (1 + rate) ** (i + 1) for i, cf in enumerate(cash_flows)) return present_value - initial_invest flows = [22000, 24000, 26620] print(npv(flows, 0.10, 50000)) # 约 9834.71，为正说明经济可行

这段代码里cash_flows按年份顺序传入，rate是年利率，initial_invest是期初一次性投入。运行结果是 9834.71 元，和教材例题一致。判断规则很简单：净现值为正，项目经济上可行；为负则不可行。

第二类题是规模与工作量估算。某部门每万行 C 语言源码对应约 250K 源文件，某项目源文件 3.75M，先算规模：3.75M ÷ 250K = 15 万行 = 150KLOC；再算工作量：150KLOC ÷ 0.625KLOC/人月 = 240 人月；总成本：240 人月 × 10000 元/人月 = 240 万元；每行代码价值：240 万元 ÷ 15 万行 = 16 元/行。这类题的关键是单位统一，KLOC 和行数不要混。

第三类题是投资回收期。某系统投资 50000 元，每年节约 20000 元，生存期 4 年，利率 5%。先逐年折现：19047、18140、17277、16454，累计到第 4 年为 70918 元，纯收入 70918 − 50000 = 20918 元（教材例题中投资额按 55000 元计，纯收入为 15918 元）。投资回收期算法是：累计折现值首次超过投资额的年份，用“上年累计 + 当年折现”去补差额。教材给出的结果约 3.033 年，答题时把折现表列出来，过程分比结果分更重要。

3.3 需求分析的四步法与六项任务

需求分析分四步：获取、建模、描述、验证。获取需求是收集过程，常用方法有问卷调查、访谈、实地操作、建立原型，收集内容包括功能需求、性能需求、可靠性需求、可用性、人机界面需求、约束和出错处理。建模是把用户语言转成分析模型，面向过程方法主要用数据流图建立逻辑模型。描述是编制文档，大型系统通常产生系统定义文档、系统需求规格说明书、软件需求规格说明书三份，小系统只编 SRS 即可。验证要从完整性、一致性、有效性、现实性四个方面检查，并对需求变更做可回溯管理。

六项任务分别是：确定对系统的综合要求、分析系统的数据需求、建立系统的逻辑模型、修订系统开发计划、编写软件需求规格说明书、需求分析评审。四步法和六项任务容易混，四步法是工作流程，六项任务是交付内容，答题时按题目问法选对应的那一套。

结构化分析方法基于“分解”和“抽象”，采用面向数据流、自顶向下、逐步求精的策略。分析时通常从数据流图输出端往输入端回溯，因为输出数据决定了系统最基本的组成元素，回溯过程同时也在定义算法。分析得到的数据元素信息记入数据字典，算法简明描述记入 IPO 表。

3.4 数据流图分层与数据字典符号

数据流图有四类元素：源点/终点、处理、数据存储、数据流。画图采用自顶向下逐层细化：顶层图只有基本系统模型加源点和终点，0 层图做功能级分解，1 层图继续细化。以订货系统为例，源点是仓库管理员，终点是采购员，处理包括事务处理和产生报表，数据存储有订货信息和库存清单，数据流是事务和订货报表。

数据字典的符号必须记准：

以旅馆电话号码为例，数据字典写法是：电话号码 = 分机号 | 外线号码；分机号 = 7201…7299；外线号码 = 9 + [市话号码 | 长话号码]；长话号码 = 区号 + 市话号码；区号 = 100…300；市话号码 = 局号 + 分局号；局号 = [455|466|888|552]；分局号 = 4{数字}。注意[]表示从中选一个，{}表示重复次数，…表示取值范围，这三种符号用错是数据字典题最常见的丢分点。

4. 设计两段：总体设计的模块化与详细设计的描述工具

设计阶段分两段：总体设计定结构，详细设计定过程。总体设计处理“系统由哪些模块组成、模块之间怎么调用”，详细设计处理“每个模块内部怎么算、怎么描述”。第 4 章和第 5 章的习题分别对应这两段，画层次图、算模块独立性、选描述工具、做 Halstead 度量，都是必练题型。

4.1 总体设计的目标与九项任务

总体设计的目标是得到良好的软件总体结构，也就是独立性良好、规模适中、深度宽度扇入扇出合适的一组模块。主要任务是把分析阶段的数据模型映射成数据库设计，把数据流图映射成软件功能结构，行为模型留给详细设计阶段做流程和算法设计。

九项任务可以按顺序记：设想供选择的方案、选取合理的方案、推荐最佳方案、功能分解、设计软件结构、数据库设计、制定测试计划、编写文档、审查和复查。这九项里，功能分解和设计软件结构是核心，测试计划和文档容易被忽略，但简答题经常考“总体设计包括哪些工作”，漏项就丢分。

总体设计和详细设计的边界也要清楚：总体设计不写模块内部算法，只定接口和调用关系；详细设计不定系统结构，只描述模块内部过程。两个阶段分开的价值在于，结构问题和过程问题可以分别优化，避免把结构缺陷拖到编码阶段才暴露。

4.2 模块独立性：耦合、内聚与七条启发规则

模块独立性由耦合和内聚共同衡量。耦合越低越好，内聚越高越好。耦合从低到高大致有非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合；内聚从高到低有功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。复习时记住“低耦合高内聚”这个总原则，再记住几个典型级别即可。

改进软件结构的七条启发规则：改进模块独立性、模块规模适中、深度宽度扇入扇出适中、模块的作用域应在控制域之内、降低模块结构复杂度、设计单入口单出口模块、模块功能应可预测。这七条里，作用域和控制域的关系最容易错。作用域指受该模块判定影响的模块集合，控制域指该模块直接或间接调用的模块集合。规则要求作用域包含在控制域内，也就是一个模块做出的判断，只能影响它自己能调用到的模块。

扇入指有多少上级模块调用它，扇出指它调用多少下级模块。扇入高说明模块复用性好，扇出高说明模块控制太宽。深度是结构层次数，宽度是同一层最大模块数。这四个参数在层次图题里经常要求标注，画图时顺手标出来能避免后面漏改。

4.3 数据流图到结构图的映射步骤

映射步骤是：复查基本系统模型、复查并精化数据流图、确定数据流图类型、确定数据流边界、完成第一级分解、完成第二级分解、优化。数据流图分变换型和事务型两类：变换型有明显输入、变换、输出三段；事务型有一个事务中心，根据事务类型选择不同处理分支。

第一级分解把整个系统映射成一个顶层控制模块和输入、变换、输出三个分支。第二级分解把每个分支继续细化成具体模块。优化时要避免机械套规则产生多余控制模块，功能过分复杂的控制模块可以增加中间层或进一步分解。优化不能违背设计原理和问题域常识，也不能为了追求“最佳设计”反复折腾。结构简单往往意味着效率高，优化目标是在有效模块化前提下用尽量少的模块，在满足信息需求前提下用最简单的数据结构。

图书管理系统的借阅分支是典型例子：登记借书文件和修改库存这两个动作，谁先谁后影响不大，但必须都完成之后才能把书交给借阅人。答题时把这条约束写出来，能体现对业务顺序的理解，不只是画图。

4.4 详细设计的图形、表格与语言工具

详细设计的任务有五项：为每个模块确定算法、确定模块内部数据结构及数据库物理结构、确定模块接口细节、为每个模块设计一组测试用例、编写文档并参加复审。描述方法分三类：图形、表格、语言。

图形工具包括结构化程序流程图、盒图（N-S 图）、问题分析图（PAD）。表格工具包括判定表和判定树。语言工具是过程设计语言 PDL。结构化程序设计有三个要点：自顶向下逐步求精、只用顺序选择循环三种基本控制结构、每个模块单入口单出口。

流程图的优点是直观清晰、易于使用，缺点是流程线可以随意跳转，容易画出非结构化结构，也不易反映逐步求精过程，还不易表示数据结构。N-S 图用方框代替流程线，所有结构都是方框嵌套，结构清晰，只能表达结构化逻辑；缺点是嵌套层数多时内层方框越来越小，绘图难度上升。PAD 的特点是清晰反映层次结构、支持逐步求精、易读易写、支持结构化原理、可自动生成程序。PDL 分内外两层，外层语法严格，内层用自然语言描述实际操作，适合直接插入源程序作注释，但不如图形工具直观。

4.5 判定树与 Halstead 度量的计算题

判定树题通常给一组条件组合，要求把算法表示成树形。以行李费为例：免费托运不超过 30kg；超过 30kg 时，头等舱国内乘客超重部分每公斤 4 元，其他舱国内乘客每公斤 6 元，外国乘客比国内乘客多一倍，残疾乘客比正常乘客少一半。画判定树时先按“是否超重”分叉，再按“国内/国外”分叉，再按“舱位”和“是否残疾”分叉，每个叶子节点写清收费单价。条件顺序不要乱，先把互斥条件放上层，组合条件放下层，树才不会交叉。

Halstead 度量预测错误数的公式是 E = (N1 + N2) × log2(n1 + n2) / 3000，其中 N1、N2 是运算符和操作数的总出现次数，n1、n2 是不同运算符和不同操作数的个数。例题给的是对 75 个数据库项访问 1300 次、对 150 个运算符使用 1200 次，代入后 E ≈ 6.5，即预测程序可能包含 6 到 7 个错误。

import math # Halstead 错误预测：N1/N2 为总次数，n1/n2 为不同个数 def predicted_errors(N1, N2, n1, n2): return (N1 + N2) * math.log2(n1 + n2) / 3000 print(predicted_errors(1200, 1300, 150, 75)) # 约 6.5，取 6~7 个

参数说明：N1是运算符总次数，N2是操作数总次数，n1是不同运算符个数，n2是不同操作数个数。注意公式里 log2 的底数是 2，分母固定 3000，这两个细节抄错，整题结果就偏了。

5. 易漏点排查：五个最容易在考场上翻车的细节

概念和计算都过了一遍之后，真正拉开差距的是那些“看答案觉得简单、自己做就错”的细节。这一章按“易漏点、为什么漏、怎么补”的结构，挑出五个高频翻车点。每一条都来自习题里反复出现的失分位置，复习时对照自己的错题本过一遍，比重新翻书效率高。

5.1 易漏点一：软件危机的原因与表现背串

易漏点：把“忽视需求分析”“缺乏方法论”这些原因当成表现来答，或者把“费用进度失控”“可靠性差”这些表现当成原因来答。

为什么漏：原因和表现都用了“软件”开头，表述风格接近，背的时候只记了关键词，没记所属类别。

怎么补：用“病因—症状”框架重新整理一遍。原因回答“为什么会发生”，表现回答“发生之后看起来怎样”。答题时先看题目问的是“原因”还是“表现”，再在草稿纸上分两列写关键词，确认归属后再展开成句子。

5.2 易漏点二：生存周期三时期与八阶段的边界

易漏点：把需求分析归到软件开发时期，或者把概要设计归到软件定义时期，三时期和八阶段的对应关系记不全。

为什么漏：八个阶段名字都熟，但三个时期的切分点没有单独记，做题时靠感觉归类。

怎么补：记两个切分点。第一个切分点在需求分析之后，需求分析及以前属于软件定义时期；第二个切分点在综合测试之后，综合测试及以前属于软件开发时期，运行维护单独成期。画一条时间轴，把八个阶段标上去，再画两条竖线切三段，比背文字牢。

5.3 易漏点三：折现方向与投资回收期算反

易漏点：把未来收益直接加总去减投资，忘了折现；或者折现时把 (1+i)^n 写成 (1+i×n)；投资回收期用累计收益减投资额，算法写错。

为什么漏：公式记了个大概，指数和乘法的区别没在意；回收期只记了“几年回本”，没记“用折现后的累计值去补差额”。

怎么补：每道题先写一行“未来值 → 当前值”的转换说明，再列表逐年折现。回收期算法固定成三步：列累计折现值、找首次超过投资的年份、用上年累计加当年折现补差额。把这三步写在错题本首页，每次做题前扫一眼。

5.4 易漏点四：数据字典符号用错

易漏点：把[]和{}混用，把|和+混用，取值范围用…写成-。

为什么漏：符号长得像，平时看书一扫而过，没有动手写过完整的数据字典条目。

怎么补：把六个符号做成一张小卡片，每个符号配一个教材原例。[]是“从中选一个”，{}是“重复若干次”，|是“二选一或几选一”，+是“顺序连接”，=是“定义为”，()是“可选”。做题时先判断这一层是选择、重复还是连接，再落符号。

5.5 易漏点五：模块作用域超出控制域

易漏点：判断一个模块的作用域是否在控制域内时，只看直接调用关系，漏掉间接调用和判定影响范围。

为什么漏：控制域好判断，顺着调用链往下找就行；作用域要看“哪些模块的加工逻辑受这个判定影响”，需要理解业务，不能只看结构图。

怎么补：先画调用链确定控制域，再逐个检查控制域内的模块，看它内部的判定或加工是否引用了上层模块的判定结果。如果某个模块受影响但不在控制域内，就说明结构有问题，需要把判定下移或把受影响模块上提。答题时把“作用域 ⊆ 控制域”这个关系式写出来，再配一句解释，基本不会丢分。

注意：这五个点不需要死记，每做一套题就在错题旁边标一个编号，考前只看带编号的错题，比从头翻书快得多。

6. 复习清单：把八章内容压成一张查漏补缺表

复习到最后阶段，最忌讳的是从头再读一遍教材。更有效的做法是把每章压成三五个可检查的条目，逐条问自己“能不能不看书画出来、算出来、讲出来”。下面这张表按知识模块列出必会项和自检方式，可以打印出来逐项打勾。

这张表的使用方法是“遮住右列自问”。能顺畅说出自检方式的，直接跳过；卡住的，回到对应章节只看那一节，不要扩大范围。全部过一遍通常两到三个小时，考前一周每天过一遍，比反复通读教材有效。

还有一个容易被忽略的练习：把教材里的计算题盖住答案重做一遍，尤其是折现题和 KLOC 估算题。这两类题步骤固定，但数字一换就容易在单位和小数点上出错。做完后对照教材的过程分步检查，不要只看最终数字对不对。

我自己的血泪经验是，第一次复习时把“软件危机原因”和“表现”背得滚瓜烂熟，结果考试问的是“软件危机有哪些表现”，我下意识把八条原因全写上去了。从那以后我每次复习概念题，都强制走一遍“题目问的是原因还是表现、是流程还是交付物、是时期还是阶段”的三问，确认问法再动笔。这个习惯看起来笨，但确实把该拿的分稳住了。希望帮到你。

本文还有配套的精品资源，点击获取