Меню

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



Системы управления требованиями: TopTeam Analyst

Прежде чем приступить непосредственно к обзору TopTeam Analyst, хотелось бы сказать пару слов о requirements management systems (системы управления требованиями). Многим будет полезно узнать, что на рынке IT анализа данная категория программного обеспечения уже давно нашла свою нишу. Все же, несмотря на это, количество компаний, активно использующих подобные системы для поддержки процесса работы с требованиями, в Беларуси мало. Среди причин можно выделить следующие:

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

Итак, что же такое RMS (requirements management systems/tools/software) и с чем их едят?

RMS – это средства поддержки и автоматизации процесса работы с требованиями на протяжении всего жизненного цикла разработки программного продукта. Такие инструменты, в своей минимальной комплектации, являются аналогом таск- и баг-трекинг систем (Microsoft Team Foundation Server или Atlassian Jira), при условии, что мы будем рассматривать «требование» как аналитический аналог задач, багов и других подобных Work Items. Дополнительные возможности варьируются от расширенной поддержки трассируемости (traceability) требований, до генерации спецификаций (в .doc, .rtf, HTML и др. форматах) и визуального моделирования. Некоторые из таких систем полностью покрывают аналитический аспект процесса разработки и даже навязывают свои методики (процессы) работы с требованиями.

Наиболее известные системы управления требованиями на данный момент – Borland CaliberRM, IBM Rational DOORS и Rational RequisitePro, Case Complete. Также — правда условно — сюда можно отнести Sparx Enterprise Architect, который, являясь по большей части инструментом для UML моделирования, все же предоставляет некоторые возможности для работы непосредственно с требованиями.

В данной статье речь пойдет об одной из альтернатив громоздким и не всегда удобным «монстрам» RMS: TopTeam Analyst от TechnoSolutions (http://www.technosolutions.com/). Сразу стоит отметить, что система, по сути, состоит из двух отдельных компонентов – Net Client Tool (клиентская часть) и Application Server (серверная часть). Это абсолютно логично и обусловлено тем, что все подобные системы работают по концепции централизованного репозитория данных. Соответственно, серверная часть разворачивается единовременно на выделенном сервере, а клиентский модуль должен быть установлен на каждой клиентской машине. Стоит отметить, что более мощные системы, например CaliberRM, имеют дополнительную возможность работы через веб-интерфейс. В TopTeam Analyst же такую возможность обнаружить не удалось.

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

Новые проекты создаются с использованием Quick либо Advanced Wizard. Advanced Wizard, в отличие от Quick Wizard, попросит вас указать имя проекта, выбрать проектного менеджера из созданных заранее пользовательских аккаунтов, выбрать участников проекта и настроить элементы работы с требованиям на проекте: работу с вариантами использования, тест кейсами, глоссарием и т.д.

В процессе работы над проектом TopTeam Analyst позволяет следующее:

1) Хранение и управление требованиями. Требования представлены довольно удобно, в виде дерева по иерархии, и основываются на типах требований, которые задаются администратором при конфигурации системы. В связи с этим, никто не мешает настроить связку Business requirement -> User requirement -> Functional + Non-functional requirements + Business Rules + Use Cases и т.д., и, как следствие, иметь вполне сносное дерево требований разных уровней. Для каждого требования имеется возможность заполнить большое количество как полезных , так и не очень атрибутов: версия, статус, источник, приоритет, итерация и т.п. Также можно назначить на работу над требованием определенного участника проекта, что отразится в его разделе Dashboard , который представляет список ваших задач, встреч и т.д. При работе над текстом требования имеется возможность использовать встроенный WYSIWYG-редактор, который, конечно, гораздо слабее MS Word, но все же позволяет довольно сносно отформатировать текст. Также имеется встроенная история, позволяющая отслеживать любые изменения в требовании.

Отдельно стоит отметить Traceability Matrix, которая позволяет взглянуть на требования в разрезе их взаимосвязи друг с другом. Данный функционал уже зарекомендовал себя в Sparx Enterprise Architect. Стоит отметить, что в TopTeam Traceability Matrix реализована на порядок приятнее и мощнее, чем в EA.
Также присутствует возможность выстраивать baselines требований по итерациям, релизам и т.д. и использовать довольно удобные средства сравнения baselines.

2) Глоссарий. Глоссарий позволяет хранить список терминов, использующихся в проекте. Также содержит встроенный spell checker (вроде бы, с поддержкой только английского языка) и позволяет разбивать термины на категории.

Читайте также:  Сравнение радиаторов vogel noot

3) Разработка вариантов использования. TopTeam предлагает очень неплохую поддержку управления вариантами использования и актерами. Для вариантов использования можно задавать практически все возможные атрибуты и описания. Также имеется встроенная возможность создать и отредактировать UML activity diagram для сценариев варианта использования.

4) Общение между участниками проекта. Данный пункт реализован «на ура». TopTeam позволяет создавать встречи наподобие MS Outlook и высылать приглашения участникам. Также имеется возможность обмениваться внутренней перепиской + есть встроенный Instant Messenger. Все это затем легко отслеживается в inbox. Однако, самая полезная, на наш взгляд, возможность – это встроенные форумы обсуждения требований, вариантов использования и других элементов проекта.

5) Моделирование. Из того, что было замечено: система позволяет строить неплохие контекстные диаграммы, диаграммы вариантов использования на основе заранее заданных use cases и actors (принцип и процесс построения диаграмм приятен и нареканий к нему нет), диаграммы навигации между экранами интерфейса, UML State и Activity диаграммы, а также free-form диаграммы (к сожалению, набор элементов для рисования маловат и с MS Visio абсолютно не сравнится).

6) Своеобразное моделирование пользовательских интерфейсов. Заметим, что TopTeam, видимо, не позволяет рисовать с нуля красивые эскизы. Вместо этого TopTeam позволяет снимать скриншоты (причем есть возможность скриншотить области экрана наподобие того, как это позволяет SnagIt) и заливать свои картинки. Все эти элементы привязываются к требованиям, и с помощью контролов Button и Text field в прототипы можно внести интерактивность.

7) Возможность создания и отправки на членов проекта issues, change requests, problem reports и др. В целом, если правильно настроить и организовать участие заказчика в использовании TopTeam (например, участие в обсуждениях, процесс review требований и т.д., наряду с классической отправкой CR и проблем), то можно добиться очень впечатляющих результатов в плане удобства организации рабочего процесса.

Вердикт:
Кроме вышеупомянутых возможностей, TopTeam Analyst предоставляет еще целый ряд приятных и весьма полезных вещей, на обзор и перечисление которых ушло бы еще около десятка страниц. Поэтому в данной статье были отмечены только основные возможности инструмента. Они не могут не удивлять, учитывая размеры инсталляционных пакетов – 32 Мб для Net Client Tool и 16 Мб для Application Server (для сравнения Borland Caliber «весит» около 600 Мб). Познакомиться с триальной версией TopTeam Analyst поближе можно по следующей ссылке: http://www.technosolutions.com/TTAnalystTrialReg.html
Цена системы довольно «кусачая» – 895$ за клиентское рабочее место. Однако, это не удивительно, учитывая, сколько всего данный инструмент предоставляет для проектной команды. TopTeam Analyst – довольно удобный, очень мощный и всеохватывающий инструмент, который будет весьма неплохим выбором для средних и больших проектных команд, при условии, что команда выиграет от использования RMS в принципе.

Оценка по пятибалльной шкале: 4.5

Источник

WEBURSITET.RU

Онлайн-курсы профессиональной разработки ПО

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

На просторах интернета периодически появляются статьи, сравнивающие возможности программных инструментов для управления требованиями по разным критериям. Я одно время коллекционировал ссылки на эти статьи, но довольно скоро выяснилось, что они очень быстро утрачивают свежесть. Одни продукты уходят с рынка, другие появляются. «Протухают» сами ссылки, переставая ссылаться. Но самое главное: стремительно изменяются представления о том, как должна выглядеть и что должна уметь система управления требованиями (СУТ), и поэтому устаревают критерии оценки, которые казались актуальными авторам этих статей.

Часто сравнительные обзоры инструментов работы с требованиями представляют компании, разрабатывающие или распространяющие такие системы. По понятным причинам они всегда выглядят однобоко. Производители и дистрибьюторы перетасовывают списки критериев так, чтобы выставить свой продукт в выгодном свете и затушевать преимущества конкурентов. Почти всегда эти обзоры представляют собой таблицы, в которых зелёные галочки, отмечающие поддержку возможностей, полностью заполняют только одну колонку. Представляющую, конечно же, «свой» продукт.

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

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

х, сам термин «управление требованиями» понимается всеми . Определения, которые даются в разных сводах знаний, довольно расплывчаты и допускают разные толкования. В моём понимании, управлять требованиями можно в узком смысле и в широком.

Читайте также:  Степень сравнения прилагательного safe

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

Управление требованиями в широком смысле — это процесс, пронизывающий всю разработку продукта. Программирование, тестирование, документирование, испытания, внедрение — всё это должно выполняться на основе требований, и жизненные циклы этих процессов порождают те статусы требований, которые не относятся к их разработке.

Система управления требованиями должна поддерживать управление и в узком, и в широком смысле. В таблице критериев я разнёс соответствующие возможности по разделам «Разработка требований» и «Управление требованиями».

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

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

Адаптируется ли она под процессы, уже сложившиеся в компании, или, наоборот, требует подстройки или даже ломки процессов под себя.

Насколько удобно её использовать людям, использующим требования, а не только разрабатывающим их. Или, другими словами, добавляет им система новой работы или, наоборот, уменьшает её объём.

Если СУТ не соответствует их интересам, то она с большой вероятностью будет отторгнута компанией. Люди просто не станут её использовать.

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

А вот и сама таблица.

Возможность

Описание

Разработка требований

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

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

Типизация и шаблонизация требований

СУТ должна обеспечивать возможность создания требований различных типов из настраиваемых шаблонов. Для этого в ней должны быть реализованы:

классификация типов требований;

управление шаблонами требований (настройка шаблонов для каждого типа требований).

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

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

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

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

Трассировка требований друг на друга

СУТ должна поддерживать связи между требованиями. Должен поддерживаться настраиваемый набор видов связей.

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

Читайте также:  Samsung galaxy j3 сравнить samsung galaxy j3 2016

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

Графическое моделирование требований

СУТ должна поддерживать возможность разработки требований в виде визуальных моделей (например, моделей UML и моделей ).

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

Согласование требований с клиентами

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

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

Хранение первичных документов с требованиями

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

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

Экспорт сводных документов требований

СУТ должна поддерживать экспорт наборов требований, отобранных по различным критериям, в виде файлов, основанных на шаблонах.

Эта возможность необходима в тех случаях, когда стандарты разработки требуют создания таких документов (например, если процесс должен соответствовать ГОСТу), или если на определённых этапах создания продукта требования должны быть представлены в виде сводных документов — например, как приложения к договорам.

Управление требованиями

СУТ должна поддерживать ведение версий каждого отдельного требования.

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

СУТ должна поддерживать ведение нескольких вариантов отдельных требований.

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

Управление статусами требований

В СУТ должен быть реализован настраиваемый набор статусов требований, отражающий их жизненный цикл в рамках компании. Должна быть возможность управления жизненным циклом как требования в целом, так и конкретной версии требования.

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

Если в компании используются автоматизированные инструменты для управления этими процессами, то эта возможность реализуется в рамках интеграции с этими инструментами.

Трассировка требований на рабочие продукты

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

Под рабочими продуктами, в частности, понимаются:

рабочие продукты тестирования — тесты, тестовые планы

Управление задачами, связанными с требованиями

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

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

Управление базовыми линиями (baseline) требований

СУТ должна поддерживать управление базовыми линиями требований. Должна быть возможность отнесения к выбранной базовой линии конкретных версий отдельных требований, в том числе с использованием групповых операций. Кроме того, для управления базовыми линиями в СУТ должны быть реализованы отчёты, позволяющие оценивать состояние базовых линий по различным критериям.

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

Приживаемость системы

Удалённый многоплатформенный доступ

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

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

Интеграция с используемыми в компании инструментами

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

Интеграция предполагает настраиваемый автоматический двусторонний обмен данными с этими инструментами.

Источник