Управление рисками - Монте карло - PERT

Управление  рисками. Монте Карло. Датой рождения метода Монте-Карло принято считать 1949 г., когда американские ученые  Н. Метрополис и С. Улам опубликовали статью «Метод Монте -Карло», в которой систематически его изложили. Название метода связано с названием города Монте-Карло, где в казино играют в рулетку- одно из простейших устройств для получения случайных чисел, на использовании которых основан этот метод.

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

Модель  Монте-Карло не столь формализована  и является более гибкой, чем другие имитирующие модели. Причины здесь  следующие:

• при моделировании по методу Монте-Карло нет необходимости определять, что именно оптимизируется;
• нет необходимости упрощать реальность для облегчения решения, поскольку применение ЭВМ позволяет реализовать модели сложных систем;
• в программе для ЭВМ можно предусмотреть опережения во времени.

Недостатки  метода Монте-Карло:

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

Система контроля качества продукции состоит из трех приборов. Вероятность безотказной  работы каждого из них в течение времени Т равна 5/6. Приборы выходят из строя независимо друг от друга. При отказе хотя бы одного прибора вся система перестает работать. Найти вероятность Ротк того, что система откажет за время Т.

Для определения  того, выйдет или не выйдет из строя  за время Т отдельный прибор, будем подбрасывать игральную кость. Если выпадет одно очко, то будем считать, что прибор вышел из строя; если два, три, ..., шесть очков, то будем считать, что прибор работал безотказно. Вероятность того, что выпадет одно очко, так же как и вероятность выхода прибора из строя, равна 1/6, а вероятность того, что выпадет любое другое число очков, как и вероятность безотказной работы прибора, равна 5/6.

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

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

Статистический  метод PERT.

В военноморских силах США был создан метод анализа и оценки программ PERT (Program Evaluation and Review Technique) для реализации проекта разработки ракетной системы "Polaris", объединяющей около 3800 подрядчиков с числом операций более 60 тыс. Применение метода PERT позволяло руководству данной программы точно знать, что нужно делать в каждый момент времени и какой исполнитель эту работу выполняет, а также определять вероятность своевременного завершения отдельных операций на процессах проекта. Руководство программой создания ракетной системы по методу PERT оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока.

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

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

• оптимистичной (O);
• пессимистической (П);
• вероятностной (В).

Далее возможное  время вычисляется по формуле: . Коэффициенты 4 и 6 получены эмпирическим путем на основе статистических данных большого количества проектов. Результат расчета используется в дальнейшем как основа для получения остальных показателей проекта. Однако следует отметить, что схема PERT-анализа эффективна только в том случае, если вы можете обосновать значения всех трех оценок.

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

1. Проект начинать с правильного шага;
2. Поддержка темпа работы на проекте;
3. Обеспечение прогресса и принятия правильных решений;
4. Анализ завершенного проекта (преимуществ и недостатков).
1. Проект начинать с правильного шага. К правильному шагу относится формирование команды разработчиков из хороших специалистов, в том числе не более 20% звезд, наиболее приспособленных для хорошей работы над проектом (много звезд - создание конфликтов). В команду входят надежные разработчики с совместимыми характерами и рабочими привычками. Звезды решают сложные вопросы, разрабатывают более ответственные алгоритмы и проводят техническое обучение остальных членов команды. Для уточнения всех особенностей проекта разработчики садятся за стол переговоров с заказчиком и составляют взаимно приемлемый документ.
2. Поддержка темпа работы предполагает:
• уменьшение текучести кадров;
• контроль качества выполняемых работ;
• управление процессом разработки продукта, а не людьми команды.

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

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

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

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