5. Без внятного ТЗ результат... не очень
Последняя ошибка -- самая сложная. Эту ошибку трудно заметить и исправить. Состоит она в том, что руководство не понимает, зачем предприятию внедрять процессы безопасности.
Причины внедрения процессов безопасности у каждого свои: «отстройка» от конкурентов, выполнение обязательных требований заказчика или закона, стремление соответствовать современному уровню техники, и др. Важно осознать эту причину и действовать так, чтобы прийти к поставленной цели, а не «обеспечить» абстрактную «безопасность».
Проиллюстрируем взаимосвязь между целями и «фокусом» работ на примерах:
· Цель – скорейшая сертификация: важен четкий процесс и «красота» документации;
· Цель – улучшить конструкцию: уделим максимум влияния процессам анализа безопасности (FMEA, FTA, ETA и др. аббр.);
· Цель – прохождение аудита у заказчика: в первую очередь узнаем, на что важно конкретному заказчику;
· Цель – создать гибкие процессы, которые будут развиваться и расширяться, в т.ч. в другие области техники: максимум инвестиций в тренинги, и т.п.
Все это -- отличные пути, ведущие в разные места. Чтобы выбрать между ними, нужно понять, куда нужно двигаться.
Последняя ошибка -- самая сложная. Эту ошибку трудно заметить и исправить. Состоит она в том, что руководство не понимает, зачем предприятию внедрять процессы безопасности.
Причины внедрения процессов безопасности у каждого свои: «отстройка» от конкурентов, выполнение обязательных требований заказчика или закона, стремление соответствовать современному уровню техники, и др. Важно осознать эту причину и действовать так, чтобы прийти к поставленной цели, а не «обеспечить» абстрактную «безопасность».
Проиллюстрируем взаимосвязь между целями и «фокусом» работ на примерах:
· Цель – скорейшая сертификация: важен четкий процесс и «красота» документации;
· Цель – улучшить конструкцию: уделим максимум влияния процессам анализа безопасности (FMEA, FTA, ETA и др. аббр.);
· Цель – прохождение аудита у заказчика: в первую очередь узнаем, на что важно конкретному заказчику;
· Цель – создать гибкие процессы, которые будут развиваться и расширяться, в т.ч. в другие области техники: максимум инвестиций в тренинги, и т.п.
Все это -- отличные пути, ведущие в разные места. Чтобы выбрать между ними, нужно понять, куда нужно двигаться.
Коротко о шагах процесса:
• Постановка задачи: выясняем, какая именно безопасность нам требуется, по каким стандартам, и зачем.
• Проведение гэп-анализа: определяем несоответствие (гэп) между теми процессами разработки, что есть, и теми, что требуют стандарты
• Планирование: рассматриваем найденные несоответствия, планируем их устранение
• Тренинги: при необходимости обучаем сотрудников
• Процессы безопасности (черновик): фиксируем наши идеи о том, как мы будем выполнять требования стандартов, в процессной документации
• Пилотный проект: проводим пилотный проект, чтобы проверить наши идеи на практике. Там, где идеи не проходят проверку, исправляем процессную документацию
• Внедрение процессов: обеспечиваем сотрудников актуальной процессной документацией и средствами для работы
Роль SafetyConsult
SafetyConsult поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.
• Постановка задачи: выясняем, какая именно безопасность нам требуется, по каким стандартам, и зачем.
• Проведение гэп-анализа: определяем несоответствие (гэп) между теми процессами разработки, что есть, и теми, что требуют стандарты
• Планирование: рассматриваем найденные несоответствия, планируем их устранение
• Тренинги: при необходимости обучаем сотрудников
• Процессы безопасности (черновик): фиксируем наши идеи о том, как мы будем выполнять требования стандартов, в процессной документации
• Пилотный проект: проводим пилотный проект, чтобы проверить наши идеи на практике. Там, где идеи не проходят проверку, исправляем процессную документацию
• Внедрение процессов: обеспечиваем сотрудников актуальной процессной документацией и средствами для работы
Роль SafetyConsult
SafetyConsult поможет на всех этапах процесса. У нас есть готовые тренинги, шаблоны, процессные документы и многое другое – это сэкономит время. На этапе «постановка задачи» проконсультируем бесплатно.
⚡Новости SafetyConsult ⚡
Многие иностранные компании ушли с российского рынка после введения санкций. Кроме Zara и IKEA это сделали и компании-сертификаторы.
SafetyConsult начинает сотрудничество с двумя сертификационными компаниями из Китая.
* Сертификация компетенций, продуктов, систем менеджмента.
* Наши партнёры аккредитованы в Китае и Германии.
* Язык общения -- английский; аудит -- по месту пребывания заказчика.
Многие иностранные компании ушли с российского рынка после введения санкций. Кроме Zara и IKEA это сделали и компании-сертификаторы.
SafetyConsult начинает сотрудничество с двумя сертификационными компаниями из Китая.
* Сертификация компетенций, продуктов, систем менеджмента.
* Наши партнёры аккредитованы в Китае и Германии.
* Язык общения -- английский; аудит -- по месту пребывания заказчика.
Мы продолжаем рассказывать вам о разных аспектах безопасности даже в выходные. Stay tuned!
SafetyConsult: Инженерия безопасности pinned «Зачем вы читаете этот канал?»
Обмен информацией для безопасной разработки: что может и что должен предоставить заказчик?
Вряд ли сейчас возможно построить автомобиль, самолёт, даже стиральную машину одной командой. Большинство продуктов появляется на свет в результате распределенной разработки, требования верхнего уровня воплощают совместными усилиями нескольких команд. У требований безопасности здесь две особенности:
· их нужно не только воплотить, но и отследить, и
· на каждом шаге нужно убедиться, что требования безопасности проходят через соответствующие процессы.
Вряд ли сейчас возможно построить автомобиль, самолёт, даже стиральную машину одной командой. Большинство продуктов появляется на свет в результате распределенной разработки, требования верхнего уровня воплощают совместными усилиями нескольких команд. У требований безопасности здесь две особенности:
· их нужно не только воплотить, но и отследить, и
· на каждом шаге нужно убедиться, что требования безопасности проходят через соответствующие процессы.
Разберем пример: компания «А» разрабатывает автомобильное устройство, при этом компания «Б» разрабатывает для этого устройства «железо», а код пишет компания «В». Это делается в интересах компании «К», которая выпускает автомобили.
Компании «Х» и «Y» поставляют «Б» и «В» программные и аппаратные компоненты.
Компании «Х» и «Y» поставляют «Б» и «В» программные и аппаратные компоненты.
Немного о названиях
На практике производителя конечного продукта (в нашем случае – автомобиля) принято называть ОЕМ (сокращение от «Original Equipment Manufacurer», т.е. «производитель оригинального оборудования»); производителя устройств, которые напрямую интегрируется в конечный продукт – «Tier 1» («поставщик первого уровня»), а поставщика специализированных компонентов для интеграции в автомобильные устройства – «Tier 2» («поставщик второго уровня»). Дальше перечисление не идет, обозначения «Tier 3», «Tier 4» и т.п. не приняты.
На практике производителя конечного продукта (в нашем случае – автомобиля) принято называть ОЕМ (сокращение от «Original Equipment Manufacurer», т.е. «производитель оригинального оборудования»); производителя устройств, которые напрямую интегрируется в конечный продукт – «Tier 1» («поставщик первого уровня»), а поставщика специализированных компонентов для интеграции в автомобильные устройства – «Tier 2» («поставщик второго уровня»). Дальше перечисление не идет, обозначения «Tier 3», «Tier 4» и т.п. не приняты.
Процессы безопасной разработки
Прежде чем говорить о требованиях к продукту, разберемся, кто за них отвечает. Чтобы воплощать требования безопасности, нужны подходящие процессы, т.н. «система менеджмента безопасности». Стандарт ИСО 26262-2 описывает жизненный цикл, содержащий функциональный и системный уровень, а также разработку «железа» и ПО. По нашей схеме это охватывает ОЕМ, Tier 1 и Tier 2, то есть компании «К», «А», «Б» и «В». К другим компаниям («X» и «Y») требование о соответствии процессов напрямую не применяется.
Обязанность убедиться в соответствии поставщиков стандартам безопасности лежит на том, кто интегрирует продукт. Это значит, «К» проводит аудит «А», а «А» -- аудит «Б» и «В». На практике аудитом цепочки часто занимается ОЕМ: если продукт нанесет вред конечному пользователю, то отвечать ОЕМ. Компенсацию с поставщиков компонентов запросить можно, если доказать, что вред нанесен по вине поставщика. Но кому нужна возня с юристами -- проще провести аудит и быть спокойным.
Если на «Х» и «Y» не распространяются требования ИСО 26262, не понятно, на чем будет основано наше доверие продуктам этих компаний. Это зависит от того, какую часть устройства они поставляют. Если речь идёт, например, об элементной базе (транзисторах, резисторах и т.п.), достаточно подтверждения системы менеджмента качества (СМК) и тестирования по соответствующему стандарту (например, для элементной базы – по стандартам AECQ). Сложные компоненты (чипы, драйверы и т.п.) интегрируются через процедуру квалификации ПО или оценки компонентов аппаратной части. Об этих процедурах – в следующих постах.
Прежде чем говорить о требованиях к продукту, разберемся, кто за них отвечает. Чтобы воплощать требования безопасности, нужны подходящие процессы, т.н. «система менеджмента безопасности». Стандарт ИСО 26262-2 описывает жизненный цикл, содержащий функциональный и системный уровень, а также разработку «железа» и ПО. По нашей схеме это охватывает ОЕМ, Tier 1 и Tier 2, то есть компании «К», «А», «Б» и «В». К другим компаниям («X» и «Y») требование о соответствии процессов напрямую не применяется.
Обязанность убедиться в соответствии поставщиков стандартам безопасности лежит на том, кто интегрирует продукт. Это значит, «К» проводит аудит «А», а «А» -- аудит «Б» и «В». На практике аудитом цепочки часто занимается ОЕМ: если продукт нанесет вред конечному пользователю, то отвечать ОЕМ. Компенсацию с поставщиков компонентов запросить можно, если доказать, что вред нанесен по вине поставщика. Но кому нужна возня с юристами -- проще провести аудит и быть спокойным.
Если на «Х» и «Y» не распространяются требования ИСО 26262, не понятно, на чем будет основано наше доверие продуктам этих компаний. Это зависит от того, какую часть устройства они поставляют. Если речь идёт, например, об элементной базе (транзисторах, резисторах и т.п.), достаточно подтверждения системы менеджмента качества (СМК) и тестирования по соответствующему стандарту (например, для элементной базы – по стандартам AECQ). Сложные компоненты (чипы, драйверы и т.п.) интегрируются через процедуру квалификации ПО или оценки компонентов аппаратной части. Об этих процедурах – в следующих постах.
Передача системных требований
Независимо от того, участвует в разработке одна команда или больше, по стандартам безопасности нужно дерево требований. Это такая структура, в которой каждое требование связано с требованием верхнего уровня, которое оно воплощает (связь "implement"). Только так можно убедиться, что технические верхних уровней решения воплощены "ниже по течению".
Кроме этого, на каждом уровне проводится анализ безопасности. Анализ проводится по специальному алгоритму чтобы убедиться, что при декомпозиции требований ничего не забыли. В ходе анализа появляются новые требования. Большинство таких требований остаются на том же уровне (например, при анализе ПО появляются требования к ПО), но иногда требования, возникшие при анализе, выставляются на другой уровень (например, при анализе ПО понимаем, что видим недостающее требование системного уровня).
Независимо от того, участвует в разработке одна команда или больше, по стандартам безопасности нужно дерево требований. Это такая структура, в которой каждое требование связано с требованием верхнего уровня, которое оно воплощает (связь "implement"). Только так можно убедиться, что технические верхних уровней решения воплощены "ниже по течению".
Кроме этого, на каждом уровне проводится анализ безопасности. Анализ проводится по специальному алгоритму чтобы убедиться, что при декомпозиции требований ничего не забыли. В ходе анализа появляются новые требования. Большинство таких требований остаются на том же уровне (например, при анализе ПО появляются требования к ПО), но иногда требования, возникшие при анализе, выставляются на другой уровень (например, при анализе ПО понимаем, что видим недостающее требование системного уровня).
При распределенной разработке каждая команда использует свою систему управления требованиями (СУТ). Отслеживание требований в этом случае происходит так: требования в СУТ команды верхнего уровня замораживаются и копируются в СУТ команды нижнего уровня, где изменять их также запрещено. Команда нижнего уровня трассирует «свои» требования к копии требований верхнего уровня в собственной СУТ. Аудиторам такое решение нравится.
Договор о взаимодействии при разработке (DIA)
Чтобы разделить работы жизненном цикле безопасности, заключают договор о взаимодействии при разработке (он же Development Interface Agreement, DIA). Если команды принадлежат к разным предприятиям, имеет смысл включить DIA в юридически обязывающий контракт. Если команды внутри одной компании, формальное подтверждение с подписью и печатью не требуется, но менее важным DIA не становится.
Чтобы разделить работы жизненном цикле безопасности, заключают договор о взаимодействии при разработке (он же Development Interface Agreement, DIA). Если команды принадлежат к разным предприятиям, имеет смысл включить DIA в юридически обязывающий контракт. Если команды внутри одной компании, формальное подтверждение с подписью и печатью не требуется, но менее важным DIA не становится.
DIA это по сути матрица RASIC, то есть таблица, где каждая строка соответствует результату работ из жизненного цикла безопасности, а каждый столбец – участнику работ. Из такой таблицы ясно, кто отвечает за тот или иной результат (R в RASIC), кто поддерживает (S), а кто только получает информацию об исполнении (I).
Роль SafetyConsult
Сотрудники SafetyConsult поддерживают распределенную разработку с 2014 года. Мы предлагаем:
· Аудит поставщиков для заказчика
· Помощь в выстраивании рабочих процессов
· Создание и согласование DIA
· Документацию доказательств безопасности (результат можем сами покажем заказчику)
Сотрудники SafetyConsult поддерживают распределенную разработку с 2014 года. Мы предлагаем:
· Аудит поставщиков для заказчика
· Помощь в выстраивании рабочих процессов
· Создание и согласование DIA
· Документацию доказательств безопасности (результат можем сами покажем заказчику)