Dfd ramus как задать объект

6

2. Порядок выполнения работы в Ramus.

Необходимо отразить потоки информации для разрабатываемой АИС. На рисунке 1 представлена функциональная модель системы, где указываются основные функции АИС и необходимый набор входных данных, для получения выходных результатов. К основным функциям относятся прием жалоб от клиентов с ввод необходимой информации, формирование нарядки на проведение тестирования и в последующем ремонта. Формирования отчетов по количеству жалоб с участков, количеству жалоб, тематике жалоб и авторов жалоб. Информацию об авторах жалоб планируется применять для определения наиболее активных и главное конструктивных абонентов, которых в последствие планируется поощрять. Отсутствует возможность удаления жалоб, только возможность отмены обработки с описанием причин изменения условий обработки. К основным функциям системы так же прилагается дополнительная функция формирования подсказки диспетчеру.

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

В таблице 1 приведено подробное описание каждого элемента из диаграммы с описанием функциональной модели системы.

Таблица 1 — Описание элементов диаграммы с перечислением основных задач необходимых к решению.

Ramus лаба (IDEF+DFD). Использование caseсредств при проектировании экономических информационных систем

Единственный в мире Музей Смайликов

Самая яркая достопримечательность Крыма
Скачать 0.62 Mb.

Использование CASE-средств при проектировании экономических информационных систем.

Оглавление

Использование CASE-средств при проектировании экономических информационных систем. 1

Упражнение №1. Методология IDEF0. Создание контекстной диаграммы 3

Упражнение №2. Методология IDEF0. Создание декомпозиции контекстной диаграммы 6

Упражнение №3. Методология IDEF0. Создание дальнейших диаграмм декомпозиций 8

Упражнение №4. Методология DFD. Понятийный аппарат. 12

Упражнение №5. Дополнение моделей процессов диаграммой DFD. 14

Введение

Перед началом работы необходимо ознакомится с материалами лекции « Информационное моделирование экономических процессов при создании ИС », а также с руководящим документом (стандартом) Методология функционального проектирования IDEF0
Сведения о проектируемой системе

В лабораторной работе речь пойдет о построении диаграмм при проектировании системы «Служба занятости в рамках ВУЗа» .

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

Разрабатываемая система предназначена для того, чтобы помочь студенту устроиться на работу уже в процессе его обучения в ВУЗе. Подав заявление в систему студент становится её клиентом и начинает обслуживаться на протяжении всего обучения в Вузе. Система предлагает профессиональные (основанные на изучаемых предметах) и психологические тестирования. Тестирования проводятся регулярно – раз в семестр.

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

Упражнение №1. Методология IDEF0. Создание контекстной диаграммы

При запуске системы Ramus Educational появляется окно вида:

Выберем опцию Создать новый файл и нажмем кнопку ОК

• Автор – свое имя
• Название проекта – Служба занятости в рамках ВУЗа
• Название модели – не пишем
• Выберите нотацию IDEF0

Раздел «классификаторы» оставьте незаполненным и нажмите

В следующем диалоговом окне нажмите и перейдите к рабочему интерфейсу программы.

В дальнейшем через меню _Свойства_модели’>Диаграмма -> Свойства модели можно отредактировать мета-данные модели, а именно: название модели, описание, место ее использования.
Активируйте окно модели, кликнув на область моделирования.

Начнем с построения контекстной IDEF0-диаграммы. Создайте контекстную диаграмму, нажав на кнопку .

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

Перейдите в режим редактирования контекстной диаграммы, нажав правой кнопкой мыши на объекте и выбрав опцию » Редактировать активный элемент «. Или щелкнув двойным щелчком левой кнопки мыши по объекту.

В появившемся окне Свойства функционального блока в закладке «Название» введите » Обслуживание клиента системы «.

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

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

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

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

Процесс обработки запросов будет выполнять Пользователь системы под контролем Администратор системы.

Управляющей стрелкой будут являться Уровни доступа.
Результат построения контекстной диаграммы будет иметь вид:

Упражнение №2. Методология IDEF0. Создание декомпозиции контекстной диаграммы

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

Выберите кнопку перехода на уровень ниже в панели инструментов.

В диалоговом окне укажите число работ на диаграмме нижнего уровня — «4», а нотацию декомпозиции – IDEF0, затем нажмите «ОК«. Автоматически будет создана диаграмма декомпозиции.

• Определение уровня доступа в систему
• Обращение к подсистеме
• Изменение БД (при необходимости)
• Обработка запроса клиента

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

Обязательно создайте стрелку обратной связи (по управлению) Запросы на изменение БД , идущую от работы Обработка запроса клиента к Изменение БД . Изменить стиль стрелки – толщину (правая кнопка мыши – Редактировать активный элемент – вкладка Линия)

Методом drag&drop возможно переносить стрелки и их названия. При необходимости возможно установить «тильду» (опция контекстного меню при нажатии на стрелке правой кнопкой мыши) для явной связи стрелки и подписи к ней.

В результате получится представление вида:

Упражнение №3. Методология IDEF0. Создание дальнейших диаграмм декомпозиций

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

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

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

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

Т.о. определение уровня доступа в систему будет выглядеть следующим образом:

Декомпозиция работы Обращение к подсистеме не отвечает цели и точки зрения модели. Пользователя системы не интересуют внутренние алгоритмы её работы. Поэтому декомпозиция данного блока не проводится. Аналогично обстоит дело с работой Изменение БД.

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

Необходимо отметить, что в блок Выполнение запроса включается работа различных подсистем. Например, если запрос включает в себя тестирование, то его будет исполнять подсистема профессиональных и психологических тестов. При анализе полученной диаграммы возникает вопрос по каким правилам проводится генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД. Причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Клиенту же предоставляется возможность выбора формы отчета.

Скорректируем диаграмму, добавив в неё стрелку Шаблоны отчетов.

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

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

В нашем случае выберем первый вариант. Т.о. изменение диаграммы повлечет за собой корректировку всех родительских диаграмм.

Декомпозиция процесса Обработка запроса клиента после корректировки примет вид:

Вернемся на диаграммы верхних уровней и сделаем необходимые изменения:

Упражнение №4. Методология DFD. Понятийный аппарат.

Диаграммы потоков данных (DFD, Data Flow Diagram) – представляют собой сеть связанных между собой работ. Их удобно использовать для описания документооборота и обработки информации.

1. Функции обработки информации – работы
2. Документы, объекты, сотрудников или отделы, участвующие в процессе обработки информации
3. Внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы
4. Таблицы для хранения документов (хранилища данных)

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

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

Хранилище данных позволянет на определенных участках определять данные, которые будут сохраняться в памяти между процессами. Фактически хранилища – это «срезы» потоков данных во времени. Информация, содержащаяся в хранилище может использоваться в любое время после её определения при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое.

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

Упражнение №5. Дополнение моделей процессов диаграммой DFD.

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

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

Тунелирование производится удалением стрелки Пользователь системы с текущей декомпозиции

Родительская диаграмма примет вид:

Декомпозируем работу Обработать запрос студента в нотации DFD.

• Составить резюме
• Найти данные по успеваемости
• Пройти тестирование

• Хранилище «Резюме»
• Хранилище «Тесты»
• Хранилище «Успеваемость»

Внесите в модель соответствующие хранилища данных при помощи кнопки .

И постройте DFD модель процесса.

Дополните харнилище элементом: Хранилище «Экспертные оценки»

Постройте DFD модель процесса «Обработать запрос эксперта»

Детальнее о Ramus

• Моделирование процессов (согласно нотаций IDEF0 и DFD);
• Разработка систем классификации и кодирования предприятия с внутренними перекрёстными связями, которая также тесно увязывается и с моделями процессов;
• Формирование отчётности по моделям и системе классификации, в том числе и отчётности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов;
• Генерация сайта, который призван обеспечить доступ к данным моделей процессов, системы классификации и кодирования а также к разнообразнейшей отчётности через веб-интерфейс.

Ramus имеет редактор диаграмм IDEF0 и DFD эргономичность которого находится на уровне не ниже чем у аналогичных продуктов имеющих схожие редакторы. Это проявляется в более лёгкой и быстрой навигации по модели, в более «умном» поведении объектов диаграмм, в поддержке шаблонов диаграмм, в возможности быстрого исправления допущенных ошибок, в том числе и в возможности отмены действий.

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

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

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

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

Для генерации отчётности в Ramus присутствует редактор отчётности.

Наличествует поддержка шаблонов отчётов в формате XML которые могут быть экспортированы из файла или импортированы в файл.

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

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

Это существенно упрощает использование и развёртку Ramus, так как избавляет от необходимости установки клиентской версии Ramus на АРМах пользователей, которые имеют доступ только на чтение информации Проекта. Всей или некоторой информации Проекта, что определяется настройками прав доступа.

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

Использование технологии Java, при реализации программных модулей, позволяет использовать Ramus под разными видами операционных систем и аппаратных платформ (MS Windows, Linux, Mac OS, и т.д.…).

Ramus может использоваться в файловом (локальном) и сетевом вариантах.

Сетевая версия Ramus позволяет распределять доступ пользователей к данным.

Сетевая версия Ramus использует стандартизированные протоколы обмена данными, что позволяет интегрировать Ramus с другими системами.

Но и без использования сетевой версии можно разделить работу над Проектом между несколькими разработчиками путём использования функции расщепления Проекта.

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

Dfd ramus как задать объект

Необходимо отразить потоки информации для разрабатываемой АИС. На рисунке 1 представлена функциональная модель системы, где указываются основные функции АИС и необходимый набор входных данных, для получения выходных результатов. К основным функциям относятся прием жалоб от клиентов с ввод необходимой информации, формирование нарядки на проведение тестирования и в последующем ремонта. Формирования отчетов по количеству жалоб с участков, количеству жалоб, тематике жалоб и авторов жалоб. Информацию об авторах жалоб планируется применять для определения наиболее активных и главное конструктивных абонентов, которых в последствие планируется поощрять. Отсутствует возможность удаления жалоб, только возможность отмены обработки с описанием причин изменения условий обработки. К основным функциям системы так же прилагается дополнительная функция формирования подсказки диспетчеру.

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

В таблице 1 приведено подробное описание каждого элемента из диаграммы с описанием функциональной модели системы.

Таблица 1 — Описание элементов диаграммы с перечислением основных задач необходимых к решению.

Dfd ramus как задать объект

Некоммерческое акционерное общество

АЛМАТИНСКИЙ УНИВЕРСИТЕТ ЭНЕРГЕТИКИ И СВЯЗИ

Кафедра «Информационные системы»

ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ

Методические указания к выполнению курсовой работы
для студентов специальности 5В070300 – «Информационные системы»

Составитель: Нурлыбаев Н.А. Информационно-управляющие системы. Методические указания к выполнению курсовой работы для студентов специальности 5В070300 – «Информационные системы» – Алматы: АУЭС, 2013. – 48 с.

Методические указания содержат указания к выполнению курсовой работы по дисциплине «Информационно-управляющие системы»

Методические указания предназначены для студентов специальности 5В070300 – «Информационные системы»

Рецензент:доцент Куликов А.А.

Печатается по плану издания НАО «Алматинский университет энергетики и связи» на 2012 г.

© НАО «Алматинский университет энергетики и связи», 2013 г.

Сводный план 2012 г. поз.204

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

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

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

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

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

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

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

На основе модели Ramus можно построить модель данных. Для построения модели данных можно использовать такие инструменты, как DBDesigner Fork или WWW SQL Designer.

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

Варианты заданий выбираются в соответствии с рекомендацией преподавателя или по схеме:

а) Две последние цифры номера зачетной книжки Nзк определяют номер варианта, если 1 < Nзк<24, если же 25< Nзк<99, то номер варианта определяется, как остаток от деления на Nзк на 25.

Варианты заданий: проектирования информационных систем.

1 Страховая компания.

Описание предметной области.

Заказчиком является страховая компания. Задачей является отслеживание финансовой деятельности компании.

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

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

2. Гостиница.

Описание предметной области.

Заказчиком является гостиница. Задачей является отслеживание финансовой стороны работы гостиницы.

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

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

Описание предметной области.

Заказчиком является ломбард. Задачей является отслеживание финансовой стороны работы ломбарда.

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

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

4 Реализация готовой продукции.

Описание предметной области.

Заказчиком является компания, занимающаяся оптово-розничной продажей различных товаров. Задачей является отслеживание финансовой стороны работы компании.

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

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

5 Ведение заказов.

Описание предметной области.

Заказчиком является компания, занимающаяся оптовой продажей различных товаров. Задачей является отслеживание финансовой стороны работы компании.

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

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

6 Бюро по трудоустройству.

Описание предметной области.

Заказчиком является бюро по трудоустройству. Задачей является отслеживание финансовой стороны работы компании.

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

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

7 Нотариальная контора.

Описание предметной области.

Заказчиком является нотариальная контора. Задачей является отслеживание финансовой стороны работы компании.

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

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

8 Фирма по продаже запчастей.

Описание предметной области.

Заказчиком является фирма, занимающаяся продажей запасных частей для автомобилей. Задачей является отслеживание финансовой стороны работы компании.

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

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

9 Распределение дополнительных обязанностей.

Описание предметной области.

Заказчиком является коммерческая компания. Задачей является отслеживание хода выполнения дополнительных работ.

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

10 Техническое обслуживание станков.

Описание предметной области.

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

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

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

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

11 Туристическая фирма.

Описание предметной области.

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

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

Фирма работает с несколькими отелями в нескольких странах. Путевки продаются на одну, две или четыре недели. Стоимость путевки зависит от длительности тура и отеля. Скидки, которые предоставляет фирма, фиксированы. Например, при покупке более 1 путевки, предоставляется скидка 5%. Скидки могут суммироваться.

12 Грузовые перевозки.

Описание предметной области.

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

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

Фирма решила ввести гибкую систему оплаты. Так, оплата водителям должна теперь зависеть не только от маршрута, но и от стажа водителя. Кроме того, нужно учесть, что перевозку могут осуществлять два водителя.

13 Учет телефонных переговоров.

Описание предметной области.

Заказчиком является коммерческая служба телефонной компании. Компания предоставляет абонентам телефонные линии для междугородних переговоров. Задачей является отслеживание стоимости междугородних телефонных переговоров.

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

Фирма решила ввести гибкую систему скидок. Так, стоимость минуты теперь уменьшается в зависимости от длительности разговора. Размер скидки для каждого города разный.

14 Учет внутриофисных расходов.

Описание предметной области.

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

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

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

15 Библиотека.

Описание предметной области.

Заказчиком является библиотека. Библиотека решила зарабатывать деньги, выдавая напрокат некоторые книги, имеющиеся в небольшом количестве экземпляров. Задачей является отслеживание финансовых показателей работы библиотеки.

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

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

16 Прокат автомобилей.

Описание предметной области.

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

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

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

17 Выдача банком кредитов.

Описание предметной области.

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

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

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

18 Платная поликлиника.

Описание предметной области.

Заказчиком является служба планирования платной поликлиники. Задачей является отслеживание финансовых показателей работы поликлиники.

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

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

19 Учет телекомпанией стоимости прошедшей в эфире рекламы.

Описание предметной области.

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

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

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

20 Интернет-магазин.

Описание предметной области.

Заказчиком является коммерческий отдел компании, продающей различные товары через Интернет. Задачей является отслеживание финансовой составляющей работы компании.

Работа компании организована следующим образом: на Интернет-сайте компании представлены (выставлены на продажу) некоторые товары. Каждый из них имеет некоторое название, цену и единицу измерения (штуки, килограммы, литры). Для проведения исследований и оптимизации работы магазина необходимо собирать данные о клиентах. При этом определяющее значение имеют стандартные анкетные данные, а также телефон и адрес электронной почты для связи. В случае приобретения товаров на сумму свыше 5000р. клиент переходит в категорию «постоянных клиентов» и получает скидку на каждую покупку в размере 2%. По каждому факту продажи автоматически фиксируется клиент, товары, количество, дата продажи, дата доставки.

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

21 Ювелирная мастерская.

Описание предметной области.

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

Ювелирное изделие может состоять из нескольких материалов. Кроме того, постоянным клиентам мастерская предоставляет скидки.

22 Парикмахерская.

Описание предметной области.

Заказчиком является парикмахерская.

Парикмахерская стрижет клиентов в соответствии с их пожеланиями и некоторым каталогом различных видов стрижки. Так, для каждой стрижки определены название, принадлежность полу (мужская, женская), стоимость работы. Для наведения порядка необходимо составить базу данных клиентов, запоминая их анкетные данные (фамилия, имя, отчество). Начиная с 5-ой стрижки, клиент переходит в категорию постоянных и получает скидку в 3% при каждой последующей стрижке. После того, как закончена очередная работа, в кассе фиксируются стрижка, клиент и дата производства работ.

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

23 Химчистка.

Описание предметной области.

Заказчиком является химчистка.

Химчистка осуществляет прием у населения вещей для выведения пятен. Для наведения порядка необходимо составить базу данных клиентов, запоминая их анкетные данные (фамилия, имя, отчество). Начиная с 3-го обращения, клиент переходит в категорию постоянных клиентов и получает скидку в 3% при чистке каждой последующей вещи. Все оказываемые услуги подразделяются на виды, имеющие название, тип и стоимость, зависящую от сложности работ. Работа с клиентом первоначально состоит в определении объема работ, вида услуги и, соответственно, ее стоимости. Если клиент согласен, он оставляет вещь (при этом фиксируется услуга, клиент и дата приема) и забирает ее после обработки (при этом фиксируется дата возврата).

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

24 Сдача в аренду торговых площадей.

Описание предметной области.

Заказчиком является крупный торговый центр, сдающий в аренду коммерсантам свои торговые площади. Задачей является наведение порядка в финансовой стороне работы торгового центра.

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

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

1 Создание моделей бизнес-процессов с использованием программного средства RAMUS

Теоретическая часть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 может содержать два типа диаграмм:

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

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

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

1.2.2 Функциональный блок.

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

Рисунок 1.1 — Пример контекстной диаграммы

Для внесения имени функционального блока следует сделать по нему двойной щелчок, выбрать в редакторе свойств вкладку «Название» и внести имя блока (см.рисунок 1.2).

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

Появляется диаграмма декомпозиции (см.рисунок 1.4). Допустимый интервал числа работ 2 — 8.

Рисунок 1.2 — Редактор свойств функционального блока

Рисунок 1.3 — Диалог «Создание новой диаграммы»

Рисунок 1.4 — Пример диаграммы декомпозиции

Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.

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

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

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

Каждая из работ на диаграмме декомпозиции может быть, в свою очередь, декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рисунке 1.4 работа «Обработка звонка» имеет номер 1 и не была еще декомпозирована. Работа «Обработка заказа» (номер 4) имеет нижний уровень декомпозиции.

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

Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/стрелки, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока, — входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелки, входящие в блок сверху, — управления. Управления определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелки, покидающие блок справа, – выходы, т.е. данные или материальные объекты, произведенные функцией.

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

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

Стандартное расположение стрелок показано на рисунке1.5.

Рисунок 1.5 — Стандартное расположение стрелок

Стрелки представляют собой некую информацию, обозначаются существительными (например, «Устав», «Сотрудники», «Заказ») или именными сочетаниями (например, «Готовое изделие»).

Рассмотрим четыре типа стрелок, которые используются в Ramus.

Вход — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, «Сырье» — это нечто, что перерабатывается в процессе «Изготовление изделия» для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при «Приеме пациента» карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — «Заполненная карта пациента»). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет — управление.

Управление — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рисунке 1. 4 стрелки «Правила бух учета» — управление для работы «Оформление документов по заказу». Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.

Выход — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рисунке 1.4 стрелка «Информация о заказе» является выходом для работы «Обработка заказа».

Механизм — ресурсы, которые выполняют работу, например, персонал предприятия, программное обеспечение, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рисунке 1.4 стрелка «Менеджер» является механизмом для работы «Обработка заказа». По усмотрение аналитика, стрелки механизма могут не изображаться в модели.

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

Туннелирование стрелок. Туннель — круглые скобки в начале и/или окончании стрелки. Туннельные стрелки означают, что данные, выраженные этими стрелками, не рассматриваются на родительской диаграмме и/или на дочерней диаграмме.

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

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

Рисунок 1.6 — Туннелирование «не в дочерней работе»

Рисунок 1.7 — Туннелирование «не в родительской диаграмме»

Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется «не в родительской диаграмме».

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

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

Пункт «Туннель» позволяет использовать на диаграммах туннелирование стрелок. Пункт доступен только при вызове контекстного меню стрелки на отрезке, обрамлённом скобками. При выборе данного пункта откроется небольшое диалоговое окно с возможными вариантами действий (см.рисунок 1.8).

Рисунок 1.8 — Туннелирование стрелки в Ramus

В окне представлены два основных действия:

1) «Создать стрелку», позволяет отменить туннелирование и создать отрезок стрелки на родительской диаграмме или внутри функционального блока (зависит от расположения туннеля);

2) «Обозначить стрелку круглыми скобками», позволяет, собственно, туннелировать стрелку.

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

1) «Обозначить стрелку круглыми скобками (показывать в отчётах для дочерних элементов)». Выбор данного варианта обозначает, что данная стрелка будет считаться стрелкой управления, входа или механизма соответственно, для всех дочерних функциональных блоков данного функционального блока, хотя на диаграммах этого и не будет показано (см.рисунок 1.9).

Рисунок 1.9 — Туннелирование стрелки в Ramus на входе в функциональный блок

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

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

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

Несвязанные граничные стрелки. При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в Ramus как синтаксическая ошибка.

На рисунке 1.10 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся Ramus при декомпозиции работы «Обработка заказа» (см. рисунок 1.4).

Рисунок 1.10 — Пример несвязанных стрелок

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

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

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

В IDEF0 различают пять типов связей работ.

Связь по входу, когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей (например, на рисунке 1.11 стрелка «Информация о заказе» связывает работы «Обработка заказа» и «Оформление документов по заказу»).

Рисунок 1.11 — Связь по входу

Связь по управлению, когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рисунке 1.12 стрелка «Учебный план» связывает работы «Разработка учебного плана» и «Проведение занятий», при этом учебный план не претерпевает изменений в процессе проведения занятий.

Рисунок 1.12 — Связь по управлению

Обратная связь по входу, когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рисунке 1.13 стрелка «Заказ на доукомплектование» связывает работы «Комплектование заказа» и «Проверка заказа», при этом выявленный недоукомплектованный заказ направляется на повторное комплектование.

Рисунок 1.13 — Обратная связь по входу

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

Рисунок 1.14 — Обратная связь по управлению

Связь выход-механизм, когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (см.рисунок 1.15).

Рисунок 1.15 — Связь выход-механизм

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис.

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (см.рисунок 1.16).

Рисунок 1.16 — Пример именования разветвляющейся стрелки

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

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

1.2.4 Нумерация работ и диаграмм.

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, А3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядко-вый номер, например работы декомпозиции А3 будут иметь номера А31, А32, А33, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам.

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, Al, А2, А21, А213 и т.д.). Ramus автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. Ramus позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии. В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер — С-number, который должен присваиваться автором модели вручную. С-number — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например, AVI00021.

1.2.5 Рекомендации по рисованию диаграмм.

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около 10 стрелок. Если диаграмма содержит 6 — 8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пересекаться. Такие диаграммы могут стать очень плохо читаемыми.

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

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

2) Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы.

3) Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

5) Обратные связи по входу рисуются «нижней» петлей, обратная связь по управлению — «верхней» (см. рисунки 1.13, 1.14). Ramus автоматически рисует обратные связи нужным образом.

6) Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная и, в случае насыщенных диаграмм, творческая работа.

7) Если нужно изобразить связь по входу, необходимо избегать нависания работ друг над другом. В этом случае Ramus изображает связи по входу в виде петли, что затрудняет чтение диаграмм.

1.2.6 Проведение экспертизы.

Цикл автор-читатель. Этот цикл предназначен для обеспечения обратной связи при построении модели. Он включает определенные формализованные процедуры, предписывающие правила координации деятельности участников создания модели. В работе над моделью принимают участие специалисты разных профилей — аналитики (авторы), эксперты предметной области (читатели), библиотекари и комитет технического контроля. Обычно библиотекарь выделяется для больших проектов. Цикл «автор-читатель» содержит следующие этапы.

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

Все коммуникации при создании модели контролируются библиотекарем. Он ответственен за прохождение папок и архивирование диаграмм модели. После создания диаграмма посылается библиотекарю для помещения в архив.

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

Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы, в разделе «Замечания», зачеркнуть цифру, соответствующую номеру замечания (это делается на твердой копии диаграммы).

После рецензирования папки возвращаются библиотекарю. Библиотекарь должен обеспечивать проведение рецензирования в срок. Затем папки регистрируются и направляются автору.

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

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

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

1.2.7 Пример выполнения практического задания.

Описание предметной области «Формирование заказов».

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

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

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

В силу данного обстоятельства требуется не только формирование заказа контракта и счета клиента, но и формирование заявки для доставки соответствующих товаров на склад

На основании приведенного описания предметной области, используя методологию IDEF0, можно построить следующую функциональную модель, описывающую основные бизнес–процессы (см. рисунки 1.17 — 1.19).

Рисунок 1.17 — Контекстная диаграмма

Рисунок 1.18 — Диаграмма декомпозиции 1-го уровня

Рисунок 1.19 — Диаграмма декомпозиции 2-го уровня

(процесс «Произвести оформление документов на заказ»)

1.3 Дополнение созданной модели процессов диаграммами DFD

1.3.1 Диаграммы поисков данных (Data Flow Diagrams).

Диаграммы потоков данных (Data flow diagrams, DFD) известны очень давно. В фольклоре упоминается следующий пример использования DFD для реорганизации переполненного клерками офиса, относящийся к 20-м годам. Осуществлявший реорганизацию консультант обозначил кружком каждого клерка, а стрелкой — каждый документ, передаваемый между ними. Используя такую диаграмму, он предложил схему реорганизации, в соответствии с которой двое клерков, обменивающиеся множеством документов, были посажены рядом, а клерки с малым взаимодействием были посажены на большом расстоянии. Так родилась первая модель, представляющая собой потоковую диаграмму — предвестника DFD.

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

DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (миниспецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью диаграмм "сущность-связь" (Entity-Relationship Diagrams, ERD).

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

Для изображения DFD традиционно используются две различные нотации: Йодана (Yourdon) и Гейна‑Сарсона (Gane‑Sarson).

В Ramus для построения диаграмм потоков данных используется нотация Гейна‑Сарсона.

Основные символы DFD в нотации Гейна‑Сарсона изображены на рис. 1.20. Опишем их назначение. На диаграммах функциональные требования представляются с помощью процессов и хранилищ, связанных потоками данных.

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

Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним — двунаправленным.

Рисунок 1.20 — Основные символы диаграммы потоков данных

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

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

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

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

Если создается независимая DFD модель, то контекстная диаграмма содержит один процесс и внешние сущности (см.рисунок 1.21).

Рисунок 1.21 — Пример контекстной DFD диаграммы

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как данные двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы — движение данных, хранение данных, поставка и распространение данных (см.рисунок 1.22).

Рисунок 1.22 — Пример DFD диаграммы

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD система может рассматриваться как совокупность предметов. В этом случае функциональные блоки именуются по названию системы, например, «Система обработки информации».

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

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

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

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

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

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

1.3.2 Создание смешанной модели

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

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге «Создание новой диаграммы» кликнуть по радио-кнопке DFD (см.рисунок 1.23).

Рисунок 1.23 — Дополнение модели IDEF0 диаграммой DFD

Создается новая диаграмма DFD, и стрелки, которые касаются родительской работы, мигрируют на диаграмму нижнего уровня так, как если бы это была диаграмма IDEF0 (см.рисунки 1.24 и 1.25). Стрелки входа родительской работы на дочерней диаграмме DFD показываются входящими стрелками с левой стороны диаграммы DFD, стрелки управления — входящими стрелками с верхней стороны диаграммы и т. д.

Рисунок 1.24 — Декомпозируемый функциональный блок на диаграмме IDEF

Рисунок 1.25 — Диаграмма DFD. Декомпозиция процесса

«Принять заказ и ввести данные»

В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

1) Добавить в диаграмму внешнюю ссылку . Внешняя ссылка является источником или приемником данных извне модели.

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

Согласно нотации DFD диаграмма не должна иметь граничных стрелок-все стрелки должны начинаться и заканчиваться на работах, хранилищах данных или внешних сущностях. Поэтому, если строго следовать правилам нотации, следует:

1) Удалить все граничные стрелки на диаграмме DFD.

2) Создать соответствующие внешние сущности и хранилища данных.

Для этого нужно добавить в диаграмму внешнюю сущность или хранилище данных, выбрав соответствующую кнопку на панели инструментов, затем сделать по объекту двойной щелчок и в появившемся диалоговом окне выбрать кнопку «Задать DFD объект» (см.рисунок 1.26).

Рисунок 1.26 — Диалоговое окно «Свойства DFD объекта»

В появившемся диалоговом окне в контекстном меню выбрать пункт Создать элемент (см.рисунок 1.27).

Рисунок 1.27 — Создание элемента классификатора

Название классификатора можно ввести в созданную строку, дважды, медленно кликнув мышью по строке или же нажав клавишу F2, предварительно выделив нужную строку мышью (см.рисунок 1.28). Собственно, таким образом можно редактировать название любого классификатора из созданных (см.рисунок 1.29).

Рисунок 1.28 — Создание классификатора Внешние сущности

Рисунок 1.29 — Создание элемента Заказчик классификатора Внешние сущности

Для завершения создания элемента необходимо щелкнуть по кнопке ОК (см. рисунок 1.30)

Рисунок 1.30 — Завершение создания DFD объекта

Аналогично создаются хранилища данных (см.рисунок 1.31)

Рисунок 1.31 — Создание хранилища данных

3. Создать внутренние стрелки, начинающиеся с внешних сущностей вместо граничных стрелок.

4. Стрелки на диаграмме IDEF0 затуннелировать.

Результат этих действий представлен на рисунке1.32 и 1.33.

Рисунок 1.32 — Туннелирование стрелок на диаграмме IDEF0

Рисунок 1.33 — Замена граничных стрелок внутренними на диаграмме DFD

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

В результате дополнения диаграмм IDEF0 диаграммами DFD может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия. Иерархию работ в смешанной модели можно увидеть в окне Модели (см.рисунок 1.34). Для отображения окна Модели, необходимо выполнить действия, показанные на рисунке 1.35.

Рисунок 1.34 — Представление смешанной модели в окне Модели

Рисунок 1.35 — Отображение окна Модели

1.3.3 Создание модели DFD.

Для создания модели DFD, в рамках проекта, необходимо в окне Модели в контекстном меню выбрать пункт Создать модель, затем выбрать ее тип и задать свойства новой модели (см.рисунки 1.36 – 1.39).

Рисунок 1.36 — Создание новой модели в проекте

Рисунок 1.37 — Выбор типа модели

Рисунок 1.38 — Контекстное меню для выбора свойств модели

Рисунок 1.39 — Редактирование свойств модели

На основании приведенного в п.п.1.2.7 описания предметной области, используя методологию DFD, можно построить следующую модель, описывающую основные бизнес–процессы (см.рисунки 1.40 — 1.43).

Полное наименование системы:

Автоматизированная информационная система «Аренда легковых автомобилей».

Условное обозначение системы:

АИС «Аренда легковых автомобилей».

Список литературы

1. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.

2. ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

3. ГОСТ 34.603-92 Информационная технология. Виды испытаний автоматизированных систем.

4. Вендров А.М. Проектирование программного обеспечения экономических информационных систем.– М.: Финансы и статистика, 2002.

5. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М.: Финансы и статистика, 1998.

6. Пятибратов А.П., Гудыно Л.П., Кириченко А.А. Вычислительные системы, сети и телекоммуникации. – М.: Финансы и статистика, 2001.

7. Мишенин А.И. Теория экономических информационных систем. – М.: Финансы и статистика, 2000.

DFD (Data Flow Diagram) Диаграммы — зачем они нужны и какие бывают

Сегодня решил написать основную теорию про применение диаграмм потоков данных как одного из инструментов моделирования процессов.

Диаграмма отображает потоки данных между системами, базами данных. Ключевыми элементами являются входные/выходные данные, системы, точки хранения и сбора данных.

Зачем нужны DFD диаграммы?

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

при разработке информационной системы;

при интеграции системы;

при миграции данных и функционала с одной системы на другую;

в проектах, связанных с Data Management;

в процессе построения аналитического хранилища, BI-решения.

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

Элементы DFD диаграммы

Выделяют 4 элемента в диаграмме:

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

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

Все хранилища данных или отдельные файлы, которые хранят исходные или выходные данные, а также все промежуточные хранилища.

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

Несколько правил построения диаграмм:

Процесс должен иметь входной и выходной поток данных.

Хранилища данных также должны иметь входные и выходные потоки данных.

Данные с внешних сущностей должны обязательно проходить через процесс чтобы попасть в хранилище.

В DFD диаграммах также выделяют 2 разные нотации. Поэтому стоит обращать внимание на условные обозначения каждого элемента в зависимости от используемой нотации. Ниже представил картинку сравнения элементов разных нотаций.

Уровни DFD Диаграммы

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

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

Концептуальный (или контекстный) уровень.

Показывает общее описание процесса, который реализуется при потоке данных. Отображает абстрактно потоки данных, связанные с разными внешними сущностями

Отображает логику преобразования данных в системе в каждом процессе, описывает. Видны входные, промежуточные, выходные данные в каждом процессе, который протекает от внешней сущности до хранилищ данных. Больше указывает на вопрос “Что включает в себя процесс потока и обмена данными со стороны бизнеса?”

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

Также часто в других источниках можно увидеть разделение уровней диаграммы на 0,1, 2, 3 и так далее, в зависимости от уровня детализации.

Если мы говорим про разработку нового решения, то важно понять “что мы имеем сейчас” (AS-IS) и “что мы желаем получить” (TO-BE). Другими словами, мы разделяем наше текущее состояние и желаемое состояние, которое мы хотим получить с помощью нашего решения.

Описываем текущую логическую диаграмму.

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

Элементы графической нотации DFD.

В современной практике используются два вида графической нотации DFD — нотация Йордана и нотация Гейна — Сарсона. Графические элементы приведены в табл. 4.1.

Элементы графической нотации DFD

Нотация Гейна — Сарсона

Процесс (система, подсистема)

На практике чаще всего можно встретиться с диаграммами, выполненными в нотации Гейна — Сарсона.

Описание элементов нотации DFD.

Приведенная выше таблица показывает, что в нотации DFD используются четыре типа элементов. Рассмотрим эти элементы подробнее.

• 1. Поток данных — это информация, которая передается от источника к приемнику посредством соединения. Поток данных в DFD — это аналог Входов и Выходов в IDEF0. На практике поток данных — это информация, которая передается по кабелю между устройствами; письма, отправляемые по почте; информация, переносимая с помощью съемных носителей (карты памяти, CD-диски и т.п.).
• 2. Процесс — это преобразование входных потоков данных в выходные на основе заранее определенных алгоритмов (аналог Функции/Работы в IDEF0). Как правило, процессы обозначаются при помощи глаголов неопределенной формы (вычислить, проверить, рассчитать и т.п.). В ряде случаев процесс может рассматриваться с точки зрения подсистемы.

В этом случае он будет обозначаться как, например, «Подсистема расчета стоимости» и т.п.

• 3. Накопитель данных — абстрактное устройство для хранения информации, причем информация может быть помещена в него или извлечена в любое время без указания конкретных способов. Па практике накопитель данных всегда имеет физическую реализацию (оперативная память, жесткий диск, ящик в картотеке и т.п.).
• 4. Внешняя сущность — это материальный объект или физическое лицо, которое является приемником или источником информации (потребитель, клиент, сотрудник, руководитель, библиотека, склад и т.п.). Внешняя сущность — это аналог Управления или Механизма в IDEF0.

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

Рис. 4.5. Пример диаграммы DFD, выполненной в нотации Гейна — Сарсона (программное средство Ramus Educational)

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

Создание и редактирование функциональных моделей в Ramus Educational

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

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

Интернет сайт должен использоваться для дистанционной поддержки обучения студентов кафедры ИС. На сайте должны быть размещены материалы, необходимые для изучения студентами дисциплин, преподаваемых на кафедре, преподаватели, ведущие занятия со студентами, расписание занятий, программное обеспечение, распространяемое бесплатно и необходимое студентами для изучения материалов учебных дисциплин, а так же новости и объявления, публикуемые преподавателями кафедры. На сайте должны быть представлены тесты, предназначенные для проверки знаний студентов по каждой дисциплине. Тесты доступны только зарегистрированным студентам. Результаты теста фиксируются в системе, а преподаватель получает уведомление о результатах прохождения тестов студентами. На сайте должен быть реализован режим анкетирования, при котором студенту предлагается заполнить анкету, т.е. дать ответы на некоторые вопросы, предложенные преподавателями. Анкетирование предназначено для выявления недостатков преподавания и корректировки системы обучения на кафедре.

Paботу с сайтом можно у словно разделить на работу студента, работу преподавателя, работу администратора. Студент, обратившись к сайту, имеет возможность просматривать все его разделы, скачивать файлы и т.д.. по не имеет возможности проходить тестирование и участвовать в анкетировании. Для того, чтобы эти возможности стали доступны студенту, ему необходимо пройти процесс регистрации, в ходе которого он выбирает себе НИК (login) и пароль, а так же вводит необходимые сведения о себе. В последствии, при подключению к сайту, студент должен иметь возможность авторизоваться на нем. введя свой ник и пароль для получения полного доступа ко всем ресурсам сайта. При прохождении теста, его результаты запоминаются в базе данных. Таким образом, накапливается статистика о результатах обучения студента, которую может использовать преподаватель для выставления окончательной экзаменационной оценки студенту по данной дисциплине. Преподаватель, обратившись к сайту имеет те же возможности, что и студент до тех пор . пока не пройдет процедуру авторизации (вход в систему). Для осуществления возможности входа в систему преподаватель так же должен пройти процедуру регистрации в системе, в ходе которой ввести ник. пароль и дополнительную информацию о себе. После входа в систему, преподаватель, помимо просмотра всех разделов сайта, ответов на контрольные вопросы и анкетирования, имеет возможность публиковать новости и объявления в соответствующих разделах сайта, а так же размещать все возможные материалы, касающихся своих курсов и других видов учебной работы. Кроме прочего, преподавателю должна быть доступна статистика ответов на вопросы контрольных тестов и анкет всех дисциплин, публикуемых на сайте. Преподаватель так же имеет возможность просматривать и корректировать списку студентов, обучающихся в «его» группах, а так же публиковать в специальном разделе сайта рейтинговые и экзаменационные оценки.

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

Основные функции образовательного интернет сайта:

• — тестирование;
• — анкетирование;
• — добавление информации (новости, объявления и др.);
• — формирование статистики.

Начало работы программы:

• 1. Запускаем программу Ramus Educational. Далее создаем новый проект.
• 2. После создания проекта осуществляется запуск мастера проекта.
• — на первом шаге в соответствующие поля вносим сведения об авторе, названии проекта и модели, а также выбираем тип нотации модели (IDEF0 или DFD);
• — на втором шаге вводим название организации, использующей данный проект;
• — на третьем шаге — даем краткое описание будущего проекта;
• — четвертый шаг позволяет создать несколько основных классификаторов (в данном случае можно пропустить этот шаг). Так как модель программного обеспечения может хранить значительное количество объектов (статистика, преподаватели, расписание, материалы и т.д.), то в Ramus предусмотрена возможность упорядочено хранить информацию об этих объектах в виде системы классификаторов. Классификация объектов упрощает поиск и обработку информации об объектах модели, а так же и об объектах непосредственно не представленных на диаграммах процессов, но относящихся к процессам образовательного интернет сайта;
• — на пятом шаге, предлагается выбрать классификаторы из созданных ранее (данный шаг пропускаем).

При необходимости можно завершить работу мастера.

После завершения работы мастера, отрывается рабочее пространство, в котором создается графическая модель. В верхней части приводятся сведения о проекте, введенные пользователем посредством мастера диаграмм.