Мозг системного аналитика глазами команды

Сравнение систем управления требованиями и баг-треккеров

Мадорская Ю.М.

«Связи решают все»  — каждый поймет по-своему эту фразу.  Для системной инженерии связи — это, прежде всего, целостность системы.  Нет связей — нет системы. При проектировании используются разные типы связей: иерархические — отражающие структуру требований, функций, модулей системы; причинно-следственные — между целями создания системы и ограничениями, к которым они приводят; детализирующие — между требованиями и моделями, уточняющими реализацию этих требований. Хорошо еще использовать связи требований с тестами — чтобы контроллировать выполнение требований заказчика. Это то, что сегодня называется обеспечением трассируемости требований или просто — трассировкой требований.

Вот пример такой трассировки — от целей к нефункциональным требованиям, функциям и тестам.

Рисунок 1. Трассировка требований разных классов.

Рисунок 1. Трассировка требований разных классов.

Трассировка требований — ключ к ответу на многие вопросы о проекте: могут ли быть достигнуты поставленные цели? Все ли требования учтены при проектировании? Требования прошли проверку или нет? Если не прошли, то какую часть проекта затрагивают найденные ошибки?

Если команда не способна поддерживать трассируемость требований — она не жизнеспособна. Также как и система, которую она создает. Отдельные проекты «выезжают» на энтузиазме аналитиков-супергероев, которые, находясь в состоянии постоянной активации, держат в голове все связи проекта, но большинство — опасаясь полагаться на супергероев, использует для этого проектные хранилища с возможностью управления системными связями — «мозг аналитика».

Чаще всего такие хранилища называют «системы управления требованиями».  Их довольно много и неопытной команде сложно сориентироваться при выборе. Однако существует тест, который позволяет быстро выявить профнепригодность такой системы для поддержки процессов системной инженерии. Этот тест включает несколько пунктов:

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

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

Таблица 1. Сравнение систем управления ошибками и систем управления требованиями по возможностям настройки модели проекта

Возможности/Системы Настройка типов элементов  Настройка типов связей Допустимая кардинальность связей
Треккеры
Redmine Да Нет
(предустановленный набор, доступно 5 типов связей)
JIRA Да Да Многие-ко-многим
Системы управления требованиями1
Axiom Да Да  Один-ко-многим
Devprom Ограничено
(фиксированный набор типов элементов — пожелания, требования, функции, тесты. Для некоторых из них можно создавать подтипы)
Нет
(доступно 2 типа связей)
IBM DOORs Да Да Многие-ко-многим
с ограничениями
3SL Cradle Да Да Многие-ко-многим

Чтобы далее не прогадать с выбором системы, потребуется на практике оценить:

  • Удобство разработки требований непосредственно в самой системе. Будет плохо, если требования придется разрабатывать как обычно в Word, а затем руками переносить поэлементно в систему управления требованиями. Это неизбежно приведет к проблемам управления версиями и рассинхронизации требований в документах и в системе.
  • Скорость создания связей. Сколько кликов потребуется, чтобы создать связь между требованием, которое отображено на экране и тем, над которым шла работа два часа назад? Если создание связей будет отнимать много времени, то аналитик будет игнорировать это и по-прежнему попытается держать все в голове. Тогда лучше не подписывать отпуск этому супергерою.
  • Аналитическую эргономику. Это комплексный параметр, который отражает возможности и легкость использования созданных связей для ответов на аналитические вопросы. Например, на какие функции системы повлияет изменение размерности этого поля данных? Какие требования по подсистеме еще не прошли тестирование? Это возможность системы мгновенно предоставить требуемый аналитический срез в форме матрицы трассировки, таблицы трассировки или иерархической диаграммы. Особенно важна возможность получения таких срезов на основе транзитивных связяй — чтобы учитывать косвенные влияния изменений.

Чтобы оценить эти три пункта придется провести командный пилот-проект. В ходе этого проекта2 стоит обратить внимание:

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

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

Эта шутливая зарисовка показывает, как может выглядеть «мозг аналитика» в зависимости от возможностей системы управления требованиями:

  • Без системы управления требованиями, с использованием документо-ориентированной технологии, например, MS Word.
  • С использованием JIRA.
  • С использованием 3SL Cradle.
Рисунок 2. Полнота связей в проектной базе в зависимости от инструмента управления требованиями

Рисунок 2. Полнота связей в проектной базе в зависимости от инструмента управления требованиями 3

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

Если же инструмент уже внедрен, то проектная база со связями —  это объективная оценка совместных возможностей команды и инструмента. Практика показывает, что при качественной работе связей в проектной базе в 2-3 раза больше, чем элементов. Если «мозг аналитика» не дотягивает до этих параметров, стоит задуматься либо о повышении квалификации системных аналитиков, либо о смене инструмента.

Гениальность — это умение видеть и использовать связи. Работа системного аналитика — создавать и управлять связями так, чтобы они были очевидны и понятны всей команде, именно тогда это будет коллектив, который можно назвать гениальным.

Примечания:

1 Confluence — это веб-аналог MS Word, т.е. это документо-ориентированная технология, она не поддерживает управление отдельными требованиями и их связями, поэтому не включена в обзор.
При сравнении систем управления требованиями на таком пилот-проекте необходимо использовать одинаковую модель трассировки требований.
Цвета кодируют разные типы элементов и разные типы связей.

Хотите сослаться на эту статью? Используйте правильную ссылку:

Мадорская Ю.М. Мозг системного аналитика глазами команды. //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/analysts-brain/, свободный. — Загл. с экрана

 

 

11 Comments

  1. Уважаемые коллеги, пользуюсь Девпромом уже достаточно продолжительное время и не согласен с Вашими выводами в отсутствии этих свойств:

    >>2. Возможность настройки типов связей. Например,чтобы отделить иерахические связи требований от причинно-следственных.

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

    >> Допустимая кардинальность связей «многие-ко-многим». Например, одному требованию может соответствовать много тестов, а один тест может покрывать несколько требований.

    Это свойство также поддерживается Девпромом. С требованием можно связать множество тестов и, обратно, на каждый тест можно добавить множество требований.

    • Павел, здравствуйте!

      Спасибо за комментарий, здорово, что Вы пользуетесь одной из систем из этого обзора. Не могли бы Вы тогда поделиться скриншотом, где показано, как настроить ТИПЫ связей в Devprom, нам не удалось это найти.

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

      С наилучшими пожеланиями,
      Мадорская Ю.М.

      • Здравствуйте. Скриншоты с Яндекс.Диска:
        — Иерархическая связь между требованиями: https://yadi.sk/i/gnVABCysigcHQ
        — Связанные требования, кардинальность связей «многие-ко-многим»: https://yadi.sk/i/CwQ0znGWigcQw (задается в свойстве требования)
        — Один из вариантов представления трассировок: https://yadi.sk/i/POeylOB2igcTe

        • Павел,

          спасибо за скриншоты. Мы уточнили таблицу, изменив примечание «доступен 1 тип связи» на «доступно 2 типа связей».
          Однако на этом, к сожалению, всё. Вы, как и мы, подтвердили, что в этой системе невозможно настроить свои типы связей, как, например, в JIRA, Axiom, 3SL Cradle. Т.е. составленная сравнительная таблица корректна.

          Колонка «Кардинальность связей» не имеет смысла без возможности настройки типов связей — если мы не можем создать свой тип связи, то и нет предмета для обсуждения кардинальности связей этого типа (таких связей просто нет).

          Спасибо за участие!

          С наилучшими пожеланиями,
          Мадорская Ю.М.

          • Да, для требований, в отличие от пожеланий, в настоящее время именно типы связей задать нельзя.

  2. Павел,

    да, по этому критерию Devprom пока недотягивает до Redmine, в котором можно настроить 5 типов связей для ЛЮБЫХ типов элементов ( в Devprom только для одного и заранее заданного). Хотя в Devprom и признают необходимость типизации связей.

    Однако Redmine это все-таки треккер и у него нет удобной возможности работать с иерархиями требований. В Devprom есть некоторая поддержка иерархий, однако она неполноценная с точки зрения работы со связями. Кроме отсутствия возможности создания разных иерархий по разным типам связей, непонятно даже для одного доступного типа связи, можно ли:
    а) включить одно и тоже требование в несколько иераррхий,
    б) можно ли быстро посмотреть, в какие иерархии входит конкретное требование.

    Посколько Devprom не проходит по критерию ТИПЫ связей, то мы не стали детально изучать насколько именно усечена работа с иерархиями (понятно, что усечена, т.к. иерархия в данном случае может быть построена только на одном типе связи), но если Вы знаете ответы на вопросы а и б — было бы интересно узнать!

    С наилучшими пожеланиями,
    Мадорская Ю.М.

  3. Добрый день, Юлия.

    Очень жаль, что Вы «лихо» выкинули Confluence из рассмотрения и составили для него столь узкое описание. Всё же Confluence это не веб-word, это WIKI, которая позволяет за счёт особенностей своей организации использовать как связи между требованиями, так и контролировать эти связи (косвенно, не явно), но всё же. Необходимо также учитывать и особенности самого проекта и требования к документированию в рамках этого проекта.
    Для меня несомненным плюсом использования Confluence — является возможность создания разнородного контента (как графики, так и тексто-таблиц) в одном месте, без необходимости использовать несколько различных приложений.

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