May 18th, 2010 by Bracken
Configuration Management is a discipline that is unique to the business of developing software so is not specifically addressed anywhere in the PMBOK. The purpose of this article is to offer suggestions on how this discipline can be incorporated into your project management plans for a software development project with the least amount of disruption. Although none of the elements of configuration management are directly addressed in the PMBOK you’ll find that developing a software application of any size is impossible without some elements of configuration management. The source library used to version and release the software is a good example. CMM also specifies that the purpose of configuration management is to maintain the integrity of the software throughout the project’s software life cycle. Configuration management will benefit the organization throughout the entire life cycle of the software product, lasting well beyond the end of the project which introduces it.
Beyond helping in the CMM/CMMI certification process, adhering to the criteria set for level 2 certification in the area of configuration management will not only benefit your software project but will also benefit future projects and help the support organization maintain the software products produced. The areas discussed in this series previously (requirements management, project planning, project tracking and oversight, subcontract management, and quality assurance) all align with some knowledge area from the PMBOK so compliance with those criteria should not add significantly to the project scope. The activities required to comply with CMM/CMMI criteria in this area might add significant overhead to your project. You should compare the needs of the project for configuration management work against the work required to meet CMM/CMMI level 2 criteria, identify the work and tools required to address the delta and ensure that your project is adequately funded and resourced to undertake the additional work.
As with the other Key Process Areas (KPAs), Software Configuration Management is organized into goals, commitments, abilities, activities, measurements, and verifications.
Goals
1. Software configuration management activities are planned.
2. Software products under configuration management are identified, controlled, and available.
3. Changes to identified products are controlled.
4. Affected groups and individuals are informed of the status and content of software baselines.
These goals will all align well with a well managed software development project. Configuration management work, like all the work of the project is planned, staffed, and scheduled, changes are controlled by the Integrated Change Control System and the content of baselines is communicated to the stakeholders in accordance with the Communications Management plan. Keep in mind that the context in which CMM/CMMI uses the term change control is specific to the software products under management and will require a tool to manage version control.
Commitment to Perform
Commitment is demonstrated by the written organizational policy for software configuration management (SCM). This policy must state who is responsible for SCM, how SCM is implemented through each project life cycle, a source library tool is used, and that baselines are established and regularly audited. The policy will be up to the organization to define unless it is specified in the scope for your project.
Ability to Perform
Ability to perform is demonstrated by the establishment of a Software Configuration Control Board (SCCB) and a Software Configuration Management (SCM) group. The SCCB is responsible for establishing software baselines, authorizing changes to the baselines, and releasing the software. The SCM group is responsible for the implementation and management of the source library and all SCM processes, procedures, standards, and plans. In addition to the implementation of these 2 groups, the organization is responsible for providing resources and funding for their activities and for training the SCCB, SCM group, and the software engineering group in SCM activities.
The creation of the SCCB, SCM group, and all the processes, procedures, plans and standards called for here will be in addition to work required to establish a source library tool and a librarian which are minimal needs for the average software project. These groups and documentation will take considerable work to implement and should be specified as part of the project scope if they are to be undertaken.
Activities Performed
1. An SCM plan is prepared for the project (and for every project) in accordance with a documented procedure. This plan will be part of the project plan and will be used as part of that plan to control SCM activities for the project.
2. A source library system is established. The criteria CMM/CMMI has for the library are pretty much what any good tool will offer, with these possible exceptions: that it support archival and recovery of configuration items and that it store SCM records and create SCM reports.
3. The software work products to be placed under configuration management are identified. “Software work products” include such ancillary items as Business Requirements Documents, Functional Specifications, Detail Design Documents, test plans, etc. Identification also includes a unique identifier for each item (this will be enforced by the library tool), the baseline it belongs to, and the owner (developer, analyst, or tester).
4. Change requests and bug reports are recorded, reviewed, decided upon, and tracked according to a documented procedure. The Integrated Change Control System has overall responsibility for managing changes to the project, including configurable items, and the system should be described in your Change Management plan.
5. Changes to baselines are controlled according to a documented procedure. The procedure should ensure that software is properly tested when it is changed, the SCCB approves changes to configurable items, and that check-outs and check-ins are performed properly (i.e. controlled by the source library). The procedure should also identify a change request or bug report with each change or fix. One way of facilitating this activity is by integrating your SCCB and Integrated Change Control Boards (ICCB).
6. Products from the source library are created and their release is controlled by a documented procedure. The procedure referred to here is the build process. The librarian or build master should have a documented procedure which they follow to build and release a product. The procedure should include such things as when and how the library is frozen, how a build is authorized (by the SCCB), and when builds are to occur.
7. The status of configurable items is recorded according to a documented procedure. This means that the source library tool is capable of reporting the current version of each item, retrieving archived versions, and the composition of each release is known (the items included and the version of each item). The source library tool should also be capable of reporting on the reason for each new version/update. Reasons will include new features, approved changes, and bug fixes.
8. Standard reports on SCM activities, baseline contents, etc. are developed and made available to all affected groups. The reports referred to are non-technical and include such information as change requests, bug reports, as well as summary reports of changes to each baseline and audit results. These reports should be described in your Communications Management plan.
9. Software baseline audits are conducted according to a documented procedure. The audits should include assessments of baseline integrity, source library structure, baseline contents (for completeness and correctness), and SCM standards and procedures compliance. The audit results must be reported to the project manager and audit points tracked to closure. Audits should be conducted by an external body but if the identification of this body is an issue; make the SCCB responsible for the audit.
Measurement and Analysis
You are required to measure your SCM activities. The measurements include progress to plan for configuration management activities, performance to budget for these items, as well as metrics for change requests. By assigning the various team members working on SCM or SCCB activities to an SCM or SCCB group you will facilitate using your MS Project file to report on only those activities. By dividing the work in the MS Project file into different areas including one for software development, and identifying change requests with the area they effect you can isolate SCM related changes and report on those.
Verification and Implementation
SCM activities should be reviewed by senior management periodically. For the purposes of the project these reviews can occur at Gate Review meetings or Steering Committee meetings, or in separate meetings scheduled for the purpose. SCM activities should also be reviewed with the project manager. This criterion will be met if you organize these meetings and are in attendance. The SCM group periodically audits software baselines to verify content and correctness. It is unclear to me exactly what the difference is between this audit and the one described in Activity #9, other than who performs the audit. Verification also calls for the SQA group to review and/or audit the work products and report the results. The SQA audit should assess the adherence of the SCM, SCCB, software engineering group, and testers to the SCM procedures and standards.
A great deal of the criteria for CMM/CMMI Level 2 certification will be met by a project manager following best practices for software development projects. There is no better way that I know of to demonstrate a grasp of project management best practices than certification as a Project Management Professional (PMP). Project managers who meet PMI’s criteria can attain the certification by taking a PMP course or similar PMP exam preparation training and then writing the certification exam. Criteria that fall outside the realm of project best practices have been identified here and should for part of your project plan.
http://www.threeo.ca
Article Source: http://EzineArticles.com/?expert=Dave_Nielsen
April 29th, 2010 by Bracken
Configuration Management is a discipline that is unique to the business of developing software so is not specifically addressed anywhere in the PMBOK. The purpose of this article is to offer suggestions on how this discipline can be incorporated into your project management plans for a software development project with the least amount of disruption. Although none of the elements of configuration management are directly addressed in the PMBOK you’ll find that developing a software application of any size is impossible without some elements of configuration management. The source library used to version and release the software is a good example. CMM also specifies that the purpose of configuration management is to maintain the integrity of the software throughout the project’s software life cycle. Configuration management will benefit the organization throughout the entire life cycle of the software product, lasting well beyond the end of the project which introduces it.
Beyond helping in the CMM/CMMI certification process, adhering to the criteria set for level 2 certification in the area of configuration management will not only benefit your software project but will also benefit future projects and help the support organization maintain the software products produced. The areas discussed in this series previously (requirements management, project planning, project tracking and oversight, subcontract management, and quality assurance) all align with some knowledge area from the PMBOK so compliance with those criteria should not add significantly to the project scope. The activities required to comply with CMM/CMMI criteria in this area might add significant overhead to your project. You should compare the needs of the project for configuration management work against the work required to meet CMM/CMMI level 2 criteria, identify the work and tools required to address the delta and ensure that your project is adequately funded and resourced to undertake the additional work.
As with the other Key Process Areas (KPAs), Software Configuration Management is organized into goals, commitments, abilities, activities, measurements, and verifications.
Goals
1. Software configuration management activities are planned.
2. Software products under configuration management are identified, controlled, and available.
3. Changes to identified products are controlled.
4. Affected groups and individuals are informed of the status and content of software baselines.
These goals will all align well with a well managed software development project. Configuration management work, like all the work of the project is planned, staffed, and scheduled, changes are controlled by the Integrated Change Control System and the content of baselines is communicated to the stakeholders in accordance with the Communications Management plan. Keep in mind that the context in which CMM/CMMI uses the term change control is specific to the software products under management and will require a tool to manage version control.
Commitment to Perform
Commitment is demonstrated by the written organizational policy for software configuration management (SCM). This policy must state who is responsible for SCM, how SCM is implemented through each project life cycle, a source library tool is used, and that baselines are established and regularly audited. The policy will be up to the organization to define unless it is specified in the scope for your project.
Ability to Perform
Ability to perform is demonstrated by the establishment of a Software Configuration Control Board (SCCB) and a Software Configuration Management (SCM) group. The SCCB is responsible for establishing software baselines, authorizing changes to the baselines, and releasing the software. The SCM group is responsible for the implementation and management of the source library and all SCM processes, procedures, standards, and plans. In addition to the implementation of these 2 groups, the organization is responsible for providing resources and funding for their activities and for training the SCCB, SCM group, and the software engineering group in SCM activities.
The creation of the SCCB, SCM group, and all the processes, procedures, plans and standards called for here will be in addition to work required to establish a source library tool and a librarian which are minimal needs for the average software project. These groups and documentation will take considerable work to implement and should be specified as part of the project scope if they are to be undertaken.
Activities Performed
1. An SCM plan is prepared for the project (and for every project) in accordance with a documented procedure. This plan will be part of the project plan and will be used as part of that plan to control SCM activities for the project.
2. A source library system is established. The criteria CMM/CMMI has for the library are pretty much what any good tool will offer, with these possible exceptions: that it support archival and recovery of configuration items and that it store SCM records and create SCM reports.
3. The software work products to be placed under configuration management are identified. “Software work products” include such ancillary items as Business Requirements Documents, Functional Specifications, Detail Design Documents, test plans, etc. Identification also includes a unique identifier for each item (this will be enforced by the library tool), the baseline it belongs to, and the owner (developer, analyst, or tester).
4. Change requests and bug reports are recorded, reviewed, decided upon, and tracked according to a documented procedure. The Integrated Change Control System has overall responsibility for managing changes to the project, including configurable items, and the system should be described in your Change Management plan.
5. Changes to baselines are controlled according to a documented procedure. The procedure should ensure that software is properly tested when it is changed, the SCCB approves changes to configurable items, and that check-outs and check-ins are performed properly (i.e. controlled by the source library). The procedure should also identify a change request or bug report with each change or fix. One way of facilitating this activity is by integrating your SCCB and Integrated Change Control Boards (ICCB).
6. Products from the source library are created and their release is controlled by a documented procedure. The procedure referred to here is the build process. The librarian or build master should have a documented procedure which they follow to build and release a product. The procedure should include such things as when and how the library is frozen, how a build is authorized (by the SCCB), and when builds are to occur.
7. The status of configurable items is recorded according to a documented procedure. This means that the source library tool is capable of reporting the current version of each item, retrieving archived versions, and the composition of each release is known (the items included and the version of each item). The source library tool should also be capable of reporting on the reason for each new version/update. Reasons will include new features, approved changes, and bug fixes.
8. Standard reports on SCM activities, baseline contents, etc. are developed and made available to all affected groups. The reports referred to are non-technical and include such information as change requests, bug reports, as well as summary reports of changes to each baseline and audit results. These reports should be described in your Communications Management plan.
9. Software baseline audits are conducted according to a documented procedure. The audits should include assessments of baseline integrity, source library structure, baseline contents (for completeness and correctness), and SCM standards and procedures compliance. The audit results must be reported to the project manager and audit points tracked to closure. Audits should be conducted by an external body but if the identification of this body is an issue; make the SCCB responsible for the audit.
Measurement and Analysis
You are required to measure your SCM activities. The measurements include progress to plan for configuration management activities, performance to budget for these items, as well as metrics for change requests. By assigning the various team members working on SCM or SCCB activities to an SCM or SCCB group you will facilitate using your MS Project file to report on only those activities. By dividing the work in the MS Project file into different areas including one for software development, and identifying change requests with the area they effect you can isolate SCM related changes and report on those.
Verification and Implementation
SCM activities should be reviewed by senior management periodically. For the purposes of the project these reviews can occur at Gate Review meetings or Steering Committee meetings, or in separate meetings scheduled for the purpose. SCM activities should also be reviewed with the project manager. This criterion will be met if you organize these meetings and are in attendance. The SCM group periodically audits software baselines to verify content and correctness. It is unclear to me exactly what the difference is between this audit and the one described in Activity #9, other than who performs the audit. Verification also calls for the SQA group to review and/or audit the work products and report the results. The SQA audit should assess the adherence of the SCM, SCCB, software engineering group, and testers to the SCM procedures and standards.
A great deal of the criteria for CMM/CMMI Level 2 certification will be met by a project manager following best practices for software development projects. There is no better way that I know of to demonstrate a grasp of project management best practices than certification as a Project Management Professional (PMP). Project managers who meet PMI’s criteria can attain the certification by taking a PMP course or similar PMP exam preparation training and then writing the certification exam. Criteria that fall outside the realm of project best practices have been identified here and should for part of your project plan.
http://www.threeo.ca
Article Source: http://EzineArticles.com/?expert=Dave_Nielsen
January 28th, 2010 by Bracken
Configuration management (CM) is a support management technique that has been adopted and adapted for application in a number of industries. Originally created by the U.S. Military in the 1950s, however, configuration management involves many different disciplines that have been around much longer.
Configuration management is a blueprint for a model of managing information throughout the development cycle and for the rest of the life of a product. Generally there are four basic elements to configuration management:
Identification – is the process of determining the attributes of a configuration item (Any intermediate work product, product component, or product placed under CM, for example, a software script or prototype).
Change Control or Management – is the approval process required to change something about a configuration item.
Status Accounting – is the process of checking a configuration item against the CM model to make sure that any changes are correct.
Verification – answers the question, “Have we made the right thing?” This is answered by, among other things, analyzing tracing reports, to ascertain that all requirements have been met, or by usability assessments, to determine the usability of the system. This check can be done when the change is made, or once the product is finished, preferably both.
Software is available to easily and quickly manage and track your processes, steps, or cycles. A piece of software, a complex weapon system, or even a blanket will go through several steps before becoming a completed product – CM software watches over these processes.
There are many different options for CM software, including some that are available for free on the internet. Some are created for a specific industry, while other options can be used for a broader range of projects. CM software can help you manage complicated processes and cycles, no matter what specific field you are in. With CM software, you do not have to spend effort on managing all this information, allowing you to be more productive in the meantime.
Configuration management may seem very complex, and it can be. However, it is the best method of dealing with complex project or system requirements.
January 21st, 2010 by Bracken
Configuration management with network performance monitoring will greatly increase the efficiently of performing various complex tasks, and effectively deliver high quality services. These networks of information systems regularly experience regular changes, however, sometimes problems occur that stop the functionality of the entire system. Network configuration management software can not only help reduce this indecent, but also return the all the network settings back to a time of good configuration. Without the use of network configuration management software, dealing with problems would much more a challenge.
Improved coordination and rhythmic working of the network system can also be improved by network configuration management software. Changes are tracked simultaneous as changes are made on the network, even to multiple devices.
Network performance monitoring is pivotal to enhance the performance of the network. You can analyze important details, like on resource utilization and network traffic is its main function. The ability to run these analyzes are of great importance, has they can help you increase efficiency on both the hardware and software components of the network.
There are certain tools that can be used to conduct network performance monitoring. The Windows 2000 package provides several tools, which are the most widely used in the industry. These include tools for both System Monitor and Network Monitor, as the server is a pivotal part of the network. The main function of the System Monitor is to track network throughput and resource utilization. Network Monitor on the other hand, utilizes captured network traffic in order to track network throughput.
A part from the two tools already mentioned, there are still other widely available tools that can be use in monitoring network performance. You should always select tools that are proven to be most effect and efficient for your specific use.
January 21st, 2010 by Bracken
The concept of configuration management has been used by businesses worldwide for more than fifty years. Originally developed by the U.S. military, this modality has been adopted and adapted for application in a number of industries.
That’s great, but what exactly is configuration management? Essentially, configuration management is a model of the life cycle of the product, process or information. This is something like a blueprint for any project it adjusts to, basically. Speaking generally, four elements make up configuration management – identification, change control/management, status accounting as well as verification. To discuss these elements, briefly, we have to tell you about some terms.
Identification determines the qualities of a configuration item. A particular product will have an end user, such as a software or specific piece of equipment. Change control includes an approval process as well as the protocols necessary to change a configuration. Status accounting is the ability to check an item against the “blueprint” given by the configuration management model originating from the identification process – and last of all, status accounting is ensuring that changes made in a configuration item has gone exactly according to plan.
This check can be done when a change has occurred or once the product is completed, preferably both. Configuration management may sound highly complex, and it certainly can be. It is, however, the preferred method of project management for complex, intricate endeavors that require an involved, multi-step process. Working with a configuration management system avoids an inordinate amount of challenge when implementing incremental modifications in a process or product over time. Of course, it is not performed by drawing flowcharts on a chalkboard — not in today’s world.
This kind of software allows for ease in tracking and managing the production process. While it is still very much in use by the military, configuration management is used by project managers in a host of disciplines, most notably in software development.
Very much like the complex weapon system, a single piece of software goes through steps before emerging as a finished product ready for use – configuration management software aids in the having to watch over this often complex, labyrinthine process. This concept software offers dozens of options, including some that are offered free of charge on the Internet.
Some are created for a specific set of tasks (e.g., managing UNIX network changes), while other options can handle a broader range of projects. Configuration management can help you manage complicated processes and cycles, no matter what specific field you’re using it for. With configuration management software, you don’t have to spend effort on this and can be more productive in the meantime.
December 30th, 2009 by Bracken
Configuration management is a support management technique that has been around for over 50 years, and is use by many organizations and companies. Originally created by the US Military, the ideas of this modality have been adopted, and adapted for use in many different industries.
Configuration management is a model of product, information, or process life cycle. It is a blueprint adapted to specific projects. Generally there are four elements to configuration management:
Identification – is the process of determining the attributes of a configuration item (Any intermediate work product, product component, or product placed under configuration management, for instance, a piece of equipment or software).
Change Control or Management – is the approval process required to change a configuration item.
Status Accounting – is the capacity to check an item against the “blueprint” provided by the configuration management model resulting from the identification process. For the purpose of making sure that a change made in a configuration item has gone according to plan.
Verification – answers the question “Have we made the right thing?” This is answered by, among other things, analyzing tracing reports, to ascertain that all requirements have been met, or by usability assessments, to determine the usability of the system. This check can be done when the change is made, or once the product is finished, preferably both.
This type of software exists to make tracking and managing your process, steps, or cycles a relatively simple task. Configuration management is also greatly used outside of the military, configuration management is used by project managers in a variety of fields, most notable in the software development field.
Much like a complex weapon system, a piece of software goes through many step before emerging as the finished product, and configuration management software can take some of the sting out of watching over this sometimes labyrinthine process. Dozens of options are available for those interested in using this concept of software, many available for free on the internet.
Some of these are made for a very specific set of tasks, while others are made for a wider scope of projects they can handle. No matter what field you are in, configuration management is an effective model for keeping a track of complicated development and production cycles and processes. Configuration management software can automate a great deal of this for you.
Configuration management may sound very complex, and it can be. However, it is perhaps the best method of project management to dealing with complex and intricate project requirements. Working with a configuration management system makes implementing incremental changes in a process or product over time much less of a challenge.
December 29th, 2009 by Bracken
Here are some common Configuration Management terms and definitions.
Audit: Checking that a configuration item released for usage meets demands—that it fulfills specifications and, when released, is complete according to configuration management information. In this book, this is regarded as a quality assurance activity.
Baseline: This expression is not used in this book, except in direct quotes from standards or maturity models.
Binaries: Files whose contents are translated (compiled) into binary presentations, with variables of only yes or no (0 and 1).
Check-in: Placement of a configuration item in storage in the controlled library.
Check-out: Release of a configuration item from storage in the controlled library to production.
Configuration Control Board (CCB) or Configuration Change Board: A group of people responsble for assessing, and approving or rejecting, proposed changes to configuration items and responsible for the performance of approved changes.
Configuration item: Any intermediate work product, product component, or product placed under configuration management.
Configuration management system: All the procedure descriptions, templates, and tools that collectively support configuration management performed in a given context.
Dynamic library: A repository used during production. It is not regarded as belonging to the configuration management process area.
Library: A repository for a collection of items.
Life-cycle-dependent process: A process in operation for a limited period during the product’s lifetime, such as design or unit test. Such a process may be repeated throughout the product’s lifetime in an iterative development model.
Life-cycle-independent process: A process that must be in effect throughout a product’s lifetime, such as project management or configuration management.
Master library: A controlled repository for storing configuration items. Also called a configuration management library.
Metadata: Information about configuration items. For instance, a document placed under configuration management is a configuration item, while the name and number of the document are metadata for the item.
Process description: A description of the techniques, methods, conventions, and procedures employed in connection with a certain activity.
Product: Something produced. It may be for internal use, such as a design sketch, or for delivery, such as an entire software system.
Release or Baseline: A collection of configuration items that together form one configuration item. The collection is formed to be deliverable and useful as an entity.
Static library: A repository for items in use. It is not regarded as belonging to the configuration management process area.
Support process: Processes used in all other processes at various points in a software project’s life cycle. Support processes in themselves make no sense; they make sense only with other processes. For instance, naming is a support process; naming only makes sense if another process has created a product to name.
December 27th, 2009 by Bracken
It is quite difficult to explain configuration management to someone who has not actually experienced it firsthand. Configuration management has been considered the “holy grail” of development and information technology companies. While there are limitations in defining the inner workings of configuration management, it can be described by its goals and purposes in which it is setup for.
Configuration management makes it easier for computer systems to evolve with the changes in software and computer technology. Constant upgrades to computer systems, networks, and products are required, because of the ever increasing complexity of information technology. In a nut shell, configuration management can reduce instances of errors caused by upgrading computer systems to newer version. This is done by tracking the changes and components of a computer system. This will reduce network downtime and unintentional outages. In addition, configuration management maintains the integrity of the entire computer system, by assuring that all changes and configurations have been deployed appropriately for all components in the system.
Configuration management reduces the risk when making changes or configuring new computer systems. Systems and even security solutions such as firewalls tend to be more hazardous when a mis-configuration occurs. Configuration management makes it easier to change configurations and setups of computer systems, by providing a restore point option when a new configuration version or upgrade fails to work properly. Configuration management software enables a turn back to a previously good configuration when new configuration changes fail. This will not only reduce configuration risks, but will also minimize network downtime, which constitute a loss of productivity.
Configuration management enhances the security features of a computer network. With a configuration management software in place, all processes, configurations and changes that take place in a computer system or network can be tracked. This greatly reduces the vulnerabilities of computer systems intrusions.
December 24th, 2009 by Bracken
Where should you start when building your CMDB?
Many consultants and vendors suggest purchasing a tool before beginning the building a Configuration Management Database (CMDB). However, this is unnecessary since most IT organizations have very little idea exactly what type of information will eventually be added into the database.
To start, an MS Excel spreadsheet will work fine. The idea is to begin by mapping out the entire Configuration Management process prior to the purchase of a fancy, and expensive tool. Often one of the biggest dilemmas associated with building the CMDB is deciding where to begin.
It is considered good practice to involve other process owners in the design of the CMDB. This way, you can ensure that the database contains information that will be immediately useful and beneficial to the organization. This also helps in getting started.
Most organizations usually already have some form of Incident and Change Management processes in place. These processes are sometimes referred to as the “customers” of the Configuration Management process.
In this sense, Incident and Change Management will benefit directly from the data to be stored in the CMDB. Starting with the requirements from these two processes is also an effective way to resolve the often lengthy discussions regarding the CMDB strategy and design.
For example, the Change Management process uses relationship data from the CMDB to help in determining the potential impact and/or risk, to IT service availability, associated with changing a particular Configuration Item (CI). This is helpful in the planning and coordinating of changes so as to prevent unwanted downtime.
Likewise, the Incident Management process (with the Service Desk) utilizes the relationship data in the CMDB to determine the impact of an unplanned outage event on the user community or on defined service levels. The Service Desk can also use the CMDB to discover whether the CI is associated with any known defects or errors. In this event, workarounds may also be available to resolve the situation and thereby minimize the impact on the IT service.
It’s also helpful for the Incident and Change Management processes to have a certain level of maturity before beginning Configuration Management. This is mostly because, there should be some idea as to what type of information will be best in helping these processes to be effective in achieving their objectives.
For example: what level of detail is required for the Incident Management process to be able to adequately resolve breakdowns in order to meet agreed service levels? For Change Management: What level of system detail is necessary to accurately assess the risk associated with a particular change so as to maintain the required level of stability.
In practice, these thresholds are usually different for different IT systems and services. Therefore, the decisions regarding the breadth and depth of your CMDB will depend largely on the level of control required for each IT system/service. This control will depend mostly on the importance and required system availability.
For each service, start with those CIs that:
- Are subject to change
- Are necessary to deliver a service
- Can be managed
- Can be uniquely identified
Once the scope of the CMDB has been decided, a detailed project plan should be created. This plan should probably be divided into several phases with discovery and CMDB population for each IT Service. This means that once the level of detail is defined for each IT Service within the project scope, this master plan should be divided into roll-out phases and outline all services included for each phase.
Each phase will include CI discovery tasks followed by CMDB population tasks. Additionally, auditing and verification (of data) tasks are also very important as the accuracy of the data is critical to the success of the database.
Each CI entered into the database should have an owner or someone who will be responsible for making sure that the data regarding that CI is both complete and accurate. The CI should also be assigned a unique identifier, CI name, that will never change throughout the entire life cycle (i.e., CI purchase to retirement.) This means, that you should think twice before including any intelligence in the naming convention that references things which are subject to change (location, owner, host names etc.)
The name should make sense (i.e., servers begin with the letter s, perhaps) but should not be such that the name no longer makes sense when circumstances change (data center move, for example). This information can always be included in the CI attributes.
The naming convention should also be consistent across all environments. When deciding which relationships to map for each CI, consider first only the important relationships. This means, begin by describing in the CMDB, the most obvious relationships between CIs.
For servers, the important relationships might be what the server is connected to, which applications are running on the server, which services are dependent on the server, etc.
Once this has been decided, it is time to begin the population of the CMDB. Again, the CMDB can start off being something as simple as one or more excel spreadsheets.
What’s important is the process. A sound and well thought out process regarding the design of the CMDB as well as the ongoing maintenance of complete and accurate information are the keys to creating a successful and effective repository.
danielle j. baker
IT PROCESS IMPROVEMENT PROFESSIONAL
Master Certified ITIL Service Management Specialist with advanced knowledge and practical experience in leading the end to end design, delivery and management of customized ITIL based best practice solutions for Fortune 500 companies across multiple industries.
Article Source: http://EzineArticles.com/?expert=Danielle_J._Baker
December 19th, 2009 by Bracken
The concept of software configuration management can be very hard to understand, unless you received a well guided introduction to it. However, many new comers will simply be placed in front a computer running an open source data CM package. The prerequisite for working with such software in CM is ‘grade A’ knowledge of C++, Java, and the basic working knowledge of Linux. This can be initially overwhelming and induce a black stare.
Configuration management literally means managing change or managing information for change. So if two users are trying to access the same Word doc in a local network they will usually be unable to edit the doc at the same time. This is because the network cannot accommodate two sets of changes at once. Without any configuration management system there is the potential for two users to open the document, do separate work then for the last one to save to overwrite the work already done. The CMS is there to avoid these types of errors.
The example is a very basic one and with CMS both users can check out their copy of the file, while the system keeps a record of every version saved and merges the changes to the document. The Word doc example is not where CMS is most important as the real value of CMS is in software development. If you have scores of software developers working on the same source code files then a software configuration management system is essential.
SCM systems work on the basis of a central database of all files. Users can check out the files, make alterations and then check them back in again, and then the files are available to all users again. The system can check changes against the original file and update them keeping an archive of each generation. Every SCM will have concurrent management and versioning.
Concurrent management is a feature that allows multiple changes from different users a2nd tfhen merges the changes. Dependent on the system configuration the SCM system will either process the changes itself, minimize the users, or it will notify the user to do so manually.
Versioning is the feature that stores archive copies of every file in the database so that users can open previous versions of a file. They also can track the history of files to establish who checked what files out and when. Synchronization is the process of a user submitting their file to the database so that the SCM system can update the file.