Configuration Management and Change Control Change is inevitable! So it has to be planned for and managed.

What is configuration management? Identifying, organising and controlling modifications to software During Development During the software lifetime Aims to increase productivity, efficiency and quality by reducing mistakes and duplicated or wasted effort Remember that change can (and will) occur at any time so activities are developed to Identify and control changes Ensure changes are implemented properly Report changes to ‘stakeholders’ Establishing Baseline Versions of Software A formally reviewed and agreed ‘release’ or ‘version’ of a product That can act as known starting point for future versions Changes can only be made to baselines if approved

What is Software Configuration The software process consists of Software Configuration Items (SCI’s) Programs (source code and executables) Documentation (user and technical) Data (internal to programs or external) As a software development continues, the number of items will increase Items need to be managed to ensure that changes are reflected in all relevant items for all changes for the lifetime of the software Change Occurs for many reasons, including: New business or market conditions; New customer needs ; Re-organisation of the business (up or down in size and complexity) ; Budgetary or scheduling constraints ; As time progresses, users (and developers) know more about the system, its limitations and possibilities Most changes are justified and therefore must be taken into consideration

The Configuration Management Process Typical SCI’sControlling the SCI’s Feasibility study and outline design System Specification Requirements Analysis System Requirements Specification Software Design Design Specification Coding Source Code Testing Test plans and procedures Release Operational Systems Project Database SCI extracted approved stored modified Formal technical reviews Software engineering tasks SCM controls Diagrams taken from Pressman Pages

Version Control Procedures and tools to manage versions of configuration objects A software system may contain hundreds of components, each of which may exist in many different versions Version management requires unique identification of each SCI version, allowing specific version components to be recovered as required Three techniques for component version identification Version numbering – components given unique version number Attribute based identification – components have a name (not unique across versions) and a set of attributes (which differ for each version) Change-oriented identification – as either of the above but attributes also associate with one or more change requests. Specific versions of a particular SCI can then be retrieved using one of several different ‘indexes’ depending upon the information available to the retrieving developer

Release Management A release is an agreed version that is distributed to customers A release may include Executable code Configuration files Data files An installation program Documentation (electronic and/or paper) Packaging and publicity Customers may choose not to install a release New releases must therefore be independent of previous releases and contain all of the components necessary for full functionality It is an expensive process deciding when to issue a release; but it is an important consideration Too frequent – customers may not upgrade Too infrequent – may lose market share, or if a bespoke development the system may diverge from the business process it is intended to support

Change Control Uncontrolled change rapidly leads to chaos Change control combines human procedures and automated tools A change request is submitted and evaluated to assess technical merit, potential side effects, overall impact on other SCI’s and cost A decision can made as to the feasibility of the change If feasible, the required SCI’s need to be checked out of the project database Appropriate changes are made, documented and tested Components checked back in and version control mechanisms create the next version, or if major changes made, release of the system Changes can be anything from minor  major in size and impact

Configuration Audit How can changes be assured of their quality? Formal technical reviews Focuses on technical correctness of change Consistency with other SCI’s, has the changed been cascaded Potential side effects examined – does this effect anything else Software configuration audits Has the change been made, has anything else been done? Has a formal technical review been conducted, what was the outcome? Have coding and documentation standards been followed Have the changes been highlighted in the SCI – change date, author and details – the audit trail, important if problems occur Have procedures been followed, if not why not Have all related SCI’s been updated?

Reporting and Management Information Configuration Management Tools can provide information such as: What has happened Who did what When did changes occur What else might be affected (links between objects, modules) Very important in large projects Two people may attempt to change the same SCI with different intentions, these may well conflict! Checking-out and checking-in enable control to be kept of versions so that changes do not get overwritten or lost. The following slide presents a flowchart for a typical change control process There seems to be a lot of steps, but these are necessary if Quality is to be maintained

Summary Configuration management is the management of system change Identifies, controls, audits and reports modifications that WILL occur in a software system throughout its lifetime All of the information produced as part of a software development becomes part of the software configuration Baselines are created at known points of stability Changes to baselined objects have to be approved and result in a new version or release of the system (and thus a new baseline) Change control is a procedural activity that assures quality and consistency in the development of software systems