Определение ключевого фактора для смены программной платформы

Применимы ли математические методы для выбора встраиваемого ПО?

В быстро меняющихся рыночных условиях менеджерам приходится при­­нимать всё больше решений в единицу времени. Средства поддержки принятия решений помогают находить объективные, взвешенные и, в конечном итоге, более корректные ответы на многие критические вопросы, в частности: «Когда переводить проекты на другую программную плат­форму?». По мере роста многообразия типов электронных уст­ройств, программных компонентов для них и требований пользователей становится всё труднее найти универсальное решение, которое подходило бы для всех производителей и одновременно покрывало весь жизненный цикл изделий. В этих ус­ловиях помочь производителям электронных устройств определить наиболее подходящий момент для пе­рехода на новые технологии могут математические методы принятия решений.

Современные производители уст­ройств находятся под давлением целого «букета» внешних факторов, как-то:

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

• увеличивающиеся требования по ин­формационной безопасности;

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

• растущие требования пользователей к производительности.

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

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

Если ваша компания не единственная на рынке и её предложение – не самое дешёвое и не самое функциональное, всегда находится место для конкуренции. Те, кто принимают ре­шение медленно, рискуют остаться на задворках, раздумывая, как одновременно увеличить инновационность и сократить временные затраты, причём даже не столько время выпуска продукта на рынок, сколько время выхода за точку безубыточности.

В силу этого производители уст­ройств стали шире использовать новые стратегии разработки программного обеспечения. Одним из вариантов та­кой стратегии может быть использование новой операционной системы, например внедрение новой версии уже применяемой ОС, либо переход с ОС собственной разработки на коммерче­скую ОС, либо смена производителя. Ключевой вопрос здесь: «Когда именно это следует делать?».

Для принятия решения о необходимости такого перехода может быть использовано бесчисленное множество критериев. Но как определить, какие из них наиболее значимы? Чтобы стать лидером рынка, требуется более чем небольшая плановая коррекция курса. Изменения всегда сопряжены с трудностями, и в области встраиваемого ПО такие трудности могут ис­ходить из самых неожиданных источников. Скажем, для членов коллектива, обладающих максимумом опыта работы с привычной ОС, переход на другую ОС может стать серьёзной угрозой их продуктивности, и вы, приняв решение о переходе, рискуете вернуть опытных специалистов на стадию но­вичков, существенно снизив их вклад в деятельность всей организации. Ре­ше­ния подобного рода способны расколоть коллективы разработчиков на враждующие фракции.

Должны ли мы выбрать коммерческий продукт или предпочесть открытое сообщество? Имеет ли смысл продолжать внутреннюю разработку или лучше перейти на готовое коммерческое решение? Чьих любимых производителей включить в список для голосования? Чтобы правильно ответить на эти вопросы, необходим чётко определённый, объективный механизм принятия решений.

Обзор метода

Предлагаемый метод является адаптацией одного из известных методов поддержки принятия решений в условиях многокритериального выбора – метода анализа иерархий, или метода аналитического иерархического процесса (Analytic Hierarchy Process – AHP), разработанного доктором Томасом Саати (Thomas Saaty). В рамках настоящей статьи метод AHP используется для получения ответа на вопрос: «Когда нам нужно будет переходить на другую ОС?».

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

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

Также следует иметь в виду, что принимаемое решение не имеет никакого отношения к тому, какую конкретно ОС (или ОС РВ) следует применять. Конечно, метод AHP может быть ис­поль­зован для сравнительной оценки преимуществ различных платформ, но это выходит за рамки данной статьи; основное назначение настоящего ма­териала – ответить на вопрос о том, как выбрать подходящий момент для сме­ны программной платформы (миграции).

Факторы, влияющие на принятие решения

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

• аппаратные факторы;

• программные факторы;

• бизнес-факторы;

• факторы внешних контрагентов.

Аппаратные факторы

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

• переход на другую архитектуру, на­пример с 16-разрядного процессора на 32-разрядный;

• переход на многоядерную архитек­туру;

• интеграция функциональности, пред­лагаемой производителем в но­вой версии процессора;

• снятие используемой линейки микросхем с производства.

Программные факторы

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

• соответствие новому промышленному стандарту;

• интеграция дополнительного связующего ПО;

• расширение линейки инструментария;

• усиление безопасности;

• соответствие требованиям сертификации;

• повышение эффективности взаимодействия между устройствами;

• реализация удалённого управления устройством.

Бизнес-факторы

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

• появление новых нормативных требований;

• введение новой корпоративной стратегии (скажем, курса на унификацию платформы);

• действия конкурентов;

• недостаток внутренних ресурсов;

• дополнительные ограничения по себестоимости продукции.

Факторы внешних контрагентов

Часть факторов может исходить от ваших внешних контрагентов, например поставщиков. Многие технические руководители периодически пересматривают состояние дел у основных по­ставщиков: если оно неудовлетворительное, то не исключено, что поставщика придётся менять. В современном мире открытого ПО далеко не все поставщики являются компаниями «из кирпича и бетона» (в оригинале “brick-and-mortar” – идиома, характеризующая компанию, бизнес которой присутствует физически и его можно «по­щупать», скажем, приехав в офис или магазин; употребляется в качестве противопоставления, например, он­лайн-бизнесу, который присутствует только в информационном пространстве. – Прим. пер.), так, для компаний, поддерживающих свой собственный дистрибутив открытой ОС, поставщиком яв­ляется свободное сообщество разработчиков, в результате соответствие заявленному плану выпуска (roadmap) и качество технической поддержки часто заслуживают критических оценок.

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

• качество продукта;

• доступность продукта, включая соответствие планам выпуска и снятия с производства;

• уровень оказываемой технической поддержки;

• стабильность и жизнеспособность поставщика;

• угроза поглощения поставщика конкурентом.

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

Пример принятия решения

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

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

Факторы, влияющие на принятие решения

(В оригинальной трактовке метода используется термин «альтернативы», поскольку рассматривается выбор из нескольких вариантов действия; адаптированная трактовка AHP, описываемая в настоящей статье, отвечает на вопрос: «Какие факторы следует считать определяющими в принятии ре­шения о миграции?», поэтому в переводе использован термин «факторы». – Прим. пер.)

Для простоты иллюстрации сведём число факторов к трём:

1. план внедрения унифицированной среды разработки (Common Develop­ment Environment – CDE) по всей организации;

2. план перехода на многоядерную ар­хитектуру;

3. подтверждённая необходимость в совместимости разрабатываемых уст­­ройств со сторонними устройст­вами и системами.

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

Критерии принятия решения

В данном примере три фактора рассматриваются в контексте трёх критериев (рис. 1):

1. стратегические преимущества, кото­рые компания получит, если примет решение с учётом данного фактора;

2. риски, с которыми сопряжено при­нятие решения с учётом данного фак­тора;

3. ожидаемая выгода от принятия ре­шения с учётом данного фактора.

В качестве примера сравнения важности факторов может выступить ответ на вопрос: «Что принесёт компании большее стратегическое преимущест­во – развёртывание унифицированной среды разработки или улучшение со­вместимости?». Результат сравнения поможет оценить «за» и «против» для каждой пары выборов в рамках каждого критерия. Из этого будет следовать, достаточно ли каждый фактор весо́м, чтобы принимать решение на его основе.

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

Шкалы оценок

Для каждого парного сравнения ис­пользуется шкала оценок от 1 до 9, где 1 означает, что при принятии решения о миграции факторы равноценны, а 9 – что один фактор существенно важнее другого.

Хотя в табл. 1 приведены только не­чётные значения, для придания срав­нению большей точности допускается использовать и чётные значения тоже. 

Обратное сравнение факторов представляется обратными значениями оце­нок: например, если фактор A в сравнении с фактором Б даёт оценку 3, то Б в сравнении с А даст 1/3.

Механика расчётов

После определения факторов и критериев следующим шагом является выполнение попарного сравнения всех факторов по принципу «каждый с каждым» для расчёта их относительных приоритетов.

Сравнение каждого фактора с самим собой по определению даёт оценку 1, поэтому по диагонали таблицы оце­­­нок можно сразу проставить единицы (рис. 2).

Сравнивая CDE с совместимостью в контексте стратегического преимущества, мы поставили оценку 8, утверждая тем самым, что внедрение унифицированной среды разработки даст компании гораздо большее стратегическое преимущество, чем обеспе­че­ние лучшей совместимости уст­ройств. Соответственно, в ячейку, за­дающую оценку для обратного сравнения (стро­­ка 2, колонка 1), можно сразу впи­­сать 1/8, то есть 0,13 (здесь и да­лее – округление до 2-го знака, поэтому не все нормированные веса в результате дают в сумме ровно 1,00. – Прим. пер.).

Продолжая попарное сравнение фак­торов в контексте стратегического преимущества, имеем оценку 6 (обратное значение 0,17) для сравнения CDE с многоядерностью; сравнение совместимости с многоядерностью тоже даёт оценку 6.

Теперь нормализуем оценки каждого попарного сравнения (рис. 3), разделив все элементы каждого столбца на сумму его значений, а потом возьмём среднее по каждой строке, чтобы получить нормализованный вес каждого фактора. Вес фактора CDE в сравнении с другими в контексте стратегического преимущества получается равным 0,71.

Проведём теперь аналогичное по­пар­ное сравнение факторов в контексте остальных критериев – риска (рис. 4) и выгоды (рис. 5). 

Из примера на рис. 4 видно, что переход на многоядерную архитектуру привносит чуть больше риска, чем остальные факторы; при этом по части ожидаемой выгоды ли­дирует фактор CDE (рис. 5).

Аналогичным образом ранжируем и взвешиваем критерии друг относительно друга (рис. 6).

Теперь, когда относительные приоритеты расставлены, можно рассчитать конечные веса каждого фактора с учётом всех критериев одновременно. В нашем примере результаты показывают, что в принятии решения о миграции решающим фактором будет не­об­ходимость внедрения унифицированной среды разработки (рис. 7).

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

Реальное положение дел

В процессе анализа решений о смене программной платформы, принятых клиентами компании Wind River, за­ме­чено, что основными факторами, по­влиявшими на это решение, были стремления:

• внедрить на всём предприятии единую среду и методологию разработки;

• снизить издержки, вызванные либо рыночными условиями, либо ценами поставщиков;

• внедрить новые технологии, не поддерживаемые существующей платформой;

• работать со стабильным поставщиком в условиях динамичного рынка.

И хотя реальные модели принятия решений, использованные компаниями-респондентами, остаются за кадром, это как раз тот самый случай, когда математические методы поддержки способны помочь реализовать взвешенный и объективный подход. ● 

Авторизованный перевод Николая Горбунова, сотрудника фирмы ПРОСОФТ
Телефон: (495) 234-0636
E-mail: info@prosoft.ru