Неожиданный эксперимент по управлению требованиями

Мадорская Ю., Курносова И., Хохрина А.

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

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

Поэтому наш неожиданный эксперимент интересен тем, что мы провели (не по своей воле) такое сравнение на одних и тех же данных. Как это было в деталях, читайте ниже.

Исходная задача.

Есть четыре документа с требованиями. Каждый документ содержит примерно 900 единиц информации, из них требований около 80%. Каждый из документов описывает одну систему, причем все четыре системы — это системы одного класса, при этом один из документов — это стандарт на системы данного класса.

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

Две технологии эксперимента.

Распарсив документы в Cradle с помощью модуля Document Loader далее необходимо было выделить из каждого документа три класса требований — структуру и содержание функций и данных, а также нефункциональные требования в виде целей и других характеристик процессов.

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

Решив ускорить процесс обобщения, мы собрались втроем для того, чтобы с помощью переклички, держа перед собой структуры данных по одной системе, быстро определять какой из элементов есть у каждого и отмечать это в Cradle. Но, неожиданно оказалось, что в месте сбора не работает интернет и сервер нам не доступен. Это нас не остановило и, в связи с тем, что мы все равно уже собрались вместе, мы решили вернуться к бумажной технологии анализа, т. к. копии документов у всех были.

Т.к. задача, которую мы решаем, очень важная, мы решили начать с того, что провести повторный независимый анализ и снова выделить структуры данных из этих четырех документов, а затем по перекличке провести объединение. На анализ каждого документа и выделение в тексте структур данных было потрачено 2*3 чел/часа, далее мы приступили к перекличке и объединению. На 6 элементе, самый молодой участник этого неожиданного эксперимента тихо и не очень уверенно произнес сокраментальную фразу «мне кажется, что это неэффективно». Это была очень мягкая оценка происходящего…

Действительно, получилось, что за 4*3/чел часа мы не сделали и одной пятой части работы, т.е. вся работа при такой технологии заняла бы у нас 12*5=60 чел/часов. В то время как при использовании Cradle на ту же самую задачу, на тех же данных было потрачено всего 6 часов.

Почему так? Вот некоторые факторы, которые можно назвать не раздумывая:

  1. Возможность быстрой смены способа отображения распарсенного документа, возможность нелинейного представления информации (в отличие от документов)
  2. Групповое копирование иерархий с сохранением связей.
  3. Возможность вывести на экран необходимое число панелей с элементами в различных представлениях.
  4. Навигации, возможность отображать связи в нужном направлении.
  5. Мгновенная связь с исходным документом, когда надо посмотреть в каком точно контексте использовалось требование.
  6. Возможность объединения элементов с передачей их связей на общий элемент.
  7. Возможность автоматического разбиения элемента на более мелкие с сохранением связей.
  8. Горячие клавиши на создание связей между элементами, открытыми в разных представлениях/панелях.
  9. Создание связей между группами элементов, перетаскиванием.
  10. Групповая перенумерация.

В ходе этого неожиданного эксперимента вспомнилась фраза из замечательной презентации Инны Курносовой «Технология управления требованиями по принципам йоги»:

 Как понять, что вы выбрали правильную систему? После внедрения системы управления требованиями, отложите ее на некоторое время и вернитесь к старой технологии. Если вам станет плохо, неудобно работать, начнется физическая ломка, значит вы выбрали правильную систему.
Author's imageКурносова И.А.

Как мы это прочувствовали!

Эксперимент показал, что «физические неудобства» испытали оба участника группы, которые до этого выполняли ту же самую работу в Cradle. Причем эти ощущения были настолько явными, что можно было заметить дерганье пальцев при попытке скопировать иерархии в бумажном документе. Примерно также, как цифровой художник пытается нажать ctrl-z при переходе к рисованию на бумаге.

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

Добавить комментарий