57
подключаемыми. Это одно из существенных архитектурных отличий этого
фреймворка от некоторых других (например, Ruby on Rails) [8].
Ниже представлен сравнительная таблица тестирования
производительности на Linux системе Python и Ruby таблица 1.1
Таблица 1.1.
Тестирование скорости языков Python и Ruby
Название теста
Real
User
system
Ruby
Python
Ruby
Python
Ruby
Python
Скорость операций с длинной
арифметикой (вычисления
факториала числа 30000)
8.974
17.609
8.963
17.602
0.007
0.004
Скорость создания и удаления
объектов
756.593
389.973
680.874
389.882
75.535
0.009
У обоих языков есть свои плюсы и минусы и в общем они примерно
равноправны, но так как философия Django больше подходит для данного проекта
и имеется опыт работы я зыком Python выпор пал в пользу последнего.
Так же разрабатываемый проект предполагает реализацию программной
логики на стороне пользователя. Для её работы традиционно использовался
скриптовый язык JavaScript. JavaScript мультипарадигменный язык
программирования. Поддерживает объектно-ориентированный, императивный и
функциональный стили. JavaScript обычно используется как встраиваемый язык
для программного доступа к объектам приложений. Наиболее широкое
применение находит в браузерах как язык сценариев для придания
интерактивности веб-страницам. Так же как в случае с Python, для ускорения
создание системы будет использован библиотека. Существует большое
количество хороших библиотек, но выбрана был JQuery по тому, библиотека
простая, код написанный с её помощью понятен и имеется опыт работы с ней.
Для оформления HTML шаблонов страниц также использовался CSS
фреймворков. Наиболее известны на данный момент 2 фреймворка: это Bootstrap
разрабатываемый в Twitter и Foundation разрабатываемый в ZURB. Оба похожи
функционалом, различий не много. Выбран был Bootstrap только из-за того, что
пользователям стандартное оформление Bootstrap понравилось больше.
58
1.4.3 Обоснование проектных решений по техническому обеспечению
Обеспечение техническое - совокупность технических средств,
компьютерной техники, средств передачи информации, используемых в
автоматизированных системах управления и в информационных системах.
Так как развертывание системы производится на уже имеющимся железе,
приобретение нового не требуется. Системные требования, которые необходимо
выделить под создаваемы LXC контейнер представлены в таблице 1.2.
Таблица 1.2.
Характеристики сервера разрабатываемой системы
Характеристика
Значение
Тактовая частота процессора
не менее 2.0 Гц
Количество ядер
8
Объем оперативной памяти
8 Гб
Объем swap
2 Гб
Постоянная память
1,5 Тб
Пропускная способность сетевого
интерфейса
100 Мбит/с
Так как для работы с разрабатываемой ИС необходим только браузер, особо
мощного компьютера для сотрудника не требуется. Подойдет любой офисный
ПК, примерные характеристики оного представлены в таблице 1.3
Таблица 1.3.
Характеристика конфигурации ПК сотрудника
Характеристика
Значение
Процессор
Intel Celeron J1800 (Bay Trail-D, 2.41 ГГц, 2Mb,
BGA1170)
Количество ядер
2
Система охлаждения
Пассивная
Установленная
оперативная память
4 Гб DDR3
Постоянная память
Объем памяти: 500 Гб (SATA III)
Видеокарта
Интегрирована в процессор Intel HD Graphics
Тип корпуса
Mini Tower
Сетевая карта
10/100/1000
59
Глава 2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Процессы Жизненного Цикла проекта автоматизации
Проанализировав большое количество существующих стандартов
жизненного цикла ИС был сделан вывод, что большинство наиболее известных
стандартов таких как ГОСТ 34, ISO 12207, MSF, RUP, COBIT рассчитаны на
крупные проекты. Из всех выделялся стандарт RUP имеющий меньшее время
разработки проекта, но и он долог. В связи с выводом, сделанным в ходе анализа
выбор был сделан в пользу стандарта RAD.
RAD (от англ. rapid application development — быстрая разработка
приложений) — концепция создания средств разработки программных
продуктов, уделяющая особое внимание быстроте и удобству программирования,
созданию технологического процесса, позволяющего программисту максимально
быстро создавать компьютерные программы. Практическое определение: RAD —
это жизненный цикл процесса проектирования, созданный для достижения более
высокой скорости разработки и качества ПО, чем это возможно при
традиционном подходе к проектированию [9].
Используемый жизненный цикл подразумеваете разработку программного
обеспечения силами небольшой команды разработчиков, использующих
методику сборки продукта из нескольких прототипов. RAD предусматривает
активное привлечение заказчика (в данном случае сотрудников для работы
которых предназначается разрабатываемая система) на ранних стадиях —
обследование, выработка требований. Последнее из указанных свойств
подразумевает полное выполнение требований заказчика как функциональных,
так и нефункциональных, с учётом их возможных изменений в период разработки
системы, а также получение качественной документации, обеспечивающей
удобство эксплуатации и сопровождения системы. Это означает, что
дополнительные затраты на сопровождение сразу после поставки будут
значительно меньше. Таким образом, полное время от начала разработки до
получения приемлемого продукта при использовании этого метода значительно
60
сокращается. Технологию RAD целесообразно применять, когда четко
определены некоторые приоритетные направления разработки проекта:
1. Необходимо выполнение проекта в сжатые сроки.
2. Нечетко определены требования к ПО.
3. Проект выполняется в условиях ограниченности бюджета.
4. Интерфейс пользователя (GUI) есть главный фактор. Нет смысла
заставлять пользователя рисовать картинки. RAD-технология дает возможность
продемонстрировать интерфейс в прототипе, причём достаточно скоро после
начала проекта.
5. Возможно разбиение проекта на функциональные компоненты.
6. Низкая вычислительная сложность ПО.
Выбор данной RAD технологии был сделан так как разрабатываемая
система подпадает под 3 из 6 пунктов (пункты первый, третий пятый).
Основным преимуществами системы являются:
Быстрота продвижения продукта на рынке.
Пользовательский интерфейс удовлетворяющий заказчика.
Возможность на лету адаптировать проект к новым требованиям.
Простота в развитии функциональности разрабатываемой системы.
Технология RAD имеет 4 фазы которые представлены на схеме 2.1:
1. Планирование - совокупность требований, полученных при системном
планировании и анализе процедуры разработки жизненного цикла.
2. Пользовательское проектирование — на протяжении данного этапа
пользователи, взаимодействуя с системными аналитиками, разрабатывают
модели и прототипы, которые включают в себя все необходимые системные
функции.
3. Конструирование — этап, в котором основная задача заключается в
разработке программ и приложений.
4. Переключение — включает в себя операции по конверсии данных,
тестирование, переход на новую систему и тренировку пользователей.
61
Схема 2.1. Фазы жизненного цикла стандарта RAD
При разработке системы на фазе планирования формируются задачи,
которые должна решать разрабатываемая система. Формулировку задач
осуществляли инженеры МЦТЭТ работающие с существующими система и
сотрудники техподдержки МЦТЭТ. Основной задачей стала разработка
масштабируемой и функциональной информационной системы с возможность
простого дополнения функционала. Первоочерёдные задачи, которые должна она
решить это организация блокировки абонентов параллельно RADIUS серверу с
журналом произведённых действий, разработка информационно справочной
системы «09», NetFlow коллектор и анализатор, веб интерфейс для работы
сотрудника технической поддержки с журналом блокировок, NetFlow
анализатором и базой LANBilling.
На этапе пользовательского проектирования прорабатываются модели
данных для разрабатываемых задач таких как блокировка абонентов и NetFlow
коллектор и анализируется уже имеющаяся модель данных в АСР LANBilling.
Совместно с сотрудниками технической поддержки детально прорабатывается
функционал для каждой задачи. Проектирование модуля блокировки
производиться с сотрудниками технической поддержки МЦТЭТ, инженерами
МРФ «Дальний Восток» и инженерами МЦТЭТ. Проектирование справочной
системы «09» осуществляется силами сотрудников МЦТЭТ. Модуль работающий
62
с базой данных LANBilling проектируется инженером МЦТЭТ совместно с
сотрудниками ГСП.
На этапе конструирования происходит разработка программного кода и
внедрение модуля для системного тестирования. Тестирование производится
параллельно работающим системам. При отсутствии ошибок и замечания модуль
переходит на стадию переключения иначе же возвращается на стадию
пользовательского проектирования. Тестирование и наблюдение за работой
модуля блокировки производиться с сотрудниками технической поддержки
МЦТЭТ, инженерами МРФ «Дальний Восток» и инженерами МЦТЭТ.
Сотрудники технической поддержки регистрируют обращения абонентов.
Инженер МРФ «Дальний Восток» контролируют формирование выгрузки и в
случае необходимости вносят поправки в её содержимое. Инженеры МЦТЭТ
отслеживают ошибки в коде, собранные данные с оборудования и полученные
данные с выгрузки. Тестирование системы «09» осуществляется силами
сотрудников МЦТЭТ и заключается в использовании новой системы. Модуль
работающий с базой данных LANBilling тестируется сотрудниками ГСП. Так же,
как и со службой «09» сотрудники ГСП работают с новой системой и в случае
недочетов фиксируют их и передают инженерам МЦТЭТ. Так как старая система
не выведена из эксплуатации в случае критических ошибок запрос данных
производится через неё.
Если модуль готов и соответствует всем предъявленным к нему требования
он попадает на стадию переключения. На данной стадии модулю внедряется в
работу пользователей, при необходимости дополнительно проводится
инструктаж сотрудников, работающих с нововведённой системой, в данном
случае это инженеры технической поддержки, сотрудники ГСП и сотрудники,
работающие с информационно справочной системой «09». В данном случая
интеграция для все модуля происходит одинаково, добавляется разработанный
модуль в подготовленный контейнер ОС Linux, настройка прав пользователей в
соответствии с политиками безопасности компании. Заранее для данного
контейнера организован ограниченный доступ на оборудования и базы данных
организации.
63
Применение данного подхода проектирования позволит быстро и
качественно спроектировать и внедрить разрабатываемую систему, а также может
быть успешно использован в её дальнейшем развитие.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
RAD-технология не является универсальной, то есть её применение
целесообразно не всегда. Например, в проектах, где требования к программному
продукту четко определены и не должны меняться, вовлечение заказчика в
процесс разработки не требуется и более эффективной может быть иерархическая
разработка (каскадный метод). То же касается проектов, ПО, сложность которых
определяется необходимостью реализации сложных алгоритмов, а роль и объём
пользовательского интерфейса невелик.
При разработке ИС с использованием RAD технологии возможные риски
могут проявиться на этапах конструирования и переключения.
На этапе конструирования предусмотрено тестирование, при выявлении
ошибок на данном этапе они передаются инженерам МЦТЭТ. Проводится анализ
ошибок, на его основании либо производится устранение недочётов и
продолжается тестирование, либо возвращается на этап пользовательского
проектирования где совместно с сотрудниками (ГСП, техподдержки, службы
«09») заново прорабатывается модель данных и анализируются поставленные
задачи.
На этапе переключения как правило проявляются ошибки, которые нельзя
выявить в результате тестирования на этапе конструирования, например, ошибки,
связанные со структурными особенностями среды разработки. Это может быть
проблемы, связанные с адресацией в оперативной памяти или же банально не
рациональное использование оперативной памяти, что в результате приведёт к
использованию всего доступного пространства и краху приложения. В результате
выявления подобных ошибок они будут передаваться инженерам МЦТЭТ для
доработки системы и немедленного внедрения доработанного кода.
64
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения безопасности системы на рабочих местах используются
средства ИБ, описанные ранее. В LXC контейнере на котором развернута ИС
ограничение доступа организовано средствами встроенного в ядро Linux
межсетевого экрана Iptables, на котором прописаны листы доступа к
определённым портам. Для удалённого доступа используется протокол SSH c
использованием RSA-ключей длиной более 2048 бит, авторизация под учётной
записью root отключена, компьютеры инженеров МЦТЭТ авторизацию проходят
с использование ключа, сгенерированного у каждого отдельно. На уровне СУБД
так же есть разграничения, каждое приложение работает со своей базой данных и
из-под своей учётной записи. Если же несколько приложений работают с одной
базой распределение прав применяется к таблицам БД, в результате чего
приложение может работать только с общедоступными для приложений данными
или только со своими.
Для дополнительной защиты и реализации подключения отдельного
модуля внутри ИС с собственной учётной записью к БД, ИС запускается в
несколько процессов, c разными подключенными модулями. Распределение
нагрузки и доступа к процессам осуществляется при помощи функций обратного
прокси сервера демона NGINX. Отдельные процессы с различными модулями
подымаются с использованием приложения Docker, что дополнительно позволяет
изолировать каждый запускаемы процесс.
На уровне самой системы также организованны распределение прав
заведённых в систему пользователей. В системе по мимо разграничения прав
между имеющимися в ней модулями подразумевается разграничения внутри
модуля. Разграничений прав пользователей ИС представлено на таблице 2.1.
65
Таблица 2.1.
Разграничение прав пользователей ИС
Пользователь
Служба «09»
База
LANBilling
NetFlow
анализатор
Журнал
блокировки
абонентов
и активных
сессий
Сотрудник службы
«09»
Чтение
Запись (только
свой район)
Удаление (только
свой район)
Нет
Нет
Нет
Сотрудник ГСП
Чтение
Да
Да
Да
Сотрудник технической
поддержки
Нет
Да
Да
Да
Инженер МЦТЭТ
Чтение
Запись
Удаление
Да
Да
Да
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
На схеме 2.2 представлена информационная модель разрабатываемой ИС.
Данная модель включает в себя несколько источников данных как формируемых
пользователями ИС, так и автоматически сформированных данных. Также
имеются несколько баз данных для хранения данных.
Рассмотрим реализацию первой задачи на данной модели. Демон
блокировки абонентов получает данные из сервера выгрузки. За формирование
выгрузки на данном сервере отвечают сотрудники МРФ «Дальний Восток». По
мимо выгрузки с сервера, демон собирает следующие данные с маршрутизаторов:
список активных сессий и лист блокировки. Полученные данные демон
записывает в таблицы log_active_session, log_block_list, log_guest_list.
Проанализировав имеющиеся данные формируется список команд необходимых
выполнить на маршрутизаторах. Список команд включает в себя команды на
добавление в гостевой лист (блокировку по балансу) или же удаление из него ip
адреса. Лог отправленных на маршрутизатор команд так же ведётся. В базе
предусмотрен триггер, формирующий архивные таблицы с подписью временного
промежутка (${data}). Данный триггер необходим для того что бы сохранить
полноценную историю и запросы к основной таблице выполнялись с приемлемой
66
скоростью при использовании меньшего процессорного времени. Собранные
данные сотрудники могут просмотреть, используя веб интерфейс системы
предварительно авторизовавшись.
Справочная служба «09» работает с основной базой (ДБ Django) на которой
реализовано функционирование системы. Пользователь, авторизовавшись в
форме запроса вводит исходные (искомые) данные и получает результат
выполнения запроса в виде списка. При добавлении или изменение данных,
пользователь дополнительно проходит проверку прав на редактирование или
создание данных указанного региона, в ответ получает результат выполнения.