l4 requirements

44-1

T E K A M ASoftware Engineering Professional Program © 2007.

Изменение требований


T E K A M A4-2Software Engineering Professional Program © 2007.


Цели и задачи

• Что такое изменение

• Управление запросами на изменение

– кто вовлечен

– процесс изменения

• Оценка степени изменения

• Анализ влияний

– оценка, планы, графики работ

• Согласование изменения



Вопросы для размышления

• Что такое изменение? Почему они происходят?– кто инициирует изменение?– всегда ли изменение это плохо?

• Возможно ли эффективно управлять изменениями и как это делать?

• Как изменения влияют на проект?• Что можно сделать, столкнувшись с изменением?



“Изменение неизбежно, прогресс только возможен...“ Аноним

“Не важно на какой фазе жизненного цикла системы вы находитесь, система изменится, а желание ее изменить будет сохраняться в течение всего жизненного цикла.”

Берсофф

“Каждый раз, когда я понимаю, где это… они его перемещают”

Аноним



Непрекращающийся запрос изменений

RE’01 Compliance Automation Inc. Hooks -- 7



Почему изменяются требования• Заказчик

– Я узнаю это, когда увижу

– Я передумал

– Я забыл, что нам также требуется это

• Рынок

– Мы не можем это больше продавать, рынок требует что-то другое

(изменения внешней среды/текущих применений)

– Если мы не поставим это завтра, то никто этого не купит

• Разработка

– Неточное определение границ проекта

– Требования неправильно поняты или плохо определены

– Мы, прежде всего, просто их не поняли

– Сработали архитектурные риски



Всегда ли изменение это плохо?

• Что на самом деле означает изменение?

– просто невозможно определить все требования заранее

– мир меняется по мере выполнения разработки

• Можно лучше управлять изменениями, если

– предложенные изменения требований были тщательно оценены

прежде, чем совершены

– соответствующие лица принимают компетентные бизнес решения

о запрошенных изменениях

– одобренные изменения сообщаются всем вовлеченным лицам

– изменения требований включаются согласованным образом



Выбор жизненного цикла

Изменчивость требований«Низкая» «Высокая»

ВОДОПАД

ПОШАГОВЫЙ

Ди

скр

етн

ос

ть п

од

хо

да

1

n

Разработка типа“Большой взрыв"

Поэтапная поставка

Спиральный

Одноразовоепрототипирование

ЭВОЛЮЦИОННЫЙ

Гибкий (Agile)

можно ли успешносоздать систему “одним махом”, если точно неизвестно, что создается?»



Типичные проблемы при управлении изменениями• Требования часто изменяются

• Изменения требований происходит на позднем этапе процесса разработки

• Часто добавляются новые требования

• Требования включаются и исключаются из границ проекта

• Изменения требований не сообщаются всем заинтересованным лицам проекта

• Предложенные изменения теряются

• Статус запросов на изменение неизвестен

• Заинтересованные лица проекта обходят формальный процесс контроля изменений

• Изменение требований требуют больше усилий, чем планировалось, и влияет на большее количество компонент, чем ожидалось

• Изменения ухудшают качество в связи с побочным влиянием

• Изменения негативно влияют на другие требования



Управление рамками проектаНекоторые общие рекомендации

• Документируйте представление, рамки и ограничения новой системы как часть бизнес требований

• Оценивайте вновь предложенное свойство/требование с позиции бизнес-целей, рамок проекта и представления

• Привлекайте заказчиков в процесс активного выявления требований, чтобы избежать пропуска требований

• Разрабатывайте прототипы, которые позволяют быстро оценить возможную реализацию

• Используйте короткие циклы разработки и поэтапный выпуск

• Научитесь говорить «НЕТ», или как минимум «НЕ СЕЙЧАС»



Процесс контроля за изменениями Преимущества использования

• Как часто используют некоторый процесс?• Какая польза от хорошего процесса?

– позволяет принимать эффективные бизнес-решения– позволяет отслеживать все предложенные изменения– является механизмом фильтрации, обеспечивающим

включение наиболее подходящих изменений• Хороший процесс

– хорошо документирован– должен быть как можно проще – эффективен

Если предлагаемое изменение не настолько существенно для заинтересованного лица, чтобы потратить несколько минут и пропустите его через простой стандартный канал… то стоит ли его вообще рассматривать?



Политика управления изменениями• Все изменения требований должны следовать процессу или не

рассматриваться

• Никакое проектирование или реализация (кроме исследования осуществимости) не выполняются для неутвержденных изменений

• Запрос на изменение не означает автоматическое одобрение. Все изменения должны быть рассмотрены советом по управлению изменениями.

• Содержание запроса должно быть видимо всем заинтересованным лицам проекта

• Начальный текст запроса не должен изменяться

• Анализ воздействия должен проводиться для каждого изменения

• Каждое добавленное требование должно прослеживаться до запроса на изменение

• Обоснование каждого одобрения запроса на изменение должно быть записано



Описание процесса контроля за изменениями1. Введение

1. Назначение2. Границы3. Определения

2. Роли и ответственности3. Состояние запроса на изменение4. Входное критерии5. Задачи

1. Оценка запроса2. Принятие решения3. Внесение изменения4. Уведомление всех затронутых сторон

6. Проверка1. Проверка изменения2. Установка продукта

7. Критерии выхода8. Отчет контроля изменений о статусе запроса

Приложение. Элементы данных, сохраненные для каждого запроса



Распределение ролей в управлении изменениями

Роль Описание роли и ответственность

Председатель совета по управлению изменениями

Совет по управлению изменениями

Эксперт по оценке

Специалист по модификации

Инициатор запроса

Получатель запроса

Контролер изменений

Возглавляет совет; как правило обладает правом принятия окончательного решения в том случае, когда совет не может достичь соглашения

группа, которая решает утвердить или отклонить предложенные изменения

Человек, который анализирует влияние изменения

Человек, отвечающий за внесение изменений после утверждения запроса на изменение

Кто-либо, подающий новый запрос на изменение

Человек, которому передают новые запросы на изменение

Человек, проверяющий, правильно ли выполнено изменение



Алгоритм обработки запроса на изменение

ЗавершеноЗавершено

ПредставленПредставлен

ОценкаОценкавыполненавыполнена

ПровереноПроверено

ИзменениеИзменениевнесеновнесено

ОдобреноОдобрено

ОтклоненоОтклонено

ОтмененоОтменено

Проверка не требуется, специалист установил модифицированный

продукт

Проверка не оправдала ожиданий

Изменение было отменено, отменить

внесенные изменения

Изменение было отменено, отменить

внесенные изменения

Совет отклонил изменение

Специалист выполнил модификацию

Проверка подтвердила изменение

Назначенный сотрудник выполнил изменение и

запросил проверку

Инициатор подает запрос на изменение

Эксперт по оценке анализирует влияние изменения

Совет решил внести изменение, определяет версию и назначает ответственного за внесение изменения

Изменение было отменено;отменить внесенные

изменения



Совет по управлению изменениями• Большие и маленькие проекты

• Состав совета по управлению изменениями

– должен представлять интересы всех сторон, которые принимают

решение в отношении рамок проекта

– управление проектом и продуктом, разработка, тестирование,

управление качеством, маркетинг/работа с заказчиками,

управление изменениями, техническая поддержка, и т.п.

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

– описывает цели, рамки, членство, операционные процедуры

• Процесс принятия решений

– кто, когда, как

– вето?



Измерение активности изменений• Зачем измерять?

– обеспечивает понимание проектов/продуктов/процессов

– оценивает стабильность требований

– совершенствование процесса

• Что измерять (предложения модели зрелости характеристик)?

– количество полученных запросов на изменение, открытых и закрытых в

настоящее время

– общее число сделанных изменений (добавленных, удаленных,

модифицированных требований)

– количество запросов на изменение, исходящих из каждого источника

– количество изменений, предложенных и внесенных в каждое требование

после создания базовой версии

– общие усилия на обработку и реализацию запросов на изменение

• Что измерять и в какой степени зависит от ситуации, исходя из

потребностей, целей, и намерений использования данных



Примеры измерения

Количество недель после сдачи базовой версии спецификаций требований

Nu

mb

er o

f P

rop

osed

Ch

ange

s0

1

2

3

4

5

6

7

8

Marketing Customer SoftwareEngineering

Management Testing Maintenance

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Кол

ич

еств

о п

ред

лаг

аем

ых

изм

енен

ий

Источники изменений



Анализ влияния

• Обоснование?– обеспечивает правильное понимание последствий

предложенного изменения

– помогает в принятии обоснованных решений по одобрению предложенных изменений

– исследует предложенное изменение с целью определения компонентов, которые будут добавлены, удалены или модифицированы в результате запрошенного изменения

– оценивает усилия, связанные с реализацией изменения

• Кто из вас пользуется анализом влияния, и какими процедурами вы пользуетесь?



Анализ влияния Процедура

• Анализ влияния предназначен для решения трех

основных вопросов

– понять последствия внесения изменения

– определения всех файлов, моделей и документов,

которые могут нуждаться в изменении, если изменение

будет реализовано

– определения задач, необходимых для реализации

изменения, и оценки усилий, необходимых для

завершения этих задач



Анализ влиянияПроцедура

Изучите подробные

контрольные списки

Оцените необходимые

усилия

Определите последовательность

задач для выполнения

Определите, находится ли изменение на критическом

пути

Оцените влияние на

график работ проекта и стоимость

Оцените приоритет изменения, определяя

достоинства и недостатки,

затраты и риск

Доложите о результатах

анализа влияния совету по

управлению изменениями



Учитесь говорить «НЕТ»

Посмотрим видеоклип



Когда настало время принять решениеКакие имеются варианты?

• Отложить низкоприоритетные требования

• Привлечь дополнительных сотрудников

• Использовать сверхурочную работу,

предпочтительно с оплатой, на короткий период

времени

• Сдвинуть график работ для реализации новой

функциональности

• Пожертвовать качеством, чтобы закончить продукт

вовремя.

• Научиться говорить “НЕТ”



Искусство и наука говорить “Нет”

• Невозможно всегда делать все, что пожелает

Заказчик

• Осознавайте связь между тем, что делаете, и

тем, какие ожидания формируют эти

действия

• Не идите по пути наименьшего

сопротивления



Как говорить “Нет”, чтобы это звучало как “Да”• “Я бы хотел ответить на ваш вопрос, но я сейчас занят.

Давайте запланируем обсуждение на завтра в удобное для нас обоих время”

• “Я помогу вам в этот раз, чтобы вы в будущем знали, как самостоятельно решить подобную проблему. Я хочу, чтобы вы понимали, что если это случится вновь, то у нас может не оказаться человека, который сможет незамедлительно помочь вам.”

• “Я бы помог Вам, если бы мог. К сожалению, моя загрузка на ближайшие 3 месяца превышает мои возможности.”

• “Мы должны отдавать приоритет тем клиентам, которые используют стандартные продукты (находятся на каком-нибудь привилегированном обслуживании). Поскольку Вы не являетесь таковым, мы обработаем вашу заявку, когда сможем, но боюсь это случится не ранее чем через пару дней/недель/месяцев.”



Преимущества подхода• Дает выигрыш во времени• Подчеркивает то, что вы ориентированы на клиента, но должны

делать выбор, кому помогать• Сигнализирует о вашем соблюдении стандартов и дает клиенту

понять, в каких случаях не следует ожидать помощи• Напоминает, что у клиентов также есть обязанности, и

разъясняет их.• Стимулирует клиента к поиску альтернативных способов

решения своих проблем• Поощряет самостоятельность клиентов• И, самое главное, помогает формировать ожидания, которые

наиболее близки к тому, что вы реально можете сделать



Применение подхода• Анализ процесса обработки заявок.

• Опишите ситуации, в которых следует говорить “Нет”, и трансформируйте их в стандарты.

• Зафиксируйте, что Вы никогда не будете делать.

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

• Четко разъясните, кто ответственный за обработку того или иного обращения клиента; не допускайте ситуации, когда Вы или Ваши коллеги выставляете нереалистичные ожидания клиенту, не имея на то права или возможности.

• Проанализируйте процессы/активности, оказание которых не дает существенного эффекта, и избавьтесь от них.

• Разработайте шаблоны конкретных фраз, как говорить “Нет”.



Заключение

• Изменение - это часть нашей жизни, и с ним надо

считаться

• Изменение - не всегда плохо, если правильно с ним

обходиться

• Анализ влияния способствует пониманию

последствий изменений, и как они воздействуют на

проект

• Существует множество вариантов работы с

изменениями, о которых должен знать руководитель

проекта



Литература

• “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



Вопросы?

l4 requirements

Documents