Unit - 3

Software Configuration Management (SCM)

3.1 Software Configuration Management (SCM) – Baselines

Software configuration management (SCM) is an umbrella activity that is applied throughout the software process, because change can occur at any time.

SCM activities are developed to

●      Identify change,

●      Control change,

●      Ensure that change is being properly implemented, and

●      Report changes to others who may have an interest.

It is important to make a clear distinction between software support and software configuration management. Support is a set of software engineering activities that occur after software has been delivered to the customer and put into operation. Software configuration management is a set of tracking and control activities that begin when a software engineering project begins and terminate only when the software is taken out of operation.

A primary goal of software engineering is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made.

The output of the software process is information that may be divided into three broad categories:

●      Computer programs (both source level and executable forms);

●      Documents that describe the computer programs (targeted at both technical practitioners and users), and

●      Data (contained within the program or external to it).

The items that comprise all information produced as part of the software process are collectively called a software configuration.

As the software process progresses, the number of software configuration items (SCIs) grows rapidly. A System Specification spawns a Software Project Plan and Software Requirements Specification (as well as hardware related documents). These in turn spawn other documents to create a hierarchy of information.

If each SCI simply spawned other SCIs, little confusion would result. Unfortunately, another variable enters the process—change. Change may occur at any time, for any reason. In fact, the First Law of System Engineering states: “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.”

There are four fundamental sources of change:

●      New business or market conditions dictate changes in product requirements or business rules.

●      New customers need modification of data produced by information systems, functionality delivered by products, or services delivered by a computer-based system.

●      Reorganization or business growth/downsizing causes changes in project priorities or software engineering team structure.

●      Budgetary or scheduling constraints cause a redefinition of the system or product.

Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process.

In certain situations, more than one risk can be traced to the issues that arise during a project. The attempt to assign origin (what risk(s) caused the problems in the project) is another risk monitoring mission.

Baseline

A software baseline is a formally approved version (regardless of media) of a configuration item that is formally designated and fixed at a specified point in the configuration item's life cycle. A specific version of a software configuration item that has been agreed upon is also referred to as a version. The baseline can only be altered through proper change control processes in either situation.

The current approved configuration is represented by a baseline and all approved changes to the baseline. Functional, allotted, developmental, and product baselines are some of the most commonly utilized baselines. The functional baseline conforms to the system requirements that have been reviewed. The assigned baseline is the same as the software requirements specification and software interface requirements specification that were examined.

The developmental baseline depicts the changing software configuration over the course of the software life cycle. This baseline's change power is normally vested in the development organization, but it may be shared with other organizations (for example, SCM or Test). The product baseline refers to a finished software product that has been provided for system integration. The SCMP typically identifies the baselines to be used for a project, as well as the related levels of authority required for modification approval.

Key takeaway :

Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. The number of software configuration items (SCIs) grows rapidly.

3.1.1 Software Configuration Items (SCI)

Software configuration identification defines items to be controlled, establishes item and version identification methods, and specifies the tools and techniques to be utilized in acquiring and maintaining controlled items. These activities serve as the foundation for the rest of the SCM operations.

Identifying Items to Be Controlled

Identifying the software objects to be managed is one of the first steps in controlling change. Understanding the software configuration in the context of the system configuration, selecting software configuration items, developing a strategy for labelling software items and describing their relationships, and identifying both the baselines to be used and the procedure for acquiring the items for a baseline are all part of this process.

Software Configuration

The functional and physical features of hardware or software as described in technical documentation or realized in a product are referred to as software configuration. It can be considered a component of a larger system setup.

Software Configuration Item

A configuration item (CI) is a piece of hardware, software, or a combination of both that is designed to be handled as a single unit. A software configuration item (SCI) is a piece of software that has been designated for use as a configuration item. In addition to the code, the SCM is usually in charge of a number of other things. Plans, specifications, and design documentation, testing materials, software tools, source and executable code, code libraries, data and data dictionaries, and documentation for installation, maintenance, operations, and software use are all examples of software products that could become SCIs.

Software Configuration Item Relationships

Other SCM operations or tasks, such as software development or studying the impact of proposed modifications, are influenced by structural linkages among the selected SCIs and their constituent elements. It's also crucial to keep track of these connections in order to provide traceability. The necessity to map recognised things to the software structure, as well as the need to allow the evolution of software items and their interactions, should be considered while designing the identification scheme for SCIs.

Software Version

As a software project progresses, software pieces change. A software item's version is a unique instance of the object. It can be compared to the state of an emerging object. A variation is a programme version that results from the use of software variety.

Acquiring Software Configuration Items

At several points in the software life cycle, software configuration elements are placed under SCM control; that is, they are incorporated into a certain baseline. The completion of a formal acceptance task, such as a formal review, is the triggering event. The rise of baselined objects as the life cycle progresses is depicted in the graph. The subscripts used in the graphic represent versions of the evolving elements and are based on the waterfall model for demonstration purposes only.

The origin and initial integrity of a SCI must be established before it can be purchased. Changes to an item must be formally approved as acceptable for the SCI and the baseline concerned, as stated in the SCMP, after it has been acquired. Following approval, the item is incorporated into the software baseline according to the appropriate procedure.

Fig 1: Acquisition of Items

Key takeaway

Software configuration identification defines items to be controlled, establishes item and version identification methods, and specifies the tools and techniques to be utilized in acquiring and maintaining controlled items.

3.1.2 SCM Process; Version Control, Change Control, Configuration Audit, Status Reporting

A disciplined framework for smooth control of work items is provided by configuration management. It requires the following operations:

Identification and Establishment –

Identification of configuration elements from goods composing baselines in time at given points (a baseline is a set of mutually consistent Configuration Items, which has been formally reviewed and agreed upon, and serves as the basis of further development).

Establishing relationships between objects, establishing a framework for managing multiple levels of control and change management system processes.

Version control –

Using the SCM framework to construct versions/specifications of an existing product to develop new products.

Suppose the configuration object's version moves from 1.0 to 1.1 after some changes. Minor corrections and adjustments occur in the 1.1.1 and 1.1.2 versions, which are followed by a significant update to 1.2.

Object 1.0's growth continues through 1.3 and 1.4, but a notable update to the object ultimately results in a new evolutionary direction, version 2.0.0. It currently supports both models.

Fig 2: version control

Change control –

Controlling changes to Configuration items (CI).

In order to determine technical merit, possible side effects, overall impact on other configuration artifacts and device functions, and the estimated cost of the update, a change request (CR) is submitted and assessed.

The assessment results are viewed as a change report used by a change control board (CCB)-a individual or body that makes a final decision on the change's status and priority. For each approved change, an engineering change Request (ECR) is created.

In the event that the modification is refused for good reason, CCB often notifies the creator. The ECR outlines the improvements to be made, the constraints that need to be met, and the evaluation and audit criteria.

Fig 3: change control

The object to be altered is "checked out" from the database of the project, the alteration is made, and the object is reviewed again. The object is then 'checked in' to the database and the next version of the programme is generated using acceptable version control mechanisms.

Configuration auditing –

Complementing the structured technical analysis of the process and product is a programme configuration audit. It focuses on the functional correctness of the configuration object that has been modified

The audit checks the completeness, accuracy and continuity of items from audit to closure in the SCM framework and monitors action items.

Reporting –

Providing developers, testers, end users, customers and stakeholders with accurate status and current configuration information through admin guides, user guides, FAQs, release notes, memos, installation guide, setup guide, etc.

Key takeaway :

●      In the SCM method, the tasks need to be understood.

●      Configuration detection, change control, version control, configuration auditing, and reporting are the five tasks of the SCM process.

●      These tasks relate to software configuration items (SCIs) and as the project progresses, they can be seen as concentric layers that contribute to SCIs.

3.1.3 Goals of SCM

The following are the main goals of software configuration:

Remote System Administration

●      The setup standard for remote system administration tools should include the relevant software and/or privileges.

●      A remote administration client that is correctly installed and configured for the remotely administered network is the cornerstone on the client side.

●      These remote programmes can be used to verify virus protection versions, computer configuration, and provide remote help-desk support.

Remote Software Installation

●      The majority of modern software packages are factory-installed predefined directories. Without a doubt, this style of installation is appropriate for a single user, but it will result in a non-uniform setup for a group of workstations.

●      Software will be put in specified directory sections to logically separate software on the disc in a good configuration standard.

●      With the help of universal scripts, it is possible to quickly identify installed components as well as automate installation procedures.

●      Because software is put in specified directories, it is easier to maintain and upgrade operating software.

Reduced User Downtime

●      The usage of a common configuration has the advantage of making systems totally convertible, resulting in less user downtime.

●      An identical new system can be dropped into place if an unrecoverable fault occurs.

●      If the non-functional machine is still accessible, user data can be transferred, or the most recent copy from the backup tape can be retrieved, with the ultimate goal of minimizing system interface changes for the user. The software has been installed.

Reliable Data Backups

●      By using a standard directory for user data, backup systems can selectively backup a small area of a machine, significantly decreasing network traffic and tape usage.

●      One of the key purposes of the configuration standards is to create a split directory structure between system and user data.

Multi-user Support

●      It is uncommon for people to share a workstation. As a result, the system is configured in such a way that multiple workstations can be used without interfering with each other's networks.

●      Some software programmes do not allow all users to have totally independent settings, however users can have independent data users.

●      The amount of independent users a system can have will not be limited by its usage of structure.

Easy workstation setup

●      Any type of standardized configuration will speed up the process of setting up the system and ensure that critical components are present.

●      Most of the setup configurations can be automated if numerous machines are being set up according to a standard set-up.

3.2 Software Quality Assurance: Software Quality Assurance Activities

Software quality assurance is a planned and systematic set of operations that ensures that an item or product complies with established technical specifications.

A series of actions aimed at calculating the development or manufacturing process for products.

Quality Assurance Criteria

The following are the quality assurance criteria that will be used to evaluate the software:

●      correctness

●      efficiency

●      flexibility

●      integrity

●      interoperability

●      maintainability

●      portability

●      reliability

●      reusability

●      testability

●      usability

SQA Encompasses

●      An approach to quality management.

●      Software engineering technology that works (methods and tools).

●      Formal technical reviews that are put to the test during the software development process.

●      A testing technique with multiple tiers.

●      Control over the documentation of software and the changes that are made to it.

●      A technique for ensuring that software development standards are followed.

●      Mechanisms for measuring and reporting.

Software Quality Assurance Activities

Software quality assurance is made up of a number of functions that are divided into two groups. Software engineers who perform technical work, as well as a SQA group in charge of quality assurance planning, record keeping, analysis, and reporting.

An independent SQA group performs the following tasks:

●      Prepares an SQA plan for a project:

During project planning, the programme is created and reviewed by all stakeholders. The plan oversees the software engineering team's and the SQA group's quality assurance actions. The plan specifies the calculations to be carried out, audits and reviews to be carried out, project-specific standards, error reporting and tracking methodologies, documentation to be created by the SQA team, and the quantity of feedback to be given to the software project team.

●      Reviews software engineering activities to verify compliance with the defined software process:

The SQA team detects, reports, and tracks process irregularities, as well as ensuring that remedies have been made.

●      Audits designated software work products to verify compliance with those defined as a part of the software process:

The SQA team examines selected work items, detects, documents, and tracks deviations, verifies that changes have been made, and delivers its findings to the project manager on a regular basis.

●      Participates in the development of the project's software process description:

For the task to be done, the software team chooses a procedure. The SQA team examines the process description for conformance to organizational policy, internal software standards, externally enforced standards (such as ISO-9001), and other aspects of the software project plan.

●      Ensures that deviations in software work and work products are documented and handled according to a documented procedure:

Deviations in the project technique, process description, applicable standards, or technical work results are all possible.

●      Records any noncompliance and reports to senior management:

Items that are out of compliance are tracked until they are remedied.

3.2.1 Software Qualities

A software product's quality is determined by its suitability for its intended use. That is, a high-quality product does exactly what its users expect. The fitness of use of software products is usually stated in terms of meeting the requirements outlined in the SRS document. For many items, such as an automobile, a table fan, a grinding machine, and so on, "fitness of purpose" is a reasonable interpretation of quality. However, "fitness of purpose" is not a totally satisfactory definition of quality for software products.

Consider a software programme that is functionally correct. That is, it completes all of the tasks outlined in the SRS document. However, the user interface is nearly unusable. Even though it may be functionally right, we cannot consider it to be a quality product.

The Successful functioning of the software product is important because critical business activities depend on them. Therefore Software quality becomes one of the most important aspects of the software development process. There are many measures of software quality, correctness, maintainability, integrity, and usability provide useful indicators for the project team.

The modern view of a software product's quality includes numerous quality methodologies, such as the following:

1. Correctness:

●      Correctness is the degree to which the software performs its required function.

●      The most common measure for correctness is defects per KLOC, where a defect is defined as a verified lack of conformance to requirements.

●      When considering the overall quality of a software product, defects are those problems reported by a user of the program after the program has been released for general use.

●      For quality assessment purposes, defects are counted over a standard period of time, typically one year.

2.     Maintainability:

●      Maintainability is the ease with which a program can be

●      Corrected if an error is encountered,

●      Adapted if its environment changes, or

●      Enhanced if the customer desires a change in requirements

●      There is no way to measure maintainability directly; therefore, we must use indirect measures.

●      A simple time-oriented metric is Mean-Time-To Change (MTTC), the time it takes to

●      Analyze the change request,

●      Design an appropriate modification,

●      Implement the change, test it, and

●      Distribute the change to all users.

●      On average, programs that are maintainable will have a lower MTTC (for equivalent types of changes) than programs that are not maintainable.

3.     Integrity:

●      This attribute measures a system's ability to withstand attacks (both accidental and intentional) to its security.

●      Attacks can be made on all three components of software: programs, data, and documents.

●      To measure integrity, two additional attributes must be defined:

●      Threat

●      Security.

●      Threat is the probability (which can be estimated or derived from empirical evidence) that an attack of a specific type will occur within a given time.

●      Security is the probability (which can be estimated or derived from empirical evidence) that the attack of a specific type will be repelled.

●      The integrity of a system can then be defined as

Integrity = summation [(1 – threat) * (1 – security)]

Where threat and security are summed over each type of attack

4.     Usability:

If a program is not user-friendly, it is often doomed to failure, even if the functions that it performs are valuable. Usability is an attempt to quantify user-friendliness and can be measured in terms of four characteristics:

●      The physical and or intellectual skill required to learn the system,

●      The time required to become moderately efficient in the use of the system,

●      The net increase in productivity measured when the system is used by someone who is moderately efficient, and

●      A subjective assessment of user’s attitudes toward the system.

5.     Portability:

If a software device can be configured to run in a variety of operating system contexts, on different machines, with other software items, and so on, it is said to be portable.

Key takeaway

●      There are many measures of software quality, correctness, maintainability, integrity, and usability that provide useful indicators for the project team.

●      Software quality one of the most important aspects of the software development process.

3.2.2 Software Quality Standards – ISO Standards for Software Organization

The Worldwide Standard Organization's objective is to promote the development of standardization and related activities in order to ease international product and service interchange. It also aids in the development of collaboration across many activities such as intellectual, scientific, technological, and commercial activity.

ISO 9000 Quality Standards :

It is defined as a quality assurance system in which quality components for implementing quality management include organizational structure, responsibilities, procedures, processes, and resources. Quality assurance systems are designed to assist businesses in ensuring that their products and services fulfill consumer expectations and criteria.

Different types of ISO standards :

The following are the various sorts of ISO standards that can be found here.

ISO 9000: 2000 –  Quality management systems, foundations, and vocabulary are all covered in ISO 9000: 2000.

ISO 9000-1: 1994 –  Quality management systems and Quality assurance standards are included in this set of standards. It also offers certain selection and application guidelines.

ISO 9000-2: 1997 – Quality management systems and quality assurance standards are also included in this set of standards. It also contains some application guidelines for ISO 9001, ISO 9002, and ISO 9003.

ISO 9000-3: 1997 – This series covers instructions for applying ISO 9001 to the development, supply, installation, and maintenance of computer systems, as well as quality management systems and quality assurance standards.

ISO 9001: 1994 –  There are Quality systems and a Quality assurance model in this set of standards. Design, development, manufacture, installation, and servicing are all aided by this methodology.

ISO 9001: 2000 – Quality management systems are also included in this set of standards.

ISO 9002: 1994 – Some Quality systems are included in this set of standards. This quality assurance paradigm is utilized in the manufacturing, installation, and maintenance of products.

ISO 9003: 1994 – Some Quality systems are included in this set of standards. In the final inspection and test, this quality assurance model was applied.

ISO 9004: 2000 – Some quality management systems are included in this set of standards. It also gives some suggestions for improving performance.

ISO 9039: 1994 – Some optics and optical instruments are included in this set of standards. It entails assessing the quality of optical systems as well as determining distortion.

ISO/IEC 9126-1: 2001 – Information technology is included in this set of standards. It also includes certain software items and models of high grade.

ISO/IEC 9040: 1997 – Information technology is included in this set of standards. It also provides virtual terminal basic class service and open system connectivity.

ISO/IEC 9041-1: 1997 – Information technology is included in this set of standards. Open system interconnection, Virtual terminal basic class service protocol, and specification are also included.

ISO/IEC 9041-2: 1997 – Information technology, open system interconnection, Virtual terminal basic class protocol, and Protocol implementation conformance statement (PICS) proforma are all part of this set of standards.

ISO/IEC 9075-9: 2001 – Information technology, database languages, and SQL/MED are all included in this set of standards (Management of External Data).

ISO/IEC 9075-10: 2000 -| Information technology, database languages, and SQL/OLB are all included in this set of standards (Object Language Bindings).

ISO/IEC 9075-13: 2002 – Information technology, database languages, SQL routines, and the Java programming language are all included in this set of standards. (SQL/JRT).

3.2.3 Capability Maturity Model (CMM)

The Capability Maturity Model (CMM) of the Software Engineering Institute (SEI) outlines an expanding succession of levels for a software development company. The better the software development process, the higher the level; thus, reaching each level is a costly and time-consuming procedure.

Level of CMM

The SEI approach provides a measure of the global effectiveness of a company’s software engineering practices and established five process maturity levels that are defined in the following manner:

Fig 4: level of CMM

Level 1: Initial.

The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends on individual effort.

Level 2: Repeatable.

Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Level 3: Defined.

The software process for both management and engineering activities is documented, standardized, and integrated into an organization-wide software process. All projects use a documented and approved version of the organization’s process for developing and supporting software. This level includes characteristics defined for level 2.

Level 4: Managed.

Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures. This level includes all characteristics defined for level 3.

Level 5: Optimizing.

Continuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies. This level includes all characteristics defined for level 4.

The five levels defined by the SEI were derived as a consequence of evaluating responses to the SEI assessment questionnaire that is based on the CMM. The results of the questionnaire are distilled to a single numerical grade that provides an indication of an organization’s process maturity.

The SEI has associated key process areas (KPAs) with each of the maturity levels. The KPAs describe those software engineering functions (e.g., software project planning, requirements management) that must be present to satisfy good practice at a particular level. Each KPA is described by identifying the following characteristics:

1. Goals: The overall objectives that the KPA must achieve.
2. Commitments: Requirements (imposed on the organization) that must be met to achieve the goals or provide proof of intent to comply with the goals.
3. Abilities: Those things that must be in place (Organizationally and technically) to enable the organization to meet the commitments.
4. Activities: The specific tasks required to achieve the KPA function.
5. Methods for monitoring implementation: The manner in which the activities are monitored as they are put into place.
6. Methods for verifying implementation: The manner in which proper practice for the KPA can be verified.

Eighteen KPAs (each described using these characteristics) are defined across the maturity model and mapped into different levels of process maturity.

The following KPAs should be achieved at each process maturity level:

1. Process maturity level 2

1. Software configuration management
2. Software quality assurance
3. Software subcontract management
4. Software project tracking and oversight
5. Software project planning
6. Requirement management

Ii. Process maturity level 3

1. Peer reviews
2. Inter – group coordination
3. Software product engineering
4. Integrated software management
5. Training program
6. Organization process definition
7. Organization process focus

Iii. Process maturity level 4

1. Software quality management
2. Quantitative process management

Iv. Process maturity level 5

1. Process change management
2. Technology change management
3. Defect prevention

Each of the KPAs is defined by a set of key practices that contribute to satisfying its goals. The key practices are policies, procedures, and activities that must occur before a key process area has been fully instituted. The SEI defines key indicators as “those key practices or components of key practices that offer the greatest insight into whether the goals of key process areas have been achieved”.

Key takeaway

1. The five levels defined by the SEI were derived as a consequence of evaluating responses to the SEI assessment questionnaire that is based on the CMM.
2. The SEI has associated key process areas (KPAs) with each of the maturity levels.
3. The KPAs describe those software engineering functions that must be present to satisfy good practice at a particular level.

3.2.4 Comparison between ISO 9001 & CMM

ISO 9000:

It is a set of International Standards on quality management and quality assurance that was created to assist businesses in properly documenting the quality system aspects required for a successful quality system.

SEI-CMM:

The Capability Maturity Model (CMM) of the SEI (Software Engineering Institute) outlines an expanding sequence of levels for a software development organization.

Difference between ISO9000 and SEI-CMM:

References:

1. Roger S Pressman, Bruce R Maxim, “Software Engineering: A Practitioner’s Approach”, Kindle Edition, 2014.
2. Ian Sommerville,” Software engineering”, Addison Wesley Longman, 2014.
3. Software Project Management by Edwin Bennatan.
4. Software Project Management by S.A. Kelkar.