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

No notes for slide

Цель создания системы

Пожелания предназначены для сбора и документирования пользовательских требований, хотелок и заявок.
В бизнес-требованиях задокументированы требования маркетинга, внешних регуляторов, результаты обследования бизнес-процессов заказчика, они хранятся в виде документов, импортированных из MSWord.
Требования или системные требования описывают требования к системе, могут быть задокументированы в форматах вариантов использования, прецедентов, технического задания и других.
Доработки позволяют детализировать системные требования и запланировать их реализацию как целиком, так и частями, например, "реализовать требование, за исключением альтернативных сценариев 4 и 5"
Функции позволяют сгруппировать доработки, например, по функциональным подсистемам или модулям, с целью более удобного контроля за ходом реализации требуемой функциональности.

1. Используйте этот процесс, если:
-вы можете сесть с заказчиком (или его представителем) в одной комнате и делать это каждый спринт
-требования часто уточняются, дополняются и меняются
-требования заказчика достаточно конкретны, полны и понятны, что ваша команда может сразу приступить к их реализации
-вам не требуется целостное и согласованное описание системы
2. В отличие от "Пользовательских истории в Scrum" используйте этот процесс, если:
-процесс разработки требует предварительного анализа и проектирования, создания поведенческих моделей или моделей данных
-в разработку системы вовлекаются новые участники, которым необходимо понимание внутреннего устройства системы
3. Используйте этот процесс, если:
-перед реализацией необходимо собрать согласованный, полный, непротиворечивый набор требований
-контролировать полноту реализации требований пользователей при помощи матрицы трассировок
-необходимо собрать требования с целью получения оценки стоимости проекта, подписать контракт на основе технического задания
-требуется одновременно поддерживать несколько версий продукта, то есть несколько версий функциональных требований.

Разработка требований с вовлечением всех участников команды, начиная с самых ранних этапов жизненного цикла продукта
Изменение текста в один клик
Все виды форматирования
Автоматические уведомления об изменениях: журнал изменений, почтовые нотификации

Фиксация технических решений в форме фотографий, скриншотов, UML-моделей и формул, с автоматической нотификацией об изменениях.

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

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

Разработка моделей осуществляется при помощи специально разработанного языка PlantUML. При помощи крайне простого синтаксиса вы можете быстро создавать UML-модели требуемого типа.

Формирование библиотеки шаблонов и требований для повторного использования в проектах.
Вставка требования в несколько документов
Сохранение типовой структуры документа в шаблоне.

К повторно используемым требованиям чаще всего относятся:
Элементы глоссария, относящиеся к общей проблемной области.
Бизнес правила, распространяющиеся на всю организацию, в бизнес-процессах которой используется несколько программных продуктов.
Требования различных регуляторов, требования на соответствие стандартам.
Модели общей предметной области, сущности и атрибуты.

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

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

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

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

При создании доработки сохраняется ссылка на выбранный бейзлайн или версию требования

Сбор и визуализация метрик для анализа проблем и повышения продуктивности

Реестр требований позволяет работать с требованиями вне зависимости от их расположения в различных документах. Группируйте требования по типам, тэгам, состояниям и другим атрибутам. Выполняйте массовые операции сразу над несколькими требованиями.
Используйте реестр требований как матрицу трассировки для получения ответов на вопросы:
-все ли необходимые системные требования запланированы в работу;
-в какой версии и как реализуются системные требования;
-как проверяются требования тестировщиками;
-каким образом документируются требования.

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

Программное обеспечение эволюционирует, требования непрерывно меняются. Тестировщикам необходимо поддерживать тестовую документацию в актуальном состоянии, чтобы тестирование получилось качественным.
Обычно тестировщики не очень рады изменениям в требованиях, потому что для них это выливается в большой объем дополнительной работы:
Необходимо изучить требования от предыдущей версии, изучить новые требования, выделить изменения в требованиях и внести соответствующие изменения в тестовую документацию.
Нужно найти все тестовые сценарии, которых коснулись изменения в требованиях, и исправить их.
При использовании Devprom ALM эти проблемы уходят, поскольку в системе хранятся все версии требований и любой участник команды может просмотреть историю изменений, чтобы выяснить что конкретно поменялось.
Более того, система автоматически сохраняет связи между проектными артефактами, например, между требованиями и тестовой документацией. Когда требование изменится, система отметит покрывающие его тестовые сценарии как неактуальные. Вам останется только отфильтровать неактуальные тестовые сценарии и перейти к их редактированию. Система отобразит изменения, которые были внесены в требования, а вам останется только подправить соответствующие тестовые сценарии.

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

Компания Atlassian предлагает семейство продуктов: Jira, Jira Agile, Confluence, Jira ServiceDesk, Jira Portfolio, FishEye, которые в сумме будут стоить более $16000 для 40 пользователей. При этом в этих продуктах нет поддержки версионирования проектной документации и трассировки проектных артефактов.

Компании Polarion Software и Intland предлагают хорошие, но дорогие ALM-решения без поддержки русского языка, без русскоязычной поддержки.

Компания Jama Software предлагает чрезмерно дорогой продукт, предоставляющий функциональность схожую с функциональностью Devprom ALM в части управления требованиями, однако, без поддержки русского языка и без русскоязычного обучения и поддержки.

Широко распространённый в РФ Microsoft TFS имеет сильные стороны только в части автоматизации сборки и тестирования продуктов, написанных средствами от Microsoft. При этом нет практически никаких средств работы с проектной документацией, управления ресурсами.

Русскоязычная поддержка, индивидуальные консультации в области процессов, практик и использования ПО в конкретных проектах.
Локализация современных практик и методологий под особенности производства ПО в РФ.
Обмен опытом, полученном при работе с российскими компаниями разработчикам ПО.
Русскоязычный интерфейс системы, с возможностью переключения на англоязычный интерфейс.
Стоимость лицензий и поддержки в рублях, значительно ниже стоимости зарубежных аналогов.
Низкая стоимость владения за счет использования «железа» уровня рабочей станции и свободно-распространяемого промежуточного ПО.