2.3 Построение модели деятельности предприятия
Бурное развитие информационных технологий является причиной постоянного роста сложности информационных систем, разрабатываемых для различных областей деятельности человека. Как правило современные информационные системы обладают следующими особенностями:
огромное количество взаимосвязанных процессов и функций приводит к сложности описания требующей детального анализа данных и моделирования процессов;
множество тесно взаимодействующих подсистем имеющие свои внутренние функции;
отсутствие взаимосвязей и различия отдельных групп разработчиков по уровню квалификации и паттернам использования тех или иных инструментальных средств;
отсутствие аналогов, ограничивающее возможность использования каких-либо типовых проектных решений и прикладных систем;
необходимость внедрения новых и существующих приложений в бизнес процессы;
функционирование в неоднородной среде на нескольких аппаратных платформах.
Для достижения всех целей разрабатываемой информационной системой, объект исследования должен быть детально проанализирован и описан. Так же должны быть построены подробные функциональные и информационные модели информационной системы. До недавнего времени проектирование информационных систем выполнялось с применением неформализованных методов, основанных на искусстве, практическом опыте, экспертных оценках и дорогостоящих экспериментальных и проверках качества функционирования информационных систем. Кроме того, в процессе создания и функционирования информационных систем, информационные потребности пользователей могут изменяться или уточняться, что еще более усложняет разработку и сопровождение таких систем.
2.3.1 Проектирование бизнес процессов с помощью IDEF0
IDEF0-модели состоят из документов трех типов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма - главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта.
Диаграмма верхнего уровня обеспечивает наиболее общее описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте.
Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А-0 (А минус ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма А-0 устанавливает область моделирования и ее границу [2].
Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
верхняя сторона имеет значение «Управление» (Control);
левая сторона имеет значение «Вход» (Input);
правая сторона имеет значение «Выход» (Output);
нижняя сторона имеет значение «Ресурсы» (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
2.3.2 Проектирование бизнес процесса аудита веб-приложения
Построим бизнес процесс аудита приложений с помощью методологии IDEF0.
На рисунке 13 представлена контекстная диаграмма данного процесса. Далее опишем дуги этой диаграммы.
Согласно правилам IDEF0 ко входу относятся:
К управляющим документам относятся:
законодательство РФ (Российской федерации), в частности Федеральный закон от 27.07.2006 N 149-ФЗ (ред. от 13.07.2015) «Об информации, информационных технологиях и о защите информации» (с изм. и доп., вступ. в силу с 10.01.2016);
устав компании.
На выходе будем наблюдать:
отчет;
решения по корректности работы приложения.
К механизмам отнесем:
информационная система;
материально техническое обеспечение (МТО);
персонал.
Рисунок 13 – Процесс аудита веб-приложения
Уровень А-0 наиболее важный в модели. На этом уровне моделируется функционально-структурная схема логической группы процессов.
Декомпозиция контекстной диаграммы «Процесс аудита веб-приложения» представлена на рисунке 14 и включает в себя пять под процессов:
формирование задачи;
создание аудита;
аудит;
формирование отчета;
анализ аудита.
Рисунок 14 – Декомпозиция блока «Процесс аудита веб-приложения»
Более подробно процесс аудита веб-приложения описан в таблице 3.
Таблица 3 – Описание бизнес-процесса аудита веб-приложения
№
|
Процесс
|
Владелец
|
Исполнители
|
Входы
|
Выходы
|
Тип
|
Название
|
Объекты
|
Название
|
Объекты
|
1.
|
A1 Формирование задачи
|
Генеральный директор
|
Начальник отдела продвижения
|
Управление
|
Устав компании
|
Устав компании
|
Задача
|
Данные об объекте аудита
|
ФЗ-149 «Об информации, информационных технологиях и о защите информации»
|
ФЗ-149
|
Механизм
|
Пользователь
|
|
Продолжение таблицы 3
№
|
Процесс
|
Владелец
|
Исполнители
|
Входы
|
Выходы
|
Тип
|
Название
|
Объекты
|
Название
|
Объекты
|
2.
|
A2 Создание аудита
|
Генеральный директор
|
Начальник отдела продвижения
|
Вход
|
Задача
|
Данные об объекте аудита
|
Id Аудита
|
Настройки аудита
|
Ссылка на приложение
|
Данные об объекте аудита
|
Управление
|
ФЗ-149 «Об информации, информационных технологиях и о защите информации»
|
ФЗ-149
|
Механизм
|
Информационная система
|
|
МТО
|
|
Продолжение таблицы 3
№
|
Процесс
|
Владелец
|
Исполнители
|
Входы
|
Выходы
|
Тип
|
Название
|
Объекты
|
Название
|
Объекты
|
3.
|
A3 Аудит
|
Разработчик системы
|
|
Вход
|
Id Аудита
|
Настройки аудита
|
Характеристики
|
Характеристики
|
Управление
|
ФЗ-149 «Об информации, информационных технологиях и о защите информации»
|
ФЗ-149
|
Механизм
|
Информационная система
|
|
МТО
|
|
Продолжение таблицы 3
№
|
Процесс
|
Владелец
|
Исполнители
|
Входы
|
Выходы
|
Тип
|
Название
|
Объекты
|
Название
|
Объекты
|
4.
|
A4 Формирование отчета
|
Генеральный директор
|
Начальник отдела продвижения
|
Вход
|
Характеристики
|
Характеристики
|
Отчет
|
Отчет
|
Управление
|
ФЗ-149 «Об информации, информационных технологиях и о защите информации»
|
ФЗ-149
|
Механизм
|
Информационная система
|
|
МТО
|
|
5.
|
A5 Анализ аудита
|
Генеральный директор
|
Начальник отдела продвижения
|
Вход
|
Отчет
|
Отчет
|
Решения по корректности работы приложения
|
|
Управление
|
Устав компании
|
Устав компании
|
Механизм
|
Пользователь
|
|
Для наглядного примера взаимодействия пользователя с информационной системой построим диаграмму последовательностей в UML.
UML – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью [26].
Диаграмма последовательности – диаграмма, на которой показано взаимодействие объектов, упорядоченное по времени, с отражением продолжительности обработки и последовательности их проявления.
Основными элементами диаграммы последовательности являются обозначения объектов, вертикальные «линии жизни», отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции, и стрелки, показывающие обмен сигналами или сообщениями между объектами.
В UML различают следующие виды сообщений:
синхронное сообщение – соответствует синхронному вызову операции и подразумевает ожидание ответа от объекта получателя. Пока ответ не поступит, никаких действий в Системе не производится;
асинхронное сообщение – которое соответствует асинхронному вызову операции и подразумевает, что объект может продолжать работу, не ожидая ответа;
ответное сообщение – ответное сообщение от вызванного метода. Данный вид сообщения показывается на диаграмме по мере необходимости или, когда возвращаемые им данные несут смысловую нагрузку.
Диаграмма последовательности процесса «Создание аудита» представлена на рисунке 15.
Рисунок 15 – Диаграмма последовательности
На диаграмме последовательности «создание аудита» представленной на рисунке 15 мы видим, что для того, чтобы пользователю запустить аудит сайта, ему достаточно совершить всего три действия:
перейти в раздел «аудиты»;
создать новый аудит, указав необходимые параметры;
запустить аудит.
|
