- •Разработка и стандартизация программ: лекция 3,4
- •Как понять, что сбор требований завершен
- •Еще один способ определить, что выявление требований завершено — создать контрольный список функциональных
- •РЕЗУЛЬТАТЫ ЭТАПА
- •РИСКИ И УПРАВЛЕНИЕ ИМИ
- •Параметры, характеризующие риск:
- •Принято выделять две категории рисков:
- •Планирование управления рисками
- •исходными данными для планирования управления рисками служат:
- •Планирование управления риском
- •План управления рисками обычно включает в себя следующие элементы:
- •Пример иерархической структуры рисков проекта
- •Шкала оценки воздействия отражает значимость риска в случае его возникновения. Шкала оценки воздействия
- •10 наиболее распространенных рисков программного проекта (Барии Боэм ):
- •5 наиболее важных источников рисков любого проекта разработки ПО (Демарко и Листер ):
- •Причина
- •Качественный анализ рисков
- •Причина
- •Номер: R-101
- •Количественный анализ рисков
- •Риски, связанные с требованиями
- ••Включение артефактов проектирования в требования. Это налагает ненужные ограничения на возможности, доступные разработчикам.
- ••Качество проверки. Если проверяющие не знают, как проводить экспертизу документации требований и какие
- ••Незнакомые технологии, методы, языки, инструменты или аппаратное обеспечение. Не нужно недооценивать необходимость обучения
- ••Определение приоритетов требований. Удостоверьтесь, что каждое функциональное требование, функция или вариант использования получило
- ••Определение нефункциональных требований. Поскольку основное внимание, естественно, обращено к функциональности продукта, легко упустить
- ••Образ и границы проекта. Расползание границ становится более вероятным, если у лиц, заинтересованных
- ••Полнота и корректность спецификации требований. Чтобы требования точно определяли потребности клиента, применяйте метод
- •Выводы
- •ИСПОЛЬЗУЕМЫЕ ИСТОЧНИКИ:
План управления рисками обычно включает в себя следующие элементы:
Определение подходов, инструментов и источников данных, которые могут использоваться . для управления рисками в данном проекте.
Распределение ролей и ответственности. Список позиций выполнения, поддержки и управления рисками для каждого вида операций, включенных в план управления рисками, назначение сотрудников на эти позиции и разъяснение их ответственности.
Выделение ресурсов и оценка стоимости мероприятий, необходимых для управления рисками. Эти данные включаются в базовый план по стоимости проекта.
Определение сроков и частоты выполнения процесса управления рисками на протяжении всего жизненного цикла проекта, а также определение операций по управлению рисками, которые необходимо включить в расписание проекта.
Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Такую структуру можно разработать с помощью составления иерархической структуры рисков.
Общие подходы для определения уровней вероятности, шкалы воздействия и близости рисков на проект.
Пример иерархической структуры рисков проекта
Шкала оценки воздействия отражает значимость риска в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.
Хотя риск может воздействовать и на сроки проекта, и на качество получаемого продукта, но все эти отклонения могут быть оценены в денежном эквиваленте. Например, последствия задержка по срокам для заказной разработки может быть выражена в сумме денежных санкций, определенных в контракте.
Вес |
Значение |
Критерий |
3 |
Катастрофические |
Потери более $100K |
2 |
Критичные |
Потери от $10K до $100K |
1 |
Умеренные |
Потери менее $10K |
Еще одной важной характеристикой риска является близость его наступления. Может быть применена, например, следующая градация: очень скоро, не очень скоро, очень нескоро.
10 наиболее распространенных рисков программного проекта (Барии Боэм ):
1.Дефицит специалистов.
2.Нереалистичные сроки и бюджет.
3.Реализация несоответствующей функциональности.
4.Разработка неправильного пользовательского интерфейса.
5."Золотая сервировка", перфекционизм, ненужная оптимизация и оттачивание деталей.
6.Непрекращающийся поток изменений.
7.Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
8.Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
9.Недостаточная производительность получаемой системы.
10."Разрыв" в квалификации специалистов разных областей знаний.
5 наиболее важных источников рисков любого проекта разработки ПО (Демарко и Листер ):
1.Изъяны календарного планирования
2.Текучесть кадров
3.Раздувание требований
4.Нарушение спецификаций
5.Низкая производительность
Результатом идентификации рисков должен стать список рисков с описанием их основных характеристик: причины, условия, последствий и ущерба.
Причина |
Условия |
Последствия |
Ущерб |
Требования не ясны. |
Отсутствие описания |
Задержка начала |
Задержки в сроках сдачи |
|
сценариев использования разработки прикладного |
готового продукта и |
|
|
системы. |
ПО. Большой объем |
дополнительные |
Недостаток |
|
переработок. |
трудозатраты. |
Архитектура и код |
Большое число ошибок. |
Задержки в сроках сдачи |
|
квалифицированных |
низкого качества. |
Большие затраты на их |
готового продукта и |
кадров. |
|
исправление. |
дополнительные |
Текучесть кадров. |
|
|
трудозатраты. |
Частая смена участников |
Низкая |
Задержки в сроках сдачи |
|
|
команды. |
производительность при |
готового продукта и |
|
|
вводе новых участников в дополнительные |
|
|
|
проект. |
трудозатраты. |
Список рисков проекта создания «Автоматизированной системы продажи документации»
Качественный анализ рисков
Качественный анализ рисков включает в себя расстановку рангов для идентифицированных рисков. При анализе вероятности и влияния предполагается, что никаких мер по предупреждению рисков не производится.
Качественный анализ рисков включает:
•Определение вероятности реализации рисков.
•Определение тяжести последствий реализации рисков.
•Определения ранга риска по матрице «вероятность — последствия».
•Определение близости наступления риска.
•Оценка качества использованной информации.
Причина |
Вероятность |
Воздействие |
Ранг |
Требования не ясны |
Очень вероятно |
Катастрофические |
9 |
Недостаток |
Очень вероятно |
Критичные |
6 |
квалифицированных |
|
|
|
кадров. |
|
|
|
Текучесть кадров. |
Возможно |
Критичные |
4 |
Матрица рангов главных выявленных рисков проекта создания «Автоматизированной системы продажи документации»
Ранг риска и матрица вероятностей и последствий
Номер: R-101 |
Категория: Технологический. |
Причина: Недостаток квалифицированных |
Симптомы: Разработчики будут использовать новую |
кадров. |
платформу — J2EE. |
Последствия: Низкая производительность |
Воздействие: Увеличение сроков и трудоемкости |
разработки |
разработки. |
Вероятность: Очень вероятно. |
Степень воздействия: Критичная. |
Близость: Очень скоро. |
Ранг: 6. |
Исходные данные: «Содержание проекта», «План обеспечения ресурсами», Протоколы совещаний №21 от 01.06.2008, №27 от 25.06.2008.
Для оценки рисков необходима точная и адекватная информация. Использование неточной информации ведет к ошибкам в оценке. Неверная оценка риска также является риском.
Критерии оценки качества используемой при анализе информации:Степень понимания риска.
Доступность и полнота информации о риске.
Надежность, целостность и достоверность источников данных.
Количественный анализ рисков
Количественный анализ производится в отношении тех рисков, которые в процессе качественного анализа были квалифицированы как имеющие высокий и средний ранг.
Для количественного анализа рисков могут быть использованы следующие методы:
•Анализ чувствительности.
•Анализ дерева решений.
•Моделирование и имитация.
Влияние факторов профессионализма разработчиков ПО на трудозатраты по проекту.
