MBA management

Change Management

In a computer system environment, change management refers to a systematic approach to keeping track of the details of the system (for example), what operating system release is running on ach computer and which fixes have been applied). Change control is a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner. It reduces the possibility that unnecessary changes will be introduced to a system without forethought, introducing faults into the system or undoing changes made by other users of software. The goals of a change control procedure usually include minimal disruption to services, reduction in back out activities, and cost effective utilization of resources involved in implementing change.

Change control is currently used in a wide variety of products and systems. For Information technology (IT) systems it is a major aspect of the broader discipline of change management. Typical examples from the computer and network environments are patches to software products, installation of new operating system, upgrades to network routing tables, or changes to the electrical power systems supporting such infrastructure.

Change Control Sets

Change Control has a set of six steps:

1. Record/classify
2. Assess
3. Plan
4. Build/Test
5. Implement
6. Close/Gain Acceptance

Record/ classify
The client initiates change by making a formal request for something to be changed. The change control team then records and categorization would include estimates of importance, impact, and complexity.

The impact assessor or assessors then make their risk analysis typically by answering a set of questions concerning risk, both to the business and to the process, and follow this by making a judgment on who should carry out the change. If the change requires more than one type of assessment, the head of the change control team will consolidate these. Everyone with a stake in the change then must meet to determine whether there is a business or technical justification for the change. The change is then sent to the delivery team for planning.

Management will assign the change to a specific delivery team, usually one with the specific role of carrying out this particular type of change. The team’s first job is to plan the change in detail as well as construct a regression plan in case the change needs to be backed out.

If all stakeholders agree with the plan, the delivery team will build the solution, which will then be tested. They will then seek approval and request a time and date to carry out the implementation phase.

All stakeholders must agree to a time, date and cost of implementation. Following implementation, it is usual to carry out a post implementation review which would take place at another stakeholder meeting.

Close/ gain acceptance
When the client agrees that the change was implemented correctly, the change can be closed.

Change Management Processes

A change management system allows software development companies to streamline software process in order to respond to change requirements more proactively. The practice prompts adherence to standardized methods and procedures in order to minimize the impact on other relevant areas of the software. The aim is to keep the overall system stable without touching a majority of the modules. Time and effort need to be factored in also. Every valid change request must be promptly addressed with minimum efforts.

Software process management needs to be robust enough to tackle external demands ranging from legislative impositions to initiatives in customer service enhancements. Another beneficial effect of change management system is that it strives to maintain a proper balance between the need to implement changes, and the negative effect of changes in a stable system. After all, we need to understand at some point of time that “change is not necessarily a progress.” Each phase of software development life cycle IT project and portfolio management; requirement capture and feasibility study; requirement analysis; application design; coding; testing and debugging; user acceptance and overall lifecycle quality management need to be practiced keeping provisions of the inevitable change requirements. The result of such a system is high visibility and greater predictability of software applications with respect to changes.

One or more of the following components may get affected due to the impact of changes:

• Hardware
• System software
• Communication equipment’s
• Application software
• All related documentation like design documents, user manuals etc.

Scope and Extent of Software Change Management

The first and foremost requirement of a change management system is the implementation of defined (and documented) steps to handle change requirements. Once established, the practice should spread to all areas of the software process management system. Today’s IT houses have already established change handling mechanisms. At the beginning, software engineers and analysts pay attention to individual changes. However, in today’s business environment, organizations functions in geographically distributed areas catering to diverse client segments. Naturally, an enterprise system cannot function like discrete information silos. An impact of a change in a particular segment of the software often has little to moderate effect in other segments also. If the overall system impact is not taken into account, inefficiencies may creep into the system. Such inaccuracies, if not addressed early, may lead to devastating impact at a later stage.

According to a research, about 45% of software development companies cater to software development initiatives that across geographical boundaries and cultures. The extent of change requests handled by these companies can easily be imagined. Over the years, the software engineering discipline has stressed the importance of measurements and metrication in handling changes. The mandatory internal and external audits have enforced process management practices. All these activities have a huge contribution towards software change management.

According to industry analysts, the competency in change management as achieved by software companies in general leaves much to be desired. The challenge is not only from the geographical distribution aspect. Organizational activities like mergers and acquisitions, inability to cope up with rapid hardware and software innovations and monetary concerns in times of economic recession contributes largely towards inefficiencies in change management.

A collaborative approach across functional silos is crucial in achieving a successful change implementation. All processes, including automation mechanisms must work in tandem in order to attain the broader goal of application stability in spite of continual change tremors.

Let us summarize the building blocks of a well coordinated change management system below:

• All development practices should be driven by well defined processes.

• Every activity in the software development life cycle should be properly controlled and measured.

• An efficient asset management practice should be in place. This will help in optimum usage of assets.

• There should be proper time management for all activities.

• Change requirements must be properly validated in order to filter out the most pressing ones with respect to business criticality, time money, and resource availability aspects.

• A proper communication chain should exist in order to communicate change requests promptly across geographically distributed teams.

• An efficient change tracking mechanism should be in place.

• Geographically distributed teams should work in a scalable, expandable, and secure technical infrastructure.

• Support from all quarters need to be granted.

Software Configuration Management(SCM)

In software engineering, software configuration management(SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

SCM concerns itself with answering the question “Somebody did something, how can one reproduce it?” Often the problem involves not reproducing “it” identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analyzing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. Now, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.

The goals of SCM are generally,

• Configuration identification Identifying configurations, configuration items and baselines.

• Configuration control implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.

• Configuration status accounting recording and reporting all the necessary information on the status of the development process.

• Configuration auditing ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.

• Build management Managing the process and tools for builds.

• Process management Ensuring adherence to the organization’s development process.

• Environment management Managing the software and hardware that our system.

• Teamwork Facilitate team interactions related to the process.

• Defect tracking making sure every defect has traceability back to the source.

Software Configuration Management Elements

Software Configuration management is concerned with labeling, tracking and controlling changes in the software components and their relationships.

The purpose of software configuration management is to identify all the interrelated components of software and to control their evolution throughout the various life cycle phases. Software configuration management is a discipline that can be applied to activities including software development, document control, problem tracking, change control, and maintenance. It can provide a high cost saving in software reusability because ach software component and its relationship to other software components have defined.

Software configuration management consists of activities that ensure that design and code are defined and cannot be changed without a review of the effect of the change itself and its documentation. The purpose of configuration management is to control code and its associated documentation so that final code and its description are consistent and represent those items that were actually reviewed and tested. Thus, spurious, last minute software changes are eliminated.

For concurrent software development projects, software configuration management can have considerable benefits. It can organize the software under development and minimize the probability of inadvertent changes. Software configuration management has a stabilizing effect on all software when there is a great deal of change activity or a considerable risk of selecting the wrong software components.

Software Configuration Management Process

Element of Software Configuration Management

Software configuration management identifies a system configuration in order to systematically control Changes, maintain integrity, and enforce tractability of the configuration throughout its life cycle. Components to be controlled include planning, analysis and design documents, source code, executable cod, utilities, job control language (JCT), Test plans, test scripts, test cases, and development reports. The software configuration process typically consists of four elements software component identification, Software version control, configuration building, and software change control, as shown in the above diagram.

Component Identification

A basic software configuration management activity is the identification of the software components that make up a deliverable at ach point of its development. Software configuration management provides guidelines to identify and name software baselines, components, and software configurations.

Software components go through a series of changes. In order to manage the development process, one must establish methods and name standards for uniquely identifying each revision. A simple way to name components revisions is to use a series of discrete digits. The first integer could refer to a software component revisions is to use a series of discrete digits. The first integer could refer to a software component’s external release number. The second integer could represent the internal software development release number. The transition from version number 2.9 to 3.1 would indicate that a new external release 3 has occurred. The software components version number is automatically incremented when the component is checked into the software library. Further levels of qualifiers could also be used as necessary, such as the date of a new version.

A software configuration is a collection of software elements that comprise a major business function. An example of a configuration is the set of program models for an order system. Identifying a configuration is quite similar to identifying individual software components. Configurations can have a sequence of versions. Each configuration must be named in a way that distinguishes it from others. Each configuration version must be differentiated from other versions. The identification of a configuration must also include its approval status and a description of how the configuration was built.

A simple technique for identifying a configuration is to store all its software components in a Single library or repository. The listing of all the components can also be documented.

Version Control

As an application evolves over time, many different versions of its software components are created and there needs to be an organized process to manage changes in the software components and their relationships. In addition, there is usually the requirement to support parallel component development and maintenance.

Software is frequently changed as it evolves through a succession of temporary states called versions. A software configuration management facility for controlling versions is a software configuration management repository or library. Version control provides the tractability or history of each software change, including who did what, why, and when.

Within the software life cycle, software components evolve, and at a certain point each reaches a relatively stable state. But as defects are corrected and enhancement features are implemented, the changes result in new versions of the components. Maintaining control of these software component versions is called versioning.

A component is identified and labeled to differentiate it from all other software versions of the component. When a software component is modified, both the old and new versions should be separately identifiable. Therefore, each version, except for the initial one, has a predecessor. The succession of component versions is the component’s history and tractability. Different versions also act as backups so that one can return to previous versions of the software.

Configuration Building

To build a software configuration on needs to identify the correct component versions and execute the component build procedures .This is often called configuration building.

A software configuration consists of a set of derived software components. An example is executable object programs derived from source programs. Derived software components are correctly associated with each source component to obtain an accurate derivation. The configuration build model defines how to control the way derived software components are put together.

The inputs and outputs required for a configuration build model include the primary inputs such as the source components, the version selection procedures, and the system model, which describes how the software components are related. The outputs are the target configuration and respectively derived software components.

Software configuration management environments use different approaches for selecting versions. The simplest approach to version selection is to maintain a list of component versions. Other approaches entail selecting the most recently tested component versions, or those modified on a particular date.

Change Control

Change control is the process by which a modification to a software component is proposed, evaluated, approved or rejected, scheduled, and tracked. Its basic foundation is a change control process, a component status reporting process, and an auditing process.

Software change control is a decision process used in controlling the changes made to software. Some proposed changes are accepted and implemented during this process. Others are rejected or postponed, and are not implemented. Chang control also provides for impact analysis to determine the dependencies.

Modification of a configuration has at least four elements; a change request an impact analysis of the change, a set of modifications and additions of new components, and a method for reliably installing the modifications as a new baseline.

A change often involves modifications to multiple software components. Therefore a storage system that provides for multiple versions of a single file is usually not sufficient. A technique is required to identify the set of modifications as a single change. This is often called delta storage.

Every software component has a development life cycle. A life cycle consists of states and allowable transitions between those states. When a software component is changed, it should always be reviewed and frozen from further modifications until a new version is created. The reviewing authority must approve or reject the modified software component. A software library holds all software components as soon as they are frozen and acts as a repository for approved component.

A derived component is linked to its source and has the same status as its source. In addition, a configuration cannot have a more complete status than any of its components, because it is meaningless to review a configuration when some of the associated components are not frozen.

All components controlled by software configuration management are stored in a software configuration library, including work products such as business data and process models, architecture groups, design units, tested application software, reusable software, and special test software. When a software components as soon as they are frozen and also acts as a repository for approved component.

A derived component is linked to its source and has the same status as its source. In addition, a configuration cannot have a more complete status than any of its components, because it is meaningless to review a configuration when some of the associated components are not frozen.

All components controlled by software configuration management are stored in a software configuration library, including work products such as business data and process models, architecture groups, design units, tested application software, reusable software, and special test software. When a software component is to be modified, it is checked out of the repository into a private workspace. It evolves through many states which are temporarily out of the scope of configuration management control.

When a change is completed, the component is checked into the library and becomes a new software component version. The previous component version is also retained.

Configuration Item

The term configuration Item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents, software, models, plans, and people. Configuration Management systems oversee the life of the CIs through a combination of process and tools. The objective of these systems is to avoid the introduction of errors related to lack of testing or incompatibilities with other CIs.

Configuration Audit

System audits are carried out against the configuration Management (CM) system to ensure the implementation of CM remains consistent with this manual, and the Configuration Management plan (CMP) or Configuration Management Instruction (CMI), as part of a Quality Assurance (QA) program General aspects to be audited include:

• ECP processes , including CCB functions;

• Integration of ECP and ECO with associated Integrated Logistics Support ( ILS) processes;

• Traceability of approved changes to the original specification and associated documentation;

• Verification that recommendations from previous audits have been implemented;

• The availability of design data in support of proposed changes; and

• The traceability of design decisions back to the Specification, Mission Profile and Use Study.

• The audit may be limited to verification of the CM system’s use and accuracy.

Audit Plans

Audits are usually time and resource intensive. Plans must be devised for their conduct, to ensure all resources are available prior to the event. Contractors may be tasked with preparation of the Audit plan during the project phase. Areas to be covered in the plan include: Identification of audit type;

• Scope and schedule;
• Audit schedule;
• Identification of auditable items;
• Applicable standards;
• Support personnel and teams;
• Responsibilities;
• Venus/facilities;
• Documentation to be audited against;
• Support documentation;
• Support equipment;
• Certification forms and methods;
• Checklists for conduct of audit;
• Action items forms ( items to be corrected after audit); and
• Post audit responsibilities.

Auditing Reports

All audits are to result in a written report, which is to be tabled at the CCB and become part of the Configuration Status According. The report is to state, as a minimum:

• Non conformances detected,
• Outstanding action items from previous audits,
• Action items from this audit, and
• Recommendations for conduct of future audits.

Web engineering is the establishment and use of sound scientific, engineering and management principles and disciplined and systematic approaches to the successful development, deployment and maintenance of high quality Web based and applications.

Configuration Control for Web Engineering

Web engineering principles and approaches can bring the potential chaos in Web based system development, starting from conception and development, performance evaluation, and continual maintenance.

Major web engineering include:

Requirements specification and analysis

Web-based system development methodologies and techniques

Integration with legacy systems

Migration of legacy system to Web environments

Web-based real-time applications development

Testing, verification and validation

Quality assessment, control and assurance

Configuration and project management

“Web metrics’- metric for estimation of development efforts

Performance specification and evaluation

Update and maintenance

Development models, teams, staffing

Human and culture aspects

User centric development, user modeling and user involvement and feedback

End user application development

Education and training
Copyright © 2015         Home | Contact | Projects | Jobs

Review Questions
  • 1. What is change management? What are the steps involved in change control? Explain.
  • 2. Explain the change management processes.
  • 3. What do you mean by software configuration management? State its goals and elements.
  • 4. Write short notes on the following

    a) Version Control
    b) Web engineering
    c) Chang control Configuration audit
Copyright © 2015         Home | Contact | Projects | Jobs

Related Topics
Change Management Keywords
  • Change Management Notes

  • Change Management Programs

  • Change Management Syllabus

  • Change Management Sample Questions

  • Change Management Subjects

  • EMBA Change Management Subjects

  • Change Management Study Material

  • BBA Change Management Study Material