СМ-Консалт
 

Практическая реализация автоматизированной системы проектирования и формирования нефтегазовой отчетности с использованием 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. Логические связи типов полей
Рисунок 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 для формирования постановки

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


Заключение

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

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

 

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

 

01.03.2009

Комментарии

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

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

Новости СМ-Консалт

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Бесплатный вебинар 14 декабря в 14 00 по Мск - «Секреты управления ИТ-командой: 10 важных практик, которые сделают команду эффективной»

Новые статьи в библиотеке

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Отчет, презентация и видео доклада для Октябрьской встречи Петербургского клуба менеджеров проектов в IT - SPM Meetup #36

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2016.
Карта сайта