ГОСТ Р МЭК 60601-1-6— 2007
- все проекты отчетов на твердых копиях;
- описание ожидаемого взаимодействия ОПЕРАТОРА с дисплеями и элементами управления (например,
какие изменения в элементах управления и дисплеях будут результатом изменений в ИЗДЕЛИИ и действиях
ОПЕРАТОРА).
DDD.4.6.4 Другие полезные средства ПРОЕКТИРОВАНИЯ ЭКСПЛУАТАЦИОННОЙ ПРИГОДНОСТИ
При определении спецификаций проекта ИНТЕРФЕЙСА ОПЕРАТОР — ИЗДЕЛИЕ полезно подготовить сле
дующее;
- диаграмму концептуальной модели, иллюстрирующую высокоуровневую структуру ИНТЕРФЕЙСА ОПЕРА
ТОР — ИЗДЕЛИЕ (см. рисунок DDD.2);
- карту ИНТЕРФЕЙСА ОПЕРАТОР — ИЗДЕЛИЕ (обычно блок-схему), показывающую взаимосвязи между
различными экранами;
- экранный шаблон — характерную для компьютерных экранов схему расположения элементов;
- архивную папку — набор распечаток программного обеспечения экрана, которые могут перекрещиваться
с шаблонами и письменными спецификациями;
- руководство по стилю — набор записанных правил, обеспечивающих согласованность действий с помо
щью управления графическим оформлением экранов и средствами взаимодействия.
DDD.4.7 Оценка проекта
DDD.4.7.1 Общие руководящие указания
Результаты каждого вида деятельности по проектированию следует оценивать на протяжении всего цикла
разработки. Эти виды деятельности повторяющиеся и накопительные; их рекомендуется применять ко всем
видам ИНТЕРФЕЙСОВ ОПЕРАТОР — ИЗДЕЛИЕ (программному обеспечению, аппаратным средствам, докумен
тации и тд.) для всех типов ОПЕРАТОРОВ (специалистов по техническому обслуживанию, монтажников и тд.).
Результатом является рабочая модель, которую следует лодверлчуть заключительной ВАЛИДАЦИИ. Различие
между ВЕРИФИКАЦИЕЙ и ВАЛИДАЦИЕЙ заключается в том. что ВЕРИФИКАЦИЯ гарантирует соответствие конст
рукции проектным требованиям, в то время как ВАЛИДАЦИЯ — ориентацию окончательной рабочей модели на
удовлетворение потребностей предполагаемого ОПЕРАТОРА.
Всесторонняя оценка проекта должна быть завершена до его окончания. Обычно детальной разработке
проекта и кодированию программного обеспечения предшествует давление, направленное на замораживание
проекта. В случае замораживания проекта значительные изменения проекта носят разрушительный характер,
отнимают много времени и являются дорогостоящими. Например, если только не обнаружена серьезная ОПАС
НОСТЬ. изготовителю будет трудно обосновать после заказадорогого оборудования потребность в существенных
изменениях панели управления, таких как реконфигурация или добавление кнопок. Более вероятно, что указан
ный проект останется замороженным и будут выбраны другие возможности, направленные на решение проблем
ЭКСПЛУАТАЦИОННОЙ ПРИГОДНОСТИ, такие как специальная маркировка, комментарии в документации для
ОПЕРАТОРА или дополнительное ОБУЧЕНИЕ. Однако эти идеи часто неэффективны и всегда менее желательны,
чем правильно разработанная первоначальная версия проекта.
DDD.4.7.2 ВЕРИФИКАЦИЯ проекта
Результаты работы и другие наглядные материалы, характеризующие проект, рекомендуется проверять в
соответствии с критериями, вытекающими из требований к проекту. Эти результаты, которые могут представлять
собой чертежи, описания задач, макеты и динамические компьютерные модели, служат для решения задач,
создания архивных папок и эвристических анализов, рассмотрения макетов и проведения испытаний ЭКСПЛУА
ТАЦИОННОЙ ПРИГОДНОСТИ. Идентифицированные при этом возможные ошибки и/или отказы изделия долж ны
быть включены в анализ опасностей.
Без повторной оценки в процессе разработки проекта результаты данной разработки, получаемые мето
дом проб и ошибок, не будут рассмотрены вплоть до ВАЛИДАЦИИ изделия (обсуждаемой в DDD.4.7.3). Недоста
точное внимание к деятельности по ВЕРИФИКАЦИИ может стать очевидным при испытании рабочих моделей и
обнаружиться в виде небезопасных и неэффективных монтажа и функционирования изделия (например, критич
ные ошибки, слабые места конструкции и медленное выполнение задач). Стоимость исправления проблем,
идентифицированных при ВЕРИФИКАЦИИ, будет намного меньше стоимости повторной сборки рабочих
моделей.
По-видимому, даже незначительные изменения проекта могут оказывать существенное влияние на работу
конечного изделия. Любые значительные изменения проекта рекомендуется включать в пересмотренный АНА
ЛИЗ РИСКА для гарантии отсутствия дополнительных ОПАСНОСТЕЙ из-за этих изменений.
Результаты таких оценок часто приводят к усовершенствованию проектных требований и облегчают выра
ботку на основе полученной информации проектных решений по таким вопросам, как:
- распределение функций ОПЕРАТОРОВ, программного обеспечения и аппаратных средств;
- последовательность, взаимосвязанность и интуитивность этапов решения задач, задаваемые аппарат
ными средствами/программным обеспечением ИНТЕРФЕЙСА ОПЕРАТОР — ИЗДЕЛИЕ;
- любые характеристики проекта, принимающие во внимание возможность ошибки или вызывающие ошибку;
- потенциальные ОПАСНОСТИ и альтернативные проектные решения;
- задачи, выполнение которых занимает слишком много времени;
- трудные для понимания или неверно истолковываемые маркировки или отображаемая информация;
- гарантии против ОБОСНОВАННО ПРОГНОЗИРУЕМОГО НЕПРАВИЛЬНОГО ПРИМЕНЕНИЯ.
31