- 软件开发生命周期
- 传统软件开发流程
两个基础模型：线性过程、迭代过程
现有的模型：瀑布过程、增量过程、V字模型、原型模型、螺旋模型。
选择合适的过程模型的依据：
用户参与程度、适应变化能力、开发效率/管理复杂度、开发出软件的质量。
瀑布过程：进步被视为在构思、开始、分析、设计、施工、测试、实施和维护等阶段稳步向下流动（就像瀑布一样）。易于使用，但事后的改变代价令人望而却步。
特点：线性推进、阶段划分清楚、整体推进、无迭代、管理简单、无法适应需求和增加/变化
增量过程： 线性推进 、增量式（多个瀑布的串行） 、无迭代、比较容易适应需求的增加
v模型：表示一个开发过程，可以被认为是瀑布模型的扩展过程。（验证与确认）
过程步骤不是线性向下移动，而是在编码阶段后向上弯曲，以形成典型的V形状。
演示开发生命周期的每个阶段与其相关的测试阶段之间的关系。-水平轴和垂直轴分别表示时间或项目完整性（从左到右）和抽象级别（最粗粒度抽象）
迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高
螺旋形：非常复杂的过程：多轮迭代基本遵循瀑布模式、每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代
- 敏捷开发
敏捷开发：它提倡适应性规划、进化发展、早期交付和持续改进，并鼓励对变化的快速和灵活的反应。通过快速迭代和小规模持续改进，以适应快速变化。每次迭代处理一个小规模增量。
极限的用户参与
极限的小步骤迭代
极限的确认/验证
- 软件配置管理(SCM)和版本控制系统(VCS)
软件配置管理：追踪和控制软件的变化，包括修订控制和建立基线。
配置项的生命周期：软件的任何组件（源代码、数据、文档、硬件、各种环境）都可以与软件生命周期中的时间一起更新。
软件配置项：软件中发生变化的基本单元
配置项目(SCI)和基线：基线是对某个时间点的产品属性的一致描述，它作为定义变化的基础。是软件持续变化过程中的“稳定时刻”
配置管理数据库：存储软件的各配置项随时间发生变化的信息+基线
版本控制：是为软件的版本号分配唯一版本名或唯一状态的过程。在给定的版本号类别中（主要、次要）中，这些数字通常按递增顺序分配，并与软件的新开发相对应。-在细粒度级别上，修订控制通常用于跟踪增量不同版本的电子信息，无论这些信息是否是计算机软件。
古老的版本控制方法：通过复制文件并修改文件名
为什么需要版本控制：对个人而言：还原到过去的版本、比交两个版本差异、备份软件版本历史、获取备份、合并属于相同早期版本的分支的版本
为什么需要版本控制：对团队而言：在多个开发者之间共享协作、记录每个开发者的动作、便于“审计”
版本控制的术语：
库：项目中版本的本地或远程存储库
工作拷贝：在开发者本地机器上的一份项目拷贝
文件：一个独立的配置项
版本：在某个特定时间点的所有文件的共同状态
变化：即code churn，两个版本之间的差异
HEAD：程序员正在其上工作的版本
本地版本控制系统：仓库存储于开发者本地机器，无法共享和协作
集中式版本控制系统：仓库存储于独立的服务器，支持多开发者之间的协作
分布式版本控制系统：仓库存储于独立的服务器+每个开发者的本地机器
- 软件建设的总体流程
- 编码：
构造语言：
从用途划分：编程语言、建模语言、配置语言、构建语言
从形态划分：基于语言学的构造语言、基于数学的形式化构造语言、基于图形的可视化构造语言
程序设计工具：集成开发环境(IDE)：为程序员提供供软件开发使用的综合设施。
- 审核和静态代码分析
代码评审是对源代码的系统检查（同行评审）。
旨在在初始开发阶段发现被忽视的错误，提高整体质量。
审查以各种形式进行，如成对编程、非正式演练和正式检查
正式的代码评审：正式的代码审查，如费根检查，涉及到一个有多个参与者和多个阶段的仔细和详细的过程。
正式的代码审查是一种传统的审查方法，即软件开发人员参加一系列会议，逐行审查代码，通常使用材料的打印副本。
正式检查非常彻底，已被证明在发现审查中代码的缺陷时有效。
轻量级的代码评审
利用工具进行的静态代码分析
代码审查目的：改进代码和程序员
- 动态代码分析
动态分析：要执行程序并观察现象、收集数据、分析不足
对代码的运行时状态和性能进行度量，发现代码中的潜在问题
- 调试和测试
测试：发现程序是否有错误
调试：定位错误、发现错误根源
- 重构
重构：在不改变功能的前提下优化代码