Перейти к основному содержанию
ИТарктика
УДК 658.511.3
Матвеев Виталий Иванович, Пикос Юлия Сергеевна, Тюфяков Алексей Владимирович
заместитель начальника, отдел разработки и адаптации информационных систем, Государственное автономное учреждение Республики Коми «Центр информационных технологий» (ГАУ РК «ЦИТ»)

консультант, отдел разработки и адаптации информационных систем
ГАУ РК «ЦИТ»

консультант, отдел разработки и адаптации информационных систем,
ГАУ РК «ЦИТ»
Разработка прогрессивных бизнес-приложений на базе государственного автономного учреждения Республики Коми «Центр информационных технологий»
Аннотация:

В статье представлены тезисы доклада о пути оптимизации производственного процесса в отделе разработки и адаптации информационных систем государственного автономного учреждения Республики Коми «Центр информационных технологий» (ГАУ РК «ЦИТ»). Выявлены проблемы использования стандартной модели разработки, Agile, спиральной модели процесса разработки. Рассмотрены изменения в производственном процессе в соответствии с методологией DevOps. Доклад был представлен на научно-техническом совете при ГАУ РК «ЦИТ».

Ключевые слова: стандартная модель разработки, Agile, спиральная модель разработки, аналитика, инструменты DevOps..

В начале 2016 года в ГАУ РК «ЦИТ» был сформирован Отдел разработки и адаптации информационных систем, целью которого стала разработка региональных систем и бизнес-приложений, обеспечивающих автоматизацию деятельности государства. Отдел состоит из начальника отдела, 6 разработчиков и 1 стажера, 3 аналитиков, 2 разработчиков государственных и муниципальных услуг, 1 технического писателя, 1 билд-инженера.

Отдел принимает активное участие в следующих проектах.

Таблица 1. Проекты Отдела

Проекты в сопровождении

Проекты в разработке

  • РКИС «ГУ-РК»:
  • Портал Госуслуг
  • Личный кабинет
  • СООЗ
  • Модуль МФЦ
  • Сервисная шина
  • Хранилище метаданных
  • Система электронных подписей
  • Конструктор портальных решений
  • АИС «Мои документы»
  • Государственные услуги
  • Сервисы МВ взаимодействия
  • Личный кабинет пациента

 

Таким образом, на отдел приходится 8 проектов в сопровождении и 4 проекта в активной разработке.

В ходе достижения основной цели были обнаружены следующие проблемы.

Таблица 2. Проблемы производственного процесса и их решения

Проблема

Решение

Большой объем и сложность кодовой базы

  • Разработка микросервисной архитектуры [3]
  • Реализация компонентного подхода
  • Внедрение международных стандартов

Недостаток человеческих ресурсов

  • Автоматизация внутренних процессов
  • Снижение порога вхождения новых сотрудников
  • Сотрудничество с вузами
  • Формирование института наставничества

Помимо приведенных выше проблем, отдельно необходимо выделить проблемы в производственном процессе:

  • проблема планирования и управления рисками;
  • проблемы взаимодействия с заказчиком;
  • проблема с определением потребностей заказчика.

Каков путь оптимизации производственного процесса для решения этих проблем? Стандартный процесс разработки программного продукта выглядит следующим образом:

длт

Рис. 1. Стандартный процесс разработки

Основные участники процесса разработки:

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

Аналитик – обеспечивает двустороннюю взаимосвязь между предметными экспертами (функциональными специалистами) заказчика и IT-специалистами путем сбора требований, их обработки, документирования и передачи IT-специалистам, доведения полученных результатов до представителей Заказчика.

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

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

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

Специалист отдела внедрения – специалист, занимающийся внедрением информационной системы, обучением пользователей.

Специалист отдела сопровождения – специалист, отвечающий за развитие и сопровождение информационной системы заказчика.

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

Исходя из цели возникают следующие проблемы:

  • невозможность оперативного внесения изменений в программный продукт;
  • долгая обратная связь от пользователей;
  • обособленность звеньев – участников процесса;
  • длительный ручной процесс сборки релиза.

Для решения проблем производственного процесса в Отделе было принято решение использовать элементы методологии Agile [2]. Agile – серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации.

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

На данный момент в Отделе используется методология DevOps [1].

DevOps (акроним от англ. development и operations) – это методология разработки программного обеспечения, сфокусированная на предельно активном взаимодействии программистов, тестировщиков и администраторов, синхронизировано обслуживающих общий для них программный продукт.

Преимущества методологии:

  • постоянный поток / непрерывное производство;
  • быстрый цикл обратной связи;
  • постоянное улучшение процесса;

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

  1. Планирование и оценка трудозатрат. Формирование дорожной карты в качестве Task Tracker. План работ на квартал – Sprint.
  2. Взаимодействие с заказчиком. Детализация требований заказчика. Интервьюирование заказчика. Основные вопросы аналитика. (Проблема – решение).
  3. Формирование моделей оптимизации. Моделирование бизнес-процессов.
  4. Взаимодействие с разработчиком. Перевод требований заказчика (желания заказчика) в постановку задачи для разработчика.
  5. Работа с инструментарием. Redmine как система управления задачами, в которой аналитик ставит задачу на разработчика. Wiki Redmine содержит все описание проекта, описанные требования, смоделированные бизнес-процессы и экранные формы, НПА и шаблоны документов.
  6. Оценка качества продукта. Функциональное тестирование, форматно-логический контроль программного продукта. Тест-планы. Обработка замечаний/предложений. Обратная связь от пользователя.

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

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

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

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

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

  • внедрение методологии в процессах автоматизации услуг и сервисов;
  • взаимодействие с вузами;
  • внедрение института наставничества;
  • использование инструментов автоматизации доставки обновлений в отдел сопровождения ГАУ РК ЦИТ.

Список литературы

  1. Ким Д., Бер К., Спаффорд Дж. Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему. [Электронный ресурс] // Фикшнбук. URL: http://fictionbook.ru/static/trials/11/08/36/11083697.a4.pdf.
  2. Сазерленд Дж. Scrum. Революционный метод управления проектами. [Электронный ресурс] // Электронная библиотека RuLit. URL: http://www.rulit.me/books/scrum-revolyucionnyj-metod-upravleniya-proektami-read-412856-1.html.
  3. ДеМарко Т. Deadline. Роман об управлении проектами. [Электронный ресурс] // Google Документы. URL: https://docs.google.com/file/d/0BxOg0amRzk9vejFOaGVoVEdkVEU/view.
  4. Чакон С., Штрауб Б. Git для профессионального программиста. [Текст] / Питер. – 2016. – 496 с.
  5. Сэм Ньюмен. Создание микросервисов. [Электронный ресурс] // WebDynamics. URL: http://sd.blackball.lv/library/Sozdanie_mikroservisov_-_Sam_Newman_2016.pdf.

References

  1. Kim Jin, Behr Kevin, Spafford George. "Phoenix" project. A novel about how DevOps changing business for the better. [Text] / Eksmo. 2015.384 p.
  2. Sutherland Jeff. Scrum. The revolutionary project management method. [Electronic resource] / E-Library RuLit. URL: http://www.rulit.me/books/scrum-revolyucionnyj-metod-upravleniya-proektami-read-412856-1.html.
  3. DeMarco Tom. Deadline. Novel about project management. [Electronic resource] / Google Docs. URL: https://docs.google.com/file/d/0BxOg0amRzk9vejFOaGVoVEdkVEU/view.
  4. Chacon Scott, Straub Ben. Git for a professional programmer. [Text] / Peter. – 2016. – 496 p.
  5. Newman Sam. Building Microservices. [Text] / Peter. – 2016. – 304 p.