Configuration Management

Software configuration management (SCM) is a set of activities designed to control 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.

Everyone involved in the project is involved with SCM to some extent, but specialized support positions are sometimes created to manage the SCM process.

In brief when every work product can be accounted for, traced, and controlled; when every change can be tracked and analyzed; when everyone who needs to know about a change has been informed— we know we’ve done it right!

Reviews

A software review is "A process or meeting during which a software product or document is examined by project personnel, managers, users, customers, user representatives, or other interested parties for comment or approval".

• Defect Detection: The foremost reason of conducting software reviews is that they can identify issues earlier and more cheaply than they would be identified by testing or by field use. The cost to find and fix a defect by a well-conducted review may be one or two orders of magnitude less than when the same defect is found by test execution or in the field.

• Defect Prevention: A second, but ultimately more important, value of software reviews is that they can be used to train technical authors in the development of extremely low-defect documents, and also to identify and remove process inadequacies that encourage defects. Our review documents list down the document/code file reviewed, date, reviewer’s name, type of review, list of defects, status of defects, assigned to and comments.

Traceability

Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements on the product. Using requirements traceability an implemented feature can be traced back to the person, or group, that wanted it during the requirements elicitation. This is done through the requirements traceability matrix. It is often used with high-level requirements and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.

SEPG

The Software Engineering Process Group (SEPG) is our organization's focal point for software process improvement activities. The individuals involved in this group perform assessments of organizational capability, develop plans to implement needed improvements, coordinate the implementation of those plans, and measure the effectiveness of these efforts. Our expert group of SEPGs have specialized skills and knowledge of many areas outside traditional software engineering.

They ensure that each and every project follows the basic principles of Software Engineering.

RCA

Root cause analysis (RCA) is predicated on the belief that problems are best solved by attempting to correct or eliminate root causes, as opposed to merely addressing the immediately obvious symptoms. By directing corrective measures at root causes, it is hoped that the likelihood of problem recurrence will be minimized. We use the following steps to do a complete Root Cause Analysis:

• Define the problem.
• Gather data/evidence.
• Ask why and identify the causal relationships associated with the defined problem.
• Identify which causes if removed or changed will prevent recurrence.
• Identify effective solutions that prevent recurrence, are within your control, meet your goals and objectives and do not cause other problems.
• Implement the recommendations.
• Observe the recommended solutions to ensure effectiveness.

Metrics

Metrics are a set of quantifiable parameters which are used to measure the effectiveness of a project or undertaking. For example, the effectiveness of the changes in the user interface can be measured by the satisfaction level of the users with each of the versions.

We have been in the IT industry for a number of years. To be able to measure the success of each project, we have developed a set of parameters for which we obtain values from the projects. Some of these metrics are Schedule/variance, Effort variance, defect injection rate, delivered defect density etc.

On analyzing this data, we find out where, why and what went correct/wrong. This allows us to tune for the next project and so on.