ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

软件工程教程第2版课后答案:五章考点地图与易漏点自查

软件工程教程第2版课后答案:五章考点地图与易漏点自查

简介:《软件工程教程》(第2版)课后习题参考答案面向使用吴迪、马宏茹、丁万宁主编教材的高校学生与备考读者,用于课后练习核对、章节复习和知识点查漏补缺。压缩包内共1个doc文档,约1.1MB,按教材章节汇总选择题、填空题与简答题的参考答案,可直接查阅对应题目。内容涉及软件危机表现与成因、软件和软件工程定义及发展阶段、软件工程目标与质量优先原则、软件生存周期三时期八阶段、瀑布模型与敏捷过程等生存期模型、SWEBOK十个知识域,以及可行性研究、成本效益分析等典型习题,便于理解答题思路和复习重点。已有3272人学习下载,适合课堂同步练习后对照订正,也可作为期末梳理概念与简答题框架的辅助材料。

1. 一张压缩过的考点地图:五章习题对应哪条主线

《软件工程教程》第2版的课后答案,如果只拿来对答案就太浪费了——它其实是一张被题目压缩过的知识地图:五章分别落在总论、可行性研究、需求分析、总体设计、详细设计上,正好是软件生存周期前半段的完整链条。选择题盯概念边界,填空题盯术语准确性,简答题盯结构完整性,应用题盯图与数的转换,四类题考的是四种不同的能力。这份笔记适合已经过了一遍教材、正在准备期末或复试用来自查的人:先看清地图,再逐章对照自己的薄弱点。

按这个视角重新排一遍题目,会发现教材的编排逻辑很清楚:第 1 章给定义和坐标系,第 2 章回答“做不做”,第 3 章回答“要什么”,第 4 章回答“怎么搭骨架”,第 5 章回答“每个模块内部怎么写”。五章之间是逐层收敛的关系,前面一章的输出就是后一章的输入。复习时如果哪一章的简答题答不完整,多半是上一章的产物没记住,顺着箭头往回找比硬背效率高得多。

2. 工程总纲:软件危机、六目标与生存周期的骨架

2.1 软件危机:八条原因与七种表现要分开记

软件危机这一节最容易背成一锅粥。原因和表现是两组不同的东西:原因是“为什么会这样”,表现是“这样具体长什么样”。原因可以归成四类——过程上忽视前期需求分析、缺乏统一规范的方法论;文档上资料不齐全或不准确;协作上忽视与用户以及开发组成员之间的交流;质量上忽视测试、不重视维护、缺少完善的质量保证体系,再加上从业人员经验不足、对产业认识不充分。表现则落在七个可观察的现象上:费用和进度失控、功能与需求不符、可靠性差、难以维护、缺少适当文档、软件成本在计算机系统总成本中占比居高不下且逐年上升、生产率提升速度跟不上应用普及的速度。

把两组对应起来看会更牢:过程缺失对应进度与成本失控,文档缺失对应“没有适当文档资料”,协作缺失对应“功能与需求不符”,质量缺失对应“可靠性差、难以维护”。考场上遇到“软件危机表现在哪些方面”时,先在心里过一遍这四组对应,再从每组展开,一般不会漏项,也不会把原因混进表现里。

2.2 两个定义与四个发展阶段

软件的定义要抓住三个组成部分:程序、数据、文档。程序是按特定顺序组织的计算机数据和指令的集合,数据是使程序能正常执行的数据结构,文档是开发、使用和维护程序所需要的图文资料。三者缺一不可,尤其“文档”这一项,是后面所有工程化讨论的落脚点。

软件工程的定义则强调三个要素:用计算机科学的理论和技术,加上工程管理的原则和方法,在预算和进度的约束下完成定义、开发、发布和维护。发展脉络按四个阶段记忆更省力:20 世纪 70 年代提出软件生产工程化思想,试图用传统工程学的原理方法克服危机;80 年代面向对象方法受到广泛重视,面向对象的分析与设计逐步形成完整技术体系;90 年代末涌现出一批敏捷方法,2001 年形成敏捷开发宣言;21 世纪延续快速应用开发(RAD)的追求,云计算、大数据、物联网、人工智能与机器学习、移动互联网、三维打印、可穿戴、虚拟现实与增强现实、社交媒体、无人驾驶等方向不断涌现,“大规模计算”“模型驱动体系结构”“构件化软件开发”被视为可能的主要发展方向。

2.3 六个目标与质量优先原则

软件工程要达到的基本目标有六条:达到要求的软件功能、取得较好的软件性能、开发出高质量的软件、付出较低的开发成本、需要较低的维护费用、能按时完成开发工作并及时交付使用。这六条本身互相拉扯——功能做全了成本上去,性能压榨了进度受影响,所以教材才强调“在冲突之间取得一定程度的平衡”。

平衡的准则是质量优先。软件质量用六个特性评价:功能性、可靠性、可用性、效率、可维护性、可移植性。

提示:简答题里如果只答“六个目标”而不写“冲突之间平衡、质量摆在最重要位置”,通常会扣掉一半分。目标清单是记忆题,平衡原则才是理解题。

2.4 生存周期:三个时期、八个阶段

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

这里有个高频混淆点:概要设计和详细设计同属开发时期,不在定义时期;可行性研究属于定义时期,不在开发时期。阶段名称要和时期归属绑在一起背,只背八个名字、不背归属,选择题一改问法就错。

2.5 过程模型谱系与 SWEBOK 十知识域

软件生存期模型也叫软件过程模型,是从需求定义到运行维护、跨越整个生存周期的开发、运行、维护所实施的全部过程、活动和任务的结构框架。典型的有瀑布模型、快速原型模型、增量模型、螺旋模型、统一过程、敏捷过程。记的时候按“线性—迭代—演化”的谱系来排:瀑布是线性代表,原型和增量解决需求不清与分批交付,螺旋把风险分析显式化,统一过程和敏捷则强调迭代与人的协作。

SWEBOK 把软件工程知识体系划成 10 个知识域,分属两类过程。开发与维护过程五个:软件需求、软件设计、软件构造、软件测试、软件维护。支持过程五个:软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法、软件质量。每个知识域还能继续分解成论题,在论题描述中引用参考文献,形成多级层次结构,以此确定知识体系的内容和边界。

分类记忆的窍门是:五个“做什么”加五个“靠什么管”。需求和设计、构造、测试、维护是产品本身的推进顺序;配置管理、工程管理、过程、工具方法、质量是让这条推进顺序可控的支撑面。

3. 可行性研究:四类判断与货币时间价值的四道算法

3.1 可行性研究的任务:先决定做不做

可行性研究的任务说起来只有一句话:决定这个软件项目做还是不做。用最小的代价、在尽可能短的时间内,确定问题是否能够解决、值得不值得去开发。它发生在问题定义之后、需求分析之前,是生存周期里最便宜的一次“刹车”。

判断的维度包括技术可行性、经济可行性、社会可行性(含运行、操作层面的可行性)以及开发方案的可行性。经济可行性里要做成本效益分析,把开发成本和预期收益放到同一时间坐标上比较;技术可行性看现有技术条件能否支撑;社会可行性看法律、使用习惯、组织流程是否允许。四项都过,项目才进入需求分析。

3.2 四类可行性与成本的四种分法

成本的分类是填空题的高频区。按性质分直接成本和间接成本;按可见性分有形收益和无形收益。收益侧还要区分“因使用新系统而增加的收入”和“使用新系统可以节省的运行费用”,这两条恰好对应创收和降本两个来源。

经济可行性用到的三个基本指标是货币的时间价值、投资回收期和纯收入。这三个指标的关系要理清:货币时间价值是方法,投资回收期和纯收入是结论,前者看多久回本,后者看总共赚多少。只算纯收入不看回收期,会漏掉资金占用时间的风险;只算回收期不看纯收入,会漏掉长期收益。

3.3 货币时间价值:四道计算题的统一算法

这一节的四道题看起来数字各异,算法只有一条:把每一年的收益按 (1+i)^n 折成当前值,累加后减去投资,得到纯收入。四道题分别是三年期 10% 利率、四年期 5% 利率、五年期 5% 利率和一道规模成本估算题。

以三年期那道为例:投资 5 万元,三年收益分别按 22000、24000、26620 计,年利率 10%。折现后是 20000 + 19834.71 + 20000 = 59834.71,减去 50000,纯收入 9834.71 元。注意第一年和第三年折现后都正好是 20000,这不是巧合,是命题时按 1.1 的幂次倒推出来的数字,认出这一点可以少按一遍计算器。

# 折现:把未来每年的收益折算成当前值,再与初期投资比较 def npv(cashflows, rate): total = 0.0 for year, cf in enumerate(cashflows, start=1): pv = cf / (1 + rate) ** year # 第 year 年的折现因子 total += pv # 逐年累加当前值 return total flows = [22000, 24000, 26620] # 三年的预计收益 rate = 0.10 # 年利率 10% invest = 50000 # 初期投资 pv = npv(flows, rate) print(round(pv, 2), round(pv - invest, 2)) # 59834.71 9834.71

函数里rate和cashflows是最需要改的两个参数:利率换成 5% 就把 0.10 改成 0.05,年数变化只要往列表里增删元素,enumerate会自动给出正确的年份序号。折现因子写成(1 + rate) ** year而不是1 + rate * year,这是单利和复利的分界,写错这一步整道题就废了。

四年期那道题还多一个动作:算投资回收期。纯收入是 4 年累计当前值 70918 减去投资 55000 得 15918 元;回收期用“累计当前值首次超过投资的年份”加一个修正项:3 + (55000 − 54464) / 16454 ≈ 3.033 年。修正项的分子是还差多少没收回,分母是第 4 年当年折现后的收益,本质上是线性插值。

注意:这两道题在题干数字和计算过程之间存在口径不一致——三年期题干写“2200 元”,计算里用的是 22000;四年期题干写投资 50000 元,计算里用的是 55000。做题时先对齐口径再动笔,考场上遇到这种题,按计算过程能自洽的那组数字走,并在答案里写明所用口径。

3.4 规模估算:KLOC、人月、每行代码成本

规模估算那道题的链路是:源文件大小 → 代码行数 → 工作量 → 成本 → 单行成本。已知每万行源码形成的源文件约 250K,某项目源文件 3.75M,则 3.75M / 250K = 15 万行 = 150KLOC。生产率 0.625KLOC/人月,则工作量 = 150 / 0.625 = 240 人月。人工价 10000 元/人月,总成本 = 240 × 10000 = 240 万元。每行代码价值 = 240 万 / 15 万行 = 16 元/行。

这条链路的关键是单位统一。KLOC 是千行,人月是工作量单位,两者相除得到的是“每人每月产出多少千行”。很多人在这一步把 150KLOC 直接除以 0.625 得到 240 之后,忘了单位是人月而不是人,写答案时漏掉“人月”二字。单行成本那一步则提醒一件事:软件成本的分母是代码行,但这个分母本身是估算出来的,估算误差会一路传导到最后那个“16 元/行”上,所以它只能作为量级参考,不能当成精确核算。

3.5 可行性报告与后续衔接

可行性研究的成果是可行性分析报告,内容包括对技术、经济、社会、操作各方面的分析结论,以及最终“做还是不做”的建议。报告一旦通过,项目进入需求分析;报告被否,项目到此为止,这也是可行性研究作为“最便宜的刹车”的价值所在。

从复习角度看,这一章和上一章的接口是生存周期阶段划分,和下一章的接口是数据流图。可行性阶段会画系统流程图(有时称泡泡图)做初步的功能与数据流描述,到了需求分析才细化为分层数据流图。两者的区别在于抽象层次:系统流程图描述的是物理系统里数据在设备与处理之间的流动,数据流图描述的是逻辑功能之间的数据变换,不涉及具体实现手段。

4. 从需求到设计:DFD、数据字典与结构图的三次映射

4.1 需求分析:四步流程与六项任务

需求分析分四步:获取、建模、描述、验证。获取是收集过程,要做充分调查研究,通常从分析当前系统的数据开始,看它处理信息时哪里不足、用户希望改进什么问题、迫切性如何。收集方法有问卷调查、访谈、实地操作、建立原型;收集内容覆盖功能需求、性能需求、可靠性需求、可用性、人机界面需求、约束和出错处理。

建模是核心任务,把来自用户的需求信息通过分析、提取、归纳、抽象,建立起描述目标系统的模型。面向过程的方法学主要用数据流图建立逻辑模型。描述是编制文档,大型复杂系统在需求阶段一般产生三份文档:系统定义文档、系统需求规格说明书、软件需求规格说明书,分别从不同角度和层次描述需求;小规模系统只编软件需求规格说明书即可。验证要从完整性、一致性、有效性、现实性四方面检查,并对需求变更做可回溯管理,避免错误来源无法追踪。

六项任务则是:确定对系统的综合需求、分析系统的数据需求、建立系统的逻辑模型、修订系统开发计划、编写软件需求规格说明书、需求分析评审。四步是流程视角,六项是任务视角,答题时看清问的是哪一个。

4.2 结构化分析:分解、抽象与分层 DFD

结构化分析采用归纳与演绎的逻辑方法,逐步建立目标系统的逻辑模型,包括数据模型、功能模型和行为模型,进而描绘出满足用户要求的软件系统。它的基本指导思想是“分解”和“抽象”,策略是面向数据流、自顶向下、逐步求精。分解是把复杂系统拆成若干小问题分别解决,抽象是忽略细节、只保留当前层次需要的信息。

数据流图有四种基本元素:源点与终点(系统之外的实体,如人、物、其他系统)、处理(加工,带名字)、数据存储、数据流(带名字的箭线)。分层绘制是标准做法:顶层图是基本系统模型加源点终点,只画一个处理;0 层图把顶层处理分解成主要功能;1 层图再往下细化。以订货系统为例,源点是仓库管理员,终点是采购员,处理包括事务处理和产生报表,数据存储是库存清单和订货信息,数据流是事务和订货报表。

需求分析的目标之一是把数据流图中的数据流和数据存储分解定义到元素级。通常从输出端着手,因为输出数据决定了系统必须具备的最基本功能;沿数据流图从输出往输入回溯,确定每个数据元素的来源,同时初步定义算法。过程中得到的数据元素信息记入数据字典,算法的简明描述记入 IPO 表。补充出来的数据流、数据存储和处理要填回数据流图的适当位置,最后从输入端开始向用户复述“输入经过怎样的处理一步步变成输出”,反复迭代把图分解到更低层次。

4.3 数据字典:五个符号与一条电话号码

数据字典的符号是必考项:=表示定义,+表示连接,|表示选择,[ ]表示从所列项中选一,{ }表示重复,( )表示可选。这套符号和正则表达式的直觉很像但不完全一样,混用是最常见的丢分点。

那条电话号码的经典题正好把符号串起来:

条目定义
电话号码分机号 | 外线号码
分机号7201…7299
外线号码9 + [市话号码 | 长话号码]
长话号码区号 + 市话号码
区号100…300
市话号码局号 + 分局号
局号[455 | 466 | 888 | 552]
分局号4{数字}

这里的[ ]表示四选一,{ }表示重复四次,…表示取值范围。写答案时如果漏掉9 +这个固定前缀,或者把[455|466|888|552]写成455|466|888|552丢了方括号,语义就从“四选一”变成了“任选其一可并列”,属于定义错误。

4.4 总体设计:九步流程与模块化的七条准则

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

流程是九步:设想供选择的方案、选取合理的方案、推荐最佳方案、功能分解、设计软件结构、数据库设计、制定测试计划、编写文档、审查和复查。注意测试计划在总体设计阶段就要开始制定,不是等到编码之后,这一条常被当成“测试是测试阶段的事”而漏掉。

模块化的准则有七条:改进软件结构以提高模块独立性;模块规模适中;深度、宽度、扇入、扇出都适中;模块的作用域应该在控制域之内;降低模块结构的复杂度;设计单入口、单出口的模块;模块功能应该可以预测。其中“作用域在控制域之内”的方向最容易记反:作用域是受该模块内一个判定影响的所有模块的集合,控制域是这个模块本身加上它直接或间接调用的所有模块的集合,要求是作用域包含于控制域,不是反过来。扇入指有多少上级模块调用它,扇出指它调用多少下级模块,扇入高说明复用性好,扇出高说明该模块职责太杂。

4.5 DFD 到结构图:七步映射与优化边界

从数据流图导出结构图分七步:复查基本系统模型、复查并精化数据流图、确定数据流图的类型、确定数据流的边界、完成第一级分解、完成第二级分解、优化。类型判断是分水岭:变换型数据流图有明显输入、变换、输出三段,第一级分解得到输入控制、变换控制、输出控制三个分支;事务型数据流图有一个事务中心,按事务类型分派处理,第一级分解得到接收分支和调度分支。

第二级分解是按控制分支逐层向下,把每个处理映射成一个模块,直到最底层的输入输出模块。优化阶段有几条禁忌:不能违背设计原理,不能违背问题域常识,不能为了追求“最佳设计”而优化。机械套用映射规则往往会多出一些没必要的控制模块,用处不大就该合并;控制模块功能过分复杂,就该增加中间层或进一步分解。结构优化不能留到过程设计阶段再做,这也正是把结构设计和过程设计分开的价值所在。结构简单往往意味着效率高,优化的方向是在有效模块化的前提下用尽可能少的模块数,在满足信息要求的前提下用最简单的数据结构。

4.6 详细设计:五任务、三类工具与 Halstead

详细设计的五项任务是:为每个模块确定采用的算法;确定每一模块的内部数据结构及数据库的物理结构;确定模块接口的细节;为每一个模块设计一组测试用例;编写文档并参加复审。第三项和第四项容易被忽略——接口细节包括参数的类型、个数、传递方式,测试用例要在设计阶段就给出,因为这时最清楚模块的边界条件。

描述工具有三类。图形类包括结构化程序流程图、盒图(N-S 图)、问题分析图(PAD);表格类包括判定表、判定树;语言类即过程设计语言 PDL。

结构化程序设计的要点是三条:采用自顶向下、逐步求精的方法;只用顺序、选择、循环三种基本控制结构构造程序;每个模块只有一个入口和一个出口。流程图的优点是直观清晰、易于使用,缺点是流程线可以随意跳转、容易造成非结构化结构,不易反映逐步求精的过程(往往只反映最后结果),不易表示数据结构。为了克服这些缺陷,要求流程图由三种控制结构顺序组合、完全嵌套而成,不能交叉,这才是结构化流程图。

N-S 图用方框代替传统流程图,所有程序结构都用方框表示,并列或嵌套一目了然,且只能表达结构化程序逻辑,逼着使用者遵守结构化规定;缺点是嵌套层次增多时内层方框越来越小,绘图难度上升、清晰性下降。PAD 的特点是清晰反映程序层次结构、支持逐步求精、易读易写、支持结构化原理、可自动生成程序。PDL 是在伪码基础上扩充了模块定义与调用、数据定义和输入输出而成的,分内外两层:外层语法规则严格,内层是表示实际操作和条件的自然语言,语法自由。它的优点是可以作为注释直接插入源程序、可用文字处理系统编辑、可自动生成;缺点是不如图形工具直观,复杂描述不如判定表清晰。

Halstead 度量那道题考的是用操作符和操作数的统计量预测错误数:

import math n1, n2 = 75, 150 # 不同操作数个数 / 不同运算符个数 N1, N2 = 1300, 1200 # 操作数总访问次数 / 运算符总使用次数 E = (N1 + N2) * math.log2(n1 + n2) / 3000 print(round(E, 2)) # 约 6.5,即预测 6~7 个错误

n1 + n2是不同操作数与不同运算符的总数,N1 + N2是实际使用次数的总和,3000 是该经验公式里的常数分母。算出 6.5 之后答“6 到 7 个错误”比答“6.5 个”更贴合题意,因为错误数是整数。

判定树那道行李费题则是另一类工具训练:30kg 以内免费;超重部分按舱位、国籍、是否残疾分档计费——头等舱国内乘客每公斤 4 元,其他舱国内乘客 6 元,外国乘客在此基础上翻倍,残疾乘客在此基础上减半。画判定树时先把三个判定条件按层次排开,再在叶子节点上写计算公式,条件顺序不同会导致树形不同,但只要覆盖全部组合且不重不漏就算正确。

5. 易漏点:五处最容易在简答和计算上丢分的地方

5.1 易漏点一:软件危机的原因与表现互换

  • 易漏点:题干问“表现”,答案先写“忽视需求分析”“缺乏规范方法论”;题干问“原因”,答案先写“费用进度失控”。
  • 为什么漏:两组内容在教材里紧挨着,背的时候按段落顺序记,没有按“因果”关系重组,考场上顺着记忆惯性就写串了。
  • 怎么补:答题前先在心里把两组各标一个标签——原因全是“忽视、缺乏、不重视”这类动作,表现全是“失控、不符、差、难、没有”这类状态。凡是能造出“因为……所以……”句式的归原因,凡是能直接观察到的现象归表现,按标签落笔。

5.2 易漏点二:八个阶段的名称与时期归属脱钩

  • 易漏点:能背出“问题定义、可行性研究、需求分析、概要设计、详细设计、软件实现和单元测试、综合测试、运行维护”,但被问到“概要设计属于哪个时期”时答成软件定义时期。
  • 为什么漏:教材按顺序罗列八阶段,视觉上是一条直线,时期划分是叠加在这条直线上的另一层信息,两者没有一起编码。
  • 怎么补:画成三栏而不是一行——定义时期放前三项,开发时期放中间四项,运行维护时期放最后一项。注意“软件实现和单元测试”是一个整体阶段,不要拆成两个;综合测试单列,也不要和单元测试合并。

5.3 易漏点三:折现题跳过折现直接减投资

  • 易漏点:把各年收益直接相加减去投资,得出“纯收入”,或者折现了收益却忘了折现投资的时间点。
  • 为什么漏:题目给的是“每年节约多少元”,数字看着整齐,很容易直接乘年数;教材强调“投资在前、效益产生在后”的那句话被当成套话跳过了。
  • 怎么补:动笔第一件事是画一条时间轴,把投资标在 0 点,收益标在 1、2、3……各点,凡是不同时间点上的钱一律先折现再比较。算完检查一遍量级:折现后的累计值一定小于直接相加的值,如果两者接近相等,说明利率设成了 0 或者公式写成了单利。

5.4 易漏点四:数据字典符号的语义边界模糊

  • 易漏点:把[ ]当成“可选”,把( )当成“选择”,或者把{ }的重复次数写丢。
  • 为什么漏:这几个符号在编程语言里各有别的含义,[]在多数语言里是数组下标,()是函数调用,肌肉记忆会盖过教材定义。
  • 怎么补:只记一句话——方括号是“多选一”,花括号是“重复若干次”,圆括号是“可选项”,加号是“并且”,竖线是“或者”。写定义时逐条对照这五个词,写完把定义倒着读一遍:从叶子条目往上游推,看能不能还原出原始条目。

5.5 易漏点五:作用域与控制域的包含方向记反

  • 易漏点:答成“控制域应该在作用域之内”,或者把扇入扇出的定义对调。
  • 为什么漏:两个词都以“域”结尾,字面看不出谁大谁小;扇入扇出一个是“被调用”一个是“去调用”,只看名字分不清方向。
  • 怎么补:作用域是“受这个判定影响的范围”,控制域是“这个模块能管到的范围”,设计上要求“影响范围不能超出管辖范围”,所以是作用域包含于控制域。扇入记成“进门的人”,扇出记成“派出去的人”,进门的多说明复用性好,派出去的多说明职责杂。

6. 复习清单:把答案变成可自查的知识网格

复习到这一步,最有用的不是再刷一遍题,而是拿一张表把自己卡住的地方标出来。下面这张表按五章的主线排,每行给出自查看点和一个可以立刻动手验证的动作,做完打勾即可。

模块自查看点验证动作
总论危机四类原因能否不重不漏展开合上书,按“过程、文档、协作、质量”四类各说一条原因和一条对应表现
总论三时期八阶段归属画三栏表格,把八个阶段名逐一填进去,不看教材
可行性折现公式是否写成复利手算三年期那道题,结果对到 9834.71
可行性四个经济指标含义用一句话分别说清货币时间价值、投资回收期、纯收入、成本效益分析
需求DFD 四元素与分层给一个订货场景,五分钟内画出顶层图和 0 层图
需求数据字典五符号默写电话号码那条定义,再对照符号表检查
设计模块化七准则挑三条最容易忘的,各配一个反例说明违反后果
设计映射七步与两种类型说清变换型和事务型第一级分解的差别
详细设计三类工具各自优缺点流程图、N-S 图、PAD、PDL 各写一句“什么时候用它”

具体操作建议按 40 分钟一轮来跑:前 10 分钟只看表里的“自查看点”列,合上所有资料自己复述;中间 20 分钟做验证动作,哪个动作卡住就在那一行标红;最后 10 分钟只翻标红对应的教材小节,不整章重读。一轮下来标红不超过五行,说明基础已经稳了,接下来该练的是答题结构而不是知识点本身。

答题结构这件事值得单独说一句。简答题丢分往往不是不会,而是“会但没答全”。一个可复用的模板是:先给一句定义性判断,再分点展开,最后补一句边界或前提条件。比如问软件工程的目标,先答“六项基本目标”,再分点列出,最后补“目标之间存在冲突,平衡时以质量为先”。三句话结构一摆出来,阅卷人一眼就能看到你抓住了主干。

我自己的血泪经验是:第一次做这套题时折现那道题直接拿收益乘年数减投资,答案看着也挺像样,直到对答案才发现差了整整一个数量级的量级感。从那以后我每次碰成本效益题,都强制先画时间轴、把投资标在 0 点,再动计算器。这个习惯后来在别的科目上也没翻过车。希望帮到你。

这套课后答案的价值不在于“对答案”,而在于它把五章的知识点压成了可以直接自测的题目。如果你也在按这份地图复习,把它当成一张可反复涂改的网格来用,比从头到尾读一遍教材要快得多;需要完整题目和参考答案对照着练的,按标题找这份资源即可。

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

RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进