Практика и проблематика моделирования бизнес-процессов - стр. 36

♦ IDEF5 (Ontology Description Capture Method) – стандарт наглядного и эффективного описания онтологии системы: словаря терминов и определений, используемых при описании характеристик объектов и процессов, имеющих отношение к рассматриваемой системе, и классификации логических взаимосвязей между ними.

♦ IDEF6 (Designed Rational Capture Method) – назначение стандарта состоит в структурировании «знаний о способе» моделирования, их представления и использования при разработке информационных систем. Под «знаниями о способе» понимаются причины, обстоятельства, другие мотивы, которые обусловливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель выглядит таким образом?». Стандарт IDEF6 акцентирует внимание именно на процессе создания модели.

♦ IDEF8 (Human-System Interaction Design) – стандарт описания интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем) и на деталях интерфейса (какие элементы управления предлагает интерфейс для выполнения операции).

♦ IDEF9 (Business Constraint Discovery) – стандарт описания бизнес-ограничений, используется при определении и анализе ограничений, в которых действует организация.

♦ IDEF14 (Network Design) – стандарт проектирования компьютерных сетей, основанный на анализе требований, специфических сетевых компонентов, существующих конфигураций сетей. Также он обеспечивает поддержку решений, связанных с рациональным управлением материальными ресурсами, что позволяет достичь существенной экономии.

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