第一章
第二章
瀑布模型是什么，优缺点是什么，适用场景是什么，特点是什么？
瀑布模型是一种线性顺序的软件开发模型，阶段依次为：需求 → 设计 → 编码 → 测试 → 部署 → 维护。
特点：阶段分明、文档驱动、流程不可逆（或极少回溯）。
优点：**结构清晰，易于管理；**文档齐全，适合规范项目；适用于需求明确稳定的项目。
缺点：**难以应对需求变更；**风险后置（问题到测试阶段才暴露）；缺乏灵活性和用户早期反馈。
适用场景：**需求明确且稳定；**技术成熟、风险低；如军工、金融等强监管领域的小型或中型项目。
需求工程中的三个主要活动？
1.需求抽取与分析 2.需求规格说明 3.需求确认
信息系统设计过程中可能包含的四个过程？
软件确认：（验证和确认，测试+确认）
软件演化3个阶段：1.开发 2.发布 3.用户测试
应对变化：变化增加了软件开发的成本，意味着已经完成的工作必须重做，称为返工
**原型：**原型是软件开发中快速构建的简化可运行模型，用于展示功能或界面。
作用：
- 帮助明确和验证用户需求；
- 减少误解，获取早期反馈；
- 降低开发风险，促进沟通。
**适用情况：**需求不明确、用户参与度高或交互复杂的项目。
**增量交付：**增量交付是将软件分多个小版本逐步开发和交付，每个版本都包含可运行的新功能。
优势：
- 用户早期就能使用部分功能；
- 便于及时反馈和调整需求；
- 降低开发风险，提升灵活性；
- 更快获得投资回报。
第三章
为什么出现敏捷开发？
因为传统开发（如瀑布模型）难以应对需求频繁变化、交付周期长和用户反馈滞后等问题，敏捷开发应运而生，强调快速响应变化、持续交付可用软件、紧密协作和客户参与。
敏捷开发的宣言和原则？
敏捷开发技术（极限编程）？
四个敏捷/极限编程（XP）核心实践的简述：
1.用户故事（User Story）
从用户角度描述系统功能的简短需求说明，通常格式为："作为一个[角色]，我希望[功能]，以便[价值]。"用户故事强调业务价值、简洁性和可沟通性，是需求分析和迭代计划的基础。
2.重构（Refactoring）
在不改变软件外部行为的前提下，对代码内部结构进行优化，以提高可读性、可维护性和可扩展性。重构是持续改进代码质量的关键实践，需配合自动化测试以确保安全性。
3.测试先行（Test-First / Test-Driven Development, TDD）
先编写失败的单元测试，再编写刚好使其通过的最小实现代码，最后重构。这一"红-绿-重构"循环确保代码始终有测试覆盖，并驱动设计演进，提升代码可靠性与可测试性。
4.结对编程（Pair Programming）
两名开发者共用一台计算机，一人编写代码（驾驶员），另一人实时审查（观察员），角色定期轮换。该实践促进知识共享、减少缺陷、提升代码质量和团队协作效率。
第四章
软件需求简述：
- **做什么：**明确系统应具备的功能、性能、约束和用户期望，回答"系统要做什么"。
- **作用：**作为开发、测试和验收的依据，减少误解与返工，控制项目范围，提升交付质量。
- **目标：**确保开发出的软件真正满足用户和业务的实际需要。
用户需求，系统需求的概念？
用户需求：从用户或业务角度描述的高层次需求，说明用户"想要什么"或"要解决什么问题"。通常用自然语言、用户故事或用例表达，关注业务价值和使用场景。
示例： "用户能通过手机快速下单。"
系统需求：对软件系统具体行为、功能、性能、接口等的详细、技术性描述，说明系统"必须做什么"才能满足用户需求。通常可被开发和测试直接使用。
示例： "系统应在3秒内响应订单提交请求，并支持每秒1000个并发用户。"
功能性需求，非功能性需求？
功能性需求：描述系统必须提供的具体功能或行为，即"系统能做什么"。
例如： 用户登录、订单支付、数据导出等。
非功能性需求：描述系统运行时的质量属性或约束条件，即"系统做得怎么样"。
例如： 性能（响应时间 ≤ 2秒）、安全性（支持HTTPS）、可用性（99.9% uptime）
关键区别：功能性需求关乎"功能"，非功能性需求关乎"质量"。两者共同决定系统是否满足用户期望。
故事和场景的简单区别
故事（User Story）是从用户角度简要描述"想要什么"和"为什么"，用于表达需求和沟通，例如"作为一个用户，我希望能重置密码，以便在忘记密码时恢复账户"；
场景（Scenario）是描述用户与系统在特定条件下交互的具体步骤和流程，用于说明"怎么用"，例如"用户点击'忘记密码'，输入邮箱，收到链接，设置新密码并成功登录"。
简单说，故事讲"要什么"，场景讲"怎么用"。
需求确认：需求确认非常重要，如果需求文档中的错误在开发过程中或在系统投入服务后被发现，会导致广泛的返工开销
需求变更为什么会出现，出现在什么阶段？
需求变更常因用户初期需求不清、业务或技术环境变化、干系人调整或发现原需求问题而出现。
它可能发生在开发任何阶段------需求、设计、编码、测试或上线后，
变更内容包括功能增删改、性能安全等非功能要求，或平台法规等约束条件。
第五章
UML建模（活动图，用例图，顺序图，状态图，类图）
第六章
体系结构设计的概念？
体系结构设计是确定软件系统的整体结构，包括主要组件、它们之间的关系以及交互方式，为后续详细设计和开发提供蓝图。
体系结构视图的概念？
体系结构视图是从不同角度（如逻辑、开发、部署、运行等）描述软件系统结构的简化表示，帮助不同角色（如开发者、运维、用户）理解系统的某一方面。
体系结构模式MVC三层架构
分层体系结构的使用场景，优缺点？
分层体系结构将系统划分为多个水平层次每层只与相邻层交互，常用于企业应用和Web系统等需要清晰职责划分的场景 。其优点是结构清晰、易于开发维护 ，有利于团队协作；缺点是层间调用可能带来性能开销，严格分层会降低灵活性，不适合高并发或实时性要求高的系统。
知识库体系结构的使用场景，优缺点？
知识库体系结构适用于需要基于大量规则、事实或专家知识进行推理和决策的系统 ，如专家系统、智能客服、诊断工具等。其优点是能有效组织和利用领域知识 ，支持灵活的知识更新与推理，便于解释决策过程；**缺点是知识获取困难（"知识工程瓶颈"），维护成本高，**且在面对模糊、不确定或动态变化的问题时适应性较差。
管道和过滤器体系结构，使用场景，优缺点？
管道和过滤器体系结构将系统组织为一系列按顺序处理数据的组件（过滤器），通过管道连接，前一个过滤器的输出作为下一个的输入。它常用于数据流处理场景，如编译器、日志处理 、ETL工具、音视频处理等。优点是结构清晰、组件松耦合 、易于复用和并行化；缺点是不适合需要复杂交互或反馈控制的数据处理，且在高吞吐或低延迟要求下可能因多次数据传递带来性能开销。
应用体系结构的意义和作用？
应用体系结构定义了软件系统的整体组织和关键设计决策，明确了组件、模块、交互方式和技术选型。其意义在于为开发提供统一蓝图，确保系统满足功能与非功能需求 ；作用包括指导开发实现、提升可维护性与可扩展性、促进团队协作、降低技术风险，并为后续演进和集成奠定基础。
第七章
高内聚，低耦合？
高内聚指模块内部各元素紧密围绕单一功能，职责集中 ；低耦合指模块之间依赖少、接口简单、相互影响小。二者共同提升软件的可读性、可维护性、可复用性和可扩展性。
6个设计原型
- 设计模型，表示系统中包含的对象或对象类，同时也描述了实体间的关联与关系。
- 结构模型：通过系统对象类及其之间的关系来描述系统的静态结构。
- 动态模型：描述系统的动态结构和系统对象之间的交互。
- 子系统模型：给出对象的逻辑分组即子系统，子系统之间存在的联系
- 时序模型：说明对象交互的序列
- 状态机模型：说明单个对象如何响应事件来改变它们的状态
设计模式的分类：
1.创建型模式------关注对象的创建，如单例、工厂方法、抽象工厂、建造者、原型；
2.结构型模式------处理类或对象的组合，如适配器、代理、外观、组合、桥接、享元；
3.行为型模式------描述对象间的职责分配与通信，如策略、观察者、责任链、迭代器等。
第八章
确认和验证？
验证（Verification） 是检查软件是否"做得正确"，即开发过程是否符合规格和设计要求，关注过程正确性，例如代码是否实现设计。
确认（Validation） 是检查软件是否"做了正确的事"，即最终产品是否满足用户真实需求和预期用途，关注结果有效性，例如系统是否解决了用户问题。
简言之：验证看"是否按图施工"，确认看"图纸是否对"。
审查和测试：
审查是通过人工检查（如代码走查、设计评审）发现缺陷，关注过程和文档的正确性；测试是通过运行程序输入数据并观察输出，验证软件行为是否符合预期。审查偏静态、早介入，测试偏动态、重执行，两者互补，共同保障软件质量。
与测试相比，软件审查有三大优势：
一是不运行系统，避免错误相互掩盖，能更全面地发现缺陷；二是可在系统不完整时进行，无需额外测试环境，节省成本；三是不仅能查错，还能评估代码的可维护性、可移植性等质量属性，提升整体软件质量。
单元测试，构件测试，系统测试的概念？
单元测试是对软件中最小可测试单元（如函数或类方法）进行检查，验证其逻辑是否正确；
构件测试（也称集成测试或组件测试）是测试多个单元组合成的模块或构件，关注接口和交互是否正常；
系统测试是在完整集成的系统上进行，验证整个系统是否符合需求规格，包括功能、性能、安全性等。
第九章
为什么出现软件演化，概念？
软件演化是指软件系统在交付后不断被修改、扩展和优化的过程 。它出现是因为用户需求会随时间变化，业务环境和技术平台持续更新，系统需修复缺陷、提升性能或适应新场景。简言之，软件必须"与时俱进"才能保持可用性和价值，因此演化是软件生命周期中的必然阶段。
演化过程
软件演化过程是指软件在发布后持续经历修改、扩展、优化和维护的迭代周期，通常包括：识别变更需求（如新功能、缺陷修复）、分析影响、修改代码、回归测试、版本发布等步骤，并可能伴随重构、架构调整或技术升级。该过程反复进行，使软件逐步适应变化的用户需求、运行环境和技术条件，保持其可用性、可靠性和竞争力。
遗留系统的概念，对演化有什么作用？
遗留系统是指仍在使用但技术陈旧、文档缺失、难以维护或基于过时平台的老系统。
对演化的作用具有两面性：
-
因结构僵化、耦合度高、缺乏测试等限制，阻碍新功能快速开发和系统升级
-
因其承载关键业务，常需通过重构、封装、逐步替换（如绞杀者模式）等方式进行渐进式演化，成为软件演化的重点对象和驱动力。