软件生命周期和配置管理

目录

• 软件开发生命周期
• 传统的软件过程模型
• 敏捷开发和极限编程
• 软件配置管理
• Git（SCM tool）

本章开始关心：软件开发(0->1->…->n)遵循什么过程。

---

软件开发生命周期（SDLC）

From 0 to 1 从无到有

Planning->Analysis->Design->Implementation->Testing&Integration->Maintenance
上面就是一个新的软件产品问世所需要经历的过程，一个从无到有的过程。

From 1 to n 从有到好

一个新的软件问世后，需要不断的更新，在原有的基础上不断升级，这就是一个从有到好的过程。

---

传统的软件过程模型

两种基本类型

• 线性过程（Linear）
  

• 迭代过程（Iterative）
  

模型

瀑布模型（Waterfall）

这是一种顺序的，非迭代的模型，由Winston W. Royce 在1970年提出。有如下特点

• 线性推进
• 阶段划分清楚
• 整体推进
• 无迭代
• 管理简单
• 无法适应需求增加/变化
  

---

增量模型（Incremental）

这是一种非迭代的模型，有如下特点。

• 线性推进
• 增量式（多个瀑布的串行）
• 无迭代
• 比较容易适应需求的增加
  

---

V字模型（V-Model ）

这是一种用于验证的模型，代表了可以被认为是瀑布模型的扩展的开发过程。

---

原型模型（Prototyping）

这是一种迭代的模型，在原型上持续不断的迭代发现用户变化的需求。
迭代即软件开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。

---

螺旋模型（Spiral）

这是一种迭代的模型，一种非常复杂的过程：多轮迭代基本遵循瀑布模式；每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代。由Barry Boehm 在1986年首次提出。

---

敏捷开发和极限编程

敏捷开发（Agile development）

敏捷开发即通过快速迭代和小规模的持续改进，以快速适应变化。 这意味着

• 极限的用户参与
• 极限的小步骤迭代

• 极限的确认/验证

  

与瀑布模型的比较如下图所示

极限编程

这里的极限编程并非指几天几夜不吃不睡一直编程，而是指严格遵守任务板且有进度监控的编程模式，同样也是一种迭代的过程。

---

软件配置管理（SCM）和版本控制系统（VCS）

软件配置管理（SCM）

软件配置管理主要用于追踪和控制软件的变化 。其中有几个概念需要了解。

• 软件配置项（SCI）：软件中发生变化的基本单元（例如：文件）
• 基线（Baseline）：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）
• 配置管理数据库 （CMDB）：存储软件的各配置项随时间发生变化的信息 +基线

版本控制系统（VCS）

版本：为软件的任一特定时刻（Moment）的形态指派一个唯一的编号，作为“身份标识” 。

需要版本控制的原因

• 个人
  回滚到上一版本
  比较两个版本差异
  备份软件版本历史
  获取备份
  合并
• 团队
  在多个开发者之间共享和协作
  记录每个开发者的动作，便于“审计”

古老的版本控制方法

通过复制文件并修改文件名

版本控制术语

仓库：即于SCM中的CMDB
工作拷贝：在开发者本地机器上的一份项目拷贝
变化：即code churn，两个版本之间的差异
HEAD：程序员正在其上工作的版本

版本控制系统

• 本地版本控制系统（Local VCS ）
  仓库存储于开发者本地机器无法共享和协作

• 集中式版本控制系统（Centralized VCS）
  仓库存储于独立的服务器， 支持多开发者之间的协作

• 分布式版本控制系统（Distributed VCS）
  仓库存储于独立的服务器+每个开发者的本地机器

---

Git

Git repository

• .gitdirectory
  本地的CMDB
• Working directory
  工作目录：本地文件系统
• Staging area
  暂存区：隔离工作目录和Git仓库

Object graph in Git

Object graph存储在存储库的.git目录中，它是版本之间的演化关系图，一条边B->A表征了“在版本A的基础上作出变化，形成了版本B”。

Git使用