Нечаев Артур Вячеславович

студент I-го курса магистратуры,

Базовая кафедра «Аналитика больших данных и методы видеоанализа»,
Институт радиоэлектронных и информационных технологий-РтФ,
ФГАОУ ВО «УрФУ имени первого Президента России Б.Н. Ельцина»,
e-mail: holdem-10@bk.ru,
г. Екатеринбург, Российская Федерация

Максимус Далиант Александрович

аспирант,
кафедра Экономической кибернетики,
ГОУВПО «Донецкий национальный технический университет»,
e-mail: daliant@mail.ru
г. Донецк, ДНР

Медведева Марина Александровна

кандидат физико-математических наук, доцент,
кафедра анализа систем и принятия решений,
ФГАОУ ВО «УрФУ имени первого Президента России Б.Н. Ельцина»,
e-mail: marmed55@yandex.ru
г. Екатеринбург, РФ

ПРОЕКТИРОВАНИЕ ВНЕДРЕНИЯ СВОБОДНОГО

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С ОТКРЫТЫМ ИСХОДНЫМ
КОДОМ В ДЕЯТЕЛЬНОСТЬ ГОСУДАРСТВЕННОГО УЧРЕЖДЕНИЯ

УДК 351.862:004.62

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

Ключевые слова:
Свободное программное обеспечение, открытый исходный код,
методологии проектирования, agile, waterfall, scrum.

Актуальность. Основной значимой проблемой проектного управления

является то, что сложность проектов как в области информационных
технологий, так и в других областях деятельности неуклонно возрастает.
Проектным группам приходится обеспечивать проектирование и создавание все
173
более сложных систем с привлечением к работам по проекту все более сложно
структурированных коллективов, что при отсутствии новых приемов
управления и проектирования приводит к аварийному прекращению проектов
или к недопустимому снижению качества их результата.
При этом для случая автоматизированных систем ситуация резко
утяжеляется. Включая в себя все большее количество компонент, которые
должны отслеживать изменения внешнего мира, они уже не располагают
временем на «отдых» и должны подвергаться практически непрерывным
изменениям. То есть все большее значение приобретает динамическая
сложность, связанная с темпом изменений требований к функциональности
автоматизированных комплексов.
Таким образом, при попытке создания новой системы с подготовкой
полных детальных функциональных требований проектная группа рискует не
добраться до этапа разработки, не говоря уже о завершении проекта.
Требования к программе неизбежно начинают меняться под влиянием внешних
условий до завершения их согласований, и это не является результатом ошибок,
допущенных при инициации проекта.
Однако не смотря на вышеуказанную проблему, крупные программные
системы продолжают создаваться и эволюционировать. В успешных проектах
применяется подход, при котором на начальном этапе формируется
минимальный набор требований, реализуемых с полезным эффектом
максимально быстро. Затем система переводится в состояние эксплуатации с
обеспечением ускоренного развития по изменяющимся требованиям.
За счет внедрения средств быстрой разработки и языков высокого уровня
со временем снижаются затраты на непосредственное написание текстов
программ и их отладку, т.е. на работу программиста. Усложнение программных
систем приводит к росту затрат на проектирование и перемещению
значительного объема работы с этапа создания программы на этап еѐ развития
и сопровождения.
Изложение основного материала. Осознание данного факта привело, в
том числе, к созданию радикально новых подходов к разработке программного
обеспечения, таких как agile. В рамках данного метода разработки практически
не предусматривается первичное проектирование программ, и делается
попытка перевести разрабатываемый продукт в этап сопровождения и развития
с первых шагов работы над процессами цифрового проекта [1]. Объектом
информатизации в данном случае выбран цифровой проект внедрения
свободного программного обеспечения с открытым исходным кодом в
деятельность государственных учреждений [2].
Согласно основным задачам цифрового проекта внедрение свободного
программного обеспечения с открытым исходным кодом происходит в
несколько этапов. В начале производятся некоторые мероприятия, которые в
дальнейшем позволят непосредственно использовать свободное программное
обеспечение с открытым исходным кодом различным предприятиям и
государственным учреждениям.

174
 Этапы внедрения СПО с ОИК можно видеть на процессной диаграмме
проекта. На рисунке 1 видно, что в самом начале проекта параллельно
происходит легализация лицензионных договоров и создание веб-сервиса
(включает организацию обмена данными). Эти мероприятия проводятся
однократно.

Рисунок 1. Первая часть общей процессной диаграммы

На рисунке 2 изображено, что после события «Копии договоров

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

175
 Рисунок 2. Вторая часть общей процессной диаграммы

На рисунке 3 изображены оставшиеся мероприятия по направлениям

развития проекта: разработка учебно-методического обеспечения, размещение
лицензии, проведение рекламной кампании.
Одним из этапов проекта по внедрению СПО с ОИК является разработка
веб-сервиса. Разработка веб-сервиса требует особого подхода, т.к. занимает
одно из ключевых мест в проекте. Разработка может проходить по различным
сценариям, но главными критериями эффективности остаются: время и
затраты. Одной из основных статей затрат при разработке является начисление
заработной платы рабочих. При этом планирование разработки может
происходить с точки зрения разных моделей: традиционной (каскадной) или
гибкой (скрам).

176
 Рисунок 3. Третья часть общей процессной диаграммы

Определение методологии разработки является довольно важным

процессом. Проще говоря, методология разработки – способ организации
работы по разработке программного обеспечения. Это не о стиле управления
проектом или конкретном техническом подходе, хотя довольно часто эти
термины объединяются или используются взаимозаменяемо.
Две основные, самые популярные методологии:
1. Waterfall, который можно более правильно назвать «традиционным»
подходом, и
2. Agile: особый тип быстрой разработки приложений, более новый, чем
Waterfall, но не такой новый, который часто реализуется с использованием
Scrum.
Оба они являются пригодными для использования, зрелыми
методологиями.
Waterfall – это линейный подход к разработке программного обеспечения.
В этой методологии последовательность событий выглядит примерно так:
1. Сбор и документирование требований
2. Дизайн
3. Код
4. Тестирование системы

177
 5. Приемочное тестирование пользователя
6. Исправление любых проблем
7. Доставка готового продукта
В настоящем проекте разработки Waterfall каждый из них представляет
отдельный этап разработки программного обеспечения, и каждый этап обычно
заканчивается до того, как может начаться следующий. Между ними обычно
есть проверка достижения определѐнных требований, например, требования
должны быть рассмотрены и утверждены заказчиком до начала
проектирования.
Есть хорошие и плохие стороны каскадной модели. С одной стороны:
- Разработчики и заказчики договариваются о том, что будет доставлено в
начале жизненного цикла разработки. Это делает планирование и
проектирование более простым.
- Прогресс легче измерить, так как весь объем работ известен заранее.
- В процессе разработки возможно участие различных членов команды
или продолжение другой работы, в зависимости от активной фазы проекта.
Например, бизнес-аналитики могут узнать и задокументировать, что
необходимо сделать, пока разработчики работают над другими проектами.
Тестировщики могут подготовить тестовые сценарии из документации по
требованиям, пока идет кодирование.
- За исключением обзоров, согласований, статусных встреч и т. д.
Присутствие клиента не требуется строго после фазы требований.
- Поскольку проектирование завершается на раннем этапе жизненного
цикла разработки, этот подход пригоден для проектов, в которых должно быть
разработано несколько программных компонентов (иногда параллельно) для
интеграции с внешними системами.
- Наконец, программное обеспечение может быть разработано полностью
и более тщательно, на основе более полного понимания всех результатов
программного обеспечения. Это обеспечивает лучшую конструкцию
программного обеспечения с меньшей вероятностью «частичного эффекта» –
явления разработки, которое может возникнуть при определении частей кода и
последующем добавлении в приложение, где они могут подходить или не
соответствовать.
Вот некоторые проблемы, с которыми можно столкнуться, используя
метод чистого waterfall:
- Одной из областей, которая почти всегда терпит неудачу, является
эффективность требований. Сбор и документирование требований таким
образом, чтобы это имело смысл для клиента, часто является наиболее сложной
частью разработки программного обеспечения. Клиентов иногда пугают
подробности, и при таком подходе требуются конкретные детали,
предоставленные в начале проекта. Кроме того, клиенты не всегда могут
визуализировать приложение из документа требований. Каркасные модели и
макеты могут помочь, но нет никаких сомнений в том, что большинство
конечных пользователей испытывают определенные трудности в соединении

178
этих элементов с письменными требованиями, чтобы составить хорошее
представление о том, что они получат.
- Другим потенциальным недостатком разработки чистого waterfall
является возможность того, что клиент будет недоволен поставленным
программным продуктом. Поскольку все результаты основаны на
задокументированных требованиях, клиент может не увидеть, что будет
доставлено, пока он не будет почти закончен. К тому времени изменения могут
быть трудными (и дорогостоящими) для реализации [3].
Agile – это итеративный командный подход к разработке. Этот подход
подчеркивает быструю доставку приложения в полных функциональных
компонентах. Вместо того, чтобы создавать задачи и графики, все время
«упаковано» в фазы, называемые «спринты». Каждый спринт имеет
определенную продолжительность (обычно в неделях) с рабочим списком
результатов, запланированных в начале спринта. Конечные результаты имеют
приоритет по стоимости бизнеса, определяемой клиентом [4]. Если все
запланированные работы для спринта не могут быть завершены, работа
перераспределяется и информация используется для будущего планирования
спринта.
Когда работа завершена, она может быть рассмотрена и оценена
проектной командой и заказчиком с помощью ежедневных сборок и
демонстраций по завершении спринта. Agile опирается на очень высокий
уровень вовлеченности клиентов на протяжении всего проекта, но особенно во
время этих проверок.
Некоторые преимущества гибкого подхода легко увидеть:
- Заказчик имеет частые и ранние возможности увидеть выполняемую
работу, а также принимать решения и вносить изменения в течение всего
проекта разработки.
- Заказчик получает сильное чувство причастности к работе благодаря
обширной и непосредственной работе с командой проекта на протяжении всего
проекта.
- Если время выхода на рынок для конкретного приложения представляет
собой большую проблему, чем выпуск полного набора функций при первом
запуске, Agile может быстрее создать базовую версию рабочего программного
обеспечения, которая может быть построена в последовательных итерациях.
- Разработка часто более ориентирована на пользователя, вероятно,
является результатом более частого руководства со стороны клиента.
И, конечно же, есть некоторые недостатки:
- Очень высокая степень вовлеченности клиентов, хотя и полезна для
проекта, может создать проблемы для некоторых клиентов, которые просто
могут не иметь времени или интереса для такого типа участия.
- Agile работает лучше всего, когда члены команды разработчиков
полностью преданы проекту.
- Поскольку Agile фокусируется на доставке в определенные, возможно,
что некоторые предметы, поставленные для доставки, не будут выполнены в
отведенные сроки. Могут потребоваться дополнительные спринты (помимо
179
запланированных), что увеличит стоимость проекта. Кроме того, участие
клиентов часто приводит к дополнительным функциям, запрашиваемым на
протяжении всего проекта. Опять же, это может добавить к общему времени и
стоимости внедрения.
- Тесными рабочими отношениями в Agile-проекте легче всего управлять,
когда члены команды находятся в одном физическом пространстве, что не
всегда возможно. Однако существует множество способов решения этой
проблемы, например веб-камеры, инструменты для совместной работы и т. д.
- Итеративный характер гибкой разработки может привести к частому
рефакторингу, если весь объем системы не учитывается в первоначальной
архитектуре и дизайне. Без этого рефакторинга система может страдать от
снижения общего качества. Это становится более выраженным в
крупномасштабных реализациях или с системами, которые включают высокий
уровень интеграции [5].
Выводы. В работе на основе процессного подхода предложены основные
этапы внедрения свободного программного обеспечения с открытым исходным
кодом, как цифрового проекта. Также приведены основные критерии
эффективности использования различных моделей проектирования. Описаны
основные отличия традиционной методологии проектирования разработки
программного обеспечения от гибкой методологии. В дальнейшем будут
проведены расчеты с целью выяснения более эффективной с точки зрения
времени и затрат методологии проектирования затрат на организации
процессов и внедрение и цифрового проекта.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Чекмарев, А. В. Управление ИТ-проектами и процессами: учебник для
академического бакалавриата / А. В. Чекмарев. – М.: Издательство Юрайт,
2019. – 228 с.
2. Коломыцева А.О., Максимус Д.А. Концептуальный подход к
построению архитектуры защиты информации для ПО с открытым исходным
кодом Сборник научных трудов Новое в экономической кибернетике: сборник
научных трудов / гл. ред. В.Н. Тимохин. – Донецк: ГОУ ВПО «ДонНУ»
[УНИЭК], 2019. – № 1. – С. 99-113.
3. Кумагина, Е.А., Неймарк, Е.А. Модели жизненного цикла и
технологии проектирования программного обеспечения: учебно-методическое
пособие / Е.А. Кумагина, Е.А. Неймарк. – Нижний Новгород: Изд-во ННГУ,
2016. – 41 с.
4. Коломыцева А.О. Медведева М.А., Максимус Д.А. Мониторинг
финансовой эффективности программ цифрового развития и внедрения ПО с
отрытым исходным кодом Proceedings of the 44th International Conference on
Applications of Mathematics in Engineering and Economics, AMEE 2019 (Том
2048). [060016] American Institute of Physics Inc. https://doi.org/10.1063/1.5082131
https://science.urfu.ru/ru/publications/on-the-use-of-cluster-analysis-for-
interpretation-of-soil-polluti

180
 5. Майк Кон. Scrum: гибкая разработка ПО = Succeeding with Agile:
Software Development Using Scrum (Addison-Wesley Signature Series). — М.:
«Вильямс», 2011. — С. 576.

Nechaev Artur
Student of the first course of the magistracy,
Department ―Big Data Analytics and Video Analysis Methods‖
Engineering School of Information Technologies,
Telecommunications and Control Systems,
Ural Federal University named after the first President of Russia B.N. Yeltsin,
e-mail: holdem-10@bk.ru,
Ekaterinburg, Russian Federation

Maximus Daliant,
Post-graduate student,
Department of Economic Cybernetics,
Donetsk National Technical University,
e-mail: daliant@mail.ru
Donetsk, DPR

Medvedeva Marina
Associate Professor, chief researcher, candidate of physical and mathematical
Sciences, Department of System Analysis and Decision Making,
Ural Federal University named after the first President of Russia Boris Yeltsin
e-mail: marmed55@yandex.ru
Ekaterinburg, Russia

PROJECTING OF FREE OPEN SOURCE SOFTWARE

IMPLEMENTATION INTO THE WORK OF GOVERNMENT
INSTITUTION

Abstracts:
The article discusses the main stages of the introduction of free open source
software. The main aspects of the effectiveness of the application of different models
are given. The main differences between the classical methodology of designing
software development and the agile methodology are described.

Keywords:
Free software, open source, projecting methodologies, agile, waterfall, scrum.

181