Jump to content

Quality engineering: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Added Category:Quality
Citation bot (talk | contribs)
Alter: template type, number. Add: s2cid, date, isbn, series, doi, chapter-url, chapter-url-access. Removed or converted URL. Removed parameters. Formatted dashes. Some additions/deletions were parameter name changes. Upgrade ISBN10 to 13. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox2 | #UCB_webform_linked 1557/2044
Line 4: Line 4:


'''Quality engineering''' is the discipline of engineering concerned with the principles and practice of product and service quality assurance and control.<ref>
'''Quality engineering''' is the discipline of engineering concerned with the principles and practice of product and service quality assurance and control.<ref>
{{cite book|last=Juran|first=J.M.|editor-last=Juran|editor-first=J.M|title=Juran's Quality Control Handbook|publisher=McGraw-Hill Book Company|date=1988|pages=[https://archive.org/details/juransqualitycon00jmju/page/2 2–3]|chapter=Appendix IV Quality Systems Terminology|isbn=0-07-033176-6|url-access=registration|url=https://archive.org/details/juransqualitycon00jmju/page/2}}</ref> In software development, it is the management, development, operation and maintenance of IT systems and [[enterprise architecture]]s with a high quality standard.<ref>{{cite web | journal=IEEE Software |author1=Ruth Breu |author2=Annie Kuntzmann-Combelles |author3=Michael Felderer | title=New Perspectives on Software Quality | access-date=2 April 2014 | date=January–February 2014 | publisher=IEEE Computer Society | volume=31 | number=1 | url=http://www.computer.org/csdl/mags/so/2014/01/mso2014010032.pdf | pages=32–38 }}</ref><ref>{{cite web | journal=International Journal of Software and Informatics |author1=Ruth Breu |author2=Berthold Agreiter |author3=Matthias Farwick |author4=Michael Felderer |author5=Michael Hafner |author6=Frank Innerhofer-Oberperfler | title=Living Models - Ten Principles for Change-Driven Software Engineering | access-date=16 April 2014 | date=2011 | publisher=ISCAS | volume=5 | number=1-2 | url=http://qe-informatik.uibk.ac.at/wp-content/uploads/2014/03/BreuLivingModels.pdf | pages=267–290 }}</ref><ref>{{cite web | journal=Software Quality. Process Automation in Software Development |author1=Michael Felderer |author2=Christian Haisjackl |author3=Ruth Breu |author4=Johannes Motz | title=Integrating Manual and Automatic Risk Assessment for Risk-Based Testing | access-date=16 April 2014 | date=2012 | publisher=Springer Berlin Heidelberg | volume=94 | url=http://qe-informatik.uibk.ac.at/wp-content/uploads/2014/03/Felderer2011AssessmentRiskBasedTesting.pdf | pages=159–180 }}</ref>
{{cite book|last=Juran|first=J.M.|editor-last=Juran|editor-first=J.M|title=Juran's Quality Control Handbook|publisher=McGraw-Hill Book Company|date=1988|pages=[https://archive.org/details/juransqualitycon00jmju/page/2 2–3]|chapter=Appendix IV Quality Systems Terminology|isbn=0-07-033176-6|chapter-url-access=registration|chapter-url=https://archive.org/details/juransqualitycon00jmju/page/2}}</ref> In software development, it is the management, development, operation and maintenance of IT systems and [[enterprise architecture]]s with a high quality standard.<ref>{{cite journal | journal=IEEE Software |author1=Ruth Breu |author2=Annie Kuntzmann-Combelles |author3=Michael Felderer | title=New Perspectives on Software Quality | access-date=2 April 2014 | date=January–February 2014 | publisher=IEEE Computer Society | volume=31 | number=1 | url=http://www.computer.org/csdl/mags/so/2014/01/mso2014010032.pdf | pages=32–38 |doi=10.1109/MS.2014.9 }}</ref><ref>{{cite journal | journal=International Journal of Software and Informatics |author1=Ruth Breu |author2=Berthold Agreiter |author3=Matthias Farwick |author4=Michael Felderer |author5=Michael Hafner |author6=Frank Innerhofer-Oberperfler | title=Living Models - Ten Principles for Change-Driven Software Engineering | access-date=16 April 2014 | date=2011 | publisher=ISCAS | volume=5 | number=1–2 | url=http://qe-informatik.uibk.ac.at/wp-content/uploads/2014/03/BreuLivingModels.pdf | pages=267–290 }}</ref><ref>{{cite journal | journal=Software Quality. Process Automation in Software Development |author1=Michael Felderer |author2=Christian Haisjackl |author3=Ruth Breu |author4=Johannes Motz | title=Integrating Manual and Automatic Risk Assessment for Risk-Based Testing |series=Lecture Notes in Business Information Processing | access-date=16 April 2014 | date=2012 | publisher=Springer Berlin Heidelberg | volume=94 | url=http://qe-informatik.uibk.ac.at/wp-content/uploads/2014/03/Felderer2011AssessmentRiskBasedTesting.pdf | pages=159–180 |doi=10.1007/978-3-642-27213-4_11 |isbn=978-3-642-27212-7 }}</ref>


== Description ==
== Description ==
Line 34: Line 34:
'''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.<ref>{{cite web|url=https://committee.iso.org/sites/tc176sc2/home/page/iso-9001-auditing-practices-grou.html|title=ISO 9001 Auditing Practices Group|website=committee.iso.org|access-date=7 September 2018|archive-url=https://web.archive.org/web/20190329083313/https://committee.iso.org/sites/tc176sc2/home/page/iso-9001-auditing-practices-grou.html|archive-date=29 March 2019|url-status=dead}}</ref>
'''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.<ref>{{cite web|url=https://committee.iso.org/sites/tc176sc2/home/page/iso-9001-auditing-practices-grou.html|title=ISO 9001 Auditing Practices Group|website=committee.iso.org|access-date=7 September 2018|archive-url=https://web.archive.org/web/20190329083313/https://committee.iso.org/sites/tc176sc2/home/page/iso-9001-auditing-practices-grou.html|archive-date=29 March 2019|url-status=dead}}</ref>


'''Process quality''': Quality engineers may be tasked with value stream mapping and statistical process control to determine if a process is likely to produce defective product. They may create inspection plans and criteria to ensure defective parts are detected prior to completion.<ref>{{cite web|url=https://www.automotiveengineeringhq.com/process-quality-engineer/|title=Process Quality Engineer|website=automotiveengineeringhq.com|access-date=7 September 2018}}</ref>
'''Process quality''': Quality engineers may be tasked with value stream mapping and statistical process control to determine if a process is likely to produce defective product. They may create inspection plans and criteria to ensure defective parts are detected prior to completion.<ref>{{cite web|url=https://www.automotiveengineeringhq.com/process-quality-engineer/|title=Process Quality Engineer|website=automotiveengineeringhq.com|date=17 December 2014 |access-date=7 September 2018}}</ref>


'''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 product.
'''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 product.
Line 49: Line 49:


== Quality objectives ==
== 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 [[GQM|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.<ref>{{cite web | journal=Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering |author1=Michael Kläs |author2=Frank Elberzhager |author3=Jürgen Münch |author4=Klaus Hartjes |author5=Olaf von Graevemeyer | title=Transparent combination of expert and measurement data for defect prediction: an industrial case study | access-date=8 April 2014 | date=2–8 May 2010 | publisher=ACM New York, USA | volume=2 | url=http://www.klaes.org/Z-files/Klaes-2010-ICSE-Paper.pdf | pages=119–128 }}</ref>
[[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 [[GQM|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.<ref>{{cite journal | journal=Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering |author1=Michael Kläs |author2=Frank Elberzhager |author3=Jürgen Münch |author4=Klaus Hartjes |author5=Olaf von Graevemeyer | title=Transparent combination of expert and measurement data for defect prediction: an industrial case study | access-date=8 April 2014 | date=2–8 May 2010 | publisher=ACM New York, USA | volume=2 | url=http://www.klaes.org/Z-files/Klaes-2010-ICSE-Paper.pdf | pages=119–128 }}</ref>


== Actors ==
== Actors ==
Line 68: Line 68:


== Knowledge management ==
== Knowledge management ==
[[Knowledge management]] plays an important part in quality engineering.<ref>{{cite web | journal=IEEE Software |author1=Jacek Czerwonka |author2=Nachiappan Nagappan |author3=Wolfram Schulte |author4=Brendan Murphy | title=CODEMINE: Building a Software Development Data Analytics Platform at Microsoft | access-date=7 April 2014 | date=July–August 2013 | publisher=IEEE Computer Society | volume=30 | number=4 | url=http://research.microsoft.com/pubs/200717/CodeMine.pdf | pages=64–71 }}</ref> The quality engineering knowledge base comprises manifold structured and [[unstructured data]], ranging from code repositories via requirements specifications, standards, test reports, 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.
[[Knowledge management]] plays an important part in quality engineering.<ref>{{cite journal | journal=IEEE Software |author1=Jacek Czerwonka |author2=Nachiappan Nagappan |author3=Wolfram Schulte |author4=Brendan Murphy | title=CODEMINE: Building a Software Development Data Analytics Platform at Microsoft | access-date=7 April 2014 | date=July–August 2013 | publisher=IEEE Computer Society | volume=30 | number=4 | url=http://research.microsoft.com/pubs/200717/CodeMine.pdf | pages=64–71 |doi=10.1109/MS.2013.68 |s2cid=32085825 }}</ref> The quality engineering knowledge base comprises manifold structured and [[unstructured data]], ranging from code repositories via requirements specifications, standards, test reports, 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:
This results in the following requirements for a quality engineering knowledge base:

Revision as of 15:37, 4 August 2023

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 a high quality standard.[2][3][4]

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]

  • Management and leadership
  • The quality system
  • Elements of a quality system
  • Product and process design
  • Classification of quality characteristics
  • Design inputs and review
  • Design verification
  • Reliability and maintainability
  • Product and process control
  • Continuous improvement
  • Quality control tools
  • Quality management and planning tools
  • Continuous improvement techniques
  • Corrective action
  • Preventive action
  • Statistical process control (SPC)
  • Risk management

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 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 product.

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 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:

  • Business architect,
  • IT architect,
  • Security officer,
  • Requirements engineer,
  • Software quality manager,
  • Test manager,
  • Project manager,
  • Product manager and
  • Security architect.

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 in fulfilling the tasks, and to 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, 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:

  • Knowledge is available in a quality as required. Important quality criteria include that knowledge is consistent and up-to-date as well as complete and adequate in terms of granularity in relation to the tasks of the appropriate actors.
  • Knowledge is interconnected and traceable in order to support interaction between the actors and to facilitate analysis of data. Such traceability relates not only to interconnectedness of data across different levels of abstraction (e.g. connection of requirements with the services realizing them) but also to their traceability over time periods, which is only possible if appropriate versioning concepts exist. Data can be interconnected both manually as well as (semi-) automatically.
  • Information has to be available in a form that is consistent with the domain knowledge of the appropriate actors. Therefore, the knowledge base has to provide adequate mechanisms for information transformation (e.g. aggregation) and visualization. The RACI concept is an example of an appropriate model for assigning actors to information in a quality engineering knowledge base.
  • In contexts, where actors from different organisations or levels interact with each other, the quality engineering knowledge base has to provide mechanisms for ensuring confidentiality and integrity.
  • Quality engineering knowledge bases offer a whole range of possibilities for analysis and finding information in order to support quality control tasks of actors.

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

External links

  • Txture is a tool for textual IT-Architecture documentation and analysis.
  • mbeddr is a set of integrated and extensible languages for embedded software engineering, plus an integrated development environment (IDE).
  • qeunit.com is a blog on QE matters

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.