Принципы и приемы оперирования требованиями (продолжение)

Прием 11. Сохранение истории изменения требований

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

История изменения требований используется следующим образом:

• для отката проекта к ранее пройденному состоянию в связи с ошибками перспективного планирования, из-за желания оценить текущую ситуацию с позиций прошлого, для переоценки приоритетов и по другим причинам;
• для отслеживания аналогичных ситуаций, чтобы текущее планирование опиралось на полученный ранее опыт;
• для поддержки версионности, в частности когда приходится выпускать для разных пользователей различные версии, базирующиеся на некотором общем релизе, пройденном ранее;
• для будущих учебных целей: изучение опыта развития данного проекта позволит повысить качество и сократить время анализа аналогичных ситуаций в последующих проектах.

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

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

Рис. 14.2. Условный пример протокола обработки исходного требования

На рис. 14.2 приведен условный пример фрагмента протокола оперирования с требованием ТР0, поступившим от Иванова (авторство указано в правой графе протокола) 12.12.2003. Все записи пронумерованы и справа от номера указана дата – 13.12.2003 к работе с этим требованием приступил Петров. Прежде всего, он трансформирует исходное представление в три типизированных представления ТР1, ТР2 и ТР3, из которых второе требование отклоняется (запись 0652 от 14.12.2003). Для унификации ТР1 и ТР3 трансформируются в ТР1У и ТР3У (записи 0654 и 0655 от 14.12.2003). 15.12.2003 Петров строит расширение модели М01 посредством ТР1У и ТР3У (запись 0681 ). Анализ показал неприемлемость такого расширения из-за ТР3У. Как следствие, решено отклонить ТР3У (запись 0682 ). Это влечет за собой автоматическое отклонение ТР3 (в графе авторства записи 0683 есть соответствующая пометка и указана причина отклонения — ссылка на предыдущую запись). По этой же причине автоматически восстанавливается модель М01. Завершает фрагмент запись, свидетельствующая о том, что Петров строит расширение модели с учетом лишь ТР1У.

Данный пример показывает важность решения еще одной задачи, связанной с организацией хранения истории:

• разработка системы типовых запросов, благодаря которым обеспечивается выполнение семантически емких часто повторяющихся заданий.

С их помощью реализуются указанные выше потребности отслеживания истории работы с требованиями. В качестве иллюстрации ниже приводятся три запроса, связанные с требованиями:

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

Во всех примерах отличительным является временной параметр запроса, используемый для получения исторических или текущих сведений.

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

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

Организации хранения исторических сведений, представленная выше, — это спецификация "глобальной" потребности. Для реального проекта она, во-первых, может быть значительно урезана до некоторого прагматического уровня, а во-вторых, оптимизирована в соответствии с этим уровнем.

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

Результатом сохранения истории изменений требований является вся совокупность исторических сведений, которая хранится для данного проекта и используется при организации дальнейших работ.