Сегодня любая компания, предоставляющая сервис на рынке IT-услуг, рано или поздно сталкивается с необходимостью сопровождения множества информационных систем, в разной степени интегрированных между собой. Естественно, среднестатистическая организация не имеет возможности разрабатывать собственное программное обеспечение для покрытия всех потребностей бизнеса, его закупают, причём, скорее всего, у разных разработчиков.
Далее, от специфики задач бизнеса можно выстроить прямую зависимость к зрелости программного комплекса, разработанного для её решения. Если рассматривать такие типичные задачи, как ведение бухгалтерского учёта, управление кадрами, создание внутреннего сервиса электронной почты в организациях, то можно с уверенностью сказать, что на сегодня на рынке имеется ряд качественных и законченных решений от мировых лидеров производства программного обеспечения. Эти решения совершенствуются, в том числе и в силу наличия прямой конкуренции.
Сложнее складывается ситуация с решениями для менее распространённых задач, имеющих куда большую специфику и большее количество нюансов в каждой организации сектора. На деле это оборачивается тем, что для создания IT-инфраструктуры закупается ряд решений от разных производителей. Зачастую решения не являются собственно программными продуктами (программный продукт - это совокупность отдельных программных средств, их документации, гарантий качества, рекламных материалов, мер по обучению пользователей, распространению и сопровождению готового программного обеспечения), а представляют собой программные комплексы, разработанные для собственных нужд. Вполне возможно, что в этом случае основной целью разработки было оперативное создание функционирующего способа решения поставленной задачи в определённой мере в ущерб архитектуре, производительности и документированию.
Сама по себе эксплуатация разнородного программного обеспечения - проблема небольшая, хотя у различных производителей представления об удобном пользовательском интерфейсе разнятся, и в итоге конечный пользователь работает с концептуально разными интерфейсами. Настоящие трудности возникают при интеграции решений в единую информационную среду с созданием интерфейсов между ними и последующим сопровождением этой системы. Описанное в статье решение помогает сделать процесс сопровождения более предсказуемым и прозрачным, а также, следовательно, и более управляемым.
Развивающаяся система, составные части которой тоже, в свою очередь, развиваются или изменяются независимо друг от друга, очень легко может стать неуправляемой и непредсказуемой. Изменения в одном из её компонентов, выполняемые в рамках развития или сопровождения системы, часто могут "аукнуться" там, где, казалось бы, никто этого не ожидал. Так как мы говорим об организации (или подразделении), не начинающей некий проект с нуля, а действующей в сложившихся к определённому моменту времени обстоятельствах, то у неё, скорее всего, уже нет возможности создать целостную концепцию развития всей системы, достаточно детальную и реалистичную для того, чтобы наложить на неё процесс развития. Бизнес требует решения своих задач здесь и сейчас и, если не удовлетворять его требования, найдутся другие, кто сделает это.
Выход из этой ситуации - описать с необходимым уровнем детализации уже имеющуюся систему с её компонентами, определить связи между ними (рисунок 1) и далее использовать эту модель для анализа предполагаемых изменений. При определении детализации описания возникает дилемма: создать достаточно детальное описание всех компонентов, затратив на этом этапе больше ресурсов, или ограничиться определением влияния модулей компонентов системы на другие компоненты (рисунок 2). В первом случае процесс анализа влияния предполагаемых изменений становится более оперативно выполняемой работой. Во втором - выигрыш в ресурсах на начальной стадии. В дальнейшем же, при обнаружении влияния изменений на компонент, к анализу привлекается эксперт этого компонента.
Рисунок 1. Определение зависимостей модулей компонентов системы
С другой стороны, будь даже модель заранее описана с глубоким уровнем детализации, привлекать экспертов компонентов, на которые обнаружено влияние, всё равно придётся. Есть рациональное зерно в том, чтобы изначально не ставить целью создание детального описания. Но опять же, при возникновении необходимости оперативного изменения системы нужных ресурсов может не оказаться, и с этой точки зрения то, что можно сделать заранее - лучше сделать заранее. Окончательный выбор скорее зависит от сложившегося в организации стиля работы, взаимоотношений между специалистами и других факторов. Главное, что это решение должно быть принято, доведено до всех лиц, которых оно затрагивает, и дальнейшая работа должна вестись согласно этому решению.
Рисунок 2. Определение связей модулей компонента с другими компонентами системы
Было бы довольно проблематично реализовать на практике описанную систему без использования специализированного инструментария. Описание компонентов можно было бы выполнить в виде стандартизованных документов, указать в них ссылки на связанные элементы, но дальнейшее использование этих документов и, в частности, отслеживание влияния изменений на зависимые элементы вручную представляется совершенно нерациональным действием. Более того, "плоские" документы не дают возможности фильтровать информацию, отсеять излишние в определённом случае данные, выделить по заданным критериям нужные. В итоге эффективность реализации на базе обычных документов достаточно низкая.
Рисунок 3. Форма Requisite Pro
Реализацию такого инструмента для анализа изменений мы выполняем на базе продукта IBM Rational RequisitePro . Приведённые выше иллюстрации - примеры форм IBM Rational RequisitePro для описываемой схемы. Данный продукт позволяет создать логически и иерархически структурированную среду в соответствии с поставленной задачей, определить связи между объектами среды, просматривать информацию под нужным ракурсом посредством настраиваемых представлений и, что самое главное, при изменении описания одного из объектов даст знать, на какие объекты это повлияет (рисунок 3). Для структуризации характеристик информационных систем можно использовать разбивку описания на заголовочную часть и подсистемы в виде отдельных сущностей (по аналогии с типами требований). Для выделения отдельных параметров можно также определить атрибуты (рисунок 4). В дальнейшем это даст возможность сортировать и фильтровать информацию по этим параметрам.
Рисунок 4. Выделенные атрибуты
Кроме того, IBM Rational RequisitePro позволяет создавать и получать необходимые отчёты, а с помощью дополнительного инструмента IBM Rational SoDA - и в привычном формате документов MS Word.