Май 2008

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

ISO 9126

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

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

В этом документе описывается метод QSOS (квалификация и выбор программного обеспечения Open Source), задуманный технологией услуг компании Atos происхождения SA, чтобы квалифицировать, выбрать и ПСОК объективной, прослеживаемого и спорили. Метод может быть интегрирован в рамках более общего процесса технологические часы, которые здесь не представлены. Он описывает процесс настройки удостоверений личности и оценочные листы для OSS.

Почему методология?

При оценке программного обеспечения, естественно возникают следующие вопросы:

  • какое программное обеспечение лучший встречает фактические или планируемые технические требования?
  • какое программное обеспечение наиболее соответствует фактическим или планируемых функциональных требований?

Кроме того каждая компания должна ответить на эти вопросы до принятия любого решения:

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

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

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

Почему бесплатно методология?

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

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

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

Общий процесс

Общий процесс QSOS состоит из четырех взаимозависимых этапов:

  1. Определение: создание систем отсчета используется в следующих шагах.
  2. Оценка: проведена по трем осям критериям: i) функциональное покрытие; II) риски для пользователя; и iii) риски для поставщика услуг, независимо от любого конкретного контекста пользователя или клиента.
  3. Квалификация: взвешивание критериев разделения по трем осям и моделирования контекста, требования пользователей и/или стратегии, установленных поставщиком услуг.
  4. Выбор: обработать данные, представленные в шагах 1 и 2 через фильтр, заданный на шаге 3 для того, чтобы перейти к запросы, сравнения и выбора продуктов.

Рисунок 1 обеспечивает визуализацию процесса QSOS четыре шага. Каждый из этих шагов подробно далее в этом документе.

Рисунок 1: Четыре шага QSOS

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

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

Шаг 1: Определение

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

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

Типы лицензий: этот круг ведения списков и классифицирует основных лицензий, используемых для OSS. Критерии, выбранных для описания такой лицензии являются: i) право собственности (производный код становятся собственностью или должен оставаться свободным?); II) virality (это еще один модуль, связанный к исходному коду, пострадавшим от лицензии?); и iii) наследование (производный код, наследуют от лицензии или это можно применить дополнительные ограничения?). Обратите внимание, что часть программного обеспечения или кода могут быть опубликованы в рамках нескольких лицензий, включая закрытые лицензии.

Типы сообществ: классификация общинных организаций, существующих вокруг ПСОК и отвечает за его жизненного цикла. Типы сообществ, выявленных на сегодняшний день являются: i) изолированный разработчик, где программное обеспечение разрабатывается и управляется одним человеком; II) Группа разработчиков, где несколько человек сотрудничают в неофициальном или не промышленно развитых стран способом; III) Организация разработчиков, где группа разработчиков управлять жизненным циклом программного обеспечения в _formalized _way, _generally _based на основе назначения ролей и меритократии; IV) юридическое лицо, которое управляет сообщество, в целом обладает авторскими правами и управляет спонсорство и связанные субсидии; и v) коммерческой организацией, используя главных разработчиков проекта, которые получают вознаграждение от продажи услуг или коммерческих версий программного обеспечения.

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

Шаг 2: Оценка

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

  • построить личность (ID) программного обеспечения
  • создать лист оценки программного обеспечения, забивший критерии разделены по трем основным направлениям: i) функциональное покрытие; II) риски с точки зрения пользователя; и iii) риски с точки зрения поставщика услуг

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

Общая информация: Это включает: i) название программного обеспечения; II) ссылка, Дата создания и Дата релиза удостоверения личности; III) автор; IV) тип программного обеспечения; v) краткое описание программного обеспечения; VI) лицензии, которым подвергается программное обеспечение; VII) проекта веб-страницы и демонстрационного сайта; VIII) совместимые операционные системы; и ix) вилка в происхождение, если программное обеспечение является вилкой.

Существующие услуги: этот компонент включает: i) документации; II) число контрактных поддержки предложений; III) число учебных предложений; и iv) число предложений консультантов.

Функциональные и технические аспекты: включают в себя: i) технологии осуществления; II) технические предпосылки; III) подробные функции; и iv) "дорожная карта".

Синтез: включает в себя общую тенденцию и любые комментарии.

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

Критерии забил от 0 до 2. Эти оценки будут использоваться в шаге 4 для сравнения и выберите программное обеспечение в соответствии weightings, представляющий пользователя требованиям, указанным в шаге 3. Ниже описываются критерии, используемые для каждой оси оценки. Обратите внимание, что такие же или аналогичные критерии могут появиться на другой оси.

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

Функциональность Оценка
Не покрытые 0
Частично покрытые 1
Полностью покрыт 2

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

«Риски с точки зрения пользователя» ось оценки включает критерии для оценки рисков, понесенные пользователем при принятии OSS. Озвучивание критериев производится независимо от контекста любого конкретного пользователя как контекст рассматривается в шаге 3. Критерии разделены на пять категорий:

  • Внутренняя прочность
  • промышленно развитые решения
  • Интеграция
  • Техническая адаптивности
  • стратегия

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

«Риски с точки зрения поставщика услуг» оси оценки объединяет критерии для оценки рисков, понесенные подрядчиком, предлагая услуги вокруг ПСОК как опыт, интеграция, развитие и поддержка. Это прежде всего на этой основе можно определить уровень приверженности.

Это можно повторять процесс QSOS. На этапе оценки это приносит способность забить критерии в трех проходов с различными уровнями детализации:

  • первые пять основных категорий
  • затем подкатегории каждой категории
  • Наконец каждый оставшийся критерий

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

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

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

Шаг 3: Квалификация

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

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

Каждая функциональности приписано выбранного среди следующих требований уровня: i) требуется функциональность; II) дополнительные функциональные возможности; и iii) не требуется функциональность. Эти требования уровни будут связаны с весовые значения на шаге 4, в соответствии с выбранным режимом выбора.

Значимость каждого критерия «пользователя риски» ось располагается согласно контексту пользователя как один из трех критериев: i) неуместные и поэтому исключены из фильтра; II) соответствующие; и iii) критическое. Это значение будет преобразованы в численное взвешенное значение на следующем шаге, в соответствии с выбранным режимом выбора.

«Фильтр по рискам поставщика услуг» используется поставщиком услуг для оценки программного обеспечения и услуг интегрировать в свое предложение и определить связанные уровни обязательств. O3S инструмент позволяет определение этих различных фильтров.

Шаг 4: Выбор

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

Строгий выбор: на основе прямой ликвидации как только программное обеспечение не выполняет требования, сформулированные на шаге 3. Причины для немедленной ликвидации включают: i) несовместимость с фильтром на удостоверение личности; II) не предоставляет функциональные возможности, требуемые фильтром по функциональной сетке; и iii) оценки на «пользователя риски» оси не соответствуют релевантности определяется пользователем, как оценка соответствующего критерия должно быть по меньшей мере равна 1 и оценка критический критерий должен быть по меньшей мере равна 2. Этот метод очень избирательны причем не в зависимости от требований пользователя, избирается не имеют права программного обеспечения. Выбранное программное обеспечение приписано общий балл, рассчитывается путем взвешивания.

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

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

Уровень требований Вес
Необходимые функциональные возможности + 3
Дополнительные функциональные возможности + 1
Не требуется функциональность 0

Взвешенное значение на «риск пользователя» ось основывается на актуальности каждого критерия следующим образом:

Актуальность Вес
Не имеет значения критерий 0
Соответствующий критерий + 1 или -1
Критический критерий + 3 или -3

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

Программное обеспечение одной семьи с общей функциональной сетки можно сравнить с помощью взвешенной оценки, определены ранее. На рисунке 2 приводится пример, показывающий, что Утяжелители на разных осях не являются репрезентативными всех видов использования систем (ВЫСОКОМАСШТАБИРУЕМЫЙ) управления реляционными базами данных.

Рисунок 2: Сравнение ВЫСОКОМАСШТАБИРУЕМЫЙ по осям QSOS

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

Заключение

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

Эта статья основана на QSOS версии 1.6, что авторское право Atos происхождения на условиях Gnu FDL и включенные в этот выпуск с разрешения владельца авторских прав. Исходный документ и его источник латекса QSOS на вебсайте.

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
Нет голосов были поданы еще. Скажи свое слово!

Добавить новый комментарий

Обычный текст

  • Теги HTML не разрешены.
  • Адреса электронной почты и адреса страниц включите в ссылки автоматически.
  • Строки и параграфы переносятся автоматически.