开发模型
瀑布模型（SDLC，Software development lifecycle 软件开发生命周期）
需求明确的项目/二次开发项目适合使用
有利于项目管理，不适用于需求变化频繁的项目
| 阶段 | 步骤 |
|---|---|
| 定义阶段 | 软件计划 |
| ^ | 需求分析 |
| 开发阶段 | 软件设计 |
| ^ | 程序编码 |
| ^ | 软件测试 |
| 维护阶段 | 运行维护 |
改进型的瀑布模型：每个阶段可以回溯，应对需求变化
改进的模型
基于原型，适用需求不明确时，用户参与过多会很难控制项目进度
- 演化模型（变换模型）：原型演化为产品
- 螺旋模型：从不可用原型开始迭代，最后才发布可操作产品
- 增量模型：每个版本均发布一个可操作的产品
V模型
需求分析 ↓ ↑ 验收测试
概要分析 ↓ ↑ 系统测试
详细设计 ↓ ↑ 集成测试
编码 ↓ ↑ 单元测试
[V模型]
喷泉模型
面向对象的模型
RAD（快速应用开发）
基于SDLC（软件开发生命周期）和CBSD（构件业务软件开发），基于构建来开发，一个控件一个控件开发
构建组装模型
构建可以在不同项目中使用
需求分析和定义→软件架构设计→
（构件库，构建获取，构建管理）构件库的建立（构建标准嵌入CORBA、COM/DCOM、EJB）→
应用软件构建→测试和发布
敏捷开发
每次发布版本都是一个可用的产品（不是完整功能）
符合敏捷宣言就是敏捷开发方法：
- 个体和交互，胜过了过程和工具
- 可工作的软件，胜过了大量的文档
- 客户合作，胜过了合同谈判
- 响应变化，胜过了遵循计划
基本原则：短平快会议、小型版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整、结对编程、测试驱动开发、持续集成、重构
有几种：
- 自适应开发
- 水晶方法
- 功用驱动开发
- 极限编程 XP（用的最多）
XP 更关注技术和工程实践，而 Scrum 更关注团队协作和管理实践
水晶方法 Crystal
用最少的纪律约束，而仍能成功的方法
开放式源码
- 开发人员在地理位置上分布很广
- 查错排障高度并行性
并列争球法 Scrum
- 开发中不能增改需求
- 明确定义了可重复的方法过程
- 用迭代方法，每段时间称为一个冲刺（2-4周）
- 按优先级实现产品功能（不严格）
- 小组并行开发
功用驱动开发 FDD
- 开发人员分为：首席程序员、“类”程序员
自适应软件开发 ASD
非线性、重叠的开发阶段：猜测、合作、学习
DSDM 动态系统开发方法
以业务为核心
项目管理
进度管理、时间管理
活动定义、活动排序、持续资源估算、活动历时估算、制定进度计划、进度控制
算那个图
软件配置管理
放到配置管理中的
- 项目计划书、需求文档、设计文档、源码、可执行代码、测试用例、运行软件所需的各种数据
- 属性：名称、标识符、文件状态、版本、作者、日期
三个库
- 开发库（动态库。程序员库，工作库）：开发人员在开发的
- 受控库（动态库。主库，系统库）：从开发库，经过测试区，通过测试的代码
- 产品库（静态库。备份库，软件仓库）
三个名词
- 检查点：规定时间间隔，对项目进行检查，对和需求的差异进行调整
- 里程碑：完成阶段性工作的标志
- 基线：一种重要的里程碑，通过正式评审，进入受控的状态
基线的类型
- 功能基线（定义基线）：系统分析、软件定义结束后，经过评审确定的
- 分配基线（需求基线）：需求分配阶段结束后，经过评审和批准
- 产品基线：综合测试结束后，经过测试、评审、批准通过的软件产品的全部配置项的规格说明书
基线并更后，需要按变更控制流程，申请变更
软件过程改进（CMM）
评价软件企业的质量保证能力，软件研制和软件测试中的质量保证能力
- 初始级：无纪律规则，英雄主义
- 可重复级：纪律化，项目级别
- 已定义级：标准化，组织级别
- 已管理级：可量化
- 优化级：缺陷预防
关键过程域（KPA）
| 成熟度等级 | 管理方面 | 组织方面 | 工程方面 |
|---|---|---|---|
| 优化级 | 技术变更管理、过程变更管理 | 缺陷预防 | |
| 已管理级 | 量化过程管理 | 软件质量管理 | |
| 已定义级 | 集成软件管理、组间合作 | 组织过程焦点、组织过程定义、培训计划 | 软件产品过程、同行评审 |
| 可重复级 | 需求管理、软件项目计划、软件项目跟踪与监控、软件子合同管理、软件质量保证、软件配置管理 |
需求工程
软件需求分析阶段
- 需求开发↓需求基线
- 需求分析↑支持
需求开发
- 需求获取
- 需求分析
- 需求定义（规格说明书）
- 需求验证
需求分析
- 变更控制
- 版本控制
- 需求跟踪
- 需求状态跟踪
需求分类
- 业务需求（整体全局）
- 用户需求（用户视角）
- 系统需求（计算机化）
- 功能需求
- 非功能需求
- 设计约束
结构化分析
数据字典
- 功能模型（数据流图 DFD，一种静态行为）
- 数据流
- 加工
- 数据存储
- 外部实体
- 行为模型（状态转换图 STD，一种动态行为）
- 状态
- 事件
- 起点
- 终点
- 数据模型（E-R图，实体的静态结构），对数据进行描述
- 实体
- 联系
- 连线
- 属性
面向对象分析
统一建模语言（UML），静态图（结构体）、动态图（行为图）
- 构造块
- 事物
- 关系
- 图
结构化设计
- 抽象化
- 自顶向下，逐步求精
- 信息隐蔽
- 模块独立（高内聚，低耦合）
模块设计原则
- 保持模块大小适中
- 尽可能减少调用深度
- 多扇入，少扇出
- 单入口，单出口
- 模块的作用域应该在模块之内
- 功能应该是可预测的
| 内聚类型 | 描述 |
|---|---|
| 功能内聚 | 完成单一功能，各个部分协同工作，缺一不可 |
| 顺序内聚 | 各个部分必须按照顺序执行（有数据传递） |
| 通信内聚 | 所有处理元素，集中在一个数据结构的区域上（使用相同数据） |
| 过程内聚 | 各个部分必须按照顺序执行（无数据传递） |
| 瞬时内聚/时间内聚 | 包含的任务，必须在同一时间间隔内执行（初始化） |
| 逻辑内聚 | 逻辑上相关的一组任务（有传参） |
| 偶然内聚 | 没关系或松散关系 |
| 耦合类型 | 描述 |
|---|---|
| 内容耦合 | 一个模块直接访问另一个模块的内部数据 |
| 公共耦合 | 多个模块引用同一个全局数据结构 |
| 外部耦合 | 依赖同一个全局变量 |
| 控制耦合 | 传递控制信息，控制另一个模块 |
| 标记耦合 | 通过参数记录表（一个数据结构的子结构，不是简单变量） |
| 数据耦合 | 一个模块通过参数传递数据给另一个模块 |
| 非直接耦合 | 两个模块之间没有直接的联系 |
结构化设计的基本任务：将系统划分为模块、确定软件的结构、设计模块间的接口
模块的概念：组成系统的基本单位，可以组合、分解、替换