Система управления требованиями Devprom alm 3.5
•Download as PPTX, PDF•
2 likes•682 views
Современный web-инструмент для разработки и управления требованиями Совместное создание полноценных документов требований из браузера Обсуждение и рецензирование требований всей командой Документирование UML-моделей, формул и алгоритмов Версионирование и трассировка требований на проектные артефакты Разработка, тестирование и документирование основанные на требованиях Загрузка и выгрузка требований в формате Microsoft Word Полностью настраиваемый процесс работы над требованиями Сбор и визуализация метрик для анализа проблем и повышения продуктивности
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Система управления требованиями Devprom alm 3.5
Similar to Система управления требованиями Devprom alm 3.5 (20)
Система управления требованиями Devprom alm 3.5
- 1. Система поддержки процессов разработки ПО Devprom ALM Разработка и управление требованиями Савицкий Евгений evgeny.savitsky@devprom.ru http://devprom.ru
- 2. Содержание • Основные понятия • Модель системы • Поддерживаемые процессы разработки • Разработка требований • Управление требованиями • Управление изменениями • Варианты использования • Конкурентный анализ • Ключевые преимущества
- 4. Документация Модель Devprom ALM Проект Релиз Сборка Требование Доработка/ История Функция Задача Итерация Портфель Управление проектом Управление продуктом Тестовый сценарийИсходный код
- 5. Процессы разработки • Пользовательские истории в Scrum или Kanban • Легковесные требования в Scrum или Kanban • Разработка основанная на системных требованиях
- 9. Импорт и экспорт • Печать требований • HTML, PDF, Excel • Двусторонняя интеграция с MSWord
- 11. Версии и бейзлайны • Журнал изменений/согласований • Фиксированные требования на релиз • Изменяемая ветка требований на релиз • Ветвление под разные платформы, клиентов
- 12. Сравнение версий
- 14. Метрики • График разработки требований • Частота изменений требований • Продуктивность аналитиков • Процент покрытия требований • Новые отчеты в обновлениях
- 15. Трассировки
- 17. Анализ изменений
- 18. Использование • SaaS • Свой сервер: Windows, Linux, Unix • Только нужные функциональные блоки
- 19. Конкурентный анализ • MSWord, Excel, Email, Wiki, BugTracker • Cradle 3SL, Jama • codeBeamer, Palarion
- 20. Преимущества • Локализация: язык, практика • Русскоязычная поддержка • Гибкость и доступность • Кастомизация (SDK)
- 21. СПАСИБО!
Editor's Notes
- Цель создания системы
- Пожелания предназначены для сбора и документирования пользовательских требований, хотелок и заявок. В бизнес-требованиях задокументированы требования маркетинга, внешних регуляторов, результаты обследования бизнес-процессов заказчика, они хранятся в виде документов, импортированных из 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. При этом нет практически никаких средств работы с проектной документацией, управления ресурсами.
- Русскоязычная поддержка, индивидуальные консультации в области процессов, практик и использования ПО в конкретных проектах. Локализация современных практик и методологий под особенности производства ПО в РФ. Обмен опытом, полученном при работе с российскими компаниями разработчикам ПО. Русскоязычный интерфейс системы, с возможностью переключения на англоязычный интерфейс. Стоимость лицензий и поддержки в рублях, значительно ниже стоимости зарубежных аналогов. Низкая стоимость владения за счет использования «железа» уровня рабочей станции и свободно-распространяемого промежуточного ПО.