by Fernando Brito e Abreu
Software Configuration Management (SCM)
Software artefacts are usually built by integration of multiple modules, often developed by different people, eventually working at several locations and on distinct development platforms. Those modules evolve over time and their name and version must be uniquely identified according to an agreed naming and numbering schema. Version modification history (forward or backward tracking) is often needed for project planning and controlling. Change authorisation and control must be carefully dealt with, especially with large teams where concurrent modifications can take place. Distinct target platforms further increase the number of items under configuration control. Document traceability from requirement specs through design specs, source code or test batteries should also be made available. The above issues are the main concerns of SCM and, hopefully, many SCM tools exist to help implementing it.
Human perception is an association and filtering process that depends on previous experience. Unexpected patterns are often not recognised. This phenomenon is called cognitive dissonance and is responsible for a considerable percentage of our own errors. Therefore, it is a common practice in most engineering fields that projects should be reviewed by somebody else besides their creators. Software reviews aim to detect and classify defects, omissions and no conformities with adopted standards. Review targets can be any kind of software project deliverables like plans, analysis and design specifications, source code or test suites. Several empirical studies have shown that the cost of removing software defects increases exponentially with effort spent after their commitment. Reviewing is then more cost effective if used since the earlier stages of the software life-cycle. An important side-effect of software reviews is that it allows a continuous learning process because team members share their knowledge (as well as their project responsibility). Project progress is also made more visible. Reviews can be informal (walkthroughs) or formal (steps and roles well defined). Software Inspections, for instance, is a formal review technique carried out by several peers (usually 4, including the producer) with specific roles, which is getting widespread in the software industry.
Metrics can be used for many distinct purposes as quality and productivity estimators and indicators. A SM is a combination of (eventually just one) measurements of software product or process (or mixed) attributes, that allows to express quantitatively a defined characteristic. SM should be defined (and collected) objectively. Unfortunately subjective metrics proliferate, but many research efforts on this subject being carried out are expected to ease this problem. Several ESPRIT projects in recent years like METKIT, MUSE or AMI were dedicated to SM. You cannot control what you cannot measure! SM are then used in Software Project Management decision making. They can help to, among other things, monitor the project progress, trigger corrective actions in time, detect potential malfunctionings, identify defect-prone software modules, make inter-project comparisons or calibrate resource estimation models. The Hawthorn effect (increase in productivity when producers feel they are being watched) is another important result of measurement. Launching a company-wide metrics initiative is not an easy task. Metrics definition should be based on company or division goals. SM rationale and their future interpretation should be known by all project peers or else their collection and validity will be jeopardised. Management must continuously support the initiative. Recommendations issued from SM analysis should be put in place and all staff should be made aware of improvements achieved over time.
Testing is an activity that, by way of trial, tries to expose flaws in software products. These flaws can be characterised by the lack of certain quality attributes like reliability, efficiency, usability or functionality. In-house defect detection techniques and tools are aimed at increasing the SW products reliability by extensive and intensive experimentation with beta versions. Efficiency bottleneck identification (or performance evaluation, if you want) by realistic workload simulation is another testing activity. Verifying that user requirements are met (suitability, accuracy, security, understandability, operability) by executable versions prior to delivery is another goal of software testing. Building and applying adequate test batteries used to be a repetitive and, let us confess, boring task. Fortunately, many testing tools that allow us to capture and reuse test batteries have emerged in recent years. Testing coverage and efficiency should be evaluated by using adequate metrics. Techniques like defect injection allow the SW project manager to decide when to stop testing.
Software Process Assessment (SPA)
Being able to identify the weaknesses (and strengths) of the SW development process in place, either for subcontractor selection, or for internal auditing before launching a SPI initiative, or even for improvement tracking purposes, is the main concern of SPA approaches. Several frameworks have been proposed and refined in the last few years like the CMM model (Software Engineering Institute), the BOOTSTRAP and SCOPE models (emerged from the ESPRIT projects of the same names), the TRILLIUM model (Bell Canada) or the international ISO SPICE (Software Process Improvement and Capability dEtermination) initiative.
Software Process Improvement (SPI)
SPI is about fostering a predictable, repeatable, controllable and progressively ameliorated software development process. There is no one size fits all solution to SPI. Each organisation should take a holistic approach, based on its defined goals and bearing in mind all technical, managerial and cultural factors. If for instance the organisations goal is to reduce the defect rate, then defect prevention techniques can be used. These are usually based on fault and defect data gathering that are subsequently used in causal analysis sessions. Cause-effect relations identified are then disclosed and corrective actions are launched (e.g. training, awareness, awards to best teams).
Software Standardisation and Certification
Standardisation plays an important role in any Software Quality initiatives. Software standards are usually good reference frameworks. Unwary software development organisations do reinvent the wheel! Indeed there are (many) standards on SW quality assurance plans, life- cycle definition and management, SW verification and validation, SW configuration management, SW metrics, SW documentation, and so on. Standards production is a long consensus gathering process and sometimes the resulting standards are too generic. Guides for applying specific standards, including interpretation criteria and application examples are often available. Because of our rather young and rapidly evolving engineering field, standards must constantly be evaluated against future best practices and updated in advance. Many national and international standards bodies are actively producing and maintaining software standards. This is the case of the IEEE, DoD, NATO, CEN/CENELEC and ISO/IEC. Within the latter, for instance, there is a committee on Software Engineering (ISO/IEC JTC1 SC7) with several working groups in subjects like Software System Documentation (WG2), Tools and Environments (WG4), Evaluation and Metrics (WG6), Life-Cycle Management (WG7), Support of Life-Cycle Processes (WG8), Process Assessment (WG10) or Function Points (WG12). Some standards are a basis for Certification. In the SW Quality field, the most widely used one is the ISO 9000-3 (Guidelines for the application of ISO 9001 to the development, supply and maintenance of software), now being reviewed. Third party Certification allows software producers to show evidence of a well organised development process and helps purchasers to reduce their risk in subcontracting. Certification bodies are officially accredited for their judging competence, objectivity and impartiality. Mutual recognition of SW Quality certificates is being spread in European countries.
inesc.pt