Некоторое время назад мы анонсировали старт работ по исследованию возможностей внедрения СУТ Devprom в проектах заказной разработки по ГОСТ. В это статье описаны основные функции , а также общая метамодель системы.

Макет экрана работы с системой представлен ниже.

Точное название системы – Devprom ALM, но нас интересовал этот продукт только с точки зрения управления требованиями, по крайней мере, на начальном этапе.

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

Нашей задачей было предложить систему управления требованиями для аналитиков нашего отдела, которая позволила бы по-прежнему работать с отчуждаемыми документами (ТЗ и ЧТЗ, или, как мы их называем, постановками на разработку).

СУТ должна была позволить:

экспортировать/импортировать документы MS Word, содержащие форматирование стилями с использованием фильтров;
работать с атрибутами требований;
работать с запросами на изменение;
работать с версиями требований;
делать трассировки требований между собой и на задачи в Jira (в перспективе).

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

За время исследования продукта Devprom ALM мы добились некоторых промежуточных результатов, которыми хотим поделиться.

Варианты использования СУТ Devprom аналитиком в процессах разработки по ГОСТ

Ниже представлена диаграмма вариантов использования СУТ Devprom аналитиком в процессах разработки по ГОСТ, как мы эти варианты использования видим.

Общая метамодель Devprom

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

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

Проект – это область, в рамках которой ведется работа с требованиями (например, 3-я очередь развития системы).
Функция – это группа требований (например, модуль некой системы).
Требование – это собственно SMART требование, которое готовит аналитик. Мы введем типизацию и добавим необходимые атрибуты.
Пожелание – это кратко сформулированная «фича» для планирования итераций (в процессе Agile-разработки). В чистом виде нам не подойдет, но мы предложим, как ее можно использовать (либо можно совсем от нее отказаться).
Тест-кейс – сценарий проверки требования (для последующей вставки в ПМИ).

Метамодели для процессов разработки по ГОСТ

Ниже представлены варианты наших метамоделей, предлагаемых для использования в проектах разработки по ГОСТ.
Для начала будем рассматривать вариант, когда ТЗ уже есть, и аналитик привлекается для его детализации в рамках разработки техно-рабочего проекта (ТРП). Вариант, когда аналитик привлекается, когда еще нет ТЗ, также рассмотрим позже.

Использование сущности «Пожелание» для исходных требований ТЗ

Метамодель с использованием исходных требований ТЗ в качестве пожеланий представлена ниже.

ТЗ – это документ MS Word с заголовками, простыми фрагментами текста, списками, таблицами и изображениями (диаграммами и схемами).
Можно представить требования ТЗ как исходные пожелания заказчика. Возможен импорт пожеланий в СУТ, но только из MS Excel (такое ограничение только для пожеланий). Необходимо предварительно «причесать» ТЗ, преобразовав его в Excel-таблицу, выкинув все общие слова, оставив только требования к реализации (которые теперь будут называться пожеланиями).

Пример таблицы с пожеланиями (формулировки из ТЗ):

Также аналитик может заносить пожелания в систему сразу, минуя Excel. Это весьма удобно, так как аналитик может оперативно фиксировать все пожелания/уточнения заказчика для дальнейшей проработки.
Далее аналитик пишет свои постановки на одно или несколько пожеланий в обычных документах MS Word, после чего импортирует эти документы в СУТ и связывает их с конкретными пожеланиями. Трассировку можно делать как целыми постановками, так и отдельными требованиями в постановках (они автоматически вычленяются по заголовкам при импорте документа). По мере разработки постановок можно смотреть покрытие пожеланий постановками.
Аналитик или тестировщик также может писать тест-кейсы для программы и методики испытаний (как в отдельных документах MS Word, так и непосредственно в web-интерфейсе СУТ) и также смотреть покрытие пожеланий/постановок/требований тест-кейсами.
После импорта постановок и тест-кейсов в СУТ возможна доработка их непосредственно в web-интерфейсе СУТ. При необходимости возможна выгрузка обратно в Word по фильтрам.
Пожелания также могут использоваться для фиксации запросов на изменение.

Использование сущности «Требование» для исходных требований ТЗ

Исходные требования непосредственно в составе документа ТЗ импортируются в СУТ и помечаются типом «ТЗ».
Отличия от предыдущего варианта в том, что и исходное и детализированное требование представлены сущностью «Требование», но с разным типом.

Заключение

Мы планируем продолжить исследования возможностей использования системы управления требованиями Devprom применительно к заказной разработке по ГОСТ.
Однако мы столкнулись с некоторыми трудностями, касающимися импорта и экспорта документов MS Word со стилями. Дело в том, что требования к оформлению документов по ГОСТ 2.105 предполагают точное стилевое оформление документов. Многочисленные стили заголовков, списков, таблиц и текста таких документов тяжело обрабатывать автоматическими анализаторами, которые разрабатывают специалисты Devprom.
Частично эту проблему удалось решить. Специалисты Devprom доработали по нашей просьбе коннектор импорта/экспорта документов в части возможности использования собственного стилевого шаблона.

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