Software Configuration Management

The configuration of a software system is the function and/or physical characteristics of hardware, firmware, software or a combination thereof as set forth in technical documentation and achieved in a product.It can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to accomplish a particular purpose.
Software configuration management (SCM) comprises a set of technical, managerial, and administrative activities related to identifying the configuration of a software system at distinct points in time for the purpose of systematically controlling changes to the configuration, recording and reporting change processing and implementation status, verifying compliance with specified requirements, and maintaining the integrity and traceability of the configuration
throughout the system life cycle. Responsibilities of each software project manager related to SCM include enforcing the practice of SCM activities for the project, distributing the activities to the relevant individuals, and managing and administrating the results of these activities.
Since SCM is a supporting lifecycle process to software product development and maintenance, a successful SCM implementation requires careful management and planning.
These are typically performed by the project manager or another designated individual, who does it in close relation with SQA activities. Management and planning activities cover all the other sets of activities,establish all the relevant SCM policies, and result in recording/updating the Software Configuration Management Plan (SCMP) for the project. The SCMP is typically subject to SQA review and audit.
Configuration identification activities provide the basis for other SCM activities. These activities enumerate the configuration items to be controlled(such as plans, specifications, source and executable code, code libraries, data and data dictionaries, testing materials, software tools, and documentation for installation, maintenance, operations and software use), establish identification schemes for the items and their versions, and establish the tools and techniques
to be used in acquiring and managing controlled items.
SCM control activities involve both managers and developers. Managers make decisions on whether some changes in configuration should be made or not, and authorize the changes. Developers perform change activities (code management) in a coordinated manner. Status reports are generated that account for each change in the configuration, and can be of use to various parties in the project, including managers, developers, testers, SQA team members, and
maintenance engineers. The information obtained by status accounting can also serve as a basis for various measurements, such as the number of change requests per software configuration item and the average time needed to implement a change request. Release processing activities support customers and the maintenance team. They are related to identification.
Packaging and delivery of the elements of a product (such as the software, its documentation, release notes, and configuration data), as well as product version management (versions for different platforms or versions with varying capabilities). The software configuration auditing activity determines the extent to which an item satisfies the required functional and physical characteristics. Its ultimate goal is to evaluate the conformance of software products and processes to applicable regulations, standards, guidelines, plans, and procedures.

Software Quality Assurance

The goals of software quality assurance (SQA) are monitoring the software and its development process, ensuring compliance with standards and procedures, and ensuring that product, process, and standards defects are visible to management.
Quality is the operational behavior of a product required by its users. It comprises a set of product characteristics, both external and internal. External quality characteristics are related to how the product works in its environment (e.g., usability and reliability). Internal quality characteristics reflect how the product is developed (characteristics such as structural complexity, size, test coverage, and fault rates). Important factors affecting product’s quality
characteristics are process maturity level of the company that has developed the software product, its development environment (such as the design methodology and CASE tools used), and the development team’s skill and experience.
It is desirable for a software development organization to plan and control product quality during development. Projects managers cannot allow the luxury of going back and adding quality by the time a quality problem is detected, it is probably too late to fix it. For that reason, it is necessary to establish procedures and expectations for high levels of quality before any other
development begins. Also, hiring developers proven to develop high-quality code, staffing the project accordingly, and enforcing peer-level code reviews and external reviews must be top priority of every software project management.

• Establishing targets for the external quality characteristics.
• Pursuing those targets during development by defining and monitoring targets for internal quality characteristics - this can be done using conventional software measures of size, fault rates, change rates, structure, test coverage, and so on, taken early in product development.
• Establishing relationships between internal and external quality characteristics, using experience from similar past software development projects.
• Identifying and setting targets for internal quality characteristics.In practice, all this can be done by first defining a quality model (in terms of measurable quality characteristics; it can be an international standard like ISO 9126, or a company-specific model), and then applying a quality process.
Quality process includes quality specification (establishing the software product’s quality requirements), planning (deciding on a suitable development process and setting target values for measurable internal quality characteristics),control (monitoring progress throughout development using internal software measures associated with deliverables and activities related to each major review point in development), and evaluation (measuring the actual values of the
external quality characteristics and comparing each actual value with its target value). Maintaining and using a database of past projects helps perform each step in the process more successfully....................

Software Testing

In spite of the fact that in every software development project the product undergoes testing, delivered software always contains residual defects. Software testing is a difficult, time-consuming process. It requires specific skills from software testers, skills that only partially overlap with those of software developers. Apart from mastering coding, testers must also possess a great deal of knowledge of formal languages, graph theory and algorithms.

• Modeling the software’s environment
• Selecting test scenarios
• Running and evaluating test scenarios
• Measuring testing progress

In the first phase, the tester’s task is to simulate the interaction between the application and its environment, be it the user or the other applications, taking into account all possible inputs and outputs that can cross the application’s boundaries. The hardest part here is the fact that in many cases the interactions can go through numerous different file formats, communication protocols, GUIs, and file systems. The other hard part is the unpredictability of the user’s actions the software under test must account for that. Since the number of possible test scenarios is usually extremely large, testers should select those scenarios that cover all code statements and all significant representatives of external events. Before running the selected scenarios, it is necessary to convert them into executable form (often as code) in order to
simulate typical interactions between the system and the external world. Applying test scenarios manually is labor-intensive and error-prone. For that reason, testers try to automate the test scenarios as much as possible. In many environments, automated application of inputs through code that simulates users is possible, and tools are available to help.

Measuring testing progress is difficult, simply because it is not just counting the numbers of bugs found. As stated in the section on software metrics, specific metrics for software testing are used to measure the coverage of the tests applied (in terms of running all lines of the source code, forcing all the internal data to be initialized and used, applying all test scenarios, exploring all the inputs, and checking for functional completeness). Note also that software reliability
engineering can greatly help - the Cleanroom methodology developed at IBM has been particularly useful in improving software quality and providing a quantitative measure for the quality of a software product at its release. TheCleanroom approach provides for the transition of process technology to the project staff and integrates several proven software-engineering practices into one methodology. The testing strategy of the Cleanroom methodology can
be best described as random sample based on usage model that predicts field reliability, rather than a futile attempt for coverage and little insight on field reliability.

If the Unified Process is used to manage software development, software testing is performed in every iteration. Test scenarios are defined from use cases, and comprise both functionality and performance testing. The advantage of this incremental and iterative approach to software testing is that in each iteration the testers test just some of the application. Moreover, the tests performed in early phases usually discover such bugs and faults that would
cause more severe instability in the project’s rhythm if they were discovered in later phases. In every iteration, tests also check whether the current iteration has jeopardized some of the previously built and tested architecture. If the project’s size is large, it is impractical to manually run all the test cases, so the use of automated testing tools is recommended. Project managers should adopt the practice of enforcing thorough testing in every iteration, and not allowing the
next iteration to begin before all the tests planned in the current iteration are completed. The entire project is considered completed only when all the UML models and all the tests are completed and delivered.