Контрольная работа: Оценка риска проектов программного обеспечения

· существует эффективный диалог между менеджером и командой проекта

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

2.2 Таксономия риска

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

Таксономия риска разрабатывалась SEI в течение трех лет и была проверена на более чем 30 проектах ПО. Она составлена с учетом типовых процессов жизненного цикла (ЖЦ) ПО и охватывает наиболее общие области риска проекта, касающиеся характеристик ПО, среды и процессов разработки и ограничений проекта. Эта таксономия может частично видоизменяться с учетом специфики конкретного проекта.

Таксономия риска SEI имеет иерархическую структуру и систематизирует источники (области) риска по трем уровням:

· класс,

· элемент класса,

· атрибут элемента

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

Таблица 2

Класс источника (области) риска Характеристика класса Элемент класса Атрибут элемента
1. Технические аспекты разработки (инженерия программного продукта) Связан с процессами (работами) на стадиях ЖЦ ПО (разработка требований, проектирование, кодирование, тестирование и др.), а также характеристиками ПО (требований, проекта, кода и др.) на этих стадиях Требования Стабильность
Полнота
Однозначность
Достоверность
Реализуемость
Новизна
Масштабность
Проект Функциональность
Сложность
Интерфейсы
Производительность
Тестируемость
Аппаратные ограничения
Приобретаемое ПО
Кодирование и автономное тестирование Реализуемость
Автономное тестирование
Кодирование/реализация
Интеграция и интеграционное тестирование Среда
Интеграция продукта
Интеграция системы
Нефункциональные характеристики ПО Удобство сопровождения
Надежность
Защищенность
Безопасность
Человеческие факторы
Спецификации
2. Среда и технология разработки Связан с методами, процедурами и инструментами, используемыми в ходе разработки ПО Процесс разработки Формализованность
Укомплектованность
Контролируемость процесса
Опыт применения
Контролируемость продукта
Система поддержкиразработки Мощность
Укомплектованность
Удобство применения
Опыт применения
Надежность
Сопровождаемость
Поставка
Процесс управления Планирование
Организация проекта
Опыт управления
Организация взаимодействия
Методы управления Мониторинг
Управление персоналом
Обеспечение качества
Управление конфигурацией
Рабочая обстановка Качество работы
Кооперация
Коммуникация
Моральный климат
3. Внешние ограничения проекта Связан с внешними для проекта факторами: наличие ресурсов разработки, условия заключаемых договоров, формы и особенности взаимодействия организаций-участников проекта ПО и др Ресурсы Сроки разработки
Штат проекта
Финансирование
Средства разработки
Условия договора Тип договора
Ограничения договора
Договорные зависимости
Интерфейсы проекта Заказчик
Смежники
Соисполнители
Головной исполнитель
Высшее руководство
Продавцы
Политические принципы

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

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

Таблица 3 - Список 10 главных программных рисков

Программные риски Техника управления рисками
1. Провалы персонала, плохой менеджмент Поиск талантов; рабочее соревнование; построение команды; персональные договора; перекрестные тренировки; предопределение ключевых фигур.
2. Нереальные сроки и бюджеты, ошибки в планировании работ над проектом Детализированный анализ стоимости и ожидаемых сроков; оценка стоимости; пошаговая разработка; повторное использование ПО; смягчение требований.
3. Разработка неправильных программных функций, ошибки проектирования системы Организационный анализ; анализ задачи; формулирование условий; пользовательские обзоры; прототипирование; ранние пользовательские руководства.
4. Разработка ошибочного интерфейса пользователя, плохая связь с заказчиком Прототипирование; сценарии; анализ задач; классификация пользователей (функциональная, стилевая, по загрузке).
5. Потеря прибыльности, неумение заключать договора, некачественное внедрение Снижение требований; прототипирование; стоимостный анализ; оценка стоимости.
6. Неверно сформулированные требования или изменяющиеся требования Высокий порог изменений; инкапсуляция информации; пошаговая разработка (откладывает изменения на дальнейшие шаги разработки).
7. Провалы во внешнем снабжении компонентами, неверный выбор коммерческого ПО Тестирования; проверки; справочные проверки; анализ совместимости.
8. Провалы во внешне исполняемых задачах, недостаточное тестирование и плохая интеграция ПО Справочные проверки; аудит; премиальные контракты; конкурентная разработка или прототипирование; построение команды.
9. Провалы производительности Имитационное моделирование; тестирование; прототипирование; подгонка инструментария.
10. Превышение возможностей компьютерной науки Технический анализ; анализ прибыльности; прототипирование; справочные проверки.

2.3 Методология оценки и управления риском

Исследования риска - это длительный (несколько месяцев) процесс, в ходе которого предпринимаются совместные усилия ведущей организацией по вопросам управления риском (в рамках страны, определенной отрасли или государственной структуры) и организацией-клиентом:

· по изучению существующей практики разработки конкретного проекта,

· оценке альтернативных приемов управления риском,

· выработке концепции управления риском клиента,

· обучению методам управления риском

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

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

Процесс управления риском проекта ПО включает следующие четыре стадии:

· согласование целей - определение нужд и целей проекта, достижение соглашений по управлению риском,

· подготовка работ - планирование и координация предстоящих работ по оцениванию риска проекта ПО,

· оценка риска - выполнение функций управления риском и получение рекомендаций по управлению риском проекта ПО,

· подготовка к устранению риска - разработка рекомендаций по устранению рисков по всем областям устранения риска, разработка плана управления риском и приведение его в действие.

Процесс управления риском применяется независимо от стадии ЖЦ, на которой находится проект ПО, и независимо от конкретного сценария и форм организации взаимодействия заказчика, исполнителя, соисполнителей и др. при разработке проекта.

Разработано 3 методологии :

· оценивание риска ПО - SRE (от Software Risk Evaluation),

К-во Просмотров: 306
Бесплатно скачать Контрольная работа: Оценка риска проектов программного обеспечения