2-1软件生命周期与配置管理
目的：
软件开发的基本过程
传统的软件开发过程模型
敏捷开发
软件配置管理
Git作为配置管理工具
1）软件开发生命周期（SDLC）
From 0 to 1 从无到有
From 1 to n 从有到好
软件的“年龄”：生产和使用多久了
软件的“生命力”：在特定的时间，它受到市场和用户的欢迎程度
2）传统软件过程模型
两种基本类型：
线性过程
迭代过程
现有的模型：
瀑布过程
增量过程
V字模型
原型过程
螺旋模型
选择合适的过程模型的依据:
用户参与程度有多大？--适应变化的能力
开发效率/管理复杂度
开发出的软件的质量
（1）瀑布过程：
通过概念、启动、分析、设计、建造、测试、实施和维护的阶段，进度被视为稳定地向下流动（如瀑布）
易于使用，但在事后改变是昂贵的
瀑布过程： 线性推进 阶段划分清楚 整体推进 无迭代 管理简单 无法适应需求、增加/变化
（2）增量过程：
该产品是设计、实现和增量测试（每次添加多一点）直到产品完成。
它逐步应用瀑布模型。
系统被分解成许多微型开发项目。
部分系统被建立以产生最终系统。
首先解决最高优先级的要求。
一旦增量部分被开发，一部分的需求就被冻结。
增量过程：线性推进 增量式（多个瀑布的串行） 无迭代 比较容易适应需求的增加
（3）V字模型：
V字模型表示可被认为是瀑布模型的扩展的开发过程。
不是以线性方式向下移动，而是在编码阶段之后向上弯曲工艺步骤，以形成典型的V形。
演示开发生命周期的每个阶段及其相关的测试阶段之间的关系。
水平轴和垂直轴分别表示时间或项目完备性（左到右）和抽象级别（最粗粒度抽象）。
原型过程：
软件原型是创建软件应用程序原型的活动，即正在开发的软件程序的不完整版本。
原型过程典型地模拟了几个方面，并且可能与最终产品完全不同。
过程：
识别基本要求：确定基本要求，包括所需的输入和输出信息。细节通常可以忽略不计。
开发初始原型：开发的初始原型只包含用户界面。
回顾：客户，包括最终用户，检查原型并提供关于添加或更改的反馈。
修改和增强原型：使用反馈既可以改进规范，也可以改进原型。如果引入变化，则需要重复步骤3和4。
好处：
软件设计师和实施者可以在项目早期得到用户的有价值的反馈。
客户端可以比较软件是否符合软件规范，并据此构建软件程序。
它还允许软件工程师洞察初始项目估算的准确性以及能否成功地完成最后期限和里程碑。
（迭代：开发出来之后由用户试用/评审，发现问题反馈给 开发者，开发者修改原有的实现，继续交给用户评审。
循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。）
螺旋模型：
螺旋模型是风险驱动的软件项目过程模型生成器。基于给定项目的独特风险模式，螺旋模型引导团队采用一个或多个过程模型的元素，如增量、瀑布或进化原型。
非常复杂的过程：
多轮迭代基本遵循瀑布模式
每轮迭代有明确的目标，遵循“原型”过程，进行严格的风险分析，方可进入下一轮迭代
3）敏捷开发
敏捷开发：通过快速迭代和小规模的持续改进，以快速适应变化
5）软件配置管理（SCM）和版本控制系统（VCS）
软件配置管理：追踪和控制软件的变化
SCM实践包括修订控制和基线的建立
配置项的生命周期：
软件的任何组成部分（源代码、数据、文档、硬件、各种环境）可以随着软件生命周期中的时间而更新
软件配置项：软件中发生变化的基本单元（例如：文件）
配置项（SCI）和基线：
基线：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）
CMDB：配置管理数据库 存储软件的各配置项随时间发生变化的信息 +基线
Versioning 版本控制：
版本：为软件的任一特定时刻（Moment）的形态指 派一个唯一的编号，作为“身份标识”
在给定的版本号类别（主要、次要）中，这些数字通常以递增的顺序分配，并且对应于软件中的新发展
在细粒度级别上，修订控制通常用于跟踪增量的不同版本的电子信息，不管该信息是否是计算机软件
古老的版本控制方法：通过复制文件并修改文件名
为什么需要版本控制？
（1）个人：
回滚到上一个版本
比较两个版本的差异
备份软件版本历史
获取备份
合并
（2）团队合作：
在多个开发者之间共享和协作
记录每个开发者的动作，便于“审计”
版本控制术语
仓库：即于SCM中的CMDB
工作拷贝：在开发者本地机器上的一份项目拷贝
变化：即code churn，两个版本之间的差异
HEAD：程序员正在其上工作的版本
版本控制系统的特点
可靠性：在需要的时候保存版本，允许备份
多个文件：项目的跟踪版本，而不是单个文件
有意义的版本：这些变化是什么？为什么要制造这些变化？
还原：全部或部分恢复旧版本
比较版本
审查历史：对于整个项目或个人档案
不仅仅是代码：散文，图像，…
它应该允许多个人一起工作：
合并：从以前的版本中分离出的版本组合
追踪责任：谁做出了改变，谁触及了那一行代码？
并行工作：允许一个程序员自己工作一段时间（不放弃版本控制）
在进行中的工作：允许多个程序员共享未完成的工作（不干扰他人，而不放弃版本控制）
版本控制系统（VCS）：
本地版本控制系统：仓库存储于开发者本地机器，无法共享和协作
集中式版本控制系统：仓库存储于独立的服务器，支持多开发者之间的协作
分布式版本控制系统：仓库存储于独立的服务器+每个开发者的本地机器
5）Git作为供应链管理工具的一个实例
Git仓库包含三部分：
本地的CMDB
工作目录：本地文件系统
暂存区：隔离工作目录和Git仓库
每个文件属于以下三种状态之一：
已修改：工作目录中的文件不同于Git仓库中的文件，但不在分级区域中
已暂存：文件被修改并被添加到分级区域中
已提交：该文件在工作目录和Git仓库中保持相同
Git中的对象图：
我们使用Git克隆、添加、提交、推、日志、合并、……进行的所有操作都是对存储项目中所有文件版本的图形数据结构的操作，以及描述这些更改的所有日志条目。
对象图是GITSCOPE项目的历史，是有向无环图（DAG）
ObjectGraph：版本之间的演化关系图，一条边 A->B表征了“在版本A的基础上作出变化，形成 了版本B”
提交：对象图中的节点
每个提交是我们整个项目的快照，其中Git用树节点表示
对于任何合理大小的项目，大多数文件在任何给定的版本中都不会更改。存储文件的冗余副本将是浪费的，所以GIT不这样做
相反，GIT对象图存储单个文件的每个版本一次，并允许多个提交返回一个副本每个提交也有日志数据-谁，何时，短日志消息等等