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

1. Изменение требований
4
Изменение требований
TEKAMA
Software Engineering Professional Program © 2007. 4-1

2. Изменение требований
Цели и задачи
• Что такое изменение
• Управление запросами на изменение
– кто вовлечен
– процесс изменения
• Оценка степени изменения
• Анализ влияний
– оценка, планы, графики работ
• Согласование изменения
TEKAMA
Software Engineering Professional Program © 2007. 4-2

3. Изменение требований
Вопросы для размышления
• Что такое изменение? Почему они происходят?
– кто инициирует изменение?
– всегда ли изменение это плохо?
• Возможно ли эффективно управлять изменениями и как
это делать?
• Как изменения влияют на проект?
• Что можно сделать, столкнувшись с изменением?
TEKAMA
Software Engineering Professional Program © 2007. 4-3

4. Изменение требований
“Изменение неизбежно, прогресс только возможен...“
Аноним
“Не важно на какой фазе жизненного цикла системы вы находитесь,
система изменится, а желание ее изменить будет сохраняться в
течение всего жизненного цикла.”
Берсофф
“Каждый раз, когда я понимаю, где это… они его перемещают”
Аноним
TEKAMA
Software Engineering Professional Program © 2007. 4-4

5. Изменение требований
Непрекращающийся запрос
изменений
RE’01 Compliance Automation Inc. Hooks -- 7
TEKAMA
Software Engineering Professional Program © 2007. 4-5

6. Изменение требований
Почему изменяются требования
• Заказчик
– Я узнаю это, когда увижу
– Я передумал
– Я забыл, что нам также требуется это
• Рынок
– Мы не можем это больше продавать, рынок требует что-то другое
(изменения внешней среды/текущих применений)
– Если мы не поставим это завтра, то никто этого не купит
• Разработка
– Неточное определение границ проекта
– Требования неправильно поняты или плохо определены
– Мы, прежде всего, просто их не поняли
– Сработали архитектурные риски
TEKAMA
Software Engineering Professional Program © 2007. 4-6

7. Изменение требований
Всегда ли изменение это плохо?
• Что на самом деле означает изменение?
– просто невозможно определить все требования заранее
– мир меняется по мере выполнения разработки
• Можно лучше управлять изменениями, если
– предложенные изменения требований были тщательно оценены
прежде, чем совершены
– соответствующие лица принимают компетентные бизнес решения
о запрошенных изменениях
– одобренные изменения сообщаются всем вовлеченным лицам
– изменения требований включаются согласованным образом
TEKAMA
Software Engineering Professional Program © 2007. 4-7

8. Изменение требований
Выбор жизненного цикла
Одноразовое
n
Дискретность подхода
ПОШАГОВЫЙ прототипировани
Поэтапная поставка е Гибкий (Agile)
ЭВОЛЮЦИОННЫЙ
Спиральный
можно ли успешно
создать систему “одним
Разработка типа
махом”, если точно
“Большой неизвестно, что
взрыв" создается?»
ВОДОПАД
1
Изменчивость требований
«Низкая» «Высокая»
TEKAMA
Software Engineering Professional Program © 2007. 4-8

9. Изменение требований
Типичные проблемы при управлении
изменениями
• Требования часто изменяются
• Изменения требований происходит на позднем этапе процесса
разработки
• Часто добавляются новые требования
• Требования включаются и исключаются из границ проекта
• Изменения требований не сообщаются всем заинтересованным лицам
проекта
• Предложенные изменения теряются
• Статус запросов на изменение неизвестен
• Заинтересованные лица проекта обходят формальный процесс
контроля изменений
• Изменение требований требуют больше усилий, чем планировалось, и
влияет на большее количество компонент, чем ожидалось
• Изменения ухудшают качество в связи с побочным влиянием
• Изменения негативно влияют на другие требования
TEKAMA
Software Engineering Professional Program © 2007. 4-9

10. Изменение требований
Управление рамками проекта
Некоторые общие рекомендации
• Документируйте представление, рамки и ограничения
новой системы как часть бизнес требований
• Оценивайте вновь предложенное свойство/требование с
позиции бизнес-целей, рамок проекта и представления
• Привлекайте заказчиков в процесс активного выявления
требований, чтобы избежать пропуска требований
• Разрабатывайте прототипы, которые позволяют быстро
оценить возможную реализацию
• Используйте короткие циклы разработки и поэтапный
выпуск
• Научитесь говорить «НЕТ», или как минимум «НЕ
СЕЙЧАС»
TEKAMA
Software Engineering Professional Program © 2007. 4-10

11. Изменение требований
Процесс контроля за изменениями
Преимущества использования
• Как часто используют некоторый процесс?
• Какая польза от хорошего процесса?
– позволяет принимать эффективные бизнес-решения
– позволяет отслеживать все предложенные изменения
– является механизмом фильтрации, обеспечивающим
включение наиболее подходящих изменений
• Хороший процесс
– хорошо документирован
– должен быть как можно проще
– эффективен
Если предлагаемое изменение не настолько существенно для заинтересованного
лица, чтобы потратить несколько минут и пропустите его через простой
стандартный канал… то стоит ли его вообще рассматривать?
TEKAMA
Software Engineering Professional Program © 2007. 4-11

12. Изменение требований
Политика управления изменениями
• Все изменения требований должны следовать процессу или не
рассматриваться
• Никакое проектирование или реализация (кроме исследования
осуществимости) не выполняются для неутвержденных изменений
• Запрос на изменение не означает автоматическое одобрение. Все
изменения должны быть рассмотрены советом по управлению
изменениями.
• Содержание запроса должно быть видимо всем заинтересованным
лицам проекта
• Начальный текст запроса не должен изменяться
• Анализ воздействия должен проводиться для каждого изменения
• Каждое добавленное требование должно прослеживаться до запроса
на изменение
• Обоснование каждого одобрения запроса на изменение должно быть
записано
TEKAMA
Software Engineering Professional Program © 2007. 4-12

13. Изменение требований
Описание процесса контроля за
изменениями
1. Введение
• Назначение
• Границы
• Определения
2. Роли и ответственности
3. Состояние запроса на изменение
4. Входное критерии
5. Задачи
• Оценка запроса
• Принятие решения
• Внесение изменения
• Уведомление всех затронутых сторон
6. Проверка
• Проверка изменения
• Установка продукта
• Критерии выхода
• Отчет контроля изменений о статусе запроса
Приложение. Элементы данных, сохраненные для каждого запроса
TEKAMA
Software Engineering Professional Program © 2007. 4-13

14. Изменение требований
Распределение ролей в управлении
изменениями
Роль Описание роли и ответственность
 Председатель совета по  Возглавляет совет; как правило обладает правом принятия
управлению изменениями окончательного решения в том случае, когда совет не может
достичь соглашения
 Совет по управлению  группа, которая решает утвердить или отклонить
изменениями предложенные изменения
 Эксперт по оценке  Человек, который анализирует влияние изменения
 Специалист по модификации  Человек, отвечающий за внесение изменений после
утверждения запроса на изменение
 Инициатор запроса  Кто-либо, подающий новый запрос на изменение
 Получатель запроса  Человек, которому передают новые запросы на изменение
 Контролер изменений  Человек, проверяющий, правильно ли выполнено изменение
TEKAMA
Software Engineering Professional Program © 2007. 4-14

15. Изменение требований
Алгоритм обработки запроса на изменение
Инициатор подает Представлен
запрос на изменение
Эксперт по оценке анализирует
влияние изменения
Оценка Совет отклонил Отклонено
выполнена изменение
Совет решил внести изменение, определяет версию и
назначает ответственного за внесение изменения
Изменение было
Одобрено отменено, отменить
внесенные
Назначенный сотрудник
изменения
выполнил изменение и
Проверка не запросил проверку
оправдала ожиданий
Изменение Изменение было
отменено, отменить Отменено
внесено внесенные
Проверка подтвердила изменение изменения
Проверка не требуется, специалист Изменение было
установил модифицированный Проверено отменено;отменить внесенные
продукт изменения
Специалист выполнил модификацию
Завершено
TEKAMA
Software Engineering Professional Program © 2007. 4-15

16. Изменение требований
Совет по управлению изменениями
• Большие и маленькие проекты
• Состав совета по управлению изменениями
– должен представлять интересы всех сторон, которые принимают
решение в отношении рамок проекта
– управление проектом и продуктом, разработка, тестирование,
управление качеством, маркетинг/работа с заказчиками,
управление изменениями, техническая поддержка, и т.п.
• Устав совета по управлению изменениями
– описывает цели, рамки, членство, операционные процедуры
• Процесс принятия решений
– кто, когда, как
– вето?
TEKAMA
Software Engineering Professional Program © 2007. 4-16

17. Изменение требований
Измерение активности изменений
• Зачем измерять?
– обеспечивает понимание проектов/продуктов/процессов
– оценивает стабильность требований
– совершенствование процесса
• Что измерять (предложения модели зрелости характеристик)?
– количество полученных запросов на изменение, открытых и закрытых в
настоящее время
– общее число сделанных изменений (добавленных, удаленных,
модифицированных требований)
– количество запросов на изменение, исходящих из каждого источника
– количество изменений, предложенных и внесенных в каждое требование
после создания базовой версии
– общие усилия на обработку и реализацию запросов на изменение
• Что измерять и в какой степени зависит от ситуации, исходя из
потребностей, целей, и намерений использования данных
TEKAMA
Software Engineering Professional Program © 2007. 4-17

18. Изменение требований
Примеры измерения
Number of Proposed Changes
14
12
Количество предлагаемых изменений
8 10
8
7
6
6 4
5 2
4 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
3
2 Количество недель после сдачи
базовой версии спецификаций
1 требований
0
Marketing Customer Software Management Testing Maintenance
Engineering
Источники изменений
TEKAMA
Software Engineering Professional Program © 2007. 4-18

19. Изменение требований
Анализ влияния
• Обоснование?
– обеспечивает правильное понимание последствий
предложенного изменения
– помогает в принятии обоснованных решений по
одобрению предложенных изменений
– исследует предложенное изменение с целью
определения компонентов, которые будут добавлены,
удалены или модифицированы в результате
запрошенного изменения
– оценивает усилия, связанные с реализацией
изменения
• Кто из вас пользуется анализом влияния, и какими
процедурами вы пользуетесь?
TEKAMA
Software Engineering Professional Program © 2007. 4-19

20. Изменение требований
Анализ влияния
Процедура
• Анализ влияния предназначен для решения трех
основных вопросов
– понять последствия внесения изменения
– определения всех файлов, моделей и документов,
которые могут нуждаться в изменении, если изменение
будет реализовано
– определения задач, необходимых для реализации
изменения, и оценки усилий, необходимых для
завершения этих задач
TEKAMA
Software Engineering Professional Program © 2007. 4-20

21. Изменение требований
Анализ влияния
Процедура
Определите, Оцените Оцените Доложите о
находится ли влияние на приоритет результатах
изменение на график работ изменения, анализа влияния
Изучите Оцените Определите определяя
критическом проекта и совету по
подробные необходимые последовательность достоинства и
пути стоимость управлению
контрольные усилия задач для недостатки, изменениями
списки выполнения затраты и риск
TEKAMA
Software Engineering Professional Program © 2007. 4-21

22. Изменение требований
Учитесь говорить «НЕТ»
Посмотрим видеоклип
TEKAMA
Software Engineering Professional Program © 2007. 4-22

23. Изменение требований
Когда настало время принять решение
Какие имеются варианты?
• Отложить низкоприоритетные требования
• Привлечь дополнительных сотрудников
• Использовать сверхурочную работу,
предпочтительно с оплатой, на короткий период
времени
• Сдвинуть график работ для реализации новой
функциональности
• Пожертвовать качеством, чтобы закончить продукт
вовремя.
• Научиться говорить “НЕТ”
TEKAMA
Software Engineering Professional Program © 2007. 4-23

24. Изменение требований
Искусство и наука говорить “Нет”
• Невозможно всегда делать все, что пожелает
Заказчик
• Осознавайте связь между тем, что делаете, и
тем, какие ожидания формируют эти
действия
• Не идите по пути наименьшего
сопротивления
TEKAMA
Software Engineering Professional Program © 2007. 4-24

25. Изменение требований
Как говорить “Нет”, чтобы это
звучало как “Да”
• “Я бы хотел ответить на ваш вопрос, но я сейчас занят.
Давайте запланируем обсуждение на завтра в удобное для нас
обоих время”
• “Я помогу вам в этот раз, чтобы вы в будущем знали, как
самостоятельно решить подобную проблему. Я хочу, чтобы вы
понимали, что если это случится вновь, то у нас может не
оказаться человека, который сможет незамедлительно помочь
вам.”
• “Я бы помог Вам, если бы мог. К сожалению, моя загрузка на
ближайшие 3 месяца превышает мои возможности.”
• “Мы должны отдавать приоритет тем клиентам, которые
используют стандартные продукты (находятся на каком-нибудь
привилегированном обслуживании). Поскольку Вы не являетесь
таковым, мы обработаем вашу заявку, когда сможем, но боюсь
это случится не ранее чем через пару дней/недель/месяцев.”
TEKAMA
Software Engineering Professional Program © 2007. 4-25

26. Изменение требований
Преимущества подхода
• Дает выигрыш во времени
• Подчеркивает то, что вы ориентированы на клиента, но должны
делать выбор, кому помогать
• Сигнализирует о вашем соблюдении стандартов и дает клиенту
понять, в каких случаях не следует ожидать помощи
• Напоминает, что у клиентов также есть обязанности, и
разъясняет их.
• Стимулирует клиента к поиску альтернативных способов
решения своих проблем
• Поощряет самостоятельность клиентов
• И, самое главное, помогает формировать ожидания, которые
наиболее близки к тому, что вы реально можете сделать
TEKAMA
Software Engineering Professional Program © 2007. 4-26

27. Изменение требований
Применение подхода
• Анализ процесса обработки заявок.
• Опишите ситуации, в которых следует говорить “Нет”, и
трансформируйте их в стандарты.
• Зафиксируйте, что Вы никогда не будете делать.
• Идентифицируйте альтернативные варианты решения той или иной
проблемы (привлечение других отделов, компаний и т.д.) и
предоставьте эту информацию клиентам.
• Четко разъясните, кто ответственный за обработку того или иного
обращения клиента; не допускайте ситуации, когда Вы или Ваши
коллеги выставляете нереалистичные ожидания клиенту, не имея на
то права или возможности.
• Проанализируйте процессы/активности, оказание которых не дает
существенного эффекта, и избавьтесь от них.
• Разработайте шаблоны конкретных фраз, как говорить “Нет”.
TEKAMA
Software Engineering Professional Program © 2007. 4-27

28. Изменение требований
Заключение
• Изменение - это часть нашей жизни, и с ним надо
считаться
• Изменение - не всегда плохо, если правильно с ним
обходиться
• Анализ влияния способствует пониманию
последствий изменений, и как они воздействуют на
проект
• Существует множество вариантов работы с
изменениями, о которых должен знать руководитель
проекта
TEKAMA
Software Engineering Professional Program © 2007. 4-28

29. Изменение требований
Литература
• “Why Do Requirements Change”
• “Software change impact analysis” Arnold R.
and Shawn Bohner
• Getting to Yes: Negotiating Agreement Without
Giving In, by Roger Fisher, William Ury, and
Bruce Patton
TEKAMA
Software Engineering Professional Program © 2007. 4-29

30. Изменение требований
Вопросы?
TEKAMA
Software Engineering Professional Program © 2007. 4-30