Реализация системы проектирования и формирования нефтегазовой отчетности с использованием IBM Rational RequisitePro и SoDA

Из ряда инструментальных средств поддержки процесса управления требованиями мы в большинстве случаев выбираем IBM Rational RequisitePro. Наш выбор обусловлен рядом причин – это в первую очередь и полная функциональная поддержка всех элементов дисциплины, и возможность интеграции с инструментами поддержки близких дисциплин – IBM Rational ClearQuest в управлении изменениями, TestManager в тестировании, интеграция RequisitePro с инструментом версионного хранения и управления конфигурациями IBM Rational ClearCase для версионного хранения репозитория требований. Кроме того, RequisitePro обладает API, что открывает широкие возможности по расширению функционала этого инструмента. В одном из проектов внедрения методологии RUP мы столкнулись с проблемой при описании требований на разработку отчётности. Из-за низкого качества постановок процесс разработки отчётности растягивался во времени, сложилась парадоксальная ситуация, когда отсутствовало понимание между аналитиками и разработчиками, и при этом никто не брал на себя ответственность в разрешении сложившейся ситуации. Кроме того, на этом этапе система, включающая и среду для разработки отчётов, находилась в стадии активной доработки – а именно разработки новой подсистемы, при этом довольно часто изменялась структура базы данных (БД), что нередко приводило к утере работоспособности уже разработанных и внедрённых отчётов. Естественно, при обследовании процессов подразделения эта проблема была озвучена, и необходимо было найти решение. Для разрешения сложившейся ситуации и устранения причин, затягивающих сроки разработки отчётов, было спроектировано комплексное решение, состоящее из специально разработанной схемы RequisitePro. При этом акцент был сделан на описание требований к отчёту, а именно на детализацию до описания каждого поля отчёта и приложения, реализующего среду для построения простых SQL-запросов из требований к отчёту, а также автоматизирующего поиск и маркировку связей полей отчёта с полями таблиц базы данных.

Рустам Зайдуллин, ведущий инженер, ТатАСУнефть" ОАО "Татнефть"

Зайдуллин Рустам работает в области информационных технологий с 2005 года. Имеет опыт адаптации и внедрения RUP и инструментальных средств IBM Rational. Сертифицированный специалист по следующим продуктам: IBM Rational ClearCase, Microsoft Project 2003. Является ведущим инженером группы контроля качества процессов разработки программного обеспечения управления "ТатАСУнефть" ОАО "Татнефть".



Александр Новичков, руководитель отдела внедрения и консалтинга, СМ-Консалт

Новичков Александр работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним можно по адресу rational.tools.info@gmail.com



27.02.2009

Исходные данные

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

Описание решения

На базе IBM Rational Requisite Pro было разработано решение для проектирования отчётов, охватывающее процесс описания полей в виде постановки, и далее – формирования SQL-запросов для получения данных в отчёт. В самом RequisitePro разработана схема, включающая типы требований и ряд атрибутов для них, а также сформирована структура каталогов, группирующая описания полей БД, отчёты и их поля.

Итак, для реализации решения в системе управления требованиями IBM Rational Requisite Pro были определены следующие типы требований.

  • Field (FLD) – поле отчёта либо таблицы, или входной параметр отчёта. Для идентификации используются атрибуты (см. ниже).
  • Глоссарий (TERM) – элемент глоссария. Добавление этого типа требований было обусловлено отсутствием формализованного глоссария системы на момент разработки решения.

Для детальной идентификации каждого из типов требований в схеме RequisitePro был описан ряд атрибутов.

Атрибуты требований типа Field

  • Тип поля. С помощью этого атрибута указывается принадлежность поля и механизм формирования значения (рисунок 1). Атрибут принимает одно из следующих значений:
    • поле отчета – определяет, является ли поле выводимым в отчет;
    • поле таблицы – говорит о том, что поле принадлежит таблице БД;
    • поле представления – указывает на принадлежность поля к представлению БД;
    • агрегация – характеризует поле как агрегированное значение других полей;
    • параметр отчёта – поле описывает параметр, задаваемый при формировании отчёта.
  • Размер поля. Атрибут указывает на количество символов поля.
  • SQL-код. Атрибут хранит SQL-код к описанию поля, разработанный в приложении расширения – Конструктор отчёта.
Рисунок 1. Логические связи типов полей
Рисунок 1. Логические связи типов полей

Атрибуты требований типа TERM:

  • Архитектурная функция. Атрибут уточняет, является ли описываемый термин архитектурной функцией системы.

Для хранения требований в репозитории была организована структура каталогов, в которой верхний уровень разделял требования на описание базы данных, отчётов и глоссария. Каталог структуры базы данных разделялся на каталоги для таблиц, в которых формировались требования – описания полей. С целью точной идентификации полей разных таблиц было оговорено правило наименования полей – имя должно содержать название таблицы и имя самого поля, разделённые точкой: Таблица_1.Поле_1.

Соответственно, каталог с описанием требований к отчётам делился на подкаталоги под каждый описываемый отчёт. Правило наименования аналогично принятому для полей таблиц – имя поля содержит название отчёта и самого поля: Отчет_2.Поле_7. Для контроля связей между полями отчёта и полями отчёта и таблиц настроены представления (View). Названия представлений содержат перечисление контролируемых сущностей – например, поля отчёта к БД, агрегациям и входным параметрам отчёта (рисунок 2).

Рисунок 2. Контроль связей полей отчёта с базой данных
Рисунок 2. Контроль связей полей отчёта с базой данных

Процесс разработки отчёта

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

Вторая проблема – это тот факт, что сама система находилась в стадии активной доработки, причём доработка затрагивала и структуру продуктивной базы данных, изменения в которой приводили к неработоспособности разработанных ранее отчётов. Ведение описаний требований к отчёту и связанных с ними полей базы данных в RequisitePro позволили контролировать нарушения связей и прогнозировать объём работы по изменению отчётности, возникающий вследствие изменения структуры БД. Результат – значительное снижение количества дефектов в отчётности и повышение качества работ организации.

После разработки и согласования шаблона постановки был утверждён стандарт на документ "Постановка на отчёт", который удовлетворял требованиям разработчиков. Но главное достоинство этого шаблона заключалось в том, что в его основе лежал шаблон отчёта IBM Rational SoDA, и формирование самой постановки на отчёт теперь выполнялось автоматически, как формирование отчёта по указанным требованиям IBM Rational RequisitePro.

Работа аналитиков была перенесена в инструмент RequisitePro. Отныне вместо описания постановки в "плоском" виде, т.е. как обычного документа, постановщики описывали отчёт в виде требований к полям отчёта, после чего формировали отчёт по описанным требованиям с получением на выходе формализованного документа (рисунок 3).

Рисунок 3. Процесс формирования постановки
Рисунок 3. Процесс формирования постановки

Следующим важным шагом в оптимизации процесса было принятие общего стандарта на описание правил формирования полей отчёта. Также были оговорены правила описания формул расчёта значений полей – иначе говоря, из описаний были исключены любые вариации описания ряда выражений и оговорен формат описания расчёта значений (рисунок 4).

Рисунок 4. Синтаксис описания поля отчёта
Рисунок 4. Синтаксис описания поля отчёта

На рисунке 5 представлено окно RequisitePro с отображением дерева отчётов и требований к их полям и развёрнутое окно описания свойств требования к полю отчёта.

Рисунок 5. Структура каталогов отчётов и описание поля
Рисунок 5. Структура каталогов отчётов и описание поля

Развёрнутое окно описания поля БД показано на рисунке 6.

Рисунок 6. Описание поля базы данных
Рисунок 6. Описание поля базы данных

Модуль конструкции SQL-кода

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

Функциональность модуля

На рисунке 7 перечислены функции, выполняемые модулем.

Рисунок 7. Функциональность модуля
Рисунок 7. Функциональность модуля

После описания требований к полям в Requisite Pro дальнейшие действия по разработке отчёта выполняются в оригинальном инструменте построения отчётов. Оригинальная разработка "Модуль конструкции SQL-кода" как надстройка к RequisitePro решает следующие основные задачи:

  • автоматизация рутинных операций проставления трассировок в репозитории RequisitePro;
  • разработка простых SQL-запросов в графическом режиме с сохранением их в репозитории RequisitePro.

Входящими данными для конструктора являются требования типа FLD репозитория требований RequisitePro. При подключении к репозиторию в правой части основной формы в древовидной структуре выводятся все каталоги отчётов и требования к их полям, описанные в репозитории.

Работа с модулем конструкции SQL-кода

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

Упомянутая выше функция автоматического контроля трассировок полей отчёта к полям БД вызывается из контекстного меню (рисунок 8).

Рисунок 8. Основная форма модуля
Рисунок 8. Основная форма модуля

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

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

При выборе в браузере отчётов поля в верхнее окно основной формы выводится описание требования к полю, во второе окно – SQL-запрос из атрибутов требования к полю (рисунок 9).

Рисунок 9. Просмотр описания поля в модуле
Рисунок 9. Просмотр описания поля в модуле

Формирование SQL-запроса выполняется в режиме конструктора – переход в него происходит по нажатию соответствующей кнопки на форме.

Режим конструктора представляет собой форму с двумя окнами (рисунок 10). В верхнее окно выводится описание требования к полю. В нижнее окно методом drag&drop перетаскиваются и группируются в SQL-код выделенные выражения. Первое перенесённое выражение составляет искомое поле таблицы, последующие – условия выборки, критерии фильтрации записей. Служебные слова SQL-запроса добавляются по мере внесения в окно новых выражений. Полученный SQL-код можно тут же отредактировать вручную. После начала редактирования функция перетаскивания выражений из описания поля становится недоступной. Для того чтобы вновь активировать её, необходимо сбросить полученный SQL-запрос нажатием на кнопку Reset.

Рисунок 10. Конструктор SQL-запросов
Рисунок 10. Конструктор SQL-запросов

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

Рисунок 11. Диалог ввода параметров отчёта
Рисунок 11. Диалог ввода параметров отчёта

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

Шаблон отчёта SoDA для формирования постановки состоит из названия отчёта, краткого описания и шапки отчёта – информация, полученная от заказчика отчёта. Далее следует правило выборки входных данных отчёта и описания его полей. Для формирования постановки на новый отчёт необходимо всего лишь изменить фильтр в шаблоне SoDA, определяющий корневой каталог отчёта (рисунок 12).

Рисунок 12. Шаблон SoDA для формирования постановки
Рисунок 12. Шаблон SoDA для формирования постановки

По проставленным модулем трассировкам в отчёт выводятся все связанные с полем отчёта поля базы данных.


Заключение

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

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

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • developerWorks Premium

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

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=373185
ArticleTitle= Реализация системы проектирования и формирования нефтегазовой отчетности с использованием IBM Rational RequisitePro и SoDA
publish-date=02272009