2.Фреймовые системы и их функционирование. Обобщенная структура фрейма. Представление знаний фреймами.

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

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

ИМЯ ФРЕЙМА

Имя 1-го слота: значение 1-го слота

Имя 2-го слота: значение 2-го слота

Имя N-гo слота: значение N-гo слота.

В качестве значения слота может выступать имя другого фрей ма. Таким образом фреймы объединяются в сеть. Свойства фреймов наследуются сверху вниз, т.е. от вышестоящих к нижестоящим через АКО-связи (начальные буквы английских слов «A Kind Of», что можно перевести как «это»). Слот с именем АКО указы вает на имя фрейма более высокого уровня иерархии.

Например, на рис. 2.2 фрейм «Студент» имеет ссылки на вы шестоящие фреймы: «Человек» и «Млекопитающее». Поэтому на вопрос: «Может ли студент мыслить?» — ответ будет положительным, так как этим свойством обладает вышестоящий фрейм «Че ловек».

 

 

 

 

 

 

 

 

 

 

 

 

Если одно и тоже свойство указывается в нескольких связан ных между собой фреймах, то приоритет отдается нижестоящему фрейму. Так, возраст фрейма «Студент» не наследуется из выше стоящих фреймов.

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

3.Управление проектом ис. Выделенные роли исполнителей. Риски, управление рисками.

(! нет про управление проектом)

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

Для конкретного проекта это

может быть:

Невыполнение какого либо требования заказчика

Функционального и нефункционального

Бизнес требований и проектных требований.

(то есть это должно идти параллельно с этапом анализа и другими этапами)

Функции (на более познем  этапе)

Увеличение расходов

Нарушение графика

относятся к требованиям и архитектуре,

связанных с базовыми программными

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

нетехнические риски

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

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

Организация собирается создавать части заявленной системы на новом для нее языке.

При возникновении каких-либо проблем на любом из этапов разработки времени, отводимого клиентом на разработку, будет не хватать.

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

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

технические риски ----

Риски, связанные с новыми технологиями.

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

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

Риски, связанные с архитектурой

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

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

Риск неучтения необходимых внешних покупных компанент

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

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

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

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

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

Некоторые риски связаны с производительностью. Например.

Время отклика для варианта использования должно быть меньше 1 секунды.

Число одновременно выполняемых экземпляров варианта использования больше 10000 в час.

Сложившиеся методы управления рисками

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

• Риски выявляются  идентифицируются и на них стихино реагирует группа разработки 

• Быстрое реагирование— проектная группа реагирует на последствия риска, когда проблема уже возникла.

• Превентивный — проектная группа управляет рисками, постоянно

отслеживая условия их реализации.

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

отдельный процесс среди процессов проектирования управление рисками.

Совокупность процедур, направленных на …

эффективное управление рисками — дина-

мический процесс.

Шаги управления рисками

Идентификация (на выход формулировка риска)

Анализ

Планирование

Отслеживание

Управление (на выход - устраненные риски, переход к шагу анализ)

Шаг 1: идентификация риска

Источники риска • задачи и цели;

• лица, принимающие решения;

• методы управления организацией;

• заказчики и пользователи;

• финансовое состояние бюджет и расходы;

конкуренция,

• график;

• характеристики проекта;

• процесс разработки;

корпоративная культура.

• среда разработки;

• персонал;

• эксплуатационная среда;

• новые технологии.

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

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

развертывание инфраструктуры,

развертывание программного обеспечения,

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

компонентная разработка.

В рамках каждой из этих областей факторы риска могут быть также

сгруппированы по таким категориям, как

цели и задачи,

руководство,

менеджмент,

бюджет

и т. д.

При описании риска группа должна указать

формулировку

симптомы симптомы (проявление), если не очевидно из названия

вероятность возникновения

причины  то есть из за чего он возникает

последствия для проекта.

формулировку	симптомы симптомы(проявление),	причины  то есть из за чего он возникает

 

Опасность пажара (очевидна), на складе

 Как показано на рис. 5.3, каждая формулировка риска

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

Шаг 2: анализ риска

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

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

• Вероятность риска — это вероятность того, что событие действительно произойдет. Для оценки ее величины можно использовать

простую процентную шкалу (0-100).

Риски с вероятностью 100% уже реализовались; другими словами, это из-

вестные проблемы.

 … может найти более эффективным такой подход,

   при котором используются от 1 до 3 точек на этой шкале, соответствующие 25, 50 и 75%,

• последствия — оценка последствий реализации риска для проекта; может быть выражена в денежном эквиваленте или числом по 5 балльной шкале, которое показывает относительную важность

этой проблемы;

Анализ можно производить тестированием распространить список в котором

• идентификатор — название, уникально идентифицирующее формулировку риска (идентификаторы понадобятся для отслеживания

и отчетности);

• источник — источник может быть идентифицирован

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

по категории (задачи и цели, руководство, менеджмент и т. д.) или

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

• условия возникновения — описание условий, в которых риск может реализоваться и поставить проект под удар;

• вероятность — оценка вероятности реализации риска. Вероятность обычно выражается значениями от 1 до 3, представляющими величины в процентах (25. 50 и 75% соответственно);

• последствия — оценка последствий реализации риска для проекта; может быть выражена в денежном эквиваленте или числом по 5 балльной шкале, которое показывает относительную важность

этой проблемы;

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

• связанные риски— перечень идентификаторов рисков, связанных с данным; этот список полезен для выявления связанных и независимых рисков.

выявить десять основных рисков проекта.

Их  должны одобрить все участники проекта.

Дополнительный перечень важных рисков нужно включить в концепцию проекта (документ, созданный на стадии «Анализ») и в

основной план проекта, который создается на стадии планирования.

Шаг 3: план действий

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

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

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

• Исследование — Исследуется если необходимо риск

• Приемлемость —возможность игнорирования

• Управление может ли группа сделать что-нибудь, чтобы снизить воздействие риска, если он реализуется?

• Возможность избежать проблемы — можно ли избежать риска, изменив продукт?

После выявления рисков, нуждающихся в реагировании, группа

получает три возможности:

• снизить вероятность возникновения риска;

• уменьшить размеры потерь;

• изменить последствия риска(проявление его?)

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

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

.. на самом деле это способы воздействия

Управление ситуацией чтобы его обойти чтото изменитьт в работе что то добавить, сделать по другому

Избежания источника то есть

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

• передача контракта более квалифицированному подрядчику.

Чтобы гарантировать надежность выполнения проекта, группа должна предусмотреть

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

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

Решение о том, в какой момент обращаться к чрезвычайной стратегии, — это вопрос определения «порогового значения». Часто группа может установить «пороговые значения» для каждого чрезвычайного плана, основываясь на типе риска или виде последствий.

В табл.

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

Тип риска	Пороговое значение
Нарушение графика	Последняя дата обращения к чрезвычайной стратегии
	Последняя возможная дата выбора другого поставщика
Необходимость допол- нительных ресурсов	Последняя дата, когда остается время на поиск  ресурсов Самая крупная сумма штрафа или пени Самая большая величина возможного перерасхода
Дополнительные рас- ходы для заказчика	Лимит средств
Время на обучение	Лимит времени

Шаг 4: отслеживание риска

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

их снижения.

 Этот процесс включает в себя

определение параметров

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

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

 Отслеживание — это «сторожевой пес» управления рисками.

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

Этот документ должен содержать анализ влияния де-сяти главных рисков проекта.

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

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

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

Отчет о статусе риска может идентифицировать четыре возможных ситуации в управлении риском:

• риск устранен, план действий выполнен;

• действия происходят по плану, реализация плана продолжается;

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

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

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

Шаг 5: управление рисками (это реакция на изменения состояния риска)

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

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

• корректировку отклонения от плана;

• реакцию на достижение «пороговых значений»;

• совершенствование процесса управления рисками,

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

Билет №35