ЖУРНАЛ СТА 4/2011

решение о переходе, рискуете вернуть опытных специалистов на стадию но- вичков, существенно снизив их вклад в деятельность всей организации. Реше- ния подобного рода способны раско- лоть коллективы разработчиков на враждующие фракции. Должны ли мы выбрать коммерче- ский продукт или предпочесть откры- тое сообщество? Имеет ли смысл про- должать внутреннюю разработку или лучше перейти на готовое коммерче- ское решение? Чьих любимых про- изводителей включить в список для голосования? Чтобы правильно отве- тить на эти вопросы, необходим чётко определённый, объективный механизм принятия решений. О БЗОР МЕТОДА Предлагаемый метод является адап- тацией одного из известных методов поддержки принятия решений в усло- виях многокритериального выбора – метода анализа иерархий, или метода аналитического иерархического процесса (Analytic Hierarchy Process – AHP), раз- работанного доктором Томасом Саати (Thomas Saaty). В рамках настоящей статьи метод AHP используется для получения ответа на вопрос: «Когда нам нужно будет переходить на другую ОС?». Применение AHP к данному классу задач – логичный выбор. Система кри- териев, применимая для одной компа- нии, может быть недопустима для дру- гой, в зависимости от характера про- изводимых устройств, текущей стадии жизненного цикла продукта, бизнес- целей и т.п. Как именно каждый про- изводитель выбирает и ранжирует кри- терии, зависит от конкретного случая; используемый механизм принятия решения должен позволять корректно учитывать все факторы – AHP как раз для этого и предназначен. Окончательная стоимость каждого варианта решения может оставаться неизвестной, эта информация исполь- зуется только при анализе возврата инвестиций. AHP для своей работы не требует данных о стоимости и прибыли (хотя их можно добавить в модель), что опять же делает его подходящим для поддержки принятия решений такого рода. Также следует иметь в виду, что при- нимаемое решение не имеет никакого отношения к тому, какую конкретно ОС (или ОС РВ) следует применять. Конечно, метод AHP может быть ис- пользован для сравнительной оценки преимуществ различных платформ, но это выходит за рамки данной статьи; основное назначение настоящего ма- териала – ответить на вопрос о том, как выбрать подходящий момент для сме- ны программной платформы (мигра- ции). Ф АКТОРЫ , ВЛИЯЮЩИЕ НА ПРИНЯТИЕ РЕШЕНИЯ Процесс принятия решения строит- ся на вычислении предпочтений между несколькими факторами, попарно сравниваемыми в контексте некоего выбранного критерия. На решение о переходе на другую ОС может влиять множество факторов; мы постараемся упростить процедуру анализа, сгруп- пировав их в более высокоуровневые категории: ● аппаратные факторы; ● программные факторы; ● бизнес-факторы; ● факторы внешних контрагентов. Аппаратные факторы Изменения в ОС часто провоци- руются изменениями в аппаратуре. Фактически пересмотра любой части аппаратной архитектуры может быть достаточно, чтобы, как минимум, заду- маться, способна ли используемая ОС его поддержать. В качестве примера можно привести: ● переход на другую архитектуру, на- пример с 16-разрядного процессора на 32-разрядный; ● переход на многоядерную архитек- туру; ● интеграция функциональности, предлагаемой производителем в но- вой версии процессора; ● снятие используемой линейки мик- росхем с производства. Программные факторы Программные факторы могут быть менее очевидными, так что здесь поль- за от применения формальных методов будет выше. Обычно изменения в ПО вносятся из соображений необходимо- сти реализовать ту или иную новую функциональность, диктуемую требо- ваниями заказчика или включённую в план выпуска. Например, существен- ную роль обычно играет необходи- мость в следующем: ● соответствие новому промышленно- му стандарту; ● интеграция дополнительного свя- зующего ПО; ● расширение линейки инструмента- рия; ● усиление безопасности; ● соответствие требованиям сертифи- кации; ● повышение эффективности взаимо- действия между устройствами; ● реализация удалённого управления устройством. Бизнес-факторы Не все решения о переходе на другие технологии вызваны требованиями сугубо технологическими. Многие являются следствием внешних или внутренних обстоятельств «нетехниче- ского» толка, которые можно собира- тельно назвать бизнес-факторами, например: ● появление новых нормативных тре- бований; ● введение новой корпоративной стра- тегии (скажем, курса на унификацию платформы); ● действия конкурентов; ● недостаток внутренних ресурсов; ● дополнительные ограничения по себестоимости продукции. Факторы внешних контрагентов Часть факторов может исходить от ваших внешних контрагентов, напри- мер поставщиков. Многие технические руководители периодически пересмат- ривают состояние дел у основных по- ставщиков: если оно неудовлетвори- тельное, то не исключено, что постав- щика придётся менять. В современном мире открытого ПО далеко не все поставщики являются компаниями «из кирпича и бетона» (в оригинале “brick- and-mortar” – идиома, характеризую- щая компанию, бизнес которой при- сутствует физически и его можно «по- щупать», скажем, приехав в офис или магазин; употребляется в качестве про- тивопоставления, например, онлайн- бизнесу, который присутствует только в информационном пространстве. – Прим. пер. ), так, для компаний, поддер- живающих свой собственный дистри- бутив открытой ОС, поставщиком яв- ляется свободное сообщество разра- ботчиков, в результате соответствие заявленному плану выпуска (roadmap) и качество технической поддержки часто заслуживают критических оце- нок. В число факторов, относящихся к поставщикам, может входить следую- щее: ОБ ЗОР / П РОГ РАММНОЕ ОБ Е СП Е Ч Е НИЕ 49 СТА 4/2011 www.cta.ru © СТА-ПРЕСС