Достижение качества открытого программного обеспечения

В публикуемых исследованиях предпринимаются серьезные попытки разобраться в механизме разработки программ категории Open Source, и при этом называются одни и те же ключевые факторы, благодаря которым достигается высокое качество программного обеспечения. В статье рассказывается о сделанных в этих исследованиях выводах, сравниваются различные подходы к обеспечению качества открытого программного обеспечения и обсуждается возможность их использования в разработке «традиционного» программного обеспечения.

Модели качества

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

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

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

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

Управление качеством

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

Устойчивое сообщество

Высокое качество открытого программного обеспечения во многом определяется существованием устойчивого сообщества, способного быстро разрабатывать код, эффективно его отлаживать и создавать новые возможности. Выводы многих исследований сводятся к тому, что формирование устойчивого сообщества должно стать основной целью проекта по созданию открытого программного обеспечения [1-3]. Изучение эволюции подобных проектов показало, что одним из важнейших факторов успеха было участие в них большого числа волонтеров [4]; кроме того, необходимо, чтобы программная система и сообщество развивались параллельно.

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

Концентрическая модель устойчивого сообщества разработки программного обеспечения

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

Для концентрической модели характерно следующее.

Основная группа должна быть небольшой. Именно эта группа пишет немалую часть кода, но, кроме того, она осуществляет общий контроль над системой. Члены основной группы интегрируют в систему только высококачественный код, определяют и выполняют план реализации проекта, а также поддерживают достаточно частый выпуск новых, итеративных версий кода. Согласно данным исследования, посвященного проекту Apache, основная группа разработчиков из 15 человек создала более 80% всего кода, реализующего функции системы [6]. Как правило, основные группы бывают очень невелики, но при этом они выполняют основной объем работ.
Соразработчики добавляют и поддерживают функции системы. Возможность легко добавлять новые функции зависит от уровня модульности кода. Соразработчики, как правило, выбирают направления, четко очерченные в планах реализации проекта, или те, которые «задевают их за живое». Также они занимаются исправлением ошибок, анализом предлагаемого кода и оказывают другую помощь, освобождая основную группу от чересчур объемной работы по исправлению ошибок.
Специалисты, сообщающие об ошибках, отвечают за тестирование и обнародование его результатов. Основные разработчики и соразработчики практически не занимаются решением этих задач. Достаточно большой размер этих групп гарантирует, что систему будет тестировать больше людей (и на большем числе платформ), чем этого могла бы добиться любая коммерческая организация. Эта группа играет основную роль в уменьшении «плотности» ошибок.

Участие и мотивация. Устойчивое сообщество нередко привлекает к работе программистов-волонтеров. Изучению мотивации волонтеров посвящено немало исследований.

Высокая модульность кода упрощает разработку и позволяет новичкам вносить свой вклад «на периферии», не влияя на основную систему, однако сама по себе модульность не сможет заинтересовать программистов в проекте. Аудрис Москус и его коллеги провели исследование Mozilla — проекта с высоким уровнем модульности, который сперва не заинтересовал волонтеров. Число его участников стало расти только после того, как основная группа доработала документацию, подготовила учебные руководства, а также усовершенствовала инструментарий и процессы разработки [7]. Кроме того, важным стимулом для участия волонтеров в проекте становится желание изучить новые технологии и инструменты и попробовать силы в решении новых задач [8].

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

Программисты хотят приобрести социальный статус, который «определяется не тем, чем вы владеете, а тем, что вы отдаете», и поэтому стараются создавать высококачественный код [2].
Ожидаемые признание и похвала со стороны членов сообщества (то есть публичное упоминание их имен) служат дополнительным мотивом для участников проекта [8].
По мере того как проект развивается и становится более успешным, он вызывает интерес у все большего числа разработчиков, которые хотят разделить его успех и привлечь к себе определенное внимание [9].

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

Модульность кода

Исследование разработки ядра Linux, проведенное Гвендолином Ли и Робертом Коулом, еще раз подтвердило, что модульность кода позволяет многим программистам расширять основную программу, работая над отдельными модулями. При этом им не нужно менять основную систему или слишком глубоко разбираться в ней, а также зависеть от результатов работы других разработчиков [10]. Это снижает риск появления новых ошибок в других модулях.

Изучение опыта проектов Apache и Mozilla позволило прийти к выводу, что низкая плотность ошибок в обоих проектах стала следствием высокой модульности кода. Немаловажную роль сыграл и тот факт, что поиском и исправлением ошибок занималось множество людей [7].

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

Еще одно исследование, касающееся разработки ядра Linux, показало, что модульность кода позволяет множеству программистов работать над одним и тем же комплексным решением, часто конкурируя друг с другом, что увеличивает вероятность создания качественного решения в срок [11]. Также исследователи отмечают, что конкуренция ведет также к более качественному, эффективному и долговременному исправлению ошибок [12].

Управление проектами

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

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

Как утверждает Эрик Реймонд, частому выпуску новых версий способствует взаимный анализ кода и быстрая реакция на комментарии и код специалистов, выполняющих этот анализ, что стимулирует их участие и заинтересованность [2]. Это находит отражение в продукте, который динамично развивается и расширяется и быстро достигает высокого качества. С другой стороны, Стив Макконнелл считает, что взаимный анализ кода, выполняемый большим числом участников, действительно полезен, но он не обязательно эффективен, и что, согласно лучшим практическим методам программной инженерии, оптимальным является, когда такую работу выполняют пять-шесть человек [13].

Утверждение Реймонда, что «при достаточном количестве глаз все ошибки оказываются мелкими» [3], означает следующее: если программную ошибку видит достаточно много людей, то по крайней мере один из них, скорее всего, поймет, в чем ее причина, и сможет ее исправить. Это особенно важно, учитывая, что, согласно выводам исследования ядра Linux, 75% разработки, как правило, — это рутинные, трудоемкие задачи, такие как отладка, анализ кода и исправление ошибок. Поскольку проекты категории Open Source располагают значительно большим количеством людских ресурсов, чем коммерческие проекты, то их разработка может вестись быстрее, чем это позволяет модель закрытых исходных текстов, и дает возможность добиваться более высокого качества [10]. Кристина Гашек и Тони Лори убедились, что при создании открытого программного обеспечения над разработчиками не так довлеют факторы времени и затрат, как при реализации коммерческого программного обеспечения, поэтому, хотя участие большого числа рецензентов не гарантирует эффективность взаимного анализа, возможно, это не так уж и важно [14].

Конечно, анализ кода при разработке коммерческих проектов практикуется десятилетиями. Изучение того, как применялись методы разработки открытого программного обеспечения в Hewlett-Packard, показало, что анализ кода в данном случае ведется непрерывно, а при создании традиционного программного обеспечения это, как правило, процесс, в лучшем случае, состоящий из одного или двух этапов [15]. Другие пришли к выводу, что взаимный анализ кода, выполняемый людьми, не входящими в состав основной команды проекта и не заинтересованными в том, чтобы закрывать на что-то глаза, заметно способствует повышению качества [16].

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

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

Управление людьми. Этот аспект управления проектом играет существенную роль в разработке программного обеспечения высокого качества. К этой области относится создание эффективной среды и формирование культуры, которую некоторые считают не менее важной, чем архитектура системы [4]. При разработке открытого программного обеспечения активно поддерживаются инновации и творчество, что способствует формированию более ориентированного на людей процесса, чем традиционная разработка, где доминируют методы, инструменты и методики [14].

Слова «ориентированный на людей процесс» означает, что волонтеры вправе присоединиться к основной группе и предложить свою помощь в работе над конкретной функциональностью [4]. Ютака Ямаучи и его коллеги согласны с тем, что это приводит к формированию стиля стихийной работы, которую начинают координировать лишь на определенном этапе — серьезное отличие от традиционной разработки, при которой координация и планирование осуществляются изначально [17]. Разработку открытого программного обеспечения характеризуют как действие, эксперимент и инновации, за которыми следуют координация, взаимный анализ кода, совершенствование и стабильность.

Однако другие исследования показывают, что действие не всегда предшествует координации. При разработке Apache, когда основная группа находила альтернативные решения проблемы, она просила прислать свои отзывы специалистов из списка почтовой рассылки разработчиков. Затем с учетом этих отзывов выбирался окончательный вариант решения [6].

Действительно, работой можно управлять по-разному, и многие исследования показывают, что четкое, рациональное принятие решений в проектах категории Open Source производится параллельно с развернутой поддержкой процесса-инструментария для совершенствования совместной разработки и отладки. По мнению Тима О?Рейли, сообщество должно создавать процедуры обсуждения и утверждения новых возможностей, позволяющие решить, кто получает доступ к источникам, и взаимодействовать таким образом, чтобы не мешать свободной разработке [3].

Процесс тестирования

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

Обнаружение и исправление ошибок. Естественно, что в открытом программном обеспечении тоже есть ошибки. После изучения 200 проектов Луюнь Джао и Себастьян Эльбаум пришли к выводу, что здесь, вместо того чтобы добиваться высокого качества промежуточных версий, действуют по принципу «выпускай быстро, выпускай часто», в результате чего код непрерывно совершенствуется большим числом разработчиков, предлагающих итерации, усовершенствования и исправления [18].

Лозунг Реймонда «при достаточном количестве глаз все ошибки оказываются мелкими» предполагает участие множества программистов, без которых, как утверждают Москус и его коллеги, основная группа разработчиков будет буквально завалена работой по тестированию и исправлению ошибок, и код может никогда не достигнуть приемлемого уровня качества [6]. Это подтверждает важность устойчивой модели сообщества для создания качественного программного обеспечения.

Тестирование системы. Исследование [18] показало, что:

менее 20% разработчиков открытого программного обеспечения составляют планы тестирования;
лишь 40% проектов используют инструментарий тестирования, хотя этот показатель растет, когда поддержка такого инструментария широко доступна для языка программирования (например, Java);
менее 50% проектов используют инструменты «покрытия кода».

При разработке открытого программного обеспечения, безусловно, не следуют структурированным методам тестирования, но это не мешает созданию качественных программ. Как и в случае с управлением проектом, тестирование ведется, но по-другому.

Согласно данным одного исследования, нередко к тестированию системы привлекаются пользователи, которые делают это даже исключительно тщательно, как это было в случае с Apache [6]. Таким образом, существование большого круга специалистов, присылающих информацию о найденных ошибках, приобретает решающее значение и гарантирует, что программное обеспечение тестируется на многих платформах. Другие утверждают, что открытое программное обеспечение в целом имеет более низкую плотность ошибок, чем традиционное, поскольку последнее невозможно протестировать так же тщательно и масштабно [7].

Тем не менее не во всех проектах полагаются на тестирование пользователями. Исследование проекта Mozilla показало, что в нем имел место необычайно жесткий процесс проверки качества, и были организованы специальные тестовые группы [19]. В проекте определяющее значение имели автоматические регрессионные тесты, и каждую ночь запускались пакеты регрессионных тестов версий для Mac OS, Windows и Linux с тем, чтобы гарантировать надежность текущего варианта системы.

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

Пока не было проведено формальных исследований, позволяющих сравнить затраты на обеспечение качества и тестирование в финансируемых свободно распространяемых проектах и проектах, выполняемых волонтерами, а также в свободно распространяемых и коммерческих продуктах. Поэтому не ясно, какой подход гарантирует более высокое качество. Однако Бартон Миллер и его коллеги предполагают, что продукты, разрабатываемые и тестируемые исключительно волонтерами, могут иметь более высокое качество, чем коммерческие продукты, но чтобы выявить здесь четкую связь, необходимо провести дополнительные исследования [20].

Идут споры и о том, насколько быстро тестирование открытого программного обеспечения позволяет обнаружить ошибки. Применение лучших практических решений программной инженерии в течение десятков лет показало, что чем раньше найдены ошибки, тем дешевле их исправить. Макконнелл отмечает, что при разработке открытого программного обеспечения ошибки исправляются на уровне кода, а не на уровне архитектуры, что противоречит наилучшим практическим решениям [13]. Он утверждает, что неполная работа на предыдущих этапах (например, на этапе проектирования системы) может погубить проект масштаба Windows NT (самый крупный из свободно распространяемых проектов, Linux, значительно меньше). Однако другие считают, что ошибки на уроне кода выявляются достаточно рано, поскольку взаимный анализ кода и системное тестирование выполняются, начиная с прототипа в рамках необычно быстрого, итеративного процесса, который позволяет избежать кардинальных ошибок, проявляющихся в зрелых, уже выпускаемых продуктах [12].

Ограничения исследования

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

сравнение качества программного обеспечения в аналогичных продуктах, разработанных в рамках проектов категории Open Source и созданных на коммерческой основе (например, CRM);
качество проектов категории Open Source, выполненных различными по масштабу устойчивыми сообществами;
качество программного обеспечения в финансируемых и реализуемых профессионалами проектах категории Open Source по сравнению с теми, которые опираются на волонтеров;
эффективность поиска ошибок и идеальное сочетание для этой цели трех основных видов тестирования в проектах категории Open Source: структурное тестирование, выполняемое командой проекта, автоматическое регрессионное тестирование и тестирование силами пользователей;
влияние на модель устойчивого сообщества коммерческой организации, объединяющей усилия разработчиков;
важность процедур, связанных с соблюдением установленных сроков (таких, как оценка рисков, цели и этапы, раннее обнаружение ошибок, параметры и планирование) для программных проектов, в которых вопрос о своевременном выпуске версий остро не стоит;
распространение исследования приложений на Си на другие языки программирования.

Представленный обзор позволил сделать следующие важные выводы.

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

Последующее объективное исследование с тем, чтобы углубить наше представление о качестве открытого программного обеспечения, не только поможет нам понять данный феномен, но и будет полезно практикам — как членам сообщества Open Source, так и создателям коммерческих программных продуктов, и откроет новые возможности использования модели Open Source в бизнесе.

Литература

L. Angelis et al., Code Quality Analysis in Open Source Software Development. Information Systems J., vol. 12, no. 1, 2002.
E. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary. O?Reilly, 2001.
T. O?Reilly, Lessons from Open-Source Software Development. Comm. ACM, vol. 42, no. 4, 1999.
K. Nakakoji et al., Evolution Patterns of Open-Source Software Systems and Communities. Proc. Int?l Workshop Principles of Software Evolution, ACM Press, 2002.
H. Annabi et al., Effective Work Practices for Software Engineering: Free/Libre Open Source Software Development. Proc. 2004 ACM Workshop on Interdisciplinary Software Eng. Research, ACM Press, 2004.
A. Mockus, R. Fielding, J. Herbsleb, A Case Study of Open Source Software Development: The Apache Server. Proc. 22nd Int?l Conf. Software Eng., IEEE CS Press, 2000.
A. Mockus, R. Fielding, J. Herbsleb, Two Case Studies of Open Source Software Development: Apache and Mozilla. ACM Trans. Software Eng. and Methodology, vol. 11, no. 3, 2002.
K. Kishida, Y. Ye, Toward an Understanding of the Motivation of Open Source Software Developers. Proc. 25th Int?l Conf. Software Eng., IEEE CS Press, 2003.
M. Bergquist, J. Ljungberg, The Power of Gifts: Organizing Social Relationships in Open Source Communities. Information Systems J., vol. 11, no. 4, 2001.
G. Lee, R. Cole, The Linux Kernel Development as a Model of Open Source Knowledge Creation. Haas School of Business, Berkeley, 2000.
J.Y. Moon et al., Essence of Distributed Work: The Case of the Linux Kernel. First Monday, vol. 5, no. 11.
T. Bollinger et al., Open Source Methods: Peering through the Clutter. IEEE Software, vol. 16, no. 4, 1999.
S. McConnell, Open Source Methodology-Ready for Prime Time? IEEE Software, vol. 16, no. 4, 1999.
C. Gacek, T. Lawrie, Issues of Dependability in Open Source Software Development. ACM SIGSOFT Software Eng. Notes, vol. 27, no. 3, 2002.
J. Dinkelacker et al., Progressive Open Source. Proc. 24th Int?l Conf. Software Eng., ACM Press, 2002.
A. Fuggetta, Controversy Corner: Open Source Software — An Evaluation. J. Systems and Software, vol. 66, no. 1, 2003.
Y. Yamauchi et al., Collaboration with Lean Media: How Open Source Software Succeeds. Proc. 2000 ACM Conf. Computer Supported Cooperative Work, ACM Press, 2000.
L. Zhao, S. Elbaum, A Survey on Quality Related Activities in Open Source. Software Eng. Notes, vol. 25, no. 3, 2000.
C. Reis, R. de Mattos Fortes, An Overview of the Software Engineering Process and Tools in the Mozilla Project. Proc. Open Source Software Development Workshop, C. Gacek, B. Arief, eds., Dependability Interdisciplinary Research Collaboration, 2002.
B. Miller et al., Fuzz Revisited: A Re-Examination of the Reliability of UNIX Utilities and Services, tech. report, Computer Sciences Dept., Univ. of Wisconsin, 2000.

Марк Эбердур (mark@opensourcetesting.org) — основатель ресурса opensourcetesting.org, посвященного инструментарию тестирования открытого программного обеспечения. Также курирует техническую сторону деятельности компании Epic (Англия), занимающейся средствами дистанционного обучения и системами управления знаниями.

Оценка качества открытого программного обеспечения

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

Модель Open Source Maturity Model (OSMM) в варианте компании CapGemini анализирует соответствие программного обеспечения набору показателей, в том числе касающихся разработки продукта, сообщества пользователей и разработчиков, стабильности продукта, поддержки и обучения. Эта коммерческая модель предполагает обращение к экспертам из CapGemini.

Open Source Maturity Model в варианте компании Navica— это формальный процесс, опубликованный на условиях открытой лицензии, который оценивает качество ключевых элементов, в том числе программного обеспечения, поддержки, документации, обучения, интеграции продуктов и профессиональных сервисов. Каждому из элементов присваивается весовой коэффициент и вычисляется общая оценка OSMM.

Business Readiness Rating — модель оценки, разрабатываемая группой академических институтов, которые намерены расширить существовавшие ранее модели OSMM, чтобы создать открытый стандарт на моделирование и оценку открытого программного обеспечения научной направленности.

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