CM:This information typically includes the versions & updates that have been applied to installed program packages & the locations & network addresses of hardware devices. Special configuration management program obtainable. When a system needs a hardware or program upgrade, A computer technician can access the program & configuration management database to see what is currently installed. Then, the technician can make a more informed decision about the necessary update.Configuration Management (CM) is the detailed & updated information describing a company's computer systems & networks, including all hardware & program components.Four advantage of a configuration management application is that the entire collection of systems can be reviewed to ensure that any changes made to a system does not adversely affect any of the other systems.Configuration management is also used in program development, where it is called Unified Configuration Management (UCM). Using the UCM, developers can keep track of source code, documentation, problems, requested changes, & changes made.
1. Identification: an identification process is necessary to reflect product structure. This involves identifying the structure & types of components, making them distinctive & available in some way, giving each component a name, a version identification, & configuration identification.
2. Control: controlling the release of a product & changes throughout the lifecycle by having controls in place that ensures that compatible program through the creation of a reference product.
3. Audit & review: validate the integrity of a product & maintaining consistency between the components, ensuring that components are in an appropriate state throughout the project life cycle & that the product is a clear set of components.
4. Status Accounting: recording & reporting the status of components & change requests, & gathering vital statistics about components in the product.The definition includes the terminology & basic configuration element, release & version, etc. At a high level, most CM systems designers to incorporate the functionality of different levels of support to these aspects. But in the run level from the user point of view, most CM systems have different functionality. Among the lots of reasons for these differences are: different platforms of hardware, operating systems & programming languages. However, a rate of interest is due to the different types of users of a CM process. This stems from the role the user plays in the organization. In particular, an administrator, a program engineer developing an application, an application client as well as a builder of the environment tend to see CM differently. As a result, they may require different (but complementary) the functionality of your CM process. For example, an administrator of "CM" evokes the picture of a Configuration Control Board. For a program engineer, the picture of the baselines arise. For a client, versions of the application of emerging. & for the environment builder, mechanisms such as libraries & information compression arise. All these images obviously result in different requirements for the CTM process & hence functionality, possibly different.
Post a Comment