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

Введение

Некоторое время назад мы с Алексеем Киселевым анонсировали старт работ по исследованию возможностей внедрения СУТ Devprom в проектах заказной разработки по ГОСТ.

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

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

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

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

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

— экспортировать/импортировать документы MS Word, содержащие форматирование стилями с использованием фильтров;

— работать с атрибутами требований;

— работать с запросами на изменение;

— работать с версиями требований;

— делать трассировки требований между собой и на задачи в Jira (в перспективе).

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

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

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

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

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

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

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

— Проект — это область, в рамках которой ведется работа с требованиями (например, 3-я очередь развития системы).

— Функция — это группа требований (например, модуль некой системы).

— Требование — это собственно SMART требование, которое готовит аналитик. Мы введем типизацию и добавим необходимые атрибуты.

— Пожелание — это кратко сформулированная «фича» для планирования итераций (в процессе Agile-разработки). В чистом виде нам не подойдет, но мы предложим, как ее можно использовать (либо можно совсем от нее отказаться).

— Тест-кейс — сценарий проверки требования (для последующей вставки в ПМИ).

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

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

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

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

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

ТЗ — это документ MS Word с заголовками, простыми фрагментами текста, списками, таблицами и изображениями (диаграммами и схемами).

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

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

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

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

Аналитик или тестировщик также может писать тест-кейсы для программы и методики испытаний (как в отдельных документах MS Word, так и непосредственно в web-интерфейсе СУТ) и также смотреть покрытие пожеланий/постановок/требований тест-кейсами.

После импорта постановок и тест-кейсов в СУТ возможна доработка их непосредственно в web-интерфейсе СУТ. При необходимости возможна выгрузка обратно в Word по фильтрам.

Пожелания также могут использоваться для фиксации запросов на изменение.

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

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

Заключение

Мы планируем продолжить исследования возможностей использования системы управления требованиями Devprom применительно к заказной разработке по ГОСТ.

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

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

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

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

Авторы: 

Борис Сторонкин, ведущий аналитик IBS

Алексей Киселев, аналитик IBS