Моделирование бизнес процессов ramus примеры

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

В качестве примера рассматривается деятельность промышленной компании. Компания занимается сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры.

Деятельность компании состоит из следующих элементов:

• продавцы принимают заказы клиентов;
• операторы группируют заказы по типам клиентов;
• операторы собирают и тестируют компьютеры;
• операторы упаковывают компьютеры согласно заказам;
• кладовщик отгружает клиентам заказ.

Компания использует приобретенную бухгалтерскую ИС, которая позволяет оформить заказ, счет и отследить платежи по счетам.

Перед выполнением упражнения 1. Запустите программу Ramus (Пуск -> Программы -> Ramus -> Ramus). Если программа не установлена на ПК, то при наличии доступа в Интернет самостоятельно произведите инсталляцию данного ПО с сайта разработчика: http://ramussoftware.com/.

14.1. Упражнение 1. Создание контекстной диаграммы

1. После запуска программы на экране появится окно начала работ (
   рис.
   14.1). Выберите опцию «Создать» и нажмите «ОК«.

   

   Рис.
   14.1.
   Диалоговое окно начала работы в Ramus

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

   В описании проекта укажите «Это учебная модель, описывающая деятельность компании«, перейдите к следующему шагу.

3. Раздел «классификаторы» оставьте незаполненным и нажмите «Дальше«.
4. В следующем диалоговом окне нажмите «Окончить» и перейдите к рабочему интерфейсу программы.
5. Через меню Диаграмма -> Свойства модели можно отредактировать мета-данные модели, а именно: название модели, описание, место ее использования.
6. Активируйте окно модели, кликнув на область моделирования. Создайте контекстную диаграмму, нажав на кнопку .
7. Перейдите в режим редактирования контекстной диаграммы, нажав правой кнопкой мыши на объекте и выбрав опцию «Редактировать активный элемент«. В закладке «Название» введите «Деятельность компании«. Во вкладке «Описание» введите «Текущие бизнес-процессы компании«. Обратите внимание, что вкладка «Описание» может быть недоступна в версии RAMUS Educational
8. Создайте стрелки на контекстной диаграмме в соответствие с информацией, приведенной в таблице 1.1. Для создания стрелок необходимо перейти в режим построения стрелок с помощью кнопки , навести курсор на исходную точку стрелки (левая, верхняя и нижняя граница области построения модели или правая граница контекстной диаграммы), после того, как область будет подсвечена черным цветом, кликнуть один раз и аналогичным образом обозначить конец стрелки (правая, верхняя и нижняя граница контекстной диаграммы или правая граница области построения модели). Перемещать стрелки и их названия можно по принципам стандартного механизма drag&drop.

На
рис.
14.2 представлен результат построения контекстной диаграммы по результатам Упражнения 1.

14.2. Упражнение 2. Создание диаграммы декомпозиций

1. Выберите кнопку перехода на уровень ниже в панели инструментов.
2. В диалоговом окне укажите число работ на диаграмме нижнего уровня — «3», а нотацию декомпозиции — IDEF (
   рис.
   14.3), затем нажмите «ОК«. Автоматически будет создана диаграмма декомпозиции.

   

   Рис.
   14.3.
   Диалоговое окно декомпозиции работ

3. Правой кнопкой мыши щелкните по 1-ой работе, выберите «Редактировать активный элемент» и на вкладке «Название» укажите имя работы. Повторите операцию для всех трех работ, а также внесите их описание в соответствующую вкладку на основе данных таблицы (табл. 1.2). Обратите внимание, что вкладка «Описание» может быть недоступна в версии RAMUS Educational.

   Таблица
   14.2.
   Описание работ декомпозиции первого уровня

   НАЗВАНИЕ	ОПИСАНИЕ
   Продажи и маркетинг	Телемаркетинг, презентации, выставки
   Сборка и тестирование компьютеров	Сборка и тестирование настольных и портативынх компьютеров
   Отгрузка и получение	Отгрузка заказов клиентам и получение компонентов от поставщиков

4. Перейдите в режим рисования стрелок. Произведите связывание граничных стрелок с функциональными объектами, как показано на
   рис.
   14.4. Для связывания граничных стрелок наводите курсор на сами стрелки, а не на границы области построения моделей.

   

   Рис.
   14.4.
   Связывание граничных стрелок на диаграмме декомпозиции A0

   Правой кнопкой мыши щёлкните по ветви стрелки «Сборка и тестирование компьютеров«, переименуйте ее в «Правила сборки и тестирования» (
   рис.
   14.5).

5. Правой кнопкой мыши щелкните по ветви стрелки механизма работы «Продажи и маркетинг» и переименуйте ее в «Система оформления заказов» (
   рис.
   14.5)

   

   Рис.
   14.5.
   Присвоение названий ветвям стрелок диаграммы декомпозиции A0

6. Создайте новые внутренние стрелки, как показано на рисунке (
   рис.
   14.6)

   

   Рис.
   14.6.
   Внутренние стрелки диаграммы декомпозиции A0

7. Создайте стрелку обратной связи (по управлению) «Результаты сборки и тестирования«, идущую от работы «Сборка и тестирование компьютеров» к «Продажи и маркетинг«. Измените стиль стрелки — толщину (правая кнопка мыши -> «Редактировать активный элемент» -> вкладка «Линия»). Методом drag&drop возможно переносить стрелки и их названия. При необходимости возможно установить «тильду» (опция контекстного меню при нажатии на стрелке правой кнопкой мыши) для явной связи стрелки и подписи к ней (
   рис.
   14.7)

   

   Рис.
   14.7.
   Результаты редактирования стрелок на диаграмме декомпозиции A0

8. Создайте новую граничную стрелку «Маркетинговые материалы«, выходящую из работы «Продажи и маркетинг» Эта стрелка автоматически не попадает на диаграмму верхнего уровне и имеет квадратные скобки у окончания . Щелкните правой кнопки мыши по квадратным скобкам и выберите в контекстном меню «Туннель» (см.
   рис.
   14.8) одну их двух опций: «Создать стрелку» и «Обозначить туннель круглыми скобками«, в нашем случае — первый вариант.

Введение

Технология создания информационных
систем (далее — ИС) предъявляет особые
требования к методикам реализации и
программным инструментальным средствам,
а именно:

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

Проект по созданию сложной ИС невозможно
реализовать в одиночку. Коллективная
работа существенно отличается от
индивидуальной, поэтому при реализации
крупных проектов необходимо иметь
средства координации и управления
коллективом разработчиков.

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

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

На современном рынке средств разработки
ИС достаточно много систем, в той или
иной степени удовлетворяющих перечисленным
требованиям.

В настоящем пособии рассматривается
САSЕ-средство верхнего
уровняRamus, поддерживающее
методологии IDEF0 (функциональная модель)
и DFD (DataFlowDiagram), предназначено для
проведения анализа и реорганизации
бизнес-процессов. Функциональная модель
предназначена для описания существующих
бизнес-процессов на предприятии (так
называемая модель AS-IS) и идеального
положения вещей — того, к чему нужно
стремиться (модель ТО-ВЕ). Методология
IDEF0 предписывает построение иерархической
системы диаграмм — единичных описаний
фрагментов системы. Сначала проводится
описание системы в целом и ее взаимодействия
с окружающим миром (контекстная
диаграмма), после чего проводится
функциональная декомпозиция — система
разбивается на подсистемы и каждая
подсистема описывается отдельно
(диаграммы декомпозиции). Затем каждая
подсистема разбивается на более мелкие
и так далее до достижения нужной степени
подробности. После каждого сеанса
декомпозиции проводится сеанс экспертизы:
каждая диаграмма проверяется экспертами
предметной области, представителями
заказчика, людьми, непосредственно
участвующими в бизнес-процессе. Такая
технология создания модели позволяет
построить модель, адекватную предметной
области на всех уровнях абстрагирования.
Если в процессе моделирования нужно
осветить специфические стороны технологии
предприятия,Ramusпозволяет
переключиться на любой ветви модели на
нотацию DFD и создать смешанную модель.
Нотация DFD включает такие понятия, как
«внешняя сущность» и «хранилище
данных», что делает ее более удобной
(по сравнению с IDEF0) для моделирования
документооборота.

На основе модели Ramusможно
построить модель данных. Для построения
модели данных можно использовать такие
инструменты какDBDesignerForkили WWW SQLDesigner.

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

1.1 Начало работы

При запуске «Ramus» появляется окно, в
котором предлагается создать новый
проект (по умолчанию) или же открыть уже
существующий файл проекта. Данное окно
не будет выводиться в дальнейшем если
поставить галочку «Использовать выбор
по умолчанию и больше не спрашивать».

При выборе пункта «Создать новый файл»
автоматически запускается мастер
создания нового проекта. Этот мастер
можно закрыть и заполнить необходимые
сведения позже, но рекомендуется
выполнить все его этапы.

На первом этапе предлагается внести
сведения об авторе, названии проекта и
модели. Также следует выбрать тип нотации
модели: IDEF0 или DFD.

На втором этапе предлагается внести
сведения о том, в какой организации
используется данный проект.

На третьем этапе предлагается дать
короткое описание проекту.

На четвёртом этапе предлагается создать
несколько основных классификаторов
проекта. Например: «Информация», «Ресурсы»
и т.д.

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

После завершения работы мастера,
откроется рабочее пространство
«Диаграммы» в котором можно приступить
к созданию графической модели.

1.2 Создание модели в стандарте idef0

1.2.1 Принципы построения модели idef0

На начальных этапах создания ИС необходимо
понять, как работает организация, которую
собираются автоматизировать. Для
описания работы предприятия необходимо
построить модель. Такая модель должна
быть адекватна предметной области;
следовательно, она должна содержать в
себе знания всех участников бизнес-процессов
организации.

Наиболее удобным языком моделирования
бизнес-процессов является IDEF0, предложенный
Дугласом Россом и называвшийся
первоначально SADT — Structured
Analysis and Design Tech-nique.
Позднее вооруженные силы США применили
подмножество SADT, касающееся моделирования
процессов, для реализации проектов в
рамках программы ICAM (IntegratedComputer-AidedManufacturing). В дальнейшем это
подмножество SADT бы-ло
принято в качестве федерального стандарта
США под наименованием IDEF0. Подробные
спецификации на стандарты IDEF можно
найти на сайте http://www.idef.com.

В IDEF0 система представляется как
совокупность взаимодействующих работ
или функций. Такая чисто функциональная
ориентация является принципиальной —
функции системы анализируются независимо
от объектов, которыми они оперируют.
Это позволяет более четко смоделировать
логику и взаимодействие процессов
организации.

Под моделью в IDEF0 понимают описание
системы (текстовое и графическое),
которое должно дать ответ на некоторые
заранее определенные вопросы.

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

Процесс моделирования какой-либо системы
в IDEF0 начинается с определения контекста,
т. е. наиболее абстрактного уровня
описания системы в целом. В контекст
входит определение субъекта моделирования,
цели и точки зрения на модель.

Под субъектом понимается сама система,
при этом необходимо точно установить,
что входит в систему, а что лежит за ее
пределами; другими словами, мы должны
определить, что мы будем в дальнейшем
рассматривать как компоненты системы,
а что как внешнее воздействие. На
определение субъекта системы будет
существенно влиять позиция, с которой
рассматривается система, и цель
моделирования — вопросы, на которые
построенная модель должна дать ответ;
другими словами, первоначально необходимо
определить область моделирования.
Описание области как системы в целом,
так и ее компонентов является основой
построения модели. Хотя предполагается,
что в течение моделирования область
может корректироваться, она должна быть
в основном сформулирована изначально,
поскольку именно область определяет
направление моделирования и когда
должна быть закончена модель. При
формулировании области необходимо
учитывать два компонента — широту и
глубину. Широта подразумевает определение
границ модели — мы определяем, что будет
рассматриваться внутри системы, а что
снаружи. Глубина определяет, на каком
уровне детализации модель является
завершенной. При определении глубины
системы необходимо не забывать об
ограничениях времени — трудоемкость
построения модели растет в геометрической
прогрессии от глубины декомпозиции.

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

Цель моделирования. Модель не может
быть построена без четко сформулированной
цели. Цель должна отвечать на следующие
вопросы:

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

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

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

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

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

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

Модели AS-IS
и ТО-ВЕ. Целью
построения функциональных моделей
обычно является выявление наиболее
слабых и уязвимых мест деятельности
организации, анализ преимуществ новых
бизнес-процессов и степени изме-нения
существующей структуры организации
бизнеса. Анализ недостатков и «узких
мест» начинают с построения модели
AS-IS (Как есть), т. е. модели существующей
организации работы. Модель AS-IS может
строиться на основе изучения документации
(должностных инструкций, положений о
пред-приятии,
приказов, отчетов и т. п.), анкетирования
и опроса служащих предприятия (организация
опроса должна быть итерационной и
реализовать цикл автор-читатель, см.
1.2.6), создания фотографии рабочего дня
и других источников. Полученная
модель AS-IS служит для выявления
неуправляемых работ, работ не обеспеченных
ресурсами, ненужных и неэффективных
работ, дублирующихся работ и других
недостатков в организации деятельности
предприятия. Исправление недостатков,
перенаправление информационных и
материальных потоков приводит к созданию
модели TO-BE (Как будет) — модели идеальной
организации бизнес-процессов. Как
правило, строится несколько моделей
ТО-ВЕ, среди которых определяют наилучший
вариант.

Следует указать на распространенную
ошибку при создании модели AS-IS — это
создание идеализированной модели.
Примером может служить создание модели
на основе знаний руководителя, а не
конкретного исполнителя работ.
Руководитель знаком с тем, как
предполагается выполнение работы по
руководствам и должностным инструкциям,
и часто не знает, как на самом деле
подчиненные выполняют рутинные работы.
В результате получается приукрашенная,
искаженная модель, которая несет ложную
ин-формацию и которую
невозможно в дальнейшем использовать
для анализа. Такая модель называется
SHOULD ВЕ (Как должно бы быть).

Технология проектирования ИС подразумевает
сначала создание модели AS-IS, ее анализ
и улучшение бизнес-процессов, т. е.
создание модели TO-BE,
и только на основе модели ТО-ВЕ строится
модель данных, прототип и затем
окончательный вариант ИС. Построение
системы на основе модели AS-IS приводит
к автоматизации предприятия по принципу
«все оставить как есть, только чтобы
компьютеры стояли», т. е. ИС автоматизирует
несовершенные бизнес-процессы и
дублирует, а не заменяет существующий
документооборот. В результате внедрение
и эксплуатация такой системы приводит
лишь к дополнительным издержкам на
закупку оборудования, создание
программного обеспечения и сопровождение
того и другого. Для закрепления материала
вспомним фразу: «в результате автоматизации
хаоса получается автоматизированный
хаос».

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

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

Модель, создаваемая в Ramusможет содержать два типа диаграмм:

• контекстную (в каждой модели может быть
  только одна контекстная диаграмма);

• декомпозиции.

Контекстная диаграмма является вершиной
древовидной структуры диаграмм и
представляет собой самое общее описание
системы и ее взаимодействия с внешней
средой. После описания системы в целом
проводится разбиение ее на крупные
фрагменты. Этот процесс называется
функциональной декомпозицией, а
диаграммы, которые описывают каждый
фрагмент и взаимодействие фрагментов,
называются диаграммами декомпозиции.
После декомпозиции контекстной диаграммы
проводится декомпозиция каждого большого
фрагмента системы на более мелкие и т.
д., до достижения нужного уровня
подробности описания, После каждого
сеанса декомпозиции проводятся сеансы
экспертизы — эксперты предметной
области указывают на соответствие
реальных бизнес-процессов созданным
диаграммам. Найденные несоответствия
исправляются, и только после прохождения
экспертизы без замечаний можно приступать
к следующему сеансу декомпозиции. Так
достигается соответствие модели реальным
бизнес-процессам на
любом уровне модели. Синтаксис описания
системы в целом и каждого ее фрагмента
одинаков во всей модели.

Рассмотрим основные компоненты нотации
IDEF0, используемые при
построении моделей.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

1. Ramus

Моделирование бизнес-процессов
Выполнила ст. гр. АС-13
Понкратенко В.А.

2. Предназначение

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

3. IDEF0

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

4. DFD

Диаграммы потоков данных. Так
называется методология графического структурного анализа,
описывающая внешние по отношению к системе источники и
адресаты данных, логические функции, потоки данных и
хранилища данных, к которым осуществляется доступ.
Диаграмма потоков — один из основных инструментов
структурного анализа и проектирования информационных
систем. Несмотря на имеющее место в современных
условиях смещение акцентов от структурного к объектноориентированному подходу к анализу и проектированию
систем, «старинные» структурные нотации по-прежнему
широко и эффективно используются как в бизнес-анализе, так
и в анализе информационных систем.

5.

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

6.

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

7. Модельный ряд:

Локальная версия Ramus:
Коммерческий продукт для широкого круга пользователей.
Сетевая версия Ramus:
Данная версия предоставляется только корпоративным клиентам вместе с
сопутствующими услугами по разворачиванию и поддержке.
Функциональность существенно расширена по сравнению с локальной версией.
Ramus Educational:
Некоммерческий продукт. Ориентирован на использование в обучении.
Доступен только в локальном варианте и ограничен по функциональности.
Перечень основных ограничений по сравнению с коммерческой локальной
версией:
ограничен перечень доступных атрибутов классификаторов;
отсутствует функциональность для работы с матричными проекциями
классификаторов;
отсутствует редактор отчётов;
отсутствует навигатор по модели.

8. Преимущества перед аналогами: Эргономичность графического редактора. Редактор поддерживает быструю навигацию по модели, шаблоны часто и

Преимущества перед аналогами:
Эргономичность графического редактора. Редактор поддерживает
быструю навигацию по модели, шаблоны часто используемых типов
диаграмм, возможность отмены последних действий, «умное» поведение
стрелок.
Поддержка неограниченного количества атрибутов различных типов.
Автоматическое построение иерархических деревьев в классификаторах
на основании значений атрибутов.
Редактор отчётов поддерживает несколько вариантов настройки:
упрощённую (с использованием инструментов редактора и набора
ключевых слов) и расширенную (с использованием JavaScript). Шаблоны
отчётов могут быть экспортированы и импортированы в формате файлов
XML.
Гибкий графический интерфейс пользователя.
Кроссплатформенность. Использование технологии Java позволяет
устанавливать систему под разными видами операционных систем и
аппаратных платформ (MS Windows, Mac OS, Linux и т.д.).

9. В качестве примера рассматрим деятельность промышленной компании. Компания занимается сборкой и продажей настольных компьютеров и ноут

В качестве примера рассматрим деятельность промышленной
компании. Компания занимается сборкой и продажей настольных
компьютеров и ноутбуков. Компания не производит компоненты
самостоятельно, а только собирает и тестирует компьютеры.
Деятельность компании состоит из следующих элементов:
продавцы принимают заказы клиентов;
операторы группируют заказы по типам клиентов;
операторы собирают и тестируют компьютеры;
операторы упаковывают компьютеры согласно заказам;
кладовщик отгружает клиентам заказ.
Компания использует приобретенную бухгалтерскую ИС,
которая позволяет оформить заказ, счет и отследить
платежи по счетам.

10. Результат декомпозиции процесса Сборка и тестирование

11.

Важно, что Ramus позволяет
просматривать содержимое проектов
через веб-интерфейс. Это упрощает
коммуникации между
разработчиками и пользователями
систем управления, созданными с
использованием возможностей
Ramus.

12. Конец!