Research Paper on Configuration Management
Within this research paper I will discuss why software configuration management is important. I will introduce four principals of configuration management; configuration management planning, change management, version & release management and system building. I will also cover standards within configuration management and version identification.Lehman’s first ‘law’ draws attention to a basic property of software systems, which is they evolve or die. One reason there is software change is new requirements, improvements are thought up and old ones become obsolete, evolving technology may cause this. Lehman’s second ‘law’ points to a fundamentally important precept that, when there is software change work has to be done to preserve quality of structure, let alone improve it if need be.
__________________________________________________________
__________________________________________________________
Configuration management
Configuration management is the development and application of standards and procedures for managing an evolving systems product. As discussed above there is many reasons for management of systems, another reason is many different versions within one system. Different versions involve proposals for change, corrections of faults and adaptations for alternate hardware or operating systems. Configuration management keeps a track of all changes made and how these changes have been implemented into the software. Configuration management procedures define how to record and process proposed system changes, relating to system components and methods used to identify versions of system. Configuration management tools are used to store versions of system components, build systems from components supplied and track the releases of version to the customer. Configuration management is sometimes seen as a general software quality management process this could be because manager share quality management and configuration management responsibilities. I have produced a simple diagram to clearly show the root from developer to configuration management;
Configuration managers are responsible for keeping track of differences between versions, ensuring new versions are derived in a controlled way and releasing new versions to correct customers at correct time. I can here you saying why have different configurations? The answer is many reasons for different configuration;
· Different computers (dell,hp)
· Different operating systems (linux,windows)
· Different client-specific functions
Configuration management standards
Configuration management process and associated documents should be based on standards such as IEEE 828-1983, which defines standards for configuration management plans. The standard should be published in the configuration management handbook or part of the quality handbook. Many standards can be used because all include important comparable processes. Taking some models as examples, ISO 9000 and SEI’s capability maturity model, organisations must define and follow formal configuration management standards for quality certification. Waterfall model the software is delivered to configuration management team after development complete and individual components tested. The team then takes control of builds and testing of complete system. If any faults are discovered during testing, the specific component is passed back to developer for repair then passed back to configuration management when fault is fixed. This approach influenced the development of configuration management standards and these have an embedded assumption that a waterfall model of the software process will be used for system development. Some organisations have therefore developed to configuration management that supports concurrent development and system testing. This relies on very regular (daily) build if the whole system from its components:-
· Time will be set for component delivery. All new versions must be delivered even if incomplete but should provide some functionality.
· New version is built, linking all components to make complete system.
· It’s then sent for testing, developers still work on components on previous faults and functionality.
· Faults found are documented and returned. These are repaired for next version.
Advantages of using daily builds include, problems can be found that stem from component interaction early in the software creation, it encourages thorough unit testing of components. Developer are put under pressure not to ‘break the build’ which causes whole system to fail. Breaking the build refers to the developer delivering a component with errors that wont allow the whole to compile therefore the build will fail, meaning time wasted. Another pro would be less system time is spent discovering and coping with faults that should be found within unit testing. Daily builds need very stringent change management process to keep track of problems that have been discovered and repaired. It also leads to a large number of system and component versions. Good configuration management is therefore essential for this approach to work successfully.
Configuration management planning
Configuration management planning is a plan describing the standards and procedures used for the configuration management. The start point for the plan is a general set of company-wide configuration management standards and are adapted as necessary for each specific project. Configuration management plans should be organised into chapters and include:-
· Definition of entities to manage and formal scheme of identifying entities
· Person responsible for configuration management procedures and submitting controlled entities to configuration management team
· Configuration management policies for change and version management
· Tools to be used and processes to be applied when using the tools
· Definition of configuration management database which is used to record configuration information
The most important part of the plan is the definition of responsibilities- who is responsible for delivery of each document or software component to quality team and configuration management. The person responsible for document delivery is not always same person who produced it. This makes it convenient to make project manager/team leader responsible for all documents produced by the team.
Configuration management documents
Large pieces of software will have thousands of documents many being technical documents which present snap shots of ideas for further development; theses are documents subject to frequent and regular change. Other documents include memos, meeting minutes, plans and proposals etc. During the configuration management planning process, you decide exactly which items are to be controlled documents or groups of related documents are to be put under configuration control, these are know as formal documents or configuration items. Projects plans, specifications, design, programs and pre-defined test data suites are maintained as configuration items, documents necessary for future maintenance should be controlled. The document-naming scheme assigns a unique name to all documents under configuration control. If there are relationships between these documents e.g. design documents will be associated with programs, the relations can be recorded by organising the naming scheme so that related documents have common roots to their name, leading to a hierarchical naming scheme. I have produced an example of a document configuration hierarchy.
The initial part of the hierarchy would be the project name, in the project there are four separate tools with the tool name used as next part of the name. Each tool is made up of different named modules which shows two formal documents are required for each managed entity, these are code of the components and set of tests for code. Upon reading about the document-naming scheme I can see one flaw, its project based meaning not reusable for other projects.
Configuration management database
The configuration management database is used to record all relevant information relating to configurations. Database functions are to assist with assessing the impact of the system change and provide management information about configuration management process. Also defining the configuration database schema with procedures for recording and retrieving project information also defined as part of configuration management planning process. The database will provide the answers to the following queries:-
· Which customer have which version
· What hardware and o/s is required for version
· How many versions are there and when was they created
· What version relies on particular components
· Outstanding changes required on version
· How many report faults exist on version
Tools
Configuration data should be integrated with version management system. Case tools makes it possible to link changes directly with documents and components affected by change. Links between documents such as design documents and code may be maintained so that it’s relatively easy to find everything that must be modified when a change is proposed. Many companies don’t use integrated case tools for configuration management but maintain their configuration database as a separate system. The configuration items may be stored in files or in a version management system such as RCS, a well-known version management system for unix. This configuration database stores information about configuration items and references file names in the version management system. Its cheep and flexible but the disadvantages are configuration items may be changed without going through the configuration database and cant be sure configuration database is up-to-date.
Change management
Change is a fact of life for large systems. A defined change management process and associated case tool ensure changes are recorded and applied in a cost-effective way. Change management process comes into effect when associated document put under the control of the configuration management team. May be initiated during system testing or after customer delivery. The first stage of change management is CRF change request form where requests sets out change required to the system. Here is an example of a change management process:-
-complete(CRF) analyse change request if valid assess how to do change record in -database submit to control board if accepted repeat make change
-record submit to quality management until quality adequate
-create new version
As well as recording changes, CRF records recommendations regarding the change, estimate cost and dates when change was requested, approved, implemented and validated. CRF should be registered in the configuration database so configuration management team can track status.
Version management and identification
Version and release management are the processes of identifying and keeping track of different versions of the system. Version managers devise procedures to ensure versions may be retrieved when required and are not accidentally changed. They work with customer liaison staff to plan when new releases of system should be distributed. New versions should allows be created by configuration management, this makes it easier to maintain consistency in the configuration database as only the configuration management team can change version information. A system version is an instance of a system that differs from other instances. New versions may have different functionality, performance or may repair system faults. Some versions may have the same functions but are designed for different hardware of software configuration. If there is only a small difference one is called a variant of the other. A system release is a version with the intention to be distributed to the customer, each system release should either include new functionality or be intended for different hardware platform. There will be many more versions than releases because versions are created within an organisation for internal development or testing but not released to customer. Version management is always supported by case tools, which manage the store of each version and control access to components. Large pieces of software have hundreds of software components each way exist in many different versions. Version management should define unambiguous way of identifying each component version, specific versions of components may be recovered for further change. There are three basic techniques which may be used for component identification:-
· Version numbering – given unique version number
· Attribute-based identification- given name (not unique across versions) and set of attributes that differ in each version.
· Change-oriented identification
Version numbering
In version numbering the system name is joined to version number to create version id- excel 2.6. Excel is the system name and 2.6 is the unique version number. A first version could be v1.0 so the next would be v1.1, v1.2, unless it’s a release therefore it would be v2.0.Next versions on from this can be v2.1, v2.2. It’s a linear one based on the assumption that versions are created in sequence. Here is a diagram to try and make it clear.
The diagram arrows indicate from which version the new one was produced v1.2 was produced from v1.1. New versions can be produced from older version not just previous version as can be seen when v2.2 is created from v1.2. This can happen because problems in v2.0 and v2.1 have required them to revert back to their last working version. Version numbering is simple but needs good deal of associated information management to keep track of differences. Makes it hard to see which versions have which components.
Attribute based identification
Problems with explicit version naming schemes are that they don’t reflect the many different attributes that may be used to identify versions. Examples of these identifying attributes are:-
· Customers
· Development language
· Development status
· Hardware platform
· Creation date
If each version is identified by unique set of attributes, it’s easy to add new versions that are derived from any of the existing versions. Identified by attribute value, they share most values with their parent version so relationships are maintained. Versions can be retrieved by specifying attribute values, with queries such as the most recently created, range of date etc. Example:-
NJA03(lang=java, plat=nt4, date=june1982)
Attribute-based identification may be implanted directly by version management system. More commonly, however its implemented on top of a hidden version naming scheme and the configuration database maintains links between identifying attributes and underlying system and component versions.
Change oriented identifying
Attribute based of system versions remove some of the problems of version retrieval that are found with simple numbering schemes. Problem is operator needs to know attributes to retrieve and need to use change management system to get relation between version and changes. Change oriented identification is used for systems rather than components so that versions of individual components are hidden from users of the configuration management system. Change sets may be applied in sequence so that in principle at least a version of the system that incorporates any arbitrary set of changes may be created. Therefore, no explicit version identification is required. The configuration management interacts with the version management system indirectly through the change management system.
Within this report I have explained why and how configuration management is used and the processes to do so and covered version management. If you wish to find more information within this subject here are the materials I have used.
Configuration management
Configuration management is the development and application of standards and procedures for managing an evolving systems product. As discussed above there is many reasons for management of systems, another reason is many different versions within one system. Different versions involve proposals for change, corrections of faults and adaptations for alternate hardware or operating systems. Configuration management keeps a track of all changes made and how these changes have been implemented into the software. Configuration management procedures define how to record and process proposed system changes, relating to system components and methods used to identify versions of system. Configuration management tools are used to store versions of system components, build systems from components supplied and track the releases of version to the customer. Configuration management is sometimes seen as a general software quality management process this could be because manager share quality management and configuration management responsibilities. I have produced a simple diagram to clearly show the root from developer to configuration management;
Configuration managers are responsible for keeping track of differences between versions, ensuring new versions are derived in a controlled way and releasing new versions to correct customers at correct time. I can here you saying why have different configurations? The answer is many reasons for different configuration;
· Different computers (dell,hp)
· Different operating systems (linux,windows)
· Different client-specific functions
Configuration management standards
Configuration management process and associated documents should be based on standards such as IEEE 828-1983, which defines standards for configuration management plans. The standard should be published in the configuration management handbook or part of the quality handbook. Many standards can be used because all include important comparable processes. Taking some models as examples, ISO 9000 and SEI’s capability maturity model, organisations must define and follow formal configuration management standards for quality certification. Waterfall model the software is delivered to configuration management team after development complete and individual components tested. The team then takes control of builds and testing of complete system. If any faults are discovered during testing, the specific component is passed back to developer for repair then passed back to configuration management when fault is fixed. This approach influenced the development of configuration management standards and these have an embedded assumption that a waterfall model of the software process will be used for system development. Some organisations have therefore developed to configuration management that supports concurrent development and system testing. This relies on very regular (daily) build if the whole system from its components:-
· Time will be set for component delivery. All new versions must be delivered even if incomplete but should provide some functionality.
· New version is built, linking all components to make complete system.
· It’s then sent for testing, developers still work on components on previous faults and functionality.
· Faults found are documented and returned. These are repaired for next version.
Advantages of using daily builds include, problems can be found that stem from component interaction early in the software creation, it encourages thorough unit testing of components. Developer are put under pressure not to ‘break the build’ which causes whole system to fail. Breaking the build refers to the developer delivering a component with errors that wont allow the whole to compile therefore the build will fail, meaning time wasted. Another pro would be less system time is spent discovering and coping with faults that should be found within unit testing. Daily builds need very stringent change management process to keep track of problems that have been discovered and repaired. It also leads to a large number of system and component versions. Good configuration management is therefore essential for this approach to work successfully.
Configuration management planning
Configuration management planning is a plan describing the standards and procedures used for the configuration management. The start point for the plan is a general set of company-wide configuration management standards and are adapted as necessary for each specific project. Configuration management plans should be organised into chapters and include:-
· Definition of entities to manage and formal scheme of identifying entities
· Person responsible for configuration management procedures and submitting controlled entities to configuration management team
· Configuration management policies for change and version management
· Tools to be used and processes to be applied when using the tools
· Definition of configuration management database which is used to record configuration information
The most important part of the plan is the definition of responsibilities- who is responsible for delivery of each document or software component to quality team and configuration management. The person responsible for document delivery is not always same person who produced it. This makes it convenient to make project manager/team leader responsible for all documents produced by the team.
Configuration management documents
Large pieces of software will have thousands of documents many being technical documents which present snap shots of ideas for further development; theses are documents subject to frequent and regular change. Other documents include memos, meeting minutes, plans and proposals etc. During the configuration management planning process, you decide exactly which items are to be controlled documents or groups of related documents are to be put under configuration control, these are know as formal documents or configuration items. Projects plans, specifications, design, programs and pre-defined test data suites are maintained as configuration items, documents necessary for future maintenance should be controlled. The document-naming scheme assigns a unique name to all documents under configuration control. If there are relationships between these documents e.g. design documents will be associated with programs, the relations can be recorded by organising the naming scheme so that related documents have common roots to their name, leading to a hierarchical naming scheme. I have produced an example of a document configuration hierarchy.
The initial part of the hierarchy would be the project name, in the project there are four separate tools with the tool name used as next part of the name. Each tool is made up of different named modules which shows two formal documents are required for each managed entity, these are code of the components and set of tests for code. Upon reading about the document-naming scheme I can see one flaw, its project based meaning not reusable for other projects.
Configuration management database
The configuration management database is used to record all relevant information relating to configurations. Database functions are to assist with assessing the impact of the system change and provide management information about configuration management process. Also defining the configuration database schema with procedures for recording and retrieving project information also defined as part of configuration management planning process. The database will provide the answers to the following queries:-
· Which customer have which version
· What hardware and o/s is required for version
· How many versions are there and when was they created
· What version relies on particular components
· Outstanding changes required on version
· How many report faults exist on version
Tools
Configuration data should be integrated with version management system. Case tools makes it possible to link changes directly with documents and components affected by change. Links between documents such as design documents and code may be maintained so that it’s relatively easy to find everything that must be modified when a change is proposed. Many companies don’t use integrated case tools for configuration management but maintain their configuration database as a separate system. The configuration items may be stored in files or in a version management system such as RCS, a well-known version management system for unix. This configuration database stores information about configuration items and references file names in the version management system. Its cheep and flexible but the disadvantages are configuration items may be changed without going through the configuration database and cant be sure configuration database is up-to-date.
Change management
Change is a fact of life for large systems. A defined change management process and associated case tool ensure changes are recorded and applied in a cost-effective way. Change management process comes into effect when associated document put under the control of the configuration management team. May be initiated during system testing or after customer delivery. The first stage of change management is CRF change request form where requests sets out change required to the system. Here is an example of a change management process:-
-complete(CRF) analyse change request if valid assess how to do change record in -database submit to control board if accepted repeat make change
-record submit to quality management until quality adequate
-create new version
As well as recording changes, CRF records recommendations regarding the change, estimate cost and dates when change was requested, approved, implemented and validated. CRF should be registered in the configuration database so configuration management team can track status.
Version management and identification
Version and release management are the processes of identifying and keeping track of different versions of the system. Version managers devise procedures to ensure versions may be retrieved when required and are not accidentally changed. They work with customer liaison staff to plan when new releases of system should be distributed. New versions should allows be created by configuration management, this makes it easier to maintain consistency in the configuration database as only the configuration management team can change version information. A system version is an instance of a system that differs from other instances. New versions may have different functionality, performance or may repair system faults. Some versions may have the same functions but are designed for different hardware of software configuration. If there is only a small difference one is called a variant of the other. A system release is a version with the intention to be distributed to the customer, each system release should either include new functionality or be intended for different hardware platform. There will be many more versions than releases because versions are created within an organisation for internal development or testing but not released to customer. Version management is always supported by case tools, which manage the store of each version and control access to components. Large pieces of software have hundreds of software components each way exist in many different versions. Version management should define unambiguous way of identifying each component version, specific versions of components may be recovered for further change. There are three basic techniques which may be used for component identification:-
· Version numbering – given unique version number
· Attribute-based identification- given name (not unique across versions) and set of attributes that differ in each version.
· Change-oriented identification
Version numbering
In version numbering the system name is joined to version number to create version id- excel 2.6. Excel is the system name and 2.6 is the unique version number. A first version could be v1.0 so the next would be v1.1, v1.2, unless it’s a release therefore it would be v2.0.Next versions on from this can be v2.1, v2.2. It’s a linear one based on the assumption that versions are created in sequence. Here is a diagram to try and make it clear.
The diagram arrows indicate from which version the new one was produced v1.2 was produced from v1.1. New versions can be produced from older version not just previous version as can be seen when v2.2 is created from v1.2. This can happen because problems in v2.0 and v2.1 have required them to revert back to their last working version. Version numbering is simple but needs good deal of associated information management to keep track of differences. Makes it hard to see which versions have which components.
Attribute based identification
Problems with explicit version naming schemes are that they don’t reflect the many different attributes that may be used to identify versions. Examples of these identifying attributes are:-
· Customers
· Development language
· Development status
· Hardware platform
· Creation date
If each version is identified by unique set of attributes, it’s easy to add new versions that are derived from any of the existing versions. Identified by attribute value, they share most values with their parent version so relationships are maintained. Versions can be retrieved by specifying attribute values, with queries such as the most recently created, range of date etc. Example:-
NJA03(lang=java, plat=nt4, date=june1982)
Attribute-based identification may be implanted directly by version management system. More commonly, however its implemented on top of a hidden version naming scheme and the configuration database maintains links between identifying attributes and underlying system and component versions.
Change oriented identifying
Attribute based of system versions remove some of the problems of version retrieval that are found with simple numbering schemes. Problem is operator needs to know attributes to retrieve and need to use change management system to get relation between version and changes. Change oriented identification is used for systems rather than components so that versions of individual components are hidden from users of the configuration management system. Change sets may be applied in sequence so that in principle at least a version of the system that incorporates any arbitrary set of changes may be created. Therefore, no explicit version identification is required. The configuration management interacts with the version management system indirectly through the change management system.
Within this report I have explained why and how configuration management is used and the processes to do so and covered version management. If you wish to find more information within this subject here are the materials I have used.
___________________________________________________________
Warning!!! All free online research papers, research paper samples and example research papers on Configuration Management topics are plagiarized and cannot be fully used in your high school, college or university education.
If you need a custom research paper, research proposal, essay, dissertation, thesis paper or term paper on your topic, EffectivePapers.com will write your research papers from scratch. Starting at $12/page you can order custom written papers online. We work with experienced PhD. and Master's freelance writers to help you with writing any academic papers in any subject! High quality and 100% non-plagiarized papers guaranteed!
___________________________________________________________Warning!!! All free online research papers, research paper samples and example research papers on Configuration Management topics are plagiarized and cannot be fully used in your high school, college or university education.
If you need a custom research paper, research proposal, essay, dissertation, thesis paper or term paper on your topic, EffectivePapers.com will write your research papers from scratch. Starting at $12/page you can order custom written papers online. We work with experienced PhD. and Master's freelance writers to help you with writing any academic papers in any subject! High quality and 100% non-plagiarized papers guaranteed!
