软件配置管理_话题_圈子与群组

项目管理者联盟 | 中国工程管理网 | 中国研发管理网

会员中心

资料库

适合敏捷开发项目
敏捷项目管理最佳实践

重视项目商业分析
商业价值与需求分析能力

产品管理国际认证
全球产品管理最佳实践

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

大型复杂项目全球标准
定位高级项目管理层

链接战略与项目
实现组织资源投资回报

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

圈子
	志同道合，朋友再聚首

会员· 圈友

圈子信息

圈名：项目管理软件
加入方式： 允许任何人加入

项目管理软件主要是项目管理软件的交流；资料的共享！欢迎有智者前来加入！！

圈主：michaeltuan 管理员：暂无管理员
成员数：76	主题数：684	排名：15

	通讯录
	圈友列表
	加入本圈
	管理本圈

发表话题 | 发起投票 | 上传资料

话题区

投票区

资料区

精华区

标题：软件配置管理楼主
michaeltuan PMB：307 省份：上海市行业：IT软件注册：2010/6/22	软件配置管理系列——1、介绍支持软件配置管理（CM）的环境和工具已经取得了相当可观的进展，本文将重点介绍业已存在的配置管理工具所提供的一些概念，包括了对这些概念的扩展或泛化。提取这些概念也并不简单，因为软件工程社区的许多CM工具的术语不尽相同，对许多概念的实现也有所不同。因此，每一个展示的概念都是存在于特定CM中的，没有任何CM系统提供了所有不同用户需要的功能。此外，每一个CM系统都只是包含了部分概念，为了完成这个报告，会简要描述例子中使用的CM系统的功能。 1、介绍通过调查现存的配置管理（CM）系统可以发现支持 CM的环境和工具已经大大改进，这可以通过CM系统提供的概念范围来证明，本文就是要强调这个范围，首先介绍一下广义的CM定义和一个典型的CM场景。 1.1 配置管理的定义软件配置管理是控制软件系统演进的学科，经典的CM讨论如[3]和[4]，IEEE 标准729-1983[16]中的定义列出了CM操作的几个方面：标识：一种标识模式反映了产品的结构，标识了组件及其类型，使之唯一并且可以通过某种方式访问。控制：控制产品的发布，并通过创建基线产品来保持软件的连续性以达到整个生命周期的变更控制。状态记录：记录和报告组件的状态和修改请求，并且收集产品中组件的重要统计。评审和复查：验证产品的完整性，通过确保产品是定义良好组件的组合来维护组件的连续性。定义也包扩配置项、基线、发布和版本等术语，大多数CM系统通过组合不同程度上的功能来支持这些方面，一些CM系统提供的功能超越了以上的定义，这归因于（抛去其他原因）多个方面的认识，如不同的用户角色（在1.3和2.1部分有进一步讨论）、异种平台的不同操作环境、建立软件工程师在其中以和谐方式工作的大项目的支持。为了捕获这些额外的功能，有必要拓宽CM的定义：制造：以一种透明的方式管理产品的构建。过程管理：确保执行组织的过程、政策和生命周期模型。团队协作：控制同一产品多个用户的工作和交互。 1.2 CM系统的定义对于CM系统的组成，没有一种普遍接受的定义。举个例子，版本控制系统是CM系统吗？理想情况下，一个CM系统应该能够提供上面定义的所有功能，但是实践中，任何提供某种形式的版本控制、配置标识、系统构建、系统建模和企图提供CM（某种程度）功能的系统都会被软件工程（和销售）社区当作CM系统。必须注意到存在的CM系统都提供了它们独有的功能组合，而不是标准的。这个报告只包括了15个 CM系统，目前至少有40 种可以获取并使用的CM系统。本文有必要阐明一个概念，CM系统和CM工具。一个CM系统可以看作是环境的一部分，CM支持的是集成环境的一部分，并且CM是以包的形式销售，一个CM工具可以被认为一个独立的工具。举个例子，Revision Control System(RCS) [15]是一种CM工具，因为它企图安装到现有的环境，但是因为这一点区别对本文并不重要，我们会用CM系统这一术语来表示这两种概念。 1.3 一个典型的CM用户场景在开始讨论CM系统之前，为了展示一个参考的框架，我们首先介绍一个组织的CM用户场景。这个场景包括了许多具备不同职责的人：一个负责软件组的项目经理，一个负责CM过程和策略的配置管理经理，一个负责开发和维护软件产品的软件工程师，一个验证产品正确性的测试员，确保产品高质量的质量保证（QA）人员和一个使用产品的客户。每一个角色都有自己的目标和任务，对于项目经理，目标是保证产品按计划开发，因此，经理监督开发过程，通过分析生成的软件状态报告，执行系统复审，及时发现问题并处理。配置经理的目标是确保代码的产生、修改和测试的过程和策略是可追踪的，同时保证项目的信息是可访问的。为了实现维护代码变更的控制的技术，这个经理引入了一种对变更进行正式请求的机制，以达到评估变更（通过一个负责确认变更的变更控制委员会（CCB））和授权变更的目的。这个经理要为工程师创建和分发任务列表并创建项目环境，另外，这个经理还要收集软件系统组件的统计信息，例如确定这个系统的哪些组件可能会出问题。对于软件工程师，目标就是有效率的创建产品，这意味着工程师不应该被非必要的工作打扰，例如他人创建和测试代码，支持产品文档等，但是与此同时，他们还要保持有效率的交流和协作。他们借助工具创建协调一致的产品，通过通知其他人关于任务需求和结束的信息来交流和协作，通过合并代码并解决冲突来将变更传递到所有人的工作中去。产品中的每个组件的演进历史都会保存，通过记录修改的内容和记录的修改原因。每个工程师都在自己的工作区域创建、修改、测试和集成代码，在特定点上，代码会纳入基线，也就是作为进一步开发的开始，也是针对其他目标机器的并行开发的改变的开始。测试员的目标是保证产品经过测试且达到满意，这包括了测试特定的版本，并且保存对应测试的记录，任何报告的错误会被反馈到合适的人，并在修正后进行回归测试。 QA 经理的目标是保证产品的高品质，这意味着特定过程和策略必须通过合适的确认，产品的缺陷必须被修正并且分发到产品的变体中，并经过进一步测试。客户对产品的抱怨也必须要跟进。客户使用产品，不同客户使用不同的版本和变体，客户依据一定的过程来请求变更以指出缺陷和改进产品。理想情况下，一个符合这个场景的CM系统必须支持所有这些目标、角色和任务，这意味着这些角色、任务和目标决定了CM系统的功能需求，这篇文章尝试展示完成这些特性的概念。 1.4 本文的组织介绍是对CM和CM系统的一个定义和CM场景的一个典型例子，因此提示了CM系统的需求。第二部分描述了对CM系统用户十分重要的CM问题，这些问题影响了用户对CM系统的期望。第三步分描述了CM概念。第四部分，展望了未来的CM系统，第五部分作出了结论。附录给出了本文参考的CM系统的总的看法。软件配置管理系列——2、用户角色[1] 2.1 用户角色就像 1.3 中的场景所描述的，一个CM系统有许多不同的用户，每一种用户都属于特定的角色，对CM系统也有不同的视角，因此对CM系统有不同的需求。图1说明了项目经理、配置经理、软件工程师、测试员、QA 经理和客户对CM系统的期望，每一个方框代表了一个功能域，图 1中的方框（审计、统计、控制、组件、结构和构建）是可以存在于任何CM系统的功能域，但是当与团队和过程功能结合后，就可以组成了一个全盘的（或者说是复杂的）CM系统。这些功能域有：组件：识别、分类、保存和访问组成产品的组件。结构：代表了产品的架构。构建：支持制品和产品的构建。审计：保持产品和过程的审计轨迹。统计：收集产品和过程的统计信息。控制：控制如何和何时进行变更。过程：支持产品功能正确性的管理。团队：支持项目团队开发和维护一系列产品。这些功能的需求会在下面详谈。对于组件的需求包括：记录组件的版本，区别和区别的原因；标识组成一个配置的组件，其中包括各个版本的组件；标识产品和其扩展的基线；确定代表特定项目组件和制品集合的项目环境。此外，用户需要版本库或运行库来保存和捕获组件和CM信息，例如保存源代码、对象代码、可执行程序、图表、文档和基线等。对于结构需求，用户需要：通过代表产品组件的列表来建立产品的模型；指出组件、版本和配置的分界点，以此使之可重用；标识和维护组件的关系；选择兼容的组件来组成正确和一致版本的产品。软件配置管理系列——2、用户角色[2] 对于构建需求，用户需要：简化构建和编译产品的过程；在任何时间对产品的状态进行快照和冻结的能力；通过减少重新编译的组件和节约空间来优化构建系统的机制；利用变更影响分析预测衍生物发生的更改；在任何给定时间更方便的重新生成任何阶段或部分的产品。对于审计需求，用户需要：所有变更的历史；在产品和他们的演化中能够追踪所有相关的组件。所有所作工作的详细日志。对于统计需求，用户需要：记录统计数据来检验产品状态的机制，更容易的生成关于产品和过程的各个方面的报告。对于控制需求，用户需要：小心的访问系统的组件防止未保证的变更和变更冲突；在线的变更请求表单和问题报告支持；也意味着要追踪问题原因、时间和处理的负责人。用一种控制的方式传递变更，贯穿不同但是相关的产品版本；分割产品达到减少变更影响的方法。对于过程需求，用户需要：支持他们的生命周期模型和组织政策；识别将要做的任务，以及这些这些任务何时和如何完成的能力；与正确的人交流相关信息的能力；和记录产品知识的工具。对于团队需求，用户需要：单独的和组的工作空间；合并修改时解决冲突的方法；支持创建和维护产品族的工具。需要注意过程框和团队框被表示成重要的功能，这是因为它们会和所有其它部分互相影响。对一个用户来说，一个理想的CM系统应该支持所有的集成了团队和过程的功能域，目前没有一个单独的系统支持所有这些功能域。 2.2 CM系统的集成任何一个CM系统都有与环境集成程度的概念，一个CM系统可以与其他工具共存或完全集成。集成包括了环境的各个方面：过程、工具集和数据库。过程集成意味着 CM系统使用模式（组成了CM过程）的结合。工具集集成意味着在环境中安装所有的CM系统，至少是与环境中的其他工具可以共存。举个例子，用户希望CM系统能够在编辑器中执行“保存”时创建一个新的版本。数据库集成关注CM数据库的逻辑位置－－是否与现存环境的数据库以某种方式合并，或者是它是一个独立的实体，或者是它利用了其它数据库的信息。所有这类集成都是普通的工具集成和技术迁移问题。但是自从CM系统尝试影响环境中的大多数对象和对象的整个生命周期的所有阶段时， CM系统的集成开始对环境中的许多工具产生了重要的影响。大多数CM系统与其他工具共存，而且有一些环境让CM成为他们自身的一部分。 2.3 何时开始使用CM系统这要看项目组何时在开发和维护的产品上开始使用CM系统。一些小组选择在产品经过了开发周期并准备好交付给客户方时，另一方面，一些小组选择从项目的一开始就将所有的事情放在CM之下。两种方式都有各自的成本，举个例子，团队会根据变更的成本作出选择，如果需要许多手工的过程（例如填写变更请求单，获得 CCB的通过和确认），团队一般会选择在开发的主要过程结束后纳入CM控制，但是如果变更请求过程可以在线操作，只需要花费较少的时间和人力，CM将会在较早的时间被引入。理论上讲，CM适应于产品的整个生命周期－－从概念、开发、产品发布、客户交付、客户使用到维护。理想情况下，CM系统必须尽可能将成本最小化，因此应该尽早将CM应用到项目。然而，现存的CM系统，容易将精力集中在产品生命周期的特定阶段，所以用户会被功能限制。
	回复 \| 引用发表时间：2010/11/8 11:07:47

xujing2247 PMB：29 省份：上海行业：IT软件注册：2008/5/30	标题：Re：软件配置管理 1 楼
	学习了
	回复 \| 引用回复时间：2010/11/10 14:02:11

chengguohong PMB：5 省份：北京市行业：金融业注册：2010/11/12	标题：Re：软件配置管理 2 楼
	哈哈，学习中
	回复 \| 引用回复时间：2010/11/12 11:33:16

刘天际 PMB：8 省份：江苏省行业：工程设计安装注册：2010/11/16	标题：Re：软件配置管理 3 楼
	受教啦
	回复 \| 引用回复时间：2010/11/16 20:19:58

刘天际 PMB：8 省份：江苏省行业：工程设计安装注册：2010/11/16	标题：Re：软件配置管理 4 楼
	受教啦！谢谢你！
	回复 \| 引用回复时间：2010/11/17 18:01:02

netflee PMB：10 省份：四川省行业：IT软件注册：2009/1/6	标题：Re：软件配置管理 5 楼
	受教啦！谢谢你！
	回复 \| 引用回复时间：2011/1/1 0:09:13

kalson PMB：1 省份：北京市行业：商业物流贸易注册：2011/1/27	标题：Re：软件配置管理 6 楼
	学习了
	回复 \| 引用回复时间：2011/2/24 22:53:35

realman PMB：75 省份：广东省行业：通信与网络注册：2011/3/9	标题：Re：软件配置管理 7 楼
	好哈了~~~~~~~
	回复 \| 引用回复时间：2011/3/9 15:24:41

dribble PMB：5 省份：北京市行业：IT软件注册：2011/2/28	标题：Re：软件配置管理 8 楼
	好
	回复 \| 引用回复时间：2011/5/7 13:11:31

wnly PMB：9 省份：新疆维吾尔自治区行业：综合应用注册：2011/6/3	标题：Re：软件配置管理 9 楼
	谢谢
	回复 \| 引用回复时间：2011/6/3 12:58:50

isrennes PMB：1 省份：河北省行业：金融业注册：2011/6/10	标题：Re：软件配置管理 10 楼
	不错，真不错。。。。。。。。
	回复 \| 引用回复时间：2011/6/10 11:28:09

！您尚未登录，不能回复主题。现在登录注册

建设运营：共创时网络

标题：软件配置管理楼主
michaeltuan PMB：307 省份：上海市行业：IT软件注册：2010/6/22	软件配置管理系列——1、介绍支持软件配置管理（CM）的环境和工具已经取得了相当可观的进展，本文将重点介绍业已存在的配置管理工具所提供的一些概念，包括了对这些概念的扩展或泛化。提取这些概念也并不简单，因为软件工程社区的许多CM工具的术语不尽相同，对许多概念的实现也有所不同。因此，每一个展示的概念都是存在于特定CM中的，没有任何CM系统提供了所有不同用户需要的功能。此外，每一个CM系统都只是包含了部分概念，为了完成这个报告，会简要描述例子中使用的CM系统的功能。 1、介绍通过调查现存的配置管理（CM）系统可以发现支持 CM的环境和工具已经大大改进，这可以通过CM系统提供的概念范围来证明，本文就是要强调这个范围，首先介绍一下广义的CM定义和一个典型的CM场景。 1.1 配置管理的定义软件配置管理是控制软件系统演进的学科，经典的CM讨论如[3]和[4]，IEEE 标准729-1983[16]中的定义列出了CM操作的几个方面：标识：一种标识模式反映了产品的结构，标识了组件及其类型，使之唯一并且可以通过某种方式访问。控制：控制产品的发布，并通过创建基线产品来保持软件的连续性以达到整个生命周期的变更控制。状态记录：记录和报告组件的状态和修改请求，并且收集产品中组件的重要统计。评审和复查：验证产品的完整性，通过确保产品是定义良好组件的组合来维护组件的连续性。定义也包扩配置项、基线、发布和版本等术语，大多数CM系统通过组合不同程度上的功能来支持这些方面，一些CM系统提供的功能超越了以上的定义，这归因于（抛去其他原因）多个方面的认识，如不同的用户角色（在1.3和2.1部分有进一步讨论）、异种平台的不同操作环境、建立软件工程师在其中以和谐方式工作的大项目的支持。为了捕获这些额外的功能，有必要拓宽CM的定义：制造：以一种透明的方式管理产品的构建。过程管理：确保执行组织的过程、政策和生命周期模型。团队协作：控制同一产品多个用户的工作和交互。 1.2 CM系统的定义对于CM系统的组成，没有一种普遍接受的定义。举个例子，版本控制系统是CM系统吗？理想情况下，一个CM系统应该能够提供上面定义的所有功能，但是实践中，任何提供某种形式的版本控制、配置标识、系统构建、系统建模和企图提供CM（某种程度）功能的系统都会被软件工程（和销售）社区当作CM系统。必须注意到存在的CM系统都提供了它们独有的功能组合，而不是标准的。这个报告只包括了15个 CM系统，目前至少有40 种可以获取并使用的CM系统。本文有必要阐明一个概念，CM系统和CM工具。一个CM系统可以看作是环境的一部分，CM支持的是集成环境的一部分，并且CM是以包的形式销售，一个CM工具可以被认为一个独立的工具。举个例子，Revision Control System(RCS) [15]是一种CM工具，因为它企图安装到现有的环境，但是因为这一点区别对本文并不重要，我们会用CM系统这一术语来表示这两种概念。 1.3 一个典型的CM用户场景在开始讨论CM系统之前，为了展示一个参考的框架，我们首先介绍一个组织的CM用户场景。这个场景包括了许多具备不同职责的人：一个负责软件组的项目经理，一个负责CM过程和策略的配置管理经理，一个负责开发和维护软件产品的软件工程师，一个验证产品正确性的测试员，确保产品高质量的质量保证（QA）人员和一个使用产品的客户。每一个角色都有自己的目标和任务，对于项目经理，目标是保证产品按计划开发，因此，经理监督开发过程，通过分析生成的软件状态报告，执行系统复审，及时发现问题并处理。配置经理的目标是确保代码的产生、修改和测试的过程和策略是可追踪的，同时保证项目的信息是可访问的。为了实现维护代码变更的控制的技术，这个经理引入了一种对变更进行正式请求的机制，以达到评估变更（通过一个负责确认变更的变更控制委员会（CCB））和授权变更的目的。这个经理要为工程师创建和分发任务列表并创建项目环境，另外，这个经理还要收集软件系统组件的统计信息，例如确定这个系统的哪些组件可能会出问题。对于软件工程师，目标就是有效率的创建产品，这意味着工程师不应该被非必要的工作打扰，例如他人创建和测试代码，支持产品文档等，但是与此同时，他们还要保持有效率的交流和协作。他们借助工具创建协调一致的产品，通过通知其他人关于任务需求和结束的信息来交流和协作，通过合并代码并解决冲突来将变更传递到所有人的工作中去。产品中的每个组件的演进历史都会保存，通过记录修改的内容和记录的修改原因。每个工程师都在自己的工作区域创建、修改、测试和集成代码，在特定点上，代码会纳入基线，也就是作为进一步开发的开始，也是针对其他目标机器的并行开发的改变的开始。测试员的目标是保证产品经过测试且达到满意，这包括了测试特定的版本，并且保存对应测试的记录，任何报告的错误会被反馈到合适的人，并在修正后进行回归测试。 QA 经理的目标是保证产品的高品质，这意味着特定过程和策略必须通过合适的确认，产品的缺陷必须被修正并且分发到产品的变体中，并经过进一步测试。客户对产品的抱怨也必须要跟进。客户使用产品，不同客户使用不同的版本和变体，客户依据一定的过程来请求变更以指出缺陷和改进产品。理想情况下，一个符合这个场景的CM系统必须支持所有这些目标、角色和任务，这意味着这些角色、任务和目标决定了CM系统的功能需求，这篇文章尝试展示完成这些特性的概念。 1.4 本文的组织介绍是对CM和CM系统的一个定义和CM场景的一个典型例子，因此提示了CM系统的需求。第二部分描述了对CM系统用户十分重要的CM问题，这些问题影响了用户对CM系统的期望。第三步分描述了CM概念。第四部分，展望了未来的CM系统，第五部分作出了结论。附录给出了本文参考的CM系统的总的看法。软件配置管理系列——2、用户角色[1] 2.1 用户角色就像 1.3 中的场景所描述的，一个CM系统有许多不同的用户，每一种用户都属于特定的角色，对CM系统也有不同的视角，因此对CM系统有不同的需求。图1说明了项目经理、配置经理、软件工程师、测试员、QA 经理和客户对CM系统的期望，每一个方框代表了一个功能域，图 1中的方框（审计、统计、控制、组件、结构和构建）是可以存在于任何CM系统的功能域，但是当与团队和过程功能结合后，就可以组成了一个全盘的（或者说是复杂的）CM系统。这些功能域有：组件：识别、分类、保存和访问组成产品的组件。结构：代表了产品的架构。构建：支持制品和产品的构建。审计：保持产品和过程的审计轨迹。统计：收集产品和过程的统计信息。控制：控制如何和何时进行变更。过程：支持产品功能正确性的管理。团队：支持项目团队开发和维护一系列产品。这些功能的需求会在下面详谈。对于组件的需求包括：记录组件的版本，区别和区别的原因；标识组成一个配置的组件，其中包括各个版本的组件；标识产品和其扩展的基线；确定代表特定项目组件和制品集合的项目环境。此外，用户需要版本库或运行库来保存和捕获组件和CM信息，例如保存源代码、对象代码、可执行程序、图表、文档和基线等。对于结构需求，用户需要：通过代表产品组件的列表来建立产品的模型；指出组件、版本和配置的分界点，以此使之可重用；标识和维护组件的关系；选择兼容的组件来组成正确和一致版本的产品。软件配置管理系列——2、用户角色[2] 对于构建需求，用户需要：简化构建和编译产品的过程；在任何时间对产品的状态进行快照和冻结的能力；通过减少重新编译的组件和节约空间来优化构建系统的机制；利用变更影响分析预测衍生物发生的更改；在任何给定时间更方便的重新生成任何阶段或部分的产品。对于审计需求，用户需要：所有变更的历史；在产品和他们的演化中能够追踪所有相关的组件。所有所作工作的详细日志。对于统计需求，用户需要：记录统计数据来检验产品状态的机制，更容易的生成关于产品和过程的各个方面的报告。对于控制需求，用户需要：小心的访问系统的组件防止未保证的变更和变更冲突；在线的变更请求表单和问题报告支持；也意味着要追踪问题原因、时间和处理的负责人。用一种控制的方式传递变更，贯穿不同但是相关的产品版本；分割产品达到减少变更影响的方法。对于过程需求，用户需要：支持他们的生命周期模型和组织政策；识别将要做的任务，以及这些这些任务何时和如何完成的能力；与正确的人交流相关信息的能力；和记录产品知识的工具。对于团队需求，用户需要：单独的和组的工作空间；合并修改时解决冲突的方法；支持创建和维护产品族的工具。需要注意过程框和团队框被表示成重要的功能，这是因为它们会和所有其它部分互相影响。对一个用户来说，一个理想的CM系统应该支持所有的集成了团队和过程的功能域，目前没有一个单独的系统支持所有这些功能域。 2.2 CM系统的集成任何一个CM系统都有与环境集成程度的概念，一个CM系统可以与其他工具共存或完全集成。集成包括了环境的各个方面：过程、工具集和数据库。过程集成意味着 CM系统使用模式（组成了CM过程）的结合。工具集集成意味着在环境中安装所有的CM系统，至少是与环境中的其他工具可以共存。举个例子，用户希望CM系统能够在编辑器中执行“保存”时创建一个新的版本。数据库集成关注CM数据库的逻辑位置－－是否与现存环境的数据库以某种方式合并，或者是它是一个独立的实体，或者是它利用了其它数据库的信息。所有这类集成都是普通的工具集成和技术迁移问题。但是自从CM系统尝试影响环境中的大多数对象和对象的整个生命周期的所有阶段时， CM系统的集成开始对环境中的许多工具产生了重要的影响。大多数CM系统与其他工具共存，而且有一些环境让CM成为他们自身的一部分。 2.3 何时开始使用CM系统这要看项目组何时在开发和维护的产品上开始使用CM系统。一些小组选择在产品经过了开发周期并准备好交付给客户方时，另一方面，一些小组选择从项目的一开始就将所有的事情放在CM之下。两种方式都有各自的成本，举个例子，团队会根据变更的成本作出选择，如果需要许多手工的过程（例如填写变更请求单，获得 CCB的通过和确认），团队一般会选择在开发的主要过程结束后纳入CM控制，但是如果变更请求过程可以在线操作，只需要花费较少的时间和人力，CM将会在较早的时间被引入。理论上讲，CM适应于产品的整个生命周期－－从概念、开发、产品发布、客户交付、客户使用到维护。理想情况下，CM系统必须尽可能将成本最小化，因此应该尽早将CM应用到项目。然而，现存的CM系统，容易将精力集中在产品生命周期的特定阶段，所以用户会被功能限制。
	回复 \| 引用发表时间：2010/11/8 11:07:47