Создание IT-продукта в сфере цифровой безопасности: этапы и методология

Создание IT-продукта в сфере цифровой безопасности: этапы и методология

24.08.2022
Создание IT-продукта в сфере цифровой безопасности: этапы и методология
© freepik.com

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


Этапы разработки программного продукта


Создание IT-продукта в организации связано с такими направлениями работы, как добыча данных (Data mining) и анализ полученной информации. Data mining представляет собой процесс оперативного и непрерывного сбора данных из открытых источников, их постобработку и сохранение в удобном для последующего анализа виде. От его эффективности зависит качество анализа добытой информации.


Выделяют несколько этапов:


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


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


3. Проектирование системы сбора данных. Неотъемлемой составляющей этого процесса являются артефакты:


  • диаграмма потока данных (dataflow diagram). Она включает в себя процессы (process) и хранилища данных (data store);

  • описание хранилищ данных;

  • описание процессов, обеспечивающих извлечение, загрузку и преобразование информации;

  • метрики, отражающие статистику загрузки данных из источника.

4. Проектирование Data Warehouse. Такое хранилище необходимо для получения новых знаний из добытых данных. Им могут пользоваться все заинтересованные лица. С целью выявления узких мест и оптимизации построения хранилищ, для получения экспертного мнения на данном этапе разработчики взаимодействуют с DWH-архитектором.


5. Разработка. Этот этап предполагает программную реализацию спроектированной системы сбора данных, а также построение DWH-хранилища. К решению задач подключаются DevOps-специалисты. Они обеспечивают всю необходимую инфраструктуру в виде изолированной среды работы системы, различных хранилищ данных, очередей, сбора и отображения метрик. Также на этапе разработки важно составить инструкцию по запуску системы, описать API (Application Programming Interface), архитектуру и различные особенности работы.


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


Иногда для оценки качества IT-решения разворачиваются аналогичные тестовые среды, которые работают с меньшим объёмом данных. Перед запуском системы в production (конечный пользователь) проводится нагрузочное тестирование. Пробный сбор данных из открытых источников проводится с той частотой, которая необходима для обеспечения необходимым потоком информации аналитиков.


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


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


Методологии разработки программного обеспечения


Существует несколько методологий разработки, среди которых выбирается наиболее подходящая для конкретного проекта. Одна из самых старых базовых моделей – Waterfall или «водопад». Она подразумевает последовательное прохождение стадий и применяется тогда, когда требования известны, понятны и неизменны. Разработка продукта по этой модели может занимать много времени, поскольку каждый последующий этап зависит от предыдущего. Есть риск того, что IT-решение будет не соответствовать требованиям заказчика либо будет уже не актуальным. По этой причине такой метод в ЦИСМ практически не используется.


В основном применяется гибкая методология Agile Model. Это набор различных методик и подходов к разработке продукта. Он позволяет оценить результат работы после каждой итерации (этапа). При этом в случае неподходящего качества или формата поставляемых данных можно доработать имеющийся функционал. Гибкая методология удобна для больших проектов, постоянно адаптируемых к меняющимся условиям. В Agile есть 4 основные ценности: люди и их взаимодействие важнее процессов и инструментов, работающий продукт значительнее исчерпывающей документации, взаимодействие с заказчиком важнее согласования условий контракта, готовность к изменениям превыше следования изначальному плану.


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


Kanban – это метод повышения качества сервиса или продукта через набор принципов и практик. Самая распространённая практика Kanban – визуализация процесса разработки с помощью Kanban-доски. Она призвана наглядно продемонстрировать этапы рабочего процесса: какие поставлены задачи, над чем идёт работа в данный момент и какие задачи уже выполнены.


Команда специалистов для создания IT-решения


Любой IT-продукт представляет собой конечное решение в соответствии с техническими требованиями заказчика. В разработке программного обеспечения участвуют:    


– backend-разработчики. Отвечают за создание серверных приложений;


– frontend-специалисты. Разрабатывают браузерные интерфейсы взаимодействия с пользователями;


– DevOps-инженеры. Они отвечают за автоматизацию поставки решений в production, предоставляют платформу для функционирования IT-решений;


– DWH-архитектор. Проектирует хранилища и витрины данных;


– QA-инженер – специалист по тестированию;


– IT-отдел. Отвечает за аппаратное обеспечение рабочих процессов;


– менеджер проекта.

 



Вернуться к списку