Особенности разработки систем на заказ от Инфосистемы Джет
Программное обеспечение Программное обеспечение

Если рассматривать разработку как услугу, в ней можно выделить 2 основных направления – продуктовую разработку, т.е. создание продуктов «на рынок», и заказную, т.е. разработку уникального ПО под нужды заказчика. Ниже мы поговорим о том, как у нас осуществляется процесс заказной разработки.

Главная>Программное обеспечение>«Фабрика разработки», или Как выглядит наш процесс разработки изнутри
Программное обеспечение

«Фабрика разработки», или Как выглядит наш процесс разработки изнутри

Дата публикации:
10.06.2016
Посетителей:
216
Просмотров:
180
Время просмотра:
0.9 мин.

Авторы

Автор
Павел Романченко Технический директор Центра инноваций компании «Инфосистемы Джет»
Если рассматривать разработку как услугу, в ней можно выделить 2 основных направления – продуктовую разработку, т.е. создание продуктов «на рынок», и заказную, т.е. разработку уникального ПО под нужды заказчика. Ниже мы поговорим о том, как у нас осуществляется процесс заказной разработки.

 

 

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

 

Три кита и одна черепаха

Разработка зиждется на трех китах: управление требованиями, разработкой и тестированием. Все это стоит на большой черепахе – на планировании.

 

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

 

В начале проекта аналитики погружаются в предметную область и описывают задачу с помощью так называемых «постановок» – описаний того, что нужно сделать. Наш основной инструмент на этом этапе – Atlassian Confluence. Это удобное средство для управления большим объемом информации. Говоря по-простому, Confluence позволяет создавать страницы с отформатированным текстом и совместно его редактировать. Для каждого документа ведется история изменений, для обсуждения предусмотрена система комментариев. Страницы можно иерархически организовывать, группируя, например, по функциональным областям проекта, по вехам и т.д.

 

Чуть позже начала анализа стартует проектирование, архитектор (он же главный конструктор) определяет основные технические решения, выбирает платформу, фреймворки, библиотеки и составляет спецификации. Основными инструментами для него являются все тот же Atlassian Confluence и Visual Paradigm. В Confluence архитектор описывает принятые решения и проставляет прямые и обратные ссылки на «постановки» аналитиков, таким образом, всегда можно понять, как ГК собирается реализовывать то или иное требование и какие требования затрагивает определенное проектное решение. Для проверки своих решений архитектор проводит Design Review: встреча объединяет участников его проектной команды, а также архитекторов и ведущих программистов других проектов, реализуемых у заказчика. Представление решения участникам имеет целью выявить неучтенные факторы, неоптимальные подходы и т.д.

 

После появления первых проектных решений мы приступаем к самой разработке. Проектные решения детализируются на спецификации, заводятся задачи в Atlassian Jira. Ссылки на задачи по разработке мы проставляем в проектные документы в Atlassian Confluence, благодаря тому что Confluence и Jira интегрированы, при открытии проектного решения мы всегда видим, в каком состоянии находятся задачи. Также стоит сказать, что для управления исходным кодом используется Git, в качестве централизованного сервера репозиториев – GitLab.

 

Каждую задачу мы разрабатываем в отдельной ветке Git, названной по имени задачи из Jira, что позволяет легко соотносить изменения с требованиями. Комментарии в commit также содержат номер задачи, чтобы коммиты отображались в Jira Worklog. Выполненные задачи переносятся (мержатся) в ветку development, а оттуда – в момент релиза – в ветку master.

 

Рис. 1. Модель ветвления Git

 

Немаловажным фактором в достижении качественного результата разработки является тестирование, особенно автоматическое. Автоматические тесты у нас разрабатывают как программисты (unit-тесты), так и тестировщики (с использованием, например, Cucumber), в качестве сервера интеграции и непрерывной сборки мы используем Jenkins.

 

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

 

Протестированный релиз, не содержащий критических и важных дефектов, выдается заказчику. Обязательный документ, сопровождающий каждый релиз, – это Release Notes. В нем мы указываем исправленные дефекты, найденные в предыдущих релизах, а также новые возможности системы.

 

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

 

Вопросы коммуникации

 

Стройный порядок вещей – аналитика, проектирование, разработка, тестирование, поставка – иногда может нарушаться по разным причинам. Самые тяжелые по последствиям случаи – это ошибки в аналитике со стороны как исполнителя, так и заказчика. Они тянут за собой перепроектирование, новую разработку, новые тест-планы, тестирование. Поэтому очень важно как можно более полное погружение аналитиков в предметную область, тщательное ведение реестра требований, отслеживание их изменений и отражение этих изменений в архитектуре приложения. Лет 7 назад на одном из проектов наш аналитик провел очень большую работу, предоставил user stories, описал предполагаемое поведение пользователей при работе с разрабатываемым решением, но при этом неверно проработал внутренние процессы (т.е. процессы, происходящие в системе, скрытые от конечного пользователя). Ошибка была замечена при презентации будущего решения заказчику. Правило представлять алгоритм наших будущих действий и общее видение системы представителям заказчика до начала самой разработки позволило избежать существенных проблем на проекте. Мы заново провели аналитику, изменили архитектуру решения и разработали систему в срок.

 

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

 

***

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

Уведомления об обновлении тем – в вашей почте

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

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

Мониторинг бизнес-приложений: экономим 50 млн рублей в час

Сколько стоит час простоя бизнес-приложений? Что умеют и чего не умеют АРМ-решения? Как пилот может сократить стоимость внедрения?

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

Обязательные требования к продукции, производству и эксплуатации определены Федеральным Законом РФ «О техническом регулировании». В нем, в частности, введено понятие безопасности продукции – «состояние, при котором отсутствует недопустимый ...

Java как центр архипелага

Когда говорят и пишут о Java, самой популярной фразой является "мир сошел с ума". Действительно, и скорость, и характер распространения (так и хочется вспомнить лексикон недавнего прошлого и сказать о "победном шествии") Java не имеют аналогов. При ...

Какие профессии в ИТ будут востребованы в 2021 году

Можно сказать однозначно: вакансий для ИТ-специалистов меньше не станет ни в течение нынешнего года, ни в 10-летней и даже более отдаленной перспективе. Материал подготовлен экспертами Trud.com

Tuxedo System — ключевой компонент корпоративных информационных систем

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

На кого учиться в ИТ: профессиональные тренды на ближайшие 10 лет

.vce-row-container .vcv-lozad {display: none} Трудно представить сферу более динамичную, чем ИТ. Факт стремительных инноваций в ней очевиден для всех, а вот что важно для самих ИТ-шников, особенно для тех, кто только начал профессиональный ...

Методология оценки безопасности информационных технологий по общим критериям

  В 1990 году под эгидой Международной организации по стандартизации (ИСО) и при содействии в дальнейшем государственных организаций США, Канады, Великобритании, Франции, Германии и Нидерландов были развернуты работы по созданию ...

XML и Java в трактовке корпорации Oracle

В первом номере информационного бюллетеня Jet Info за 2000 год была опубликована статья , посвященная языкам разметки документов. Большая часть статьи касалась языка XML (eXtensible Markup Language), не сходящего ныне со страниц компьютерных ...

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня