软件工程这门课很多同学学的时候没感觉期末一复习才发现知识点又多又杂什么生命周期、开发模型、可行性研究、结构化分析、面向对象、测试用例设计……密密麻麻背了忘忘了背。我当年期末复习的时候也差点被逼疯后来把整门课拆成“工程流程线 关键方法论 高频考点”三个维度来整理才算真正吃透。这篇笔记就是按照这个思路整理的覆盖软件工程期末最常见的考查范围和重难点从概念到实操题型都有适合考前突击、系统回顾也适合平时学得云里雾里的同学拿来搭框架。1. 课程体系与复习主线1.1 软件工程到底学什么软件工程不是单纯写代码它解决的是“怎么把软件做出来、做好、做快”的问题。和编程课不一样编程课关注代码怎么写软件工程关注的是整个软件从无到有的全过程要不要做、做什么、怎么设计、怎么写、怎么测、怎么维护、怎么管理进度和成本。期末复习首先要有一个整体框架别上来就背名词解释。整门课的核心逻辑就是一条时间线问题定义 → 可行性研究 → 需求分析 → 概要设计 → 详细设计 → 编码与测试 → 维护这就是软件生命周期。你所有的知识点基本都能挂在这条线上。复习的时候建议先记住这条主线再把每个阶段的概念、方法、工具、产出物填进去这样就算遇到没见过的题目也能靠逻辑推断出大概答案而不是死记硬背。1.2 期末考试的常见题型与备考思路软件工程期末考试的题型一般比较固定无非是这几类概念题考名词解释或简答比如“什么是软件危机”“什么是内聚”“什么是耦合”这类题考察对核心定义的准确记忆。对比题让比较两个模型或概念的异同比如瀑布模型和原型模型的区别、黑盒测试和白盒测试的区别。这类题靠理解写的时候要有条理。应用题给你一个系统描述让你画数据流图、画ER图、画用例图或者设计测试用例。这类题分值最大也是最容易拉分的地方。综合题给你一个项目场景让你选择开发模型并说明理由或让你写需求分析的步骤这类题考察工程思维。复习策略上我建议概念题靠关键词记忆对比题靠表格整理应用题必须动手练。数据流图、测试用例设计这些光看不练等于白学我在后面会详细拆解。2. 软件工程基础概念与经典开发模型2.1 软件危机与软件工程的定义软件危机是软件工程这门课最开头的核心概念几乎是必考点。它指的是在软件开发过程中经常遇到的、无法克服的困难集中表现为开发进度难以预测、成本超支、产品质量不可靠、维护极其困难。一个系统做到最后烂尾、改一处崩三处本质上都是软件危机的表现。软件工程就是为了解决软件危机而提出的工程化方法。定义要记准确软件工程是指导计算机软件开发和维护的一门工程学科它采用工程的概念、原理、技术和方法来开发与维护软件把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。这里有个容易出选择题和判断题的点软件工程不仅包括技术方法还包括项目管理、人员组织、质量保证等内容它强调的是“工程化”不是单打独斗写代码。考试如果问“软件工程的三要素”要答过程、方法、工具。过程是框架方法是手段工具是支撑。2.2 常用软件过程模型对比软件过程模型也叫软件开发模型是期末的重点和必考点。每个模型都要记住核心思想、适用场景、优缺点。这里我按从经典到现代的脉络来梳理。瀑布模型是最经典、最基础的一个它是线性顺序模型像瀑布一样自上而下流动。阶段划分很清晰问题定义与可行性研究、需求分析、设计、编码、测试、维护。优点是有严格的阶段划分和文档管理每个阶段都有评审缺点是太死板用户要等很久才能看到结果而且需求一旦变更项目就会返工甚至推倒重来。原型模型则主要是为了解决瀑布模型需求不明确的问题。它先快速开发一个“样品”给用户看用户觉得哪里不对就改哪里反复迭代直到需求明确然后再开发正式产品。优点是能快速确认需求特别适合用户说不清楚自己想要什么的场景缺点是在原型的基础上不断修改可能导致系统结构不清晰、质量受影响。增量模型和螺旋模型也经常会考。增量模型把系统拆成一个个增量先交付核心功能再逐步增加功能用户能较早使用部分功能。螺旋模型则引入了风险分析每一圈螺旋都包括制定计划、风险分析、实施工程、客户评估四个阶段特别适合大型、复杂、高风险的项目。还要注意统一过程RUP和敏捷开发。RUP是一个二维的开发框架横轴是时间纵轴是工作流核心思想是用例驱动、以架构为中心、迭代和增量。敏捷开发强调个体和互动胜过过程和工具、可工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。敏捷这个词如果考简答要把这四个价值观写出来最好还能说说常见的敏捷实践比如Scrum里的Sprint冲刺、每日站会、产品待办列表等。2.3 模型选择的判断依据期末综合题里经常给一个项目场景让你选择开发模型。这种题没有标准答案但你要能自圆其说理由充分。一般逻辑是这样的需求明确、技术成熟、不容易变更的项目选瀑布模型比较稳妥因为阶段划分清晰便于管理。需求不明确、用户参与度高的项目选原型模型或增量模型。大型复杂、风险高的项目选螺旋模型因为它有风险分析环节。需求变化快、强调快速交付的项目选敏捷开发。答题时一定要结合场景说理由比如“该项目需求不够明确因此采用原型模型可以尽早与用户确认需求避免后期大改”。这样写分就基本拿到了。2.4 常见算法类知识在软工中的应用提醒搜软件工程期末资料的时候很多同学会搜到“Floyed算法类似的算法”。这里得提醒一下Floyed算法本身是算法设计课程的内容软件工程期末考试一般不会直接考 Floyd 算法的代码实现但是“算法”两个字在软件工程里还是有出题点的。软件工程里涉及算法和逻辑设计的地方主要有两类一是详细设计阶段的算法描述工具比如程序流程图、盒图N-S图、PAD图它们的作用就是把算法逻辑表达清楚二是在选择架构或模块实现方案时需要评估算法或数据结构的时间复杂度和空间复杂度判断是否满足需求中的性能约束。所以如果你搜Floyed算法搜到了软件工程的资料大概率是这两个情景之一。复习时重点掌握详细设计工具怎么画以及如何用类似逻辑去描述一个处理过程不要在Floyed这种具体算法实现上花费太多时间那不是这门课的考查重心。3. 需求分析画图能力是分水岭3.1 需求分析的任务与产出物需求分析是软件工程中承上启下的关键步骤目的是搞清楚“系统到底要做什么”。很多同学觉得需求分析就是聊聊天、记记笔记但在考试里它对应的是数据流图、数据字典、ER图、用例图这些硬核考点。需求分析的具体任务包括确定系统综合要求功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束等、分析系统的数据需求、导出系统的逻辑模型、修正系统开发计划。产出物是需求规格说明书它是后续设计、测试和验收的依据。期末复习时需求这块要注意几个高频概念功能需求是“系统必须做什么”非功能需求是“系统做到什么程度”性能、安全、可用性等。数据流图关注系统的数据流向和处理逻辑ER图关注数据之间的关系用例图关注用户和系统的交互。这三张图是需求分析阶段最常考的三类题目。3.2 数据流图DFD的画法与判分点数据流图是结构化分析的核心工具期末应用题出现频率极高。它描述数据在系统中的流动和处理过程由四个基本元素组成外部实体矩形、加工圆角矩形或圆圈、数据存储开口矩形、数据流箭头。画数据流图有几个关键步骤。首先识别外部实体也就是跟系统交互的人和外部系统比如学生选课系统里的“学生”就是外部实体。然后确定系统的输入和输出数据流接着从中心加工开始逐层分解。顶层图也叫上下文图把整个系统看成一个加工只画外部实体和输入输出。然后进行一层层细化把大的加工拆成小的加工直到每个加工都能明确表达为止。考试里数据流图的判分点通常在以下几点加工必须有输入输出而且输入输出数据要匹配不会凭空消失数据流的箭头方向不能画反数据存储和加工之间要有数据流连接加工至少要有一个输入和一个输出。修改数据流图时必须遵守一个规则就是父图和子图的数据流要平衡父图中某个加工的输入输出数据流必须在子图中出现。画数据流图时最容易犯的错误是漏画数据存储、把外部实体直接连到数据存储、或者加工之间缺少中间数据流。平时练习时可以先写一个数据字典把所有用到的数据项列出来再动笔画图这个习惯能帮你避免很多低级失误。3.3 用例图以用户视角捕获需求面向对象的需求分析中用例图是必考内容。用例图的核心思想是以用户视角描述系统功能回答“谁用系统做什么事”。用例图的三要素是参与者、用例和关系。参与者是外部角色用人形符号表示不一定是真人也可以是外部系统。用例是一个完整的功能单元用椭圆表示。关系包括关联、包含、扩展和泛化关联是参与者和用例之间的关系包含是一个用例必包含另一个用例的动作扩展是在某些条件下才触发的额外行为泛化是继承关系。画用例图时容易搞混的是包含和扩展。我考试时总结了一个经验只要看到“每次都执行”“必需的子步骤”就画成包含用带《include》的虚线箭头从基本用例指向子用例只要看到“在某些条件下”“可选的额外功能”就画成扩展用带《extend》的箭头从扩展用例指向基本用例。平时练习可以拿快递柜、网上订餐、图书馆借书这些身边系统来画用例图重点训练识别参与者和粒度划分别把“输入用户名密码”这种登录子功能都当成一个大用例用例粒度要控制在“能独立完成一个有价值的用户目标”这个层级。3.4 ER图与数据字典要点ER图在软件工程期末中经常和数据库概论结合考但软件工程课程的侧重点在“如何通过数据建模来明确需求”而不是ER图的详细数据库设计规则。ER图的基本成分是实体、属性和联系。实体用矩形属性用椭圆联系用菱形。联系类型有一对一1:1、一对多1:N、多对多M:N。考试通常会给一段需求描述要求画出ER图并在联系上标注联系类型。数据字典则是数据流图的补充它定义数据流图中出现的数据项、数据结构、数据流、数据存储和处理逻辑。简单说数据流图是系统逻辑模型的骨架数据字典是这张骨架上的血肉两者配合才能完整描述系统需求。复习时至少要掌握数据字典的四个条目怎么写尤其是数据流条目要说明名称、别名、组成、来源、去向和流通量。4. 软件设计从概要设计到详细设计4.1 概要设计要解决什么问题概要设计又叫系统设计它的任务是把需求转化为软件的系统结构和数据结构回答的是“系统怎么组织”的问题。期末考试中概要设计部分的高频考点是模块化、内聚与耦合、结构化设计方法、软件架构风格。模块化是概要设计的核心原则把系统拆成一个个相对独立的模块每个模块完成一个子功能。模块化的好处是降低复杂度、便于测试和维护。判断模块化程度的指标是内聚和耦合。内聚是指一个模块内部各元素之间联系的紧密程度。从弱到强依次是偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。耦合是模块之间的相互依赖程度。从弱到强依次是非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。设计原则就是一句话高内聚、低耦合。功能内聚最强数据耦合最弱在不考虑非直接耦合的情况下。考题有时候会给你几个模块关系让你判断内聚和耦合类型需要记住各种类型的特征。比如模块之间传递一个参数是数据耦合传递一个控制信号是控制耦合多个模块共享一个全局数据结构是公共耦合一个模块直接访问另一个模块的内部数据是内容耦合。这个几乎年年有题。4.2 软件架构风格与设计原则软件架构风格也是近年比较常考的内容。常见的架构风格包括数据流风格批处理序列、管道-过滤器、调用/返回风格主程序-子程序、面向对象、层次结构、独立构件风格进程通信、事件驱动、虚拟机风格解释器、规则系统、仓库风格数据库系统、超文本系统等。这里不用死记每种风格的细节但至少看到某个系统描述时能判断属于哪种风格。比如编译器适合用管道-过滤器风格操作系统适合用层次结构AI专家系统适合用规则系统。概要设计的另一个考点是模块设计的基本原则比如降低模块接口复杂度、设计高内聚模块、设计单入口单出口的模块、把可能变化的区域封装起来等。解答这类题目时如果能结合内聚耦合一起来答显得更有深度。4.3 详细设计工具与程序流程图详细设计阶段的任务是为每个模块的内部实现设计具体的处理逻辑也就是“模块内部怎么做”。考试题型往往是让你用工具画出某个算法流程或者给出流程图让你补充缺失的判断条件。详细设计的典型工具包括程序流程图、盒图N-S图、PAD图、判定表和判定树、过程设计语言PDL。程序流程图是我要特别提醒的一个点因为很多同学画着画着就画错了。程序流程图的基本符号对应的是标准流程图的写法起止框用圆角矩形处理框用矩形判断框用菱形输入输出框用平行四边形箭头表示控制流。画的时候要注意判断框必须有“是”和“否”两条出口循环结构在流程图中要区分当型和直到型。期末阅卷的时候很多老师会重点看判断框出口有没有标注“Y/N”或“真/假”这是常见的扣分点。盒图N-S图不像程序流程图那样有箭头它是完全结构化的表示方法去掉了控制流的随意转向强制设计者按照顺序、选择、循环三种基本结构来组织逻辑。盒图的优点是防止程序出现非结构化的跳转缺点是不适合大规模系统的整体描述。PAD图是中国学者提出的采用二维树形结构最左边是主线和层次结构逻辑清晰也容易转换成代码。考试中如果要求绘制某两种图的转换最常考的是程序流程图和盒图互相转换只要记住原则就行结构化流程才能无损转换非结构化的随意跳转不能转换为盒图。判定表和判定树主要用于表示复杂的条件组合与动作之间的对应关系比如机票折扣、运费计算这类多条件多结果的场景。判定表由条件桩、动作桩、条件项、动作项组成判定树则是判定表的图形化表达。这里顺带说一下很多人在看的“详细设计-2”这个搜索词实际就是教材里详细设计章节的后续部分主要内容就是这些算法描述工具和面向数据结构的设计方法。其中Jackson方法的核心思想是“程序结构必须与数据结构相对应”看到顺序、选择、重复这三种数据结构就对应设计出顺序、选择、重复三种程序结构。4.4 详细设计的符号规范一张表理清流程图形状期末考试里经常会给一段文字描述让你画出程序流程图。很多同学画得乱七八糟问题就出在符号用得不规范。这里我整理了一张我在复习时反复对照的表格符号形状名称作用圆角矩形起止框算法开始或结束平行四边形输入/输出框数据的输入或输出矩形处理框赋值、计算等处理操作菱形判断框条件判断必须有两个出口带箭头的线控制流指明执行顺序画流程图的步骤我建议这样先理清算法逻辑确定哪里开始、哪里结束、哪些是判断点然后把判断点作为分岔路先画主干流程再补分支最后把每条路径走一遍看是否有遗漏、是否有死循环。判断框的双出口最容易出错经常有同学只画一个出口或者出口没有标注。另一个常见问题是处理框和输入输出框混用把“输入x”写成了矩形处理框这种粗心丢分很可惜。平时练的时候把这些细节盯住考试就不会失分。5. 编码与测试拿分最快也最容易踩坑的部分5.1 编码规范与编程风格编码阶段涉及到的考点不多但经常会出选择题或简答题考察编程风格。核心观点是编码阶段要注重程序的可读性和可维护性代码是写给人看的其次才是让机器执行。好的编程风格包括有意义的变量名、规范的注释、清晰的控制结构、避免难以理解的技巧性写法。考试中如果问“编码阶段应该注意什么”从源程序文档化、数据说明规范化、语句构造简单直接、输入输出友好这四个角度回答基本不会丢分。5.2 软件测试的目的与原则测试是软件工程期末的绝对重点几乎每个题型的每份试卷都会涉及。要搞清楚一个核心观念测试的目的是发现程序中的错误而不是证明程序没有错误。软件测试的原则有很多条高频可考的有测试用例应由输入数据和预期的输出结果两部分组成不仅要选择合理的输入数据还要选择不合理的输入数据进行测试应尽早地、不断地进行测试测试用例必须包含预期输出结果程序模块应由编写者之外的人来测试比较合理。其中“程序员应避免测试自己的程序”这个原则经常考判断或简答。测试信息流模型中测试的输入是软件配置需求、设计、源程序和测试配置测试计划、测试用例、预期结果输出是测试结果、错误分析和排错信息。这个图有时候会考“测试信息流”相关选择题。5.3 白盒测试逻辑覆盖是命题集中地白盒测试又叫结构测试是把程序看作一个透明的盒子根据程序内部逻辑结构设计测试用例。白盒测试的考查重点是逻辑覆盖从弱到强排列是语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。每种覆盖的具体要求要记清楚语句覆盖每个可执行语句至少执行一次。最弱。判定覆盖每个判定的真分支和假分支至少各执行一次。条件覆盖每个判定中的每个条件的真和假至少各执行一次。判定/条件覆盖同时满足判定覆盖和条件覆盖。条件组合覆盖每个判定中所有条件组合至少出现一次。路径覆盖程序的所有可能路径都至少执行一次。期末考试最常见的考法是给一段代码和一个流程图让你设计测试用例看是否满足某种覆盖标准。这部分的题目只有动手算才能熟练掌握光背定义没有用。做这类题我有一个笨但有效的方法先把每个判定的条件分别标出来比如判定1的条件是“x0 y0”就把它们命名为C1、C2然后逐一列出每个条件的真假情况再组合成测试用例。这样一步一笔写下来就不会漏条件也不会搞混覆盖标准。这里要特别提醒条件组合覆盖不一定覆盖每条路径路径覆盖也不一定满足条件组合覆盖它们不是包含关系。这是很多同学做题时会踩的坑考试偶尔会出判断题或简答题来考这个点。5.4 黑盒测试等价类划分与边界值分析黑盒测试也叫功能测试是把程序看作一个不透明的黑盒子完全基于输入输出来测试。最常考的两种方法是等价类划分和边界值分析。等价类划分的核心思想是把输入数据划分成若干等价类在每个等价类中取一个代表值进行测试。有效等价类是符合需求规格说明的合理输入无效等价类是不合理、无意义的输入。设计测试用例时要覆盖所有的有效等价类和无效等价类。需要注意一个原则每个无效等价类要单独设计测试用例不能好几个无效等价类塞在一个用例里否则测出来错误也定位不到是哪个条件引起的。边界值分析则是选择输入或输出边界的值来测试因为经验表明很多错误都出现在边界附近。比如输入范围是1到100那么边界值设计时要测0、1、100、101还要测一个正常值比如50来作为对照。这两种方法经常放在一道应用题里考比如“某程序要求输入用户名长度为6到12个字符请用等价类划分和边界值分析设计测试用例”。这属于白送分题但前提是你平时练过。我建议考试前至少亲手写两套完整的测试用例格式包括用例编号、输入数据、预期输出、覆盖类型练熟了考场上才能又快又规范。5.5 单元测试、集成测试与系统测试测试策略也是常考知识点。从小到大的层次是单元测试、集成测试、确认测试、系统测试。单元测试针对每个模块通常由程序员自己完成重点测试模块接口、局部数据结构、边界条件和独立的执行路径。集成测试是把模块组装起来测试有非渐增式和渐增式两种方法渐增式又分为自顶向下和自底向上。如果考“自顶向下测试”和“自底向上测试”的区别要答自顶向下需要编写桩模块能较早发现顶层接口错误但底层模块的测试可能要推迟自底向上需要编写驱动程序底层模块可以较早得到测试但顶层模块的问题发现较晚。扇形测试法是自底向上和自顶向下结合的混合策略。确认测试也叫有效性测试是验证软件的功能和性能与用户需求是否一致用黑盒测试为主。系统测试则是把软件放在真实的运行环境中和硬件、外设、其他软件系统一起测试。还有一个很容易考的选择题陷阱α测试是由用户在开发者的场所进行的测试开发者在一旁观看受控的环境。β测试是由用户在最终用户场所进行的测试开发者不在场环境不受控制。这两个定义经常混着考一定要区分清楚。5.6 调试与软件维护测试和调试的区别也是高频考点。测试是发现错误调试是定位并纠正错误。测试在先调试在后。调试的方法有蛮力法、回溯法、原因排除法对分查找、归纳法、演绎法考试考填空或选择的几率较大名词知道就行。软件维护是生命周期中耗时最长、成本最高的阶段有四种维护类型改正性维护修复发现的错误、适应性维护适应环境变化、完善性维护增加新功能或改进性能、预防性维护为将来维护做准备。其中完善性维护占比最高。如果考“哪类维护占比最大”要答完善性维护这是教材中的经典数据。6. 项目管理与软件质量容易被忽略的送分题6.1 软件项目管理的基本内容软件项目管理在期末考试中的占比不是最大但常以选择题、填空题或简答题形式出现而且内容相对简单属于送分板块。软件项目管理的内容包括计划制定、人员组织、成本估算、进度管理、风险分析、质量保证、配置管理等。复习时重点掌握成本估算和风险分析这两块因为它们有具体的公式和方法。成本估算方面要会算代码行数LOC和功能点FP还要掌握基本COCOMO模型。COCOMO模型的基本公式是工作量 E a × (KLOC)^b 人月。简单说代码量越大、项目越复杂工作量增长越快。考试中如果给定了a、b的值和代码量套公式计算就可以。进度管理要了解Gantt图甘特图和工程网络图。甘特图直观显示任务的开始和结束时间但无法清晰显示任务之间的依赖关系。工程网络图PERT图能显示任务之间的依赖关系适合做关键路径分析。如果考关键路径的计算把所有路径长度算出来最长的那条就是关键路径这条路径上的任务延误会直接影响整个项目工期。6.2 风险分析与软件质量保证风险分析包括风险识别、风险预测、风险评估和风险管理。软件工程中经常把风险分为项目风险、技术风险和商业风险三类。复习时能理解这三种风险的区别即可。软件质量保证SQA的目标是验证软件是否满足规定的技术和用户需求。质量度量方面McCabe复杂度度量是常考的计算题。环形复杂度V(G)有三种计算方法V(G) 区域数V(G) 判定节点数 1V(G) 边数 - 节点数 2。画好程序图之后任选一种方法计算即可。一般算出来数值越大程序可测试性和可维护性越差。这个考点在期末中经常以小计算题或填空题的形式出现值得拿分。6.3 软件能力成熟度模型CMMCMMCapability Maturity Model描述的是软件组织在开发和维护软件时过程成熟度的五个等级初始级、可重复级、已定义级、已管理级、优化级。这五个等级从低到高体现了组织软件开发过程的规范化和持续改进能力。期末如果考CMM多考等级名称和顺序偶尔会考某个等级的特点比如初始级的特点是过程无序、 depends on 个人英雄主义优化级则关注过程的持续改进。记住五个等级名称和顺序这个考点就不会失分。如果用的是“软件工程概率第十版”这类教材CMM和ISO 9000的区别也是可能出现的简答题CMM强调过程和能力成熟度ISO 9000强调质量体系的符合性认证。能写清楚这一点就够了。7. 高频易错点与考前速记清单7.1 几十个高频考点的速查识别考前最后一轮复习我建议直接过一遍高频考点速查看到自己瞬间想不起来定义的点立刻翻书补漏。下面这份清单基本覆盖了期末试卷中最常出现的名词和简答内容软件工程三要素过程、方法、工具软件生命周期各阶段名称及顺序瀑布模型 vs 原型模型 vs 增量模型 vs 螺旋模型的核心特征内聚的七种类型从弱到强排序耦合的七种类型从弱到强排序数据流图四要素及画法数据字典的四种条目用例图三要素及包含/扩展关系详细设计工具名称流程图、盒图、PAD图、判定表、PDL白盒测试的各种逻辑覆盖标准及强弱关系黑盒测试的等价类划分方法边界值分析的设计要点单元测试、集成测试、确认测试、系统测试的关系α测试与β测试的区别测试与调试的区别软件维护的四种类型及占比McCabe环形复杂度计算COCOMO模型的工作量计算关键路径的计算CMM五级名称与顺序其中我特别要强调一个有迷惑性的点测试用例设计时无效等价类要“逐类分别测试”但有效等价类可以合并测试因为有效等价类之间不冲突而多个无效条件同时出现时无法判断具体是哪个条件导致系统出错。考试中如果问这个原则很多同学会答反要注意。7.2 计算题与画图题的考场策略软件工程期末的计算题和画图题分值高主观性强但也是最好拿分的部分。我的考场策略是先做计算题再做画图题最后做简答和概念题因为计算和画图题目答案明确做完心里有底。做McCabe复杂度计算时建议先画程序图再数区域区域数这个方法是三种方法中不容易漏数的。做关键路径计算时把所有路径都列出来不要凭直觉判断。做COCOMO计算时注意KLOC的单位是千行不是行代入公式之前先换算。画数据流图和用例图时先用铅笔轻轻画出框架再用签字笔定稿卷面整洁在主观题里还是挺占便宜的。做等价类划分题时一定要把“无效等价类”也写全很多同学只写有效等价类白白丢了半道题的分。7.3 我自己复习时踩过的坑这里分享几个我复习软件工程时踩过的坑都是实实在在的教训。第一个坑是不画图。我第一次复习数据流图的时候觉得看看例题就能看懂结果上了考场手忙脚乱。数据流图、ER图、程序流程图、盒图这些必须动手画只有自己画一遍才会发现漏了输入输出、判断框出口没标注这些细节。第二个坑是死记内聚耦合的排序。内聚和耦合各七种类型的强弱顺序光背容易串我的方法是编口诀或找规律内聚从“偶然”到“功能”越来越强耦合从“内容”到“非直接”越来越弱考试时先写出两端再往中间推就不容易乱。第三个坑是概念混在一起。比如把“确认测试”和“系统测试”搞混把“适应性维护”和“完善性维护”搞混。我的解决办法是拿A4纸画框架图把每个阶段、每类测试、每种维护方式放在一张图上用箭头标注之间的关系这样复习到最后就不容易乱。第四个坑是只背书不动笔算。McCabe复杂度、COCOMO、关键路径这三类计算题看会了和自己算出来完全不是一回事。建议考前至少把教材例题从头到尾算一遍保证每一步公式都写对。7.4 考前一周的复习安排建议如果还有一周时间我建议按照这样的节奏来安排前三天过完所有概念和模型配合整理对比表格第四到五天集中练画图和测试用例设计题不用多每个题型三道就够但每一道都要完整写不要看书第六天刷计算题McCabe、COCOMO、关键路径、等价类划分这些轮着做最后一天快速过一遍高频考点清单把自己仍然记不住的点集中背一下。软件工程的知识点不是靠死记硬背就能全部覆盖的它更强调理解和应用。期末复习虽然时间紧任务重但抓住主线、理清框架、勤练画图题和计算题及格往上还是很容易的。如果想要冲击高分细节概念不能放过答题时图文结合条理清晰就能和大部分人拉开差距。
软件工程这门课很多同学学的时候没感觉期末一复习才发现知识点又多又杂什么生命周期、开发模型、可行性研究、结构化分析、面向对象、测试用例设计……密密麻麻背了忘忘了背。我当年期末复习的时候也差点被逼疯后来把整门课拆成“工程流程线 关键方法论 高频考点”三个维度来整理才算真正吃透。这篇笔记就是按照这个思路整理的覆盖软件工程期末最常见的考查范围和重难点从概念到实操题型都有适合考前突击、系统回顾也适合平时学得云里雾里的同学拿来搭框架。1. 课程体系与复习主线1.1 软件工程到底学什么软件工程不是单纯写代码它解决的是“怎么把软件做出来、做好、做快”的问题。和编程课不一样编程课关注代码怎么写软件工程关注的是整个软件从无到有的全过程要不要做、做什么、怎么设计、怎么写、怎么测、怎么维护、怎么管理进度和成本。期末复习首先要有一个整体框架别上来就背名词解释。整门课的核心逻辑就是一条时间线问题定义 → 可行性研究 → 需求分析 → 概要设计 → 详细设计 → 编码与测试 → 维护这就是软件生命周期。你所有的知识点基本都能挂在这条线上。复习的时候建议先记住这条主线再把每个阶段的概念、方法、工具、产出物填进去这样就算遇到没见过的题目也能靠逻辑推断出大概答案而不是死记硬背。1.2 期末考试的常见题型与备考思路软件工程期末考试的题型一般比较固定无非是这几类概念题考名词解释或简答比如“什么是软件危机”“什么是内聚”“什么是耦合”这类题考察对核心定义的准确记忆。对比题让比较两个模型或概念的异同比如瀑布模型和原型模型的区别、黑盒测试和白盒测试的区别。这类题靠理解写的时候要有条理。应用题给你一个系统描述让你画数据流图、画ER图、画用例图或者设计测试用例。这类题分值最大也是最容易拉分的地方。综合题给你一个项目场景让你选择开发模型并说明理由或让你写需求分析的步骤这类题考察工程思维。复习策略上我建议概念题靠关键词记忆对比题靠表格整理应用题必须动手练。数据流图、测试用例设计这些光看不练等于白学我在后面会详细拆解。2. 软件工程基础概念与经典开发模型2.1 软件危机与软件工程的定义软件危机是软件工程这门课最开头的核心概念几乎是必考点。它指的是在软件开发过程中经常遇到的、无法克服的困难集中表现为开发进度难以预测、成本超支、产品质量不可靠、维护极其困难。一个系统做到最后烂尾、改一处崩三处本质上都是软件危机的表现。软件工程就是为了解决软件危机而提出的工程化方法。定义要记准确软件工程是指导计算机软件开发和维护的一门工程学科它采用工程的概念、原理、技术和方法来开发与维护软件把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。这里有个容易出选择题和判断题的点软件工程不仅包括技术方法还包括项目管理、人员组织、质量保证等内容它强调的是“工程化”不是单打独斗写代码。考试如果问“软件工程的三要素”要答过程、方法、工具。过程是框架方法是手段工具是支撑。2.2 常用软件过程模型对比软件过程模型也叫软件开发模型是期末的重点和必考点。每个模型都要记住核心思想、适用场景、优缺点。这里我按从经典到现代的脉络来梳理。瀑布模型是最经典、最基础的一个它是线性顺序模型像瀑布一样自上而下流动。阶段划分很清晰问题定义与可行性研究、需求分析、设计、编码、测试、维护。优点是有严格的阶段划分和文档管理每个阶段都有评审缺点是太死板用户要等很久才能看到结果而且需求一旦变更项目就会返工甚至推倒重来。原型模型则主要是为了解决瀑布模型需求不明确的问题。它先快速开发一个“样品”给用户看用户觉得哪里不对就改哪里反复迭代直到需求明确然后再开发正式产品。优点是能快速确认需求特别适合用户说不清楚自己想要什么的场景缺点是在原型的基础上不断修改可能导致系统结构不清晰、质量受影响。增量模型和螺旋模型也经常会考。增量模型把系统拆成一个个增量先交付核心功能再逐步增加功能用户能较早使用部分功能。螺旋模型则引入了风险分析每一圈螺旋都包括制定计划、风险分析、实施工程、客户评估四个阶段特别适合大型、复杂、高风险的项目。还要注意统一过程RUP和敏捷开发。RUP是一个二维的开发框架横轴是时间纵轴是工作流核心思想是用例驱动、以架构为中心、迭代和增量。敏捷开发强调个体和互动胜过过程和工具、可工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。敏捷这个词如果考简答要把这四个价值观写出来最好还能说说常见的敏捷实践比如Scrum里的Sprint冲刺、每日站会、产品待办列表等。2.3 模型选择的判断依据期末综合题里经常给一个项目场景让你选择开发模型。这种题没有标准答案但你要能自圆其说理由充分。一般逻辑是这样的需求明确、技术成熟、不容易变更的项目选瀑布模型比较稳妥因为阶段划分清晰便于管理。需求不明确、用户参与度高的项目选原型模型或增量模型。大型复杂、风险高的项目选螺旋模型因为它有风险分析环节。需求变化快、强调快速交付的项目选敏捷开发。答题时一定要结合场景说理由比如“该项目需求不够明确因此采用原型模型可以尽早与用户确认需求避免后期大改”。这样写分就基本拿到了。2.4 常见算法类知识在软工中的应用提醒搜软件工程期末资料的时候很多同学会搜到“Floyed算法类似的算法”。这里得提醒一下Floyed算法本身是算法设计课程的内容软件工程期末考试一般不会直接考 Floyd 算法的代码实现但是“算法”两个字在软件工程里还是有出题点的。软件工程里涉及算法和逻辑设计的地方主要有两类一是详细设计阶段的算法描述工具比如程序流程图、盒图N-S图、PAD图它们的作用就是把算法逻辑表达清楚二是在选择架构或模块实现方案时需要评估算法或数据结构的时间复杂度和空间复杂度判断是否满足需求中的性能约束。所以如果你搜Floyed算法搜到了软件工程的资料大概率是这两个情景之一。复习时重点掌握详细设计工具怎么画以及如何用类似逻辑去描述一个处理过程不要在Floyed这种具体算法实现上花费太多时间那不是这门课的考查重心。3. 需求分析画图能力是分水岭3.1 需求分析的任务与产出物需求分析是软件工程中承上启下的关键步骤目的是搞清楚“系统到底要做什么”。很多同学觉得需求分析就是聊聊天、记记笔记但在考试里它对应的是数据流图、数据字典、ER图、用例图这些硬核考点。需求分析的具体任务包括确定系统综合要求功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束等、分析系统的数据需求、导出系统的逻辑模型、修正系统开发计划。产出物是需求规格说明书它是后续设计、测试和验收的依据。期末复习时需求这块要注意几个高频概念功能需求是“系统必须做什么”非功能需求是“系统做到什么程度”性能、安全、可用性等。数据流图关注系统的数据流向和处理逻辑ER图关注数据之间的关系用例图关注用户和系统的交互。这三张图是需求分析阶段最常考的三类题目。3.2 数据流图DFD的画法与判分点数据流图是结构化分析的核心工具期末应用题出现频率极高。它描述数据在系统中的流动和处理过程由四个基本元素组成外部实体矩形、加工圆角矩形或圆圈、数据存储开口矩形、数据流箭头。画数据流图有几个关键步骤。首先识别外部实体也就是跟系统交互的人和外部系统比如学生选课系统里的“学生”就是外部实体。然后确定系统的输入和输出数据流接着从中心加工开始逐层分解。顶层图也叫上下文图把整个系统看成一个加工只画外部实体和输入输出。然后进行一层层细化把大的加工拆成小的加工直到每个加工都能明确表达为止。考试里数据流图的判分点通常在以下几点加工必须有输入输出而且输入输出数据要匹配不会凭空消失数据流的箭头方向不能画反数据存储和加工之间要有数据流连接加工至少要有一个输入和一个输出。修改数据流图时必须遵守一个规则就是父图和子图的数据流要平衡父图中某个加工的输入输出数据流必须在子图中出现。画数据流图时最容易犯的错误是漏画数据存储、把外部实体直接连到数据存储、或者加工之间缺少中间数据流。平时练习时可以先写一个数据字典把所有用到的数据项列出来再动笔画图这个习惯能帮你避免很多低级失误。3.3 用例图以用户视角捕获需求面向对象的需求分析中用例图是必考内容。用例图的核心思想是以用户视角描述系统功能回答“谁用系统做什么事”。用例图的三要素是参与者、用例和关系。参与者是外部角色用人形符号表示不一定是真人也可以是外部系统。用例是一个完整的功能单元用椭圆表示。关系包括关联、包含、扩展和泛化关联是参与者和用例之间的关系包含是一个用例必包含另一个用例的动作扩展是在某些条件下才触发的额外行为泛化是继承关系。画用例图时容易搞混的是包含和扩展。我考试时总结了一个经验只要看到“每次都执行”“必需的子步骤”就画成包含用带《include》的虚线箭头从基本用例指向子用例只要看到“在某些条件下”“可选的额外功能”就画成扩展用带《extend》的箭头从扩展用例指向基本用例。平时练习可以拿快递柜、网上订餐、图书馆借书这些身边系统来画用例图重点训练识别参与者和粒度划分别把“输入用户名密码”这种登录子功能都当成一个大用例用例粒度要控制在“能独立完成一个有价值的用户目标”这个层级。3.4 ER图与数据字典要点ER图在软件工程期末中经常和数据库概论结合考但软件工程课程的侧重点在“如何通过数据建模来明确需求”而不是ER图的详细数据库设计规则。ER图的基本成分是实体、属性和联系。实体用矩形属性用椭圆联系用菱形。联系类型有一对一1:1、一对多1:N、多对多M:N。考试通常会给一段需求描述要求画出ER图并在联系上标注联系类型。数据字典则是数据流图的补充它定义数据流图中出现的数据项、数据结构、数据流、数据存储和处理逻辑。简单说数据流图是系统逻辑模型的骨架数据字典是这张骨架上的血肉两者配合才能完整描述系统需求。复习时至少要掌握数据字典的四个条目怎么写尤其是数据流条目要说明名称、别名、组成、来源、去向和流通量。4. 软件设计从概要设计到详细设计4.1 概要设计要解决什么问题概要设计又叫系统设计它的任务是把需求转化为软件的系统结构和数据结构回答的是“系统怎么组织”的问题。期末考试中概要设计部分的高频考点是模块化、内聚与耦合、结构化设计方法、软件架构风格。模块化是概要设计的核心原则把系统拆成一个个相对独立的模块每个模块完成一个子功能。模块化的好处是降低复杂度、便于测试和维护。判断模块化程度的指标是内聚和耦合。内聚是指一个模块内部各元素之间联系的紧密程度。从弱到强依次是偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。耦合是模块之间的相互依赖程度。从弱到强依次是非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。设计原则就是一句话高内聚、低耦合。功能内聚最强数据耦合最弱在不考虑非直接耦合的情况下。考题有时候会给你几个模块关系让你判断内聚和耦合类型需要记住各种类型的特征。比如模块之间传递一个参数是数据耦合传递一个控制信号是控制耦合多个模块共享一个全局数据结构是公共耦合一个模块直接访问另一个模块的内部数据是内容耦合。这个几乎年年有题。4.2 软件架构风格与设计原则软件架构风格也是近年比较常考的内容。常见的架构风格包括数据流风格批处理序列、管道-过滤器、调用/返回风格主程序-子程序、面向对象、层次结构、独立构件风格进程通信、事件驱动、虚拟机风格解释器、规则系统、仓库风格数据库系统、超文本系统等。这里不用死记每种风格的细节但至少看到某个系统描述时能判断属于哪种风格。比如编译器适合用管道-过滤器风格操作系统适合用层次结构AI专家系统适合用规则系统。概要设计的另一个考点是模块设计的基本原则比如降低模块接口复杂度、设计高内聚模块、设计单入口单出口的模块、把可能变化的区域封装起来等。解答这类题目时如果能结合内聚耦合一起来答显得更有深度。4.3 详细设计工具与程序流程图详细设计阶段的任务是为每个模块的内部实现设计具体的处理逻辑也就是“模块内部怎么做”。考试题型往往是让你用工具画出某个算法流程或者给出流程图让你补充缺失的判断条件。详细设计的典型工具包括程序流程图、盒图N-S图、PAD图、判定表和判定树、过程设计语言PDL。程序流程图是我要特别提醒的一个点因为很多同学画着画着就画错了。程序流程图的基本符号对应的是标准流程图的写法起止框用圆角矩形处理框用矩形判断框用菱形输入输出框用平行四边形箭头表示控制流。画的时候要注意判断框必须有“是”和“否”两条出口循环结构在流程图中要区分当型和直到型。期末阅卷的时候很多老师会重点看判断框出口有没有标注“Y/N”或“真/假”这是常见的扣分点。盒图N-S图不像程序流程图那样有箭头它是完全结构化的表示方法去掉了控制流的随意转向强制设计者按照顺序、选择、循环三种基本结构来组织逻辑。盒图的优点是防止程序出现非结构化的跳转缺点是不适合大规模系统的整体描述。PAD图是中国学者提出的采用二维树形结构最左边是主线和层次结构逻辑清晰也容易转换成代码。考试中如果要求绘制某两种图的转换最常考的是程序流程图和盒图互相转换只要记住原则就行结构化流程才能无损转换非结构化的随意跳转不能转换为盒图。判定表和判定树主要用于表示复杂的条件组合与动作之间的对应关系比如机票折扣、运费计算这类多条件多结果的场景。判定表由条件桩、动作桩、条件项、动作项组成判定树则是判定表的图形化表达。这里顺带说一下很多人在看的“详细设计-2”这个搜索词实际就是教材里详细设计章节的后续部分主要内容就是这些算法描述工具和面向数据结构的设计方法。其中Jackson方法的核心思想是“程序结构必须与数据结构相对应”看到顺序、选择、重复这三种数据结构就对应设计出顺序、选择、重复三种程序结构。4.4 详细设计的符号规范一张表理清流程图形状期末考试里经常会给一段文字描述让你画出程序流程图。很多同学画得乱七八糟问题就出在符号用得不规范。这里我整理了一张我在复习时反复对照的表格符号形状名称作用圆角矩形起止框算法开始或结束平行四边形输入/输出框数据的输入或输出矩形处理框赋值、计算等处理操作菱形判断框条件判断必须有两个出口带箭头的线控制流指明执行顺序画流程图的步骤我建议这样先理清算法逻辑确定哪里开始、哪里结束、哪些是判断点然后把判断点作为分岔路先画主干流程再补分支最后把每条路径走一遍看是否有遗漏、是否有死循环。判断框的双出口最容易出错经常有同学只画一个出口或者出口没有标注。另一个常见问题是处理框和输入输出框混用把“输入x”写成了矩形处理框这种粗心丢分很可惜。平时练的时候把这些细节盯住考试就不会失分。5. 编码与测试拿分最快也最容易踩坑的部分5.1 编码规范与编程风格编码阶段涉及到的考点不多但经常会出选择题或简答题考察编程风格。核心观点是编码阶段要注重程序的可读性和可维护性代码是写给人看的其次才是让机器执行。好的编程风格包括有意义的变量名、规范的注释、清晰的控制结构、避免难以理解的技巧性写法。考试中如果问“编码阶段应该注意什么”从源程序文档化、数据说明规范化、语句构造简单直接、输入输出友好这四个角度回答基本不会丢分。5.2 软件测试的目的与原则测试是软件工程期末的绝对重点几乎每个题型的每份试卷都会涉及。要搞清楚一个核心观念测试的目的是发现程序中的错误而不是证明程序没有错误。软件测试的原则有很多条高频可考的有测试用例应由输入数据和预期的输出结果两部分组成不仅要选择合理的输入数据还要选择不合理的输入数据进行测试应尽早地、不断地进行测试测试用例必须包含预期输出结果程序模块应由编写者之外的人来测试比较合理。其中“程序员应避免测试自己的程序”这个原则经常考判断或简答。测试信息流模型中测试的输入是软件配置需求、设计、源程序和测试配置测试计划、测试用例、预期结果输出是测试结果、错误分析和排错信息。这个图有时候会考“测试信息流”相关选择题。5.3 白盒测试逻辑覆盖是命题集中地白盒测试又叫结构测试是把程序看作一个透明的盒子根据程序内部逻辑结构设计测试用例。白盒测试的考查重点是逻辑覆盖从弱到强排列是语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。每种覆盖的具体要求要记清楚语句覆盖每个可执行语句至少执行一次。最弱。判定覆盖每个判定的真分支和假分支至少各执行一次。条件覆盖每个判定中的每个条件的真和假至少各执行一次。判定/条件覆盖同时满足判定覆盖和条件覆盖。条件组合覆盖每个判定中所有条件组合至少出现一次。路径覆盖程序的所有可能路径都至少执行一次。期末考试最常见的考法是给一段代码和一个流程图让你设计测试用例看是否满足某种覆盖标准。这部分的题目只有动手算才能熟练掌握光背定义没有用。做这类题我有一个笨但有效的方法先把每个判定的条件分别标出来比如判定1的条件是“x0 y0”就把它们命名为C1、C2然后逐一列出每个条件的真假情况再组合成测试用例。这样一步一笔写下来就不会漏条件也不会搞混覆盖标准。这里要特别提醒条件组合覆盖不一定覆盖每条路径路径覆盖也不一定满足条件组合覆盖它们不是包含关系。这是很多同学做题时会踩的坑考试偶尔会出判断题或简答题来考这个点。5.4 黑盒测试等价类划分与边界值分析黑盒测试也叫功能测试是把程序看作一个不透明的黑盒子完全基于输入输出来测试。最常考的两种方法是等价类划分和边界值分析。等价类划分的核心思想是把输入数据划分成若干等价类在每个等价类中取一个代表值进行测试。有效等价类是符合需求规格说明的合理输入无效等价类是不合理、无意义的输入。设计测试用例时要覆盖所有的有效等价类和无效等价类。需要注意一个原则每个无效等价类要单独设计测试用例不能好几个无效等价类塞在一个用例里否则测出来错误也定位不到是哪个条件引起的。边界值分析则是选择输入或输出边界的值来测试因为经验表明很多错误都出现在边界附近。比如输入范围是1到100那么边界值设计时要测0、1、100、101还要测一个正常值比如50来作为对照。这两种方法经常放在一道应用题里考比如“某程序要求输入用户名长度为6到12个字符请用等价类划分和边界值分析设计测试用例”。这属于白送分题但前提是你平时练过。我建议考试前至少亲手写两套完整的测试用例格式包括用例编号、输入数据、预期输出、覆盖类型练熟了考场上才能又快又规范。5.5 单元测试、集成测试与系统测试测试策略也是常考知识点。从小到大的层次是单元测试、集成测试、确认测试、系统测试。单元测试针对每个模块通常由程序员自己完成重点测试模块接口、局部数据结构、边界条件和独立的执行路径。集成测试是把模块组装起来测试有非渐增式和渐增式两种方法渐增式又分为自顶向下和自底向上。如果考“自顶向下测试”和“自底向上测试”的区别要答自顶向下需要编写桩模块能较早发现顶层接口错误但底层模块的测试可能要推迟自底向上需要编写驱动程序底层模块可以较早得到测试但顶层模块的问题发现较晚。扇形测试法是自底向上和自顶向下结合的混合策略。确认测试也叫有效性测试是验证软件的功能和性能与用户需求是否一致用黑盒测试为主。系统测试则是把软件放在真实的运行环境中和硬件、外设、其他软件系统一起测试。还有一个很容易考的选择题陷阱α测试是由用户在开发者的场所进行的测试开发者在一旁观看受控的环境。β测试是由用户在最终用户场所进行的测试开发者不在场环境不受控制。这两个定义经常混着考一定要区分清楚。5.6 调试与软件维护测试和调试的区别也是高频考点。测试是发现错误调试是定位并纠正错误。测试在先调试在后。调试的方法有蛮力法、回溯法、原因排除法对分查找、归纳法、演绎法考试考填空或选择的几率较大名词知道就行。软件维护是生命周期中耗时最长、成本最高的阶段有四种维护类型改正性维护修复发现的错误、适应性维护适应环境变化、完善性维护增加新功能或改进性能、预防性维护为将来维护做准备。其中完善性维护占比最高。如果考“哪类维护占比最大”要答完善性维护这是教材中的经典数据。6. 项目管理与软件质量容易被忽略的送分题6.1 软件项目管理的基本内容软件项目管理在期末考试中的占比不是最大但常以选择题、填空题或简答题形式出现而且内容相对简单属于送分板块。软件项目管理的内容包括计划制定、人员组织、成本估算、进度管理、风险分析、质量保证、配置管理等。复习时重点掌握成本估算和风险分析这两块因为它们有具体的公式和方法。成本估算方面要会算代码行数LOC和功能点FP还要掌握基本COCOMO模型。COCOMO模型的基本公式是工作量 E a × (KLOC)^b 人月。简单说代码量越大、项目越复杂工作量增长越快。考试中如果给定了a、b的值和代码量套公式计算就可以。进度管理要了解Gantt图甘特图和工程网络图。甘特图直观显示任务的开始和结束时间但无法清晰显示任务之间的依赖关系。工程网络图PERT图能显示任务之间的依赖关系适合做关键路径分析。如果考关键路径的计算把所有路径长度算出来最长的那条就是关键路径这条路径上的任务延误会直接影响整个项目工期。6.2 风险分析与软件质量保证风险分析包括风险识别、风险预测、风险评估和风险管理。软件工程中经常把风险分为项目风险、技术风险和商业风险三类。复习时能理解这三种风险的区别即可。软件质量保证SQA的目标是验证软件是否满足规定的技术和用户需求。质量度量方面McCabe复杂度度量是常考的计算题。环形复杂度V(G)有三种计算方法V(G) 区域数V(G) 判定节点数 1V(G) 边数 - 节点数 2。画好程序图之后任选一种方法计算即可。一般算出来数值越大程序可测试性和可维护性越差。这个考点在期末中经常以小计算题或填空题的形式出现值得拿分。6.3 软件能力成熟度模型CMMCMMCapability Maturity Model描述的是软件组织在开发和维护软件时过程成熟度的五个等级初始级、可重复级、已定义级、已管理级、优化级。这五个等级从低到高体现了组织软件开发过程的规范化和持续改进能力。期末如果考CMM多考等级名称和顺序偶尔会考某个等级的特点比如初始级的特点是过程无序、 depends on 个人英雄主义优化级则关注过程的持续改进。记住五个等级名称和顺序这个考点就不会失分。如果用的是“软件工程概率第十版”这类教材CMM和ISO 9000的区别也是可能出现的简答题CMM强调过程和能力成熟度ISO 9000强调质量体系的符合性认证。能写清楚这一点就够了。7. 高频易错点与考前速记清单7.1 几十个高频考点的速查识别考前最后一轮复习我建议直接过一遍高频考点速查看到自己瞬间想不起来定义的点立刻翻书补漏。下面这份清单基本覆盖了期末试卷中最常出现的名词和简答内容软件工程三要素过程、方法、工具软件生命周期各阶段名称及顺序瀑布模型 vs 原型模型 vs 增量模型 vs 螺旋模型的核心特征内聚的七种类型从弱到强排序耦合的七种类型从弱到强排序数据流图四要素及画法数据字典的四种条目用例图三要素及包含/扩展关系详细设计工具名称流程图、盒图、PAD图、判定表、PDL白盒测试的各种逻辑覆盖标准及强弱关系黑盒测试的等价类划分方法边界值分析的设计要点单元测试、集成测试、确认测试、系统测试的关系α测试与β测试的区别测试与调试的区别软件维护的四种类型及占比McCabe环形复杂度计算COCOMO模型的工作量计算关键路径的计算CMM五级名称与顺序其中我特别要强调一个有迷惑性的点测试用例设计时无效等价类要“逐类分别测试”但有效等价类可以合并测试因为有效等价类之间不冲突而多个无效条件同时出现时无法判断具体是哪个条件导致系统出错。考试中如果问这个原则很多同学会答反要注意。7.2 计算题与画图题的考场策略软件工程期末的计算题和画图题分值高主观性强但也是最好拿分的部分。我的考场策略是先做计算题再做画图题最后做简答和概念题因为计算和画图题目答案明确做完心里有底。做McCabe复杂度计算时建议先画程序图再数区域区域数这个方法是三种方法中不容易漏数的。做关键路径计算时把所有路径都列出来不要凭直觉判断。做COCOMO计算时注意KLOC的单位是千行不是行代入公式之前先换算。画数据流图和用例图时先用铅笔轻轻画出框架再用签字笔定稿卷面整洁在主观题里还是挺占便宜的。做等价类划分题时一定要把“无效等价类”也写全很多同学只写有效等价类白白丢了半道题的分。7.3 我自己复习时踩过的坑这里分享几个我复习软件工程时踩过的坑都是实实在在的教训。第一个坑是不画图。我第一次复习数据流图的时候觉得看看例题就能看懂结果上了考场手忙脚乱。数据流图、ER图、程序流程图、盒图这些必须动手画只有自己画一遍才会发现漏了输入输出、判断框出口没标注这些细节。第二个坑是死记内聚耦合的排序。内聚和耦合各七种类型的强弱顺序光背容易串我的方法是编口诀或找规律内聚从“偶然”到“功能”越来越强耦合从“内容”到“非直接”越来越弱考试时先写出两端再往中间推就不容易乱。第三个坑是概念混在一起。比如把“确认测试”和“系统测试”搞混把“适应性维护”和“完善性维护”搞混。我的解决办法是拿A4纸画框架图把每个阶段、每类测试、每种维护方式放在一张图上用箭头标注之间的关系这样复习到最后就不容易乱。第四个坑是只背书不动笔算。McCabe复杂度、COCOMO、关键路径这三类计算题看会了和自己算出来完全不是一回事。建议考前至少把教材例题从头到尾算一遍保证每一步公式都写对。7.4 考前一周的复习安排建议如果还有一周时间我建议按照这样的节奏来安排前三天过完所有概念和模型配合整理对比表格第四到五天集中练画图和测试用例设计题不用多每个题型三道就够但每一道都要完整写不要看书第六天刷计算题McCabe、COCOMO、关键路径、等价类划分这些轮着做最后一天快速过一遍高频考点清单把自己仍然记不住的点集中背一下。软件工程的知识点不是靠死记硬背就能全部覆盖的它更强调理解和应用。期末复习虽然时间紧任务重但抓住主线、理清框架、勤练画图题和计算题及格往上还是很容易的。如果想要冲击高分细节概念不能放过答题时图文结合条理清晰就能和大部分人拉开差距。
