ОСОБЕННОСТИ ИСПОЛЬЗОВАНИЯ СИСТЕМ КОНТРОЛЯ ВЕРСИЙ И УПРАВЛЕНИЯ СОВМЕСТНОЙ РАЗРАБОТКИ В ОТДЕЛЕ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

FEATURES OF USE OF SYSTEMS OF CONTROL OF VERSIONS AND MANAGEMENT OF JOINT DEVELOPMENT IN THE DEPARTMENT OF DEVELOPMENT OF SOFTWARE

Введение

 На сегодняшний день написано много книг о том, как управлять людьми и деятельностью, программным кодом и оборудованием для построения связи с клиентами или субподрядчиками. Существует много работ экспертов – гуру, а также ряд методологий и стандартов сертификации, таких как ITIL, PMBOK, SWEBOK, RUP, CMMI и т. д [1].  

К сожалению, универсального решения пока не найдено. Прежде всего, большинство концепций предполагают слишком формализованные процессы. Эта формализация, вероятно, оправдана в обществах, где разработка программного обеспечения не является бизнесом, а ИТ – отдел является сервисным подразделением, эффективность которого практически не влияет на прибыльность организации. Но для софтверных компаний чрезмерная формализация выражается в ненужных отчетах и ​​процессах («часы», сбор данных для метрик, которые необходимы только для «контроля» и т. д.) [3].

На наш взгляд, это подавляет инициативу и снижает производительность труда. Кроме того, существует деструктивная демотивация сотрудников: самые влиятельные программисты и аналитики просто отказываются работать в таких условиях (или требуют вознаграждения в супермаркете), в то время как другие склонны молча саботировать «бюрократию». Во – вторых, описания самих методологий не отвечают на вопрос, какую систему автоматизации использовать для управления разработкой [2, С.15].

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

В результате поиска эффективных методов коллективной разработки программного обеспечения, которые с одной стороны обеспечивают прозрачность и управляемость, а с другой  –  минимальные накладные расходы, мы придумали минимальную модель информационных объектов в процессе разработки и соответствующий набор Системы с открытым исходным кодом для хранения этих объектов. Благодаря открытию исходного кода выбранные системы были интегрированы друг с другом и адаптированы к методам гибкой разработки, разработанным компанией. Долгое время мы обнаружили, что наши подходы очень близки к подходу Scrum, и мы перешли к нему, используя домашние методы, основанные на творческой переоценке принципов экстремального программирования и упрощенном ориентированном на клиента управлении проектами (разработка итеративного макета в приоритетных областях заказчика) [4].

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

Рис. 1.  Информационные объекты в разработке программного обеспечения

 

Основная классификация возникающих информационных объектов в процессе разработки и сопровождения таможенных информационных систем может быть представлена ​​в виде модели, показанной на рис. 1 [2].

Информационные объекты, аналогичные атрибутам, и методы работы с ними сгруппированы в три разных цветовые зоны. Например, пересекающаяся область, документация для программных продуктов, охватывает как созданные артефакты, так и базу знаний. На пересечении «зоны знаний» и «проблемной зоны» находится история решения проблем. Выбор информационных систем в соответствии с этим подходом требует, с одной стороны, полного охвата этих проблемных областей, а с другой стороны, сводит к минимуму количество конкурирующих информационных систем в каждой из этих областей.  Предположим, мы вводим систему регистрации проблем в верхней красной зоне, другую для регистрации инцидентов, третью для запросов на регистрацию, несколько других систем регистрации и другую систему регистрации ошибок [2, С.108] .

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

Системы должны обеспечивать максимальную производительность в коллективной работе, хотя за счет некоторых индивидуальных удобств  –  обязательно должно быть «лекарство от страха» в форме поддержки контроля версий и истории изменений. Например, это означает выбор систем контроля версий с возможностью параллельной работы без исключительных блоков и автоматической модификации изменений, а также максимально возможную замену текстовых процессоров для документов в двоичном формате на системы группового управления документами в простых текстовых тегах, таких как SGML Docbook, XHTML. XML, LaTeX и т. д [1].

Кроме того, требуется максимальная прозрачность и простота мониторинга процессов, что означает возможность быстрого поиска и отслеживания информационных объектов и их взаимосвязей через веб – интерфейс, получения ответов на такие вопросы, как «что с этим было сделано». ? »,« Какой код был изменен для исправления? Таких и таких ошибок? »,« Где история обсуждения этой проблемы и как долго она решалась? », Не говоря уже о простом поиске текст для ответов на вопросы «где ключи от офиса?» и «что делать, если возникает ошибка?» 0x8040459 в. Модули PM – BLACK – BOX? ».

Рис. 2. Покрытие проблемных зон системами – решениями

 

Для себя мы выбрали тот, который показан на рис. 2  –  диаграмма покрытия проблемных областей, показанных на рис. 1. Бронируйте сейчас: наш выбор может быть не оптимальным сегодня  –  для каждой выбранной нами системы есть коммерческие и бесплатные аналоги, которые могут быть превосходного качества, но эта система работает для нас, может быть взята за основу и заменена отдельными компонентами более уместно. Пунктирный квадрат указывает область систем с веб – интерфейсом, в котором однонаправленные стрелки указывают на возможность гипертекстовых переходов между соответствующими объектами в этих системах. Двунаправленные стрелки показывают более сложную интеграцию перегрузки данных. Следует также отметить, что OmniFind не является системой с открытым исходным кодом, но она полностью бесплатна и допускает адаптацию, которая достаточна для наших целей, и до момента ее выбора не было других бесплатных аналоговых поисковых систем, включающих морфологию России.

Заключение

В настоящее время мы используем две системы контроля версий: CVS и SVN (Subversion). Многие проекты были собраны для CVS, но многие из них в настоящее время недостаточно развиты, и нет смысла преобразовывать их в SVN, а все новые проекты, находящиеся в стадии активной разработки, были преобразованы в SVN. Для тех, кто выбирает систему контроля версий с нуля, мы рекомендуем немедленно использовать SVN. Дружественный графический интерфейс TortoiseSVN (также бесплатный и с открытым исходным кодом) позволяет работать с Subversion даже с обслуживающим персоналом. А отсутствие «унаследованных» заболеваний CVS (например, невозможность изменить структуру файла без потери истории) позволяет исправлять любые ошибки, допущенные неопытными сотрудниками в хранилище. Рассмотренный подход позволяет автоматизировать командную работу в компании – разработчике с сотнями сотрудников, практически бесплатно.

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

 

 

Список литературы / References

  1. Грей Клиффорд Ф, Ларсон Эрик У. Управление проектами. Практическое руководство: Пер. с англ. — М.: Изд. «Дело и сервис», 2003.
  2. Дюваль, П. М. Непрерывная интеграция. Улучшение качества программного обеспечения и снижение риска / П. М. Дюваль. –  М. : Вильямс, 2008.  –  345 с.
  3. Федоров, В. К. Контроль и испытания в проектировании и производстве радиоэлектронных средств / В. К. Федоров, Н. П. Сергеев, А. А. Кондрашин. –  М. : Техносфера, 2005.  –  504 с.

Список литературы на английском языке / References in English

  1. A successful Git branching model [Электронный ресурс]. — URL: http://nvie.com/posts/a – successful – git – branching – model (датаобращения: 15.11.2015)
  2. Scott Chacon. Pro Git / Scott Chacon, Ben Straub. — New York: Apress, 2009. 598 p.
  3. Susan Potter. Архитектура приложений с открытым исходным кодом / Susan Potter — New York: O'Reilly, 2013.
  4. CI Feature Matrix [Электронный ресурс]. –  URL: http://confluence.public. thoughtworks.org/display/CC/Cl+Feature+.