Анализ программ по коллективной разработке ПО

Дата: 2025-06-14; Просмотры: 1

Оценка:

0.00 из 5.00 — оценок

Скачиваний: 0

Скачать

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

Говоря о Mercurial следует отметить, что простой и отточенный интерфейс, и набор команд, возможность импортировать репозиториев с других систем контроля версий, — сделают переход на данную программу безболезненным и быстрым, а её надёжность и скорость работы позволяют пользоваться имя для контроля версий огромных проектов. Все это позволяет Mercurial стать достойным конкурентом git’а.

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

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

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

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

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

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

2. Авторская разработка.

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

Этот принцип был достаточно широко распространен в 70-80-е годы XX века. Сейчас он применяется редко. Примерами авторских разработок являются операционная система Диспак , текстовый редактор Лексикон, трансляторы с языков Algol-68 и Pascal .

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

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

По данным А. П. Кулаичева [Кулаичев 1999], авторская разработка может выигрывать по производительности в тридцать и более раз у коллективной разработки, что достигается за счет:

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

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

Объем программного продукта, выполненного методом авторской разработки, в 5-20 раз меньше по сравнению с индустриальными аналогами.

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

3. Коллективная разработка.

Одним из основных вопросов коллективной разработки является разделение труда - от равноправных соисполнителей до организации в виде жесткой иерархии (например, бригады главного программиста).

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

3.1 Технические командные роли.

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

· инженеры-разработчики (специалисты по инженерии программирования и программисты);

· технические писатели;

· инженеры тестирования;

· инженеры качества;

· специалисты по сопровождению продукта;

· специалисты по продажам продукта.

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

· Разработка приложений.

ü Программист.

ü Специалист по инженерии программирования.

ü Специалист по инженерии знаний.

· Работа с приложениями.

ü Специалист по приложениям.

ü Администратор данных.

ü Администратор базы данных.

· Техническая поддержка.

ü Системный администратор.

ü Сетевой администратор.

ü Администратор коммуникаций,

· Обеспечение качества продукта.

ü Технический писатель.

ü Инженер тестирования.

ü Инженер качества.

· Маркетинг.

ü Специалист по сопровождению продукта.

ü Специалист по продажам продукта.

· Системное интегрирование.

ü Системный интегратор.

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

3.2. Бригада главного программиста

Харлан Миллз предложил организовывать команды (бригады) главного программиста (chief programmer teams), подобные хирургическим бригадам. Лишь один участник команды занимается основной работой, остальные оказывают ему всевозможную поддержку. Бригада главного программиста включает десять человек, выполняющих специализированные роли в команде.

Основные члены бригады выполняют функции, перечисленные ниже:

· Главный программист. Лично выполняет анализ и проектирование, создание и отладку кода, написание документации. Должен обладать талантом, большим опытом работы и существенными знаниями.

· Дублер. Может выполнять любую работу главного программиста, но менее опытен. Подстраховывает главного программиста, может заниматься написанием кода, но не несет ответственности за проект.

· Администратор, он же - менеджер. Под его контролем - деньги, люди, помещения, машинные ресурсы, контакты с другими группами и руководством.

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

· Языковед. Эксперт в тонкостях языков программирования. Может найти эффективные способы использования языка для решения сложных задач. Обычно работает с несколькими бригадами.

· Инструментальщик. Разработчик специализированных инструментов - утилит и скриптов. Поддерживает основной инструментарий и оказывает по нему консультации. При необходимости может осуществлять администрирование операционной системы.

· Отладчик. Разработчик тестов и организатор тестирования программного продукта.

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

3.3. Психологические командные роли

Роб Томсет (Rob Thomsett) предложил восемь ключевых ролей в проекте.

· Председатель. Выбирает путь, по которому команда движется вперед к общим целям. Умеет обнаружить сильные и слабые стороны команды и обеспечить наибольшее применение потенциала каждого ее участника.

· Архитектор. Он же оформитель. Придает законченную форму действиям команды. Имеет четкое представление о проблемах и их возможных решениях.

· Генератор идей. Предлагает радикально новые идеи и стратегии, новые подходы к решению проблем, с которыми сталкивается группа. Особое внимание уделяет главным проблемам.

· Критик. Он же скептик, оценивающий проблемы с прагматической точки зрения. Ищет недостатки, изъяны и недоделки. Компенсирует оптимизм генератора идей.

· Исполнитель. Работник, собственно занимающийся написанием кода. Как правило, он не обладает широтой кругозора.

· Завершающий. Поддерживает в команде настойчивость в достижении цели. Играет доминирующую роль на завершающих стадиях разработки.

· Дипломат. Поддерживает силу духа в участниках проекта. Оказывает им помощь в трудных положениях. Пытается улучшить взаимоотношения в команде.

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

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

3.4. Типы совместной деятельности.

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

· Мандатная деятельность, обычно представленная формальными собраниями, проводимыми на регулярной основе. Обычно собрания планируются заранее, а присутствие на них обязательно. Статистика показывает, что программисты проводят около 4% своего рабочего времени на собраниях.

· Созываемая деятельность, которая имеет место в случае решения двух или более программистов собраться вместе для решения некоторого технического вопроса. Такие собрания обычно не планируются заранее и в них участвуют только действительно заинтересованные в решении проблемы программисты. На эту деятельность уходит около 14% рабочего времени.

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

· Индивидуальная деятельность имеет место, когда программист работает над задачей, которая не выполняется в то же самое время никаким другим программистом и поэтому маловероятно его взаимодействие по этому предмету с любыми другими программистами группы. Эта деятельность занимает также около 41% рабочего времени.

4. Общинная модель разработки.

Идеология общинной ("базарной") модели разработки сформулирована в программной статье Эрика Раймонда (Eric Raymond) "Собор и Базар" .Общинная модель характеризуется тремя основными факторами.

· Децентролизованность разработки. Не существует ограничения сверху на количество людей, принимающих участие в проекте. Как правило, разработки такого типа ведутся на базе сети Интернет и могут включать любого заинтересованного разработчика Сети.

· Разработка ведется на базе открытых исходных текстов. По ним можно разобраться с сутью задачи и в любой момент подключиться к разработке.

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

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

· Каждая хорошая программа начинается с энтузиазма разработчика.

· Хорошие программисты знают, что можно написать, а великие - что можно переписать.

· При правильном отношении интересная проблема найдет вас сама.

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

· Следует выпускать ранние и частые версии программ.

· Обнаружить проблему и исправить ее могут разные люди.

· Иногда использовать идеи пользователей лучше, чем свои идеи.

Контрольные вопросы:

1. Что такое коллективная разработка?

2. Какие процессы включает в себя коллективная разработка?

3. Какие есть системы управления версиями?

4. Что такое авторская разработка?

5. Какой состав бригады разработчиков?

6. Основные члены бригады какие выполняют функции?

7. Психологические командные роли?

8. Какие есть типы совместной деятельности ?

9. Основные факторы общинной модели ?

10. Особенности общинной модели ?

Список используемой литературы:

1. Иванова Г. С. Технология программирования. М.: Изд-во

МГТУ им. Баумана, 2002.

2. Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Технология разработки программного обеспечения: учебное пособие / под ред. Л. Г Гагариной. — М: ИД «ФОРУМ»: ИНФРА-М, 2008.