Клуб разработчиков программных систем

Темы | Статьи | Рейтинги |

Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational

Галахов И.В., Лапыгин Д.В., Новичков А.Н., Подоляк О.Р., Позин Б.А.
rational@sibintek.ru, www.sibintek.ru

01.07.2003

Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем"www.osp.ru, www.fostas.ru
На страницах www.caseclub.ru публикуется с разрешения авторов.

Предисловие

В статье представлена технология автоматизированного создания документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational, разработанная на основе опыта, полученного в ходе реализации ряда проектов при проведении сравнительного анализа состава и содержания артефактов Rational Unified Process (RUP) и требований к оформлению документов по ГОСТ 34 и 19.

Рассмотрены краткие сведения об используемых инструментальных средствах IBM Rational.

На конференции по стандартам данный доклад вызвал практический интерес аудитории, что и побудило авторов к его размещению в Интернете. Планируется публикация продолжения данной статьи. Если Вас заинтересовал данный материал, то можете присылать вопросы по адресу rational@sibintek.ru

По этому же адресу (rational@sibintek.ru) можно запросить презентацию доклада на русском языке в формате PowerPoint и подписаться на рассылку новостей по продуктам и технологиям IBM Rational.

Введение

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

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

Вторым аспектом повышения эффективности проектов является автоматизация рутинных операций за счет использования инструментальных средств, что позволяет снизить влияние “человеческого фактора” на конечный результат.

Регламентация проектной деятельности основывается на стандартах и методологиях, среди которых в настоящее время наиболее популярны как стандарты ГОСТ 34-й и 19-й серий, определяющие требования к разрабатываемой документации, так и новые стандарты ГОСТ Р ИСО/МЭК 12207-99 и ГОСТ Р ИСО/МЭК 14764-2002, определяющие процессы жизненного цикла программных средств. Одной из наиболее развитых и популярных методологий, описывающих процессы ЖЦ ПС, является Rational Unified Process (RUP), разработанный компанией Rational Software и соответствующий ГОСТ Р ИСО/МЭК 12207-99. При этом необходимо отметить, что RUP ориентирован прежде всего на разработку ПС и без предварительной адаптации не может использоваться для задач процесса сопровождения.

Сейчас складывается ситуация, когда многие коллективы, разрабатывающие программные средства, переходят на использование технологий, основанных на методологии RUP. В то же время, большинство Заказчиков, как внешних, так и внутренних, продолжают использовать стандарты серии ГОСТ 19 и 34 как основные при приемке программных средств от разработчика. Таким образом, возникает необходимость поддерживать двойную технологию, ориентируясь при разработке на методологию RUP, а при сдаче результатов – на стандарты ГОСТ 19 и 34. Такая ситуация может просуществовать достаточно долго и требует решения, позволяющего максимально снизить затраты по использованию такой двойной технологии.

Далее в статье представлены результаты обобщения опыта нескольких проектов, сведенные в единую технологию, позволяющую автоматизировать процесс формирования документов серии ГОСТ 19 и 34 на основании данных и артефактов, создаваемых в ходе разработки ПС по технологии, основанной на Rational Unified Process.

Адаптация RUP

RUP является методологией, которую можно применять к проектам различного уровня и с различными характеристиками. Обратной стороной такой универсальности является тот факт, что RUP нельзя применить в том виде “как он есть”, необходимо провести адаптацию RUP к потребностям конкретной организации или проекта.

Реализация методологии RUP в виде набора взаимосвязанных компонентов (см. рисунок 1), таких как “стадия”, “процесс”, “работа”, “задача”, “роль”, “артефакт”, позволяет применять типовой подход при его адаптации, учитывая при этом требования, как международных стандартов, так и стандартов серии ГОСТ 19 и 34. Представленный в статье опыт адаптации стандартов к потребностям организации (предприятия) обобщен и доведен до уровня типовой технологии, которая может быть использована при реализации аналогичных проектов.

Рисунок 1 - Взаимосвязь компонентов RUP

Далее рассматривается только вариант адаптации RUP, выполняемый с целью формирования в ходе проекта документации, соответствующей требованиям ГОСТ 19 и 34. Адаптация проводится в основном за счет уточнения состава работ, задач, ролей и, прежде всего, артефактов и взаимосвязей между ними. В отдельных случаях может изменяться состав стадий и процессов, но такие случаи в данной статье не рассматриваются.

Артефакты RUP и документы ГОСТ

Пусть имеется один или несколько проектов разработки или сопровождения программных средств, в которых используется технология работ, основанная на RUP, а документация на программные средства должна соответствовать требованиям ГОСТ 19 или 34.

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

Для решения задачи было проведено сопоставление артефактов RUP и документации, разрабатываемой по требованиям ГОСТ 19 и 34. При сопоставлении артефактов учитывались стадии ЖЦ ПС, на которых они разрабатываются. Сопоставление стадий RUP и ГОСТ 34 приведено в таблице 1.

Таблица 1 - Сравнительный анализ стадий RUP и ГОСТ

Стадии RUP

Стадии ГОСТ 34.601-90

Обследование (Inception)

Формирование требований

Разработка концепции

Техническое задание

Технический проект (Elaboration)

Эскизный проект

Технический проект

Рабочий проект (Construction)

Рабочая документация

Передача в эксплуатацию (Transition)

Ввод в действие

Сопровождение

С учетом установленного соответствия стадий, для каждой стадии были выделены группы артефактов RUP, на основании которых могут автоматически генерироваться документы ГОСТ19 и 34. Необходимо отметить, что понятие “артефакт” включает не только документы, но и другие проектные материалы, создаваемые в ходе выполнения проекта. Например, модели, исходные коды, тестовые скрипты и т.п.

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

Для установления четкого однозначного соответствия между артефактами RUP и документами ГОСТ необходимо “опуститься” на уровень отдельных разделов документов и компонентов артефактов. Понятие “компонент” используется для артефакта вместо понятия “раздел” по той причине, что, как было показано ранее, не все артефакты являются документами и говорить о “разделе” применительно к модели нельзя. Поэтому в каждом артефакте выделяются компоненты, а в документах используются разделы, соответствующие требованиям ГОСТ (см. рисунок 2).

Рисунок 2 - Взаимосвязь артефактов RUP и документов ГОСТ

В сравнении участвуют только те артефакты RUP, которые создаются в ходе для конкретного проекта (их перечень определяется при планировании), и действует правило сопоставления по стадиям – документы ГОСТ 19 и 34 или их разделы, формирующиеся на определенной стадии, сопоставляются с артефактами RUP, которые создаются на той же стадии. В качестве примера можно привести перечень основных документов по ГОСТ 19, обычно используемых в проектах и наиболее часто используемых артефактов RUP (см. таблицу 2).

Таблица 2 - Основные документы ГОСТ 19 и артефакты RUP

Стадия

Артефакт RUP

Документы ГОСТ 19

Техническое задание

  • Концепция системы
  • Описание процесса разработки продукта
  • План разработки продукта

Техническое задание 19.201-78

Эскизный проект

  • Архитектура системы
  • Руководство по программированию
  • Руководство по проектированию
  • Дополнительные технические требования
  • План тестирования
  • План обеспечения качества
  • План разработки продукта

Пояснительная записка 19.404-79

В результате на этом шаге мы имеем для каждого формируемого документа ГОСТ 19 и 34 набор компонентов артефактов, на основании которого можно формировать документ.

Адаптация структуры и содержания артефактов RUP

При проведении анализа состава и содержания документов ГОСТ и артефактов RUP выясняется, что большинство компонент артефактов RUP имеют достаточную избыточность, т.е. содержат не только информацию, соответствующую разделам документов ГОСТ 19 и 34, но и информацию, в документах ГОСТ 19 и 34 не использующуюся. В некоторых случаях разделы документов ГОСТ 19 и 34 и артефактов RUP практически полностью совпадают друг с другом.

Примером практически полного соответствия разделов могут служить требования ГОСТ 19.301-79 “программа и методика испытаний”, которые совпадают с требованиями к разделу артефакта RUP “план тестирования” (см. таблицу 3).

Таблица 3 - Соответствие требований ГОСТ 19.301-79 и артефакта RUP “План тестирования”

Требования ГОСТ 19.301-79

Требования RUP

…должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах “Требования к программе” и “Требования к программной документации”

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

Все же в большинстве случаев невозможно установить однозначное соответствие между компонентами артефактов и разделами документов ГОСТ 19 и 34 без дополнительной адаптации структуры и содержания артефактов RUP. В отношении документов ГОСТ 19 и 34 мы исходим из предположения, что их структура и содержание согласовано с Заказчиком и дальнейшего уточнения не требует. Остается только “подогнать” артефакты RUP под структуру и содержание документов ГОСТ 19 и 34 путем дополнительной адаптации.

На этом шаге необходимо решить следующие задачи (см. рисунок 3):

Рисунок 3 - Реструктуризация артефактов RUP

В результате проделанной реструктуризации мы получаем возможность формировать документы ГОСТ 19 и 34 из компонент артефактов, не редактируя содержание этих компонент, т.к. вся внутренняя информация уже переведена в другие компоненты артефактов, которые не участвуют в формировании документов ГОСТ 19 и 34.

Автоматизированное создание документов ГОСТ

После установления соответствия между документами ГОСТ 19 и 34 и артефактами RUP на уровне разделов и компонентов является разработка специальных шаблонов для настройки автоматизированной отчетности с помощью инструментального средства Rational SoDA.

Rational SoDA имеет возможности выборки данных из различных артефактов, созданных на основе инструментальных средств Rational, – моделей данных и классов (Rational Rose), версионного хранилища (Rational ClearCase), репозитория требований (Rational RequisitePro), репозитория запросов на изменения (Rational ClearQuest), репозитория тестирования (Rational Test Manager).

Документация генерируется по заранее определенным шаблонам на основе артефактов, создаваемых в процессе выполнения работ ЖЦ ПС. Генератор отчетов Rational SoDA имеет ряд встроенных отчетов, ориентированных на работу по методологии RUP. Для генерации документов другого типа требуется разработать новые шаблоны, что и было сделано при формировании документов серии ГОСТ 19 и 34.

Преимущества представленной технологии

Представленный обобщенный опыт автоматизированного создания документов ГОСТ 19 и 34 на основе адаптации артефактов RUP к потребностям организации доведен до уровня типовой технологии, которая может быть использована при реализации аналогичных проектов и включает следующие составляющие:

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

       

    1. Технология основана на широко распространенной методологии и стандартах и может использоваться в большом числе проектов при незначительном уровне доработок;
    2. Применение такой технологии сокращает до минимума количество ручных операций при создании документации;
    3. Использование технологии позволит косвенным образом контролировать ход проекта по уровню готовности документации, которая может автоматически создаваться на любом этапе проекта;
    4. Представленная технология может быть достаточно легко применена к документации и отчетности любого типа, отличного от рассмотренных документов серии ГОСТ 19 и 34, за счет переработки шаблонов отчетов SoDA и реструктуризации артефактов RUP в соответствии с требованиями по структуре и содержанию документации.

Сведения об авторах:

Все авторы работают в дирекции по консалтингу и методологии создания программного обеспечения информационных систем компании ООО ИК СИБИНТЕК в г. Москва.

Позин Борис Аронович– директор дирекции,
Галахов Илья Владимирович– начальник управления,
Лапыгин Дмитрий Владимирович – главный специалист,
Новичков Александр Николаевич – ведущий специалист,
Подоляк Ольга Робертовна – старший специалист.

rational@sibintek.ru
www.sibintek.ru

 

Статьи по теме:

Rational Unified Process – путь к успеху. Руководство по внедрению RUP.
Rational Unified Process – это легко.Руководство по RUP для практиков.
Методы сбора требований к программному обеспечению
Варианты использования (Use Case)
Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств...
Рабочие процессы RUP и диаграммы UML
Унифицированный процесс разработки от Rational Software
Использование моделей в процессе разработки программных систем
Что такое Rational Unified Process

Связанные темы:
IBM Rational
RUP
| 1 |

Имя : Сергей Трофимов 01/07/2003 23:07
Сообщение:
Идея интересная, но не совсем понятно как она будет воплощаться, поскольку примера шаблона SoDa или хотя бы созданного по нему документа в статье нет. А то, что их можно создать - это и так понятно.
Несколько странно выглядят диаграммы, созданные явно не в Rational Rose, хотя статья по продуктам Rational.
В целом остается какое-то ощущение недосказанности. Вроде идея есть, а попробовать или посмотреть как это работает нельзя.
Ответить

Имя : Yuri I. Bouloui Город : Москва 04/07/2003 17:05
Сообщение:
Согласен с интересностью идеи ... но вот не вполне понятно как насчет итеративного процесса -- это таки неотъемлемая часть RUP ... и как это вяжется с ГОСТ, который IMHO "водопад"?
Ответить

Имя : Гость Город : Москва 08/11/2005 18:46
Сообщение:
ГОСТ не есть "водопад" :) Итерации в ГОСТ тоже предусмотрены. В виде дополнительных соглашений и т.д.

Положим, прокололись на стадии "техническое задание", потребовалось внести изменение в некий раздел указанного документа. Пишем Дополнение к ТЗ, в нем - "пункт такой-то принять в указанной ниже редакции". Далее - новая редакция того самого пункта. И с Заказчиком Дополнение согласовываем.

Вот и все. Это и есть итерация.
Ответить

Имя : Светлана 02/12/2005 17:23
Сообщение:
Где можно найти руководство пользователя на русском языке о том, как правильно настроить почту, чтобы принимать (отправлять) сообщения пользователям при изменении статуса запроса?
Ответить

Имя : Ангелина 06/02/2007 11:25
Сообщение:
Где можно найти шаблоны (стандарты) для написания документации? Почитать о том, какие вообще документы должны создаваться на стадии системного анализа?
Ответов: 1 Последний ответ: 06/02/2007 11:40


| 1 |
Комментарии к статьям закрыты.

© Trofimov Sergey   http://www.caseclub.ru при цитировании ссылка обязательна.