Введение При работе с требованиями можно использовать различные методы их организации: от метода полного хаоса до интеграции требований с программным кодом (статья Пять уровней зрелости требований ).
Постепенно совершенствуя работу с требованиями, обычно в процесс начинают внедрять различные новые методологии и инструменты.
Одним из классов инструментов, предназначенных для упрощения работы с требованиями, являются специально обученные «животные»: системы управления требованиями (RMS).
Основными возможностями таких систем являются:
- Создание единицы управления проектом проще, чем целый документ (требование).
Прочитать и подтвердить одно требование гораздо проще, чем согласовать всю Техническую спецификацию.
- Указание связей между требованиями.
Эта возможность позволяет отслеживать изменения в связанных требованиях.
Те.
если что-то изменилось, то система может выделить все элементы, связанные с изменением, как подозрительные на изменение.
- Выбор представления набора взаимосвязанных требований.
При наличии большого количества требований иногда необходимо представить полную картину их взаимосвязи.
Кому-то удобнее просматривать эту информацию в виде таблицы (матрицы трассировки), кому-то – в виде иерархического дерева, кому-то – в виде сетевых графиков (статья Системы управления требованиями: что и зачем? ).
Такие системы обычно хорошо зарекомендовали себя, но дороги.
Однако среди этого списка есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» вроде Axiom.
Цель статьи
Обычно, когда принимается решение о внедрении нового инструмента, предполагается, что у членов команды есть список требований к новому программному обеспечению, основанный на проблемах, с которыми они столкнулись.Лично я, оказавшись в подобной ситуации, очень скучал по обзорным статьям, в которых описывался функционал инструментов и конкретные ситуации их использования.
Поэтому целью данной статьи является описание основного функционала системы управления требованиями Axiom.
Суть проблемы
С проблемой управления требованиями я столкнулся при сборе требований к готовому программному обеспечению, которое можно настроить под нужды клиентов.Функциональность данной программы определяет набор требований к ней.
Поясню на абстрактном примере.
Допустим, есть готовая программа, в которой пользователь может:
- Введите текст в текстовое поле;
- Сохраните введенный текст в форматах doc, xml и pdf;
- Распечатайте введенный текст.
Исходя из этого, получаем следующий набор требований к данному Заказчику:
Все возможности программного обеспечения | Требования заказчика 1 |
---|---|
|
|
Имеет собственное программное обеспечение, которое прекрасно печатает документы в форматах doc, xml и pdf. Для данного Заказчика перечень требований к программному обеспечению содержит:
Все возможности программного обеспечения | Требования клиентов 2 |
---|---|
|
|
Все возможности программного обеспечения | Требования клиентов 3 |
---|---|
|
|
В процессе улучшения качества программы количество функционала значительно увеличилось.
В результате возросло и количество требований.
Документы технических условий (ТЗ) стали очень громоздкими.
И техническим специалистам, и клиентам стало гораздо сложнее их понять.
Плюс стало сложнее держать в голове такое большое количество возможностей.
Вероятность отсутствия какой-либо реализованной функции возросла.
Из-за сложившейся ситуации я решил попробовать инструмент, в котором можно было бы описать все требования к программному обеспечению.
Из полного списка всех возможных требований необходимо выбрать те требования, которые удовлетворяют потребностям Заказчика для конкретного проекта.
На основе этого набора инструмент также должен автоматически генерировать документы в формате doc, чтобы упростить задачу формирования технического задания.
Кроме того, необходимо, чтобы можно было определить связь между требованием и действиями, которые необходимо предпринять для включения или исключения этого конкретного требования в программном обеспечении.
Попробовав различные SUT (выбирались в основном бесплатные инструменты из статьи) Список инструментов управления требованиями ), я остановился на инструменте Аксиома iConcur .
Аксиома
Axiom — это бесплатное кроссплатформенное приложение для управления требованиями клиента/сервера.Также следует отметить, что у разработчика есть и платная версия продукта, с дополнительными возможностями, но Axiom по-прежнему позиционируется как бесплатный продукт, поскольку функционал бесплатной версии вполне достаточен для упрощения работы с требованиями.
Так почему же Аксиома? Я выбрал этот инструмент по следующим причинам:
- Бесплатно программное обеспечение;
- Гибкость инструмента (возможность настройки работы с инструментом в зависимости от особенностей конкретной компании или проекта);
- Простота инструмента;
- Возможность генерировать документы на основе данных, хранящихся в инструменте.
Первое знакомство с Аксиомой
После авторизации пользователя открывается главное окно инструмента.
Его можно разделить на следующие логические части:
- Панель инструментов и меню (вверху);
- Дерево артефактов (в левой части окна; что такое артефакт, будет описано ниже);
- Окно редактирования информации об артефакте (посередине);
- Вспомогательные разделы (вид), расположенные справа и снизу.
Все объекты, созданные пользователем, являются артефактами, и все они появятся в дереве артефактов.
Список создаваемых артефактов и информация, которая будет из них собираться, определяется самими пользователями инструмента с помощью шаблонов артефактов.
Создание шаблонов артефактов
Именно эта функция делает инструмент очень гибким и его можно настроить в соответствии с различными потребностями членов команды.Что такое шаблон? Образец – это набор атрибутов, которыми описывается артефакт. Например, для работы нам нужен артефакт Functional Requirement. Функциональное требование должно содержать следующую информацию:
- Название («Сохранение документа», «Добавление кнопки в интерфейс», «Передача данных»);
- Описание (например: Система должна сохранить документ при нажатии кнопки «ОК»);
- Источник требования, т.е.
лицо, его озвучившее;
- Вопросы, возникающие при обсуждении данного требования;
- Статус запроса, например, «Одобрено», «Согласовано», «Рассмотрено», «Отклонено» и т. д.
- Приоритетность, т.е.
насколько важно реализовать это требование.
- Информация о том, будет ли данное требование реализовано в первой версии продукта.
Атрибуты в Axiom могут быть разных типов: это текстовые поля, раскрывающиеся списки с определяемыми пользователем списками значений и атрибуты-флаги, которые можно использовать для указания того, имеет ли артефакт определенное свойство или нет. Из описанных выше атрибутов Функционального требования логично предположить, что атрибуты «Источник» и «Проблемы» должны быть текстовыми полями, «Статус» и «Приоритет» — раскрывающимися списками, а информация о включении требования в первой версии продукта можно реализовать с помощью флага.
На рисунке ниже показан пример с реализованным шаблоном Функциональных требований, который называется «Требования».
На основе созданного шаблона можно будет генерировать неограниченное количество артефактов.
Создание Артефакта
Само создание артефакта происходит следующим образом:- В дереве артефактов вы выбираете узел (группу артефактов), которому принадлежит данный артефакт;
- Затем вам необходимо выбрать шаблон, на основе которого будет создан артефакт;
- Задайте имя артефакта (Name);
- И отредактируйте его атрибуты и описание.
Аналогичным образом вы можете создавать артефакты на основе других шаблонов.
На рисунке ниже создан артефакт конфигурации программы, содержащий описание действий, которые необходимо выполнить для включения в программу определенного функционала.
Этот артефакт создан на основе другого шаблона и, следовательно, имеет другой набор атрибутов.
Отношения между артефактами
Для определения связей между артефактами в Axiom есть специальный раздел «Linking Surface».В Аксиоме реализован стандартный шаблон отношений, на основе которого можно создавать различные типы связей, например, «Связано с», «Невозможно реализовать без», «Родительский элемент для» и т.д. Отношения задаются пользователем вручную.
в разделе «Связывание поверхности», соединив артефакты по выбранному типу соединения.
На рисунке ниже показана связь между функциональными требованиями и настройками, созданными с использованием нового типа связи «Необходимо выполнить».
Данные связи показывают, какие настройки необходимо выполнить для работы той или иной функции.
Кроме того, связи могут представлять собой гиперссылки на другие артефакты, которые можно добавить к описанию артефакта для дополнительных пояснений.
Интеграция с MS Word
Axiom имеет интеграцию с MS Word, что позволяет создавать документы, содержащие информацию о созданных артефактах.Эта функция предназначена для упрощения создания таких документов, как спецификация требований к программному обеспечению, концепция и другие проектные документы.
Требуемая информация об артефакте уже хранится в Axiom, и пользователю не нужно повторно вводить эту информацию вручную.
После установки Аксиомы на компьютер в MS Word появляется специальная вкладка «Аксиома», с помощью которой пользователь может создать шаблон документа.
Для этого пользователю необходимо разместить ссылки на атрибуты выбранных артефактов в нужных местах документа.
На рисунке ниже создан шаблон документа, содержащий следующую информацию об артефакте:
- Имя;
- Идентификационный номер (ID);
- Описание нефункционального требования (Содержание).
После этого пользователь может сформировать готовый документ, содержащий все необходимые данные.
Следует отметить, что я тестировал интеграцию Axiom только с MS Word версии 2007, 2010. .
Версия 2013 года также тестировалась, но с ней интеграция не работает.
Таблица артефактов
Таблица Артефактов — специальный раздел Аксиомы для представления набора артефактов в удобной табличной форме.
Одним из удобных функционалов этого раздела я считаю изменение атрибута сразу нескольких артефактов.
Например, вам необходимо изменить статус сразу нескольких требований на «Выполнено».
На мой взгляд, эта функция значительно ускоряет редактирование артефактов.
Кроме
Выше перечислены основные функциональные возможности Axiom, которые я использовал и нашел очень удобными на текущем этапе внедрения инструмента в рабочий процесс.Но кроме того, бесплатная версия Axiom включает в себя следующие удобные возможности:
- Обсуждения.
Пользователи могут обсуждать артефакты и получать отзывы, используя специальный раздел «Обсуждение»;
- Администрирование пользователей.
Эта функция позволяет создать нового пользователя и определить его логин и пароль.
К сожалению, в текущей версии продукта реализованы только 2 роли пользователя: администратор, который может всё, и простой «смертный» пользователь, который может только просматривать артефакты.
- Просматривайте историю версий артефактов и атрибутов разных версий с помощью раздела «История».
- ?Экспортировать сгенерированные данные в формат xml, xls.
- Язык правил аксиом.
Функциональность, которую лично мне было бы интересно попробовать.
В чем его суть? iConcur создал собственный язык описания требований, чтобы исключить двусмысленность в их понимании.
Кроме того, создан редактор, проверяющий правильность написанного требования.
На рисунке ниже показан наглядный пример требования, написанного на этом языке.
- Прототипирование интерфейса.
Платная версия Axiom имеет встроенный редактор прототипов.
Созданные интерфейсы также считаются артефактами и могут быть связаны с другими артефактами.
- Просмотрите матрицу трассировки требований, используя специальный раздел «Матрица связей».
Этот раздел позволяет просматривать связи между артефактами в табличной форме, как показано на рисунке ниже.
- Просмотрите иерархическое дерево связей артефактов (Дерево связей).
Общий
Подводя итог, хотелось бы перечислить выявленные преимущества и недостатки данного продукта.
плюсы
БЕСПЛАТНО.Из бесплатных инструментов, которые я пробовал, эта система самая «достойная».
Красивый сайт компании-разработчика, простая установка, удобный интерфейс.
Плюс, для бесплатного инструмента программа имеет достаточный функционал, как минимум для решения моей проблемы.
Гибкость инструмента.
Благодаря возможности пользователей создавать шаблоны для артефактов, которые они используют в своей работе, этот инструмент можно использовать в различных проектах.
Простота эксплуатации.
Во-первых, это интуитивно понятный интерфейс.
Во-вторых, инструмент не имеет сложных настроек работы и каких-либо дополнительных параметров, как, например, в MS Word есть раздел меню «Параметры», определяющий важные, но порой не очевидные аспекты работы с программой.
Кроме того, Axiom имеет набор бесплатных видеоуроки , которые обучают (именно обучают, а не объясняют) пользователя основным возможностям инструмента и дополнительным «возможностям», которые позволяют существенно упростить работу с инструментом в доступной форме.
Кроссплатформенность.
Версия 4.0 была доступна для установки только для ОС Windows и Linux. В новой версии 4.1 стала доступна установка продукта на Mac OS.
Минусы
Странная компания.Впервые я встретил упоминание об этой программе на Переполнение стека , где «генеральный директор iConcur Software» Брент Уилсон рекламировал продукт. Комментарии к ответу Брента, особенно к этому: «Я недавно попробовал этот продукт и даже не смог войти в систему как администратор.
Я пробовал звонить, писать по электронной почте и открывать заявку в службу поддержки, но через неделю ответа не последовало.
iConcur еще живЭ» Я был удивлен.
Ну и ко всему прочему техподдержка работает вообще странно: иногда отвечает в тот же день, иногда не отвечает неделями, а иногда вообще молчит. В оправдание компании могу отметить, что недавно вышла новая версия программного обеспечения, так что «пациент скорее жив, чем мертв».
Программные ошибки.
Я не нашел ошибок, которые сделали бы невозможным работу с продуктом или, например, удалили результаты часовой работы.
Были баги, связанные с установкой ПО, запуском клиентской части (перед этим нужно перезагрузить сервер) или не отображались иконки в интерфейсе.
Но всё равно это не очень приятно.
С другой стороны, многие из нас работают с MS Word. Отсутствие интеграции с MS Word 2013. Это действительно позор.
Потому что считаю этот функционал очень удобным, но он ограничивает меня в выборе версии другого ПО.
Но возможно всё будет исправлено в будущих версиях.
P.S.
Лично мне это средство очень нравится.К сожалению, я не могу описать окончательные результаты ее реализации, поскольку по разным причинам это медленный процесс.
В любом случае, я считаю, что Axiom может быть полезен даже для простого знакомства с такими «животными», как системы управления требованиями.
Теги: #управление требованиями #управление требованиями #системы управления требованиями #аналитика #сущность #Аксиома #Анализ и проектирование систем
-
Самые Выгодные Картриджи Canon Pg-510
19 Oct, 24 -
Paypal И Почта России.
19 Oct, 24 -
Pagodabox — Облачный Хостинг Php-Проектов
19 Oct, 24 -
It-Стартапы: Кто «Ест» Венчурные Инвестиции
19 Oct, 24 -
Бета-Тест Леопарда
19 Oct, 24