Функциональная модель системы

В рамках методологии SADT было разработано несколько графических языков функционального моделирования систем под общей аббревиатурой IDEF (Integration Definition for Function Modeling). Из них наибольшее распространение получили нотации IDEF0 и IDEF3.

На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать, каков состав функциональных подсистем разрабатываемой или модернизируемой системы и как они могут взаимодействовать между собой. Для описания работы системы необходимо построить ее модель, дающую адекватное отображение предметной области и всех участников бизнес-процессов организации. Наиболее удобным языком моделирования в подобных ситуациях является нотация IDEF0. Под моделью в IDEF0 понимается описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее поставленные вопросы. При этом технология IDEF0 реализует методологию функционального описания систем в целом как множество взаимозависимых действий или функций. Важно подчеркнуть именно функциональную направленность IDEF0 – функции системы исследуются независимо от объектов, которые обеспечивают их выполнение. Это позволяет четко отделить целевые аспекты системы и подсистем от аспектов технической и физической реализации. Поэтому данная нотация в основном применяется для описания систем на ранних стадиях проектирования.

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

Моделирование какой-либо системы в IDEF0 начинается с определения контекста, т. е. наиболее абстрактного (по сути концептуального) уровня описания системы в целом. Он предполагает задание субъекта моделирования, целей моделирования и точки зрения на модель. Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами. Другими словами, мы должны определить, что в дальнейшем будет рассматриваться как компоненты системы, а что – как внешняя среда. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, а также цель моделирования – вопросы, на которые разрабатываемая модель должна дать ответ.

Первоначально необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. При формулировании области необходимо учитывать 2 компонента – широту и глубину. Широта подразумевает определение границ модели: мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени – трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.

Модель не может быть построена без четко сформулированной цели (Purpose). Цель должна отвечать на следующие вопросы: почему этот процесс должен быть исследован и что должна показывать модель? Формулировка цели позволяет аналитикам сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: «Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений», «Описать функциональность предприятия с целью определения спецификаций информационной системы» и т. д.

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будут выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за разработку модели работу в целом. При выборе точки зрения на модель важно иногда документировать дополнительные альтернативные точки зрения. Для этого обычно используют специальные диаграммы для экспозиции (For Exposition Only).

Итак, модель, полученная с использованием IDEF0, предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения.

Важным также является разделение модели «AS-IS» и модели «ТО-ВЕ». Обычно сначала строится модель существующей системы – AS-IS (как есть). Анализ такой функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаками неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот, отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-BE (как будет) – модели новой системы или организации бизнес-процессов. Модель ТО-BE нужна для анализа альтернативных/лучших путей выполнения работы и документирования того, как будет построена работа организации в будущем. Следует указать на распространенную ошибку при создании модели AS-IS – это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям и часто не знает, как на самом деле реально выполняются работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD BE (как должно бы быть).

Таким образом, технология моделирования и проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и разработку предложений по модернизации всей системы в целом и ее отдельных бизнес-процессов, отображаемых в модели ТО-ВЕ. Далее только на основе модели ТО-ВЕ строятся модели данных, прототипы и затем окончательный вариант ИС.