Билет № 16

1. Статистическое моделирование на ЭВМ. Моделирование дискретных и непрерывных случайных величин.

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

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

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

Моделирование дискретных случайных величин:

-моделирование события: если случайное число меньше вероятности события, то событие наступило, и наоборот

-моделирование дискретно распределенных случайных величин: если случайное число Ri попало в интервал , , то случайная величина «а» приняла значение .

Моделирование непрерывных случайных величин:

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

F(x)=P(X<=xi)

f(х)=P(a<=x<=b)

1) Для того, чтобы разыграть возможное значение xi непрерывной случайной величины X, зная её функцию распределения F(x), надо выбрать случайное число ri, приравнять его к функции распределения и решить относительно xi полученное уравнение.

2) Для того, чтобы разыграть возможное значение xi непрерывной случайной величины X, зная плотность вероятности f(x), надо выбрать случайное число ri и решить относительно xi уравнение

, где «а»- наименьшее возможное конечное значение случайной величины «x»

 

2. Жизненный цикл программного средства.

ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания ИС (информационной системы) и заканчивается в момент его полного изъятия из эксплуатации.

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207. ISO (International Organization of Standardization) - международная организация по стандартизации, IEC (International Electrotechnical Commission) - международная комиссия по электротехнике.

Стандарт ISO/IEC 12207 определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

В соответствии со стандартом ISO/IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис. 1): пять основных процессов (приобретение, поставка, разработка, эксплуатация, сопровождение); восемь вспомогательных процессов, обеспечивающих выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем); четыре организационных процесса (управление, создание инфраструктуры, усовершенствование, обучение).

Для обеспечения выделенных процессов в ЖЦ можно выделить несколько групп исполнителей, т.е. субъектов реализующих процессы: заказчик - субъект, для которого разрабатывается, и у которого будет эксплуатироваться ИС; поставщик - субъект, обеспечивающий поставку ИС заказчику; разработчик - субъект, выполняющий разработку ПО; группа сопровождения - субъект или субъекты, выполняющие функции сопровождения. Функции сопровождения могут выполнять разработчики, но во многих случаях данные функции выполняются другими организациями.

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

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

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

В состав жизненного цикла ПО обычно включаются следующие стадии:

1. Стадия формирования требований к ПО. Данная стадия включает следующие этапы: Планирование работ; Проведение обследования деятельности автоматизируемого объекта (организации); Построение моделей деятельности организации. Обычно формируются 2 модели: модели «AS-IS» («как есть»); модели «ТО-ВЕ» («как должно быть»).

Каждая из моделей включает в себя полную функциональную и информационную модель деятельности организации, а также, в случае необходимости, модель, описывающую динамику поведения организации. Прорабатывается процесс перехода от модели «AS-IS» к модели «ТО-ВЕ».

2. Стадия проектирования (разработка системного проекта). На этом этапе определяются архитектура системы, ее функции, внешние условия функционирования, интерфейсы и распределение функций между пользователями и системой, требования к программным и информационным компонентам, состав исполнителей и сроки разработки. Основу системного проекта составляют модели «ТО-ВЕ».

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

4. Стадия тестирования и все последующие стадии включают соответствующие процессы из ЖЦ.

Основные модели ЖЦ ПО:

Каскадная модель - подразумевает ступенчатое выполнение стадий ЖЦ, следующая стадия наступает после полного завершения предыдущей стадии рис. 3.

Данная модель очевидна, последовательность этапов логична. Модель позволяет планировать объем работ при наличии данных о выполненных стадиях аналогичной системы.

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

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

Спиральная модель

Прикладное ПО создается не сразу, а по частям с использованием метода прототипирования. Создание прототипов осуществляется в несколько итераций, или витков спирали рис. 4.

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

При использовании данного подхода возможно не только наращивание прототипов, но и изменение прототипов нижнего уровня.

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

Рис. 3. Каскадная схема разработки ПО

 

Рис. 4. Спиральная модель ЖЦ ПО

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

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

3. Задачи обработки экспертных оценок. Групповая экспертная оценка объектов при непосредственном оценивании.

Задачей обработки являются:

1) Построение обобщённой оценки понятий и объектов на основе индивидуальных оценок эксперта.

2) Построение обобщённой оценки понятий и объектов на основе парного сравнения объектов каждым экспериментом.

3) Определение относительных весов взаимосвязанных объектов

4) Определение зависимостей между ранжировками

5) Определение согласованности мнений эксперта

6) Оценка надёжности обработки результата.

Групповая экспертная оценка объектов при непосредственном оценивании

Пусть имеется m экспертов которые провели оценку N объектов, причём каждый объект оценивали по L показателям.

Xijh - определяется из ряда чисел отрезка или по баллам.

i - номер объекта, j - номер эксперта, h - номер показателя

В качестве групповой оценки принимается средневзвешенное значение, которое определяется по следующим формулам:

Xi= ∑(h=1,l) ∑(j=1,m)Xijh*Kj*q h, где q h, - коэффициент весовых показателей сравнения объектов, Kj- коэффициент компетентности экспертов. К и q нормированы следующим образом : Сумма qh=1 , Сумма Кj=1.

qh может быть определён как средний коэффициент веса показателя h по всем экспертам, т.е.

qh=∑(j=1,m) Kj*q h j

Пусть h=1, тогда алгоритм вычисления групповых оценок имеет следующий вид:

1) шаг приближения t=0, тогда начальные значения всех коэффициентов компетентности одинаковы, Kj0 = 1/m.

2) t=1,2,3 … , n, групповая оценка будет определяться по след зависимости:

Xit=∑(j=1,m)Xij*Kjt-1

Нормировочный коэффициент равен: λt=∑(i=1,n)∑(j=1,m)Xit*Xij

Коэффициент компетентности j- го эксперта на шаге t определяется след образом: Kjt=(1/ λt )*∑(i=1,n)Xit*Xij

Коэффициент компетентности эксперта m из условия нормировки рассчитывается след образом: Kmt=1-∑(j=1,m)Kjt

3) расчёты ведут до удовлетворения признака окончания итерационного процесса: max(|Xit-Xit-1|)<E.

 

 

Hosted by uCoz