Моделирование пользовательских интерфейсов и трассировка требований

На ранних стадиях проектирования пользовательский интерфейс — один из самых изменяемых компонентов ПО.  Хорошо, когда все требования оттрассированы к элементам интерфейса — тогда при изменениях легко понять, что на что повлияет, например, какие элементы интерфейса затронет изменение выбранного Use Cases или на какие Use Cases повлияет изменение поля на форме?

Существуют разные инструменты проектирования интерфейсов: кто-то рисует их от руки на бумаге, кто-то использует Visio, а кто-то специализированное ПО типа Axure. Часто используется технология «wireframe», так называемых каркасов, которые позволяют определить требования к составу элементов интерфейса, их пропорциям и взаимному расположению.

Как и другие требования, требования к пользовательскому интерфесу, как правило разрабатывает системный аналитик (или тот, кто выполняет эту роль в проекте). Если в команде есть выделенный специалист по проектированию интерфейсов, то далее эти требования могут быть переданы ему на доработку и реализацию.

Как поддержать этот процесс в 3SL Cradle и обеспечить трассируемость всех требований, в том числе, требований к пользовательскому интерфейсу? Есть несколько вариантов:

  1. Разработка требований к пользовательскому интерфейсу с помощью wireframe прямо в Cradle.
  2. Интеграция Cradle с внешним редактором wireframe с помощью технологии фреймов.
  3. Комбинация 1 и 2.

Рассмотрим их по порядку.

Разработка требований к пользовательскому интерфейсу с помощью wireframe прямо в Cradle

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

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

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

Мы рекомендуем использовать для этого диаграммы Block Definition Diagrams из SysML, как наиболее соответствующие семантике данной задачи, а также потому, что блоки могут быть вложенными, что это полностью соответствует концепции пользовательских интерфейсов.

Для моделирования интерфейса можно просто использовать блоки (Рисунок 1)  или дополнить их своей библиотекой изображений (Рисунок 2).

GUI_sysml

Рисунок 1. Моделирование пользовательского интерфейса с помощью Block Definition Diagram (без дополнительных изображений)

GUI_sysml_images

Рисунок 2. Моделирование пользовательского интерфейса с помощью Block Definition Diagram (с добавленными к каждому блоку изображениями)

При этом для каждого блока автоматически создается его спецификация:

GUI_sysml_specs

Рисунок 3. Спецификации блоков SysML Block Definition Diagram в Cradle

Которая далее может быть связана с исходными требованиями заказчика или Use Cases или любыми другими типами проектных данных.

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

При этом спецификации можно использовать повторно, т.е. один и тот же элемент может появляется на разных диаграммах (например, повторное использование формы поиска). Соответственно при изменении спецификации этого элемента, она поменяется для всех диаграмм.

GUI_edit_spec

Рисунок 4. Редактирование спецификации элемента пользовательского интерфейса.

Все привычные функции Cradle, такие как запросы, представления, аналитические HID-диаграммы и матрицы трассировки будут работать и в этом случае:

GUI_specs_hid

Рисунок 5. Аналитические трассировочные представление в виде таблицы трассировки и диаграммы иерархии для пользовательского интерфейса.

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

Интеграция Cradle с внешним редактором wireframe с помощью технологии фреймов

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

Такая интеграция настраивается с помощью фреймов (атрибутов элементов). Фреймы могут либо хранить в себе файлы сторонних программ или ссылаться на файлы или веб-адреса в сторонних приложениях.

Для Visio существует готовый тип фрейма (Visio link), который позволяет связывать требования в Cradle с конкретными символами диаграмм Visio. Чтобы использовать эту технологию — просто добавьте в настройках проекта к вашему типу(ам) требований (например, Use Cases) фрейм типа Visio link.

Для Axure или других внешних редакторов можно настроить свой тип фрейма — это делается за несколько минут. При этом можно настроить фрейм так, чтобы файл проекта интерфейса сохранялся в Cradle, а при редактировании открывался специализированный инструмент. При этом все изменения будут также сохранятся в Cradle.

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

Поэтому если необходима высокая точность трассировки, то для разработки wireframe лучше использовать технологию проектирования, описанную в первом варианте.

Комбинация двух предыдущих вариантов

Комбинация двух предыдущих вариантов будет хорошо работать в случае, когда исходные требования к интерфейсу разрабатывает системный аналитик, например, в виде рассмотренных выше wireframe, а далее передает эти требования на реализацию дизайнеру интерфейсов.

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

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