Распределенная разработка программного обеспечения

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

Размещено на

Содержание

Введение

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

1.1 Ключевое отличие распределенной разработки. Достоинства и недостатки

1.2 Концептуальное решение и выбор типа разработки

2. Особенности программного обеспечения с открытым исходным кодом

2.1. Идея и развитие Open Source

2.2. Наиболее важные Open Source - проекты

Заключение

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



Введение

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

Распределенная разработка программного обеспечения сегодня стала нормой: современные средства связи позволяют объединять людей, находящихся по разные стороны океана, а минимизация издержек при разработке в развивающихся странах привлекает заказчиков из стран Европы и США. Кроме того, специалистов нужной квалификации может просто не оказаться «на месте», и тогда взаимодействие с удаленными рабочими группами или внешними подрядчиками окажется просто необходимым.

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

Термин «open source» был создан вместе с определением в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих коммерческих предпринимателей.

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

Отличие между движениями открытого ПО и свободного ПО заключается в основном в приоритетах. Сторонники термина «open source» делают упор на эффективность открытых исходников как метода разработки, модернизации и сопровождения программ. Сторонники термина «free software» считают, что именно права на свободное распространение, модификацию и изучение программ являются главным достоинством свободного открытого ПО.



1 Распределенная разработка программного обеспечения

1.1 Ключевое отличие распределенной разработки. Достоинства и недостатки

Несмотря на ряд достоинств, распределенная разработка программного обеспечения имеет и определенные недостатки. Привлекая более квалифицированную или дефицитную рабочую силу, снижая издержки, компании-разработчики неизбежно за это «расплачиваются». Усложняется их контроль над качеством продуктов, увеличиваются сроки создания программных продуктов, растет количество проблем, связанных с координацией действий разрозненных рабочих групп. Есть ли возможность хотя бы минимизировать негативные последствия децентрализации разработки? Есть, но она обеспечивается не только определенными инструментами поддержки групповой работы. Не существует решения, которое разом решит все проблемы, поэтому необходимо комплексное использование инструментов и новых методологий разработки и контроля над качеством.

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

Хотя в обществе сложилось представление о программисте как о классическом интроверте (человеке, который полностью погружен в работу и мало общается с коллегами в течение рабочего дня), исследования дают совершенно другую картину. Одно из них свидетельствует, что каждый разработчик уделяет в среднем 75 минут в день неформальному обсуждению с коллегами вопросов, связанных с проектом. Согласно исследованию, разработчики телекоммуникационного программного обеспечения тратят на формальное и неформальное взаимодействие с коллегами 50% своего времени -- вплоть до последнего месяца разработки, когда этот показатель снижается до 10%. Конечно, показатели варьируются от проекта к проекту, но можно однозначно утверждать, что общение имеет для разработчика огромное значение.

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

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

Какое непосредственное влияние оказывает уровень взаимодействия разработчиков на выполнение проекта? Наиболее очевидным параметром является время завершения проекта. Если одним специалистам регулярно приходится ждать других для решения каких-либо вопросов, то задержки неизбежны. Они возникают и при обычной, нераспределенной, разработке, но бывают значительно меньшими по времени. Опрос разработчиков нескольких десятков компаний из Великобритании и Германии, проведенный исследовательским подразделением Lucent Technologies, дал следующие результаты. При работе в пределах одного здания каждый реципиент сталкивался в среднем с 2,1 задержки в месяц при продолжительности каждой 0,9 рабочего дня. При распределенной разработке возникало 1,9 задержки в месяц, но их средняя продолжительность составляла уже 2,1 дня. Итак, разница в количестве задержек при локальной и распределенной разработке несущественна, тогда как разница в их продолжительности достаточно ощутима.

Примерно те же результаты получены при анализе запросов на изменение проекта в целом. В среднем при локальной разработке на одно существенное изменение в проекте (исправление ошибок или добавление новых функций) требовалось 5 дней (с начала реальной работы до внесения последних изменений в код -- это называется «рабочим интервалом»). Если в создании программных продуктов участвовали несколько удаленных коллективов, такой интервал увеличивался до 12,7 дня (то есть более чем в два с половиной раза). Ситуация с полным интервалом (временем с момента поступления запроса на изменение до внесения последнего изменения в код; этот интервал несколько больше рабочего, поскольку включает в себя время, необходимое для анализа запроса, назначение приоритета и т.п.) аналогична: 20,5 дня против 12,7.

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

· Число занятых в проекте разработчиков. Логично предположить, что при увеличении числа разработчиков растет количество и продолжительность задержек.

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

· Масштаб изменений. Чем больше изменений вносится, тем больше вероятность задержек.

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

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

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