多语种 小语种网站推广方法,nginx wordpress 优化,国外网站空间租用哪个好,wordpress小工具文件夹软件配置管理
第一章
1#xff0c;软件配置管理用于控制变化
2#xff0c;软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则#xff0c;它是控制软件系统演变的学科。
3#xff0c;软件配置…软件配置管理
第一章
1软件配置管理用于控制变化
2软件配置管理(Software Configuration Management, SCM)是指一套管理软件开发和维护过程中所产生的各种中间软件产品的方法和规则它是控制软件系统演变的学科。
3软件配置管理是一种标识、组织和控制修改的技术软件配置管理应用于整个软件工程过程
4SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更
5从某种角度讲SCM的目的是使错误降为最小并最有效地提高生产效率。
6软件配置管理定义
软件配置管理是贯穿于整个软件过程中的保护性活动它被设计用来
(1) 标识变化(2) 控制变化(3) 保证变化被适当的发现(4) 向其他可能有兴趣的人员报告变化
7配置管理是否有成效取决于三个要素人、规范、工具。
8软件配置是一个软件产品在生存期各个阶段的不同形式记录特定信息的不同媒体和不同版本的程序、文档及相关数据的集合或者说是配置项的集合
9软件配置是一个集合该集合中的每一个元素称为该软件产品软件配置中的一个配置项Software Configuration ItemSCI。
10常见的软件配置项需求规格说明书、设计规格说明书、源代码、测试计划、测试用例、用户手册等
11基线(Baseline)是指一个或一组配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是软件生命周期中各开发阶段的一个特定点它的作用是把开发各阶段工作的划分更加明确化使本来连续的工作在这些点上断开以便于检查与肯定阶段成果
12基线是已经正式通过复审和批准的某规约和产品它因此可作为进一步开发的基础并且只能通过正式的变化控制过程来改变。基线通常标志开发过程一个阶段的结束里程碑。
13里程碑(Milestone)是检查点 (Check Point)检查点不一定是里程碑因为检查点还可以是时间、计划和事件
14功能基线所规定的对待开发软件系统的规格说明
15指派基线又称为分配基线指在软件需求分析阶段结束时经过正式评审和批准的软件需求的规格说明指派基线是最初批准的指派配置标识。
16产品基线指在软件组装与系统测试阶段结束时经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明产品基线是最初批准的产品配置标识
17软件配置控制委员会(Software Configuration Control Board, SCCB)负责管理软件配置项变更的组织。
具体责任如下
评估变更批准变更请求在生命周期内规范变更申请流程对变更进行反馈与项目管理层沟通
18软件配置管理是在贯穿整个软件生命周期中建立和维护项目产品的完整性。它的基本目标包括
目标 1: 软件配置管理的各项工作是有计划进行的。
目标 2: 被选择的项目产品得到识别控制并且可以被相关人员获取。
目标 3: 已识别出的项目产品的更改得到控制。
目标 4: 使相关组别和个人及时了解软件基准的状态和内容。
第二章
1软件配置管理角色
PM: 项目经理CCB: 配置控制委员会CMO: 配置管理员SIO: 系统集成员DEV: 开发人员
2项目经理Project ManagerPM
根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。
职责制定和修改项目的组织结构和配置管理策略批准、发布配置管理计划
决定项目起始基线和开发里程碑接受并审阅配置控制委员会的报告。
配置控制委员会Configuration Control BoardCCB
负责指导和控制配置管理的各项具体活动的进行为项目经理的决策提供建议。
职责定制开发子系统定制访问控制制定常用策略建立、更改基线的设置审核变更申请根据配置管理员的报告决定相应的对策。
配置管理员Configuration Management OfficerCMO
根据配置管理计划执行各项管理任务定期向CCB提交报告并列席CCB的例会。
职责软件配置管理工具的日常管理与维护提交配置管理计划各配置项的管理与维护执行版本控制和变更控制方案完成配置审计并提交报告对开发人员进行相关的培训识别软件开发过程中存在的问题并拟定解决方案。
系统集成员System Integration OfficerSIO
系统集成员负责生成和管理项目的内部和外部发布版本。
职责集成修改构建系统完成对版本的日常维护建立外部发布版本。
开发人员DeveloperDEV
开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定按照软件配置管理工具的使用模型来完成开发任务。
34软件配置管理过程包括7项基本活动
(1) 制定配置管理计划(2) 识别和标志配置项(3) 搭建配置管理环境(4) 配置项的版本控制(5) 基线变更管理(6) 配置审核(7) 配置状态统计
5制定配置管理计划
配置管理计划的主要内容
配置管理组织及其职责配置管理工具和配置库的组织结构配置项标志和基线定义
变更管理流程配置审核和配置状态统计
6识别和标志配置项
1为每一个配置项分配唯一的标志建立配置项间的对应关系
2两类配置项
基本配置项软件开发者在项目开发过程中所创建的基本工作单元。
集成配置项一个集成配置项是基本配置项或其它集成配置项的集合。
7搭建配置管理环境
配置管理环境是用于进行软件配置管理的系统环境其中最重要的是配置管理库简称配置库
配置库存储配置项 (SCI)、修改请求、变化记录等并提供对库中所存储文件的版本控制
一般需采用配置管理工具来建立配置库。
8配置项的版本控制
配置库的检入检出和版本控制机制解决了软件开发中的两个重要问题
访问控制保证具有相应权限的人员才能修改配置项。
并行控制保证不同人员同时对某配置项进行的修改不会互相覆盖。
对配置项的修改不同版本间的差别应被记录下来。
更动者姓名及其身份更动日期和时间被更动SCI名及其版本号
更动内容及其位置更动原因受此更动影响的诸SCI名表。
软件产品版本编号方法
数字顺序型版本编号
普通版本编号
x.y.zx为主版本号y为特征版本号z为缺陷修复版本号如V3.10.16。
主版本号的增加表示提供给客户的主要产品功能的增强。
特征版本号的增加表示产品新增了一些特征或做了一些重要修改。
缺陷修复版本号的增加表示在软件产品上做了一些缺陷修复工作。
α和β版本编号
在普通版本编号后面增加一个大写字符A或者B来分别表示α版本或β版本。例如1.2.4A或1.2.4B。
如果存在多次的α发布和β发布可在A或B后面添加一个数字来说明发布的次数例如1.2.5A11.3.0B2。
α测试是由公司内部的用户在模拟实际操作环境下进行的测试。
β测试是由软件的多个用户在实际使用环境下进行的测试。
属性版本编号
把版本的重要属性反映在标识中。可以包括的属性有客户名、开发语言、开发状态、硬件平台、生成日期等。例如 J2SDK.v.l.2.2:10/31/2000-18:00,native threads, jit-122
包含的信息丰富方便了查询和管理版本间的关系易于保持但由于太复杂一般只用于软件组织内部的管理
9基线变更管理
变更批准或拒绝
根据评估结果对变更作出决策
直接实现变更挂起或延迟变更拒绝变更
对于批准的变更要确定其实现进度
立即实现变更在特定的日期实现变更在软件另外的版本中实现
变更实现
10配置审核
配置管理活动审核确保所有配置管理活动符合已批准的软件配置管理规程
基线审核审核基线配置项的完整性和一致性从而保证基线配置项可被正确地构造。
11配置状态统计和报告
变更请求的数量。变更管理活动的执行情况。
配置管理系统存储量的变化。配置管理系统和SCCB在运作中发生异常的次数
第三章
1CMM/CMMI将软件配置管理的活动分为6个方面每个方面又再进行了细分
SCM过程管理软件配置标识软件配置控制软件配置状态统计软件配置审计软件发布管理和交付
2在CMM和CMMI中将配置管理的目的定义为建立和维护产品的完整性
3配置完整性对标准的理解
产品完整性项目提交的工作成果是产品集合完整、子产品正确的
产品集合完整产品包含的子产品配置项是完整的
子产品正确子产品配置项达到了需求要求满足标准、规程的要求
4三库管理三库的概念源自CMM/CMMI即开发库、受控库和产品库。配置项在三库之间迁移一级比一级的控制更严格。
5软件开发组日常的工作在开发库中开展当工作达到里程碑时再迁移到受控库在受控库中经过更严格的测试后再上升到产品库最后发布。
6在实践中三库常常被实现为物理上的三库而不是通过逻辑的方式来实现三库物理隔离带来的最大问题是配置项失去了历史可追溯性
7实现三库的指导思想应该是逻辑上独立物理上在一起通过权限与流程的控制来实现配置项在不同库之间的流转以及相应角色的人员对相应库的访问。
CMM2在配置管理方面主要针对于实现部分;CMM3将配置管理扩展到需求、规格说明、设计和工具
SCM意义
记录软件产品的演化过程
确保软件开发者在软件生命周期中的各个阶段都能得到精确的产品配置
最终保证软件产品的完整性、一致性、追朔性、可控性;。
10每个基线都将接受配置管理的严格控制对其的修改将严格按照变更控制要求的过程进行在一个软件开发阶段结束时上一个基线加上增加和修改的基线内容形成下一个基线这就是基线管理的过程
11建立基线的好处重现性可追踪性版本隔离。
基线管理的步骤
(1) 在开发前确定基线的配置(2) 基线批准前根据配置检查配置项是否齐备
(3) 对各个配置项确认其版本的正确性(4) 对每个配置项建立基线标志
(5) 基线变更管理(6) 基线的各类报告和审计信息。
12变更管理的流程
获得提出变更请求由CCB审核并决定是否批准
为被接受修改请求分配人员提取SCI进行修改
提交修改后的SCI并测试或者评审重建软件的适当版本
复审审计所有SCI的变化发布新版本。
—可以通过两种表格来帮助发现受到变更影响的内容一种是《需求跟踪表》一种是《配置项依赖关系表》
13配置库管理
(1)设置配置库即文件夹设置和设置版本的分支
(2)为每个配置项从建立开始就划分成3个不同的分支私有分支、集成分支、公共主干分支
私有分支开发人员的私有开发空间开发人员
集成分支开发团队的公共空间由系统集成员及相关指定人员负责所有涉及多人协调的开发工作如集成测试等都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限而其他成员只有只读权限。
公共主干分支整个软件开发组织的公共空间:系统集成员:各个开发小组在现阶段的任务完成后将可以发布的版本归并到该分支上,对组织内的全体软件人员开放只读权限
上面定义的3类工作空间分支由配置管理员统一管理
(3)按配置项类型分类建库和按任务建库。
(4)配置库的日常工作对配置库的定期备份清除无用的文件和版本检测并改进配置库的性能等
14,配置审计主要作用是作为变更控制的补充手段来确保某一变更需求已被切实实现
记录了谁修改了这个工件什么时候做的修改为什么原因做出这个改动以及修改了哪些地方。 Who、When、Why、What
同时配置审计工作该应当说明如下信息
(1) 变更要求被完成并且对附加的修改已经执行了 (2) 采用了正确的正式验证手段
(3) 遵循了标准的要求 (4) 变更的4W信息被完整记录并和相关配置项关联
配置审计有两种:
PCA (Physics Configuration Audit)-----非配置管理人员
主要是检查版本是否正确一致。(1) 配置项是否齐备(2) 版本是否齐全由非配置管理人员来进行。
FCA (Function Configuration Audit) -----CMO
检查配置项是否完整各种过程文档是否齐备、正确、与需求是否一致归结为两点即完全和齐备。
15配置审计
When软件交付或release时每个阶段结束时对于维护性项目周期性地进行
Who非本项目组成员其他项目中的配置控制者内部审计者SCM小组
配置审计步骤How-审计流程
(1) 由项目经理决定何时进行配置审计工作识别配置审计的时间[PM]
(2) 质量保证组或项目组的配置管理组制定该项目的配置审计人员指派审计者[QA/Audit Group]
(3) 项目经理和配置审计员决定审计范围定义审计范围[PMAuditors]
(4) 配置审计员准备配置审计检查单准备配置审计Checklist[Auditor]
(5) 配置审计员安排时间审计文档和记录审计活动可能涉及到项目范围配置项的入库(check in)及出库(check out)评审记录配置项的变更历史测试记录文件的命名变更请求和版本的编号等
通过评审Review、文档记录进行审计[Auditor]
(6) 配置审计员在审计中发现不一致现象并作记录识别不符合项[Auditor]
(7) 由项目经理负责消除不一致现象关闭不符合项[PM]
(8) 配置审计员验证所有发现的不一致现象确已得到解决验证[Auditor]
16配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况
应该是定期进行并尽量通过CASE工具自动生成用数据库中的客观数据来真实的反映各配置项的情况。
应着重反映当前基线配置项的状态以作为对开发进度报告的参照
17软件配置管理最佳实践
统一标识配置项并存入安全的配置管理系统控制和审计配置项的变更合理组织配置项
在项目的里程碑建立相应的基线记录和跟踪变更请求过程驱动的软件配置管理
维护稳定而一致的工作空间支持并行开发尽早和持续集成
确保有能力重现软件的构建过程把握好工具、流程和人员三者之间的关系善用模式和反模式
18模式可以指导我们如何成功应用前人的实践避免犯前人犯过的错误提高SCM的实施成功率。
反模式是指那些在特定情况下不应该采取的策略和方式。
第4章
1软件配置管理计划 人员及职责配置管理软硬件资源配置项计划基线计划配置库备份计划
2配置库管理报告 基本信息项目成员的操作权限配置项记录基线记录配置库备份记录配置项交付记录配置库重要操作日志
3配置项变更控制报告 变更申请审批变更申请变更配置项结束变更
4配置状态报告 (Configuration Status Report)目的有效记录和报告管理配置所需要的信息及时、准确地给出软件配置项的当前状态供相关人员了解以加强配置管理工作
内容
各份变更请示概要变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期
基线库状态库标识、至某日预计库内配置项数、实际配置项数
发行信息发行版本、计划发行时间、实际发行日期、说明
备份信息备份日期、介质、备份存放位置
配置管理工具状态
配置管理培训状态
5配置审计目的验证配置项信息与配置标识需求、标准、流程…的一致性4W
配置审计报告内容配置项状态统计基线库基线统计变更统计审计中发现的主要问题
第5章
1配置管理模式分类 描述工作区结构的模式 描述码线结构的模式
2码线(codeline)–源代码文件与组成某个软件组件的其他人工制品配置项随着时间而变更的进展过程。
码线包含沿着一条路径发展的各个配置项的每个版本
3与码线有关的模式主线 活动开发线 码线策略 私用版本 版本线 版本预备线 任务分支4与工作区有关的模式 私有工作区储存库 私有系统构造 集成构造 第三方码线任务级提 冒烟测试 单元测试 回归测试
主线——问题 如何使当前活动码线的数目保持在容易管理的水平避免项目的版本树长得太宽太密如何使合并的开销减至最小
解决方案简化分支模型开发单个产品版本时在主线上进行开发。分支时先考虑总体战略然后再创建分支
6分支是组织文件版本和显示版本历史的手段是隔离变更的强有力机制。
7主线既要使码线的并发性达到最大又要使推迟集成可能造成的问题减至最小
8私有工作区——问题 如何跟上不断变化的码线并取得进展而不会为环境变化而分心
解决方案以隔离工作的方法控制变更 (Isolate your work to change control)
储存库——问题如何获得填充新工作区的正确组件的正确版本11
冒烟测试(Smoke Test)如何知道系统在你变更后仍能工作
描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程
是确定和修复软件缺陷的最经济有效的方法缺点在于覆盖面很有限。执行者是开发人员或版本编译人员
12每次构造都必须进行冒烟测试以显而易见的方式验证应用未被损坏。
13单元测试(Unit Test)如何测试模块经你变更后是否仍能像预期一样工作
14回归测试(Regression Test)如何确保现有的代码没有因你进行其他改进而变得更糟
15每日构建 (Daily Build)
就是把一个软件项目的所有的最新的代码从配置库中取出然后从头进行编译、链接和运行。通常由工具自动完成构建自动化。
daily build 的另一个重要功能就是验证软件中各模块关系是否正确也可称为每日集成。
第9章
1版本库Repository按照一定格式存储了所有数据包括文件和目录
经过授权的客户端可以连接到版本库读写库中的文件
版本库和普通文件服务器的不同版本库会记录每一次的更改
2版本控制系统的核心任务协作编辑和数据共享
3拷贝-合并模型假定文件是可以通过上下文合并的。通常情况下文本文件例如源代码以及用纯文本HTMLTXT等格式保存的文档因为其内部结构直观可知容易理解上下文所以用拷贝-合并方案较好。而二进制文件例如用Microsoft Word格式说PDF等格式保存的文档及图片声音可执行文件库等内部结构复杂且不容易理解更改处的上下文采用锁定-解锁方案较好
4Subversion主要采用拷贝-修改-合并模型配合锁定-修改-解锁模型管理数据的共享
5工作拷贝Working Copy是本地机器的一个普通的目录是私有工作区
6修订版本Revision每当一次提交完成后版本库的文件系统就进入了一个新的状态叫做一次修订Revision。在版本库中最新的一个修订版本称为HEAD
7CheckOut从版本库中取出某个目录的拷贝到本机上某个目录的操作
例svn co svn://192.168.0.1/svnrepos/skizcorp/trunk
-r 1452 会检出1452版如果存在的话-N不递归仅针对顶层目录否则目录递归默认常用
8Update把版本库的修改同步到本地
例1up 直接把工作拷贝更新到最新版HEAD版
例2up -r 2007 更新到2007版
例3up doc/design 只更新doc/design下的文件
9BASE版某个文件的BASE版本是指存放在管理目录.svn中的该文件拷贝的版本Revert会使该文件回到BASE版本
10Revert是指放弃对某个文件的修改------revert abc.c 丢弃对abc.c的所有修改
11当文件发生冲突时SVN会额外创建3个不受版本控制的文件
12add把一个文件加入SVN版本控制系统delete从版本控制系统中移除
move(rename)移动或者重命名mkdir创建目录copy拷贝commit提交
status检查工作拷贝的状态diff检查更改的内容
13分支(Branch)是开发的一条支线。它独立于其他开发的线路并且和其他线路并行开发
所有的分支都有共同的历史有着原先共同的主线(Trunk)
14创建分支使用copy命令copy 源目录 目标目录
例先把目录checkout到本地在本地执行copy命令后提交至版本库
svn co svn://localhost/ svn copy trunk/ branches/mybranch svn commit –m “My branch created”
svn copy svn://localhost/trunk svn://localhost/branches/mybranch –m “My branch”
15Switch操作可以使工作拷贝在不同的分支之间或者在位于不同服务器上相同的版本库的分支间切换。它的作用是改变工作拷贝对应的URLswitch [–relocate] 目标URL
16,分支的合并是指把修改从分支拷贝到主干或者把主干的修改拷贝到分支的过程。
传统方法diff patch(只适用于文件内容)
例子取出主干2000版到2007版的修改然后把它应用到工作拷贝
svn diff –r 2000:2007 svn://localhost/trunk patchfilepatch –p0 patchfilemerge 初始版本树 最终版本树 目标(能够处理目录树的修改而不限于单个文件内容)
例子
merge svn://localhost/trunk2000 svn://localhost/trunk2007 my_wc
merge –r 2000:2007 svn://localhost/trunk my_wc
17,tag通常tag对应于milestone是一个完整可用的版本不能修改是只读的
branch是trunk或tag的分支可以修改是可写的用于做并行开发
18常用的SVN命令
命令名称
功能
svn add
往版本库中添加新的文件
svn checkout
将文件checkout到本地目录
svn cleanup
递归清理工作拷贝
svn commit
将改动的文件提交到版本库
svn copy
拷贝文件
svn delete
删除文件
svn diff
比较差异
svn export
导出目录树
svn import
导入目录树
svn info
打印作者、时间戳、日志信息大小和日志信息
svn list
版本库下的文件和目录列表
svn lock
文件加锁
svn log
查看日志
svn merge
将两个版本之间的差异合并到当前文件
svn mkdir
创建纳入版本控制下的新目录
svn move
移动一个文件或目录
svn resolved
移除工作副本的目录或文件的冲突状态
svn revert
恢复本地修改
svn status
查看文件或者目录状态
svn switch
代码库URL变更
svn unlock
文件解锁
svn update
更新到某个版本
第8章
1两种版本控制模型
Lock-Modify-Unlock Model (加锁-修改-解锁)CVSSVNVSS2005
Copy-Modify-Merge Model (拷贝-修改-合并)VSS6.0PCVS
2基于拷贝—修改—合并的并发控制
客户端check out后有文件的一份独立拷贝。
开发者在自己的工作目录中修改文件。
若有版本冲突则使用合并merge功能与其它开发者的修改合并然后提交check in。
第6章
1常用的配置管理工具Visual SourceSafeVSS CVS SubversionSVN Borland StarTeam IBM Rational ClearCase ClearQuest Hansky Firefly
ClearCaseFirefly支持异地开发与开发工具的集成非常好价格昂贵
VSS仅支持windows,其他支持常见平台与vs无缝集成与其他开发工具集成性差
2软件配置管理工具的主要功能
版本控制变更管理配置审核配置审计
配置状态统计查询和报告问题跟踪跟踪缺陷和变更访问控制和安全控制
3ClearCase主要应用于复杂产品的并行开发、发布和维护其功能划分为四个范畴版本控制Version Control、工作空间管理Workspace Management、构造管理Build Management、过程控制Process Control。
4ClearCase把所有版本控制的数据存放在一个永久、安全的存储区中这个存储区被称为版本对象类Version Object Bases
A VIEW selects versions of elements
What is seen is the result of an ordered set of rules called a configuration specification (config spec).
Selected versions appear in a standard directory tree with recognizable file names.
View分为SnapShot View和Dynamic ViewSnapshot view是ClearCase在服务器上存储的文件和目录的一个本地镜像Dynamic View是动态试图它并不在本地存储任何文件始终和服务器保持一致。
软件配置管理工具选择功能是否符合团队特点性能费用是售后服务易用性
序号
活动名称
角色
活动描述
参考
1
计划配置管理 配置管理经理
CCB
制定配置管理策略 制定变更控制策略 编写配置管理计划 评审配置管理计划
《配置管理计划》模板
2
创建配置管理环境 配置管理经理
设置硬件环境 设置网络环境 设置软件环境
建立一个配置管理库储存项目中定义的配置项安装配置管理工具例如 VSS等。
提供配置管理培训
《VSS使用手册》
《组织管理配置库使用指南》
3
配置项的标识 配置管理经理
对文档类的配置项进行的标识,参见附录B 对程序(coding、模型)的配置项进行标识 《软件开发文档命名约定》
4
建立基线 配置管理经理
集成员
标识基线根据配置管理计划对经过测试或者评审通过的工件进行标识。 审批基线CCB负责召开会议评审配置管理经理建立的基线。 发布基线将建立的基线向相关人员发布。 《配置管理计划模板》
《基线策略指南》
5
报告配置状态 配置管理经理
根据配置管理计划收集配置活动数据 编写配置状态报告。
《配置状态报告》模板
6
执行配置审计 配置管理经理
根据配置管理计划定期地执行配置审计它包括 物理审计 功能审计 编写配置审计报告
《配置审计报告》模板
7
变更控制管理 CCB
任意角色
参见《变更控制规范》 《文档变更请求》
