1. Chapter : 22 Software Configuration Management

2. Introduction Software Configuration Management is a set of activities designed to manage change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.

3. Software Configuration Management The out put of the software process is information that may be divided into three categories: (1) computer programs (2) work products related to computer programs, and (3) data or content. The items that comprise all information produced as a part of the software process are collectively known as Software Configuration. AS SE work progresses, a hierarchy of software configuration items (SCIs) is created. Change may occur at any time, for any reason.

4. There are four fundamental sources of change : 1.New business or market conditions dictate (say) changes in product requirements or business rules. 2.New stakeholder needs demand modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system. 3.Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure. 4.Budgetary or scheduling constraints cause a redefinition of the system. SCM can be viewed as a software quality assurance activity that is applied throughout the software process.

5. An SCM Scenario A typical CM operational scenario involves : 1.A project manager who is in charge of a software group. Hence, the manager monitors the process of development by generating and analyzing reports about the status of the system by performing reviews. 2.A configuration manager who is in charge of CM procedure and policies. The goal is to ensure that procedures and policies for creating, changing and testing of code is followed. To implement techniques for maintaining control over code changes, the manager introduces mechanisms for making official requests for changes, for evaluating them, and for authorizing the changes.

6. 3.The software engineers who are responsible for developing and maintaining the software product. The goal is to work effectively. Changes are propagated across each other’s work by merging files. Mechanisms exist to ensure that, for components that undergo simultaneous change, there is some way of resolving conflicts and merging changes 4.The customer who use the product. The customer follows formal procedures for requesting changes and for indicating bugs in the product.

7. Elements Of Software Configuration Management Four important elements that should exist when configuration management system is developed. 1.Component Elements : A set of tools coupled within file management system that enables access to and management of each software configuration item. 2.Process Elements : A collection of actions and tasks that define an effective approach to change management for all constituencies involved in management, engineering and use of computer software.

8. 3. Construction Elements : A set of tools that automate the construction of software by ensuring that the proper set of validated components have been assembled. 4. Human Elements : A set of tools and process features used by the software team to implement effective SCM.

9. Baseline Change is fact of life. A baseline is a software configuration management concept that helps you to control change without seriously impending (approaching) justifiable (acceptable) change. Before a software configuration item becomes a baseline, changes may be made quickly and informally. Once a baseline is established, changes can be made, but a specific, formal procedure must be applied to evaluate and verify each change. In the context of SE, a baseline is a milestone (landmark) in the development of software.

10. A baseline is marked by the delivery of one and more software configuration items that have been approved as a consequence of technical review. E.g., the elements of a design model have been documented and reviewed. Errors are found and corrected. Once all parts of model have been reviewed, corrected, and then approved, the design model becomes baseline. Further changes can be made only after each has been evaluated and approved. Figure 22.1 Explain

11. Software Configuration Items SCI is information produced as a part of SE process. More realistically, SCI is all or part of a work product e.g. document, a suite of test cases. In addition to this, many SE organization also place software tools under configuration control. That is, specific versions of editors, compilers, browsers are frozen as a part of the software configuration. Because these tools are used to produce documentation, source code, and data, they must be available when changes to the software configuration are to be made.

12. SCIs are organized to form configuration objects that may be cataloged in the project database with a single name. A configuration object has a name, attributes, and is connected to other objects by relationship. Fig 22.2 A curved arrow indicates a compositional relation. E.g. in fig, DataModel and ComponentN are part of the object DesignSpecification. A double headed straight arrow indicates an interrelationship. It enables to determine what other objects might be affected.

13. The SCM Repository In early days, SCIs were maintained as paper documents, placed in file folders. The repository is a “thing” – a database that acts as “the center for both accumulation and storage of software engineering information.”

14. The Role Of Repository The SCM repository is the set of mechanisms and data structures that allow a software team to manage change in an effective manner. It provides obvious functions of a modern database management system by ensuring data integrity, sharing, and integration. To achieve its capabilities, the repository is defined in terms of a meta-model. The meta-model determines how information is stored in the repository, how data can be accessed by the tools and viewed by software engineers, how well data security and integrity can be maintained.

15. General Features And Content A robust repository provides two different classes of services : (1) the same types of services that might be expected from any sophisticated DBMS (2) services that are specific to the SE environment. A repository that serves a SE team should also (1) integrate with or directly support process management functions (2) supports specific rules that govern the SCM function and the data maintained within the repository (3) provide an interface to other software engineering tools (4) accommodate storage of sophisticated data objects (e.g. text, audio, video) Fig 22.3

16. SCM Features 1.Versioning : As a project progresses, many versions of individual work products will be created. The repository must be able to save all of these versions to go back to previous versions during testing and debugging. 2.Dependency tracking and change management : The repository manages wide variety of relationships between data elements stored in it. These include relationship between design elements and deliverables, between enterprise entities and processes etc. E.g. if a UML class diagram is modified, the repository can detect whether related classes, interface descriptions and code components also require modification and can bring

17. affected SCIs to developer’s attention. 3. Requirement tracing : It provides the ability to track all the design and construction components and deliverables that result from a specific requirements specification. 4. Configuration management : A CM facility keeps track of series of configurations representing specific project milestones or protection release. 5. Audit trails : An audit trail establishes additional information about when, why, and by whom changes are made. Information about the source of changes can be entered as attributes of specific objects in the repository. A repository trigger mechanism is helpful for prompting the developer to initiate entry of audit information whenever a design element is modified.

18. The SCM Process The SCM process defines a series of tasks that have four objectives (1) to identify items that collectively define the software configuration, (2) to manage changes to one or more of these items (3) to facilitate the construction of different versions of application (4) to ensure that software quality is maintained as the configuration evolves over time. Figure 22.4 Explain

19. Identification Of Objects In Software Configuration To control and manage SCIs, each should be separately named and organized using OO approach. Two types of objects : (1) A basic object is a unit of information that you create during analysis, design, code, or test. E.g. a section of a requirement specification, part of a design model etc. (2) An aggregate object is a collection of basic objects and other aggregate objects. E.g. DesignSpecification. It consists of ArchitecturalModel and DataModel as aggregate objects and ComponentN and UMLClassDiagramN as basic model.

20. Each object has a set of distinct features that identify it uniquely : a name, a description, a list of resource, and a “realization”. Resources are entities that are provided, processed, referenced or required by the object. The realization is a pointer to the unit of text for basic objects and null for an aggregate object. The identification scheme for software objects must recognize that objects evolve throughout the software process.

21. Version Control Version Control (VC) combines procedures and tools to manage different versions of configuration objects that are created during the software process. A version control system implements and directly integrated with 3 major capabilities : (1) a project database that stores all relevant configuration objects, (2) a version management capability that stores all versions of configuration object, and (3) a make facility that enables to collect all relevant configuration objects and construct a specific versions of the software. In addition, version and change control system implement issue tracking capability that enables the team to record and track the status of all outstanding issues associated with each configuration object.

22. A number of version control system establishes a change set – a collection of changes that are required to create a specific version of the software. A change set captures all changes to all files in the configuration along with the reason for changes and details of who made the changes and when. A number of change sets can be identified for an application or system. This enables to construct a version of the software. To accomplish this, a system modeling approach is applied.

23. The system model contains : (1) a template that includes a component hierarchy and a build order for the components that describes how the system must be constructed (2) construction rules (3) verification rules.

24. Change Control For a large project, uncontrolled change leads to chaos. Change controls combines human procedures and automated tools to provide mechanism for control of change. Change control process – 22.5 A change request is submitted and evaluated to assess technical merits, side effects and over all impact etc. The result of evaluation are presented as a change report, which is used by a change control authority (CCA) – a person and group that makes a final decision on the status and priority of the change.

25. An engineering change order (ECO) is generated for each approved change. ECO describes the change to be made, the constraints that must be respected, and the criteria for review and audit. The objects to be changed can be placed in a directory that is controlled by software engineer making change. A version control system updates the original file once the change has been made. As an alternative, the objects to be changed can be checked out of the project database the change is made, and appropriate SQA activities are applied. The object is then checked in to the database and appropriate version control mechanisms are used to create the next version of the software.

26. These version control mechanisms, integrated within the change control process, implement two elements of change management – access control governs which software engineers have an authority to access and modify a particular configuration object and synchronization control helps to ensure that parallel changes, performed by two different people, don’t overwrite one another. Prior to SCI becoming a baseline, only informal change control need be applied. The developer may make changes are justified by project and technical requirements. Once the object has undergone technical review and has been approved, a baseline is created.

27. Once an SCI becomes a baseline, project level change control is implemented. To make a change, the developer must gain approval from the project manager. When the software is released to customers, formal change control is instituted (introduced).

28. Configuration Audit A software team ensure that the change has been properly implemented by (1) technical review (2) the software configuration audit. The technical review focuses on the technical correctness of the configuration object that has been modified. The reviewers assesses the SCIs to determine consistency with other SCIsw, omissions, or potentil side effects. A software configuration audit complements the technical review by assessing a configuration object for characteristics that are generally not considered during review.

29. The audit asks and answers the following questions : 1. Has the changes specified in ECO been made? Have additional modifications been incorporated? 2. Have SCM procedures for noting the change, recording it, and reporting it been followed? 3. Have all related SCIs been properly updated? Configuration audit ensure that correct SCIs have been incorporated into a specific build and all documentation is up-to-date and consistent with the version that has been built.

30. Status Reporting Configuration status reporting is an SCM task that answers the following questions : (1) What happed? (2) Who did it? (3) When did it happen? (4) What else will be affected? Each time a change is approved by the CCA, a CSR entry is made. Each time an SCI is assigned new or updated identification, a CSR entry is made. Each time a configuration audit is conducted, the result is reported as part of CSR task. Output from CSR may be placed in online database or website so that software developers or support staff can access change information by keyword category. It is generated on regular basis.

31. Configuration Management For WebApp Dominant Issues General strategies for SCM are applicable, but tactics (policies) and tools must be adapted to conform to unique nature of WebApp. Four issues should be considered when developing tactics for WebApp configuration management.

32. 1.Content : A WebApp contains a vast array of content – text, graphics, applets, etc. The challenge is to organize this content into rational set of configuration objects and then establish appropriate configuration control mechanism for these objects. One approach is to model the WebApp content using conventional data modeling techniques, attaching a set of specialized properties to each object that are required to establish an effective SCM approach. 2.People : Any person involved in the WebApp can create content. Many content creator have no SE background and are unaware of need of CM. As a consequence, the application grows and changes in an uncontrolled fashion.

33. 3. Scalability : As the size and complexity grows, small changes can have far-reaching and unintended effects that can be problematic. Therefore, the rigor (inflexibility) of configuration control mechanisms should be directly proportional to application scale. 4. Politics : “Who owns the WebApp?” The answer to this question has a significant impact on the management and control activities. There are some questions which help to understand the politics associated with Web Engineering: Who assumes the responsibility for accuracy of information on the website? Who is responsible for making change? The answers to these questions help determine the people within an organization who must adopt a configuration management process for WebApp.

34. WebApp Configuration Objects WebApp encompasses a broad array of configuration objects : content objects (text, audio, video), functional components (scripts, applets), and interface objects (CORBA). WebApp objects can be identified in any manner but some conventions are followed to ensure that cross- platform compatibility is maintained. Conventions: Filename should be limited to 32 chars, underscore in file name should be avoided, mixed-case and all-caps should be avoided.

35. URL references within a configuration object should use relative path (e.g.../products/alarm.html). Content structure defines a content architecture; i.e, it defines the way in which content objects are assembled.

36. Content Management Content management is related to configuration management in a sense that a content management system establishes a process that acquires existing content from an array of WebApp configuration objects, structures it in a way that enables it to be presented to an end user, and then provides it to the client-side environment for display. The most common use of a content management system occurs when a dynamic WebApp is built. E.g. a music company provides a library of CDS for sale. When a user requests a CD, a database is queried and a variety of information are downloaded and configured into a standard content template.

37. The resultant Web page is built on the server side and passed to the client-side browser. Figure : 22.6 A content management system invokes three integrated subsystem: 1.The collection subsystem : Content is derived from data and information that must be created and acquired by the content developer. The collection subsystem encompasses all actions required to create and/or acquire content, and technical functions that are necessary to (1) convert content into a form that can be represented by mark-up language (2) organize content into packets that can be displayed effectively on the client side.

38. Once the content exists, it must be converted to conform to the requirements of a CMS,i.e., stripping raw content of any unnecessary information (e.g. redundant graphical representation), formatting the content to conform to the requirements of the CMS, and mapping the result into an information structure that will enable it to be managed and published. 2.The management subsystem : Once the content exists, it must be stored in a repository, cataloged for subsequent acquisition and use, and labeled to define (1) current status (2) the appropriate version of the content object (3) related content object. Therefore the management subsystem implements a repository that encompasses the following element:

39. (i)Content database : the information structure that has been established to store all content objects. (ii)Database capabilities : functions that enable the CMS to search for specific objects, store and retrieve objects, and manage the file structure that has been established for the content. (iii)Configuration management functions : the functional elements and associated workflow that support content object identification, version control, change management, change auditing, and reporting. In addition, it implements an administration function that encompasses the metadata and rules that control the overall structure of content and the manner in which it is supported. 3.The publishing system :

40. Content must be extracted from the repository, converted to a form that is amenable to publication, and formatted so that it can be transmitted to client- side browser. The publishing subsystem accomplishes these tasks using series of templates. Each template is a function that builds a publication using one of three different components : (i)Static elements : text, media and scripts that require no further processing are transmitted directly to the client side. (ii)Publication services : function calls to specific retrieval and formatting services that personalize content, perform data conversions, and build appropriate navigation links.

41. (iii)External services : access to external corporate information infrastructure such as enterprise data.

42. Change Management To implement CM for WebApp, the conventional change control process must be modified. Each change should be categorized into one of four classes: i)Class 1 : a content or function change that corrects an error or enhances local content or functionality ii)Class 2 : a content or function change that has an impact on other content objects or functional component iii)Class 3 : a content or function change that has a broad impact across a WebApp iv)Class 4 : a major design change that will be immediately noticeable to users. Once the requested change has been categorized, it can be processed according to the algo in fig 22.7

43. For class 1 change, evaluate the impact of the change, but no external review or documentation is required. For class 2 change, review the impact of change on related objects. If the change can be made without requiring significant changes to other objects, modification occurs without additional review or documentation. If substantive changes are required, further evaluation and planning are necessary. Class 3 and 4 changes are treated in agile (lively) manner, but some descriptive documentation and more formal review procedure are required. A change description – describing the change and providing a brief assessment of the impact of change – is developed for class 3 changes.

44. Version Control As a WebApp evolves through a series of increments, a number of different versions exists at the same time. Configuration objects must be clearly defined so that each can be associated with the appropriate version. 1.A central repository for WebApp project should be developed : The repository will hold current versions of all WebApp configuration objects. 2.Each web engineer creates his or her own folder : The folder contains those objects that are being created or changed at any given time. 3.The clocks on all developer workstations should be synchronized : This is done to avoid overwriting conflicts when two developers make updates that

45. are very close to one another in time. 4. As new configuration objects are developed or existing objects are changed, they are imported into the central repository : The version control tool will manage all check-in and check-out functions from the working folders of each WebApp developer. 5. As objects are imported or exported from the repository, an automatic, time stamped log message is made : This provides useful information for auditing and can become part of an effective reporting scheme.

46. Auditing And Reporting All objects that are checked into or out of the repository are recorded in a log that can be reviewed at any point in time. A complete log report can be created so that all members of the WebApp team have a knowledge of changes over a defined period of time. An automated e-mail notification can be sent every time an object is checked-in or out of repository.