Определение контекста

Контекст – наиболее абстрактный уровень описания системы в целом, в который входит определение области моделирования (Scope). Определение области моделирования подразумевает описание:

· субъекта моделирования (субъект – сама система), в процессе описания которого устанавливается:

ü что входит в систему (является ее компонентами),

ü что лежит за ее пределами (является внешним воздействием).

· цели моделирования (Purpose – закладка Purpose меню Edit/Model Properties), которая должна отвечать на следующие вопросы:

ü почему этот процесс должен быть замоделирован?

ü Что должна показывать модель?

ü Что может получить читатель?

Примеры: а) «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений»,

б) Идентифицировать роли и ответственность служащих для написания должностных инструкций,

в) описать функциональность предприятия с целью написания спецификаций ИС и т.д.

· точки зрения (Viewpoint - закладка Purpose меню Edit/Model Properties) на модель.

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

· Источников информации для построения модели (Source)

Пример: «Опрос экспертов предметной области и анализ документации».

· Статуса модели: черновой вариант, рабочий, окончательный и т.д.

· Временных рамок (AS-IS или TO-BE)

Вначале создается модель, на которой можно определить слабые места предприятия, например бесполезные, дублирующие и неуправляемые работы, неэффективный документооборот (нет нужных документов на нужном месте в нужное время), отсутствие обратной связи по управлению (нет результата) или по входу (информация используется нерационально).

AS-IS - «что мы делаем сегодня», перед тем как перепрыгнуть на то, «что мы будем делать завтра». Неверно, если создается идеализированная модель (например, на основе знаний руководителя, а не конкретного исполнителя), такая модель называется SHOULD BE (как должно бы быть).

После анализа модели AS-IS и улучшения бизнес-процессов, создается модель TO-BE, и только на основе модели TO-BE строится впоследствии модель данных, прототип, а затем окончательный вариант ИС