© 1995-2021 Компания «Инфосистемы Джет»
Особенности разработки систем на заказ от Инфосистемы Джет
Программное обеспечение

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

Программное обеспечение

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

10.06.2016

Посетителей: 120

Просмотров: 108

Время просмотра: 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 на час-полтора, что в итоге начало тормозить рабочий процесс. По согласованию с заказчиком мы перешли на более эффективные встречи меньшими группами, общий статус собирался раз неделю.

 

***

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

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

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

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

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

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

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

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

Облачный подход к разработке

Облачные технологии и сервисы меняют подход разработчиков к построению информационных систем

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

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

Компонентная объектная модель JavaBeans

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

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

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

Опыт внедрения Java-технологии в компании Sun Microsystems

Информационная модель Java находит применение во многих различных вычислительных средах — от смарт-карт до суперкомпьютеров. В настоящей статье описывается, как Java и Java-устройства, такие как JavaStation компании SUN Microsystems, могут ...

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

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

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





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







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







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







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








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

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

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

            Спасибо!

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

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