Организация управления требованиями
Оглавление
Введение
1. Сравнительный
анализ методик управления требованиями
1.1 Процессы
управления требованиями в REBOK
.2 Процессы
управления требованиями в PMBOK
.3 Процессы
управления требованиями в RUP
.4 Процессы
управления требованиями в ITIL
.5 Процессы
управления требованиями в BABOK
.6 Процессы
управления требованиями в SWEBOK
.7
Особенности разработки заказного программного обеспечения
.8 Критерии
сравнения методик
.9 Выбор
методики для проектов заказной разработки программного обеспечения
2. Разработка
показателей эффективности процессов управления требованиями
2.1 Описание
профиля компании
.2 Описание
типового проекта разработки заказного программного обеспечения
.3 Процессы
управления требованиями в проектах компании
.4
Теоретические основы по разработке показателей эффективности
.5 Состав
показателей эффективности процессов управления требованиями
3. Оценка
текущих процессов в компании и разработка рекомендаций
3.1 Оценка
процессов управления требованиями в реализованных проектах компании
.2 Рекомендации
по повышению качества процессов управления требованиями в компании
Заключение
Список литературы
ПРИЛОЖЕНИЯ
Введение
Одним из важных аспектов при реализации проектов внедрения информационных
систем является управление требованиями Заказчика.
Наличие понятного и хорошо спланированного подхода к управлению
требованиями гарантирует минимизацию рисков совершения ошибок во время
исполнения проекта, способствует расстановке приоритетов и формированию четко
определенного плана осуществления проекта. Недостаточно серьезное отношение к
вопросу управления требованиями, в свою очередь, создает риски возникновения
барьеров на пути исполнения проектов и грозит превышением объема
финансирования, срывов обозначенных сроков и даже отменой проекта без получения
итогового, удовлетворяющего первоначальным требованиями результата.
Правильно сформированный набор требований - это своего рода «залог»
достижения поставленных перед проектом целей. Для основной доли систем объем
требований может быть достаточно значительным, более того, следует отметить,
что в ходе реализации проекта требования чаще всего подвергаются изменениям
[1].
К наиболее явным причинам сложности задачи управления требованиями [2, 4,
5, 6] можно отнести:
· значительное количество потенциальных заинтересованных сторон в проекте,
требования которых следует выявлять и фиксировать;
· широкий диапазон типов требований, при этом, каждое из них
требует особого описания, наличия собственных атрибутов, своей степени
проработки;
· потребность формирования и поддержания сложной иерархической
структуры требований;
· необходимость в трассировке требований, установлении связей
между ними;
· требования подвергаются изменениям в ходе реализации проекта,
что часто происходит в связи с изменением внешнего окружения, требованиями
бизнеса.
Типичными причинами срыва сроков и бюджета проектов, как правило,
являются [5, 7, 8]:
· плохо сформулированные требования;
· не все требования были выявлены;
· сложности в отслеживании изменений требований.
Широко распространены ситуации, в которых устранение ошибок требований
представляет собой достаточно амбициозную задачу, требующих немалых временных и
финансовых усилий. Устранение ошибки в требованиях на стадии сопровождения
готового программного продукта обходится, как правило, в среднем в 200 раз
дороже, нежели на этапе формирования спецификации требований. Это значение
можно сравнить со стоимостью ошибки в требованиях, выявляемой на поздних фазах
проекта - такая ошибка, как правило, приводит к 30-40% превышению бюджета
проекта [9].
С учетом сказанного трудно не согласиться с утверждением о том, что
актуальность задачи управления требованиями является очевидной и важной задачей
в реалиях сегодняшнего дня, задачей, которая должна быть на виду у любой
организации, осуществляющей разработку программного обеспечения (ПО).
С подобными проблемами сталкивается и рассмотренная в данной работе
ИТ-компания, занимающаяся разработкой заказного программного обеспечения. Не
основательно проработанные процессы управления требованиями являются основной
проблемой компании. Превышение бюджета проекта, срыв сроков, общая
неудовлетворенность Заказчика результатами проведенной работы - всё это можно
отнести к очевидным следствиям некачественной, проще говоря, неэффективной
организации процессов управления требованиями.
Вопросы формирования, документирования, анализа, управления требованиями
были изучены и проанализированы в работах отечественных и зарубежных авторов.
Среди них следует отметить труды таких авторов, как: Вигерс К., Коберн А., Халл
Э., Леффингуэлл Д., Мацяшек Л., Орлик С., Уидриг Д., Меняев М.Ф., Булуй Ю.,
Липаев В.В. Так, книга Вигерс К. «Подходы к управлению требованиями» посвящена
разработке качественных требований к программному продукту. В ней представлен
ряд методов формирования, проверки, анализа, тестирования требований к
программному обеспечению. В работе Халл Э. «Подходы к управлению требованиями»
рассмотрен процесс разработки и управления требованиями.
На текущий момент существует значительное количество нормативных
документов, регламентирующих работу с требованиями к программному продукту.
Среди них стоит отметить разработки IEEE: IEEE 1233 «Guide for Developing System Requirements
Specifications», IEEE Guide to the Software Engineering Body of Knowledge -
SWEBOK, «IEEE Recommended Practice for Software Requirements Specifications». Кроме этого нельзя не упомянуть
отечественные стандарты, включая: ГОСТ 34.601-90. Информационная технология.
Автоматизированные системы. Стадии создания, ГОСТ 19.201-78. Единая система
программной документации. Техническое задание. Требования к содержанию и
оформлению, ГОСТ 34.602-89. Информационная технология. Техническое задание на
создание автоматизированной системы. Вопросы работы с требованиями затронуты в следующих методологиях: Requirements Engineering
Body Of Knowledge (REBOK), Rational Unified Process (RUP), Microsoft Solutions
Framework (MSF), Project Management Body of Knowledge (PMBoK), Agile software
development [10].
Тем не менее, управление требованиями продолжает оставаться заметной
причиной неудач внушительного количества проектов внедрения информационных
систем. Согласно информации исследования Института по Управлению Проектами (PMI) в 47% причиной провала проектов
является плохое управление требованиями.
В качестве объекта исследования настоящей работы выступает ИТ-компания,
которая занимается созданием программного обеспечения на заказ. Если говорить о
предмете исследования, то в данном случае его роль играет оценка и повышение
качества процессов управления требованиями в проектах создания программного
обеспечения на заказ.
Цель представленной работы - оценка эффективности процессов управления
требованиями для проектов разработки заказного программного обеспечения и
разработка рекомендаций по их улучшению.
Набор задач, который был сформирован для достижения обозначенной цели,
включает в себя:
· Определение критериев для сравнения методик управления требованиями;
· Сравнительный анализ методик управления требованиями по
выбранным критериям и выбор наиболее подходящей методики для проектов заказной
разработки программного обеспечения;
· Описание структуры проектов заказной разработки программного
обеспечения и выделение процессов управления требованиями в компании;
· Разработка показателей эффективности для выделенных процессов
управления требованиями;
· Оценка проектов компании по разработанным показателям;
· Формирование рекомендаций по повышению качества процессов
управления требований в компании.
Гипотезой исследования настоящей магистерской диссертации является
предположение о том, что существует такие процессы управления требованиями для
проектов создания программного обеспечения на заказ, которые представляются
наиболее подходящими такого вида проектам.
Основу теоретической базы исследования формируют концепции работы с
требованиями, проанализированные в работах российских и зарубежных авторов, а
также принципы процесса управления требованиями, рассмотренные в широко
известных стандартах, методологиях, нормативных документах.
В исследовании использованы такие общенаучные методы, как: анализ, метод
анализа иерархий, методы дедукции и индукции, сравнение.
Научная новизна работы заключается в рекомендациях для организации
процессов управления требованиями Заказчика в проектах заказной разработки
программного обеспечения, которые будут способствовать обеспечению успешной
реализации проектов и удовлетворенности Заказчика итоговым продуктом.
Практический результат представленной работы заключается в рекомендациях
по повышению эффективности процессов управления требованиями в проектах
разработки программного обеспечения на заказ. Сформированный набор критериев,
обеспечивающий выбор методики управления требованиями вполне возможно применять
в процессе сравнения других альтернатив. Разработанный набор показателей
эффективности процессов управления требованиями может использоваться в других
компаниях такого профиля с аналогичным набором процессов.
Работа включает в себя три главы. Первая глава дает описание процессов
управления требованиями в шести различных методиках, осуществляется выбор
критериев для сравнения методик и выбор наиболее подходящей методики для
проектов заказной разработки программного обеспечения.
Вторая глава представляет описание профиля компании, которая занимается
созданием программного обеспечения на заказ. В данной главе содержится описание
структуры проектов компании, существующие процессы, наличие связей с
управлением требованиями. Разработан набор показателей, характеризующий
эффективность процессов.
В третьей главе приводится оценка проектов компании по разработанным во
второй главе показателям эффективности. Также, данная глава содержит выводы по
результатам оценки и рекомендации по повышению качества управления требованиями
в компании.
Итоговым результатом работы является оценка процессов управления
требованиями в ИТ-компании, занимающейся разработкой заказного программного
обеспечения и разработка рекомендаций по повышению качества этих процессов.
Ключевые слова
Требования к программному продукту, управление требованиями, управление
изменениями, управление проектом, методика, методология, свод знаний, лучшие
практики, REBOK, PMBOK, RUP, ITIL, BABOK, SWEBOK,
заказное программное обеспечение, метод анализа иерархий, показатель
эффективности, принцип SMART
1. Сравнительный анализ методик управления требованиями
1.1 Процессы управления требованиями в REBOK
Работа с требованиями в своде знаний REBOK (Requirements Engineering Body Of Knowledge) представлена в двух процессах:
Формирование требований (Requirements Development) и
Управление требованиями (Requirement Management).
В процессе Формирования требований можно выделить следующие этапы:
· Выявление требований (Requirements Elicitation).
Основные цели: определение всех потребных характеристик, функций будущего
программного продукта, детализация требований и подробное описание функций
системы.
· Анализ требований (Requirements Analysis). Основные моменты данного этапа: определение и разрешение конфликтов в
требованиях, обозначение границ проекта, преобразование пожеланий Заказчика в
программные и системные требования.
· Спецификация требований (Requirements Specification). Спецификации содержат такую
информацию: пользовательские требования, ограничения проекта, критерии приемки
результатов проекта.
· Моделирование (Solution and System Modeling). Базовыми являются такие модели:
концептуальная модель, модель решения, модель требований.
· Утверждение и проверка требований (Requirements Validation
and Verification). Данные
активности должны быть запланированы в начале проекта. Следует выполнять
проверку документации требований на соответствие стандартов, а также утверждать
разработанные модели на этапах анализа и спецификации [11].
Процесс формирования требований представлен на рисунке 1.
Рисунок 1 - Процесс формирования требований (Process for Requirements Development)
Процесс управления требованиями согласно REBOK состоит из следующих
этапов:
· Отслеживание требований (Tracking of Requirements). Данный этап помогает проверить все ли
важные цели процесса разработки выполнены;
· Управление изменениями (Change Management). Управление
изменениями включает в себя следующие процедуры:
o Идентификация потенциальных изменений;
o Регистрация запроса на изменения;
o Анализ запросов на изменения;
o Оценка изменений;
o Планирование выполнения изменений;
o Реализация изменений;
o Обзор и закрытие изменений.
· Обеспечение качества (Quality Assurance). Основные функции этого этапа:
o Организация системы управления качеством, проведение обучения
специалистов;
o Проведение аудита и последующих корректирующих действий;
o Оценка и анализ инжиниринга требований;
o Совершенствование процесса инжиниринга требований.
1.2 Процессы управления требованиями в PMBOK
В своде знаний по управлению проектами PMBOK подход к требованиям описан
в главе «Общее управление изменениями» [12]. Согласно PMBOK общее управление
изменениями включает в себя следующие операции:
· Идентификация изменений;
· Рассмотрение и утверждение изменений;
· Управление изменениями;
· Поддержка целостности базовых планов, а также поддержка их
конфигурации и плановой документации;
· Проверка и одобрение корректирующих и предупреждающих
действий;
· Контроль и обновление содержания, стоимости, бюджета,
расписания проекта и требований к качеству;
· Документирование выполненных изменений;
· Санкционирование исправлений дефектов;
· Контроль качества проекта по стандартам.
Общий вид процесса управления изменениями согласно PMBOK представлен на рисунке 2.
Рисунок 2 - Общее управление изменениями (входы, выходы, процессы)
1.3 Процессы
управления требованиями в RUP
Согласно RUP (Rational Unified Process), управление требованиями - это
систематический подход к выявлению, организации и документированию требований к
системе, а также установка и поддержание соглашения между клиентом и группой
разработки по поводу изменений требований к системе [13].
В состав действий по управлению требованиями включаются:
· Формирование плана управления требованиями. Данный план описывает общие
подходы к управлению требованиями в проекте: как собираются требования, как
отслеживаются изменения и т.д.;
· Сбор требований;
· Разработка документов концепции (Vision);
· Создание сценариев использования (Use Cases). Сценарии использования - это форма для описания
функциональных требований, представляет собой описание системы в терминах
последовательности действий. Сценарии использования:
o Инициируются действующим лицом;
o Представляют собой взаимодействие между пользователем и
системой;
o Определяют последовательность действий;
o Содержат в себе функциональные требования;
o Имеют некоторое значение для действующего лица;
o Представляют собой имеющий смысл сценарий событий.
Рисунок 3 - Модель процессов управления требованиями в RUP. Источник - Филипп Крачтен «Введение
в Rational
Unified Process»
· Дополнительная спецификация. Содержит описание нефункциональных
требований (удобство работы, надежность, производительность и др.), а также
некоторые функциональные требования.
· Создание тестовых сценариев (Test Cases) из сценариев использования (Use Case). Тестовые сценарии показывают тестеровщикам шаги
работы в системе для проверки требований.
· Создание тестовых сценариев (Test Cases) из дополнительной спецификации;
· Проектирование системы. Основой процесса являются требования.
Проектирование зачастую сопровождается применением Универсального Языка
Моделирования - Unified
Model Language (UML) [14, 15].
На рисунке 3 можно ознакомиться с моделью управления требованиями
согласно RUP.
1.4 Процессы
управления требованиями в ITIL
В
библиотеке ITIL (IT
<https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8>
Infrastructure Library) работа с требованиями представлена в рамках двух
процессов: Проектирование услуг (Service Design) и Преобразование услуг
(Service Transition) [16]. В первом процессе описана классификация
требований и инструменты для их выявления.
Управление
изменениями требований представлено в одноименном процессе Управление
изменениями (Change Management) и включает в себя
следующие шаги [10]:
· Формирование запроса на изменение;
· Рассмотрение запросов и предложений на изменения;
· Анализ и оценка влияния изменений на сервис и активы.
· Авторизация изменений:
o Получение разрешения/отказа на реализацию изменения;
o Оповещение заинтересованных сторон.
· Обновление планов;
· Управление выполнения изменений;
· Рассмотрение и закрытие изменений:
o Рассмотрение изменений и внесение правок в документацию;
o Закрытие документации.
С моделью процесса управления изменениями можно ознакомиться на рисунке
4.
Рисунок 4 - Модель управления изменениями в ITIL. Источник «ITIL Version 3.0. Service Transition»
1.5 Процессы
управления требованиями в BABOK
Свод лучших знаний BABOK (Business Analysis
Body Of Knowledge) раскрывает вопрос управления
требованиями в главе «Управление требованиями и коммуникации». Ниже представлен
перечень основных этапов работы с требованиями [17].
· Управление границами решения и их требованиями (Manage Solution
Scope&Requirements). Данная задача состоит из обеспечения утверждения
требований всех заинтересованных сторон, управления анализом требований. Задача
включает в себя:
o Управление рамками решений (Solution Scope Management);
o Управление конфликтами (Conflict and Issue
Management);
o Представление требований для обзора (Presenting Requirements
For Review);
o Утверждение (Approval).
· Управление прослеживаемостью требований (Manage Requirements Traceability).
Целью является создание и поддержка отношений между бизнес-целями, требованиями
и компонентами. Задача состоит из следующих шагов:
o Определение отношений (Relationships) между требованиями;
o Анализ влияния (Impact Analysis) изменения;
o Система управления конфигурацией (Configuration Management
System).
· Поддержка требований для повторного использования (Maintain Requirements
for Re-use) - управление знаниями о требованиях после их выполнения. Шаги
задачи:
o Текущие требования (Ongoing Requirements) - требования,
которые могут быть использованы на постоянной основе: договорные обязательства,
соглашения об уровне обслуживания, бизнес-правила, бизнес-процессы, стандарты
качества;
o Удовлетворенные требования (Satisfied Requirements).
· Подготовка пакета требований (Prepare Requirements Package). Цель данной
задачи − выбор и структурирование требований в набор так, чтобы
обеспечить эффективные коммуникации, понимание и применение требований всеми
заинтересованными сторонами проекта. Шаги задачи:
o Рабочие
проекты и результаты (Work Products and Deliverables);
o Формат (Format). В зависимости от типа требований может
меняться формат их представления.
· Коммуникация требований (Communicate Requirements). Цель - общее
понимание требований всеми заинтересованными участниками. Включает в себя
беседы, дискуссии, заметки, документы, презентации.
o Общие коммуникации (General Communication);
o Презентации (Presentations).
В целом процесс управления требований представлен на рисунке 5.
Рисунок 5 - Процесс управления требованиями по BABOK. Источник «A Guide to the Business Analysis Body Of Knowledge.
Version 2.0»
1.6 Процессы
управления требованиями в SWEBOK
SWEBOK (Guide to the Software Engineering Body of Knowledge) выделяет в работе с требованиями следующие этапы:
· Выявление требований (Requirements Elicitation);
· Анализ требований (Requirements Analysis) - включает в себя
выявление и разрешение конфликтов между требованиями, определение границ
программного продукта, разработку системных требований. Этап состоит из
следующих задач:
o Классификация требований (Requirements Classification);
o Концептуальное моделирование (Conceptual Modeling) -
выполняется для понимания сути проблемы;
o Архитектурное проектирование и распределение требований
(Architectural Design and Requirements Allocation);
o Согласование требований (Requirements Negotiation).
· Спецификация требований (Requirements Specification) - документы,
полученные в результате сбора и анализа требований, их моделирования и
архитектурного проектирования. Чаще всего используются следующие виды
спецификации:
o Определение системы (System Definition) - формируется документ, который описывает
системные требования, определяет высокоуровневые требования и стратегические
цели программного продукта;
o Системные требования (System Requirements) - документ-спецификация описывает действия
системных инженеров;
o Программные требования (Software Requirements) -определяются соглашения между Заказчиком и
исполнителем в отношении того, что должна делать система.
· Проверка требований (Requirements Validation) [18, 19].
Описанный процесс представлен на рисунке 6.
Рисунок 6 - Работа с требованиями по SWEBOK
В главе «Конфигурационное управление» (Software Configuration Management)
SWEBOK рассматриваются вопросы управления изменениями. Описание включает в
себя, какие именно изменения должны быть сделаны, какие полномочия необходимы
для утверждения изменений, в чем состоит поддержка реализации этих изменений. К
данному процессу относятся такие этапы, как [20]:
· Предложение, оценка и утверждение изменений (Requesting, Evaluating, and Approving Software Changes). Включает формальные процедуры по
предложению и регистрации запросов на изменения, оценки стоимости и влияния
предлагаемых изменений, а также утверждение или отказ от внесенных предложений
по изменениям.
· Реализация изменений (Implementing Software
Changes).
· Отклонения и отказ от изменений (Deviations and Waivers).
Отклонение - утверждение изменений с некоторой корректировкой условий и работ.
Описанный процесс представлен на рисунке 7.
Рисунок 7 - Процесс управления изменениями по SWEBOK
1.7 Особенности
разработки заказного программного обеспечения
Заказные разработки на текущий момент являются неотъемлемой составляющей
современного ИТ-рынка и применяются в самых разнообразных отраслях экономики.
Создание программного обеспечения на заказ учитывает характерные особенности
бизнес-процессов Заказчика. В большинстве случаев к услугам создания заказного
программного обеспечения обращаются в таких ситуациях:
· Для решения поставленной задачи не существует тиражируемого программного
обеспечения;
· Тиражируемое программное обеспечение существует, но оно не
удовлетворяет в полной мере всем требованиям Заказчика;
· Слишком дорогая лицензия на существующее тиражируемое
программное обеспечение [22, 23].
Чаще всего разработка на заказ и внедрение программного продукта
используется при решении таких задач [24, 25]:
· Автоматизация уникальных бизнес-процессов;
· Адаптация существующих систем к новым нестандартным
требованиям Заказчика;
· Интеграция существующих информационных систем;
· Усовершенствование существующих систем: расширение
функциональности, создание мобильного приложения или веб-интерфейса и т.д.;
· Интеграция с информационными системами предприятий-партнеров;
· Интеграция данных из территориально распределенных
подразделений компании.
Для удачного завершения проектов заказного программного обеспечения выделяют
факторы [22, 24, 25, 26]:
· Четкая ориентация на бизнес-цели Заказчика;
· Активное участие всех заинтересованных сторон;
· Постоянная коммуникация между заинтересованными сторонами;
· Детальная проработка требований на ранних этапах проекта;
· Готовность к изменениям требований на всех этапах проекта, в
том числе и на поздних;
· Многократная поставка результатов;
· Тестирование выполняется непрерывно;
· Во главу ставится соответствие готового решения
бизнес-требованиям;
· Гибкость к модификациям и масштабируемость системы под
требования растущего бизнеса.
Безусловно, заказное программное обеспечение подразумевает и некоторые
риски, имеющие отношения к таким распространенным практическим аспектам, как:
превышение сроков и бюджета разработки, большие затраты на сопровождение
системы, проблемы с удовлетворением ожиданий Заказчика, утрату актуальности
продукта или технологий еще в процессе разработки. Зачастую возникают проблемы
с интеграцией разработанного приложения в имеющуюся среду компании. Также, в ряде
случае небезосновательным является мнение о том, что в тиражируемом ПО, как
правило, меньше ошибок в сравнению с программным обеспечением разрабатываемым
на заказ.
1.8
Критерии сравнения методик
Различные методологии предлагают подходы к организации управления
требованиями, регламентируя способы сбора, документирования, анализа
требований, внесение изменений. Регламентация всех этих этапов должна
обеспечить высокое качество работ с требованиями и обеспечить успешное
завершение разработки, внедрения, сопровождения информационных систем. Выбор
методики управления требованиями должен основываться на специфике работы
компании, особенностях выполняемых ею работ и оказываемых услуг.
При реализации заказного программного обеспечения важную роль играют
детально проработанные на ранних этапах требования, в связи с чем следует
выбирать методику, в которой изложен пошаговый процесс идентификации,
детализации, оценки требований, инструменты сбора требований, указаны роли и их
функции в данном процессе. Значительное место занимает раннее предоставление
результатов, поэтому приветствуются методики, которые используют методы
прототипирования. Заказная разработка программного обеспечения подразумевает
изменение требований Заказчика вплоть до поздних этапов проекта, поэтому важно
наличие в методике детального определения этапов выявления, анализа,
утверждения или отклонения изменений. Следует обратить внимание на методики,
определяющие этап проверки, тестирования требований, формирования критериев
оценки выполнения требования [22, 25, 26].
Исходя из представленных особенностей заказной разработки ПО совместно с
группой экспертов были выделены следующие критерии для сравнения перечисленных
выше методик:
· Инструменты и техники выявления требований;
· Описание потребных характеристик требований;
· Выделение и спецификация ролей;
· Инструменты демонстрации результатов на ранних этапов;
· Формализация этапа анализа требований;
· Наличие алгоритма внесения изменений в требования;
· Наличие методики проверки/тестирования требований.
· Ориентация на заказную разработку;
· Степень полезности (определяет, насколько методика полезна в
понимании и создании эффективной модели управления требованиями);
· Соответствие этапов методики этапам проекта;
· Нейтральность по отношению к масштабам проекта;
· Степень формализма (наличие документов, представленных в
методике. Данный критерий выделен, т.к. формализм в данном случае оказывает
влияние на скорость и трудоемкость выполнения разработки).
1.9 Выбор
методики для проектов заказной разработки программного обеспечения
На основе сформированных критериев выполним сравнение методик с помощью
метода анализа иерархий (метод Саати). Критерии сравнения и альтернативы выбора
представляются в виде иерархии, которая представлена в Приложении 1.
Для определения весов критериев и оценки методик по каждому критерию
применяется метод попарного сравнения [27]. Для регистрации результата
сравнения пары использовалась шкала, представленная в таблице 1.
Таблица 1
Шкала сравнения пары альтернатив
|
Значение
|
Качественная характеристика
|
|
1
|
Равноценные элементы
|
|
2
|
Несущественный приоритет
|
|
3
|
Слабый приоритет
|
|
4
|
Умеренный приоритет
|
|
5
|
Значительный приоритет
|
|
6
|
Существенный приоритет
|
|
7
|
Сильный приоритет
|
|
8
|
Очень сильный приоритет
|
|
9
|
Безусловный приоритет
|
Результаты парных сравнений заносятся в матрицу. Для каждой матрицы
определяется вектор приоритетов. Для определения весов использовался следующий
способ: из произведения n
элементов каждой строки извлекаем корень n-й степени и нормализуем полученные значения [28, 29].
Исходя из сформированной иерархии выполняется попарное сравнение всех
методик по каждому из критерию, определяется вес критериев и выполняется
линейная свертка.
Также проводим расчет показателей согласованности. Отклонение от
согласованности называют индексом согласованности (ИС), которое рассчитывается
по следующей формуле:
Главное
значение матрицы - 
определяем следующим образом: суммируем произведения
векторов приоритетов на суммы элементов каждого столбца. Далее определяем
отношение согласованности как
Модельное
значение СИ для таких матриц соответственно равно 1,24 и 1,48.
Значение
ОС≤0,10 считается приемлемым порогом допустимой согласованности суждений.
В
сравнении методик принимало участие 5 экспертов - специалистов ИТ-компании,
занимающейся разработкой заказного программного обеспечения. В состав
экспертной группы вошли специалисты со стажем 3 и более лет в данной компании и
общим 5-летним стажем в ИТ-области. В качестве экспертов выступили:
руководитель отдела аналитики, 2 аналитика, ведущий разработчик, руководитель
проектов.
В
Приложении 2, 3, 4, 5, 6 представлены матрицы сравнения альтернатив по
критериям и свертка результатов для экспертов 1, 2, 3, 4, 5 соответственно.
Отношение согласованности матриц имеет допустимые значения. Ниже в таблице
представлены итоговые веса альтернатив, сделанные каждым экспертом и
окончательный выбор методики.
Таблица 2
Итоговые веса альтернатив экспертами и выбор методики
|
Э1
|
Э2
|
Э3
|
Э4
|
Э5
|
Итоговый вес
|
|
B1
|
0,12
|
0,16
|
0,17
|
0,16
|
0,20
|
0,16
|
|
B2
|
0,09
|
0,08
|
0,08
|
0,07
|
0,09
|
0,08
|
|
B3
|
0,25
|
0,22
|
0,22
|
0,23
|
0,21
|
0,23
|
|
B4
|
0,18
|
0,18
|
0,22
|
0,22
|
0,23
|
0,21
|
|
B5
|
0,22
|
0,13
|
0,09
|
0,14
|
0,15
|
0,15
|
|
B6
|
0,14
|
0,23
|
0,21
|
0,19
|
0,12
|
0,18
|
По результатам расчетов наиболее подходящей методикой управления
требованиями для проектов заказной разработки программного обеспечения является
методология Rational Unified Process.
2.
Разработка
показателей эффективности процессов управления требованиями
1.10 Описание
профиля компании
ИТ-компания занимается разработкой порталов, сайтов, информационных
систем, работает над научными и образовательными проектами. Компания работает с
2003 года. Сначала это был небольшой творческий коллектив «айтишников», сейчас
компания насчитывает около 200 сотрудников.
В 2008г. компания выпустила первую версию CRM, которая изначально
разрабатывалась для собственных нужд. В 2010г. компания была зарегистрирована.
К этому времени коллектив «наработал» репутацию, стали поступать крупные
заказы. В 2011г. компания выпустила свой CRM-продукт на рынок. Развитие
продукта продолжается. Часть заказной разработки ведется на платформе данного
решения.
Основные направления работы компании:
· Автоматизация малого и среднего бизнеса. В основном
разработки ведутся на платформе собственного разработанного комплекса, который
позволяет управлять организацией, ресурсами, проектами;
· Работа над крупными ИТ-проектами для
социальной и образовательной областей;
· Разработка порталов и сайтов;
· Разработка информационных систем для
крупных компаний и госструктур;
· Консалтинг в области оптимизации
бизнес-процессов, управлении проектами, управлении отношениями с клиентами и
маркетинг, управлении персоналом, внедрение информационных систем для
управления организацией;
· Организация и информационное
сопровождение мероприятий;
· Проведение бизнес-мероприятий,
обучение предпринимателей, информационная поддержка деловых событий;
· Дизайн, 3D-графика и полиграфия.
Компания имеет следующие лицензии:
· Лицензии Минкомсвязи России:
o 87107 (Услуги связи по передаче
данных, за исключением услуг связи по передаче данных для целей передачи
голосовой информации);
o 87108 (Телематические услуги связи);
o 87110 (Услуги связи по передаче
данных для целей передачи голосовой информации).
· Лицензии ФСБ и ФСТЭК России:
o Лицензия от 01.11.2012г. Центра по
лицензированию, сертификации и защите государственной тайны ФСБ России на
осуществление разработки, производства, распространения шифровальных
(криптографических) средств, информационных систем и телекоммуникационных
систем.
o Лицензия Федеральной службы по
техническому и экспортному контролю от 28.11.2012г. на деятельность по
технической защите конфиденциальной информации.
o Лицензия Федеральной службы по
техническому и экспортному контролю от 28.11.2012г. на деятельность по
разработке и производству средств защиты конфиденциальной информации.
Компания имеет следующие свидетельства и сертификаты:
· Сертификат соответствия международной системе менеджмента качества ISO
9001:2008 от 20.09.2011.
· Свидетельство о членстве в Московской торгово-промышленной
палате и Торгово-промышленной палате Российской Федерации.
· Сертификат члена Ассоциации менеджеров.
· Свидетельство Почетного члена Фонда поддержки
предпринимательских инициатив.
Клиентами компании являются как бизнес-организации, так и государственные
компании различного масштаба.
На рисунке 8 представлена организационная структура компании.
Рисунок 8 - Организационная структура компании
1.11 Описание
типового проекта разработки заказного программного обеспечения
Клиентами компании являются государственные и коммерческие организации
различного масштаба. Уровень формализации отношений с Заказчиком варьируется от
проекта к проекту. В целом, чем крупнее организация, тем выше степень
формальности. Также уровень формальности выше для государственных организаций.
Для государственных предприятий и крупных коммерческих также обычно имеются
ограничения на размещение заказа и приемку результатов. Для таких организаций
характерна некоторая ограниченность персонала в виду их занятости, что
сказывается на скорости принятия решений, получения информации, обратной связи
от сотрудников и т.п. Работа с небольшими коммерческими организациями имеет
мене формальный характер. Представители таких организаций как правило более
настроены на результат.
Несмотря на многообразие направлений, масштабов реализуемых проектов,
нюансы и особенности отдельно каждого проекта, можно выделить примерный
стандартный жизненный цикл проекта разработки заказного программного
обеспечения, который применяется в компании. Жизненный цикл такого типового
проекта описан ниже.
Работа над проектом начинается с подготовительного этапа. На данном этапе
выполняется разработка концепции будущего программного обеспечения,
предварительная оценка стоимости проекта, реализуемости проекта.
Подготавливается коммерческое предложение для Заказчика с приложением сметы на
проект и концептуальной модели будущего ПО. В случае, если решение о выборе
Исполнителя принимается на конкурсной основе, то на данном этапе выполняется
подготовка всей необходимой документации для участия в конкурсе. Результатом
данного этапа является подписанный договор на оказание услуг.
Следующим этапом является «Анализ требований». Здесь формируется перечень
всех требований Заказчика к программному обеспечению. Выполняются такие работы,
как сбор требований, анализ, решение конфликтных требований. В результате на
данном этапе формируется техническое задание на реализацию проекта.
После этого идет этап проектирования архитектуры. Целью этапа является
разработка логической и физической архитектуры.
По окончанию проектирования архитектуры, как правило, разрабатывается
дизайн и прототип будущей информационной системы. Далее прототип согласовывается
с Заказчиком, и как правило на этом этапе выполняется уточнение и корректировка
требований к программному обеспечению.
Далее идет этап разработки программного обеспечения. Большинство проектов
реализуются поэтапно с демонстрацией и согласованием версий продукта с
Заказчиком. При этом, ключевая функциональность реализуется в первую очередь. В
рамках подготовки отдельной версии продукта выполняются следующие работы:
кодирование, модульное тестирование, подготовка версии, итоговое тестирование.
После демонстрации Заказчику промежуточной версии продукта, как правило,
происходит уточнение и корректировка требований к информационной системе, что
влечет за собой повторный анализ всех требований на предмет согласованности,
непротиворечивости и т.п.
Рисунок 9 - Жизненный цикл типового проекта разработки заказного ПО
Полностью завершенная информационная система переходит на этап опытной
эксплуатации. Совместно с Заказчиков выполняется проверка работы готовой
системы в реальных условиях эксплуатации. Параллельно формируется пакет
документов к программному обеспечению.
Далее идет этап внедрения. На данном этапе выполняются следующие задачи:
установка и настройка системы, обучение пользователей.
Заключительный этап - сопровождение системы. Обычно по договору
составляет 12 месяцев с момента подписания Акта выполненных работ. За этот
период производится устранение всех недочетов и ошибок, осуществляется
поддержка пользователей.
На рисунке 9 схематично представлен жизненный цикл типового проекта на
разработку заказного программного обеспечения.
На рисунке 10 представлена типовая организационная структура проекта
разработки заказного программного обеспечения.
Рисунок 10 - Организационная структура проекта
Ключевая роль в проектной команде - руководитель проекта. Это всегда один
человек. В зависимости от масштабов проекта привлекается 1-2 аналитика. Иногда,
в случае, если проект небольшой, то роль аналитика может выполнять руководитель
проекта. Также в зависимости от масштабов проекта привлекается как правило от
одного до пяти программистов (в среднем 2-3 программиста).
· Формирование концептуальной модели
Основная цель данного процесса - выявление ключевых требований к системе
и формирование документа-концепции. Документ представляет собой высокоуровневое
видение будущей системы, в нем представлены ключевые характеристики, функции,
ограничения.
Выходами данного процесса являются:
o Задаются ключевые характеристики и функции системы;
o Определяются ограничения для решений;
o Формируется основа для ведения переговоров и заключения
соглашения о разработке продукта;
o Формируется документ-концепция
· Сбор требований
Определяется перечень заинтересованных лиц, собираются пожелания
выявленных участников к будущей информационной системе.
Цель процесса - выявление требований к системе, выполнение которых
обеспечит удовлетворение потребностей Заказчика.
Задачи процесса:
o Идентификация заинтересованных сторон;
o Идентификация требований;
o Оценка требований;
o Согласование требований;
o Регистрация требований.
Выходы процесса:
o Задаются свойства системы;
o Задаются ограничения на решения.
· Анализ требований
Цель процесса - преобразовать определенные требования в совокупность
системных технических требований, которыми будут руководствоваться при
проектировании системы.
Задачи:
o Документирование требований;
o Оценивание требований.
Выходы:
o Устанавливается перечень системных функциональных и
нефункциональных требований;
o Системные требования анализируются на корректность и
тестируемость;
o Требования ранжируются, утверждаются;
o Определяются график выполнения работ, стоимость выполнения
работ.
· Проектирование системы
Собранные требования документируются более формально в виде моделей и
документации, разрабатывается архитектурный проект системы.
Цель процесса заключается в определении какие требования и как
распределить в относительно элементов системы.
Задачи:
o Формальная документация требований;
o Создание архитектуры проекта;
o Оценка архитектуры проекта;
o Документация проекта.
Выходы:
o Модели программного продукта;
o Определяется архитектурный проект системы;
o Требования распределяются по элементам системы;
o Разработка дополнительных спецификаций;
o Определяются интерфейсы системы;
o Техническое задание на разработку.
· Разработка прототипа системы
Цель: создание прототипа будущего программного продукта.
Задачи:
o Создание прототипа;
o Согласование прототипа.
Выходы:
o Прототип системы;
o Согласованные требования к системе.
· Управление изменениями
Цель процесса:
Обеспечить качественную и эффективную обработку изменений с целью
минимизации инцидентов, обусловленных преобразованиями.
Рисунок 11- Процессы управления требованиями в компании
Задачи:
o Провести проверку того, что результаты изменений
соответствуют представлениям Заказчика о системе;
o Внести изменения в проект, документацию.
Выходы:
o Измененные модели проекта, документация;
o Авторизованные изменения.
Описанные процессы схематично изображены на рисунке ниже.
1.13 Теоретические
основы по разработке показателей эффективности
При разработке набора показателей эффективности для процессов управления
требованиями будем придерживаться следующих принципов разработки метрик.
Показатели эффективности должны соответствовать принципу SMART (Specific, Measurable, Achievable, Realistic, Timely - конкретный, измеримый, достижимый, реалистичный,
своевременный). Этот набор вопрос должен быть задан для каждого показателя
эффективности, чтобы убедиться в его «правильности» [30].
Дадим расшифровку каждого вопроса:
· Конкретный - показатель должен быть максимально конкретным и ясным, не
должно возникать более одной трактовки сути и смысла показателя.
· Измеримый - должна быть возможность измерить/оценить
показатель.
· Достижимый - необходимо адекватно оценивать ситуацию и
понимать, что показатель достижим с точки зрения внешний и внутренних ресурсов,
которыми располагает организация.
· Реалистичный - показатель должен быть реалистичным и уместным
в конкретной ситуации.
· Своевременный − срок или точный период измерения - одна
из составляющих показателя.
1.14 Состав
показателей эффективности процессов управления требованиями
Для выявленных процессов проектов, связанных с управлением требованиями,
сформированы ключевые показатели их эффективности, которые представлены ниже.
Процесс «Формирование концептуальной модели»
Показатели для процесса формирования концептуальной модели представлены в
таблицах 3-5.
Табли
Описание показателя A1
|
Свойства
|
Описание
|
|
Показатель
|
Время разработки
концептуальной модели
|
|
Описание
|
Время, потраченное на
разработку и согласование концептуальной модели
|
|
Спецификация
|
Количество рабочих дней,
потраченных на разработку концептуальной модели будущего программного
продукта, ее демонстрацию и согласование с Заказчиком
|
|
Обоснование
|
На продолжительность
данного этапа влияет скорость реагирования проектной команды. Способность к
взаимодействию, переговорам и заключению договора должна улучшаться и данный
показатель оценивает эту тенденцию
|
|
Аудитория
|
Руководство компании,
руководитель проекта, члены проектной команды
|
|
Опасное значение
|
20 дней
|
|
Целевое значение
|
10 дней
|
|
Возможные значения
|
9999
|
|
Приоритет
|
1
|
Таблица 4
Описание показателя А2
|
Свойства
|
Описание
|
|
Показатель
|
Количество замечаний
Заказчика к концептуальной модели
|
|
Описание
|
Степень удовлетворенности
Заказчика концептуальной моделью системы
|
|
Спецификация
|
Количество замечаний, поступивших
от Заказчика при демонстрации концептуальной модели будущего программного
продукта
|
|
Обоснование
|
Показатель поможет оценить
эффективность процесса разработки концептуальной модели будущего программного
продукта
|
|
Аудитория
|
Руководство компании, руководитель
проекта, члены проектной команды
|
|
Опасное значение
|
>25
|
|
Целевое значение
|
10
|
|
Возможные значения
|
999
|
|
Приоритет
|
3
|
Таблица 5
Описание показателя А3
|
Свойства
|
Описание
|
|
Показатель
|
Затраты на формирование
концептуальной модели
|
|
Описание
|
Сколько стоит разработка
концептуальной модели системы
|
|
Спецификация
|
Оцениваются часы работы
сотрудников, материальные издержки, другие статьи расходов, связанные с
разработкой концептуальной модели системы
|
|
Обоснование
|
Показатели затрат имеют
важное значение на всех этапах реализации проекта, независимо от того
применительно к каким процессам они рассчитываются
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
20% бюджета проекта
|
|
Целевое значение
|
5% бюджета проекта
|
|
Возможные значения
|
По согласованию с
Заказчиком. Теоретически не ограничены
|
|
Приоритет
|
2
|
Процесс «Сбор требований»
Показатели для процесса «Сбор требований» представлены в таблицах 6-8.
Таблица 6
Описание показателя B1
|
Свойства
|
Описание
|
|
Показатель
|
Время сбора требований
|
|
Описание
|
Время, потраченное
проектной командой на сбор пожеланий к будущему программному продукту от
заинтересованных сторон
|
|
Спецификация
|
Количество дней,
необходимых для выявления заинтересованных в продукте лиц, сбора пожеланий к
программному продукту у них, формализации пожеланий в требования
|
|
Обоснование
|
Для качественного выявления
требований должно быть выделено достаточно времени на выявление всех
заинтересованных сторон, проведения бесед с ними и сбора требований к
будущему продукту
|
|
Аудитория
|
Руководитель проекта, члены
проектной команды
|
|
Опасное значение
|
25 дней
|
|
Целевое значение
|
15 дней
|
|
Возможные значения
|
9999
|
|
Приоритет
|
1
|
Таблица 7
Описание показателя В2
|
Свойства
|
Описание
|
|
Показатель
|
Покрытие требованиями
предметной области
|
|
Описание
|
Насколько выявленные
требования охватывают рассматриваемую предметную область
|
|
Спецификация
|
Экспертная оценка
|
|
Обоснование
|
Полнота анализа предметной
области и последующая разработка целостных требований непосредственно влияет
на ход работы и успех реализации проекта в целом
|
|
Аудитория
|
Руководитель проекта, члены
проектной команды
|
|
Опасное значение
|
<70%
|
|
Целевое значение
|
100%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
3
|
Таблица 8
Описание показателя В3
|
Свойства
|
Описание
|
|
Показатель
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
|
Описание
|
Насколько доступны для
взаимодействия заинтересованные стороны для сбора у них требований
|
|
Спецификация
|
Количество обращений к
заинтересованным лицам различными способами (почта, звонки, личные встречи и
т.д.) до момента получения требований от них/Количество заинтересованных лиц,
у которых необходимо собрать требования
|
|
Обоснование
|
Сроки сбора требований
напрямую зависят от возможности заинтересованных сторон взаимодействовать с
проектной командой
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
>8
|
|
Целевое значение
|
4
|
|
Возможные значения
|
99
|
|
Приоритет
|
2
|
Процесс «Анализ требований»
Показатели процесса анализа требований представлены в таблицах 9 - 12.
Таблица 9
Описание показателя С1
|
Свойства
|
Описание
|
|
Показатель
|
Процент подлежащих
реализации требований
|
|
Описание
|
Насколько высокий
показатель утвержденных к реализации требований, в сравнении с общим
количеством требований, выявленных в ходе аналитических работ
|
|
Спецификация
|
Количество требований,
утвержденных для реализации по отношению к общему количеству выявленных
требований, выраженное в процентном соотношении
|
|
Обоснование
|
Показатель процента
подлежащих реализации требований позволяет оценить качество выполненного
предварительного анализа, а также перспективы дальнейшего развития проекта
|
|
Аудитория
|
Руководитель проекта, члены
проектной команды
|
|
Опасное значение
|
<60%
|
|
Целевое значение
|
80%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
4
|
Таблица 10
Описание показателя С2
|
СвойстваОписание
|
|
|
Показатель
|
Количество дополнительных
требований
|
|
Описание
|
Выявленные требования на
этапе анализа
|
|
Спецификация
|
Количество новых выявленных
требований на этапе анализа и утвержденных к реализации
|
|
Обоснование
|
В момент проведения анализа
могут быть выявлены новые требования. Показатель отображает эффективность
процесса сбора требований
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
30
|
|
Целевое значение
|
10
|
|
Возможные значения
|
9999
|
|
Приоритет
|
2
|
Таблица 11
Описание показателя С3
|
Свойства
|
Описание
|
|
Показатель
|
Процент требований,
подлежащих корректировке
|
|
Описание
|
Количество требований с
ошибками после завершения стадии анализа
|
|
Спецификация
|
Отношение количества
требований с ошибками к общему объему требований после завершения стадии
анализа, выраженное в процентах
|
|
Обоснование
|
Уровень ошибок определяет
качество требований. Ошибкой в требовании можно считать: неполнота,
неоднозначность, двусмысленность, отсутствие необходимости, отсутствие
возможности протестировать требование
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
20%
|
|
Целевое значение
|
3%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
3
|
Таблица 12
Описание показателя С4
|
Свойства
|
Описание
|
|
Показатель
|
Точность планирования
аналитических работ
|
|
Описание
|
Насколько точно было
спланировано проведение аналитических работ.
|
|
Спецификация
|
(Затраченное время -
Запланированное время)/Запланированное время
|
|
Обоснование
|
Повысить качество
управления аналитическими работами
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
>0,2
|
|
Целевое значение
|
0,05
|
|
Возможные значения
|
9999
|
|
Приоритет
|
1
|
Процесс «Проектирование системы»
Показатели процесса «Проектирование системы» описаны в таблицах 13-15.
Таблица 13
Описание показателя D1
|
Свойства
|
Описание
|
|
Показатель
|
Затраты на проектирование
системы
|
|
Описание
|
Сколько стоит данный этап
разработки программного продукта
|
|
Спецификация
|
Оцениваются часы работы
сотрудников, материальные издержки, связанные с проектированием системы
|
|
Обоснование
|
Процесс проектирования
системы является важным и трудозатратным этапом при разработке программного
продукта. Поэтому необходимо отслеживать затраты на данный этап
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
50% бюджета
|
|
Целевое значение
|
Сделать этап экономически
выгодным
|
|
Возможные значения
|
Теоретически не ограничены
|
|
Приоритет
|
2
|
Таблица 14
Описание показателя D2
|
Свойства
|
Описание
|
|
Показатель
|
Время проектирования
системы
|
|
Описание
|
Время, потраченное
проектной командой на проектирование программного продукта
|
|
Спецификация
|
Количество рабочих дней,
необходимых для проектирования программного продукта по отношению к общей
длительности проекта, в процентном соотношении
|
|
Обоснование
|
Для успешной реализации
системы необходимо уделить достаточное время проектированию. При этом
чрезмерное увеличение сроков данного этапа могут пойти в ущерб длительности
этапа реализации системы и проектная команда рискует не уложиться в сроки
|
|
Аудитория
|
Руководство компании,
руководитель проекта, члены проектной команды
|
|
Опасное значение
|
50%
|
|
Целевое значение
|
30%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
1
|
Таблица 15
Описание показателя D3
|
Свойства
|
Описание
|
|
Показатель
|
Процент измененных
требований
|
Процент измененных
требований на этапе проектирования
|
|
Спецификация
|
Процентное соотношение количества
требований, претерпевших изменения на этапе проектирования продукта к общему
количеству утвержденных к реализации требованиям
|
|
Обоснование
|
Показатель отображает
эффективность процессов сбора и анализа требований. На этапе проектирования
программного продукта выявляются требования, требующие корректировки,
уточнений
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
10%
|
|
Целевое значение
|
3%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
3
|
Процесс «Разработка прототипа системы».
Показатели процесса, связанного с разработкой прототипа системы
представлены в таблицах 16-18.
Таблица 16
Описание показателя Е1
|
Свойства
|
Описание
|
|
Показатель
|
Количество замечаний,
поступивших от Заказчика
|
|
Описание
|
Степень удовлетворенности
Заказчика прототипом системы
|
|
Спецификация
|
Количество замечаний,
поступивших от Заказчика при демонстрации прототипа системы
|
|
Обоснование
|
Показатель поможет оценить
эффективность процесса разработки прототипа системы
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
>20
|
|
Целевое значение
|
10
|
|
Возможные значения
|
999
|
|
Приоритет
|
3
|
Таблица 17
Описание показателя Е2
|
СвойстваОписание
|
|
|
Показатель
|
Время разработки прототипа
|
|
Описание
|
Время, потраченное
проектной командой на разработку и утверждение с Заказчиком прототипа
|
|
Спецификация
|
Количество рабочих дней,
необходимых для разработки прототипа системы и утверждение его с Заказчиком
по отношению к общей длительности проекта, выраженное в процентах
|
|
Обоснование
|
Быстрая разработка
прототипа позволяет своевременно получить от Заказчика обратную связь,
утвердить и согласовать принципиально важные моменты и начать разработку в
нужном направлении.
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
>10%
|
|
Целевое значение
|
5%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
2
|
Таблица 18
Описание показателя Е3
|
СвойстваОписание
|
|
|
Показатель
|
Стоимость разработки
прототипа
|
|
Описание
|
Сколько стоит разработка
прототипа
|
|
Спецификация
|
Оцениваются часы работы
сотрудников, материальные издержки, связанные с разработкой прототипа по
отношению к бюджету проекта, выраженные в процентном соотношении
|
|
Обоснование
|
Прототип будущего
программного продукта позволяет убедиться в правильности выбранного
направления реализации, согласовать важные функциональные требования. Однако
разработка прототипа не должна влечь за собой больших финансовых затрат.
Данный показатель позволяет экономически обосновать наличие данного этапа в
разработке системы
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
>10%
|
|
Целевое значение
|
5%
|
|
Возможные значения
|
9999
|
|
Приоритет
|
1
|
программный управление требование
Процесс «Управление изменениями»
Показатели процесса «Управление изменениями» описаны в таблицах 19-24.
Таблица 19
Описание показателя F1
|
Свойства
|
Описание
|
|
Показатель
|
Количество несогласованных
требований
|
|
Описание
|
По мере реализации проекта
будут появляться новые требования или изменяться уже выявленные, которые
необходимо проанализировать, устранить несогласованности в требованиях,
проранжировать и т.д.
|
|
Спецификация
|
Зафиксированные требования,
которые еще не были проанализированы и утверждены
|
|
Обоснование
|
Несвоевременное
согласование требований может привести к реализации противоречивых или
неактуальных требований, что повлечет за собой увеличение сроков реализации
проекта и увеличению бюджета.
|
|
Аудитория
|
Руководитель проекта,
аналитик
|
|
Опасное значение
|
10
|
|
Целевое значение
|
5
|
|
Возможные значения
|
9999
|
|
Приоритет
|
3
|
Таблица 20
Описание показателя F2
|
Свойства
|
Описание
|
|
Показатель
|
Процент утвержденных
изменений
|
|
Описание
|
Процент утвержденных
изменений в общем количестве поступивших изменений
|
|
Спецификация
|
Отношение принятых к
реализации изменений к общему количеству поступивших от Заказчика изменений,
выраженное в процентах
|
|
Обоснование
|
Увеличение данного
показателя может свидетельствовать о некачественном проведении проверки того,
что результаты внесения изменений соответствуют изначальным целям разработки.
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
80%
|
|
Целевое значение
|
50%
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
4
|
Таблица 21
Описание показателя F3
|
Свойства
|
Описание
|
|
Показатель
|
Количество новых выявленных
требований
|
|
Описание
|
Количество новых
требований, которые не были выявлены до этого момента
|
|
Спецификация
|
Количество новых выявленных
и утвержденных к реализации требований на этапе реализации
|
|
Обоснование
|
Если на текущем этапе
появляется значительное количество новых требований, значит процесс
первоначального сбора и анализа требований был проведен недостаточно
эффективно.
|
|
Аудитория
|
Руководитель проекта, проектная
команда
|
|
Опасное значение
|
10
|
|
Целевое значение
|
5
|
|
Возможные значения
|
9999
|
|
Приоритет
|
1
|
Таблица 22
Описание показателя F4
|
Свойства
|
Описание
|
|
Показатель
|
Стоимость выявленных
изменений
|
|
Описание
|
Сколько стоит внесение
выявленных изменений
|
|
Спецификация
|
Оцениваются часы работы
сотрудников, материальные издержки, связанные с реализацией выявленных
изменений в проекте и новых требований.
|
|
Обоснование
|
Поступающие от Заказчика
изменения в имеющихся требованиях (особенно уже реализованных) и новые требования
могут значительно увеличивать сроки и стоимость работ. Есть риск выйти за
рамки бюджета. Поэтому необходимо своевременно оценивать и отслеживать
стоимость внесения изменений.
|
|
Аудитория
|
Руководство компании,
руководитель проекта
|
|
Опасное значение
|
Превышение бюджета проекта
|
|
Целевое значение
|
Сделать этап экономически
выгодным
|
|
Возможные значения
|
9999
|
|
Приоритет
|
5
|
Таблица 23
Описание показателя F5
|
Свойства
|
Описание
|
|
Показатель
|
Количество требований,
потерявших актуальность
|
|
Описание
|
Количество реализованных
требований, потерявших актуальность к моменту выпуска итогового продукта
|
|
Спецификация
|
Количество требований,
реализованных в итоговом продукте, но не имеющих более ценности для Заказчика
|
|
Обоснование
|
Во время разработки
требования могут изменяться и часть из них может стать совсем неактуальной.
Данная метрика показывает эффективность и скорость внесения изменений в
документацию и своевременное принятие решений
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
5
|
|
Целевое значение
|
0
|
|
Возможные значения
|
9999
|
|
Приоритет
|
2
|
Таблица 24
Описание показателя F6
|
Свойства
|
Описание
|
|
Показатель
|
Процент нереализованных
требований
|
|
Описание
|
Количество требований,
подлежащих реализации, но по каким-либо причинам так и не реализованным в
итоговом программном продукте в общем количестве принятым к реализации
требованиям
|
|
Спецификация
|
Количество нереализованных
требований к общему количеству требований, подлежащих реализации, выраженное
в процентном соотношении
|
|
Обоснование
|
Нереализованные требования снижают
способность итогового продукта полностью удовлетворить ожиданиям Заказчика
|
|
Аудитория
|
Руководитель проекта,
проектная команда
|
|
Опасное значение
|
2%
|
|
Целевое значение
|
0
|
|
Возможные значения
|
0-100%
|
|
Приоритет
|
6
|
Разработанные показатели эффективности процессов представлены на рисунке
ниже.
Рисунок 12 - Показатели эффективности процессов управления требованиями
2. Оценка текущих процессов в компании и разработка
рекомендаций
2.1 Оценка
процессов управления требованиями в реализованных проектах компании
Проект P1 - Автоматизация социальной защиты. ГБУ «Кризисный центр помощи женщинам
и детям»
В ходе реализации проекта был создан продукт для автоматизации
реабилитационных центров. Возможности системы:
· Автоматизация основных бизнес-процессов;
· Ведение электронного документооборота;
· Система ключевых показателей работы Центра в реальном
времени;
· Формирование расписания всех мероприятий клиентов и
специалистов Центра;
· Учет оказанных услуг;
· Управление отношениями с клиентами.
Оценка процессов управления требованиями в проекте представлена в
Приложении 7.
Как видно из оценок, много времени было потрачено на разработку
концептуальной модели, однако модель оказалась недостаточно убедительной для
Заказчика, было получено много замечаний (хотя их количество и не достигло
критического показателя).
Исходя из показателей, много времени было потрачено на сбор требований,
что в основном связано с плохой доступностью заинтересованных сторон для сбора
у них требований (значение показателя превышает критический уровень). Но и
количество и качество в итоге собранных требований оказалось недостаточным -
покрытие предметной области всего на 70%. Качество сбора требований отразилось
и на других показателях - большое количество новых выявленных требований и
требований подлежащих корректировке на этапе анализа, измененных требований на
этапе проектирования системы и значительное количество новых выявленных
требований впоследствии.
В итоге стоимость принятых изменений оказалась экономически невыгодной.
Имеются неудовлетворительные значения показателей «F5. Количество требований, потерявших актуальность» и «F6. Процент нереализованных
требований».
Несмотря на плохие значения многих показателей, продукт был внедрен в
компании и успешно эксплуатируется. Нереализованные требования будут учтены в
будущем, при подписании договора на развитие информационной системы.
Проект P2 - Автоматизация ООО Частное охранное предприятие «Русский Витязь»
Разработанная система позволяет:
· Вести учет сотрудников охранного предприятия, охраняемых объектов;
· Проводить инспекцию сотрудников и объектов;
· Включает наглядную систему показателей эффективности работы
сотрудников.
Оценка процессов управления требованиями в проекте представлена в
Приложении 8.
Разработка системы проходила достаточно быстрыми темпами. Положительными
сторонами проекта было достаточно активное участие заинтересованных сторон в
разработке системы, их доступность для проектной команды, достаточно ясное
понимание требований к будущему продукту.
Много времени и ресурсов было потрачены на проектирование информационной
системы и прототипирование, однако это помогло в дальнейшем избежать
значительных изменений в требованиях, уложиться в короткие сроки проекта и
бюджет.
Проект P3 - Автоматизация ООО «СПОРТФИШ ТУР»
Разработанная система управления клиентами позволяет не только эффективно
взаимодействовать с клиентами:
· Учет бронирования туров;
· Автоматическое формирование пакета документов для оформления
заказа;
· Учет оплат и предоплат, отслеживание неоплаченных заказов;
· Интеграция с сайтом.
Оценка процессов управления требованиями в проекте представлена в
Приложении 9.
В ходе данного проекта значительная часть времени была потрачена на сбор
требований, что в основном было обусловлено несогласованностью заинтересованных
сторон в отношении требований к будущей системе. Эта несогласованность
прослеживалась на всем этапе реализации проекта, что можно увидеть из значений
показателей «E1. Количество замечаний, поступивших
от Заказчика», «F1. Количество
несогласованных требований», «F3.
Количество новых выявленных требований», «F4. Стоимость выявленных изменений», «F5. Количество требований, потерявших актуальность».
Система внедрена и успешно используется в компании, хотя достаточно
ресурсов было потрачено при внедрении и сопровождении системы.
Проект P4 - Автоматизация Российских студенческих отрядов
Российские студенческие отряды, организация с более 200 тыс. членов. Для
достижения целей развития организации было предложено специальное решение:
· Создание единой информационной среды;
· Управление работой с партнерами и заказчиками;
· Координация работы подразделений;
· Создание единого реестра бойцов;
· Управление проектами и задачами;
· Ведение электронного документооборота.
Оценка процессов управления требованиями в проекте представлена в
Приложении 10.
Исходя из приведенных значений показателей можно сделать вывод об
успешности проекта, что в основном обусловлено применении собственной
разработанной платформы при разработке, легкостью реализации заявленных
требований к системе с помощью данной платформы.
Проект Р5 - Автоматизация открытых R&D центров - ФРИП ТПП
Было разработано приложение на базе комплекса «Простой бизнес» с
возможностями социальной сети, которое позволяет:
· Выявить потребности крупного бизнеса в области инновационного развития;
· Управлять системой открытых R&D центров с целью
применения научно-технического потенциала инновационных предприятий, ВУЗов и
НИИ вне зависимости от их географического положения;
· Наладить диалог между крупным и малым бизнесом.
Оценка процессов управления требованиями в проекте представлена в
Приложении 11.
Данный проект отличается сложностью самих требований к информационной
системе с точки зрения логики работы. В связи с этим значительное количество
времени было потрачено на разработку концептуальной модели, проектирование
системы и прототипирование. Хотя количество замечаний у Заказчика было не много
и в ходе реализации проекта поступило незначительное количество новых
требований, но сложность реализации этих изменений негативно отразилась на экономических
показателях проекта. Также часть требований к моменту окончания проекта так и
не была реализована.
2.2
Рекомендации по повышению качества процессов управления требованиями в компании
На рисунке ниже представлена общая ситуация по процессам по итогам оценок
пяти проектов.
Рисунок 13 - Общая оценка процессов управления требованиями в компании
Как видно из рисунка, наименее качественно управление требованиями
осуществляется на этапе управления изменениями требований. Также имеются
проблемы в процессах анализа требований и сбора требований.
В связи с этим, для повышения качества данных процессов рекомендуется
провести изменения, основанные на методологии RUP.
Для процесса «Управление изменениями» предлагается следующий алгоритм
управления запросами на изменения [35], который представлен на рисунке ниже в
виде диаграммы действий.
Рисунок 14 - Диаграмма действий для запроса на изменение
В Приложении 12 представлено описание задач и роли процесса управления
запросами на изменения.
В компании не существует единой формы запроса на внесение изменений,
поэтому предлагается использовать форму, представленную в методике RUP (Приложение 13).
Для сбора требований в компании преимущественно используется метод
интервьюирования. Рекомендуется в дополнение применение метода анализа
вариантов использования [36].
Предлагаемый вариант изменений в процессе сбора требований представлен в
виде диаграммы действий на рисунке 15.
Рисунок 15 - Ход процесса сбора требований
Описание задач процесса сбора требований и ролей представлено в
Приложении 15.
Анализ требований рекомендуется проводить на основе описаний вариантов
использования. Анализ на базе вариантов использования считается эффективным,
т.к. данный метод позволяет предотвратить потерю связи с пользовательскими
историями и демонстрирует поведение будущего продукта в целом и гарантирует
востребованность всего функционала системы. Что в свою очередь должно снизить
значение показателя «F5.
Количество требований, потерявших актуальность», которое имеет
неудовлетворительное значение в ряде проектов компании. Варианты использования
также будут использоваться при оценке выполнения работ.
В компании недостаточно эффективно отлажены процессы тестирования. В
связи с этим предлагается использовать активности/задачи, связанные с
тестированием, предложенные в методике RUP [37]. В целом процесс тестирования представлен на
рисунке ниже.
Рисунок 16 - Процесс тестирования
Описание задач и ролей процесса тестирования представлено в Приложении
15.
С учетом предложенных изменений общая схема процессов управления
требований компании будет выглядеть следующим образом (см. рисунок 17).
Рисунок 17 - Предлагаемые процессу управления требованиями
Заключение
Разработка программного обеспечения критически уязвима, если процессу
управления требованиями не уделяется достаточное внимание. Одним из способов предотвращения
широкого спектра проблем при разработке информационных систем является
использование подходов, уделяющих серьезное внимание работе с требованиями,
начиная, что особенно важно, с самых ранних этапов реализации проекта. Довольно
часто требования претерпевают изменения в ходе проекта, что приводит к
необходимости управления ими в ходе всего жизненного цикла программного
обеспечения. Управление требованиями должно быть систематизированным и
поэтапным, чтобы убедиться, что продукт продолжает удовлетворять заявленным
требованиям Заказчика.
К настоящему моменту процессы выявления, анализа, тестирования, изменения
требований рассмотрены во многих методологиях разработки программного
обеспечения и управления проектами. Чтобы управление требованиями обеспечивало
максимальную эффективность, каждая компания-разработчик программного
обеспечения должна принять решение в пользу той или иной методологии, учитывая
специфику ее деятельности и особенности проектов.
В ходе выполнения работы был сформирован набор критериев для оценки
процессов управления требованиями в различных методиках с точки зрения
возможности их использования для проектов заказной разработки программного
обеспечения. По результатам выполненного анализа с помощью метода анализа
иерархий оптимальной методикой управления требованиями в заказной разработке
программного обеспечения является методология разработки программного
обеспечения RUP, в основе которой лежат следующие принципы:
· Ориентация на требования Заказчика;
· Раннее выявление и постоянное устранение рисков;
· Постоянное обеспечение качества;
· Готовность к изменениям в требованиях в ходе реализации
проекта.
Был осуществлен анализ деятельности ИТ-компании, которая занимается
разработкой программного обеспечения на заказ. Были выделены имеющиеся в
компании процессы, связанные с управлением требованиями. Для каждого процесса
был разработан набор показателей эффективности и произведена оценка выполненных
проектов по данным показателям.
Учитывая полученные результаты оценки процессов управления требованиями,
в компании были сформулированы рекомендации по внесению изменений в процессы с
целью повышения их качества. Предложенные изменения были основаны на процессах
методологии RUP, которая по итогам анализа оказалась
наиболее подходящей для проектов заказной разработки программного обеспечения.
Разработанный набор критериев для сравнения методик может быть
использован компании, перед которыми стоит задача выбора методологии для
организации управления требованиями. При этом набор альтернатив может
отличаться от представленного в настоящей работе.
Разработанный набор показателей эффективности процессов управления
требованиями может применяться компаниями, в которых присутствуют аналогичные
процессы.
СПИСОК ЛИТЕРАТУРЫ
1. Вигерс
Карл. Разработка требований к программному обеспечению / Пер, с англ. - М.:
Издательско-торговый дом «Русская Редакция», 2004. -576с.: ил.
2. Леффингуэлл
Дин, Уидриг Дон. Принципы работы с требованиями к программному обеспечению.
Унифицированный подход.: Пер. с англ. - М. : Издательский дом «Вильямс», 2002.
- 448 с.:ил. - Парал. тит. англ.
3. IEEE
Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990.
4. Астелс,
Дэвид; Миллер Гранвилл; Новак, Мирослав. Практическое руководство по
экстремальному программированию: Пер. с англ. - М.: Издательский дом «Вильямс»,
2002. - 320 с.: ил. - Парал. тит. англ.
5. Алистер
Коберн. Современные методы описания функциональных требований к системам. М.:
издательство «Лори», 2002. - 263 с.
. Мацяшек
Лешек. Анализ требований и проектирование систем. Разработка информационных :с
Диалектика-Вильямс.
. Элизабет
Халл, Кен Джексон, Джереми Дик. Разработка и управление требованиями.
Практическое руководство пользователя. 2005.
. Доминик
Товассоли. Управление требованиями. Десять шагов на пути к совершенству
[Электронный ресурс]
. Новичков
Александр. Роль процесса управления требованиями при разработке сложных
программных систем [Электронный ресурс]
10. Роман
Алфимов, Елена Золотухина, Светлана Красникова. Управление требованиями на базе
стандартов [Электронный ресурс]
11. REQB®
REBOK Requirements Engineering Body Of Knowledge. Version 1.0.
12. Руководство
к своду знаний по управлению проектами. Третье издание. (Руководство PMBOK).
13. Технология Rational Unified Process
(IBM Rational Software) [Электронный ресурс]
14. Филипп
Крачтен. Принципы управления требованиями в Rational Unified Process.
15. Алексей
Закис. RUP и другие методологии разработки ПО
[Электронный ресурс]
16. IT
<https://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8>
Infrastructure Library. Version 3.0
17. A Guide to
the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0.
. Guide to
the Software Engineering Body of Knowledge (SWEBOK). 2004 Version.
19. Сергей Орлик, Юрий
Булуй. Программная инженерия. Программные
требования (Software Requirements). Глава базируется на
IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK, 2004. Содержит перевод описания области знаний SWEBOK Software Requirements, с комментариями и
замечаниями. 2004 - 2005.
. Сергей Орлик.
Программная инженерия. Конфигурационное управление (Software
Configuration Management). Глава базируется на IEEE Guide to the Software Engineering
Body of Knowledge - SWEBOK, 2004. Содержит
перевод описания области знаний SWEBOK Software Configuration Management, с комментариями и замечаниями. 2004 - 2005.
. Булуй Ю.И.
Классификация требований к программному обеспечению и ее представление в
стандартах и методологиях.
. В.В. Липаев.
Проектирование и производство сложных заказных программных продуктов. - М.:
СИНТЕГ, 2011. - 408 с.
. Брауде Э. Технологии
разработки программного обеспечения. - СПб: Питер, 2004. - 655 с.: ил.
. Владимир Грудинин.
Разработка на заказ. Российский рынок разработки на заказ: тенденции и
перспективы [Электронный ресурс]
. Ольга Мельник.
Заказное ПО: спрос растет [Электронный ресурс]
. Тиражные приложения
и заказная разработка. Преимущества для заказчика. [Электронный ресурс]
. Т. Саати. Принятие
решений. Метод анализа иерархий. Пер. с англ. - М.: «Радио и связь», 1993.
. Петровский А.Б.
Теория принятия решений - М.: Издательский центр «Академия», 2009.
. Саати Т.Л. Decision-making with the AHP: why is the
principal eigenvector necessary, European J. Oper. Res., 2003 [Электронный ресурс]
30. Брукс П.
Метрики для управления ИТ-услугами; Пер. с англ. - М. Альпина Бизнес Букс,
2008.
. Система KPI: разработка и применение показателей
бизнес-процесса. Показатели эффективности [Электронный ресурс]
32. Г.М.
Шишков, С.С. Зинина. Измерение качества процесса [Электронный ресурс]
. Антипов
Д.В. Разработка модели оценочных показателей устойчивого развития организации
// Вектор науки Тольятинского государственного университета. - 2010. - №4. - С.
186-189.
. Балашова
Е.С. Показатели оценки организационной эффективности бизнес-процессов / Е.С.
Балашова // Научно-технические ведомости СПбГПУ. Экономические науки. - 2014. -
№2 (192). - с. 185-190.
35. Unified
Change Management from Rational Software: An Activity-Based Process for
Managing Change [Электронный ресурс]
36. Определение
требований как основа эффективности поставки программного обеспечения
[Электронный ресурс]
. Вячеслав
Панкратов. Препарируем RUP -
задачи и роли в тестировании [Электронный ресурс]
ПРИЛОЖЕНИЕ 1
Иерархия критериев для выбора методики по управлению
требованиями
ПРИЛОЖЕНИЕ 2
Сравнительный анализ методик экспертом 1
|
A1
|
B1
|
B2
|
B3
|
B4
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
8
|
3
|
4
|
2
|
6
|
3,24
|
0,39
|
|
6,2795
|
0,0559
|
0,0451
|
|
B2
|
1/8
|
1
|
1/7
|
1/5
|
1/9
|
1/3
|
0,23
|
0,03
|
|
|
|
|
|
B3
|
1/3
|
7
|
1
|
1
|
1/2
|
2
|
1,15
|
0,14
|
|
|
|
|
|
B4
|
1/4
|
5
|
1
|
1
|
1/3
|
1/2
|
0,77
|
0,09
|
|
|
|
|
|
B5
|
1/2
|
9
|
2
|
3
|
1
|
6
|
2,33
|
0,28
|
|
|
|
|
|
B6
|
1/6
|
3
|
1/2
|
2
|
1/6
|
1
|
0,66
|
0,08
|
|
|
|
|
|
A2
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
1/8
|
1/8
|
1/7
|
4
|
0,57
|
0,01
|
|
5,2688
|
0,1462
|
0,1179
|
|
B2
|
1/4
|
1
|
1/9
|
1/9
|
1/8
|
1
|
2,60
|
0,03
|
|
|
|
|
|
B3
|
8
|
9
|
1
|
1
|
1
|
7
|
27,00
|
0,31
|
|
|
|
|
|
B4
|
8
|
9
|
1
|
1
|
2
|
8
|
29,00
|
0,33
|
|
|
|
|
|
B5
|
7
|
8
|
1
|
1/2
|
1
|
8
|
25,50
|
0,29
|
|
|
|
|
|
B6
|
1/4
|
1
|
1/7
|
1/8
|
1/8
|
1
|
2,64
|
0,03
|
|
|
|
|
|
A3
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1
|
1/4
|
1/5
|
1/5
|
1/2
|
0,41
|
0,06
|
|
6,0111
|
0,0022
|
0,0018
|
|
B2
|
1
|
1
|
1/4
|
1/5
|
1/5
|
1/2
|
0,41
|
0,06
|
|
|
|
|
|
B3
|
4
|
4
|
1
|
1
|
1
|
2
|
1,78
|
0,24
|
|
|
|
|
|
B4
|
5
|
5
|
1
|
1
|
1
|
2
|
1,92
|
0,26
|
|
|
|
|
|
B5
|
5
|
5
|
1
|
1
|
1
|
2
|
1,92
|
0,26
|
|
|
|
|
|
B6
|
2
|
2
|
1/2
|
1/2
|
1/2
|
1
|
0,89
|
0,12
|
|
|
|
|
|
A4
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
7
|
1/2
|
1
|
7
|
2
|
1,91
|
0,23
|
|
6,3816
|
0,0763
|
0,0616
|
|
B2
|
1/7
|
1
|
1/5
|
1/7
|
1
|
1/5
|
0,31
|
0,04
|
|
|
|
|
|
B3
|
2
|
5
|
1
|
3
|
7
|
2
|
2,74
|
0,33
|
|
|
|
|
|
B4
|
1
|
7
|
1/3
|
1
|
7
|
3
|
1,91
|
0,23
|
|
|
|
|
|
B5
|
1/7
|
1
|
1/7
|
1/7
|
1
|
1/6
|
0,28
|
0,03
|
|
|
|
|
|
B6
|
1/2
|
5
|
1/2
|
1/3
|
6
|
1
|
1,16
|
0,14
|
|
|
|
|
|
A5
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
6
|
1/2
|
5
|
1/4
|
1/3
|
1,04
|
0,12
|
|
6,4016
|
0,0803
|
0,0648
|
|
B2
|
1/6
|
1
|
1/7
|
1/2
|
1/6
|
1/5
|
0,27
|
0,03
|
|
|
|
|
|
B3
|
2
|
7
|
1
|
6
|
1
|
3
|
2,51
|
0,30
|
|
|
|
|
|
B4
|
1/5
|
2
|
1/6
|
1
|
1/6
|
1/5
|
0,36
|
0,04
|
|
|
|
|
|
B5
|
4
|
6
|
1
|
6
|
1
|
3
|
2,75
|
0,33
|
|
|
|
|
|
B6
|
3
|
5
|
1/3
|
5
|
1/3
|
1
|
1,42
|
0,17
|
|
|
|
|
|
A6
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
|
B1
|
1
|
5
|
1/2
|
1
|
6
|
5
|
2,05
|
0,24
|
|
6,2353
|
0,0471
|
0,0380
|
|
B2
|
1/5
|
1
|
1/6
|
1/6
|
2
|
1/3
|
0,39
|
0,05
|
|
|
|
|
|
B3
|
2
|
6
|
1
|
2
|
6
|
5
|
2,99
|
0,35
|
|
|
|
|
|
B4
|
1
|
6
|
1/2
|
1
|
6
|
5
|
2,12
|
0,25
|
|
|
|
|
|
B5
|
1/6
|
1/2
|
1/6
|
1/6
|
1
|
1/3
|
0,30
|
0,04
|
|
|
|
|
|
B6
|
1/5
|
3
|
1/5
|
1/5
|
3
|
1
|
0,64
|
0,08
|
|
|
|
|
|
A7
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/6
|
3
|
1/6
|
1/6
|
0,55
|
0,06
|
|
6,1708
|
0,0342
|
0,0275
|
|
B2
|
1/2
|
1
|
1/7
|
1
|
1/7
|
1/7
|
0,34
|
0,04
|
|
|
|
|
|
B3
|
6
|
7
|
1
|
7
|
1
|
2
|
2,89
|
0,33
|
|
|
|
|
|
B4
|
1/3
|
1
|
1/7
|
1
|
1/6
|
1/5
|
0,34
|
0,04
|
|
|
|
|
|
B5
|
6
|
7
|
1
|
6
|
1
|
2
|
2,82
|
0,32
|
|
|
|
|
|
B6
|
6
|
7
|
1/2
|
5
|
1/2
|
1
|
1,94
|
0,22
|
|
|
|
|
|
A8
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/6
|
1/6
|
1/6
|
4
|
0,62
|
0,07
|
|
6,1932
|
0,0386
|
0,0312
|
|
B2
|
1/3
|
1
|
1/7
|
1/7
|
1/7
|
3
|
0,38
|
0,04
|
|
|
|
|
|
B3
|
6
|
7
|
1
|
1
|
1
|
7
|
2,58
|
0,29
|
|
|
|
|
|
B4
|
6
|
7
|
1
|
1
|
1
|
7
|
2,58
|
0,29
|
|
|
|
|
|
B5
|
6
|
7
|
1
|
1
|
1
|
7
|
2,58
|
0,29
|
|
|
|
|
|
B6
|
1/4
|
1/3
|
1/7
|
1/7
|
1/7
|
1
|
0,25
|
0,03
|
|
|
|
|
|
A9
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1/4
|
1/4
|
1/5
|
1/5
|
1/4
|
0,29
|
0,04
|
|
6,1071
|
0,0214
|
0,0173
|
|
B2
|
4
|
1
|
2
|
1
|
1
|
2
|
1,59
|
0,23
|
|
|
|
|
|
B3
|
4
|
1/2
|
1
|
1
|
1/2
|
2
|
1,12
|
0,16
|
|
|
|
|
|
B4
|
5
|
1
|
1
|
1
|
1
|
2
|
1,47
|
0,21
|
|
|
|
|
|
B5
|
5
|
1
|
2
|
1
|
1
|
2
|
1,65
|
0,24
|
|
|
|
|
|
B6
|
4
|
1/2
|
1/2
|
1/2
|
1/2
|
1
|
0,79
|
0,11
|
|
|
|
|
|
A10
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1
|
1/4
|
1/4
|
1/4
|
1/3
|
0,42
|
0,06
|
|
6,0234
|
0,0047
|
0,0038
|
|
B2
|
1
|
1
|
1/4
|
1/4
|
1/4
|
1/3
|
0,42
|
0,06
|
|
|
|
|
|
B3
|
4
|
4
|
1
|
1
|
1
|
2
|
1,78
|
0,25
|
|
|
|
|
|
B4
|
4
|
4
|
1
|
1
|
1
|
2
|
1,78
|
0,25
|
|
|
|
|
|
B5
|
4
|
4
|
1
|
1
|
1
|
2
|
1,78
|
0,25
|
|
|
|
|
|
B6
|
3
|
3
|
1/2
|
1/2
|
1/2
|
1
|
1,02
|
0,14
|
|
|
|
|
|
A11
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/2
|
2
|
1
|
1,12
|
0,18
|
|
6,0662
|
0,0132
|
0,0107
|
|
B2
|
1/2
|
1
|
1/3
|
1
|
1/2
|
1/2
|
0,59
|
0,09
|
|
|
|
|
|
B3
|
2
|
3
|
1
|
2
|
1
|
1
|
1,51
|
0,24
|
|
|
|
|
|
B4
|
1/2
|
1
|
1/2
|
1
|
1/2
|
1/2
|
0,63
|
0,10
|
|
|
|
|
|
B5
|
1
|
2
|
1
|
2
|
1
|
1
|
1,26
|
0,20
|
|
|
|
|
|
B6
|
1
|
2
|
1
|
2
|
1
|
1
|
1,26
|
0,20
|
|
|
|
|
|
A12
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
2
|
1
|
2
|
1
|
1,51
|
0,23
|
|
6,0257
|
0,0051
|
0,0041
|
|
B2
|
1/3
|
1
|
1
|
1/3
|
1
|
1/2
|
0,62
|
0,10
|
|
|
|
|
|
B3
|
1/2
|
1
|
1
|
1/2
|
1
|
1/2
|
0,71
|
0,11
|
|
|
|
|
|
B4
|
1
|
3
|
2
|
1
|
2
|
1
|
1,51
|
0,23
|
|
|
|
|
|
B5
|
1/2
|
1
|
1
|
1/2
|
1
|
1/2
|
0,71
|
0,11
|
|
|
|
|
|
B6
|
1
|
2
|
2
|
1
|
2
|
1
|
1,41
|
0,22
|
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вектор
|
Норм вектор
|
λmax
|
CI
|
CR
|
|
A1
|
1
|
1
|
3
|
3
|
1/5
|
1/8
|
1/8
|
2
|
1/5
|
1/5
|
1
|
1/4
|
0,54
|
0,04
|
13,1987
|
0,1090
|
0,0736
|
|
A2
|
1
|
1
|
2
|
1/3
|
1/5
|
1/7
|
1/8
|
1/3
|
1/5
|
1/5
|
1/4
|
1/2
|
0,35
|
0,02
|
|
|
|
|
A3
|
1/3
|
1/2
|
1
|
1/3
|
1/5
|
1/7
|
1/7
|
1
|
1/5
|
1/5
|
1/4
|
1/4
|
0,30
|
0,02
|
|
|
|
|
A4
|
1/3
|
3
|
3
|
1
|
1/4
|
1/5
|
1/5
|
1/2
|
1/5
|
1/4
|
1/4
|
1/4
|
0,44
|
0,03
|
|
|
|
|
A5
|
5
|
5
|
5
|
4
|
1
|
1
|
1
|
1
|
1/3
|
1/2
|
1/3
|
2
|
1,40
|
0,09
|
|
|
|
|
A6
|
8
|
7
|
7
|
5
|
1
|
1
|
1
|
1
|
1/2
|
1/2
|
1/2
|
2
|
1,68
|
0,11
|
|
|
|
|
A7
|
8
|
8
|
7
|
5
|
1
|
1
|
1
|
1
|
1/2
|
1/2
|
1/2
|
2
|
1,69
|
0,11
|
|
|
|
|
A8
|
1/2
|
3
|
1
|
2
|
1
|
1
|
1
|
1
|
1/3
|
1/3
|
1
|
1
|
0,91
|
0,06
|
|
|
|
|
A9
|
5
|
5
|
5
|
5
|
3
|
2
|
2
|
3
|
1
|
2
|
2
|
2
|
2,74
|
0,18
|
|
|
|
|
A10
|
5
|
5
|
5
|
4
|
2
|
2
|
2
|
3
|
1/2
|
1
|
2
|
2
|
2,32
|
0,15
|
|
|
|
|
A11
|
1
|
4
|
4
|
4
|
3
|
2
|
2
|
1
|
1/2
|
1/2
|
1
|
2
|
1,64
|
0,11
|
|
|
|
|
A12
|
4
|
2
|
4
|
4
|
1/2
|
1/2
|
1/2
|
1
|
1/2
|
1/2
|
1/2
|
1
|
1,06
|
0,07
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вес
|
|
B1
|
0,39
|
0,01
|
0,06
|
0,23
|
0,12
|
0,24
|
0,06
|
0,07
|
0,04
|
0,06
|
0,18
|
0,23
|
0,12
|
|
B2
|
0,03
|
0,06
|
0,04
|
0,03
|
0,05
|
0,04
|
0,04
|
0,23
|
0,06
|
0,09
|
0,10
|
0,09
|
|
B3
|
0,14
|
0,31
|
0,24
|
0,33
|
0,30
|
0,35
|
0,33
|
0,29
|
0,16
|
0,25
|
0,24
|
0,11
|
0,25
|
|
B4
|
0,09
|
0,33
|
0,26
|
0,23
|
0,04
|
0,25
|
0,04
|
0,29
|
0,21
|
0,25
|
0,10
|
0,23
|
0,18
|
|
B5
|
0,28
|
0,29
|
0,26
|
0,03
|
0,33
|
0,04
|
0,32
|
0,29
|
0,24
|
0,25
|
0,20
|
0,11
|
0,22
|
|
B6
|
0,08
|
0,03
|
0,12
|
0,14
|
0,17
|
0,08
|
0,22
|
0,03
|
0,11
|
0,14
|
0,20
|
0,22
|
0,14
|
ПРИЛОЖЕНИЕ
3
Сравнительный анализ методик экспертом 2
|
A1
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
2
|
1
|
1/3
|
1
|
1,12
|
0,18
|
|
6,4893
|
0,0979
|
0,0789
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
1/2
|
1
|
0,51
|
0,08
|
|
|
|
|
|
B3
|
1/2
|
3
|
1
|
1
|
1
|
1
|
1,07
|
0,17
|
|
|
|
|
|
B4
|
1
|
3
|
1
|
1
|
1/2
|
1/2
|
0,95
|
0,15
|
|
|
|
|
|
B5
|
3
|
2
|
1
|
2
|
1
|
1
|
1,51
|
0,24
|
|
|
|
|
|
B6
|
1
|
1
|
1
|
2
|
1
|
1
|
1,12
|
0,18
|
|
|
|
|
|
A2
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
1
|
1
|
3
|
1/3
|
1,26
|
0,19
|
|
6,5902
|
0,1180
|
0,0952
|
|
B2
|
1/4
|
1
|
1/4
|
1/4
|
1/2
|
1/2
|
0,40
|
0,06
|
|
|
|
|
|
B3
|
1
|
4
|
1
|
1
|
3
|
2
|
1,70
|
0,25
|
|
|
|
|
|
B4
|
1
|
4
|
1
|
1
|
3
|
2
|
1,70
|
0,25
|
|
|
|
|
|
B5
|
1/3
|
2
|
1/3
|
1/3
|
1
|
2
|
0,73
|
0,11
|
|
|
|
|
|
B6
|
3
|
2
|
1/2
|
1/2
|
1/2
|
1
|
0,95
|
0,14
|
|
|
|
|
|
A3
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1
|
3
|
3
|
1/2
|
1,44
|
0,23
|
|
6,5656
|
0,1131
|
0,0912
|
|
B2
|
1/2
|
1
|
1/2
|
1
|
1
|
1/2
|
0,71
|
0,11
|
|
|
|
|
|
B3
|
1
|
2
|
1
|
1
|
2
|
2
|
1,41
|
0,22
|
|
|
|
|
|
B4
|
1/3
|
1
|
1
|
1
|
3
|
2
|
1,12
|
0,18
|
|
|
|
|
|
B5
|
1/3
|
1
|
1/2
|
1/3
|
1
|
1/2
|
0,55
|
0,09
|
|
|
|
|
|
B6
|
2
|
2
|
1/2
|
1/2
|
2
|
1
|
1,12
|
0,18
|
|
|
|
|
|
A4
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/2
|
1
|
5
|
1
|
1,40
|
0,21
|
|
6,4710
|
0,0942
|
0,0760
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
1/4
|
1/4
|
0,36
|
0,05
|
|
|
|
|
|
B3
|
2
|
3
|
1
|
3
|
2
|
2
|
2,04
|
0,30
|
|
|
|
|
|
B4
|
1
|
3
|
1/3
|
1
|
1
|
1
|
1,00
|
0,15
|
|
|
|
|
|
B5
|
1/5
|
4
|
1/2
|
1
|
1
|
1
|
0,86
|
0,13
|
|
|
|
|
|
B6
|
1
|
4
|
1/2
|
1
|
1
|
1
|
1,12
|
0,17
|
|
|
|
|
|
A5
|
B1
|
B2
|
B3
|
B4
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
4
|
3
|
3
|
1/4
|
1,82
|
0,23
|
|
6,4947
|
0,0989
|
0,0798
|
|
B2
|
1/4
|
1
|
1/2
|
1/3
|
1/3
|
1/4
|
0,39
|
0,05
|
|
|
|
|
|
B3
|
1/4
|
2
|
1
|
1/2
|
1/3
|
1/5
|
0,51
|
0,06
|
|
|
|
|
|
B4
|
1/3
|
3
|
2
|
1
|
1
|
1/5
|
0,86
|
0,11
|
|
|
|
|
|
B5
|
1/3
|
3
|
3
|
1
|
1
|
1/5
|
0,92
|
0,11
|
|
|
|
|
|
B6
|
4
|
4
|
5
|
5
|
5
|
1
|
3,55
|
0,44
|
|
|
|
|
|
A6
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
4
|
1/3
|
5
|
1/5
|
1,32
|
0,16
|
|
6,4958
|
0,0992
|
0,0800
|
|
B2
|
1/4
|
1
|
1/3
|
1/5
|
1
|
1/5
|
0,39
|
0,05
|
|
|
|
|
|
B3
|
1/4
|
3
|
1
|
1/4
|
3
|
1/4
|
0,72
|
0,09
|
|
|
|
|
|
B4
|
3
|
5
|
4
|
1
|
6
|
1/2
|
2,38
|
0,28
|
|
|
|
|
|
B5
|
1/5
|
1
|
1/3
|
1/6
|
1
|
1/6
|
0,35
|
0,04
|
|
|
|
|
|
B6
|
5
|
5
|
4
|
2
|
6
|
1
|
3,26
|
0,39
|
|
|
|
|
|
A7
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1
|
1/3
|
1
|
1
|
1/5
|
0,64
|
0,08
|
|
6,2502
|
0,0500
|
0,0404
|
|
B2
|
1
|
1
|
1/5
|
1
|
1
|
1/4
|
0,61
|
0,08
|
|
|
|
|
|
B3
|
3
|
5
|
1
|
5
|
5
|
3
|
3,22
|
0,43
|
|
|
|
|
|
B4
|
1
|
1
|
1/5
|
1
|
1
|
1/2
|
0,68
|
0,09
|
|
|
|
|
|
B5
|
1
|
1
|
1/5
|
1
|
1
|
1/2
|
0,68
|
0,09
|
|
|
|
|
|
B6
|
5
|
4
|
1/3
|
2
|
2
|
1
|
1,73
|
0,23
|
|
|
|
|
|
A8
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/3
|
1/3
|
1/3
|
2
|
0,73
|
0,10
|
|
6,5289
|
0,1058
|
0,0853
|
|
B2
|
1/2
|
1
|
1/3
|
1/3
|
1/3
|
1/4
|
0,41
|
0,06
|
|
|
|
|
|
B3
|
3
|
3
|
1
|
3
|
3
|
2
|
2,33
|
0,33
|
|
|
|
|
|
B4
|
3
|
3
|
1/3
|
1
|
1
|
3
|
1,44
|
0,21
|
|
|
|
|
|
B5
|
3
|
3
|
1/3
|
1
|
1
|
2
|
1,35
|
0,19
|
|
|
|
|
|
B6
|
1/2
|
4
|
1/2
|
1/3
|
1/2
|
1
|
0,74
|
0,11
|
|
|
|
|
|
A9
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/3
|
1/3
|
1/3
|
1/3
|
0,54
|
0,08
|
|
6,1043
|
0,0209
|
0,0168
|
|
B2
|
1/2
|
1
|
1/3
|
1/3
|
1/3
|
1/2
|
0,46
|
0,07
|
|
|
|
|
|
B3
|
3
|
3
|
1
|
1
|
1
|
2
|
1,62
|
0,24
|
|
|
|
|
|
B4
|
3
|
3
|
1
|
1
|
1
|
1
|
1,44
|
0,22
|
|
|
|
|
|
B5
|
3
|
3
|
1
|
1
|
1
|
1
|
1,44
|
0,22
|
|
|
|
|
|
B6
|
3
|
2
|
1/2
|
1
|
1
|
1
|
1,20
|
0,18
|
|
|
|
|
|
A10
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
|
B1
|
1
|
1
|
1
|
2
|
3
|
2
|
1,51
|
0,24
|
|
6,5811
|
0,1162
|
0,0937
|
|
B2
|
1
|
1
|
1/3
|
1/2
|
1
|
1/3
|
0,62
|
0,10
|
|
|
|
|
|
B3
|
1
|
3
|
1
|
1
|
1
|
3
|
1,44
|
0,22
|
|
|
|
|
|
B4
|
1/2
|
2
|
1
|
1
|
2
|
3
|
1,35
|
0,21
|
|
|
|
|
|
B5
|
1/3
|
1
|
1
|
1/2
|
1
|
3
|
0,89
|
0,14
|
|
|
|
|
|
B6
|
1/2
|
3
|
1/3
|
1/3
|
1/3
|
1
|
0,62
|
0,10
|
|
|
|
|
|
A11
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1
|
1/2
|
2
|
1/2
|
1,00
|
0,16
|
|
6,2819
|
0,0564
|
0,0455
|
|
B2
|
1/2
|
1
|
1/2
|
1
|
2
|
1
|
0,89
|
0,14
|
|
|
|
|
|
B3
|
1
|
2
|
1
|
1
|
2
|
1
|
1,26
|
0,20
|
|
|
|
|
|
B4
|
2
|
1
|
1
|
1
|
2
|
2
|
1,41
|
0,23
|
|
|
|
|
|
B5
|
1/2
|
1/2
|
1/2
|
1/2
|
1
|
1/2
|
0,56
|
0,09
|
|
|
|
|
|
B6
|
2
|
1
|
1
|
1/2
|
2
|
1
|
1,12
|
0,18
|
|
|
|
|
|
A12
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
3
|
1
|
1
|
1,44
|
0,23
|
|
6,5314
|
0,1063
|
0,0857
|
|
B2
|
1/3
|
1
|
2
|
3
|
1
|
1
|
1,12
|
0,18
|
|
|
|
|
|
B3
|
1
|
1/2
|
1
|
1
|
2
|
2
|
1,12
|
0,18
|
|
|
|
|
|
B4
|
1/3
|
1/3
|
1
|
1
|
1/2
|
1/2
|
0,55
|
0,09
|
|
|
|
|
|
B5
|
1
|
1
|
1/2
|
2
|
1
|
1
|
1,00
|
0,16
|
|
|
|
|
|
B6
|
1
|
1
|
1/2
|
2
|
1
|
1
|
1,00
|
0,16
|
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вектор
|
Норм. вектор
|
λmax
|
CI
|
CR
|
|
A1
|
1
|
2
|
1
|
2
|
1/5
|
1/6
|
1/6
|
1/3
|
1/4
|
1/4
|
1
|
2
|
0,56
|
0,04
|
12,5945
|
0,0540
|
0,0365
|
|
A2
|
1/2
|
1
|
1
|
1/2
|
1/5
|
1/5
|
1/5
|
1/3
|
1/4
|
1/5
|
1/3
|
1/2
|
0,36
|
0,02
|
|
|
|
|
A3
|
1
|
1
|
1
|
1
|
1/6
|
1/6
|
1/6
|
1/3
|
1/4
|
1/5
|
1/4
|
1/2
|
0,38
|
0,02
|
|
|
|
|
A4
|
1/2
|
2
|
1
|
1
|
1/5
|
1/5
|
1/5
|
1/4
|
1/4
|
1/4
|
1/3
|
1/3
|
0,39
|
0,03
|
|
|
|
|
A5
|
5
|
5
|
6
|
5
|
1
|
1
|
1
|
3
|
1/2
|
1
|
2
|
3
|
2,09
|
0,14
|
|
|
|
|
A6
|
6
|
5
|
6
|
5
|
1
|
1
|
1
|
3
|
1/2
|
1
|
2
|
3
|
2,12
|
0,14
|
|
|
|
|
A7
|
6
|
5
|
6
|
5
|
1
|
1
|
1
|
3
|
1/2
|
1
|
2
|
3
|
2,12
|
0,14
|
|
|
|
|
A8
|
3
|
3
|
3
|
4
|
1/3
|
1/3
|
1/3
|
1
|
1/2
|
1/4
|
1
|
2
|
1,00
|
0,07
|
|
|
|
|
A9
|
4
|
4
|
4
|
4
|
2
|
2
|
2
|
2
|
1
|
1
|
2
|
2
|
2,24
|
|
|
|
|
A10
|
4
|
5
|
5
|
4
|
1
|
1
|
1
|
4
|
1
|
1
|
4
|
5
|
2,37
|
0,16
|
|
|
|
|
A11
|
1
|
3
|
4
|
3
|
1/2
|
1/2
|
1/2
|
1
|
1/2
|
1/4
|
1
|
3
|
1,04
|
0,07
|
|
|
|
|
A12
|
1/2
|
2
|
2
|
3
|
1/3
|
1/3
|
1/3
|
1/2
|
1/2
|
1/5
|
1/3
|
1
|
0,63
|
0,04
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вес
|
|
B1
|
0,18
|
0,19
|
0,23
|
0,21
|
0,23
|
0,16
|
0,08
|
0,10
|
0,08
|
0,24
|
0,16
|
0,23
|
0,16
|
|
B2
|
0,08
|
0,06
|
0,11
|
0,05
|
0,05
|
0,05
|
0,08
|
0,06
|
0,07
|
0,10
|
0,14
|
0,18
|
0,08
|
|
B3
|
0,17
|
0,25
|
0,22
|
0,30
|
0,06
|
0,09
|
0,43
|
0,33
|
0,24
|
0,22
|
0,20
|
0,18
|
0,22
|
|
B4
|
0,15
|
0,25
|
0,18
|
0,15
|
0,11
|
0,28
|
0,09
|
0,21
|
0,22
|
0,21
|
0,23
|
0,09
|
0,18
|
|
B5
|
0,24
|
0,11
|
0,09
|
0,13
|
0,11
|
0,04
|
0,09
|
0,19
|
0,22
|
0,14
|
0,09
|
0,16
|
0,13
|
|
B6
|
0,18
|
0,14
|
0,18
|
0,17
|
0,44
|
0,39
|
0,23
|
0,11
|
0,18
|
0,10
|
0,18
|
0,16
|
0,23
|
ПРИЛОЖЕНИЕ
4
Сравнительный анализ методик экспертом 3
|
A1
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
2
|
2
|
1
|
1/3
|
1,26
|
0,19
|
6,4829
|
0,0966
|
0,0779
|
|
B2
|
1/3
|
1
|
1/4
|
1/3
|
1/2
|
1/2
|
0,44
|
0,07
|
|
|
|
|
B3
|
1/2
|
4
|
1
|
3
|
1
|
1
|
1,35
|
0,21
|
|
|
|
|
B4
|
1/2
|
3
|
1/3
|
1
|
1/2
|
1/2
|
0,71
|
0,11
|
|
|
|
|
B5
|
1
|
2
|
1
|
2
|
1
|
1/2
|
1,12
|
0,17
|
|
|
|
|
B6
|
3
|
2
|
1
|
2
|
2
|
1
|
1,70
|
0,26
|
|
|
|
|
A2
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
3
|
2
|
2
|
4
|
2,40
|
0,35
|
6,2179
|
0,0436
|
0,0351
|
|
B2
|
1/4
|
1
|
1/3
|
1/4
|
1/2
|
1/2
|
0,42
|
0,06
|
|
|
|
|
B3
|
1/3
|
3
|
1
|
1
|
1/2
|
2
|
1,00
|
0,14
|
|
|
|
|
B4
|
1/2
|
4
|
1
|
1
|
2
|
2
|
1,41
|
0,20
|
|
|
|
|
B5
|
1/2
|
2
|
2
|
1/2
|
1
|
1
|
1,00
|
0,14
|
|
|
|
|
B6
|
1/4
|
2
|
1/2
|
1/2
|
1
|
1
|
0,71
|
0,10
|
|
|
|
|
A3
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
1
|
2
|
2
|
1,51
|
0,24
|
6,4913
|
0,0983
|
0,0792
|
|
B2
|
1/3
|
1
|
1
|
2
|
2
|
1
|
1,05
|
0,17
|
|
|
|
|
B3
|
1
|
1
|
1
|
1
|
1
|
3
|
1,20
|
0,19
|
|
|
|
|
B4
|
1
|
1/2
|
1
|
1
|
2
|
3
|
1,20
|
0,19
|
|
|
|
|
B5
|
1/2
|
1/2
|
1
|
1/2
|
1
|
3
|
0,85
|
0,13
|
|
|
|
|
B6
|
1/2
|
1
|
1/3
|
1/3
|
1/3
|
1
|
0,51
|
|
|
|
|
A4
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/3
|
2
|
4
|
1
|
1,41
|
0,20
|
6,3820
|
0,0764
|
0,0616
|
|
B2
|
1/3
|
1
|
1/4
|
1/4
|
1/4
|
1/4
|
0,33
|
0,05
|
|
|
|
|
B3
|
3
|
4
|
1
|
3
|
3
|
3
|
2,62
|
0,36
|
|
|
|
|
B4
|
1/2
|
4
|
1/3
|
1
|
1
|
1
|
0,93
|
0,13
|
|
|
|
|
B5
|
1/4
|
4
|
1/3
|
1
|
1
|
1
|
0,83
|
0,12
|
|
|
|
|
B6
|
1
|
4
|
1/3
|
1
|
1
|
1
|
1,05
|
0,15
|
|
|
|
|
A5
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
4
|
1/2
|
1
|
1/7
|
0,97
|
0,11
|
6,5754
|
0,1151
|
0,0928
|
|
B2
|
1/3
|
1
|
1/2
|
1/5
|
1/4
|
1/5
|
0,34
|
0,04
|
|
|
|
|
B3
|
1/4
|
2
|
1
|
1/3
|
1/4
|
1/7
|
0,43
|
0,05
|
|
|
|
|
B4
|
2
|
5
|
3
|
1
|
1
|
1/5
|
1,35
|
0,15
|
|
|
|
|
B5
|
1
|
4
|
4
|
1
|
1
|
1/7
|
1,15
|
0,13
|
|
|
|
|
B6
|
7
|
5
|
7
|
5
|
7
|
1
|
4,52
|
0,52
|
|
|
|
|
A6
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
3
|
1/2
|
6
|
1/2
|
1,54
|
0,19
|
6,1865
|
0,0373
|
0,0301
|
|
B2
|
1/3
|
1
|
1/4
|
1/6
|
1
|
1/4
|
0,39
|
0,05
|
|
|
|
|
B3
|
1/3
|
4
|
1
|
1/3
|
3
|
1/4
|
0,83
|
0,10
|
|
|
|
|
B4
|
2
|
6
|
3
|
1
|
6
|
1
|
2,45
|
0,31
|
|
|
|
|
B5
|
1/6
|
1
|
1/3
|
1/6
|
1
|
1/6
|
0,34
|
0,04
|
|
|
|
|
B6
|
2
|
4
|
4
|
1
|
6
|
1
|
2,40
|
0,30
|
|
|
|
|
A7
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/4
|
1/2
|
2
|
1/3
|
0,74
|
0,10
|
6,5445
|
0,1089
|
0,0878
|
|
B2
|
1/2
|
1
|
1/4
|
1/4
|
1/4
|
1/5
|
0,34
|
0,05
|
|
|
|
|
B3
|
4
|
4
|
1
|
1/2
|
4
|
3
|
2,14
|
0,30
|
|
|
|
|
B4
|
2
|
4
|
2
|
1
|
2
|
2
|
2,00
|
0,28
|
|
|
|
|
B5
|
1/2
|
4
|
1/4
|
1/2
|
1
|
1/2
|
0,71
|
0,10
|
|
|
|
|
B6
|
3
|
5
|
1/3
|
1/2
|
2
|
1
|
1,31
|
0,18
|
|
|
|
|
A8
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
1/2
|
1/2
|
3
|
2
|
1,35
|
0,19
|
6,5664
|
0,1133
|
0,0914
|
|
B2
|
1/4
|
1
|
1/3
|
1/3
|
2
|
1
|
0,62
|
0,09
|
|
|
|
|
B3
|
2
|
3
|
1
|
1
|
3
|
2
|
1,82
|
0,26
|
|
|
|
|
B4
|
2
|
3
|
1
|
1
|
3
|
2
|
1,82
|
0,26
|
|
|
|
|
B5
|
1/3
|
1/2
|
1/3
|
1/3
|
1
|
1/3
|
0,43
|
0,06
|
|
|
|
|
B6
|
2
|
1
|
1/2
|
1/2
|
3
|
1
|
1,07
|
0,15
|
|
|
|
|
A9
|
B1
|
B2
|
B3
|
B4
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/2
|
1/2
|
3
|
1/2
|
1,02
|
0,14
|
6,6027
|
0,1205
|
0,0972
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
1
|
1/2
|
0,51
|
0,07
|
|
|
|
|
B3
|
2
|
3
|
1
|
1
|
2
|
1
|
1,51
|
0,21
|
|
|
|
|
B4
|
2
|
3
|
1
|
1
|
3
|
2
|
1,82
|
0,26
|
|
|
|
|
B5
|
1/3
|
1
|
1/2
|
1/2
|
1
|
1/3
|
0,55
|
0,08
|
|
|
|
|
B6
|
2
|
2
|
1
|
2
|
3
|
1
|
1,70
|
0,24
|
|
|
|
|
A10
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/2
|
1
|
3
|
3
|
1,54
|
0,21
|
6,1218
|
0,0244
|
0,0196
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
1
|
1
|
0,58
|
0,08
|
|
|
|
|
B3
|
2
|
3
|
1
|
3
|
5
|
5
|
2,77
|
0,37
|
|
|
|
|
B4
|
1
|
3
|
1/3
|
1
|
3
|
3
|
1,44
|
0,20
|
|
|
|
|
B5
|
1/3
|
1
|
1/5
|
1/3
|
1
|
1
|
0,53
|
0,07
|
|
|
|
|
B6
|
1/3
|
1
|
1/5
|
1/3
|
1
|
1
|
0,53
|
0,07
|
|
|
|
|
A11
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1/3
|
1/3
|
1/2
|
1
|
1/2
|
0,55
|
0,08
|
6,5090
|
0,1018
|
0,0821
|
|
B2
|
3
|
1
|
1/3
|
1/3
|
1/2
|
1/3
|
0,62
|
0,09
|
|
|
|
|
B3
|
3
|
3
|
1
|
2
|
3
|
4
|
2,45
|
0,34
|
|
|
|
|
B4
|
2
|
3
|
1/2
|
1
|
3
|
2
|
1,62
|
0,23
|
|
|
|
|
B5
|
1
|
2
|
1/3
|
1/3
|
1
|
1/2
|
0,69
|
0,10
|
|
|
|
|
B6
|
2
|
3
|
1/2
|
1/2
|
2
|
1
|
1,20
|
0,17
|
|
|
|
|
A12
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1
|
2
|
3
|
1
|
1
|
1,35
|
0,22
|
6,4142
|
0,0828
|
0,0668
|
|
B2
|
1
|
1
|
2
|
2
|
1
|
1
|
1,26
|
0,20
|
|
|
|
|
B3
|
1/2
|
1/2
|
1
|
1
|
1/2
|
1/2
|
0,63
|
0,10
|
|
|
|
|
B4
|
1/3
|
1/2
|
1
|
1
|
2
|
2
|
0,93
|
0,15
|
|
|
|
|
B5
|
1
|
1
|
2
|
1/2
|
1
|
1
|
1,00
|
0,16
|
|
|
|
|
B6
|
1
|
1
|
2
|
1/2
|
1
|
1
|
1,00
|
0,16
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вектор
|
Норм. вектор
|
λmax
|
CI
|
CR
|
|
A1
|
1
|
1
|
1
|
1
|
1/4
|
1/4
|
1/4
|
1
|
1/3
|
1/5
|
1
|
1
|
0,56
|
0,04
|
12,8284
|
0,0753
|
0,0509
|
|
A2
|
1
|
1
|
2
|
2
|
1/4
|
1/4
|
1/4
|
1/3
|
1/4
|
1/4
|
1/2
|
1
|
0,54
|
0,04
|
|
|
|
|
A3
|
1
|
1/2
|
1
|
2
|
1/4
|
1/4
|
1/4
|
1
|
1/4
|
1/4
|
1/3
|
1/3
|
0,47
|
0,03
|
|
|
|
|
A4
|
1
|
1/2
|
1/2
|
1
|
1/3
|
1/4
|
1/4
|
1
|
1/3
|
1/4
|
1
|
1/2
|
0,50
|
|
|
|
|
A5
|
4
|
4
|
4
|
3
|
1
|
1/2
|
1/2
|
4
|
1/2
|
1/3
|
2
|
2
|
1,50
|
0,11
|
|
|
|
|
A6
|
4
|
4
|
4
|
4
|
2
|
1
|
2
|
2
|
1
|
1/2
|
3
|
2
|
2,07
|
0,15
|
|
|
|
|
A7
|
4
|
4
|
4
|
4
|
2
|
1/2
|
1
|
1
|
1/3
|
1/3
|
1
|
1
|
1,32
|
0,09
|
|
|
|
|
A8
|
1
|
3
|
1
|
1
|
1/4
|
1/2
|
1
|
1
|
1/2
|
1/4
|
2
|
1/2
|
0,77
|
0,06
|
|
|
|
|
A9
|
3
|
4
|
4
|
3
|
2
|
1
|
3
|
2
|
1
|
1
|
1
|
1
|
1,86
|
0,13
|
|
|
|
|
A10
|
5
|
4
|
4
|
4
|
3
|
2
|
3
|
4
|
1
|
1
|
2
|
2
|
2,59
|
0,19
|
|
|
|
|
A11
|
1
|
2
|
3
|
1
|
1/2
|
1/3
|
1
|
1/2
|
1
|
1/2
|
1
|
1
|
0,89
|
0,06
|
|
|
|
|
A12
|
1
|
1
|
3
|
2
|
1/2
|
1/2
|
1
|
2
|
1
|
0
|
1
|
1
|
0,89
|
0,06
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вес
|
|
B1
|
0,19
|
0,35
|
0,24
|
0,20
|
0,11
|
0,19
|
0,10
|
0,19
|
0,14
|
0,21
|
0,08
|
0,22
|
0,17
|
|
B2
|
0,07
|
0,06
|
0,17
|
0,05
|
0,04
|
0,05
|
0,05
|
0,09
|
0,07
|
0,08
|
0,09
|
0,20
|
0,08
|
|
B3
|
0,21
|
0,14
|
0,19
|
0,36
|
0,05
|
0,10
|
0,30
|
0,26
|
0,21
|
0,37
|
0,34
|
0,10
|
0,22
|
|
B4
|
0,11
|
0,20
|
0,19
|
0,13
|
0,15
|
0,31
|
0,28
|
0,26
|
0,26
|
0,20
|
0,23
|
0,15
|
0,22
|
|
B5
|
0,17
|
0,14
|
0,13
|
0,12
|
0,13
|
0,04
|
0,10
|
0,06
|
0,08
|
0,07
|
0,10
|
0,16
|
0,09
|
|
B6
|
0,26
|
0,10
|
0,08
|
0,15
|
0,52
|
0,30
|
0,18
|
0,15
|
0,24
|
0,07
|
0,17
|
0,16
|
0,21
|
ПРИЛОЖЕНИЕ
5
Сравнительный анализ методик экспертом 4
|
A1
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм. вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
2
|
1
|
1
|
1,35
|
0,21
|
6,0818
|
0,0164
|
0,0132
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
1/3
|
1/3
|
0,40
|
0,06
|
|
|
|
|
B3
|
1
|
3
|
1
|
2
|
1
|
1
|
1,35
|
0,21
|
|
|
|
|
B4
|
1/2
|
3
|
1/2
|
1
|
1
|
1
|
0,95
|
0,15
|
|
|
|
|
B5
|
1
|
3
|
1
|
1
|
1
|
1
|
1,20
|
0,19
|
|
|
|
|
B6
|
1
|
3
|
1
|
1
|
1
|
1
|
1,20
|
0,19
|
|
|
|
|
A2
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/5
|
1/5
|
1/5
|
3
|
0,60
|
0,08
|
6,2357
|
0,0471
|
0,0380
|
|
B2
|
1/2
|
1
|
1/4
|
1/4
|
1/3
|
1
|
0,47
|
0,06
|
|
|
|
|
B3
|
5
|
4
|
1
|
1
|
1
|
5
|
2,15
|
0,28
|
|
|
|
|
B4
|
5
|
4
|
1
|
1
|
2
|
4
|
2,33
|
0,30
|
|
|
|
|
B5
|
5
|
3
|
1
|
1/2
|
1
|
4
|
1,76
|
0,23
|
|
|
|
|
B6
|
1/3
|
1/5
|
1/4
|
1/4
|
1
|
0,40
|
0,05
|
|
|
|
|
A3
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/4
|
1/4
|
1/3
|
1/2
|
0,52
|
0,08
|
6,1334
|
0,0267
|
0,0215
|
|
B2
|
1/2
|
1
|
1/2
|
1/2
|
1/2
|
1
|
0,63
|
0,09
|
|
|
|
|
B3
|
4
|
2
|
1
|
1
|
1
|
2
|
1,59
|
0,24
|
|
|
|
|
B4
|
4
|
2
|
1
|
1
|
1
|
2
|
1,59
|
0,24
|
|
|
|
|
B5
|
3
|
2
|
1
|
1
|
1
|
2
|
1,51
|
0,23
|
|
|
|
|
B6
|
2
|
1
|
1/2
|
1/2
|
1/2
|
1
|
0,79
|
0,12
|
|
|
|
|
A4
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
5
|
1/5
|
2
|
4
|
2
|
1,59
|
0,22
|
6,6095
|
0,1219
|
0,0983
|
|
B2
|
1/5
|
1
|
1/6
|
1/2
|
1/3
|
1
|
0,42
|
0,06
|
|
|
|
|
B3
|
5
|
6
|
1
|
2
|
3
|
3
|
2,85
|
0,39
|
|
|
|
|
B4
|
1/2
|
2
|
1/2
|
1
|
2
|
1
|
1,00
|
0,14
|
|
|
|
|
B5
|
1/4
|
3
|
1/3
|
1/2
|
1
|
1
|
0,71
|
0,10
|
|
|
|
|
B6
|
1/2
|
1
|
1/3
|
1
|
1
|
1
|
0,74
|
0,10
|
|
|
|
|
A5
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1/3
|
1/3
|
1/2
|
1/3
|
1/3
|
0,43
|
0,06
|
6,5418
|
0,1084
|
0,0874
|
|
B2
|
3
|
1
|
1
|
1/3
|
1/4
|
1/5
|
0,61
|
0,08
|
|
|
|
|
B3
|
3
|
1
|
1
|
1/3
|
1/4
|
1/5
|
0,61
|
0,08
|
|
|
|
|
B4
|
2
|
3
|
3
|
1
|
2
|
1/2
|
1,62
|
0,22
|
|
|
|
|
B5
|
3
|
4
|
4
|
1/2
|
1
|
1/4
|
1,35
|
0,18
|
|
|
|
|
B6
|
3
|
5
|
5
|
2
|
4
|
1
|
2,90
|
0,39
|
|
|
|
|
A6
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
5
|
5
|
1/3
|
5
|
1/3
|
1,55
|
0,20
|
6,4439
|
0,0888
|
0,0716
|
|
B2
|
1/5
|
1
|
1
|
1/4
|
1
|
1/4
|
0,48
|
0,06
|
|
|
|
|
B3
|
1/5
|
1
|
1
|
1/3
|
1
|
1/3
|
0,53
|
0,07
|
|
|
|
|
B4
|
3
|
4
|
3
|
1
|
4
|
1
|
2,29
|
0,30
|
|
|
|
|
B5
|
1/5
|
1
|
1
|
1/4
|
1
|
1/4
|
0,48
|
0,06
|
|
|
|
|
B6
|
3
|
4
|
3
|
1
|
4
|
1
|
2,29
|
0,30
|
|
|
|
|
A7
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/5
|
2
|
1/3
|
1/3
|
0,67
|
0,08
|
6,5156
|
0,1031
|
0,0832
|
|
B2
|
1/2
|
1
|
1/5
|
1/3
|
1/3
|
1/3
|
0,39
|
0,05
|
|
|
|
|
B3
|
5
|
5
|
1
|
5
|
5
|
4
|
3,68
|
0,47
|
|
|
|
|
B4
|
1/2
|
3
|
1/5
|
1
|
1/2
|
2
|
0,82
|
0,10
|
|
|
|
|
B5
|
3
|
3
|
1/5
|
2
|
1
|
2
|
1,39
|
0,18
|
|
|
|
|
B6
|
3
|
3
|
1/4
|
1/2
|
1/2
|
1
|
0,91
|
|
|
|
|
A8
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1/2
|
1/3
|
1/3
|
2
|
0,83
|
0,12
|
6,1056
|
0,0211
|
0,0170
|
|
B2
|
1/3
|
1
|
1/5
|
1/5
|
1/5
|
1/2
|
0,33
|
0,05
|
|
|
|
|
B3
|
2
|
5
|
1
|
1
|
1
|
2
|
1,65
|
0,23
|
|
|
|
|
B4
|
3
|
5
|
1
|
1
|
1
|
2
|
1,76
|
0,25
|
|
|
|
|
B5
|
3
|
5
|
1
|
1
|
1
|
2
|
1,76
|
0,25
|
|
|
|
|
B6
|
1/2
|
2
|
1/2
|
1/2
|
1/2
|
1
|
0,71
|
0,10
|
|
|
|
|
A9
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
1
|
3
|
1/3
|
1,20
|
0,18
|
6,4198
|
0,0840
|
0,0677
|
|
B2
|
1/3
|
1
|
1/2
|
1/3
|
2
|
1/2
|
0,62
|
0,09
|
|
|
|
|
B3
|
1
|
2
|
1
|
1
|
3
|
2
|
1,51
|
0,23
|
|
|
|
|
B4
|
1
|
3
|
1
|
1
|
3
|
2
|
1,62
|
0,24
|
|
|
|
|
B5
|
1/3
|
1/2
|
1/3
|
1/3
|
1
|
1/2
|
0,46
|
0,07
|
|
|
|
|
B6
|
3
|
2
|
1/2
|
1/2
|
2
|
1
|
1,20
|
0,18
|
|
|
|
|
A10
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
5
|
1/3
|
2
|
4
|
4
|
1,94
|
0,26
|
6,4356
|
0,0871
|
0,0703
|
|
B2
|
1/5
|
1
|
1/2
|
1/2
|
1
|
1
|
0,61
|
0,08
|
|
|
|
|
B3
|
3
|
2
|
1
|
2
|
5
|
5
|
2,59
|
0,34
|
|
|
|
|
B4
|
1/2
|
2
|
1/2
|
1
|
4
|
4
|
1,41
|
0,19
|
|
|
|
|
B5
|
1/4
|
1
|
1/5
|
1/4
|
1
|
1
|
0,48
|
0,06
|
|
|
|
|
B6
|
1/4
|
1
|
1/5
|
1/4
|
1
|
1
|
0,48
|
0,06
|
|
|
|
|
A11
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/3
|
1/2
|
2
|
1
|
0,93
|
0,14
|
6,3486
|
0,0697
|
0,0562
|
|
B2
|
1/2
|
1
|
1/2
|
1/3
|
1/2
|
1/3
|
0,49
|
0,07
|
|
|
|
|
B3
|
3
|
2
|
1
|
1
|
3
|
3
|
1,94
|
0,30
|
|
|
|
|
B4
|
2
|
3
|
1
|
1
|
1
|
1
|
1,35
|
0,21
|
|
|
|
|
B5
|
1/2
|
2
|
1/3
|
1
|
1
|
1
|
0,83
|
0,13
|
|
|
|
|
B6
|
1
|
3
|
1/3
|
1
|
1
|
1
|
1,00
|
0,15
|
|
|
|
|
A12
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1/2
|
1
|
2
|
1
|
1
|
1,00
|
0,16
|
6,5755
|
0,1151
|
0,0928
|
|
B2
|
2
|
1
|
1/2
|
1
|
1/3
|
1/3
|
0,69
|
0,11
|
|
|
|
|
B3
|
1
|
2
|
1
|
3
|
1
|
2
|
1,51
|
0,24
|
|
|
|
|
B4
|
1/2
|
1
|
1/3
|
1
|
1
|
2
|
0,83
|
0,13
|
|
|
|
|
B5
|
1
|
3
|
1
|
1
|
1
|
2
|
1,35
|
0,22
|
|
|
|
|
B6
|
1
|
3
|
1/2
|
1/2
|
1/2
|
1
|
0,85
|
0,14
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вектор
|
Норм. векторвектор
|
λmax
|
CI
|
CR
|
|
A1
|
1
|
1/2
|
1/2
|
1
|
1/7
|
1/7
|
1/7
|
1/4
|
1/5
|
1/5
|
1/3
|
1/3
|
0,31
|
0,02
|
13,0734
|
0,0976
|
0,0659
|
|
A2
|
2
|
1
|
3
|
1/2
|
1/5
|
1/5
|
1/5
|
1/3
|
1/4
|
1/4
|
1/2
|
1/2
|
0,47
|
0,03
|
|
|
|
|
A3
|
2
|
1/3
|
1
|
2
|
1/6
|
1/6
|
1/6
|
1/4
|
1/5
|
1/5
|
1/3
|
1/3
|
0,37
|
0,02
|
|
|
|
|
A4
|
1
|
2
|
1/2
|
1
|
1/2
|
1/3
|
1/4
|
1/3
|
1/5
|
1/5
|
1/3
|
1/3
|
0,45
|
0,03
|
|
|
|
|
A5
|
7
|
5
|
6
|
2
|
1
|
1/2
|
2
|
3
|
2
|
1
|
2
|
2
|
2,16
|
0,14
|
|
|
|
|
A6
|
7
|
5
|
6
|
3
|
2
|
1
|
3
|
2
|
2
|
2
|
2
|
2
|
2,65
|
0,18
|
|
|
|
|
A7
|
7
|
5
|
6
|
4
|
1/2
|
1/3
|
1
|
1
|
1/2
|
1/3
|
1
|
1
|
1,30
|
0,09
|
|
|
|
|
A8
|
4
|
3
|
4
|
3
|
1/3
|
1/2
|
1
|
1
|
3
|
2
|
3
|
3
|
1,82
|
0,12
|
|
|
|
|
A9
|
5
|
4
|
5
|
5
|
1/2
|
1/2
|
2
|
1/3
|
1
|
1/3
|
1
|
1
|
1,32
|
0,09
|
|
|
|
|
A10
|
5
|
4
|
5
|
5
|
1
|
1/2
|
3
|
1/2
|
3
|
1
|
4
|
4
|
2,26
|
0,15
|
|
|
|
|
A11
|
3
|
2
|
3
|
3
|
1/2
|
1/2
|
1
|
1/3
|
1
|
1/4
|
1
|
1
|
1,01
|
0,07
|
|
|
|
|
A12
|
3
|
2
|
3
|
3
|
1/2
|
1/2
|
1
|
1/3
|
1
|
1/4
|
1
|
1
|
1,01
|
0,07
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вес
|
|
B1
|
0,21
|
0,08
|
0,08
|
0,22
|
0,06
|
0,20
|
0,08
|
0,12
|
0,18
|
0,26
|
0,14
|
0,16
|
0,16
|
|
B2
|
0,06
|
0,06
|
0,09
|
0,06
|
0,08
|
0,06
|
0,05
|
0,05
|
0,09
|
0,08
|
0,07
|
0,11
|
0,07
|
|
B3
|
0,21
|
0,28
|
0,24
|
0,39
|
0,08
|
0,07
|
0,47
|
0,23
|
0,23
|
0,34
|
0,30
|
0,24
|
0,23
|
|
B4
|
0,15
|
0,30
|
0,24
|
0,14
|
0,22
|
0,30
|
0,10
|
0,25
|
0,24
|
0,19
|
0,21
|
0,13
|
0,22
|
|
B5
|
0,19
|
0,23
|
0,23
|
0,10
|
0,18
|
0,06
|
0,18
|
0,25
|
0,07
|
0,06
|
0,13
|
0,22
|
0,14
|
|
B6
|
0,19
|
0,05
|
0,12
|
0,10
|
0,39
|
0,30
|
0,12
|
0,10
|
0,18
|
0,06
|
0,15
|
0,14
|
0,19
|
ПРИЛОЖЕНИЕ 6
Сравнительный анализ методик экспертом 5
|
A1
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
2
|
1
|
2
|
1
|
1,41
|
0,22
|
6,4533
|
0,0907
|
0,0731
|
|
B2
|
1/2
|
1
|
1
|
1
|
2
|
1
|
1,00
|
0,16
|
|
|
|
|
B3
|
1/2
|
1
|
1
|
1
|
1
|
2
|
1,00
|
0,16
|
|
|
|
|
B4
|
1
|
1
|
1
|
1
|
3
|
4
|
1,51
|
0,24
|
|
|
|
|
B5
|
1/2
|
1/2
|
1
|
1/3
|
1/3
|
0,55
|
0,09
|
|
|
|
|
B6
|
1
|
1
|
1/2
|
1/4
|
3
|
1
|
0,85
|
0,13
|
|
|
|
|
A2
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
2
|
2
|
3
|
3
|
2,04
|
0,31
|
6,1886
|
0,0377
|
0,0304
|
|
B2
|
1/2
|
1
|
1/2
|
1/2
|
1/2
|
1/2
|
0,56
|
0,09
|
|
|
|
|
B3
|
1/2
|
2
|
1
|
1
|
1
|
2
|
1,12
|
0,17
|
|
|
|
|
B4
|
1/2
|
2
|
1
|
1
|
2
|
2
|
1,26
|
0,19
|
|
|
|
|
B5
|
1/3
|
2
|
1
|
1/2
|
1
|
2
|
0,93
|
0,14
|
|
|
|
|
B6
|
1/3
|
2
|
1/2
|
1/2
|
1/2
|
1
|
0,66
|
0,10
|
|
|
|
|
A3
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/4
|
1/4
|
1/3
|
1
|
0,59
|
0,08
|
6,2778
|
0,0556
|
0,0448
|
|
B2
|
1/2
|
1
|
1/3
|
1/4
|
1/3
|
1/2
|
0,44
|
0,06
|
|
|
|
|
B3
|
4
|
3
|
1
|
1
|
2
|
1
|
1,70
|
0,24
|
|
|
|
|
B4
|
4
|
4
|
1
|
1
|
3
|
2
|
2,14
|
0,31
|
|
|
|
|
B5
|
3
|
3
|
1/2
|
1/3
|
1
|
1/2
|
0,95
|
0,14
|
|
|
|
|
B6
|
1
|
2
|
1
|
1/2
|
2
|
1
|
1,12
|
0,16
|
|
|
|
|
A4
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1
|
3
|
2
|
2
|
3
|
1,82
|
0,29
|
6,5120
|
0,1024
|
0,0826
|
|
B2
|
1
|
1
|
2
|
1/2
|
2
|
1/2
|
1,00
|
0,16
|
|
|
|
|
B3
|
1/3
|
1/2
|
1
|
1
|
1
|
1/2
|
0,66
|
0,10
|
|
|
|
|
B4
|
1/2
|
2
|
1
|
1
|
1
|
2
|
1,12
|
0,18
|
|
|
|
|
B5
|
1/2
|
1/2
|
1
|
1
|
1
|
2
|
0,89
|
0,14
|
|
|
|
|
B6
|
1/3
|
2
|
2
|
1/2
|
1/2
|
1
|
0,83
|
0,13
|
|
|
|
|
A5
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
1/2
|
1
|
1/2
|
1/2
|
0,89
|
0,13
|
6,6150
|
0,1230
|
0,0992
|
|
B2
|
1/4
|
1
|
1/4
|
1/2
|
1/3
|
1/3
|
0,39
|
0,06
|
|
|
|
|
B3
|
2
|
4
|
1
|
1/2
|
2
|
3
|
1,70
|
0,25
|
|
|
|
|
B4
|
1
|
2
|
2
|
1
|
2
|
2
|
1,59
|
0,24
|
|
|
|
|
B5
|
2
|
3
|
1/2
|
1/2
|
1
|
3
|
1,28
|
0,19
|
|
|
|
|
B6
|
2
|
3
|
1/3
|
1/2
|
1/3
|
1
|
0,83
|
0,12
|
|
|
|
|
A6
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
3
|
1/2
|
5
|
5
|
2,31
|
0,30
|
6,4082
|
0,0816
|
0,0658
|
|
B2
|
1/4
|
1
|
1/4
|
1/4
|
1/2
|
1/2
|
0,40
|
0,05
|
|
|
|
|
B3
|
1/3
|
4
|
1
|
1/4
|
2
|
2
|
1,05
|
0,14
|
|
|
|
|
B4
|
2
|
4
|
4
|
1
|
3
|
3
|
2,57
|
0,34
|
|
|
|
|
B5
|
1/5
|
2
|
1/2
|
1/3
|
1
|
1/2
|
0,57
|
0,07
|
|
|
|
|
B6
|
1/5
|
1/2
|
1/3
|
2
|
1
|
0,71
|
0,09
|
|
|
|
|
A7
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
3
|
1/3
|
1/3
|
1,00
|
0,15
|
6,2914
|
0,0583
|
0,0470
|
|
B2
|
1/3
|
1
|
1/3
|
1
|
1/3
|
1/3
|
0,48
|
0,07
|
|
|
|
|
B3
|
1
|
3
|
1
|
3
|
1
|
1
|
1,44
|
0,21
|
|
|
|
|
B4
|
1/3
|
1
|
1/3
|
1
|
1/2
|
1/2
|
0,55
|
0,08
|
|
|
|
|
B5
|
3
|
3
|
1
|
2
|
1
|
1
|
1,62
|
0,24
|
|
|
|
|
B6
|
3
|
3
|
1
|
2
|
1
|
1
|
1,62
|
0,24
|
|
|
|
|
A8
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1/4
|
1/4
|
1/4
|
2
|
0,63
|
0,08
|
6,3333
|
0,0667
|
0,0538
|
|
B2
|
1/2
|
1
|
1/5
|
1/5
|
1/5
|
1
|
0,40
|
0,05
|
|
|
|
|
B3
|
4
|
5
|
1
|
1
|
1
|
3
|
1,98
|
0,26
|
|
|
|
|
B4
|
4
|
5
|
1
|
1
|
1
|
3
|
1,98
|
0,26
|
|
|
|
|
B5
|
4
|
5
|
1
|
1
|
1
|
4
|
2,08
|
0,27
|
|
|
|
|
B6
|
2
|
1
|
1/3
|
1/3
|
1/4
|
1
|
0,62
|
0,08
|
|
|
|
|
A9
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
3
|
1
|
1/2
|
1/2
|
1
|
0,95
|
0,15
|
6,5324
|
0,1065
|
0,0859
|
|
B2
|
1/3
|
1
|
1/3
|
1/3
|
2
|
2
|
0,73
|
0,11
|
|
|
|
|
B3
|
1
|
3
|
1
|
1
|
2
|
1
|
1,35
|
0,21
|
|
|
|
|
B4
|
2
|
3
|
1
|
1
|
3
|
2
|
1,82
|
0,28
|
|
|
|
|
B5
|
2
|
1/2
|
1/2
|
1/3
|
1
|
1/2
|
0,66
|
0,10
|
|
|
|
|
B6
|
1
|
1/2
|
1
|
1/2
|
2
|
1
|
0,89
|
0,14
|
|
|
|
|
A10
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
4
|
1
|
3
|
3
|
3
|
2,18
|
0,31
|
6,1993
|
0,0399
|
0,0321
|
|
B2
|
1/4
|
1
|
1/3
|
1/3
|
1/2
|
1/2
|
0,44
|
0,06
|
|
|
|
|
B3
|
1
|
3
|
1
|
1
|
3
|
3
|
1,73
|
0,25
|
|
|
|
|
B4
|
1/3
|
3
|
1
|
1
|
2
|
2
|
1,26
|
0,18
|
|
|
|
|
B5
|
1/3
|
2
|
1/3
|
1/2
|
1
|
2
|
0,78
|
0,11
|
|
|
|
|
B6
|
1/3
|
2
|
1/3
|
1/2
|
1/2
|
1
|
0,62
|
0,09
|
|
|
|
|
A11
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
2
|
1
|
1/2
|
1/2
|
1
|
0,89
|
0,14
|
6,3538
|
0,0708
|
0,0571
|
|
B2
|
1/2
|
1
|
1/2
|
1/2
|
2
|
1
|
0,79
|
0,12
|
|
|
|
|
B3
|
1
|
2
|
1
|
1
|
3
|
2
|
1,51
|
0,24
|
|
|
|
|
B4
|
2
|
2
|
1
|
1
|
2
|
3
|
1,70
|
0,27
|
|
|
|
|
B5
|
2
|
1/2
|
1/3
|
1/2
|
1
|
2
|
0,83
|
0,13
|
|
|
|
|
B6
|
1
|
1
|
1/2
|
1/3
|
1/2
|
1
|
0,66
|
|
|
|
|
A12
|
B1
|
B2
|
B3
|
B4
|
B5
|
B6
|
Вектор
|
Норм.вектор
|
λmax
|
CI
|
CR
|
|
B1
|
1
|
1/2
|
1/2
|
1/2
|
1/3
|
1
|
0,59
|
0,09
|
6,5975
|
0,1195
|
0,0964
|
|
B2
|
2
|
1
|
4
|
3
|
2
|
2
|
2,14
|
0,32
|
|
|
|
|
B3
|
2
|
1/4
|
1
|
1/2
|
2
|
3
|
1,07
|
0,16
|
|
|
|
|
B4
|
2
|
1/3
|
2
|
1
|
2
|
3
|
1,41
|
0,21
|
|
|
|
|
B5
|
3
|
1/2
|
1/2
|
1/2
|
1
|
2
|
0,95
|
0,14
|
|
|
|
|
B6
|
1
|
1/2
|
1/3
|
1/3
|
1/2
|
1
|
0,55
|
0,08
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вектор
|
Норм. вектор
|
λmax
|
CI
|
CR
|
|
A1
|
1
|
1/3
|
1/3
|
3
|
1/6
|
1/7
|
1/6
|
1/2
|
1/4
|
1/5
|
1/2
|
1/2
|
0,38
|
0,02
|
13,0598
|
0,0963
|
0,0651
|
|
A2
|
3
|
1
|
1
|
2
|
1/6
|
1/7
|
1/6
|
1/4
|
1/4
|
1/5
|
1/2
|
1/2
|
0,45
|
0,03
|
|
|
|
|
A3
|
3
|
1
|
1
|
3
|
1/5
|
1/6
|
1/5
|
1/3
|
1/4
|
1/5
|
1/2
|
1/2
|
0,50
|
0,03
|
|
|
|
|
A4
|
1/3
|
1/2
|
1/3
|
1
|
1/5
|
1/5
|
1/5
|
1/5
|
1/4
|
1/4
|
1/2
|
1/2
|
0,33
|
0,02
|
|
|
|
|
A5
|
6
|
6
|
5
|
5
|
1
|
1/3
|
1/3
|
1
|
1
|
2
|
2
|
2
|
1,75
|
0,12
|
|
|
|
|
A6
|
7
|
7
|
6
|
5
|
3
|
1
|
1
|
3
|
2
|
1
|
2
|
2
|
2,62
|
0,17
|
|
|
|
|
A7
|
6
|
6
|
5
|
5
|
3
|
1
|
1
|
1
|
1/3
|
1/2
|
2
|
2
|
1,87
|
0,12
|
|
|
|
|
A8
|
2
|
4
|
3
|
5
|
1
|
1/3
|
1
|
1
|
1/2
|
1/4
|
1
|
1
|
1,14
|
0,08
|
|
|
|
|
A9
|
4
|
4
|
4
|
4
|
1
|
1/2
|
3
|
2
|
1
|
1/2
|
2
|
2
|
1,84
|
0,12
|
|
|
|
|
A10
|
5
|
5
|
5
|
4
|
1/2
|
1
|
2
|
4
|
2
|
1
|
4
|
4
|
2,51
|
0,17
|
|
|
|
|
A11
|
2
|
2
|
2
|
2
|
1/2
|
1/2
|
1/2
|
1
|
1/2
|
1/4
|
1
|
1
|
0,89
|
0,06
|
|
|
|
|
A12
|
2
|
2
|
2
|
2
|
1/2
|
1/2
|
1/2
|
1
|
1/2
|
1/4
|
1
|
1
|
0,89
|
0,06
|
|
|
|
|
G
|
A1
|
A2
|
A3
|
A4
|
A5
|
A6
|
A7
|
A8
|
A9
|
A10
|
A11
|
A12
|
Вес
|
|
B1
|
0,22
|
0,31
|
0,08
|
0,29
|
0,13
|
0,30
|
0,15
|
0,08
|
0,15
|
0,31
|
0,14
|
0,09
|
0,20
|
|
B2
|
0,16
|
0,09
|
0,06
|
0,16
|
0,06
|
0,05
|
0,07
|
0,05
|
0,11
|
0,06
|
0,12
|
0,32
|
0,09
|
|
B3
|
0,16
|
0,17
|
0,24
|
0,10
|
0,25
|
0,14
|
0,21
|
0,26
|
0,21
|
0,25
|
0,24
|
0,16
|
0,21
|
|
B4
|
0,24
|
0,19
|
0,31
|
0,18
|
0,24
|
0,34
|
0,08
|
0,26
|
0,28
|
0,18
|
0,27
|
0,21
|
0,23
|
|
B5
|
0,09
|
0,14
|
0,14
|
0,14
|
0,19
|
0,07
|
0,24
|
0,27
|
0,10
|
0,13
|
0,14
|
0,15
|
|
B6
|
0,13
|
0,10
|
0,16
|
0,13
|
0,12
|
0,09
|
0,24
|
0,08
|
0,14
|
0,09
|
0,10
|
0,08
|
0,12
|
ПРИЛОЖЕНИЕ
7
Оценка процессов управления требованиями в проекте Р1 -
Автоматизация социальной защиты. ГБУ «Кризисный центр помощи женщинам и детям»
|
№
|
Код
|
Показатель
|
Значение
|
Опасное значение
|
Целевое значение
|
|
А1
|
Время разработки
концептуальной модели
|
20 дней
|
20 дней
|
10 дней
|
|
А2
|
Количество замечаний
Заказчика к концептуальной модели
|
20
|
>25
|
10
|
|
А3
|
Затраты на формирование
концептуальной модели
|
6%
|
20% бюджета проекта
|
Сделать этап экономически
выгодным
|
|
В1
|
Время сбора требований
|
30 дней
|
25 дней
|
15 дней
|
|
В2
|
Покрытие требованиями
предметной области
|
70%
|
<70%
|
100%
|
|
В3
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
14
|
>8
|
4
|
|
С1
|
Процент подлежащих
реализации требований
|
65%
|
<60%
|
80%
|
|
С2
|
Количество дополнительных
требований
|
32
|
30
|
10
|
|
С3
|
Процент требований,
подлежащих корректировке
|
22%
|
20%
|
3%
|
|
С4
|
Точность планирования
аналитических работ
|
0,3
|
0,2
|
0,05
|
|
D1
|
Затраты на проектирование
системы
|
35%
|
50% бюджета
|
Сделать этап экономически
выгодным
|
|
D2
|
Время проектирования
системы
|
35%
|
50%
|
30%
|
|
D3
|
Процент измененных
требований
|
15%
|
10%
|
3%
|
|
E1
|
Количество замечаний,
поступивших от Заказчика
|
30
|
>20
|
10
|
|
E2
|
Время разработки прототипа
|
8%
|
>10%
|
5%
|
|
E3
|
Стоимость разработки
прототипа
|
5%
|
>10%
|
5%
|
|
F1
|
Количество несогласованных
требований
|
12
|
10
|
5
|
|
F2
|
Процент утвержденных
изменений
|
60%
|
80%
|
50%
|
|
F3
|
Количество новых выявленных
требований
|
20
|
10
|
5
|
|
F4
|
Стоимость выявленных
изменений
|
Экономически не выгодно
|
Превышение бюджета проекта
|
Сделать этап экономически
выгодным
|
|
F5
|
Количество требований,
потерявших актуальность
|
4
|
5
|
0
|
|
F6
|
Процент нереализованных
требований
|
3%
|
2%
|
0
|
ПРИЛОЖЕНИЕ
8
Оценка процессов управления требованиями в проекте Р2 -
Автоматизация ООО Частное охранное предприятие «Русский Витязь»
|
№
|
Код
|
Показатель
|
Значение
|
Опасное значение
|
Целевое значение
|
|
А1
|
Время разработки
концептуальной модели
|
14 дней
|
20 дней
|
10 дней
|
|
А2
|
Количество замечаний
Заказчика к концептуальной модели
|
12
|
>25
|
10
|
|
А3
|
Затраты на формирование
концептуальной модели
|
5%
|
20% бюджета проекта
|
Сделать этап экономически
выгодным
|
|
В1
|
Время сбора требований
|
14 дней
|
25 дней
|
15 дней
|
|
В2
|
Покрытие требованиями
предметной области
|
90%
|
<70%
|
100%
|
|
В3
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
6
|
>8
|
4
|
|
С1
|
Процент подлежащих
реализации требований
|
90%
|
<60%
|
80%
|
|
С2
|
Количество дополнительных
требований
|
10
|
30
|
10
|
|
С3
|
Процент требований,
подлежащих корректировке
|
10%
|
20%
|
3%
|
|
С4
|
Точность планирования
аналитических работ
|
0,07
|
0,2
|
0,05
|
|
D1
|
Затраты на проектирование
системы
|
45%
|
50% бюджета
|
Сделать этап экономически
выгодным
|
|
D2
|
Время проектирования
системы
|
50%
|
50%
|
30%
|
|
D3
|
Процент измененных
требований
|
7%
|
10%
|
3%
|
|
E1
|
Количество замечаний,
поступивших от Заказчика
|
8
|
>20
|
10
|
|
E2
|
Время разработки прототипа
|
8%
|
>10%
|
5%
|
|
E3
|
Стоимость разработки
прототипа
|
10%
|
>10%
|
5%
|
|
F1
|
Количество несогласованных
требований
|
2
|
10
|
5
|
|
F2
|
Процент утвержденных
изменений
|
35%
|
80%
|
50%
|
|
F3
|
Количество новых выявленных
требований
|
3
|
10
|
5
|
|
F4
|
Стоимость выявленных
изменений
|
3% Экономически выгодно
|
Превышение бюджета проекта
|
Сделать этап экономически
выгодным
|
|
F5
|
Количество требований,
потерявших актуальность
|
0
|
5
|
0
|
|
F6
|
Процент нереализованных
требований
|
0
|
2%
|
0
|
ПРИЛОЖЕНИЕ
9
Оценка процессов управления требованиями в проекте Р3 -
Автоматизация ООО «СПОРТФИШ ТУР»
|
№
|
Код
|
Показатель
|
Значение
|
Опасное значение
|
Целевое значение
|
|
А1
|
Время разработки
концептуальной модели
|
12 дней
|
20 дней
|
10 дней
|
|
А2
|
Количество замечаний
Заказчика к концептуальной модели
|
17
|
>25
|
10
|
|
А3
|
Затраты на формирование концептуальной
модели
|
4%
|
20% бюджета проекта
|
Сделать этап экономически
выгодным
|
|
В1
|
Время сбора требований
|
25 дней
|
25 дней
|
15 дней
|
|
В2
|
Покрытие требованиями
предметной области
|
95%
|
<70%
|
100%
|
|
В3
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
3
|
>8
|
4
|
|
С1
|
Процент подлежащих
реализации требований
|
92%
|
<60%
|
80%
|
|
С2
|
Количество дополнительных
требований
|
6
|
30
|
10
|
|
С3
|
Процент требований,
подлежащих корректировке
|
5%
|
20%
|
3%
|
|
С4
|
Точность планирования
аналитических работ
|
0,1
|
0,2
|
0,05
|
|
D1
|
Затраты на проектирование
системы
|
15%
|
50% бюджета
|
Сделать этап экономически
выгодным
|
|
D2
|
Время проектирования
системы
|
20%
|
50%
|
30%
|
|
D3
|
Процент измененных
требований
|
2%
|
10%
|
3%
|
|
E1
|
Количество замечаний,
поступивших от Заказчика
|
20
|
>20
|
10
|
|
E2
|
Время разработки прототипа
|
5%
|
>10%
|
5%
|
|
E3
|
Стоимость разработки
прототипа
|
3%
|
>10%
|
5%
|
|
F1
|
Количество несогласованных
требований
|
9
|
10
|
5
|
|
F2
|
Процент утвержденных
изменений
|
70%
|
80%
|
50%
|
|
F3
|
Количество новых выявленных
требований
|
10
|
5
|
|
F4
|
Стоимость выявленных
изменений
|
Экономически не выгодно
|
Превышение бюджета проекта
|
Сделать этап экономически
выгодным
|
|
F5
|
Количество требований,
потерявших актуальность
|
4
|
5
|
0
|
|
F6
|
Процент нереализованных
требований
|
0,8%
|
2%
|
0
|
ПРИЛОЖЕНИЕ
10
Оценка процессов управления требованиями в проекте Р4 -
«Автоматизация Российских студенческих отрядов»
|
№
|
Код
|
Показатель
|
Значение
|
Опасное значение
|
Целевое значение
|
|
А1
|
Время разработки
концептуальной модели
|
8 дней
|
20 дней
|
10 дней
|
|
А2
|
Количество замечаний
Заказчика к концептуальной модели
|
6
|
>25
|
10
|
|
А3
|
Затраты на формирование
концептуальной модели
|
5%
|
20% бюджета проекта
|
Сделать этап экономически
выгодным
|
|
В1
|
Время сбора требований
|
10 дней
|
25 дней
|
15 дней
|
|
В2
|
Покрытие требованиями
предметной области
|
98%
|
<70%
|
100%
|
|
В3
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
3
|
>8
|
4
|
|
С1
|
Процент подлежащих
реализации требований
|
90%
|
<60%
|
80%
|
|
С2
|
Количество дополнительных
требований
|
5
|
30
|
10
|
|
С3
|
Процент требований,
подлежащих корректировке
|
1%
|
20%
|
3%
|
|
С4
|
Точность планирования
аналитических работ
|
0,03
|
0,2
|
0,05
|
|
D1
|
Затраты на проектирование
системы
|
20%
|
50% бюджета
|
Сделать этап экономически
выгодным
|
|
D2
|
Время проектирования
системы
|
20%
|
50%
|
30%
|
|
D3
|
Процент измененных
требований
|
1%
|
10%
|
3%
|
|
E1
|
Количество замечаний,
поступивших от Заказчика
|
7
|
>20
|
10
|
|
E2
|
Время разработки прототипа
|
3%
|
>10%
|
5%
|
|
E3
|
Стоимость разработки
прототипа
|
3%
|
>10%
|
5%
|
|
F1
|
Количество несогласованных
требований
|
10
|
10
|
5
|
|
F2
|
Процент утвержденных
изменений
|
90%
|
80%
|
50%
|
|
F3
|
Количество новых выявленных
требований
|
10
|
10
|
5
|
|
F4
|
Стоимость выявленных
изменений
|
Экономически выгодно
|
Превышение бюджета проекта
|
Сделать этап экономически
выгодным
|
|
F5
|
Количество требований,
потерявших актуальность
|
2
|
5
|
0
|
|
F6
|
Процент нереализованных
требований
|
0,5%
|
2%
|
0
|
Приложение
11
Оценка процессов управления требованиями в проекте Р5 -
Автоматизация открытых R&D центров - ФРИП ТПП
|
№
|
Код
|
Показатель
|
Значение
|
Опасное значение
|
Целевое значение
|
|
А1
|
Время разработки
концептуальной модели
|
18 дней
|
20 дней
|
10 дней
|
|
А2
|
Количество замечаний
Заказчика к концептуальной модели
|
3
|
>25
|
10
|
|
А3
|
Затраты на формирование
концептуальной модели
|
5%
|
20% бюджета проекта
|
Сделать этап экономически
выгодным
|
|
В1
|
Время сбора требований
|
5 дней
|
25 дней
|
15 дней
|
|
В2
|
Покрытие требованиями
предметной области
|
98%
|
<70%
|
100%
|
|
В3
|
Среднее количество
обращений к заинтересованным сторонам до момента получения требований
|
2
|
>8
|
4
|
|
С1
|
Процент подлежащих
реализации требований
|
95%
|
<60%
|
80%
|
|
С2
|
Количество дополнительных
требований
|
0
|
30
|
10
|
|
С3
|
Процент требований,
подлежащих корректировке
|
0,05%
|
20%
|
3%
|
|
С4
|
Точность планирования
аналитических работ
|
0,1
|
0,2
|
0,05
|
|
D1
|
Затраты на проектирование
системы
|
45%
|
50% бюджета
|
Сделать этап экономически
выгодным
|
|
D2
|
Время проектирования
системы
|
45%
|
50%
|
30%
|
|
D3
|
Процент измененных
требований
|
5%
|
10%
|
3%
|
|
E1
|
Количество замечаний,
поступивших от Заказчика
|
3
|
>20
|
10
|
|
E2
|
Время разработки прототипа
|
10%
|
>10%
|
5%
|
|
E3
|
Стоимость разработки
прототипа
|
7%
|
>10%
|
5%
|
|
F1
|
Количество несогласованных
требований
|
1
|
10
|
5
|
|
F2
|
Процент утвержденных
изменений
|
50%
|
80%
|
50%
|
|
F3
|
Количество новых выявленных
требований
|
3
|
10
|
5
|
|
F4
|
Стоимость выявленных
изменений
|
Экономически невыгодно
|
Превышение бюджета проекта
|
Сделать этап экономически
выгодным
|
|
F5
|
Количество требований,
потерявших актуальность
|
0
|
5
|
0
|
|
F6
|
Процент нереализованных
требований
|
4%
|
2%
|
0
|
Приложение
12
Задачи и роли процесса управления запросами на изменения
|
Задача
|
Описание задачи
|
Роль
|
Вход
|
Выход
|
|
Планирование контроля
изменений
|
Создается план, который
определяет каким образом изменяются требования, упорядочиваются,
отслеживаются в течение жизненного цикла проекта
|
Менеджер проекта
|
План создания продукта
|
План управления изменениями
|
|
Регистрация запроса на
изменение
|
Запрос на изменение
регистрируется в системе и ставится в очередь на рассмотрение
|
Регистратор
|
Запрос заинтересованной
стороны
|
Зарегистрированный запрос
на изменение
|
|
Пересмотр запроса на
изменение
|
Определяется обоснованность
запроса. Если запрос обоснован, то определяется принадлежность изменения к
текущей версии. Определение основывается на графике работ, доступных
ресурсах, риске и т.д.
|
Менеджер изменений
|
Запрос на изменение
|
Запрос на изменение
|
|
Подтверждение состояния
«Отклонено» или «Дубликат» для запроса на изменение
|
Если запрос является
дубликатом уже зарегистрированного ранее запроса или идентифицируется как
неправильный, ему назначается соответствующий статус
|
Менеджер изменений
|
Запрос на изменение
|
Запрос на изменение с
соответствующим статусом
|
|
Обновление запроса на
изменение
|
Если требуется
дополнительная информация для оценки запроса, то после ее поступления,
регистратор вносит данные и вновь ставит запрос в очередь рассмотрения
|
Регистратор
|
Запрос на изменение
|
Обновленный запрос на
изменение
|
|
Выполнение изменений
|
Назначенный сотрудник
выполняет ряд работ, необходимых для выполнения запрошенных изменений
|
Назначенный член команды
разработчика
|
Запрос на изменение
|
Выполненный запрос на
изменение
|
|
Верификация изменений в
тестовой сборке
|
Проверка выполненных
изменений в тестовой сборке продукта
|
Тестировщик
|
Запрос на изменение; Тестовая
сборка; Журнал тестирования
|
Запрос на изменение;
Результаты тестирования
|
|
Верификация изменений в
собранном релизе
|
Проверка выполненных
изменений в сборке релиза продукта
|
Тестировщик
|
Запрос на изменение;
Сборка; Журнал тестирования
|
Запрос на изменение;
Результаты тестирования
|
|
Распределение работ
|
Назначаются работы
соответствующему члену команды разработчика в зависимости от типа запроса.
Вносятся соответствующие изменения в график работ
|
Менеджер проекта
|
График работ
|
Обновленный график работ
|
ПРИЛОЖЕНИЕ
13
Форма запроса на изменение
· Идентификация
o проект;
o номер запроса на изменение;
o тип запроса на изменение: (проблема или улучшение);
o заголовок;
o дата внесения;
o инициатор;
o приоритет запроса на изменение.
· Текущая проблема
o описание текущей проблемы;
o серьезная ошибка;
o неудобство;
o улучшение;
o новое требование;
o условия обнаружения проблемы;
o текущая среда разработки: оборудование;
o операционная система;
o компилятор;
o источник текущей проблемы;
o издержки от текущей проблемы.
· Предложенное изменение (инициатор)
o описание предложенного изменения;
o оценка стоимости реализации предложенного изменения.
· Предложенное изменение (группа оценки изменения)
o действие;
o одобрено;
o не одобрено;
o отсрочено;
o описание предложенного изменения;
o затрагиваемые элементы конфигурации;
o категория;
o исправление;
o улучшение;
o новые свойства;
o другое.
· Решение
o предполагаемая цена реализации предложенного изменения;
o программист;
o время реализации изменения;
o анализ;
o реализация;
o тестирование;
o документация;
o число изменяемых строк кода.
· Оценка
o методы тестирования;
o инспекция;
o демонстрация;
o тестирование;
o платформы тестирования;
o сценарии тестирования.
Приложение
14
Задачи и роли процесса сбора требований
|
Задача
|
Описание задачи
|
Роль
|
Вход
|
Выход
|
|
Разработка плана управления
требованиями
|
Разрабатывается документ, в
котором описываются типы требований, их структура, методы сбора требований
|
Аналитик
|
Запросы заинтересованных
сторон
|
План управления требованиями
|
|
Разработка концепции ИС
|
Определяются основные
свойства системы, устанавливаются границы
|
Аналитик
|
Запросы заинтересованных
сторон; Бизнес-модель;
|
Концепция
|
|
Детализация требований
|
Структурируются все
требования к системе. Недостаточно описанные требования дополняются.
Формируются спецификации требований
|
Спецификатор требований
|
Концепция; Варианты
использования; Модель вариантов использования
|
Спецификация программных
требований; Дополнительная спецификация
|
|
Приоритизация требований
|
Определяется порядок реализации
функциональности продукта
|
Аналитик
|
Концепция; Модель вариантов
использования; План итерации
|
Архитектура системы; План
итерации уточненный
|
|
Определение
заинтересованных сторон и вариантов использования
|
Определяются агенты и
варианты использования системы. Варианты использования кратко описываются.
Формируется модель вариантов использования
|
Аналитик
|
Концепция; Бизнес-модель;
Запросы заинтересованных сторон
|
Варианты использования;
Модель вариантов использования
|
|
Детализация вариантов
использования
|
Детализируется описание
каждого варианта использования. Определяются дополнительные требования
|
Спецификатор требований
|
Концепция; Варианты
использования (не детализированные); Модель вариантов использования (не
детализированная)
|
Варианты использования
детализированные; Модель вариантов использования детализированнаая
|
|
Моделирование
пользовательского интерфейса
|
Варианты использования
описываются в терминах интерфейсных классов
|
Дизайнер
|
Модель вариантов
использования детализированная; Дополнительная спецификация
|
Интерфейсное описание
вариантов использования
|
Приложение
15
Задачи/активности тестирования по методологии RUP
Задачи тестирования:
· Планирование тестов (Plan Test):
o Определение требований к тестам (Identify requirements for test);
o Формирование стратегии (Develop test strategy);
o Определение ресурсов (Identify test resources);
o Формирование графика работ (Create schedule);
o Разработка Плана тестирования
(Generate Test Plan);
· Дизайн тестов (Design Test):
o Анализ объема работ (Prepare workload analysis);
o Описание тестовых случаев (Identify and describe
test cases);
o Определение и структурирование
тестовых процедур (Identify and
structure test procedures);
o Обзор и оценка тестового покрытия (Review and assess test coverage);
· Разработка тестов (Implement Test):
o Разработка тестовых скриптов (Record or program test
scripts);
o Создание/подготовка тестовых наборов
данных (Establish external data sets);
· Выполнение тестов (Execute Test):
o Выполнение тестовых процедур (Execute Test procedures);
o Оценка выполнения тестов (Evaluate execution of Test);
o Проверка результатов (Verify the
results);
o Исследование непредвиденных
результатов (Investigate unexpected results);
o Запись ошибок (Log defects);
· Оценка тестов (Evaluate Test):
o Оценка покрытия тестовыми случаями (Evaluate Test-case coverage);
o Оценка покрытия кода (Evaluate code coverage);
o Анализ дефектов (Analyze defects);
o Определение критериев завершения и успешности тестирования (Determine if Test Completion Criteria and Success Criteria
have been achieved.
Таблица
Роли в процессе тестирования
|
Роль
|
Описание
|
|
Менеджер проекта по
тестированию
|
Производит управленческий
контроль
|
|
Тест дизайнер
|
Разрабатывает план
тестирования; Разрабатывает модель тестирования; Определяет тестовые наборы;
Оценивает эффективность тестирования.
|
|
Администратор тестовой
системы
|
Администрирует систему
управления тестированием; Устанавливает и управляет доступом к тестовой
системе.
|
|
Тестировщик
|
Выполняет тесты; Фиксирует
результаты тестирования.
|
|
Разработчик тестов
|
Разрабатывает тестовые
наборы; Создает тестовые классы; Собирает тестовые пакеты и интегрирует их в
тестовую модель
|