Управління ІТ-проектами / Література / Элизабет Халл. Разработка и управление требованиями

языках для региональных рыков сбыта. При этом каждая модификация может иметь свои собственные версии. Т.е. каждая следующая версия (в рамках одной модификации) будет чем-то положительно отличаться от предыдущей (исправлены ошибки и/или добавлены новые возможности).

На рис. 8.5 схематично показаны несколько параллельных модификаций одного и того же продукта, каждая их которых имеет несколько версий, находящихся на разных стадиях своего жизненного цикла. Буквы S, D, U обозначают различные фазы разработки продукта

– разработку спецификаций (specification), производство (development) и коммерческую эксплуатацию (use). С точки зрения метода «ворота стадий», каждой из этих фаз соответствует одна или несколько стадий жизненного цикла продукта.

Рис. 8.5 Версии и модификации.

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

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

В предыдущих разделах мы использовали термин «релиз» и, чтобы не запутывать читателей, необходимо пояснить разницу между версией продукта и его релизом. Отличие состоит в том, что релиз это версия, которая была доставлена (доступна) пользователям. Понятно, что в силу целого ряда причин, далеко не каждая версия продукта доходит до пользователей.

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

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

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

8.5.2 Контроль за ходом выполнения работ

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

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

∙заполнены ли значения атрибутов;

∙определены ли статусы проверки;

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

Из рис. 8.6 видно, что для каждой модификации вносимые изменения должны иметь свои собственные значения состояний «Запланировано», «Отложено», «Включено». При этом значение «Выполнено» состояние первичного изменения может принять только после отработки его по всем модификациим продукта.

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

8.6 Заключение

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

8.6.1 Планирование

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

Конечными результатами могут быть:

∙различные объекты информации (например, список заинтересованных сторон, пользовательские требования, системные требования, элементы спецификации или решения);

∙атрибуты, относящиейся к соответствующим информационным объектам;

∙связи между объектами информации, необходимые для организации трассировки, стратегией проверки, контроля изменений и т.п.;

∙критерии для рецензирования и анализа качества информационных объектов и их атрибутов;

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

Перед выполнением любой работы она обязательно должна быть согласована и утверждена внутри компании.

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

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

Нормой - особенно в отношении разработки абсолютно новых систем - должна стать последовательная (итерационная) разработка. Это, естественно, ведет к использованию

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

8.6.2 Контроль за ходом выполнения работ

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

8.6.3 Изменения

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

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

Далее необходимо ввести имя модуля в поле Name (обязательно!) и описание в поле Description (рекомендуется). Поскольку для каждого нового объекта внутри модуля система автоматически будет создавать уникальный идентификационный номер, то в этом же окне можно задать число, с которого будет начинаться нумерация объектов модуля (Start at:).

Помимо номера идентификатор объекта может содержать префикс (Prefix), который также можно задать при создании модуля. Префикс используется для более наглядного отображения содержимого модуля; например, для модуля, содержащего пользовательские требования, можно было бы задать префикс ПТ. Если для каждого формального модуля, входящего в конкретный проект, задать свой уникальный префикс, то простым способом мы получим уникальную идентификацию всех объектов всех модулей внутри данного проекта. В этом случае можно (и это проще) ссылаться на идентификатор объекта без указания названия модуля и всем будет понятно, какой именно модуль имеется в виду.

Если же открыть существующий формальный модуль, то, по умолчанию, слева будет окно структуры данных модуля (Module Explorer), а справа окно с данными, содержащимися в модуле (см. рис. 9.4).

Рис. 9.4 Вид формального модуля (по умолчанию).

Структура модуля полностью отображает структуру информации, содержащейся в модуле, и при необходимости позволяет легко перемещаться в нужное место. При этом, в окне структуры модуля возможно производить все те же манипуляции, что и в Проводнике (Windows Explorer), т.е. свертывать (-) и разворачивать (+) элементы структуры.