Arcade Game Maker Product Line Configuration Management Plan

Transcription

1 Arcade Game Maker Product Line Configuration Management Plan ArcadeGame Team July 2003

2

3 Table of Contents 1 Introduction 1 2 Policies Version control Configuration Management Change Control 2 3 CM Process Overview of steps Authority Responsibility 3 4 Tools 5 5 References and Further Reading 6 CMU/SEI-2001-TR-001 i

4

5 1 Introduction The AGM product line will produce a large number of assets. These assets will evolve over time due to defect repairs and technology and requirements changes. This document describes a plan for managing this change using configuration management. The strategy described in this document is based on the product line evolution plan described in [McGregor 03]. Traditional configuration management includes the tasks of configuration identification, change management, configuration status accounting, and configuration review. The product line environment complicates this by adding dependencies between configurations. That is, an asset may be used concurrently in multiple configurations. In section 3 we discuss how these dependencies can be handled. In section 4 we discuss the implications of these dependencies on the selection of tools. 1

6 2 Policies The following policies govern the management of change of assets. 2.1 Version control?? Every asset intended for use in more than one product will be placed under version control. Product teams are encouraged to control even assets for a specific product using the version control process.?? No modification will be allowed to any asset until that asset is checked out (for writing) from the version control system. (Change management) 2.2 Configuration Management?? Every asset is represented by a configuration of assets including software, plans, architecture, and other resources. (Configuration identification)?? Any build of any product can be accurately recreated at any time.?? The product team is responsible for updating the traceability matrix that associates features from the requirements model to the specific program or module that implements that feature.?? Every change to a configuration is initiated by a change request. These changes are stored under version control. (Configuration status accounting)?? The owner of a configuration and the users of that configuration will periodically, usually just prior to the release of a whole-numbered version, consider the direction of evolution of the configured asset. (Configuration review) 2.3 Change Control?? Publicly visible changes to an asset must be approved by the change control board.?? A change request must describe the impact of the change on existing uses of the product. 2 CMU/SEI-2001-TR-001

7 3 CM Process The configuration management process implements the policies stated in section 2. The CM process treats each asset or product as an aggregation of other assets. 3.1 Overview of steps A configuration is created when a new asset is defined. The initial configuration may only contain that definition. As assets are selected to further define and implement the asset, they are added to the configuration. The configuration evolves by extension and revision. Existing assets within the configuration are modified to repair bugs and new versions are created. Additional assets are added to the configuration to contribute to the definition of the asset. Once an asset is released for public use, all changes are first approved by the change control board. A configuration is maintained as long as the asset is available for use. The configuration is versioned over time as constituent assets evolve. When the asset is retired the configuration is likewise retired. 3.2 Authority The change control board has the authority to approve changes in assets used in more than one product. In cases where there is an asset specific control board (architecture change board), the change control board only has authority to mediate between the requestor and the asset-specific change management board. The owner of each asset has the authority to modify the configuration of an asset but not the publicly available attributes. The owner will review and accept or reject any configuration change requests. 3.3 Responsibility Each product team is responsible for following VC and CM policies in their use of assets. Each person assigned a work task is responsible for following CM policies with respect to that work task. Each person is responsible for checking out the asset upon which they are 3

8 working, checking the asset in when the work is completed, and initiating any configuration changes required by that work. 4 CMU/SEI-2001-TR-001

9 4 Tools AGM is still looking for tools to fully automate the configuration management process. We have been unable to find a single tool that covers all of our needs. For now, we will use CVS as the version control mechanism. This tool runs on most platforms. It is simple to use and allows several types of file use. We will use the facilities of the.net IDE as the software configuration management tool. The Visual Studio.Net IDE has two levels of configuration management. A project is the smallest unit. Projects can be aggregated into a solution. A project allows source code files to be associated with resources such as graphics and media files. We will use text manifest files to maintain the overall configuration for a product. This will allow us to associate all of the information that defines a product. It will also allow us to associate an asset with multiple configurations. 5

10 5 References and Further Reading For references see the Bibliography document. 6 CMU/SEI-2001-TR-001

11 7