2-1 软件生命周期与配置管理

目的
▪ 了解软件开发的一般过程
▪ 了解传统软件过程模型的原理，包括线性和迭代模型（瀑布、增量、原型、螺旋和V模型）
▪ 认识和实践敏捷开发
▪ 了解软件配置管理（SCM）
▪ 学习如何将Git用于日常的SCM任务（用于个人开发的基本命令，用于协作开发的高级命令）

大纲
▪ 软件开发生命周期（SDLC）
▪ 传统的软件过程模型（瀑布、增量、Vmodel、原型、螺旋）
▪ 敏捷开发和极限编程（XP）
▪ 软件配置管理
▪ Git作为SCM工具
▪ 摘要

2.传统的软件过程模型
两种基本类型：线性&迭代
▪ 现有模型：
–瀑布（线性，非迭代）
–增量（非迭代）
–V模型（用于验证和确认）
–原型（迭代）
–螺旋（迭代）
▪ 关键质量考虑因素：
–用户参与（适应变化）
–开发效率、管理复杂性
–软件质量

瀑布式（顺序，非迭代）
▪ 进度被视为在概念、启动、分析、设计、构建、测试、实现和维护的各个阶段稳步向下流动（像瀑布一样）。
▪ 易于使用，但事后的改变代价高昂。
▪ 1970年由温斯顿·W·罗伊斯定义。

增量（非迭代）

V型（用于验证和确认）
▪ V-model表示一个开发过程，它可以被视为瀑布模型的扩展。
–过程步骤不是以线性方式向下移动，而是在编码阶段之后向上弯曲，形成典型的V形。
–演示开发生命周期的每个阶段与其相关测试阶段之间的关系。
–水平轴和垂直轴分别表示时间或项目完整性（从左到右）和抽象级别（最上面的粗粒度抽象）

原型（迭代）
▪ 优点：软件设计者和实现者可以在项目早期从用户那里得到有价值的反馈。
–客户可以比较所制作的软件是否与软件规范相匹配，根据该规范构建软件程序。
–它还允许软件工程师深入了解初始项目估计的准确性，以及是否可以成功地满足截止日期和里程碑
迭代：开发出来之后由用户试用/评审，发现问题反馈给 开发者，开发者修改原有的实现，继续交给用户评审。
循环往复这个过程，直到用户满意为止。 时间代价高，但开发质量也高。

螺旋（迭代）
一种风险驱动的过程模型
非常复杂的过程：
• 多轮迭代基本遵循瀑布模式
• 每轮迭代有明确的目 标，遵循“原型”过 程，进行严格的风险 分析，方可进入下一 轮迭代

3.敏捷开发
它提倡适应性规划、渐进式发展、早期交付和持续改进，并鼓励快速灵活地应对变化。
▪ 敏捷宣言由17位著名的“程序员”于2001年首次提出。


▪ 极限的用户参与
▪ 极限的小步骤迭代
▪ 极限的确认/验证




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

软件配置管理。（供应链管理）
▪ 供应链管理的任务是跟踪和控制软件的变化。
▪ 供应链管理实践包括修订控制和基线的建立。

配置项（CI）的生命周期
▪ 软件的任何组成部分（源代码、数据、文档、硬件、各种环境）都可以随着软件生命周期的时间而更新。
▪ 软件配置项（SCI）：供应链管理的基本结构单元。
配置项（SCI）和基线
▪ 基线是在某个时间点对产品属性的一致描述，它是定义变更的基础。

版本控制
▪ 版本控制是为软件的唯一状态指定唯一版本名或唯一版本号的过程。版本：–在给定的版本号类别（主版本号、次版本号）内，这些编号通常按递增顺序分配，并与软件的新开发相对应。
–在细粒度级别上，修订控制通常用于以增量方式跟踪电子信息的不同版本，无论这些信息是否为计算机软件。

为什么需要版本控制？
-针对个人
▪ 恢复到以前的版本
▪ 比较两个不同的版本
▪ 将完整版本历史记录推送到另一个位置
▪ 把历史从那个地方拉回来
▪ 合并同一早期版本的分支版本
–团队合作
▪ 多个开发人员之间的通信和共享/合并工作
▪ 记录不同开发人员的个性化作品进行审核

多个版本之间形成线性或结构分支

版本控制术语
▪ 存储库Repository：项目中版本的本地或远程存储
▪ 工作副本Working copy：我们可以处理的项目的本地可编辑副本
▪ 文件 File：项目中的单个文件
▪ 版本或修订Versionor revision：一个时间点上项目内容的记录
▪ 更改或差异Change or diff：两个版本之间的差异：
▪ HEAD：当前版本

版本控制系统的特性
▪ 可靠：只要我们需要，就可以保留版本；允许备份
▪ 多个文件：跟踪项目的版本，而不是单个文件
▪ 有意义的版本：有什么变化，为什么要做出这些变化？
▪ 还原：全部或部分还原旧版本
▪ 比较版本
▪ 回顾历史：用于整个项目或单个文件

版本控制系统的特性
▪ 它应该允许多个人一起工作：
–合并：合并不同于以前通用版本的版本
–跟踪责任：谁做了那个更改，谁接触了那个代码行？
–并行工作：允许一个程序员自己工作一段时间（不放弃版本控制）
–进行中工作：允许多个程序员共享未完成的工作（不干扰其他人，不放弃版本控制）

仓库存储于开发者本地机器 无法共享和协作

仓库存储于独立的服务器， 支持多开发者之间的协作

5.Git

Git存储库
▪ Git存储库有三个部分：
–.Git目录（存储所有版本控制数据的存储库）
–工作目录（本地文件系统）
–暂存区（内存中）
▪ 每个文件都属于以下三种状态之一：
–Modified（工作目录中的文件不同于git存储库中的文件，但不在暂存区域）
–Staged（文件已修改并添加到暂存区域）
–Committed（工作目录和git目录中的文件保持相同）

Git中的对象图
▪ 我们使用Git执行的所有操作-克隆、添加、提交、推送、日志、合并…
-都是图形数据结构上的操作，该结构存储项目中所有文件版本以及描述这些更改的所有日志项。
▪ Gitobject图存储在存储库的.git目录中。
▪ 从另一台机器/服务器复制git项目意味着复制整个对象图。

对象图是什么样子的？
▪ 对象图是Git项目的历史，是一个有向无环图（DAG）

▪ 历史图中的每个节点都是项目的提交a.k.a.版本a.k.a.修订版：该时间点上所有文件的完整快照。
–除了初始提交，每个提交都有一个指向父提交的指针。
–有些提交具有相同的父级：它们是不同于普通先前版本的版本。–有些承诺有两个父项：它们是将不同历史联系在一起的版本。
▪ 分支只是指向提交的名称。
▪ HEAD指向当前提交。
–我们需要记住我们正在处理哪个分支。所以HEAD指向当前分支，它指向当前提交。

Git表示具有树节点的提交。
–对于任何大小合理的项目，大多数文件在任何给定的修订中都不会更改。存储文件的冗余副本是浪费，所以Git不会这样做。
–相反，Git object graph只存储单个文件的每个版本一次，并允许多个提交共享该副本。
–每个提交也有日志数据-谁、何时、短日志消息等

Git支持分支和合并
▪ 分支是在修订控制下的对象的复制，因此可以沿两个分支并行进行修改。



GitHub：一个基于web的Git服务器和Internet托管服务。
–它提供了Git的所有分布式版本控制和SCM功能，并添加了自己的特性。
–它为每个项目提供访问控制和几个协作功能，如bug跟踪、功能请求、任务管理和wiki。
–私有和免费存储库（用于开源项目）
▪ 2019年，它拥有超过3100万用户，超过1亿个存储库。
GitHub工作流程
▪ 基本流程：提交、分支和合并
▪ 协作过程：fork-and-pull请求


总结：
▪ 通用软件开发生命周期（SDLC）
▪ 传统的软件过程模型——瀑布、增量、原型、迭代
▪ 敏捷开发
▪ 协同软件开发
▪ 软件配置管理
▪ Git作为SCM工具