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

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

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

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

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

В настоящее время существует множество подходов к разработке программного обеспечения. Такие как «Каскадная модель» [1], «Инкрементальная модель» [2], «RAD Model» [3], «Гибкая методология разработки Agile» [4], «Итеративная модель» [5], «Спиральная модель» [6], «V-Model» [7].

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

В большинстве продуктовых компаний процесс принятия замечаний от пользователей и их решений выглядит следующим образом (Рисунок 1):

Рисунок 1 – Диаграмма состояний процесса решения возникшей проблемы работы программного продукта

1. Поступает заявка от пользователя;

2. Аналитик обрабатывает поступившую заявку. Если необходимо, создает задачу, готовит контрольные примеры;

3. Если задача была создана она попадает в очередь задач на реализацию;

4. Разработчики оценивают задачи и берут их в работу;

5. По завершении выполнения задачи, разработчик отправляет ее на приемку аналитику;

6. Если аналитик не выявит дефектов, то заявка закрывается и оповещаются клиенты о выполнении поставленной задачи. Если дефект был найден, то задача отправляется на доработку (пункт 4).

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

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

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

В работе будут широко использоваться диаграммы «UML» для описания процессов. «UML» (англ. «Unified Modeling Language» — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. [9]

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

Рисунок 2 – Диаграмма вариантов использования процесса поступления и решения задачи

На рисунке 2 представлена диаграмма вариантов использования процесса поступления и решения задачи. В процессе были выделены четыре роли:

• 1.    Пользователь;

• 2.    Специалист службы поддержки;

• 3.    Аналитик;

• 4.    Разработчик.

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

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

Аналитик - это человек, обладающий глубокими знаниями в предметной области, который имеет четкое представление о тонкостях работы программного продукта. В обязанности аналитика входит изучение всех изменений, происходящих в предметной области, будь то новые законы, приказы, специфичные требования для отдельных субъектов Российской Федерации и др. Так же аналитик занимается разбором неординарных случаев, возникающих в процессе эксплуатации программного продукта. От него требуется усидчивость и желание довести дело до конца, потому что могут возникать ситуации, на разбор которых может уйти несколько дней. При создании новых функциональных возможностей программного продукта, аналитик занимается изучением и детальным описанием знаний с учётом ограничений, которые накладывает программный продукт. В задачи аналитика входит как описание возникших ситуаций, функционала, так проверка результатов работы созданного функционала на предмет корректности.

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

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

Для более детального анализа процесса поступления и решения задачи была построена диаграмма состояний (Рисунок 3).

Рисунок 3 – Диаграмма состояний процесса постановки и решения задачи

При более детальном рассмотрении можно выделить семь этапов процесса решения пользовательской проблемы:

• 1.    Возникновение проблемы во время эксплуатации программного продукта. Когда пользователь сталкивается с ошибками в функционале программного продукта, он может обратиться в службу поддержки.

• 2.    При поступлении заявки от пользователя в виде письма или телефонного звонка, специалисты службы поддержки помогают пользователю посредством удаленного подключения к рабочему персональному компьютеру. Если специалисту не удается решить проблему

• 3.    Аналитики занимаются анализом поступающих заявок. Часть проблем пользователя разрешается посредством уже существующего функционала программного продукта. В тех случаях, когда явно выражено неверное поведение ПП создается задача с детальным описанием проблемы для разработчиков. Так же в обязанности аналитика входит создание контрольных примеров на тестовых серверах. В зависимости от сложности рассматриваемого поведения, на создание примеров уходит от одного до четырех часов;

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

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

пользователя, то он создает задачу в системе учета поступающих заявок для дальнейшего анализа аналитиками;

При работе по данному алгоритму возникают трудности. Анализ алгоритма производится на проекте, который работает в нескольких регионах Российской Федерации уже более пяти лет.

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

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

Рисунок 4 – Схема работы аналитиков и разработчиков с тестовыми базами данных

На рисунке 4, в упрощенном виде, показана работа аналитиков и разработчиков с тестовыми базами данных. В реальной жизни над проектами могут работать десятки человек и с ростом числа членов команды сложность взаимодействия будет только увеличиваться. Если ориентироваться на крупные проекты, то в основном они имеют широкую географию внедрения по различным регионам, субъектам Российской Федерации. При возникновении ошибок в работе программных продуктов необходимо рассматривать ситуацию на конкретном примере действий пользователя, что накладывает дополнительные ограничения в работе с данными. Резервные копии баз данных разворачиваются на тестовых серверах и на персональных компьютерах разработчиков на их усмотрение. Также на большинстве тестовых серверов каждый день разворачиваются недавно полученные копии баз данных для поддержания актуальности информации. Если к этому добавить географическое распределение команды, то могут возникать ситуации, описанные выше: порча данных, обновление серверов, на которых были созданы примеры для решения специфичных задач, простои из-за ошибок при разворачивании резервных копий баз данных.

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

• 1.    Исчезновение контрольных примеров после работы разработчиков с данными;

• 2.    Исчезновение контрольных примеров после внезапного обновления данных на тестовом сервере;

• 3.    Порча данных разработчиками с дальнейшим отсутствием возможности работы с базой;

• 4.    Сбои при обновлении данных на тестовых серверах;

• 5.    Низкая скорость получения данных с тестовых серверов разработчиками, обоснованная накладными расходами на транспортировку данных;

• 6.    Одновременная работа пользователей с одними наборами данных, которая может вызвать непредвиденное поведение программного продукта;

• 7.    Дополнительные расходы на аренду серверов для тестовых приложений.

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

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

• 1.    Кроссплатформенность;

• 2.    Возможность запуска программного продукта с необходимыми параметрами;

• 3.    Возможность запуска программного продукта разных версий;

• 4.    Возможность запуска программного продукта с подключением к указанной базе данных;

• 5.    Минимальное время развертывания резервной копии базы данных;

• 6.    Возможность конфигурирования сторонних продуктов, таких как очереди, дополнительные хранилища данных и др;

• 7.    Административная панель программного продукта должна быть веб решением;

• 8.    Возможность объединения пользователей в группы и настройка прав доступа к ресурсам вычислительных машин.

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

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

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

Рисунок 5 - Схема распределения компонентов сборки на компьютерах пользователей

Пользователи программного продукта могут использовать ресурсы персональных компьютеров других пользователей при разворачивании проекта необходимой версии для тестирования и решения поставленных задач. Рассмотрим пример: пользователю необходимо развернуть разрабатываемый программный продукт определенной версии.

Производимый программный продукт состоит из четырех компонентов – «RabbitMQ» [10], «Redis» [10], «PostgreSQL» [11], «Приложение». Для разворачивания приложения было бы необходимо сконфигурировать все компоненты, развернуть снимок базы данных, установить все программные зависимости и запустить приложение. Как уже упоминалось, в крупных проектах, количество накопленных данных исчисляется десятками гигабайт. На разворачивание резервной копии базы данных уходит может уходить более пяти часов. Для этого предлагается разворачивать резервную копию в контейнер [12] и далее создавать из него образ [13] используя технологию «Docker» [14]. Это позволит сократить время развертывания до нескольких часов часов.

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