- PVSM.RU - https://www.pvsm.ru -
При работе с требованиями возможно применение различных методов их организации: от метода полного хаоса, до интеграции требований с программным кодом (статья Пять уровней зрелости требований [1]). Постепенно улучшая работу с требованиями, обычно, в процесс начинают внедрять различные новые методологии и инструменты. Одним из классов инструментов, призванных упростить работу с требованиями, являются специально обученные «зверьки»: Системы Управления Требованиями (СУТ). Основными возможностями таких систем являются:
Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS [3], Borland Caliber [4], Polarion Requirements [5] и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.
Как правило, когда принимается решение о внедрении нового инструмента, подразумевается, что у членов команды есть перечень требований к новому ПО, сложившийся из тех проблем, с которыми они столкнулись. Лично мне, когда я была в подобной ситуации, очень не хватало обзорных статей, в которых описывались функциональные возможности инструментов и конкретные ситуации их применения. Поэтому целью данной статьи является описание основных функциональных возможностей системы управления требованиями Axiom.
Я столкнулась с проблемой управления требованиями, когда собирала потребности к готовому программному обеспечению, которое может настраиваться под нужды клиентов. Функциональные возможности этой программы определяют набор требований к ней. Объясню на абстрактном примере. Допустим есть готовая программа, в которой пользователь может:
Первый Заказчик, покупая данное ПО, заявил, что ему нужны все перечисленные функции, но форматы xml и pdf он не знает, платить за эту возможность он не хочет, поэтому сохранять введенный текст он будет только в формате doc. Исходя из этого получаем следующий набор требований для этого Заказчика:
Все возможности ПО | Требования Заказчика 1 |
---|---|
|
|
Второй заказчик сказал, что ему вообще не нужна функция печати текста. У него есть свое ПО, которое отлично распечатывает документы в форматах doc, xml и pdf. Для данного Заказчика перечень требований к ПО содержит:
Все возможности ПО | Требования Заказчика 2 |
---|---|
|
|
А третий Заказчик купил ПО с полным набором функциональных возможностей.
Все возможности ПО | Требования Заказчика 3 |
---|---|
|
|
Это значит, что количество требований к покупаемому продукту, который настраивается под конкретного Заказчика, меньше либо равно количеству функциональных возможностей программы.
В процессе совершенствования качества программы в разы увеличилось количество функциональных возможностей. Как следствие возросло и число требований. Документы технического задания (ТЗ) стали очень громоздкими. Вникать в них как техническим специалистам, так и клиентам, стало намного труднее. Плюс ко всему стало труднее держать такое большое количество возможностей в голове. Увеличилась вероятность упустить какую-либо реализованную функцию.
Из-за сложившейся ситуации я решила попробовать инструмент, в котором было бы возможно описать все требования к ПО. Из полного перечня всех возможных требований, для конкретного проекта должны выбираться те требования, которые отвечают нуждам Заказчика. На основе данного набора инструмент также должен автоматически генерировать документы формата doc, чтобы упрощать задачу формирования Технического задания. Кроме того, необходимо, чтобы в нем можно было определить взаимосвязи между требованием и теми действиями, которые нужно сделать для включения или исключения именно этого требования в ПО.
Попробовав различные СУТ (выбирались в основном бесплатные инструменты из статьи List of Requirements Management Tools [6]), я остановилась на инструменте Axiom компании iConcur [7].
Axiom – это бесплатное кросс-платформенное клиент-серверное приложение управления требованиями.
Необходимо также отметить, что у разработчика имеется и платная версия продукта, с дополнительными возможностями, но все же Axiom позиционируется как бесплатный продукт, так как функциональных возможностей бесплатной версии вполне достаточно для упрощения работы с требованиями.
Итак, почему именно Axiom? Я выбрала данный инструмент, по следующим причинам:
Но остановимся подробнее на основных функциональных возможностях данного продукта.
После авторизации пользователя открывается главное окно инструмента.
Его можно разделить на следующие логические части:
Итак, что такое артефакт? Артефакт – это продукт проекта, порождаемый и/или используемый в нем при работе над программным обеспечением, например, требование, тест кейс и пр. В Axiom данный термин применяется очень активно.
Все объекты, создаваемые пользователем, являются артефактами, и все они будут отображаться в дереве артефактов.
Перечень создаваемых артефактов и сведений, которые будут по ним собираться, определяется самими пользователями инструмента с помощью шаблонов артефактов.
Именно благодаря данной функции инструмент является очень гибким и его можно настроить под различные нужды членов команды.
Что такое шаблон? Шаблон – это набор атрибутов по которому выполняется описание артефакта. Например, для работы нам нужен артефакт Функциональное требование. Функционально требование должно содержать следующие сведения:
Перечисленный выше список представляет собой набор данных (атрибутов), по которому будет выполняться описание всех функциональных требований продукта.
Атрибуты в Axiom могут быть различных типов: это и текстовые поля, и выпадающие списки, с установленными пользователем перечнем значений, и атрибуты-флажки, с помощью которых можно отметить обладает ли артефакт определенным свойством или нет.
Из описанных выше атрибутов Функционального требования логично предположить, что атрибуты «Источник» и «Вопросы» должны быть текстовыми полями, «Статус» и «Приоритет» – выпадающими списками, а информацию о вхождении требования в первую версию продукта можно реализовать флагом. На рисунке ниже представлен пример с реализованным шаблоном Функциональных требований, который назван «Требования».
На основе созданного шаблона можно будет сформировать неограниченное количество артефактов.
Создание самого артефакта происходит следующим образом:
На рисунке ниже представлен результат создания артефакта функционального требования «Ввод текста» на основе шаблона «Требования».
Аналогичным образом можно создавать артефакты на основе других шаблонов. На рисунке ниже создан артефакт настройки программы, содержащий описание действий, которые необходимо выполнить для того, чтобы определенная функциональная возможность была включена в ПО. Данный артефакт создан на основе другого шаблона и поэтому обладает другим набором атрибутов.
Для определения связей между артефактами в Axiom имеется специальный раздел «Linking Surface». В Axiom реализован стандартный шаблон взаимосвязей, на основе которого можно создавать различные типы связей, например, «Связан с», «Невозможно реализовать без», «Родительский элемент для» и пр. Взаимосвязи устанавливаются пользователем вручную в разделе «Linking Surface», путем соединением артефактов выбранным типом связи. На рисунке ниже представлена созданная взаимосвязь функциональных требований и настроек с помощью нового типа связи «Необходимо выполнить».
Данные связи показывают какие настройки необходимо выполнить, чтобы работала та или иная функциональная возможность.
Кроме того, в качестве взаимосвязей могут выступать гиперссылки на другие артефакты, которые можно добавлять в описание к артефакту для дополнительного пояснения.
В Axiom реализована интеграция с MS Word, что позволяет формировать документы, содержащие информацию по созданным артефактам. Данная функциональная возможность предназначена для упрощения формирования таких документов, как Техническое задание (Software Requirements Specification), Видение (Vision) и других проектных документов. Необходимая информация по артефактам уже хранится в Axiom, и пользователю не нужно повторно вводить эти сведения вручную.
После установки Axiom на компьютер в MS Word появляется специальная вкладка «Axiom», с помощью которой пользователь может сформировать шаблон документа. Для этого пользователю необходимо расставить в нужных местах документа ссылки на атрибуты выбранных артефактов. На рисунке ниже создается шаблон документа, содержащего следующие сведения об артефактах:
После этого пользователь может сформировать готовый документ, содержащий все необходимые данные.
Необходимо отметить, что мной была проверена интеграции Axiom только с MS Word версии 2007, 2010. 2013 версия также проверялась, но с ней интеграция не работает.
Таблица артефактов (Artifact Table) – это специальный раздел Axiom для представления набора артефактов в удобном табличном виде.
Одной из удобных функциональных возможностей данного раздела, я считаю изменение атрибута сразу нескольких артефактов. Например, нужно изменить статус сразу у нескольких требований на «Complete».
На мой взгляд, эта возможность значительно ускоряет редактирование артефактов.
Выше были перечислены те основные функциональные возможности Axiom, которые я использовала и нашла очень удобными на текущем этапе внедрения инструмента в процесс работы. Но кроме того, в бесплатной версии Axiom реализованы следующие удобные функции:
Для платной версии также доступны:
Примечание: функциональные возможности платной версии инструмента описаны на основании Руководства пользователя Axiom и не были мной опробованы.
Подводя итоги, хотелось бы перечислить выявленные достоинства и недостатки данного продукта.
БЕСПЛАТНЫЙ. Из опробованных мною бесплатных инструментов данная система самая «приличная». Приятный сайт компании разработчика, простая установка, удобный пользовательский интерфейс. Плюс ко всему для бесплатного инструмента у программы реализовано достаточное количество функциональных возможностей, по крайней мере, для того, чтобы решить мою задачу.
Гибкость инструмента. Благодаря возможности создания самими пользователями шаблонов тех артефактов, которые используются ими при работе, данный инструмент может быть применен в различных проектах.
Простота работы. Во-первых, это интуитивно понятный интерфейс. Во-вторых, у инструмента нет мудреных настроек работы и каких-то дополнительных параметров, как, например, у MS Word раздел меню «Параметры», определяющий важные, но иногда неочевидные аспекты работы с ПО. Дополнительно, Axiom обладает набором бесплатных видео-туториалов [8], которые доступным образом обучают (именно обучают, а не объясняют) пользователя основным возможностям инструмента и дополнительными «фичам», которые могут значительно упростить работу с инструментом.
Кроссплатформенность. Версия 4.0 была доступна для установки только для Windows OS и Linux. В новой версии 4.1 стала доступна установка продукта на Mac OS.
Странная компания. Впервые я встретила упоминание об этой программе на Stack Overflow [9], где «CEO of iConcur Software» Брент Вилсон рекламировал данный продукт. Комментарии к ответу Брента, особенно вот этот: «I tried this product recently and couldn't even log in as the admin. I tried calling, emailing, and opening a support ticket but no response after a week. Is iConcur still alive?» меня удивили. Ну и плюс ко всему техническая поддержка работает действительно странно: иногда отвечает в тот же день, иногда неделями не отвечает, а бывает, что и вовсе молчит. В оправдание компании могу заметить, что недавно вышла новая версия ПО, так что «пациент скорее жив, чем мертв».
Ошибки ПО. Таких ошибок, которые делали бы невозможным работу с продуктом или, например, удаляли результаты часовой работы, я не обнаружила. Были баги связанные с установкой ПО, запуском клиентской части (перед этим нужно перезапустить сервер) или не отображались значки в интерфейсе… Но все же это не очень приятно. С другой стороны, многие из нас работают с MS WORD…
Отсутствие интеграции с MS Word 2013. Это действительно обидно. Потому что данную функциональную возможность я нахожу очень удобной, но она ограничивает меня в выборе версии другого ПО. Но возможно все исправится в следующих версиях.
Лично мне данный инструмент действительно нравится. К сожалению, я не могу описать итоговые результаты его внедрения, так как это, по различным причинам, процесс небыстрый. В любом случае, я считаю, что Axiom может быть полезен даже для простого ознакомления с такими «зверьками» как системы управления требованиями.
Автор: teterevkova
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/58943
Ссылки в тексте:
[1] Пять уровней зрелости требований: http://www.ibm.com/developerworks/ru/library/r-requirements/index.html
[2] Системы управления требованиями: что и зачем?: http://edu.reqcenter.pro/?p=2433
[3] IBM Rational DOORS: http://www-03.ibm.com/software/products/ru/ratidoor
[4] Borland Caliber: http://www.borland.com/products/caliber/
[5] Polarion Requirements: http://www.polarion.com/products/requirements/index.php
[6] List of Requirements Management Tools: http://makingofsoftware.com/resources/list-of-rm-tools
[7] Axiom компании iConcur: http://www.iconcur-software.com/index.html
[8] видео-туториалов: http://www.iconcur-software.com/resources.html
[9] Stack Overflow: http://stackoverflow.com/questions/164938/what-are-some-free-and-or-open-source-requirements-management-tools
[10] Источник: http://habrahabr.ru/post/219439/
Нажмите здесь для печати.