Quality engineering

Last updated

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

Contents

Description

Quality engineering is the discipline of engineering that creates and implements strategies for quality assurance in product development and production as well as software development. [5]

Quality Engineers focus on optimizing product quality which W. Edwards Deming defined as:

Quality engineering body of knowledge includes: [6]

Roles

Auditor: Quality engineers may be responsible for auditing their own companies or their suppliers for compliance to international quality standards such as ISO9000 and AS9100. They may also be independent auditors under an auditing body. [7]

Process quality: Quality engineers may be tasked with value stream mapping and statistical process control to determine if a process is likely to produce a defective product. They may create inspection plans and criteria to ensure defective parts are detected prior to completion. [8]

Supplier quality: Quality engineers may be responsible for auditing suppliers or performing root cause and corrective action at their facility or overseeing such activity to prevent the delivery of defective products.

Software

IT services are increasingly interlinked in workflows across platform boundaries, device and organisational boundaries, for example in cyber-physical systems, business-to-business workflows or when using cloud services. In such contexts, quality engineering facilitates the necessary all-embracing consideration of quality attributes.

In such contexts an "end-to-end" view of quality from management to operation is vital. Quality engineering integrates methods and tools from enterprise architecture-management, Software product management, IT service management, software engineering and systems engineering, and from software quality management and information security management. This means that quality engineering goes beyond the classic disciplines of software engineering, information security management or software product management since it integrates management issues (such as business and IT strategy, risk management, business process views, knowledge and information management, operative performance management), design considerations (including the software development process, requirements analysis, software testing) and operative considerations (such as configuration, monitoring, IT service management). In many of the fields where it is used, quality engineering is closely linked to compliance with legal and business requirements, contractual obligations and standards. As far as quality attributes are concerned, reliability, security and safety of IT services play a predominant role.

In quality engineering, quality objectives are implemented in a collaborative process. This process requires the interaction of largely independent actors whose knowledge is based on different sources of information.

Quality engineering Quality Engineering.jpg
Quality engineering

Quality objectives

Quality objectives describe basic requirements for software quality. In quality engineering they often address the quality attributes of availability, security, safety, reliability and performance. With the help of quality models like ISO/IEC 25000 and methods like the Goal Question Metric approach it is possible to attribute metrics to quality objectives. This allows measuring the degree of attainment of quality objectives. This is a key component of the quality engineering process and, at the same time, is a prerequisite for its continuous monitoring and control. To ensure effective and efficient measuring of quality objectives the integration of core numbers, which were identified manually (e.g. by expert estimates or reviews), and automatically identified metrics (e.g. by statistical analysis of source codes or automated regression tests) as a basis for decision-making is favourable. [9]

Actors

The end-to-end quality management approach to quality engineering requires numerous actors with different responsibilities and tasks, different expertise and involvement in the organisation.

Different roles involved in quality engineering:

Typically, these roles are distributed over geographic and organisational boundaries. Therefore, appropriate measures need to be taken to coordinate the heterogeneous tasks of the various roles in quality engineering and to consolidate and synchronize the data and information necessary to fulfill the tasks, and make them available to each actor in an appropriate form.

Knowledge management

Knowledge management plays an important part in quality engineering. [10] The quality engineering knowledge base comprises manifold structured and unstructured data, ranging from code repositories via requirements specifications, standards, test reports and enterprise architecture models to system configurations and runtime logs. Software and system models play an important role in mapping this knowledge. The data of the quality engineering knowledge base are generated, processed and made available both manually as well as tool-based in a geographically, organisationally and technically distributed context. Of prime importance is the focus on quality assurance tasks, early recognition of risks, and appropriate support for the collaboration of actors.

This results in the following requirements for a quality engineering knowledge base:

Collaborative processes

The quality engineering process comprises all tasks carried out manually and in a (semi-)automated way to identify, fulfil and measure any quality features in a chosen context. The process is a highly collaborative one in the sense that it requires interaction of actors, widely acting independently from each other.

The quality engineering process has to integrate any existing sub-processes that may comprise highly structured processes such as IT service management and processes with limited structure such as agile software development. Another important aspect is change-driven procedure, where change events, such as changed requirements are dealt with in the local context of information and actors affected by such change. A pre-requisite for this is methods and tools, which support change propagation and change handling.

The objective of an efficient quality engineering process is the coordination of automated and manual quality assurance tasks. Code review or elicitation of quality objectives are examples of manual tasks, while regression tests and the collection of code metrics are examples for automatically performed tasks. The quality engineering process (or its sub-processes) can be supported by tools such as ticketing systems or security management tools.

See also

Associations

Related Research Articles

Software engineering is an engineering approach to software development. A practitioner, a software engineer, applies the engineering design process to develop software.

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

<span class="mw-page-title-main">Configuration management</span> Process for maintaining consistency of a product attributes with its design

Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and other industrial engineering segments such as roads, bridges, canals, dams, and buildings.

In software engineering, software configuration management is the task of tracking and controlling changes in the software, part of the larger cross-disciplinary field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine the "what, when, why and who" of the change. If a configuration is working well, SCM can determine how to replicate it across many hosts.

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.

Quality assurance (QA) is the term used in both manufacturing and service industries to describe the systematic efforts taken to assure that the product(s) delivered to customer(s) meet with the contractual and other agreed upon performance, design, reliability, and maintainability expectations of that customer. The core purpose of Quality Assurance is to prevent mistakes and defects in the development and production of both manufactured products, such as automobiles and shoes, and delivered services, such as automotive repair and athletic shoe design. Assuring quality and therefore avoiding problems and delays when delivering products or services to customers is what ISO 9000 defines as that "part of quality management focused on providing confidence that quality requirements will be fulfilled". This defect prevention aspect of quality assurance differs from the defect detection aspect of quality control and has been referred to as a shift left since it focuses on quality efforts earlier in product development and production and on avoiding defects in the first place rather than correcting them after the fact.

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

<span class="mw-page-title-main">Requirements analysis</span> Engineering process

In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating, and managing software or system requirements.

ISO/IEC/IEEE 12207Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

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

Reliability engineering is a sub-discipline of systems engineering that emphasizes the ability of equipment to function without failure. Reliability describes the ability of a system or component to function under stated conditions for a specified period. Reliability is closely related to availability, which is typically described as the ability of a component or system to function at a specified moment or interval of time.

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.

DO-178B, Software Considerations in Airborne Systems and Equipment Certification is a guideline dealing with the safety of safety-critical software used in certain airborne systems. It was jointly developed by the safety-critical working group RTCA SC-167 of the Radio Technical Commission for Aeronautics (RTCA) and WG-12 of the European Organisation for Civil Aviation Equipment (EUROCAE). RTCA published the document as RTCA/DO-178B, while EUROCAE published the document as ED-12B. Although technically a guideline, it was a de facto standard for developing avionics software systems until it was replaced in 2012 by DO-178C.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

Software assurance (SwA) is a critical process in software development that ensures the reliability, safety, and security of software products. It involves a variety of activities, including requirements analysis, design reviews, code inspections, testing, and formal verification. One crucial component of software assurance is secure coding practices, which follow industry-accepted standards and best practices, such as those outlined by the Software Engineering Institute (SEI) in their CERT Secure Coding Standards (SCS).

Requirements traceability is a sub-discipline of requirements management within software development and systems engineering. Traceability as a general term is defined by the IEEE Systems and Software Engineering Vocabulary as (1) the degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or primary-subordinate relationship to one another; (2) the identification and documentation of derivation paths (upward) and allocation or flowdown paths (downward) of work products in the work product hierarchy; (3) the degree to which each element in a software development product establishes its reason for existing; and (4) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks.

<span class="mw-page-title-main">View model</span>

A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.

Software requirements for a system are the description of what the system should do, the service or services that it provides and the constraints on its operation. The IEEE Standard Glossary of Software Engineering Terminology defines a requirement as:

  1. A condition or capability needed by a user to solve a problem or achieve an objective
  2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  3. A documented representation of a condition or capability as in 1 or 2

In software engineering, a software development process or software development life cycle (SDLC) 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. 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.

ISO/IEC JTC 1/SC 7 Software and systems engineering is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), that develops and facilitates standards within the field of engineering of software products and systems. The international secretariat of ISO/IEC JTC 1/SC 7 is the Bureau of Indian Standards (BIS) located in India.

References

  1. Juran, J.M. (1988). "Appendix IV Quality Systems Terminology" . In Juran, J.M (ed.). Juran's Quality Control Handbook. McGraw-Hill Book Company. pp.  2–3. ISBN   0-07-033176-6.
  2. Ruth Breu; Annie Kuntzmann-Combelles; Michael Felderer (January–February 2014). "New Perspectives on Software Quality" (PDF). IEEE Software. 31 (1). IEEE Computer Society: 32–38. doi:10.1109/MS.2014.9 . Retrieved 2 April 2014.
  3. Ruth Breu; Berthold Agreiter; Matthias Farwick; Michael Felderer; Michael Hafner; Frank Innerhofer-Oberperfler (2011). "Living Models - Ten Principles for Change-Driven Software Engineering" (PDF). International Journal of Software and Informatics. 5 (1–2). ISCAS: 267–290. Retrieved 16 April 2014.
  4. Michael Felderer; Christian Haisjackl; Ruth Breu; Johannes Motz (2012). "Integrating Manual and Automatic Risk Assessment for Risk-Based Testing" (PDF). Software Quality. Process Automation in Software Development. Lecture Notes in Business Information Processing. 94. Springer Berlin Heidelberg: 159–180. doi:10.1007/978-3-642-27213-4_11. ISBN   978-3-642-27212-7 . Retrieved 16 April 2014.
  5. "What is a Quality Engineer - what do they do & how can you become one?". 17 February 2017. Retrieved 2 October 2018.
  6. "Certified Quality Engineer Certification Preparation - ASQ". asq.org. Retrieved 2 October 2018.
  7. "ISO 9001 Auditing Practices Group". committee.iso.org. Archived from the original on 29 March 2019. Retrieved 7 September 2018.
  8. "Process Quality Engineer". automotiveengineeringhq.com. 17 December 2014. Retrieved 7 September 2018.
  9. Michael Kläs; Frank Elberzhager; Jürgen Münch; Klaus Hartjes; Olaf von Graevemeyer (2–8 May 2010). "Transparent combination of expert and measurement data for defect prediction: an industrial case study" (PDF). Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering. 2. ACM New York, USA: 119–128. Retrieved 8 April 2014.
  10. Jacek Czerwonka; Nachiappan Nagappan; Wolfram Schulte; Brendan Murphy (July–August 2013). "CODEMINE: Building a Software Development Data Analytics Platform at Microsoft" (PDF). IEEE Software. 30 (4). IEEE Computer Society: 64–71. doi:10.1109/MS.2013.68. S2CID   32085825 . Retrieved 7 April 2014.