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

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

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

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

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

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

Хранение и обработка

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

Данные унаследованных систем. В каждой из обследованных 11 систем мы определили все элементы данных и соответствующие метаданные.

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

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

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

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

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

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

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

На этом шаге мы немного рисковали — в основном из-за того, что невозможно гарантировать стопроцентную корректность выбора элемента и преобразования, но, по крайней мере, данная методика приводит к созданию «единственно верного» видения данных. В новой системе каждый элемент данных должен иметь лишь одно определение и поступать из вполне конкретного источника или источников. В табл. 1 пример такого элемента данных, который не переносится из унаследованных систем, — это элемент Name в системе отдела продаж. Вместо него переносятся четыре элемента, которые сейчас содержатся в системе отдела маркетинга: first name, middle initial, last name и suffix. Система отдела продаж в этой организации была очень старой и не обеспечивала той гибкости, которую поддерживала система отдела маркетинга.

Естественно, все эти бизнес-правила присутствуют в метаданных в составе конечной системы — благодаря этому пользователи могут выяснить текущее определение и правила обработки независимо от того, к какой унаследованной системе они привыкли ранее. (См. статью The Confidence Game от 8 марта 2002 г., доступную на Web-странице www.intelligententerprise.com/020308/505feat2_1.shtml.)

Источники данных

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

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

Выходные данные

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

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

Счастливый заказчик

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

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

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

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

Карен Казимер-Шокли (Karen Kazimer-Shockley) — старший консультант в компании Alltech. Как старший системный инженер она имеет опыт работы на всех участках цикла разработки ПО — от анализа требований до тестирования интеграции. С автором можно связаться по адресу e-mail: k.kazimer-shockley@att.net.

Дополнительная информация

В статье Марка Риггла (Mark Riggle) Breaking the Cycle of Failure от 10 августа 2001 года рассказывается о решении задачи анализа требований при создании информационных хранилищ. Статья доступна на Web-странице www.intelligententerprise.com/010810/412feat3_1.shtml.