Содержание


Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Часть 1. Особенности разработки ПО в коллективе, контроль версий, подготовка документации

Comments

Серия контента:

Этот контент является частью # из серии # статей: Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Организация совместной разработки ПО на базе SVN+DocBook+Mantis

Следите за выходом новых статей этой серии.

Кому адресована статья

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

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

При совместной работе следует решить для себя следующие вопросы:

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

Каждый из вопросов по-своему важен и решается разными средствами, однако ни один из них не может быть проигнорирован.

Объекты, участвующие в разработке

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

  • Заказчик (физическое или юридическое лицо, которое желает получить программный продукт и с которым заключены договорные отношения).
  • Администрация (руководящее звено заказчика, уполномоченное решать финансовые и юридические вопросы).
  • Рабочая группа по разработке системы (часть общей рабочей группы со стороны заказчика).
  • Руководитель (лицо, отвечающее за ход разработки и внедрения со стороны заказчика).
  • Специалисты по предметной области (представители тех подразделений заказчика, в которых будет внедряться новая система).
  • Сотрудники IT подразделений (специалисты в области вычислительной техники со стороны заказчика: отдел ИТ, системные, сетевые и прочие администраторы).
  • Исполнитель (также физическое или юридическое лицо, обязующееся на договорной основе выполнить определенный объем работ для заказчика)
  • Администрация (то же, что и у Заказчика)
  • Рабочая группа по разработке
  • Руководитель проекта (координатор, главная задача которого заключается в организации работы коллектива)
  • Системные аналитики (исследуют предметную область на выявление семантических зависимостей и бизнес-правил)
  • Программисты (ведут конкретную работу по созданию программного обеспечения, его настройке, модификации, модернизации и исправлению ошибок)
  • Тестировщики (со стороны исполнителя проводят проверку работоспособности функционала и качества пользовательского интерфейса)
  • Техническая поддержка при внедрении (обучение персонала заказчика, дублирование его работы, решение вопросов, не требующих изменения ПО)

Субъекты разработки

  • Финансово-правовая документация.
  • Техническая документация.
  • Справочная документация.
  • База данных.
  • Серверное программное обеспечение.
  • Клиентское программное обеспечение.

Схема взаимодействия субъектов

Финансово-правовая информация, как правило, циркулирует внутри довольно узкого круга лиц и доступ к ней строго ограничен, что делает ее для нас неинтересной.

Техническая документация должна быть доступна для редактирования руководителю проекта, программистам и системным аналитикам, а для чтения – всем участникам проекта. При этом следует отметить, что одни и те же документы могут, с одной стороны, редактироваться одновременно несколькими людьми, что накладывает определенные ограничения на формат файлов, а с другой стороны – должны передаваться заказчику в одном из широко используемых форматов (pdf, rtf, doc и т. д.).

Справочная информация также готовится коллективно и также передается заказчику в удобном для него формате.

База данных – совокупность схемы и данных. Данные – это дело заказчика, они нужны при разработке только для тестирования программного обеспечения. Ряд фирм специально разрабатывают средства для переработки данных (для этого используется термин «маскирование данных») таким образом, что сохраняя семантические ограничения (очень важно для тестирования), данные меняются и становятся бесполезными для злоумышленников. Схема базы данных представляет для разработчиков текстовый скрипт на языке SQL создания схемы и так называемый alter-скрипт, хранящий все изменения с комментариями в виде тех же команд SQL.

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

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

Виды программного обеспечения, необходимые для организации работы

Системы контроля версий

(Version Control Systems, VCS). Назначение систем контроля версий заключается в предоставлении нескольким работникам возможности вносить изменения в одни и те же файлы. Заметим сразу, что речь идет именно о текстовых файлах. Не важно – это простой текстовый файл или структурированный текстовый файл. Остальные файлы относятся к бинарным.

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

Системы контроля версий позволяют хранить, с одной стороны, историю всех изменений, внесенных участниками проекта (часто приводят пример «машины времени», когда имеется возможность вернуться к состоянию проекта в определенный момент времени), и учитывать все изменения, вносимые во все файлы.

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

Основные характеристики систем контроля версий

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

Система является коммерческой или бесплатной. Если вы платите за программу, то это еще не значит, что вы получили лучшее.

Atomic Commits – возможность атомарных фиксаций изменений, сделанных в рабочей копии в хранилище. В этом случае все изменения, во всех файлах рабочей копии, внесенные после последней фиксации в хранилище, будут зафиксированы после одной команды фиксации (commit).

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

Разделение файлов. В модели «Блокирование–Изменение–Разблокирование» участник, редактирующий файл, блокирует доступ к нему до фиксации изменений в хранилище. Остальные участники при этом полностью лишены возможности редактирования этого файла. В модели «Копирование–Изменение–Слияние» один и тот же файл могут редактировать одновременно несколько участников. Если при этом они работают с различными частями файла (еще раз – это именно текстовый файл), то потом изменения сливаются. Если редактируется одна часть файла, то запрашивается, какое из изменений надо принять, и окончательное решение принимается обязательно в ручном режиме (это вопрос принципиальный, и подробнее о нем будет рассказано в следующих статьях цикла).

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

Остальные характеристики, с моей точки зрения, не столь существенны, и их можно просто перечислить:

перемещение и переименование файлов и директорий, копирование файлов и директорий, репликация, создание удаленной копии репозитория, разграничение доступа к различным частям репозитория, объединение группы связанных изменений в разных файлах в один логический блок, подробная история построчных изменений, возможность получения отдельной директории из репозитория, контроль изменений в рабочей копии до фиксации в репозиторий, задание отдельного текста комментария для отдельного файла при фиксации, наличие Web-интерфейсов пользователя, наличие GUI-интерфейсов пользователя, встроенная поддержка во многих IDE.

Сравнение наиболее распространенных систем

Если у вас появилось желание выполнить сравнение различных систем, то здесь вам окажет неоценимую помощь специализированный сайт http://www.versioncontrolblog.com/comparison/, на котором предлагается сравнить 27 систем (по данным на момент написания статьи). Интерфейс построен таким образом, что вы можете выбрать несколько приглянувшихся систем, и автоматически будет сформирована таблица, где они будут сравниваться по нескольким параметрам.

Подход к выбору системы контроля версий

Однозначного подхода до сих пор не существует, однако можно следовать некоторым рекомендациям:

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

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

Основные характеристики Subversion

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

  • соответствие приведенным выше рекомендациям;
  • совместимость сверху вниз с широко распространенными системами RCS (прототип CVS) и собственно CVS (прототип Subversion);
  • наличие Web- и GUI-интерфейсов;
  • подробная документация.

Системы хранения и обработки документации

Почему не подходят стандартные офисные пакеты

Процессу подготовки технической документации должно уделяться самое пристальное внимание. Кроме стандартных средств, к которым можно отнести текстовые процессоры (OpenOfficeWriter, MS Word и т. д.), широкий ряд продуктов Adobe (Adobe FrameMaker, Adobe RoboHelp, Adobe Captivate, Adobe Acrobat), на рынке присутствует ряд специализированных программ, предназначенных для автоматического формирования документации на основе программного кода (Javadoc, phpDocumentor и т. д.).

Последняя группа слишком сильно ориентирована на программный код, что препятствует разработке таких документов, как «Руководство оператора», «Техническое задание» и прочие, не основанные на программном коде.

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

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

Тут на помощь приходят специализированные средства (почему такое странное название, станет понятно позже), которые предоставляют нам следующие возможности:

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

Очень хорошо этому удовлетворяет DocBook, краткий обзор которого будет приведен ниже.

Основы DocBook

На самом деле DocBook вовсе не является системой для подготовки документов, а представляет собой набор правил для создания структурированного текстового файла. Этот файл состоит из набора тегов, и в этом отношении очень похож на широко известный HTML. DocBook поддерживает форматы XML и SGML. За счет этого он легко поддерживается системами контроля версий и, следовательно, с документами в этом формате могут свободно работать сотни пользователей одновременно.

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

Стили форматирования хранятся отдельно и, следовательно, нет необходимости в согласовании формата каждого из документов.

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

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

Регистрация ошибок, замечаний и пожеланий в процессе разработки и эксплуатации

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

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

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

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

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

В настоящее время широко распространены следующие программы.

Свободно распространяемые:

  • Bugzilla
  • BUGS – the Bug Genie
  • eTraxis
  • Mantis bug tracking system
  • Trac
  • EmForge
  • Redmine

Проприетарные:

  • Atlassian JIRA
  • PVCS Tracker
  • TrackStudio Enterprise

В последующих статьях будет рассмотрен MantisBT, выбранный в силу следующих причин:

  • для работы достаточно широко известной связки Apache+PHP+MySQL;
  • вся работа идет через Web-интерфейс;
  • работает практически без дополнительных настроек;
  • имеется достаточное количество плагинов, расширяющих возможности.

Имитация среды пользователя

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

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

В кругах программистов широкой популярностью пользуются VMware Workstation и Sun Microsystems, VirtualBox, хотя всего список виртуальных машин составляет около 30 наименований.

Рассматривать будем VirtualBox по причине ее легкости, кроссплатформенности, простоты в эксплуатации и настройке.

Защита информации при разработке совместного ПО

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

Одним из наиболее надежных протоколов передачи шифруемой информации через компьютерные сети является SSH (Secure Shell), который может использоваться совместно с Subversion для защиты данных в хранилище.

Заключение

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


Ресурсы для скачивания


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=500632
ArticleTitle=Организация совместной разработки ПО на базе SVN+DocBook+Mantis: Часть 1. Особенности разработки ПО в коллективе, контроль версий, подготовка документации
publish-date=07152010