38. Управление рисками проекта. Ранжирование, планирование управления, разрешение и наблюдение риска.
Влияние риска вычисляют по приведенной формуле:
RE=P(UO)*L(UO)
P(UO) – вероятность неудовлетворительного результата.
L(UO) – потери от неудовлетворительного результата
RE – показатель риска.
При разработке программного продукта неудовлетворительным результатом м. б.
Превышение бюджета
Низкая надежность
Некорректное функционирование
Управление рисками включает 6 действий:
Идентификация (выявление) риска.
Анализ риска – оценка вероятности и величины потери по каждому элементу риска
Ранжирование риска (упорядочивание по степени влияния)
Планирование управления риском (подготовка к работе с каждым элементом риска)
Разрешение риска (устранение или разрешение элемента риска)
Наблюдение риска (отслеживание динамики и выполнение корректировки действий)
1-3) Оценивание риска 4-6)Контроль риска
3) Ранжирование – назначение каждому элементу риска приоритета, который пропорционален влиянию элемента на проектирование. Это позволяет выделить категории элементов риска и определить наиболее важный из них. Для большинства проектировщиков количество рисков 30-40. В этом случае управления рисками затруднено. Поэтому надо определить наиболее важные из рисков. Опыт показывает, что 80% рисков приходится на долю 20% от общего количества элементов. В ходе ранжирования определяются эти 20% и работают с ними.
4) Планирование управления рисками
Цель – сформулировать набор функций управления каждым элементом риска. Эталонный уровень риска обычно выбирают:
1) превышение стоимости
2) срыв планирования
3) упадок производительности
Они чаще всего являются причиной прекращения проекта. В фазовом производстве риска эталонному уровню риска соответствует точка на эталонной кривой. В эталонной точке решается продолжать проект или прекратить
На практике эталонный уровень представляют сферой в N-мерном пространстве признаков, где наблюдаются неопределенности.
5) Основанием за наблюдением и разрешением риска является план по управлению им. Работы по наблюдения проводятся от начала и до конца разработки. Разрешение риска – выполнение условий по его уменьшению.
6) Наблюдение риска гарантирует:
1) цикличность процесса слежения за риском
2) вызов необходимой корректировки действий
Для управления риском используется методика отслеживания первых 10 верхних элементов риска. Она призвана концентрировать внимание на факторах повышения риска, экономит время и минимизирует непредвиденные ситуации. Шаги методики:
1) введение и ранжирование наиболее существенных элементов риска в проекте
2) планирование регулярных просмотров процесса разработки
3) каждый просмотр начинать обсуждать с изменений в 10 первых элементах риска. При этом фиксируется текущий приоритет, предыдущий приоритет и частоту попадания элемента в 10-ку.
4) Концентрировать внимание участников разработки на всех элементах из 10-ки.
39. Метрики объектно-ориентированных программных систем. Локализация. Инкапсуляция. Информационная закрытость
ОО-метрики вводятся с целью:
1) улучшения понимания качества продукта;
2) оценки эффективности процесса конструирования;
3) улучшения качества работы на этапе проектирования.
Для ОО-системы существует 5 метрических характеристик:
1) локализация;
2) инкапсуляция;
3) информационная закрытость;
4) наследование;
5) абстрагирование.
(1) — способ группировки информации в программе. В ОО-среде это происходит внутри классов/объектов. Т.к. базовый элемент — класс, локализация основывается на объектах. Метрики применяются к классу/объекту как комплексной сущности.
Метрики, отражающие способы взаимодействия классов, должны быть приспособлены к отношениям «один-ко-многим» и «многие-ко-многим».
(2) — инкапсулируются обязанности классов, задаваемые его свойствами. Для метрик учёт инкапсуляции приводит к смещению фокуса измерений с одного модуля на группу свойств обрабатывающих модулей (операций).
(3) — делает невидимыми операционные детали программного компонента. Считается, что для качественных ОО-систем характерен высокий уровень закрытости.
(4) — распространяется через все уровни иерархии классов. Не-ОО-системы не поддерживают эту характеристику.
(5) — выделение главного в компоненте/системе. Т.к. главный элемент ОО-системы — класс, следует понимать, что соответствующие метрики должны представлять и оценивать классы в терминах абстракции.