Пример создания информационной инфраструктуры на основе системного подхода

ПЛАН

ПРОВЕДЕННЯ ЗАНЯТТЯ

з навчальної дисципліни

Теорія ризиків

 

Вид заняття: Лекція

Модуль2. Прикладні технології управління ризиками.

Змістовний модуль 6. Об’єкти управління інформаційною безпекою

Тема 12. Створення інформаційної інфраструктури. Приклади.

 

Метод проведення заняття усне викладення.

 

 

Навчальна та виховна мета:

1. Засвоїти сучасні підходи щодо побудови інформаційних інфраструктур.

Навчально-матеріальне забезпечення

1. Комплект слайдів до лекції № 12.

2. Навчальний сайт.

 

Навчальна література

1. Шевченко В.Л. Оптимізаційне моделювання в стратегічному плануванні. – К.: ЦВСД НУОУ, 2011. – 283 с.

2. Бюлетень. Автоматизована система управління оборонними ресурсами Збройних Сил України / за ред.В.Л.Шевченко. – К.: ЦВСД НУОУ, 2012. – 72 с.

3. Руководство к своду знаний по управлению проектами. Керівництво PMBOK. 2004. Project Management Institute. Four campus boulevard. Newtown square. PA 19073-3299. USA. 405 pp.

 

 


План проведення заняття

№ зп Навчальні питання, та короткий їх зміст Час хв Дії викладача та тих, що навчаються
  І   ІІ   ІІІ     Вступ 1. Прийом навчальної групи.   2. Зв'язок з матеріалами заняття, що вивчалось раніше.     3. Тема, мета і організація заняття.     Основна частина   4. Приклад створення ІІ на основі системного підходу 5. Переваги рішень на основі системного підходу     Заключна частина Підведення підсумків Відповіді на запитання Завдання на самостійну підготовку Виконати самостійне завдання . 1. Підготувати термінологічний словник за темою лекції   Тема і місце наступного заняття                   Перевірка наявності студентів та готовність їх до заняття. Нагадую тему попереднього заняття та пов’язую його з сьогоднішнім заняттям. Актуальність заняття.   Оголошую тему, мету заняття та навчальні питання. Оголошую порядок проведення заняття.   Матеріал викладати у темпі, що дозволяє вести записи, основні положення, визначення. Даю під запис за необхідністю визначений матеріал. Пояснюю слайди, що демонструються. За необхідності наводжу приклади з практики. Короткий висновок першого питання.   Нагадую тему заняття її зміст (навчальні питання). Визначаю ступінь досягнення мети заняття. (Визначаю позитивні сторони заняття та загальні недоліки) Відповідаю на запитання студентів Видаю завдання на самостійну підготовку Оголошую тему, час і місце проведення заняття

 

Завідувач кафедри управління інформаційною безпекою

______________________________________________________ д.т.н., с.н.с. В.Л.Шевченко


Міністерство освіти і науки України

Державний університет телекомунікацій

Навчально-науковий інститут захисту інформації

КАФЕДРА УПРАВЛІННЯ ІНФОРМАЦІЙНОЮ БЕЗПЕКОЮ

 

ЗАТВЕРДЖУЮ

Завідувач кафедри

д.т.н., с.н.с.

 

_______________________ В.С. Наконечний

 

"___" _____________20__ року

 

 

Методична розробка

Для проведення лекції з навчальної дисципліни

“ Теорія ризиків ”

 

Модуль2. Прикладні технології управління ризиками.

Змістовний модуль 6. Об’єкти управління інформаційною безпекою

Тема 12. Створення інформаційної інфраструктури. Приклади.

Обговорене на засіданні кафедри

Протокол № 1

« __ » серпня 20__р.

 

КИЇВ – 20__


 

== Слайд ==

 

Пример создания информационной инфраструктуры на основе системного подхода

 

== Слайд == (МОУ)

  Состояние информатизацииорганизации перед началом проекта
На час початку проекту в Організації існувало багато розрізнених автономних комп’ютерних систем, різного призначення, які задовільно працюють на своєму рівні, але незадовільно вирішують задачі інтеграції інформації: На момент начала проектав организации существовало множествоавтономних компьютерных систем,различного назначения, которые в целом удовлетворительно работали (каждая на своем уровне) но неудовлетворительно решали задачи интеграции информации

 

== Слайд ==

  Основная цель создания информационной инфраструктуры организации интегрировать (связать) существующие программы: · Через центральный сервер · Напрямую
  Проблемы ведущие к необходимости интеграции:
1. Повторний ввід данихрізними користувачами в різних точках організації. 1. Повторный ввод данных разными пользователями в разных точках организации.
2. Повторюваність запитань на дані від різних користувачів 2. Повторяемость запросов на данные от разных пользователей.
3. Велика кількість користувачів системи (декілька тисяч - десятків тисяч). Постійне масштабування системи (додавання нових ієрархічних рівнів, складових елементів, користувачів системи) 3. Большое количество пользователей системы (несколько тысяч-десятков тысяч). Постоянное масштабирование системы (прибавление новых иерархических уровней, составляющих элементов, пользователей системы).
4. Потреба сумісного використання існуючих автономних рішень. 4. Необходимость совместного использования существующих автономных решений.
5. Постійні зміни «правил гри», які потребують централізованого корегування програмного забезпечення у багатьох (або всіх) користувачів. 5. Постоянные изменения «правил игры», которые требуют централизованного корректирования программного обеспечения у многих (или всех) пользователей.

 

== Слайд ==

Для подолання подібних проблем близько 40 років тому була розроблена ідеологія ERP- систем (Enterprise Resource Planning – планування ресурсів підпріємства) управління ресурсами підприємств. Для преодоления подобных проблем около 40 лет назад была разработана идеология ERP - систем (Enterprise Resource Planning - планирования ресурсов предприятия) управления ресурсами предприятия

 

== Слайд ==

  ERP – системы (например SAP) обеспечивают интеграцию: 1) людских ресурсов 2) информации 3) данных 4) процессов

 

== Слайд ==

При обранні конкретного типу ERP- системивисувають вимоги щодо: · функціональності, · надійності, · уніфікованості, масштабованості, · простоти модифікації тощо. · А головне, щоб постачальник технології не зник з ринку в середині життєвого циклу системи, залишивши її без підтримки. При выборе конкретного типа ERP – системы выдвигают требования к: · Функциональности · Надежности · Унификации · Масштабирования · Простоты модификации и т.д. · А главное, чтобы поставщик технологии не исчез с рынка в середине жизненного цикла системы, оставив ее без техподдержки.
Саме так, в свій час, Міністерство оборони обрало технологію SAP, яка охоплює більш 50% світового ринку ERP-систем. Именно так, в свое время, Министерство обороны выбрало технологию SAP, которая охватывает более 50% мирового рынка ERP – систем.
Основні цілі проекту Основные цели проекта
• забезпечення керівництва достовірною інформацією; Обеспечение руководства достоверной информацией
• досягнення прозорості діяльності; Достижение прозрачностидеятельности
• удосконалення організаційної структури органів управління; Усовершенствование структурыорганов управления
• інтеграціїв єдину функціонально - інформаційну систему на єдиній програмній платформі усіх розробок з автоматизації процесів управління оборонними ресурсами. Интеграцияв единую функционально-информационную систему на единой программной платформе всех разработок по автоматизации процессов управления оборонными ресурсами

 

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

 

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

 

== Слайд ==

Для иллюстрации сложности информационных взаимосвязей, и соответственно уровня сверхвысоких требований к качеству работы телекоммуникационной составляющей Информационной инфраструктуры,

рассмотрим отдельные функциональные подсистемы проекта (бизнес-процессы, функциональные процессы).

 

Подсистема Кадры

== Слайд == соответствующие АРМы

== Слайд == Финансы и Бюджет

== Слайд == АРМы

== Слайд == Зарплата

== Слайд == АРМы

== Слайд == Недвижимость

== Слайд == АРМы

== Слайд == Обеспечение жильем

== Слайд == АРМы

== Слайд == Логистика

== Слайд == Кодификация

== Слайд == ТОРО(техобслуживание и ремонт)

== Слайд == АРМы

== Слайд == Перечень функциональных подсистем АС УОР:

• управління військовим майном;

• забезпечення житлом;

• підтримки бюджетного процесу і фінансового забезпечення;

• управління особовим складом і організаційною структурою;

• управління процесами МТЗ (логістика);

• розрахунку заробітної плати;

• технічного обслуговування та ремонту (ТОРО);

• правового забезпечення;

• оборонного планування;

• підтримки прийняття рішень;

• класифікації і кодування;

• обміну інформації.

• медичного забезпечення;

• військової освіти;

• підтримки наукової діяльності;

• міжнародне співробітництво;

• ревізійної діяльності .

 

== Слайд ==

  Топологию коммуникаций существенно усложняет большое количество организаций, вовлеченных в использование системы и интенсивное информационное взаимодействие между собой.
У якості споживачів (користувачів) до проекту залучені представники практично всіх підрозділів МОУ та ГШ ЗСУ. В качестве потребителей (пользователей) в проект вовлечены практически все подразделения МОУ и ГШ.

 

== Слайд ==

  Необходимым условием создания такой сложной информационной инфраструктуры является четкая организационная структура проекта:
Включає Раду управління проектом, Виконавчу та Оперативну ради до складу яких входять представники від Замовника, Розробника та постачальника технології - SAP. Включает Совет управления проектом, исполнительный и Оперативный совет, в состав которых входят представители от Заказчика, Разработчика и поставщика технологии SAP

 

== Слайд ==

Безпосереднім виконанням робот опікується оперативна рада, яка включає Робочі підгрупи. Непосредственным выполнением работ занимается оперативный совет, который включает Рабочие подгруппы
Складність та багатопов'язіність функціональних процесів що автоматизуються призвела до необхідності організації сумісної роботи в складі робочих підгруп фахівців із різноплановими знаннями та вміннями, а саме: Сложность и многосвязанность автоматизируемых функциональных процессов привела к необходимости организации совместной работы в составе рабочих подгрупп специалистов с разноплановыми знаниями и умениями, а именно:

 

Стороны проекта(или их представители) Умения и знания Время ввода в строй
Пользователь Знает что надо. Не знает как сделать 0,5 – 1 год
Разработчики (консультанты) Знает как сделать. Не знает – что. 3 – 5 лет
центр Внедрения   Знает чуть-чуть что и чуть-чуть как. 1. Налаживает диалог Пользователя и Разработчика; 2. Контроль Разработчика. 3. Тех.помощь пользователю. 1,5 – 2 года

 

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

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

 

== Слайд == Структура АС УОР включает:

· ЦК - центр коммутации (продуктивный сервер)

· АТК (автоматизированные технологические комплексы)

включают АРМ – автоматизированные рабочие места пользователей по функциональным подсистемам АС УОР

На 3-х уровнях (в/ч, командования-виды, МОУ-ГШ)

· ЦВ (центр внедрения).

 

Как это все выглядит

== Слайд ==Серверное оборудование

== Слайд ==Системы хранения данных

== Слайд ==Ленточные системы хранения данных

== Слайд ==Серверный комплекс Центра коммутации

== Слайд ==Серверный комплекс Центра внедрения

 

== Слайд ==Как объдиняются и разделяются сервера

 

== Слайд ==Зачем?

Чтобы разместить все функциональные подсистемы по отдельным логическим серверам?

Отчасти да, но в основном

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

 

== Слайд ==Главное, что на разных логических серверах

ERP система «живет»в разные периоды своего развития:

· разработка,

· обеспечение качества,

· продуктивная эксплуатация.

Зачем? Для повышения качества.

 

== Слайд ==

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

Мандант включает:

· Репозитарий объектов (программы, таблицы и т.д.).

· Общие настройки.

· Специальные настройки (коды, словари).

· Данные прикладных программ.

· Данные о пользователях.

 

== Слайд ==

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

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

Ошибки обнаруженные в качестве устраняют только в разработке.

После этого тестирование повторяют и при положительном исходе

коды и настройки из разработки переносят в продуктив.

 

== Слайд ==

Чем сложнее система, тем тщательнее процедура тестирования.

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

 

Кто всем этим должен заниматься?

Разработчик?

Возможно, но если с ним что-нибудь случится, то где искать текущие результаты разработки?

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

 

== Слайд ==Итак, Структура АС УОР включает:

· продуктивный сервер

· АТК

· ЦВ (центр внедрения). Сервер разработки. Тестирование, обучение и тех.поддержка пользователей.

Основная задача ЦВ на этапе разработки – техническая поддержка и контроль разработки.

 

 

== Слайд ==Для техподдержки используется Call-Center.

 

== Слайд ==В конечном счетеЦентр внедрениядолжен трансформироваться в центр компетенции,который для такой системы (в соответствии с мировым опытом может дать экономический эффект до 2 млн. долл. в год.

1. Снижки до 75% от стоимости лицензий.

2. Отказ от привлечения внешних консультантов (до 2 000 евро в день)

3. Обучение пользователей от 500 до 5000 долл. на 1 человека.

 

== Слайд ==То, что мы рассмотрели в структуре АС УОР можно назвать:

· Централизованная система

Кроме того, предполагается наличие таких составляющих:

· Децентрализованные компоненты

· Мобильные компоненты

 

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

Создание КСЗИ (комплексной системы защиты информации) включает:

 

1. (12 мес.) Формирование общих требований к КСЗИ

2. (8 мес.) Разработка политики безопасности информации

3. (3 мес.) Разработка технического задания на создание КСЗИ.

4. (6 мес.) Разработка проекта КСЗИ

Введение КСЗИ в действие

Оценка защищенности информации

 

== Слайд ==Для связи с другими ИАС (информационно-аналитическими системами) должны быть предусмотрены программно-аппаратные комплексы передачи закрытой информации.

 

== Слайд == Аутентификация пользователей осуществляется с помощью центра сертификации ключей.

 

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

 


== Слайд ==