1.软件过程模型（重要）

1.1.瀑布模型

1. 只适合需求明确的项目
2. 严格串行化，很长时间才能看到结果。
3. 严格区分阶段，每个阶段因果紧密相连，且要求每个阶段一次性解决该阶段的任务

1.2.原型模型（构造简易模型确定需求）

1. 适合需求不明确的项目
2. 分为原型开发阶段和目标软件开发阶段
3. 原型开发阶段分为：需求分析，软件设计，程序设计

1.3.螺旋模型（原型+瀑布+风险分析）

1. 增加了风险分析
2. 把开发过程分为多个阶段，每个阶段都有评审+目标设定+风险分析+开发与有效性验证构成

1.4.统一过程

1.4.1.阶段

1. 初始：确定系统范围，定义产品视图和业务模型
2. 细化：设计系统架构，确定工作计划及资源需求
3. 构造：开发剩余构件，并集成成产品测试
4. 移交：制作产品发布版本

1.4.2.九个核心工作流

1. 过程：业务建模，需求，分析与设计，实现，测试，部署
2. 支持：配置与变更管理，项目管理，环境

1.4.3.核心

1. 用例驱动
2. 架构为中心
3. 迭代和增量

1.5.敏捷方法（适合小型项目）

1.5.1.特点

1. 增量迭代，小步快跑
2. 适应性的而非预设性
3. 以人为本
4. 适合小型项目
5. 价值观：沟通（面对面），简单（不过度设计），反馈，勇气

1.5.2.敏捷方法

1. 极限编程XP：近螺旋开发方法。价值观（交流，朴素，反馈，勇气）
2. 水晶方法：提倡机动性
3. scrum：侧重于项目管理
4. 特征驱动开发（FDD）：开发三要素（人，过程，技术）。六种关键项目角色（项目经理，首席架构师，开发经理，主程序员，程序员，领域专家）
5. 开放式源码：开发人员地域上分布广，不会集中办公

1.6.构建组装模型（易复用）

1.6.1.优缺点

1. 优点：易扩展，易重用，降低成本，安排任务更灵活
2. 缺点：构件设计需要经验丰富架构师，第三方构件质量难控制
3. 服务是一种标准化程度更高的构件

1.6.2.基于构件的软件工程CBSE（购买而不是重新构造）

1.6.2.1.特征

1. 可组装：所有外部交互通过公开接口进行
2. 可部署：构件是二进制形式，作为一个独立实体在平台运行
3. 文档化：用户根据文档判断是否满足需求
4. 独立性：在无其他构件情况下组装
5. 标准化：符合某种标准化的构件模型

1.6.2.2.模型要素

1. 接口：构件通过构件接口来定义（操作名/参数/异常）
2. 使用信息：构件元数据是构件本身相关的数据。构件是通用实体，在部署的时候，必须对构件进行配置适应系统
3. 部署：有关包中内容信息+二进制构成信息

1.6.2.3.组装（借助胶水代码）

1. 顺序组装：按顺序调用已经存在的构件
2. 层次组装：A调用B，B调用C，一条调用链.接口兼容
3. 叠加组装：多个构件形成新构件，对外提供新接口

1.6.2.4.组装出现不兼容

1. 参数不兼容：操作名相同，但是参数个数或者类型不同
2. 操作不兼容：操作名不同
3. 操作不完备：提供接口是所需的子集，或者相反

1.7.V模型

1. 测试贯穿始终，而不是像瀑布模型最后再有，避免最后出问题再整体改
2. 从需求分析起，每个阶段都有对应的测试

2.逆向工程（设计的恢复过程）

1. 实现级：抽象语法树，符号表，过程
2. 结构级：程序分量之间的依赖关系，调用图，结构图，数据结构
3. 功能级：程序段功能及程序段之间关系，数据和控制流模型
4. 领域级：应用领域概念间关系。实体关系模型

3.净室软件工程（理想化软件开发）

3.1.概念

1. 强调以合理的成本开发高质量软件
2. 函数理论和抽样理论为其理论基础
3. 不需要单元测试（保留传统的模块测试），进行正确性验证和统计质量控制

3.2.技术手段

1. 控制迭代：统计过程控制下增量式开发
2. 基于函数的规范和设计：行为视图（黑盒）- 有限状态机视图（状态盒）-过程视图（明盒）
3. 正确性验证：净室工程的核心，使软件质量有了极大的提高
4. 统计测试和软件验证：抽样

3.3.缺点

1. 太理论化，正确性验证步骤比较难且耗时
2. 不进行传统模块测试不现实
3. 带有传统软件工程的弊端

4.需求工程

4.1.概念

1. 需求开发+需求管理构成
2. 需求开发：需求获取+需求分析+形成需求规格（SRS）+需求确认与验证（形成需求基线）
3. 需求管理是对需求基线机型管理，包括变更控制，版本控制，需求跟踪，需求状态跟踪

4.2.需求获取

4.2.1.获取方法

1. 用户面谈：1对1或3，有代表性用户，成本高，需要有领域知识支撑
2. 需求专题讨论会（JRP）：高度组织的群体会议，了解想法，消除分歧，成本高，
3. 问卷调查：用户多，无法一一访谈，成本低
4. 原型：解决早期需求不确定问题
5. 头脑风暴：发散思维

4.2.2.需求分层

1. 业务需求（整体全局）
2. 用户需求（用户视角）
3. 功能需求（计算机化）：功能需求+性能需求+设计约束

4.2.3.项目管理维度（QFD）

1. 基本需求（明示）
2. 期望需求（隐含）
3. 兴奋需求（多余）

4.3.需求分析

4.2.1.组成（数据字典是核心）

1. 行为模型：状态转换图（状态+事件）
2. 功能模型：数据流图（DFD）：数据流+加工+数据存储+外部实体
3. 数据模型：ER图（实体+联系）
4. 数据字典：数据元素+数据结构+数据流+数据存储+加工逻辑+外部实体

4.2.2.ER图

1. m:n

4.2.3.UML

1. 静态图：类图，对象图，构件图，部署图（软硬件映射）
2. 动态图：用例图（系统与外部参与者互动），顺序图（按时间顺序），通信图（协作图），活动图（并行行为），状态图（状态变迁）

4.3.需求定义（形成需求规格）

4.3.1.严格定义法

1. 所有需求能够被预先定义
2. 开发人员与用户之间能够准确而清晰的交流
3. 图形/文字可以充分体现最终系统

4.3.2.原型法

1. 并非所有需求都能在开发前被定义
2. 项目参与者之间通常存在交流困难
3. 需要实际可供用户参与的系统模型

4.4.需求变更管理过程

1. 需求变更管理过程：问题分析和变更描述（识别出问题）- 变更分析和成本计算 - 变更实现
2. 需求变更控制流程十大步骤：明确问题-书面申请-判断变更需求类别-评估变更影响-判断变更紧急级别-沟通确认-明确解决方案-审批管理（变更控制委员会）-执行变更-版本控制

5.系统设计

5.1.界面设计

1. 置于用户控制之下
2. 减少用户记忆负担
3. 保持界面一致性

5.2.结构化设计

5.2.1.分类

1. 概要设计（外部设计）：确定每个模块的功能和调用关系，形成模块结构图
2. 详细设计（内部设计）：为每个具体任务选择适当的技术手段和处理方法

5.2.2.结构化设计原则

1. 模块独立性原则（高内聚，低耦合）
2. 保持模块大小适中
3. 多扇入，少扇出
4. 深度和宽度不宜过高

5.2.3.耦合（低-高）

1. 非直接耦合
2. 数据耦合（简单数据传递）
3. 标记耦合（数据结构传递）
4. 控制耦合(控制模块内部逻辑信息传递)
5. 外部耦合：全局简单变量
6. 公共耦合：公共数据环境
7. 内容耦合：代码重叠

5.2.4.内聚（高-低）

1. 功能内聚：完成单一功能，各部分协同工作
2. 顺序内聚：必须顺序执行
3. 通信内聚：处理元素集中在一个数据结构区域上
4. 过程内聚：处理元素相关，必须按特定次序执行
5. 时间内聚：必须同一时间间隔执行
6. 逻辑内聚：逻辑上相关的任务
7. 偶然内聚：没啥关系

5.2.5.面向对象设计原则

1. 输入和输出
2. 处理功能
3. 内部数据
4. 程序代码

5.2.6.类的分类

1. 边界类（API接口、用户界面）
2. 控制类（应用逻辑，业务逻辑，数据访问逻辑）
3. 实体类（数据ER图）

5.2.7.面向对象设计原则

1. 单一职责：目的单一的类
2. 开放-封闭原则：扩展开放，修改封闭
3. 李氏替换：子类可以替换父类
4. 依赖倒置：针对接口编程而不是具体实现
5. 接口隔离原则：多个专门接口比单一综合接口好
6. 组合重用原则：尽量使用组合，而不是继承关系
7. 迪米特原则：一个对象对其他对象尽可能了解少

6.软件测试

6.1.软件测试方法

1. 动态测试：白盒测试（关注内部结构与逻辑），黑盒测试（关注输入输出）
2. 静态测试：桌前检查，代码审查（静态分析），代码走查

6.2.动态测试

6.2.1.白盒测试（结构测试，单元测试阶段）

1. 控制流测试:逻辑覆盖测试（语句覆盖最弱-路径测试覆盖最强）
2. 程序变异测试（错误驱动）

6.2.2.黑盒测试（功能测试，集成，确认，系统测试阶段）

1. 等价类划分
2. 边界值分析
3. 错误推测：测试人员的经验和直觉
4. 判定表：多个逻辑条件取值的组合所构成的复杂情况下，分别要执行哪些不同操作
5. 因果图：根据输入条件与输出结果之间的因果关系来设计测试用例

6.3.软件测试阶段

6.3.1.阶段

1. 单元测试：依据详细设计，模块内
2. 集成测试：依据概要设计，模块间
3. 系统测试：依据需求文档，功能测试，性能测试，验收测试（确认测试，依据需求文档，用户参与），压力测试

6.3.2.其他测试

1. AB测试：多版本同时使用（网页优化方法）
2. Web测试：web系统测试与其他测试测试重点不同
3. 链接测试：确实链接到该链接的页面，测试链接页面是否存在，确定没有鼓励页面
4. 表单测试：验证服务器是否正确保存数据，测试提交操作的完整性

6.3.3.集成测试策略

1. 一次性组装（风险高）
2. 增量式组装（测试全面）：自顶向下（桩模块mock），自底向上（驱动模块），混合式（都需要）

6.3.4.软件系统测试

1. 功能测试
2. 性能测试：负载测试，压力测试（测上限），强度测试（测下限），容量测试（并发测试）。可靠性测试