39
ниже 3 Ghz на ядро, и количеством ядер 4. Для хранения информации будет
достаточно HDD объемом 100 гб и более.
Веб-сервер на рабочей станции рекомендуется запускать при помощи
контейнеров Docker и настроенных контейнеров для разработки Drupal сайтов
Docker4Drupal (27). Это позволит получить максимально пригодную среду
разработки для разработки под Drupal, со всеми специфическими настройками, а
также дополнительными возможности в виде дебаггера.
В качестве ОС необходимо установить любой дистрибутив Linux на своё
усмотрение. Docker будет активно использоваться при разработке. Данное ПО
пишется в первую очередь для Linux систем, из-за чего использует возможности
Linux ядра напрямую, без добавления прослойки в виде виртуальной машины.
Благодаря этому на Linux достигается максимальная производительность (28) и
нативная
23
работа программы, не требующая никаких настроек.
Также, Linux имеет из коробки все необходимые для комфортной работы
инструменты: SSH, git, гибкий терминал, полноценную интеграцию со всеми
консольными утилитами. Это позволит максимально быстро приступить к
работе, не тратя время на установку множества мелкого софта.
Помимо прочего, Linux также используется на веб-сервере, что также
является мотиватором для использования его на рабочей станции. Окончания
файлов, переносы строк в формате Unix, отсутствие BOM (29) меток,
добавляемых Windows в текстовые файлы, которые приводят к ошибкам в
работе кода, так как эти метки не должны находиться в коде, они является
невидимыми, и в случае Linux, о них не придется заботиться. Одинаковая работа
прав доступа к файлам и папкам, также позволит корректнее отлаживать ИС
максимально приближено к продакшен серверу.
23
Естественная.
40
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Процессы жизненного цикла проекта автоматизации
В качестве жизненного цикла ПО был выбран, очень популярный на
данный момент, метод SCRUM (30, 31).
SCRUM — это подход к разработке ПО, который позволяет организовать
большую гибкость в разработке (4), а также непрерывное развитие и изменение
ПО. Это позволяет достигать цели намного быстрее, путем релиза готовых
частей ПО (модулей, возможностей) в ближайшие сроки после их готовности, на
основе их приоритетов. Итерации в данном подходе называются спринтами.
Спринт — это определенная итерация в SCRUM методологии, в пределах
которой реализуется определенный функционал. Как правило, длительность
одного спринта может быть от 1 до 4 недель, но каждая компания сама выбирает
необходимые сроки для каждого спринта, исходя из задач проекта. В пределах
спринта реализуется весь запланированный функционал.
По окончанию спринта, данный функционал выгружается или внедряется
в готовый продукт, затем, формируются новые спринты, проводится аналитика
проблем и анализ того как был пройден спринт, и так по циклу.
Рис. №7 SCRUM процесс.
При помощи данного подхода, новый функционал будет доступен на
проверку практически сразу после его реализации. В связи с этим, сразу можно
будет собирать отзывы и замечания, и реализовывать их в последующих
спринтах.
41
В SCRUM имеется жесткое деление людей, вовлеченных в разработку, на
следующие роли:
Владелец продукта (SCRUM Product Owner) — данный человек, или
группа лиц, представляют собой заинтересованную сторону, которая формирует
список задач для проекта в целом.
Скрам-мастер (SCRUM Master) — люди данный роли отвечают за
координацию проекта, процесс ее разработки и внедрения, проводят совещания,
а также, следят за соблюдением принципов SCRUM разработки, при это,
защищает команду от отвлекающих факторов.
Скрам-команда (SCRUM Team) — люди, непосредственно участвующие в
разработке продукта. Под эту роль попадают программисты, аналитики, тестеры
и прочие специалисты вовлеченные в процесс разработки.
В очень крупных проектах могут появляться дополнительные роли, но в
данном случае будут использованы лишь основные.
Рассматривая SCRUM как жизненный цикл продукта, можно выделить
следующие этапы:
Бэклог продукта (Product Backlog) — на данном этапе составляется список
требования или задач к разрабатываемому продукту. Каждая задача в SCRUM
называется пользовательской историей (user story). У каждой задачи есть свой
уникальный ID в рамках разрабатываемого проекта. В данных задачах, которые
формируются лицами в роли владельца продукта, описываются желаемые задачи
и функционал, который необходимо сделать. Бэклог может включать в себя
дополнительные данные, для более корректного определения приоритета задач:
важность, предварительную оценку по объему предстоящих работ, способы
демонстрации завершенной задачи, различные теги или категории, список или
отсылка к компонентам или частям проекта, которые будут изменены в ходе
данный задачи и прочая дополнительная информация, необходимая для решения
задачи.
42
Рис. №8 Пример бэклога продукта.
Создание бэклога спринта — планирование ближайшего спринта и выбор
задач из бэклога продукта для реализации в пределах данного спринта. На
данном этапе выбирается длительность спринта, в зависимости от объема задача,
выбранных из бэклога продукта, и их сложности реализации. Более короткие
сроки позволяют быстрее получать отзыв от клиента, и быстрее выявлять
ошибки, с другой стороны, более длительные сроки позволяют решить задачу
более оптимально, за счет дополнительного времени на реализацию. Как
правило, срок спринта выбирается посередине, между самым коротким и самым
длинным, чтобы не пришлось делать всё в спешке, и не задерживать реализацию
долго, чтобы быстрее получить обратную связь. На данном этапе активно
взаимодействуют между собой владелец продукта и скрам-команда. Сообща,
43
определяется важность задачи, различные ее нюансы, а команда, примерно
оценивает трудозатраты на выполнение той или иной задачи.
Спринт — процесс разработки актуальных для данного спринта задач.
Выбранные задачи, как правило, принято разделять на определенные статусы,
или использовать таблицы\столбцы для ведения учета задач в пределах спринта.
В общих случаях будут присутствовать: задачи, которые необходимо сделать,
задачи в работе, сделанные задачи. В ходе работы над задачей, она меняет свой
статус и по нему легко отслеживать, какие задачи остались нерешенными, какие
уже решены, а какие ещё в процессе. Для более крупных проектов также можно
встретить следующие этапы: тестирование, проверка.
Рис. №9 Пример доски со статусом задач.
4. Тестирование и демонстрация — на данном этапе проводится
демонстрация готового продукта заказчику, сбор отзывов и предложений.
Все собранные данные отправляются в дальнейший процесс разработки -
бэклог продукта. На данном этапе активно участвует владелец продукта.
5. Ретроспектива и планирование следующего спринта — на текущем
этапе производится анализ и делаются выводы из прошедшего спринта.
На нем определяется, как можно улучшить процесс разработки на
следующем этапе, чтобы ускорить процесс, или избежать ошибок,
которые были допущены в ходе действующего спринта. На данном этапе
44
могут участвовать все роли, но как правило, основные участники данного
этапа скрам-мастер и скрам-команда.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Как и у любого ПО, в ходе работ будут появляться проблемы и ошибки. В
связи с тем, что данная ИС в дальнейшем планируется развиваться и
расширяться, это сразу влечет за собой как очевидные, так и не очевидные
ожидаемые риски в процессе работы над проектом.
К актуальным ожидаемым рискам разрабатываемой ИС можно отнести:
● Некорректную архитектуру данных. В случае некорректных
архитектуру данных, придется переделывать либо определенную часть, либо
модуль в целом. Если это выявится на этапе построения, проблема не так
критична, лишь придется потратить время на переделывание, в случае
обнаружения проблемы в ходе эксплуатации, придется делать перенос данных
для их сохранения и внедрять всё на лету. Но это потребует значительно больше
усилией и времени, нежели сделать всё корректно сразу.
● Некорректная реализация задачи. Беря в учет то, что задача реализуется
на Drupal 8 и требуется каждый модуль оформить как сущность под данные,
может выйти так, что базовые поля и конфигурационные, будут перемешаны.
Некорректное определение что является свойство, а что обычными данными,
может повлечь за собой проблемы в хранении данных. На этапе разработки, это
можно исправить простым переделыванием, и переустановкой модулей. В
процессе работы, потребуется писать обновления или миграции данных, и
возможно, временно выводить систему из строя, чтобы в процессе данные не
были активны.
● Некорректные выборы типы данных для хранения. Например, можно
изначально сделать, чтобы под телефон было одно значение, но в дальнейшем,
потребуется множественное значение, с возможность указания, что это за
значение, например факс, или личный номер телефона. Если наименования
свойств и полей корректно, то проблема будет решать простым добавлением
нового поля для хранения множественных данных, с последующим переносом
старых в новое поле. Так как множественное и единственное число для названия
полей также учитывается, их машинные имена не будут конфликтовать, и это не
45
скажется на работе системы, но потребует затратить время на корректный
перенос данных.
На каждом этапе жизненного цикла также могут быть свои определенные
ожидаемые риски:
● Бэклог продукта. На данном этапе могут быть поставлены
некорректные задачи. Например, владелец написал что хочет, но после спринта,
оказывается что он хотел совершенно другое. То есть, написал не то что хотел на
самом деле. Это очень распространенная проблема при разработке ПО, на неё
влияет множество факторов, из-за чего данный риск, скорее всего, будет самый
ожидаемый. К сожалению, в большинстве случаев, если задача согласована с
обеих стороны, но стороны поняли их по разному, придется либо дорабатывать,
либо переделывать. Тут как раз поможет выбранный жизненный цикл
разработки ИС. После спринта, где задача будет сделана скрам-командой, и
получен фидбек от владельца о не соответствии, можно будет сделать сразу
спринт, который решает проблему, не оттягивая её в долгий ящик.
● Создание бэклог спринта. На данном этапе есть риск неполных данных,
или опускание различных нюансов для задачи. Например, клиент предоставил
данные, рассказал всё как и должно быть, но забыл о чем-то упомянуть, что
может сильно изменить реализацию задачи и ее сроки. Из-за чего результат
может оказаться не тем, что требуется, либо некорректно оценены сроки на ее
реализацию. Чтобы избежать подобных проблем, потребуется опыт со стороны
разработчика, чтобы задавать наводящие вопросы, чтобы получить как можно
больше полезной информации с владельца. Как правило, владельцы зачастую
очень важные моменты считают что они неважные, и их сделать можно позже,
но на практике может оказаться так, что эти мелочи, делая их в будущем,
потребует кратных трудозатрат, нежели если их сделать сразу. Либо вообще
могут поломать функционал того, что было сделано.
● Спринт. На данном этапе существуют классические риски разработки:
○ Срыв сроков. Например, было оценено что задачу можно реализовать за
день, а на деле потребовалась неделя. Хорошо если это укладывается в рамки
спринта и не вредит другим задачам в спринте, но если вредит, то это скажется
46
на всем спринте в целом. Для этого, задачу лучше оценивать заведомо с запасом
времени на основе предыдущих спринтов и опыте команды.
○ Недостаток информации. Например, необходимо сделать интеграцию
со сторонним сервисом, клиент полностью описал что и как он хочет видеть в
итоговом продукте, предоставил всю необходимую документацию от третьего
сервиса, но в ходе реализации оказалось так, что документация является
неполной. А знать это наверняка, на момент составления бэклога спринта,
практически невозможно, так как это часть спринта, внедрения API и изучения
его основных возможностей. Может оказаться так, что требуемая часть
документации выдается под другими условиями, является платной или по
требованию, о чем мог не знать как владелец, так и скрам-команда. Решить
данную проблему крайне проблематично, и все будет зависеть от третьего лица,
от действий которых будут решаться дальнейшие действия. В случае со SCRUM,
данную задачу лучше всего перенести на следующий спринт, после того как
данные будут получены.
○ Задача не может быть решена, пока не решены другие задачи, которые
могут даже не находиться в списке задач или текущем спринте. Подобного рода
проблемы должны выявляться этапе создания бэклога спринта, но все же
случаются на практике. В подобной ситуации либо придется внедрять новые
задачи экстренно в спринт, либо откладывать текущую до следующей.
Внедрение дополнительных задач в действующий спринт, может повлиять на его
успешность выполнения, а откладывание текущей задачи на следующий спринт,
повлияет на сроки внедрения функционала.
● Тестирование и демонстрация. На данном этапе есть риск неполного
тестирования и проверки готового функционала. Тестирования должны быть
исчерпывающими, охватывающие все возможные поведения и вводы данных, но
не всегда можно предусмотреть все, из-за чего могут выявляться совершенно
неочевидные пути до ошибки. Данные проблемы необходимо ставить в задачи и
решать в последующих спринтах.
● Ретроспектива и планированирование следующего спринта. На данном
этапе есть риски некорректного планирования спринта, а также, необъективная
оценка и анализ прошедшего спринта.
47
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Основная защита будет строиться поверх выбранной системы и её
возможностей. Всё что не будет доступно для решения средствами системы или
будет сочтено недостаточным, будет решаться внешними средствами.
В качестве защиты от внутренних и внешних угроз для сервера
реализована защита на уровне авторизации при помощи SSH ключей. Для всех
пользователей сервера, доступ по паролю отключен, тем самым исключая
возможность прямой авторизации, утечки пароля или же подбора пароля. SSH
ключ будет доступен только владельцу и ключ от него будет знать только
владелец. Таким образом, подключиться к серверу будет практически
невозможно.
На уровне ИС будут использоваться штатные средства защиты и прав
доступа к информации.
Для защиты от внутренних угроз будет четкое распределение прав
доступа на основе ролей. Каждая роль в системе имеет свои определенные права.
Количество прав и их необходимость для собственных модулей контролируется
руками. При необходимости есть возможность делать максимально гибкие права
доступа.
Таблица №5
Права доступа к модулям по ролям.
Роль\Модули
Модуль компании
Модуль
контактных лиц
Модуль проектов
Гость
Нет
Нет
Нет
Авторизованный
пользователь
Нет
Нет
Нет
Сотрудник
Чтение
Чтение
Чтение
Администратор
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
Чтение/Создание/
Удаление
48
В дополнение к распределению прав доступа, регистрация на сайте будет
полностью отключена. Новые профили для доступа сможет создавать только
главный администратор.
На данном этапе внедрения защита данных не стоит в приоритете, так как
ничего важного там находиться не будет. В дальнейшем права будет меняться и
модернизироваться. Например, в дальнейшем планируется показывать только те
проекты, клиентов и контактных лиц сотруднику, к которым он привязан.
В качестве протокола для работы ИС будет использовать https, что
позволит избавиться от части популярных способов атак типа Man In The Middle
(MITM) (32).
Для защиты аккаунтов сотрудников от перебора будет стоят защита от
перебора паролей, когда после 5 неуспешных вводов, аккаунт блокируется до
вмешательства администратора. Пароли будут создаваться администратором
случайным генератором паролей содержащим символы, цифры, а также спец.
символы. Все действия сотрудников будут автоматически логироваться
24
системой в системный журнал.
Для защиты системы от сбоев, каждый день по крону
25
в 3 часа ночи по
серверному времени будет создаваться полная резервная копия системы
содержащая в себе все файлы системы, кодовую базу и БД. Данные будут
архивироваться в один архив, включая все настройки сервера под данный проект
и информацией о проведении резервной копии. Архив за последние сутки будет
храниться на сервере, для быстрого доступа в случае экстренных ситуаций. Для
большей безопасности и надежности, после создания бэкапа они также будут
отсылаться в закрытое файловое хранилище Amazon S3 (33) посредствам
защиненного протокола s3 с дополнительным шиврованием данных в момент
передачи. Файл передается чанками
26
, каждый по отдельности, и отдельно
зашифрован, а не потоково файл целиком, для дополнительной безопасности и
перехвата данных. На самом сервисе Amazon S3, данные архивы хранятся
дополнительно неделю, спустя данный срок они удаляются. Таким образом, у
системы будет резервная копия за последние 7 дней относительно текущего. На
24
Запись в журнал действий системы.
25
Cron - утилита для выполнения регулярных операций.
26
От англ. chunk - кусок.