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