Roles of CM Users and Views of CM
Different views of CM emanate from the different roles and concerns of people in an organization.

A simple, typical, CM user scenario of an organization is described in order to present the various roles and the subsequent views of CM support. The scenario involves various people with different responsibilities: a project manager who is in charge of a software group, a configuration manager who is in charge of the CM procedures and policies, the programmers who are responsible for developing and maintaining the software product, the tester who validates the correctness of the product, the quality assurance (QA) manager who ensures the high quality of the product, and the customer who uses the product. Each role comes with its own goals and tasks. For the project manager, major goals are to ensure that the product is developed within a certain time frame and meets the customer’s  requirements. Hence, the manager monitors the progress of development and recognizes and reacts to problems. This is done by generating and analyzing reports about the status of the software system and by performing reviews on the system.

The goals of the configuration manager are to ensure that procedures and policies for creating,
changing, and testing of code are defined and followed, as well as to make information about the project accessible. To implement techniques for maintaining control over code changes, this manager introduces mechanisms for making official requests for changes, for evaluating changes (via a Change Control Board (CCB) that is responsible for approving changes to the software system), and for authorizing changes. The manager creates and disseminates task lists for the programmers and basically creates the project context. Also, the manager collects statistics about components in the software system, such as information determining which components in the system are problematic.

For the programmers, the goal is to work effectively in creating the product. This means programmers do not unnecessarily interfere with each other in the creation and testing of code and in the production of supporting documents. But, at the same time, they communicate and coordinate efficiently. They use tools that help build a consistent software product, and they communicate and coordinate by notifying one another about tasks required and tasks completed. Changes are propagated between each other’s work by merging those changes and resolving any conflicts. A history is kept of the evolution of all components in the product along with a log of what actually changed and reasons for those
changes. The programmers have their own work area for creating, changing, testing, and integrating code. At a certain point, the code is made into a baseline from which further development continues and from which parallel development for variants of other target machines emerges.
The tester’s goal is to make sure every component of the product is tested and found satis-factory. This involves testing a particular version of the product and keeping a record of which tests apply to which version of the product along with the results of the tests. Any errors are reported back to the appropriate people, tracked and fixes are put through regression testing.

The Quality Assurance (QA) manager’s goal is to ensure the high quality of the product. This means that certain procedures and policies must be fulfilled with the appropriate approval. Bugs must be fixed and fixes propagated to the appropriate variants of the product with the correct amount of testing applied to each variant. Customer complaints about the product must be followed up.

The customers use the product — most likely, different customers use different versions and variants of it. Customers follow certain procedures for requesting changes and for indicating bugs and improvements for the product.

As a result of the various roles, an organization ends up with several views of CM. These views range from corporate CM (CCM) and project CM (PCM) to developer CM (DCM) and application CM (ACM). The former two views treat CM as a management and control discipline emphasizing the process aspect of CM, while the latter two views treat CM as a developer support function emphasizing tool support for CM. CCM focuses on maintaining CM information for a product, whose data is the basis for strategic impact analysis and process improvement. PCM focuses on managing change to a product through formal control processes such as change authorization via CCBs and configuration managers guarding CM repositories. DCM focuses on supporting developers (programmers) performing actual changes, maintaining history of actual changes, and providing stability and consistency through system build and team support. ACM focuses on configuration of applications as they are deployed, addressing issues of installation management, as well as dynamic configuration and reconfiguration. Ideally, a CM system suited to the views should support all these goals, roles and tasks.

Reference: 
The State of Automated Configuration Management
A. Brown, S. Dart, P. Feiler, K. Wallnau