Процесс разработки программного обеспечения

Минимальные и необходимые требования к инфраструктуре для разработки ПО

Вступление

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

• Нет регламента на выпуск билдов (builds) и релизов (releases);
• Нет описания свойств проекта (используемые библиотеки, ресурсы и т.д.);
• Нет описания деплоя (deploy) проекта;
• Отсутствие тестов;
• Отсутствие общей базы знаний (БЗ);
• Нет достаточного внимания архитектуре проекта;

Чтобы решить данные проблемы, необходимо использовать определенные правила (методологии), регламентирующие фазы разработки ПО.

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

RUP
RUP (Rational Unified Process) - методология описывает весь жизненный цикл создания ПО. На практике поддержать все фазы методологии RUP сложно. Требуется достаточно большой пакет ПО, плюс специалисты разных областей. Поэтому, некоторые фазы можно отбросить и оставить самые важные.

XP
XP (eXtreme programming) методология, более гибкая по сравнению с RUP. Главная идея XP методологии – это совместная разработка (парами) и постоянный анализ проделанной работы.

Жестко следовать регламенту приведенных методологий нет необходимости. Но, игнорирование фаз, опробованных мировой практикой – крайне ошибочно.

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

Инструмент сборки проекта (build tool)

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

• Библиотеки, используемые в проекте, их версии;
• Другие ресурсы, необходимые для сборки/запуска проекта;
• Запуск тестов;

Для сборки проектов многие команды используют, всем известный инструмент Ant, который имеет следующие недостатки:

• Отсутствие регламентированного жизненного цикла сборки проекта;
• Отсутствие механизма управления библиотеками, ресурсами проекта;

Инструмент сборки - Maven от apache, призван решить данные проблемы и многие другие. Преимущества, которые дает maven:

• Регламентированный жизненный цикл сборки;
• Механизм управления библиотеками - централизован. Что позволяет избавиться от дублирования библиотек в разных проектах;

Система автоматической сборки проекта (build system)

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

• конфигурация проекта для диплоя на сервер;
• deploy проекта на сервер;

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

Преимущества

• быстрое обнаружение ошибок;
• экономия времени на хозяйственных операциях;
• оперативный доступ к последним изменениям в проекте;

На данный момент существует два лидера, предоставляющих ПО для Continuous Integration. Это – CrouseControl, Luntbuild. Обе программы богаты функционалом. На своем опыте знаю, что Luntbuild легче (намного) настраивать, чем CrouseControl.

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

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

1. Возможность привязки номера бага (issue) к изменениям в коде;
2. Возможность создавать записи не только типа bug, но и другие типы, такие как task, improvement и т.д.;

2-й пункт (в принципе) понятен. Следует обратить внимание на 1-й пункт. Привязка номера бага к коду позволяет участникам проекта, которые не исправляли баг, быстро находить изменения в коде, если оперативная ситуация требует быстрое вникание в суть проблемы. Консультироваться с автором нет возможности (уехал в отпуск, уволился и т.д.). Данный подход позволяет значительно сократить время на изучение изменений. Как правило, такую возможность предоставляют коммерческие системы. Мне известны Jira, Trac.

База знаний

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

Для создания БЗ хорошо подходит wiki.

Администратор сервера разработки

Инфраструктура для разработки состоит из достаточно большого набора программного обеспечения, кто-то всем этим должен управлять. Делегирование этих полномочий разработчикам - плохая идея, т.к. они будут решать проблемы администрирования, а не свои прямые обязанности – (вести разработку). Это будет замедлять развитие проекта (до 50% общего времени может уходить на администрирование, даже больше). Данным комплексом должен управлением отдельный человек, не задействованный в разработке. Разработчики должны выступать только в роли консультантов. Логично и целесообразно поручить это системному администратору (в нашей компании данная должность называлась Software Administrator), который уже есть в штате каждой компании. Если он не будет справляться, следует назначить ему помощника. В дальнейшем, данный специалист должен стать экспертом по многим продуктам и выступать в роли консультанта для разработчиков. Таким образом, они не будут тратить ценное время на чтение документации, скажем по не стандартным настройкам Tomcat.

Список ПО для администрирования:

• Application server (Tomcat, Resin и т.д.);
• Build system;
• Http server (apache);
• CVS;
• Wiki;

Рабочее место разработчика

Несоответствие аппаратной части (компьютера) также сильно влияет на процесс разработки. Необходимо помнить, что разработка ведется в отладочном режиме. Приходится выполнять ресурсоемкие операции, которые в обычном режиме не задействованы (production mode). Компьютер аналитика – это не компьютер разработчика, который в полном объеме попадает под определение – рабочая станция!

Резюме

Подводя итог выше сказанному, выделим основные цели и решаемые проблемы:

• Внедрение инструмента сборки проекта – maven – избавляет от дублирования библиотек в проектах, регламентирует фазы сборки проектов для проектных команд (наведет порядок в структуре проектов);
• Внедрение инструмента автоматической сборки (Build System) – быстрое обнаружение ошибок, экономия времени на хозяйственных операциях (сборка проекта, конфигурирование, копирование на сервер), оперативный доступ к последним изменениям в проекте;
• Внедрение базы знаний – централизованное хранение документации (архитектурных решения и т.д.) по проекту;
• Внедрение системы Issue tracker – централизованное ведение выявленных ошибок, улучшений, задач. Сохранение истории проведенных работ по тем или иным задачам;
• Использование ПК соответствующего решаемым задачам – выполнение поставленных задач. Экономия времени на ресурсоемких операциях (компиляция, генерация, отладка и т.д.);
• Администратор сервера разработки – Экономия времени разработчиков на администрирование;

Необходимые действия

1. Внедрение инструмента сборки проекта – maven

Шаги по внедрению:

• Настройка центрального репозитория;
• Знакомство с maven;
• Настройка проекта для maven;

Срок исполнения:

• Установка центральный репозиторий - 1 час;
• Изучение maven – от 2-х часов и более (в зависимости от задач);
• Настройка проекта для maven - 1 - 5 дней;

Продукт бесплатный.

2. Система автоматической сборки проекта (build system)

Шаги по внедрению:

• Исследования существующих систем;
• Установка;
• Добавление проекта в систему;

Срок исполнения:

• Исследования существующих систем – 1 – 2 дня;
• Установка – 1 – 3 часа (в зависимости от системы);
• Добавление проекта в систему – 1 – 16 часов (в зависимости от сложности проекта и наработок);

Стоимость продукта. На рынке присутствует две системы:

• Luntbuild - бесплатная;
• Teamcity – 200$;

3. Внедрение базы знаний

Шаги по внедрению:

• Исследования существующих систем (возможно исключить, если знания уже имеются);
• Установка;

Срок исполнения:

• Провидение исследования существующих систем – 2 дня;
• Установка – 1 – 3 часов;

Стоимость продукта: есть, как коммерческие системы, так и бесплатные.

4. Внедрение системы Issue tracker

Шаги по внедрению:

• Исследования существующих систем;
• Установка, настройка;

Срок исполнения:

• Исследования существующих систем – 2 – 3 дня;
• Установка – 1 – 5 часов;

Стоимость продукта: есть, как коммерческие системы, так и бесплатные.

Необходимый регламент
1. Для ведения Базы Знаний необходимо утвердить разделы, общие для всех проектов.
2. Написание регламента по тестам (junit).

Большое спасибо соучастнику Eugene Kirin за любезно предоставленную полезную статью