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

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

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

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

10.06.2016

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

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

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

 

***

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

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

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

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

Операционная среда Sun Solaris

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

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

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

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

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

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

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

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

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

Современные технологии создания программного обеспечения (обзор)

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

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

Разработка корпоративных информационных систем (ИС) является одной из крупнейших проблем в информационных технологиях.   Основной принцип управления любой сложной системой был известен давно: "devide et impera" — "разделяй и властвуй". ...

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

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

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





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







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







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







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








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

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

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

            Спасибо!

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

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