WikiDer > Качественная инженерия

Quality engineering
Для журнала см. Качественная инженерия (журнал).

Качественная инженерия инженерная дисциплина, связанная с принципами и практикой обеспечения и контроля качества продукции и услуг.[1] При разработке программного обеспечения это управление, разработка, эксплуатация и обслуживание ИТ-систем и корпоративные архитектуры с высоким стандартом качества.[2][3][4]

Описание

Инженерия качества - это инженерная дисциплина, которая создает и реализует стратегии обеспечения качества при разработке и производстве продукции, а также разработке программного обеспечения.[5]

Инженеры по качеству сосредоточены на оптимизации качества продукции, которая У. Эдвардс Деминг определяется как:[6]

Свод знаний в области инженерии качества включает:[7]

  • Менеджмент и лидерство
  • Система качества
  • Элементы системы качества
  • Дизайн продуктов и процессов
  • Классификация качественных характеристик
  • Входные данные и обзор дизайна
  • Проверка дизайна
  • Надежность и ремонтопригодность
  • Контроль продуктов и процессов
  • Непрерывное улучшение
  • Инструменты контроля качества
  • Инструменты управления качеством и планирования
  • Методы постоянного улучшения
  • Корректирующее действие
  • Предупредительные меры
  • Статистический контроль процессов (SPC)
  • Управление рисками

Роли

Аудитор: Инженеры по качеству могут нести ответственность за аудит своих компаний или их поставщиков на соответствие международным стандартам качества, таким как ISO9000 и AS9100. Они также могут быть независимыми аудиторами при аудиторском органе.[8]

Качество процесса: Инженерам по качеству может быть поручено составление карты потока создания ценности и статистический контроль процессов, чтобы определить, может ли процесс производить дефектный продукт. Они могут создавать планы и критерии проверки, чтобы убедиться, что дефектные детали обнаружены до завершения.[9]

Качество поставщика: Инженеры по качеству могут нести ответственность за аудит поставщиков или выполнение первопричин и корректирующих действий на их предприятии или надзор за такой деятельностью, чтобы предотвратить поставку дефектной продукции.

Программного обеспечения

ИТ-сервисы все больше взаимосвязаны в рабочих процессах, независимо от границ платформ, устройств и организаций, например, в киберфизических системах, рабочих процессах между бизнесом или при использовании облачных сервисов. В таких контекстах инженерия качества способствует необходимому всеобъемлющему учету атрибутов качества.

В таких условиях жизненно важно «сквозное» представление качества от управления до эксплуатации. Инженерия качества объединяет методы и инструменты из архитектура предприятия-управление, Управление программным продуктом, Управление ИТ-услугами, программная инженерия и системная инженерия, и из управление качеством программного обеспечения и управление информационной безопасностью. Это означает, что инженерия качества выходит за рамки классических дисциплин программной инженерии, управления информационной безопасностью или управления программными продуктами, поскольку объединяет вопросы управления (такие как бизнес-стратегия и ИТ-стратегия, управление рисками, представления бизнес-процессов, управление знаниями и информацией, управление оперативной производительностью). , соображения дизайна (включая процесс разработки программного обеспечения, анализ требований, тестирование программного обеспечения) и оперативные соображения (например, конфигурация, мониторинг, Управление ИТ-услугами). Во многих областях, где он используется, инженерия качества тесно связана с соблюдением юридических и деловых требований, договорных обязательств и стандартов. Что касается атрибутов качества, то надежность, безопасность и безопасность ИТ-услуг играют доминирующую роль.

В инженерии качества цели в области качества реализуются в процессе сотрудничества. Этот процесс требует взаимодействия в значительной степени независимых субъектов, знания которых основаны на различных источниках информации.

Качественная инженерия

Цели качества

Цели качества описать основные требования к качество программного обеспечения. В качественном проектировании они часто обращаются к качественным атрибутам доступности, безопасности, безопасности, надежности и производительности. С помощью моделей качества, таких как ISO / IEC 25000, и таких методов, как Показатель вопроса о цели При таком подходе можно отнести метрики к целям качества. Это позволяет измерить степень достижения целей в области качества. Это ключевой компонент процесса разработки качества и, в то же время, необходимое условие для его непрерывного мониторинга и контроля. Для обеспечения эффективного и действенного измерения целей в области качества интеграция основных показателей, которые были определены вручную (например, экспертными оценками или обзорами), и автоматически определенных метрик (например, путем статистического анализа исходных кодов или автоматических регрессионных тестов) в качестве основы для принятия решения. - изготовление благоприятное.[10]

Актеры

Подход к непрерывному управлению качеством к инженерии качества требует наличия множества участников с разными обязанностями и задачами, разного опыта и участия в организации.

Различные роли, задействованные в инженерии качества:

  • Бизнес-архитектор,
  • ИТ-архитектор,
  • Сотрудник службы безопасности,
  • Инженер по требованиям,
  • Менеджер по качеству программного обеспечения,
  • Менеджер по тестированию,
  • Руководитель проекта,
  • Менеджер по продукту и
  • Архитектор безопасности.

Обычно эти роли распределяются по географическим и организационным границам. Следовательно, необходимо принять соответствующие меры для координации разнородных задач различных ролей в инженерии качества, а также для консолидации и синхронизации данных и информации, необходимых для выполнения задач, и сделать их доступными для каждого участника в соответствующей форме.

Управление знаниями

Управление знаниями играет важную роль в качественном проектировании.[11] База знаний по качественному инжинирингу включает в себя разнообразную структуру и неструктурированные данные, начиная от репозиториев кода и заканчивая спецификациями требований, стандартами, отчетами об испытаниях, моделями архитектуры предприятия до конфигураций системы и журналов времени выполнения. Программное обеспечение и системные модели играют важную роль в отображении этих знаний. Данные базы знаний в области инженерии качества генерируются, обрабатываются и становятся доступными как вручную, так и с помощью инструментов в географически, организационно и технически распределенном контексте. Первостепенное значение имеет акцент на гарантия качества задачи, раннее распознавание рисков и соответствующая поддержка сотрудничества участников.

Это приводит к следующим требованиям к базе знаний в области инженерии качества:

  • Знания доступны в необходимом качестве. Важные критерии качества включают то, что знания являются последовательными и актуальными, а также полными и адекватными с точки зрения детализации по отношению к задачам соответствующих субъектов.
  • Знания взаимосвязаны и отслеживаются, чтобы поддерживать взаимодействие между участниками и облегчить анализ данных. Такая прослеживаемость относится не только к взаимосвязанности данных на разных уровнях абстракции (например, связь требований со службами, реализующими их), но и к их прослеживаемости за периоды времени, что возможно только при наличии соответствующих концепций управления версиями. Данные могут быть связаны как вручную, так и (полу) автоматически.
  • Информация должна быть доступна в форме, соответствующей базовые знания соответствующих актеров. Следовательно, база знаний должна обеспечивать адекватные механизмы преобразования информации (например, агрегирования) и визуализации. В RACI Концепция является примером подходящей модели для присвоения акторам информации в базе знаний по качественной инженерии.
  • В условиях, когда субъекты из разных организаций или уровней взаимодействуют друг с другом, база знаний по качественной инженерии должна обеспечивать механизмы для обеспечения конфиденциальности и целостности.
  • Базы знаний в области инженерии качества предлагают целый ряд возможностей для анализа и поиска информации для поддержки задач по контролю качества субъектов.

Совместные процессы

Процесс инжиниринга качества включает в себя все задачи, выполняемые вручную и (полу) автоматизированным способом для выявления, выполнения и измерения любых характеристик качества в выбранном контексте. Этот процесс является в высшей степени совместным в том смысле, что он требует взаимодействия субъектов, широко действующих независимо друг от друга.

Процесс инженерии качества должен интегрировать любые существующие подпроцессы, которые могут включать в себя сильно структурированные процессы, такие как Управление ИТ-услугами и процессы с ограниченной структурой, такие как гибкая разработка программного обеспечения. Другим важным аспектом является процедура, основанная на изменениях, когда события изменения, такие как измененные требования, рассматриваются в местном контексте информации и субъектов, затронутых такими изменениями. Необходимым условием для этого являются методы и инструменты, которые поддерживают распространение изменений и обработку изменений.

Целью эффективного процесса разработки качества является координация автоматизированного и ручного гарантия качества задачи. Обзор кода или выявление целей качества - это примеры ручных задач, в то время как регрессионные тесты и сбор показателей кода - примеры для автоматически выполняемых задач. Процесс разработки качества (или его подпроцессы) может поддерживаться такими инструментами, как системы продажи билетов или инструменты управления безопасностью.

Смотрите также

Ассоциации

внешняя ссылка

  • Txture это инструмент для текстовой документации и анализа IT-архитектуры.
  • mbeddr представляет собой набор интегрированных и расширяемых языков для разработки встроенного программного обеспечения, а также интегрированную среду разработки (IDE).

Рекомендации

  1. ^ Джуран, Дж. М. (1988). «Приложение IV Терминология систем качества». В Джуран, Дж. М. (ред.). Справочник Джурана по контролю качества. Книжная компания McGraw-Hill. стр.2–3. ISBN 0-07-033176-6.
  2. ^ Рут Бреу; Анни Кунцманн-Комбеллес; Майкл Фельдерер (январь – февраль 2014 г.). «Новые взгляды на качество программного обеспечения» (PDF). Программное обеспечение IEEE. Компьютерное общество IEEE. стр. 32–38. Получено 2 апреля 2014.
  3. ^ Рут Бреу; Бертольд Агрейтер; Маттиас Фарвик; Майкл Фельдерер; Майкл Хафнер; Франк Иннерхофер-Оберперфлер (2011). «Живые модели - десять принципов разработки программного обеспечения с учетом изменений» (PDF). Международный журнал программного обеспечения и информатики. ISCAS. стр. 267–290. Получено 16 апреля 2014.
  4. ^ Майкл Фельдерер; Кристиан Хайсджакль; Рут Бреу; Йоханнес Моц (2012). «Интеграция ручной и автоматической оценки рисков для тестирования на основе рисков» (PDF). Качество программного обеспечения. Автоматизация процессов в разработке программного обеспечения. Springer Berlin Heidelberg. стр. 159–180. Получено 16 апреля 2014.
  5. ^ «Что такое инженер по качеству - чем он занимается и как вы можете им стать?». 17 февраля 2017 г.. Получено 2 октября 2018.
  6. ^ Моннаппа, Авантика. «Пионеры управления проектами: Деминг против Джурана против Кросби».
  7. ^ «Подготовка к сертификации сертифицированного инженера по качеству - ASQ». asq.org. Получено 2 октября 2018.
  8. ^ «Группа аудиторских практик ISO 9001». Committee.iso.org. Архивировано из оригинал 29 марта 2019 г.. Получено 7 сентября 2018.
  9. ^ «Инженер по качеству процессов». automotiveengineeringhq.com. Получено 7 сентября 2018.
  10. ^ Майкл Клэс; Франк Эльбержагер; Юрген Мюнх; Клаус Хартьес; Олаф фон Грейвмайер (2–8 мая 2010 г.). «Прозрачное сочетание экспертных данных и данных измерений для прогнозирования дефектов: промышленный пример» (PDF). Материалы 32-й Международной конференции ACM / IEEE по программной инженерии. ACM Нью-Йорк, США. стр. 119–128. Получено 8 апреля 2014.
  11. ^ Яцек Червонка; Начиаппан Нагаппан; Вольфрам Шульте; Брендан Мерфи (июль – август 2013 г.). «CODEMINE: Создание платформы анализа данных для разработки программного обеспечения в Microsoft» (PDF). Программное обеспечение IEEE. Компьютерное общество IEEE. стр. 64–71. Получено 7 апреля 2014.