Риски в разработке ПО связанные с требованиями

© 2009 Илья Корнипаев

Риски в разработке ПО связанные с требованиями


Рамки проектаВозможности

продукта/качество

Стоимость Сроки

Лучше

Дешевле Быстрее

2

Возможные решения


Возможности vs. Качество

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

3


Что такое риски?

Риск проекта - это неопределенное событие или условие, которое будет иметь положительное или отрицательное воздействие как минимум на одну цель проекта, если оно произойдет. (PMBOK)

4


Бонус - «Популярные» риски

5

Трамвай 'Аннушка' на Патриарших прудах


Бонус - Как победить трамвай?

6

Делайте остановки

Дублируйте критические функции и

органы


Некоторые другие события

• Поступил запрос на изменение требований в ходе работы;

• Обнаружена ошибка в оценках;• Продукт не прошел приемку у

Заказчика.

7


Структура идентификации риска

• Описание события.• Последствия влияния события на

проект.• Причины возникновения.• Методы увеличения/уменьшения

влияния.

8


Запрос на изменение

9



• Описание события:

Поступил запрос на изменение в ходе работы• Последствия влияния события на

проект:

10



От чего зависят последствия возникновения запроса на изменение:

– Размер и сложность запроса;– Его влияния на ход проекта;– Процедуры управления изменениями;– Договора/контракта;

11



Причины возникновения:– На стороне Заказчика:

• Изменения внешних факторов (законодательство, конкуренция);

• Изменение бизнеса;• еще ?

– На стороне Разработчика:• Низкое качество требований;• Пропущенные требования;• Пропущенные заинтересованные стороны;• Низкое качество дизайна и прототипов;• еще?

12



Методы увеличения/уменьшения влияния:– «Правильные люди» на стороне Заказчика и

Разработчика участвующие в процессе проектирования;

– Проверенные методы улучшения качества проектной документации;

– Работающие процедуры управления изменениями, в т.ч. в контрактах;

– Разбиение проекта на фазы.

13


Обнаружена ошибка в оценках

14




Обнаружена ошибка в оценках• Последствия влияния события на

проект:

15



Причины возникновения:– Недостаточная квалификация людей дававших

оценки; – Оценки даны на основе неточных данных:

• Низкое качество информации на основе которой давалась оценка;

• Использована новая технология/среда разработки;• еще?

16



Методы увеличения/уменьшения влияния:– «Правильные люди» в команде Разработки;– Улучшение качества требований и другой

проектной документации;– Использование проверенных

методологий/инструментов;– Обучение; – Прототипирование.

17


Продукт не прошел приемку

18




Продукт не прошел приемку у Заказчика• Последствия влияния события на

проект:

19



Причины возникновения:– Продукт был не готов к приемке (ну не успели); – Сделали не то что нужно:

• Сменился бизнес (но у разработчика не было информации об этом);

• Сменились люди на стороне Заказчика (принимают не те, кто формулировал требования);

• Потеря в канале (аналитики не донесли требования Заказчика до разработчиков);

• еще?

20



Методы увеличения/уменьшения влияния:– Квалифицированный ПМ (управление объемом,

сроками, ожиданиями).– Постоянный контакт с Заказчиком.

Прототипирование, предварительные показы, регулярные встречи;

– «Правильные» аналитики доступные на протяжении всего срока проекта;

– Улучшение качества требований и другой проектной документации.

21


Методы снижения рисков

Можно выделить следующие методы увеличения/уменьшения влияния рисков связанные с требованиями (и прочей проектной документацией), а так же с процессом их разработки:– Выбор правильных людей на соответствующие позиции как

на стороне Разработчика, так и на стороне Заказчика.– Постоянный состав людей участвующих в разработке

требований на протяжении всего проекта (как минимум преемственность и взаимозаменяемость)

– Проверенные методы улучшения качества проектной документации;

– Работающие процедуры управления изменениями, в т.ч. в контрактах;

– Прототипы.

22


Правильные люди• Каждая проектная роль обладает своей спецификой.

Очень немногим людям удается совмещать сразу несколько ролей на одном проект эффективно.

• К любой работе нужно иметь способности/склонности. Нужно учиться.

• Опыт важен.• Экспертиза vs. Практика.

23


Улучшение качества документов

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

24


Виды проверок

• Формальные и неформальные проверки• Проверки требований коллегами

аналитиками (peer review)• Согласования требований с

представителями заинтересованных сторон

• Согласования требований с разработчиками/проектировщиками.

25


Работающие процедуры

• Управление требованиями• Управление изменениями• Инструменты

26


Прототипы

• Преимущества:– Визуализация;– Динамика.

• Опасности:– Завышенные ожидания Заказчика;– Отвлечение от важных аспектов в сторону

несущественных мелочей.

27


Заключение

Сделать проект успешным вам помогут:

– Правильные люди доступные на все время проекта;

– Работающие процедуры;– Проверки и еще раз проверки;– Прототипы (а куда без них?)!

28


Спасибо!

Вопросы и ответы

29

Риски в разработке ПО связанные с требованиями

Business