Файл: Национальный исследовательский университет мэи Практическое задание.docx

Введение 3

Задание 1. Выписки из ГОСТ 4

Задание 2. Описать процесс блок схемой 7

Задание 3а. Описать процесс с помощью IDEF 9

Задание 3б. Описать структуру управления информационной безопасностью организации с помощью IDEF 10

Задание 4. Описание процессов на основе модели UML 11

Выводы 12

Список используемых источников 14

Введение

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

Настоящая практическая работа направлена на совершенствование компетенций в практическом использовании различных методов описания информационных систем. Для достижения цели предстоит использование прикладных пакетов (MS Visio) и изучение различных стандартов описания моделей (ГОСТ 19.002-80, 19.003-80).

Задание 1. Выписки из ГОСТ

На сегодняшний день стандарты:

ГОСТ 19.002-80 Единая система программной документации (ЕСПД). Схемы алгоритмов и программ. Правила выполнения

ГОСТ 19.003-80 Единая система программной документации (ЕСПД). Схемы алгоритмов и программ. Обозначения условные графические

Имеют статус «Не действует - Заменен».

Взамен был введен ГОСТ 19.701-90 - Единая система программной документации. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения (от 01.01.92).

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

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

Описание символов (элементов)

Рассмотрим только основные элементы.

Данные
Символ отображает данные, носитель данных не определен.

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

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

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

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

Полный список символов представлен на Рис. 1

Рис. 1 - описание символов

Правила применения символов и выполнения схем (основные).

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

Задание 2. Описать процесс блок схемой

Вариант 4. Проверка изменения паролей в корпоративной сети.

Настройка аудита смены паролей пользователей

Используя групповые политики Active Directory, можно настроить аудит смены паролей и других действий, связанных с пользователями. Эти события можно получить, используя оснастку Event Viewer и Powershell. Политика, которая нужна, называется 'Audit account management/Аудит управления учетной записью'. Она включает аудит связанный с изменением пользователя, пароля и групп. В этой политике нужно включить учет успешных попыток изменения данных (Success) и провала (Failure). У домен контроллеров есть роль FSMO, которая отвечает за пароли. Ее название PDC - 'Primary domain controller'.[3] На домен контроллере, который держит эту роль, и будут собираться все события, связанные с политикой аудита. Далее нужно открыть журнал логов на домен-контроллере и посмотреть события. Также можно настроить фильтры, которые будут выводить события с определёнными идентификаторами, касающимися паролей.

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

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

Блок-схемы описанных вариантов действий представлена на

Рис. 2 - блок-схема управление доступом

Задание 3а. Описать процесс с помощью IDEF

Вариант 9. Изменение права доступа к информации.

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

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

Обобщенная схема действий представлена на IDEF0-диаграмме (Рис. 3)

Рис. 3 IDEF0-диаграмма изменения прав доступа

Задание 3б. Описать структуру управления информационной безопасностью организации с помощью IDEF

Описание: Мы только открыли салон-красоты и решаем выделить перечень всей поступающей информации, как от клиентов так и от фирмы. Эту информацию разделили на конфиденциальную и общедоступную. Далее определили нормы ИБ к каждому типу информации и способы их защиты техническими и информационными средствами. Задокументировали все проверки и отчеты.

Диаграмма представлена в Приложении 1.

Задание 4. Описание процессов на основе модели UML

Вариант 16. Процесс блокировки конфиденциальных документов

Описание: Руководитель отдела имеет право давать и блокировать доступ к определенным документам компании рядовым сотрудникам.

Рис. 4 – диаграмма вариантов использования для руководителя отдела

Выводы

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

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

После выполнения практического задания можно выделить преимущества и недостатки этого метода:

+наглядность перехода функций;

+структурированное представление задачи;

- из-за общего представления есть возможность упущения деталей;

- если программа объёмная, то и блок-схема будет большой (или нужно будет разбивать ее на блоки).

Также на основе проделанной работы следует выделить плюсы и минусы работы с IDEF0 (подкреплено мнением экспертов [2]).

+Полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи);

+Детализация потоков данных (разделение и слияние стрелок);

+Жесткие требования методологии обеспечивают получение моделей стандартного вида;

- сложность восприятия (большое количество потоков данных);

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

Что касается диаграммы вариантов использования нотации UML – я выделила для себя следующие преимуществ аи недостатки:

+ возможность взглянуть на задачу с разных сторон;

+ простота понимания базовых обозначений;

+ UML - это объектно-ориентированный язык, поэтому методы, с помощью которых описываются результаты анализа и проектирования являются семантически идентичными к методам программирования на ключевых ОО-языках;