39 Summary III

Software Configuration Management deals with all the issues related to control of software changes, proper documentation of changes, registering and storing the approved software versions, provision of the relevant information and supply of copies of registered versions throughout the software system’s life cycle. Software configuration management tasks are classified into the following four groups:

  • Control of software change
    • Release of SCI and software configuration
    • versions Provision of SCM information services
  • Verification of compliance to SCM procedures.

Baseline versions are configuration versions that are planned ahead, during a system’s development or operating stage. Baseline versions are also reviewed and approved. They serve as milestones in the software system’s life cycle. Intermediate versions are configuration versions released to respond to immediate needs. They will not receive the attention and efforts typically invested in baseline versions. Controlled document is currently vital or may become vital for the development and maintenance of software systems as well as for the management of current and future relationships with the customer. Quality record is a special type of controlled document. It is a customer targeted document that may be required to demonstrate full compliance with customer requirements and effective operation of the software quality assurance system throughout the development and maintenance processes.

 

The main objectives for managing controlled documents are:

  • To assure the quality of the document.
    • To assure the document’s technical completeness, compliance with approved document structure and use instructions
    • To assure future availability of documents that may be required for maintenance, further development of the software system or responding to the customer’s complaints.
    • To support investigation of software failure causes and to assign responsibility as part of corrective and other actions.

Two alternative but complementary definitions describe quality metrics as a category of SQA tools they are a quantitative measure of the degree to which an item possesses a given quality attribute and a function whose inputs are software data and whose output is a single numerical value can be referred as the degree to which the software possesses a given quality attribute. Software quality metrics are implemented to support control of software development projects and software maintenance contracts.

Quality metrics is determined by the degree to which the following general and operative requirements are fulfilled:

 

General requirements:

  • Relevant – measures an attribute of considerable
  • importance Valid – measures the required attribute
  • Reliable – produces similar results when applied in similar conditions
  • Comprehensive – applicable to a large variety of situations
  • Mutually exclusive – does not measure attributes already measured by other metrics.

Operative requirements

  • Easy and simple – data collection is implemented with minimal resources
    • Does not require independent data collection – metrics data collection is based on currently employed data collection systems, e.g. employee attendance records, cost accounting methods
    • Immune to biased interventions by interested parties (team members and others).

The objectives of cost of software quality measurements relate to management interventions on the basis of economic data. It is used to control the costs associated with error prevention (prior to occurrence) and detection of errors (once they occur). It can also be used to evaluate the extent of economic damages of software failures and prevention and appraisal costs as a basis for revising and updating the SQA budget. It also helps to facilitate economic evaluation of planned increases or decreases in SQA activities or investment in new or updated SQA infrastructure, based on past economic performance.

 

Entities of ISO 9000-3 includes customer focus which understands a customer’s current and future needs. In leadership, it is exercised in the creation and maintenance of a positive internal environment in order to achieve the organization’s objectives. And in involvement of people at all levels to further organizational goals.

 

The general principles of ISO 9000-3 includes:

    Process approach – activities and related resources perceived and managed as a process

 

Systems approach to management – managing processes as a system

 

Continual improvement of the organization’s overall performance

 

Factual approach to decision-making – decisions based on the analysis of data and information

 

Mutually beneficial supplier relationships – emphasis on coordination and cooperation.

 

In Capability Maturity Model (CMM) Application of more highly elaborated software quality management methods increases the organization’s capability to control quality and improve software process productivity. Application of the five levels of the CMM enables the organization to evaluate its achievements and determine what additional efforts are needed to reach the next capability level. Process areas are generic, with the model defining “what” and leaving the “how” to the implementing organizations, i.e., the choice of life cycle model, design methodology, software development tool, programming language and documentation standard. Project process standards focus on methodologies for carrying out software development and maintenance on the “how” of software development project implementation. The major benefits of SQA includes:

  • The ability to apply the most professional software development and maintenance methodologies.
  • The ability to apply state-of-the-art project process procedures.
  • Better mutual understanding and coordination among teams, especially between development and maintenance teams.
  • Greater cooperation between the software developer and external participants in the project.
  • Better understanding and cooperation between suppliers and customers, based on incorporation of known standards within the contract.

Three IEEE standards are being introduced:

  • IEEE/EIA Std 12207 (the framework standard)
  • IEEE Std 1012 (on verification and validation)
  • IEEE Std 1028 (on reviews)

In IEEE/EIA Std 12207:

 

Applicability of the standard and its adaptation by tailoring

 

The standard is applicable to projects that vary by size, complexity and user.

 

Applicability for all participants in the software life cycle

 

The standard serves all the participants of the software life cycle – acquirers, suppliers, developers, operators and maintainers – and provides separate sections for each participant.

 

Flexibility and responsiveness to technological changes

 

The standard instructs “how to do” and not “exactly how to do” a project; users can choose their life cycle model.

 

Software links with its system

 

For each phase of the life cycle, the standard establishes strong links between the software and the system of which it is a part.

 

   TQM consistency

 

The standard is consistent with Total Quality Management concepts.

 

No certification of developer organizations

 

The standard does not require certification of the developer organization.

 

Baselining

 

The standard requires that the software configuration versions be prepared according to the project schedule.

 

In IEEE Std 1012 (Verification and Validation, the standard views V&V activities broadly, to be performed throughout the software life cycle. The standard distinguishes four integrity levels –

high, major, moderate and low – according to the criticality of the software function, module or unit. It also lists the tasks to be performed for every activity throughout the software life cycle. Independent V&V (IV&V) are defined in the standard as managerial, technical and financial independence in the performance of the V&V process. The standard requires compliance with international and IEEE standards, especially IEEE/EIA Std 12207.0-1996. Metrics for evaluation of software development process and products, and the metrics for quality and coverage evaluation of V&V activities.

 

In IEEE Std 1028 (On Reviews), review processes are formal, as realized in authorization and documentation contents requirements. The standard extends the review process to include follow-up and approval of satisfactory performance of the required corrections listed in the review document, irrespective of the type of review. The Standard complies with other IEEE standards and international standards.

 

e.g., ISO/IEC 9000-3, pertaining to performance of reviews.

 

Three levels of management found in many software development organizations:

 

Top management

  • Department management
  • Project management.

The top management responsibility includes:

  •  Assuring the quality of the company’s software products.
  • Communicating to all employees the importance of product and customer satisfaction.
  • Assuring satisfactory functioning with customer requirements.
  • Ensuring SQA system objectives are established.
  • Planning and controlling implementation of changes necessary to adapt the SQA system.
  • Preparation of the department’s annual SQA activities program and budget.
  • Preparation of the department’s SQA system development plans.
  • Control of performance of the department’s annual SQA activities program and development projects.
  •  Presentation of the department’s SQA issues to top management, in the person.

Staff members whose SQA activities represent all or part of their standard assignments or whose participation in SQA bodies goes beyond their regular activities, namely:

  •  SQA unit members
  •  SQA trustees
  • SQA committee members
  • SQA forum members

The tasks of the SQA unit are grouped into SQA operations functions and SQA development and maintenance functions. In Project life cycle SQA, performs tasks such as contract reviews, formal design reviews and software testing. In SQA infrastructure operations, it performs tasks such as publication of updated versions of SQA procedures, SQA training activities and follow-up of staff certification. SQA audits and certification, including internal SQA audits, SQA audits of subcontractors, external audits performed by certification bodies and external audits performed by customers. SQA support: performs tasks such as consultations related to project quality plan etc.

 

In SQA development and maintenance functions:

 

SQA standards and procedures: tasks such as development and updating of procedures, adaptations to changes in professional standards and recommendations for adoption of additional standards.

SQA engineering: tasks such as evaluation of quality and productivity of new development tools, development of solutions to difficulties encountered in application of software development tools, and development of methods for measuring software quality.

SQA information system: tasks such as development of software development and maintenance unit-level SQA information systems, development of systems for receipt and processing of data by the SQA Unit, and maintenance of the SQA Internet/intranet site

 

SQA trustees are involved in unit-related tasks and organization-related tasks, which vary considerably among organizations.

Typical unit-related tasks: support other unit/team members in solving difficulties in implementation of software quality procedures, help their unit manager in performing his SQA tasks, and report to the SQA unit on substantial and systematic non-compliance situations and severe software quality failures.

Typical organization-related tasks: initiation of changes and updates of SQA procedures, initiation of organization-wide improvements of development and maintenance processes and applications to the CAB, identification of SQA training needs and preparation of proposals for appropriate training and/or instruction programs.

SQA committees may be permanent or ad hoc. The subjects, membership criteria and authority of permanent SQA committees are usually defined by SQA procedures. Ad hoc committees are quite different: establishment of ad hoc committees and their task definitions are initiated by various bodies, according to circumstances and current needs. Members of ad hoc committees are chosen by their availability; their authority is adjusted to the committee initiators’ needs. One may expect great variation among the ad hoc committees nominated for the same task by different initiators and at different times. SQA forums are informal components of the SQA organizational framework. They are established, operated and developed freely. Forum subjects, activities and participants vary by organization and typically relate to SQA procedure improvements and implementation, quality metrics, development of software engineering tools. Participation in SQA forums may be closed or open. Participants of open SQA forums can include SQA unit members, SQA trustees, members of software development and maintenance teams, customer representatives and software engineering consultants.