Quality engineering

For the journal, see Quality Engineering (journal).

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]

공정 품질: 품질 엔지니어들은 어떤 공정이 결함이 있는 제품을 생산할 가능성이 있는지를 판단하기 위해 가치 스트림 매핑과 통계적 공정 제어를 담당할 수 있다. 그들은 완성 전에 불량 부품이 발견되도록 검사 계획과 기준을 작성할 수 있다.[8]

공급업체 품질: 품질 엔지니어는 공급업체를 감사하거나 해당 시설에서 근본 원인 및 시정 조치를 수행하거나 결함이 있는 제품이 납품되지 않도록 그러한 활동을 감독할 책임이 있다.

소프트웨어

예를 들어 사이버-물리적 시스템, 비즈니스 간 워크플로우 또는 클라우드 서비스를 사용할 때 플랫폼 경계, 장치 및 조직 경계를 넘어 워크플로우에 IT 서비스가 점점 더 연동되고 있다. 그러한 맥락에서, 품질 공학은 품질 속성의 필요한 모든 것을 고려하는 것을 용이하게 한다.

이러한 맥락에서 경영에서 운영까지 품질에 대한 "종단간" 관점은 필수적이다. 품질 엔지니어링은 엔터프라이즈 아키텍처 관리, 소프트웨어 제품 관리, IT 서비스 관리, 소프트웨어 엔지니어링 및 시스템 엔지니어링, 소프트웨어 품질 관리 및 정보 보안 관리의 방법과 도구를 통합한다. 즉, 품질 엔지니어링은 경영 문제(비즈니스 및 IT 전략, 리스크 관리, 비즈니스 프로세스 뷰, 지식 및 정보 관리, 운영 성과 관리 등)를 통합하기 때문에 소프트웨어 엔지니어링, 정보보안 관리 또는 소프트웨어 제품 관리의 고전적 분야를 넘어선다.서명 고려사항(소프트웨어 개발 프로세스, 요구사항 분석, 소프트웨어 테스트 포함) 및 운영 고려사항(구성, 모니터링, IT 서비스 관리 등) 그것이 사용되는 많은 분야에서, 품질 공학은 법적, 사업적 요건, 계약적 의무 및 표준의 준수에 밀접하게 연관되어 있다. 품질 속성에 관한 한, IT 서비스의 신뢰성, 보안 및 안전성이 주된 역할을 한다.

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.

이에 따라 품질 엔지니어링 지식 기반에 대한 다음과 같은 요구사항이 발생한다.

  • 지식은 필요에 따라 질적으로 이용할 수 있다. 중요한 품질 기준은 지식이 일관되고 최신일 뿐만 아니라 해당 행위자의 직무와 관련하여 세분화 측면에서 완전하고 적절하다는 것을 포함한다.
  • 지식은 행위자 간의 상호작용을 지원하고 데이터 분석을 용이하게 하기 위해 상호 연결되고 추적 가능하다. 그러한 추적가능성은 서로 다른 추상화 수준에 걸친 데이터의 상호연결성(예: 이를 실현하는 서비스와의 요구사항 연결)뿐만 아니라, 적절한 버전화 개념이 존재하는 경우에만 가능한 시간에 따른 추적가능성과도 관련이 있다. 데이터는 (반-) 자동뿐만 아니라 수동으로 모두 상호 연결될 수 있다.
  • 정보는 적절한 행위자의 도메인 지식과 일치하는 형태로 이용 가능해야 한다. 따라서, 지식 기반은 정보 변환(예: 통합)과 시각화를 위한 적절한 메커니즘을 제공해야 한다. RACI 개념은 품질 공학 지식 기반에서 정보로 행위자를 할당하기 위한 적절한 모델의 예다.
  • 서로 다른 조직이나 수준의 행위자들이 서로 상호작용하는 맥락에서, 품질 공학 지식 기반은 기밀성과 무결성을 보장하기 위한 메커니즘을 제공해야 한다.
  • 품질 공학 지식 기반은 행위자의 품질 관리 업무를 지원하기 위해 분석 및 정보 찾기에 대한 광범위한 가능성을 제공한다.

협업 프로세스

품질 엔지니어링 프로세스는 선택한 맥락에서 품질 특성을 식별, 이행 및 측정할 수 있는 자동화된 방식으로 수동적으로 수행되는 모든 작업으로 구성된다. 그 과정은 배우들의 상호작용이 필요하고, 서로 독립적으로 광범위하게 작용한다는 점에서 매우 협력적인 과정이다.

품질 엔지니어링 프로세스는 IT 서비스 관리와 같은 고도로 구조화된 프로세스와 신속한 변화를 위한 소프트웨어 개발과 같은 제한된 구조를 가진 프로세스로 구성될 수 있는 기존의 하위 프로세스를 통합해야 한다. 또 다른 중요한 측면은 변화 주도 절차로서, 변경된 요건과 같은 변경 사건이 그러한 변화의 영향을 받는 정보 및 행위자의 국지적 맥락에서 처리된다. 이를 위한 사전 요구사항은 변경 전파 및 변경 처리를 지원하는 방법과 툴이다.

효율적인 품질 엔지니어링 프로세스의 목표는 자동화 및 수동 품질 보증 작업의 조정이다. 코드 검토 또는 품질 목표 도출은 수동 작업의 예인 반면 회귀 테스트와 코드 메트릭스 수집은 자동으로 수행되는 작업의 예다. 품질 엔지니어링 프로세스(또는 그 하위 프로세스)는 티켓팅 시스템이나 보안 관리 도구와 같은 도구로 지원될 수 있다.

참고 항목

연관성

외부 링크

  • Tuffix는 텍스트 IT 아키텍처 문서화 및 분석을 위한 툴이다.
  • mbeddr은 임베디드 소프트웨어 엔지니어링을 위한 통합 및 확장 가능한 언어 세트와 통합 개발 환경(IDE)이다.

참조

  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. IEEE Computer Society. pp. 32–38. 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. ISCAS. pp. 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. Springer Berlin Heidelberg. pp. 159–180. 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. 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. ACM New York, USA. pp. 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. IEEE Computer Society. pp. 64–71. Retrieved 7 April 2014.