Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

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

Из ряда инструментальных средств поддержки процесса управления требованиями мы в большинстве случаев выбираем IBM Rational RequisitePro. Наш выбор обусловлен рядом причин – это в первую очередь и полная функциональная поддержка всех элементов дисциплины, и возможность интеграции с инструментами поддержки близких дисциплин – IBM Rational ClearQuest в управлении изменениями, TestManager в тестировании, интеграция RequisitePro с инструментом версионного хранения и управления конфигурациями IBM Rational ClearCase для версионного хранения репозитория требований. В статье говорится о практике не совсем стандартного применения Requisite Pro для решения задач чисто прикладного характера, находящейся в плоскости требований и архитектуры.
Зайдуллин Рустам - ведущий инженер, ТатАСУнефть" ОАО "Татнефть", Новичков Александр, руководитель отдела внедрения и консалтинга, СМ-Консалт
Cтатья опубликована на сайте IBM.

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Логические связи типов полей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

Ресурсы СМ-Консалт

• Организация совместной разработки программного обеспечения между заказчиком и подрядчиком с использованием IBM Rational ClearCase
  
• Использование Method Composer при описании сложных и нестандартных процессов. Практика применения
  
• Rational Unified Process. Методология и технология  
• Оценка возврата инвестиций от внедрения процесса управления конфигурациями 
• Зачем нам нужен план управления конфигурациями? Основные понятия и концепции документа 
• Роль процесса Управления Требованиями при разработке сложных программных систем. Практика применения методологии IBM RUP и инструмента IBM Rational RequisitePro 
• Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational
• Стратегия и тактика обучения сотрудников в проекте внедрения методологии и технологии работ 
• Как правильно внедрить управление версиями и изменениями в софтверной организации 
• Консалтинг в тестировании
  
•  Инструменты, изменяющие процесс 

01.03.2009

Комментарии

• nevyfaRJMsrxsbhlze
  Автор: You've hit the ball out the park! Incredblie!  ·  02.10.2011 06:13:25
  You've hit the ball out the park! Incredblie!
• beIYSwfCTZwGAbo
  Автор: Your story was really inofrmatvie, thanks!  ·  30.09.2011 22:20:02
  Your story was really inofrmatvie, thanks!
• GNtngiAkSLG
  Автор: Cool! That's a clever way of lokonig at it!  ·  20.09.2011 12:15:20
  Cool! That's a clever way of lokonig at it!

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"