配置与变更管理工作流全解析
1. 引言
配置与变更管理工作流的目的是确保项目工件的一致性和质量,同时维护和保护项目工作的范围。在项目的构建阶段,像软件架构文档、项目计划和需求模型等项目工件都要置于配置管理(CM)的控制之下。配置管理对于保证项目参与者所产生的众多工件的一致性和质量至关重要,有助于避免团队成员之间的混淆。而且,随着需求模型的演变,需要对需求变更进行优先级排序,并将其分配到项目的合适版本、阶段和/或迭代中。若缺乏这种变更控制,项目就会面临范围蔓延的问题,即增加原本未商定要实现的需求。
配置管理有助于确保工件的一致性和质量,而变更控制则有助于确保只在合适的时间构建应该构建的内容。要有效地开展配置与变更管理工作流,需要了解以下几个方面。
2. 配置管理
- 配置管理的理念与价值 :Tani Haque认为项目团队要认识到软件开发会产生许多随时间演变的不同工件,而配置管理工具能跟踪和控制这种演变。配置管理工具是工件开发、缺陷跟踪、版本控制和软件分发的核心。如果将软件开发工作视为建造大教堂而非单纯砌砖,遵循经过验证的配置与变更管理流程,就能成为软件大教堂的建造者,而非简单的软件砌砖工。
- 配置管理与组件重用 :Clemens Szyperski指出,通过组件组装构建软件前景广阔,但必须克服版本控制和组件相关的挑战。他解释了版本控制的重要性以及相对衰减的概念。要实现跨应用程序的重用,就需要控制好配置管理流程。他还提到了一些使配置管理独特的因素,如不精确的组件接口和从外部不易察觉的组件内部耦合等。有效的变更管理流程是实现组件重用和整体重用成功的关键。
- 版本描述文档(VDD) :为了跟踪和传达项目团队内部以及向软件客户的配置管理信息,可以创建版本描述文档(VDD),这是IEEE标准的软件过程工件。VDD会列出软件的所有组件,包括可执行文件等软件组件和用户手册等物理组件,以及这些组件的版本和它们的组合方式。
3. 变更管理
John Heberling介绍了变更管理的流程、角色和工具。他描述了如何管理软件变更这一软件项目的基本现实,并给出了经过验证的最佳实践。同时,他也指出了项目团队常见的陷阱,比如利用变更管理流程阻碍变更而非促进变更。他对变更管理相关角色和职责的讨论,对招聘该岗位人员的项目经理和考虑担任该岗位的开发者都很有价值。最后,他还讨论了支持该工作流所需的工具类型,并推荐了一些软件配置管理(SCM)和变更跟踪工具。变更管理的目的是促进变更,而非阻碍它。
4. 可追溯性
可追溯性是配置与变更管理工作流成功的基础。它指的是能否将软件工件中的特性追溯到导致其创建的其他工件中的特性。例如,业务类源代码中的操作应能追溯到设计模型中的操作,进而追溯到分析模型中的操作,最终追溯到设计模型中的一个或多个需求。可追溯性很重要,因为它能进行影响分析,从而有效管理变更。当需求变更或发现缺陷时,能够确定建议的变更将如何影响现有系统。如果在整个工件中没有保持可追溯性,就无法做到这一点。
为了说明可追溯性在实践中难以实现的原因,以一个简单的类图演变为例,最初分析模型中的两个类在设计模型中迅速演变为四个类,这表明在这个过程中保持可追溯性是非常困难的。
5. 相关文章解读
5.1 “Creating a Culture for CM”(创建配置管理文化)
- 配置管理工具的重要性 :配置管理工具是可预测软件开发结构的基石。团队可以将软件开发视为有许多不同工作产品和可交付成果的任务,将软件开发过程看作这些工作产品随时间演变的过程,并将配置管理工具视为跟踪和控制这种演变的工具,从而减少对项目关键路径的依赖。但仅靠工具是不够的,在实施以配置管理为中心的系统时,考虑如何将这些变化融入组织文化同样重要。
- 改善组织文化 :一些编程团队仍将配置管理视为繁琐且无甚益处的工作,通常这种态度出现在仅拥有基本版本控制系统的团队中。当程序员看到配置管理工具成为文档开发、缺陷跟踪、无缝版本控制和软件分发的核心时,他们往往会成为配置管理流程和工具的最大支持者。改善软件过程是改善组织文化的绝佳机会,如果处理得当,企业可以重复这些过程改进并在整个组织中加以利用。
-
配置管理的实施策略
- 闭环管理 :有效的配置管理以闭环方式为各项任务提供必要的支持基础设施。但一旦决定采用这种方式,不遵循就可能付出高昂代价。例如,一个小的变更请求若未按流程处理,可能会演变成未记录的“特性”;发现的bug若未跟踪和修复,可能会引发危机。不过,这些问题是可以避免的,成熟的配置管理流程应能处理客户的事件报告,将其正式引入变更控制流程,分配修复任务,并跟踪缺陷的优先级分配、审查、实施、测试、发布和分发等过程。
- 分而治之 :配置管理解决方案可以分解为具有明确定义接口的可行区域。采用“并发工作”的理念并让高层管理人员参与项目是一种有效的方法。要向管理层表明,项目的成功取决于并发工程的成功,现代配置管理系统将为企业提供必要的基础设施。同时,要说明瀑布式方法隔离功能是无效的,所有团队成员应作为一个团队工作,项目生命周期的所有子部分应同时活跃,这样团队才能最大限度地并行工作。
- 明确各阶段角色和职责 :项目生命周期的每个阶段都有特定的可交付成果,如需求定义阶段的需求规格说明书、分析阶段的分析文档等。对于每个阶段,还需要确定相关的角色、任务和可交付成果。大多数团队的角色包括测试经理、测试人员、首席分析师等。表7.3和表7.4展示了典型分析和设计阶段的建议角色、工作产品和职责。
| 角色缩写 | 角色名称 |
|---|---|
| TM | 测试经理 |
| TE | 测试人员 |
| LA | 首席分析师 |
| STM | 系统测试经理 |
| BUI | 构建人员 |
| LE | 首席工程师 |
| AUT | 作者 |
| ENG | 工程师 |
| ITM | 集成测试经理 |
| REV | 评审人员 |
| DM | 开发经理 |
| CM | 配置经理 |
| RM | 发布经理 |
| QA | 质量保证人员 |
| AN | 分析师 |
| 开发阶段 | 准备分析文档 | 评审分析文档 | 准备模型 | 评审分析可交付成果 | 制定分析基线 | 验证基线内容 | 制定产品验收标准 | 评审产品验收标准 |
|---|---|---|---|---|---|---|---|---|
| 分析 |
AN:R
LA:I ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:I LE:I TM:I DM:I RM:R CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:I LE:I TM:I DM:I RM:R CM:I |
AN:I
LA:I ENG:I LE:I TM:I DM:I RM:I CM:R |
| 开发任务 | 准备设计文档 | 准备集成和系统测试文档 | 准备设计模型 | 评审设计模型 | 评审设计文档 | 评审集成和系统测试文档 | 准备数据模型 | 制定功能基线 | 验证基线内容 |
|---|---|---|---|---|---|---|---|---|---|
| 设计 |
AN:I
LA:I ENG:R LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:R LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:I LE:R TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:I LE:I TM:I DM:I RM:R CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:I LE:I TM:I DM:I RM:R CM:I |
AN:I
LA:R ENG:I LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:R LE:I TM:I DM:I RM:I CM:I |
AN:I
LA:I ENG:R LE:I TM:I DM:I RM:I CM:I |
- 规划与文档记录 :要尽早进行规划,各级管理人员和工程师需要相互协作。生成的文档应明确各阶段的接口和关系,这些过程可能是同步或异步的,本质上是一个分析问题。程序员在系统分析方面可能比公司其他人更有技能和经验。支持以配置管理为中心的过程的工具至关重要,要考虑工具的集成性、灵活性和风险规避性,技术不应需要特殊修改或依赖任何操作系统的特性。
mermaid图如下:
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(需求定义):::process --> B(分析):::process
B --> C(初步或高层设计):::process
C --> D(详细设计):::process
D --> E(实现):::process
E --> F(集成构建和测试):::process
F --> G(系统构建和测试):::process
G --> H(客户验收测试):::process
A -.-> I(贯穿项目):::process
B -.-> I
C -.-> I
D -.-> I
E -.-> I
F -.-> I
G -.-> I
H -.-> I
6. “Greetings from DLL Hell”解读
- 组件化软件面临的挑战 :通过组件组装构建软件对软件工程的未来充满希望,但首先要克服版本控制和组件的挑战。安装新软件包时,可能会导致之前加载的软件出现问题,而两个软件包单独使用时却正常,这就是所谓的“DLL地狱”。在所有平台上,基本上有两种选择:部署静态链接且大量冗余的软件包,除操作系统外不共享任何内容;或者面临“DLL地狱”。但前一种策略也不太可行,因为操作系统会变化,而且不清楚共享平台的具体组成部分。
- 相对衰减与版本控制 :对软件进行版本控制的一个重要原因是相对衰减,即自上次版本化以来项目发生的相关变化。软件本身不会像物理物品那样衰减,但它依赖于解决问题的上下文假设。随着周围环境的变化,软件的适用性也会改变。
-
跨版本重用的问题与解决方案
- 重用的问题 :在跨应用程序重用软件单元时,传统的修改和重建共享单元的方法往往会导致软件崩溃。原因包括单元之间隐藏的依赖关系、不精确的接口规范、组件之间不易察觉的耦合以及中间单元未升级等。
- 中间层场景的解决方案 :以一个中间层场景为例,当新的HTML版本出现,仅WebPuller升级时,如果直接修改IRenderHTML接口的含义,可能会导致旧的ScreenMagic出现问题。为避免这种情况,可以定义新的接口IRenderHTML2,并让WebPuller实例同时实现IRenderHTML和IRenderHTML2。这样,Base和ScreenMagic可以继续通过IRenderHTML工作,而WebPuller可以通过动态类型检查来确定使用哪个版本的接口。
- 语言层面的细节问题及解决办法 :在C++、Java等面向对象语言中,上述方法会遇到问题。由于类会合并所有实现接口的方法,为避免冲突,需要对IRenderHTML2中需要改变语义的方法进行重命名。当遇到接口继承的情况时,重命名所有方法不可行,此时可以使用适配器对象。例如:
class ScreenMagicRenderer implements IRenderHTML ...
class ScreenMagicRenderer2 implements IRenderHTML2 ...
为了解决Base组件只能持有ScreenMagicRenderer实例的问题,可以引入INavigate接口:
interface INavigate {
Object GetInterface (String iName);
//*GetInterface returns null if no such interface */
}
这样WebPuller可以从Base获取实现IRenderHTML的对象,并询问该对象是否实现了IRenderHTML2。
综上所述,配置与变更管理工作流在软件开发中起着至关重要的作用,通过有效的配置管理、变更管理和可追溯性管理,可以提高软件的质量和开发效率,实现组件重用和大规模的软件开发目标。同时,要充分考虑组织文化、工具选择和技术细节等方面的因素,以应对各种挑战。
配置与变更管理工作流全解析
7. 配置管理与变更管理的协同作用
配置管理和变更管理是相辅相成的,它们共同保障了软件开发项目的顺利进行。配置管理确保了项目工件的一致性和质量,而变更管理则控制着项目范围和进度,使得项目能够灵活应对各种变化。
当项目中出现需求变更时,变更管理流程首先对变更进行评估和优先级排序。如果变更被批准,配置管理系统需要对相关的项目工件进行更新和版本控制。例如,当需求文档发生变更时,配置管理系统要确保新的需求文档被正确纳入版本管理,并记录变更的历史信息。同时,变更管理过程要跟踪变更的实施情况,确保变更能够按照计划完成,并对项目的其他部分产生的影响进行评估。
在实际操作中,可以通过以下步骤实现配置管理和变更管理的协同:
1.
变更请求的提交
:当项目团队成员或客户提出变更请求时,需要详细描述变更的内容、原因和预期影响。
2.
变更评估
:由变更管理团队对变更请求进行评估,包括技术可行性、对项目进度和成本的影响等。
3.
变更批准
:根据评估结果,相关负责人决定是否批准变更。如果批准,进入下一步。
4.
配置更新
:配置管理团队根据变更内容更新相关的项目工件,如代码、文档等,并进行版本控制。
5.
变更实施
:开发团队按照变更计划实施变更,并进行测试。
6.
变更验证
:测试团队对变更进行验证,确保变更达到预期效果,且没有引入新的问题。
7.
变更发布
:经过验证的变更被发布到生产环境,同时更新相关的文档和配置信息。
8. 可追溯性管理的最佳实践
可追溯性管理是配置与变更管理工作流中的关键环节,它有助于提高软件的质量和可维护性。以下是一些可追溯性管理的最佳实践:
-
建立明确的追溯关系
:在项目开始时,就应该定义好不同工件之间的追溯关系,例如需求与设计、设计与代码、代码与测试用例之间的对应关系。可以使用工具来记录和管理这些追溯关系,确保在项目的整个生命周期中能够方便地进行查询和验证。
-
定期审查和更新追溯信息
:随着项目的进展,工件会不断发生变化,因此需要定期审查和更新追溯信息,确保其准确性和完整性。可以在每个迭代或里程碑结束时进行追溯信息的审查和更新。
-
培训团队成员
:确保项目团队成员了解可追溯性管理的重要性,并掌握相关的工具和方法。可以通过培训和文档来提高团队成员的意识和技能。
-
使用自动化工具
:利用自动化工具来辅助可追溯性管理,例如需求管理工具、版本控制系统等。这些工具可以提高追溯信息的管理效率和准确性。
9. 配置与变更管理的案例分析
为了更好地理解配置与变更管理工作流的实际应用,下面通过一个具体的案例进行分析。
某软件开发公司正在开发一款企业级的管理软件,项目团队采用敏捷开发方法。在项目的初期,团队建立了完善的配置管理和变更管理流程。配置管理系统使用了专业的版本控制系统,对代码、文档等项目工件进行了有效的管理。变更管理流程则规定了变更请求的提交、评估、批准和实施的步骤。
在项目的开发过程中,客户提出了一些新的功能需求。项目团队按照变更管理流程对这些需求进行了评估,发现其中一些需求对项目的进度和成本影响较大。经过与客户的沟通和协商,最终确定了部分需求作为本次迭代的变更内容。
配置管理团队根据变更内容更新了相关的项目工件,包括代码和文档。开发团队在规定的时间内完成了变更的实施,并进行了测试。测试团队对变更进行了严格的验证,确保变更没有引入新的问题。最终,经过验证的变更被发布到生产环境,得到了客户的认可。
通过这个案例可以看出,有效的配置与变更管理工作流能够帮助项目团队更好地应对需求变更,确保项目的顺利进行。同时,可追溯性管理也在整个过程中发挥了重要作用,使得团队能够快速定位问题,并评估变更对项目的影响。
10. 未来趋势与展望
随着软件开发技术的不断发展,配置与变更管理工作流也面临着新的挑战和机遇。以下是一些未来可能的发展趋势:
-
智能化管理
:利用人工智能和机器学习技术,实现配置与变更管理的智能化。例如,通过分析历史数据,预测变更可能带来的风险,并提供相应的建议。
-
云原生配置管理
:随着云计算的普及,越来越多的软件采用云原生架构。云原生配置管理将更加注重容器化、微服务和自动化部署,以适应云环境的特点。
-
跨团队协作
:在大型项目中,往往涉及多个团队的协作。未来的配置与变更管理工作流将更加注重跨团队的协作和沟通,提高团队之间的协同效率。
-
安全与合规性
:随着软件安全和合规性要求的不断提高,配置与变更管理工作流将更加注重对安全和合规性的管理,确保软件的安全性和合法性。
为了适应这些未来趋势,软件开发团队需要不断学习和掌握新的技术和方法,不断优化配置与变更管理工作流,以提高软件的质量和开发效率。
11. 总结
配置与变更管理工作流是软件开发过程中不可或缺的一部分,它对于确保项目工件的一致性和质量、控制项目范围和进度、提高软件的可维护性和可追溯性都具有重要意义。通过本文的介绍,我们了解了配置管理、变更管理、可追溯性管理的相关概念和方法,以及如何实现它们之间的协同工作。同时,通过案例分析和未来趋势展望,我们也看到了配置与变更管理工作流在实际应用中的重要性和发展前景。
在实际项目中,软件开发团队应该根据项目的特点和需求,选择合适的配置与变更管理工具和方法,并不断优化工作流程,以提高项目的成功率和软件的质量。同时,要注重团队成员的培训和意识提升,确保每个人都能够理解和遵守配置与变更管理的规则和流程。
| 关键要点 | 描述 |
|---|---|
| 配置管理 | 确保项目工件的一致性和质量,实现大规模重用 |
| 变更管理 | 促进变更,控制项目范围和进度 |
| 可追溯性管理 | 提高软件的可维护性和可追溯性,便于影响分析 |
| 协同工作 | 配置管理和变更管理相互配合,确保变更顺利实施 |
| 最佳实践 | 建立明确追溯关系、定期审查更新、培训团队成员、使用自动化工具 |
| 未来趋势 | 智能化管理、云原生配置管理、跨团队协作、安全与合规性 |
mermaid图如下:
graph LR
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
A(配置管理):::process --> B(协同工作):::process
C(变更管理):::process --> B
D(可追溯性管理):::process --> B
B --> E(项目成功):::process
F(最佳实践):::process --> A
F --> C
F --> D
G(未来趋势):::process --> A
G --> C
G --> D
通过遵循这些原则和方法,软件开发团队可以更好地应对各种挑战,提高软件的质量和开发效率,实现项目的成功。
超级会员免费看
5366

被折叠的 条评论
为什么被折叠?



