Обнаруживает дефекты и ошибки в компьютерной игре, контролирует ее качество

Обновлено: 06.07.2024

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

"Качество шести сигм" — это термин, обычно используемый для обозначения того, что процесс хорошо контролируется (в пределах процесса ±3 с от центральной линии на контрольной диаграмме и в пределах требований/допусков ±6 с от центральной линии).

Разные мнения об определении шести сигм

Различные определения, приведенные ниже, были предложены для шести сигм, но все они имеют некоторые общие черты:

Использование команд, которым назначены четко определенные проекты, оказывающие непосредственное влияние на итоговую прибыль организации.
Обучение «статистическому мышлению» на всех уровнях, а также предоставление ключевым специалистам всестороннего обучения передовой статистике и управлению проектами. Этих ключевых людей называют «черными поясами». Ознакомьтесь с различными поясами, уровнями и ролями шести сигм.
Акцент на подходе DMAIC к решению проблем: определение, измерение, анализ, улучшение и контроль.
Среда управления, поддерживающая эти инициативы в качестве бизнес-стратегии.

Философия. С философской точки зрения шесть сигм рассматривают всю работу как процессы, которые можно определить, измерить, проанализировать, улучшить и контролировать. Процессы требуют входных данных (x) и производят выходные данные (y). Если вы контролируете входы, вы будете контролировать и выходы. Обычно это выражается как y = f(x).

Набор инструментов. Эксперт по шести сигм использует качественные и количественные методы или инструменты для улучшения процессов. К таким инструментам относятся статистический контроль процессов (SPC), контрольные карты, анализ видов и последствий отказов (FMEA) и картирование процессов. Профессионалы «Шести сигм» не полностью согласны с тем, какие именно инструменты составляют набор.

Методология. Этот взгляд на шесть сигм отражает лежащий в основе и строгий подход DMAIC. DMAIC определяет шаги, которым должен следовать практик Шести Сигм, начиная с выявления проблемы и заканчивая внедрением долгосрочных решений. Хотя DMAIC — не единственная используемая методология «Шесть сигм», она, безусловно, является наиболее широко распространенной и признанной.

Показатели. Проще говоря, показатели качества "Шесть сигм" означают 3,4 дефекта на миллион возможностей (со смещением среднего значения на 1,5 сигмы).

Шесть сигм качества

Что такое Lean Six Sigma?

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

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

Шесть сигм на ASQTV™

Только для участников ASQ

Серия веб-трансляций «Семь инструментов шести сигм»:

Объединение бережливого производства и шести сигм

Бережливое производство и шесть сигм обеспечивают клиентам наилучшее качество, стоимость, доставку и новый атрибут — оперативность. Эти две дисциплины во многом пересекаются; однако оба они подходят к своей общей цели с несколько разных точек зрения:

• Бережливое производство направлено на сокращение отходов, а метод "Шесть сигм" – на сокращение вариаций.

• Бережливое производство достигает своих целей за счет менее технических инструментов, таких как кайдзен, организация рабочего места и средства визуального контроля, в то время как метод "Шесть сигм" обычно использует статистический анализ данных, планирование экспериментов и проверку гипотез.

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

Внедрение шести сигм

Стратегии внедрения "Шести сигм" могут существенно различаться в разных организациях в зависимости от их культуры и стратегических бизнес-целей.Приняв решение внедрить шесть сигм, у организации есть два основных варианта:

Внедрить программу или инициативу "Шесть сигм".
Создайте инфраструктуру шести сигм.

Вариант 1. Внедрение программы или инициативы «Шесть сигм»

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

Когда организации внедряют "Шесть сигм" в качестве программы или инициативы, часто кажется, что они добавили в свой набор инструментов неструктурированным образом несколько новых инструментов в ходе учебных занятий. Одним из расширений этого подхода является применение инструментов по мере необходимости к назначенным проектам. Однако важно отметить, что выбор, управление и выполнение проектов обычно не являются неотъемлемой частью организации.

Внедрение программы или инициативы "Шесть сигм" может привести к уникальным проблемам. Поскольку эти проекты часто создаются на низком уровне внутри организации, они могут не поддерживаться высшим руководством, что может привести к сопротивлению со стороны других групп, затронутых инициативой. Кроме того, как правило, никто не назначается для поддержки проектов за пределами организации и содействия изменениям.

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

Для настоящего успеха необходима поддержка на уровне высшего руководства и участие руководства. Это может помочь в применении статистических инструментов и других методологий "Шесть сигм" за пределами организации.

Вариант 2. Создайте инфраструктуру шести сигм

Вместо того, чтобы сосредотачиваться на отдельных инструментах, лучше всего, когда обучение «Шесть сигм» предлагает ориентированный на процесс подход, который обучает практиков методологии выбора правильного инструмента в нужное время для заранее определенного проекта. Обучение шести сигм для практиков (черных поясов) с использованием этого подхода обычно состоит из четырех недель обучения в течение четырех месяцев, когда студенты работают над своими проектами в течение трех недель между сессиями.

Внедрение «Шесть сигм» в качестве бизнес-стратегии посредством проектов, а не инструментов — это более эффективный способ извлечь выгоду из времени и денег, вложенных в обучение «Шесть сигм».

Рассмотрите следующие преимущества развертывания Six Sigma благодаря проектам, имеющим поддержку высшего руководства:

Оказывает большее влияние благодаря проектам, привязанным к конечным результатам.
Использует инструменты более целенаправленно и продуктивно
Предлагает процесс/стратегию управления проектами, которые можно изучить и улучшить.
Расширяет общение между руководством и практиками посредством презентаций проектов
Облегчает детальное понимание важнейших бизнес-процессов.
Предоставляет сотрудникам и руководству информацию о том, как статистические инструменты могут быть полезны для организаций.
Позволяет обладателям черного пояса получать отзывы об их подходе к проекту во время обучения.
Применяет метод "Шесть сигм" с замкнутым циклом, выделяя время для аудита и включения извлеченных уроков в общую бизнес-стратегию.

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

Изначально у компаний могут быть проекты, которые слишком велики или, возможно, не выбраны из-за их стратегического влияния на итоговую прибыль. Разочарование в первом наборе проектов может стать жизненно важным опытом, мотивирующим к совершенствованию на втором этапе.

Шесть сигм – это долгосрочное обязательство. Рассмотрение развертывания как процесса позволяет провести объективный анализ всех аспектов процесса, включая выбор проекта и его определение. Использование извлеченных уроков и включение их в последующие этапы плана внедрения создает замкнутую петлю обратной связи и реальные существенные выгоды, если организация инвестирует время и исполнительную энергию, необходимые для внедрения «Шести сигм» в качестве бизнес-стратегии!

Ресурсы «Шесть сигм»

Вы также можете искать статьи, тематические исследования и публикации по ресурсам Six Sigma.

Книги

Примеры использования

Pitch Perfect (Обзор бережливого производства и шести сигм). Изучение тонкостей анализа возможностей путем изучения результатов бейсбольного питчера.

The More The Merrier (Журнал Six Sigma Forum) В мире качества хорошо известно, что инициативы Lean и Six Sigma (LSS) вряд ли увенчаются успехом или будут реализованы без поддержки управление высокого уровня. В трех тематических исследованиях эта концепция демонстрируется на реальных примерах.

Save Your Steps (журнал Six Sigma Forum) Linde Group, газовая и инженерная организация, провела модернизацию процессов на нескольких предприятиях в Северной Америке, чтобы повысить эффективность процессов с помощью принципов бережливого производства и шести сигм.

Статьи

Модели развертывания и зрелости Lean Six Sigma: критический обзор (Журнал управления качеством). Исследование указывает на важную потребность в научном анализе процесса внедрения таких подходов, как LSS, и для более эффективного перевод устоявшейся теории организационного развития в формы, которые могут использовать практики.

Человеческая сторона шести сигм: положительные отзывы (журнал Six Sigma Forum) В этой статье исследуется идея о том, что для успеха проекта шести сигм по бережливому производству члены команды и другие лица, участвующие в процессе, должны проявлять бдительность в отношении положительных отзывов, когда наблюдается похвальное поведение.

Интернет-трансляции

Lean Six Sigma в эпоху искусственного интеллекта Майкл Л. Джордж старший, генеральный директор AI Technologies, на примерах из практики производства и тематическом исследовании объясняет, что такое ИИ, почему он важен для анализа больших данных и проливает свет на Темные данные, а также то, как их можно применить к программе «бережливое производство + шесть сигм» и усилиям по постоянному совершенствованию, чтобы дать вам существенное конкурентное преимущество.

Веб-трансляция обзора Lean & Six Sigma Новый редактор, д-р Джами Ковач, расскажет нам о новом обзоре Lean & Six Sigma, выделив новые столбцы, функции, ответы на часто задаваемые вопросы и актуальные темы.

Сертификаты "Шесть сигм"

Проекты «Шесть сигм» могут принести пользу, в том числе повысить организационную эффективность, повысить удовлетворенность клиентов, сократить расходы, увеличить доходы и многое другое. В Справочнике сертифицированных «черных поясов по шести сигмам» сообщается, что многие «черные пояса по шести сигмам» «управляют четырьмя проектами в год на общую сумму от 500 000 до 5 000 000 долларов США, внося свой вклад в прибыль компании".

Сертификат «Черный пояс шести сигм» (CSSBB)

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

Сертифицированный зеленый пояс шести сигм (CSSGB)

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

Сертифицированный желтый пояс шести сигм (CSSYB)

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

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

Вот почему команды разработчиков используют инструменты статического анализа. Здесь мы обсудим статический анализ и преимущества использования инструмента статического анализа кода.

Прочитайте или перейдите к разделу, который вас больше всего интересует:

Что такое статический анализ?
Что такое статический анализ кода?
На каком этапе выполняется статический анализ кода?
Каковы преимущества инструментов статического анализа?
Как выбрать инструмент статического анализа кода?

Что такое статический анализ?

Статический анализ лучше всего описать как метод отладки путем автоматической проверки исходного кода перед запуском программы.

Что такое статический анализ кода?

Статический анализ кода — это метод отладки путем изучения исходного кода перед запуском программы. Это делается путем анализа набора кода на соответствие набору (или нескольким наборам) правил кодирования.

Статический анализ кода и статический анализ часто используются взаимозаменяемо вместе с анализом исходного кода.

Этот тип анализа устраняет слабые места в исходном коде, которые могут привести к уязвимостям.Конечно, это также может быть достигнуто путем ручной проверки кода. Но гораздо эффективнее использовать автоматизированные инструменты.

Статический анализ обычно используется для соблюдения рекомендаций по кодированию, таких как MISRA. И часто используется для обеспечения соответствия отраслевым стандартам, таким как ISO 26262.

📕 Ресурс по теме: Как работает статический анализ кода для обеспечения высокого качества, безопасности и надежности кода.

На каком этапе выполняется статический анализ кода?

Статический анализ кода выполняется на ранней стадии разработки, до начала тестирования программного обеспечения. Для организаций, практикующих DevOps, статический анализ кода выполняется на этапе «Создание».

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

Статический анализ и динамический анализ

Итак, в чем разница между статическим и динамическим анализом?

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

Статический анализ выявляет дефекты перед запуском программы (например, между кодированием и модульным тестированием).

Динамический анализ кода выявляет дефекты после запуска программы (например, во время модульного тестирования). Однако некоторые ошибки кодирования могут не проявляться во время модульного тестирования. Таким образом, есть дефекты, которые могут быть упущены при динамическом тестировании, но могут быть обнаружены при статическом анализе кода.

Каковы ограничения инструмента статического анализа кода?

Статический анализ кода используется для определенной цели на определенном этапе разработки. Но у инструмента статического анализа кода есть некоторые ограничения.

Нет понимания намерений разработчика

Инструмент статического анализа может обнаружить возможное переполнение в этом расчете. Но он не может определить, что функция принципиально не делает то, что ожидается!

Правила, которые не применяются статически

Некоторые правила кодирования зависят от внешней документации. Или они открыты для субъективной интерпретации.

CERT-C MSC04:

Используйте комментарии последовательно и в удобочитаемой форме.

Возможные дефекты приводят к ложноположительным и ложноотрицательным результатам

В некоторых случаях инструмент может сообщить только о возможном дефекте.

Если мы ничего не знаем о foo(), мы не знаем, какое значение будет иметь x.

Результат неразрешим. Это означает, что инструменты могут сообщать о дефектах, которых на самом деле не существует (ложные срабатывания). Или они могут не сообщить о реальных дефектах (ложноотрицательные результаты).

Каковы преимущества инструментов статического анализа?

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

Лучшие инструменты статического анализа кода отличаются скоростью, глубиной и точностью.

Скорость

Разработчикам требуется время для ручной проверки кода. Автоматизированные инструменты работают намного быстрее.

Статическая проверка кода устраняет проблемы на раннем этапе. И он точно указывает, где ошибка в коде. Таким образом, вы сможете исправить эти ошибки быстрее. Кроме того, ошибки кодирования, обнаруженные ранее, устраняются с меньшими затратами.

Глубина

Тестирование не может охватить все возможные пути выполнения кода. Но статический анализатор кода может.

Он проверяет код во время работы над сборкой. Вы получите подробный анализ того, где в вашем коде могут быть потенциальные проблемы, на основе примененных вами правил.

Вот пример углубленного анализа кода в Helix QAC.

Точность

Проверка кода вручную чревата человеческими ошибками. Автоматизированные инструменты — нет.

Они сканируют каждую строку кода, чтобы выявить потенциальные проблемы. Это поможет вам убедиться, что код самого высокого качества уже готов — до начала тестирования. В конце концов, когда вы соблюдаете стандарт кодирования, качество имеет решающее значение.

Как выбрать инструмент статического анализа кода?

Вот несколько моментов, которые следует учитывать при выборе подходящего инструмента.

Язык программирования

Анализаторы предназначены для многих языков программирования. Поэтому важно выбрать инструмент, который поддерживает ваш язык.

Стандарты

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

Советы по выбору инструмента статического анализа

Хотите получить дополнительные советы по выбору инструмента статического анализа кода? "Как выбрать лучший анализатор статического кода" охватывает:

Преимущества и проблемы статического анализа кода.
Рекомендации по его использованию.
6 требований для выбора правильного инструмента.

📕 Связанный информационный документ: узнайте, как правильно выбрать инструмент статического анализа кода для вашей команды.

Почему стоит выбрать инструмент статического анализа кода Perforce?

Узнайте на собственном опыте, как инструмент статического анализа кода Perforce может повлиять на качество вашего программного обеспечения. Подпишитесь на бесплатную пробную версию сегодня.

Ричард Беллерс

Менеджер по маркетингу продуктов, Perforce

Ричард Беллерс имеет более чем 20-летний опыт работы в самых разных отраслях. В 90-е и начале 2000-х он занимал должности в области разработки электроники и программного обеспечения в производственной, оборонной, испытательной и измерительной отраслях, прежде чем перейти к управлению продуктами и маркетингу продуктов. Сейчас он поддерживает ведущее на рынке решение Perforce для управления качеством кода. Ричард имеет степень бакалавра в области электронной техники, полученную в Шеффилдском университете, и профессиональный диплом в области маркетинга, полученный в Чартерном институте маркетинга (CIM).

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

Чтобы ускорить и упростить обнаружение и приоритизацию дефектов, я рекомендую применять к ним строгие методы классификации. Ниже я описал подход, который мы применяем в ScienceSoft к классификации программных ошибок, и перечислил наиболее распространенные типы ошибок, сопровождая их примерами.

Три общие классификации программных ошибок

Я выделяю три классификации программных ошибок: по характеру, по приоритету и по серьезности. Хотя классификаторы для последних двух присутствуют в системах отслеживания ошибок по умолчанию, я рекомендую также настроить классификатор для разделения ошибок по их характеру, поскольку это помогает упростить назначение задач по исправлению ошибок ответственным командам.

Программные дефекты по своей природе

Функциональные дефекты

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

Дефекты производительности

Дефекты производительности связаны со скоростью, стабильностью, временем отклика и потреблением ресурсов программного обеспечения и обнаруживаются во время тестирования производительности. Пример дефекта производительности — время отклика системы в Х раз больше заявленного в требованиях.

Дефекты удобства использования

Дефекты юзабилити делают приложение неудобным в использовании и, таким образом, затрудняют работу пользователя с программным обеспечением. Макет контента, который сложно просматривать или перемещать, а также слишком сложная процедура регистрации являются примерами дефектов юзабилити. Чтобы выявить такие дефекты, инженеры-испытатели и бизнес-аналитики (или дизайнеры UX) компании ScienceSoft проверяют программное обеспечение на соответствие требованиям удобства использования и Руководству по доступности веб-контента (WCAG) во время тестирования удобства использования.

Дефекты совместимости

Приложение с ошибками совместимости не показывает стабильной производительности на определенных типах оборудования, операционных систем, браузеров и устройств, а также при интеграции с определенным программным обеспечением или работе в определенных сетевых конфигурациях. Тестирование совместимости проводится для обнаружения таких проблем. Например, тестируя мобильное приложение для оценки возмещения по автострахованию, мы обнаружили, что оно не соответствует требованиям на Android 8.0 и 8.1. Дефекты были связаны с изменениями размера шрифта, выравнивания содержимого и полосы прокрутки.

Дефекты безопасности

Мой коллега Владислав Мурашко, консультант по тестированию на проникновение и сертифицированный этичный хакер, говорит: «Дефекты безопасности — это слабые места, позволяющие совершить потенциальную атаку безопасности. Наиболее частые дефекты безопасности в проектах, для которых мы проводим тестирование безопасности, — это ошибки шифрования, уязвимость к SQL-инъекциям, XSS-уязвимости, переполнение буфера, слабая аутентификация и логические ошибки в ролевом доступе».

Консультанты ScienceSoft по контролю качества помогут вам определить критерии анализа дефектов, оптимальные для вашего проекта, и выполнить классификацию дефектов.

Дефекты программного обеспечения по серьезности

В ScienceSoft мы классифицируем дефекты по серьезности на основе технического воздействия дефекта на систему и выделяем следующие уровни серьезности:

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

Дефекты программного обеспечения по приоритету

Приоритет дефекта характеризует влияние ошибки на бизнес. В проектах ScienceSoft руководитель проекта, владелец продукта или любое заинтересованное лицо определяет приоритет дефекта. Мы выделяем следующие уровни приоритета:

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

Почему так важна правильная классификация дефектов?

Изучив основы классификации дефектов, вы не только убедитесь, что обработка дефектов возложена на ответственные проектные группы, но и упростите приоритизацию дефектов. Это, в свою очередь, ускоряет устранение дефектов и повышает общую эффективность процессов тестирования и разработки.

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

Консалтинг по контролю качества от ScienceSoft

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

При обнаружении дефектов на производстве можно использовать машинное обучение (ML) и компьютерное зрение (CV), чтобы сократить эксплуатационные расходы, сократить время выхода на рынок и повысить производительность, качество и безопасность. По данным McKinsey, «по оценкам, преимущества обнаружения дефектов и других приложений Индустрии 4.0 создадут потенциальную ценность в 3,7 триллиона долларов в 2025 году для производителей и поставщиков». Визуальный контроль качества обычно используется для мониторинга производственных процессов либо с помощью человеческого контроля, либо с помощью систем машинного зрения на основе эвристики. Автоматизированный визуальный осмотр и обнаружение неисправностей с использованием искусственного интеллекта (ИИ) для расширенного распознавания изображений могут повысить производительность на 50 % и повысить скорость обнаружения дефектов до 90 % по сравнению с осмотром человеком.

Дискретные производственные процессы производят большое количество продукции с малой задержкой, от миллисекунд до нескольких секунд.Чтобы выявлять дефекты при той же производительности, потоки изображений с камер также должны обрабатываться с малой задержкой. Кроме того, фабрики могут иметь низкую пропускную способность сети или прерывистое подключение к облаку. В таких случаях вы можете предпочесть запустить систему обнаружения дефектов в локальной вычислительной инфраструктуре и загрузить обработанные результаты для дальнейшей разработки и мониторинга в облако AWS. Этот гибридный подход с использованием как локального периферийного оборудования, так и облака может удовлетворить требования к низкой задержке, а также помочь снизить затраты на хранение и передачу данных по сети в облако. Для некоторых клиентов это также может соответствовать требованиям конфиденциальности данных и другим нормативным требованиям.

В этом посте мы покажем вам, как с помощью Amazon SageMaker создать решение «от облака до периферии» для обнаружения дефектных деталей в потоке изображений, отправляемых на периферийное устройство в режиме реального времени.

Amazon Lookout for Vision – это служба машинного обучения, которая помогает выявлять дефекты продукции с помощью компьютерного зрения, чтобы автоматизировать процесс контроля качества на производственных линиях, не требуя специальных знаний в области машинного обучения. Вы можете начать работу всего с 30 изображениями продуктов (20 обычных и 10 аномальных), чтобы обучить свою модель классификации изображений и выполнить вывод в облаке AWS.

Однако, если вы хотите обучить или развернуть собственную архитектуру модели и выполнить вывод на периферии, вы можете использовать Amazon SageMaker. SageMaker позволяет специалистам по машинному обучению создавать, обучать, оптимизировать, развертывать и отслеживать высококачественные модели, предоставляя широкий набор специально разработанных возможностей машинного обучения. Полностью управляемая услуга берет на себя тяжелую работу с недифференцированной инфраструктурой, связанную с проектами машинного обучения. Вы можете построить жизненный цикл от облака до периферии, о котором мы говорили, с помощью компонентов SageMaker, включая SageMaker Training, SageMaker Pipelines и SageMaker Edge.

Пограничные устройства могут варьироваться от локальных локальных виртуализированных аппаратных средств Intel x86-64 до небольших мощных компьютеров, таких как Nvidia Jetson Xavier, или обычных аппаратных средств с ограниченными ресурсами. Вы также можете рассмотреть AWS Panorama Appliance, аппаратное устройство, установленное в сети клиента, которое взаимодействует с существующими промышленными камерами с меньшими возможностями для запуска моделей компьютерного зрения в нескольких одновременных видеопотоках.

В этом посте мы используем общедоступный набор данных о деталях с дефектами поверхности и строим CV-модели, чтобы идентифицировать детали как дефектные или нет, а также локализовать дефекты в определенной области изображения. Мы создаем автоматизированный конвейер в облаке AWS с помощью SageMaker Pipelines для предварительной обработки набора данных, а также обучения и компиляции модели классификации изображений и семантической сегментации из двух разных сред: Apache MXNet и TensorFlow. Затем мы используем SageMaker Edge для создания парка периферийных устройств, устанавливаем агент на каждое устройство, подготавливаем скомпилированные модели для устройства, загружаем модель с агентом, запускаем вывод на устройстве и синхронизируем полученные данные обратно в облако. Наконец, мы демонстрируем пользовательское приложение, которое выполняет вывод на пограничном устройстве, и делимся тестами задержки для двух разных устройств: виртуальных машин с ЦП Intel X86-64 и NVIDIA Jetson Nano с графическим процессором NVIDIA Maxwell.

Код этого примера доступен на GitHub.

Методология

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

Изображения, созданные для контролируемого машинного обучения, должны включать примеры как дефектных, так и исправных продуктов. Дефектные изображения далее подвергаются выборке с помощью методов увеличения данных, чтобы уменьшить дисбаланс классов. Эти изображения затем аннотируются с помощью инструментов маркировки изображений, чтобы включать метаданные, такие как классы дефектов, ограничивающие рамки и маски сегментации. Запускается автоматизированный рабочий процесс построения модели, включающий последовательность шагов, включая увеличение данных, обучение модели и постобработку. Этапы постобработки включают компиляцию модели, оптимизацию и упаковку для развертывания в целевой пограничной среде выполнения. Сборка и развертывание модели автоматизированы с помощью инструментов непрерывной интеграции и непрерывной доставки (CI/CD), которые запускают переобучение модели в облаке и обновления по беспроводной сети (OTA) на периферии.

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

На следующей диаграмме показана эта архитектура.

Далее мы опишем пример жизненного цикла от облака до периферии для обнаружения дефектов с помощью SageMaker.

Набор данных и вариант использования

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

В этом примере мы используем набор данных KolektorSDD2, который состоит примерно из 3335 изображений поверхностей с дефектами и без них и соответствующих им масок истинности. Примеры таких дефектов в этом наборе данных показаны на следующем изображении. Разрешение на использование этого набора данных предоставлено Kolektor Group, которая предоставила изображения и аннотировала их.

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

Модели

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

Классификация изображений. Мы используем встроенный алгоритм SageMaker для классификации изображений, который поможет вам быстро приступить к обучению модели классификатора изображений. Нам просто нужно предоставить необходимые гиперпараметры и изображения для обучения и проверки.
Семантическая сегментация. Мы используем модель семантической сегментации для обнаружения масок дефектов на основе архитектуры нейронной сети U-Net с оценщиком платформы TensorFlow, представленным в SageMaker SDK.

Обзор решения

Решение, которое мы описали в этом посте, доступно в виде семинара на GitHub. Подробные сведения о реализации см. в коде и документации в репозитории.

Архитектура этого решения показана на следующем изображении. Его можно разбить на три основные части:

Разработка и автоматизированное обучение различных версий и типов моделей в облаке.
Подготовка артефактов модели и автоматическое развертывание на пограничном устройстве.
Инференс на границе для интеграции с бизнес-приложением. В этом случае мы показываем прогнозы в простом веб-интерфейсе.

Разработка моделей и автоматизированное обучение

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

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

Развертывание модели на периферии

Предпосылкой для развертывания модели на периферии является соответствующая настройка граничного устройства.Мы устанавливаем агент SageMaker Edge и приложение для развертывания и управления жизненным циклом моделей на устройстве. Мы предоставляем простой сценарий установки для ручной загрузки пограничного устройства.

Этот этап включает подготовку артефакта модели и его развертывание на периферии. Он состоит из трех шагов:

Скомпилируйте модель с помощью SageMaker Neo.
Упакуйте модель с помощью SageMaker Edge.
Создайте AWS IoT Corejob, чтобы дать указание пограничному приложению загрузить пакет модели.

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

Вы можете легко автоматизировать эти шаги, например, используя рабочий процесс AWS Step Functions и программно вызывая соответствующие API для SageMaker Edge и AWS IoT. Вы также можете использовать события Amazon EventBridge, инициированные действием утверждения в реестре моделей, и автоматизировать построение и развертывание модели на пограничном устройстве. Кроме того, SageMaker Edge интегрируется с AWS IoT Greengrass V2, чтобы упростить доступ, обслуживание и развертывание агента и модели SageMaker Edge на ваших устройствах. В этом контексте вы также можете использовать AWS IoT Greengrass V2 для управления устройствами.

Вывод на грани

Пограничное устройство запускает приложение для обнаружения дефектов с локальным выводом машинного обучения. Мы создаем простое веб-приложение, которое запускается локально на пограничном устройстве и показывает результаты логического вывода в реальном времени для входящих изображений. Кроме того, приложение предоставляет дополнительную информацию о моделях и их версиях, загруженных в настоящее время в SageMaker Edge Agent.

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

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

Важно отслеживать производительность моделей, развернутых на периферии, чтобы обнаруживать отклонения в точности моделей. Вы можете синхронизировать данные постобработки и прогнозы с облаком для целей отслеживания и переобучения модели. Агент SageMaker Edge предоставляет API для синхронизации захваченных данных с Amazon Simple Storage Service (Amazon S3). В этом примере мы можем инициировать переобучение модели с помощью конвейеров автоматизированного обучения и развертывать новые версии модели на пограничном устройстве.

Результаты задержки вывода

Мы можем использовать SageMaker Edge для выполнения логических выводов на самых разных периферийных устройствах. На момент написания этой статьи они включают подмножество устройств, архитектур микросхем и систем, которые поддерживаются в качестве целей компиляции с Neo. Мы также провели тесты на двух разных периферийных устройствах: виртуальных машинах с ЦП Intel X86-64 и NVIDIA Jetson Nano с графическим процессором NVIDIA Maxwell. Мы измерили сквозную задержку, которая включает время, затраченное на отправку входных полезных данных агенту SageMaker Edge из приложения, задержку вывода модели со средой выполнения SageMaker Edge Agent и время, затраченное на отправку выходных полезных данных обратно в приложение. . Это время не включает предварительную обработку, которая выполняется в приложении. В следующей таблице приведены результаты для двух типов устройств и двух типов моделей с полезной нагрузкой входного изображения размером 400 КБ.

Заключение

В этом посте мы описали типичный сценарий обнаружения промышленных дефектов на периферии с помощью SageMaker.Мы рассмотрели ключевые компоненты жизненного цикла облака и периферии на сквозном примере с набором данных KolektorSDD2 и моделями компьютерного зрения из двух разных сред (Apache MXNet и TensorFlow). Мы решили основные проблемы, связанные с управлением несколькими моделями машинного обучения на множестве периферийных устройств, компиляцией моделей, чтобы исключить необходимость установки отдельных платформ, и инициированием логического вывода модели с малой задержкой из периферийного приложения через простой API.

Вы можете использовать Pipelines для автоматизации обучения в облаке, SageMaker Edge для подготовки моделей и агента устройства, задания AWS IoT для развертывания моделей на устройстве и SageMaker Edge для безопасного управления и мониторинга моделей на устройстве. С помощью вывода машинного обучения на периферии вы можете сократить расходы на хранение и передачу данных по сети в облако, выполнить требования к конфиденциальности данных и создать системы управления с малой задержкой и периодическим подключением к облаку.

После успешного внедрения решения для одной фабрики вы можете масштабировать его на несколько фабрик в разных местах с централизованным управлением в облаке AWS.

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

Об авторах

Дэвид Лихтенвальтер (David Lichtenwalter) — младший архитектор решений в AWS, базирующийся в Мюнхене, Германия. Дэвид работает с клиентами из немецкой производственной отрасли, чтобы предоставить им передовой опыт в их переходе к облаку. Он увлечен машинным обучением и тем, как его можно использовать для решения сложных отраслевых задач.

Хасан Пунавала (Hasan Poonawala) — старший архитектор решений AI/ML в AWS, базирующийся в Лондоне, Великобритания. Хасан помогает клиентам разрабатывать и развертывать приложения машинного обучения в рабочей среде на AWS. Он имеет более чем 12-летний опыт работы в качестве специалиста по данным, специалиста по машинному обучению и разработчика программного обеспечения. В свободное время Хасан любит исследовать природу и проводить время с друзьями и семьей.

Самир Араужо — архитектор решений AI/ML в AWS. Он помогает клиентам создавать решения AI/ML, которые решают их бизнес-задачи с помощью AWS. Он работал над несколькими проектами AI/ML, связанными с компьютерным зрением, обработкой естественного языка, прогнозированием, ML на периферии и многим другим. В свободное время он любит играть с аппаратным обеспечением и проектами автоматизации, а также особенно интересуется робототехникой.

Читайте также: