Диаграмма бизнес функций это

Согласно РД 50-34.698-90 «Автоматизированные системы требования к содержанию документов», документ «Схема функциональной структуры» содержит:

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

Ниже представлен пример формирования схемы функциональной структуры с использованием AllFusion Process Modeler (Bpwin) в формате IDEF0. Схема функциональной структуры разрабатывается на этапе технического проектирования. В качестве примера для формирования схемы функциональной структуры в формате IDEF0 была взята система аналитического хранилища данных и ее подсистемы.

Повышение наглядности диаграмм бизнес-процессов (на примере IDEF0-диаграммы процесса производства)

Элементы функциональной структуры

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

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

1. подсистема сбора, обработки и загрузки данных — предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных;
2. подсистема хранения данных — предназначена для хранения данных в структурах, нацеленных на принятие решений;
3. подсистема формирование и визуализации отчетности — предназначена для формирования бизнес-ориентированных витрин данных и отчетности.

Функции и задачи подсистем Системы

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

Подсистема сбора, обработки и загрузки данных

Функция Задача

Управляет процессами сбора, обработки и загрузки данных	Создание, редактирование и удаление процессов сбора, обработки и загрузки данных
	Формирование последовательности выполнения процессов сбора, обработки и загрузки данных (регламентов загрузки данных)
	Определение и изменение расписания процессов сбора, обработки и загрузки данных
Выполнение процессов сбора, обработки и загрузки данных из источников в ХД	Запуск процедур сбора данных из систем источников, загрузка данных в область временного, постоянного хранения
	Обработка и преобразование извлечённых данных
	Поддержка медленно меняющихся измерений
Протоколирует результаты сбора, обработки и загрузки данных	Ведение журналов результатов сбора, обработки и загрузки данных
	Оперативное извещение пользователей о всех нештатных ситуациях в процессе работы подсистемы

Подсистема хранения данных

Функция Задача

Создание и сопровождение структуры базы данных	Поддержка (разработка, модификация) модели ХД
	Создание таблиц, представлений, материализованных представлений, последовательностей, табличных пространств, функций, пакетов, триггеров
Запись, хранения и модификация данных	Выполнение операций в терминах языка SQL (Insert, Update, Delete)
	Сохранение значений ранее загруженных данных в случае их изменения
	Архивирование малоиспользуемой информации
Резервное копирование данных	Осуществление полного холодного копирования
	Осуществление логического копирования
	Осуществление инкрементального резервного копирования
Предоставление данных	Выполнение операции предоставления данных в терминах языка SQL (Select)
Протоколирование результатов работы подсистемы	Ведение журналов событий СУБД
	Оперативное извещение администратора СУБД о всех нештатных ситуациях

Подсистема формирования и визуализации отчетности

Функция Задача

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

Информационные связи между элементами Системы с внешней средой

В разделе приводится модель в нотации IDEF0, отражающая информационные связи между элементами (подсистемами) информационной системы и внешней средой.

Современные нотации описания бизнес-процессов

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

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

Основными объектами модели являются:

1. Функциональные блоки. Отражают название функциональных подсистем.
2. Стрелки управления (сверху функционального блока). Отражают команды (запросы от пользователей или других подсистем) и инструкции, влияющие на работу подсистемы.
3. Стрелки входа (слева от функционального блока). Отражают входящие потоки данных из внешней среды или другой подсистемы.
4. Стрелки выхода (справа от функционального блока). Отражают исходящие потоки (результаты работы подсистемы) данных во внешнюю среду (пользователям и администраторам) или в другую подсистему.
5. Стрелки исполняющего механизма (снизу функционального блока). Отражают средства (программное обеспечение, людские ресурсы), которые используются при работе подсистемы.

Детализированные схемы частей функциональной структуры

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

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

Ковтун М.В. Октябрь 2010

Источник: www.prj-exp.ru

Функциональное проектирование ИС. Декомпозиция всей системы на некоторое множество иерархически подчиненных функций. Основные идеи структурного анализа. — презентация

Презентация на тему: » Функциональное проектирование ИС. Декомпозиция всей системы на некоторое множество иерархически подчиненных функций. Основные идеи структурного анализа.» — Транскрипт:

1 Функциональное проектирование ИС

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

3 В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы: 1. Диаграмма бизнес-функций BFD (Business Function Diagram) (функциональные спецификации, диаграммы иерархии функций) 2. Диаграмма потоков данных ДПД DFD (Data Flow Diagram ). 3. Диаграммы переходов состояний (ДПС) – STD (State Transition Diagram)

4 В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы: 4. Диаграмма «сущность – связь». ERD (Entity Relationship Diagram) ER – модель данных предметной области. 5. Диаграмма структуры программного приложения SSD (System Structure Diagram).

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

6 Изображение объектов диаграммы иерархии функций Объект ЙоданаГеина- Сарсона SADTSAG Функция Декомпозиция функции иерархи- чески связанные уровни детализации Имя, Имя Имя

7 Диаграммы бизнес-функций Входные данные для технологической операции «Построение диаграммы бизнес-функций: материалы обследования системы. Этапы построения диаграммы бизнес-функций: отображение основной функции; декомпозиция основной функции на подфункции; дальнейшая декомпозиция подфункций до необходимой степени детализации ; контроль правильности построенной диаграммы.

8 Организация товародвижения на складе Прием товара Отпуск товара Ведение БД «Движение товара» Инвентарный контроль Фрагмент диаграммы иерархии функций для задачи аналитического учета товаров на складе

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

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

11 Основные понятия ДПД Источник/приемник информации – некий внешний объект системы. Контекстная диаграмма – самый верхний процесс декомпозиции системы, отражающий общие представления о системе. Цель построения иерархически взаимосвязанных диаграмм потоков данных — необходимость сделать требования к системе ясными на каждом уровне детализации.

12 Изображение объектов диаграммы потоков данных Объект ЙоданаГеина- Сарсона SADTSAG Процесс Поток данных Хранилище данных Нет Имя, Имя Имя БД

13 Изображение объектов диаграммы потоков данных Объект ЙоданаГеина- Сарсона SADTSAG Источник/ приемник информации Текстовая метка Имя

14 Рекомендации при построении ДПД на каждом уровне представлять 3 – 6 процессов и не более; выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД; не загромождать диаграмму несущественными моментами на данном уровне детализации.

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

16 1. Идентификация внешних объектов по отношению к системе. Алгоритм построения диаграммы потоков данных 2. Идентификация информации, которая передается между процессами. 3. Разработка контекстной диаграммы. 4. Формирование ДПД первого уровня, где отражены основные функции системы. 5. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить в виде алгоритма.

17 Контекстная диаграмма проекта «Разработка ПО»

18 Формирование ДПД первого уровня (основные функции системы)

19 Результат декомпозиции функции – Планирование и проектирование разработки продукта

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

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

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

22 Рекомендации при построении ДПС необходимо построение диаграммы переходов состояний на высоком уровне детализации диаграммы потоков данных; строить диаграммы, содержащие 4 – 6 состояний; использовать те же наименования состояний, что и при наименовании процессов и потоков.

23 материалы обследования системы. диаграмма «сущность – связь». Входные данные для технологической операции «Построение ДПC»: диаграмма бизнес-функций (иерархии) функций; диаграмма потоков данных;

24 Применяются 2 способа построения диаграммы переходов состояний: I. Cначала выявляются возможные состояния системы, далее – возможные переходы из одного состояния в другое. II. Cначала строится начальное состояние, затем осуществляется последовательный переход в очередное состояние.

25 Изображение объектов диаграммы переходов состояний Объект ЙоданаГеина- Сарсона SAGSADT Состояние Нет Начальное состояние Нет Переход Нет Триггер Имя () Условие перехода Действие перехода Условие перехода Действие перехода Имя

26 Оформление прихода товаров Данные о приходе Ведение базы данных «Движение товаров»

27 Диаграмма «сущность – связь» ERD (Entity Relationship Diagram) ER – модель данных предметной области. Моделирует структуры данных, которые будут храниться в БД. Эта диаграмма представляет собой набор множества объектов и их характеристик, а также взаимосвязей между ними, нужных для выявления данных, которые в дальнейшем используются функциями проектируемой системы.

28 Основные понятия диаграммы «сущность-связь» Сущность – представляет собой множество экземпляров реальных или абстрактных объектов, которые обладают общими свойствами (атрибутами). Отношение – связь между 2 и более сущностями. Независимая сущность – независимые данные, которые всегда присутствуют в системе. Зависимая сущность – данные, которые зависят от других сущностей.

29 Изображение объектов диаграммы «сущность-связь» Объект ЧенаБеркераSAGSADT Независимая сущность Начальное состояние Отношение (связь) Имя Список атрибутов Имя Список атрибутов Имя Список атрибутов Имя Список атрибутов Имя Список атрибутов Имя

30 материалы обследования системы. Входные данные для технологической операции «Построение диаграммы сущность-связь»: диаграмма потоков данных; Этапы построения диаграммы «сущность — связь»: 1. Идентифицируются все сущности, их атрибуты. 2. Идентифицируются отношения между сущностями. 3. Если были выявлены отношения N:N, то их нужно преобразовать либо 1:N, либо 1:1 с помощью добавления новой сущности.

31 Диаграмма структуры программного приложения SSD (System Structure Diagram) Структура программного приложения (SSD) представляет собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Входные данные: диаграмма «сущность – связь»; диаграмма бизнес-функций (иерархии) функций; диаграмма потоков данных; диаграмма переходов состояний.

32 1. В диаграмме бизнес-функций необходимо выделить функции, которые будут реализованы в программном виде. Этапы построения диаграммы структуры программного приложения 2. Провести анализ входных и выходных потоков диаграммы потоков данных для выделенных функций. 3. Определить структуру потоков данных, задав список атрибутов сущностей из диаграммы «сущность – связь».

33 4. На диаграмме переходов состояний определить состояния, переходы и вызывающие их события, которые реализуют бизнес-функции. Этапы построения диаграммы структуры программного приложения 5. Выполнить программную реализацию каждого состояния в виде библиотечного модуля CASE- системы. 6. Создать эскиз системной структурной диаграммы для каждой выделенной функции.

34 7. Объединить построенные системные структурные диаграммы в одну, исходя из диаграммы иерархии функций. Этапы построения диаграммы структуры программного приложения 8. Проконтролировать системную структурную диаграмму, если позволяют CASE-средства, 9. Макетирование (прототипирование) интерфейса программного приложения на основе системной структурной диаграммы.

35 10. Для каждого модуля выбрать шаблон интерфейса из встроенной библиотеки либо в режиме конструктора создать шаблон (написать программный модуль на встроенном языке программирования). Этапы построения диаграммы структуры программного приложения

36 Изображение объектов диаграммы структуры программного приложения Объект Константе ин SAGSADT Модуль Библиотечный модуль Вызов модуля Имя

Источник: www.myshared.ru

Разработка диаграмм модели бизнес-процесса в среде ARIS

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

Уровни представления моделей

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

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

Это различие выражено в трехярусной модели ARIS.

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

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

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

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

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

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

Организационное моделирование.

Диаграмма организационной структуры — Organizational chart

В организационном описании различают организацию структуры предприятия и организацию процедур выполнения ее БП. В организационном виде моделирования в первую очередь описывают структуру предприятия. Универсальной «совершенной» организационной структуры-прототипа не существует. Оптимальное структурирование организации зависит от различных факторов.

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

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

На рисунке 2 описана организационная структура регистратуры ООО «СтильДент».

В задачи и функции регистратуры входит:

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

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

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

В соответствии с поставленными задачами регистратура осуществляет:

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

o информирование о порядке предварительной записи на прием к врачам, о времени и месте приема населения главным врачом и его заместителями;

o предварительную запись на прием к врачам стоматологии, выдачу талонов на прием;

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

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

Рисунок 2. Оргструктура регистратуры «СтильДент» в нотации Organization Chart

Technical resources — Модель технических ресурсов.

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

При выполнении работы по составлению отчетности специалисты ЦТО используют технические ресурсы.

Technical resources — Модель технических ресурсов.

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

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

Рисунок 3 — Операционные ресурсы, используемые специалистами регистратуры в нотации диаграммы Technical Resources

Моделирование данных

Information carrier diagram — Диаграмма носителей информации.

Диаграмма носителей информации предназначена для структурированного описания документов организации. Диаграмма носителей информации регистратуры ООО «СтильДент» в нотации Information Carrier Diagram представлена на рисунке

Рисунок 4 — Диаграммы носителей информации регистратуры ООО «СтильДент» в нотации Information Carrier Diagram

Процессное моделирование

Knowledge map — Карта знаний

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

Рисунок 5 — Требования к знаниям регистратора в нотации Knowledge map

Таблица 4 — Детализирующие связи для диаграммы КМ

Наименование детализируемого объекта

Источник: studentopedia.ru