Научные стремления 2012-1

Результаты Для оценки работы фреймворка был проведѐн ряд экспериментов на

тестовой базе и по методике, представленным в [3]. Результаты исследования показали сокращение ошибки определения положения головы в 1,5- 2 раза (по сравнению с результатами, представленными в [3]), а также существенное увеличение скорости работы алгоритма.

Разработанный алгоритм трэкинга был использован в коммерческом приложении «Виртуальный магазин очков» компании «Moda e Technologia» (http://www.onstageinterattivo.it/).

Литературные источники

1.Murphy-Chutorian, E. Head Pose Estimation in Computer Vision: A Survey / E. Murphy-Chutorian, M.M. Trivedi // IEEE Transactions on Pattern Analysis and Machine Intelligence.

–Vol. 31, No. 4, 2009. – pp. 607-626.

2.Bruhn, A. Lucas-Kanade meets Horn-Schunk: combining local and global optic flow methods / A. Bruhn, J. Weikert, C. Schnorr // Internation Journal on Computer Vision. – Vol. 61, No.3, 2005. – pp. 211-231.

3.La Cascia. M. Fast, Reliable Head Tracking under Varying Illumination / M. La Cascia, S. Sclaroff, V. Athitsos // IEEE Transactions on Pattern Analysis and Machine Intelligence. – Vol. 22, No.4, 2000. – pp. 322-336.

Iskra N.A., Iskra V.V.

A FRAMEWORK FOR OBJECT SPATIAL ORIENTATION RESTORATION USING OPTICAL FLOW

Belarusian State University of Informatics and Radioelectronics, Minsk

Summary

This thesis presents a framework for object spatial orientation restoration in real-time. We present the technique for head movements tracking based on the optical flow algorithm. Our framework shows high rates of correct head spatial orientation estimation, appears to be robust and effective in real-time and therefore can be implemented in so-called augmented reality applications.

431

УДК 519.8

Клюкин Леонид Викторович

Моделирование соотношение генов в биологических системах используя теорию игр

ГУО «Средняя школа №4 города Жодино»

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

Целью работы определить соотношение генов в биологических системах. Для выполнения цели работы поставлены следующие задачи:

1)«Создать» компьютерную программу среду для моделирования.

2)Изучить литературу по данной теме

3)Создать гены

4)Проследить частоту появления генов в среде

Диллема заключенного из теории игр

Классическая формулировка дилеммы заключѐнного такова:

Двое преступников, А и Б, попались примерно в одно и то же время на сходных преступлениях. Есть основания полагать, что они действовали по сговору, и полиция, изолировав их друг от друга, предлагает им одну и ту же сделку: если один свидетельствует против другого, а тот хранит молчание, то первый освобождается за помощь следствию, а второй получает максимальный срок лишения свободы (10 лет). Если оба молчат, их деяние проходит по более лѐгкой статье, и они приговариваются к 6 месяцам. Если оба свидетельствуют против друг друга, они получают минимальный срок (по 2 года

Игру можно представить в виде следующей таблицы:

Дилемма появляется, если предположить, что оба заботятся только о минимизации собственного срока заключения.

Представим рассуждения одного из заключѐнных. Если партнѐр молчит, то лучше его предать и выйти на свободу (иначе — полгода тюрьмы). Если партнѐр свидетельствует, то лучше тоже свидетельствовать против него, чтобы получить 2 года (иначе — 10 лет). Стратегия «свидетельствовать» строго доминирует над стратегией «молчать». Аналогично другой заключѐнный приходит к тому же выводу.

С точки зрения группы (этих двух заключѐнных) лучше всего сотрудничать друг с другом, хранить молчание и получить по полгода, так как

432

это уменьшит суммарный срок заключения. Любое другое решение будет менее выгодным.

В дилемме заключѐнного предательство строго доминирует над сотрудничеством, поэтому единственное возможное равновесие — предательство обоих участников. Проще говоря, не важно, что сделает другой игрок, каждый выиграет больше, если предаст. Поскольку в любой ситуации предать выгоднее, чем сотрудничать, все рациональные игроки выберут предательство.

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

Примеры с заключѐнными, показаться надуманными, но на самом деле есть множество примеров взаимодействия людей и животных, имеющие такую же матрицу выигрышей. Поэтому ДЗ представляет интерес социальным наукам, таким как экономика, политология и социология, а также разделам биологии — этологии и эволюционной биологии. Многие природные процессы были обобщены в модели, в которых живые существа участвуют в бесконечных играх типа дилеммы заключѐнного. Такая широкая применимость ДЗ придаѐт этой игре значительную важность.

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

Игровые стратегии

Мы будем использовать 14 стратегий описанных на языке программирования Delphi, которые условно можно поделить на две группы:

1)«хорошие парни» сами первые не когда не играют ОТКАЗЫВАЮСЬ

2)«плохие парни» могут сыграть отказываюсь первыми ОТКАЗЫВАЮСЬ

Хорошие парни описание стратегий

1)«Добро»

Всегда, чтобы не произошло играет КООПЕРИРУЮСЬ.

2)«Око за око»

433

Первый раз играет кооперируюсь, а потом так, как соперник в преведущем ходе.

3)«Око за око с прощением»

То же, что и Око за око, но чтобы избежать серию взаимных отказов, может случайным образом сыграть КООПЕРИРУЮСЬ.

4)«Злопамятен». Сотрудничает до первого предательства.

5)«Менее злопамятен». Сотрудничает до двух первых предательств.

6)«Сотрудничать в среднем»

Сотрудничает, если в среднем количество кооперируясь у противника было больше, чем количество предательств.

Плохие парни описание стратегий

1)«Зло»

Всегда, чтобы не произошло играет ОТКАЗЫВАЮСЬ

2)«Рандом» Ходит случайным образом

3)«Пакостник»

Играет всегда, КООПЕРИРУЮСЬ, но каждый двадцатый ход ОТКАЗЫВАЮСЬ

4)Пакостник с извинениями

Тоже, что и пакостник, но после пакости прощает соперника, если тот его наказывает, то есть дает возможность один раз отомстить без последствий для соперника.

5)«Ответ на пакость»

Делает ОТКАЗЫВАЮСЬ случайным образом и пока ему за это не отомстят играет постоянно ОТКАЗЫВАЮСЬ

6)«Зеркальное око»

Тоже, что и око за око, но наоборот на хороший ход отвечает плохим, а на плохой хорошим.

434

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

Литературные источники

1.Доукинс Ричард Эгоитический ген

Leonid Victorivich Klukin

MODELING THE RELATIONSHIP OF GENES IN BIOLOGICAL SYSTEMS USING GAME THEORY

"High school № 4 Zhodino"

Summary

The paper deals with modeling of social processes in the built environment. Simulated behavior strategies and found that provide the maximum benefit.

435

УДК 330.47: 519.87

Кратенок А.А.

ИССЛЕДОВАНИЕ МЕТОДОВ И СРЕДСТВ ОЦЕНКИ СТОИМОСТИ ITПРОЕКТОВ

Белорусский государственный университет информатики и радиоэлектроники, Минск

Актуальность данной темы заключается в том, что существует реальная потребность в разработке методов и средств, позволяющих менеджеру ITпроектов оценить требуемые ресурсы на основе всех имеющихся характеристик проекта: истории подобных проектов, опыта и производительности сотрудников, специфики компании и т. п. Кроме того, требуется возможность перерасчета и уточнения сроков и ресурсов уже на этапе разработки системы с учетом тенденций, наблюдаемых при реализации проекта, что поможет менеджеру своевременно обнаружить отклонения от установленного графика и принять соответствующие меры в управлении проектом.

Целью данного исследования является повышение точности оценки стоимости IT-проектов на стадии предварительного проектирования посредством разработки автоматизированной системы.

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

Общая стоимость проекта включает стоимость разработки программного обеспечения, стоимость оплаты сопутствующих работ и прочие расходы. Основной составляющей общей стоимости является стоимость его разработки, т. е. стоимость трудозатрат. По этой причине важно максимально точно оценить трудоемкость разработки ПО. После этого рассчитывается стоимость его разработки с учетом распределения на проекте работников разных категорий и стоимости 1 человеко-месяца для каждой категории.

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

На практике при оценке проекта сталкиваются с тремя проблемами, имеющими принципиальное значение [2]: выбор модели, метода оценки программного продукта, метрики его размера и критериев точности оценки.

Методы оценки проектов разделяются на две группы [3]:

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

методы макрооценки, основанные на функциональных требованиях и/или других определениях конечного продукта (методы функциональных точек, СОСОМО), в основном применяется для внутреннего аудита проекта.

436

С другой стороны, все методы оценки можно разделить на следующие

типы:

Алгоритмические. Основаны на математических моделях, которые определяют трудозатраты как функцию, зависящую от множества факторов, влияющих на трудозатраты. Математический аппарат варьируется от простых линейный формул до сложных регрессионных моделей [3]. Для улучшения точности алгоритмических моделей их требуется приспособить к конкретным обстоятельствам (например, с помощью пересчета основных параметров и коэффициентов). Причем, даже после калибровки точность может быть весьма низкой, поскольку у каждой модели есть своя конкретная область применения,

вкоторой она дает адекватный конечный результат. По типу используемых в моделях функций выделяют линейные, мультипликативные и степенные модели.

Неалгоритмические. При оценке используются определенные схемы, принципы. К основным неалгоритмическим методам относятся: оценка по аналогии, экспертная оценка, цена победы, оценка ―снизу вверх‖ и ―сверху вниз‖.

В качестве модели оценки была выбрана COCOMO II (Constructive Cost Model) – одна из самых популярных алгоритмических моделей оценки трудоемкости программного обеспечения, ставшая стандартом. Модель относится к классу степенных. Параметры модели варьируются в зависимости от сложности разрабатываемого программного обеспечения, а также различных режимов использования модели.

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

Достоинством выбранной модели является возможность применения ее в каскадной, спиральной и итеративной моделях жизненного цикла проекта. При построении COCOMO II для обработки статистических данных использовался Байесовский анализ, позволяющий получить лучшие результаты для программных проектов, характеризующихся неполнотой и неоднозначностью. Также допускается измерять размер проекта числом строк кода, функциональными и объектными точками. Помимо прочего, при расчете показателей COCOMO II учитывает уровень зрелости процесса разработки в соответствии с моделями SEI CMM/CMMI [4].

Таким образом, модель может использоваться на разных этапах жизненного цикла разработки проекта, поскольку позволяет получать оценки тремя разными способами на разных этапах проекта [5]:

437

–на самых ранних этапах, когда примерно известны общие требования и проектирование не начиналось, используется модель состава приложения. В качестве метрики размера ПО выступают объектные точки (число экранов пользовательского интерфейса, отчетов, 3GL компонент).

–на следующих этапах, когда требования в основном известны и начинается разработка архитектуры ПО, используется модель этапа предварительного проектирования. В качестве метрик размера ПО используются функциональные точки или тысячи строк исходного кода - число непустых строк исходного кода, исключая комментарии;

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

Вмодели состава приложения производится оценка размера экранов, форм, отчетов, компонентов и модулей будущей системы (так называемых объектных точек). Каждый элемент оценивается с коэффициентом от 1 до 10 в зависимости от сложности. Учитывается процент повторного использования части компонентов в оцениваемом проекте и производительность разработки, зависящая от опыта команды разработчиков и применяемых инструментов.

Вмодели этапа предварительного проектирования используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

Главной особенностью в оценке трудоемкости является использование в качестве метрики размера программного продукта тысяч строк исходного кода (KSLOC). Размер программного продукта может быть оценен экспертами с применением метода PERT или получен путем анализа продукта методом функциональных точек.

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

Вданной работе реализуется модифицированный метод оценки трудоемкости проекта с целью повышения точности оценки, используя модели COCOMO II на разных этапах проекта.

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

438

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

Разработанная в рамках данного исследования система является эффективным средством управления такими ресурсами проекта, как трудоемкость, стоимость и длительность, на разных этапах проекта, основана на использовании современных информационных технологий (реализована на языке Java с применением технологий Spring MVC, Hibernate, JSP), позволяет ускорить процесс обработки данных, а также повысить точность предварительной оценки проектов. Также были разработаны предложения по улучшению модели оценки стоимости с целью повышения точности оценок.

Литературные источники

1.K. Lum, M. Bramble Handbook for Software Cost Estimation. – JPL: Pasadena, California, 2003 – 63 c.

2.Управление проектами по созданию программного обеспечения / У. Ройс. – Москва: ЛОРИ, 2002.

3.Менеджмент ИТ-проектов. / Д. Филлипс. – Москва: ЛОРИ, 2005.

4.Учебно-методическое пособие по дисциплине ―Управление проектами и разработкой ПО‖. / Ф.А. Новиков. – Москва, 2009. – 256 с.

5.Лекции по управлению проектами. / С. Архипенков. – Москва, 2009. – 127с.

Kratenok A.A.

RESEARCH OF METHODS AND TOOLS OF IT-PROJECTS COST ESTIMATION

Belarusian State University of Informatics and Radioelectronics, Minsk

Summary

In this study, were considered the methods and tools to estimate cost of IT-projects, as well as software implementation of one of the methods in the preliminary design stage. This software can be used to estimate the cost of the project prior to the software design, when only general requirements are known, and in the next steps: when requirements for the project have been basically formulated and the development of the software architecture have been started or have been completed.

439

УДК 004

Кудрин И.Г. 1, Железняков А.В. 1

ИСПОЛЬЗОВАНИЕ ГЕОИНФОРМАЦИОННЫХ СИСТЕМ И СИСТЕМ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЯ В СЛУЖЕБНОЙ ДЕЯТЕЛЬНОСТИ СИЛОВЫХ СТРУКТУР РЕСПУБЛИКИ БЕЛАРУСЬ

1Факультет внутренних войск учреждения образования «Военная академия Республики Беларусь», г. Минск

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

На сегодняшний день в Республики Беларусь нет такого единого центра управления, в котором были бы собраны представители различных ведомств для решения различно рода проблем.

Все чаще и чаще руководителям приходится принимать управленческие решения в условиях жесткого дефицита времени. Для работы «по ситуации» необходимо быстро и наглядно оценивать различные аспекты проблемы, включая анализ последствий тех или иных решений. Для повышения уровня безопасности требуется долгосрочное и краткосрочное прогнозирование развития ситуаций, подготовка и отработка типовых сценариев реагирования. Сегодня критические параметры управления — скорость реакции на быстрое изменение обстановки и высокая степень ответственности за результат. Для успешного исполнения решений также требуется хорошо отлаженное взаимодействие с подчиненными, вышестоящими и взаимодействующими структурами с помощью современных технологических средств.

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

Исходя из анализа выполняемых служебно-боевых задач силовыми структурами Республики Беларусь, необходимо отметить, что общими задачами являются:

участие в проведении государственной политики;

440