上一章讲的是软件构造的结果形态和评价维度
这一章讲软件开发的过程(从无到有、从有到好)
参考资料:
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 软件构造过程、系统与工具