软件构造课程笔记(2)——第二章总结（待更新）

上一章讲的是软件构造的结果形态和评价维度

这一章讲软件开发的过程（从无到有、从有到好）

参考资料：

MIT 6.031：05、28

CMU 17-214：Nov 19、Nov 21

软件工程——实践者的研究方法：第2-3、22章

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

软件开发的生命周期(Software Development Lifecycle,SDLC)

从无到有：计划->分析(获取需求)->设计->写代码->测试->运行维护

从有到好：更新维护

传统的软件开发过程模型

两种大类：线性过程模型；迭代过程模型

迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。循环往复这个过程，直到用户满意为止。时间代价高，但开发质量也高。

已有的模型：

瀑布过程模型（线性非迭代）（管理简单、无法适应需求增加/变化）

增量过程模型（线性非迭代）（增量式，瀑布模型的改进--多个瀑布的串行）（比较容易适应需求的增加、难以适应已有需求的变化）

V字模型（瀑布模型的扩展）（V代表verification和validation）

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

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

选择合适的过程模型的依据

用户参与程度（适应变化的能力）

开发效率，管理复杂度

开发出的软件的质量

敏捷开发(Agile development)和(eXtreme Programming,XP)

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

敏捷宣言：

个人交互胜于过程管理和工具

可用软件胜于繁杂的文档

客户协作胜于硬性合同规定

响应变化胜于遵循硬性计划

敏捷（Agile）=增量+迭代（每次迭代处理一个小规模增量）

敏捷开发强调：

极限的用户参与

极限的小步骤迭代

极限的确认/验证

传统计划驱动开发：把每个阶段整个环节分布清楚按计划严格实施软件开发的管理

敏捷开发：把整个开发任务列为任务清单或开发列表进行快速开发快速迭代，每次解决一个小问题

敏捷开发方式：极限编程

编码时强调重构（不改变软件外部接口情况下，对内部代码进行改变以提升质量）

进行协作编程（两个人一组，一个实现，一个评审）

项目管理方法：任务看板机制

敏捷开发方法：冲刺模型（Scrum）

软件配置管理(Software Configuration Management,SCM）

软件配置管理：追踪和控制软件的变化

核心：版本控制和基线的确认

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

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

配置管理数据库（CMDB）：存储软件的各配置项随时间发生变化的信息+基线

版本控制优势：

个人：

回滚到上一个版本

比较两个版本的差异

备份软件版本历史

获取备份

合并

团队：

在多个开发者之间共享和协作

记录每个开发者的动作，便于“审计”

版本控制系统的特点：它允许多人一起工作

可以合并版本

可以追踪责任

允许程序员独立工作

允许多个程序员共享未完成的工作

版本控制系统的类型：

本地版本控制系统：仓库存储于开发者本地机器，无法共享和协作

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

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

Git

一个Git仓库包括：

工作目录：本地文件系统

暂存区：隔离工作目录和Git仓库

.git 目录：本地的CMDB（配置管理数据库）

Git的所有操作都是在一个图数据结构（对象图）上进行

对象图：

一个有向无环图

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

对象图中的每个节点是一个commit

每个commit指向一个父亲

多个commit指向同一个父亲：分支

一个commit指向两个父亲：合并

HEAD指向了当前分支的当前commit

从另一台机器/服务器复制git项目意味着复制整个对象图

2.2 软件构造过程、系统与工具