Методические основы проектирования ИС управления экономической деятельностью презентация

Технологии проектирования ИС

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

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

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

Этапы развития технологий проектирования ИС
1. Метод "снизу-вверх" - не создание тиражируемых продуктов, а обслуживание сотрудников конкретного учреждения. Успешно автоматизируются отдельные, важные с точки зрения руководства рабочие места. («Лоскутная автоматизация»)
2. Метод "сверху-вниз " - из всего спектра проблем разработчики выделили наиболее заметные: автоматизацию ведения бухгалтерского аналитического учета и технологических процессов. Системы были спроектированы "сверху", т.е. в предположении что одна программа должна удовлетворять потребности всех пользователей: резко ограничены возможности разработчиков в структуре информационных множеств базы данных, использовании вариантов экранных форм, алгоритмов расчета и, следовательно, лишила возможности по ведению глубокого, часто специфического аналитического и производственно - технологического учета.

Технология проектирования DATARUN
Компания
PDS – структура первичных данных
CDM – концептуальная модель данных
BPM – модель бизнес-процессов
SPM – модель процессов системы
ISA – архитектура ИС
IPM – модель представления интерфейса
ISM – модель спецификации интерфейса
ADM – модель данных приложений
Технология структурного моделирования

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

Модель ИС

Технология проектирования RUP
Компания
модель бизнес-процессов
описания бизнес-процессов
модель состояний
модель бизнес-сущностей
модель ролей
модель бизнес-правил
модель структуры
Бизнес-моделирование
модель функций системы
экранные формы
модель работы пользователей
Анализ и проектирование
модель размещения
модель данных
модель разработки
Определение требований
Технология объектно-ориентированного моделирования
Описание
деятельности
предприятия

Моделирование как основа проектирования ИС

Процесс разработки ИС - процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла ИС.
Модели:
организации,
деятельности организации,
требований к ИС,
проекта ИС,
требований к приложениям и т.д.

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

Организационно-функциональная модель
Функция – это обособленный вид деятельности компании. Функции выполняются постоянно.

Шаблон распределения функций по организационным звеньям
Определяет состав и распределение рабочих мест пользователей ИС
Матрица проекций

Цикл реструктуризации
Продуктовая модель
Функциональная модель
+
Функциональная модель
Организационная модель
+
+
+
+
Проверка на соответствие

Задачи моделирования
бизнес-процессов

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

Обобщенная модель бизнес-процесса
Организация Подразделение Работник
Вход
Выход
Ресурсы:
Сырье
Промежуточная продукция
Информация
Деньги
Преобразование ресурсов, добавляющее стоимость
Продукты: Топливо
Прибор
Счет-фактура
Промежуточная продукция
Информация
Бизнес-процессы
Бизнес-процесс – модель преобразования сущностей типа «вход-выход», рассматриваемая как работа по реализации предписываемой функции

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

Технологии и инструментальные средства моделирования бизнес-процессов.
Структурный анализ – метод исследования системы, которое начинается с общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней.
Объектно-ориентированное моделирование - подразумевает описание статической структуры системы в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект обладает своим собственным поведением, моделирующим поведение объекта реального мира.
Технология Aris – управляемые событиями модели
Программные средства: IDEF Designer, ERwin\BPwin, Oracl Designer, BPM Workbench, Aris, Rational Rose

Общая методология IDEF
В настоящее время включает ряд частных методологий для моделирования систем, в том числе:
IDEF0 - функциональное моделирования
IDEF1 - информационное моделирование
IDEF1X - моделирование данных
IDEF3 - моделирование процессов
IDEF4 - объектно-ориентированное проектирование и анализ
IDEF5 - определение онтологий (словарей)
IDEF9 - моделирование требований

СТАНДАРТЫ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ
Ключевой особенностью стандарта IDEF является то, что основной синтаксической единицей является "работа", или "деятельность" ("activity“). Таким образом, анализу подвергается не только форма (например, правовая или организационная структура компании), и не только результат ее деятельности (например, финансовые или иные показатели), а сама деятельность в деталях. Анализ предприятия путем построения модели в стандарте IDEF0 позволяет понять, как именно достигается результат деятельности предприятия.

Общая модель бизнес-процесса

СТАНДАРТЫ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ
IDEF0 (AS-IS TO-BE) – совокупность иерархически упорядоченных и взаимосвязанных диаграмм.
DFD (Data Flow Diagramming) – описание документооборота и обработки информации.
IDEF3 (Workflow Diagramming) – возможность описания процессов и объектов, участвующих совместно в одном процессе.

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

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

IDEF0
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами.
Точка зрения (Viewpoint). Точка зрения должна соот­ветствовать цели моделирования. Для документирования дополнительных альтернативных точки зрения используют диаграммы FEO (For Exposition Only).

IDEF0
Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
Почему этот процесс должен быть замоделирован?
Что должна показывать модель?
Что может получить пользователь?

IDEF0
Модель может содержать четыре типа диаграмм:
контекстную (в каждой модели может быть только одна контекстная диаграмма);
декомпозиции;
дерева узлов;
только для экспозиции (FEO).

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

Диаграмма декомпозиций

Создание модели в стандарте IDEF0
ВХОД (нечто, что перерабатывается системой), ВЫХОД (результат деятельности системы), УПРАВЛЕНИЕ (стратегии и процедуры, под управлением которых производится работа) и МЕХАНИЗМ (ресурсы, необходимые для проведения работы).
Находясь под управлением, система преобразует входы в выходы, используя механизмы.

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

Каркас диаграммы
Used At - используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова
REV - дата последнего редактирования диаграммы
Notes - используется при проведении сеанса экспертизы
Status - статус отображает стадию создания диаграммы, отображая все этапы публикации
Working - новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы
Draft - диаграмма прошла первичную экспертизу
Recommended - диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается
Publication - диаграмма готова к окончательной печати и публикации
Reader - имя читателя (эксперта)
Date - дата прочтения (экспертизы)
Context - схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показана надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы.

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

Стрелки (Arrow)

Стрелки (Arrow)

Связь по входу

Связь по управлению

Обратная связь по входу

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

Связь по выход-механизм

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

Пример неверного именования разветвляющейся стрелки

Неразрешенная (unresolved) стрелка

Типы тоннелирования стрелок

Нумерация работ и диаграмм
Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, A1, A2, А21, А213 и т.д.).
Model Properties (меню Edit/Model Properties).

Рекомендации по построению диаграмм
Прямоугольники работ должны располагаться по диагонали с левого верхнего в правый нижний угол (порядок доминирования). Порядок доминирования подчеркивает взаимосвязь работ, позволяет минимизировать изгибы и пересечения стрелок.
Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. (Model/Model Properties/Layout/Automatically space arrows - расположение стрелок нужным образом автоматически.)
Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

Проверка синтаксиса модели
Tools/Reports/Model Consistency Report
Preview (предварительный просмотр списка синтаксических ошибок модели)
Список синтаксических ошибок может включать: неименованные функциональные блоки и стрелки (unnamed arrows, unnamed activities), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connection), блоки, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления и т.д.

Дополнение созданной модели процессов диаграммами DFD и Workflow (IDEF3)
В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.
DFD описывает:
функции обработки информации (работы);
документы (стрелки, arrow), объекты, сотрудников или отделы, которые участвуют в обработке информации;
внешние ссылки (external references), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;
таблицы для хранения документов (хранилище данных, data store).

Компоненты DFD-диаграмм
Внешний объект – материальный объект или физическое лицо, представляющее собой источник или приемник информации (заказчик, поставщик, склад, ГНИ …)
Хранилище данных – абстрактное устройство для хранения
информации, которую можно в любой момент поместить или извлечь из хранилища (база данных, картотека …) (способы размещения и извлечения информации не описываются)
Стрелки – определяют перемещение потоков объектов от одного блока к другому. Могут быть двунаправленными.
Ветвление стрелок отображает декомпозицию или объединение данных.
Записать адрес клиента
Проверить индекс
Проверить город
Проверить улицу
Адрес
клиента
Почтовый
индекс
Город
Улица

DFD-диаграмма "Оформление и выдача трудовой книжки сотруднику при увольнении" (нотация Гейна-Сарсона)

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.
Представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities)
Дополнение модели IDEF0 диаграммой DFD

Дополнение модели IDEF0 диаграммой DFD

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

В результате BPwin позволяет создавать на диаграмме DFD четыре типа граничных стрелок (рис. 1.4.36, сверху вниз):
обычная граничная стрелка (не допускается нотацией DFD);
межстраничная ссылка;
тоннельная стрелка (не предусмотрена нотацией DFD);
внешняя ссылка.
Дополнение модели IDEF0 диаграммой DFD

Граничные стрелки на диаграмме DFD

Пример диаграммы DFD

Пример DFD-диаграммы

Пример DFD-диаграммы

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

Схема бизнес-процесса в стандарте IDEF3

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

Типы связей между работами в стандарте IDEF3.

Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы расхождения.

Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы схождения.

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

BPwin
ERwin
Paradigm Plus
Model Mart
Arena
EasyABC
Формат
IDL
Word,
Excel,
HTML
Общая схема взаимодействия BPwin с программными продуктами Computer Associates и других фирм
Моделирование
данных
Организация кол.
работы
Объектное моделирование
Имитационное моделирование
Стоимостной анализ
Экспорт отчетов
Другие CASE-средства

Деятельность отдела учета налогоплательщиков – организаций ГНИ
Учредительные документы
Данные о налогоплательщике

ERD-описание БД «Налогоплательщики»
Имеет
Учредитель
ИНН
ЮР. лицо
Код ОПФ
Наименование
Адрес
Номер паспорта
Серия паспорта
Физ. лицо
Имеет
Счет
Номер счета
Тип счета
Имеет
Банк
Наименование
БИК
Кор. Счет
Адрес
(1,N)
(1,N)
(1,1)
(1,1)
(1,1)
(0,N)
(0,1)
(0,1)
(1,1)
(1,1)
Is-a (1)
Is-a (2)
Связь «супертип-подтип»

Структура модели деятельности предприятия
Процессы
SADT DFD
Контекст