авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

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


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |

«УДК 002.52/.54(075.8) ББК 32.973.202я73 МИНОБРНАУКИ РОССИИ ...»

-- [ Страница 4 ] --

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

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

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

Рис. 2.41 Построение MDA-системы на двух технологических платформах и генерация межплатформного адаптера Преимущества использования MDA Тестирование и модификация Пользуясь MDA, можно организовать не только переход от абстрактной модели к детальной (от PIM к PSM, от PSM к коду системы), но и обратное преобразование — повышение уровня абстракции. Возможно создание инструментов, позволяющих осуществлять не только прямое, но и обратное преобразование моделей на основе стандартных отображений. Благодаря этому открывается возможность вести разработку, тестирование и модификацию одновременно платформно-независимой и платформно зависимой моделей;

если возникает необходимость изменить логику работы программы на абстрактном уровне (т. е. изменить PIM), эти изменения могут быть отображены в изменения PSM.

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

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

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

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

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

Литература: [10];

[13];

[14] ;

[15].

3 ПРАКТИЧЕСКИЕ ЗАНЯТИЯ ПО ДИСЦИПЛИНЕ Оборуд Литера № Тема лекции Тема пр. зан. Часы ование тура 1. Модели и методы Получение 4 ЭВМ [1];

[5] исследования систем. оптимального решения Классификация по выбору заданной информационных технологии (средства) моделей моделирования 2. Предмет, основные Вычисление энтропии 4 ЭВМ [1];

[5] задачи и понятия теории дискретного источника информационных информации процессов 3. Технологии Разработка 6 ЭВМ [2];

[3] ;

проектирования технического задания [4] ;

[6] информационных систем на проектирование ;

[7] ;

[8] ;

[9] ;

[11] 3.1 Практическая работа. Получение оптимального решения из нескольких альтернатив.

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература:

[1];

[5].

Краткое изложение основных теоретических и методических аспектов работы Методы, применяемые на этапе оценки и выбора альтернатив Сущность анализа альтернатив действий Альтернативой в процессе принятия решений называют способ действий или стратегию по достижению цели. Дословно «альтернатива» (франц. alternative, лат. alter – один из двух) означает необходимость выбора одного из двух или нескольких возможных решений, направлений, нужных вариантов и т. п.

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

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

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

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

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

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

Пусть ai - некоторая альтернатива из множества A. Считается, что для всех aiA, может быть задана функция Kr(a), которая называется критерием и обладает следующим свойством: если альтернатива a1 предпочтительнее альтернативы a2 (a1a2), то выполняется соотношение Kr(a1)Kr(a2) и обратно.

Если выбор осуществляется в условиях определенности и заданный критерий Kr(a) численно выражает оценку этих последствий, то наилучшей альтернативой a* является та, которая обладает наибольшим значением критерия:

a* = arg{maxi Kr(ai)}, ai A Задача отыскания a* часто оказывается сложной для решения, поскольку метод ее решения определяется как характером множества A, так и характером критерия Kr(a).

Кроме этого, сложность возрастает еще и потому, что детализация альтернатив приводит к необходимости оценивать их по нескольким критериям, отличающимся друг от друга. Если используются нескольких критериев Kri(a), i = 1,…,k;

интересен случай, когда во множестве A окажется одна наилучшая альтернатива a*, обладающая наибольшими значениями всех k критериев. Однако на практике такие случаи почти не встречаются.

Наиболее употребительные способы решения многокритериальных задач:

введение суперкритерия (скалярной функции векторного аргумента);

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

поиск Ai с заданными свойствами;

множество Парето (отказ от выделения единственной оптимальной Ai).

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

Допустим, имеем n альтернатив Ai (i=1-n) и начинаем сравнивать их попарно, оставляя более предпочтительную и сравнивая ее со следующей, до тех пор, пока не останется одна (рис. ).

Основные предположения языка бинарных отношений сводятся к следующему:

отдельная альтернатива не оценивается, (критериальная функция не вводится);

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

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

Рис. 3.2 Схема осуществления парных сравнений Язык функций выбора описывает выбор, как операцию над произвольным множеством альтернатив Ai, каждая из которых ставит этому множеству в соответствие некоторое его подмножество. Функция выбора применяется в ситуациях, когда предпочтение между двумя альтернативами зависит от остальных. Последствия выбора могут быть точно известны (выбор в условиях определенности), иметь вероятностный характер, (выбор в условиях риска), или иметь неоднозначный исход (выбор в условиях неопределенности).

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

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

Различия между определенностью, риском и неопределенностью отражают различия в степени знания лица, принимающего решения. Если представить состояния его знания как линию спектра, то на одном ее конце будет определенность (полное знание), а на другом - неопределенность (полное отсутствие знания). Риск (частичное знание) будет лежать между ними. Положение на линии спектра будет отражать имеющуюся степень определенности (или неопределенности).

Концепция определенности Определенность понимается как такое состояние знания, которые лицо, принимающее решение, заранее знает конкретный исход для каждой альтернативы.

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

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

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

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

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

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

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

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

Выработка решения в условиях риска Условия риска и неопределенности характеризуются так называемыми условиями многозначных ожиданий будущей ситуации во внешней среде. В этом случае ЛПР должен сделать выбор альтернативы (Аi), не имея точного представления о факторах внешней среды и их влияния на результат. В этих условиях исход, результат каждой альтернативы представляет собой функцию условий – факторов внешней среды (функцию полезности), который не всегда способен предвидеть ЛПР. Для предоставления и анализа результатов выбранных альтернативных стратегий используют матрицу решений. Пример матрицы решений приведен в таблице 2. 1.

Таблица 2. Матрица решений Альтернативы Состояние предметной области S1 S2 S3 … A1 E11 E12 E13 … A2 E21 E22 E23 … A3 E31 E32 E33 … A1, A2, A3 –альтернативные стратегии действий;

S1, S2, S3 – состояние предметной области (стабильность, спад, рост и др. );

E11;

E12;

E13;

E21;

… E33;

… - результаты решений.

Числа в ячейках матрицы представляют собой результаты реализации Eij стратегии Ai в условиях Sj. При этом, в условиях риска вероятность наступления Sj известна, а в условиях неопределенности эта вероятность может быть определена субъективно, в зависимости от того какой информацией располагает ЛПР. Методы принятия решений в условиях риска используют теорию выбора, получившую название теории полезности. В соответствии с этой теорией, ЛПР выбирает Ai из совокупности Ai (i = 1 … n), если она максимизирует ожидаемую стоимость его функции полезности Yi,j.

В условиях риска при принятии решения основным моментом является определение вероятности наступления состояния среды Sj, т. е. степени риска.

После определения вероятности наступления состояния среды Sj, определяют ожидаемую стоимость реализации каждой альтернативы, которая представляет собой средневзвешенную оценку E(x):

E(x) = P1x1 + P2x2 + … + Pnxn = Pixi где xi – результат реализации Ai;

Pi – вероятность реализации Ai в условиях Sj.

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

E(x) = Pi*xi =max при Pi = 1.

Следующий метод, применяемый для принятия решений в условиях риска, носит название дерева решений. Его применяют тогда, когда необходимо принимать последовательный ряд решений. Дерево решений – графический метод, позволяющий увязать точки принятия решения, возможные стратегии Ai, их последствия Yi,j с возможными факторами, условиями внешней среды. Построение дерева решений начинается с более раннего решения, затем изображается возможные действия и последствия каждого действия (событие), затем снова принимается решение (выбор направления действия) и т. д., до тех пор, пока все логические последствия результатов не будут исчерпаны.

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

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

Практикуются два основных подхода к принятию решения в условиях неопределенности.

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

Если степень неопределенности слишком высока, то лицо;

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

а) критерия решения Вальда, называемый также максимином;

б) альфа-критерий решения Гурвица;

в) критерий решений Сзйвиджа, называемый также критерием отказа от мини макса;

г) критерий решений Лапласа, называемый также критерием решения Бэйеса.

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

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

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

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

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

Используются следующие методы ранжирования: метод простой ранжировки;

метод непосредственной оценки;

метод парных сравнений и др.

Метод простой ранжировки. Заключается в том, что эксперты располагают объекты ранжирования (например, критерии) в порядке убывания их значимости (скажем, для альтернатив это убывание предпочтительности). Ранги обозначаются цифрами от 1 до n, где n — количество рангов. Сумма рангов Sn при этом будет равна сумме чисел натурального ряда:

Sn=n(n+1)/ При ранжировании n объектов m экспертами ранжирование производят следующим образом:

1. каждый j-й эксперт (j=1-m) выносит суждения о ранге RjAi каждого i-го объекта (i=1-n);

2. для каждого i-го объекта (i=1-n) подсчитывают сумму рангов, полученных от всех экспертов, т. е m S im = R Ai j j = где RjAi — суждение j-го эксперта о ранге i-го объекта;

i=1-n;

j=1-m;

Si — результирующий ранг i-го объекта;

3. определяют ранги объектов (от 1 до n), от наименьшего до наибольшего результирующего ранга.

Метод непосредственной оценки заключается в отнесении объекта оценки к определенному значению по оценочной шкале (т. е. в присвоении объекту оценки балла в определенном интервале), например, от 0 до 10 — в соответствии с предпочтением по какому-либо признаку или их группе (альтернативы, например, по предпочтению;

критерии — по значимости;

факторы внешней среды — по оказываемому влиянию;

проблемы — по приоритетности решения).

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

Таблица 2. 2.

Матрица парных сравнений для четырех объектов.

A1 A2 A3 A4 Ранг A1 - 1 (А1,2) 0 1 A2 0 (А2,1) - 0 1 A3 1 1 - 1 A4 0 0 0 - В ячейке А1,2 вписана единица, это означает, что элемент А1 получает большую оценку, чем элемент А2. Соответственно в ячейке А2,1 пишут 0, а в ячейке А1,4 вписана 1, и затем, суммируя значения по строкам, получают ранги объектов.

Критериальные методы. Критерий (от греч. criterion – средство для суждения;

признак, на основании которого производится оценка;

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

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

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

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

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

Задачи оценки эффективности решений одновременно по нескольким критериям называют многокритериальными.

В многокритериальных задачах появляются вопросы: Как формализовать задачу?

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

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

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

Прямые методы. Примерный алгоритм многокритериальной оценки альтернатив следующий:

• определить критерий оценки альтернатив;

• ранжировать критерий по важности;

• отбросить маловажные критерии;

• назначить числа, соответствующие относительной важности критериев;

• нормировать коэффициенты (wi) по важности из условия:

n w = i i = где wi – вес i-го критерия, назначаемый ЛПР;

• произвести предварительное отсечение альтернатив по качеству (на шкалах критериев определяется индекс качества);

• определить функции U полезности для каждого из критериев N U = (( xi xi* ) / xi* ) i = • определить полезность каждой из альтернатив по формуле:

N U = wi U i i = Методы порогов несравнимости. Данные методы предложены впервые профессором Б. Руа во Франции. Суть методов в следующем: решают оптимизационную задачу с одним первым критерием, считая, что других критериев нет. Затем решают задачу с одним вторым критерием и т. д. После выявления экстремальных уровней, которые достижимы по каждому критерию в отдельности, для каждого критерия, начиная с наиболее важного, задается порог, который не должен нарушаться. Условие нерушимости порога считают ограничением, затем добавляют ограничения по порогу второго критерия и т. д.

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

Задание на выполнение практической работы:

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

2. Найти 6 объектов изучения в качестве альтернатив.

3. Создать структурированное описание объектов по параметрам (текстовое).

4. Выбрать метод выбора альтернатив для принятия решения.

5. Рассчитать параметры для оценивания альтернатив.

6. Рассчитать приоритеты и выбрать наилучший вариант.

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

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература 1, 5.

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

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

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

Формальные определения Информационная двоичная энтропия для независимых случайных событий с возможными состояниями (от до, — функция вероятности) рассчитывается по формуле:

Эта величина также называется средней энтропией сообщения.

Величина называется частной энтропией, характеризующей только -e состояние.

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

Определение по Шеннону Клод Шеннон предположил, что прирост информации равен утраченной неопределённости, и задал требования к её измерению:

1. мера должна быть непрерывной;

то есть изменение значения величины вероятности на малую величину должно вызывать малое результирующее изменение функции;

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

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

Поэтому функция энтропии должна удовлетворять условиям:

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

3. Для целых положительных, где, должно выполняться равенство:

Шеннон показал, что единственная функция, удовлетворяющая этим требованиям, имеет вид:

где — константа (и в действительности нужна только для выбора единиц измерения).

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

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

и собственной информации:

Тогда энтропия определяется как:

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

От основания логарифма зависит числовая величина единицы измерения количества информации и энтропии.

Свойства Энтропия является количеством, определённым в контексте вероятностной модели для источника данных. Например, кидание монеты имеет энтропию:

бит на одно кидание (при условии его независимости), а количество возможных состояний равно: возможных состояния (значения) ("орёл" и "решка").

У источника, который генерирует строку, состоящую только из букв «А», энтропия равна нулю:, а количество возможных состояний равно: возможное состояние (значение) («А») и от основания логарифма не зависит.

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

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

1. Некоторые биты данных могут не нести информации. Например, структуры данных часто хранят избыточную информацию, или имеют идентичные секции независимо от информации в структуре данных.

2. Количество энтропии не всегда выражается целым числом битов.

3.

Математические свойства 1. Неотрицательность:.

2. Ограниченность:

, что вытекает из неравенства Йенсена для вогнутой функции и.

Если все элементов из равновероятны,.

3. Если независимы, то.

4. Энтропия — выпуклая вверх функция распределения вероятностей элементов.

5. Если имеют одинаковое распределение вероятностей элементов, то.

Эффективность Алфавит может иметь вероятностное распределение далекое от равномерного. Если исходный алфавит содержит символов, тогда его можно сравнить с «оптимизированным алфавитом», вероятностное распределение которого равномерное. Соотношение энтропии исходного и оптимизированного алфавита — это эффективность исходного алфавита, которая может быть выражена в процентах. Эффективность исходного алфавита с символами может быть также определена как его -арная энтропия.

Энтропия ограничивает максимально возможное сжатие без потерь (или почти без потерь), которое может быть реализовано при использовании теоретически — типичного набора или, на практике, — кодирования Хаффмана, кодирования Лемпеля — Зива — Велча или арифметического кодирования.

Условная энтропия Если следование символов алфавита не независимо (например, во французском языке после буквы «q» почти всегда следует «u», а после слова «передовик» в советских газетах обычно следовало слово «производства» или «труда»), количество информации, которую несёт последовательность таких символов (а, следовательно, и энтропия), очевидно, меньше. Для учёта таких фактов используется условная энтропия.

Условной энтропией первого порядка называется энтропия для алфавита, где известны вероятности появления одной буквы после другой (то есть, вероятности двухбуквенных сочетаний):

где — это состояние, зависящее от предшествующего символа, и — это вероятность при условии, что был предыдущим символом.

Например, для русского языка без буквы «ё»

.

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

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

Для вычисления потерь при передаче всех сигналов используется общая условная энтропия:

означает энтропию со стороны источника, аналогично рассматривается — энтропия со стороны приёмника: вместо всюду указывается (суммируя элементы строки можно получить, а элементы диагонали означают вероятность того, что был отправлен именно тот символ, который получен, то есть вероятность правильной передачи).

Взаимная энтропия Взаимная энтропия или энтропия объединения предназначена для расчёта энтропии взаимосвязанных систем (энтропии совместного появления статистически зависимых сообщений) и обозначается, где характеризует передатчик, а — приёмник.

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

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

Условные вероятности производятся по формуле Байеса. Таким образом, имеются все данные для вычисления энтропий источника и приёмника:

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

Единица измерения — бит/два символа, это объясняется тем, что взаимная энтропия описывает неопределённость на пару символов: отправленного и полученного. Путём несложных преобразований также получаем Взаимная энтропия обладает свойством информационной полноты — из неё можно получить все рассматриваемые величины.

Задание на практическую работу:

1. Изучить теоретические материалы по расчету энтропии сообщения.

Расчет максимального значения энтропии вычисляется по формуле H ( xi ) = log a K = log, бит/символ K Расчет энтропии сообщения вычисляется по формуле N H ( X ) = p( xi ) log a p( xi ), бит/символ i = Расчет избыточности вычисляется по формуле = 1 H ( X ) / log( K ) 2. Разработать алгоритм вычисления алфавита произвольного сообщения.

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

Работу выполнять на языке программирования по выбору студента.

В программе использовать венгерскую систему имен, начинающуюся с инициалов студента (KAB_).

К основным блокам и переменным в программе добавлять комментарии.

4. Разработать алгоритм расчета вероятности появления символов в заданном сообщении.

5. Доработать программу по расчету энтропии сообщения с целью получения избыточности выбранного источника.

6. Провести исследование для источников (файлов) разных форматов (минимум форматов).

7. Сохранить результаты исследования по файлам разных форматов в виде сравнительной таблицы.

8. Проанализировать полученные результаты.

9. Представить результаты для защиты преподавателю.

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

ЭВМ с операционной системой Windows XP (или выше версия) или семейства Linux.

Литература [2];

[3] ;

[4] ;

[6] ;

[7] ;

[8] ;

[9] ;

[11].

Краткое изложение основных теоретических и методических аспектов работы Техническое задание — исходный документ на проектирование технического объекта. ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д. ) и её состав, а также специальные требования.

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

(например, проектное задание в строительстве, боевое задание, домашнее задание, договор на литературное произведение и т. д. ).

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

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

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

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

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

Проектирование — это процесс (разработки проекта), который обладает определённой структурой, то есть последовательностью и составом стадий и этапов, совокупностью процедур и привлекаемых технических средств, взаимодействием участников процесса.

Стадии проектирования регламентированы стандартами:

Техническое задание, Техническое предложение, Эскизный проект, Технический проект, Стадии рабочего проекта.

Как правило, ТЗ составляют на основе анализа результатов предварительных исследований, расчётов и моделирования.

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

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

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

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

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

Техническое проектирование ведется при тесном взаимодействии всех разработчиков.

Составление ТЗ — сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет поставлено, способно облегчить или затруднить последующее проектирование (образно говоря, «как корабль назовешь, так он и поплывет»).

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

Содержание ТЗ регламентировано нормативными документами (ГОСТ, ОСТ):

ГОСТ 19. 201-78. Единая система программной документации. Техническое задание.

Требования к содержанию и оформлению (кратко изложено содержание ТЗ);

ГОСТ 34. 602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (достаточно подробно изложены состав и содержание ТЗ);

ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ).

В части выполнения НИР ТЗ регламентируется следующими документами:

ОСТ 95 18-2001. Порядок проведения научно-исследовательских и опытно конструкторских работ.

Приложение №3 к Правилам приемки НИОКР, утвержденным Приказом Роспрома16.

09. 2004 №95.

Разделы ТЗ по ГОСТ 34. 602-89 (пример):

Общие сведения a. полное наименование системы и ее условное обозначение;

Пример: Полное наименование системы: Автоматизированная система "Управление" Условное обозначение: АСУ b. шифр темы или шифр (номер) договора;

Пример: Договор № ХХХ от ДД. ММ. ГГГГ c. наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты;

Пример: ЗАКАЗЧИК Наименование заказчика: ООО "…" Юридический адрес заказчика: … Фактический адрес заказчика: … Телефон: … Адрес электронной почты: … ИНН: … КПП: … ИСПОЛНИТЕЛЬ Наименование исполнителя: ООО "…" Юридический адрес исполнителя: … Фактический адрес исполнителя: … Телефон: … Адрес электронной почты: … ИНН: … КПП: … d. перечень документов, на основании которых создается система, кем и когда утверждены эти документы;

e. плановые сроки начала и окончания работы по созданию системы;

f. сведения об источниках и порядке финансирования работ;

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

2. Назначение и цели создания системы 3. Характеристика объекта автоматизации a. краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;

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

4. Требования к системе a. Требования к системе в целом;

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

c. Требования к видам обеспечения.

5. Состав и содержание работ по созданию системы a. перечень документов по ГОСТ 34. 201, предъявляемых по окончании соответствующих стадий и этапов работ;

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

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

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

6. Порядок контроля и приемки системы a. виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему);

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

c. статус приемочной комиссии (государственная, межведомственная, ведомственная).

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие a. приведение поступающей в систему информации (в соответствии с требованиями к информационному и лингвистическому обеспечению) к виду, пригодному для обработки с помощью ЭВМ;

b. изменения, которые необходимо осуществить в объекте автоматизации;

c. создание условий функционирования объекта автоматизации, при которых гарантируется соответствие создаваемой системы требованиям, содержащимся в ТЗ;

d. создание необходимых для функционирования системы подразделений и служб;

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

8. Требования к документированию a. согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34. 201 и научно-технической документации отрасли заказчика;


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

b. требования по документированию комплектующих элементов межотраслевого применения в соответствии с требованиями ЕСКД и ЕСПД;

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

9. Источники разработки: документы и информационные материалы (технико экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др. ), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

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

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

Также, функция — более четкий термин для описания сути назначения устройства;

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

o условия, характеризуются конкретными значениями данных. Например, масса изделия должна составлять 10 кг, место эксплуатации — тундра;

o ограничения, задают допустимую область данных. Например, вес изделия не должен превышать 10 кг, применять углеродистые стали;

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

Для конкретизации целей и требований, заданных нечётко либо качественно, применяют метод декомпозиции.

При формировании системы требований обязателен анализ следующих источников:

Доступность ресурсов, находящихся в распоряжении заказчика и разработчика:

финансовые, производственные, людские, временные.

Учет требований надзорных и лицензионных органов при проектировании, например, технологических комплексов (производств).

Жизненная среда проектируемой системы. Она задает требования, характеризующие взаимное влияние спроектированной системы и окружающих её живых и неживых объектов и внешней среды.

Составление списка требований ТЗ Анализ задания заказчика Исходное задание выдаётся заказчиком и оформляется в виде технических требований. Перевести эти требования на язык предметной области, сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения, осмыслить и уточнить исходные данные — первый этап работы. Исполнитель выполняет его в тесном контакте с заказчиком.

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

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

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

либо усовершенствовать прообраз, воспользовавшись ИКР;

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

Конкретизация целей проектирования После уточнения и обоснования целей разработки назначают соответствующие им функции. Чтобы предубеждения и психологическая инерция не сужали область поиска, а заказчик своей формулировкой задачи не предопределял направления поиска решения, желательно функцию формулировать обобщенно и в нейтральных терминах. Так, функцию «сбивать» (допустим, доски) лучше заменить термином «соединять», что позволяет отвлечься от естественной ассоциации — сбивать гвоздями, и предлагает более широкий круг возможных решений.

В процессе поиска наиболее полной и точной формулировки строится цепочка функций (дерево целей) — от первоначально предложенной до окончательно принятой.

Этому помогает ответ на вопрос «Зачем это нужно?» (и другие вопросы метода контрольных вопросов).

Обработка собранной информации 1. Обобщение и абстрагирование.

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

2. Проверка на противоречивость.

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

Условия и ограничения также следует проверять на противоречивость.

3. Разграничение требований на условия, ограничения и показатели качества.

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

4. Параметризация.

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

Основной метод конкретизации формулировок — построение дерева целей (И или ИЛИ-деревья): исходный показатель декомпозируется до выявления элементарных понятий, однозначно характеризуемых наборами параметров.

5. Усечение списка требований.

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

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

6. Сведение требований в единый документ и утверждение его заказчиком.

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

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

Задачи управления требованиями На каждом этапе процесса разработки существуют ключевые методы и задачи связанные с управлением требованиями. Рассмотрим стандартный процесс разработки с пятью фазами: исследованием, анализом осуществимости, дизайном, разработкой и тестированием и выпуском.

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

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

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

Анализ осуществимости На стадии анализа осуществимости определяется стоимость требований.

Для пользовательских требований текущая стоимость работы сравнивается с будущей стоимостью установленной системы. Задаются вопросы такие как: «Сколько нам сейчас стоят ошибки ввода данных?»

Деловая стоимость включает ответы на такие вопросы как: «У какого отдела есть бюджет для этого?» «Каков уровень возврата средств от нового продукта на рынке?»

«Каков уровень сокращения внутренних расходов на обучение и поддержку, если мы сделаем новую, более простую в использовании систему?»

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

«Нуждаемся ли мы в новом оборудовании для поддержки новой системы?»


Результатом стадии анализа осуществимости является бюджет и график проекта.

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

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

Выпуск Управление требованиями не заканчивается выпуском продукта. С этого момента полученные данные о приемлемости приложения собираются и используются во время фазы исследования для следующего поколения системы или выпуска. Таким образом, процесс начинается снова.

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

Виды требований по уровням Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

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

Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).

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

Описывается в системной спецификации (англ. system requirement specification, SRS).

Виды требований по характеру Функциональный характер — требования к поведению системы Бизнес-требования Пользовательские требования Функциональные требования Нефункциональный характер — требования к характеру поведения системы Бизнес-правила — определяют ограничения, проистекающие из предметной области и свойств автоматизируемого объекта (предприятия) Системные требования и ограничения — определения элементарных операций, которые должна иметь система, а также различных условий, которым она может удовлетворять. К системным ограничениям относятся ограничения на программные интерфейсы, требования к атрибутам качества, требования к применяемому оборудованию и ПО.

Атрибуты качества.

Внешние системы и интерфейсы.

Ограничения.

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

Нормативное обеспечение организации (регламенты, положения, уставы, приказы) Текущая организация деятельности объекта автоматизации Модели деятельности (диаграммы бизнес-процессов) Представления и ожидания потребителей и пользователей системы Журналы использования существующих программно-аппаратных систем Конкурирующие программные продукты Характеристики качественных требований Следующие характеристики являются общепризнанными:

Характеристика Объяснение Единичность Требование описывает одну и только одну вещь.

Требование полностью определено в одном месте и вся Завершённость необходимая информация присутствует.

Требование не противоречит другим требованиям и Последовательность полностью соответствует внешней документации.

Требование «атомарно». То есть оно не может быть Атомарность разбито на ряд более детальных требований без потери завершённости.

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

Актуальность Требование не стало устаревшим с течением времени.

Выполнимость Требование может быть реализовано в пределах проекта.

Оно выражает объективные факты, не субъективные мнения. Возможна только одна интерпретация.

Недвусмысленность Определение не содержит нечётких фраз. Использование отрицательных утверждений и составных утверждений запрещено.

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

Реализованность требования может быть определена через Проверяемость один из четырёх возможных методов: осмотр, демонстрация, тест или анализ.

Методы выявления требований Интервью, опросы, анкетирование Мозговой штурм, семинар Наблюдение за производственной деятельностью, «фотографирование»

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

Документирование требований Один общий способ задокументировать требование — это написать утверждение о том, что должна сделать система. В зарубежной и российской практике встречаются следующие типы документов требований:

Концепция программы Спецификация программного обеспечения (англ. Software Requirements Specification, SRS) Изменение требований В общем случае требования изменяются со временем. После того, как требования определены и одобрены, изменения должны попадать под контроль внесения изменений.

Пример технического задания на создание автоматизированной системы «Корпоративное хранилище данных»

Разделы технического задания:

Общие сведения Назначение и цели создания системы Назначение системы Цели создания системы Характеристика объектов автоматизации Требования к системе Требования к системе в целом Требования к функциям, выполняемым системой Требования к видам обеспечения Состав и содержание работ по созданию системы Порядок контроля и приёмки системы Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие Требования к документированию Источники разработки 1. Общие сведения 1. 1. Наименование системы 1. 1. 1. Полное наименование системы Например:

Полное наименование: Корпоративное хранилище данных.

1. 1. 2. Краткое наименование системы Например:

Краткое наименование: КХД, Система.

1. 2. Основания для проведения работ Перечень документов, на основании которых создается система, кем и когда утверждены документы. Указывается шифр темы или шифр (номер) договора, дата договора.

Например:

Работа выполняется на основании договора № … от … между … 1. 3. Наименование организаций – Заказчика и Разработчика 1. 3. 1. Заказчик Заказчик:

Адрес фактический: г. Уфа...

Телефон / Факс: +7 … 1. 3. 2. Разработчик Разработчик: ЗАО Адрес фактический: г....

Телефон / Факс: +7 … 1. 4. Плановые сроки начала и окончания работы Указываются плановые сроки начала и окончания работ по созданию системы (на основании Договора). Если сроки определены не точно, то указать на какой стадии сроки уточняются.

1. 5. Источники и порядок финансирования Если не целесообразно указывать эти сведения, то дается ссылка на Договор.

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

Например:

Работы по созданию КХД сдаются Разработчиком поэтапно в соответствии с календарным планом Проекта. По окончании каждого из этапов работ Разработчик сдает Заказчику соответствующие отчетные документы этапа, состав которых определены Договором.

2. Назначение и цели создания системы 2. 1. Назначение системы Указать вид автоматизируемой деятельности (указать для управления какими процессами предназначена система).

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

КХД предназначена для повышения оперативности и качества принимаемых управленческих решений сотрудниками Заказчика.

Основным назначением КХД является автоматизация информационно-аналитической деятельности в бизнес-процессах Заказчика.

В рамках проекта автоматизируется информационно-аналитическая деятельность в следующих бизнес-процессах:

анализ финансово-хозяйственной деятельности;

информационная поддержка процессов бюджетирования;

2. 2. Цели создания системы Наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АИС;

критерии оценки достижения целей создания системы.

КХД создается с целью:

обеспечения сбора и первичной обработки исходной информации, необходимой для подготовки отчетности по показателям деятельности;

...

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

время сбора и первичной обработки исходной информации;

...

3. Характеристика объектов автоматизации Приводятся краткие сведения об области деятельности Заказчика (или подразделения организационной структуры Заказчика, для нужд которого разрабатывается система) и сферы автоматизации с указанием ссылок на ранее разработанные документы, содержащие более подробные сведения об организации заказчика.

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

Выделены следующие процессы в деятельности указать подразделение Заказчика, в рамках которых производится анализ информации и вынесены соответствующие выводы о возможности их автоматизации:

Структурное Наименование Возможность Решение об подразделение процесса автоматизации автоматизации в ходе проекта Анализ отклонений фактических Будет Отдел анализа Возможна значений автоматизирован показателей от плановых............

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

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

В Системе предлагается выделить следующие функциональные подсистемы:

подсистема сбора, обработки и загрузки данных, которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных;

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

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

Указываются требования к способам и средствам информационного обмена между компонентами системы.

В качестве протокола взаимодействия между компонентами Системы на транспортно сетевом уровне необходимо использовать протокол TCP/IP.

Для организации информационного обмена между компонентами Системы должны использоваться специальные протоколы прикладного уровня, такие как: NFS, HTTP и его расширение HTTPS, NetBios/SMB, Oracle TNS.

Для организации доступа пользователей к отчетности должен использоваться протокол презентационного уровня HTTP и его расширение HTTPS.

Приводятся требования к характеристикам взаимосвязей со смежными системами.

Смежными системами для КХД являются:

- информационные системы оперативной обработки данных Заказчика;

-...

Источниками данных для Системы должны быть:

- Информационная система управления предприятием (СУБД MS SQL).

-...

Перечень предпочтительных способов взаимодействия со смежными системами приведен ниже.

- Информационная система управления предприятием - с использованием промежуточной базы данных (ПБД).

-...

Определяются требования к режимам функционирования системы.

Например:

Система должна поддерживать следующие режимы функционирования:

- Основной режим, в котором подсистемы КХД выполняют все свои основные функции.

-… В основном режиме функционирования Система КХД должна обеспечивать:

- работу пользователей режиме – 24 часов в день, 7 дней в неделю (24х7);

-… В профилактическом режиме Система КХД должна обеспечивать возможность проведения следующих работ:

- техническое обслуживание;

-… Общее время проведения профилактических работ не должно превышать X% от общего времени работы системы в основном режиме (Y часов в месяц).

Указываются требования по диагностированию системы (какие средства будут использоваться или создаваться, чтобы обеспечить диагностику системы).

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

Диагностирование Системы должно осуществляться следующими штатными средствами, входящими в комплект поставки программного обеспечения:- СУБД указывается ПО администратора позволяющее проводить мониторинг;

- ETL-средство -..

- средство визуализации -...

Обязательно ведение журналов инцидентов в электронной форме, а также графиков и журналов проведения ППР.

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

4. 1. 2. Требования к численности и квалификации персонала системы и режиму его работы 4. 1. 2. 1. Требования к численности персонала В состав персонала, необходимого для обеспечения эксплуатации КХД в рамках соответствующих подразделений Заказчика, необходимо выделение следующих ответственных лиц:

- Руководитель эксплуатирующего подразделения - 1 человек.

- Администратор подсистемы сбора, обработки и загрузки данных - 2 человека.

- Администратор подсистемы хранения данных - 2 человека.

- Администратор подсистемы формирования и визуализации отчетности - 1 человек.

Данные лица должны выполнять следующие функциональные обязанности.

- Руководитель эксплуатирующего подразделения - на всем протяжении функционирования КХД обеспечивает общее руководство группой сопровождения,...

- Администратор подсистемы сбора, обработки и загрузки данных - на всем протяжении функционирования КХД обеспечивает контроль процессов ETL, подготовку и загрузка данных из внешних источников в хранилище данных,...

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

- Администратор подсистемы формирования и визуализации отчетности - на всем протяжении функционирования КХД обеспечивает поддержку пользователей, формирование отчетности,...

4. 1. 2. 2. Требования к квалификации персонала К квалификации персонала, эксплуатирующего Систему КХД, предъявляются следующие требования.

- Конечный пользователь - знание соответствующей предметной области;

знание основ многомерного анализа;

знания и навыки работы с аналитическими приложениями..

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

знание методологии проектирования ETL процедур;

знание интерфейсов интеграции ХД с источниками данных;

знание СУБД;

знание языка запросов SQL.

- Администратор подсистемы хранения данных - глубокие знания СУБД;

знание архитектуры «Звезда» и «Снежинка»;

опыт администрирования СУБД;

знание и навыки операций архивирования и восстановления данных;

знание и навыки оптимизации работы СУБД.

- Администратор подсистемы формирования и визуализации отчетности - понимание принципов многомерного анализа;

знание методологии проектирования хранилищ данных;

знание и навыки администрирования приложения;

знание языка запросов SQL;

знание инструментов разработки.

4. 1. 2. 3. Требования к режимам работы персонала Персонал, работающий с Системой КХД и выполняющий функции её сопровождения и обслуживания, должен работать в следующих режимах:

- Конечный пользователь - в соответствии с основным рабочим графиком подразделений Заказчика.

- Администратор подсистемы сбора, обработки и загрузки данных – двухсменный график, поочередно.

- Администратор подсистемы хранения данных – двухсменный график, поочередно.

- Администратор подсистемы формирования и визуализации отчетности – в соответствии с основным рабочим графиком подразделений Заказчика.

4. 1. 3. Показатели назначения 4. 1. 3. 1. Параметры, характеризующие степень соответствия системы назначению Система должна обеспечивать следующие количественные показатели, которые характеризуют степень соответствия ее назначению:

- Количество измерений – X.

- Количество показателей – Y.

- Количество аналитических отчетов – Z.

4. 1. 3. 2. Требования к приспособляемости системы к изменениям Обеспечение приспособляемости системы должно выполняться за счет:

- своевременности администрирования;

-...

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

Вероятное условие Требование Нарушения в работе системы внешнего электроснабжения серверного оборудования Функционирование в полном объеме.

продолжительностью до 15 мин.

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

4. 1. 4. Требования к надежности 4. 1. 4. 1. Состав показателей надежности для системы в целом Например:

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

Надежность должна обеспечиваться за счет:

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

- своевременного выполнения процессов администрирования Системы КХД;

- соблюдения правил эксплуатации и технического обслуживания программно аппаратных средств;

- предварительного обучения пользователей и обслуживающего персонала.



Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.