软件构造笔记——2.1 软件开发模型与软件配置管理

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接: https://blog.csdn.net/lll_90/article/details/92225475

这里,将Software Development Lifecycle 简写为SDCL,将Software Configuration Management简写为SCM。
1.软件开发的目标是活力与较长的生命周期。
2.传统设计模式从基本的,可以分为两种:线性的(瀑布模型、增量模型)与迭代的(原型法、螺旋模型)
还有特殊的V模型是,基于验证的。
3.最佳的开发方式主要考虑的是:用户参与(适应变化需要),高效开发,项目管理,软件的质量。

传统开发模式中,
1)瀑布模型的开发过程:
用户需求-> 设计->实现-> 验证->维护
2)增量模型:即将整个产品分成几个增量,逐一完成;
注意:一旦开始开发某增量,则该增量的对应需求被冻结
3)V-模型:瀑布模型的拓展,随着开发的完成度,进行强化测试
在这里插入图片描述纵轴是抽象程度,横轴是项目的完整度或时间

3.模型法与瀑布法的不同之处在于迭代式的用户反馈,有助于开发者更精确地理解用户需求,对后面的开发计划进行预估(ddl等)
在这里插入图片描述3.螺旋形模型:由风险驱动,每一轮迭代开始,根据风险评估,选择最适合的传统模型(上面提到过的一种)
在这里插入图片描述
4。而现在流行的是敏捷开发, pair programming ,尊重用户的需求,对用户的需求变化,及时做出调整。 最重要的是开发周期短,在反复评价的过程中,规格说明不是固化的
在这里插入图片描述敏捷开发主要有两种方式:
1.XP(特点是与用户一起coding)
2.scrum(特点是将任务分割,小组合作,各自开发,定期进行交流)

版本控制
软件配置管理的目的是控制版本和建立基线。
软件配置项是软件配置管理的基本单位,包括源代码、数据、文档(系统说明,代码的规格说明,测试方案等)、软硬件、环境等。
软件配置项由软件配置数据库管理.
软件配置管理数据库的更新有check_in(用户或开发者获取版本)和check_out(用户提交修改过的版本)的过程。
check_in 和check_out都有一个和配置管理数据库交互的过程,是基于一个CMDB控制下的软件版本基线,对某一部分的版本进行修改。访问的权限由一个access control进行是否可修改的开锁解锁控制。

在这里插入图片描述
版本控制系统是分布式还是中心式的关键在于用户是否用于所有的版本备份,可以满足用户之间相互传递数据。(分布式也是有控制所有版本的服务器滴)

术语:head指当前版本
working copy 指当前本地可进行编辑修改的备份。
git仓库分为3部分:工作区(Modified)、缓存区(Staged)、.git目录(保存了仓库的各版本控制数据)(Committed)。

尤其要注意的是:在传统的VCS中,保存的是每个版本的增量(即发生修改的部分);而在git中,保存整个发生修改过的文件,且每个文件的每个版本只保存一次,然后每个版本共享。如下图:在这里插入图片描述
注意git命令的理解下面是一个例子
注意git merge的两种情况
master是被合并分支的祖先
在这里插入图片描述master不是被合并分支的祖先,于是两者形成一个新的版本。
在这里插入图片描述在分工合作开发的过程中,随着合作方版本的更新,可以通过git fetch 命令将远程的版本克隆到本地仓库,与本地仓库中已git commit的部分通过git merge 命令进行合并。
图示如下:
在这里插入图片描述

猜你喜欢

转载自blog.csdn.net/lll_90/article/details/92225475
今日推荐