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

Содержание
Введение…………..……………….…………....…………………….… 3
1. Ключевое отличие распределенной разработки…...……….….…... 4
Заключение...……………….………....................................................... 9
Список литературы………....……………………………...……...….. 10
Введение
Практически ни одна организация не может обойтись без разработки или доработки программного обеспечения под свои потребности.
Разработка программного обеспечения (software development) — это род деятельности и процесс, направленный на создание и поддержание работоспособности, качества и надёжности ПОРаспределенная разработка программного обеспечения сегодня стала нормой: современные средства связи позволяют объединять людей, находящихся по разные стороны океана, а минимизация издержек при разработке в развивающихся странах привлекает заказчиков из стран Европы и США. Кроме того, специалистов нужной квалификации может просто не оказаться «на месте», и тогда взаимодействие с удаленными рабочими группами или внешними подрядчиками окажется просто необходимым.
Открытое программное обеспечение (англ. Open-source software) -- программное обеспечение с открытым исходным кодом. Исходный код таких программ доступен для просмотра, изучения и изменения, что позволяет пользователю принять участие в доработке самой открытой программы, использовать код для создания новых программ и исправления в них ошибок -- через заимствование исходного кода, если это позволяет совместимость лицензий, или через изучение использованных алгоритмов, структур данных, технологий, методик и интерфейсов (поскольку исходный код может существенно дополнять документацию, а при отсутствии таковой сам служит документацией).
Термин «open source» был создан вместе с определением в 1998 году Эриком Реймондом и Брюсом Перенсом, которые утверждали, что термин free software (свободное программное обеспечение) в английском языке неоднозначен и смущает многих коммерческих предпринимателей.
1. Ключевое отличие распределенной разработки
При сопоставлении с распределенной разработкой традиционного процесса (при котором разработчики находятся если не в одной комнате, то, по крайней мере, в одном здании) выявляется несколько различий. Одно из них можно считать ключевым: это значительное усложнение взаимодействия (особенно неформального) между участниками проекта.
Хотя в обществе сложилось представление о программисте как о классическом интроверте (человеке, который полностью погружен в работу и мало общается с коллегами в течение рабочего дня), исследования дают совершенно другую картину. Одно из них свидетельствует, что каждый разработчик уделяет в среднем 75 минут в день неформальному обсуждению с коллегами вопросов, связанных с проектом.
Современная практика допускает внесение изменений в проект не только при проектировании, но и на этапе кодирования, что обусловлено требованиями непрерывно изменяющегося рынка и условиями, в которых находится заказчик. Даже при идеально составленной проектной документации и определении ролей каждого из участников проекта неизбежно будут возникать ситуации, требующие согласования интерфейсов, поведения отдельных компонентов системы и даже общей функциональности. Однако координация, которая не вызывает особых проблем при работе в пределах одного здания, может оказаться сложной, если коллективы разработчиков разделены тысячами километров. Впрочем, согласно некоторым исследованиям, сотрудники, работающие в разных зданиях, общаются примерно с той же интенсивностью, что и их коллеги, находящиеся в разных частях света.
Наиболее очевидным параметром является время завершения проекта. Если одним специалистам регулярно приходится ждать других для решения каких-либо вопросов, то задержки неизбежны. Они возникают и при обычной, нераспределенной, разработке, но бывают значительно меньшими по времени. Опрос разработчиков нескольких десятков компаний из Великобритании и Германии, проведенный исследовательским подразделением Lucent Technologies, дал следующие результаты. При работе в пределах одного здания каждый реципиент сталкивался в среднем с 2,1 задержки в месяц при продолжительности каждой 0,9 рабочего дня. При распределенной разработке возникало 1,9 задержки в месяц, но их средняя продолжительность составляла уже 2,1 дня. Итак, разница в количестве задержек при локальной и распределенной разработке несущественна, тогда как разница в их продолжительности достаточно ощутима.
Количество и продолжительность задержек зависят от ряда параметров, характеризующих каждый проект создания программного обеспечения. Выявление зависимости этих параметров от задержек поможет свести последние к минимуму. С использованием статистических данных, полученных, в том числе при опросе нескольких сотен разработчиков, было проанализировано влияние следующих параметров на продолжительность задержек.
Число занятых в проекте разработчиков. Логично предположить, что при увеличении числа разработчиков растет количество и продолжительность задержек.
Распределение изменений по удаленным объектам. Чем больше количество модулей системы, затрагиваемых изменениями (особенно если эти модули разрабатываются в разных местах), тем более вероятны задержки.
Масштаб изменений. Чем больше изменений вносится, тем больше вероятность задержек.
Время первой модификации исходного кода. Считается, что время, затрачиваемое на изменение продукта с целью исправления ошибок, отличается от времени изменения при добавлении новых функций.
Серьезность изменений. Данный фактор можно рассматривать как аналог приоритетности изменений. Считается, что чем более высокий приоритет назначен изменению (например, при исправлении критически важных ошибок), тем быстрее оно будет проведено. Предполагается, что внесение изменений в рамках распределенной разработки потребует больше времени, чем при работе всей команды в одном месте.
Число разработчиков, масштаб и распределение изменений значительно увеличивают рабочий интервал внесения изменений в проект. Этот интервал увеличивается также со временем и уменьшается в соответствии с серьезностью изменений. Удивительно, но факт: то, что проект выполняется с участием удаленных коллективов, не приводит к существенному увеличению рабочего интервала. Для масштабных изменений требуется больше времени, и вполне вероятно, что для их реализации будут привлечены удаленные коллективы. Для реализации изменений, затрагивающих большее число компонентов системы (критерий — распределение изменений по удаленным объектам), требуется больше времени, и весьма вероятно, что такие изменения будут выполняться с помощью удаленных коллективов. Участие удаленных коллективов требует большего числа разработчиков, что, в свою очередь, приводит к значительному росту задержек.
Для дальнейшего анализа служит графическая модель Гаусса (рис. 1).

Рисунок 1 – Графическая модель Гаусса
Узлы здесь — исследуемые переменные факторы, а дуги — частная корреляция между ними. Частная корреляция между переменными отличается от обычной выборочной корреляции тем, что показывает величину взаимосвязи между переменными при фиксированных значениях других переменных, напрямую влияющих на выбранные. Толщина линии определяет значимость корреляции. В отличие от обычной корреляции (взаимозависимости величин), частная корреляция используется, если нельзя достоверно утверждать, что величины связаны между собой напрямую, а не через некоторую третью величину или группу величин. В таких случаях рассматривается так называемая «частная корреляция двух величин при неизменных значениях остальных величин». Переменные, не связанные между собой напрямую, являются независимыми при фиксированных значениях переменных, с которыми они связаны.
На рисунке 1 видно, что переменными, напрямую связанными с рабочим интервалом, являются число разработчиков, распределение и масштаб изменений. Не подтверждаются предположения о том, что более масштабные изменения требуют больших времени и участия удаленных коллективов, а также что изменения большего количества компонентов системы требуют большего времени и, скорее всего, — участия тех же удаленных коллективов. Критерий участия удаленных коллективов не имеет существенной частной корреляции с масштабом или распределением изменений.
Модель подтверждает предположение, что распределенная разработка обусловливает использование большего числа разработчиков, что, в свою очередь, приводит к увеличению задержек. Удаленная разработка сильно связана с количеством разработчиков, а последний фактор, в свою очередь, — с рабочим интервалом. Получается, что при выполнении проекта несколькими удаленными коллективами снижается скорость создания программного обеспечения — из-за привлечения большего количества разработчиков. Похоже, что одна из причин этого состоит в снижении эффективности взаимодействия разработчиков друг с другом, а также в недостатках координации коллективов.
Компаниям, участвовавшим в исследовании Lucent, был задан ряд вопросов. Анализ их ответов показал, что наибольший вклад в увеличение задержки вносит отсутствие помощи коллег при решении сложных задач в условиях распределенной разработки. Интересно, что данный фактор, по сути, является единственным значимым. Кроме того, ни один из опрошенных разработчиков не считает себя частью проблемы. Другими словами, разработчики уверены, что в равной степени помогают коллегам, находящимся с ними в одном здании и за тысячи километров от них. Однако те же самые специалисты убеждены, что получают гораздо большую помощь от местных коллег, нежели от удаленных. Одно из объяснений может быть таким: разработчики действительно пытаются быть полезными для других, но дистанционная помощь менее эффективна. Или же им трудно определять уровни сложности и срочности проблем, возникающих у удаленных разработчиков, то есть недооценивается важность помощи, за которой к ним обращаются.
В целом опрос свидетельствует о том, что координация и взаимодействие сильно страдают при распределенной разработке.
Во-первых, значительно проще разрабатывать и осуществлять изменения в многомодульном проекте, если все модули создаются и поддерживаются в одном месте. У разработчиков появляется возможность оперативно получать всю необходимую информацию «из первых рук».
Во-вторых, неформальное общение с разработчиками, создававшими изменяемый код (которое зачастую бывает весьма эффективным), практически недоступно участникам распределенных проектов.
В-третьих, при распределенной работе значительно сложнее найти специалиста, обладающего необходимыми информацией и опытом. Вероятность вовлечения в изменения нужного человека из удаленного коллектива много меньше, чем в том случае, когда все работы ведутся в одном месте, поэтому изменения займут больше времени и потребуют участия большего числа разработчиков.
Заключение
Открытое программное обеспечение — способ разработки ПО, при котором создаваемый исходный код программ открыт, то есть общедоступен для просмотра и изменения. Это позволяет всем желающим использовать уже созданный код для своих нужд и, возможно, помочь в разработке открытой программы.
Бесплатность ПО есть право пользователя, но не обязанность производителя — «открытая» лицензия не требует, чтобы ПО всегда предоставлялось бесплатно. Многие из наиболее успешных проектов «открытого» ПО, тем не менее, бесплатны. Подавляющее большинство открытых программ является одновременно «свободными» и наоборот, ибо определения открытого и свободного ПО близки, а большинство лицензий соответствуют обоим.Отличие между движениями открытого ПО и свободного ПО заключается в основном в приоритетах. Сторонники открытого ПО делают упор на эффективность открытых исходников как метода разработки. Сторонники свободного ПО исходят из идеологических соображений, и считают, что именно права на распространение, модификацию и изучение программ являются главным достоинством свободного ПО. Концепция OpenSource не означает всего лишь возможности доступа к исходному коду.
Список литературы
1. Гагарина, Л. Г. Технология разработки программного обеспечения / Л.Г. Гагарина, Е.В. Кокорева, Б.Д. Виснадул. - М.: Форум, Инфра-М, 2013. – 250 c.;
2. Гусятников, В. Н. Стандартизация и разработка программных систем / В.Н. Гусятников, А.И. Безруков. - М.: Финансы и статистика, Инфра-М, 2012. - 230 c.;
3. Лукин, В. В. Технология разработки программного обеспечения. Учебное пособие / В.В. Лукин, В.Н. Лукин, Т.В. Лукин. - М.: Вузовская книга, 2015. – 255 c.;
4. Орлов, С. А. Технологии разработки программного обеспечения / С.А. Орлов, Б.Я. Цилькер. - М.: Питер, 2012. – 390 c.;
5. Тузовский, А. Ф. Проектирование и разработка web-приложений. Учебное пособие / А.Ф. Тузовский. - М.: Юрайт, 2016. - 255 c.