软件工程期末考试冲刺版知识库

基于课程全部12章PPT逐页深度分析 | 考试结构：选择题30分 + 简答题20分 + 应用题50分
教材：《Introduction to Systems Analysis and Design, 6th Edition》Satzinger, Jackson & Burd

任务一：全部知识点提取

【知识点1】软件的定义 (Software Definition)

定义：软件是计算机中与硬件相互依存的另一部分，是程序、数据及其相关文档的完整集合。

核心内容：

  • 程序(Program)：按事先设计的功能和性能要求执行的指令序列
  • 数据(Data)：使程序能够正确处理信息的数据结构
  • 文档(Document)：与程序开发、维护和使用有关的图文资料

关键术语：Software = Program + Data + Document

重要细节：

  • 软件是逻辑产品（非物理产品）
  • 软件不会磨损和老化（但会退化——维护引入新错误）
  • 软件依赖硬件运行
  • 目前仍以手工开发为主
  • 软件技术发展三阶段：程序设计→程序系统→软件工程

常见陷阱：选择题干扰项”软件=代码+文档”（缺少数据）；”软件不会退化”（物理不磨损但逻辑退化）

考试出现形式：填空”软件的三个组成部分”；选择”以下哪项不属于软件”

重要程度：⭐⭐ 高频

【知识点2】软件危机 (Software Crisis)

定义：在软件开发和维护过程中遇到的一系列严重问题。

产生原因（6条）：

  1. 忽视前期调研和需求分析
  2. 缺乏开发经验和数据积累
  3. 缺乏统一的、规范化的方法论指导
  4. 忽视与用户、团队间的有效沟通
  5. 文档资料不规范或不准确
  6. 没有完善的质量保证体系

主要表现（5条）：

  1. 软件不能满足用户需求
  2. 开发成本严重超标，周期大大超过规定日期
  3. 软件质量难于保证，可靠性差
  4. 软件难于维护
  5. 软件开发速度跟不上计算机发展速度

解决方案：

  • 技术措施：好的方法(Methods) + 好的工具(Tools)
  • 管理措施：良好的组织、严密的管理

为什么推动软件工程产生：软件危机的严重性迫使人们将工程化原则引入软件开发，1968年NATO会议首次提出”软件工程”概念。

经典案例：

  • IBM OS/360（1961-1964）：100万条指令，5000人年，5亿美元，2000+错误
  • 美国银行信托系统（1982-1987）：预算2000万→6000万，最终放弃，失去340亿美元信托账户

考试常见问法：简答”简述软件危机的主要表现和原因”；选择”以下哪项不是软件危机的表现”

重要程度：⭐⭐⭐ 必考

【知识点3】软件工程的诞生与定义 (Birth of Software Engineering)

定义：软件工程是从技术和管理两方面研究如何更好地开发和维护计算机软件的学科。

核心内容：

  • 1968年，NATO（北大西洋公约组织）计算机科学会议
  • Fritz Bauer 首次提出”软件工程”概念
  • Edsger Dijkstra 同年发表”GOTO Statement Considered Harmful”

Boehm七条基本原理（必须完整记忆）：

  1. 用分阶段的软件生存周期计划进行严格的质量管理
  2. 坚持进行阶段评审
  3. 实行严格的产品控制
  4. 采用现代程序设计技术
  5. 软件工程结果应能清楚地审查
  6. 开发小组的人员应该少而精
  7. 承认不断改进软件工程实践的必要性

记忆口诀：”计评审控技，审精改”

重要程度：⭐⭐⭐ 必考

【知识点4】软件生存周期 (Software Life Cycle / SDLC)

定义：软件从立项到废弃的整个过程。

六大阶段：

阶段 英文 核心问题
立项分析 Project Initiation 为什么要做？
需求分析 Requirements Analysis 系统需要什么功能？
系统设计 System Design 如何实现？
编码 Coding 怎么写代码？
测试 Testing 代码能否经受考验？
部署与维护 Deployment & Maintenance 如何部署和维护？

SDLC支持阶段三大活动：

  • 维护系统(Maintaining)：修复错误，做小调整
  • 增强系统(Enhancing)：添加新功能
  • 支持用户(Supporting Users)：培训，帮助台

重要程度：⭐⭐ 高频

【知识点5】SDLC两种方法 (Predictive vs Adaptive)

定义：

预测性方法(Predictive Approach)：项目可以提前完整规划，按计划顺序开发。典型代表：瀑布模型。假设需求明确、技术风险低。

适应性方法(Adaptive Approach)：项目必须灵活适应变化中的需求，始终包含迭代。典型代表：螺旋模型、敏捷。假设需求不确定、技术风险高。

核心要点：大多数项目处于预测性和适应性之间的连续谱(continuum)上。

常见陷阱：选择”瀑布模型是适应性方法”（错，是预测性）；”螺旋模型是预测性方法”（错，是适应性）

重要程度：⭐⭐⭐ 必考

【知识点6】结构化方法 (Structured Approach)

定义：将系统视为一组与数据交互的过程的集合。

三个阶段：

  • 结构化分析(SA)：用数据流图(DFD)建立功能模型
  • 结构化设计(SD)：将DFD转换为软件体系结构
  • 结构化程序设计(SP)：用标准控制结构表示模块功能

结构化程序设计五原则：

  1. 使用有限的基本控制结构（顺序/选择/循环）
  2. 每个控制结构只有一个入口和一个出口
  3. 语句组成容易识别的块(Block)
  4. 复杂结构用基本控制结构组合嵌套实现
  5. 严格控制GOTO语句

五种基本控制结构：顺序型、选择型、当型循环(While)、直到型循环(Until)、多情况选择型(Case)

描述工具：

  • 结构图(SC)：矩形框=模块，空心圆=传数据，实心圆=传控制
  • 程序流程图：五种基本结构的图形表示
  • N-S图（盒图）：Nassi-Shneideman图
  • PAD图（问题分析图）

四种模块类型：

  • 原子模块(Atomic)：不可再分的底层模块
  • 传入模块(Input)：从下属模块取数据，处理后传给上级
  • 传出模块(Output)：从上级获数据，处理后传给下属
  • 变换模块(Transform)：从上级获数据，特定处理后返回上级
  • 协调模块(Coordination)：管理所有下属模块

两种系统结构：

  • 变换型(Transform)：传入→变换中心→传出
  • 事务型(Transaction)：事务中心根据事务类型分配处理

重要人物：Dijkstra(1965提出结构化程序设计), Bohm & Jacopini(1966证明三种控制结构可实现任何程序)

重要程度：⭐⭐⭐ 必考

【知识点7】面向对象方法 (Object-Oriented Approach)

定义：将系统视为一组为完成任务而交互的对象的集合。

三个阶段：

  • OOA(面向对象分析)：识别用例和类
  • OOD(面向对象设计)：定义对象类型及交互
  • OOP(面向对象编程)：编写类定义和行为代码

核心概念：对象=数据+操作，类(Class)，消息(Message)，继承(Inheritance)

vs 结构化方法：

维度 结构化方法 面向对象方法
基本假设 系统=过程+数据 系统=对象交互
分解方式 功能分解 对象分解
数据与操作 分离 封装在一起
可重用性 差 好
适用场景 中小型/数据流明确 大型/复杂/交互性强

重要程度：⭐⭐⭐ 必考

【知识点8】系统分析活动 (Systems Analysis Activities)

定义：理解业务需求并建立系统模型的过程。

五个步骤：

  1. 收集详细信息(Gather Detailed Information)
  2. 定义需求(Define Requirements)
  3. 需求优先级排序(Prioritize Requirements)：Essential/Important/Nice to have
  4. 开发用户界面对话(Develop User-Interface Dialogs)
  5. 与用户评估需求(Evaluate Requirements with Users)

重要程度：⭐⭐ 高频

【知识点9】需求分类 (Requirements Classification)

定义：系统需求分为功能需求和非功能需求。

功能需求(Functional Requirements)：系统必须执行的活动/业务功能。描述系统”做什么”。

非功能需求(Non-functional Requirements)：约束条件和性能目标。描述系统”做得怎样”。

FURPS+ 模型（高频考点）：

字母 全称 中文 类型
F Functional 功能需求 功能
U Usability 可用性需求 非功能
R Reliability 可靠性需求 非功能
P Performance 性能需求 非功能
S Security 安全需求 非功能
+ 扩展 设计限制/开发/接口/物理/支持 非功能

常见陷阱：F(功能需求)本身不是非功能需求，U/R/P/S/+才是非功能需求

重要程度：⭐⭐⭐ 必考

【知识点10】利益相关者 (Stakeholders)

定义：对系统成功实施有兴趣的人。

四种分类：

内部(Internal) 外部(External)
操作(Operational) 内部操作员（如员工） 外部操作员（如客户）
执行(Executive) 内部管理者 外部管理者/股东

重要程度：⭐⭐ 高频

【知识点11】信息收集技术 (Information-Gathering Techniques)

六种方法：

  1. 访谈(Interviewing)：准备问题→讨论答案→记录→跟进
  2. 问卷(Questionnaires)：大范围收集
  3. 审查文档(Reviewing documents)：现有输入/输出/文档
  4. 观察流程(Observing procedures)：直接观察业务流程
  5. 研究供应商(Researching vendors)：白皮书、供应商方案
  6. 收集反馈(Collecting comments)：活跃用户的意见和建议

重要程度：⭐⭐ 高频

【知识点12】活动图 (Activity Diagram)

定义：描述用户/系统活动、执行人员和活动顺序流的UML图。

组成元素：

  • 初始节点(Initial Node)：黑色实心圆
  • 活动(Activity)：圆角矩形
  • 判断(Decision)：菱形
  • 分叉/汇合(Fork/Join)：粗横线，表示并行路径
  • 终止节点(Final Node)：带环的黑色实心圆

考试画图步骤：

  1. 确定起始和终止节点
  2. 识别主要活动
  3. 添加判断分支
  4. 添加并行路径(Fork/Join成对出现)
  5. 连接所有节点

常见错误：Fork和Join不成对出现；判断菱形后没有分支

重要程度：⭐⭐⭐ 必考（应用题画图）

【知识点13】数据流图 DFD (Data Flow Diagram)

定义：描述系统中数据流动和加工的图形工具。

四种基本符号：

  • 数据流(Data Flow)：箭头
  • 加工(Process)：圆或圆角矩形
  • 数据存储(Data Store)：开口矩形
  • 外部实体(External Entity)：矩形

绘制步骤：

  1. 画顶层DFD（确定系统边界）
  2. 逐层分解（自顶向下）
  3. 画总DFD

数据词典(DD)条目：名字、别名、分类、内容描述、何处使用

重要程度：⭐⭐⭐ 必考

【知识点14】需求规格说明书 SRS (Software Requirements Specification)

定义：用户与开发方之间的技术合同，描述系统必须做什么。

参照标准：GB/T 8567-2006

编写要求：

  1. 准确无误无二义性
  2. 规范书写
  3. 允许适当调整
  4. 后续设计和编码的基础

需求评审四个方面：

  • 一致性(Consistency)：需求不矛盾
  • 完整性(Completeness)：包含所有功能和性能
  • 现实性(Feasibility)：现有技术可实现
  • 有效性(Validity)：需求正确有效

重要程度：⭐⭐⭐ 必考

【知识点15】用例 (Use Case)

定义：系统执行的活动，通常是对用户请求的响应。

命名规则：动词-名词(Verb-Noun)，如”Create customer account”

EBP(基本业务流程)：由一个人在特定地点为响应交易事件执行的任务，增加可衡量的业务价值。

重要程度：⭐⭐⭐ 必考

【知识点16】识别用例的三种技术

1. 用户目标技术(User Goal Technique)
执行8步流程：识别所有潜在用户、按功能角色分类、按组织层次分类、采访用户收集目标、创建初步用例列表、去重和解决不一致、确定共享用例、与利益相关者审查。

2. 事件分解技术(Event Decomposition)
包含三种事件：

类型 定义 举例
外部事件(External) 系统外部发生，由外部代理发起 顾客购买产品
时间事件(Temporal) 到达某时间点时发生 月末生成报表
状态事件(State) 系统内部某事发生时触发 库存低于再订购点

理想技术假设(Perfect Technology Assumption)：分析阶段只考虑最佳条件下需要响应的事件。排除Login/Logout/密码修改/备份恢复等系统控制事件。

3. CRUD技术
CRUD = Create/Read/Update/Delete。主要用于验证用例完整性，确保每种数据的每个操作都有对应用例。

重要程度：⭐⭐⭐ 必考

【知识点17】用例图关系 (Use Case Relationships)

  • <<includes>> 包含关系：执行用例A时必须执行用例B才完整。箭头方向：A → B（主用例指向被包含用例）。类比调用子程序。举例：处理订单 <<includes>> 验证客户信息。
  • <<extend>> 扩展关系：执行用例A时在某些条件下会执行B。箭头方向：B → A（扩展用例指向主用例）。特点：B是可选的扩展。举例：计算折扣 <<extend>> 处理订单。
  • Generalization 泛化：继承关系，子用例指向父用例。

记忆口诀：”includes主指向被含（必须），extend被扩指向主（可选）”

重要程度：⭐⭐⭐ 必考（应用题画图核心）

【知识点18】完全开发的用例描述 (Fully Developed Use Case Description)

11个字段（必须全部记忆）：

# 字段 说明
1 Use case name 动词-名词
2 Scenario 特定路径/特殊情况
3 Triggering event 基于事件分解
4 Brief description 一句话描述
5 Actors 来自用例图
6 Related use cases <<includes>>关系
7 Stakeholders 感兴趣的人
8 Preconditions 开始前必须为真的条件
9 Post conditions 完成后必须为真的条件
10 Flow of activities 用户操作+系统响应（两列格式）
11 Exception conditions 可能出错的情况

重要程度：⭐⭐⭐ 必考（应用题核心）

【知识点19】系统顺序图 SSD (System Sequence Diagram)

定义：UML顺序图的特殊情况，只显示Actor和:System。

消息符号：

符号 含义 示例
* 重复/循环 *addItem()
[condition] 条件判断 [stockAvailable]
messageName 消息名(动词-名词) createOrder
(params) 参数列表 (itemID, qty)
returnValue 返回值 orderID

框架：Loop(循环)/Opt(可选)/Alt(条件分支)

重要程度：⭐⭐⭐ 必考（应用题画图）

【知识点20】状态机图 (State Machine Diagram)

定义：显示对象在状态和转换中的生命周期的UML图。

核心概念：

  • 状态(State)：对象生命周期中的条件
  • 转换(Transition)：从一种状态到另一种状态
  • 伪状态(Pseudo state)：起始点（黑色圆点）
  • 保护条件(Guard condition)：真/假测试，决定转换是否触发
  • 行动表达(Action expression)：转换时执行的活动
  • 复合状态(Composite state)：包含其他状态
  • 并行路径(Concurrent paths)：复合状态中的独立路径

转换格式：触发器名称[保护条件] / 行动表达

重要程度：⭐⭐⭐ 必考

【知识点21】域建模 (Domain Modeling)

定义：识别问题域中的”事物”并建立域模型类图。

两种识别技术：头脑风暴法(Brainstorming) 和 名词技术(Noun Technique)。

域模型类图 vs 设计类图：

  • 域模型类图没有方法（只有属性和关系）
  • 设计类图有方法（含可见性、Stereotype）

重要程度：⭐⭐⭐ 必考

【知识点22】类图关系 (Class Diagram Relationships)

五种关系：

关系 符号 定义 举例
关联(Association) 普通实线 类之间的连接 客户-订单
泛化(Generalization) 空心三角箭头 继承关系 Student→Person
聚合(Aggregation) 空心菱形 部分可独立 汽车-轮胎
组合(Composition) 实心菱形 部分不可分 人-头
依赖(Dependency) 虚线箭头 使用关系 类A使用方法参数类B

Multiplicity重数：0..1, 1, 0.., 1.., m..n

重要程度：⭐⭐⭐ 必考

【知识点23】内聚 (Cohesion) ⭐⭐⭐

定义：模块内部各元素之间联系的紧密程度。目标：高内聚。

七级（由低到高）：

级别 名称 定义 例子
1 偶然内聚(Coincidental) 模块内各部分无关系 把不相关的函数放一起
2 逻辑内聚(Logical) 模块执行逻辑上相似的功能 一个模块处理所有输入验证
3 时间内聚(Temporal) 模块内各部分在同一时间段执行 初始化模块
4 过程内聚(Procedural) 模块内各部分按特定顺序执行 读取文件→解析→验证
5 通信内聚(Communicational) 模块内各部分操作同一数据 更新客户地址和电话
6 顺序内聚(Sequential) 前一处理的输出是后一处理的输入 计算总和→计算平均
7 功能内聚(Functional) 模块只做一件事 计算折扣

记忆口诀：”巧逻时过通信顺功”

重要程度：⭐⭐⭐ 必考

【知识点24】耦合 (Coupling) ⭐⭐⭐

定义：模块之间相互依赖的程度。目标：松耦合（低耦合）。

七级（由低到高）：

级别 名称 定义 例子
1 非直接耦合(No Direct) 模块间无直接联系 独立模块
2 数据耦合(Data) 通过参数传递简单数据 传递一个整数参数
3 标记耦合(Stamp) 传递复合数据结构 传递一个对象/结构体
4 控制耦合(Control) 传递控制信息 传递一个标志位决定行为
5 外部耦合(External) 共享外部数据格式 共享全局常量
6 公共耦合(Common) 共享全局数据区 共享全局变量
7 内容耦合(Content) 直接访问另一模块内部 跳转到另一模块内部

记忆口诀：”非数标控外公内”

重要程度：⭐⭐⭐ 必考

【知识点25】SOLID设计原则

  • SRP(Single Responsibility Principle)：一个类只有一个引起变化的原因。违反：OrderProcessor同时处理订单、发邮件、存数据库。
  • OCP(Open-Closed Principle)：对扩展开放，对修改关闭。通过抽象/接口实现。
  • LSP(Liskov Substitution Principle)：子类型必须能替换基类型而不改变程序正确性。
  • ISP(Interface Segregation Principle)：客户端不应依赖不使用的接口。将大接口拆分为小接口。
  • DIP(Dependency Inversion Principle)：高层模块不应依赖低层模块，都应依赖抽象。

重要程度：⭐⭐⭐ 必考

【知识点26】三层架构 (Three-Layer Architecture)

  • View层(表示层)：用户界面，接收输入/展示输出
  • Domain层(域层/业务逻辑层)：核心业务规则和逻辑
  • Data Access层(数据访问层)：数据库交互，数据持久化

Controller模式：UI → Controller → Domain → DataAccess

用例实现流程：SSD → 添加Controller → 分配到Domain → 访问DataAccess

重要程度：⭐⭐⭐ 必考（应用题架构设计）

【知识点27】设计类Stereotype

五种类型：Entity（域对象/业务实体）、Boundary（界面边界）、Control（控制器/协调器）、Data Access（数据访问对象）、Persistent（持久化对象）

属性可见性：+ public, - private, # protected, ~ package

重要程度：⭐⭐ 高频

【知识点28】设计模式 (Design Patterns)

23种GoF设计模式：

  • 创建型(5种)：Factory, Singleton, Builder, Prototype, Abstract Factory
  • 结构型(7种)：Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
  • 行为型(11种)：Observer, Strategy, Command, Template Method, Iterator, State, Chain of Responsibility, Mediator, Memento, Visitor, Interpreter

四个重点模式详解：

  • Factory：封装对象创建逻辑，客户端无需知道具体类名
  • Singleton：确保只有一个实例，提供全局访问点
  • Adapter：将一个接口转换为客户端期望的接口
  • Controller：将系统事件处理分配给协调类

重要程度：⭐⭐⭐ 必考

【知识点29】用户界面设计 (UI Design)

核心概念：

  • 用户界面(UI)：直接涉及人类用户的输入输出
  • 系统界面(SI)：需要最少人工干预的自动化输入输出
  • HCI(人机交互)：研究用户与计算机系统交互效率和效果的学科
  • Visibility(可见性)：控件必须对用户可见
  • Affordance(可供性)：外观应暗示其功能

UI设计七大指南：一致性(Consistency)、快捷键(Shortcuts)、反馈(Feedback)、对话闭合(Dialog Closure)、错误处理(Error Handling with Guidance)、操作可逆(Reversal of Actions)、减轻短期记忆负担(Reduce Short Term Memory Load)

记忆口诀：”一快反闭错撤记”

以用户为中心设计原则：早期关注用户和工作、评估设计确保可用性、使用迭代开发

重要程度：⭐⭐⭐ 必考

【知识点30】V&V (Verification & Validation)

  • Verification(验证)：”Are we building the product right?” — 检查是否正确实现了规格说明（关注过程）
  • Validation(确认)：”Are we building the right product?” — 检查是否满足用户真实需求（关注结果）

SQA(Software Quality Assurance)：软件质量保证。测试只是SQA的一个元素。质量必须内建于开发过程，不能事后用测试来添加。

重要程度：⭐⭐⭐ 必考

【知识点31】测试组织 (Testing Organization)

  • Developer(开发者)：了解系统，但倾向温和测试，被交付驱动
  • ITG(Independent Test Group, 独立测试组)：不了解系统但倾向破坏，被质量驱动

正确做法：开发者做单元测试+集成测试，然后交给ITG。ITG应在分析和设计阶段就参与。

重要程度：⭐⭐ 高频

【知识点32】集成测试策略

  • 大爆炸测试(Big-bang)：所有模块一次性集成。简单但难以定位错误。
  • 自顶向下(Top-down)：从顶层开始，逐步加入底层。**需要Stub(桩模块)**模拟底层。
  • 自底向上(Bottom-up)：从底层开始，逐步加入顶层。**需要Driver(驱动模块)**模拟上层。

Driver：模拟上层模块调用被测模块
Stub：模拟被测模块调用的下层模块

重要程度：⭐⭐⭐ 必考

【知识点33】测试级别

级别 对象 执行者
单元测试(Unit) 单个模块/类 开发者
集成测试(Integration) 模块间接口 开发者+ITG
系统测试(System) 整个系统 ITG
验收测试(Acceptance) 用户需求 用户

回归测试(Regression)：修改后重新测试确保无新错误
冒烟测试(Smoke)：快速检查核心功能是否正常

重要程度：⭐⭐⭐ 必考

【知识点34】系统测试四种类型

类型 目的
恢复测试(Recovery) 测试系统从故障中恢复的能力
安全测试(Security) 测试安全机制的有效性
压力测试(Stress) 测试系统在极限条件下的表现
性能测试(Performance) 测试系统的响应时间和吞吐量

重要程度：⭐⭐ 高频

【知识点35】安装部署方式

方式 定义 优点 缺点
直接安装(Direct) 直接替换旧系统 成本低 风险高
并行安装(Parallel) 新旧系统同时运行 风险低 成本高
分阶段安装(Phased) 逐步替换 平衡风险和成本 时间长

重要程度：⭐⭐ 高频

【知识点36】形式化方法

有穷状态机 FSM (Finite State Machine)

  • 5元组：$(J, K, T, S, F)$
    • J：有穷非空状态集
    • K：有穷非空输入集
    • T：转换函数 $(J-F) \times K \to J$
    • S：初始状态
    • F：终态集
  • 6元组扩展：加入谓词集P

Petri网 (Petri Net)

  • 4元组：$(P, T, I, O)$
    • P：位置集（圆圈）
    • T：转换集（短直线）
    • I：输入函数（位置→转换）
    • O：输出函数（转换→位置）
  • 标记(Marking)：权标(token)分配
  • 激发条件：每个输入位置的权标数 ≥ 该位置到转换的线数
  • 禁止线(Inhibitor arc)：权标为零时转换才能触发

重要程度：⭐⭐ 高频

【知识点37】CRC卡技术

CRC = Class / Responsibility / Collaborator

  • Class：类名
  • Responsibility：该类的职责
  • Collaborator：与该类协作的其他类

重要程度：⭐ 一般

【知识点38】版本管理

SCCS(Source Code Control System)：源代码控制系统

版本类型：Alpha（内部开发测试）、Beta（外部用户测试）、Production（正式发布）、Maintenance（维护修复）

重要程度：⭐ 一般

【知识点39】质量保证评审方法

维度 Walkthrough(走查) Inspection(审查)
正式程度 非正式 正式
参与者 开发团队 跨职能团队
文档记录 简单 详细
效率 较低 较高

重要程度：⭐⭐ 高频

【知识点40】氛围编程 (Vibe Coding)

定义：由Andrej Karpathy（2025年2月）提出的AI辅助编程方式。

流程：自然语言需求→AI生成代码→运行→反馈修改

工具：ChatGPT, Cursor AI, GitHub Copilot

重要程度：⭐ 一般（新知识点）

任务二：考试知识库

选择题考点精选（30道高频）

题1：软件危机中IBM OS/360项目的投资金额为？
A. 1亿美元 B. 5亿美元 C. 10亿美元 D. 5000万美元
答案：B | 干扰项：A太小，C太大

题2：以下哪个不属于敏捷宣言的核心价值观？
A. 个体和交互胜过过程和工具 B. 详细文档胜过工作软件
C. 客户合作胜过合同谈判 D. 响应变化胜过遵循计划
答案：B | 干扰项：正确的是”工作软件胜过文档”

题3：FURPS+中”R”代表什么？
A. Requirements B. Reliability C. Reusability D. Response
答案：B | Reliability可靠性

题4：<<includes>>的箭头方向是？
A. 被包含→主用例 B. 主用例→被包含 C. 双向 D. 无箭头
答案：B | 关键区分点

题5：聚合关系使用的符号是？
A. 实心菱形 B. 空心菱形 C. 实心三角 D. 空心三角
答案：B | 组合是实心菱形

题6：以下哪种内聚最强？
A. 通信内聚 B. 过程内聚 C. 功能内聚 D. 顺序内聚
答案：C | 功能内聚是最高级

题7：以下哪种耦合最弱？
A. 数据耦合 B. 标记耦合 C. 非直接耦合 D. 控制耦合
答案：C | 非直接耦合是最低级

题8：螺旋模型的核心特征是？
A. 迭代开发 B. 风险驱动 C. 原型驱动 D. 文档驱动
答案：B | 风险驱动是螺旋模型最大特点

题9：Verification关注的是什么？
A. 产品是否满足用户需求 B. 产品是否正确实现了规格说明
C. 产品是否通过验收测试 D. 产品是否有好的性能
答案：B | Verification=过程正确性

题10：自顶向下集成测试需要什么？
A. Driver B. Stub C. 两者都需要 D. 两者都不需要
答案：B | 自底向上需要Driver

题11：域模型类图与设计类图的区别是？
A. 域模型有方法 B. 设计类图没有方法 C. 域模型没有方法 D. 两者完全相同
答案：C | 域模型只有属性和关系

题12：XP的提出者是？
A. Booch B. Kent Beck C. Rumbaugh D. Jacobson
答案：B | 1996年提出

题13：以下哪种事件属于时间事件？
A. 顾客下单 B. 月末生成报表 C. 库存低于阈值 D. 用户登录
答案：B | 时间事件=到达时间点触发

题14：以下哪项不是理想技术假设排除的事件？
A. 登录 B. 备份数据库 C. 客户下单 D. 修改密码
答案：C | 客户下单是业务事件，不排除

题15：SSD中*号表示什么？
A. 条件判断 B. 循环/重复 C. 可选 D. 返回值
答案：B | *表示重复

题16：以下哪种安装方式风险最高？
A. 直接安装 B. 并行安装 C. 分阶段安装 D. 灰度安装
答案：A | 直接替换，出问题无法回退

题17：Petri网的4元组是？
A. (J,K,T,S,F) B. (P,T,I,O) C. (C,R,A,L) D. (P,T,I,M)
答案：B | FSM是5元组(J,K,T,S,F)

题18：Walkthrough和Inspection的主要区别是？
A. Walkthrough更正式 B. Inspection更正式 C. 没有区别 D. Walkthrough由用户执行
答案：B | Inspection是正式评审

题19：Controller模式中，请求的正确流向是？
A. UI→Domain→DataAccess B. UI→Controller→Domain→DataAccess
C. Controller→UI→Domain D. Domain→Controller→UI
答案：B | Controller是中间协调者

题20：以下哪个不是设计类的Stereotype？
A. Entity B. Boundary C. Interface D. Control
答案：C | 五种是Entity/Boundary/Control/DataAccess/Persistent

题21：喷泉模型的主要特点是？
A. 线性顺序 B. 风险驱动 C. 对象驱动，阶段重叠 D. 严格文档
答案：C | 面向对象、各阶段重叠

题22：结构化程序设计中严格控制的是什么语句？
A. IF B. WHILE C. GOTO D. RETURN
答案：C | Dijkstra主张消除GOTO

题23：变换型系统结构包含？
A. 事务中心 B. 传入部分→变换中心→传出部分 C. 并行处理 D. 递归调用
答案：B | 事务型包含事务中心

题24：Alpha测试和Beta测试的区别是？
A. Alpha由用户执行 B. Beta在开发环境中执行 C. Alpha在开发环境中执行 D. 没有区别
答案：C | Alpha=开发环境，Beta=真实用户环境

题25：SRP原则的含义是？
A. 一个系统只有一个类 B. 一个类只有一个变化原因 C. 一个方法只做一件事 D. 一个项目只有一个开发者
答案：B | Single Responsibility = 一个变化原因

题26：以下哪个不是系统测试类型？
A. 恢复测试 B. 单元测试 C. 安全测试 D. 压力测试
答案：B | 单元测试是单独的测试级别

题27：需求评审的四个方面不包括？
A. 一致性 B. 完整性 C. 创新性 D. 有效性
答案：C | 四方面：一致性/完整性/现实性/有效性

题28：以下哪个不是CRUD操作？
A. Create B. Replace C. Update D. Delete
答案：B | CRUD = Create/Read/Update/Delete

题29：OOA的全称是？
A. Object-Oriented Architecture B. Object-Oriented Analysis
C. Object-Oriented Application D. Open-Oriented Analysis
答案：B | 面向对象分析

题30：有穷状态机的初始状态用哪个字母表示？
A. J B. K C. S D. F
答案：C | S=初始状态，F=终态集

简答题考点精选（10道，标准答案结构）

简答题1：简述软件危机的主要表现和产生原因。
答题结构：表现5条(每条1分) + 原因6条(每条1分)
关键词：需求不满足、成本超标、质量差、难维护、速度跟不上

简答题2：简述Boehm的七条基本原理。
答题结构：逐条列举(每条1分)
关键词：分阶段计划、阶段评审、产品控制、现代技术、可审查、少而精、不断改进

简答题3：简述敏捷宣言的四大核心价值观。
答题结构：四组对比(每组2分)
关键词：个体交互>过程工具、工作软件>文档、客户合作>谈判、响应变化>计划

简答题4：比较 <<includes>> 和 <<extend>> 的区别。
答题结构：定义(各2分) + 箭头方向(各1分) + 举例(各1分)
关键词：必须执行/可选执行、箭头A→B/箭头B→A

简答题5：解释内聚和耦合的概念及追求”高内聚低耦合”的原因。
答题结构：内聚定义+7级(3分) + 耦合定义+7级(3分) + 原因(2分)
关键词：模块内部紧密度、模块间依赖度、独立性、可维护性、可重用性

简答题6：简述SOLID五大设计原则。
答题结构：每条原则名称+简要解释(每条2分)
关键词：单一职责、开闭、里氏替换、接口隔离、依赖倒置

简答题7：解释Verification和Validation的区别。
答题结构：定义(各3分) + 区别(2分)
关键词：building the product right / building the right product

简答题8：简述三种集成测试策略及其优缺点。
答题结构：三种策略(各3分)
关键词：大爆炸/自顶向下(需Stub)/自底向上(需Driver)

简答题9：简述FURPS+需求分类模型。
答题结构：每个字母含义(各1分) + +号扩展(1分)
关键词：Functional/Usability/Reliability/Performance/Security

简答题10：简述UI设计的七大指南。
答题结构：每条名称+简要解释(每条1分)
关键词：一致性、快捷键、反馈、对话闭合、错误处理、操作可逆、减轻记忆

应用题考点精选（50分重点，详细解题步骤）

应用题类型1：完整需求分析案例（最可能出大题）

  • 典型题目：给定一个业务系统场景，完成完整的需求分析。
  • 解题步骤：识别利益相关者（列出内部/外部等）；事件分解（识别外部/时间/状态事件）；画用例图（画矩形系统边界，椭圆写用例名，小人画参与者，实线连接参与者和用例，标注 <<includes>> 和 <<extend>> 关系）；编写用例描述（选取1-2个用例写完整11字段）；画SSD（Actor→:System的消息序列）。
  • 评分点：用例图(15分) + 用例描述(10分) + SSD(10分) + 分析过程(5分)

应用题类型2：类图绘制与分析

  • 典型题目：给定业务场景，画域模型类图或设计类图。
  • 解题步骤：识别类（名词技术/头脑风暴）；确定属性；确定关系（关联/泛化/聚合/组合）；标注Multiplicity重数；如果是设计类图需添加方法、可见性、Stereotype。
  • 评分点：类识别(5分) + 关系正确(10分) + 重数(5分) + 完整性(5分)

应用题类型3：架构设计分析

  • 典型题目：分析系统架构问题，提出设计方案。
  • 解题步骤：分析当前架构的问题（内聚/耦合分析）；识别违反的设计原则（SOLID）；提出重构方案（三层架构、设计模式）；画重构后的类图/架构图；说明改进效果。
  • 评分点：问题分析(10分) + 方案(10分) + 图(10分) + 说明(5分)

应用题类型4：测试策略设计

  • 典型题目：为给定系统设计测试方案。
  • 解题步骤：确定测试级别（单元/集成/系统/验收）；选择集成策略（自顶向下/自底向上）；设计Driver/Stub；设计测试用例；规划回归测试和冒烟测试。
  • 评分点：测试策略(10分) + 集成方案(10分) + 测试用例(10分)

应用题类型5：状态机图/活动图绘制

  • 典型题目：给定对象生命周期或业务流程，画图。
  • 解题步骤：状态机图（确定所有状态→确定转换→添加保护条件和行动表达→检查复合状态和并行路径）；活动图（确定起止节点→识别活动→添加判断→添加Fork/Join→连接）。
  • 评分点：状态/活动识别(5分) + 转换/连接正确(10分) + 保护条件(5分) + 完整性(5分)

任务三：软件工程模型详细整理

瀑布模型 (Waterfall Model)

定义：线性顺序的软件开发模型，各阶段按顺序执行，前一阶段完成后才进入下一阶段。

原理：基于工程方法，假设需求可以在早期完整确定。

生命周期流程：需求分析 → 系统设计 → 详细设计 → 编码 → 测试 → 部署维护（每个阶段有验证和确认环节）。

优缺点与适用场景：

  • 优点：原理简单易掌握，便于质量管理和项目跟踪，适合结构化方法。
  • 缺点：缺乏灵活性，不能适应需求变化，回溯性差，用户很晚才能看到产品。
  • 适用项目：需求明确且稳定、技术风险低、大型正规项目。

快速原型模型 (Rapid Prototyping)

定义：通过快速构建可运行的原型系统来理解和确认需求。

优缺点与适用场景：

  • 优点：增强交流、及早发现问题、降低风险。
  • 缺点：缺乏工具支持、原型可能被误当最终产品、难以彻底测试。
  • 适用：需求不明确的交互式系统。

增量模型 (Incremental Model)

定义：以组件为单位分批交付软件，可看作重复执行的多个瀑布模型。

优缺点与适用场景：

  • 优点：分批交付，用户及早使用，降低开发风险，灵活调整开发顺序。
  • 缺点：总体需求定义困难，体系结构必须开放，每次增量必须可测试。
  • 适用：需求可分优先级、需要分批交付的大型系统。

螺旋模型 (Spiral Model) ⭐⭐⭐

定义：结合瀑布和原型，强调风险分析的迭代模型。

原理：风险驱动(Risk-driven)

生命周期流程（每轮四象限）：计划(Planning) → 风险分析(Risk Analysis) → 工程(Engineering) → 客户评估(Customer Evaluation)

优缺点与适用场景：

  • 优点：风险驱动、灵活、适合大型项目。
  • 缺点：成本高、需要风险评估经验、不适合小项目。
  • 适用：大型、复杂、高风险的系统。

喷泉模型 (Fountain Model)

定义：面向对象的开发模型，各阶段相互重叠。

五大特点：阶段重叠（并行性）；分析阶段消耗资源最多；返回低层无资源消耗；”分析一点、设计一点”；对象驱动。

V模型 (V-Model)

定义：瀑布模型的扩展，强调测试与开发阶段的对应关系。

对应关系：需求分析↔验收测试；系统设计↔系统测试；详细设计↔集成测试；编码↔单元测试。

RUP (Rational Unified Process)

定义：Rational公司推出的完整软件过程框架。

六大最佳实践：迭代式开发、管理需求、基于构件的体系结构、可视化建模(UML)、验证软件质量、控制变更。

四个阶段：初始(Inception)→细化(Elaboration)→构建(Construction)→交付(Transition)。

敏捷开发 (Agile Development)

定义：2001年17位专家联合发布敏捷宣言。

四大价值观：

  1. 个体和交互 > 过程和工具
  2. 可以工作的软件 > 面面俱到的文档
  3. 客户合作 > 合同谈判
  4. 响应变化 > 遵循计划

XP 极限编程 (Extreme Programming)

提出者：Kent Beck, 1996年

十大核心实践：以人为本、简单设计、结对编程(Pair Programming)、持续集成(Continuous Integration)、短周期迭代(1-2周)、代码重构(Refactoring)、测试驱动开发(TDD)、现场客户(On-site Customer)、可持续的开发速度、开放的工作环境。

Scrum

定义：一种敏捷框架，使用固定时间盒(Sprint)进行迭代开发。

三个角色：Product Owner, Scrum Master, Development Team
五个事件：Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
三个工件：Product Backlog, Sprint Backlog, Increment

模型对比总表

模型 核心特征 适用场景 最大优点 最大缺点
瀑布 线性顺序 需求明确 简单规范 不灵活
原型 快速验证 需求不清 及早确认需求 原型被误用
增量 分批交付 大型系统 降低风险 架构设计难
螺旋 风险驱动 高风险大型 风险管理 成本高
喷泉 对象驱动 OO项目 阶段重叠 管理复杂
V模型 测试对应 质量要求高 测试前置 仍线性
RUP 最佳实践 大型团队 完整框架 学习成本高
敏捷 响应变化 需求变化大 快速交付 文档不足
XP 工程实践 小型团队 TDD/结对 难规模化
Scrum 管理框架 产品开发 透明度高 依赖团队

任务四：需求工程详细整理

需求获取 (Requirements Elicitation)

六种方法：

方法 流程 优点 缺点 适用场景
访谈 准备→讨论→记录→跟进 深入、灵活 耗时、主观 关键利益相关者
问卷 设计→发放→收集→分析 大范围、标准化 回收率低、不深入 大量用户
文档审查 收集→阅读→提取→整理 客观、系统 可能过时 现有系统分析
观察 选择→观察→记录→分析 真实、直接 霍桑效应 业务流程
供应商研究 搜索→评估→比较 技术先进 可能不适用 技术方案
用户反馈 收集→分类→分析 实时、有价值 零散 活跃用户

需求分析 (Requirements Analysis)

功能需求：系统必须做什么（业务功能）

非功能需求：约束条件和性能目标。包括可用性(Usability)、可靠性(Reliability)、性能(Performance)、安全性(Security)，以及设计限制、开发约束、接口要求、物理要求、支持要求等。

需求建模与验证

三种模型类型：文本模型(Textual)、图形模型(Graphical)、数学模型(Mathematical)。

需求验证四个方面：一致性（不矛盾）、完整性（包含所有）、现实性（可实现）、有效性（正确有效）。

优先级三级：Essential(必要) > Important(重要) > Nice to have(锦上添花)。

任务五：软件设计详细整理

模块化 (Modularity)

定义：将系统分解为可独立开发和测试的模块。

数学根据：$C(x_1+x_2) > C(x_1) + C(x_2)$，即整体复杂性大于部分之和，所以分解可降低复杂性。

原则：模块规模适度，既不太大（难维护）也不太小（接口太多）。

抽象与信息隐藏

过程抽象：用高级概念描述操作（如”排序”而非具体代码）
数据抽象：用高级概念描述数据结构（如”栈”而非数组实现）
信息隐藏：每个模块的实现细节对其他模块不可见。降低耦合、提高独立性。

软件体系结构与设计启发规则

常见架构风格：分层架构(Layered)、管道-过滤器(Pipe-Filter)、客户端-服务器(Client-Server)、事件驱动(Event-Driven)、MVC(Model-View-Controller)。

设计启发规则：模块规模适度；深度、宽度、扇出、扇入适度；作用域应在控制域之内；降低接口复杂程度；单入口单出口；模块功能可预测。

任务六：UML图详细整理

用例图 (Use Case Diagram)

用途：记录系统功能需求和用户交互。
关系：<<includes>>(包含)、<<extend>>(扩展)、Generalization(泛化)。
常见错误：includes/extend箭头方向搞反；Actor之间画关联线；用例之间画普通连线。

类图 (Class Diagram)

用途：描述系统静态结构。
关系类型：关联、聚合(空心菱形)、组合(实心菱形)、泛化(空心三角)、依赖(虚线箭头)。

活动图 (Activity Diagram)

用途：描述业务流程和工作流。
绘制规则：Fork和Join必须成对出现；判断后必须有多个分支。

顺序图 / SSD (Sequence Diagram / SSD)

用途：描述对象间的消息交互顺序。
SSD特殊规则：只有Actor和:System两个生命线。
消息符号：实线=输入消息、虚线=返回消息、*=循环、[condition]=条件。

状态机图与通信图

状态机图：描述对象的生命周期状态变化。转换格式为 触发器[保护条件]/行动表达。
通信图：描述对象间的关系和消息传递（强调结构而非时间）。

任务七：软件测试详细整理

测试层次

  • 单元测试 (Unit Testing)：测试单个模块/类的正确性（开发者，白盒为主）。
  • 集成测试 (Integration Testing)：测试模块间的接口和交互（大爆炸/自顶向下/自底向上）。
  • 系统测试 (System Testing)：测试整个系统的功能和非功能特性（恢复/安全/压力/性能测试）。
  • 验收测试 (Acceptance Testing)：用户确认系统是否满足需求（Alpha/Beta）。
  • 回归测试 (Regression Testing)：修改后重新测试确保没有引入新错误。
  • 冒烟测试 (Smoke Testing)：快速检查核心功能是否正常工作的初步测试。

测试方法与调试策略

白盒测试：知道内部结构，测试代码逻辑路径（语句覆盖、分支覆盖等）。
黑盒测试：不知道内部结构，测试功能和输出（等价类划分、边界值分析等）。

调试策略：蛮力法(Brute Force)、回溯法(Backtracking)、原因排除法(Cause Elimination)、归纳法(Induction)。

任务八：软件项目管理

  • 项目计划：立项分析阶段确定项目愿景文档。
  • 项目估算：专家判断、类比估算、参数模型(COCOMO)。
  • 风险管理：螺旋模型核心，流程包含识别→评估→制定策略→监控。
  • 配置管理：SCCS控制源代码版本。包含 Alpha/Beta/Production/Maintenance 版本。
  • 质量管理：SQA 包含 Walkthrough（非正式）和 Inspection（正式）。质量必须内建于开发过程。
  • 进度管理：甘特图(Gantt Chart)、PERT图、关键路径法(CPM)。

任务九：必考知识点 Top 30

排名 知识点 为什么容易考 常见题型
1 用例图绘制（含includes/extend） 应用题核心，综合考察需求分析能力 应用题(画图)
2 完全开发的用例描述（11字段） 考察需求文档化能力 应用题
3 内聚七级/耦合七级 设计质量核心指标，易混淆 选择+简答
4 SOLID五大原则 设计原则核心 选择+简答+应用
5 瀑布vs增量vs螺旋模型对比 模型选择是基本能力 选择+简答+应用
6 敏捷宣言四价值观+XP实践 当前主流方法论 选择+简答
7 三层架构（View/Domain/DataAccess） 架构设计核心 选择+简答+应用
8 V&V（验证与确认） 概念容易混淆 选择+简答
9 集成测试策略（Big-bang/Top-down/Bottom-up） Driver/Stub是经典考点 选择+简答+应用
10 类图关系（关联/聚合/组合/泛化） 类图是OO设计核心工具 选择+应用(画图)
11 SSD系统顺序图 从需求到设计的桥梁 应用题(画图)
12 状态机图 对象生命周期建模 应用题(画图)
13 活动图 业务流程建模 应用题(画图)
14 FURPS+需求分类 需求分析基础 选择+简答
15 功能需求vs非功能需求 基本概念区分 选择
16 Boehm七条原理 软件工程基础 简答
17 软件危机（表现+原因） 历史背景必知 简答
18 三种事件类型（外部/时间/状态） 用例识别基础 选择+应用
19 设计模式（Factory/Singleton/Adapter/Controller） 设计能力考察 选择+应用
20 域模型类图vs设计类图 分析与设计的区别 选择+应用(画图)
21 UI设计七大指南 界面设计核心 简答+应用
22 DFD数据流图 结构化分析核心工具 应用题(画图)
23 SRS需求规格说明书 需求文档化标准 简答
24 测试级别（单元/集成/系统/验收） 测试体系框架 选择+简答
25 系统测试四种类型 非功能测试 选择+简答
26 CRC卡技术 设计工具 选择+应用
27 安装方式（直接/并行/分阶段） 部署策略 选择+简答
28 Walkthrough vs Inspection 质量保证方法 选择+简答
29 有穷状态机/Petri网 形式化方法 选择+简答
30 CRUD技术 需求验证工具 选择+应用

任务十：预测考题

预测选择题考点（30道）

基础概念类（10道）

  1. 软件三个组成部分 → 程序+数据+文档
  2. 软件工程诞生时间和人物 → 1968, NATO, Fritz Bauer
  3. Boehm原理的数量 → 七条
  4. 软件危机案例（IBM OS/360的投资额） → 5亿美元
  5. 敏捷宣言提出年份 → 2001年
  6. XP提出者和年份 → Kent Beck, 1996
  7. FURPS+中各字母含义
  8. CRUD各字母含义
  9. EBP的定义
  10. SSD中消息符号(*、[]等)

模型与方法类（10道）
11. 螺旋模型核心特征 → 风险驱动
12. 喷泉模型特点 → 对象驱动、阶段重叠
13. 瀑布模型属于什么方法 → 预测性方法
14. 结构化程序设计控制GOTO → Dijkstra
15. Bohm和Jacopini证明年份 → 1966
16. 三种基本控制结构 → 顺序/选择/循环
17. 变换型vs事务型系统结构
18. RUP的六个最佳实践数量
19. Scrum的Sprint持续时间 → 通常2-4周
20. 预测性vs适应性SDLC

设计与测试类（10道）
21. 内聚最高级别 → 功能内聚
22. 耦合最低级别 → 非直接耦合
23. 聚合vs组合的符号区别
24. SOLID中OCP的含义 → 开闭原则
25. 三层架构的中间层 → Domain/业务逻辑层
26. Driver vs Stub的区别
27. 自顶向下集成需要什么 → Stub
28. Alpha测试在哪里执行 → 开发环境
29. 域模型类图有没有方法 → 没有
30. Verification关注什么 → 过程正确性

预测简答题考点（10道）

  1. 软件危机的表现和原因
  2. Boehm七条基本原理
  3. 敏捷宣言四大价值观
  4. 三种集成测试策略对比
  5. V&V的区别
  6. <<includes>> 和 <<extend>> 的区别
  7. 内聚和耦合的概念及原则
  8. FURPS+需求分类模型
  9. UI设计七大指南
  10. 三种安装部署方式对比

预测应用题考点（10道，50分重点）

应用题1：在线购物系统需求分析

  • 解题步骤：识别角色→事件分解→画用例图(含includes/extend)→写用例描述→画SSD。
  • 容易失分：includes/extend箭头方向搞反；遗漏异常条件；SSD消息格式不规范。

应用题2：图书馆管理系统类图设计

  • 解题步骤：识别类→确定属性→确定关系(关联/聚合/组合/泛化)→标注Multiplicity。
  • 容易失分：聚合和组合分不清；重数标注错误。

应用题3：订单处理系统架构重构

  • 解题步骤：分析当前问题(内聚/耦合)→识别违反的SOLID原则→提出三层架构重构方案→画重构后类图。
  • 容易失分：不能准确识别违反的设计原则；重构方案不具体。

应用题4：学生选课系统测试方案设计

  • 解题步骤：确定测试级别→选择集成策略→设计Driver/Stub→设计测试用例→规划回归测试。
  • 容易失分：Driver/Stub使用场景搞混。

应用题5：电梯控制系统状态机图

  • 解题步骤：确定所有状态→确定转换→添加保护条件和行动表达。
  • 容易失分：遗漏状态；保护条件描述不准确。

应用题6：医院预约系统活动图

  • 解题步骤：确定起止→识别活动→添加判断→添加Fork/Join→连接。
  • 容易失分：Fork/Join不成对；判断菱形后缺少分支。

应用题7：银行系统安全测试方案

  • 解题步骤：确定系统测试类型(恢复/安全/压力/性能)→为每种类型设计测试用例。
  • 容易失分：混淆系统测试和验收测试。

应用题8：电商系统UI设计评审

  • 解题步骤：对照七大指南逐项检查→指出违反的原则→提出改进建议。
  • 容易失分：不能将UI问题对应到具体原则。

应用题9：保险理赔系统形式化建模

  • 解题步骤：用有穷状态机5元组建模或用Petri网4元组建模。
  • 容易失分：5元组各分量定义不准确。

应用题10：企业ERP系统开发模型选择

  • 解题步骤：分析项目特点→对比候选模型→选择最佳模型→说明理由。
  • 容易失分：只说优点不说缺点；不结合项目特点分析。

附录：关键人物与年份速查表

人物 贡献 年份
Edsger Dijkstra GOTO Statement Considered Harmful 1968
Edsger Dijkstra 结构程序设计概念 1965
Fritz Bauer 首次提出”软件工程” 1968(NATO)
Boehm 软件工程七条原理 -
Bohm & Jacopini 证明三种控制结构可实现任何程序 1966
E. Yourdon 结构化分析方法(SA) 1970s
Kent Beck 极限编程(XP) 1996
17位专家 敏捷宣言 2001
Andrej Karpathy 氛围编程(Vibe Coding) 2025
Carl Adam Petri Petri网 -
Nassi & Shneideman N-S图(盒图) -

附录：完整缩写对照表

缩写 英文全称 中文翻译
SDLC System Development Life Cycle 系统开发生命周期
UML Unified Modeling Language 统一建模语言
OOA Object-Oriented Analysis 面向对象分析
OOD Object-Oriented Design 面向对象设计
OOP Object-Oriented Programming 面向对象编程
SA Structured Analysis 结构化分析
SD Structured Design 结构化设计
SP Structured Programming 结构化程序设计
DFD Data Flow Diagram 数据流图
DD Data Dictionary 数据词典
SRS Software Requirements Specification 软件需求规格说明书
SC Structured Chart 结构图
PAD Problem Analysis Diagram 问题分析图
N-S Nassi-Shneideman N-S图/盒图
IPO Input Process Output 输入-加工-输出
FURPS+ Functional,Usability,Reliability,Performance,Security+ 需求分类法
EBP Elementary Business Process 基本业务流程
CRUD Create, Read, Update, Delete 增删改查
SSD System Sequence Diagram 系统顺序图
HCI Human-Computer Interaction 人机交互
SQA Software Quality Assurance 软件质量保证
ITG Independent Test Group 独立测试组
SCCS Source Code Control System 源代码控制系统
RUP Rational Unified Process Rational统一过程
XP Extreme Programming 极限编程
TDD Test-Driven Development 测试驱动开发
SRP Single Responsibility Principle 单一职责原则
OCP Open-Closed Principle 开闭原则
LSP Liskov Substitution Principle 里氏替换原则
ISP Interface Segregation Principle 接口隔离原则
DIP Dependency Inversion Principle 依赖倒置原则
LoD Law of Demeter 迪米特法则
FSM Finite State Machine 有穷状态机
NATO North Atlantic Treaty Organization 北大西洋公约组织
CACM Communications of the ACM ACM通讯
ERD Entity Relationship Diagram 实体关系图
API Application Programming Interface 应用程序接口
CSS Control Specification Statement 控制规范声明
SaaS Software as a Service 软件即服务
GoF Gang of Four 四人帮(设计模式作者)
MVC Model-View-Controller 模型-视图-控制器