以知识为核心的ALM之变更管理篇.doc
以知识为核心的 ALM 之变更管理篇 变更管理作为贯穿于软件开发应用生命周期各个阶段的关键要素,旨在准确地记录软件产品的演化过程,帮助开发人员在 ALM 各个阶段得到不同版本的产品配置。其中,在任务和缺陷跟踪及版本控制过程中,通过变更管理系统,开发人员需要记录和查找源码和文档变更的原因、时间以及影响,并反映其工作的效率及进度;开发经理需要保证所有代码的可靠性,并约束团队成员执行变更的权限;有时,开发项目的甲方还需要查看与产品特性或缺陷对应关联的源码文件。 很多公司通过版本控制系统来管理源码及各类文档的变更,却往往忽略了与任务跟踪和项目管理过程真 正意义上的集成,致使变更管理和开发过程一定程度上的脱节。本文将介绍一种新型的变更管理模型。该模型将很大程度地提高软件开发中变更管理的效率。 开发过程中的两类变更 在软件开发过程中,变更主要体现为以下两种方式:第一类是不需要变更代码就能完成,如设计、测试和各种与文档相关的任务等;另外一类则与源代码相关的开发任务,包括新缺陷、新功能等。一个好的模型应该能实现对这两类变更的集中统一管理(如图 1 所示)。本节将分别就这两类变更,阐述这一新型的变更模型的管理策略。 基于智能化知识库的文档变更管理 软件开发应用生命周期的各阶段涉及多类与源码无关的文档,包含需求分析、数据库设计、测试文档等面向客户的文档,也包含供项目成员使用的内部文档,如模 块开发卷宗、数据存储规则等。一个智能化的完整知识库将帮助项目开发团队及时共享所有的文档,并支持版本管理,从而提供一个体现以往经验和产品需求的平台。 虽然文档的一致性问题并不是非常突出,多人同时修改一个文档的情况也不多见。然而,如果只在本地保留文档的当前版本,而将不同版本的集中管理交给知识库自动完成,将会减少冗余,还便于随时随地查看不同时期文档的内容,相互比对。 TechExcel 以知识为核心的 ALM解决方案中的 KnowledgeWise不仅支持普通意义上的文档版本管理,还从更高的层面实现了知识历史的 跟踪和记录。知识条目作为知识库管理的基本单元,通过自身属性描述和所附文档完整呈现相关知识内容。而知识条目和所附文档的任何变更,将会自动触发版本控制机制。因此,知识库得以保留所有历史版本的知识,并能提供分类搜索和查找。 集成任务跟踪与版本控制的源代码变更模型 源代码的变更管理对软件开发的成败尤为重要。传统的版本控制集成往往将项目开发中的任务或问题与源码文件直接关联。这种方式在应对任务与源码文件间的复杂关系时,常常显得力不从心。 集成任务跟踪与版本控制的变更模型旨在使软件开发中的版本管理和任务跟踪乃至项 目规划实现真正意义上的一体化,进而优化软件开发的过程。在此模型中,变更( Change)取代源码文件成为基本单元。首先,通过 Change 将源代码文件封装,这就使得项目颗粒度变大,抽象性更强;经过封装后的源代码文件,再通过 Change 与开发任务关联。实质上, Change 在任务跟踪和版本控制之间建立了桥梁(如图 2)。通过提交 Change,就能轻松更新源代码,并记录引起源代码修改的任务。依据实际情况,开发任务和 Change 的关联分为以下三种情况: “一对一”关联,即提交一个 Change 完成一个工作任务,这和传统的源代码文件与工作任务“一对一”关系是不同的。例如,开发人员通过修改多个源代码文件才能修复一个bug,但开发人员只需提交一个 Change 就能完成该任务。 “多对一”关联,即通过修改提交一个 Change,可以完成多个任 务;或者完成一个任务需要提交多个 Change。对于后一种情况,能够帮助开发人员规划自己的工作,也使得其工作可见并量化。例如,程序员认为完成一个任务需要 5 个工作日,如果在 5天以后才提交源代码,可能会影响团队其他成员的工作。他可以选择每天以提交单个 Change 的方式记录自己的工作进展,版本库中的源代码文件会自动更新,直至最终完成这个任务。 “多对多”关联,即多个工作任务与多个 Change相关。例如,测试人员提交的 6 个 bug 被分配给 2 个程序员修复,他们可以通过新建不同的 Change,将自己要修改的源文件和相关 bug 关联起来,实现协同工作。集成变更模型的功能及优势 为了在可控制的工作流环境下实现多种管理功能,如工作项管理、任务跟踪和缺陷跟踪等,上述集成变更模型系统至少应具备以下功能: 实现开发任务、变更( Change)和源代码文件三者的自由关联。开发任务应该通过 Change 这个纽带,对各自之间的关系和历史做详细记录,便于追溯和查找。同时,也应支持“一对多”和“多对多”的关联方式。 任务跟踪软件与第三方版本控制系统集成。在企业多项目、多团队的管理中,统一的任务跟踪工具如果能和多个版本控制系统自由集成 ,尤其能考虑到开源软件,如 Subversion、 CVS 等,将为企业节约实施成本。 变更控制与主流集成开发环境( IDE)工具的集成。开发工程师无需脱离 IDE,也无需登录任务跟踪系统,便可直接通过 IDE 中集成的变更管理机制,完成源代码与开发任务的关联和版本库中的代码更新。 源代码提交与“变更”强制关联。源代码在版本库中的更新都将由提交 Change 来实现。程序员在提交新版本之前必须通过 Change 关联开发任务,这保证了任何源码文件的变更都事出有因,将使得开发过程更加安全可靠。 源代码变更直接推进 任务状态。在变更源代码文件时,获得权限的负责人可以把任务状态的推进作为 Change 的一部分进行提交。因为很多情况下,源代码文件的修改完成,也标志着一个任务可以进入下一个状态,或者转给下一个负责人,这时候如果再回到任务跟踪工具里去做更改,就会降低变更控制的效率。 因此,面向软件规范化、工程化、自动化的需要,运用科学有效的集成变更模型,将给企业带来一系列益处。 缩短开发周期。开发团队之间的问题跟踪及消息发布,加强了人员沟通。版本库的严密管理,可最大限度地共享代码。开发人员不用跳转系统就能一次性完成源码的 关联和检入,并且提交一次 Change 就能检入多个文件,还能利用 Change 对工作进行规划和总结,这些都将提高他们的开发效率。 有利于知识库的建立。对版本的有序管理,有利于企业建立代码、文档和业务经验知识库。如果能够结合项目规划、测试等其它应用,更能建立完整的企业级知识库,为企业的可持续发展做重要的知识积累。 规范管理。对项目成员的工作量进行量化的统计,使员工考核更加规范;强制执行源文件与开发任务的关联,使开发习惯更加规范;项目成员遵循预定的工作流程进行设计、开发和测试,使开发过程更加规范;项目成员间 加强了沟通,有问题能及时发现、分配并解决,且不增加额外的工作量,使项目管理更加规范。 集成变更模型应用示例 — DevTrack 与 Subversion集成 Subversion 是一个免费、开源的版本控制系统,可用来管理任何类型的文件。任务跟踪工具 DevTrack 可以通过 VersionLink 变更模块与 Subversion有效集成。通过 VersionLink插件, Subversion用户可以在 IDE(如 VisualStudio)或 SVN 客户端(如 RapidSVN、 TortoiseSVN)界面直接将提交操作 与 DevTrack开发任务关联起来。另外,独立的 VersionLink 客户端也为开发人员提供了更灵活的变更管理。 无缝集成。当在系统中创建新的变更任务被创建或已建立的变更任务被选择时,开发人员可以在 DevTrack 中选择与变更相关的文件。VersionLink 用户能够直接操作他们所负责的 DevTrack 任务,并将所有变更的数据都保存在 DevTrack 数据库中。同时,用户在 VersionLink 中还能查看并检索 DevTrack 子项目树。 智能变更管理。 VersionLink 会在 Change 被提交时自动 执行源文件检入操作。如果失败, VersionLink 则不会更新 DevTrack 开发任务或 Subversion 版本库。此外, DevTrack 智能化的工作流机制也在VersionLink 中体现。报表分析。管理团队和开发团队可以浏览 DevTrack 中的工作进展。通过 DevTrack 中的 Subversion 页面就可以显示出所有的变更、源码文件以及相关的开发任务。 DevTrack 报表将呈现某一特定产品版本的所有变更文件、为修复一个或多个 bug 而新建的文件以及其他重要的数据元素。