CC BY
74
4. Николайчук О.А., Павлов А.И., Юрин А.Ю. Компонентный подход: модуль продукционной экспертной системы // Программные продукты и системы. 2010. № 3. С. 41-44.
5. Юрин А.Ю., Грищенко М.А. Редактор баз знаний в формате CLIPS // Программные продукты и системы. 2012. № 4. С. 83-87.
References
1. Jess, the Rule Engine for the Java TM Platform, available at: http://www.jessrules.com/ (accessed 28 March 2013).
2. The Protégé project, available at: http://protege.stan-ford.edu/ (accessed 28 March 2013).
3. Gribachev K.G., Delphi i Model Driven Architecture. Razrabotka prilozheniy baz dannykh [Delphi i Model Driven Architecture. Data bases applications development], Piter, 2004.
4. Nikolaychuk O.A., Pavlov A.I., Yurin A.Yu., Pro-grammnye produkty i sistemy [Software & systems], 2010, no. 3, pp. 41-44.
5. Yurin A.Yu., Grishchenko M.A., Programmnyeprodukty i sistemy [Software & systems], 2012, no. 4, pp. 83-87.
УДК 519.816
ПРЕДПОСЫЛКИ УНИФИКАЦИИ ПРОГРАММНЫХ СРЕДСТВ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
(Работа выполнена при поддержке гранта РФФИ № 13-01-00895 А)
В.П. Осипов, к.т.н., доцент, ведущий научный сотрудник;
Т.В. Сивакова, младший научный сотрудник; В.А. Судаков, к.т.н., доцент, старший научный сотрудник (Институт прикладной математики им. М.В. Келдыша РАН, Миусская пл., 4, г. Москва, 125047, Россия, [email protected], [email protected], [email protected])
Рассматриваются вопросы разработки систем поддержки принятия решений (СППР), инвариантных по отношению к предметной области. Предлагается унифицированный подход к созданию СППР, включающий следующие принципы: свобода от субъективизма разработчиков, инвариантность по отношению к предметной области, множественность методов поддержки решений, субъективизм лица, принимающего решения, и дружелюбность по отношению к нему. Архитектура СППР, реализующая указанные принципы, строится на каркасном подходе. Каркас отвечает за механизм описания пространства критериев и параметров модели предметной области, позволяет пользователю выбирать методы поддержки решений и организует информационный обмен между ними, обеспечивает хранение, отображение и редактирование атрибутов альтернатив, обеспечивает контроль доступа. Все множество вариативных поведений СППР выделяется в модули, которые подключаются через точки расширения. Даны некоторые правила качественной разработки СППР. Предложены характеристики оценки качества, включая свойства, присущие методу поддержки решений, и свойства, присущие программной реализации метода. Предложенные методологические основы с успехом применены при создании СППР «Космос», которая используется в ранжировании заявок на научно-прикладные исследования на Российском сегменте Международной космической станции.
Ключевые слова: система поддержки решений, унифицированный подход, качество программного обеспечения, трехзвенная архитектура.
THE BACKGROUND FOR DECISION SUPPORT TOOLS SOFTWARE UNIFICATION Osipov V.P., Ph.D., associate professor, leading research associate; Sivakova T. V. , junior researcher; Sudakov V. A, Ph.D., associate professor, senior researcher (Keldysh Institute of Applied Mathematics, Miusskaya Sq., 4, Moscow, 125047, Russia, [email protected], [email protected], [email protected]) Abstract. The paper describes the development of decision support systems (DSS) that are invariant with respect to the domain area. A unified approach to the DSS is provided. It includes the following principles: no developers' subjectivity, the domain area invariance, decision support methods multiplicity, decision maker subjectivity and usability. DSS architecture, that implements these principles, based on the frame approach. The framework is responsible for the mechanism of describing domain model criteria and parameters, allows the user to choose their decision support methods and organizes the information exchange between them, provides storaging, displaying and editing the alternatives attributes, provides access control. The entire set of variable DSS behavior stands out in the modules that are connected via extension points. The article provides some guidelines of DSS quality design. It also proposes the characteristics for quality evaluation including the decision support method properties and software implementation properties of the method. The proposed methodological framework is successfully used to design the DSS COSMOS which is used in the ranking of applications for scientific and applied research on the International Space Station Russian segment.
Keywords: decision support system, unified approach, software quality, three-tier architecture.
Анализ структуры и процессов разработки компьютерных систем поддержки принятия решений (СППР), таких как DSS/UTES, СППР «Космос», Автоматизированная система мониторинга
муниципальных образований, АСКУ, АСМ ВУЗ [1, 2], позволил оценить предпосылки и сформулировать общие принципы унификации этапов проектирования и разработки компонентов СППР.
По мнению авторов, основная потребность в унификации связана со стремлением сделать максимально широким и доступным весь набор информационных и аналитических ресурсов и сервисов для аналитиков и ЛПР. Современные методы системного и информационного моделирования бизнес-процессов (например технология SADT, язык ЦМЬ), методы проектирования и системной интеграции информационно-аналитических систем дают возможность не только формализовать с использованием унифицированных подходов основные процедуры выработки и обоснования решений, рекомендуемые теорией, но и предложить решение по программной реализации ресурсов и сервисов СППР, инвариантных по отношению к предметной области.
Обобщенная схема принятия решений, представленная в работе [3], включает следующие этапы:
- выявление предпочтений ЛПР в формировании критериев;
- использование субъективных предпочтений ЛПР в оценке ситуации (анализе результатов мониторинга [4]);
- использование субъективных предпочтений ЛПР в процессе генерации возможных управленческих решений;
- оценка альтернатив управленческих решений с учетом предпочтений ЛПР;
- учет предпочтений ЛПР в прогнозе результатов принимаемых решений;
- согласование групповых решений;
- выбор лучшего, с точки зрения ЛПР, варианта решения.
Анализ данной схемы принятия решений позволил сформулировать определенные принципы, соблюдение которых, по мнению авторов, должно лежать в основе формирования унифицированных требований к программным средствам информационно-аналитической поддержки принятия решений, обеспечивающих приоритет интересов пользователей СППР, прежде всего ЛПР.
Унифицированный подход к разработке ПО СППР состоит из совокупности принципов проектирования, каркасного подхода к разработке архитектуры ПО, шаблона правил качественного кодирования, а также набора характеристик оценки качества.
Покажем, что скрывается под каждой из позиций. Унификация заключается в том, что все эти методические рекомендации применимы независимо от того, в какой предметной области необходимо решать задачи поддержки решений. Конечно, некоторые предметные области могут потребовать специфичных проектных решений, но они не противоречат предложенному унифицированному подходу, а лишь дополняют его.
Предполагается, что при проектировании и сборке ПО СППР используются следующие принципы.
Принцип свободы от субъективизма разработчиков. Система должна быть максимально гибкой и подстраиваться под нужды и потребности пользователя. При этом настройка решающих правил должна выполняться в интерфейсе системы пользователем без необходимости изменения исходных текстов ПО.
Принцип инвариантности по отношению к предметной области. ПО СППР должно включать реализацию широкого набора методов работы с векторным критерием, методов оптимизации, содержать инструменты выявления предпочтений пользователя. Программная реализация этих методов достаточно трудоемка, при этом сами методы не привязаны к конкретной предметной области, поэтому целесообразно разрабатывать унифицированную архитектуру СППР, которая способна работать с произвольной предметной областью.
Принцип множественности методов. Существует множество методов принятия решений. СППР должна обеспечивать легкую и прозрачную интеграцию требуемых методов, советовать пользователю, какой метод в данном случае лучше применить и почему, но не настаивать на нем.
Принцип субъективизма ЛПР. ЛПР наделено полномочиями и несет ответственность за принимаемые решения. Решения, которые предлагает СППР, должны отражать опыт, квалификацию и предпочтения ЛПР. После первоначальной настройки результаты работы СППР часто не устраивают ЛПР, поэтому нужно предусмотреть процедуру обратного вывода, которая сможет объяснить, какие предпочтения привели к полученному результату и что нужно изменить, чтобы результат работы выглядел иначе.
Принцип дружелюбности к ЛПР. Для работы с СППР не следует требовать от ЛПР специальных знаний теории принятия решений. Интерфейс системы должен наглядно показывать ЛПР все настройки и предпочтения на минимальном количестве экранных форм. СППР должна содержать механизм выявления противоречий в суждениях ЛПР и указывать на них.
Архитектура СППР, реализующая указанные принципы, строится на каркасном подходе [5]. В этом подходе каркас отвечает за базовое поведение, а все множество вариативных поведений СППР выделяется в модули, которые подключаются через точки расширения. Каркас СППР выполняет следующие функции:
- реализует механизм описания пространства критериев и параметров модели предметной области;
- позволяет пользователю выбирать методы поддержки решений и организует информационный обмен между ними;
- обеспечивает хранение, отображение и редактирование атрибутов альтернатив;
- обеспечивает контроль доступа.
Альтернативы могут вводиться пользователем в интерфейсе СППР, импортироваться и экспортироваться из внешней системы или генерироваться поисковыми методами оптимизации. Контроль доступа должен быть организован как к отдельным функциям СППР, так и к отдельным критериям и альтернативам.
Остальные функции СППР реализуются через следующие точки расширения (гнезда) каркаса:
- ввод и редактирование предпочтений ЛПР;
- описание системы ограничений для параметров модели предметной области с целью определения множества допустимых решений;
- описание модели предметной области, в том числе связей между параметрами модели предметной области и критериями эффективности найденных решений;
- многокритериальная оценка или кластеризация альтернатив с учетом введенных предпочтений;
- поиск допустимых решений выбранным методом оптимизации;
- экспорт и импорт данных.
При настройке соответствующего модуля в точке расширения указывается, для какого подмножества альтернатив и критериев он будет использоваться.
На рисунке приведена схема СППР «Космос», созданная на базе данных принципов. Программа реализована в трехзвенной архитектуре: сервер СУБД MS SQL Server, промежуточный уровень -MS Internet Information Server, тонкий клиент -Mozilla Firefox. Разработка велась с использованием языков C#, TSQL, JavaScript.
Разработка ПО базируется на принципах открытости по отношению к новым методам свертки векторного критерия и новым методам оптимизации. Все исходные тексты помещены в открытом репозитории http ://code.google.com/p/microgravi-ty/source/browse/.
Структура БД разрабатывается так, чтобы систему можно было настраивать на решение задач из различных предметных областей в единой информационной среде. Таким образом, при разработке СППР обеспечивается свойство инвариантности их использования по отношению к предметной области.
При программной реализации СППР крайне важно обеспечить высокий уровень качества создаваемого ПО. Рассмотрим некоторые правила качественной разработки, применявшиеся при создании СППР «Космос».
• Все исходные тексты программ, кроме временных скриптов, должны храниться в единой системе контроля версий.
• Недопустимо дублирование одной и той же логики в разных частях кода без веских оснований. Основаниями могут быть техническая невозможность избежать дублирования, обусловленная спецификой среды разработки, и невозможность иного способа достижения приемлемой производительности.
• Недопустимо использование в коде магических чисел. В программе не должно быть закомментированного кода.
• Переменные, структуры данных, таблицы должны объявляться в начале каждого скрипта, в других местах их объявление недопустимо.
• Все добавления, изменения и удаления в таблицах должны сохраняться в таблице журнала изменений.
• Все скрипты должны быть в единой кодировке (рекомендуется выбрать UTF-8).
• Группу связанных изменений БД необходимо выполнять внутри транзакции.
• Названия любых объектов (переменные, поля, таблицы) должны отражать смысл своих значений.
• В части FROM запроса после присоединения новой таблицы оператором JOIN в условии ON должны встречаться только поля логического первичного ключа присоединенной таблицы, при этом должны встречаться все поля этого первичного ключа.
• Если есть условия, непосредственно не связанные с правилом объединения связываемых таблиц, а накладывающие ограничения на итоговый результирующий набор данных, они записываются в секции WHERE запроса.
Тонкий клиент
Веб-браузер
Редактор критериев
Редактор системы ценностей
Редактор альтернатив
Редактор оценок альтернатив
Мониторинг результатов
Уровень СУБД
Хранимые процедуры многокритериальной оценки
О
Хранимые процедуры оптимизации
БД
А
Структура ПО СППР «Космос»
• Во всех случаях, кроме разовых временных запросов, недопустимо использовать конструкцию SELECT INTO для создания таблиц, таблица должна быть явно создана в начале скрипта.
• При объединении двух таблиц всегда необходимо использовать оператор JOIN, а при выполнении внешнего объединения - LEFT OUTER JOIN.
• Курсоры и циклы в SQL допустимо использовать только в том случае, когда задачу нельзя решить иначе.
• Если в select размещено более одной таблицы, то ссылка на поля без имени или псевдонима имени таблицы запрещена.
• Результат не должен зависеть от не контролируемого разработчиком порядка выборки данных самим SQL-сервером. Запрещено использовать top без order by.
• Все свойства форматирования веб-страниц должны устанавливаться через CSS-файл.
• Обращение к БД с веб-сервера должно происходить только через хранимые процедуры.
Таким образом, достигается оперативность изменений бизнес-логики, повышаются производительность и гибкость, обеспечивается более высокий уровень безопасности.
Список этих правил не претендует на полноту. Он возник из опыта разработки ряда СППР и систем мониторинга. На основе этого списка правил проектировщик СППР должен разрабатывать свой список, специфичный для выбранных средств разработки и с учетом мнения коллектива программистов. Важно, чтобы среди всех разработчиков СППР было достигнуто согласие относительно этих правил.
СППР должна содержать рекомендации по выбору метода принятия решений. Причем этот выбор зависит от множества условий, которые накладываются конкретной решаемой задачей. Кроме самого метода, важно качество его программной реализации. Необходимо учесть пожелания ЛПР по точности решения, возможным трудозатратам, быстродействию и другим моментам. Все эти факторы могут быть разделены на две группы: свойства, присущие методу поддержки решений, и свойства, присущие программной реализации метода поддержки решений.
Первая группа свойств:
- точность;
- трудоемкость;
- размерность по числу критериев, числу градаций на шкалах, числу альтернатив;
- алгоритмическая сложность;
- понятность;
- требования к исходным данным (качественные оценки, количественные оценки, нечеткие оценки).
Свойства программной реализации СППР должны оцениваться по существующим стандартам качества [6]. К требуемым свойствам программной реализации СППР относятся следующие:
- удобство интерфейса, простота изучения и простота использования;
- эффективность по времени отклика системы, времени поиска решения;
- эффективность использования ресурсов (оперативной памяти тонкого клиента, процессоров серверов и клиентов, внешних запоминающих устройств);
- переносимость;
- масштабируемость;
- интегрируемость;
- надежность;
- защищенность.
Данные методологические основы разработки систем поддержки решений были успешно использованы в СППР «Космос», применявшейся в задаче формирования этапной программы научно-прикладных исследований и экспериментов, планируемых на Российском сегменте МКС [1].
Литература
1. Осипов В.П., Судаков В.А., Хахулин Г.Ф. Информационные технологии формирования этапной программы научно-прикладных исследований на Российском сегменте Международной космической станции // Вестн. компьютерных и информационных технологий. 2012. № 12. C. 24-28.
2. Бомас В.В., Судаков В.А. Поддержка субъективных решений в многокритериальных задачах. М.: Изд-во МАИ, 2011.
3. Трахтенгерц Э.А. Компьютерная поддержка принятия решений. М.: СИНТЕГ, 1998.
4. Сивакова Т.В. Компьютерный мониторинг космических экспериментов // NPNJ'2012: матер. IX междунар. конф. по неравновесным процессам в соплах и струях. М.: МАИ-ПРИНТ, 2012. C. 622-623.
5. Горбунов-Посадов М.М. Расширяемые программы. М.: Полиптих, 1999.
6. Судаков В.А. Автоматизация процесса управления разработкой корпоративной информационной системы // Вестн. МАИ. 2010. Т. 17. № 1. C. 149-153.
References
1. Osipov V.P., Sudakov V.A., Khakhulin G.F., Vestnik kompyuternykh i informatsionnykh tekhnology [The bulletin of computer and IT], 2012, no. 12, pp. 24-28.
2. Bomas V.V., Sudakov V.A., Podderzhka subyektivnykh resheny v mnogokriterialnykh zadachakh [Subjective decision support in multiobjective problems], Moscow, MAI Press, 2011.
3. Trakhtengerts E.A., Kompyuternaya podderzhka prinya-tiya resheny [Computer-based support of decision making processes], Moscow, SINTEG, 1998.
4. Sivakova T.V., Materialy IX mezhdunar. konf. po neravnovesnym protsessam v soplakh i struyakh (NPNJ'2012) [Proc. of 9th int. conf. on nonequilibrium processes in orifices and streams], Moscow, MAI-PRINT, 2012, pp. 622-623.
5. Gorbunov-Posadov M.M., Rasshiryaemye programmy [Expanded programs], Moscow, Poliptikh, 1999.
6. Sudakov V.A., Vestnik Moskovskogo aviatsionnogo instituta [The Bulletin of Moscow Aviation Institute], Vol. 17, no. 1, pp. 149-153.
УДК 004.413
МИНИМИЗАЦИЯ РИСКОВ ПРИ РАЗРАБОТКЕ ПРОГРАММНЫХ СРЕДСТВ
В.В. Бахтизин, к.т.н., доцент; А.А. Кузиков, м.т.н., аспирант (Белорусский государственный университет информатики и радиоэлектроники, ул. П. Бровки, 6, г. Минск, 220013, Республика Беларусь, [email protected]; [email protected])
Рассматриваются проблемы, с которыми сталкиваются команды, разрабатывающие программные средства по методологии Scrum, а также влияние на качество программных средств неразрешение этих проблем. Предложены метрики, позволяющие количественно оценивать риски несвоевременного выполнения работ, связанные с простоем отдельных членов команды и неоптимальной декомпозицией запланированных работ на задачи. Предлагается метод, ориентированный на минимизацию рисков, которые связаны с неэффективной занятостью членов Scrum-команды в процессе итерации. Представлены алгоритмы для применения предложенного метода на этапах планирования и выполнения работ процесса разработки, организованного в соответствии с методологией Scrum.
Ключевые слова: гибкая методология разработки, качество программных средств, минимизация рисков, гибкое управление проектами.
SOFTWARE DEVELOPMENT RISKS MANAGEMENT Bakhtizin V. V., Ph.D., associate professor; Kuzikov A A, MscIT, postgraduate (Belarusian State University of Information Science and Radioelectronics, P. Brovki St., 6, Minsk, 220013, Belarus, [email protected], [email protected]) Abstract. The article examines the obstacles that are usual for software development teams working with the Scrum methodology and the impact on software quality. The authors propose a method aimed at risks minimizing when risks are connected with ineffective productivity time of Scrum-team members during Scrum iteration. The paper suggests the measures that help in the risks quantitative assessment for late performances when the risks are linked with team members' idle time and non-optimal decomposition of scheduled work.
There are algorithms to apply the method on planning and implementation stages of the Scrum development process. Keywords: agile software development, software quality, risks minimizing, agile project management.
Многие компании сегодня рассматривают возможность перехода к инкрементной и эволюционной моделям процесса разработки программных средств (ПС), так как каскадная модель процесса разработки ПС имеет ряд недостатков [1, 2]. Более того, применение гибких методологий обусловлено необходимостью выпуска качественных ПС раньше конкурентов. Гибкие методологии разработки ПС, детализирующие и расширяющие инкрементную модель, а также хорошо зарекомендовавшие себя в условиях меняющихся требований, адаптированы и достаточно широко применяются в реальных проектах.
Среди многообразия существующих гибких методологий одно из лидирующих мест занимает методология Scrum, которая, предоставляя каркас организации и управления процессом разработки ПС, успешно сочетается с методологиями, ориентированными на различные инженерные практики [3, 4], например, экстремальное программирование и разработку, управляемую тестами. Методология Scrum благодаря своей относительной простоте и адаптируемости широко используется компаниями, предоставляющими услуги по разработке и тестированию ПС.
Как правило, Scrum-команда выполняет разработку ПС по требованиям заказчика, представленным в журнале требований к продукту в виде историй в течение итераций продолжительностью от двух до шести недель [3-5]. Фиксированные временные рамки обусловливают выполнение только полезных и важных заказчику требований и вы-
пуск работоспособных версий ПС на регулярной основе. Кроме того, декомпозиция требований на отдельные задачи всячески стимулирует членов команды к сотрудничеству, постоянному отслеживанию зависимости своих задач от результатов работы других членов.
Тем не менее Scrum-команды нередко сталкиваются с проблемами невыполнения работ, запланированных в рамках итерации, вследствие изменения цели итерации, вызванного непредвиденной сменой приоритетов пользовательских требований, и срыва графиков выполнения запланированных работ [5]. Как правило, риски, связанные с изменением цели итерации, предусмотреть сложно. Однако оценить риски невыполнения запланированных работ в рамках итерации и управлять ими вполне возможно.
Проблема срыва графиков выполнения работ в течение итерации
Согласно методологии Scrum, истории, выбранные для реализации в рамках итерации, можно рассматривать как достаточно независимые участки работы. Однако между задачами, на которые декомпозирована каждая история, как правило, существуют взаимосвязи, определяющие порядок их выполнения членами Scrum-команды. Пренебрежение данными взаимосвязями зачастую приводит к тому, что отдельные члены команды получают возможность приступить к выполнению назначенных им задач ближе к концу итерации.
