一. 概述

什么是软件、软件危机、软件工程

软件是可执行的指令（程序）、操作信息的数据以及描述程序操作和使用的文档的集合。

软件危机指软件开发速度跟不上需求增长，导致设计拙劣、维护困难，可能造成经济损失或灾难。

软件工程是1968年NATO会议提出的概念，旨在解决软件危机。

软工的目标

软件工程通过系统化、规范、可量化的方法指导软件开发、运行和维护，以解决软件危机，确保软件质量。

软工的三层结构：过程、工具和方法

层次	定义	主要内容	作用
过程（Process）	支持软件生命周期（SLC）的所有活动，为开发、运行、维护提供框架。	- 阶段：问题定义、可行性分析、需求分析、设计、编码、测试、验收、维护、废弃 - 主要活动：沟通、策划、建模、构建、部署 - 保护伞活动：项目跟踪、测量、技术评审、质量保证、风险管理、配置管理、可复用管理	定义活动顺序、任务分配和里程碑，确保项目有序推进。
方法（Methods）	提供“如何做”的技术指导，具体解决每个阶段的技术问题。	- 经典方法：结构化分析、设计、实现 - 面向对象方法：基于对象建模，映射问题域 - 面向方面方法：处理系统性关注点 - 基于构件方法：组装已有构件 - 基于知识的软件工程：运用AI和知识工程	提供技术路线和最佳实践，确保实现符合需求和质量标准。
工具（Tools）	提供自动化或半自动化支持，提升开发效率和质量。	- CASE工具：支持开发、维护、管理 - 重点工具：UML（统一建模语言） - 其他工具：IDE、测试工具、配置管理工具等	简化重复性工作，规范开发流程，减少人为错误。

层次

定义

主要内容

作用

过程（Process）

支持软件生命周期（SLC）的所有活动，为开发、运行、维护提供框架。

- 阶段：问题定义、可行性分析、需求分析、设计、编码、测试、验收、维护、废弃

- 主要活动：沟通、策划、建模、构建、部署

- 保护伞活动：项目跟踪、测量、技术评审、质量保证、风险管理、配置管理、可复用管理

定义活动顺序、任务分配和里程碑，确保项目有序推进。

方法（Methods）

提供“如何做”的技术指导，具体解决每个阶段的技术问题。

- 经典方法：结构化分析、设计、实现

- 面向对象方法：基于对象建模，映射问题域

- 面向方面方法：处理系统性关注点

- 基于构件方法：组装已有构件

- 基于知识的软件工程：运用AI和知识工程

提供技术路线和最佳实践，确保实现符合需求和质量标准。

工具（Tools）

提供自动化或半自动化支持，提升开发效率和质量。

- CASE工具：支持开发、维护、管理

- 重点工具：UML（统一建模语言）

- 其他工具：IDE、测试工具、配置管理工具等

简化重复性工作，规范开发流程，减少人为错误。

常用的过程模型：瀑布、增量、螺旋、快速原型等

模型	定义	特点	优点	缺点	适用场景
瀑布模型	按阶段顺序开发，线性推进。	阶段明确，需文档和评审。	管理简单，适合需求稳定。	需求不清晰易出错，成果交付晚。	需求明确的小型项目。
增量模型	分步交付功能，逐步完善。	每次增量加功能，可并行开发。	早期交付，灵活，客户可反馈。	集成复杂，需求变更成本高。	需快速交付的中大型项目。
螺旋模型	迭代开发，结合风险评估。	每轮迭代有原型，强调风险管理。	适合高风险，减少失败概率。	成本高，管理复杂。	高风险的大型项目。
快速原型	快速建原型验证需求后开发。	抛弃型或演化型原型，与客户交互。	验证需求，减少误解。	原型成本高，可能设计不佳。	需求模糊的项目。
统一过程（RUP）	用例驱动，迭代增量开发。	架构为中心，强调质量和最佳实践。	灵活，适合复杂项目。	实施复杂，需经验团队。	需高质量架构的大型项目。

二. 项目计划 & 七. 项目管理

度量和估算

概述

度量：用数字量化软件开发过程、产品或资源的特性，为管理和改进提供基础（Lord Kelvin：用数字表达了解程度）。
估算：预测开发所需资源（如时间、人力、成本），基于经验、历史数据和模型，需接受不确定性。

度量与估算核心内容（表格）

类别	定义与内容	方法与公式	作用与特点
面向规模的度量	基于代码行（Loc/Kloc）衡量软件规模及相关指标。	- 指标：每千行代码错误数、成本、文档页数；每人月错误数、代码行、文档成本。	- 简单直观，易于统计。 - 受语言差异影响，难以比较不同项目。
面向功能的度量	基于功能点（FP）衡量软件功能复杂度。	- 公式：FP = CT × (0.65 + 0.01 × ΣFi) - CT：用户输入、输出、查询、文件、外部接口数 - Fi：14项调整因子（如备份、数据通信）	- 聚焦功能，独立于语言。 - 需经验判断调整因子，计算复杂。
软件质量度量	评估软件质量属性（如功能性、可靠性）。	- 模型：McCall（层级质量属性）、Boehm（高层/中层/原始属性）、ISO/IEC 9126（已由ISO/IEC 25010:2011取代）。	- 提供质量评估标准。 - 需结合具体项目需求选择模型。
估算方法	预测资源需求的多种技术，结合经验和数据。	- 基于类似项目：参考历史项目。 - 分解技术：按活动/功能/模块划分，定义最好/最坏情况。 - 经验模型：如CoCoMO、Putnam。 - 其他：德尔菲法、敏捷估算。	- 提高资源分配准确性。 - 需经验、历史数据和勇气，接受不确定性。
分解技术	将项目分解为小单元估算（如过程活动、功能模块）。	- 定义最好/最坏情况。 - 三点估算：EV = (Sopt + 4Sm + Spess) / 6（乐观值、可能值、悲观值）。	- 细化估算，降低误差。 - 需清晰分解结构。
经验模型	使用数学模型估算工作量和时间。	- 形式：E = A + B × (ev)^C（E：工作量，ev：估算变量）。 - Putnam方程：E = (Loc^3 × B) / (P^3 × t^4)（B：技术因子，P：生产率，t：持续时间）。 - CoCoMO ：E = aKLOC^b，D = cE^d（基本/中级/高级模型）。	- 提供定量预测。 - 依赖参数准确性，需校准。
资源金字塔	估算开发所需资源，层次分明。	- 底层：硬件/软件工具（基础支持）。 - 中层：可复用软件资源（降低成本、提早交付）。 - 顶层：人员（主要资源）。	- 明确资源优先级。 - 强调人员关键性，复用资源可显著优化。

配置管理

📌 一、定义与作用

配置管理：对软件开发过程中的所有可交付成果进行标识、控制、审计和记录的活动。
作用：确保变更可控、版本可追溯、文档一致性，提高质量与效率。

📌 二、四大活动（考试高频）

配置项标识：确定需要管理的对象并赋予唯一编号。
变更控制：所有变更必须经过审批（如CR审批）。
配置状态记录：记录每个配置项的状态和版本演变。
配置审计：验证配置项的完整性和一致性。

📌 三、重要术语

配置项（SCI）：需要管理的项目，如源代码、设计文档、测试用例等。
基线（Baseline）：经批准冻结的配置项快照，只能通过变更控制修改。
版本（Version）：某一配置项的一个具体实例。
修订（Revision）：对同一项的局部小修改。
变更请求（CR）：正式申请变更的文档或记录。

📌 四、配置管理工具

Git：分布式管理，主流代码版本控制工具。
SVN：集中式管理，适合文档或传统项目。
GitHub/GitLab：托管平台，支持协作和持续集成。

📌 五、基线类型

需求基线：冻结需求版本。
设计基线：冻结设计方案。
代码基线：冻结开发阶段的代码版本。
测试基线：冻结测试方案和测试结果。

📌 六、配置管理的价值

避免版本混乱，支持并行开发。
保证交付内容的一致性、完整性、可追踪性。
是质量保证、项目管理不可或缺的一部分。

软件质量保证

软件质量是软件满足明确和隐含需求的程度。

软件质量保证是保证软件过程和产品质量的系统活动。

SQA贯穿软件生命周期的所有阶段。

SQA的目标是预防缺陷，而不是仅仅发现缺陷。

SQA确保开发过程遵循标准和规范。

质量计划包含质量目标、标准和审核流程。

过程审计监督软件开发是否按计划执行。

技术审查评审需求、设计、代码等成果。

测试管理组织各类测试并跟踪缺陷。

缺陷管理确保缺陷被及时记录、修复和验证。

质量度量用数据支持质量管理和决策。

McCall质量模型包含功能性、可靠性、效率、可维护性等。

Boehm模型分高层、中层和底层质量属性。

ISO/IEC 9126定义功能性、可靠性、易用性等六大质量特性。

ISO/IEC 25010是9126的更新版本。

FURPS+模型包括功能、易用性、可靠性、性能和支持性。

质量保证活动贯穿需求、设计、编码、测试和交付阶段。

需求阶段重点评审需求完整性和一致性。

设计阶段重点评审设计和接口合理性。

编码阶段进行代码检查和规范审查。

测试阶段进行测试计划制定和执行。

交付阶段审查文档和用户手册。

质量保证关注过程，质量控制关注产品结果。

审核检查是否遵守流程，评审评价项目成果。

验证确认产品是否符合设计要求。

确认验证产品是否满足用户需求。

认证

认证是第三方确认产品或服务符合规定标准和规范的过程。

软件认证分为产品质量认证和质量体系认证两大类。

产品质量认证：确认软件产品符合特定技术和质量标准。

质量体系认证：确认软件开发企业的质量管理体系符合标准要求。

常见的国际标准认证有ISO 9001（质量管理体系认证）。

软件能力成熟度模型（CMM/CMMI）常用于评估软件过程能力和成熟度。

认证能够提高软件的市场竞争力和用户信任度。

认证过程通常包括审核、评审、测试和现场检查。

获得认证的产品或组织会得到证书或标志作为合格证明。

认证是软件质量保证的重要组成部分，促进标准化和规范化。

认证可以帮助发现和改进软件开发过程中的缺陷和不足。

认证过程应保持客观、公正和透明。

敏捷

敏捷开发强调快速响应变化，而非严格遵循计划。

敏捷开发的核心是人和交互高于流程和工具。

敏捷开发重视工作的软件高于详尽文档。

强调客户合作胜过合同谈判。

敏捷宣言提出响应变化胜过遵循计划。

敏捷方法不是固定流程，而是一种灵活的开发态度和原则。

敏捷适合需求不稳定、快速变化的项目环境。

常见敏捷方法有**极限编程（XP）、Scrum、看板（Kanban）、透明水晶（Crystal）**等。

敏捷团队强调自组织和跨职能协作。

敏捷开发通过迭代和增量交付软件产品。

每次迭代结束要交付可工作的软件。

持续集成和持续测试是敏捷的重要实践。

敏捷团队通过每日站会快速沟通和调整。

敏捷鼓励持续反馈和持续改进。

敏捷开发强调团队成员间的开放沟通和信任。

三. 需求分析

什么是需求

需求是用户对软件系统功能、性能和约束的描述。

需求体现了用户期望系统实现的目标和行为。

需求是软件开发的基础，决定系统的设计和实现。

需求分为功能需求和非功能需求。

功能需求描述系统应具备的具体功能和服务。

非功能需求包括性能、安全性、可靠性、可维护性等质量属性。

需求应是完整、准确、一致、可验证和可追踪的。

需求来源包括用户、市场调研、法律法规、业务流程等。

需求分析的目标是明确、细化和规范需求。

不良需求会导致项目失败或返工，需求管理非常重要。

需求工程分了哪几个阶段

需求获取（Elicitation）
- 收集用户、客户和相关方的需求信息。
- 通过访谈、问卷、观察、头脑风暴等方法。
需求分析（Analysis）
- 对获取的需求进行分类、整理、澄清和矛盾分析。
- 明确需求的优先级和范围。
需求规格说明（Specification）
- 将需求以书面形式规范化描述，形成需求规格说明书（SRS）。
- 要求需求清晰、完整、一致且可验证。
需求验证（Validation）
- 确认需求文档满足用户真实需求。
- 通过评审、走查、原型演示等方式。
需求管理（Management）
- 控制需求变更，维护需求的版本和追踪。
- 保障需求的可追踪性和一致性。

如何获取需求

访谈（Interview）
- 与用户、客户或利益相关者面对面交流，了解需求。
- 结构化、半结构化或非结构化访谈。
问卷调查（Questionnaire/Survey）
- 设计有针对性的问题，收集大量用户反馈。
- 适合用户分布广泛或人数多的场景。
观察（Observation）
- 直接观察用户的工作流程和操作行为，发现隐含需求。
- 可以是现场观察或录像分析。
头脑风暴（Brainstorming）
- 团队成员集体讨论，激发创意，收集多种需求想法。
文档分析（Document Analysis）
- 审查现有系统文档、业务流程、法规标准等资料。
原型法（Prototyping）
- 制作简单模型或样品，帮助用户更直观表达需求。
用例法（Use Case）
- 通过描述系统如何与用户交互，明确功能需求。
需求研讨会（Workshops）
- 组织多方代表集中讨论、协商，达成共识。
竞争对手分析
- 研究类似产品，发现潜在需求和改进点。

结构化需求分析常用的模型：数据流图、实体关系图

数据流图（DFD, Data Flow Diagram）
- 描述系统的数据流动、处理过程和数据存储。
- 用来分析系统功能和信息流。
- 包含外部实体、过程、数据流和数据存储四要素。
实体关系图（ERD, Entity-Relationship Diagram）
- 描述系统中的实体、属性和实体间的关系。
- 用于数据建模和数据库设计。
状态转换图（State Transition Diagram）
- 描述系统或对象状态的变化及触发事件。
- 用于分析系统动态行为。
过程说明书（Process Specification）
- 对数据流图中的处理过程进行详细说明。
结构化英语（Structured English）
- 用类似程序语言的形式描述处理逻辑。
决策表（Decision Table）
- 用表格形式表示复杂的逻辑判断和对应操作。
决策树（Decision Tree）
- 用树状图形表示决策路径和结果。

需求分析文档的编制

定义：需求分析文档（SRS，Software Requirement Specification）是对系统需求的详细书面描述。
目的：明确系统功能和性能需求，为后续设计和开发提供依据。
结构一般包括：
- 引言（目的、范围、定义、参考资料）
- 总体描述（产品视角、功能概述、用户特征、约束条件）
- 具体需求（功能需求、性能需求、安全需求等）
- 其他需求（接口需求、硬件需求、软件质量属性）
编写步骤：
- 收集和整理需求信息
- 需求分类和分析
- 规范化需求描述，避免歧义
- 审核和确认需求
编写原则：
- 语言简洁明了，避免模糊表达
- 需求应完整、一致、可验证
- 使用图表（如用例图、数据流图）辅助说明
常用工具：Word、Excel、UML建模工具等。
审核与版本控制：确保文档准确无误，并做好版本管理，方便追踪修改。
文档维护：需求变更时及时更新文档，保持与实际开发同步。

四. 设计

一些设计概念：抽象、求精、模块化、信息隐藏、内聚和耦合等

抽象（Abstraction）
- 抓住事物的本质特征，忽略非本质细节。
- 通过抽象，简化复杂系统，便于理解和设计。
求精（Refinement）
- 逐步细化设计，层层展开细节。
- 从高层抽象逐步向具体实现过渡。
模块化（Modularity）
- 将系统划分为独立且功能明确的模块。
- 便于开发、测试和维护。
信息隐藏（Information Hiding）
- 隐藏模块内部实现细节，仅通过接口与外界交互。
- 降低模块间依赖，提升系统稳定性。
内聚（Cohesion）
- 模块内部元素之间的关联程度。
- 高内聚表示模块职责单一且紧密，设计优良。
耦合（Coupling）
- 模块之间的依赖关系。
- 低耦合意味着模块间依赖少，系统更灵活易维护。

架构设计风格

分层架构（Layered Architecture）
- 系统划分为多个层，每层只与相邻层交互。
- 常见层有表示层、业务逻辑层和数据访问层。
- 优点：高内聚、低耦合，便于维护和扩展。
客户端-服务器架构（Client-Server）
- 客户端请求服务，服务器响应请求。
- 支持多客户端共享服务器资源。
事件驱动架构（Event-Driven Architecture）
- 通过事件触发和响应，解耦组件之间的关系。
- 适合异步通信和实时系统。
微内核架构（Microkernel Architecture）
- 核心系统功能最小化，通过插件扩展额外功能。
- 常用于操作系统和可扩展产品。
微服务架构（Microservices Architecture）
- 将系统拆分为多个小型、独立的服务，每个服务完成特定功能。
- 支持独立部署和扩展。
管道-过滤器架构（Pipe and Filter）
- 系统由一系列处理过滤器组成，数据通过管道流动。
- 适合数据流处理系统。
共享数据架构（Shared Data Architecture）
- 组件通过共享数据库或数据存储进行交互。
服务导向架构（SOA，Service-Oriented Architecture）
- 系统由多个服务组成，服务通过标准协议通信。
- 强调服务的松耦合和重用。

详细设计的内容：用户界面设计、接口设计、数据设计、过程与算法设计等

用户界面设计（User Interface Design）
- 设计软件系统的人机交互界面。
- 包括界面布局、导航方式、交互元素（按钮、菜单等）、视觉风格和用户体验。
- 目标是提升用户的操作效率和满意度。
接口设计（Interface Design）
- 设计模块之间、系统与外部系统之间的交互方式。
- 包括接口的调用规范、数据格式、传输协议等。
- 确保模块间通信准确、高效、可靠。
数据设计（Data Design）
- 设计系统的数据结构和数据库方案。
- 包括数据模型、数据存储方式、数据访问接口。
- 重点保证数据的一致性、完整性和安全性。
过程与算法设计（Process and Algorithm Design）
- 设计实现功能的具体过程和算法逻辑。
- 关注算法的正确性、效率和可维护性。
- 通过流程图、伪代码等形式描述。

设计原则

单一职责原则（SRP）
- 一个类只负责一项职责。
- 有助于降低复杂度和提高可维护性。
开闭原则（OCP）
- 软件实体应对扩展开放，对修改关闭。
- 通过抽象和继承实现扩展而不修改原代码。
里氏替换原则（LSP）
- 子类对象必须能替换父类对象，且功能正确。
- 保证继承体系的正确性。
依赖倒置原则（DIP）
- 高层模块不依赖低层模块，两者都依赖抽象。
- 抽象不依赖细节，细节依赖抽象。
接口隔离原则（ISP）
- 客户端不应依赖它不需要的接口。
- 拆分大接口为多个专门接口。
迪米特法则（LoD，最少知识原则）
- 一个对象应尽量少了解其他对象的内部细节。

设计模式

创建型模式（Creational Patterns）
- 关注对象创建的机制，常见有：
- 单例模式（Singleton）：保证一个类只有一个实例。
- 工厂模式（Factory）：通过工厂类创建对象，解耦实例化过程。
- 抽象工厂（Abstract Factory）：创建相关或依赖对象的家族。
- 建造者模式（Builder）：分步骤创建复杂对象。
- 原型模式（Prototype）：通过复制已有对象创建新对象。
结构型模式（Structural Patterns）
- 关注类和对象的组合，常见有：
- 适配器模式（Adapter）：转换接口，使不兼容接口协同工作。
- 装饰器模式（Decorator）：动态增加对象功能。
- 代理模式（Proxy）：为对象提供代理控制访问。
- 外观模式（Facade）：为子系统提供统一接口。
- 组合模式（Composite）：将对象组合成树形结构。
- 桥接模式（Bridge）：分离抽象和实现。
行为型模式（Behavioral Patterns）
- 关注对象间的通信，常见有：
- 观察者模式（Observer）：对象间一对多依赖。
- 策略模式（Strategy）：定义一系列算法，互换使用。
- 责任链模式（Chain of Responsibility）：请求沿链传递。
- 命令模式（Command）：将请求封装成对象。
- 状态模式（State）：对象行为随状态变化而改变。
- 迭代器模式（Iterator）：顺序访问集合元素。

五. OOAD & UML

用例图

类图

交互图（顺序图和通信图）

状态机图（也包括活动图）

六. 实现

编码风格

命名规范
- 变量、函数、类名应具有描述性，易于理解。
- 遵循驼峰命名法（camelCase）或下划线命名法（snake_case），保持一致。
缩进和排版
- 统一使用空格或制表符缩进，一般推荐4个空格。
- 合理分段，代码块清晰，增强可读性。
注释规范
- 重要逻辑、复杂算法、接口说明必须注释。
- 注释应简洁明了，避免多余和重复。
代码简洁
- 避免冗余代码，保持代码简洁、清晰。
- 避免深层嵌套，提升代码可维护性。
一致性
- 代码风格在整个项目中保持一致。
- 团队应制定并遵守统一的编码规范。
错误处理
- 合理处理异常和错误，避免程序崩溃。
- 使用统一的错误处理机制。
避免魔法数字和硬编码
- 使用常量定义代替魔法数字，增强代码可读性。
代码复用
- 避免重复代码，提取公共函数或模块。

测试的目标

发现缺陷
- 通过测试找出软件中的错误和缺陷。
验证和确认需求
- 确保软件满足用户需求和规格说明。
提高软件质量
- 发现问题及时修正，提升软件的稳定性和可靠性。
评估软件性能
- 评估系统的响应时间、吞吐量和资源利用等性能指标。
保证软件符合设计
- 确保实现与设计一致。
减少维护成本
- 通过及早发现缺陷，降低后期维护难度和成本。

测试的原则

测试表明存在缺陷
- 测试只能发现缺陷，不能证明软件无缺陷。
穷尽所有测试是不可能的
- 不能测试所有输入组合，只能有针对性地选择测试用例。
早期测试
- 尽早开始测试活动，尽早发现缺陷。
缺陷聚集原则
- 少数模块含有多数缺陷，测试应重点关注高风险区域。
杀虫剂悖论
- 重复相同的测试会失去效果，测试用例需要不断更新。
测试应独立于开发
- 测试人员应保持一定独立性，确保测试客观性。
缺陷的严重性不同
- 测试应优先发现和解决严重缺陷。
测试环境应尽量接近真实环境
- 模拟真实运行环境以提高测试效果。

测试的过程

测试计划（Test Planning）
- 明确测试目标、范围、资源、时间安排和测试方法。
- 制定测试策略和风险评估。
测试设计（Test Design）
- 分析需求规格，设计测试用例和测试数据。
- 确定测试环境和测试工具。
测试准备（Test Preparation）
- 搭建测试环境，准备测试数据和测试脚本。
- 确认测试资源到位。
测试执行（Test Execution）
- 按测试用例执行测试，记录测试结果。
- 发现缺陷及时反馈给开发人员。
缺陷跟踪（Defect Tracking）
- 记录缺陷信息，跟踪缺陷的修复状态。
- 验证缺陷修复情况。
测试评估与报告（Test Evaluation and Reporting）
- 分析测试结果，评估软件质量和测试覆盖率。
- 编写测试报告，向相关人员汇报。
测试总结与改进（Test Summary and Improvement）
- 总结测试经验和教训，提出改进建议。
- 更新测试文档和测试用例库。

常用的测试方法：等价类划分、边界值分析、独立路径等

等价类划分（Equivalence Partitioning）
- 把所有可能的输入划分成若干等价类。
- 认为每个等价类中的输入测试效果相同，选择其中一个代表进行测试。
- 目的是减少测试用例数量，提高测试效率。
边界值分析（Boundary Value Analysis）
- 重点测试输入域的边界值及其邻近值。
- 因为错误多出现在边界处。
- 包括上边界、下边界及其内外侧的测试值。
独立路径测试（Independent Path Testing）
- 基于程序控制流图，设计测试用例覆盖所有独立路径。
- 独立路径是指包含至少一条未被其他路径覆盖的边。
- 确保代码中所有可能的执行路径都被测试。