SQALE

Last updated

SQALE (Software Quality Assessment based on Lifecycle Expectations) is a method to support the evaluation of a software application source code. It is a generic method, independent of the language and source code analysis tools, licensed under the Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported license. [1] Software editors can freely use and implement the SQALE method.

Contents

The SQALE method was developed by inspearit France (formerly DNV ITGS France). It is used by many organizations for applications of any type and any size. This method is implemented by several static code analysis tools that produce the defined indices and indicators. In addition, this method allows doing the precise management of design debt for Agile software development projects.

History

The SQALE method has been developed to answer a general need for assessing the quality of source code. It is meant to answer fundamental questions such as:

  • What is the quality of the source code delivered by the developers?
  • Is the code changeable, maintainable, portable, reusable?
  • What is the design debt stored up by the project?

Standards, like ISO 9126, do not provide effective support about the manner of building a global answer. To be able to evaluate the quality of source code, the developers community needs a generic method having the following properties:

  • Objective, specific and reproducible
  • Producing indices, syntheses or/and indicators easily understandable and helping to make decisions relating to the improvement of the source code
  • Independent of the languages
  • Independent of the tools for analysis

Fundamental principles

  1. The quality of the source code is a non-functional requirement.
  2. The requirements in relation to the quality of the source code have to be formalised according to the same quality criteria as all other requirements.
  3. Assessing the quality of a source code is in essence assessing the distance between its state and its expected quality objective.
  4. The SQALE method assesses the distance to the conformity with the requirements by considering the necessary remediation cost for bringing the source code to conformity.
  5. The SQALE method respects the representation condition.
  6. The SQALE method uses addition for aggregating the remediation costs and for calculating its quality indicators.
  7. The SQALE method's quality model is orthogonal.
  8. The SQALE method's quality model takes the software's lifecycle into account.

Details

The method is based on 4 main concepts:

  1. The quality model
  2. The analysis model
  3. The indices
  4. The indicators

The quality model

The SQALE Quality Model is used for formulating and organising the non-functional requirements that relate to the code's quality. It is organised in three hierarchical levels. The first level is composed of characteristics, the second of sub-characteristics. The third level is composed of requirements that relate to the source code's internal attributes. These requirements usually depend on the software's context and language.

The analysis model

The SQALE analysis model contains on the one hand the rules that are used for normalising the measures and the controls relating to the code, and on the other hand the rules for aggregating the normalised values. The SQALE method normalises the reports resulting from the source code analysis tools by transforming them into remediation costs. To do this, either a remediation factor or a remediation function is used. The SQALE Method defines rules for aggregating the remediation costs, either in the Quality Model's tree structure, or in the hierarchy of the source code's artefacts.

The indices

All SQALE indices represent costs. These costs can be calculated in work unit, in time unit or in monetary unit. In all cases, the indices values are on a scale of ratio type. They can be handled with all the allowed operations for this type of scale. For any element of the hierarchy of the source code artefacts, the remediation cost relating to a given characteristic can be estimated by adding all remediation costs linked to the requirements of the characteristic. The indices of SQALE characteristics are the following:

  • SQALE Testability Index : STI
  • SQALE Reliability Index : SRI
  • SQALE Changeability Index : SCI
  • SQALE Efficiency Index : SEI
  • SQALE Security Index : SSI
  • SQALE Maintainability Index : SMI
  • SQALE Portability Index : SPI
  • SQALE Reusability Index : SRuI

The method also defines a global index: For any element of the hierarchy of the source code artefacts, the remediation cost relating to all the characteristics of the quality model can be estimated by adding all remediation costs linked to all the requirements of the quality model. This derived measurement is called: SQALE Quality Index: SQI For the AGILE Software Development, the SQI index correspond to the design debt (or technical debt) of the project. The method also defines index densities which allow comparing the products quality of different size (for example SQID: SQALE Quality Density Index).

The indicators

The SQALE method defines three synthesised indicators. Each user can define indicators according to his needs.

SQALE and Agile Software Development

The SQALE method is particularly devoted to the management of the design debt (or technical debt) of Agile Software Development. It allows:

  • To clearly define what creates design debt
  • To correctly estimate design debt
  • To describe this debt into various parts relating to the testability, the reliability, the changeability, the maintainability... This classification supports the analysis regarding the impact of the debt and how to define the priority actions of code refactoring.

In the requirements relating to the source code (the SQALE Quality Model), the method allows to include a minimum threshold to reach with unit testing. In the case that this threshold is not reached, the reliability index of the application is impacted.

Tools which implement the SQALE method

See also

Related Research Articles

Software documentation is written text or illustration that accompanies computer software or is embedded in the source code. The documentation either explains how the software operates or how to use it, and may mean different things to people in different roles.

In computer science, static program analysis is the analysis of computer programs performed without executing them, in contrast with dynamic program analysis, which is performed on programs during their execution.

Software testing is the act of examining the artifacts and the behavior of the software under test by validation and verification. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not necessarily limited to:

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

The following outline is provided as an overview of and topical guide to software engineering:

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.

In the context of software engineering, software quality refers to two related but distinct notions:

<span class="mw-page-title-main">ISO/IEC 9126</span> Former ISO and IEC standard

ISO/IEC 9126Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.

Software quality assurance (SQA) is a means and practice of monitoring all software engineering processes, methods, and work products to ensure compliance against defined standards. It may include ensuring conformance to standards or models, such as ISO/IEC 9126, SPICE or CMMI.

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.

Quality engineering is the discipline of engineering concerned with the principles and practice of product and service quality assurance and control. In software development, it is the management, development, operation and maintenance of IT systems and enterprise architectures with a high quality standard.

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

The Service Measurement Index is an application framework that defines method for the calculation of a relative index, which may be used to compare IT services against one another, or to track services over time.

SQUORE is a software analytics and static code analysis tool for software projects. It gathers information from different artefacts types and tools and publishes a summarised view of the project quality or progress.

A software map represents static, dynamic, and evolutionary information of software systems and their software development processes by means of 2D or 3D map-oriented information visualization. It constitutes a fundamental concept and tool in software visualization, software analytics, and software diagnosis. Its primary applications include risk analysis for and monitoring of code quality, team activity, or software development progress and, generally, improving effectiveness of software engineering with respect to all related artifacts, processes, and stakeholders throughout the software engineering process and software maintenance.

Software Intelligence is insight into the inner workings and structural condition of software assets produced by software designed to analyze database structure, software framework and source code to better understand and control complex software systems in Information Technology environments. Similarly to Business Intelligence (BI), Software Intelligence is produced by a set of software tools and techniques for the mining of data and the software's inner-structure. Results are automatically produced and feed a knowledge base containing technical documentation and make it available to all to be used by business and software stakeholders to make informed decisions, measure the efficiency of software development organizations, communicate about the software health, prevent software catastrophes.

References

  1. "SQALE details at SQALE website" . Retrieved January 29, 2014.