Serena Dimensions RM
Решение Serena Dimensions RM - гибкое и функциональное решение, построенное на WEB технологиях и позволяющее автоматизировать процессы управления требованиями и потребностями как в направлении ИТ разработок, так и в других направлениях деятельности компании.
Задачи по управлению требованиями и работы с ними являются, пожалуй, одними из самых важных на тактическом и стратегическом уровнях работы любой компании. Почему? Да потому, что именно с требования или с потребности обычно начинаются любые изменения в бизнес процессах, информационных системах, услугах, формах документов, организационной структуре и в других важнейших составляющих деятельности любой компании.
Требования не возникают из ниоткуда! Предпосылками изменений может быть всё что угодно:
-
• Изменения в законодательстве (особенно в динамично изменяющейся сфере деятельности кредитных организаций).
• Выводы по результатам анализа работы компании.
• Постоянно изменяющийся рынок: его конъюнктура, предложения конкурентов или просто новые тенденции и тренды.
• Мнения и пожелания клиентов.
• Собственные внутренние инициативы сотрудников.
• Ну и конечно же собственные корпоративные планы развития и прочие предпосылки.
Среди создаваемых информационных потоков сотрудникам компании приходится выявлять действительно важные и потенциально нужные, либо обязательные изменения и затем начинать по ним работу.
Работа может состоять из различных шагов и этапов, а также выполняться с требованиями разного уровня полноты и формализации. Для того, чтобы максимально полно соответствовать реальным процессам, уже существующим или формирующимся в компании в решении Serena Dimensions RM предусмотрено средство простой и гибкой конфигурации (RM Class Definition) собираемой информации, которая может фактически быть представлена требованиями различных типов и уровней.
|
RM Class Manager
|
Графическая диаграмма классов RM Class Manager. Диаграмма позволяет визуализировать связи между информационными объектами, которые хранятся в базе данных. |
|
Окно настройки реквизитов любого объекта базы данных
|
Настройка реквизитов объектов базы данных с требованиями. |
Конфигурируя информационные объекты, в которых будут храниться будущие требования, может быть использован механизм классов и их наследования друг от друга. К базовым классам относятся такие классы как базовый класс, требование, голосование, абзац текста документа и другие. На базе них уже могут создаваться собственные классы. В качестве примеров можно привести наиболее часто создаваемые в наших проектах классы бизнес требований, функциональных и не функциональных требований, спецификаций и другие.
Выполняя смысловое наполнение класса и настраивая его реквизиты, могут быть применены такие типы данных как:
- небольшие текстовые;
- численные, даты;
- файлы-вложения (в одно поле можно вложить 1 файл);
- изображения;
- списки;
- большие текстовые поля с возможностью ввода форматированных данных.
Для каждого поля и для каждого класса может задаваться требуемый уровень доступа. Для полей возможно предоставление права на обновление пользователю или их группе. Для классов предусмотрены такие права доступа как:
- создание объекта класса или запроса на изменение к объекту класса;
- изменение или создание новой версии объекта;
- просмотр, блокировка и разблокировка объекта;
- а также другие специальные привилегии.
|
Окно настройки свойств текстового поля
|
Настройка свойств текстового поля |
|
Настройка свойств одно из системных полей.
|
Настройка свойств системного поля |
У каждого объекта в Dimensions RM есть минимальный жизненный цикл, в котором представлены ключевые состояния типового объекта (см. рис. ниже).
Состояния «Текущее», «Удалённое» и «Заменённое» относятся к самим объектам в базе данных RM. В свою очередь состояния «Предложенный», «Принятый» и «Отклонённый» относятся к запросам на изменение к объектам, хранящимся в базе данных. При принятии запроса на изменение создаётся новая версия объекта RM с учётом принятых в запросе изменений.
Для расширения жизненного цикла любого объекта RM с ним в паре может быть использовано специализированное решение компании Serena по управлению бизнес процессами, которое называется Serena Business Mashups. С ним встроенными средствами выполняется синхронизация объектов баз данных обоих решений.
|
|
Пример части рабочего процесса, построенного в SBM для объекта RM, относящегося к классу Бизнес требование. |
Пользовательский интерфейс RM построен на тонком клиенте и функционирует через обычный интернет браузер. За счёт этого решение может быть использовано конечными пользователями, находящимися практически в любом месте, откуда есть доступ в интернет. Интерфейс построен на основе унифицированной модели и включает рабочие области для эффективной выборки данных, а также гибко настраиваемую область с данными (см. рис. ниже).
Для выборки данных и их эффективного анализа пользователи могут использовать практически произвольно настраиваемые 3 вида отчётов: отчёты по классам, отчёты по связям и отчёты трассировки.
Отчёт каждого из видов может быть создан как самим сотрудником для собственных нужд (при наличии привилегий), так и централизовано администраторами решения. При создании отчётов настраивается набор полей в них, условия для выборки данных, выбираются связи между классами, которые участвуют в выборке данных, параметры сортировки. Отчёты могут создаваться на базе уже имеющихся отчётов с последующим их незначительным изменением.
Отчёты поддерживают динамическую сортировку и перенастройку прямо непосредственно при их использовании. Каждый элемент отчёта является активным и двойной щелчок мыши на нём позволяет получить на экране детальную форму и данными выбранного элемента.
|
Пример отчёта по классам
|
Отчёт выводит перечень объектов определённого класса (классов), выбранных по заданным условиям |
|
Пример отчёта по связям
|
Отчёт выводит перечень объектов и зависимых от них объектов с учётом выбранных связей |
|
Пример трассировочного отчёта
|
Отчёт выводит перечень объектов в дереве и позволяет динамически углубляться или подниматься по иерархии объектов, просматривая детали объекта в правой области |
Детальные формы с информацией, хранящихся в объектах того или иного класса строятся автоматически с использованием принципа группировки данных по отдельным зонам рабочего окна (см. рис. ниже).
Среди зон выделяются зоны с атрибутами, зона файловых вложений, зона комментариев (организованы в виде чата), зона голосований, зона истории версий, зона управления контейнерами, в которых находится объект. Последовательность зон, а также последовательность полей в зонах со стандартными, пользовательскими и системными полями может быть также настроена для объектов различных классов. Проводя изменения в объектах данные могут либо просто изменяться в базе данных, либо может создаваться новая версия объекта. Это решение принимается непосредственно пользователем. Для доступа к данным объекта в любой его предыдущей версии используется раздел «History». (см. рис. ниже).
Безусловно, ни одна существующая информационная система не идеальна и не удовлетворяет сразу всем возможным требованиям всех своих пользователей. В качестве примера приведём небольшое сравнение с одним из игроков рынка систем управления требованиями - решением HP Quality Center (см. таблицу далее).
|
Критерий сравнения |
Mercury Quality Center (HP) (ver 10) |
Dimension RM (Serena) |
|
Возможность трассировки требований (виды: табличный, в виде отчета и т.д.) |
"+" |
"+". В дополнение имеется возможность трассировки не только требований, но ещё и тест кейсов, активов разработки и даже релизов и сборок (при применении решения Dimensions CM). |
|
Возможность построения иерархии требований |
"-". Иерархия типизированных требований отсутствует |
"+" |
|
Возможность установление связи между требованиями (насколько наглядно и удобно) |
"+" |
«+/-». Выполняется только через раздел Links в деталях объекта. Ввиду применения тонкого клиента полнофункциональные механизмы Drug-and-Drop не реализованы. |
|
Возможность связывания требований из разных проектов |
"-" |
"-/+". Возможно. Однако для этого будет необходимо специальным образом организовать данные и разграничить уровни доступа на базе категорий |
|
Возможности отслеживания изменений в требованиях (инструменты: внешний вид, отчеты т.д.) |
"+/-" |
"+/-" |
|
Возможность расширения числа аттрибутов требований |
"+" |
"+" |
|
Возможность отмены требований |
"+" |
"+/-". Статус не является системным по умолчанию, однако может быть добавлен) |
|
Возможность изменения процесса прохождения состояний требования (настройка прохождения статусов у требований) |
"-/+". Ручное изменение поля статус. |
"+". Возможность как создания собственного поля состояний, так и прямой интеграции с Serena Business Mashup. |
|
Возможность отслеживания реализации требований |
"-". Только ручным способом через специальные поля. |
"-/+". В комбинации с Dimensions CM либо ручным способом через специальные поля. |
|
Наличие контроля версий требований |
"+" |
"+/-". В текущей версии RM не сохраняются версии связей на другие объекты в RM |
|
Возможность работы с Word и Excel (экспорт/импорт) |
"+" (экспорт есть, импорт из Excel есть) |
"+" |
|
Возможность настройки внешнего вида и структуры генерируемых документов |
"-". Существует предопределенный набор шаблонов |
"-/+". Возможность выбора местонахождения объектов одного типа в генерируемом по шаблону документе. Объекты представляются в виде таблицы-перечня. |
|
Наглядность и овсваиваемость продукта (от 1 до 5) |
"2". Для написания требований достаточно прост в освоении |
“3”. RM является более сложным и менее интуитивным, чем HP QC. |
|
Возможность создания среза всех требований (на дату в прошлом) |
"+" |
"+" |
|
Возможность сравнения срезов требований |
"+” |
"+" |
|
Интеграция с другими системами (тестирование (Quality Center), управление изменениями (PVCS), планирование проектов (MS Project) и т.д.) |
только с (Quality Center) |
Интеграция с HP QC для тестирования, Dimencions CM для конф. управления, Serena Business Mashups для процессного управления и MS Project |
|
Сложность разворачивания, поддержки и разграничения доступа в системе (сервер, сотрудники и т.д.) |
Не сложно |
Не сложно |
|
Гибкость настройки распределения пользователей по ролям и частям workflow для требований |
Достаточно просто |
Достаточно просто |
|
Наличие русификации |
Требования можно вести на русском языке, интерфейс на английском языке |
Требования можно вести на русском языке, интерфейс на английском языке |
|
Возможность авторизации через Active Directory |
"+" |
Имеется поддержка LDAP |
|
Наличие "толстого" клиента |
"+/-". По сути решение реализовано на толстом клиенте, устанавливаемом через браузер прозрачно от пользователя. |
Полностью тонкий клиент для конечных пользователей и толстый клиент для администраторов. |