На рис. 19-1 показан шаблон описания процесса контроля изменений для обработки модификаций требований и других изменений проекта. Вы можете загрузить его образец с https://www.processimpact.com/goodies.shtml. Далее речь пойдет в основном о том, как процесс будет обрабатывать изменения требований. Я считаю полезным включить следующие четыре компонента во все процедуры и описания процесса:
· входной критерий — условия, которые должны быть удовлетворены до выполнения процесса или процедуры;
· различные задачи, задействованные в процессе или процедуре;
· участник проекта, отвечающий за выполнение каждой задачи, и другие лица, принимающие участие в выполнении задачи;
· последовательные действия для подтверждения того, что задачи были выполнены правильно;
· выходной критерий — условия, указывающие, когда процесс или процедура считаются успешно завершенными.
| 1. Введение 1.1. Назначение 1.2. Границы 1.3. Определения |
| 2. Роли и ответственности |
| 3. Состояние запроса на изменение |
| 4. Входной критерий |
| 5. Задачи 5.1. Оценка запроса 5.2. Принятие решения 5.3. Внесение изменения 5.4. Уведомление всех задействованных лиц |
| 6. Проверка 6.1. Проверка изменения 6.2, Установка продукта |
| 7. Выходной критерий |
| 8. Отчет о состоянии контроля изменений |
| Приложение. Элементы данных, сохраненные для каждого запроса |
Рис. 19-1. Пример шаблона описания процесса контроля изменений
Введение
Во введении описывается назначение процесса и определяются организационные границы, вкоторых он применяется. Если этот процесс затрагивает только изменения в определенных продуктах, их следует определить здесь. Также укажите, существуют ли какие-то специальные виды изменений, которые не подлежат контролю, например изменения в промежуточных или служебных продуктах, созданных в ходе проекта. В разделе 1.3 определите все термины, необходимые для понимания остальной информации.
Роли и ответственности
Перечислите членов команды — по ролям, не по именам, которые участвуют в процессе контроля изменений, и опишите их обязанности. В табл. 19-1 приведены некоторые типичные роли; адаптируйте их в соответствии с конкретной ситуацией. Каждый человек может выполнять несколько ролей. Например, председатель совета по управлению изменениями также может получать подаваемые запросы на изменения. В небольших проектах несколько, а возможно, и все роли выполняются одним человеком.
Таблица 19-1. Возможные роли участников проекта при управлении изменениями
| Роль | Описание и ответственность |
| Председатель совета, по управлению изменениями | Возглавляет совет по управлению изменениями; как правило, обладает правом принятия окончательного решения, если совет не приходит к согласию; выбирает тех, кто оценивает и вносит изменения для каждого запроса на изменение. |
| Совет по управлению изменениями | Группа, принимающее решение утвердить или отклонить каждое предложенное изменение для определенного проекта. |
| Тот, кто оценивает изменение | Человек, которого председатель совета просит проанализировать влияние предложенного изменения; это может быть сотрудник технического отдела, клиент, маркетолог или сотрудник, занимающийся всем этим понемногу. |
| Тот, кто вносит изменение | Отвечает за внесение изменений в продукт, когда запрос: на изменение утвержден. |
| Тот, кто инициирует запрос | Некто, подающий новый запрос на изменение. |
| Получатель запроса | Лицо, которому передаются новые запросы на изменение. |
| Тот, кто проверяет изменение | Человек, определяющий, корректно ли выполнено изменение. |
Состояние запроса на изменение
Запрос на изменение проходит через определенные стадии на протяжении жизненного цикла, причем на каждой стадии он имеет различные статусы. Вы можете представить эти изменения состояния, используя диаграмму перехода состояний, как показано на рис. 19-2. Обновляйте состояние запроса, только когда удовлетворяются определенные критерии.
Рис. 19-2.Диаграмма перехода состояний для запроса на изменение
Входной критерий
Основным входным критерием для процесса контроля изменений является действительный запрос на изменение, полученный по утвержденным каналам.
Все потенциальные инициаторы запросов должны знать, как подавать запросы на изменение, независимо от того, отправляют они его, заполняя бумажную форму или Web-форму, отправляя сообщение по электронной почте или используя средство контроля изменений. Назначьте каждому запросу на изменение уникальный идентификатор и направьте их всех к единой точке контакта — получателю запроса.
Задачи
Следующий шаг — это оценка запроса на предмет технической выполнимости, затрат и соответствия бизнес-требованиям проекта и ограничениям ресурсов. Председатель совета по управлению изменениями может назначить сотрудника для оценки влияния изменения, анализа риска, анализа опасности и др. Анализ позволяет убедиться, что вероятные последствия изменения ясны. Тот, кому поручена оценка, и члены совета по управлению изменениями должны также рассмотреть коммерческие и технические последствия отклонения изменения.
Затем уполномоченные члены совета по управлению изменениями решают, утвердить или отклонить запрошенное изменение. Совет по управлению изменениями присваивает каждому одобренному изменению уровень приоритета, или назначает дату реализации, или назначает это изменение определенной сборке или номеру версии. Далее совет по управлению изменениями оповещает о решении, обновляя состояние запроса или уведомляя всех членов команды, которые занимаются модификацией. После этого необходимо обновить документацию требований, описание проекта и моделей, компоненты пользовательского интерфейса, код, документацию тестирования, экраны справки и руководства для пользователей. Тот,кто вносит изменения, делает это установленным путем.
Проверка
Изменения требования, как правило, проверяют с помощью экспертной оценки, чтобы убедиться, что измененные требования, варианты использования и модели соответствующим образом отражают все аспекты изменения. Информация о трассируемости поможет вам найти все части системы, которые это изменение затрагивает и которые, как следствие, необходимо проверить. Поручите нескольким членам команды проверить изменения с помощью тестирования или экспертизы. После этих процедур тот, кто занимается проверкой, устанавливает обновленные продукты, сделав их доступными остальным членам команды, и переопределяет базовую версию, в которой учтены изменения.
Выходной критерий
Все перечисленные далее выходные критерии должны быть удовлетворены, чтобы должным образом завершить процесс управлений изменениями:
· состояние запроса: Rejected (Отклонено), Closed (Закрыто) или Canceled (Отменено); все изменения записаны в соответствующих разделах;
· инициатор запроса, председатель совета по управлению изменениями, менеджер проекта и другие значимые участники проекта оповещены о деталях изменения и текущем состоянии запроса на изменение;
· матрица связей требований обновлена. (В главе 20 о трассируемости требований рассказано более подробно.)