ITIL : 1 Change management engineering 156 See also Change control Change….
A good example of the change management process in action can be found in software development.
Often users report bugs or desire new functionality from their software programs, which leads to a change request.
The product software company then looks into the technical and economical feasibility of implementing this change and consequently it decides whether the change will actually be realized.
If that indeed is the case, the change has to be planned, for example through the usage of function points.
The actual execution of the change leads to the creation and/or alteration of software code and when this change is propagated it probably causes other code fragments to change as well.
After the initial test results seem satisfactory, the documentation can be brought up to date and be released, together with the software.
Finally, the project manager verifies the change and closes this entry in the change log.
Another typical area for change management in the way it is treated here, is the manufacturing domain.
Take for instance the design and production of a car.
If for example the vehicle’s air bags are found to automatically fill with air after driving long distances, this will without a doubt lead to customer complaints (or hopefully problem reports during the testing phase).
In turn, these produce a change request (see Figure 2 on the right), which will probably justify a change.
Nevertheless, a – most likely simplistic – cost and benefit analysis has to be done, after which the change request can be approved.
Following an analysis of the impact on the car design and production schedules, the planning for the implementation of the change can be created.
According to this planning, the change can actually be realized, after which the new version of the car is hopefully thoroughly tested before it is released to the public.
In industrial plants Since complex processes can be very sensitive to even small changes, proper management of change to industrial facilities and processes is recognized as critical to safety.
In the US, OSHA has regulations that govern how changes are to be made and documented.
The main requirement is that a thorough review of a proposed change be performed by a multi-disciplinary team to ensure that as many possible viewpoints are used to minimize the chances of missing a hazard.
In this context, change management is known as Management of Change, or MOC.
It is just one of many components of Process Safety Management, section 1910.119(l).1 Change management (engineering) 156 See also • • • • • • • • • • • Change control Change management Engineering Change Notice, Engineering Change Order, Change request PRINCE2 ITIL Versioning Release Management Software life cycle Application Lifecycle Management Systems engineering Issue tracking system References [1] Crnkovic, Asklund & Persson-Dahlqvist, 2003 [2] Dennis, Wixom & Tegarden, 2002.
[3] Hinley 1996.
[4] Huang & Mak, 1999.
[5] Actually, not both Require new functionality and Encounter problem have to occur in order to get a CHANGE REQUEST; usually only one of the two will.
Modeling them as unordered activities approximately approaches this meaning; an alternative would be to create two separate ‘starting points’ (i.e.
initial states), both pointing to Request change.
[6] Weerd 2006 [7] Scott & Nisse, 2001.
Further reading • Crnkovi? I., Asklund, U.
& Persson-Dahlqvist, A.
(2003).
Implementing and Integrating Product Data Management and Software Configuration Management.
London: Artech House.
• Dennis, A., Wixom, B.H.
& Tegarden, D.
(2002).
System Analysis & Design: An Object-Oriented Approach with UML.
Hoboken, New York: John Wiley & Sons, Inc.
• Georgetown University (n.d.).
Data Warehouse: Glossary.
Retrieved April 13, 2006 from: uis.
georgetown.edu/departments/eets/dw/GLOSSARY0816.html.
• Hinley, D.S.
(1996).
Software evolution management: a process-oriented perspective.
Information and Software Technology, 38, 723-730.
• Huang, G.H.
& Mak, K.L.
(1999).
Current practices of engineering change management in UK manufacturing industries.
International Journal of Operations & Production Management, 19(1), 21-37.
• IEEE (1991).
Standard Glossary of Software Engineering Terminology (ANSI).
The Institute of Electrical and Electronics Engineers Inc.
Retrieved April 13, 2006 from: www.ee.oulu.fi/research/ouspg/sage/ glossary/#reference_6.
• Mäkäräinen, M.
(2000).
Software change management processes in the development of embedded software.
PhD dissertation.
Espoo: VTT Publications.
Available online: www.vtt.fi/inf/pdf/publications/2000/P416.
pdf.
• NASA (2005).
NASA IV&V Facility Metrics Data Program – Glossary and Definitions.
Retrieved March 4, 2006 from: mdp.ivv.nasa.gov/mdp_glossary.html.
• Pennsylvania State University Libraries (2004).
CCL Manual: Glossary of Terms and Acronyms.
Retrieved April 13, 2006 from: www.libraries.psu.edu/tas/cataloging/ccl/glossary.htm.
• Princeton University (2003).
WordNet 2.0.
Retrieved April 13, 2006 from: dictionary.reference.com/ search?q=release.
Change management (engineering) • Rajlich, V.
(1999).
Software Change and Evolution.
In Pavelka, J., Tel, G.
& Bartošek, M.
(Eds.), SOFSEM’99, Lecture Notes in Computer Science 1725, 189-202.
• Rigby, K.
(2003).
Managing Standards: Glossary of Terms.
Retrieved April 1, 2006 from: sparc.airtime.
co.uk/users/wysywig/gloss.htm.
• Scott, J.A.
& Nisse, D.
(2001).
Software Configuration Management, Guide to Software Engineering Body of Knowledge, Chapter 7, IEEE Computer Society Press.
• Vogl, G.
(2004).
Management Information Systems: Glossary of Terms.
Retrieved April 13, 2006 from Uganda Martyrs University website: www.321site.com/greg/courses/mis1/glossary.htm.
• Weerd, I.
van de (2006).
Meta-modeling Technique: Draft for the course Method Engineering 05/06.
Retrieved March 1, 2006 from: bscw.cs.uu.nl/bscw/bscw.cgi/d1009019/Instructions for the process-data diagram.pdf [restricted access].
157 Configuration Management Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system’s or product’s performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life Top level Configuration Management Activity model [2] cycle of an information system.
CM for information assurance, sometimes referred to as Secure Configuration Management, relies upon performance, functional, and physical attributes of IT platforms and products and their environments to determine the appropriate security features and assurances that are used to measure a system configuration state.
For example, configuration requirements may be different for a network firewall that functions as part of an organization’s Internet boundary versus one that functions as an internal local network firewall.
History Configuration management was first developed by the United States Air Force for the Department of Defense in the 1950s as a technical management discipline of hardware.
The concepts of this discipline have been widely adopted by numerous technical management functions, including systems engineering (SE), integrated logistics support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management methodology, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and application lifecycle management.
Many of these functions and models have redefined configuration management from its traditional holistic approach to technical management.
Some treat configuration management as being similar to a librarian activity, and break out change control or change management as a separate or stand alone discipline.
Configuration Management However the bottomline is and always shall be Traceability.
158 Software configuration management The traditional software configuration management (SCM) process is looked upon by practitioners as the best solution to handling changes in software projects.
It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle.
The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release.
It identifies four procedures that must be defined for each software project to ensure that a sound SCM process is implemented.
They are: 1.
2.
3.
4.
Configuration identification Configuration control Configuration status accounting Configuration audits These terms and definitions change from standard to standard, but are essentially the same.
• Configuration identification is the process of identifying the attributes that define every aspect of a configuration item.
A configuration item is a product (hardware and/or software) that has an end-user purpose.
These attributes are recorded in configuration documentation and baselined.
Baselining an attribute forces formal configuration change control processes to be effected in the event that these attributes are changed.
• Configuration change control is a set of processes and approval stages required to change a configuration item’s attributes and to re-baseline them.
• Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time.
• Configuration audits are broken into functional and physical configuration audits.
They occur either at delivery or at the moment of effecting the change.
A functional configuration audit ensures that functional and performance attributes of a configuration item are achieved, while a physical configuration audit ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation.
Configuration management is widely used by many military organizations to manage the technical aspects of any complex systems, such as weapon systems, vehicles, and information systems.
The discipline combines the capability aspects that these systems provide an organization with the issues of management of change to these systems over time.
Outside of the military, CM is appropriate to a wide range of fields and industry and commercial sectors.[3] Computer hardware configuration management Computer hardware configuration management is the process of creating and maintaining an up-to-date record of all the components of the infrastructure, including related documentation.
Its purpose is to show what makes up the infrastructure and illustrate the physical locations and links between each item, which are known as configuration items.
Computer hardware configuration goes beyond the recording of computer hardware for the purpose of asset management, although it can be used to maintain asset information.
The extra value provided is the rich source of support information that it provides to all interested parties.
This information is typically stored together in a configuration management database (CMDB).
This concept was introduced by ITIL.
The scope of configuration management is assumed to include, at a minimum, all configuration items used in the provision of live, operational services.
Configuration Management Computer hardware configuration management provides direct control over information technology (IT) assets and improves the ability of the service provider to deliver quality IT services in an economical and effective manner.
Configuration management should work closely with change management.
All components of the IT infrastructure should be registered in the CMDB.
The responsibilities of configuration management with regard to the CMDB are: • • • • identification control status accounting verification 159 The scope of configuration management is assumed to include: • • • • • • • physical client and server hardware products and versions operating system software products and versions application development software products and versions technical architecture product sets and versions as they are defined and introduced live documentation networking products and versions live application products and versions • definitions of packages of software releases • definitions of hardware base configurations • configuration item standards and definitions The benefits of computer hardware configuration management are: • • • • • helps to minimize the impact of changes provides accurate information on CIs improves security by controlling the versions of CIs in use facilitates adherence to legal obligations helps in financial and expenditure planning Maintenance systems Configuration management is used to maintain an understanding of the status of complex assets with a view to maintaining the highest level of serviceability for the lowest cost.
Specifically, it aims to ensure that operations are not disrupted due to the asset (or parts of the asset) overrunning limits of planned lifespan or below quality levels.
In the military, this type of activity is often classed as “mission readiness”, and seeks to define which assets are available and for which type of mission; a classic example is whether aircraft on-board an aircraft carrier are equipped with bombs for ground support or missiles for defense.
A theory of configuration maintenance was worked out by Mark Burgess[4] [5] [6] , with a practical implementation on present day computer systems in the software Cfengine able to perform real time repair as well as preventive maintenance.
Configuration Management 160 — • Software testing tools and products (www.dmoz.org/Computers/Programming/Software_Testing/ Products_and_Tools/) at the Open Directory Project • “Software that makes Software better” Economist.com (www.economist.com/science/tq/displaystory.
cfm?story_id=10789417) • Software QA Testing Glossary (www.qatutor.com/glossary.html) • Automated software testing metrics including manual testing metrics (www.innovativedefense.com/img/ UsefulAutomatedTestingMetrics.pdf) Release Management 177 Release Management Release Management is the relatively new but rapidly growing discipline within software engineering of managing software releases.
As software systems, software development processes, and resources become more distributed, they invariably become more specialized and complex.
Furthermore, software products (especially web applications) are typically in an ongoing cycle of development, testing, and release.
Add to this an evolution and growing complexity of the platforms on which these systems run, and it becomes clear there are a lot of moving pieces that must fit together seamlessly to guarantee the success and long-term value of a product or project.
The need therefore exists for dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems.
Although project managers have done this in the past, they generally are more concerned with high-level, “grand design” aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects.
Release Managers (aka “RMs”) address this need.
They must have a general knowledge of every aspect of the Software Development Life Cycle (SDLC), various applicable operating systems and software application or platforms, as well as various business functions and perspectives.
A Release Manager is: • Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.
• Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.
• Architect – helps to identify, create and/or implement processes or products to efficiently manage the release of code.
• Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).
• Coordinator – utilized to coordinate disparate source trees, projects, teams and components.
Some of the challenges facing a Software Release Manager include the management of: • • • • • • • Software Defects Issues Risks Software Change Requests New Development Requests (additional features and functions) Deployment and Packaging New Development Tasks Impact of Agile Software Development on Release Management Agile software development methodologies have driven radically higher numbers of release events in organizations where it has been adopted.
More release events have corresponded to increased pressure on release management teams and their colleagues in IT Operations to track and execute complex application release processes.
Operations teams have used methodologies – such as Information Technology Infrastructure Library ITIL v3 Book: Service Transition (which contains a section on release management) to improve their release management capabilities as they relate to both business applications and internal IT services.
Agile has also driven development and operations teams to collaborate more closely during production release events – this trend is referred to as DevOps.
Release Management 178 Notable Release Management products Notable Release Management products include: Name Go Vendor ThoughtWorks Nolio ASAP Nolio See also • • • • • • Build automation Change management Configuration management Agile software development Information Technology Infrastructure Library Granular Configuration Automation References • Beck, B., Fowler, M.
(2000).
Planning Extreme programming, Addison Wesley.
• Erenkrantz, J.
R.(2003) Release Management Within Open Source Projects.
In: Proceedings of the 3rd Open Source Software DevelopmentWorkshop.
Portland, Oregon, USA, May 2003, S.
51–55.
• Hoek, A.
van der, Hall, R.
S., Heimbigner D., Wolf, A.
L.
(1997) Software release management, Proceedings of the 6th European conference held jointly with the 5th ACM SIGSOFT international symposium on Foundations of software engineering, p.159-175, September 22-25, Zurich, Switzerland.
• Hoek, A.
van der, Wolf, A.
L.
(2003) Software release management for component-based software.
Software—Practice & Experience.
Vol.
33, Issue 1, pp.
77–98.
John Wiley & Sons, Inc.
New York, NY, USA.
• Humble, J., Farley, D.
(2010).
Continuous Delivery, Addison Wesley.
• Krishnan M.
S., (1994).
Software release management: a business perspective, Proceedings of the 1994 conference of the Centre for Advanced Studies on Collaborative research, p.36, October 31-November 3, 1994, Toronto, Ontario, Canada External links • • • • Project Management: Best Practices for IT Professionals [1] Release Management – Where to Start? [2] Managing Software Projects By Frank F.
Tsui [3] Software Release Decisions [4].
References [1] http:/ / books.
google.
com/ books?id=BR9ppkdnIrQC& pg=PA193& lpg=PA193& dq=release+ manager& source=web& ots=M-ejUHsZW6& sig=zwuyg_J60Xwcr77VXjReliQ5WEI& hl=en& sa=X& oi=book_result& resnum=9& ct=result [2] http:/ / www.
itsmwatch.
com/ itil/ article.
php/ 3680776 [3] http:/ / books.
google.
com/ books?id=zUTiHzyyDLwC& pg=PT273& lpg=PT273& dq=release+ manager& source=web& ots=dJwEC7lz_Z& sig=PXBGdOj_4BURbb98N9RpNk1xf18& hl=en& sa=X& oi=book_result& resnum=1& ct=result [4] http:/ / www.
se-cure.
ch/ Publications.
html Issue management 179 Issue management In business, Issue Management refers to the discipline and process of managing business issues and usually implies using technology to electronically automate the process.
In Project Management, the purpose of Issue Management is to ensure that any concerns recognized during a project are addressed in a timely manner and do not go unresolved until they become major problems[1] .
Electronic issue management has gathered steam as a business and technology movement in recent years as mid-sized and large businesses have realized the advantage of implementing systems to manage, document, and track work.
Early examples of issue management systems appeared in the late 1980s with customer ticketing systems.
Businesses that implemented these systems were often addressing customer complaints and needed a method to document, track, and manage complaints to successful resolution.
These systems evolved with the widespread introduction of Information Technology departments, leading to wider deployment of issue management systems in the form of ‘help desk’ systems.
Today, help desk and ticketing remain the most prevalent roles for issue management systems, though common enterprise-wide systems have emerged to consolidate and increase visibility of issues across an organization.
Product or software development Today, issue management systems are commonly used by product development companies to manage requests, changes to products, and reported defects.
A typical issue workflow might look like this with regard to issue state: [issue submitted] -> [open] -> [in evaluation] -> [in work] -> [in test] -> [closed] Where the [in test] and [in work] phases often loop.
A typical issue management electronic workflow might look like this with regard to roles: 1.
2.
3.
4.
5.
An issue is submitted by a customer, salesperson, engineer, or test engineer, often via a web browser.
The issue management system logs the issue and relocates the issue to a predefined representative’s inbox.
The representative evaluates the issue and assigns it to an appropriate employee.
Work is done on the issue, documented in the system, and closed.
In most processes, the originator is notified that the issue has been resolved.
Any issue management process in which there are well defined inputs and outputs can be automated electronically.
There are both private and open source issue management software solutions available to companies interested in implementing issue management.
Open source issue management systems are steadily improving, but still have some short-comings compared to commercial solutions.
At the time of this writing they have not incorporated important system features related to project integration.
Specifically, open source solutions have not yet delivered features that contextualize issues as a part of an overall project, incorporate dependent and transitional fields, and support multiple workflows within a single interface.
The word issues management[2] was first used to describe the social, political, and economic concerns that affect organisations strategic future and viability by Howard Chase in 1976.[3] It is a process that is inherent to the practice of modern Public Relations.
Issue management
Read more about ITIL:
Accredited ITIL Foundation, Intermediate and Expert Certifications
Accredited ITIL Foundation, Intermediate and Expert Certifications, Learn more about ITIL HERE:
ITIL - Accredited ITIL Foundation, Intermediate and Expert Certifications
ITIL - Accredited ITIL Foundation, Intermediate and Expert Certifications