Такую оценку принято разделять на массовую и индивидуальную.

Массовая оценка недвижимости  –  это оценка большого числа объектов недвижимости на конкретную дату с использованием стандартных методик и статистического анализа. При этом унифицируется процедура оценки большого числа объектов [7].

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

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

Индивидуальная оценка недвижимости – это оценка конкретного объекта на определённую дату. Она необходима для защиты результатов оценки в судах, для определения стоимости объектов специального назначения и т.п. [7].

Для обоих видов оценок стоит задача разработки методик оценки недвижимости, в основу которых могут быть положены разнообразные модели и методы (рисунок 1).

Рисунок 1 – Методы разработки моделей оценки недвижимости

Общим требованиями к применению данных методов является наличие обширной и достоверной базы данных о сделках купли-продажи с описанием физических и экономических характеристик объектов недвижимости, участвовавших в этих сделках;

Статистические методы

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

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

Экспертные методы.

Данная группа методов основана на формализации мнений специалистов (экспертов) о характере зависимости рыночной стоимости объекта от его параметров.

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

Методы интеллектуального анализа данных

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

Нечеткая логика

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

Построение и поиск решения на нечетких моделях обладает рядом преимуществ:

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

Использование аппарата нечеткой логики рекомендуется для:

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

Недостатками нечетких систем являются:

• отсутствие стандартной методики конструирования нечетких систем;
• точность вычислений не превосходит, а порой и меньше, чем статистических методов.

Искусственные нейронные сети

Суть методов принятия решений с использованием нейросетевого моделирования заключается в построении формальной математической модели «по образу и подобию» человеческого мозга.

Структуру нейросети можно описать следующим образом. Нейросеть состоит из нескольких слоев: входной, внутренние (скрытые) и выходной слои. Входной слой реализует связь свходными данными, выходной – с выходными. Внутренних слоев может быть от одного и больше.

В каждом слое содержится несколько нейронов (рисунок 2).

Рисунок 2 – Структура нейросети

Между нейронами есть связи, называемые весами.

Преимущества нейросетевого подхода состоят в следующих особенностях:

- сокращение времени разработки, что достигается установлением связей между входными и выходными нейронами (параметрами), по-сути, без построения математической модели;

- отсутствие ограничений на типы входных и выходной информации;

- самообучаемость нейронных сетей, а также возможность работы с «зашумленными» данными.

Современные средства нейросетевого моделирования достаточно просты и могут с успехом применяться для поставленной задачи.

Рассмотрим деятельность менеджера проектов на примере компании по разработке веб-сайтов.

Существует 3 типа менеджеров проектов в компании по производству веб-сайтов:

1. Аккаунт менеджер – лицо, наделенное ответственностью вести аккаунт проекты. Аккаунт проект – это проекты, которые не имеют жестких временных проектных рамок, не имеют четко установленного плана-графика проекта. Задачи в таком проекте поступают хаотично, в зависимости от потребностей клиента. Чаще всего аккаунт проекты – это проекты на развитие программного продукта.
2. Проектный менеджер – лицо, наделенное ответственностью вести стандартные проекты по разработке веб-сайтов. Проект по разработке веб-сайта имеет четко установленные сроки в рамках плана-графика работ, этапы проекта. Проектный менеджер осуществляет свою деятельность с момента передачи ему вводных данных по проекту, до момента сдачи проекта заказчику и передачи проекта в архив [1, 2, 3].
3. Менеджер технической поддержки – лицо, наделенное ответственностью вести проекты в рамках технической веб-сайтов. Проект технической поддержки веб-сайта заключатся в проведении работ по устранению ошибок, возникающих в программном продукте или выполнение небольших работ по изменению веб-сайта. Проект действует в рамках специального пакета оказания услуг.

Рассмотрим применение стандартов в деятельности менеджера проектов в области разработки веб-сайтов на примере проектного менеджера. На рисунке 1 представлена модель в нотации eEPC, иллюстрирующая деятельность проектного менеджера в рамках одного стандартного проекта [4, 5, 6].

На рисунке 1 показаны основные стандарты (отмечены в виде красных документов), которые используются в деятельности проектного менеджера компании по разработке веб-сайтов:

1. PMBOK.
2. Корпоративный PMBOK.
3. ISO 10006.
4. ГОСТ 34.601.
5. ГОСТ 34.602.
6. ГОСТ 24.301-80.

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

Корпоративный PMBOK. Стандарт, разработанный внутри компании по разработке веб-сайтов на основе международного руководства по управлению проектами PMBOK. Данный стандарт адаптирован под деятельность конкретной организации и является обязательным регламентирующим документом в проектной деятельности менеджером компании [7, 8, 9].

Рис. 1. Деятельность проектного менеджера компании по разработке веб-сайтов

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

Стандарт ISO 10006 является основополагающим документом из серии стандартов рассматриваемого профиля, подготовленным техническим комитетом ISO/TC 176 “Управление качеством и обеспечение качества” Всемирной федерации национальных органов стандартизации (члены ISO). Основной упор сделан на принцип эффективности проектирования оптимального процесса и контроля этого процесса, а не на контроле конечного результата.

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

Настоящий стандарт не является руководством по управлению проектами. В нем рассматриваются вопросы менеджмента качества процессов проектирования. Руководство по процессному подходу и по процессам качества проектируемой продукции приведено в ИСО 9004.

ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания». Настоящий стандарт распространяется на автоматизированные системы (АС), используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях, объединениях и на предприятиях (далее – организациях). Стандарт устанавливает стадии и этапы создания АС.

ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Настоящий стандарт распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы» (далее – ТЗ на АС).

ГОСТ 24.301-80 «Система технической документации на АСУ. Общие требования к выполнению текстовых документов». Настоящий стандарт распространяется на техническую документацию на автоматизированные системы управления (АСУ) всех видов, разрабатываемые для всех уровней управления (кроме общегосударственного), и устанавливает общие требования к выполнению текстовых документов, перечень которых установлен ГОСТ 24.101-80.

Стандарт не распространяется на программные и организационно-распорядительные документы АСУ, правила выполнения которых регламентированы государственными стандартами других систем документации.

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

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

ГОСТ 34.601-90 является руководством скорее для проектной группы и компании в целом, так как стандарт устанавливает стадии создания программного продукта. Однако для менеджера проекта, особенно проектного менеджера он является не менее важным, так как именно менеджер устанавливает и ведет все стадии проекта.

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

ГОСТ 24.301-80 используется как руководство при оформлении проектной и технической документации.

Рассмотрим применение стандартов на примере описания процесса «создание технической документации программного продукта» с указанием всех ГОСТов, применяемых в данной предметной области (рис.1).

Вводная часть

Предприятие с условным названием «ПРОГРАММиК» занимается созданием и сопровождением программных продуктов для коммерческого использования. К основным бизнес-процессам (БП) предприятия относятся [4, 5, 6]:

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

Детально рассмотрим БП «Создание сопроводительной документации (документирование)». Процесс заключается в создании техническим писателем документа (документов), описывающих разработку для возможности работы с ней определенных категорий клиентов-потребителей:

• системных администраторов (документы «Руководство администратора», «Руководство системного администратора», «Руководство по установке»)
• программистов (документы «Руководство программиста», «Структура базы данных», «Application Programming Interface», «Функциональная спецификация»)
• пользователей (документ «Руководство пользователя»)

Этапы создания документации:

1. Постановка задачи.
2. Получение входных данных.
3. Документирование.
4. Рецензирование документации.
5. Проверка документации.

1. На этапе постановки задачи разработчик/менеджер проекта составляет запрос на проведение работ в системе ведения проектов JIRA (регулируется внутренним регламентом компании) на выполнение документирования техническим писателем. В заявке содержится минимальная информация по проделываемой работе: срок, приоритет, тип запроса (новый компонент, задача, подзадача, исправление) и краткое описание.

2. На этапе получения входных данных технический писатель запрашивает (самостоятельно находит) входные данные, необходимые для решения запроса. Иногда необходимые данные указывают непосредственно в запросе, тогда данный этап пропускается. В качестве входных данных могут выступать [7, 8, 9]:

• текст программы (регулируется стандартом ГОСТ 19.401-78 «Единая система программной документации. Текст программы. Требования к содержанию и оформлению»)
• техническое задание (регулируется стандартом ГОСТ 19.201-78 “Единая система программной документации. Техническое задание. Требования к содержанию и оформлению”)
• техническая или функциональная спецификация (регулируется стандартом ГОСТ 19.202-78 «Единая система программной документации. Спецификация. Требования к содержанию и оформлению»)

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

3. На этапе описания разработки (документирования)  выполняется переработка входной информации и создается описание на техническом языке, доступном для понимания конечного пользователя. Технический писатель при создании описания руководствуется следующими нормативными документами:

• ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства» (для документа «Руководство пользователя»)
• ГОСТ 19.202-78 «Единая система программной документации. Спецификация. Требования к содержанию и оформлению» (для документа «Функциональная спецификация»)
• ГОСТ 19.504-79 «ГОСТ 19.202-78 «Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению» (для документа «Руководство программиста»)
• ГОСТ 19.603-78 «Единая система программной документации. Общие правила внесения изменений» (для внесения изменений в существующую документацию)
• ГОСТ Р ИСО 9127-94 «Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов» (для документа «Руководство по установке»)
• ГОСТ 18421-93 «Аналоговая и аналогово-цифровая вычислительная техника. Термины и определения» (для обеспечения единообразия используемой в документации терминологии)

Также для описания разработки используются внутренние стандарты, разработанные компанией (регламент описания документов «Структура базы данных», «Application Programming Interface» и т.д.).

4. На этапе рецензирования документации выполняется проверка текста документации и внесение соответствующих корректировок. Разделяют внутреннее (со стороны коллеги – технического писателя) и внешнее (со стороны разработчика) рецензирование. Процесс рецензирования регулируется внутренними регламентами отдела технической документации и взаимодействия между отделами.

5. На этапе проверки качества и соответствия технической документации руководителем отдела документации (старшим техническим писателем) выполняется проверка выполненной работы. Основным документом, регламентирующим деятельность руководителя отдела технической документации, является стандарт ГОСТ Р ИСО/МЭК ТО 9294-93 «Информационная технология. Руководство по управлению документированием программного обеспечения».

Дата основания предприятия – ноябрь 1985 года.

Форма собственности – Общество с ограниченной ответственностью.

Учредителем предприятия является Иванов Иван Иванович.

Уставный фонд  – 17,6 млн. руб.

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

Юридический адрес предприятия – Московская область, ул. XX, д.XX.

В состав предприятия  также входят станция диагностики, магазин, объекты социальной сферы: общежитие и столовая.

Рисунок 1 – Организационная диаграмма

Рассмотрим факторы, которые смогут повлиять на результат работы исследуемого нами отдела. В качестве основной методологии проектирования на данном этапе будем использовать методологию ARIS, диаграмму причин и факторов Исикавы (рис. 2).

Рисунок 2 – Диаграмма Исикавы

В данной диаграмме выделено 5 основных причин влияющие на неэффективную работу отдела:

1. Человек

• Большая загрузка сотрудников
• Болезни
• Отсутствие квалификации

1. Оборудование и инструмент

• Выход из строя техники
• Выход из строя погрузочного транспорта
• Недостаточная мощность серверов
• Недостаток автоматизации

1. Среда

• Плохая погода
• Неподходящие условия труда

1. Методы

• Отсутствие регламента
• Не оптимальность процесса

1. Менеджмент

• Отсутствие грамотного менеджера
• Плохая оптимизация рабочего времени сотрудников

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

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

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

Механики осуществляют ремонт оборудования.

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

Рисунок 3- План проекта

На данном графике (Рисунок 3) детально показан план разработки системы для предприятия. Показано не только название задачи, но и ее трудозатраты, длительность, а так же когда задача приступает к осуществлению и когда заканчивает. Для большей наглядности последовательности исполнения задач, нужно посмотреь на график проекта (Рисунок 4).

Рисунок 4 – График проекта

Использование ресурсов

После создания календарного плана необходимо распределить ресурсы для каждой из задач. На рисунке показано распределение ресурсов для каждой из задач (Рисунок 5).

Рисунок 5 – Использование ресурсов

Использование задач

На диаграмме использование задач наглядно видно какой ресурс использует каждая из задач, её трудозатраты, длительность, а так же начало  и окончание работы. Предназначена данная диаграмма для анализа участия ресурсов в проекте (Рисунок 4).

Рисунок 6 – Использование задач

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

Отчеты проекта

Рисунок 7 – Отчет «Обзор ресурсов»

Рисунок 8 – Отчет «Движение денежных средств»

Рисунок 9 – Отчет «Обзор затрат ресурсов»

Рисунок 10 – Отчет «О вехах»

Устав проекта

а                                                                      б

Рис. 1. Карты Шухарта для числа несоответствий, выявленных в учебно-методическом обеспечении образовательных программ, размещенных факультетами на информационно-образовательном портале в а) базовом учебном году; б) отчетном учебном году

На рис. 1. представлены карты Шухарта по числу дефектов – типовых ошибок. На них зарегистрировано число разных типов несоответствий (c), выявленных в учебно-методическом обеспечении образовательных программ, размещенных в разделах факультетов на информационно-образовательном портале.

Средняя линия () рассчитана как среднее арифметическое всех несоответствий по факультетам. Контрольные границы - _. Так как при данной формуле расчета значения  нижней границы получаются отрицательными, то их  считаем равными нулю.

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

Мотивация к работе в системе электронного обучения с использованием образовательного портала постепенно возрастает, изменяются цели использования портала в образовательной деятельности, подтверждением этому служит результат опроса участников образовательной деятельности вуза (Рисунок 2). Опрос проводился среди преподавательского состава вуза. Один из вопросов звучал так: «Для каких целей Вы используете внутренний образовательный портал? Из выбранных пользователями, представленных ответов были следующие»:

1.  «Для ознакомления с внутренними нормативными документами, для ознакомления с новостями, для организации учебного процесса в рамках аудиторной и/или самостоятельной работы студентов» (на гистограмме представлен колонкой под номером «1»).
2. «Для ознакомления с внутренними нормативными документами и для ознакомления с новостями» (на гистограмме представлен колонкой под номером «2»).
3. «Для ознакомления с внутренними нормативными документами и для организации учебного процесса в рамках аудиторной иили самостоятельной работы» (на гистограмме представлен колонкой под номером «3»).

Рисунок 2. График результатов опроса пользователей портала в базовый и отчетный периоды

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

В ходе разработки модели будем использовать следующую последовательность шагов:

Шаг 1. Разработка архитектуры нейросети.

Шаг 2. Обучение нейросети (осуществляется подачей на вход обучающего множества).

Шаг 3. Тестирование (оценивается качество классификации при подаче на вход тестового множества). Сеть считается успешной при относительной ошибке не более 20 %. Если ошибка больше, следует возврат к шагу 2. В случае, когда повторное обучение не улучшило результат, сеть считается неудачной и выбывает из эксперимента.

Шаг 4. Контрольная классификация.

Источником входных и выходных данных являлся сайт «Ситистар» (недвижимость г. Магнитогорска). В качестве параметров были выбраны: количество комнат, тип дома, район, этаж, этажность дома, общая площадь, жилая площадь, площадь кухни, наличие ремонта, мебели, застеклённость балкона и стоимость.

Входные параметры:

Х1 – количество комнат;

X2 – тип дома, закодирован следующими значениями :

1 – УП (улучшенная планировка);

2 – БР («брежневка»);

3 – ХР («хрущевка»);

4 – СП (старая планировка);

5 – МС (квартира малосемейного типа); 6 – студия; 7 – новостройка;

8 – нестандартная;

9 – «сталинка»;

10- стандартная;

11 – «свердловский вариант»;

X3 – район:

1 – Ленинский;

2 – Правобережный;

3 – Орджоникидзевский;

X4 – этаж;

X5 – всего этажей;

X6 – общая площадь (кв. м.);

X7 – жилая площадь (кв. м.);

X8 – площадь кухни (кв. м.);

X9 – балкон (1 – застеклён; 2 – не застеклён);

Х10 – наличие мебели (1 – есть; 2 – нет);

Х11 – наличие ремонта (1 – есть; 2 – нет).

Выходной параметр: Y1 – стоимость квартиры (тыс. руб.).

В ходе выполнения работы была сформирована выборка из 200 объявлений, составленная в офисном пакете MSExcel, после чего был произведён импорт в Deductor (рисунок 1).

Рисунок 1 – Импорт выборки

После импорта данных и получения детальной статистики по выборке были установлены входные и выходные поля данных. Далее был установлен процент обучающего множества – 80% и тестового – 20%. После разбиения исходного набора данных на подмножества мы определили допустимый диапазон нейронов на скрытых слоях персептрона. Для этого мы использовали формулу, являющуюся следствием теорем Арнольда–Колмогорова–Хехт–Нильсена.

гдеN_x – размерность входного сигнала;  - размерность выходного сигнала; Q – число элементов обучающей выборки.

Следовательно, число нейронов в скрытых слоях  приN_x=11, N_y=1, Q=200.

При определении N_опти обучении персептрона на 10000 эпохах было найдено необходимое количество нейронов в скрытых слоях равное четырём, при которых система осуществляет вычисления с минимальной погрешностью (среднеквадратичная ошибка обучающего множества составила – 1,94Е-03).

Итак, при разработке архитектуры нейросети были установлены следующие параметры:

1. Число слоев нейронов – 4;
2. Число нейронов входного слоя – 14;
3. Число нейронов выходного слоя – 1;
4. Крутизна – 0,3;
5. Функция активации – сигмоида.

Перед началом обучения были настроены шаги спуска и подъема на уровне 0,4 и 1,2 соответственно. Шаг спуска – в случае изменения знака градиентной составляющей ошибки для данного веса задает величину следующей коррекции веса. Шаг подъема – в случае сохранения знака градиентной составляющей ошибки для данного веса задает величину следующей коррекции веса, по умолчанию 1,2 (рисунок 2).

Рисунок 2 – Обучение нейронной сети

Для отдельных значений тестовой выборки максимальная ошибка составляла до 6,44Е-01, что может объясняться:

1. Недостаточным объемом исходной информации, например, отсутствие данных о состоянии квартиры.
2. Слабой корреляцией между отдельными параметрами.

В результате проделанной работы была получена нейронная сеть представленная на рисунке 3.

Обучив нейронную сеть, мы получили возможность оценивать любую квартиру по заданным параметрам с помощью инструмента «что если» (рисунок 4).

Рисунок 3 – Нейронная сеть

Рисунок 4 – Анализ построенной модели по принципу «Что если»

Таким образом, двухкомнатная квартира нестандартной планировки в Орджоникидзевском районе, находящаяся на восьмом этаже девятиэтажного дома общей площадью 51 кв. м. будет стоить 1,544 млн. рублей.

Рисунок 1 – Дерево-иерархии

Эксперт на основе своего субъективного мнения оценивает принадлежность элемента данному множеству относительно другого элемента. Для проведения субъективных парных сравнений Т. Саати была разработана шкала относительной важности, ее модификация приведена в таблице 1 [8].

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

Таблица 1 – Шкала относительной важности

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

Для оценки формируются матрицы попарных сравнений сначала критериев, затем каждой альтернативы по каждому критерию. Результаты попарного сравнения элементов заносятся в матрицу сравненияA размерности n×n, где n – число сравниваемых элементов. Элемент  указанной матрицы выражает результат сравнения элементов i и j. Если при сравнении элементов i и j получено a(i,j)=b, то результатом сравнения элементов jи iдолжно быть a(j,i)=1/b. Очевидно, что диагональные элементы матрицы равны 1.

Рассчитывается вектор-строка сумм матрицы попарных сравнений критериев:

Произведем нормирование матрицы A (где -элемент этой матрицы):

(v₁,…,v_n – элементы вектора v)

Тогда вектор w-веса критериев будет определяться следующим образом:

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

Затем производится линейная свертка по каждой альтернативе (комбинированный весовой коэффициент – R), например, для А: , где – веса критериев, – локальные оценки альтернатив по критерию А.

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

1)    определить цель;

2)    определить критерии выбора;

3)    определить альтернативы (в нашем случае для обоих этапов оценки эффективности в качестве таковых будут выступать методологии  и технологии внедрения ИТ-решений);

4)    построить иерархическую структуру выбора альтернатив;

5)    определить приоритеты критериев (суждения) с использованием шкалы относительной важности, построить матрицу парных сравнений критериев и альтернатив для каждого критерия;

6)    выполним проверку матрицы попарных сравнений на непротиворечивость;

7)    рассчитать комбинированный весовой коэффициент по каждой альтернативе;

8)    сделать выводы [8].

Для оценки перспективности и выбора наилучшего решения был применён метод анализа иерархий по следующим критериям (рисунок 2):

• Простота программной реализации;
• Простота калибровки;
• Точность;
• Гибкость.

Рисунок 2 – Метод анализа иерархий для методов ИАД

А1 (Нейронные сети) = 0,71*0,21+0,71*0,29+0,8*0,07+0,5*0,33 = 0,6509;

А2 (Нечёткая логика) = 0,29*0,21+0,29*0,29+0,2*0,07+0,5*0,33 = 0,349.

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