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