2.1 软件生命周期与配置管理

一.

1.1. Software Development Lifecycle(SDLC) 软件的生命周期

1.1.1 软件的版本 从有到好

  软件的变化导致软件生成周期的变化（如：图中黑色线的变化）。

1.1.2

1.2 Traditional Software process models 传统软件开发模型

  两种类型：线性过程（按部就班：编写、测试、修改等，可能造成需求不明确、浪费时间）、迭代过程（每到一定程度后给用户使用根据反馈进行下一步骤）。
  存在模型：瀑布过程、增量过程、V字模型、原型过程、螺旋过程。

1.2.1 Waterfall(sequential, non-iterative) 瀑布过程

  瀑布过程要求线性推进，但具有线性过程的缺点，阶段划分清楚，属于整体推进，但无迭代，管理简单但无法适应需求增加 / 变化。常用语军方如航天类项目。

1.2.2 Incremental(non-iterative) 增量模型

  划分为多个模块，一个模块一个模块的开发，人员较少可容易分配容易，但要求模型架构是开放的 、模型的接口由精细化的设计。
  增量过程是先行推进的，是增量式即多个瀑布的串行；是无迭代的，但与瀑布过程相比比较容易适应需求的增加。

1.2.3 V-Model(for verification and validation) V字模型

  每个阶段生成可并能通过测试的文档。

1.2.4 Prototyping(iterative) 原型模型

  先生成界面。在原型上持续不断的迭代
  通过系统原型帮助用户了解需求，主要针对需求不确定的场景。

1.2.5 Spiral(iterative) 螺旋模型

  计划象限、鉴别和解决风险、开发测试象限(类瀑布模型)、测试和部署
  这是一个非常复杂的开发过程，多轮迭代，每轮迭代基本遵循瀑布模式，有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代。
  把原型模型的易变化、瀑布模型的每个阶段可控性融合在一起，但只适用于长周期软件开发。并且螺旋模型引入了风险分析，要求引入专业的风险分析人员。

1.3 Agile Development 敏捷开发

1.3.1

  快速迭代、小规模的持续改进，以快速适应变化。

1.3.2 Agile Manifesto 敏捷宣言

  交互要比工具更重要 灵活、快速适应。
  可工作的软件要比文档有用的多。
  客户协作比用合同沟通重要得多。
  强调需求的变化。

1.3.3 一般形式

  会议型快速沟通。
  Agile = 增量 + 迭代。

1.3.4 敏捷开发的特点

  极限的用户参与 (Extreme user involvement)
  极限的小步骤迭代 (Extreme small iteration)
  极限的确认 / 验证 (Extreme V & V)

1.3.5 eXtreme Programming (XP，极限编程)

  多个阶段的（类）瀑布模型：

  变化1：文档少了。传统开发注重文档、每个阶段需要验证、不能多分支更改，而敏捷开发强调短周期迭代、将用户加入开发团队，不注重文档。
  变化2：编码阶段强调结对编程，本来需要代码的 review，结对编程可实时review或者交换 review 与programming 的角色，测试驱动的开发（需要有经验、成熟的代码写作经历）。
  需要注意的是，这其中使用自动化的手段进行部署。

1.4 Software Configuration Management (SCM) and Version Control System (VCS) 软件的配置管理 + 版本控制工具

1.4.1 Software Configuration Management (SCM) 软件配置管理

  软件配置管理：追踪和控制软件的变化，对程序、文档、数据等的管理。
  软件配置项：软件中发生变化的基本单元（例如：文件）。

  基线(baseline)：软件持续变化过程中的稳定时刻（例如：对外发布的版本）

  CMDB：配置管理数据库 存储软件的各配置项随时间发生变化的信息+基线，如下图中的SCIs：

1.4.2 Version Control System (VCS)版本控制系统

1.4.2.1 版本号

  版本号中越前的数字越稳当，越后面数字的更高越可能只是对程序的一个补丁。

1.4.2.2 版本控制方法

  古老的版本控制方法：通过复制文件并修改文件名（考验人的记忆力）。如下图所示：
  而对新型的版本控制工具而言，主要的功能如图所示，有如下部分：
  1. 回滚到上一个版本；
  2. 比较两个版本的差异；
  3. 备份软件版本历史；
  4. 获取备份；
  5. 合并；
  6. 在多个开发者之间共享和协作；
  7. 记录每个开发者的动作，便于“审计”。

1.4.2.3 History of an SCI

  多个版本之间形成线性或分支结构。分支容许多个不同的版本存在，如 Git 中可以将branch版本合并到主线master上。

1.4.2.4 版本控制工具的一些大致概念

  1. 仓库：即于 SCM 中的 CMDB。
  2. 工作拷贝：在开发者本地机器上的一份项目拷贝。由于对某一版本的文件，需要经过下载、在本地机上的目录修改、更新（上传）等的步骤，而其中本地机上的目录指的就是工作拷贝。
  3.文件：一个独立的配置项。
  4.版本：在某个特定时间点的所有文件的共同状态。
  5.变化：即 code churn，两个版本之间的差异。
  6.HEAD：程序员正在其上工作的版本。即指针，指明了程序员正在工作的版本。

1.4.2.5 VCS的三种类型

  1.本地式版本控制工具 (Local VCS)：
  仓库存储与开发者本地机器，无法共享和协作。

  2.集中式版本控制工具 (Centralized VCS)：
  仓库存储于独立的服务器，支持多开发者之间的协作，版本集中管理，不会出现差异，但服务器宕机则版本数据丢失，所以需要备份。

  3.分布式版本控制工具 (Distributed VCS)：
  仓库存储与独立的服务器+每个开发者的本地机器如Git，安全但一致性无法保证，容易出现差异，需要通过其他手段保证一致性。

1.5 Git as an example of SCM tool 软件配置管理工具：Git

1.5.1 Git 的结构

  由服务器（即远程的版本库）以及本地端存在的三个目录组成。
  本地端存在三个目录：
  1.本地端仓库，用来存放程序的所有版本。
  2.工作目录（即工作区）。它是对程序进行更改的目录。
  3.暂存区（Staging area(in memory)）：更改完程序的地方，更改后的程序可能过如 $git\space add .\space$git add.  指令存放在这里，之后可通过 $git\space commit$git commit 提交到版本库中形成新的版本库。用来隔离工作目录和 Git 仓库。
  需要注意的是，除了暂存区不是真实存在的以外，其他目录及服务器均是真实存在的。
  暂存区表示为某一个文件设置一位，如结尾增加标志位，实质上是设置文件的状态。

1.5.2 Git repository

   $git\space directory$git directory是本地的CMDB；$Working\space directory$Working directory 工作目录是本地文件系统。
  每个文件有这样的三种状态：状态有已修改、已暂存、已提交（该状态位于Git 的本地仓库）。

1.5.3 Object graph in Git

  需要明确的是：不同版本是以对象形式来存储的。使用指针能够追溯版本，指针将版本串在一起，以如下有向无环图的形式存在：

  图中的版本之间的演化关系图（Object Graph），一条边A->B表征了“在版本B的基础上做出变化，形成了版本A”