软件生命周期和配置管理
目录
- 软件开发生命周期
- 传统的软件过程模型
- 敏捷开发和极限编程
- 软件配置管理
- 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”。