CC BY
52
УЕБТЫНС
мвви
УДК 69:658.51
Д.В. Аникин
ФГБОУВПО «МГСУ»
КРИТЕРИИ ОЦЕНКИ ПРИМЕНЕНИЯ ИНТЕРОПЕРАБЕЛЬНОСТИ, ЗАДАННЫЕ УСЛОВИЯМИ ПРИНЯТИЯ РЕШЕНИЯ
Показана необходимость подбора программных продуктов, составляющих корпоративное информационное пространство. Обоснована причина создания интероперабельности корпоративных информационных систем. Были упомянуты два крайних подхода к формированию интероперабельного пространства. Указаны различные критерии для подбора оптимального набора программных продуктов. Рассмотрен вопрос об уровне стандартизации интероперабельности корпоративного информационного пространства. Предложен вариант подбора интероперабельных программных продуктов для организации в соответствии с неким коэффициентом. Этот коэффициент представляет собой вероятность появления события «удовлетворенность выбранным программным продуктом» по /-му критерию из п возможных. Эти критерии должны составляться коллегией компетентных сотрудников организации с учетом целей оптимизации и поставленных задач.
Ключевые слова: критерии оценки, информационная система, вероятность, условия выбора, поправочный коэффициент, интероперабельность.
Понятие интероперабельности зарождалось еще до появления необходимости дать определение и попытки описать и систематизировать все жизненные процессы, осознать уровень взаимодействия составляющих комплекса. Сейчас более актуально создание таких продуктов, которые могут поддерживать интероперабельность всей системы в целом. Так, относительно новые понятия: облачные технологии, виртуальные предприятия, центры мониторинга систем — неразрывно связаны с интероперабельностью и тем более в строительной отрасли. Под интероперабельностью будем понимать способность продукта или системы, интерфейсы которого полностью открыты, взаимодействовать и функционировать с другими продуктами и системами без каких-либо ограничений доступа и реализации.
В настоящее время требуется умение определить, насколько выбранный способ взаимодействия с другими системами комплекса более удобен для создания интероперабельных продуктов и систем программных продуктов. Как определить, что данный способ взаимодействия внутри комплекса и с внешними источниками наиболее оптимален? То есть интероперабельность кроме количественной характеристики должна иметь качественную, состоящую из умения программного обеспечения использовать в данных условиях более оптимальный способ взаимодействия с другими внутренними и внешними системами, источниками и данными.
Возникает вопрос, что значит оптимальный способ, как определить, что он оптимальный? Проблема в том, что понятие оптимальности не объективно, но и не субъективно. Оптимальность диктуется условиями, ограничениями, которые требуют решения задачи. Например, в условиях чрезвычайных ситуаций следует получать решения в наикротчайшие сроки, если следует максимизиро-
ВЕСТНИК лтчпл'».
10/2013
вать прибыль, то скорость принятия решения будет интересовать нас в меньшей степени, нежели решения, способные максимизировать доход. В условиях банкротства следует минимизировать затраты, а в условиях строительства многоэтажных зданий следует учитывать не минимизацию затрат в первую очередь, а наличие качественных стройматериалов, поставляемых в наикратчайшие сроки с наименьшими затратами на поставку, производство этих составляющих. Если рассматривать оптимизацию способов интероперабельности программных продуктов и комплексов в строительной отрасли, то следует учесть для каких целей создается интероперабельность продукта, в каких условиях будет использоваться данная возможность, как долго и как часто. Как и любой товар, будь то физический или интеллектуальный, интероперабельность должна иметь и сроки своего использования, тем более для строительных организаций. Ведь, все развивается, в т.ч. интеллектуальные продукты и с их изменением и появлением новых возникают новые способы интероперабельности. В зависимости от ситуации интеро-перабельность должна включать в себя разные составляющие, способы, уровни. Таким образом, интероперабельность — живой организм, который постоянно меняется в зависимости от изменения отправных условий и достигаемых целей.
Интересен тот факт, что на интероперабельность смотрят с разных точек зрения. В соответствии с этим возникает множество противоречивых фактов и решений. С одной стороны, имеются мнения, что из процесса интероперабельных программных продуктов и программных системных решений следует полностью исключить посредническую часть сторонних организаций или частных лиц, которые предлагают свои способы решения вопросов совместимости, что не всегда является лучшим решением. Более того, данные вопросы могут решать некомпетентные люди, что может усугубить ситуацию, решение может привести к неконкурентоспособности организации. Единственно правильным решением в данном случае, по мнению сторонников данной позиции, является стандарт, в соответствии с которым будет выполнена выгрузка данных и дальнейшая загрузка таковых в другие программы или системы. В стандарт в этом случае могут включать не только правила, но и алгоритмы, форматы, последовательность данных, определяется место для хранения выгруженных данных, правила безопасности хранимых данных и безопасности их передачи. Иначе говоря, конечный пользователь должен выполнить все согласно инструкции прописанной в стандарте, тогда интероперабельность программных продуктов будет на высоком уровне и даст качественный результат. Ответственность за интероперабельность системы будет возлагаться на производителей отдельных программных продуктов, а не на потенциально некомпетентное лицо или организацию.
Сторонники второго подхода, будем называть его нестандартизированным, предлагают полностью передать решение задач интероперабельности пользователям или третьим лицам. Приверженцы данного подхода категорически не принимают позицию глубокой стандартизации. Причины непринятия вышеизложенного способа интероперабельности заключается в ряде его недостатков:
отсутствует возможность учитывать нюансы быстро развивающейся компьютерной индустрии;
отсутствует возможность учитывать появление новых технологий.
отсутствует возможность учитывать способы и уровни безопасности хранимых и передаваемых данных;
некомпетентность отдельных сотрудников присуща фирмам производителям поставляемого программного обеспечения, что сказывается на корректности программных продуктов и корректности работы системы в целом. Следовательно вопрос компетентности на разных уровнях по-прежнему остался, зато исчезла потенциальная возможность дополнительного контроля выгружаемых данных, их корректности [1—3];
затрудняет исправления некорректных данных на этапе передачи информации;
необходимость постоянного утверждения новых стандартов, что потребует немедленного выпуска обновленного программного обеспечения и неопределенности с предыдущими стандартами;
требует дополнительного интерфейса в соответствии с утвержденными стандартами интероперабельности, поставляемого и изменяемого разработчиком, что увеличивает время решения проблемы соответствия последним стандартам, а значит, возможности пользоваться последними научными разработками и новыми технологиями в области компьютерной техники.
Следует упомянуть, что нестандартизированный способ интероперабель-ности имеет свои особенности и недостатки:
растет армия посредников, предлагающих услуги внедрения программного обеспечения, которые могут не иметь подготовку в данной области, т.е. могут предложить не квалифицированную помощь;
ответственность переходит с фирм-производителей программного обеспечения в области интероперабельности к третьим лицам, предлагающим и осуществляющим данную услугу;
требуется знать структуру метаданных «стыкуемого» программного обеспечения и хранимых данных;
безопасность передачи и безопасность хранения передаваемых данных будет полностью лежать на третьем лице, предлагающем услуги внедрения, и на фирме заказчике;
непосредственное участие в решении мелких задач сотрудников фирмы-заказчика.
В каждом из случаев имеются и свои положительные стороны, о которых также следует упомянуть. В стандартизированном способе:
нет необходимости привлечения третьих лиц для решения задач интеропе-рабельности;
не требуется в дальнейшем сотрудников, возможно, сторонних, которые будут обслуживать данное решение;
нет необходимости решать вопрос безопасности хранимых и передаваемых данных;
не требуется знать структуру метаданных программных продуктов. Имеются положительные стороны и в нестандартизированном способе решения задачи интероперабельности:
повышение скорости реакции на изменения бурно развивающего рынка информационных технологий;
создание более гибких способов настройки приема и передачи данных;
ВЕСТНИК AmiMt.
10/2013
возможность иметь в своем штате специалиста, способного выявить место возникновения проблемы в процессе интероперабельности как в самом программном обеспечении, структуре данных, так и в передаваемых данных.
Трудно умолчать и о третьем подходе к проблеме, который как таковой к интероперабельности никакого отношения не имеет, но он способен эту проблему искоренить. Это одна общая база данных, с огромным набором метаданных, которая затрагивает абсолютно все аспекты деятельности строительной организации. Понятно, что здесь вопроса интероперабельности нет, и встает вопрос уровней доступа отдельных сотрудников к определенному набору данных. Следует задумываться о способах предоставления информации для конечного пользователя, умениях и возможностях ограничить их права доступа. Возникают проблемы обновления базы данных, хранения данных огромных размеров, необходимости использования дорогостоящего серверного оборудования. Кто-то может сказать, что к поставленной проблеме эта возможность не относится и рассматривать ее не следует, но ее исключать из рассмотрения категорически нельзя, иначе проблема интероперабельности будет исключена, если все данные будут храниться в одной структуре информации.
Для многих уже очевидно, что принятие одной из сторон неприемлемо, хотя бы потому, что истина находится где-то посередине. Другими словами, следует искать решение, которое содержит смешанный способ использования системы программного обеспечения с возможностью интероперабельности как стандартизированной, так и нестандартизированной.
Трудно будет спорить с позицией, что ведение начислений по зарплате и кадровый учет следует вести в одной базе данных, а не разделять возможности приема, перемещения, увольнения в одну базу, ведение командировок, отпусков, больничных в другую базу, начисление заработной платы во вторую, а формирование отчетных форм в третью. Очевидно, что если не принять сотрудника на работу, то его нельзя отправить в командировку и начислить заработную плату. Если эту задачу реализовывать через интероперабельность, то в базу данных по начислению заработной платы придется вносить те же данные по сотруднику и по приказу о приеме или перемещении с указанием полагающейся заработной платы. Далее проводим расчет доходов сотрудника, а затем передаем эти данные с указанием данных сотрудника в базу, предназначенную для сбора данных и подготовки отчетов. Таким образом, третий вариант выхода из положения об интероперабельности здесь наиболее актуален, т.е. здесь должна быть единая база данных, иначе все три базы будут содержать практически одни и те же данные, синхронизация которых должна проводиться постоянно, практически в режиме on-line. При таком подходе к решению проблемы сеть будет перегружена.
Когда актуален первый способ интероперабельности, т.е. интероперабельность с высокой степенью стандартизации? Это актуально на этапе передачи отчетных данных в государственные налоговые органы контроля. На этом этапе известны форматы передаваемых данных, меняются они с предварительным оглашением новых утвержденных форматов. Эти форматы справедливы для всех видов организаций и способов передачи информации.
Все остальные способы интероперабельности должны иметь гибкий способ стандартизации, позволяющий получить максимальную отдачу от взаимосвязи с другими программными продуктами и системами.
Согласно исследованиям, соответствующим различным постановкам задач отрасли строительства [4—10], интероперабельность имеет более двадцати определений, ряд из них дают организации, решающие поставленные перед ними задачи взаимодействия программных продуктов. В соответствии с одним из выбранных определений ставятся определенные цели, задачи, способы достижения целей, методы решения задач. Никто не станет спорить с тем, что они тесно связаны с экономической составляющей предприятия, которому следует максимизировать свою прибыль, минимизировав затраты, в т.ч. затраты на приобретение программных продуктов, их освоение, введение их в интероперабельную систему организации, сопровождение данного продукта. Кроме экономической могут решаться и другие задачи: управление предприятием в условиях кризиса, управление предприятием в условиях чрезвычайных ситуациях, управление предприятием в условиях недостаточности квалифицированных специалистов. В соответствии с этим следует определиться с правилами и условиями выбора соответствующего программного обеспечения.
С одной стороны, решение о выборе интероперабельного программного продукта может полностью зависеть от принимаемого на работу сотрудника, который знает об используемом им программном продукте все и может использовать его возможности максимально. С другой стороны, выбирается единственно возможный и неимеющий конкуренции. С третьей стороны, конкретное программное обеспечение диктуется вышестоящей организацией или законодательством. Если не брать эти конечные ситуации, то выбор того или иного интероперабельного программного продукта может осуществляться согласно коэффициенту, который будет находиться по формуле
к = П Р, (1)
г=1
где ру — вероятность события «удовлетворенность выбранным программным продуктом», по У-му критерию из п возможных, т.е. 0 <рг- <1, для каждого У = 1... п, а значит и 0 < к < 1, т.е. она так же является вероятностью выбора данного интероперабельного программного продукта, которая есть произведение вероятностей «У-я удовлетворенность программой».
Приведем примеры того, каковы могут быть события удовлетворенности: ценой программного обеспечения; ценой сопровождения программы; уровнем качества сопровождения ПП; эффективностью использования; уровнем потребности в данном программном продукте; уровнем обучаемости данному программному продукту; уровнем соответствия критериям безопасности использования; уровнем понятности функций в программном обеспечении, его интерфейса, логики работы; уровнем интероперабельности программы; наличием специалистов, имеющих опыт работы с программным продуктом.
Этот перечень можно продолжать долго, но точно можно сказать, что он конечен, а значит, можно воспользоваться понятием простого или дискретного распределения величины к — вероятность выбора программного продукта. Переходя от общего к частному, можно заключить, что дискретное распределение можно применить и для вероятностей р где рк — вероятность события «удовлетворенность функцией» у выбранного программного продукта.
ВЕСТНИК лтчпл'».
10/2013
Следует упомянуть, что данный подход имеет особенность. Если есть категорическая неудовлетворенность одному из критериев, т.е. вероятность выбора по этому критерию равна нулю, то будет неудовлетворенность всем продуктом. Это означает, что при таком подходе наименее значимые критерии удовлетворенности следует исключить из рассмотрения. Однако если исключить незначимые и малозначимые критерии, то данный подход позволяет ярко показать, что данный программный продукт нас не устраивает.
Можно воспользоваться немного измененной формулой вероятности выбора интероперабельного программного продукта
п
Е р
к = . (2) п
Не следует путать числитель данной формулы с общепринятым понятием «математического ожидания дискретного распределения»:
ад
Р(Х = хй) = р, £р = 1, (3)
к=\
где X — дискретная случайная величина, имеющая распределение: Г ® Л
Р
Ер*
(4)
У
Понятно, что формула (2) — это среднеарифметическое значение вероятностей. При таком подходе исключили ошибку использования малозначимых удовлетворенностей, но приравняли их к значимым удовлетворенностям. Данная погрешность менее критична по сравнению с первым подходом, но дает шанс на жизнь тем разработкам программного обеспечения, которые в мелочах хороши, а в важных вещах категорически не устраивают. Какой подход использовать для принятия решения в выборе той или иной программы решает пользователь. Чтобы оставить максимальную достоверность при выборе программного обеспечения, рекомендуется ввести поправочный коэффициент ц, который соответствует уровню значимости удовлетворенностью программным продуктом и определяется человеком, или группой лиц, являющимися профессионалами в данной области. Тогда наша формула изменится и примет вид
п
Е^р
к = -. (5)
п
Очевидно, что если на рынке программного обеспечения имеется т их разновидностей, то выбор будет в пользу того программного обеспечения, которое находится по формуле
К = шах (к Д (6)
1< ] 1 '
где к. — вероятность выборау-го программного продукта из т возможных.
Теперь следует задуматься над тем, как подобрать набор программного обеспечения для создания корпоративного информационного пространства строительной организации, т.е. найти тот коэффициент, который позволит определить, насколько подборка программных продуктов удовлетворяет нашим критериям.
Обязательным критерием для всех без исключения программных продуктов является удовлетворенность интероперабельностью с другими программами комплекса. Тогда, не нарушая общности, можно заключить, что если взять конкретную разновидность программного обеспечения, то выбор падет на то программное обеспечение, результат выбора которого будет удовлетворять формуле (6). Для создания корпоративного информационного пространства, состоящего из г программных продуктов каждого необходимого направления деятельности, можно получить следующие выражения:
Ч = П К (7)
I=1
или
IРК
Ч = --, (8)
г
где К1 — максимальные вероятности выбора программного продукта 1-й направленности из г необходимых направлений; Р1 — поправочный коэффициент потребности в выбираемом программном продукте.
Как и с выбором интероперабельного программного обеспечения, не входящего в состав корпоративного, получаем, что наименее важные программные продукты могут негативно влиять на весь подбор комплекса интероперабельного корпоративного информационного пространства при выборе формулы (7). Если использовать формулу (8), то можно учесть не всегда положительную особенность при выборе программных продуктов.
Следует определиться с правилами задачи поправочных коэффициентов. Рекомендуется их использовать таким образом, чтобы
I ^ = 1 (9)
i=1
и
= 1. (10)
1=1
Количество комбинаций набора программных продуктов, необходимых для создания интероперабельного корпоративного пространства, зависит от количества требуемого программного обеспечения. Допустим, оно имеет 5 вариаций, тогда для создания интероперабельного корпоративного пространства с высоким уровнем отдачи требуется тот набор, который соответствует формуле
6 = шах(?г). (11)
1< г < х
Подводя итог вышесказанного, можно получить 4 варианта критерия выбора наилучшей подборки программных продуктов интероперабельного корпоративного информационного пространства:
( г / ЛЛ Л
г п \ \
Q = тах
1< z <s
Z I max I Z
у = { 0<jm y ,=1 j
(12)
где вместо знака произведений можно использовать знак суммы. Выбор критерия оценки выбора по-прежнему остается за теми, кто занимается системами.
ВЕСТНИК AmiMt.
10/2013
Анализируя все вышеизложенное, получаем, что данная задача является нетривиальной и имеет большое количество способов решения, каждый из которых будет являться оптимальным при определенных критериях удовлетворенности отдельными функциями отдельных программных продуктов, с одним общим критерием для всех программ — возможностью интероперабель-ности внутри системы с программами вне корпоративной системы.
Библиографический список
1. Волков А.А. Системы активной безопасности строительных объектов // Жилищное строительство. 2000. № 7. С. 13.
2. Волков А.А. Иерархии представления энергетических систем // Вестник МГСУ 2013. № 1. С. 190—193.
3. Sedov A., Volkov A., Chelyshkov P. Usage of building information modeling for evaluation of energy efficiency. Applied Mechanics and Materials (Trans Tech Publications, Switzerland). 2013, vol. 409—410, pp. 630—633.
4. Volkov A., Sukneva L. Programming applications of computer aided design and layout of the complex solar panels. Applied Mechanics and Materials (Trans Tech Publications, Switzerland). 2013, vol. 411—414, pp. 1840—1843.
5. Волков А.А., Ярулин Р.Н. Автоматизация проектирования производства ремонтных работ зданий и инженерной инфраструктуры // Вестник МГСУ 2012. № 9. С. 234—240.
6. Волков А.А., Игнатов В.П. Мягкие вычисления в моделях гомеостата строительных объектов // Вестник МГСУ 2010. № 2. С. 279—282.
7. Волков А.А., Воднев Н.Н. Системотехника численных представлений качественных параметров среды жизнедеятельности: рекурсивное погружение на уровни детализации объекта // Промышленное и гражданское строительство. 2013. № 7. С. 29—32.
8. Волков А.А. Гомеостатическое управление зданиями // Жилищное строительство. 2003. № 4. С. 9—10.
9. Волков А.А. Безопасность строительных объектов в чрезвычайной ситуации // Сельское строительство. 2000. № 3. С. 42—43.
10. Волков А.А., Пихтерев Д.В. К вопросу об организации информационного обеспечения строительного объекта // Вестник МГСУ 2011. № 6. С. 460—462.
Поступила в редакцию в октябре 2013 г.
Об авторе: Аникин Дмитрий Васильевич — инженер отдела корпоративных информационных систем, ФГБОУ ВПО «Московский государственный строительный университет» (ФГБОУ ВПО «МГСУ»), 129337, г. Москва, Ярославское шоссе, д. 26, AnikinDB@mgsu.ru.
Для цитирования: Аникин Д.В. Критерии оценки применения интероперабельно-сти, заданные условиями принятия решения // Вестник МГСУ. 2013. № 10. С. 249—257.
D.V. Дшкш
EVALUATION CRITERIA OF INTEROPERABILITY SET BY THE DECISION-MAKING
CONDITIONS
The article states the necessity of selecting software products that make up the corporate information space. The reason for establishing interoperability of enterprise information systems is justified. Two extreme approaches to the interoperable space formation were mentioned. Various criteria for choosing the optimal set of software products are offered. The question about the level of interoperability standards of corporate information space is raised. The author offers an option of choosing interoperable software products for a company in accordance with a certain coefficient. This coefficient is the
probability of the event "satisfaction with the selected software product" by /'-criterion of n-possible. These criteria should be worked out by a board of competent staff of a company taking into account the optimization tasks and the problems set.
This approach is based on the concept of simple and discrete distribution of coefficients. In the formula it is proposed to use a correction factor which corresponds to the level of satisfaction with the software. It is determined by a person or a group of persons - professionals in the field. It is also required to find another coefficient pl — the need in selectable software product.
It is known that interoperable enterprise information environment consists of a set of interoperable enterprise information spaces. Each of them has a number of functions. These functions have a their own level of importance. Then end result of software products selection is the reduction up to four types of formulas.
We give the positive side of selection using coefficients, they produce a summation or multiplication. Negative aspects of each approach are also discussed. The final selection process of interoperable enterprise information space on the basis of these coefficients should be made by a competent board of a company.
Key words: evaluation criteria, information system, probability, selection conditions, correction factor, interoperability.
References
1. Volkov A.A. Sistemy aktivnoy bezopasnosti stroitel'nykh ob"ektov [Active Safety Systems of Construction Sites]. Zhilishchnoe stroitel'stvo [House Construction]. 2000, no. 7, p. 13.
2. Volkov A.A. Ierarkhii predstavleniya energeticheskikh sistem [Hierarchies of Description of Energy Systems]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering]. 2013, no. 1, pp. 190—193.
3. Sedov A., Volkov A., Chelyshkov P. Usage of Building Information Modeling for Evaluation of Energy Efficiency. Applied Mechanics and Materials (Trans Tech Publications, Switzerland). 2013, vol. 409—410, pp. 630—633.
4. Volkov A., Sukneva L. Programming Applications of Computer Aided Design and Layout of the Complex Solar Panels. Applied Mechanics and Materials (Trans Tech Publications, Switzerland). 2013, vol. 411—414, pp. 1840—1843.
5. Volkov A.A., Yarulin R.N. Avtomatizatsiya proektirovaniya proizvodstva remontnykh rabot zdaniy i inzhenernoy infrastruktury [Computer-Aided Design of Repairs of Buildings and the Engineering Infrastructure]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering]. 2012, no. 9, pp. 234—240.
6. Volkov A.A., Ignatov V.P. Myagkie vychisleniya v modelyakh gomeostata stroi-tel'nykh ob"ektov [Soft Computing of the Homeostat Models of Buildings]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering]. 2010, no. 2. pp. 279—282.
7. Volkov A., Vodnev N.N. Sistemotekhnika chislennykh predstavleniy kachestvennykh parametrov sredy zhiznedeyatel'nosti: rekursivnoe pogruzhenie na urovni detalizatsii ob"ekta [Numerical Representation System Engineering of the Quality Parameters of Living and Working Environment: Recursive Exposure into Detailization Levels of an Object]. Promyshlennoe i grazhdanskoe stroitel'stvo [Industrial and Civil Engineering]. 2013, no. 7, pp. 29—32.
8. Volkov A.A. Gomeostaticheskoe upravlenie zdaniyami [Homeostatic Management of Buildings]. Zhilishchnoe stroitel'stvo [House Construction]. 2003, no. 4, pp. 9—10.
9. Volkov A.A. Bezopasnost' stroitel'nykh ob"ektov v chrezvychaynoy situatsii [Safety of Construction Projects in Emergency Situations]. Sel'skoe stroitel'stvo [Rural Construction]. 2000, no. 3, pp. 42—43.
10. Volkov A.A., Pikhterev D.V. K voprosu ob organizatsii informatsionnogo obespech-eniya stroitel'nogo ob"ekta [On the Issue of Arrangement of Information Support of a Construction Facility]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering]. 2011, no. 6, pp. 460—462.
About the author: Anikin Dmitrii Vasilevich — Engineer, Department of Enterprise Information Systems, Moscow State University of Civil Engineering (MGSU), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; AnikinDB@mgsu.ru.
For citation: Anikin D.V. Kriterii otsenki primeneniya interoperabel'nosti, zadannye uslovi-yami prinyatiya resheniya [Evaluation Criteria of Interoperability Set by the Decision-making Conditions]. Vestnik mGsU [Proceedings of Moscow State University of Civil Engineering]. 2013, no. 10, pp. 249—257.
