Функциональное моделирование хозяйственной деятельности предприятия на примере ООО «Дедал-Сервис»

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

В качестве компьютерного инструмента  ССА используются так называемые CASE-средства¹².

CASE-средства (Computer-Aided Software/Systems Engineering) – комплекс средств автоматизации для анализа, проектирования, разработки и сопровождения сложных систем.

В основе CASE лежат такие понятия  как методология, метод, нотация  и средство.

Методология определяет совокупность методов, правила их использования, а также последовательность шагов выполнения работы.

Метод – процедура или техника описания компонентов объекта исследования, программного обеспечения или ИС.

Нотации предназначены для описания структуры системы, элементов данных, этапов обработки и включает графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки.

Средства – инструментарий для поддержки и усиления методов.

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

Автор методологии, Дуглас Росс, в 1969 г. часть своих теорий, относящихся  к методологии и языку описания систем, назвал «Structured Analysis and Design Technique» (Методология структурного анализа и проектирования). Первое ее крупное приложение было реализовано в 1973 г. при разработке большого аэрокосмического проекта, а на рынке SADT появляется в 1975 г.

Описание системы с помощью SADT называется моделью, при этом используются как естественный, так и графические языки. SADT-модель может быть сосредоточена либо на функциях системы, либо на ее объектах: модели, ориентированные на функции, принято называть функциональными моделями, а ориентированные на объекты системы – моделями данных¹³.

Основные задачи, которые могут решаться с помощью SADT-методологии для систем любой природы:

• анализ функций, выполняемых системой;
• описание спецификаций – требований и функций проектируемой системы;
• проектирование системы.

Более 10 лет SADT была «бумажной» технологией, но в середине 80-х, когда на письменных столах появились персональные компьютеры с графическими возможностями, SADT «пересела» за компьютер. Одним из первых программных комплексов структурно-функционального анализа на основе SADT был пакет AUTOIDEF0, разработанный в рамках программы ВВС США по созданию интегрированной автоматизированной системы управления производством (ICAM – Integrated Computer Aided Manufacturing). В основе пакета лежит доведенное до уровня стандарта подмножество SADT – методология IDEF (IСАМ DEFinition), состоящая из трех методологий:

• IDEF0 – функциональное моделирование;
• IDEF1 – информационное моделирование;
• IDEF2 – динамическое моделирование функций, информации и ресурсов¹⁴.

Методология IDEF, основанная на принципах  системного анализа и предназначенная для представления функций произвольной системы (будь то управление финансами, организация работ, обучение или автоматизация), фактически стала стандартом не только в США, но и в ряде европейских стран. Из трех названных методологий наибольшее распространение получила первая – IDEF0. В 1985 методология IDEF1 была расширена и переименована в IDEF1X. Что касается методологии IDEF2, то она не получила широкого распространения.

Всего же планировалось создать  множество стандартов от IDEF0 до IDEF14. Однако не все она стали стандартами де-факто¹⁵.

 

2.2. Описание функционального  моделирования с помощью технологий IDEF0

 

В основе метода IDEF0 лежат следующие  концептуальные положения:

• графическое представление модели в виде иерархии диаграмм, обеспечивающее компактность представления информации;
• максимальная выразительность, т. е. способность наилучшим образом обеспечить понимание модели;
• строгость и точность представления;
• пошаговые процедуры разработки модели, ее просмотра и объединения;
• отделение организации от функции – исключение влияния организационной структуры на функциональную модель.

IDEF0-модель составлена из иерархического  ряда диаграмм, которые постепенно  отображают уровни все более  подробных описаний функций и  их интерфейсов в пределах системы. Диаграмма, находящаяся на вершине модели, обобщает всю рассматриваемую систему. Диаграммы первого уровня представляют важнейшие подсистемы с их взаимосвязями, а диаграммы самого нижнего уровня представляют детализированные функции, с помощью которых, собственно, и работает система.

Одним из достоинств IDEF0-моделей является то, что они обеспечивают возможность  обмена информацией о рассматриваемом  объекте на языке, понятном не только аналитику и разработчику системы, но и специалисту-эксперту в предметной области, пользователю, руководителю (Д. Росс, назвал технику структурного анализа языком для передачи понимания). Создаваемая IDEF0-модель имеет конкретное назначение, называемое целью модели. Цель моделирования можно понять из следующего формального определения модели¹⁶:

M есть модель системы S, если M может быть использована для получения ответов на вопросы относительно S с точностью A.

Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говором, что модель не достигла своей цели.

Обычно вопросы для IDEF0-модели формулируются на самом раннем этапе анализа или проектирования, при этом основная суть этих вопросов должна быть выражена в одной-двух фразах.

С определением цели модели тесно  связана позиция, с которой наблюдается  система и создается ее модель. IDEF0 требует, чтобы конкретная модель всегда рассматривалась с одной и той же точки зрения. Эта позиция называется точкой зрения данной модели.

Компоненты синтаксиса IDEF0-диаграмм – функциональные блоки и дуги (стрелки), правила и диаграммы. Функциональные блоки представляют функции, определенные как действия, процессы или преобразования. Дуги представляют данные или объекты, связанные с функциями. Правила определяют, как компоненты используются, а диаграммы обеспечивают формат для словесного или графического изображения моделей.

Функциональный блок описывает  то, что происходит в рассматриваемой  части системы. Блок изображаются прямоугольником и должен иметь название (имя) и номер внутри границ блока (рис. 2.1). Дуга изображается одинарной линией со стрелкой на конце. Они изображают такие понятия как данные или объекты, связанные с выполняемыми функциями и описываются существительными или существительными с определениями.

Примеры наименований дуг: товары, платежи, законы, сотрудники, оборудование, командировочное задание, деньги.

Дуги должны соответствовать следующим  синтаксическим правилам:

• при изгибе дуга может быть изогнута только на 90є;
• дуги изображаются сплошной линией;
• дуги должны чертиться только горизонтально или вертикально (но не по диагонали);
• дуги должны касаться внешней границы блока, но не должна входить в блок;
• дуги должны присоединяться к сторонам блока, но не к углам.

Между данными/объектами и функциями  возможны четыре отношения: вход, управление, выход и механизм. Каждое из этих отношений изображается дугой, связанной с определенной стороной блока (рис. 2.3): левая сторона предназначена для выходных дуг (входов), правая – для выходных (выходов), верхняя сторона – для управленческих дуг и нижняя – для дуг механизмов.

Входные дуги изображают данные/объекты, используемые и преобразуемые функциями (документы, сырье, детали).

Выходные дуги изображают данные/объекты, в которые преобразуются входы (документы, счета, деньги, устройства).

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

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

Дуга в IDEF0 редко изображает один объект или одни данные. Обычно она  отражает их набор, поэтому дуги могут разветвляться и соединяться различными сложными способами. Вся дуга или часть ее может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках. Дуги на диаграммах верхнего уровня можно рассматривать как конвейеры или трубопроводы. IDEF0-диаграмма составлена из блоков, связанных дугами, которые определяют, как блоки влияют друг на друга. Это влияние может выражаться либо в передаче результатов работы одного блока другому блоку для дальнейшего преобразования, либо в выработке управляющей информации, предписывающей, что именно должна выполнять другая функция¹⁷. Можно выделить пять типов взаимосвязей между блоками для описания их отношений:

• управление;
• вход;
• обратная связь по управлению;
• обратная связь по входу;
• выход-механизм.

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

На контекстной диаграмме также  должны быть указаны точка зрения модели и цель ее создания, которые  помогают направлять создание модели. Точка зрения определяет то, что  может быть «видно» в пределах контекстной модели и из какой перспективы или «угла». Формулировка цели выражает причину создания модели и фактически определяет ее структуру. Наиболее важные особенности системы представлены в иерархии, поскольку функция верхнего уровня декомпозируется на подфункции.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

¹ Абрютина, М.С. Экономический анализ хозяйственной деятельности: Учебное пособие / М.С.Абрютина. – М.: Инфра, 2010. – с. 201.

² Артеменко, В.Г., Белелндир М.В. Финансовый анализ: Учебное пособие, 4-е изд., перераб. и доп. / В.Г.Артеменко, М.В.Беллендир. - М.: Дело, 2011.  – с. 101.

³ Балашов, В.Г., Ириков В.А. Технология повышения финансовых результатов предприятий и корпораций / В.Г.Балашов, В.А.Ириков. - М.: Издательство ПРИОР, 2010. – с. 98.

⁴ Барнгольц, С.Б. Экономический анализ хозяйственной деятельности предприятий и объединений: Учебник. – 4-е изд., перераб. и доп. / С.Б.Барнгольц. – М.: Финансы и статистика, 2010. – с. 91.

⁵ Донцова, Л. В. Анализ финансовой отчетности: учебник. - 3-е изд., перераб. и доп. / Н.А.Никифорова. – М.: Издательство "Дело и Сервис", 2011. – с. 129.

⁶ Ивлев В., Попова Т., Огороднийчук Д. Использование CASE-средств для совершенствования деятельности предприятий // PCWEEK/RE. – 2011. – 23 сентября. – С. 53-54.

⁷ Илясов, Г.А. Оценка финансового состояния предприятия / Г.А.Илясова // Экономист. - 2010. – С. 10-12.

⁸ Калянов Г.Н. Консалтинг при автоматизации предприятий. – М.: СИНТЕГ, 2010. – с. 201.

⁹ Каменнова М.. Структурный анализ и реорганизация деятельности предприятия. – http:/www.citforum.ru/win/ofis/ofis96/103.shtml.

¹⁰

¹¹ Ивлев В., Попова Т., Огороднийчук Д. Использование CASE-средств для совершенствования деятельности предприятий // PCWEEK/RE. – 2011. – 23 сентября. – С. 53-54.

¹² Илясов, Г.А. Оценка финансового состояния предприятия / Г.А.Илясова // Экономист. - 2010. – С. 10-12.

¹³ Калянов Г.Н. Консалтинг при автоматизации предприятий. – М.: СИНТЕГ, 2010. – 316 с.

¹⁴ Марка Д.А., МакГоуэл К. М. Методология структурного анализа и проектирования SADT. – М.: Метатехнология, 2011. – с. 101.

¹⁵ Росс Д. Структурный анализ (SA): язык для передачи понимания // Требования и спецификации в разработке программ. М.: Мир, 2010. – С. 240-284.

¹⁶ Росс Д. Структурный анализ (SA): язык для передачи понимания // Требования и спецификации в разработке программ. М.: Мир, 2010. – С. 240-284.

¹⁷ Структурный системный анализ: Методические указания к лабораторным работам / Качала В.В., Сенецкая Л.Б., Шалаева С.В. – Мурманск, изд-во МГТУ, 2009. – с. 101.

¹⁸ Росс Д. Структурный анализ (SA): язык для передачи понимания // Требования и спецификации в разработке программ. М.: Мир, 2010. – С. 240-284.