2.2. Структурные правила для моделей процессов (Structurerulesforprocessmodels): Каждый путь должен начинаться и заканчиваться событием или интерфейсом в другой процесс (Each path must begin and end with an event); Проверка корректности количества входящих и исходящих соединений логических операторов (NumberofOutgoingandincomingConnectionsattheoperator); Все функции и события должны иметь только одно входящее и одно исходящее соединения (Allfunctions/eventshaveonlyoneincoming/outgoingconnection); Невозможность XOR/OR после события (NoXOR/ORPossibleafterEvent); Порядок у операторов должен быть сохранен (SequenceattheOperatorNeedsToBeFollowed).
2.3. Специальные структурные правила для иерархических моделей для моделей Дерево функций и Организационной диаграммы: Возможен только один корень (Only one root possible); Каждый объект может иметь только одного родителя (Each object may have only one direct predecessor); Разрешено только одно соединение между двумя объектами (Only one connection is allowed between two object); Все исходящие соединения объекта должны иметь один и тот же тип (All outgoing connections of an object must be of the same type); Все соединения в модели должны иметь один и тот же тип (All connections in a model must be of the same type).
После проведения семантической проверки те модели, в которых выявлены ошибки, исправить, и в курсовом проекте показать модели до и после исправления, а также вставить отчет SemanticReport. Для этого построить модели, которые содержат одну или несколько ошибок в структуре.
3. Проверить модели на адекватность, ответив на вопросы по вашим моделям:
3.1 Есть ли выходы (документы, файлы, продукция) в моделях процессов, которые не используются другими функциями в этом же процессе;
3.2 Есть ли организационные единицы, должности, группы, местоположения и сотрудники в орг. структуре, которые не задействованы в процессах и не выполняют ни одной (или только одну-две) функции. Для этого можно провести семантическую проверку по правилам существования (ExistenceRules) применительно к построенным eEPC и VAD-моделям по правилам – «Организационный элемент из модели процесса существует в организационной модели» (OrganizationalUnitfromeEPCinOrganizationalChart), «Должность из модели процесса существует в организационной модели» (PositionfromeEPCinOrganizationalChart), «Сотрудник из модели процесса существует в организационной модели» (PersonfromeEPCinOrganizationalChart), «Группа из модели процесса существует в организационной модели» (GroupfromeEPCinOrganizationalChart), «Местоположение из модели процесса существует в организационной модели» (LocationfromeEPCinOrganizationalChart).
3.3 Есть ли функции в процессах, исполнитель которой не указан или его трудно определить. Для этого можно запустить скрипт семантической проверки по правилам взаимосвязи объектов для eEPC (AllocationRulesforeEPC): Функции выполняются организационной единицей (Functionisexecutedbyorganizationalunit), Функции выполняются должностью (Functionisexecutedbyposition), а также не указан потребляемый ресурс;
3.4 Есть ли не автоматизированные функции (т.е. выполняемые вручную или технический ресурс не указан),
3.5 Есть ли в процессах информационные и организационные разрывы. Для этого можно воспользоваться встроенными скриптами ARISAnalysis.Работа с модулем ARISAnalysis описана в ПЗ_16, перечень скриптов и примеры их применения приведены в файле «Обзор стандартных скриптов анализа ПС ARIS 5.0 (6.0)»;
3.6 Есть ли руководители в организационных диаграммах, у которых в подчинении менее 3-х человек или, наоборот, более 5-6 подразделений;
3.7 Есть ли функции, дублирующие друг друга (или функции со схожими названиями), но выполняемые различными лицами в различных процессах. Для этого можно запустить модуль ARISConsolidation для определения наличия в БД объектов с одинаковыми названиями (Работа с ARISConsolidation описана в ПЗ_11);
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.