Вы находитесь на страницах старой версии сайта.
Переходите на новую версию Interface.Ru

Технология структурирования требований к ПО с помощью AllFusion Process Modeler (ранее: BPwin) и AllFusion ERwin Data Modeler (ранее: ERwin)

© Н.А. Трушин, НП АТС
© С.В. Тупчиенко, НП АТС

Введение

Цель публикации

Цель данной публикации состоит в описании подхода к формированию и структурированию требований к программному обеспечению.

Рамки

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

Технология также включает в себя методику автоматической подготовки документа "Техническое задание на разработку ПО" (или "Спецификация требований к программному обеспечению").

Технология предназначена в первую очередь для использования её системными и бизнес аналитиками на этапе формирования требований.

Предположения и зависимости

Предлагаемая технология основана на использовании программных продуктов AllFusion Process Modeler (ранее BPwin), AllFusion ERwin Data Modeler (ранее: ERwin) и системы управления требованиями Doors (возможно, также, использование системы управления требованиями IBM Rational RequisitePro).

Существующие технологии

Традиционно структурирование требований к программному обеспечению производится в рамках отдельного документа, например в формате Word, в соответствии с одним из шаблонов ГОСТ/SRS. Современные системы управления требованиями также предоставляют возможность ведения требований в специализированных базах данных или гибридных структурах Текстовый процессор + БД.

Рассмотрим кратко характеристики предлагаемых вариантов.

Таким образом, на собственном опыте автора логичным выбором для разработки технического задания, или SRS, является ведение требований в рамках единого документа с возможностью управления требованиями как отдельными объектами.

В рассмотренных системах управления требованиями (RequisitePro & Doors) предоставляется также возможность связывания отдельных требований с объектами (классами, или прецедентами) аналитических моделей (UML), разрабатываемых на последующих этапах разработки.

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

  • это связь по ссылке, что не всегда удобно в использовании.

    Ещё один подход к формированию требований к ПО.

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

    Рассмотрим возможности ведения требований на примере одного из самых известных продуктов, поддерживающих моделирование в стандарте IDEF0, AllFusion Process Modeler (ранее BPwin).

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

    Таким образом, в рамках единой структурированной модели имеется возможность совместить и графическое и текстовое (в виде определений к графическим элементам) представление требований к ПО. Но остаётся проблема получения единого документа, содержащего все требования к ПО, структурированные в соответствии с одним из шаблонов ГОСТ/SRS, так как существующий генератор отчётов AllFusion Process Modeler (Bpwin) предоставляет достаточно скудные средства форматирования. Невозможна также трассировка требований и их версионирование (использование AllFusion Model Manager (ранее ModelMart) для получения истории изменения требований представляется сложным).

    Предлагаемая технология

    Описание технологии

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

    Построение процессной модели (IDEF0/DFD/IDEF3)
    На первом этапе, в соответствии с принятыми ограничениями, аналитик производит формирование процессной модели системы (методология IDEF0/DFD/IDEF3) с использованием программного продукта AllFusion Process Modeler. По мере уточнения требований производится декомпозиция функций системы до необходимого уровня. Все функции системы должны быть связны, а информационные потоки, увязывающие функции должны быть строго определены.

    Построение ER модели (IDEF1X)
    В рамках сбора требований к ПО производится определение требований к информации, которую будет обрабатывать система. Данные требования обычно включают в себя описание видов и атрибутики обрабатываемой информации.

    Технология предполагает разработку связной ER модели сущностей предметной области на этапе сбора требований. ER модель разрабатывается с использование программного продукта AllFusion Data Modeler (ERwin), при этом ERwin рассматривается как система формирования требований к информации.

    Связывание процессной и ER моделей
    Между процессной моделью и моделью сущностей устанавливается связь с использованием механизма связи, предоставляемого AllFusion Process Modeler (Bpwin). При установлении связи в AllFusion Process Modeler модель копируется словарь сущностей и атрибутов, включая определения и типы данных.

    Для каждого информационного потока модели AllFusion Process Modeler при помощи средств AllFusion Process Modeler выбирается набор сущностей и атрибутов, включённых в соответствующий поток.

    Экспорт данных в систему управления требованиями
    После разработки связной функциональной модели при помощи специального модуля сопряжения производится экспорт информации, подготовленной в AllFusion Process Modeler модели, в систему управления требованиями. В настоящий момент разработан модуль сопряжения с системой Doors, однако, существующий API для RequisitePro позволяет осуществлять экспорт требований в базу данных этой системы.

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

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

    Таким образом, например, уникальным функциональным требованием в системе будет являться деятельность с заданными в AllFusion Process Modeler наименованием и определением. Иерархия экспортируемых функциональных требований полностью повторяет иерархию деятельностей AllFusion Process Modeler.

    Ведение нефункциональных требований
    Нефункциональные требования ведутся в рамках системы Doors в отдельных разделах документа в соответствии со структурой шаблона документа.

    Трассировка требований
    Между любыми требованиями, как экспортированными, так и введёнными в DOORS вручную может быть установлена связь, которая остаётся неизменной при повторном экспорте.

    Изменение требований

    Для соотнесения требований в Doors и объектов AllFusion Process Modeler используется уникальный идентификатор объектов, присваиваемый AllFusion Process Modeler. При экспорте производится проверка неизменности передаваемой информации, в случае изменения, требование Doors модифицируется новым значением.

    При изменении атрибутов требований Doors автоматически производит сохранение версий требований.

    Формирование печатной версии документа
    Для формирования печатной версии документа используется стандартное средство экспорта документа Doors в формат Microsoft Word. При этом производится форматирование информации на основании стилей документа Microsoft Word в соответствии с её типом (примеры типов: наименование требования, определение требования, наименование сущности, атрибут…).

    Структура итогового документа ТЗ/SRS

    Далее, кратко, описана структура разделов результирующего документа, которые автоматически заполняются при экспорте требований из AllFusion Process Modeler модели в Doors. Кроме них в документе существуют разделы, которые изначально ведутся в Doors, однако они не рассматриваются.

    Краткая характеристика системы
    В разделе приводится:

    Описание окружения
    В разделе перечисляются Externals & Referents, которые являются источниками, или приёмниками информационных потоков AllFusion Process Modeler модели и помечены, как внешние системы (при помощи UDP переменной). Вместе с наименованиями внешних систем, выводится их описание.

    Описание ролей
    В разделе перечисляются все роли, которые были указаны в каких-либо деятельностях AllFusion Process Modeler модели. Для каждой роли приводится список деятельностей, в которых она принимает участие.

    Требования к функциям
    В раздел полностью переносится иерархия деятельностей, представленная в AllFusion Process Modeler модели.

    Для каждой функции выводится:

    1. Наименование функции, вместе с номером деятельности AllFusion Process Modeler модели.
    2. Определение функции (Definition), в котором должны быть перечислены все требования к функции.
    3. Примечание функции (Note).
    4. Перечень регламентирующей информации (наименования управляющих стрелок).
    5. Перечень входящей информации (наименования входящих стрелок).
    6. Перечень ресурсов (наименования стрелок-механизмов).
    7. Перечень исходящей информации (наименования исходящих стрелок).
    8. Перечень ролей, участвующих в исполнении деятельности.
    9. Перечень вызовов, осуществляемых функцией (Call стрелки)
    10. Перечень переходов к исполнению определённых сценариев, при выполнении заданных условий (используется в IDEF3 диаграммах).

    Если входящие, или исходящие стрелки имеют своим источником/приёмником External или Referent, то вместе с наименованием стрелки приводится наименование источника/приёмника информации.

    Все типы стрелок сгруппированы под соответствующими заголовками.

    Существует возможность вывода в документ нескольких сценариев (декомпозиций) IDEF3 для одной деятельности.

    Требования к информации
    В раздел выводится информация по входящим, или исходящим дугам AllFusion Process Modeler модели, которые помечены (при помощи UDP переменной) для вывода в раздел требований к информации. В зависимости от типа пометки, информация по дугам относится в один из подразделов: "Информационные потоки", "Системные сообщения", "Документы/неструктурированная информация".

    Для каждой дуги выводится:

    1. Наименование дуги (Name).
    2. Описание дуги (Definition).
    3. Примечание дуги (Note).
    4. Перечень сущностей, ассоциированных с дугой.

    Для каждой сущности выводится:

    1. Наименование сущности (Name).
    2. Описание сущности (Definition).
    3. Перечень атрибутов, ассоциированных с дугой.

    Для каждого атрибута выводится:

    1. Наименование атрибута (Name).
    2. Тип атрибута (тип, заданный в AllFusion Data Modeler модели).
    3. Описание атрибута (Definition).

    Необходимые комментарии к технологии

    Недостатки подхода

    1. Один из недостатков (который с другой стороны является преимуществом, как будет сказано ниже) состоит следующем: для внесения изменений в требования к системе, приходится вносить изменения в AllFusion Process Modeler, или AllFusion Data Modeler модели, и это само занимает ощутимое время, а при неправильно разработанной модели, некоторые изменения могут привести к значительным переработкам.
    2. При экспорте данных в Doors наименование и определение к функции выводится как одно требование, т.е. в текущей версии модуля сопряжения нет возможности разделить на отдельные требования текст, введённый в определении функции
    3. поле Definition (в настоящий момент, для преодоления этого недостатка рекомендуется производить дополнительную декомпозицию сложной деятельности).

    Преимущества и другие характеристики

    1. Требования к ПО изначально организованы в виде системы связных функций, что позволяет уже на этапе сбора требований описать интерфейсы между различными функциональными блоками. Связность модели исключает наличие в требованиях "изолированных" функций, или "изолированных" информационных потоков.
    2. Фактически, модель AllFusion Process Modeler является прототипом системы и предоставляет возможность судить о расширяемости и изменяемости разрабатываемой системы в будущем. На практике так и происходит, поскольку все изменения к требованиям необходимо проводить через AllFusion Process Modeler и AllFusion Data Modeler модели, и чем "правильнее" построена модель, тем легче провести изменения.
    3. Любое единичное требование, или изменение к требованию вносится единожды и только в одном месте
    4. в AllFusion Data Modeler модель
    5. для требований к информации, в AllFusion Process Modeler модель
    6. для требований к функциям, в Doors
    7. для других требований. В окончательный документ требование/изменение попадает автоматически при помощи операций экспорта.
    8. В любой момент времени модели AllFusion Process Modeler, AllFusion Data Modeler и текст документа находятся в полном соответствии. Т.е. информационная модель соответствует процессной (функциональной) модели, а процессная (функциональная) модель полностью соответствует документу Техническому заданию.
    9. Процессная модель AllFusion Process Modeler должна отражать автоматизацию некоторых процессов (процессный подход), и это даёт возможность вместе с разработкой модели оптимизировать автоматизируемые, бизнес-процессы.
    10. Одним из побочных эффектов применения технологии стали хорошие результаты в структурировании требований к графическому интерфейсу, формулировка и структуризация которых всегда вызывает определённые сложности.
    11. Нельзя не отметить следующий положительный эффект
    12. на выходе мы получаем три документа, обращённых к различным категориям лиц, воспринимающих информацию со своей определённой точки зрения:
      • хорошо структурированный текстовый документ для тех, кто лучше воспринимает печатный текст;
      • IDEF0/DFD/IDEF3 модель, для тех, кому необходима функциональная схема ПО;
      • IDEF1X модель, для тех, кто воспринимает требования "от объектов", хотя могут понадобиться дополнительные диаграммы, например, StateChart.

    Опыт применения

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

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

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

    Приложения

    Приложение №1. Модель для ТЗ "Подсистема контроля филиалов"

    A0 Подсистема контроля филиалов

    Кликните для увеличения

    A1 Загрузка данных

    Организационная структура

    Приложение №2. Текст технического задания, получаемый из модели

     

     

    Подсистема контроля филиалов

    ТЕХНИЧЕСКОЕ ЗАДАНИЕ
    на разработку программного обеспечения

     

     

    Краткая характеристика подсистемы

    Подсистема "Подсистема контроля филиалов (A0)"

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

    Регламентирующая/управляющая информация

    Входящая информация

    Ресурсы

    Исходящая информация

    Основные решаемые задачи

    Загрузка данных
    Данные, предоставляемые филиалом, загружаются в БД Системы контроля, проводится контроль корректности данных и их предварительная обработка.

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

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

    Описание окружения

    Система хранения данных

    Система хранения данных накапливает информацию о финансовых потоках филиалов.

    Описание ролей

    Отдел контроля филиалов

    Оператор контролер

    Отдел обмена данными с филиалами

    Оператор обмена данными

    Требования к функциям

    Загрузка данных (A1)

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

    Регламентирующая/управляющая информация

    Входящая информация

    Ресурсы

    Исходящая информация

    Исполнители

    Загрузка данных о филиалах во временные структуры данных (A1.1)
    Загрузка пакета данных о филиалах должна производиться по команде оператора.

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

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

    Входящая информация

    Исходящая информация

    Актуализация данных о филиалах (A1.2)
    При загрузке данных о файлах должна проводиться их проверка на непротиворечивость, включая:

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

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

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

    Входящая информация

    Исходящая информация

    Загрузка данных о движении товара (A1.3)
    В случае успешной актуализации данных о филиалах, должна быть произведена загрузка данных о движении товара.

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

    В случае обнаружения ошибок в системном журнале должны быть сохранены соответствующие сообщения.

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

    Оборот товара (шт) = Продажа товара (шт) + Приход товара на склад (шт)
    Баланс на складе (шт) = Продажа товара (шт) - Приход товара на склад (шт)

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

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

    Как варианты, возможны следующие решения:

    Входящая информация

    Исходящая информация

    Загрузка финансовых данных (A1.4)
    Вне зависимости от результатов загрузки данных о движении товара, должна быть проведена загрузка финансовых данных.

    При загрузке финансовых данных, должны проводиться проверки на корректность данных, включая:

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

    Входящая информация

    Исходящая информация

    Контроль расчётных значений за сутки (A2)

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

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

    Для всех сформированных табличных форм должна быть обеспечена возможность экспорта информации в формат Microsoft Excel.

    Регламентирующая/управляющая информация

    Входящая информация

    Ресурсы

    Исходящая информация

    Исполнители

    Контроль суммарных расчётных значений (A3)

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

    Расчётные значения должны предоставляться пользователю в табличной форме.

    Для всех сформированных табличных форм должна быть обеспечена возможность экспорта информации в формат Microsoft Excel.

    Регламентирующая/управляющая информация

    Входящая информация

    Ресурсы

    Исходящая информация

    Исполнители

    Требования к информации

    Информационные потоки

    Данные о филиалах
    Данные о филиалах являются составляющей частью пакета данных о деятельнсти филиала и описывают основные характеристики филиала.

      Филиал

    Атрибуты

    Пакет данных о деятельности филиала (XML-файл)
    Пакет данных о деятельности филиалов поступает по электронной почте в виде прикрепленного файла в формате XML

      Движение товара

    Атрибуты

      Объемы продаж

    Атрибуты

      Расчетные данные

      Филиал

    Атрибуты

    Расчётные данные о товарах

      Расчетные данные

    Атрибуты

    Тарифы на продукт деятельности филиала
    Тариф на продукт деятельности филиала предоставляется региональным представительтвом по определению тарифов на продукты в регионе

    Формат предоставления данных может различаться в зависимости от региона. На данный момент используются форматы XML и CSV.

      Товар

    Атрибуты

    Системные сообщения

     

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

    За дополнительной информацией обращайтесь в компанию Interface Ltd.

    Обсудить на форуме Computer Associates

    Рекомендовать страницу
    INTERFACE Ltd.
    Телефон/Факс: +7 (495) 925-0049
    Отправить E-Mail
    http://www.interface.ru
    Rambler's Top100
    Ваши замечания и предложения отправляйте редактору
    По техническим вопросам обращайтесь к вебмастеру
    Дата публикации: 12.07.05