Введение 4
1. Определение задачи исследования 10
1.1. Обзор существующих решений 11
2. Анализ процесса поставок программного обеспечения на примере Банка
России 17
2.1. Текущая методология процесса поставки программного обеспечения в Банке России 17
2.2. Недостатки текущей методологии 19
2.3. Предлагаемые улучшения 20
2.4. Спецификация к информационной системе автоматизации процессов поставки программного обеспечения 22
3. Решение поставленных задач 25
3.1. Обзор и анализ существующих методологий и моделей разработки 25
3.2. Требования к процессу ведения проектов 27
3.2.1. Формат хранения исходного кода и вспомогательных программных ресурсов на стороне разработчика 27
3.2.2. Структура репозитория приложений, библиотек, вспомогательных файлов 27
3.2.3. Модель ветвления в репозитории 29
3.2.4. Общие требования к версионированию 30
3.3. Реализация прототипа информационной системы “Автоматизации
процессов поставки программного обеспечения” 31
3.3.1. Структура проекта 31
3.3.2. Модели 32
3.3.3. Работа с данными 32
3.3.4. Визуальные компоненты 32
3.3.5. Механизмы информационной безопасности 33
3.3.6. Инсталляция и настройка 33
4. Полученные результаты 34
Заключение 36
Глоссарий 37
Список литературы 38
Приложение 41
А Диаграмма жизненного цикла релизов 41
Б Статистика по дефектам релизов в Банке России за 2017-2018 год 42
В Проблемы влияющие на поставку ПО 43
Г Описание комплекта поставки (пример) 46
Д Методология расчёта трудоемкости 47
Е Протокол предварительных испытаний информационной системы “Автоматизации процессов поставки программного обеспечения.” 49
Ж Структура файла changelogjson 56
З Диаграмма классов программного обеспечения 57

Купить

В современных условиях IT бизнес характеризуется 2 вехами:
Во-первых, заказчики хотят получить максимум из уже заказанного и эксплуатируемого ПО. Платить за уже реализованные функции повторно - никто не хочет. Поэтому, уже внедренное ПО развивается и сопровождается максимально долго. Сменить разработчика так же становится проблематичным, так как с ростом объема кода и сложности автоматизируемых функций передать компетенции другой команде разработки трудно. С наработкой опыта, текущая команда превращается в экспертов не только в предметной области, но и в понимании потребностей заказчика. Это приводит к тому, что заказчик хочет максимально долго развивать уже разработанное программное обеспечение и договора на его сопровождение продлеваются десятилетиями [17].
Во-вторых, современные методологии разработки предусматривают итерационный процесс развития продукта. Это позволяет быстро удовлетворить часть потребностей заказчика и продолжать делать это весь срок контракта. Так же изменение законодательства или выявление скрытых ошибок требует сопровождения системы весь срок ее эксплуатации. Это приводит к тому, что договорные отношения заключаются на долгий срок и в течении всего этого срока исполнитель поставляет модификации к системе. Данные модификации по своей сути являются новыми версиями продукта[26].
Согласно спиральной методологии разработки программного обеспечения [23] последней фазой процесса разработки программного обеспечения является внедрение готового программного обеспечения или очередной его итерации в промышленную эксплуатацию. Артефактом данного процесса является релиз. Схема описания процесса и его жизненного цикла приведена в приложении A. В работе мы будем использовать следующие определение релиза:
Релиз —это выпуск окончательной версии программы, готового для использования продукта. В релизе обычно собирают все версии и обновления, и выпускают конечный продукт со всеми исправлениями, который не нужно обновлять, так как он является последней актуальной версией программного обеспечения. При итеративном процессе разработки, релиз выпускается в конце каждой итерации. В случае если программное обеспечение уже внедрено в эксплуатацию, релиз в
виде пакетов модификаций(патчей) рассылается по клиентам и внедряется в программный продукт [14].
Релиз — набор аппаратного обеспечения, программного обеспечения, документации, процессов или других компонентов, которые необходимы для внедрения одного или нескольких согласованных изменений в услугах.Содержание каждого релиза управляться, тестируется и развертывается как отдельная сущность^].
Применение данных модификаций несет следующие риски [28] для промышленной эксплуатации системы:
• Некорректно реализован новый функционал;
• Внесена ошибка в действующий функционал;
• Система перестает справляться с нагрузкой.
Таким образом новый продукт должен быть наполнен только требуемыми функциями, проверен и его риски должны быть минимизированы.
Процесс управления выпуском готового к эксплуатации продукта называется управлением релизами. Цель процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Для достижения поставленной цели, в области разработки программного обеспечения используется процесс управления выпусками — “Release Management’’[4].
Поскольку программные системы, процессы разработки программного обеспечения и ресурсы становятся более распределенными, они неизменно становятся более специализированными и сложными. При использовании современных методологий, программные продукты находятся в непрерывном цикле разработки, тестирования и выпуска, такие системы требуют выделенных отдельных ролей для контроля за интеграцией и потоком разработки, тестирования, развертывания и поддержки. Ранее данные функции ложились на разработчиков, тестировщиков и менеджеров проекта, но в связи с внедрением территориально распределенных команд, передачей части функций на аутсорсинг все чаще для процесса формирования релиза стали выделять отдельную роль. Данную роль принято называть «Релиз-менеджер» — “Release Engineer”[12].
«Релиз-менеджер» отвечает за операции по выпуску продукта. Основная цель «релиз-менеджера» - обеспечение выпуска готового продукта. Он координирует выпуск продукта со специалистами по эксплуатации, создает план выпуска продукта и сертифицирует подготовленные к выпуску версии для поставки или развертывания[4].
В качестве направления нашего исследования мы выбрали проблемы, влияющие на выпуска готового продукта в промышленную эксплуатацию и выявляемые на этапе подготовки релиза.
Данное направление выбрано нами в качестве предмета для исследования, по следующим причинам:
Теоретической:
Внедрение — одна из фаз жизненного цикла программного обеспечения. В каких-то моделях оно относится к стадии развертывания и сопровождения, в других — разработки и тестирования.Дисциплина управления релизами является относительно новой для программной инженерии и еще не получила широкого раскрытия в литературе и учебных планах.
Во многих методологиях данной роли вообще нет, а ее функции распределены между ProjectManager, ProductOwner, TeamLeader. Но при промышленной разработке без нее не обойтись, так как управление релизами позволяет связать процесс разработки с процессами управления качеством и поддержки пользователей.
По мнению автора, в рамках существующих учебных программ тема управления релизами затрагивается вскользь в дисциплинах «Жизненный цикл программного обеспечения» и «Основы управления проектами». Рассчитываем, что работа позволит не только продолжить исследования в части применения подходов автоматизации в процессе поставок программного обеспечения, но и сформирует материал для дальнейшего расширения учебных программ по специальности.
Автор данной работы уже несколько лет работает релиз - менеджером. Заняв данную должность, использовал существующие в организации практики. Но по мере накопления статистики по проблемам и нештатным ситуациям, стало понятно, что процесс необходимо модернизировать.
Для решения стоящих практических проблем будет изучен текущий процесс поставок, принятый в организации, сформирован список проблем организации, рассмотрены наши предложения по их устранению или снижению рисков по ним, в процессе формирования релизов. Для этого изучим существующий опыт и методологий.
Работа раскрывает особенности управления выпусками программного обеспечения, базируясь не только на теоретических источниках, но и накопленном опыте автора и научного руководителя, в данной области.
Основной упор в работе будет сделан на автоматизацию процесса. Это вызвано следующими факторами:
• Компактность структуры;
Процесс управления поставками программного обеспечения, в силу своих особенностей, не может быть децентрализован или распределен по большому количеству персонала. Он связан с принятием стратегических решений и их оформлением. Для этого вся полнота информации должна быть сосредоточена у одного - двух сотрудников. Так же, данная роль воспринимается в IT-компаниях, как административно - вспомогательная и её штатная численность, обычно, мала.
• Большой объем информации;
Для принятие решения о составе релиза, конфигурации, дате внедрения и существующих ограничениях требуется доступ к большому объему информации, поступающему от различных источников.
• Процесс принятия решений на данный момент невозможно полностью автоматизировать или переложить на искусственный интеллект, так как кроме технических событий, таких как оценка качества, прохождение тестового покрытия или соответствие план-графику поставок, релиз-менеджеру приходится сталкивается и с нормативно-договорными факторами, субъективно оценивать риски и взвешивать улучшения и ухудшения в работе с системой, после установки релиза. В настоящее время, во многих компаниях управление выпуском программного обеспечения остается творческим процессом. Данной парадигмы мы продолжим придерживаться. Но постараемся обеспечить полный доступ и контроль за информацией, в рамках автоматизированного подхода;
• Готовых программных решений, для управления релизами не много. Данный функционал лишь частично представлен в различных системах управления разработкой. Выполненная нами разработка позволит получить прототип востребованного специализированного сервисного программного продукта, с малым количеством конкурентов;
• Полученные результаты возможно апробировать на базе организации - партнера Казанского (Поволжского) федерального университета - Центрального Банка Российской Федерации (Банка России). Что позволит подтвердить или опровергнуть эффективность выполненной работы.
Таким образом, целью исследования является:
• Оптимизация работ, выполняемых в рамках процесса поставок программного обеспечения, в целях снижения трудозатрат и улучшения качества выпускаемого программного обеспечения;
• Создание прототипа системы, позволяющей применить автоматизированные подходы к работам, выполняемым в рамках процесса поставки программного обеспечения, для снижения их трудозатрат и улучшения качества результатов процесса.
Областью исследований является методология подготовка и формирование готового программного обеспечения для поставки заказчику и возможности автоматизации данного процесса путем разработки специального программного обеспечения. Данное программное обеспечение представляет собой информационную автоматизированную систему, целью которой является оказание помощи релиз - менеджерам и другим участникам данного процесса в формировании поставок программного обеспечения.
Предметом исследования являются процедуры и методологии процесса поставки программного обеспечения.
В исследовании использовались следующие методы: информационный поиск, интеллектуальный анализ данных, поиск знаний в базах данных, рассуждение на основе прецедентов, имитационное моделирование, прототипирование, экспериментальный, ситуационный анализ, и когнитивное моделирование.
В рамках данного исследования автором изучены труды отечественных и иностранных исследователей в области управления релизами и их решений. Книги:
• Майкла Нейгарда - “Release it! Проектирование и дизайн ПО для тех, кому не всё равно” [28];
• Chaminda Chandrasekara - “Beginning Build and Release Management with TFS 2017 and VSTS” [2];
• Джеза Хамбл и Девида Фарлей - “Непрерывная поставка” [6];
• Перевод материалов библиотеки “ITIL v.3” от компании YeSSoft [25];
• Dave Howard - “IT release management” [4].
Статьи:
• Evolution of thinking models in automatic incident processing systems [11];
• Thinking lifecycle as an implementation of machine understanding in software maintenance automation domain [10];
• Модель мышления и понимания в автоматической обработке запросов пользователя [9];
• Thinking-Understanding approach in IT maintenance domain automation [27];
• Управление процессом разработки программного обеспечения на основе статистического имитационного моделирования[31].
Диссертации:
• Тощев А. С. - “Интеллектуальная система повышения эффективности ИТ- службы предприятия” [30].
Задачи исследования: провести анализ предметной области, сформировать гипотезу, создать прототип для проверки гипотез, выполнить проверку гипотез, проанализировать результаты.

Купить