当前位置：首页 > news >正文

软考-系统架构设计师软件工程详细讲解

news 2025/9/16 8:16:04

个人博客：blogs.wurp.top

一、软件工程核心思想与生命周期

1. 软件工程的定义与目标

定义：软件工程是将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护的过程，即对上述方法的研究。
核心思想：用工程化的方法管理软件开发，以解决“软件危机”所带来的质量、成本和进度失控问题。
目标：在给定的时间和成本下，生产出具有正确性、可靠性、可维护性、可移植性、高可用性等质量属性的软件产品。

2. 软件生命周期 (Software Life Cycle)

指软件从产生到废弃的全过程。最常见的划分是如下六个阶段：

可行性分析与计划：确定项目是否值得做，技术上是否可行，并制定初步计划。
需求分析：准确确定系统“做什么”，产出《需求规格说明书》。这是架构设计的直接输入，至关重要。
设计阶段：分为概要设计（架构设计，确定系统整体结构、模块划分）和详细设计（模块内部算法、数据结构设计）。这是架构师的核心工作。
编码实现：将设计转换为程序代码。
测试：发现并纠正软件中的缺陷，包括单元测试、集成测试、系统测试、验收测试。
运行与维护：软件交付后的所有活动，包括改正性、适应性、完善性和预防性维护。

二、软件开发模型（过程模型）(软考极高频率考点)

这是组织软件生命周期各个阶段的方式，是软考必考内容。

1. 瀑布模型 (Waterfall Model)

特点：线性顺序、阶段间具有顺序性和依赖性。前一阶段的工作完成后，才能开始后一阶段。
优点：文档驱动、流程清晰、易于管理。
缺点：缺乏灵活性、风险滞后（到测试阶段才发现需求问题代价巨大）、客户无法早期看到产品。
适用场景：需求明确、稳定的项目，如军工、航天等传统领域。

2. 原型模型 (Prototyping Model)

特点：快速构建一个简化版（原型）给用户演示，获取反馈，逐步明确需求，最终开发正式产品。
优点：有助于解决需求不明确的问题，用户参与度高。
缺点：原型可能被误用作正式产品，导致设计粗糙。
适用场景：需求不明确、模糊的项目。

3. 增量模型与迭代模型

增量模型：分块开发、分块交付。每个增量都是一个可操作的产品。如：先做核心功能V1.0，再做功能A V1.1，再做功能B V1.2。
迭代模型：反复 refining。每一次迭代都完成一个完整的开发循环（需求-设计-编码-测试），每次迭代都产生一个可运行的版本，功能由少到多，系统由简到精。RUP（统一过程） 是典型的迭代模型。
区别：增量是加法（一块块增加）；迭代是升级（一遍遍 refine）。

4. 螺旋模型 (Spiral Model)

特点：结合了瀑布模型的系统性和原型模型的风险分析。每个迭代周期都包含四个象限：制定计划、风险分析、实施工程、客户评估。
优点：强调风险分析，最适合大型、高风险项目。
缺点：风险分析需要专门技术，成本高。
适用场景：规模庞大、复杂度高、风险大的项目。

5. 敏捷开发 (Agile Development) - 现代主流

核心价值观：基于《敏捷宣言》，强调个体与交互、可工作的软件、客户合作、响应变化高于流程和工具、文档、合同谈判、遵循计划。
特点：轻文档、重交流、小步快跑、持续交付。
主要实践：
- Scrum：最流行的敏捷框架。核心角色：产品负责人（PO）、Scrum Master、开发团队。核心工件：产品Backlog、Sprint Backlog、增量产品。核心事件：Sprint计划会、每日站会、Sprint评审会、Sprint回顾会。
- XP（极限编程）：强调工程实践，如测试驱动开发（TDD）、结对编程、持续集成、重构。
适用场景：需求多变、需要快速适应市场的互联网项目。

6. DevOps

核心思想：Development（开发） 和Operations（运维） 的一体化。是一种文化和实践的集合，旨在通过自动化软件交付和基础设施变更流程，来缩短开发周期，提高部署频率，更可靠地发布软件。
关键实践：持续集成（CI）、持续交付/部署（CD）、基础设施即代码（IaC）、自动化监控。
与敏捷的关系：敏捷解决的是“开发-测试”之间的墙，DevOps解决的是“开发-运维”之间的墙。

三、软件需求工程

这是架构设计的起点，输入错误，满盘皆输。

需求层次：
- 业务需求：反映组织或客户的高层级目标。
- 用户需求：用户期望系统能够帮助他完成什么任务。
- 功能需求：系统应该提供的功能或服务。
- 非功能需求：架构师最应关注的，是系统运行的约束和品质标准。包括：
  - 性能：响应时间、吞吐量。
  - 安全性：数据保密、防攻击。
  - 可靠性：平均无故障时间（MTBF）。
  - 可用性：平均修复时间（MTTR），系统可用率。
  - 可维护性：易于修改和扩展。
  - 可移植性：跨平台能力。
需求获取技术：访谈、问卷调查、原型法、观察等。
需求分析模型：
- 结构化分析：数据流图（DFD）、数据字典、实体关系图（ERD）、状态转换图（STD）。
- 面向对象分析（OOA）：用例图（描述系统功能）、类图（描述系统静态结构）、活动图、序列图（描述对象间交互）。

四、软件设计工程（架构师核心领域）

1. 设计基本原则 - SOLID 原则（面向对象设计）

S - 单一职责原则：一个类只负责一项职责。
O - 开闭原则：对扩展开放，对修改关闭。
L - 里氏替换原则：子类必须能够替换其父类。
I - 接口隔离原则：使用多个专门的接口，而不是一个庞大臃肿的总接口。
D - 依赖倒置原则：依赖于抽象（接口），而不是具体实现。

2. 结构化设计 vs. 面向对象设计 (OOD)

结构化设计：采用自顶向下、逐步求精的方法，将系统分解为若干功能模块。核心是模块化，强调高内聚、低耦合。
面向对象设计 (OOD)：将系统看作一系列相互作用的对象。核心是运用封装、继承、多态等机制。常用UML图（类图、序列图、组件图、部署图）进行设计表达。

3. 软件测试

测试级别：
- 单元测试：测试单个模块或类。通常由开发人员采用白盒测试方法完成。
- 集成测试：测试模块之间的接口。策略有一次性集成、自顶向下、自底向上、三明治集成等。
- 系统测试：在真实环境下测试整个系统，验证非功能需求（性能、安全、压力、恢复测试等）。
- 验收测试：由用户执行，确认系统是否满足合同要求。
测试方法：
- 白盒测试：清楚内部逻辑，针对代码结构设计测试用例（逻辑覆盖、路径覆盖）。
- 黑盒测试：不考虑内部实现，只针对功能设计测试用例（等价类划分、边界值分析、因果图）。

五、软件质量与维护

软件质量模型：ISO/IEC 25010标准定义了功能性、可靠性、易用性、效率、可维护性、可移植性等质量特性。
软件维护类型：
- 改正性维护：修复错误。
- 适应性维护：使软件适应外部环境变化（如操作系统升级）。
- 完善性维护：扩充功能或改善性能。
- 预防性维护：为未来的可维护性和可靠性做修改。
软件过程改进模型 - CMMI（能力成熟度模型集成）：
- 衡量一个组织软件开发过程成熟度的标准。
- 5个等级：1. 初始级 -> 2. 已管理级 -> 3. 已定义级 -> 4. 量化管理级 -> 5. 优化级。
- 目标是帮助组织改进其软件开发过程。

六、软考考点总结与应用

选择题：
- 直接考查各种开发模型的特点、优缺点和适用场景（瀑布 vs. 原型 vs. 螺旋 vs. 敏捷）。
- 考查需求层次和非功能需求的类型。
- 考查设计原则（如SOLID）、测试方法（黑盒白盒）、维护类型。
- 考查CMMI的等级特征。
案例分析题：
- 题目描述一个项目陷入困境（如需求频繁变更、延期、质量差）。
- 问题1：分析项目存在的问题及原因。（如：需求不明确却用了瀑布模型；缺乏沟通；没有测试流程）。
- 问题2：请提出改进建议。（答题套路：1. 建议采用敏捷开发模式应对变化；2. 加强需求管理，建立需求变更控制流程；3. 引入持续集成和自动化测试；4. 加强配置管理）。
- 问题3：作为架构师，如何提取非功能需求并指导设计？（答：与利益相关者沟通，明确性能、安全等指标，并将其作为架构设计的约束条件）。
论文题：
- 可能围绕“论敏捷开发在某某项目中的应用”、“软件架构设计与软件质量保证”、“论软件开发过程改进”等主题。
- 写作时，必须结合一个具体项目，详细论述你如何运用软件工程的方法论：
  - 如何选择开发模型及其原因。
  - 如何进行需求分析，特别是非功能需求的分析。
  - 如何将设计原则（如高内聚低耦合、SOLID）应用到架构设计中。
  - 如何组织测试和重构来保证质量。
  - 过程中的经验和教训。