哈尔滨工业大学软件构造课程笔记第二章第一节

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

1.软件开发生命周期（SDLC）

软件开发生命周期：从无到有
软件生命周期中的多个版本：从有到好

2.传统软件过程模型

传统的软件过程模型

两种基本类型:线性过程、迭代过程

已有模型：瀑布过程、增量过程、V字模型、原型过程、螺旋模型

选择合适的过程模型的依据:
1.用户参与程度有多大？–适应变化的能力
2.开发效率/管理复杂度
3.开发出的软件的质量

瀑布过程（连续的、非迭代的
）

通过概念、启动、分析、设计、构建、测试、实现和维护的阶段，进展被看作是稳定地向下流动(像瀑布一样)。

易于使用，但事后更改的成本高得令人望而却步。

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

增量过程（非迭代的）

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

V字模型（用于验证和确认）

瀑布模型的扩展
不是以线性方式向下移动，而是在编码阶段后向上弯曲，形成典型的V形。
演示开发生命周期的每个阶段与相关的测试阶段之间的关系。
横轴和纵轴表示时间或项目的完整性(从左到右)和抽象级别(最主要的是粗粒度抽象)。

原型过程（迭代的）
在原型上持续不断的迭代发现用户变化的需求

优点：
软件设计者和实现者可以在项目的早期从用户那里得到有价值的反馈。
客户端可以比较所制作的软件是否符合软件规格，根据软件规格来编制软件程序。
它还允许软件工程师深入了解初始项目评估的准确性，以及是否可以成功地满足最后期限和里程碑。

迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。

循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。

螺旋模型（迭代的）
一种风险驱动的过程模型

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

3.敏捷开发

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

敏捷 = 增量 + 迭代
每次迭代处理一个小规模增量
▪ 极限的用户参与
▪ 极限的小步骤迭代
▪ 极限的确认/验证

敏捷开发方法：极限编程（XP）
结对编程
任务板和进度监控

敏捷开发方法：扭打（Scrum）

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

软件配置管理：追踪和控制软件的变化
核心：版本控制和基线的确立
配置项的生命周期(CI)
软件的任何组成部分(源代码、数据、文档、硬件、各种环境)都可以随软件生命周期的时间而更新。

软件配置项：软件中发生变化的基本单元（例如：文件）

配置项(SCI)和基线
基线：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）

CMDB和审核的签入/签出
CMDB：配置管理数据库
存储软件的各配置项随时间发生变化的信息+基线

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

在给定的版本号类别(主版本号、次版本号)中，这些数字通常按递增的顺序分配，并与软件中的新开发相对应。

在细粒度级别上，修订控制通常用于跟踪电子信息的增量不同版本，不管这些信息是否是计算机软件。

古老的版本控制方法：通过复制文件并修改文件名
为什么需要版本控制——对于个人
回滚到上一个版本
比较两个版本的差异
备份软件版本历史
获取备份
合并

为什么需要版本控制——对于团队
在多个开发者之间共享和协作
记录每个开发者的动作，便于“审计”

配置项SCI的历史：多个版本之间，形成线性
或分支结构

版本控制的术语
仓库：即于SCM中的CMDB
工作拷贝：在开发者本地机器上的一份项目拷贝
文件：一个独立的配置项
版本：在某个特定时间点的所有文件的共同状态
变化：即code churn，两个版本之间的差异
HEAD：程序员正在其上工作的版本

版本控制系统的特性
可靠:保留版本，只要我们需要他们;允许备份
多个文件:跟踪项目的版本，而不是单个文件
有意义的版本:有什么变化，为什么要做?
还原:还原旧版本，全部或部分
版本比较
回顾历史：对于整个项目或单个文件
不仅仅是代码:散文，图片，…

它应该允许多人一起工作：
合并:合并与以前版本不同的版本
跟踪责任:谁做了更改，谁碰了那一行代码?
并行工作:允许一个程序员独立工作一段时间
(没有放弃版本控制)
工作进行中:允许多个程序员共享未完成的工作
(在不影响其他人,没有放弃版本控制)

版本控制系统（VCS)

本地版本控制系统
中化版本控制系统
分布式版本控制系统

本地版本控制系统：
仓库存储于开发者本地机器无法共享和协作
集中式版本控制系统：仓库存储于独立的服务器，支持多开发者之间的协作

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

5.以Git为例的软件配置管理工具

管理软件演进过程中的变更

Git存储库

Git仓库有三个部分:
本地的CMDB
工作目录：本地文件系统
暂存区：隔离工作目录和Git仓库

每个文件属于下列三种状态之一:
已修改
已暂存
已提交

Git中的对象图

Git的所有操作都是在一个图数据结构(对象图)上进行
从另一台机器/服务器复制git项目意味着复制整个对象图

git clone URL local_repository

对象图是一个有向无环图(DAG)，它是Git项目的历史记录
对象图：版本之间的演化关系图，一条边A->B表征了“在版本B的基础上作出变化，形成了版本A”

提交:对象图中的节点
历史图中的每个节点都是项目的提交版本，也就是项目的修订版本:在那个时间点上所有文件的完整快照。

每个commit指向一个父亲
多个commit指向同一个父亲：分支
一个commit指向两个父亲：合并

分支只是一个指向提交的名称。
Head指向了当前分支的当前commit

Git用树节点表示提交。

管理Git中的更改
传统VCS存储版本之间的变化（行）

Git存储发生变化的文件（而非代码行），不变化的文件不重复存储


文件未发生变化，则后续多个版本始终指向同一个文件
文件发生变化了，存储两份不同的文件，两个版本指向不同的文件

使用git提交添加到对象图
使用git push和git pull发送和接收对象图

基本的Git命令：取得项目的 Git 仓库
▪ 下载并在本机安装设置Git环境 https://git-scm.com/

▪ 在工作目录中初始化新仓库
– 要对现有的某个项目开始用Git管理，只需到此项目所在的目录，执行git
init命令，用 git add 命令告诉Git开始对这些文件进行跟踪，然后提交：
• git add *.c
• git add readme.txt
• git commit -m ‘initial project version’

▪ 从现有仓库克隆：复制服务器上项目的所有历史信息到本地
– git clone [url]

基本的Git命令：记录每次更新到仓库
在工作目录对某些文件作了修改之后，Git将这些文件标为“已修改”，可提交本次更新到仓库。
▪ 逐步把这些修改过的文件放到暂存区域，直到最后一次性提交所有这些暂存起来的文件，如此重复

基本的Git命令：跟踪新文件、暂存已修改文件
使用git add开始跟踪一个新文件（使某个文件纳入到git中管理）。
▪ 一个修改过的且被跟踪的文件，处于暂存状态。
▪ git add后面可以指明要跟踪的文件或目录路径。如果是目录的话，就说明要递归跟踪该目录下的所有文件。
▪ git add的潜台词：把目标文件快照放入暂存区域，也就是 add file into staged area，同时之前未曾跟踪过的文件标记为需要跟踪。
▪ 若对已跟踪的文件进行了修改，使用git add命令将其放入暂存区；
▪ 运行了git add之后又对相应文件做了修改，要重新git add。

基本的Git命令：检查当前文件状态
要确定哪些文件当前处于什么状态，用git status命令：
– # On branch master nothing to commit (working directory clean)
当前没有任何跟踪着的文件，也没有任何文件在上次提交后更改过
– # On branch master # Untracked files: …
有未跟踪的文件，使用git add开始跟踪一个新文件
– # On branch master # Changes to be committed:
有处于已暂存状态的文件

基本的Git命令：查看已暂存和未暂存的更新
▪ git status回答：当前做的哪些更新还没有暂存？有哪些更新已经暂存起来准备好了下次提交？
▪ 如果要查看具体修改了什么地方，可以用git diff命令，使用文件补丁的格式显示具体添加和删除的行。
▪ 要查看尚未暂存的文件更新了哪些部分，不加参数直接输入git diff： – 比较的是工作目录中当前文件和暂存区域快照之间的差异，也就是修改之后还没有暂存起来的变化内容。
▪ 若要查看已暂存起来的文件和上次提交时的快照之间的差异，可以用 git diff --cached 命令。

基本的Git命令：提交更新
▪ 在使用git commit命令进行提交之前，要确认是否还有修改过的或新建的文件没有git add过，否则提交的时候不会记录这些还没暂存起来的变化。
– 每次准备提交前，先用git status进行检查，然后再运行提交命令git commit。 ▪ 提交后返回结果：
– 当前是在哪个分支(master)提交的
– 本次提交的完整 SHA-1 校验和是什么
– 在本次提交中，有多少文件修订过、多少行添改和删改过。
▪ 提交时记录的是放在暂存区域的快照，任何还未暂存的仍然保持已修改状态，可以在下次提交时纳入版本管理。每一次运行提交操作，都是对项目做一次快照，以后可以回到这个状态，或者进行比较。

基本的Git命令：跳过使用暂存区域、移除文件

▪ Git提供了一个跳过使用暂存区域的方式，只要在提交的时候，给 git commit 加上-a 选项，Git 就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add步骤；
▪ 使用git rm命令从Git中移除某个文件，把它从已跟踪文件清单(暂存区域)中移除，并连带从工作目录中删除指定的文件。

基本的Git命令：对远程仓库的操作
▪ 远程仓库：托管在网络上的项目仓库；
▪ 多人协作开发某个项目时，需要管理这些远程仓库，以便推送或拉取数据，分享各自的工作进展。
▪ 管理远程仓库：添加远程库、移除废弃的远程库、管理各式远程库分支、定义是否跟踪这些分支。
– git remote：获取当前配置的所有远程仓库；
– git remote add [shortname] [url]：添加一个远程仓库；
– git fetch：从远程仓库抓取数据到本地；
– git pull： 从一个仓库或者本地的分支拉取并且整合代码；
– git push [remote-name] [branch-name]：将本地仓库中的数据推送到远程
仓库；
– git remote show [remote-name]：查看某个远程仓库的详细信息；
– git remote rm：从本地移除远程仓库；

Git支持分支和合并

分支是在版本控制下对对象的复制，以便可以沿两个分支平行进行修改。

合并两个分支

GitHub是人们构建软件的方式

GitHub：一个基于web的Git服务器和互联网托管服务。

它提供了Git的所有分布式版本控制和SCM功能，并添加了自己的特性。
它为每个项目提供访问控制和若干协作特性，如bug跟踪、特性请求、任务管理和wiki
私有和自由存储库(用于开源项目)

GitHub工作过程
基本流程:提交、分支和合并
协作过程:fork和pull请求

6.总结

通用软件开发生命周期(SDLC)

传统软件过程模型:瀑布，增量，原型，迭代

敏捷开发

协同软件开发

软件配置管理(SCM)

作为软件配置管理工具的Git