Spread Knowledge

CS605 - Software Engineering II - Lecture Handout 33

User Rating:  / 0
PoorBest 

Related Content: CS605 - VU Lectures, Handouts, PPT Slides, Assignments, Quizzes, Papers & Books of Software Engineering II

Software Configuration Management (SCM)

You may recall that software configuration management (SCM) is one of the five KPA required for an organization to be at CMM level 2. That means, according to SEI, effective project management is not possible without having a proper SCM function in place.
The basic idea behind SCM is to manage and control change. As mentioned by Bersoff, no matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. It is therefore essential that we manage and control it in a fashion that this continuous change does not convert into chaos.
This has become more important in the context of contemporary software development as we are getting more and more complex software projects in terms of size, sophistication, and technology. In addition, these software systems are used by millions of users all over the world. These systems need multilingual and multi-platform support (hardware, software) and have to operate in a distributed environment. That means that a software system may come in many configuration flavors including desktop, standard, professional, and enterprise versions. There is a brutal competition out there and any complacency may result in losing a big market share. The huge maintenance frequency – corrective and adaptive – makes life even more difficult.

More complex development environment with shorter reaction time results in confusion and chaos!

Change Chaos

This frequent change, if not managed properly, results in chaos. First of all there would be problems of identification and tracking which would result in questions like the following:

    • “This program worked yesterday. What happened?”
    • “I fixed this error last week. Why is it back?”
    • “Where are all my changes from last week?”
    • “This seems like an obvious fix. Has it been tried before?”
    • “Who is responsible for this change?”
    Then there are problems of version selection. The typical problems faced are:
      • “Has everything been compiled? Tested?”
      • “How do I configure for test, with my updates and no others?”
      • “How do I exclude this incomplete/faulty change?”
      • “I can’t reproduce the error in this copy!”
      • “Exactly which fixes went into this configuration?”
      • “Oh my God!. I need to merge 250 files!”
      • Nobody knows which versions of programs are final
        • Where is the latest version?
        • Which version is the right one? I have so many
        • I have lost my latest changes
      • Latest versions of code overwritten by old versions
      • There was a minor problem, I fixed it but it is no longer working
        • I can’t figure-out the changes made to the previous version.
        • I can’t go back

      Then there are software delivery problems.

        • “Which configuration does this customer have?”
        • “Did we deliver a consistent configuration?”
        • “Did the customer modify the code?”
        • “The customer skipped the previous two releases. What happens if we send him the new one?”
        • Shipped the wrong version to the client.
        This is not all. There may be more chaos in the following shapes and forms:

        • The design document is out of sync with programs
        • I don’t know if all the changes that were suggested have been incorporated
        • Which code was sent to testing?

        SCM is a function that, if implemented, will reduce these problems to a minimal level.

        Configuration management

        As defined by CMM, the purpose of SCM is to establish and maintain the integrity or software products through the project’s life cycle.
        Configuration management is concerned with managing evolving software systems. It acknowledges that system change is a team activity and thus it aims to control the costs and effort involved in making changes to a system.
        SCM involves the development and application of procedures and standards to manage an evolving software product and is part of a more general quality management process.
        Baseline
        When released to CM, software systems are called baselines and serve as the starting point for further development.A baseline is a software configuration management concept that helps us to control change without seriously impeding justifiable change. It is defined by IEEE as:

        A specification or a product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.
        Software Configuration Item (SCI)
        A Software Configuration Item is the information that is created as part of the software engineering process. Typical SCIs include requirement specifications, design specification, source code, test cases and recorded results, user guides and installation manuals, executable programs, and standards and procedures (for example C++ design guidelines).

        Software Configuration Management Tasks

        Software configuration management tasks include:

        • Identification
        • Version Control
        • Change Control
        • Configuration Auditing
        • Reporting
        Identification addresses how does an organization identify and manage the many existing versions of a program in a manner that will enable changes to be accommodated efficiently?

        Version Control talks about how does an organization control changes before and after software is released to a customer? It is actually a combination of procedures and tools to manage different versions of the software configuration.

        Clemm states that
        Configuration management allows the user to specify alternative configurations of the software system through the selection of the appropriate versions. This is supported by associating with each software version, and then allowing configuration to be specified and constructed by describing the set of desired attributes.

        A version has many different attributes. In the simplest form a specific version number that is attached to each object and in the complex form it may have a string of Boolean variables (switches) that indicate specific types of functional changes that have been applied to the system.

        The Change Control process addresses the important question of who has the responsibility for approving and ranking changes. Configuration Auditing deals with ensuring that the changes have been made properly and finally Reporting talks about the mechanism used to apprise others of changes that are made. Configuration Identification involves identification of a tool for SCM. Then a baseline is established and identified which is then used to identify configurable software items. At the minimum, all deliverables must be identified as configurable items. This includes design, software, test cases, tutorials, and user guides.