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