📖 第一章 软件工程概述

1.1 软件的定义与特点

定义：软件是计算机系统中与硬件相互依存的部分，它包括程序（可执行代码）、数据（程序运行所必需的信息）及其相关文档（描述、设计、使用手册）的完整集合。它不仅仅是代码，更是一个逻辑实体。

核心特点：

抽象性：软件是逻辑产品，缺乏物理形态，其开发过程本质上是逻辑思维与设计的过程。

可复制性：软件可以被无限次完美复制，生产成本极低，但开发成本极高。

不可退化性：软件不会像硬件一样“磨损”或老化。但软件退化表现为：随着运行环境变化和需求变更，它会变得低效、难以维护。

依赖性：软件依赖于特定的硬件和系统环境。

演化性：软件在其生命周期中需要持续修改以适应变化，这是软件维护工作量巨大的根源。

1.2 软件危机与软件工程的诞生

软件危机的表现（20世纪60-70年代）：

预算与进度失控：项目严重超支、延期。

产品质量低劣：软件漏洞多，可靠性差。

可维护性差：代码混乱如“意大利面条”，难以修改和升级。

用户不满意：最终产品与用户需求不符。

软件工程的定义：

为了应对软件危机而诞生的学科。它是一门将系统化、规范化、可量化的工程原理和方法应用于软件的开发、运行和维护全过程的学科。其核心目标是：在给定的预算和时间内，生产出高质量的、满足用户需求的软件产品。

1.3 软件生命周期模型（⭐ 考试重点，必考对比分析）

软件生命周期模型（过程模型）定义了从概念到废弃的整个过程中，软件开发活动的组织方式。

软件生命周期模型（过程模型）定义了从概念到废弃的整个过程中，软件开发活动的组织方式。

1. 瀑布模型

• 描述：将开发过程划分为需求分析、设计、编码、测试、维护等固定顺序的阶段，如同瀑布流水，逐级下落。

• 优点：阶段清晰，文档驱动，易于管理。

• 缺点：无法适应需求变更，风险延迟至后期才发现，用户直到末期才能看到产品。

• 适用场景：需求极其明确、稳定的项目（如航天控制系统、银行核心系统升级）。

  

2. 原型模型

• 描述：快速构建一个可运行的简化版（原型），让用户试用并反馈，据此反复修改原型，逐步明确需求，最终在原型基础上开发正式产品或抛弃原型重新开发。

• 优点：有效解决需求不明确的问题，用户参与度高。

• 缺点：可能导致“凑合”心理，原型设计不佳可能影响系统架构。

• 适用场景：需求模糊、用户界面复杂的系统（如新型网站、APP）。

  

3. 迭代与增量模型

• 描述：将整个项目划分为一系列小型的、可交付的增量。每个迭代周期（如2-6周）都经历一个完整的迷你开发流程（分析、设计、编码、测试），并产生一个可运行的软件版本。功能是逐步累加的。

• 优点：早期交付部分功能，降低风险，易于适应变更。

• 缺点：需要良好的架构设计来支持增量集成。

• 适用场景：大型项目，需求可分段。

  

4. 螺旋模型

• 描述：结合了瀑布的系统和原型的迭代，并加入了风险分析作为核心驱动。每个螺旋周期包括：制定目标、风险分析、工程实现（开发原型或正式版本）、用户评审。

• 优点：强调风险驱动，适合高风险大型项目。

• 缺点：复杂，需要丰富的风险评估经验，成本高。

• 适用场景：高风险、大规模的内部项目（如国防、大型企业软件）。

  

5. 敏捷模型（⭐ 近年高频考点）

• 角色：产品负责人（定义需求优先级）、Scrum Master（流程教练）、开发团队。

• 工件：产品待办列表（所有需求）、冲刺待办列表（当前迭代要完成的需求）。

• 活动：冲刺规划会（计划2-4周的迭代）、每日站会（15分钟同步）、冲刺评审会（演示成果）、冲刺回顾会（团队改进）。

• 核心理念：拥抱变化，快速响应。强调个体与互动、可工作的软件、客户合作高于流程和工具、文档、合同谈判。

• 典型代表 – Scrum框架：

• 优点：高度灵活，交付快，客户满意度高。

• 缺点：对团队成员自律性和沟通能力要求极高，文档相对少。

• 适用场景：需求多变、创新性强的项目（互联网产品、创业公司项目）。

  

---

🧩 第二章 需求工程

2.1 需求分类

功能需求：描述系统“必须做什么”。例如：“用户必须能够通过ISBN号搜索图书。”

非功能需求：描述系统“运行得怎么样”，是全局性约束。

领域需求：来自应用领域的特殊规则或约束。例如：“在医疗软件中，所有操作必须符合HIPAA法案。”

2.2 需求获取方法

访谈（一对一/一对多）：深入但耗时。

问卷：面向大量用户，成本低，但设计难度大。

原型法：最直观有效，尤其适合界面需求。

观察：观察用户现有工作流程，发现隐性需求。

文档分析：分析现有系统的文档、报表、政策。

2.3 需求分析建模（⭐ 重点，常考画图）

用图形化模型清晰表达需求，消除歧义。

用例图：从用户（参与者）角度描述系统功能。

活动图：描述业务或操作的工作流程。

数据流图（DFD）：描述系统中数据的流动、处理和存储，独立于具体技术。

---

🏗 第三章 软件设计（⭐ 核心与难点）

3.1 设计原则：SOLID原则（⭐ 必背，常考简答）

单一职责原则：一个类只应有一个引起它变化的原因。即，一个类只负责一项职责。

开放-封闭原则：软件实体（类、模块、函数）应该对扩展开放，对修改关闭。即，通过增加新代码来增加新功能，而非修改已有代码。

里氏替换原则：子类型必须能够替换掉它们的父类型，而不影响程序的正确性。

接口隔离原则：不应该强迫客户依赖于它们不用的方法。使用多个专门的接口，好于使用一个庞大臃肿的总接口。

依赖倒置原则：

3.2 设计模式（⭐ 掌握几种经典模式的意图和结构）

定义：对软件设计中普遍存在、反复出现的问题，所提出的通用、可复用的解决方案。

单例模式：保证一个类仅有一个实例，并提供一个全局访问点。常用于数据库连接池、配置管理器。

工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。将对象的创建与使用分离。

观察者模式：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。常用于事件处理系统、MVC中的模型-视图关系。

3.3 软件体系结构风格

分层架构：将系统划分为若干层（如表现层、业务逻辑层、数据访问层），每层只依赖于下一层。优点：高内聚、低耦合，易于维护和复用。

客户端-服务器架构：资源或服务由服务器集中管理，多个客户端请求服务。典型：Web应用、数据库系统。

模型-视图-控制器（MVC）：

3.4 UML设计图（⭐ 常考读图与简单绘图）

类图（静态结构）：展示系统的静态结构，包括类、接口、关联、继承、聚合/组合关系。是面向对象设计的核心。

时序图（动态行为）：强调消息的时间顺序，展示对象之间如何交互以完成一个特定用例。

状态图：描述一个对象在其生命周期内，响应外部事件时，其状态的变迁。适合具有复杂状态行为的对象（如订单：待支付、已支付、已发货、已完成）。

组件图：描述系统的物理结构，展示软件组件（如可执行文件、库、源代码文件）之间的依赖关系。

---

💻 第四章 实现与测试

4.1 编码与代码复审

编码规范：统一命名、格式、注释风格，提高代码可读性和可维护性。是现代软件工程的底线要求。

代码复审：同行评审代码，旨在早期发现缺陷，分享知识，保证代码质量。形式包括：结对编程、走查、正式审查会议。

4.2 测试的级别（V模型）

单元测试：针对最小的软件设计单元（如函数、类）进行测试。通常由开发者自己完成，使用框架（如JUnit）。

集成测试：将多个单元模块组合起来进行测试，重点是模块间的接口和交互是否正确。

系统测试：在完整的、集成的系统上执行测试，以验证系统是否满足所有需求（功能和非功能）。

验收测试：由用户或客户执行，以确认系统是否满足合同要求，决定是否接收产品。

4.3 测试技术（⭐ 重点，常考设计用例或计算）

黑盒测试：不关心内部结构，只根据输入和输出规格说明设计测试用例。

等价类划分：将输入域划分为若干子集（等价类），从每个子集中选取一个代表性数据作为测试用例。例如，输入“年龄”的有效类是[1, 150]，无效类是( -∞, 0]和[151, +∞)。

边界值分析：取边界值和刚刚超出边界的值作为测试用例。因为错误常发生在边界。例如，对于[1, 150]，测试0, 1, 2, 149, 150, 151。

白盒测试（结构测试）：基于程序的内部逻辑结构设计测试用例。

语句覆盖：使程序中每条可执行语句至少执行一次。覆盖率最低。

分支覆盖（判定覆盖）：使程序中每个判定的真、假分支至少各执行一次。

路径覆盖：使程序中所有可能的执行路径至少执行一次。覆盖率最高，但通常难以实现。

4.4 调试与测试工具

调试：定位并修复已发现缺陷的过程。方法：断点、单步执行、变量监视、日志分析。

工具：

单元测试：JUnit (Java), pytest (Python)

Web UI自动化：Selenium

API测试：Postman

性能测试：JMeter

---

🔄 第五章 维护与演化

5.1 软件维护的类型

改正性维护：修复在测试阶段未发现的缺陷或错误。约占20%。

适应性维护：为使软件适应变化的外部环境（如新操作系统、新硬件、新数据库）而进行的修改。约占25%。

完善性维护：为扩展功能、改善性能或可维护性而进行的修改。这是最主要的维护活动，约占50%以上。

预防性维护：为了提高软件未来的可维护性和可靠性而进行的修改，通常是对代码进行重构。

5.2 软件重构与再工程

重构：在不改变软件外部可观察行为的前提下，调整其内部结构，改善代码质量（如消除重复、简化条件逻辑、提高可读性）。是持续进行的“代码清理”。

再工程：对遗留系统进行全面或部分的重新开发、逆向工程和改造，以提升其可维护性、性能或架构。这是一个工程活动，目标是延长系统寿命。

5.3 配置管理与版本控制（Git）

核心概念：管理软件在生命周期内各种版本的标识、变更和控制。

Git：分布式版本控制系统。

---

📊 第六章 项目管理

6.1 软件项目估算

专家判断法：依赖专家经验。

类比估算法：参考类似历史项目的成本。

参数估算法 – COCOMO模型：使用基于代码行数和一系列成本驱动因子（人员能力、产品复杂度等）的公式进行估算。常考基本COCOMO公式：Effort = a * (KLOC)^b（人月），其中a和b是系数，KLOC是千行代码数。

6.2 项目进度安排（⭐ 常考关键路径计算）

甘特图：条形图，直观展示任务、开始/结束时间、持续时间及重叠关系。优点：直观；缺点：不显示任务间的逻辑依赖。

PERT图（网络图）：用节点表示任务，箭头表示依赖关系。关键路径是图中从开始到结束，路径长度（总持续时间）最长的路径。它决定了项目的最短工期，关键路径上任何任务延误都会导致整个项目延误。

6.3 风险管理

风险识别：列出可能的风险（技术、人员、组织、需求变更等）。

风险分析：评估风险发生的概率和影响。

风险规划：制定应对策略（规避、转移、缓解、接受）。

风险监控：持续跟踪已识别风险，识别新风险。

6.4 敏捷项目管理（Scrum实践细节）

产品待办列表：一个按优先级排序的需求列表，是产品的唯一需求来源。

冲刺：一个固定时长（通常2-4周）的迭代周期，期间团队完成一组承诺的需求。

每日站会：15分钟内，每个成员回答三个问题：昨天做了什么？今天计划做什么？遇到什么障碍？

冲刺评审会：在冲刺结束时，向产品负责人和其他干系人演示完成的工作，获取反馈。

冲刺回顾会：团队内部会议，总结本次冲刺在流程和人方面的优缺点，制定改进计划。

---

更多优质内容，持续输出中~

新书发售👇

听说你也是做数据的？👇